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

Table of Contents Previous Next Print


Server Load Balancing > Virtual Server Ports

Virtual Server Ports
The following sections describe how to modify parameters for application ports on virtual servers.
Disabling or Re-enabling an Application Port
Application ports are enabled by default. To disable an application port on a virtual server, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip Zoot_Allures 1.2.3.4
ServerIron(config-vs-Zoot_Allures)# port http disable
Syntax: [no] port <tcp/udp-port> disable
To re-enable a port, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip Zoot_Allures 1.2.3.4
ServerIron(config-vs-Zoot_Allures)# no port http disable
Globally Disabling Real and Virtual Ports
You can globally disable a Layer 4 port on the ServerIron ADX. The port can be disabled for all real servers, all virtual servers or all real and virtual servers. After you disable a port globally, you can enable the port on individual real or virtual servers as necessary. By default, all real and virtual ports are enabled.
When the ServerIron ADX is booted, if the command to globally disable a real or virtual port exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port is created, and the port has been disabled globally, the real or virtual port is disabled as well. You must enable the port explicitly.
To disable all real HTTP ports:
ServerIron(config)# server port 80
ServerIron(config-port-http)# disable real
ServerIron(config-port-http)#
To disable all virtual HTTP ports:
ServerIron(config)# server port 80
ServerIron(config-port-http)# disable virtual
ServerIron(config-port-http)#
To disable all real and virtual HTTP ports:
ServerIron(config)# server port 80
ServerIron(config-port-http)# disable
ServerIron(config-port-http)#
Syntax: disable [real | virtual
Configuring Sticky Ports
By default, the ServerIron ADX sends a client’s request to the next available real server based on the load balancing method. This is true regardless of whether the client has already sent a request for the same application. If you want the ServerIron ADX to send all of a client’s requests for a given application to the same real server during a client’s session with the server, configure the application port to be sticky.
The port tracking and port group features require the application ports to be 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. These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky. In addition, the Telnet and TFTP ports are configured to track the HTTP port.
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
Syntax: [no] port <tcp/udp-port> sticky
Configuring Stickiness Based on Client’s Subet
The sticky function causes the ServerIron ADX to send all of a client’s requests for a given application to the same real server during the client’s session with the server. By default, the stickiness is based on the client's IP address. You can configure the ServerIron ADX to base the stickiness on the client’s subnet, rather than IP address. All requests originating from a specific subnet for a given application are sent to the same real server.
For example, to send all HTTP requests originating from a given subnet to the same real server, 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)# port http client-subnet-sticky prefix-length 24
Syntax: [no] port <portnum> client-subnet-sticky prefix-length <prefix-length>
or
Syntax: [no] port <portnum> client-subnet-sticky subnet-mask <client-subnet-mask>
In this example, client requests from sub-net 192.168.9.x would go to the same real server. Sub-net sticky connections are aged out according to the sticky age setting, in the same way regular sticky connections are aged out.
The features port sticky and port client-subnet-sticky cannot be configured together on the same port on the same virtual server.
The SSL port is configured as sticky by default, and the CLI will not allow you to configure port client-subnet-sticky on an SSL port of a virtual server. As a work around, you must first disable the sticky function before configuring port ssl client-subnet-sticky on a virtual serverl
ServerIron(config)# server virtual-name-or-ip vs1 10.10.10.10
ServerIron(config-vs-vs1)# port ssl
ServerIron(config-vs-vs1)# no port ssl sticky
ServerIron(config-vs-vs1)# port ssl client-subnet-sticky prefix-length 24
Increase Sticky-age per VIP longer than 60 minutes
Several applications require sticky age to be longer than the 60 minute global maximum that is configured using the server sticky-age command as described in “Setting the Sticky Age”. This may occur where a client connects in the morning and requires connectivity throughput the day.
There are also situations where you may want to configure a different value per Virtual Server. The following command allows you to apply a multiplier value to the global sticky-age value for a specific Virtual Server:
ServerIron(config)# server virtual-name-or-ip vs1 10.10.10.10
ServerIron(config-vs-vs1)# sticky-age-multiplier 5
 
