Overview of ACE Layer 7 Load Balancing

Layer 7 server load balancing (SLB) is the process that the load-balancing device uses to decide which server should fulfill a client request for an L7 service. For example, a client request may consist of a HyperText Transport Protocol (HTTP) GET for a web page or a File Transfer Protocol (FTP) GET to download a file. The job of the load balancer is to select the server that can successfully fulfill the client request and do so in the shortest amount of time without overloading either the server or the server farm as a whole.

The ACE supports the load balancing of the following protocols:

Generic protocols

HTTP

Remote Authentication Dial-In User Service (RADIUS)

Reliable Datagram Protocol (RDP)

Real-Time Streaming Protocol (RTSP)

Session Initiation Protocol (SIP)

Depending on the load-balancing algorithm—or predictor—that you configure, the ACE performs a series of checks and calculations to determine which server can best service each client request. The ACE bases server selection on several factors including the source or destination address, cookies, URLs, HTTP headers, or the server with the fewest connections with respect to load.

Load-Balancing Predictors

The ACE uses the following predictors to select the best server to fulfill a client request:

Application response—Selects the server with the lowest average response time for the specified response-time measurement based on the current connection count and server weight (if configured).

Hash address—Selects the server using a hash value based on either the source or destination IP address or both. Use these predictors for firewall load balancing (FWLB). For more information about FWLB, see Configuring Firewall Load Balancing in the Cisco Application Control Engine Module Server Load-Balancing Configuration Guide (Software Version A2(1.0)).

Hash content—Selects the server using a hash value based on a content string in the Trusted Third Parties (TTP) packet body.

Hash cookie—Selects the server using a hash value based on a cookie name.

Hash header—Selects the server using a hash value based on the HTTP header name.

Hash URL—Selects the server using a hash value based on the requested URL. You can specify a beginning pattern and an ending pattern to match in the URL. Use this predictor method to load balance cache servers.

Least bandwidth—Selects the server that processed the least amount of network traffic based on the average bandwidth that the server used over a specified number of samples.

Least connections—Selects the server with the fewest number of active connections based on the server weight. For the least-connections predictor, you can configure a slow-start mechanism to avoid sending a high rate of new connections to servers that you have just put into service.

Least loaded—Selects the server with the lowest load based on information obtained from Simple Network Management Protocol (SNMP) probes. To use this predictor, you must associate an SNMP probe with it.

Round-robin—Selects the next server in the list of real servers based on the server weight (weighted round-robin). Servers with a higher weight value receive a higher percentage of the connections. This is the default predictor.

Note:

The hash predictor methods do not recognize the weight value that you configure for real servers. The ACE uses the weight that you assign to real servers only in the least-connections, application-response, and round-robin predictor methods.

Classifying L7 Traffic for Server Load Balancing

You classify inbound network traffic destined to or passing through the ACE based on a series of flow match criteria specified by a class map. Each class map defines a traffic classification, which is network traffic that is of interest to you. A policy map defines a series of actions (functions) that you want applied to a set of classified inbound or outbound traffic.

The three major steps in the traffic classification process are as follows:

Create a class map using the class-map command and the associated match commands, which comprise a set of match criteria related to Layer 3 and Layer 4 traffic classifications or Layer 7 protocol classifications.

Create a policy map using the policy-map command, which refers to the class maps and identifies a series of actions to perform based on the traffic match criteria.

Activate the policy map by associating it with a specific VLAN interface or globally with all VLAN interfaces using the service-policy command to filter the traffic received by the ACE.

Figure 1 provides a basic overview of the process required to build and apply the Layer 3, Layer 4, and Layer 7 policies that the ACE uses for SLB. The figure also shows how to associate the various components of the SLB policy configuration with each other.

Figure 1. SLB Flow Diagram

Example of a L7 Load-Balancing Configuration

The following example shows a running configuration that includes multiple class maps and policy maps that define a traffic policy for SLB. In this configuration, when a server farm is chosen for a connection, the connection is sent to a real server based on one of several load-balancing predictors. The leastconns predictor method load balances connections to the server that has the lowest number of open connections.

5. Check the total conn-dropcount field for the primary server farm in the output of the following command. Also, check the IP address, state, and the connection statistics for each real server that is configured in the server farm.

The connection failures counter increments only if the ACE attempts to load balance a connection and the ACE does not receive a SYN-ACK from the real server in response to a SYN or if the real server responds to the SYN with a RST.

6. Check the L7 load-balance statistics by entering the following command:

The ID Map is used to map real servers and server farms between the local and the remote peers in a redundant configuration. The Total IDMap Lookup Failures field increments if the local ACE fails to find the local ACE to peer ACE ID mapping. A failure can occur if the peer ACE did not send a proper remote ID for the local ACE to look up and so the local ACE could not perform a mapping or if the ID Map table was not created.

7. If you are having problems with HTTP, check the HTTP statistics and error counters by entering the following command: