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.
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.
Syntax: [no] port <tcp/udp-port>
Syntax: bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number>
Syntax: [no] port <tcp/udp-port> lb-pri-servers [backup-stay-active]
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.
Syntax: [no] host-range <range>
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.
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.
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.
Syntax: [no] track <primary-port> <TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-port>]]]
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 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.
|
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
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.
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.
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:
Syntax: [no] server track-group-unbind-wait-all
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.
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.
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.
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).
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.
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.
ServerIron(config)# server virtual-name-or-ip vs1 192.168.1.2
ServerIron(config-vs-vs1)# port 1234 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:
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.
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”.
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.
Syntax: [no] tcp-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).
Copyright © 2009 Brocade Communications Systems, Inc.
