How to Enhance Round Robin DNS Load Balancing?

Question

This is form further to my question at Old Question. Following to the suggestion in the answer I got this text here

The DNS based load balancing method shown above does not take care of various potential issues such as unavailable servers (if one server goes down), or DNS caching by other name servers. The DNS server does not have any knowledge of the server availability and will continue to point to an unavailable server. It can only differentiate by IP address, but not by server port. The IP address can also be cached by other nameservers, hence requests may not be sent to the load balancing DNS server.

Now I am thinking out of the box, Does these exists some way to deal with potential issues?

Answer 1

The answer you've quoted is wrong.

such as unavailable servers (if one server goes down)

If the user makes a subsequent request after one fails (times out) the resolver on the client should automatically switch to the next entry in the list.

or DNS caching by other name servers

When a DNS server receives multiple records for a name it should cache all of them or none. When it receives a request for a cached name with multiple records, in the absence of other instructions it should return the entire list in a (pseudo)random order.

No standard solution exists for recovering a HTTP request which fails (although it is possible to build such capability into the application layer) due to the risk of replaying the same transaction twice.

The only issue with round-robin is the time taken for the client to detect a failure. And this can easily be addressed by implementing a local address take over on the cluster when a node becomes unavailable.

Answer 2

Don't use DNS to do your load-balancing, and use some real load balancing software or hardware that will specifically take care of what you want.

There are some DNS services & software out there that will monitor servers and issue appropriate responses based on whatever parameters you want, but given DNS caching, and that this isn't really the purpose of DNS - it's really not what you want.

Answer 3

it really depends on what your architecture looks like and what type of application you plan to load balance. (A) the architecture: 1. same network segment: using haproxy or relayd can be a good start. it is also possible to do tcp load balancing directly within the firewall (e.g. PF on free|open bsd) but see (B) 2. servers spread world-wide: concentrating the incoming requests into one access point to handle the balancing logic could work but you probably want to think about using DNS RR and replicate the balancing logic at each node level (B) the type of application 1. static content delivery only, not data-driven, no sessions (stateless): you can safely use DNS RR with a low TTL (can be set to zero). The browser will try to connect to the next ip address if previous fails 2. dynamic content, data-driven (database backend), stateless: you should think either data-partitioning or data replication. You can still use DNS round robin. If a node fails you will loose only part of data when partitioning is used or no data lost at all when replicating. The logic gets complicated on maintaining a hot backup for the master data node. 3. stateful applications: if you need to maintain sessions you will need to do the request routing at session level. You should use haproxy. Or you can fully replicate your user sessions to all servers. Or partition the sessions (e.g. in memcached) and have your session manager transparently lookup the user session properly one one of the servers.

node failures: both haproxy and relayd can take care of removing dead nodes from the server pool. for tcp/dns balancing you should add external logic for maintaining a good list of workers. There's no straight answer on how to do load balancing the right way. It totally depends on the environment and applications.

Answer 4

RR-DNS is only good for distributing the load, not load balancing.