Syntax: sticky-age-multiplier <multiplier-value>
The <multiplier-value> variable is a numerical value in the following range: 2 to 120. This value is used to produce a sticky-age value for the Virtual Server it is configured under that is a multiple of the value configured globally for the ServerIron as described in “Setting the Sticky Age”. For example, if the sticky age is configured to be 20 minutes, and the sticky-age-multiplier to be 40, then the actual sticky age of the sticky sessions for the server will be 20x40= 800 minutes.
Please note that even though the sticky-ages are multiplied, the show session command will still only show ordinary age of the sticky sessions. The difference is that the age is incremented in a slower pace when multiplier is applied. For example if the sticky-age-multiplier is configured to be 40, the age counter in the session table is incremented once in 40 minutes instead of 1 minute.
NOTE: You can remove the multiplier by using sticky-age-multiplier 1 or no sticky-age-multiplier <number>
Enabling a Concurrent Port
The concurrent feature allows a client to have sessions on different application ports on the same real server at the same time. When you enable an application port to be concurrent, the real server can open additional (“concurrent”) TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers.
Although the concurrent connections attribute is similar to application groups, application groups apply to specific TCP/UDP ports that you configure on the virtual server.
NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent.
To enable an application port to be concurrent, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 concurrent
Syntax: [no] port <tcp/udp-port> concurrent
Configuring the Smooth Factor
This section applies to the server response time load balancing method.
The ServerIron ADX calculates the server response time value for a real server by regularly collecting response time samples, then using a calculation to smooth the values of the samples and derive a single response time value for the real server. The ServerIron ADX collects the samples around once every 100 milliseconds (about 10 times a second). The sampling rate can vary slightly depending on the processing the ServerIron ADX is performing.
To smooth the samples out, the ServerIron ADX uses the following calculation:
R = ((S * previous_R) + ((100 - S) * new_R)) / 100
where:
R = Response time
S = Smooth factor, which is configurable and can be from 1 – 99. The default is 90. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time.
For example, if a given real server’s previous response time value was 2 milliseconds, and a new measurement also results in 2 milliseconds, the calculated server response time using the default smooth factor is as follows:
R = ((90 * 2) + ((100 - 90) * 2) / 100
R = 180 + 20 / 100
R = 200 / 100
R = 2
If the real server’s response time slows due to processing for additional connections, the slower response time affects the Server Response Time calculation for the server. For example, if the next server response time sample is 5 milliseconds instead of 2, the Server Response Time calculation is as follows:
R = ((90 * 2) + ((100 - 90) * 5) / 100
R = 180 + 50 / 100
R = 230 / 100
R = 2.3
Since the real server’s response time has slowed by two and a half times, the server’s response time calculation biases the ServerIron ADX away from selecting that server for new connections.
You can affect the degree of difference in subsequent response time weights by changing the smooth factor (S). For example, if you change the smooth factor from 90 (the default) to 50, the calculations shown above have the following results:
Here is the calculation when the previous and new response times are 2 milliseconds:
R = ((50 * 2) + ((100 - 50) * 2) / 100
R = 100 + 100 / 100
R = 200 / 100
R = 2
Here is the calculation if the server’s next response time is 5 milliseconds.
R = ((50 * 2) + ((100 - 50) * 5) / 100
R = 100 + 250 / 100
R = 350 / 100
R = 3.5
Notice that the differences between the first and second samples are much greater when the smooth factor is 50 than when the smooth factor is 90. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time.
You can change the smooth factor on an individual virtual server basis and on an individual application port basis.
If you change the smooth factor for an application port, the change affects Server Response Time calculations only for port bindings that use that application port.
To change the smooth factor for a virtual server, enter a command such as the following at the configuration level for the virtual server:
ServerIron(config-vs-Joes_Garage)# port 80 smooth-factor 50
Syntax: [no] smooth-factor <num>
The <num> parameter specifies the smooth factor value the server response time calculation uses. You can specify a number from 1 – 99. The default is 90.
Configuring a Stateless Port
By default, the ServerIron ADX creates session table entries for sessions between clients and applications on real servers. The ServerIron ADX uses the session table entries to maintain state information for the sessions. The ServerIron ADX uses the state information for features such as health checking and session failover in hot-standby configurations.
You can configure individual application ports to be stateless. The ServerIron ADX does not maintain state information for a stateless port. Making a port stateless is useful when you want to conserve session table resources or when you have configured the VIP to be transparent.
For examples and configuration information, see “Stateless Server Load Balancing”.
To configure an application port to be stateless, enable the stateless parameter on the port in the virtual server, such as the follwing:
ServerIron(config)# server real R1 10.10.10.1
ServerIron(config-rs-R1)# port http
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real R2 10.10.11.1
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# exit
ServerIron(config)# server virtual-name-or-ip StatelessHTTP 192.168.4.69
ServerIron(config-vs-StatelessHTTP)# port http stateless
ServerIron(config-vs-StatelessHTTP)# bind http R1 http
ServerIron(config-vs-StatelessHTTP)# bind http R2 http
 
Syntax: [no] port <tcp/udp-portnum> stateless
The <tcp/udp-portnum> parameter specifies the application port you want to make stateless.
NOTE: This software release supports stateless SLB only for TCP port 80 (HTTP).
Configuring Virtual Source
In a typical configuration, a client’s IP address remains the same throughout the client’s session with a virtual server. However, in some configurations where a proxy is used for the clients before the client traffic reaches the ServerIron ADX, the client’s IP address can be different for each request. To configure session persistence in a proxy environment, configure a standard IP ACL containing the addresses, then use the Virtual Source feature.
When you configure the Virtual Source feature, the ServerIron ADX sends all client traffic from a specified range of IP addresses to the same real server for the application ports you specify. To specify the IP addresses, configure a standard IP ACL. Use this command in configurations where a proxy device allocates IP addresses to client traffic before sending the traffic to the VIP. In some configurations, the proxy device assigns different IP addresses to traffic from the same client. Unless you configure the addresses to go to the same real server, the ServerIron ADX might load balance the client traffic to different servers. This makes applications that require continued access to the same real server unusable.
To configure the Virtual Source feature, enter commands such as the following:
ServerIron(config)# access-list 1 permit 209.157.22.0
ServerIron(config)# server virtual-name-or-ip fromproxy 1.1.1.1
ServerIron(config-vs-fromproxy)# port 80 sticky-acl 1
Syntax: [no] access-list <num> deny | permit <source-ip> | <hostname> <wildcard> [log]
or
Syntax: [no] access-list <num> deny | permit <source-ip>/<mask-bits> | <hostname> [log]
Syntax: [no] port <tcp/udp-port> sticky-acl <num>
NOTE: This feature is different from the sticky feature, which you can associate with ports on the virtual server level. The sticky attribute ensures that subsequent packets from the same client during the same TCP session go to the same real server. In this case, the ServerIron ADX knows the packets are from the same client based on the source IP address. When a proxy is used, subsequent packets from the same client can have different IP addresses.
For standard IP ACL configuration information, see the “Configuring Standard ACLs” section in the “Access Control Lists” chapter of the Brocade ServerIron ADX Security Guide.
Disabling Port Translation
By default, the ServerIron ADX translates the application port number requested by the client into the application port number you specify on the virtual server when you bind it to the real server. For example, if you bind port 80 on a virtual server to port 8080 on a real server, the ServerIron ADX translates the application port in the client’s request from port 80 into 8080 before forwarding the request to a real server.
A few ServerIron ADX configurations require that you disable translation for an application port. For example, if you want to bind multiple virtual IP addresses to the same real server, you must disable port translation for all but one of the virtual IP addresses, then bind the virtual IP addresses to an alias port for the application. Disabling port translation enables the virtual IP addresses to use the same actual port number on the real server while the ServerIron ADX collects and displays separate statistics for the alias port number associated with each virtual IP address.
For a complete configuration example, see “Many-To-One TCP/UDP Port Binding”.
To disable translation for an application port, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# no port 80 translate
Syntax: [no] port <tcp/udp-port> translate
Enabling the ServerIron ADX to Use the Alias Port’s State
In a configuration with two VIPs bound to the same server port, where the VIPs are hosting multiple Web sites on the same server (different VIPs point to different sites), an alias port is required. In this scenario, if the master port goes down, the ServerIron ADX stops forwarding traffic to the other sites as well, even though these sites are up. This occurs because the ServerIron ADX uses the master port’s state for traffic forwarding decisions. To resolve this issue, you must enable the ServerIron ADX to use the alias port’s state for traffic forwarding decisions. Thus, if the alias port’s state is up, the ServerIron ADX continues to forwarding traffic. Likewise, if the alias port’s state is down, the ServerIron ADX stops forwarding traffic to the server.
To enable the ServerIron ADX to use the alias port’s state for traffic forwarding decisions, enter the following command:
ServerIronADX(config-vs-v2))# port http use-alias-port-state
Syntax: port <tcp/udp port> use-alias-port-state
In the next example, if site test1 goes down, the ServerIron ADX would stop forwarding traffic to VIP2 as well. In this scenario, you would enable the port http-use-alias-port-state command so that traffic to VIP2 does not stop when site test1 goes down.
ServerIronADX(config)# server real r1 10.10.1.31
ServerIronADX(config-rs-r1)# port http
ServerIronADX(config-rs-r1)# port http url "test1.html"
ServerIronADX(config-rs-r1)# port 8080
ServerIronADX(config-rs-r1)# port 8080 url "test2.html"
ServerIronADX(config-rs-r1)# server virt VIP1 10.10.1.121
ServerIronADX(config-vs-v1)# port http
ServerIronADX(config-vs-v1)# bind http r1 http
ServerIronADX(config-vs-v1)# server virt VIP2 10.10.1.122
ServerIronADX(config-vs-v2)# port http
ServerIronADX(config-vs-v2)# bind http r1 8080
ServerIronADX(config-vs-v2)# no port http translate
Sticky Connection Return from Backup Server to Primary
You can designate real servers as primary servers or backup servers. A primary server is used by the ServerIron ADX when load balancing client requests for an application. A backup server is used by the ServerIron ADX only if all the primary servers are unavailable for the requested application.
In a configuration where one real server is configured as a primary server and another is configured as a backup, the virtual server may have the sticky option enabled, which ensures that new connections are sent to the primary server, and a sticky session to a given port is created that points to that primary server.
If the primary server goes down, new connections are sent to the backup server, and a sticky session to the port is created that points to the backup server. The sticky session to the (inoperative) primary server is deleted. When the primary server becomes operative again, since the sticky session to the backup server is still valid (that is, it has not aged out), new connections to the port are still sent to the backup server. This is the default behavior.
You can optionally configure the ServerIron ADX to send new connections for the port to the primary server when it comes back up, even though there is a sticky session to the backup server.
To do this for the DNS port on virtual server v1, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1 192.168.9.210
ServerIron(config-vs-v1)# port dns lb-pri-servers
ServerIron(config-vs-v1)# port dns sticky
ServerIron(config-vs-v1)# port dns active-primary-overide-sticky
Syntax: port <port> active-primary-overide-sticky
When the active-primary-overide-sticky command is configured, if the primary server goes down and then comes back up, any new connection to the DNS port is sent to the primary server. The old sticky session to the backup server is deleted, and a new sticky session to the primary server is created.
Performing SLB Based on Alias Port State
To perform SLB based on an alias port state, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip v1 10.10.1.151
ServerIron(config-vs-v1)# port 8080
ServerIron(config-vs-v1)# no port 8080 translate
ServerIron(config-vs-v1)# port 8080 use-alias-port-state
Syntax: [no] port <number> use-alias-port-state
Assume a configuration having two VIPs on the same real server with different healthchecks for each VIP using no port translate. If the real server healthcheck fails for the first VIP (bound to master port), traffic is not sent to the second VIP (bound to alias port). The client will receive a RST. When port use-alias-port-state is enabled, traffic to a VIP on the alias port will be forwarded if the health of the alias port passes. This feature is useful in scenarios where master port health and alias port health are using different URLs for healthcheck.

Server Load Balancing > Virtual Server Ports

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