Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Répartition de charge de niveau DNS

Répartition de charge de niveau DNS

Principe

La répartition de charge de niveau DNS intervient dans l’association d’une adresse IP à un nom de serveur.

Lorsque le navigateur doit accéder à un serveur dont il connaît le nom, par exemple www.smile.fr, il commence par rechercher l’adresse IP correspondant à ce serveur www sur le domaine smile.fr, en adressant une requête à son serveur DNS, qui lui-même, s’il ne dispose pas de l’information, interrogera d’autres serveurs DNS, de manière récursive. Une fois que le poste client a obtenu l’adresse IP, il la conserve en cache selon différentes règles, généralement de l’ordre d’une demi-heure.

C’est dans cette phase d’association entre un nom de serveur et une adresse IP, c’est à dire un serveur, qu’intervient la répartition de charge de niveau DNS, simplement en fournissant différentes adresses IP pour un même nom de serveur.

On utilise assez peu cette technique pour répartir la charge entre serveurs d’un même datacenter, simplement parce que les répartition réseau, que nous verrons plus loin, sont plus flexibles et plus réactives.

La répartition de niveau DNS est donc plutôt utilisée pour répartir la charge entre plusieurs datacenters.

Quelle en est la finalité ?

  • La tolérance aux pannes : un datacenter peut se trouver globalement indisponible, pour différentes raisons, et toutes les mesures internes à la plateformes seront alors inopérantes.
  • La proximité physique des internautes, dans une approche de type « Content Delivery Network ».
  • La recherche d’un point d’équilibre entre mesures de haute-disponibilité internes à une plateforme, et haute-disponibilité globale multi-plateformes, pour viser une haute-disponibilité globale au moindre coût.

Nous passerons en revue trois types de solutions de répartition de niveau DNS : DNS Round-Robin, GeoDNS et Anycast.

La première est la seule qui soit totalement standard, compatible avec n’importe quel DNS ; les deux suivantes requièrent un serveur DNS spécifique et sont donc sensiblement plus complexes à mettre en œuvre.

DNS-Round-Robin

La technique de répartition DNS la plus simple et la plus couramment utilisée est celle du DNS Round-Robin, ou DNS-RR.

Lorsqu’un serveur DNS répond à un client, il peut fournir non pas une adresse IP, mais une liste d’adresses IP, dans un certain ordre. La première adresse est celle qu’il faut utiliser en premier lieu, les autres sont des adresses de secours. Si l’on dispose de trois serveurs S1, S2, S3 capables de traiter les requêtes, alors le serveur DNS pourra répondre { S1, S2, S3 }, dans cet ordre. Rappelons qu’ici Si désigne l’adresse IP d’un serveur. Le principe du DNS-RR consiste à répondre en indiquant les serveurs en permutation circulaire : {S1, S2, S3 }, puis {S2, S3, S1 }, puis {S3, S1, S2 } et ainsi de suite. Le premier client, s’adressera donc à S1, le second à S2, le troisième à S3. Et si S1 ne répond pas, alors le premier s’adressera à S2 en secours.

Cette technique a le mérite d’être très simple à mettre en œuvre, et ne requiert pas un DNS spécifique, le Round-Robin est supporté par tous les serveurs DNS de l’Internet, il n’y a qu’à demander. La solution peut convenir lorsqu’on dispose de 2 ou 3 datacenters d’une même région géographique, d’un même continent. Elle convient beaucoup moins bien au niveau global, avec des datacenters sur différents continents, car elle peut amener l’internaute européen sur un datacenter asiatique, l’internaute américain sur un datacenter européen, et ainsi dégrader la qualité de service de tout le monde. On a vu déjà qu’à l’échelle de la planète la proximité géographique a un impact important sur la qualité de service.

La répartition par DNS-RR est assimilable au global à une répartition aléatoire. En particulier, elle ne s’appuie sur aucune connaissance de la charge respective des serveurs. Néanmoins, avec un trafic important, l’aléatoire procure une répartition tout à fait satisfaisante, avec des écarts en général de moins de 5% entre les serveurs.

On met en œuvre également le DNS-RR lorsqu’on vise un hébergement low-cost, qui ne permet pas d’insérer de load-balancer.

GeoDNS

