Load Balancing Using Round Robin

Creating a Load Balancing effect with DNS servers is easier than you might think. Maybe if you have ever heard of the term round robin algorythms you have an idea of what im talking about. Find out a detail article of load balancing using DNS servers like BIND.

Configure Round Robin

We take for granted that you already have multiple servers and that you are in need og dividing your load between servers. The most typical load balacing scenarios are applied on web servers, however you can do it with Mail Servers or other type of services as needed.

Balancing Mail

You can balance your mail simply adding different mail hosts with the same mail priority, like in the case below, you will notice 3 instances of mail servers with a priority of 10. This simply will divide the load between the 3 servers.

Define multiple MX records with the same priority

; zone file fragment IN MX 10 mail.example.com.
IN MX 10 mail1.example.com.
IN MX 10 mail2.example.com
.....
mail IN A 192.168.0.1
mail1 IN A 192.168.0.2
mail2 IN A 192.168.0.3
The name server will deliver the MX records in the order defined by the rrset-order and the receiving SMTP software will select one based on its algorithm. In some cases the SMTP alogithm may work against the definition of the rrset-order statement. Current versions of sendmail (8.13.x), Exim (4.44) and Postfix (2.1 or 2.2) all have definitive references to indicate they randomly select equal preference servers (Postfix allows control of the behaviour with the smtp_randomize_addresses parameter) and consequentially may use an address which the rrset-order has carefully tried to change! qmail, courier-mta and Microsoft (Exchange and IIS SMTP) documentation do not appear to have definitive references to indicate how they handle this case.

2. The alternate approach is to define multiple A records with the same name and different IP addresses.

; zone file fragment
IN MX 10 mail.example.com
.....
mail IN A 192.168.0.4
IN A 192.168.0.5
IN A 192.168.0.6

In this case the load-balancing effect is under the control of BIND and the rrset-order record. In order to avoid problems if the receiving mail system does reverse look up as a spam check then the PTR records for 192.168.0.4, 192.168.0.5, 192.168.0.6 above must all define to mail.example.com.

In all the above cases each mail server must be capable of handling and synchronising the load for all the mail boxes served by the domain, using some appropriate back-end to do this or by defining all but one server to be a relay or forwarder.

Balancing Other Services

Assuming you want to load share your ftp or web services then you simply define multiple A records with the same name and different IPs as in the example below.

; zone file fragment
ftp IN A 192.168.0.4
ftp IN A 192.168.0.5
ftp IN A 192.168.0.6
www IN A 192.168.0.7
www IN A 192.168.0.8
; or use this format which gives exactly the same result
ftp IN A 192.168.0.4
IN A 192.168.0.5
IN A 192.168.0.6
www IN A 192.168.0.7
IN A 192.168.0.8

The DNS will deliver all the IP addresses defined, the first IP address in the list will be in a default round robin (controlled by the rrset 'named.conf' directive). The FTP and WEB servers must all be exact replicas of each other in this scenario.


Controlling the order of RRs

You can control the order of RR that BIND supplies in response to queries by use of a rrset-order option which works for any set of equal records. The default behaviour is defined to be random-cyclic - a random selection of the initial order thereafter cyclic (round-robin). Experimentation with BIND 9.3.0 showed that the default is cyclic.

rrset-order

rrset-order { order_spec ; [ order_spec ; ... ]

rrset-order defines the order in which multiple records of the same type are returned. This works for any record type in which the records are similar. RRSET-ORDER IS FULLY IMPLEMENTED IN BIND > 9.2.3. The default is defined to be a random-cyclic order (the starting address is randomly chosen and thereafter round-robin order). Note: Experimentation showed the default to be pure cyclic.

The full specification of rrset-order is shown below. An 'order_spec' is defined as:

class class_name ][ type type_name ][ name "domain_name"] order ordering;

Where 'class_name' is the record class e.g. IN (default is 'any'), type is the resource record type (if none specified defaults to 'any'), domain_name limits the statement to a specific domain suffix and defaults to root (all domains), order is a key word and ordering may take one of the following values:

* fixed - records are returned in the order they are defined in the zone file
* random - records are returned in a random order
* cyclic - records are returned in a round-robin fashion

Examples

Defines that all equal records for all domains will be returned in random order.

rrset-order {order random;};

Defines that all equal MX records for all example.com will be returned in random order all others in cyclic order.

rrset-order {type MX order random name "example.com"; order cyclic};

This statement may be used in a view or a global options clause.

Effectiveness of DNS Load Balancing

Assuming the interest in controlling the order is to load balance across multiple servers supporting a single service - the real question is how effective can the DNS system be in providing this balancing?

The effects of caching will distort the effectiveness of any IP address allocation algorithm unless a 0 TTL is used which has the effect of significantly increasing the load on the DNS (and is not always implemented consistently). In this case the cure may be worse than the disease Good news we have good load balancing on our web servers. Bad news we need 17 more DNS servers!. Intuitively, and without running any experiments to verify, we would suggest that given a normal TTL (12 hours or more) and ANY IP allocation algorithm other than a single static list, loads should be reasonably balanced (measured by request arrivals at destination IPs) given the following assumptions:

1. traffic is balanced over a number of DNS caches i.e. traffic originates from a number of ISPs or customer locations. Specifically there are no PATHOLOGICAL patterns where 90% (or some large'ish number) of the load originates from a particular cache/service).

2. the volume of traffic is reasonably high - since PATHOLOGICAL patterns are more likely in small traffic volumes.

What DNS load balancing cannot do is to account for service loading e.g. certain transactions may generate very high CPU or resource loads. For this type of control only a local load balancer - one which measures response times - will be effective.

Finally on this topic if you still consider that a DNS solution will do the trick if only you could control the order of IP address generation you can use the BIND 9 SDB API to achieve the result.