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

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. Lisez ici le 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 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.

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" telle que décrite par OP.

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ée comme étant:

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 DNS Split Horizon,
4. et la surveillance de la disponibilité et les flux de trafic sont disponibles d'une manière ou d'une autre pour les nœuds DNS "intelligents",
5. de sorte que la requête DNS de l' utilisateur passe par le serveur DNS le plus proche via IP Anycast ,
6. et ce serveur DNS distribue un enregistrement / jeu d'enregistrements A de faible durée de vie pour le centre de données le plus proche / le meilleur pour cet utilisateur final via un DNS "à horizon divisé" intelligent.

Il est généralement bon d’utiliser anycast pour DNS, car les réponses DNS sont sans état et presque 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 bien 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 trafic HTTP, l'utilisation de DNS RR est le SEUL moyen d'assurer la 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).

Edit: Le document de Google "Aller au-delà des informations de chemin de bout en bout pour optimiser les performances CDN" me semble être un système de pointe en matière de distribution de charge globale pour des performances optimales pour l'utilisateur final.

Edit 2: J'ai lu l'article "Pourquoi DNS Based .. GSLB .. Ne fonctionne pas" auquel l'OP est lié, et c'est un bon aperçu - je vous recommande de le consulter . 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 connecte au hasard et reçoit 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.

Ceci est une autre solution que mes étapes 1 - 6. Je ne peux pas donner une réponse parfaite à ce sujet , je pense un spécialiste DNS de l'aime d'Akamai ou Google est nécessaire, car une grande partie de cela se résume à un savoir-faire pratique sur les limitations des caches DNS et des navigateurs déployés aujourd'hui. 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 des portails de navigateurs mobiles (téléphones cellulaires) - est que la diversité et le niveau de pannes totales des navigateurs sont incroyables. 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. :-)

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 n’est JAMAIS le bon moyen 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 cela, les technologies de routage de base d'Internet sont utilisées pour acheminer les demandes au bon centre de données, au lieu d'utiliser la technologie d' adressage de base d'Internet .

Dans la configuration la plus simple, cela ne fournit qu'un basculement. Il peut également être utilisé pour fournir Anycast, avec l'avertissement que les protocoles basés sur TCP échoueront au moment du basculement en cas d'instabilité dans le routage.

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

Clairement, 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 seule 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 chaque client donne accès 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, comme les requêtes DNS peuvent être envoyées partout, vous avez gagné ».

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

Très belle observation vmiazzo +1 pour vous !! Je suis coincé exactement là où tu es… déconcerté 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 exploitent un réseau local qui s'étend sur différents centres de données, ce qui leur permet de faire quelque chose comme CARP sur leurs hôtes sur différents centres de données.

Ou

• Ils utilisent le protocole Gateway Load Balancing Protocol sur leurs routeurs ou le protocole HSRP (Hot Standby Router Protocol) . qui traitent de la panne du centre de données.
• La raison pour laquelle ils incluent plusieurs adresses IP est que le client va réessayer et que, le cas échéant, le chemin de routage aura peut-être changé.

Pour le moment, les solutions suivantes fonctionnent pour moi: - DNS renvoie plusieurs adresses 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.

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.

2 - Vous pouvez le faire avec Anycast avec Quagga

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

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 faut l’ajouter à 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 ceux qui prétendent que cela cause beaucoup de problèmes ne savent pas de quoi ils 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 pour 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.

Un autre choix très simple consiste à utiliser un TTL faible (selon vos besoins) dans l'enregistrement DNS A ou CNAME et à mettre à jour cet enregistrement pour choisir l'adresse IP à utiliser.

Nous avons 2 FAI et plusieurs services publics et nous utilisons avec succès cette méthode pour une haute disponibilité à partir de 3 ans.

Une solution est que plusieurs fournisseurs d’accès à Internet ont des résolveurs mal configurés qui mettent en cache les enregistrements pour un intervalle défini et ignorent complètement les paramètres de durée de vie. Cela ne devrait pas être le cas et il n’ya aucune excuse à cela, mais malheureusement, c’est ce que j’ai vécu avec la migration de nombreux sites Web et services.

Anycast TCP est en fait très stable et est utilisé au moins par CacheFly (depuis 2002), Prolexic et BitGravity. Une bonne présentation sur TCP Anycast a été faite à NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

Plusieurs enregistrements A constituent le seul moyen d’éliminer un seul point de défaillance possible. Toute autre solution oblige toutes les demandes entrantes à passer par un seul périphérique, quelque part entre le serveur et le client.

Donc, pour la redondance absolue, il est nécessaire. C’est la raison pour laquelle Google le fait, ou quiconque souhaite être assuré de la disponibilité continue du service.

C’est assez évident pourquoi cela est le cas ... Plusieurs enregistrements A sont le seul moyen de déplacer le point auquel les demandes sont acheminées vers le navigateur client. Toute autre méthode reposera sur un seul point entre le navigateur client et le serveur sur lequel une panne peut survenir, entraînant l'arrêt de votre service. En utilisant les enregistrements A, le seul point de défaillance d'un client à un serveur devient le client lui-même.

Si vous n'avez pas configuré plusieurs enregistrements A, vous demandez un temps d'arrêt ...

Cette méthode ne peut évidemment pas être utilisée pour l’équilibrage de charge.