ServerIron ADX Server Load Balancing Guide
Release 12.0.00
June 15, 2009

Table of Contents Previous Next Print


Server Load Balancing > Real Server Settings

Real Server Settings
For basic real server configuration, you need to specify a name and the real server’s IP address, then add the application ports that you want to load balance. The following sections describe more advanced real server options.
Changing a Real Server’s IP Address
The ServerIron ADX enables you to easily change a real server’s IP address, even when the real server is active. This capability is useful when you want to perform some maintenance on the real server (either the server itself or the server’s configuration on the ServerIron ADX) or when the network topology has changed.
By default, when you change a server’s IP address, the ServerIron ADX performs the change gracefully, as follows:
Optionally, you can force all existing connections to be reset instead of waiting for them to terminate normally. When you force the connections to be reset, the ServerIron ADX immediately resets a connection when it receives client data for the connection.
To change a real server’s IP address, enter commands such as the following:
ServerIron(config)# server real rs1
ServerIron(config-rs-rs1)# ip-address 5.6.7.8
Syntax: [no] ip-address <ip-addr> [force-shutdown]
The <ip-addr> parameter specifies the real server’s new IP address.
The force-shutdown parameter immediately resets a client’s connection to the IP address when the ServerIron ADX receives TCP data from the client. By default, the ServerIron ADX allows existing connections to terminate normally following the address change.
Adding a Description
You can add a description to a real server, virtual server, firewall, or cache. The description appears in the output of show commands and in the running-config and startup-config files.
To add a description, enter commands such as the following:
ServerIron(config)# server real RS20 1.2.3.4
ServerIron(config-rs-RS20)# description "Real Server # 20"
Syntax: [no] description “<text>"
Configuring a Local or Remote Real Server
When you define a real server, you specify whether the real server is local or remote.
Local – A local server is one that is connected to the ServerIron ADX at Layer 2. The ServerIron ADX uses local servers for regular load balancing.
Remote – A remote server is one that is connected to the ServerIron ADX through one or more router hops. The ServerIron ADX uses remote servers only if all the local servers are unavailable.
NOTE: To use a remote server for regular load balancing, see “Configuring Primary and Backup Servers”.
Configuring a Local Real Server
To configure a local real server, enter a command such as the following:
ServerIron(config)# server real Web1 207.95.55.21
ServerIron(config-rs-Web1)
Syntax: server real-name-or-ip <name> <ip-addr>
The server name is used to bind the server IP address, so that the real server name can be used to represent the server. The server name can be any alphanumeric string of up to 32 characters.
Configuring a Remote Real Server
If the server is attached through one or more router hops, configure the server as remote. When you add a remote real server, the ServerIron ADX does not include the server in the predictor (load-balancing method). Instead, the ServerIron ADX sends traffic to the remote server only if all local real servers are unavailable. The server name is used to bind the server IP address, so that the real server name can be used to represent the server.
To configure a remote real server, enter a command such as the following:
Syntax: server remote-name <name> <ip-addr>
The server name can be any alphanumeric string of up to 32 characters.
This command is used in conjunction with the Server Load Balancing feature on the ServerIron ADX switch.
See “Real Server Ports”.
Configuring Primary and Backup Servers
The real server is either a primary server or a backup server based on how you added the server:
A primary server is used by the ServerIron ADX when load balancing client requests for an application. It is locally attached server added using the server real-name-or-ip command or Web equivalent.
A backup server is used by the ServerIron ADX only if all the primary servers are unavailable for the requested application. It is remotely attached added using the server remote-name command or Web equivalent
You can explicitly designate a server to be a primary or backup server, regardless of the command you used to add it. Thus, a primary or backup server can be locally attached or attached through a router.
In addition, this feature implements the primary and backup configuration on an individual VIP basis. You designate each backup server by changing the real server configurations. You do not need to designate the primary servers. You enable the feature in individual VIPs for individual application ports.
Figure 2.11 shows an SLB configuration that uses locally-attached and remotely-attached servers. The configuration also uses some of the servers as the primary load-balancing servers while using the other servers only as backups. Notice that one of the locally-attached servers is a backup server while one of the remotely-attached servers is a primary load-balancing server.
Figure 2.11
By default, when this feature is enabled on a VIP and all the primary servers are unavailable, a VIP begins using the backup servers until a primary server becomes available again. Once a primary server is available, the VIP uses the primary server instead. Optionally, you can configure a VIP to continue to use the backup servers even after the primary servers become available again.
To configure primary and backup servers, perform the following tasks:
1.
NOTE: You do not need to designate the primary servers. The ServerIron ADX assumes that all servers you do not designate as backup servers are primary servers.
2.
Enable use of the primary and backup servers in individual VIPs on individual application ports. Only the VIPs and application ports for which you enable the feature use it. The other application ports within the VIP, and the other VIPs, use the locally-attached servers (configured using the server real-name-or-ip command) as their primary servers and the remotely-attached servers (configured using the server remote-name command) as their backup servers.

