BIND and Load Balancing

Many people ask about how to do load balancing with BIND. We have
also received several requests to improve BIND's ability to do
load balancing. We are reluctant to do so, and would like to
explain why.
Technical Background
DNS consists of a set of resource records (RRs) in a hierarchical
structure. These resource records are of the form of a name,
a type and data specific to the type. DNS allows for more
than one RR to have the same name and type, and this is called
a set (RRset). According to the spec for DNS, the order of RRs
in a RRset is unknown. Each RR has a TTL value that says how
long it is allowed to live in caches.
There is a whole chain of things that act on the basic request.
The resolver library creates the DNS query and decodes the answer
for the application. There are the master and slave nameservers
who have the permanent answers to the questions, and there may
be several intermediate nameservers who could have the answer in
cache or need to pass the request on.
Meanwhile, at the application level, many applications are not
designed to handle a set of answers to a query. In the case of name
to address translation, it is common practice to simply pick the
first one in the list and try it as if it was the only one in the
list. For most applications, all that comes back is the IP address,
and all the other information that DNS had is lost.
Load balancing today
In the early version of the nameserver, the order of RRs in an
RRset was fixed. This meant that even though you may have several
RRs, by the way all the pieces in the DNS chain worked, no one would
ever used anything but the first entry. It was realized that since
the spec said there was no order in an RRset, it would break nothing
to shuffle the order. The simplest way to do this was to roll the
order each time you answered a query for this RRset. Since almost
all the issues are for A records, unless otherwise noted we will
assume host address lookups.
This is the current "round robin" function, and it has been used
quite successfully for several years in sharing load among several
machines. But this does not meet everyone's needs. People want to
do other things beyond the simple even distribution. Some people
want to detect and remove dead servers from the list (if 1 of 4
servers dies, 25% of the connections will fail.) Others want to
dymanically change the rate at which various servers are on top of
the list to spread work better rather than just connections. Others
are interested more in minimizing delay to the user, and want to
sort the list to get the closest machine on top.
So which ordering mechanism do we choose to implement?
Given that the spec says that the data is not ordered, and there
are different ideas of what kind of reordering is needed, we see

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有