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

Table of Contents Previous Next Print


Health Checks > Server and Application Port States

Server and Application Port States
Server States
The server states only concern up to Layer 3. They do not deal with Layers 4 or 7. In Table 4.3, Layer 2 reachability refers to ARPs, a Layer 2 query for Layer 3 information. Layer 3 reachability refers to ICMP echo requests and replies, or pings.
NOTE: Layer 4 refers to making a TCP connection to a port. Layer 7 refers to making an HTTP request and getting an HTTP reply.
 
Table 4.3: Server States  
The real server has failed to respond to repeated Layer 3 health checks (IP pings). Typically, a real server changes to the FAILED state from the SUSPECT state.
A real server will go to "Testing" if it is reachable at Layer 2 but not at Layer 3. When you first add a real server, the ServerIron ADXXL will first try to ARP it. While it is ARPing, the server state will read "State: Enabled". After the real server replies to the ARP, the ServerIron ADXXL will normally send one ICMP echo request. After it gets the ARP reply and before it gets the ICMP echo reply, the ServerIron ADXXL will show the real server state as Testing. If you have a firewall application on the real server so that it responds to ARP queries but not to ICMP pings, then the real server will show as "Testing" forever.
Use the show server real command to display detailed state information. The show server bind command is more concise, though it focuses on port status.
The ServerIron ADX associates a time stamp with each packet sent to and received from the real servers. If the time gap between the last packet received from the server and the last packet sent to the server grows to 3 or 4 seconds, the ServerIron ADX sends a ping (Layer 3 health check) to the server. If the server doesn’t respond within the ping interval (a configurable parameter), the ServerIron ADX changes the state to SUSPECT and resends the ping, up to the number of retries specified by the ping retries parameter (also configurable). If the server still doesn’t respond after all the retries, the state changes to FAILED. If the server does respond, the state changes to ACTIVE.
A real server will go to active as long as it is reachable at Layer 2 and 3, regardless of whether or not its ports are bound to anything, regardless of whether or not its ports pass tests.
After receiving that first ping reply, normally the ServerIron ADXXL switches to periodic ARPs. If you enable server l3-health-check globally, then the ServerIron ADXXL switches to using periodic pings instead. The real server still shows the state active. If you enter the no server l3-health-check command globally, then the ServerIron ADXXL will switch back to ARP. After that first ping succeeds, if you do not have L3 health checks enabled, you can add an ICMP blocking ACL on the real server, and the system will still display "Active". If you re-add server l3-health-check, then the real server state will change from Active to Suspect and then Failed. This behavior is all done before any ports have been bound to a virtual server. All these states on a real server have nothing to do with L4/L7.
AWU:await-unbind
AWD: await-shutdown
Both can occur when you're trying to unbind or delete ports. You might not even see them in anything but a live environment. After you remove real servers from a virtual server or delete virtual servers or unbind ports, normally the ServerIron ADX or stackable waits until connections in progress finish their business.
 
Application Port States
Table 4.4 lists the application port states.
 
There is no link to the server. The server is configured on the ServerIron ADX but is not connected to the ServerIron ADX. (This is the same as the ENABLED server state.)
The application has failed to respond to repeated Layer 4 or (if applicable) Layer 7 health checks. Typically, an application changes to the FAILED state from the SUSPECT state. Note that if a application does not pass the Layer 4 health check, the ServerIron ADX does not waste resources on the Layer 7 health check, since the application clearly is not available. When an application enters the FAILED state, the state of the real server itself moves to the TEST state while the ServerIron ADX continually tries to reach the failed application.
The ServerIron ADX associates a time stamp with each packet sent to and received from the real servers. If the time gap between the last packet received from the server and the last packet sent to the server grows to 3 or 4 seconds, the ServerIron ADX sends a Layer 4 health check to the service. (If applicable, and if the server passes the Layer 4 health check, the ServerIron ADX then sends a Layer 7 health check to the application.) If the application doesn’t respond within a specified interval, the ServerIron ADX changes the state to SUSPECT and resends the Layer 4 (and if applicable, Layer 7) health check up to a specific number of retries. If the application still doesn’t respond after all the retries, the state changes to FAILED and the server state changes to TEST. If the application does respond, the application state changes to ACTIVE.
This following sections describe how to display the state information.
Displaying Real Server State Information
To display real server information, enter the following command at any level of the CLI. For complete information about these displays, see “Displaying Virtual Servers Configuration Statistics”.
information for remaining real servers omitted for brevity...
Syntax: show server real
The state information shown by this display is highlighted in bold type in the example above. The state of the server itself is listed first, then the states of each of the application ports configured on the server are displayed.
In this example, the server itself is enabled. The HTTP port also is enabled, but the “default” port (a port the ServerIron ADX automatically configures on all the real and virtual servers) is unbound. These states are typical of a ServerIron ADX that is configured for deployment but has not been connected to the real servers.
The information under the row for the HTTP application shows settings for the Layer 7 health checks for the port. For information about HTTP health checks and other configurable Layer 7 health check parameters, see “Layer 7 Health Checks”.
Displaying Virtual Server State Information
To display virtual server information, enter the following command at any level of the CLI. For complete information about these displays, see “Displaying Virtual Servers Configuration Statistics”.
In this example, the virtual server and the application ports configured on the server are enabled, indicating that the server and the application ports are configured on the ServerIron ADX but the ServerIron ADX is not connected to the real servers bound to this virtual server. See “Displaying Real Server State Information” for descriptions of the server and application states.
NOTE: The number following “state” in the “Sym” row indicates the Symmetric SLB state of this VIP. See “Displaying Virtual Servers Configuration Statistics”.

Health Checks > Server and Application Port States

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