Multihomed server for backup & load balancing

Nate Duehr nate at natetech.com
Fri Feb 16 07:07:02 UTC 2001


On Thu, Feb 15, 2001 at 04:56:30PM -0500, Kevin Darcy wrote:

> I think you'll find that *most* clients will eventually fail over, but
> the failover timeout will vary from client platform to client platform.
> Of course, if a client is lucky enough to get the live address first in
> the address list, then there's not timeout at all.
> 
> One huge advantage of something like Local Director or BGP4 (I assume
> that's what you meant; I've never heard of "MGP4") is that they eliminate
> the timeout completely. Also, the higher-end products allow you present a
> whole farm of servers as a single address and to dynamically shift the
> traffic between them as load conditions change. They are therefore a much
> more elegant solution than plain old DNS "round-robin", although often
> very expensive...

Kevin, this sounds like you have personal experience with the
LocalDirector.  You have me curious now.  Does the Cisco LocalDirector
properly load-balance DNS traffic against multiple real servers?  Seems
like it would be rather interesting to get this to work.

Now you have me wanting to go read through the documentation on my
employer's load-balancer du jour, the Alteon to see if they do this or
not.

Other questions I would have would be are the real servers on
non-routable IP addresses (10.x.x.x, etc.) or real IP's behind a NAT in
the load-balancer.  Seems like the servers themselves would be quite
confused by having private-side addresses and this would cause a number
of problems with doing recursion from them -- the replies may not get
back to them from other nameservers if the NAT isn't done right.

Now you have me REALLY curious.  I'm going to have to grab a notebook
and pen and draw up a few hypotheticals about how this might (not) work.

-- 
Nate Duehr <nate at natetech.com>

GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2
Public Key available upon request, or at wwwkeys.pgp.net and others.


More information about the bind-users mailing list