80 votes

RYFN avatar

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

Demandé el 30 de Septembre, 2009
Quand la question a-t-elle été
25415 affichage
Nombre de visites la question a
5 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

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.
Demandé el 30 de Septembre, 2009 par RYFN

0 votes

Avatar de RYFN

La haute disponibilité implique un basculement quasi instantané. Le client ne devrait pas remarquer de problème même si un centre de données tombe en panne. J'ai affiné la question.

Commenté el 30 de Septembre, 2009 par RYFN

0 votes

Avatar de rmalayter

MaxCDN utilise anycast TCP et ses bords peuvent être utilisés en mode proxy de mise en cache ("origin fetch" dans la terminologie de l'industrie CDN).

Commenté el 22 de Mars, 2010 par rmalayter

0 votes

Avatar de Pacerier

@vmiazzo, Votre lien pdf est en panne... Voulez-vous dire 15 minutes ou 20 secondes à 15 minutes ?

Commenté el 14 de Mai, 2014 par Pacerier

Réponses

Trop de publicités?

35voto

Zameer Manji avatar
Zameer Manji Points 1213

Lorsque j'utilise le terme "DNS Round Robin", je l'entends généralement dans le sens de la "technique d'équilibrage de charge bon marché" telle que la décrit OP.

Mais ce n'est pas la seule façon dont le DNS peut être utilisé pour la haute disponibilité globale. La plupart du temps, il est difficile pour des personnes issues de milieux (technologiques) différents de bien communiquer.

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

  1. Un réseau mondial de serveurs DNS "intelligents" de type "Anycast",
  2. et un ensemble de centres de données répartis dans le monde entier,
  3. où chaque nœud DNS met en œuvre le Split Horizon DNS,
  4. et la surveillance de la disponibilité et des flux de trafic sont disponibles pour les nœuds DNS "intelligents" d'une manière ou d'une autre,
  5. de sorte que le la demande DNS de l'utilisateur est transmise au serveur DNS le plus proche via IP Anycast. ,
  6. et ceci Le serveur DNS distribue un enregistrement A ou un ensemble d'enregistrements A à faible TL pour l'adresse suivante le plus proche / le meilleur centre de données pour cet utilisateur final via un DNS "intelligent" à horizon partagé.

L'utilisation de l'anycast pour le DNS est généralement bonne, car les réponses DNS sont sans état et presque extrêmement courtes. Ainsi, si les routes BGP changent, il est très peu probable que cela interrompe une requête DNS.

L'Anycast est moins adapté aux conversations HTTP plus longues et avec état, c'est pourquoi ce système utilise le DNS à horizon partagé. Une session HTTP entre un client et un serveur est conservée dans un centre de données ; elle ne peut généralement pas basculer vers un autre centre de données sans rompre la session.

Comme je l'ai indiqué avec le "jeu d'enregistrements A", ce que j'appellerais le "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 répartiteurs de charge hautement disponibles dans chaque centre de données (afin d'obtenir une meilleure redondance, d'utiliser des répartiteurs de charge plus petits/moins chers, de ne pas submerger les tampons du réseau Unix d'un seul serveur hôte, etc.)

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

Non, ce n'est pas vrai, si par "DNS Round Robin" on entend simplement distribuer plusieurs enregistrements A pour un domaine. Mais il est vrai qu'une utilisation intelligente du DNS est un élément essentiel de tout système global de haute disponibilité. L'exemple ci-dessus illustre une façon courante (souvent la meilleure) de procéder.

Editar: Le document de Google "Aller au-delà des informations sur les chemins d'accès de bout en bout pour optimiser les performances des CDN". me semble être l'état de l'art en matière de distribution globale de la charge pour une meilleure performance de l'utilisateur final.

Edit 2 : J'ai lu l'article "Pourquoi le DNS basé GSLB ne fonctionne pas" que le PO a mis en lien, et c'est une bonne vue d'ensemble - je vous recommande de la consulter. Lisez-le depuis le début.

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

Dans la section "Watering it down" vers le bas, il est précisé 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 souvent un DC "lent" sur un autre continent. Ainsi, pour que cela fonctionne vraiment bien, il faut plusieurs centres de données sur chaque continent.

Il s'agit d'une solution différente de mes étapes 1 à 6. Je ne peux pas fournir une réponse parfaite à cette question, je pense qu'un spécialiste des DNS comme Akamai ou Google est nécessaire, car la plupart des problèmes se résument à ceci savoir-faire pratique sur les limites des caches DNS déployés et des navigateurs actuels. À ma connaissance, les étapes 1 à 6 correspondent à ce que fait Akamai avec son DNS (quelqu'un peut-il le confirmer ?).

Mon sentiment - pour avoir travaillé en tant que gestionnaire de projet sur des portails de navigation mobile (téléphones portables) - est que la diversité et le niveau de l'offre de services de l'UE sont très importants. rupture totale des navigateurs qui existent est incroyable. Personnellement, je ne ferais pas confiance à une solution HA qui exige du terminal de l'utilisateur final qu'il " fasse ce qu'il faut " ; c'est pourquoi je pense que le basculement instantané global sans rupture de session n'est pas réalisable aujourd'hui.

Je pense que mes étapes 1 à 6 ci-dessus sont les meilleures disponibles avec la technologie de base. Cette solution ne dispose pas d'un fail over instantané.

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

Répondu el 30 de Septembre, 2009 par Zameer Manji (1213 Points )

0 votes

Avatar de RYFN

J'ai ajouté plus d'explications dans la question. Si je comprends bien votre "meilleure technique d'équilibrage de charge" (point 6), elle ne fait de la publicité que pour 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.

Commenté el 30 de Septembre, 2009 par RYFN

0 votes

Avatar de Utilisateur non enregistré

@vmiazzo : Oui, vous m'avez bien compris. J'ajoute une deuxième modification à mon message pour clarifier - mais fondamentalement, je pense que le fail over instantané que vous recherchez est peu pratique / impossible.

Commenté el 30 de Septembre, 2009 par Utilisateur non enregistré

0 votes

Avatar de Jeff Thomas

Ce que je trouve intéressant, c'est que personne n'a suggéré de combiner les deux approches. Bien que ce ne soit pas l'idéal, cela permettrait une vitesse raisonnable lorsque les choses fonctionnent correctement, et une résilience supplémentaire lorsque ce n'est pas le cas. La pénalité serait un délai important lorsque les clients passent d'une adresse DNS basée sur l'anycast à une autre.

Commenté el 13 de Septembre, 2012 par Jeff Thomas
Afficher 1 autres commentaires

19voto

Joey deVilla avatar
Joey deVilla Points 4487

Votre question est la suivante : "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 en soi)

La bonne façon d'obtenir un basculement instantané est d'utiliser le routage BGP4 de sorte que les deux sites utilisent les mêmes adresses IP. En utilisant cette méthode, le noyau de l'Internet routage Les technologies sont utilisées pour itinéraire les requêtes vers le bon centre de données, au lieu d'utiliser le cœur de l'internet. s'adressant à technologie.

Dans la configuration la plus simple, cette uniquement assure le basculement. Il peut également être utilisé pour fournir un service Anycast, à condition que les protocoles basés sur TCP échouent au moment du basculement en cas d'instabilité du routage.

Répondu el 30 de Septembre, 2009 par Joey deVilla (4487 Points )

0 votes

Avatar de RYFN

J'ai ajouté quelques informations sur le basculement Anycast dans la question. Fondamentalement, TCP Anycast n'est pas non plus une solution parfaite.

Commenté el 1 de Octobre, 2009 par RYFN

0 votes

Avatar de Joey deVilla

@vmiazzo re TCP Anycast - en effet, d'où la note dans ma réponse sur l'instabilité du routage et comment elle affecte TCP.

Commenté el 1 de Octobre, 2009 par Joey deVilla

6voto

IaCoder avatar
IaCoder Points 2449

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 la 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 round-robin[*] comme unique solution (certains peuvent l'utiliser en partie, avec d'autres approches).

Il existe de nombreuses options possibles, mais le choix de l'une d'entre elles dépend vraiment des autres contraintes que vous rencontrez avec votre service/application.

Il est possible d'utiliser des techniques round-robin sur une approche simple, avec des serveurs situés au même endroit, et de ne pas avoir à s'inquiéter d'une panne de serveur, si vous prenez également des dispositions pour 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 que toutes les demandes d'une même session soient adressées aux mêmes serveurs, mais vous souhaitez que les demandes soient réparties sur différents clusters de serveurs régionaux ? Le Round Robin n'est pas approprié pour cela : vous devez faire quelque chose qui garantisse qu'un client donné accède au même cluster de serveurs physiques à chaque fois (sauf en cas d'exception, comme une panne de serveur). Soit ils reçoivent une adresse IP cohérente à partir d'une requête DNS, soit ils sont acheminé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 annonces de réseau BGP. Vous pourriez 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 un peu partout, vous n'obtiendrez aucune affinité de localisation avec cette approche).

(* Je vais utiliser "round-robin", car "RR" dans la terminologie DNS signifie "resource record").

Répondu el 30 de Septembre, 2009 par IaCoder (2449 Points )

0 votes

Avatar de RYFN

J'ai ajouté plus d'explications dans la réponse. Votre suggestion d'utiliser des "équilibreurs de charge" DNS ne permet pas, à mon avis, un basculement instantané. A propos de BGP, faites-vous référence à une solution TCP Anycast ?

Commenté el 30 de Septembre, 2009 par RYFN

0 votes

Avatar de IaCoder

Je ne suggère pas une solution particulière plutôt qu'une autre - je dis que vous devez choisir la bonne solution pour votre problème (que vous n'avez pas réellement énoncé dans votre question) et vos contraintes (idem). Le DNS round-robin ne fournit pas un fail-over instantané, pas plus que le DNS LB, parce que les navigateurs ne sont pas garantis de faire "la bonne chose" (principalement parce que la "bonne chose" n'est pas strictement définie ou prescrite. Je ne crois pas qu'il y ait suffisamment de "navigateurs HTML intelligents", même aujourd'hui - je suis d'accord avec Jesper pour dire qu'ils ont des comportements trop variés pour qu'on puisse s'y fier).

Commenté el 1 de Octobre, 2009 par IaCoder

0 votes

Avatar de RYFN

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".

Commenté el 1 de Octobre, 2009 par RYFN

5voto

Steve avatar
Steve Points 11

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

Voici ce que je pense de la façon dont les CDN gèrent leur réseau :

  • Utilisez Anycast DNS (mentionné par Jesper Mortensen) pour obtenir le centre de données le plus proche.
  • Ils gèrent un réseau local qui s'étendent sur différents centres de données, ce qui leur permet de faire quelque chose comme CARP sur leurs hôtes dans différents centres de données

Ou

Pour le moment, la solution suivante fonctionne pour moi : - Le DNS renvoie plusieurs IP, par ex :

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 reverse proxy sur le cloud d'Amazon, qui passe intelligemment vers un serveur disponible (ou fournit une page de maintenance).

Le proxy inversé est toujours touché, mais il n'est pas aussi lourd que le proxy principal.

Répondu el 14 de Décembre, 2009 par Steve (11 Points )

0 votes

Avatar de Sylvain

L'ordre des enregistrements DNS multiples que les clients recevront est intentionnellement aléatoire, de sorte que votre reverse proxy est probablement touché environ 1/6e du temps (1/2 de 1/3). En quoi cela est-il meilleur ou différent que d'avoir 6 enregistrements A ?

Commenté el 17 de Janvier, 2013 par Sylvain

3voto

Utilisateur non enregistré avatar
Utilisateur non enregistré Points 0

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 aucun type de navigateur ? Les choses seraient plus faciles... Il y a un bug, ouvert depuis dix ans dans Mozilla ! !! parce que ce sera la fin de l'industrie des load-balancer commerciaux ? ??? Je suis très déçu de cela.

Répondu el 16 de Avril, 2010 par Utilisateur non enregistré (0 Points )

Questions connexes

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X