Plusieurs enregistrements A pointant vers le même domaine semblent être utilisés presque exclusivement pour implémenter DNS Round Robin en tant que technique d’équilibrage de charge peu coûteuse.
L'avertissement habituel contre DNS RR est qu'il n'est pas bon pour la haute disponibilité. Quand 1 IP tombe en panne, les clients continueront à l'utiliser pendant quelques minutes.
Un équilibreur de charge est souvent suggéré comme meilleur choix.
Les deux affirmations ne sont pas complètement vraies:
Lorsque le trafic est alors HTTP, la plupart des navigateurs HTML peuvent automatiquement essayer le prochain enregistrement A si le précédent est en panne, sans nouvelle recherche DNS. Lisez ici le chapitre 3.1 et ici .
Lorsque plusieurs centres de données sont impliqués, DNS RR est la seule option pour répartir le trafic sur eux.
Alors, est-il vrai que, avec plusieurs centres de données et le trafic HTTP, l’utilisation de DNS RR est le SEUL moyen d’assurer un basculement instantané en cas de panne d’un centre de données?
Merci,
Valentino
Modifier:
- Bien entendu, chaque centre de données dispose d'un équilibreur de charge local avec disque de secours.
- Vous pouvez sacrifier l'affinité de session pour un basculement instantané.
- D'après les informations dont je dispose, le seul moyen pour un DNS de suggérer un centre de données plutôt qu'un autre consiste à répondre uniquement avec l'adresse IP (ou les IP) associée à ce centre de données. Si le centre de données devient inaccessible, toutes ces adresses IP sont également inaccessibles. Cela signifie que, même si les navigateurs HTML intelligents peuvent essayer instantanément un autre enregistrement A, toutes les tentatives échouent jusqu'à ce que l'entrée du cache local expire et qu'une nouvelle recherche DNS soit effectuée, en récupérant les nouvelles adresses IP qui fonctionnent nouveau centre de données en cas d'échec). Ainsi, le "DNS intelligent" ne peut pas assurer un basculement instantané.
- À l'inverse, un tour de rôle DNS le permet. Lorsqu'un des centres de données tombe en panne, les navigateurs HTML intelligents (la plupart d'entre eux) testent instantanément les autres enregistrements A mis en cache en passant à un autre centre de données (opérationnel). Ainsi, le round-robin DNS n'assure pas l'affinité de session ou le RTT le plus bas, mais semble être le seul moyen d'assurer un basculement instantané lorsque les clients sont des navigateurs HTML "intelligents".
Edit 2:
- Certaines personnes suggèrent TCP Anycast comme solution définitive. Dans cet article (chapitre 6), il est expliqué que le basculement d’Anycast est lié à la convergence BGP. Pour cette raison, Anycast peut utiliser de 15 minutes à 20 secondes. 20 secondes sont possibles sur les réseaux où la topologie a été optimisée pour cela. Seuls les opérateurs CDN peuvent probablement accorder de tels basculements rapides.
Modifier 3: *
- J'ai fait des recherches DNS et des traceroutes (peut-être qu'un expert peut vérifier) et:
- CacheFly semble être le seul CDN utilisant TCP Anycast. D'autres opérateurs, tels que les réseaux CDN et BitGravity, utilisent CacheFly. On dirait que leurs bords ne peuvent pas être utilisés comme proxy inverse. Par conséquent, ils ne peuvent pas être utilisés pour accorder un basculement instantané.
- Akamai et LimeLight semblent utiliser un DNS géo-conscient. Mais! Ils renvoient plusieurs enregistrements A. De traceroutes semble que les adresses IP retournées sont sur le même centre de données. Je ne comprends donc pas comment ils peuvent proposer un contrat de niveau de service à 100% lorsqu'un centre de données tombe en panne.