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.
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.
Syntax: [no] ip-address <ip-addr> [force-shutdown]
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.
Syntax: [no] description “<text>"
|
•
|
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.
|
Syntax: server real-name-or-ip <name> <ip-addr>
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.
Syntax: server remote-name <name> <ip-addr>
|
•
|
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
|
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.
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.
|
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.
|
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.
Syntax: [no] port <tcp/udp-port> lb-pri-servers [backup-stay-active]
Notice that the backup command is used with servers R3 and R5.
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.
Syntax: [no] port <port-name> backup
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.
ServerIron(config)# server real rs1 1.1.1.1
ServerIron(config-rs-rs1)# disable
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.
Syntax: [no] port <tcp/udp-port>
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.
Syntax: [no] host-range <num>
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.
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.
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.
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.
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.
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:
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:
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.
Syntax: [no] host-range-map <map-number>
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.
Syntax: [no] server no-host-range-ip-check.
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.
Syntax: [no] max-conn <1-1000000>
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.
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.
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.
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.
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
|
•
|
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.
|
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”.
To configure warning and shutdown thresholds for an individual server, enter a command such as the following:
Syntax: [no] response-time <warning-threshold> [<shutdown-threshold>]
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.
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.
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:
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.
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:
Copyright © 2009 Brocade Communications Systems, Inc.
