WebPagetest on EC2

[andrewa]

(10-29-2010 03:11 AM)pmeenan Wrote:  

(10-29-2010 02:02 AM)andrewa Wrote:  I just wanted to throw out my thanks to everyone contributing -- it's amazing how straightforward it already is to get servers up and running. I'm running a combination of servers on Amazon EC2 and Rackspace CloudServer to get some better regional representation (though still working on having some ability to determine which data center the Rackspace instance comes up in).

I wanted to add an insight that may apply to some users that depend on distributed CDNs. One caveat I've encountered with Amazon is that the DNS servers used end up making requests that appear to served out of Seattle. The CDN I use has POPs (Points of Presence) in most major cities, but when using the Amazon US East nodes, they still end up using CNAMEs pointing at the CDN POPs located in Seattle rather than on the east coast. The Rackspace servers I run correctly resolve our CNAMEs to point at POPs near to the data center as I would expect.

The workaround that I'm using is to manually override the DNS settings on the EC2 instance, and have the first DNS server point at a public DNS (such as OpenDNS) and the second pointing at the originally assigned DNS (just in case there's a need for it)

-andrew

FWIW, I have some public EC2 AMI's configured that I'm doing some testing with. If it all looks good I'll make them available for people to use. I have enhanced URLBlast to auto-configure itself based on user data so the AMI's can come right up and start testing.

For the CDN issue, did you tracert to the IP's or were you trusting WebPagetest's IP lookup (it tends to not be all that reliable with CDN POP's). Which CDN provider?

Amazon's DNS servers should be anycast and available in each data center so it would largely be the CDN provider's problem to geo-locate them correctly. Switching to Google DNS might be an option but there was a thread earlier on how Akamai has problems geo-locating through Google's DNS.

Thanks,

-Pat

Thanks for the response. I was using nslookup, actually, which should be accurate for the response. We're using Internap's CDN product, which should geo-locate correctly.

Here's the output from nslookup, the first using the DNS provided via DHCP, and the second using OpenDNS, the third using Google DNS.

Code:

C:\Users\Administrator>nslookup www.cozi.com. 172.16.0.23
Server:  ip-172-16-0-23.ec2.internal
Address:  172.16.0.23

Non-authoritative answer:
Name:    cdce.sef004.internap.com
Address:  64.94.126.65
Aliases:  www.cozi.com
          cozicorp.http.internapcdn.net
          http.sef004.internap.com

C:\Users\Administrator>nslookup www.cozi.com. 208.67.222.222
Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
Name:    cdce.wdc007.internap.com
Address:  69.88.152.250
Aliases:  www.cozi.com
          cozicorp.http.internapcdn.net
          http.wdc007.internap.com

C:\Users\Administrator>nslookup www.cozi.com. 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    cdce.wdc007.internap.com
Address:  69.88.152.250
Aliases:  www.cozi.com
          cozicorp.http.internapcdn.net
          http.wdc007.internap.com

The instance is running in US-East, so the Washington, DC (WDC) lookup in the second and third case is what I would expect. The Seattle (SEF) lookup in the first, seems wrong.