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

Table of Contents Previous Next Print


Server Load Balancing > VIP Settings

VIP Settings
For basic Virtual IP server (VIP) configuration, you need to specify a name and the virtual server’s IP address (the VIP), add the application ports that you want to load balance, then bind the VIP to the real servers based on the application ports. The following sections describe more advanced virtual server options.
Adding Application Ports and Bindings
You can specify the TCP or UDP application ports for which you want the ServerIron ADX to load balance requests. Add the ports to the virtual server, then bind the virtual server to the real server based on the ports.
You can use the CLI. See “Binding Virtual and Real Servers”.
To add an application port to a virtual server, enter commands such as the following:
ServerIron(config-rs-Web4)# server virtual-name-or-ip www.altergo.com 207.95.55.1
ServerIron(config-vs-www.alterego.com)# port http
Syntax: [no] port <tcp/udp-port>
This command has additional, optional parameters. See “Virtual Server Ports”.
To bind a real server to a virtual server, enter commands such as the following:
ServerIron(config-rs-Web4)# server virtual-name-or-ip www.altergo.com
ServerIron(config-vs-www.alterego.com)# bind http Web1 http
ServerIron(config-vs-www.alterego.com)# bind http Web2 http
ServerIron(config-vs-www.alterego.com)# bind http Web3 http
ServerIron(config-vs-www.alterego.com)# bind http Web4 http
 
