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

Table of Contents Previous Next Print


Health Checks > Health Checks Overview

Health Checks Overview
The ServerIron ADX uses Layer 3, Layer 4, and Layer 7 health checks to verify the availability of real servers and applications on the real servers.
When you configure a real server, the ServerIron ADX sends an ARP request for the real server and then sends an IP ping to the server to verify that the ServerIron ADX can reach the server through the network. The ARP request is sometimes referred to as a Layer 2 health check since the request is for the real server’s hardware layer address.
Later, when you bind the real server to a Virtual IP (VIP) server, the ServerIron ADX sends a Layer 4 or Layer 7 health check to bring up the port you used for the binding. For example, if you bind a real server to a virtual server using port HTTP, the ServerIron ADX sends an HTTP Layer 7 health check to bring up the HTTP port on the real server.
The ServerIron ADX performs the health checks described above by default. In addition, you can enable periodic Layer 4 or Layer 7 keepalive health checks for individual application ports. Following successful bringup of an application port when you bind a real server to a virtual server, the ServerIron ADX repeats the Layer 4 or Layer 7 keepalive health check to continually verify the health of the port.
Enhanced Server Bringup
Enhanced Server Bringup increases the speed of the bringup process, by sending more (up to a maximum of 50) health-checks at one time.
In previous releases, the ServerIron ADX would send a health check for each real server port in a configuration, in the process of bringing up all of the ports. As a result, if the configuration contained a lot of real server ports, the ServerIron ADX would take too much time to bring all of the ports up, one port at a time. To make the bringup process faster, the ServerIron now sends more bringup health-checks at a time (up to a maximum of 50). The actual number of health-checks that the ServerIron ADX sends at any given instance depends on the number of server ports that are in the testing state. The ServerIron ADX performs L2 and L3 health checks, and if these are successful, it puts the port in a testing state. When it is time to send out bringup health checks, the ServerIron ADX collects all the server ports that are in the testing state, and sends them health checks.
The actual number of health checks that are sent out at any given instance also depends on the number of server ports for which the ServerIron ADX has sent out the health-check request and is still waiting for response. For example, if there are 75 server ports configured on the ServerIron ADX, and at the first instance since 30 have passed L2 and L3 checks, the ServerIron ADX sends out bringup health-checks to these 30 server ports. In the next 100 ms, when it is time to send out health-checks again, if only 20 of the above 30 server ports have responded and are UP, then there are 10 ports that are still in the bringup process. Assuming that the remaining 45 server ports have all passed L2 and L3 checks, the ServerIron ADX can send bringup health-checks for 40 server ports, since it is waiting for response for the 10 previously sent. In the next 100 ms cycle, when it is time to send the next round of health-checks, assuming that the ServerIron ADX got response from all the 50 server ports, it now sends bringup health-checks for the remaining 5 server ports. The ServerIron ADX can send 50 bringup health-checks at a time separately for TCP and UDP ports.
Application Ports
The ServerIron ADX selects a Layer 4 or Layer 7 health check based on whether the application port is known to the ServerIron ADX. A Layer 4 health check is a TCP or UDP request and is not related to a specific application. A Layer 7 health check is an application-aware health check designed for the specific application. The following application ports are known to the ServerIron ADX. The ServerIron ADX performs Layer 7 health checks for these ports. For other ports, the ServerIron ADX performs a Layer 4 TCP or UDP health check instead:
TCP Ports
UDP Ports
NOTE: You can add either port 1812 or port 1645 to a given real or virtual server, but you cannot add both ports to the same server.
The keepalive health checks are disabled by default. To enable a keepalive health check for an application port, configure a port profile for the port (which automatically enables the keepalive globally for the port) or enable the keepalive on individual real servers that use the port.
Layer 3 Health Checks
Layer 3 health checks consist of ICMP-based IP pings and ARP requests. When you configure a real server on the ServerIron ADX, the ServerIron ADX sends an ARP request and an IP ping to the real server to verify that the ServerIron ADX can reach the server through the network.
The ServerIron ADX also sends an IP ping to a real server in the following circumstances:
If the ARP entry for the server times out. In this case, the ServerIron ADX uses the IP ping to create a new ARP entry for the server. The ARP request is sometimes referred to as a Layer 2 health check since the request is for the real server’s hardware layer address.
If the time between the last packet sent to the server and the last packet received from the server increases. In this case, the ServerIron ADX uses the IP ping to determine whether the slowed response time indicates loss of the server. If the server responds to the ping, the ServerIron ADX then sends a Layer 4 or Layer 7 health check, depending on whether the port’s application type is known to the ServerIron ADX. The ServerIron ADX sends pings at an interval of 2 seconds apart, and retries unsuccessful pings up to 4 times by default. You can change the ping interval and retries if desired. See “Modifying the Ping Interval and Ping Retries”.
The following Layer 3 health check types are supported:
ARP Request
A standard IP ARP request for the server’s MAC address, which the ServerIron ADX adds to its ARP table.
Perform:
IP Ping
A standard ICMP-based IP ping.
Performed
 
