Configuring Server Persistence Using Stickiness
This chapter describes how to configure server persistence using stickiness on the Cisco 4700 Series Application Control Engine (ACE) appliance. It describes how to configure stickiness using the HTTP cookie sticky method.
This chapter contains the following sections:
•Information About Configuring Stickiness
•Configuring HTTP Cookie Stickiness
•Configuration Example for the Hash Header Predictor
•Where to Go Next
Information About Configuring Stickiness
After reading this chapter, you should have a basic understanding of how the ACE appliance provides server persistence using stickiness, and how to configure HTTP cookie stickiness.
After reading this chapter, you should have a basic understanding of how the ACE provides server persistence using stickiness, and how to configure HTTP cookie stickiness.
When customers visit an e-commerce site, they usually start by browsing the site. Depending on the application, the site may require that the client remain connected (stuck) to one server as soon as the initial connection is established, or the application may require this action only when the client starts to create a transaction, such as building a shopping cart.
For example, after the client adds items to a shopping cart, it is important that all subsequent client requests are directed to the same real server so that all the items are contained in one shopping cart on one server. An instance of a customer's shopping cart is typically local to a particular server rather than duplicated across multiple servers.
E-commerce applications are not the only types of applications that require a sequence of client requests to be directed to the same real server. Any web applications that maintain client information may require this behavior, such as banking and online trading applications, or FTP and HTTP file transfers.
You can configure the ACE so that the same client can maintain multiple, simultaneous, or subsequent TCP or IP connections with the same real server for the duration of a session. This session persistence capability of the ACE is called stickiness. A session is defined as a series of transactions between a client and a server over some finite period of time (from several minutes to several hours).
Depending on the configured server load-balancing policy, the ACE sticks a client to an appropriate server after the ACE determines which load-balancing method to use. If the ACE determines that a client is already stuck to a particular server, then the ACE sends that client request to that server, regardless of the load-balancing criteria. If the ACE determines that the client is not stuck to a particular server, it applies the normal load-balancing rules to the request.
To determine how a particular client is stuck to a specific web server and how an application distinguishes each client or a group of clients, the ACE supports the following sticky methods:
•Source and/or destination IP address—For stickiness, you can use the source IP address, the destination IP address, or both to uniquely identify individual clients and their requests based on their IP net masks. However, if an enterprise or service provider uses a mega-proxy (a free, anonymous web proxy service that can represent hundreds or thousands of different clients with a single source IP address) to establish client connections to the Internet, the source IP address is not a reliable indicator of the true source of the request. In this case, you can use another sticky method to ensure session persistence.
•Cookie—Client cookies uniquely identify clients to the ACE and to the servers that provide content. A cookie is a small data structure within the HTTP header that a server uses to deliver data to a web client, with the request that the client store the information. The cookie may be inserted into a response packet from the server or the ACE can insert the cookie. This information may include items that users have added to their shopping carts or travel dates that they have chosen. When the ACE examines a request for content and determines that the content is sticky, it examines any cookie or URL present in the content request. The ACE uses the information in the cookie or URL to direct the content request to the appropriate server.
•Hypertext Transfer Protocol (HTTP) header—You can specify a header offset to provide stickiness based on a unique portion of the HTTP header.
•Layer 4 Payload Stickiness—Layer 4 payload stickiness allows you to stick a client to a server based on the data in Layer 4 frames. You can specify a beginning pattern and ending pattern, the number of bytes to parse, and an offset that specifies how many bytes to ignore from the beginning of the data.
•HTTP Content Stickiness—HTTP content stickiness allows you to stick a client to a server based on the content of an HTTP packet. You can specify a beginning pattern and ending pattern, the number of bytes to parse, and an offset that specifies how many bytes to ignore from the beginning of the data.
•RADIUS Attribute Stickiness—The ACE supports stickiness based on RADIUS attributes. The following attributes are supported for RADIUS sticky groups:
–Framed IP and calling station ID
–Framed IP and username
•RTSP Session Header Stickiness—The ACE supports stickiness based on the RTSP session header field. With RTSP header stickiness, you can specify a header offset to provide stickiness based on a unique portion of the RTSP header.
•SIP Call-ID Header Stickiness—The ACE supports stickiness based on the SIP Call-ID header field. SIP header stickiness requires the entire SIP header, so you cannot specify an offset.
•SSL Session-ID Stickiness—This feature allows the ACE to stick the same client to the same SSL server based on the SSL Session ID. This feature supports SSLv3 only. Because the SSL Session ID is unique across multiple connections from the same client, you can use this feature to stick clients to a particular SSL server when the ACE is configured to load balance SSL traffic, but not terminate it. To use this feature, you must configure a generic protocol-parsing policy for sticky learning. The ACE learns the SSL Session ID from the SSL server or other SSL-termination device.
Because an SSL server can reuse the same SSL Session ID for new connections from a known client, the SSL handshake time is reduced. This reduction in the handshake time translates directly into lower computational requirements for the server and reduced CPU utilization, and, therefore, increased SSL transactions per second (TPS).
The e-commerce application often dictates which of these methods is appropriate for a particular e-commerce application.
The ACE uses sticky groups for stickiness attributes. These attributes include the sticky method, timeout, replication, and attributes related to a particular sticky method.
To track sticky connections, the ACE uses a sticky table with information about sticky groups, sticky methods, sticky connections, and real servers. The ACE uses a configurable timeout mechanism to age out sticky table entries. When an entry times out, it becomes eligible for reuse. High connection rates may cause the premature aging out of sticky entries. In this case, the ACE reuses the entries that are closest to expiration first.
Entries in the sticky table can be either dynamic (generated by the ACE as needed) or static (configured). When you create a static sticky entry, the ACE places the entry in the sticky table immediately, and it remains in the sticky database until you remove it from the configuration.
Figure 8-1 illustrates that in a server load-balancing environment, requests from a client are stuck to real server RS_web4 in a session.
Figure 8-1 Client Requests Stuck to a Server
For information on how to configure stickiness using the IP address and HTTP header methods, see the Server Load-Balancing Guide, Cisco ACE Application Control Engine.
Configuring HTTP Cookie Stickiness
To configure sticky, you can use either the ACE Device Manager user interface (GUI) or the CLI.
•Configuring HTTP Cookie Stickiness Using the Device Manager GUI
•Configuring HTTP Cookie Stickiness Using the CLI
Configuring HTTP Cookie Stickiness Using the Device Manager GUI
You can configure HTTP cookie stickiness using the GUI by following these steps:
Step 1 Make sure that the context in which you are configuring the sticky group is associated with a resource class that allocates resources to stickiness. See the "Creating a Resource Class" section in Chapter 3.
Step 2 Choose Load Balancing > Stickiness. The Stickiness pane appears.
Step 3 Choose the VC_web context.
Step 4 Add a new sticky group by clicking Add. The Stickiness configuration window appears.
Step 5 Enter the following attributes for the new sticky group. Leave the remaining attributes blank or with their default values.
•Group Name: StickyGroup1
•Type: HTTP Cookie
•Cookie Name: Cookie1
•Sticky Server Farm: SF_web
Step 6 Add the new sticky group to the Stickiness pane by clicking Deploy Now.
Configuring HTTP Cookie Stickiness Using the CLI
You can configure HTTP cookie stickiness using the CLI by following these steps:
Step 1 Verify that you are operating in the desired context by checking the CLI prompt. If necessary, change to the correct context.
host1/Admin# changeto VC_web
Step 2 Enter configuration mode.
Step 3 Create an HTTP-cookie-type sticky group and enter the cookie configuration mode.
host1/VC_web(config)# sticky http-cookie Cookie1 StickyGroup1
Step 4 Configure a timeout for HTTP cookie stickiness.
host1/VC_web(config-sticky-cookie)# timeout 1440
Step 5 Associate a server farm with the sticky group and exit configuration mode.
host1/VC_web(config-sticky-cookie)# serverfarm SF_web
Step 6 Display the HTTP cookie configuration.
host1/VC_web# show running-config sticky
Configuration Example for the Hash Header Predictor
The following example shows how to configure the hash header predictor. The commands that you have configured in this chapter appear in bold text.
switch/VC_web(config)# do show running config
access-list INBOUND line 8 extended permit ip any any
description content server web-one
description content server web-two
description content server web-three
description content server web-four
class-map type management match-any REMOTE_ACCESS
description Remote access traffic match
3 match protocol telnet any
4 match protocol icmp any
class-map match-all VS_WEB
2 match virtual-address 10.10.40.10 tcp eq www
policy-map type management first-match REMOTE_MGMT_ALLOW_POLICY
policy-map type loadbalance first-match PM_LB
policy-map multi-match PM_MULTI_MATCH
loadbalance vip inservice
service-policy input REMOTE_MGMT_ALLOW_POLICY
description Client connectivity on VLAN 400
ip address 10.10.40.1 255.255.255.0
access-group input INBOUND
service-policy input PM_MULTI_MATCH
description Server connectivity on VLAN 500
ip address 10.10.50.2 255.255.255.0
ip route 0.0.0.0 0.0.0.0 172.25.91.1
username USER1 password 5 $1$vAN9gQDI$MmbmjQgJPj45lxbtzXPpB1 role SLB-Admin domain DOMAIN1
Where to Go Next
In this chapter, you have configured a sticky group using the HTTP-cookie method. In the next chapter, you will configure SSL security.