Au lieu de répondre en permutation circulaire, le serveur DNS peut essayer de répondre intelligemment, en fournissant en premier le serveur le plus proche de l’internaute, après avoir localisé l’internaute, au moyen de son adresse IP. C’est l’objet de l’extension GeoDNS, qui ajoute cette fonctionnalité au serveur BIND, le DNS plus utilisé sur l’Internet.

Bien entendu, cela suppose de gérer son propre DNS sur son domaine.

L’extension GeoDNS permet de définir, pays par pays, la réponse spécifique du DNS à une demande de l’internaute, et donc de répondre { SFR, SUS, SKR } a un internaute européen, et { SKR, SUS, SEU } à un internaute chinois, où SFR, SUS, SKR sont les adresses des serveurs hébergés respectivement en France, Etats-Unis et Corée du Sud.

C’est donc une solution qui convient bien au niveau global.

image050

Anycast

La dernière solution, utilisée par les plus grands sites globaux, s’appelle « Anycast ». Elle consiste à utiliser la même adresse IP pour différents serveurs DNS en charge du domaine, chaque serveur étant hébergé sur le même datacenter que l’une des plateformes web. Ainsi si l’on dispose de trois plateformes dans trois datacenters, en Europe, Asie et Amérique, on mettra en place trois DNS pour mondomaine.com, sur ces mêmes plateformes.

Comme ces trois serveurs DNS partagent la même adresse IP, on compte sur les algorithmes de routage IP pour trouver automatiquement le serveur DNS le plus proche de l’internaute. Chaque DNS répond à la requête de nom de domaine de manière légèrement différente, en plaçant l’IP de son propre datacenter en tête de liste.

Le génie de cette solution, c’est de trouver de manière naturelle le serveur le plus proche, au sens de la topologie de l’Internet, et non au sens géographique, en utilisant les mécanismes standards du réseau.

Partager une adresse IP est en général hasardeux, et effectivement, dans une connexion TCP/IP, il se pourrait que certains paquets arrivent à un serveur et d’autres à un autre serveur, ce qui rendrait la communication impossible. Mais l’interrogation DNS n’utilise que le protocole UDP, qui est sans session, de sorte qu’il est compatible avec le mode Anycast.

Avantages et limites de la répartition DNS

Comme on l’a vu, la répartition de niveau DNS, quel qu’en soit l’outil, est pratiquement la seule qui permette de répartir sur différents datacenters, ce qui permet à la fois une meilleure tolérance aux pannes, et dans certains cas une moindre latence donc une meilleure qualité de service.

Dans le mode Round-Robin, elle est très facile à mettre en place, et peu coûteuse, pour autant que l’application soit compatible, c’est à dire qu’elle ne suppose aucune ressource partagée, un « share nothing » de niveau datacenter.

Elle présente toutefois les limitations suivantes :

  • La gestion de la détection de panne et du secours est laissée à la charge du navigateur. Si le serveur HTTP répond une erreur 500, par exemple, le navigateur ne passe pas sur la seconde adresse.
  • L’équilibrage de la charge n’est pas géré de manière fine, typiquement avec des capacités d’accueil différentes selon les plateformes, ou bien l’affectation au datacenter le moins chargé.
  • Elle ne permet pas de mettre en œuvre l’affinité de serveur de manière satisfaisante.

A la différence des solutions de répartition de charge réseau, que l’on verra plus loin, la répartition de niveau DNS ne met pas en œuvre une surveillance des plateformes, et n’adapte pas la répartition à la disponibilité ou à la charge.

Notons qu’il existe malgré tout quelques solutions gérant la haute-disponibilité au travers d’une reconfiguration DNS : on met en œuvre un monitoring des différents serveurs, et si l’un d’entre eux ne répond pas, on met à jour les DNS pour exclure ce serveur.

Tant qu’on utilise les DNS de manière standard, c’est le cas pour le mode round-robin, la tolérance aux pannes du dispositif de répartition lui-même est excellente. En revanche, pour les deux autres modes, qui demandent un DNS spécifique, c’est à vous d’assurer son secours et sa disponibilité.

Redirection applicative

Il faut évoquer aussi la possibilité de redirection applicative, vers un serveur ou un datacenter proche de l’internaute. C’est une version très rustique du GeoDNS : l’internaute se connecte à un premier serveur www.smile.fr, l’application localise l’internaute, en déduit le serveur le plus approprié, et adresse un redirect HTTP vers ce serveur, par exemple www-us.smile.fr, qui assurera la suite de la session.