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 comme technique d'équilibrage de charge bon marché.
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 de l'utiliser pendant quelques minutes.
Un équilibreur de charge est souvent suggéré comme un meilleur choix.
Les deux affirmations ne sont pas complètement vraies:
Lorsque le trafic est HTTP, la plupart des navigateurs HTML peuvent essayer automatiquement l'enregistrement A suivant si le précédent est en panne, sans nouvelle recherche DNS. Lire ici 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 entre eux.
Alors, est-il vrai qu'avec plusieurs centres de données et du 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
Modifier:
- Bien sûr, 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é.
- AFAIK la seule façon pour un DNS de suggérer un centre de données au lieu d'un autre est de répondre uniquement avec l'IP (ou les IP) associée (s) à ce centre de données. Si le centre de données devient inaccessible, tous ces IP sont également inaccessibles. 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'à l'expiration de l'entrée de cache local et une nouvelle recherche DNS sera effectuée, récupérant les nouvelles adresses IP actives (je suppose que DNS suggère automatiquement à un nouveau centre de données en cas de défaillance). Ainsi, le "DNS intelligent" ne peut pas assurer un basculement instantané.
- A l'inverse, un round robin DNS 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 mis en cache pour passer à un autre centre de données (en fonctionnement). 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".
Édition 2:
- Certaines personnes suggèrent TCP Anycast comme solution définitive. Dans this papier (chapitre 6 ) est expliqué que le basculement Anycast est lié à la convergence BGP. Pour cette raison, Anycast peut utiliser de 15 minutes à 20 secondes pour se terminer. 20 secondes sont possibles sur les réseaux où la topologie a été optimisée pour cela. Probablement seuls les opérateurs CDN peuvent accorder de telles basculements rapides.
Édition 3: *
- J'ai fait des recherches DNS et des traceroutes (peut-être qu'un expert peut vérifier) et:
- Le seul CDN utilisant TCP Anycast semble être CacheFly, d'autres opérateurs comme les réseaux CDN et BitGravity utilisent CacheFly. Il semble que leurs bords ne puissent pas être utilisés comme proxy inverses. Par conséquent, ils ne peuvent pas être utilisés pour accorder des basculement.
- Akamai et LimeLight semblent utiliser un DNS géo-conscient. Mais! Ils renvoient plusieurs enregistrements A. De traceroutes semble que les IP retournées sont sur le même centre de données. Donc, je suis perplexe sur la façon dont ils peuvent offrir un 100% SLA lorsqu'un centre de données tombe en panne.
Lorsque j'utilise le terme "DNS Round Robin", je veux généralement dire dans le sens de la "technique d'équilibrage de charge bon marché" comme OP le décrit.
Mais ce n'est pas la seule façon d'utiliser le DNS pour une haute disponibilité mondiale. La plupart du temps, il est difficile pour les personnes d'horizons (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:
- Un réseau mondial Anycast de serveurs DNS "intelligents",
- et un ensemble de centres de données répartis à l'échelle mondiale,
- où chaque nœud DNS implémente Split Horizon DNS,
- et la surveillance de la disponibilité et des flux de trafic sont disponibles pour les nœuds DNS "intelligents" d'une certaine manière,
- afin que la requête DNS de l'utilisateur soit acheminée vers le serveur DNS le plus proche via IP Anycast ,
- et ce serveur DNS distribue un enregistrement A à faible TTL/ensemble d'enregistrements A pour le centre de données le plus proche/le meilleur pour cet utilisateur final via DNS "intelligent" à horizon partagé.
Utiliser anycast pour DNS est généralement correct, car les réponses DNS sont sans état et presque extrêmement courtes. Donc, si les routes BGP changent, il est très peu probable d'interrompre une requête DNS.
Anycast est moins adapté aux conversations HTTP plus longues et avec état, donc ce système utilise 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 que vous puissiez obtenir une meilleure redondance, utiliser des équilibreurs de charge plus petits/moins chers, sans surcharger les tampons réseau Unix d'un seul serveur hôte, etc.).
Alors, est-il vrai qu'avec plusieurs centres de données et du trafic HTTP, l'utilisation de DNS RR est la SEULE façon 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 élément essentiel de tout système mondial à haute disponibilité. Ce qui précède illustre une façon courante (souvent la meilleure) d'aller.
Edit: Le document Google "Aller au-delà des informations de chemin de bout en bout pour optimiser les performances du CDN" me semble être état de l'art dans la répartition de la charge mondiale pour les meilleures performances de l'utilisateur final.
Edit 2: J'ai lu l'article "Pourquoi DNS basé .. GSLB .. ne fonctionne pas" cet OP lié à , et c'est un bon aperçu - je recommande de le regarder. Lisez-le d'en 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 "Arroser" vers le bas, il se développe sur l'évidence, que l'envoi de plusieurs enregistrements A n'est pas cool s'ils pointent vers des centres de données sur plusieurs continents, car le client se connectera au hasard et obtiendra donc assez 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 solution différente de mes étapes 1 à 6. Je ne peux pas fournir une réponse parfaite à ce sujet, je pense qu'un spécialiste DNS comme Akamai ou Google est nécessaire, car cela se résume en grande partie à savoir-faire pratique sur les limites des caches et navigateurs DNS déployés aujourd'hui. AFAIK, mes étapes 1 à 6 sont ce que fait Akamai avec son DNS (quelqu'un peut-il le confirmer?).
Mon sentiment - venant d'avoir travaillé en tant que PM sur les portails de navigateurs mobiles (téléphones portables) - est que la diversité et le niveau de rupture totale du les navigateurs là-bas sont incroyables. Personnellement, je ne ferais pas confiance à une solution HA qui nécessite que le terminal de l'utilisateur final "fasse la bonne chose"; Je pense donc que le basculement instantané mondial sans interrompre une session n'est pas possible aujourd'hui.
Je pense que mes étapes 1 à 6 ci-dessus sont les meilleures qui soient disponibles avec la technologie des produits de base. Cette solution n'a pas de basculement instantané.
J'adorerais qu'un de ces spécialistes DNS d'Akamai, de Google, etc. vienne me prouver le contraire. :-)
Votre question est: "Le 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 seul)
La bonne façon d'obtenir un basculement instantané est d'utiliser le routage BGP4 de telle sorte que les deux sites utilisent les mêmes adresses IP. En utilisant cela, le cœur de l'Internet le routage les technologies sont utilisées pour acheminer les demandes vers le bon centre de données, au lieu d'utiliser le cœur de l'Internet l'adressage technologie.
Dans la configuration la plus simple, ceci seulement fournit un basculement. Il peut également être utilisé pour fournir Anycast, avec l'avertissement que TCP échoueront au moment du basculement s'il y a une instabilité dans le routage.
Alors, est-il vrai qu'avec plusieurs centres de données et du trafic HTTP, l'utilisation de DNS RR est la SEULE façon d'assurer une haute disponibilité?
Il s'agit clairement d'une fausse affirmation - il suffit de regarder Google, Akamai, Yahoo, pour voir qu'ils n'utilisent pas les réponses à tour de rôle [*] comme seule solution (certains peuvent l'utiliser en partie, avec d'autres approches .)
Il existe de nombreuses options possibles, mais cela dépend vraiment des autres contraintes que vous avez, de votre service/application pour lequel vous choisissez.
Il est possible d'utiliser des techniques de tourniquet sur une approche de serveur simple et colocalisée, et ne pas avoir à vous soucier de la défaillance du 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 les équilibreurs de charge.)
Peut-être avez-vous besoin de toutes les demandes pour une seule session pour aller 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 alternée n'est pas appropriée, pour cela: vous devez faire quelque chose qui garantit qu'un client donné accède à chaque fois au même cluster de serveurs physiques (sauf lorsque des `` exceptions '' se produisent, telles qu'une défaillance du serveur). Soit ils reçoivent une adresse IP cohérente d'une requête DNS, soit ils 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 de réseau BGP. Vous pouvez simplement faire en sorte que les serveurs de noms de votre propre domaine donnent des réponses entièrement différentes (mais, comme les demandes DNS peuvent être envoyées partout, vous n'obtiendrez aucune affinité de localisation avec cette approche.)
[* Je vais utiliser "round-robin", car "RR" dans la terminologie DNS signifie "enregistrement de ressource".]
Très belle observation vmiazzo +1 pour vous !! Je suis coincé exactement où tu es .. déconcerté par la façon dont ces CDN font leur magie.
Voici ma conjecture sur la façon dont CDN gère son réseau:
- Utilisez Anycast DNS (mentionné par Jesper Mortensen) pour obtenir le centre de données le plus proche
- Ils exécutent un réseau local qui s'étend sur différents centres de données, ce qui leur permet de faire quelque chose comme CARPE sur leurs hôtes dans différents centres de données
Ou
- Ils emploient Gateway Load Balancing Protocol sur leurs routeurs ou Hot Standby Router Protocol (HSRP) . qui traitent des pannes de centres de données.
- La raison pour laquelle ils incluent plusieurs IP est pour que le client réessaye et au moment où le client réessaye, le chemin de routage peut avoir changé.
Pour le moment, la solution suivante fonctionne pour moi: - 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
- Dernier point d'entrée vers un proxy inverse sur le cloud Amazon, qui passe intelligemment au serveur disponible (ou fournit sous la page de maintenance)
Le proxy inverse est toujours touché mais aussi lourd que le principal.
Pourquoi la RFC 2782 (appliquer la même chose que MX/priorité pour des services comme http, imap, ...) n'est pas implémentée dans tout type de navigateur? Les choses seraient plus faciles ... Il y a un bug sur, ouvert depuis dix ans à Mozilla !!! car ce sera la fin de l'industrie de l'équilibreur de charge commercial ??? J'en suis très déçu.
Je me demande combien de personnes répondant à ces questions exécutent actuellement un vaste réseau mondial de serveurs? Google utilise le tournoi à la ronde et mon entreprise l'utilise depuis des années. Cela peut très bien fonctionner, avec quelques limitations. Oui, il doit être complété par d'autres mesures.
La vraie clé est d'être prêt à accepter un hoquet ou deux si un serveur tombe en panne. Lorsque je débranche la fiche d'un serveur, si un navigateur tente d'accéder à ce serveur, il y aura un délai d'une minute environ pendant que le navigateur apprend que l'adresse IP est en panne. Mais il passe ensuite très rapidement sur un autre serveur.
Cela fonctionne très bien et les gens qui prétendent que cela cause beaucoup de problèmes ne savent pas de quoi ils parlent. Cela nécessite simplement 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 approfondie pour créer des systèmes de basculement et je ne suis pas du tout fan de basculement.
En outre, RR fonctionne pour répartir la charge, même si elle est passive plutôt qu'active. Nos journaux de serveur indiquent clairement le pourcentage approprié de trafic sur chaque serveur - dans des limites raisonnables.
TCP Anycast 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
Une clé dans les travaux est qu'un certain nombre de FAI 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 TTL. Il ne devrait pas en être ainsi et il n'y a aucune excuse pour cela. , mais malheureusement, d'après mon expérience avec la migration de nombreux sites Web et services, cela se produit.
Un autre choix très simple consiste à utiliser une valeur faible (la valeur la plus faible dépend de vos besoins) TTL dans l'enregistrement DNS A ou CNAME et mettez à jour cet enregistrement pour choisir quelle IP sera utilisée.
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.