Optionally, configure the individual applications on the VIPs to continue using the backup servers following a failover, instead of returning to the primary servers.
Designating a Real Server as a Backup
By default, the virtual server uses the locally attached real servers as the primary load-balancing servers and uses the remotely attached servers as backups.
To designate a real server to be a backup server, enter the following command:
ServerIron(config-rs-R3)# backup
Syntax: [no] backup
In order for the backup functionality to operate, you must also apply the lb-pri-servers command.
Enabling a VIP to Use the Primary and Backup Servers
To enable a VIP to use the servers designated as backups only as backups, and use the other servers as the load-balancing servers, enter the following command at the configuration level for the VIP:
ServerIron(config-vs-VIP1)# port http lb-pri-servers
This command enables VIP1 to use the backup and primary servers for application port HTTP.
The port http lb-pri-servers command is needed for the backup functionality to operate, regardless of the real servers you have, local or remote. For example, even if all your real servers are local and you have one designated as backup, it will not be used as a backup unless you apply this command.
To configure the VIP and application port to continue using the backup servers even after the primary servers become available again, use the backup-stay-active parameter, as in the following example:
ServerIron(config-vs-VIP1)# port http lb-pri-servers backup-stay-active
Syntax: [no] port <tcp/udp-port> lb-pri-servers [backup-stay-active]
Configuration Example
The example configures load-balancing shown in Figure 2.11.
To configure the real servers, enter commands such as the following:
ServerIronADX(config)# server real R1 10.10.10.10
ServerIronADX(config-rs-R1)# port http
ServerIronADX(config-rs-R1)# exit
ServerIronADX(config)# server real R2 10.10.10.20
ServerIronADX(config-rs-R2)# port http
ServerIronADX(config-rs-R2)# exit
ServerIronADX(config)# server real R3 10.10.10.30
ServerIronADX(config-rs-R3)# backup
ServerIronADX(config-rs-R3)# port http
ServerIronADX(config-rs-R3)# exit
ServerIronADX(config)# server remote-name R4 198.10.10.40
ServerIronADX(config-rs-R4)# port http
ServerIronADX(config-rs-R4)# exit
ServerIronADX(config)# server remote-name R5 198.10.10.50
ServerIronADX(config-rs-R5)# backup
ServerIronADX(config-rs-R5)# port http
 
