DNS RR offers at least some measure of protection in case the whole data 
center loses its connection(s) to the world, which happens from time to time. 
Of course, if you have another data center to fall to. ;)

So ideally you would have keepalived-like solution inside each data center, 
but DNS RR if you deploy your solution to multiple data centers.

Anze


On Thursday 06 January 2011, Angelo Höngens wrote:
> Round robin is not the same as random.
> 
> If a host name has 4 A records, then most DNS servers (if not all) will
> return it round-robin. So first a.a.a.1, then a.a.a.2, then a.a.a.1, then
> a.a.a.2, etc.. Of course there are multiple dns servers involved and
> thousands of clients over the world, but in the end we almost always get a
> perfect 25-25-25-25 balancing.
> 
> > -----Original Message-----
> > From: David [mailto:da...@silveregg.co.jp]
> > Sent: donderdag 6 januari 2011 9:45
> > To: haproxy@formilux.org
> > Subject: Re: Haproxy failover: DNS RR vs Virtual IP (heartbeat,
> > keepalived)
> > 
> > On 01/06/2011 05:01 PM, Angelo Höngens wrote:
> > > (sorry for top posting, damn Outlook)
> > > 
> > > Just to second Willy's story, this is how a lot of people do it,
> > 
> > including us. We use pacemaker for high availability, and dnr rr for
> > loadbalancing.
> > 
> > > For example we have a 4-node cluster running varnish and haproxy. In
> > 
> > this case I have 4 virtual ipv4-addresses and 4 virtual ipv6 addresses
> > on the cluster. We use pacemaker to keep the virtual ip's up, and we
> > use dns round-robin to balance the load. We get nice equal load
> > balancing this way, and if a node is down (or I want to do
> > maintenance), the vip's move to other nodes, and they take the extra
> > load.
> > 
> > 
> > Thanks for the information. Both Willy and you refer to DNS RR as a
> > load
> > balancing solution, but I don't really understand that point: if
> > caching, etc... means hostname->load balancer resolution is random, the
> > load balancing will likely be very unbalanced, no ?
> > 
> > cheers,
> > 
> > David


Reply via email to