Why is load balancing of servers needed?
If there is only one web server responding to all the incoming HTTP requests for your website, the capacity of the web server may not be able to handle high volumes of incoming traffic once the website becomes popular. The website's pages will load slowly as some of the users will have to wait until the web server is free to process their requests. The increase in traffic and connections to your website can lead to a point where upgrading the server hardware will no longer be cost effective.

In order to achieve web server scalability, more servers need to be added to distribute the load among the group of servers, which is also known as a server cluster. The load distribution among these servers is known as load balancing. Load balancing applies to all types of servers (application server, database server), however, we will be devoting this section for load balancing of web servers (HTTP server) only.

About load balancing mechanism - IP Spraying
When multiple web servers are present in a server group, the HTTP traffic needs to be evenly distributed among the servers. In the process, these servers must appear as one web server to the web client, for example an internet browser. The load balancing mechanism used for spreading HTTP requests is known as IP Spraying. The equipment used for IP spraying is also called the 'load dispatcher' or 'network dispatcher' or simply, the 'load balancer'. In this case, the IP sprayer intercepts each HTTP request, and redirects them to a server in the server cluster. Depending on the type of sprayer involved, the architecture can provide scalability, load balancing and failover requirements.

---

How DNS load balancing works
When the request comes to the DNS server to resolve the domain name, it gives out one of the several canonical names in a rotated order. This redirects the request to one of the several servers in a server group. Once the BIND feature of DNS resolves the domain to one of the servers, subsequent requests from the same client are sent to the same server.

DNS load balancing implementation (Multiple CNAMES)
This approach works for BIND 4 name servers, where multiple CNAMES are not considered as a configuration error. Assuming there are 4 web servers in the cluster configured with IP addresses 123.45.67.[1-4], add all of them to the DNS with Address records (A Names) as below. The srv[1-4] can be set to any name you want, such as foo[1-4], but should match the next step.

	server1   IN  A   123.45.67.1
	server2   IN  A   123.45.67.2
	server3   IN  A   123.45.67.3
	server4   IN  A   123.45.67.4
	

Add the following canonical names to resolve www.domain.com to one of these servers.

	www    IN  CNAME   server1.domain.tld.
	       IN  CNAME   server2.domain.tld.
	       IN  CNAME   server3.domain.tld.
	       IN  CNAME   server4.domain.tld.

The DNS server will resolve the www.domain.com to one of the listed servers in a rotated manner. That will spread the requests over the group of servers.

Note:
The requests sent to http://domain.com (without 'www') should be forwarded to http://www.domain.com in this case to work. For BIND 8 name servers, the above approach will throw an error for multiple CNAMES. This can be avoided by an explicit multiple CNAME configuration option as shown below.

options {
   multiple-cnames yes;
};              

DNS load balancing implementation (Multiple A Records)

This above approach with multiple CNAMES for one domain name is not a valid DNS server configuration for BIND 9 and above. In this case, multiple A records are used.

	www.domain.tld.  60  IN  A  123.45.67.1
	www.domain.tld.  60  IN  A  123.45.67.2
	www.domain.tld.  60  IN  A  123.45.67.3
	www.domain.tld.  60  IN  A  123.45.67.4

The TTL value should be kept to a low value, so that the DNS cache is refreshed faster.

Other considerations
The DNS based load balancing method shown above does not take care of various potential issues such as unavailable servers (if one server goes down), or DNS caching by other Nameservers. The DNS server does not have any knowledge of the server availability and will continue to point to an unavailable server. It can only differentiate by IP address , but not by server port. The IP address can also be cached by other Nameservers, hence requests may not be sent to the load balancing DNS server.

Considering the functionality, the round robin DNS is not a load balancing mechanism but a load distribution option. Some of these drawbacks can be overcome by implementing an advanced version of the DNS load balancer using Perl scripts. The details can be found here.

Some other variety of load balancing can be performed by using a proxy server , where one of the web servers, is solely used for re-routing of traffic to the other servers. If Apache is used as a web server, the mod_rewrite feature of Apache can be used for this purpose as detailed in this Apache website article.

