Load-balancing

[Kevin Darcy]

af281 at city.ac.uk wrote:

> We are considering a proposal to move from Microsoft Domain Name
> Service Manager (4.0) to BIND 9.x.x running on Solaris 8
>
> I had a question about any kind of load-balancing available on BIND 9.x
>
> Is it possible to load-balance using a hash or other algorithm if I had,
> say, 2 BIND servers running on Solaris?
>
> We are looking at the possibility of doing some kind of load-balancing at
> the DNS level rather than (or in addition to) the network level.

There are basically 3 approaches to using DNS for load balancing:

1) The nameserver gives only only 1 address (or a small subset of
addresses) for a given name -- the address of the "preferred" server(s),
where "preferred" ephemerally depends on what servers are up, down,
lightly-loaded versus heavily-loaded, etc. You could use some sort of script
for measuring/monitoring these things, and then updating BIND using the
Dynamic Update protocol to reflect the preference.

2) The nameserver gives *all* of the addresses for the name, but sorts them
in order of preference. The advantage of this is that most modern
application clients (e.g. web browsers) will automatically failover through
the address list sequentially in case of machine failures or slow-responding
servers. In terms of implementation, again, you could have an automatic
script re-arrange the order of the records dynamically, and you'd have to
configure your master and all of your slaves with an "rrset-order" option
for the name(s), set to "fixed".

3) Use SRV records for your service instead of regular A records.
SRV records have "preference" and "weight" fields which determine the order
in which clients should access the servers. You could have a script
dynamically manipulate the preference and weight fields, if necessary, to
reflect changing conditions.

The problem with all 3 of these approaches is caching. DNS servers will
cache responses and then give out that answer any way it sees fit. So in the
case of approach #1, clients may still try to go to a dead or overloaded
server even after you've changed the records; similarly in the case of
approach #3, clients may not see your manipulations to the weight and/or
preference fields until long after you've made them; and in the case of
approach #2, the caching server may re-arrange the order of the address
records, thus mucking up your careful ordering scheme.

You can mitigate the effects of caching somewhat by reducing the TTL values
on your records. But that will make your nameservers (and possibly even your
network infrastructure) overwork, and it's a rather rude and anti-social
thing to do since it makes everyone *else's* nameservers overwork as well.
It's not an acceptable general solution: the whole DNS system would be
brought to its knees if everyone reduced the TTLs on their address records
to 0.

Approach #3 is generally considered to be the technically *best* form of
DNS-based load balancing. However, SRV records are somewhat new, and no
browsers are currently known to support them (see
http://bugzilla.mozilla.org/show_bug.cgi?id=14328 for a recent attempt to
get this into Mozilla).


- Kevin