Load balancing - Multiple servers, different locations

Question

I've been scaling out a service very rapidly, and have found a problem in the way I've been balancing the load. My servers do not need a perfectly even distribution, so I was simply using a round robin DNS setup to direct clients to the servers.

However, it is very important that a client not be bounced between servers, and I've found that many of the clients running their software on Ubuntu do NOT cache the DNS result they receive, so they are constantly changing which server they communicate with.

Is there any way to force a DNS record to stick to them, or will I have to begin looking at a software or hardware load balancer? My concern is the latency of a load balancer. If the LB is in the US and the client is directed to the UK, my understanding is the client will always have to connect to the US load balancer before being redirected to the UK.

Answer 1

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:

1. User requests www.yourdomain.com.
2. Server handling www.yourdomain.com looks up geographic area of user.
3. Server determines that user is in the US.
4. Server redirects user to us.yourdomain.com.
5. 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.

Answer 2

Sticky sessions suck!

While it may be inconvenient that users get sent around various machine, one of the main reasons for using RRDns is for availability. If you need to keep your users on the same server then you loose the benefits.

Certainly pushing users preferentially to a nearby server delivers good performance benefits - most large DNS providers now offer geo-aware DNS lookups (without the expense of a full content delivery network). And if you're feeling brave and do your own name serving, then you can configure bind to do it for you. Note that with normal RRDNS, the hosts are served up in a random order by the nameserver - it's quite possible to have a failover config where the 'local' servers are always presented in the same order to the same clients along with a failover list which always appears at the end.

A lot of what is appropriate depends on the scale you are working at. If you're confident that you've got good availability within each datacenter, then using a local load balancer at each datacenter might be the way to go (checkout HA-Proxy and Varnish).

Answer 3

Round robin DNS resource record set shuffling doesn't do what you think it to do, and doesn't do what you want. Use SRV resource records or a proper load balancer.