dns based loadbalancing/failover

Christopher A. Woodfield rekoil at semihuman.com
Sun Oct 7 20:26:18 UTC 2001


Akamai hostnames do not map to specific customers; that information is 
part of the metadata that follows the hostname. Obviously, the customer ID 
and the source server must match or else no cachey cachey. :) The number 
in the hostname figures into Akamai's load balancing algorithm, IIRC.

What actually happens is a type of "mapping" that tries to nail down the 
network location of the source IP that's on the DNS query, and returns the 
IP of the cache server that's hopefully closest to that source IP.

Most of the time this works well, although it's not extremely precise; 
the most obvious caveat is that the source IP recorded is that of the 
DNS resolver, not the HTTP client. If your workstation on UUNet in Washington 
is configured to query a name server that's on, say, Level3's network in 
Seattle, Akamai's servers will use the latter location for this 
evaluation, with the obvious sub-optimal result.  But the majority of the 
time, it delivers the IP of a machine that's closer to the end user than the 
customer's server. And the customer gets the benefit of reduced outbound 
traffic and server load in any case.

It's particularly effective at my office, as my workstation is 4ms away 
from the Akamai server in our local data center. But my home DSL service, 
for which the other end of the PVC lives at the same site, is served by an 
Akamai server in Philadelphia. Go figure.

-Chris

On Sun, Oct 07, 2001 at 01:14:24AM -0400, Vivien M. wrote:
> 
> > -----Original Message-----
> > From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On 
> > Behalf Of Valdis.Kletnieks at vt.edu
> > Sent: October 7, 2001 1:05 AM
> > To: Mary Grace
> > Cc: nanog at merit.edu
> > Subject: Re: dns based loadbalancing/failover 
> > 
> > 
> > 
> > On Sat, 06 Oct 2001 16:44:57 EDT, Mary Grace said:
> > > Hrmm, no, that is called "Akamai", isn't it?  :)
> > 
> > There's an Akamai across the hall from my office, and the way 
> > it was explained to *me* was that the DNS always returns the 
> > same IP address for a given Akamai'zed page (so the URLs in 
> > the HTML are consistent), but routing games are used to 
> > direct the packets to the appropriate server.  In other 
> > words, it's one IP that points to disparate machines.
> 
> They lied to you (I don't remember who a96.g.akamai is; it's some
> well-known Akamai customer, maybe CNN):
> vivienm at quartz:~$ nslookup a96.g.akamai.net 
> Server:  quartz.bos.dyndns.org
> Address:  66.37.218.198
> 
> Non-authoritative answer:
> Name:    a96.g.akamai.net
> Addresses:  216.32.119.10, 216.32.119.74
> 
> vivienm at quartz:~$ nslookup a96.g.akamai.net amethyst.ith.dyndns.org
> Server:  amethyst.ith.dyndns.org
> Address:  216.7.11.130
> 
> Non-authoritative answer:
> Name:    a96.g.akamai.net
> Addresses:  207.127.111.70, 207.127.111.73
> 
> vivienm at nickel:~$ nslookup a96.g.akamai.net
> Server:  zinc.fmt.dyndns.org
> Address:  64.71.191.27
> 
> Non-authoritative answer:
> Name:    a96.g.akamai.net
> Addresses:  64.21.49.15, 64.21.49.36
> 
> vivienm at lapis:~$ nslookup a96.g.akamai.net
> Server:         212.100.224.10
> Address:        212.100.224.10#53
> 
> Name:   a96.g.akamai.net
> Address: 64.124.157.126
> Name:   a96.g.akamai.net
> Address: 64.124.157.91
> 
> [from my home box]
> 
> vivienm at deep:~$ nslookup a96.g.akamai.net
> Server:  proxy1.slnt1.on.wave.home.com
> Address:  24.112.33.4
> 
> Name:    a96.g.akamai.net
> Addresses:  65.163.234.8, 65.163.234.24
> 
> [from one of your DNS servers]
> vivienm at quartz:~$ nslookup a96.g.akamai.net milo.cns.vt.edu
> Server:  milo.cns.vt.edu
> Address:  198.82.247.98
> 
> Name:    a96.g.akamai.net
> Addresses:  198.82.164.48, 198.82.164.40
> 
> I'm sure I could keep going if you really wanted, but I think that's
> enough to prove the point...
> 
> Vivien
> 
> -- 
> Vivien M.
> vivienm at dyndns.org
> Assistant System Administrator
> Dynamic DNS Network Services
> http://www.dyndns.org/
> 

-- 
---------------------------
Christopher A. Woodfield		rekoil at semihuman.com

PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B



More information about the NANOG mailing list