Syntax: bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number>
NOTE: For clarity, the bindings in the example above are shown as four separate entries. Alternatively, you can enter all the binding information as one command: bind http Web1 http Web2 http Web3 http Web4 http
Configuring Primary and Backup Servers
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.
You can enable the virtual server to use the servers designated as backups only as backups, and use the other servers as the primary load-balancing servers.
To configure primary and backup servers:
1.
NOTE: You do not need to designate the primary servers. The ServerIron ADX assumes that all servers you do not designate as backup serves 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 as their primary servers and the remotely-attached servers 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.
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 primary 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.
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]
For a complete CLI example, see “Configuring Primary and Backup Servers”.
Configuring a Host Range
If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses, define a host range on the real servers and on the virtual server. 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.
NOTE: You also must configure the same size host range on each of the real servers.
For a complete configuration example, see “Web Hosting with Unlimited Virtual IP Addresses”.
To configure a host range on a virtual server, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.6
ServerIron(config-vs-v1)# host-range 20
Syntax: [no] host-range <range>
Enabling HTTP Redirect on a Virtual Server
HTTP redirect is disabled by default on a virtual server. When enabled, HTTP redicrect configures the ServerIron ADX to send an HTTP redirect message to the client, so the client redirects its HTTP connection to the real server’s IP address instead of the VIP. Use HTTP redicrect when you configure remote real servers and want replies from the servers to go directly to clients.
For a complete configuration example, see “Using HTTP Redirect with Geographically-Distributed Servers”.
To enable HTTP redirect on a virtual server, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip VIP1 209.157.22.88
ServerIron(config-vs-VIP1) #port http
ServerIron(config-vs-VIP1)# bind http r1 80 r2 80 r3 80
ServerIron(config-vs-VIP1)# httpredirect
Syntax: [no] httpredirect
Setting Symmetric SLB Priority
If you are configuring a pair of ServerIron ADXs to provide redundancy for individual VIPs, you must specify an SLB priority on each ServerIron ADX for each of the VIPs. The ServerIron ADX with the higher priority for a given VIP is the default active ServerIron ADX for that VIP. The other ServerIron ADX is the default standby for the VIP.
For a configuration example and more information, see “Symmetric SLB”.
To specify the priority, enter a command such as the following:
ServerIron(config)# server virtual-name-or-ip noi-is-cool 1.2.3.4
ServerIron(config-vs-noi-is-cool)# sym-priority 254
Syntax: [no] sym-priority <num>
You can specify from 0 – 255. If you specify 0, the priority setting is removed.
NOTE: Brocade recommends that you specify 2 (instead of 1) as a low priority or 254 (instead of 255) as a high priority. This way, you can easily force failover of the high priority ServerIron ADX to the low priority ServerIron ADX by changing the priority on just one of the ServerIron ADXs. For example, you can force a failover by changing the priority on the high priority ServerIron ADX from 254 to 1. Since the priority on the low priority ServerIron ADX is 2, the low priority ServerIron ADX takes over for the VIP. Likewise, you can force the low priority ServerIron ADX to take over by changing its priority to 255, since the priority on the high priority ServerIron ADX is only 254.
Tracking the Primary Port
You can configure the ServerIron ADX to send all client requests for a specific set of TCP/UDP ports to the same real server as a “primary” TCP/UDP port grouped with the other ports. You can group a primary TCP/UDP port with up to four additional TCP/UDP ports. After the ServerIron ADX sends a client request for the primary port to a real server, subsequent requests from the client for ports grouped with the primary port go to the same real server. See “TCP/UDP Application Groups” for an example of application grouping.
Note that if any service port is down for a real server, any track ports on that real server are not considered for load balancing.
NOTE: You must configure all the grouped ports to be “sticky” and bind them to all real servers involved.
NOTE: If a client requests one of the ports that follows the primary port before requesting the primary port itself, the ServerIron ADX does not make the connection sticky. Only after the client requests the primary port does the ServerIron ADX make subsequent requests from the client for that port or ports that track the primary port sticky.
NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent.
For a configuration example and more information, see “TCP/UDP Application Groups”.
To configure a TCP/UDP application group, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# track 80 23 69
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(config-vs-v1)# bind 69 r1 69 r2 69
These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky.
Syntax: [no] track <primary-port> <TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-port>]]]
Configuring a Track Port Group
A track group is similar to track ports. The ServerIron ADX sends a client’s request for one of the ports to the same real server the ServerIron ADX selected for the same client’s request for another application port. The features differ in the following way:
In a track port configuration, the tracking applies only to the primary port, which is the first port in the list of track ports. If the client requests one of the other applications (one of the applications that is tracking the primary application) first, the ServerIron ADX track feature does not apply.
In a track port group, the ServerIron ADX sends a client’s requests for any of the applications in the group to the same real server, regardless of which application the client requests first.
For a configuration example and more information, see “TCP/UDP Application Groups”.
Note that if any service port is down for a real server, any track port groups on that real server are not considered for load balancing.
NOTE: You must configure all the track port groups to be “sticky” and bind them to all real servers involved.
To configure a track port group, use either of the following methods.
The following commands illustrate the track group function:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# track-group 80 69 23
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(config-vs-v1)# bind 69 r1 69 r2 69
ServerIron(config-vs-v1)# exit
Syntax: [no] track-group <TCP/UDP-port>...
In this example, the track-group command groups the HTTP port (80), Telnet port (23), and TFTP port (69) together. Whenever a client attempts to connect to a port within the group, the ServerIron ADX ensures all ports in the group are active before granting the connection.
The sticky parameter makes the TCP/UDP ports sticky. The sticky parameter must be set for all ports in the group.
After the ServerIron ADX sends a client to a real server for any of these three ports, subsequent requests from that client for the HTTP, TFTP, or Telnet port go to the same real server. Up to eight ports can be grouped together using the track group function. A port can be part of only one group. The track-group and track commands for a port are mutually exclusive.
Track Group Health Check for Real Servers
NOTE: The track-group functionality discussed earlier is available under virtual server definition. The ServerIron ADX also allows track-group specification under real server definition. This capability helps reduce the need for creating large numbers of boolean health checks.
You can track the health of multiple application ports under real server definition. If the health of one of the application ports fail then the aggregated health wii be marked as fail.
The feature co-exists with existing health checks and other features of the ServerIron ADX. If even one of the application ports under real server is not up then track-group state will be down and hence the traffic will not be forwarded to any of the ports of the track group.
A sample configuration is shown below:
ServerIron(config)# server real r1 1.1.1.1
ServerIron(config-real-server-r1) port 80
ServerIron(config-real-server-r1) port ftp
ServerIron(config-real-server-r1) port dns
ServerIron(config-rsr1) hc-track-group 80 21 53
 
