Load Balancing 101: Nuts and Bolts

Written by KJ (Ken) Salchow, Jr. | Manager, Product Management Load Balancing 101: Nuts and Bolts
Introduction Load balancing technology is alive and well; in fact, it is the basis from which today's Application Deliver Controllers (ADCs) operate. But the pervasiveness of load balancing technology does not mean it is universally understood, nor is it typically discussed other than from a basic, network-centric viewpoint. In a more thorough exploration of the subject, this white paper intends to strip away some of the mystery and magic from basic load balancing practices.
Network-Based Load balancing Hardware The second iteration of purpose-built load balancing (following application-based proprietary systems) came about as network-based appliances. These are the true founding fathers of today's Application Delivery Controllers. Because these boxes were application-neutral and resided outside of the application servers themselves, they could achieve load balancing using straight-forward network techniques. In essence, these devices would present a "virtual server" address to the outside world and when users attempted to connect, it would forward the connection on the most appropriate real server doing bi-directional network address translation (NAT).

Basic Terminology It would certainly help if everyone used the same lexicon; unfortunately, every vendor of load balancing devices (and, in turn, ADCs) seems to use different terminology. With a little explanation, however, the confusion surrounding this issue can easily be alleviated.
The "Node," "Host," "Member," and "Server" Most load balancers have the concept of a node, host, member, or server; some have all three and they mean different things. There are two basic concepts that they all try to express. One concept-usually called a node or server-is the idea of the physical server itself that will receive traffic from the load balancer. This is synonymous with the IP address of the physical server and, in the absence of a load balancer, would be the IP address that the server "name" (for example, www.example.com) would resolve to. For the remainder of this paper, we will refer to this concept as the "host." The second concept is a member (sometimes, unfortunately, also called a node by some manufacturers). A member is usually a little more defined than a server/node in that it includes the TCP port of the actual application that will be receiving traffic. For instance, a server named www.example.com may resolve to an address of 172.16.1.10, which represents the server/node, and may have an application (a web server) running on TCP port 80, making the member address 172.16.1.10:80. Simply put, the member includes the
F5 Networks, Inc. - 1 - © Jul-07 Written by KJ (Ken) Salchow, Jr. | Manager, Product Management definition of the application port as well as the IP address of the physical server. For the remainder of this paper, we will refer to this as the "service." Why all the complication? The distinction between a physical server and the application services running on it allows the load balancer to individually interact with the applications instead of the underlying hardware. A host (172.16.1.10) may have more than one service available (HTTP, FTP, DNS, and so on). By defining each application uniquely (172.16.1.10:80, 172.16.1.10:21, and 172.16.1.10:53), the load balancer can now apply unique load balancing and health monitoring (discussed later) based on the services instead of the host. However, there are still times when being able to interact with the host (like low-level health monitoring or when taking a server offline for maintenance) is extremely convenient. The important part to remember is simply that most load balancing-based technology uses some concept to represent the host, or physical server, and a second one to represent the services available on it.
The "Pool," "Cluster," and "Farm" Load balancing allows you to distribute inbound traffic across multiple back-end destinations. It is therefore a necessity to have the concept of a collection of back-end destinations. Clusters, as we will refer to them herein, are collections of similar services available on any number of hosts. For instance, all services that offer the company web page would be collected into a cluster called "company web page" and all services that offer ecommerce services would be collected into a clu... [download for more]