Multiple data centers and HTTP traffic: DNS Round Robin is the ONLY way to assure instant fail-over?

Solution 1:

When I use the term "DNS Round Robin" I generally mean in in the sense of the "cheap load balancing technique" as OP describes it.

But that's not the only way DNS can be used for global high availability. Most of the time, it's just hard for people with different (technology) backgrounds to communicate well.

The best load balancing technique (if money is not a problem) is generally considered to be:

1. A Anycast'ed global network of 'intelligent' DNS servers,
2. and a set of globally spread out datacenters,
3. where each DNS node implements Split Horizon DNS,
4. and monitoring of availability and traffic flows are available to the 'intelligent' DNS nodes in some fashion,
5. so that the user DNS request flows to the nearest DNS server via IP Anycast,
6. and this DNS server hands out a low-TTL A Record / set of A Records for the nearest / best datacenter for this end user via 'intelligent' split horizon DNS.

Using anycast for DNS is generally fine, because DNS responses are stateless and almost extremely short. So if the BGP routes change it's highly unlikely to interrupt a DNS query.

Anycast is less suited for the longer and stateful HTTP conversations, thus this system uses split horizon DNS. A HTTP session between a client and server is kept to one datacenter; it generally cannot fail over to another datacenter without breaking the session.

As I indicated with "set of A Records" what I would call 'DNS Round Robin' can be used together with the setup above. It is typically used to spread the traffic load over multiple highly available load balancers in each datacenter (so that you can get better redundancy, use smaller/cheaper load balancers, not overwhelm the Unix network buffers of a single host server, etc).

So, is it true that, with multiple data centers and HTTP traffic, the use of DNS RR is the ONLY way to assure high availability?

No it's not true, not if by 'DNS Round Robin' we simply mean handing out multiple A records for a domain. But it's true that clever use of DNS is a critical component in any global high availability system. The above illustrates one common (often best) way to go.

Edit: The Google paper "Moving Beyond End-to-End Path Information to Optimize CDN Performance" seems to me to be state-of-the-art in global load distribution for best end-user performance.

Edit 2: I read the article "Why DNS Based .. GSLB .. Doesn't Work" that OP linked to, and it is a good overview -- I recommend looking at it. Read it from the top.

In the section "The solution to the browser caching issue" it advocates DNS responses with multiple A Records pointing to multiple datacenters as the only possible solution for instantaneous fail over.

In the section "Watering it down" near the bottom, it expands on the obvious, that sending multiple A Records is uncool if they point to datacenters on multiple continents, because the client will connect at random and thus quite often get a 'slow' DC on another continent. Thus for this to work really well, multiple datacenters on each continent are needed.

This is a different solution than my steps 1 - 6. I can't provide a perfect answer on this, I think a DNS specialist from the likes of Akamai or Google is needed, because much of this boils down to practical know-how on the limitations of deployed DNS caches and browsers today. AFAIK, my steps 1-6 are what Akamai does with their DNS (can anyone confirm this?).

My feeling -- coming from having worked as a PM on mobile browser portals (cell phones) -- is that the diversity and level of total brokeness of the browsers out there is incredible. I personally would not trust a HA solution that requires the end user terminal to 'do the right thing'; thus I believe that global instantaneous fail over without breaking a session isn't feasible today.

I think my steps 1-6 above are the best that are available with commodity technology. This solution does not have instantaneous fail over.

I'd love for one of those DNS specialists from Akamai, Google etc to come around and prove me wrong. :-)

Solution 2:

Your question is: "Is DNS Round Robin the ONLY way to assure instant fail-over?"

The answer is: "DNS Round Robin is NEVER the right way to assure instant fail-over".

(at least not on its own)

The right way to achieve instant fail-over is to use BGP4 routing such that both sites use the same IP addresses. Using this the internet's core routing technologies are used to route the requests to the right data center, instead of using the internet's core addressing technology.

In the simplest configuration this only provides fail-over. It can also be used to provide Anycast, with the caveat that TCP based protocols will fail at the moment of switch-over if there is any instability in the routing.

Solution 3:

So, is it true that, with multiple data centers and HTTP traffic, the use of DNS RR is the ONLY way to assure high availability?

Clearly it is a false claim - you have only to look at Google, Akamai, Yahoo, to see that they're not using round-robin[*] responses as their sole solution (some may use it in part, along with other approaches.)

There are many possible options, but it really depends upon what other constraints you have, with your service/application as to which you pick.

It is possible to use round-robin techniques on a simple, co-located server approach, and not have to worry about server failure, if you also arrange for the 'fail-over' of the IP address. (But most opt for load-balancing techniques, a single IP address, and fail-over between load-balancers.)

Maybe you need all requests for a single session to go to the same servers, but you want requests to be spread across different, regional server clusters? Round robin is not appropriate, for that: you need to do something that ensures any given client accesses the same physical server cluster each time (except when 'exceptions' occur, such as server failure). Either they receive a consistent IP address from a DNS query, or get routed to the same physical server cluster. Solutions for that include various commercial and non-commercial DNS "load balancers", or (if you have more control of your network) BGP network advertisements. You could simply arrange for your own domain's nameservers to give entirely different responses (but, as DNS requests can get sent all over the place, you won't achieve any location affinity with that approach.)

[* I'm going to use "round-robin", because 'RR' in DNS terminology means "resource record".]

Solution 4:

Very nice observation vmiazzo +1 for you !! I'm stuck exactly where you are .. baffled with how these CDN do their magic.

Following are my guess on how CDN run their network :

• Use Anycast DNS (mentioned by Jesper Mortensen) to get the closest data centre
• They run a local network which span across different data centre which allow them to do something like CARP on their hosts across different data centre

Or

• They employ Gateway Load Balancing Protocol on their routers or Hot Standby Router Protocol (HSRP). which deal with datacenter outage.
• The reason they include multiple IP is so that client will retry , and by the time the client retry, routing path might have changed.

At the moment following solution work for me : - DNS return multiple IP, eg:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Last entry point to a reverse proxy at amazon cloud, which intelligently pass to available server (or provide under maintenance page)

Reverse proxy still get hit but bot as heavy as main one.