Notice that the backup command is used with servers R3 and R5.
To configure the VIP, enter commands such as the following:
ServerIron(config-rs-R5)# server virtual-name-or-ip VIP1 198.10.10.100
ServerIron(config-vs-VIP1)# port http lb-pri-servers
ServerIron(config-vs-VIP1)# bind http R1 http R2 http R3 http R4 http R5 http
Designating a Real Server Port as a Backup
Backup functionality can be configured at the application port level. This means for a given real server, you can specify one port to be a backup, while another port is a primary. Figure 2.12 illustrates this feature.
Figure 2.12
In this example, real servers RS1 and RS2 are bound to a VIP. Each real server has three ports defined: HTTP, FTP, and DNS. RS1 is the primary server for HTTP and FTP, and the backup for DNS. RS2 is the primary server for DNS, and the backup for HTTP and FTP. An HTTP or FTP request will not be sent to RS2 unless the HTTP or FTP service on RS1 is down, and a DNS request will not be sent to RS1 unless the DNS service on RS2 is down.
To configure the VIP and the real servers in Figure 2.12, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip vs1 10.10.10.10
ServerIron(config-vs-vs1)# port http
ServerIron(config-vs-vs1)# bind http rs1 http rs2 http
ServerIron(config-vs-vs1)# port http lb-primary-servers
ServerIron(config-vs-vs1)# port ftp
ServerIron(config-vs-vs1)# bind ftp rs1 ftp rs2 ftp
ServerIron(config-vs-vs1)# port ftp lb-primary-servers
ServerIron(config-vs-vs1)# port dns
ServerIron(config-vs-vs1)# bind dns rs1 dns rs2 dns
ServerIron(config-vs-vs1)# port dns lb-primary-servers
ServerIron(config)# server real rs1 10.10.10.1
ServerIron(config-rs-rs1)# port http
ServerIron(config-rs-rs1)# port ftp
ServerIron(config-rs-rs1)# port dns backup
ServerIron(config-rs-rs1)# exit
ServerIron(config)# server real rs2 10.10.10.2
ServerIron(config-rs-rs2)# port http backup
ServerIron(config-rs-rs2)# port ftp backup
ServerIron(config-rs-rs2)# port dns
ServerIron(config-rs-rs2)# exit
 
Syntax: [no] port <port-name> backup
Disabling a Real Server
Under real server config level, you can disable a real server. Disabling a real server also disables all the existing real server ports. The real server state will become "disabeld", and no new connections will be assigned to a disabled real server. However, all the existing connections will remain. No health check will be done for a disabled real server.
To disable a real server, enter commands such as the following:
ServerIron(config)# server real rs1 1.1.1.1
ServerIron(config-rs-rs1)# disable
Syntax: [no] disable
You can enable a previously disabled real server with no disable.
Adding Application Ports to a Real Server
You must specify the application ports that you want the ServerIron ADX to load balance. The ServerIron ADX sends client requests only to the application ports you specify in the real server definition.
To add application ports to a real server you’ve already defined, enter commands such as the following:
ServerIronADX(config)# server real Web1 207.95.55.21
ServerIronADX(config-rs-Web1)# port http
ServerIronADX(config-rs-Web1)# port ftp
ServerIronADX(config-rs-Web1)# port 8080
Syntax: [no] port <tcp/udp-port>
This command has additional, optional parameters. See “Real Server Ports”.
Configuring a Host Range
If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses on the real server, configure a host range to create a range of contiguous virtual IP addresses (VIPs) based on the VIP address of the virtual server. The ServerIron ADX creates the range by creating the number of VIPs that you specify with this command. You do not specify a range; you specify the number of hosts in the range. The beginning address in the range is always the VIP. The IP addresses must be contiguous on the real server.
To define a range of 500 contiguous VIPs, enter commands such as the following:
ServerIron(config)# server real-name r1 10.4.4.4
ServerIron(config-rs-r1)# host-range 500
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.4.4.5
ServerIron(config-rs-r2)# host-range 500
ServerIron(config-rs-r2)# exit
ServerIron(config)# server virtual-name-or-ip lotsofhosts 209.157.22.99
ServerIron(config-vs-lotsofhosts)# host-range 500
ServerIron(config-vs-lotsofhosts)# exit
 
Defining a host range simplifies configuration by allowing you to enter a single command or Web option for the whole range of addresses instead of entering information for each address individually.
You must also configure a corresponding range of addresses on the virtual server. For a complete configuration example, see “Web Hosting with Unlimited Virtual IP Addresses”.
To configure a host range on a real server:
ServerIron(config)# server real-name r1 10.0.0.1
ServerIron(config-rs-r1)# host-range 20
This command configures a range of 20 IP addresses, from 10.0.0.1 through 10.0.0.20.
Syntax: [no] host-range <num>
Configuring Host-Range Maps
A host range allows you to easily configure a contiguous range of VIP addresses. Instead of individually configuring each VIP address, you can configure the base VIP address (the lowest VIP address in the range), then specify how many addresses the range contains. These VIP addresses can, in turn, be mapped to a range of real server addresses. When a client requests an address in the VIP host range, the ServerIron ADX automatically maps the VIP address to a real IP address on a real server, based on the real server address’s offset from the base VIP address.
For example, you can specify that a host range of 5 VIP addresses on a virtual server be mapped to a host range of 5 IP addresses on a real server. If the virtual server’s base IP address is 192.168.9.10 and the real server’s base IP address is 10.10.10.30, the mapping would be as follows.
 
