3

We would like to mirror our site in the UK and the US for two reasons. So that...

  1. The site is fast for users located in either America/Europe.
  2. So that if either server goes down, the user can still access the website.

As for data sharing between the servers, we're going to use MySQL mirroring, and probably rsync to keep the files mirrored.

If we only needed to do point 1, then we could program some code to redirect users to either site based on their IP, but to do this, we'd have a single point of failure.

Is there a reasonably inexpensive way of telling users a different IP based on their location? Maybe we can do something fancy with our DNS server?

Nick Bolton
  • 5,016
  • 12
  • 51
  • 62

2 Answers2

1

"High Availability" is always fun :-)

On the "simple" side, you can specify multiple A records. This works in a (typically) round-robin style, and offers no ability to specify which server you want to serve by default. This means that you'll wind up with people in Britain getting served by the American servers, and vice versa. This is not what you want (least of all because we Americans get confused by all of the extra 'u's that show up in words like colour) ;-)

A more sophisticated solution would be using a DNS service that uses a feature similar to the one that you suggested in the comments. A technique exists called Global Service Load Balancing as well, which accomplishes something similar.

On the more expensive and sophisticated side, you could use BGP MultiSite MultiHoming, where you buy an Autonomous System Number (ASN), and advertise BGP routes to the same network from both sites. This theoretically ensures that everyone gets the "closest" (based on network accessibility) site.

Or, of couse, you can hire Akamai to distribute your data and applications for you. For a lot of money.

If you've got the money and expertise, I'd recommend the BGP multihomed solution. If not, you might want to look at the DNS solutions.

Matt Simmons
  • 20,218
  • 10
  • 67
  • 114
0

As Matt says, there are companies which will provide CDNs.

A cheaper approach would be to use RRDNS, with 

www.example.com   A (UK address)
www.example.com   A (US address)

uk.www.example.com A (UK address)
uk.www.example.com A (UK address)
uk.www.example.com A (UK address)
...
uk.www.example.com A (US address)

us.www.example.com A (US address)
us.www.example.com A (US address)
us.www.example.com A (US address)
...
us.www.example.com A (UK address)

And on both servers, try to drop a cookie (if there's not one) indicating which continent the client is on (saves repeated expensive lookups).

Maintain the state of the 'other' system(s) in each server. When you get a connection on the www.example.com address, redirect to the most local system for the customer which is available (e.g. uk.www.example.com).

On the localised vhosts (uk. and us.) whenever a GET request comes in, if it is for a non-local vhost, check if the prefered host at that location is available, and redirect the customer there.

You'd probably want to implement better failover detection (avoiding split-brain) and detect looping between servers not to mention other tweaks.

Its not perfect and relies a lot on you coding your own redirect / failover handling.

A more practical solution might be to implement your own location-sensitive DNS server alternatively, there are a small, but growing number of DNS providers who can provide just such a service (again use RRDNS with lots of repeated local A and few remote A records).

C.

symcbean
  • 19,931
  • 1
  • 29
  • 49