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 choices:
-
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 overburdened.”
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:
- Round 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 to dynamic 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 interface.]
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.
Conclusions
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 gains. ##
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.