Offset from VIP base address
Additionally, you can map a host range of VIP addresses to a host range of IP addresses on multiple real servers. For example:
 
Offset from VIP base address
With host ranges, the mapping between the host range on the virtual server and the host range on the real server(s) had to be sequential and contiguous. With the host-range map feature, addresses in the host range on the real server(s) do not need to be contiguous.
The host-range map feature allows you to select the addresses in a real server’s host range that can be mapped to addresses in the virtual server’s host range. For example, using this feature, you can establish the following mapping between a host range of VIP addresses on a virtual server and a host range of IP addresses on three real servers.
 
Offset from VIP base address
In this example, real server 1 can use addresses in its host range that are offset by 2, 3, and 4 from its base IP address to map to VIP addresses that are offset by 2, 3, and 4 from the virtual server’s base VIP address. However, the IP address in real server 1’s host range that is offset by 1 from its base IP address would not be mapped to the VIP address that is offset by 1 from the virtual server’s base VIP address.
You can use the host-range map feature with up to 32 real servers and host ranges of up to 255 addresses.
To use the host-range map feature to establish a mapping structure like the one shown in Table 2.6, perform the following tasks:
1.
2.
3.
Assigning a Bind-ID to a Real Server
A bind-ID is a number you assign to a real server. When you configure the host range map, you refer to the real servers by their bind-IDs. Assign a bind-ID to each real server to be included in a host-range map.
For example, to implement the configuration in Table 2.6, you can assign real server 1 to bind-ID = 1, real server 2 to bind-ID = 2, and real server 3 to bind-ID = 3. The following commands configure these three real servers.
ServerIron(config)# server real rs1 10.10.10.30
ServerIron(config-rs-rs1)# host-range 5
ServerIron(config-rs-rs1)# bind-id 1
ServerIron(config-rs-rs1)# port http
ServerIron(config-rs-rs1)# exit
ServerIron(config)# server real rs2 10.10.10.50
ServerIron(config-rs-rs2)# host-range 5
ServerIron(config-rs-rs2)# bind-id 2
ServerIron(config-rs-rs2)# port http
ServerIron(config-rs-rs2)# exit
ServerIron(config)# server real rs3 10.10.10.70
ServerIron(config-rs-rs3)# host-range 5
ServerIron(config-rs-rs3)# bind-id 3
ServerIron(config-rs-rs3)# port http
ServerIron(config-rs-rs3)# exit
Syntax: [no] host-range <number-of-addresses>
Syntax: [no] bind-id <number>
The host-range <number-of-addresses> command specifies the number of IP addresses that will be included in the host range for the real server. For example, since real server rs1 has a base IP address of 10.10.10.30, the host-range 5 command causes addresses 10.10.10.30 through 10.10.10.34 to be included in the host range. You use the host range map to select individual addresses within the range and omit the addresses you want to omit.
The bind-id <number> command assigns a bind-ID to each real server to be included in a host-range map. When you configure a host range map, you refer to the real servers by their bind-IDs. Each real server in a host range map must have a unique bind-ID.
Defining a Host-Range Map
The host-range map specifies which IP addresses in the host ranges of each real server you actually want to use for SLB. The map enables you to selectively include individual addresses, by specifying their offsets in the range.
To define a host range map, you associate each VIP offset with one or more bind-IDs, then determine the binary representation of this association, then convert the binary representation to a hexadecimal number. You enter this hex number as part of the host-range map definition.
When defining a host-range map, it may be useful to create a table containing a row for each VIP offset and a column for each bind-ID (real server), as well as a column for the binary representation and a column for the hex number. For each VIP offset, specify which bind-ID can use IP addresses in its host range to map to the VIP offset address. For the sample configuration in Table 2.6, such a table would look like the following:
 
