Session Persistence
| When a client uses a load-balanced application, real servers sometimes store information about the client in memory for use throughout the session. For your applications that require your clients to remain connected for the duration of their session to the real server that contains the client's information, you can use one of the following content switching methods:
Hash Load BalancingAs you learned previously, content switches can perform a hash on source IP addresses, destination IP addresses, domain names, and URLs to distribute client requests across real servers. You should use hashing load balancing in the caching environments as discussed in Chapter 13. However, source IP hashing also provides a simple stateless way to stick a client to the same real server in SLB environments. To configure source IP hashing on your CSS, use the following content rule configuration command: balance srcip To enable source IP address hashing on the CSM, use the following command: predictor ip-hash netmask source You must specify the portion of the source address to hash with the address mask parameter. IP Address StickinessIP address stickiness differs from hashing load balancing sticky because the content switch creates entries in a sticky table, whereas hashing is stateless. Additionally, with IP address stickiness, you configure the load-balancing method separately from the sticky method. Therefore, IP stickiness can determine when a server goes down or comes back online, whereas hashing cannot. To configure source IP sticky on the CSS, use the following command in content rule configuration mode: advanced-balance sticky-srcip To configure source IP and destination port stickiness on the CSS, use the following content rule configuration command: advanced-balance sticky-srcip-dstport sticky-mask netmask sticky-inactive-timeout value Use the sticky mask to modify the maximum amount of clients from a subnet that will stick to a single server. The inactive timeout value specifies how long the CSS waits with no activity to a sticky entry before invalidating it. To configure source IP sticky on the CSM, use the following command: sticky sticky-group-id netmask netmask address source timeout sticky-time You must associate this command to a policy and virtual server on the CSM in the same manner as Example 10-17 illustrates. The CSM does not support source IP in conjunction with destination port stickiness. Both the CSS and CSM store entries for Layer 3 and 4 stickiness in a sticky table within RAM. When the content switch establishes a TCP connection between the client and server, it creates an entry in the table for subsequent application requests. When the client sends subsequent application requests over a separate TCP connection, the content switch performs a sticky table lookup to select the same real server for the client. To view the contents of the sticky table on the CSS, use the following exec command: show sticky-table [all-sticky | l3-sticky | l4-sticky | sip-callid-sticky | ssl-sticky | wap-sticky] To view the contents of the CSM sticky table, use the following exec command: show module csm mod-num sticky You learned previously that some ISPs use mega-proxies to NAT several clients to the same source IP address, causing a large number of clients to stick to the same real server in the server farm. If you are concerned with the number of clients that originate from behind a mega-proxy, you should consider using HTTP Cookie, URL strings, SIP caller ID, or WAP MSISDN number sticky instead. Some ISP proxies may also allow a single client to use multiple IP addresses throughout the duration of the client's session. For example, a client's Internet connection may temporarily disconnect, and then reconnect with a new IP address. Sticking on source IP address with a mask of 255.255.255.255 causes the content switch to send a client using multiple IPs to different real servers. If you are concerned with clients that may use multiple IP addresses, you should use a larger address mask, such as 255.255.255.0, to stick a larger amount of client IP addresses to a single real server. HTTP CookiesRecall from Chapter 8 that HTTP is not inherently stateful; however, servers may maintain state locally on behalf of clients visiting their site through the use of HTTP cookies. The server may then process any subsequent HTTP request using the stored client information, as a means to maintain the state of the HTTP "session." A typical example is an online shopping site that uses logical shopping carts to store items chosen by clients during their sessions. Although most browsers support HTTP 1.1 connection persistence and pipelining, the majority of browsers open multiple TCP connections throughout the duration of a single user session to a website. In Chapter 1, "Introducing Content Networking," you learned the reason for opening multiple TCP connections to a site, to increase the effective bandwidth due to limitations of TCP over links with very high latency. Additionally, content switches can use HTTP rebalancing to distribute HTTP requests within the same TCP connection to different servers. In both cases, the content switch sends the client unknowingly to a real server that is unaware of the client's state information that is stored on the originally selected real server. To maintain client state, the content switch must send all requests during the client's session to the same real server, because this is where the client's information residesFigure 10-24 illustrates this point. Figure 10-24. Forwarding Client Requests to Multiple Reals While Maintaining Session State on Single Real Server You can accomplish session stickiness using HTTP cookies. You learned in Chapter 8 that two types of HTTP cookies are available. Real servers store persistent cookies in a text file on the hard disk of the client's computer, primarily to provide personalization and customization for the user on subsequent visits to the site. Real servers and clients store session cookies locally in RAM, and they exist only temporarily for the life of the session. The browser removes the cookie from RAM when the user closes the browser window(s) for the session, and the real server removes the cookie from RAM after a configurable timeout on your web server. Content switches use session cookies to provide session stickiness for clients and can be set on the real server or, if the real server is not capable of setting cookies, the content switch can set the cookie on the real server's behalf. The session cookie is set by the server with the HTTP "Set-Cookie:" header. The value of the cookie can be set to any attribute/value pair, such as "SESSION_ID=012321." For subsequent HTTP requests, either within the same TCP connection or across connections, the client uses the cookie as a handle for all communication during the session. You must configure your content switch to inspect cookies with a value starting with "SESSION_ID=," in this example, and store a mapping of the associated value to the real server originally chosen for the session. This way, the content switch does not load balance subsequent requests to new real serversthe cookie overrides the normal load-balance decision. Figure 10-25 illustrates how the CSM sticks a client to the same server. Figure 10-25. Session Persistence on the CSM In Figure 10-25, the CSM selects the real server using the configured load balancing method, and forwards the GET request to that real. When the CSM receives the "Set-Cookie:" header from the real server, the CSM stores the association between the cookie value and real server in the sticky table. On subsequent requests from the client, the CSM performs a table lookup with the cookie that the client supplies to determine which real the client is stuck to. To configure your CSM to inspect HTTP cookies, you can use the configuration in Example 10-18. You must give the sticky configuration for "SESSION_ID" a unique identifier (for example, 1 in this case) and apply the sticky configuration to a policy using the stick-group command. You then apply the policy to the virtual server using the policy command. Example 10-18. Configuring Sticky Cookies on the CSM
To stick to only a portion of a cookie, as opposed to the entire cookie, use the following command: cookie offset 5 length 8 This command benefits applications, such as Java 2.0 Enterprise Edition (J2EE), which store the real session ID only in certain bytes of the cookie value. If your origin servers do not support cookies, you can configure your CSM to insert a cookie in the server's response to the client, using the following command: sticky 5 cookie mycookie insert If you configure HTTP cookie stickiness on the CSS, it does not store entries in the sticky table. Instead, you can manually assign cookie string values to the services on the CSS. When a real server generates a cookie, the client uses that cookie in subsequent requests. The CSS inspects the cookie value and directs the request to the service configured with that value. With this configuration, the real server must generate the same cookie value for all clients, in order to identify itself to the CSS. By default, the CSS uses manual service sticky strings. If you disable this feature and need to reenable it, you can use the following command: string operation match-service-cookie Because this is the default behavior for sticky cookies on the CSS, this command does not show in the configuration given in Example 10-19. Example 10-19. Configuring Sticky Cookies on the CSS
You can also configure the CSS to hash cookie values to stick to the same real server throughout the client's session. With cookie hashing, the CSS selects an original real server using the configured load-balancing method. The original real server generates a cookie, and the CSS responds to the client's request with the cookie, as normal. However, when the CSS receives subsequent requests from the client with the cookie, the CSS hashes the cookie to determine the sticky real server. Hashing the cookie assigns the client to the same real server for each request, but the sticky real server may be different from the original real server that generated the cookie. This should not be a problem, because the original real does not store any information about the client that is needed throughout the sessionits sole task is to generate the cookie. With this configuration, the real servers can generate unique cookies for each requesting client, because you do not manually assign reals to predefined cookie values. To configure cookie hashing, use the following CSS content rule configuration command: string operation [hash-a | hash-crc32 | hash-xor] As mentioned previously, you can also configure your content switch to insert cookies into real server responses, which is transparent to both client and server, by using the following command: advanced-balance arrowpoint-cookie Note You should use CSS cookies in a redundant CSS configuration. Because the sticky table is not used, failing over to the backup CSS does not cause the CSS to lose sticky information, whereas, with sticky mechanisms on the CSS that use the sticky table, sticky information is lost during the failover. For more information on CSS redundancy, see the section "Content Switch High Availability" at the end of this Chapter. URL Sticky StringsInstead of setting a sticky string within a "Set-Cookie:" HTTP header of an HTTP 200 OK method, you can configure your real servers to send an HTTP 302 Object Moved method containing a sticky string within the URL of the "Location:" header. You must direct your content switch to inspect URLs from clients for the sticky cookie. For example, you can configure your real server to return the following URL in an HTTP 302 Object Moved method for client logins: HTTP/1.1 302 Object Moved Location: login.asp?session-id=201421 Clients use the value in the "Location:" header to request the login page. Your real servers must also embed the sticky string into the hyperlinks within all further HTML pages to which the client will have access during their session. To direct the CSS to inspect the client URLs to find the sticky string within your URL strings (after the "?" in the URL field), use the following content rule configuration command: advanced-balance cookieurl To configure your CSM to check the URL for the sticky string, use the sticky configuration command: cookie secondary session-id Note The CSM combines URL strings with cookies in that it can search a cookie value in the URL after having learned it dynamically from a "Set-cookie:" message, to account for clients that reject the cookie sent by the server. SSL StickyRecall from Chapter 8 that SSL version 3 provides a stateful session identifier in the SSL Handshake Protocol. SSL clients reference this session ID throughout the SSL communication between the client and server, even across TCP connections. Content switches create a mapping between the SSL session ID and real server, in the same way as with HTTP Cookies, and they store the mapping in their sticky tables. For every SSL packet, in any TCP session that is created within the main SSL session, the content switch uses the session ID as key into the sticky session lookup table. The content switch uses the resultant real server to which it forwards the clients' subsequent requests. The command advanced-balance ssl enables the CSS to use the SSL session ID to stick to clients. Additionally, the application ssl command tells the CSS to not inspect the Layer 57 application. Once the CSS establishes the SSL flow, it cannot decipher the encrypted data, so there is no need for the content switch to inspect Layer 57 content. Example 10-20 shows you how to configure SSL sticky on the CSS. Example 10-20. Configuring SSL Sticky on the CSS
Example 10-21 gives a sample SSL sticky configuration for the CSM. Example 10-21. Configuring SSL Sticky on the CSM
Note Both the CSM and CSS store SSL sticky entries in their sticky tables. SIP Caller ID and MSISDN Number StickyYou can also configure your CSS to perform sticky based on Session Information Protocol (SIP) caller identification using the advanced-balance sip-call-id content rule command. Additionally, WAP gateways often add an HTTP extension header for the Mobile Station International ISDN Number (MSISDN). The extension header is "X-MSISDN:" and contains the unique identifier for the WAP client. You can configure your CSS to stick to clients based on the value in the "X-MSISDN:" header using the advanced-balance wap-msisdn content rule command. Note The CSS uses its sticky table for both SIP and MSISDN sticky entries. The CSM does not support SIP caller ID or MSISDN number sticky. Permanent Session Information StorageWith the stateful sticky methods you have learned so far (that is, HTTP cookies, URL sticky strings, SIP caller-id, and MSISDN numbers), if the sticky server that creates the cookie fails, the cookie is permanently removed from memory. Creating a permanent store of session information, such as an SQL database, is an alternative to stateful memory-based session information storage. If the original real server that a client connects to fails, the content switch can load balance subsequent requests to any available real server. Because the session information is available through a separate back-end channel, the newly selected real servers can perform a lookup to the load the client's session information, based on the cookie or sticky string embedded within the client's request. A disadvantage of this method is the overhead of performing lookups across the network for every user request. |
EAN: 2147483647
Pages: 178