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


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 que cela 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:

  1. 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. Lis ici chapitre 3.1 et ici.

  2. 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 actives (je suppose que DNS suggère automatiquement nouveau centre de données en cas d'échec). Ainsi, le "DNS intelligent" ne peut pas assurer un basculement instantané.
  • Inversement, un round robin 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 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 suggèrent TCP Anycast comme solution définitive. Dans ce L'article (chapitre 6) explique 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 dans le 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 IP retournés 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.

76
2017-09-30 08:44


origine


Avec la haute disponibilité, j'impliquais un basculement presque instantané. Le client ne doit pas remarquer de problème même si un centre de données tombe en panne. J'ai affiné la question. - Valentino Miazzo
MaxCDN utilise anycast TCP et ses contours peuvent être utilisés en mode proxy de mise en cache ("extraction d'origine" dans la terminologie de l'industrie CDN). - rmalayter
@vmiazzo, votre lien pdf est en panne ... Voulez-vous dire 15 minutes ou 20 secondes à 15 minutes? - Pacerier


Réponses:


Lorsque j'utilise le terme "DNS Round Robin", je veux dire en général dans le sens de "technique d'équilibrage de charge économique" comme l'OP le décrit.

Mais ce n'est pas la seule façon d'utiliser le DNS pour une haute disponibilité globale. La plupart du temps, il est tout simplement difficile pour les personnes ayant des antécédents (technologiques) différents de bien communiquer.

La meilleure technique d'équilibrage de charge (si l'argent n'est pas un problème) est généralement considéré comme:

  1. Un réseau mondial de serveurs DNS 'intelligents' basé sur Anycast,
  2. et un ensemble de centres de données répartis à l'échelle mondiale,
  3. où chaque nœud DNS implémente le DNS Split Horizon,
  4. et la surveillance de la disponibilité et les flux de trafic sont à la disposition des nœuds DNS «intelligents»,
  5. de sorte que la la requête DNS de l'utilisateur passe au serveur DNS le plus proche via IP Anycast,
  6. et ça Le serveur DNS distribue un enregistrement / jeu d’enregistrements A de faible durée de vie. plus proche / meilleur centre de données pour cet utilisateur final via un DNS fractionné «intelligent».

Utiliser anycast pour DNS est généralement acceptable, car les réponses DNS sont sans état et sont extrêmement courtes. Par conséquent, si les itinéraires BGP changent, il est fortement improbable d'interrompre une requête DNS.

Anycast est moins adapté aux conversations HTTP longues et avec état. Ce système utilise donc un DNS à horizon divisé. Une session HTTP entre un client et un serveur est conservée dans un centre de données. il ne peut généralement pas basculer vers un autre centre de données sans interrompre la session.

Comme je l'ai indiqué avec "set of A Records", ce que j'appellerais "DNS Round Robin" peut être utilisé avec la configuration ci-dessus. Il est généralement utilisé pour répartir la charge de trafic sur plusieurs équilibreurs de charge hautement disponibles dans chaque centre de données (afin d'obtenir une meilleure redondance, d'utiliser des équilibreurs de charge plus petits / moins chers, sans surcharger les tampons réseau Unix d'un serveur hôte unique, etc.).

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 une haute disponibilité?

Non, ce n'est pas vrai. Pas si, par 'DNS Round Robin', nous entendons simplement distribuer plusieurs enregistrements A pour un domaine. Mais il est vrai que l'utilisation intelligente du DNS est un composant essentiel de tout système mondial à haute disponibilité. Ce qui précède illustre un chemin commun (souvent le meilleur).

Modifier: Le papier de Google "Aller au-delà des informations de chemin de bout en bout pour optimiser les performances CDN" me semble être à la pointe de la technologie en matière de répartition globale de la charge afin d’optimiser les performances de l’utilisateur final.

Edit 2: J'ai lu l'article "Pourquoi DNS Based .. GSLB .. Ne fonctionne pas" ce PO lié à, et c’est un bon aperçu - je vous recommande de le regarder. Lisez-le du haut.

Dans la section "La solution au problème de mise en cache du navigateur", il préconise les réponses DNS avec plusieurs enregistrements A pointant vers plusieurs centres de données comme la seule solution possible pour un basculement instantané.

Dans la section "Réduire au minimum" vers le bas, il est évident que l'envoi de plusieurs enregistrements A n'est pas cool s'ils pointent vers des centres de données situés sur plusieurs continents, car le client se connectera au hasard et obtiendra donc souvent un "lent". DC sur un autre continent. Ainsi, pour que cela fonctionne vraiment bien, plusieurs centres de données sur chaque continent sont nécessaires.

C’est une solution différente de celle décrite dans les étapes 1 à 6. Je ne peux pas vous fournir de réponse parfaite à ce sujet. Je pense qu’un spécialiste DNS de Akamai ou de Google, par exemple, est nécessaire. savoir-faire pratique sur les limitations des caches DNS déployés et des navigateurs actuels. Autant que je sache, mes étapes 1 à 6 sont ce que Akamai fait avec son DNS (quelqu'un peut-il le confirmer?).

Mon sentiment, après avoir travaillé en tant que Premier ministre sur les portails de navigateurs mobiles (téléphones cellulaires), est que la diversité et le niveau de bris total des navigateurs là-bas est incroyable. Personnellement, je ne ferais pas confiance à une solution de haute disponibilité qui demande au terminal de l’utilisateur final de «faire le bon choix»; Je pense donc que le basculement instantané global sans interrompre une session n'est pas réalisable aujourd'hui.

Je pense que les étapes 1 à 6 ci-dessus sont les meilleures qui soient disponibles avec une technologie standard. Cette solution n'a pas de basculement instantané.

J'aimerais qu'un de ces spécialistes DNS d'Akamai, Google, etc. vienne me prouver le contraire. :-)


34
2017-09-30 10:56



J'ai ajouté plus d'explications à la question. Si je comprends votre "meilleure technique d'équilibrage de charge" (point 6), elle n'annonce que les enregistrements A du "meilleur" centre de données. Comme j'ai essayé de l'expliquer dans la question, cela ne permet pas un basculement instantané sur le client. - Valentino Miazzo
@vmiazzo: Oui, vous m'avez bien compris. J'ajoute une 2e édition à mon article pour clarifier - mais je pense fondamentalement que l'échec instantané que vous cherchez est impraticable / impossible. - Jesper Mortensen
Ce que je trouve intéressant, c’est que personne n’a suggéré de combiner les deux approches. Bien que cela ne soit pas idéal, il fournirait une vitesse raisonnable lorsque les choses fonctionneraient correctement et une résilience supplémentaire dans les autres cas. La pénalité serait un retard important, car les clients sont passés d’une adresse DNS anycast à une autre. - Avery Payne
@JesperMortensen, lorsque vous parlez de DNS 'intelligent', voulez-vous dire par DNS à horizon divisé? Ou voulez-vous dire autre chose (décider en fonction de facteurs au-delà IP source)? - Pacerier


Votre question est la suivante: "DNS Round Robin est-il le SEUL moyen d'assurer un basculement instantané?"

La réponse est: "DNS Round Robin est JAMAIS la bonne façon d’assurer un basculement instantané ".

(du moins pas tout seul)

Le bon moyen de réaliser un basculement instantané consiste à utiliser le routage BGP4 de sorte que les deux sites utilisent les mêmes adresses IP. En utilisant ce noyau Internet routage les technologies sont utilisées pour route les demandes au bon centre de données, au lieu d'utiliser le coeur d'internet adresser La technologie.

Dans la configuration la plus simple cette seulement fournit le basculement. Il peut également être utilisé pour fournir Anycast, en précisant que les protocoles basés sur TCP échoueront au moment du basculement en cas d'instabilité dans le routage.


18
2017-09-30 16:04



Ajout d'informations sur le basculement d'Anycast sur la question. De manière générale, TCP Anycast n’est pas une solution parfaite. - Valentino Miazzo
@vmiazzo re TCP Anycast - d’où la remarque de ma réponse concernant l’instabilité du routage et son incidence sur le protocole TCP. - Alnitak


Alors, est-il vrai qu'avec l'utilisation de plusieurs centres de données et du trafic HTTP, l'utilisation de DNS RR est le SEUL moyen d'assurer la haute disponibilité?

Manifestement, il s’agit d’une fausse affirmation. Il suffit de consulter Google, Akamai, Yahoo pour voir qu’ils n’utilisent pas les réponses répétitives [*] comme seule solution (certaines peuvent l’utiliser en partie, ainsi que d’autres approches). .)

Il existe de nombreuses options possibles, mais cela dépend vraiment des autres contraintes que vous avez, avec votre service / application pour lequel vous choisissez.

Il est possible d'utiliser des techniques de va-et-vient sur une approche serveur simple et co-localisée, sans avoir à s'inquiéter de la défaillance d'un serveur, si vous organisez également le «basculement» de l'adresse IP. (Mais la plupart optent pour des techniques d’équilibrage de charge, une adresse IP unique et un basculement entre équilibreurs de charge.)

Peut-être avez-vous besoin que toutes les demandes d'une même session aillent sur les mêmes serveurs, mais vous voulez que les demandes soient réparties sur différents clusters de serveurs régionaux? La répétition à la ronde n’est pas appropriée pour cela: vous devez faire en sorte que tout client donné accède au même cluster de serveurs physique à chaque fois (sauf en cas d’exceptions, telles que des pannes de serveur). Ils reçoivent une adresse IP cohérente d'une requête DNS ou sont routés vers le même cluster de serveurs physiques. Les solutions pour cela incluent divers "équilibreurs de charge" DNS commerciaux et non commerciaux, ou (si vous avez plus de contrôle sur votre réseau) des publicités sur le réseau BGP. Vous pouvez simplement faire en sorte que les serveurs de noms de votre propre domaine donnent des réponses totalement différentes (mais, étant donné que les requêtes DNS peuvent être envoyées partout, vous n'obtiendrez aucune affinité d'emplacement avec cette approche.)

[* Je vais utiliser "round-robin", parce que "RR" dans la terminologie DNS signifie "enregistrement de ressource".]


6
2017-09-30 09:47



J'ai ajouté plus d'explications dans la réponse. Votre suggestion d’utiliser des «équilibreurs de charge» DNS ne permet pas un basculement instantané. À propos du BGP, faites-vous référence à une solution Anycast TCP? - Valentino Miazzo
Je ne suggère aucune solution particulière à une autre - je dis que vous devez choisir la bonne solution à votre problème (ce que vous n'avez pas vraiment indiqué dans votre question) et à vos contraintes (idem.). pas plus que DNS LB avec un basculement instantané, car il n’est pas garanti que les navigateurs agissent "correctement" (principalement parce que le "correct" n’est pas strictement défini ni prescrit. Je ne crois pas qu’il existe suffisamment Navigateurs HTML ", même maintenant - je suis d'accord avec Jesper sur le fait qu'ils sont trop variés dans leurs comportements pour pouvoir compter sur eux.) - jrg
Je comprends votre scepticisme. Quoi qu'il en soit, comme vous pouvez le lire ici crypto.stanford.edu/dns/dns-rebinding.pdf la plupart des navigateurs HTML actuels sont déjà "intelligents". - Valentino Miazzo


Très belle observation vmiazzo +1 pour vous !! Je suis coincé exactement là où vous êtes… dérouté par la façon dont ces CDN font leur magie.

Voici comment je suppose que CDN gère son réseau:

  • Utiliser le DNS Anycast (mentionné par Jesper Mortensen) pour obtenir le centre de données le plus proche
  • Ils courent un réseau local qui couvrent différents centres de données qui leur permettent de faire quelque chose comme CARPE sur leurs hôtes à travers différents centres de données

Ou

Au moment où la solution suivante fonctionne pour moi: - Le DNS retourne plusieurs IP, par exemple:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy
  • Dernière entrée pointant vers un proxy inverse sur le cloud amazon, qui passe intelligemment au serveur disponible (ou fournit sur la page de maintenance)

Le proxy inverse est toujours touché, mais il est aussi lourd que le principal.


5
2017-12-14 08:15



L'ordre des enregistrements DNS multiples que les clients recevront est intentionnellement randomisé afin que votre proxy inverse soit probablement touché environ 1/6 du temps (1/2 sur 1/3). En quoi est-ce meilleur ou différent que d'avoir 6 enregistrements A? - ColinM


Pourquoi la RFC 2782 (appliquer la même chose que MX / priority pour des services tels que http, imap, ...) n'est pas implémentée dans aucun type de navigateur? Les choses seraient plus faciles ... Il y a un bug qui existe depuis dix ans chez Mozilla !!! parce que ce sera la fin de l'industrie de l'équilibreur de charge commercial ??? Je suis très déçu de cela.


3
2018-04-16 15:05





2 - Vous pouvez le faire avec Anycast en utilisant Quagga

(Même s'il existe des informations selon lesquelles Anycast est mauvais avec TCP, plusieurs grandes entreprises l'utilisent comme CacheFly)


2
2017-09-30 09:08



Absolument, mais vous ne pouvez pas faire cela avec des serveurs loués, vous avez besoin de votre propre réseau. - Julien Tartarin
Ajout d'informations sur le basculement d'Anycast sur la question. De manière générale, TCP Anycast n’est pas une solution parfaite. - Valentino Miazzo


Je me demande combien de personnes répondant à ces questions exploitent un grand réseau mondial de serveurs? Google utilise round robin et mon entreprise l'utilise depuis des années. Cela peut très bien fonctionner, avec certaines limitations. Oui, il doit être complété par d'autres mesures.

La vraie clé est d'être disposé à accepter un hoquet ou deux si un serveur tombe en panne. Lorsque je déconnecte un serveur, si un navigateur tente d'accéder à ce serveur, il s'écoule environ une minute avant que le navigateur apprenne que l'adresse IP est indisponible. Mais cela passe ensuite très rapidement sur un autre serveur.

Cela fonctionne très bien et les personnes qui prétendent que cela cause beaucoup de problèmes ne savent pas de quoi elles parlent. Cela nécessite juste la bonne conception.

Le basculement est nul. Le meilleur HA utilise toutes les ressources tout le temps.

Je travaille avec HA depuis 1986. J'ai suivi une formation poussée pour créer des systèmes de basculement et je ne suis pas du tout un fan du basculement.

En outre, RR travaille à répartir la charge, même de manière passive plutôt qu'active. Les journaux de nos serveurs indiquent clairement le pourcentage de trafic approprié sur chaque serveur - dans des limites raisonnables.


2
2017-07-19 14:34