This chapter describes server load balancing (SLB) as implemented in the Cisco 4700 Series Application Control Engine (ACE) appliance. It contains the following major sections:
•Server Load-Balancing Overview
•Real Servers and Server Farms
•Configuring Traffic Classifications and Policies
•Operating the ACE Strictly as a Load Balancer
•Where to Go Next
Server Load-Balancing Overview
Server load balancing (SLB) is the process of deciding to which server a load-balancing device should send a client request for service. For example, a client request may consist of an HTTP GET for a web page or an 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.
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.
The ACE uses the following predictors to select the best server to fulfill a client request:
•Round-robin—Selects the next server in the list of real servers based on server weight (weighted round-robin). Servers with a higher weight value receive a higher percentage of the connections. This is the default predictor.
•Least connections—Selects the server with the fewest number of active connections based on server weight. For the least connection 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.
•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 Chapter 6, Configuring Firewall Load Balancing.
•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. Cache servers perform better with the URL hash method because you can divide the contents of the caches evenly if the traffic is random enough. In a redundant configuration, the cache servers continue to work even if the active ACE switches over to the standby ACE. For information about configuring redundancy, see the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
Note The hash predictor methods do not recognize the weight value you configure for real servers. The ACE uses the weight that you assign to real servers only in the round-robin and least-connections predictor methods.
For more information about load-balancing predictors, see Chapter 2, Configuring Real Servers and Server Farms.
Real Servers and Server Farms
This section briefly describes real servers and server farms and how they are implemented on the ACE. It contains the following topics:
To provide services to clients, you configure real servers (the actual physical servers) on the ACE. Real servers provide client services such as HTTP or XML content, hosting web sites, FTP file uploads or downloads, redirection for web pages that have moved to another location, and so on. The ACE also allows you to configure backup servers in case a server is taken out of service for any reason.
After you create and name a real server on the ACE, you can configure several parameters, including connection limits, health probes, and weight. You can assign a weight to each real server based on its relative importance to other servers in the server farm. The ACE uses the server weight value for the weighted round-robin and the least-connections load-balancing predictors. For a listing and brief description of the ACE predictors, see the "Load-Balancing Predictors" section. For more detailed information about the ACE load-balancing predictors and server farms, see Chapter 2, Configuring Real Servers and Server Farms.
Typically, in data centers, servers are organized into related groups called server farms. Servers within server farms often contain identical content (referred to as mirrored content) so that if one server becomes inoperative, another server can take its place immediately. Also, mirrored content allows several servers to share the load of increased demand during important local or international events, for example, the Olympic Games. This sudden large demand for content is called a flash crowd.
After you create and name a server farm, you can add existing real servers to it and configure other server-farm parameters, such as the load-balancing predictor, server weight, backup server, health probe, and so on. For a description of the ACE predictors, see the "Load-Balancing Predictors" section. For more detailed information about the ACE load-balancing predictors and server farms, see Chapter 2, Configuring Real Servers and Server Farms.
You can instruct the ACE to check the health of servers and server farms by configuring health probes (sometimes referred to as keepalives). After you create a probe, you assign it to a real server or a server farm. A probe can be one of many types, including TCP, ICMP, Telnet, HTTP, and so on. You can also configure scripted probes using the TCL scripting language.
The ACE sends out probes periodically to determine the status of a server, verifies the server response, and checks for other network problems that may prevent a client from reaching a server. Based on the server response, the ACE can place the server in or out of service, and, based on the status of the servers in the server farm, can make reliable load-balancing decisions. For more information about out-of-band health monitoring, see Chapter 4, Configuring Health Monitoring.
Configuring Traffic Classifications and Policies
The ACE uses several configuration elements to classify (filter) interesting traffic and then to perform various actions on that traffic before making the load-balancing decision. These filtering elements and subsequent actions form the basis of a traffic policy for SLB. This section contains the following topics:
•Filtering Traffic with ACLs
•Classifying Layer 3 and Layer 4 Traffic
•Classifying Layer 7 Traffic
•Configuring an HTTP Parameter Map
•Creating Traffic Policies
•Applying Traffic Policies to an Interface Using a Service Policy
Filtering Traffic with ACLs
To permit or deny traffic to or from a specific IP address or an entire network, you can configure an access control list (ACL). ACLs provide a measure of security for the ACE and the data center by allowing access only to traffic that you explicitly authorize on a specific interface or on all interfaces. An ACL consists of a series of permit or deny entries with special criteria for the source address, destination address, protocol, port, and so on. All ACLs contain an implicit deny statement, so you must include an explicit permit entry to allow traffic to and through the ACE. For more information about ACLs, see the Cisco 4700 Series Application Control Engine Appliance Security Configuration Guide.
Classifying Layer 3 and Layer 4 Traffic
To classify Layer 3 and Layer 4 network traffic, you configure class maps and specify match criteria according to your application requirements. When a traffic flow matches certain match criteria, the ACE applies the actions specified in the policy map with which the class map is associated. A policy map acts on traffic ingressing the interface to which the policy map is applied through a service policy (globally to all VLAN interfaces in a context or to a single VLAN interface).
Class maps that operate at Layer 3 and Layer 4 for SLB typically use virtual IP (VIP) addresses as matching criteria. For details about Layer 3 and Layer 4 class maps for SLB, see Chapter 3, Configuring Traffic Policies for Server Load Balancing.
Classifying Layer 7 Traffic
In addition to Layer 3 and Layer 4 class maps, you can also configure Layer 7 class maps for advanced load-balancing matching criteria, such as HTTP cookie, header, and URL settings. After you configure a Layer 7 class map, you associate it with a Layer 7 policy map. You cannot apply a Layer 7 policy map to an interface directly (see the "Creating Traffic Policies" section). For details about Layer 7 class maps for SLB, see Chapter 3, Configuring Traffic Policies for Server Load Balancing.
Configuring an HTTP Parameter Map
An HTTP parameter map combines related HTTP actions for use in a Layer 3 and Layer 4 policy map. Parameter maps provide a means of performing actions on traffic that ingresses an ACE interface based on certain criteria, such as HTTP header and cookie settings, server connection reuse, the action to take when an HTTP header, cookie or URL exceeds a configured maximum length, and so on. After you configure an HTTP parameter map, you associate it with a Layer 3 and Layer 4 policy map. For details about configuring an HTTP parameter map, see Chapter 3, Configuring Traffic Policies for Server Load Balancing.
Creating Traffic Policies
The ACE uses policy maps to combine class maps and parameter maps into traffic policies and to perform certain configured actions on the traffic that matches the specified criteria in the policies. Policy maps operate at Layer 3 and Layer 4, as well as Layer 7. Because the ACE considers a Layer 7 policy map a child policy, you must associate each Layer 7 policy map with a Layer 3 and Layer 4 policy map before you can apply the traffic policy to an interface using a service policy. For more information about configuring SLB traffic policies, see Chapter 3, Configuring Traffic Policies for Server Load Balancing.
Applying Traffic Policies to an Interface Using a Service Policy
To apply a traffic policy to one or more interfaces, you use a service policy. You can use a service policy on an individual interface or globally on all interfaces in a context in the input direction only. When you use a service policy on an interface, you apply and activate a Layer 3 and Layer 4 policy map with all its class-map, parameter-map, and Layer 7 policy-map associations and match criteria. For more information about using a service policy to apply a traffic policy to an interface, see Chapter 3, Configuring Traffic Policies for Server Load Balancing.
Operating the ACE Strictly as a Load Balancer
You can operate your ACE strictly as an SLB device. If you want to use SLB only, you must configure certain parameters and disable some of the ACE security features. By default, the ACE performs TCP/IP normalization checks and ICMP security checks on traffic that enters the ACE interfaces. Using the following configuration will also allow asymmetric routing as required by your network application.
The major configuration items are as follows:
•Configuring a global permit-all ACL and applying it to all interfaces in a context to open all ports
•Disabling TCP/IP normalization
•Disabling ICMP security checks
To operate the ACE for SLB only, perform the following steps:
Step 1 Configure a global permit-all ACL and apply it to all interfaces in a context. This action will open all ports in the current context.
host1/Admin(config)# access-list ACL1 extended permit ip any any
host1/Admin(config)# access-group input ACL1
Step 2 Disable the default TCP/IP normalization checks on each interface where you want to configure a VIP using a load-balancing service policy. For details about TCP normalization, see the Cisco 4700 Series Application Control Engine Appliance Security Configuration Guide.
host1/Admin(config)# interface vlan 100
host1/Admin(config-if)# no normalization
Disabling TCP normalization may expose your ACE and your data center to potential security risks. TCP normalization helps protect the ACE and the data center from attackers by enforcing strict security policies that are designed to examine traffic for malformed or malicious segments.
Step 3 Disable the default ICMP security checks on each interface where you want to configure a VIP using a load-balancing service policy. For details about the ICMP security checks, see the Cisco 4700 Series Application Control Engine Appliance Security Configuration Guide.
host1/Admin(config-if)# no icmp-guard
Disabling the ACE ICMP security checks may expose your ACE and your data center to potential security risks. In addition, after you enter the
no icmp-guard command, the ACE no longer performs NAT translations on the ICMP header and payload in error packets, which potentially can reveal real host IP addresses to attackers.
Step 4 Configure SLB. For details, see the remaining chapters in this guide.
Where to Go Next
To start configuring SLB on your ACE, proceed to Chapter 2, Configuring Real Servers and Server Farms.