---

Server Load Balancing Methods
There are various ways in which load balancing can be achieved. The deciding factors for choosing one over the other depends on the requirement, available features, complexity of implementation, and cost. For example, using a hardware load balancing equipment is very costly compared to the software version.

• Round Robin DNS Load Balancing
  The in-built round-robin feature of BIND of a DNS server can be used to load balance multiple web servers. It is one of the early adopted load balancing techniques to cycle through the IP addresses corresponding to a group of servers in a cluser. The details on the implementation is discussed here.

  Pros: Very simple, inexpensive and easy to implement.

  Cons: The DNS server does not have any knowledge of the server availability and will continue to point to an unavailable server. It can only differentiate by IP address, but not by server port. The IP address can also be cached by other Nameservers and requests may not be sent to the load balancing DNS server.

• Hardware Load Balancing
  Hardware load balancers can route TCP/IP packets to various servers in a cluster. These types of load balancers are often found to provide a robust topology with high availability, but comes for a much higher cost.

  Pros: Uses circuit level network gateway to route traffic.

  Cons: Higher costs compared to software versions.

• Software Load Balancing
  Most commonly used load balancers are software based, and often comes as an integrated component of expensive web server and application server software packages.

  Pros: Cheaper than hardware load balancers. More configurable based on requirements. Can incorporate intelligent routing based on multiple input parameters.

  Cons: Need to provide additional hardware to isolate the load balancer.

---

Round Robin DNS
A load balancing technique in which balance power is placed in the DNS server instead of a strictly dedicated machine as other load techniques do.

Round robin works on a rotating basis in that one server IP address is handed out, then moves to the back of the list; the next server IP address is handed out, and then it moves to the end of the list; and so on, depending on the number of servers being used. This works in a looping fashion.

Round robin DNS is usually used for balancing the load of geographically distributed Web servers. For example, a company has one domain name and three identical home pages residing on three servers with three different IP addresses. When one user accesses the home page it will be sent to the first IP address. The second user who accesses the home page will be sent to the next IP address, and the third user will be sent to the third IP address. In each case, once the IP address is given out, it goes to the end of the list. The fourth user, therefore, will be sent to the first IP address, and so forth.

Although very easy to implement, round robin DNS has important drawbacks, such as those inherited from the DNS hierarchy itself and TTL times, which causes undesired address caching to be very difficult to manage. Moreover, its simplicity makes that remote servers that go unpredictably down inconsistent in the DNS tables. However, this technique, together with other load balancing and clustering methods, can produce good solutions for some situations.

In BIND 9, this is as easy as adding multiple A records for a single host. For example, suppose we use this in the zone file for ServerTune.com:

	www 60	IN	A	207.250.188.7
	www 60 	IN	A	207.250.188.8
	

 Now, when a hosts looks up www.ServerTune.com in DNS, about half of the time they will see:

root:~$ host www.ServerTune.com
www.ServerTune.com has address 207.250.188.7
www.ServerTune.com has address 207.250.188.8

and the rest of the time, they get:

root:~$ host www.ServerTune.com
www.ServerTune.com has address 207.250.188.7
www.ServerTune.com has address 207.250.188.8

As most applications only use the first address returned by DNS, this works rather nicely. Approximately half of the requests will go to each address, and therefore the load of two servers should be roughly half of that of a single server. We set the TTL low (to 60 seconds) to prevent any intervening caching DNS servers from hanging onto one sort order for too long, which will hopefully help keep the number of requests to each host more or less equal.

It is only useful to spread out the load if all of the servers are in agreement about what they're serving. If your data gets out of sync, then browsers might get one version of a web page on the first hit and another when they hit reload. If you're looking for a way to keep that from happening, take a look at.

Also, keep in mind that doing actual IP takeover (in case one host is unable to perform its duties) is tricky business. If one server dies, you can't change DNS and wait for it to propagate to the entire Internet. You'll need something that takes over for the down server immediately.

Other articles in this Category