North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: DNS Based Load Balancers

  • From: Matt Ghali
  • Date: Tue Jul 04 20:29:11 2006


On Tue, 4 Jul 2006, Sam Stickland wrote:


We work with a couple of different technologies here - our own GSS's, cache
farms and also external CDNs (for overflow). This is currently and area that
is currently under evaluation for a quite significant expansion.

Are you able to give some kind of description as to the problems you
experienced whilst using your own appliances? It would be very useful to be
able to avoid making the same mistakes.

From my experience with F5's GSLB product 3dns, my issues with
geographic load balancing via an appliance can be reduced to the criteria they have available to decide what answer to give a query.

- Pings and traceroutes are both subject to rapid state change. Paths and latencies change for a number of reasons not related to network proximities. Traceroute hops in particular are a terrible metric to use in judging proximity, as it could be very easy for a 14-hop path inside the US to trump a 4-hop transatlantic path. Pings/traceroutes also take a long time, and are only valuable for repeat queries from the same client, dumping the first on some default pool. Not so load balanced.

- BGP aspath length. This is actually probably the 'best' data that a geopraphical load balancing system can use. The data is detailed and metrics for any inbound connection are already in the 'db'. However, expecting a corporate IT or ops department to configure bgp peering on their load balancer is probably expecting a bit much. To the best of my knowledge, no appliance uses aspath length.

- Maps of RIR allocations and their geographic locations. OK. I can see how these might be useful for balancing traffic roughly across global regions, but the lack of granularity makes this a somewhat elaborate way to skin this particular cat. Also, we all know how well RIR allocation corresponds to actual location in the real world. At work, I am pleasantly surprised by 'geolocation' tools that claim my office in Redwood City is actually in Washington DC or London.

If you're looking to distribute traffic across several data centers, across many geographic regions, why not anycast a set of auth nameservers, with each pointing at their own data center in answers? This solution probably gives you a better 'correct' hit rate than any commercial appliance, and can be implemented yourself, or with the help of a commercial provider who specializes in this sort of thing. No vendor lock-in, no arm and a leg for a substandard PC in a rack mount case. (but you dont get the big fancy logo either)

matto

[email protected]<darwin><
  Moral indignation is a technique to endow the idiot with dignity.
                                                - Marshall McLuhan