DNS Based Load Balancers

David Temkin dave at rightmedia.com
Mon Jul 3 00:55:53 UTC 2006


The problem being that most of what you linked to below is either A) out
of date, or B) the only way to get proximity based load balancing (GSLB
type stuff) with them is with DNS tricks.  

Breaking it down in order:

 The IBM solution hasn't been updated since 1999.  It also seems
relatively proprietary.

 The Cisco solution relies on either doing HTTP redirects (which is
useless if you're not doing HTTP) or DNS.   

 Both Foundry and Radware rely 100% on DNS to do their GSLB.  You can do
local load balancing on both boxes   	without, however.

 The last link is an outdated thesis paper that makes reference moreso
to local load balancing and not global.

It seems that in lieu of a real, currently produced solution, the only
option is presently DNS to meet the requirements.  Others have sent me
off-list stuff they're working on, but none of it's ready for prime
time.  


-Dave

> -----Original Message-----
> From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On 
> Behalf Of Paul Vixie
> Sent: Sunday, July 02, 2006 2:03 PM
> To: nanog at merit.edu
> Subject: Re: DNS Based Load Balancers
> 
> 
> dave at rightmedia.com ("David Temkin") writes:
> 
> > So, you guys have been pretty clear on what he shouldn't do.
> > 
> > What should he do as an alternative to using DNS for a 
> proximity based 
> > solution?
> 
> http://www.redbooks.ibm.com/redbooks/pdfs/sg245858.pdf
> http://www.cisco.com/univercd/cc/td/doc/product/iaabu/distrdir
> /dd2501/ovr.htm
> http://www.radware.com/content/products/library/faq_wsd.pdf
> http://www.foundrynet.com/solutions/appNotes/GSLB.html
> http://www.ifi.unizh.ch/ifiadmin/staff/rofrei/DA/DA_Arbeiten_2
000/Masutti_Oliver.pdf
> 
> note that several of these describe or offer a dns-based 
> solution as an option, but they all describe session-level 
> redirection and most recommend that (as i
> do) and some even say "using dns for this is bad" (as i do, 
> but for different
> reasons.)
> --
> Paul Vixie
> 



More information about the NANOG mailing list