VIP Offset
Binary Representation
The first line of the table indicates that VIP offset 1 applies only to the real server with bind-ID = 2. Only real server 2 will map the IP address in its host range that is offset by 1 to the IP address that is offset by one from the VIP’s base IP address. The binary representation of this is “010”, which means “not bind-ID = 3, bind-ID = 2, not bind-ID = 1". The hex representation of “010” is “2”. You enter this hex number as part of the definition of the host-range map.
Using the information in Table 2.7, you would define the host-range map for the configuration in Table 2.6 as follows:
ServerIron(config)# vip-host-range-map 1
ServerIron(config-vip-host-range-1)# vip-offset 1 2
ServerIron(config-vip-host-range-1)# vip-offset 2 7
ServerIron(config-vip-host-range-1)# vip-offset 3 5
ServerIron(config-vip-host-range-1)# vip-offset 4 3
ServerIron(config-vip-host-range-1)# exit
 
Syntax: [no] vip-host-range-map <map-number>
Syntax: [no] vip-offset <vip-offset-number> <hex-number>
The default behavior (without a host-range map definition) is to bind each VIP address offset from the virtual server’s base address to the comparable offset address on each of the real servers. In the sample configuration, the host-range map definition for VIP offset 2 specifies that addresses from all three real servers be included in the bindings. Since this is the default behavior, the vip-offset 2 7 command in the host-range map definition can be omitted.
Applying the Host-Range Map to the Virtual Server
After you assign the bind-IDs to the real servers and create a host-range map, you apply the host-range map to the virtual server.
For example, to apply host-range map 1 to virtual server vs1, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip vs1 192.168.9.10
ServerIron(config-vs-vs1)# host-range 5
ServerIron(config-vs-vs1)# host-range-map 1
ServerIron(config-vs-vs1)# port http
ServerIron(config-vs-vs1)# bind http rs1 http rs2 http rs3 http
 
Syntax: [no] host-range-map <map-number>
Disabling Overlap Checking
If you are using SwitchBack (sometimes called "Direct Server Return"), you configure a separate loopback interface on each real server for the VIP’s base address and also for each additional address in the host range you want to use on the real server.
The ServerIron ADX sends the client traffic to the real server without translating the destination address. The real server receives the client traffic addressed to a loopback address configured on the server and responds directly to the client.
Normally, the CLI checks for address range overlaps when you configure a real server. For example, if real server abc has management IP address 10.10.10.10 and a host range of 5, the CLI assumes that the real server also will have addresses 10.10.10.11 – 10.10.10.14. If you then try to configure real server def with management IP address 10.10.10.12, the CLI detects an address overlap, since 10.10.10.12 is within the range specified for abc, and displays an error message instead of accepting the configuration. Here is an example:
ServerIron(config)# server real def 10.10.10.12
duplicate IP address !!!
Error - Failed to create real server
The overlap check is not applicable to SwitchBack configurations since the addresses in the range are not going to be configured on the real server. For example, if the VIP is 192.168.9.10 with a range of 5, you need to configure loopback interfaces 192.168.9.10 – 192.168.9.14 on each real server. You do not need to configure a range beginning with the real server’s management IP address.
For a SwitchBack configuration, if the management IP address of a real server is within the host range on another real server (even though the addresses in the range will not actually be configured on the real server), you need to disable overlap checking.
NOTE: Do not disable overlap checking unless you are configuring a host range in a SwitchBack configuration. If the configuration is not SwitchBack, disabling overlap checking can cause the feature to work incorrectly.
To disable overlap checking, enter the following command:
ServerIron(config)#server no-host-range-ip-check
Syntax: [no] server no-host-range-ip-check.
After you disable the range check, use the commands described in the previous section to configure the real servers, bind-IDs, VIP, and host range map.
Defining the Maximum Number of Sessions
You can limit the maximum number of sessions the ServerIron ADX will maintain in its session table for each barrel processor of a real server . By setting a limit for each barrel processor of a real server, you can avoid a condition where the capacity threshold of the real server is exceeded.
When a barrel processor of a real server reaches the maximum defined connection threshold, an SNMP trap is sent. When all the barrel processors of a real server pool reach their maximum connection threshold, additional TCP/UDP packets are dropped, and an ICMP destination unreachable message is sent.
Up to one million total sessions are supported on the ServerIron ADX. This is also the default maximum connection value for real servers.
To modify the maximum connections supported for a specific real server, enter commands such as the following:
ServerIron(config)# server real Web1
ServerIron(config-rs-Web1)# max-conn 145000
ServerIron(config-rs-Web4)# end
ServerIron# write mem
 
