Jeff, I disagree, load balancing does not imply redundancy, it's quite the opposite in fact. The more servers you have, the more likely you'll have a failure at a given instant. That's why redundancy IS mandatory when doing load balancing, but unfortunately there are a lot of solutions which only provide load balancing without performing any health check, resulting in a less reliable service.
DNS roundrobin is excellent to increase capacity, by distributing the load across multiple points (potentially geographically distributed). But it does not provide fail-over. You must first describe what type of failure you are trying to cover. A server failure must be covered locally using a standard IP address takeover mechanism (VRRP, CARP, ...). A switch failure is covered by resilient links on the server to two switches. A WAN link failure can be covered by a multi-link setup between you and your provider, using either a routing protocol or a layer2 solution (eg: multi-link PPP). A site failure should be covered by BGP : your IP addresses are replicated over multiple sites and you announce them to the net only where they are available.
From your question, it seems that you only need to provide a server fail-over solution, which is the easiest solution since it does not involve any hardware nor contract with any ISP. You just have to setup the appropriate software on your server for that, and it's by far the cheapest and most reliable solution.
You asked "what if an haproxy machine fails ?". It's the same. All people I know who use haproxy for load balancing and high availability have two machines and run either ucarp, keepalived or heartbeat on them to ensure that one of them is always available.
Hoping this helps!
Unfortunately, there is no way to force a DNS record to stick to a particular user. A load balancer could track a user's session and always send them to the same server. However, it seems that you're running into issues with geographically separated application instances.
In this case, your best bet would to have the following setup:
- Have a subdomain for each geographic area you want to represent that contains the IPs for servers in that area. us.yourdomain.com and uk.yourdomain.com
- Have a web server handling the www.yourdomain.com record, or whatever users typically type in, that utilizes a Geographic lookup system (such as GeoIP) to redirect users to the appropriate subdomain.
Using this architecture, an initial HTTP request for a user in the US would look something like this:
- User requests www.yourdomain.com.
- Server handling www.yourdomain.com looks up geographic area of user.
- Server determines that user is in the US.
- Server redirects user to us.yourdomain.com.
- User's browser accepts redirect, and all subsequent requests go to us.yourdomain.com.
This setup will require a total of at least 3 servers. One handling US requests, one handling UK requests, and one that handles redirecting users to the US/UK sites.
Best Answer
Elastic Load Balancing gives you a CNAME as an endpoint. Here's an example:
As you can see, ELB works by providing a
.wherever.elb.amazonaws.com
domain name, with a low TTL. Amazon will then return you different DNS values for the ELB based on where you are coming from, and what backend servers are up. (I wrote a blog post on this topic once which I encourage you to read if you want more detail.)So, you can make
site.abc.com
or even*.abc.com
a CNAME to your.wherever.elb.amazonaws.com
address, and the name will be forwarded to the instances behind it as you would expect.aaa.com is trickier, as the zone apex (root name) cannot generally be a CNAME. The previous workaround was to point aaa.com to a single EC2 instance on an elastic IP, which you would re-map in the case of failure; however, Amazon recently released an addition to their Route 53 DNS service where they will set keep the DNS records for aaa.com in sync with what your ELB CNAME will return.