Product Reviews

Keeping Your Balance

As your Web site grows, you must find a way to manage traffic. Here are some load-balancing technologies that can help your site zip right along.

• By Tony Northrup
• 01/01/2001

One of the older load-balancing solutions is Cisco LocalDirector. I’ve been working with the device for more than four years. While I’ve had good and bad experiences with it, over time, LocalDirector has proven itself reliable and predictable.

Logically, LocalDirector resides in front of your Web server array, as illustrated in Figure 1.

Typically, the physical architecture mirrors this logical architecture — LocalDirector bridges traffic between the public Internet connection and your server farm. As HTTP requests are sent to your Web servers, LocalDirector intercepts these requests. It then applies a routing algorithm to determine to which Web server it’ll direct the request and sends the packets to that server.

LocalDirector has its own operating system, a version of Cisco’s IOS. It’s actually quite easy to use, but for Windows administrators it seems counter-intuitive. The primary method of administering LocalDirector is via a text interface that can be accessed through a serial cable or telnet session. Unix administrators will feel right at home with this, but MCSEs may be frustrated. As an alternative, a graphical interface is available; still, most people prefer the text controls.

Figure 1. Cisco LocalDirector assumes your Web site’s primary IP address and intelligently distributes requests among multiple Web servers.

Keep in mind that, at this high level, all load-balancing devices perform similarly. The devil is in the details, though, so to differentiate among the devices we need to dig a little deeper.

The Importance of Persistent Connections
Five years ago, when the Internet was still young, load-distribution products had a much easier task. Web sites were little more than electronic brochures. Nowadays, virtually every site keeps track of individual users as they browse. If you’re using a load-distribution product, there’s a chance the load-distribution device will send a user to different Web servers during the time they spend at your site. With IIS 5 and ASP sessions, user information exists only in the RAM of a single Web server, so if a user is bounced to a different server, the new server won’t have that user’s session information. This feature’s so important that all modern load-distribution products provide a way to ensure that a specific user’s requests are forwarded to the same server throughout a session.

The simplest method of maintaining persistent connections is through what’s called a sticky session. When a sticky session is enabled, LocalDirector remembers the source IP address of every incoming connection and the server where the last request was forwarded. Every new incoming connection from the same IP address is forwarded to the same real server. This is a good start and works perfectly for about 80 percent of users.

The sticky algorithm shows weakness, however, when there isn’t a one-to-one relationship between users and IP addresses. When multiple users are coming from a single IP address, such as when NAT or Microsoft Proxy Server is used, all users behind the same proxy are sent to the same destination server. This may not sound like much of a problem, but when you consider the large number of America Online users who are behind a proxy, load distribution can be measurably unbalanced.

A more difficult problem occurs when a single user doesn’t keep a single IP address throughout a session. Again, we have to blame AOL’s proxy architecture. AOL uses numerous proxy servers to handle its high traffic; a single user’s session can be sent through several different proxy servers—changing the source IP address of requests each time. When LocalDirector receives a request with a different source IP address, the device views this as a brand-new user and sends the request to the least busy server. If this happens in the middle of a user’s session, there’s a good chance that the user will be sent to a different Web server and session information will be lost. If the user is forced to log in again, he or she may quit browsing your site.

Besides sticky sessions, Cisco offers several other solutions. If your site consistently uses SSL during a session, LocalDirector can examine the SSL session ID to identify users. If this mechanism is used for load balancing instead of sticky sessions, individual users will be sent to the same server even if their IP addresses change. For sites that don’t use SSL, Cisco’s “Cookie Sticky” algorithm uses HTTP cookies in a similar way, generating new cookies or using those that your Web application has provided.

New with version 4.1.1 of LocalDirector, content load balancing allows incoming requests to be distributed to a specific server based on the request’s URL. For example, this setup allows you to have all requests for files within your /html directory to be sent to your WWW1 server, requests for /images to be sent to your WWW2 server, and requests for /scripts to be sent to your WWW3 server. This is a useful strategy for content-heavy sites. Note that content load balancing is one of the key differentiators between high-end load balancing products. According to F5 Networks, its BIG-IP controllers, with Layer 7 intelligence, can actually analyze data within HTTP requests in order to make distribution decisions.