Apache Security - Ivan Ristic [137]
DNS Round Robin (DNSRR) load balancing
A cluster of servers (see Figure 9-7) provides scalability, high availability, and efficient resource utilization (load balancing). First, we need to create a cluster. An ideal cluster consists of N identical servers, called (cluster) nodes. Each node is capable of serving a request equally well. To create consistency at the storage level, one of the following strategies can be used:
Install nodes from a single image and automate maintenance afterward.
Boot nodes from the network. (Such nodes are referred to as diskless nodes.)
Use shared storage. (This can be a useful thing to do, but it can be expensive and it is a central point of failure.)
Replicate content (e.g., using rsync).
Put everything into a database (optionally clustering the database, too).
Figure 9-7. DNS Round Robin cluster
After creating a cluster, we need to distribute requests among cluster nodes. The simplest approach is to use a feature called DNS Round Robin (DNSRR). Each node is given a real IP address, and all IP addresses are associated with the same domain name. Before a client can make a request, it must resolve the domain name of the cluster to an IP address. The following query illustrates what happens during the resolution process. This query returns all IP addresses associated with the specified domain name:
$ dig www.cnn.com
; <<>> DiG 9.2.1 <<>> www.cnn.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38792
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;www.cnn.com. IN A
;; ANSWER SECTION:
www.cnn.com. 285 IN CNAME cnn.com.
cnn.com. 285 IN A 64.236.16.20
cnn.com. 285 IN A 64.236.16.52
cnn.com. 285 IN A 64.236.16.84
cnn.com. 285 IN A 64.236.16.116
cnn.com. 285 IN A 64.236.24.4
cnn.com. 285 IN A 64.236.24.12
cnn.com. 285 IN A 64.236.24.20
cnn.com. 285 IN A 64.236.24.28
Here you can see the domain name www.cnn.com resolves to eight different IP addresses. If you repeat the query several times, you will notice the order in which the IP addresses appear changes every time. Hence the name "round robin." Similarly, during domain name resolution, each client gets a "random" IP address from the list. This leads to the total system load being distributed evenly across all cluster nodes.
But what happens when a cluster node fails? The clients working with the node have already resolved the name, and they will not repeat the process. For them, the site appears to be down though other nodes in the cluster are working.
One solution for this problem is to dynamically modify the list of IP addresses in short intervals, while simultaneously shortening the time-to-live (TTL, the period during which DNS query results are to be considered valid).
If you look at the results of the query for www.cnn.com, the TTL is set to 285 seconds. In fact, CNN domain name servers regenerate the list every five minutes. When a node fails, its IP address will not appear on the list until it recovers. In that case, one portion of all clients will experience a downtime of a couple of minutes.
This process can be automated with the help of Lbnamed, a load-balancing name server written in Perl (http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html).
Another solution is to keep the DNS static but implement a fault-tolerant cluster of nodes using Wackamole (http://www.backhand.org/wackamole/). Wackamole works in a peer-to-peer fashion and ensures that all IP addresses in a cluster remain active. When a node breaks down, Wackamole detects the event and instructs one of the remaining nodes to assume the lost IP address.
The DNSRR clustering architecture works quite well, especially