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
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
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
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
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.
About the Author
Tony Northrup, MCSE, Compaq ASE, lives in the Boston area and is currently
a systems architect at Genuity. He’s the author of Introducing Windows
2000 Server (Microsoft Press) and NT Network Plumbing (IDG Books), and
co-author of Networking Essentials Unleashed (SAMS Publishing).