FRAMINGHAM (04/20/2000) - Most e-commerce sites and many enterprise applications encounter a major challenge when they deploy multiple servers for scalability. A transaction typically consists of several TCP connections between the client browser and the servers. Once multiple servers are deployed, connections for a given transaction can go to any of the servers.
While many load balancers solve the problem of balancing load across multiple servers, not every one supports the different persistence needs. Because persistence by definition requires load balancers to ignore load conditions on servers and select a server based on persistence rules, the trick for load-balancing products is to ensure that the required level of persistence is met while retaining load balancing as much as possible.
For this reason, there are a variety of persistence methods. Three of their methods are of particular importance in building Web sites for e-commerce: virtual source, cookie and Secure Sockets Layer (SSL) session ID-based persistence.
When an enterprise or ISP uses load balancing across multiple proxy servers to connect to the Internet, the same user may be coming to a Web site from a different proxy server for each TCP connection. Therefore, the source IP address in the connection is not a reliable indicator of a given user. This is known as the megaproxy problem. It can be addressed by using cookie-based or virtual source persistence.
Virtual source, which allows the load balancer to treat all traffic from multiple source IP addresses as if it's coming from one source, can be a handy feature for situations in which cookie switching cannot be used and for users who have turned off the cookies in their browser.
There are two ways to do cookie-based persistence.
In the first approach, the Web server sets a cookie value that indicates to the load-balancing switch which Web server a connection must be directed to.
Alternatively, the load balancer can hash on the entire cookie string to select a Web server. Once the load balancer selects a Web server for a given hashing value, it will stick with that Web server for all subsequent requests with the same cookie string. Cookie-based persistence can be used in conjunction with source IP-based persistence to deal with users or situations in which a cookie is not present.
SSL is a protocol used to provide secure e-commerce over the Internet. In order to establish an SSL session, the client and the Web server first exchange certain parameters for encryption and decryption. The Web server sends an SSL identifier as part of the negotiation. The load balancer stores the SSL session ID and its association with a Web server to ensure that all subsequent traffic with that SSL session ID will be directed to the same Web server.
When evaluating load-balancing switches for superior session persistence, it's important to consider their concurrent session capacity. Because ensuring session persistence over extended periods of time can consume a significant portion of the session table, a load-balancing switch must have enough session capacity to handle not only all of the active sessions, but also be able to keep track of persistence information for past sessions.
For example, a load-balancing switch must keep track of 20,000 SSL session IDs to successfully process a shopping cart application for 20,000 customers simultaneously. Load-balancing switches that track sessions in central shared memory tend to provide superior concurrent session capacity and support many different network topologies to suit various price/performance and reliability needs.
On the other hand, load-balancing switches that track sessions in memory associated with each port provide very limited concurrent-session capacity due to per-port limitations and impose severe restrictions in the network design.
Kopparapu is a product marketing manager at Foundry Networks Inc., a maker of Internet routers, Layer 3 switches and traffic management products located in San Jose. She can be reached at Chandra@foundrynet.com.