The ServerIron ADX now tracks health status for ports 80, 21, and 53. If any of these ports is down then the combined health would be marked as failed and the ServerIron will not use these ports for load balancing traffic.
Sample Configuration
server real rs1 10.1.1.1
port http
port 8081
port 8082
hc-track-group http 8081 8082
Here is the output of the show command for this feature:
ServerIron# show hc-track-group
Real Server track-group state
rs1 80 21 53 ACTIVE
Enabling Track Ports in a Track Group to Unbind
By default, when you unbind a port that is the lead port in a track group, all the ports that track the lead port also are immediately unbound. This occurs even if a port is still active and has not completed the AW_unbind (awaiting unbind) state.
To configure the ServerIron ADX to allow track ports in a track group to unbind gracefully following the unbinding of the track group’s lead port, enter the following command:
ServerIron(config)# server track-group-unbind-wait-all
Syntax: [no] server track-group-unbind-wait-all
Identifying VIP Port as TCP Only or UDP Only
You can explicitly identify an application port to be "TCP only" or "UDP only". The "TCP only" port accepts connections that arrive on TCP transport and drop connections that arrive on UDP transport. The ports that are identified as "UDP only" ports accept connections only on UDP transport.
On ServerIron ADX, when a port is defined under VIP, both UDP and TCP traffic with the port number are enabled and passed through to the real server. This is not desirable in some cases.
As an enhancement, the user is to be allowed to define a TCP-only or UDP-only port so that only TCP or UDP traffic with the specified port number can pass through. This document is the feature specification for this enhancement.
TCP-only or UDP-only traffic control has been supported internally on ServerIron, but no CLI is available for the user to enable it.
As the enhancement, following commands are to be provided to the user to enable/disable TCP-only or UDP-only traffic control for a port defined under VIP:
Syntax: [no] port <port> tcp-only
Syntax: [no] port <port> udp-only
The command is available under VIP configuration mode.
When either TCP-only or UDP-only is configured, only TCP traffic or UDP traffic can pass through as configured; otherwise both TCP traffic and UDP traffic can pass through as before. TCP-only and UDP-only are exclusive, that means when TCP-only is configured, TCP-only and UDP-only cannot be configured for a port at the same time. UDP-only will be automatically disabled if TCP-only is configured, and vice verse.
Enabling Server Cluster Support
In some configurations, such as those that use a cluster of servers for an application, you might want to configure the ServerIron ADX to stop sending traffic for established connections to a server when the requested application is down on the server. For example, this feature is useful in an Network File System (NFS) server farm
When you enable this feature, the ServerIron ADX does one of the following in addition to redirecting future requests away from the real server:
UDP – For an unavailable UDP application, the ServerIron ADX terminates the connection.
TCP – For an unavailable TCP application, the ServerIron ADX resets the connection.
NOTE: The ServerIron ADX always redirects new connections to real servers on which the requested application ports are available. The command in this section applies only to connections that are already established when the application fails.
To configure the ServerIron ADX to stop sending requests for an established connection to a real server for an application that is down on the server, enter the following command at the configuration level for the VIP:
ServerIron(config-vs-VIP1)# port 80 reset-on-port-fail
This command configures the ServerIron ADX to stop sending traffic on existing HTTP connections to a real server bound to VIP1 if the HTTP application has failed on the server. The ServerIron ADX instead terminates the connection (if UDP) or resets the connection (if TCP).
Syntax: [no] port <tcp/udp-portnum> reset-port-on-fail
Enabling Fast Aging for UDP Sessions
When fast aging for UDP sessions is configured, a client request causes the ServerIron ADX to add an entry to its session table; when a response is detected, the ServerIron ADX immediately deletes the session table entry.
NOTE: Fast aging is the default behavior for the well-known DNS and RADIUS ports. To change DNS or RADIUS to use the UDP age timer instead, see “Enabling Normal UDP Aging for DNS and RADIUS”.
When this feature is configured, if the ServerIron ADX detects a server response to a client request, and the response is not fragmented, the session table entry is deleted immediately. If the response is fragmented, the ServerIron ADX waits for the last fragment to arrive, forwards it to the client, and then sends the session to the delete queue. The session stays in the delete queue for 8 seconds by default before being deleted. You can change the amount of time the session stays in the delete queue to between 1 – 40 seconds.
To activate fast aging for UDP sessions for port 1234, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip vs1 192.168.1.2
ServerIron(config-vs-vs1)# port 1234 udp-fast-age
Syntax: port <UDP-portnum> udp-fast-age
To set the amount of time sessions for ports configured with the udp-fast-age command stay in the delete queue before being deleted:
ServerIron(config)# server msl 2
Syntax: server msl <secs>
The <secs> parameter can be from 1 – 40 seconds.
Enabling Normal UDP Aging for DNS and RADIUS
By default, the ServerIron ADX immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron ADX receives a reply for the application from a real server. You can configure the ServerIron ADX to instead age DNS or RADIUS sessions out normally using the UDP age timer.
To age DNS or RADIUS sessions using the UDP age timer, enter the following command at the global CONFIG level of the CLI:
ServerIron(config-vs-VIP1)# port dns udp-normal-age
Syntax: [no] port dns | radius udp-normal-age
For DNS and RADIUS UDP load balancing, unless the port is configured with this command, the DNS or RADIUS sessions are always aged out after two minutes.
Enabling Transparent VIP
Transparent VIP allows you to configure a ServerIron ADX to transparently load balance a VIP, without owning the VIP address. Multiple ServerIron ADXs on which this virtual server is configured to be transparent can load balance requests for the server. For examples and configuration information, see “Stateless Server Load Balancing”.
To configure an individual virtual server for the transparent VIP feature, enter a command such as the following:
ServerIronADX(config-vs-TransVIP)# transparent-vip
Syntax: [no] transparent-vip
Setting TCP and UDP Ages for VIPs
The TCP and UDP ages specify how many minutes a TCP or UDP session can remain inactive before the ServerIron ADX closes the session and clears the session from its session table. You can set the TCP or UDP ages for a specific virtual server, and you can set the TCP or UDP ages for an individual port on a virtual server.
For example, to set the TCP age for virtual server v1 to 20 minutes, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1
ServerIron(config-vs-v1)# tcp-age 20
Syntax: [no] tcp-age <minutes>
To set the UDP age for virtual server v1 to 26 minutes, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1
ServerIron(config-vs-v1)# udp-age 26
Syntax: [no] udp-age <minutes>
To set the TCP age for the HTTP port on virtual server v1 to 10 minutes, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1
ServerIron(config-vs-v1)# port http tcp-age 10
Syntax: [no] port <port> tcp-age <minutes>
To set the UDP age for the SNMP port on virtual server v1 to 26 minutes, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1
ServerIron(config-vs-v1)# port snmp udp-age 26
Syntax: [no] port <port> udp-age <minutes>
You can set the TCP or UDP age from 2 – 60 minutes. The default TCP age is 30 minutes. The default UDP age is five minutes.
More specific settings override more general settings; that is, a TCP or UDP age setting for the HTTP port will override a TCP or UDP age setting for the virtual server, which will override the global TCP or UDP age (set with the server tcp-age or server udp-age commands).

Server Load Balancing > VIP Settings

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