Headers for cached page www.cisco.com/warp/public/787/49.html:
HTTP/1.0 200 OK
Date: Thu, 14 Oct 1999 00:59:47 GMT
Server: CCO/1.0.5.7
Content-type: text/html
Content-length: 5079
Last-modified: Tue, 20 Jan 1998 19:01:09 GMT
![navbar]()
"Round-Robin" DNS
Introduction
This document explains the implementation of "round-robin" DNS in
the Berkeley Internet Name Domain (BIND) and contrasts it with DNS
load balancing, also a supported feature of MultiNet.
MultiNet Support for Round Robin
The current MultiNet releases (V3.5 and 4.0) support round robin.
Versions 4.9.1 and later of BIND support "round-robin" DNS. MultiNet 4.0
supports BIND 4.9.3.
Note: You can upgrade support for BIND by downloading the ECO
ECO-BIND040.ZIP
via FTP.(Download ECO-BIND035B-494-P1.ZIP if your system is running MultiNet
3.5. Earlier versions of MultiNet are no longer officially supported.)
For details about downloading, unzipping, and installing ECOs, see
ECOs and Software Updates.
Note: If ever you're not sure and want to check the BIND version
you are using, the command $ MULTINET NETCONTROL DOMAIN VERSION
will show the BIND version; the version also appears in an early OPCOM message
when DNS is started.
What Is "Round-Robin" DNS?
In "round-robin" DNS, a random IP address will be
returned with each request if multiple entries exist in the DNS
using CNAME and
A records.)
The purpose of round robin is to allow use of multiple HTTP servers
(with identical contents) in order to distribute the connection loads.
Round-robin is not random, though it gives a random effect. It operates
in a round-robin fashion (as the name implies), in that it rotates the
return record sequence by one for each response one address is handed
out, put at the end of the list, and then the next one is handed out for
the next translation request, something like a translation list.
One of the advantages of have the round-robin translations is being able to
take one of the server systems out of the loop for maintenance. A simple
removal at the nameserver level from the round-robin list allows almost no
apparent loss to the client systems (except for those that cache).
The disadvantage is possible confusion at the user level. When one system
fails, it appears to the user as intermittent failure because the service
appears to come and go, so, once connected, a user is less likely to report
a failure.
Although using round robin will work, it does not provide
true load balancing, and it doesn't automatically handle hosts that
go down (manual modification of DNS zone files and reloading DNS is
required).
Any BIND server that supports DNS round robin can serve the
"A" records for any host your nameserver doesn't need to be running
on the host(s) where you want to do round robin.
Round Robin Contrasted to Load Balancing
As stated above, round-robin DNS does not provide true load balancing.
MultiNet's DNS Load Balancing feature does implement true, dynamic
load balancing
using a LAT-like algorithm of computable processes above DEFPRI and other
metrics to determine system load. MultiNet returns an
IP address based on the current load on the systems listed and will serve
the fastest node first.
This works only in a VMScluster. (You must have at least one
node in your cluster
act as a nameserver for the pseudo-hostname you set up for load
balancing. For redundancy,
we recommend more than one host.) DNS load balancing
automatically handles hosts going down without requiring
manual intervention.
Cisco LocalDirector Load Balancing
Cisco's LocalDirector
product provides true load
balancing for any TCP-based service (HTTP, Telnet, FTP, and so on).
LocalDirector is a piece of hardware
that sits between your Internet connection and the hosts you want to load
balance. To your system, it looks like a bridge unless it is performing
load balancing.
LocalDirector
doesn't use DNS and it doesn't require any load-measuring
process to be installed on your host machines. It also automatically handles hosts going down.
It supports use of any
operating system as your server system and speeds up to T3.
Some of the information in this document was contributed by
Michael Young (mcysys@xxxxxxx) and R. Kevin Oberman (oberman@xxxxxx).
Posted: Tue Jan 20 10:47:32 PST 1998
CKg |