Syntax: [no] max-conn <1-1000000>
You can alos limit the maximum number of connections for individual application ports on a real server.
For example, to limit the number of FTP connections on real server Web1 to 10, enter the following commands:
ServerIron(config)#server real Web1
ServerIron(config-rs-Web1)# port ftp max-conn 10
Syntax: [no] port <port> max-conn <number>
NOTE: For ftp (Port 21), the number of current connections is equal to the number of control connections, plus any data connections opened during the session. For example, logging on to an FTP site (the control connection) and transferring a file from the FTP site equal two connections. Therefore, although you have only one control connection, additional operations you perform while you are logged on could consume all the FTP connections allowed.
NOTE: If you use the max-conn command for a firewall, the command specifies the maximum permissible number of connections that can be initiated from this ServerIron ADX's direction on the firewall paths. The max-conn command does not limit the total number of connections that can exist on the ServerIron ADX, which includes connections that come from the ServerIron ADXs at the other ends of the firewall paths. For FWLB, the command to restrict the total number of connections that can exist on the ServerIron ADX is fw-exceed-max-drop.
Configuring Local Max-Conn
You can configure Local Max-Conn for real servers and real server ports on a a ServerIron ADX, as described in this section.
Configuring Local Max-Conn for a Real Server
You can configure the local limit for a real server in two ways, either explicitly, or by using a percentage.
Specify the local max-conn count explicitly
ServerIron(config)# server real rs1
ServerIron(config-real-server-rs1)# local-max-conn 3000 4000 2000
Syntax: local-max-conn <BP1-limit> <BP2-limit> <BP3-limit>
The command in this example limits max-conn to 3000, 4000, 2000 connections on BP1, BP2, and BP3 respectively.
Specify the local max-conn count using a percentage
ServerIron(config)# server real rs1
ServerIron(config)# max-conn 200000
ServerIron(config-real-server-rs1)# max-conn-weight 33 33 34
Syntax: max-conn-weight <BP1-%> <BP2-%> <BP3-%>
In this example, the command limits max-conn to 66000, 66000, 68000 connections on BP1, BP2 and BP3 respectively.
NOTE: If you do not issue the max-conn command, then the max-conn-weight command limits the connection count to 330000, 330000, 340000 connections on BP1, BP2 and BP3 respectively, considering the default max-conn limit of 1M connection per real server.
Configuring Local Max-Conn for a Real Server Port
You can configure the local limit for real server ports either explicitly or using a percentage, as described in the following sections.
Specify the local max-conn count explicitly
ServerIron(config)# server real rs1
ServerIron(config-real-server-rs1)# port http local-max-conn 3000 4000 2000
Syntax: local-max-conn <BP1-limit> <BP2-limit> <BP3-limit>
In this example, the command limits max-conn to 3000, 4000, 2000 connections on BP1, BP2, and BP3 respectively.
Specify the local max-conn count using a percentage
ServerIron(config)# server real rs1
ServerIron(config)# port http max-conn 200000
ServerIron(config-real-server-rs1)# port http max-conn-weight 33 33 34
Syntax: max-conn-weight <BP1-%> <BP2-%> <BP3-%>
In this example, the command limits max-conn to 66000, 66000, 68000 connections on BP1, BP2 and BP3 respectively.
If you do not issue the max-conn command, the max-conn-weight command limits the connection count to 330000, 330000, 340000 connections on BP1, BP2 and BP3 respectively, considering the default max-conn limit of 1M connection per real server.
Setting the Traffic Rate Threshold
You can configure a threshold for the traffic rate on a real server. When this threshold is reached, the real server is not assigned any new connections, although the real server will continue to handle previously assigned connections.
To set a threshold for the traffic rate on a real server, enter commands such as the following:
ServerIron(config)# server real R 10.10.10.50
ServerIron(config-rs-R)# byte-rate-threshold 10000
The ServerIron ADX uses the number of bytes in all received and transmitted TCP and UDP packets in its calculation of the traffic rate.
Syntax: [no] byte-rate-threshold <bytes-per-second>
Setting Warning and Shutdown Thresholds for a Server
Response-time thresholds for real servers enable you to display warning messages when a server’s response is too slow and even to stop using the server. You can specify a warning threshold and a shutdown threshold:
Warning – If an application’s average response time is longer than the number of milliseconds of the warning threshold, the software generates a Syslog message and an SNMP trap.
Shutdown – If an application’s average response time is longer than the number of milliseconds of the shutdown threshold, the software generates a Syslog message and an SNMP trap and also shuts down the application port on the real server. Other application ports on the real server are not affected.
By default, a real server does not have a warning threshold or a shutdown threshold. For each threshold, you can specify a threshold value from 0 (disabled) – 65535 milliseconds (65 seconds).
You can configure one or both thresholds globally or on an individual real server basis. The thresholds configured on an individual real server override the globally configured thresholds. After bringing down the application port, the ServerIron ADX periodically attempts to reach the port and brings the port back up once the port responds. For information, see “Application Port States”.
NOTE: This feature requires the Layer 4 and Layer 7 health checks to enabled. If the health checks are not enabled, the ServerIron ADX does not apply the response thresholds you configure.
NOTE: This feature applies only to TCP ports.
To configure warning and shutdown thresholds for an individual server, enter a command such as the following:
ServerIron(config-rs-R1)# response-time 50 75
This command sets the warning threshold to 50 milliseconds and the shutdown threshold to 75 milliseconds for the real server.
Syntax: [no] response-time <warning-threshold> [<shutdown-threshold>]
The parameters are the same as the ones for the server response-time command.
NOTE: The threshold values you configure on an individual real server override the globally configured thresholds.
To globally set warning and shutdown thresholds for all real servers, see “Configuring Warning and Shutdown Thresholds for All Real Servers”.
Viewing Threshold Messages in the Syslog
When an application port’s average response time exceeds the warning or shutdown threshold, the ServerIron ADX generates a Syslog message and an SNMP trap.
To display Syslog entries, enter the following command at any level of the CLI:
The first message shown in bold type is a warning message. The last message shown in bold type is a shutdown message.
Syntax: show logging
Disabling Layer 3 Health Check on a Real Server
By default, when you add a real server configuration to the ServerIron ADX, the ServerIron ADX uses a Layer 3 health check (IP ping) to determine the server’s reachability. If the real server responds to the ping, the ServerIron ADX changes the server’s state to ACTIVE and begins using the server for client requests.
You can globally disable the Layer 3 health check for local servers or remote servers. You also can disable the Layer 3 health check on individual real servers. When you disable the Layer 3 health check, the ServerIron ADX sends an ARP request for the default gateway and makes the server’s state ACTIVE as long as the ARP entry is present in the ServerIron ADX’s ARP cache.
By default, when you add a real server configuration to the ServerIron ADX, the ServerIron ADX uses a Layer 3 health check (IP ping) to determine the server’s reachability. If the real server responds to the ping, the ServerIron ADX changes the server’s state to ACTIVE and begins using the server for client requests. When you disable the Layer 3 health check, the ServerIron ADX sends an ARP request for the default gateway and makes the server’s state ACTIVE as long as the ARP entry is present in the ServerIron ADX’s ARP cache.
To disable the Layer 3 health check on a real server, enter the following command:
ServerIron(config-rs-R1)# no-l3-check
Syntax: [no] no-l3-check
To globally disable Layer 3 health checks for local real servers or remote real servers, use the server no-real-l3-check and server no-remote-l3-check commands.
NOTE: To globally disable Layer 3 health checks for local real servers or remote real servers, see “Layer 3 Health Check”.
NOTE: The server no-remote-l3-check command also disables Layer3 health checks of IPs learned through GSLB.
Enabling Source NAT on a Real Server
Source NAT allows the ServerIron ADX to use a source IP address as the source for packets sent to the real server.
Source NAT allows the ServerIron ADX to be in more than one subnet. If the real server and the ServerIron ADX are in different subnets and not connected by a router that is multinetted, enable source NAT on the real server.
If you enable source NAT on a real server, the feature applies only to the server. You also can enable source NAT globally. See “Enabling Source NAT Globally”.
To enable source NAT on a real server, enter commands such as the following:
ServerIron(config)# server real-name berto
ServerIron(config-rs-berto)# source-nat
Syntax: [no] source-nat
Source NAT is disabled by default.
Configuring the Weight for Real Server
This parameter specifies the weight assigned to the real server. It is used for the weighted and least connection with server response-time-weights for load balancing methods.
Suppose you want to assign a higher weight to real server Web1 to bias traffic toward that server. No other changes are made to the weights of Web servers 2, 3, and 4, and they remain configured with the default weight of zero (Figure 2.9). Enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip www.alterego.com
ServerIron(config-vs-www.alterego.com)# predictor weighted
ServerIron(config-vs-www.alterego.com)# server real Web1 207.95.55.21
ServerIron(config-vs-www.alterego.com)# exit
ServerIron(config)# server real Web1
ServerIron(config-rs-Web1)# weight 10
 