A standard IP ARP request for the server’s MAC address, which the ServerIron ADX adds to its ARP table.
If the time between the last packet sent to the server and the last packet received from the server increases
Layer 4 Health Checks
When you bind a real server to a virtual server, the ServerIron ADX performs either a Layer 4 TCP or UDP health check or a Layer 7 health check to bring up the application port that binds the real and virtual servers. If the application port is not one of the applications that is known to the ServerIron ADX, the ServerIron ADX uses a Layer 4 health check. Otherwise, the ServerIron ADX uses the Layer 7 health check for the known application type.
The Layer 4 health check can be a TCP check or a UDP check:
TCP health check – The ServerIron ADX checks the TCP port’s health based on a TCP three-way handshake:
UDP health check – The ServerIron ADX sends a UDP packet with garbage (meaningless) data to the UDP port:
If the server does not respond at all, the ServerIron ADX assumes that the port is alive and received the garbage data. Since UDP is a connectionless protocol, the ServerIron ADX and other clients do not expect replies to data sent to a UDP port. Thus, lack of a response indicates a healthy port.
NOTE: The ServerIron ADX assumes that a port is a UDP port unless you configure the port as a TCP port. To configure a port as a TCP port, add a port profile for the port and specify the port type TCP. See “Port Profiles and Attributes”.
After the ServerIron ADX sends an initial packet (TCP or UDP) to the server to bring the port up, the ServerIron ADX waits one second and then checks for a response from the server. If no response is received during that time, the ServerIron ADX will send another packet. The time at which the ServerIron ADX sends the second packet depends on the number of ports being brought up at that time. The ServerIron ADX will send the second packet after it has sent initial packets to all the other ports being brought up at that time.
By default, the ServerIron ADX does not repeat the Layer 4 health check after bringing up the port when you bind the real server to the virtual server. However, you can enable a periodic keepalive health check for the port. To configure the keepalive health check globally, configure a port profile for the port. You also can enable or disable the keepalive health check on individual real servers.
The following Layer 4 health check types are supported:
TCP
The ServerIron ADX attempts to engage in a normal three-way TCP handshake with the port on the real server:
Performed
UDP
The ServerIron ADX sends a UDP packet with garbage (meaningless) data to the UDP port.
If the server does not respond at all, the ServerIron ADX assumes that the port is alive and received the garbage data. Since UDP is a connectionless protocol, the ServerIron ADX and other clients do not expect replies to data sent to a UDP port. Thus, lack of a response is a good outcome.
Performed
When you bind a TCP application port on a real server to a TCP application port on a virtual server
At regular intervals, if keepalive is enabled for the port and the port does not have a Layer 7 health check
The ServerIron ADX attempts to engage in a normal three-way TCP handshake with the port on the real server:
If the ServerIron ADX receives the SYN ACK, the ServerIron ADX sends a TCP RESET, satisfied that the TCP port is alive.
When you bind a UDP application port on a real server to a UDP application port on a virtual server
At regular intervals, if keepalive is enabled for the port and the port does not have a Layer 7 health check
The ServerIron ADX sends a UDP packet with garbage (meaningless) data to the UDP port.
If the server responds with an ICMP “Port Unreachable” message, the ServerIron ADX concludes that the port is not alive.
If the server does not respond at all, the ServerIron ADX assumes that the port is alive and received the garbage data. Since UDP is a connectionless protocol, the ServerIron ADX and other clients do not expect replies to data sent to a UDP port. Thus, lack of a response is a good outcome.
Layer 7 Health Checks
For certain TCP and UDP application ports, the ServerIron ADX can send application-specific health checks to determine the health of the application. For example, the ServerIron ADX can send user-configurable HTTP requests to real servers to assess the health of the servers.
When you bind a real server to a virtual server using an application port that is known to the ServerIron ADX, the ServerIron ADX sends a Layer 7 health check to the application on the real server to bring up the application port.
By default, if a client requests a TCP/UDP port that is not available, the ServerIron ADX does not send an ICMP “Destination Unreachable” message to the client. For HTTP traffic, you can configure the ServerIron ADX to send such a message to the client by enabling the ICMP Message feature for HTTP. See “Sending ICMP Port Unreachable or Destination Unreachable Messages” for details.
You can enable a Layer 7 health check globally by configuring a port profile or locally by enabling the health check on an individual real server. In addition, you can customize some types of Layer 7 health checks for individual real servers. For example, you can specify a URL that the ServerIron ADX should request on a specific real server when sending the Layer 7 HTTP health check to that server.
The following Layer 7 health check types are supported:
DNS
The ServerIron ADX performs one or both of the following types of DNS health checks:
Address-based – The ServerIron ADX sends an address request for a specific domain name. If the server successfully responds with the IP address for the domain name, the server passes the health check.
Zone-based – The ServerIron ADX sends a Source-of-Authority (SOA) request for a specific zone name. If the server is authoritative for the zone and successfully responds to the SOA request, the server passes the health check.
NOTE: If you configure both types of DNS health check for a server, the server must successfully respond to both health checks to remain in the server rotation. You enable each type of DNS health check on a global basis and configure them on an individual server basis.
If the server does not reply with the requested IP address or zone name, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the requested information, the ServerIron ADX marks the DNS port on the server FAILED and removes the server from the rotation for DNS services.
NOTE: By default, the health check is non-recursive. If the real server (DNS server) does not successfully reply to the health check, then the DNS port fails the health check. You can enable the real server to perform a recursive lookup for the IP address or zone requested by the health check. In this case, if the real server does not have the requested address or zone, the server can pass the request on to a DNS server with higher authority. See “Enabling Recursive DNS Health Checks”.
Performed
Configuration
To perform a health check on a DNS port, use a configuration such as the following:
EXAMPLE  
ServerIron(config-port-dns)# show run | b 53
server port 53
udp keepalive 15 3
tcp keepalive disable
 
