Plusieurs centres de données et trafic HTTP : Le DNS Round Robin est le SEUL moyen d'assurer un basculement instantané ?

Les enregistrements A multiples pointant vers le même domaine semblent être utilisés presque exclusivement pour mettre en œuvre le DNS Round Robin comme technique bon marché d'équilibrage de la charge.

L'avertissement habituel contre le DNS RR est qu'il n'est pas bon pour la haute disponibilité. Lorsqu'une IP tombe en panne, les clients continuent à l'utiliser pendant plusieurs minutes.

Un équilibreur de charge est souvent suggéré comme un meilleur choix.

Ces deux affirmations ne sont pas totalement vraies :

1. Dans ce cas, lorsque le trafic est de type HTTP, la plupart des navigateurs HTML sont capables d'essayer automatiquement l'enregistrement A suivant si le précédent est en panne, sans nouvelle recherche DNS. Lire ici le chapitre 3.1 y ici .

2. Lorsque plusieurs centres de données sont concernés, le DNS RR est la seule option pour répartir le trafic entre eux.

Alors, est-il vrai qu'avec plusieurs centres de données et un trafic HTTP, l'utilisation de DNS RR est le SEUL moyen d'assurer un basculement instantané lorsqu'un centre de données tombe en panne ?

Merci,

Valentino

Editar:

• Bien entendu, chaque centre de données dispose d'un équilibreur de charge local avec un système de secours.
• Il n'y a pas de mal à sacrifier l'affinité de session pour un basculement instantané.
• AFAIK, la seule façon pour un DNS de suggérer un centre de données plutôt qu'un autre est de répondre avec seulement l'IP (ou les IP) associée(s) à ce centre de données. Si le centre de données devient inaccessible, toutes ces IP le sont également. Cela signifie que, même si les navigateurs HTML intelligents sont capables d'essayer instantanément un autre enregistrement A, toutes les tentatives échoueront jusqu'à ce que l'entrée dans le cache local expire et qu'une nouvelle recherche DNS soit effectuée, récupérant les nouvelles IP de travail (je suppose que le DNS suggère automatiquement un nouveau centre de données lorsqu'il échoue). Ainsi, le "DNS intelligent" ne peut pas garantir un basculement instantané.
• Inversement, un DNS round-robin le permet. Lorsqu'un centre de données tombe en panne, les navigateurs HTML intelligents (la plupart d'entre eux) essaient instantanément les autres enregistrements A en cache qui sautent vers un autre centre de données (qui fonctionne). Ainsi, le DNS round-robin ne garantit 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 proposent TCP Anycast comme solution définitive. Sur ce Dans le document (chapitre 6), il est expliqué que le basculement d'Anycast est lié à la convergence BGP. Pour cette raison, Anycast peut employer de 15 minutes à 20 secondes pour se terminer. Ces 20 secondes sont possibles sur les réseaux dont la topologie a été optimisée pour cela. Il est probable que seuls les opérateurs CDN peuvent garantir des basculements aussi rapides.

Edit 3:*

• J'ai fait quelques recherches de DNS et traceroutes (peut-être qu'un expert peut vérifier) et :
  • Le seul CDN utilisant TCP Anycast semble être CacheFly, d'autres opérateurs comme CDN networks et BitGravity utilisent CacheFly. Il semble que leurs bords ne peuvent pas être utilisés comme des reverse proxies. Par conséquent, ils ne peuvent pas être utilisés pour assurer un basculement instantané.
  • Akamai et LimeLight semblent utiliser un DNS géo-averti. Mais ils renvoient plusieurs enregistrements A. D'après les traceroutes, il semble que les adresses IP renvoyées se trouvent dans le même centre de données. Je suis donc perplexe quant à la façon dont ils peuvent offrir un accord de niveau de service de 100 % lorsqu'un centre de données tombe en panne.