Syntax: weight <least-connections-weight> [<response-time-weight>]
The <least-connections-weight> parameter specifies the real server’s weight relative to other real servers in terms of the number of connections on the server. More precisely, this weight is based on the number of session table entries the ServerIron ADX has for TCP or UDP sessions with the real server. You can specify a value from 0 – 65000. The default is 1. This parameter is required. However, if you want to use a weight value only for the Server Response Time but not for the number of connections, specify 0 for this parameter.
The <response-time-weight> parameter specifies the real server’s weight relative to other real servers in terms of the server’s response time to client requests sent to the server. You can specify a value from 0 – 65000. The default is 0 (disabled). This weight is applicable only when the server response time load-balancing method is enabled. See “Setting a Real Server’s Weight Based on Response Time”.
If you enter a value for <response-time-weight>, the ServerIron ADX adds the two weight values together when selecting a real server. If you specify equal values for each parameter, the ServerIron ADX treats the weights equally. The number of connections on the server is just as relevant as the server’s response time. However, if you set one parameter to a higher value than the other, the ServerIron ADX places more emphasis (weight) on the parameter with the higher value. For example, if you specify a higher server response time weight than the weight for the number of connections, the ServerIron ADX pays more attention to the server’s response time than to the number of connections it currently has when considering the real server for a new connection.
Setting a Real Server’s Weight Based on Response Time
The Server Response Time metric, when used by itself, always selects the real server with the fastest response time. If all your real servers have similar response capacities, then using the Server Response Time metric by itself generally provides an even load-balancing distribution among the real servers. However, if your server farm contains a mixture of servers, some of which have greater response capability than others, you might want to set the Server Response Time weights on individual real servers.
The default Server Response Time weight is 0 (no weight). You can specify a weight from 0 – 65000. Setting a real server’s weight higher relative to other real servers biases the ServerIron ADX’s load-balancing selections toward that real server.
For example, if you bind a virtual server to three real servers, and one of the servers tends to respond less quickly than the other two but otherwise has the same connection capacity as the faster servers, you can enter commands such as the following to increase the Server Response Time weight of the faster servers:
ServerIron(config)# server real-name wolalak
ServerIron(config-rs-wolalak)# weight 1 5
ServerIron(config-rs-wolalak)# exit
ServerIron(config)# server real-name wuwanich
ServerIron(config-rs-wuwanich)# weight 1 5
 
This command sets the Server Response Time weight on the faster servers to 5, giving the servers more weight in terms of response time than the slower real server.
Syntax: [no] weight <least-connections-weight> [<response-time-weight>]
NOTE: If you use the server response time method, you also can modify the smooth factor on individual application ports. See “Configuring the Smooth Factor”.

Server Load Balancing > Real Server Settings

Table of Contents Previous Next Print
Copyright © 2009 Brocade Communications Systems, Inc.