2

I don't know much about DNS administration, etc, however I know about best practices in application programming.

Currently, in my company, we have 6 servers respectively named :

  • s1.domain.com
  • s2.domain.com
  • s3.domain.com
  • s4.domain.com
  • s5.domain.com
  • s6.domain.com

That's fine.

However, the sysadmin asked us to handle those random endpoint in our application, it means, that we need to pick randomly a server from within this list.

It looks bad to me, because whenever we need to add a server, we need to edit our application (even if it's just a config file), but I think application should not be aware of such things, similarly to entity should not know about persisting server.

My though is to use a dns load balancing, one domain, pointing to different ip

One endpoint: mobile.domain.com

The sysadmin told me that's bad or something like that, but I'm convinced it's the best solution, more it'll allow later geolocalisation load balancing which is great. By the way, randomly pick a server from a list won't prevent the server to shutdown since random is, just not random, and doesn't look efficient for me.

Thank you for your feedback, if you have arguments pro & cons I can use : )

voretaq7
  • 79,879
  • 17
  • 130
  • 214
JohnT
  • 145
  • 1
  • 1
  • 4

3 Answers3

2

I think what your Sysadmin was trying to say was that using DNS for load balancing is not bad but inconvenient. You can add 6 IP to the DNS for a particular domain but it becomes hard to manage the cluster. If you want to take one of the machines out of the rotation you would have to edit your DNS record and wait for it to propagate. That can be handled by setting a lower TTL but you can't account for any intermediate resolvers which don't follow DNS protocol.

Its more convenient to have a load balancer and point the domain to the LB and but the 6 servers behind it. It allows one to add/remove servers because you don't have to worry about DNS propagation time.

Sameer
  • 4,118
  • 2
  • 17
  • 11
  • ok thank you for your answer, I totally understand your arguments. However _edit your DNS record and wait for it to propagate_ that's true, but if a server is down or should be shutdown, it is not more convenient than doing it programmatically in my application, it doesn't resolve anything imo. However your idea about pointing the domain to the LB seems the best solution. – JohnT May 06 '11 at 09:52
1

DNS round robin is generally accepted as a very low cost solution to load balancing. It is true that it requires manual changes to the DNS in the case of a server becoming unavailable. It is also true that your DNS changes need time to propagate (and that this depends on intermediate resolvers).

On the other hand it is very cheap, compared to the cost of a proper load balancer. There is also the question of complexity. There are open source solutions for load balancing, but they are not simple to set up and if something goes wrong, you (or your sysadmins) need to have the expertise to fix it. Updating a DNS zone is a comparatively simple thing to do.

Unless you have a situation where availability of the service is absolutely crucial or failing requests (due to DNS delays) result in severe loss of income, your best bet is DNS round robin.

In order to anwser the question of what kind of load balancing you need, you need to establish the cost of failing requests.

In any case, changes to the application, be it code or config files, is not a good idea, since this introduces even longer delays (in propagating the application changes).

wolfgangsz
  • 8,847
  • 3
  • 30
  • 34
  • I totally agree with your answer, thank you, I hope my sysadmin will understand your last point as it the one we diverge. I actually don't think application shouldn't be aware of such informations – JohnT May 06 '11 at 10:51
0

Whilst what Sameer and wolfgangsz say is true for round-robin, they've understated the problems with what is really a useless mechanism, and missed several problems that will cause you grief, including DNS-client and resolving-DNS-proxy caching and lack of order preservation guarantees in the journey from content DNS server to DNS client.

As mentioned, SRV resource records address all of these problems. You get a priority and a weighting, that caching in proxy DNS servers does not destroy. Administrators can, with them, do things that you'll probably end up wanting to do down the road such as set up fallback and primary server groups, specify fallback order, and control weights withing a single server group. Writing the client code to pick the server to talk to using the given weights and priorities isn't terrifically difficult, either.

Depending from who is going to use your applications, just you or the world at large, you may have to register your protocol name (used in the SRV resource record domain names) with registries such as this one. As you can see, other people already have.

As Sameer also said, a real load balancer is another, also preferable, alternative to the useless round-robin shuffling.

JdeBP
  • 3,990
  • 18
  • 17