Server Load Balancing Concepts
(and the Vclass)
by David M. Piscitello, President, Core Competence, Inc.
Your users complain that your Web server’s slow. You
investigate and confirm that your server is indeed overworked. Your
Live with it
Upgrade the server, or
Distribute your Web service
across multiple servers.
Distributing Web service is often the wisest choice,
but it also requires planning to assure that content and policy remain
consistent across servers. To assure that you actually improve
performance, it’s often important to consider some form of load
balancing across servers.
What is Server Load Balancing?
In Server Load
Balancing, Tony Bourke explains that, “Load balancing distributes
traffic efficiently among network servers so that no individual server is
In many scenarios, however, it’s not simply a matter of
distributing traffic equally across however many servers one deploys.
Other factors can come into play, such as server capacity and whether
content is distributed rather than duplicated across
servers. Certain Web transactions may also require that a Web server
consult a non-local database or networked storage, which increases latency
for each such transaction. With the emergence of Web Services, where
organizations share and exchange applications using HTTP as a messaging
protocol, a server may need to request additional application support from
yet another Web server, again adding processing and communications
latency. The concept may seem intuitive, but balancing can be tricky.
Load Balancing Actions
Server load balancing begins with a “round robin”
technique, where all servers are treated as equally capable, and hence
receive equal priority and scheduling. But that’s just the beginning.
Efficient load balancing requires that you identify the factors that add
complexity, and that the load balancing agent offer algorithms that let
you adjust and fine tune server load. The Firebox Vclass offers a number
of load balancing actions:
Robin. If you have a
farm of servers that have the same CPU speeds, memory, LAN interface
speed, operating system, application mix and content – in simple terms,
if the services they offer are nearly identical and the rate at which
they can process transactions is equal – then choose this algorithm to
distribute traffic evenly (with equal priority) across all the servers
in the farm.
Weighted Round Robin. Suppose your
application mix and content is mirrored (identical) across all your
servers, but you have a mix of older and new server hardware. You have
benchmarked your servers and have determined that two servers handle 500
transactions per second and two handle 250 transactions per second. In
this scenario you want to direct traffic towards the faster servers. Do
so by assigning a larger percentage of the total load (a weight)
to the two faster servers. In this example, I would assign 33% to each
fast server, and 16% to each slower server.
Random and Weighted Random. The
Random algorithm is self-explanatory. Traffic is directed arbitrarily to
any server in your farm. Like the term “jumbo shrimp,” Weighted Random
initially sounds like an oxymoron. But the implementation simply biases
the random distribution of load in favor of faster machines. Using my
same four servers from my earlier example, each of the faster servers
would be twice as likely to be “randomly” selected for handling an
incoming request as the slower servers.
Least Connection and Weighted Least
Connection. Another metric to measure server capacity is the number
of connections it can handle “simultaneously.” When you choose Least
Connection, the Firebox Vclass keeps track of the number of
connections each server is handling, and directs incoming connections to
the least busy server in the farm. This is especially meaningful if your
server sessions tend to be longer-lived (for example, if your servers
offer streaming media or large file downloads). As you would expect, the
weighted variant of this algorithm allows you to fine tune traffic
direction in favor of the faster of your servers.
So far, so good, right? But the Vclass offers yet
another fine-tuning option. These actions are configured in conjunction
with something called Virtual IP Network Address Translation.
Virtual IP Network Address Translation
When you expand from one to many servers, you will
often want to keep the same public domain name(s) and address(es) for the
services you offer. The Firebox Vclass supports a specific kind of network
address translation (NAT) for this purpose. Virtual
IP NAT directs external requests delivered to a publicly known IP address through a
list of IP addresses assigned to the servers in your farm. The Virtual IP
is the public IP address you assigned to your Firebox Vclass. Users who
resolve the domain name for your external-facing Web server (extranet or
public Web, for example) will have their requests forwarded to the Firebox
Vclass for handling. The Vclass NATs this single public address onto
however many IP addresses you have assigned to the systems that comprise
your server farm. Thus, Virtual IP as the Vclass uses the term corresponds
NAT in Firebox III and earlier models.
[For those of
you familiar with WatchGuard Firebox System MUVPN, this interpretation of
the term Virtual IP is very different. With MUVPN, a Virtual
IP is assigned to remote access IPsec clients from a primary or
secondary IP subnet assigned to the Firebox’s Trusted
Virtual IP NAT and load balancing actions are elements
of a Vclass security policy. As with all Vclass security policies, your
traffic specification will “pass” traffic from a source (typically, ANY)
to a destination (always the IP address assigned to the Vclass public
interface). Use protocol to specify traffic type (e.g., HTTP). Apply
a Virtual IP NAT action, and then define the load balancing action
associated with this NAT type.
Virtual IP NAT can minimize addressing issues you might
otherwise encounter when expanding Web and other services from one (or a
few) to many servers. Complemented with Server Load Balancing, it can ease
the pains an organization experiences as its Web services grow. As the
name of the action implies, balancing can be tricky. The more you know
about the capacity of your servers, the better prepared you will be to
select a load balancing action that makes most efficient use of your
resources. Perhaps it is as much art as science, but with some careful
experimentation – and the various tools the Firebox Vclass offers – you
can efficiently balance your servers and accomplish noticeable throughput
Copyright© 2003, WatchGuard Technologies, Inc. All rights
reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks
or registered trademarks of WatchGuard Technologies, Inc. in the United
States and other countries.