server real rs1 2.2.2.200
port dns
port dns keepalive
port dns addr_query "www.brocade.com"
 
server virtual-name-or-ip test 2.2.2.222
sticky-age 60
 
port dns
port dns stateless no-hash
 
bind dns linux dns rs1 dns
!
end
FTP
The ServerIron ADX waits for a message from the server.
If the server does not send a greeting message with status code 220, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for FTP service.
Performed
HTTP (Status Code)
The ServerIron ADX sends HTTP GET or HEAD requests to cache servers (when using TCS) or HTTP servers (when using SLB).
The GET or HEAD request specifies a page (identified by the URL, “Universal Resource Locator”) on the server. By default, the ServerIron ADX sends a HEAD request for the default page, “1.0”.
If the server responds with an acceptable status code, the ServerIron ADX resets the connection and marks the port ACTIVE. For SLB, the default acceptable status codes for the check are 200 – 299 and 401. For TCS, the default acceptable status codes are 100 – 499.
If the server does not respond, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for HTTP service.
NOTE: You can change the status code range for individual servers. If you do so, the defaults are removed and only the status code ranges you specify cause the server to pass the health check.
Performed
HTTP (Content Verification)
The ServerIron ADX sends HTTP GET or HEAD requests to cache servers (when using TCS) or HTTP servers (when using SLB).
The GET or HEAD request specifies a page (identified by the URL) on the server. The ServerIron ADX examines the page and compares the contents of the page to a list of user-defined selection criteria.
Based on the results of this comparison, the ServerIron ADX takes one of the following actions with respect to port 80 (HTTP) on the real server.
See “Configuring HTTP Content Matching Lists” for information on specifying a page to check and setting up lists of selection criteria
Performed
Scripted (Content Verification for Unknown Ports)
After a successful Layer 4 health check, the ServerIron ADX waits for the real server to send back a packet in response.
The ServerIron ADX looks in the response packet for a user-specified ASCII string, defined in a matching list. The ServerIron ADX compares the contents of the string to a list of user-defined selection criteria in the matching list.
Based on the results of this comparison, the ServerIron ADX takes one of the following actions with respect to the port on the real server.
If no response is received within the configured interval (the default is five seconds), the ServerIron ADX sends a RST and retries the health check. After the configured number of retries (the default is two retries), if the server still does not respond, the ServerIron ADX marks the server port FAILED.
See “Configuring Scripted Health Checks” for more information.
Performed
IMAP4
The ServerIron ADX waits for a message from the IMAP4 server.
If the server sends a greeting message that starts with “* OK”, The ServerIron ADX sends a Logout command to the IMAP4 port on the real server, then resets the connection and marks the port ACTIVE.
If the server does not send a greeting message that starts with “* OK”, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for IMAP4 service.
Performed
LDAP
The ServerIron ADX sends a bind request to the LDAP server and waits for a reply. The bind request includes a configurable version number. The version number can be 2 or 3. The default is 3.
If the server does not send a bind reply by the time the LDAP keepalive retries expires, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for LDAP service.
Performed
MMS
The ServerIron ADX sends an intentionally invalid request to the server.
If the server does not reply with a packet containing the value "MMS", the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for MMS service.
NOTE: You can view the ServerIron ADX’s invalid request in the MMS server log. The log entry has error code 400.
Performed
NNTP
The ServerIron ADX waits for a message from the NNTP server.
If the server sends a greeting message with status code 200 or 201, the ServerIron ADX sends a Quit command to the NNTP port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE.
If the server does not send a greeting message with status code 200 or 201, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for NNTP service.
Performed
PNM
The ServerIron ADX sends a PNM file request that does not have a file name.
If the server does not send a reply containing the value "PNA", the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for PNM service.
Performed
POP3
The ServerIron ADX waits for a message from the POP3 server.
If the server sends a greeting message that starts with “+ OK”, the ServerIron ADX sends a Quit command to the POP3 port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE
If the server does not send a greeting message that starts with “+ OK”, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for POP3 service.
Performed
RADIUS
The ServerIron sends an authentication request with a user name, password, and key to the RADIUS server. The account information does not need to be valid for the server to pass the health check. In fact, to prevent someone from learning account information by observing the ServerIron’s RADIUS health check, Brocade recommends you use invalid information.
If the server replies with the result code “ACCEPT” or “REJECT, the ServerIron considers the port to be ok and marks it ACTIVE.
If the server does not reply or the server Sends an ICMP “Destination Unreachable” message, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not reply with “ACCEPT” or ”REJECT”, the ServerIron marks the RADIUS port FAILED and removes the server from the rotation for RADIUS services.
NOTE: You can configure a check either for the well-known RADIUS port number 1812 or 1645. You cannot configure a health check for both of these ports on the same server.
Performed
RTSP
The ServerIron ADX sends a standard RTSP option packet, using sequence number 1.
If the server responds with an acceptable status code, the ServerIron ADX resets the connection and marks the port ACTIVE. For SLB, the default acceptable status codes for the check are 200 – 299 and 401.
If the server does not respond, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for RTSP service.
Performed
SMTP
The ServerIron ADX waits for a message from the SMTP server.
If the server sends a greeting message with status code 220, the ServerIron ADX sends a Quit command to the SMTP port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE.
If the server does not send a greeting message with status code 220, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for SMTP service.
Performed
SSL (Complete)
The ServerIron ADX initiates an SSL connection with the server on TCP port 443, a secure link is negotiated, and encrypted data is transferred across it.
After the SSL connection is established, the ServerIron ADX sends the SSL server an HTTP GET or HEAD request. The GET or HEAD request specifies a page containing the URL of a page on the server. By default, the ServerIron ADX sends a HEAD request for the default page, “1.0”, although this can be changed with the port ssl url command.
If the server does not respond, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for SSL service.
Performed
SSL (Simple)
The ServerIron ADX sends an SSL client hello with the SSL SID set to 0:
If the server does not respond, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for SSL service.
Performed
Telnet
The ServerIron ADX waits for a message from the Telnet server.
If the server does not send a command that starts with the IAC escape character, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected escape character, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for Telnet service.
Performed
Distributed Health Checks
ServerIron ADX supports distributed health checks for the GSLB ServerIron ADX. This feature distributes the health checking tasks to the site ServerIron ADXs. For details about this features, see “Distributed Health Checks for GSLB”.
Health Checking for Real Servers in Other Subnets
The ServerIron ADX must be able to receive the real server’s response to a health check in order to assess the success of the health check. In topologies where reply traffic from a real server is guaranteed to pass through the ServerIron ADX, the ServerIron ADX is able to receive replies to the health checks.
However, if the topology is such that the ServerIron ADX and real servers are in different subnets or the server reply is not guaranteed to pass back though the ServerIron ADX, you might need to use source NAT and configure a source IP address. Source NAT and source IP addresses allow the ServerIron ADX to have multiple subnet identities. Generally, the ServerIron ADX is a member of only one subnet, the subnet that contains the ServerIron ADX’s management IP address. You can place the ServerIron ADX into up to eight additional subnets by enabling source NAT and adding source IP addresses to the ServerIron ADX.
Normally, the ServerIron ADX uses its management IP address as the source address for health check packets. When you enable source NAT and add a source IP address, the ServerIron ADX uses the source IP address as the source for the health check packets. Thus, when the real server replies, the reply is addressed to the source IP address instead of the ServerIron ADX’s management IP address.
For an example of how to configure source NAT and source IP addresses, see “Web Hosting with ServerIron ADX and Real Servers in Different Subnets”.
FastCache
In typical TCS configurations, the ServerIron ADX uses cache responses that flow back through the ServerIron ADX as a means to determine the health of the cache server.
When the ServerIron ADX receives cache responses to client requests sent to the cache by the ServerIron ADX, the ServerIron ADX knows that the cache server is healthy. However, if the cache server does not respond to client requests, the ServerIron ADX does not receive the responses from the cache server. Therefore, the ServerIron ADX determines that the cache server is down and stops sending client requests to the cache server.
Some configurations might require responses from a cache server to select a path that does not return through the ServerIron ADX. For example, if a cache server supports only one default path and that path is to a gateway router, not to the ServerIron ADX, the cache server might send responses to the clients through the default gateway instead of through the ServerIron ADX. In this case, the ServerIron ADX assumes that the cache server has stopped responding even though the cache server is still working normally.
You can override health checking on an individual server basis by enabling FastCache. This feature allows the ServerIron ADX to continue using a cache server even if the server does not send responses to client requests back through the ServerIron ADX. When you enable FastCache on a cache server, the ServerIron ADX continues to send client requests to the cache server even if the server does not respond through the ServerIron ADX.

Health Checks > Health Checks Overview

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