Pourquoi le basculement DNS n'est-il pas recommandé?

D'après la lecture, il semble que le basculement DNS n'est pas recommandé simplement parce que DNS n'a pas été conçu pour cela. Mais si vous avez deux serveurs Web sur des sous-réseaux différents hébergeant un contenu redondant, quelles autres méthodes existe-t-il pour garantir que tout le trafic est acheminé vers le serveur en direct si l'un des serveurs tombe en panne?

Pour moi, il semble que le basculement DNS soit la seule option de basculement, mais le consensus est que ce n'est pas une bonne option. Pourtant, des services comme DNSmadeeasy.com le fournissent, il doit donc y avoir du mérite. Des commentaires?

Par 'basculement DNS', je suppose que vous entendez DNS Round Robin associé à une surveillance, par exemple la publication de plusieurs adresses IP pour un nom d'hôte DNS et la suppression d'une adresse inactive lorsque la surveillance détecte qu'un serveur est en panne. Cela peut fonctionner pour des sites Web de petite taille et moins soumis à la traite.

De par leur conception, lorsque vous répondez à une demande DNS, vous fournissez également une durée de vie (TTL) pour la réponse que vous distribuez. En d'autres termes, vous dites aux autres serveurs et caches DNS "vous pouvez stocker cette réponse et l'utiliser pendant x minutes avant de vérifier avec moi". Les inconvénients proviennent de ceci:

• Avec le basculement DNS, un pourcentage inconnu de vos utilisateurs aura vos données DNS mises en cache avec des quantités variables de durée de vie restante. Jusqu'à l'expiration de la durée de vie, ceux-ci peuvent se connecter au serveur hors service. Il existe des moyens plus rapides pour effectuer le basculement que cela.
• En raison de ce qui précède, vous êtes enclin à définir une durée de vie relativement basse, par exemple 5 à 10 minutes. Toutefois, une valeur plus élevée offre un avantage (très faible) en termes de performances et peut aider votre propagation DNS à fonctionner de manière fiable, même en cas de problème de courte durée dans le trafic réseau. Ainsi, l'utilisation du basculement basé sur le DNS va à l'encontre de la durée de vie élevée, mais cette durée fait partie du DNS et peut être utile.

Les méthodes les plus courantes pour obtenir une bonne disponibilité impliquent:

• Placement des serveurs ensemble sur le même réseau local.
• Placez le réseau local dans un centre de données avec des plans d'alimentation et de réseau hautement disponibles.
• Utilisez un équilibreur de charge HTTP pour répartir la charge et effectuer un basculement sur des défaillances de serveur individuelles.
• Obtenez le niveau de redondance / la disponibilité attendue dont vous avez besoin pour vos pare-feu, équilibreurs de charge et commutateurs.
• Ayez une stratégie de communication en place pour les pannes de centre de données complet et les pannes occasionnelles d'un commutateur / serveur de base de données / autre ressource qui ne peuvent pas être facilement mises en miroir.

Une très petite minorité de sites Web utilisent des configurations multi-centres de données, avec un «équilibrage géographique» entre centres de données.

Le basculement DNS fonctionne parfaitement. Je l'utilise depuis de nombreuses années pour transférer manuellement le trafic entre des centres de données ou automatiquement lorsque les systèmes de surveillance détectent des pannes, des problèmes de connectivité ou des serveurs surchargés. Lorsque vous voyez la vitesse à laquelle cela fonctionne et les volumes de trafic du monde réel qui peuvent être facilement déplacés, vous ne regarderez jamais en arrière. J'utilise Zabbix pour surveiller tous mes systèmes et les graphiques visuels qui montrent ce qui se passe lors d'une situation de basculement DNS dissipent tous mes doutes. Il existe peut-être quelques FAI qui ignorent les TTL, et certains utilisateurs utilisent encore d'anciens navigateurs - mais lorsque vous consultez du trafic provenant de millions de pages vues par jour sur 2 emplacements de centre de données, vous effectuez un transfert de trafic DNS - le trafic résiduel entrant qui ignore les TTL est risible.

DNS n'a pas été conçu pour le basculement - mais il a été conçu avec des TTL qui fonctionnent à merveille pour les besoins de basculement lorsqu'ils sont combinés avec un système de surveillance solide. Les TTL peuvent être très courts. J'ai utilisé efficacement des TTL de 5 secondes en production pour alléger les solutions basées sur le basculement DNS rapide. Vous devez avoir des serveurs DNS capables de gérer la charge supplémentaire - et nommés ne vont pas la couper. Cependant, powerdns fait l'affaire quand il est sauvegardé avec une base de données répliquée mysql sur des serveurs de noms redondants. Vous avez également besoin d'un système de surveillance distribué solide sur lequel vous pouvez compter pour l'intégration du basculement automatisé. Zabbix fonctionne pour moi - je peux vérifier les pannes de plusieurs systèmes Zabbix distribués presque instantanément - mettre à jour instantanément les enregistrements mysql utilisés par powerdns - et fournir un basculement presque instantané pendant les pannes et les pics de trafic.

Mais bon, j’ai construit une entreprise qui fournit des services de basculement DNS après des années de travail pour les grandes entreprises. Alors, prenez mon avis avec un grain de sel. Si vous souhaitez voir des graphiques de trafic zabbix de sites à volume élevé pendant une panne - pour voir par vous-même exactement comment fonctionne le basculement DNS - envoyez-moi un message, je serai ravi de le partager.

Le problème avec le basculement DNS est qu’il est, dans de nombreux cas, peu fiable. Certains fournisseurs de services Internet ignoreront vos TTL. Cela ne se produit pas immédiatement, même s'ils les respectent. Lorsque le site réapparaît, cela peut donner lieu à des sessions étranges lorsque le cache DNS d'un utilisateur arrive à expiration. sur l'autre serveur.

Malheureusement, c'est pratiquement la seule option, à moins que vous ne soyez assez grand pour effectuer votre propre routage (externe).

L’opinion la plus répandue est qu’avec le RR DNS, lorsqu’une adresse IP tombe en panne, certains clients continuent à utiliser l’adresse IP endommagée pendant quelques minutes. Cela a été dit dans certaines des réponses précédentes à la question et cela est également écrit sur Wikipedia.

En tous cas,

http://crypto.stanford.edu/dns/dns-rebinding.pdf explique que ce n'est pas le cas pour la plupart des navigateurs HTML actuels. Ils vont essayer la prochaine adresse IP en quelques secondes.

http://www.tenereillo.com/GSLBPageOfShame.htm semble être encore plus fort:

L'utilisation de plusieurs enregistrements A n'est pas une astuce du métier, ni une fonctionnalité conçue par les fournisseurs d'équipement d'équilibrage de charge. Le protocole DNS a été conçu avec la prise en charge de plusieurs enregistrements A pour cette raison même. Les applications telles que les navigateurs, les serveurs proxy et les serveurs de messagerie utilisent cette partie du protocole DNS.

Certains experts peuvent peut-être commenter et expliquer plus clairement pourquoi DNS RR n’est pas adapté à la haute disponibilité.

Merci,

Valentino

PS: désolé pour le lien brisé mais, en tant que nouvel utilisateur, je ne peux pas publier plus de 1

J'ai exécuté le basculement DNS RR sur un site Web de production à trafic modéré mais critique (sur deux sites géographiques) pendant de nombreuses années.

Cela fonctionne bien, mais il y a au moins trois subtilités que j'ai apprises à la dure.

1) Les navigateurs passeront d’une adresse IP inutilisée à une adresse IP opérationnelle après 30 secondes (la dernière fois que j’ai vérifiée) si les deux sont considérés comme actifs dans le DNS mis en cache disponible pour vos clients. C'est fondamentalement une bonne chose.

Mais attendre "la moitié" de vos utilisateurs attendre 30 secondes est inacceptable, vous voudrez probablement mettre à jour vos enregistrements TTL en quelques minutes, et non quelques jours ou semaines, afin qu'en cas de panne, vous puissiez rapidement supprimer le serveur hors service. de votre DNS. D'autres ont fait allusion à cela dans leurs réponses.

2) Si l'un de vos serveurs de noms (ou l'une de vos deux régions géographiques) tombe en panne et sert votre domaine round robin, et si le premier d'entre eux tombe en panne, je me souviens vaguement que vous pouvez rencontrer d'autres problèmes en essayant de le supprimer. Si vous n'avez pas défini votre durée de vie SOA / expiration pour le serveur de noms sur une valeur suffisamment basse, DNS est également en panne. Je pourrais avoir des détails techniques faux ici, mais il y a plus d'un paramètre TTL dont vous avez besoin pour bien vous défendre et vous défendre réellement contre les points de défaillance uniques.

3) Si vous publiez des API Web, des services REST, etc., ceux-ci ne sont généralement pas appelés par les navigateurs. Par conséquent, à mon avis, le basculement DNS commence à montrer de véritables failles. C'est peut-être pour cela que certains disent, comme vous dites, "ce n'est pas recommandé". Voici pourquoi je dis ça. Premièrement, les applications qui consomment ces URL ne sont généralement pas des navigateurs. Elles ne disposent donc pas des propriétés / logique de basculement de 30 secondes des navigateurs classiques. Deuxièmement, le fait que la deuxième entrée DNS soit appelée ou non, ou même que le DNS soit réinterrogé, dépend beaucoup des détails de programmation de bas niveau des bibliothèques réseau dans les langages de programmation utilisés par ces clients API / REST, ainsi que de la façon dont elles sont appelées par l'application cliente API / REST. (Sous leurs couvertures, la bibliothèque appelle-t-elle get_addr et quand? Si des sockets se ferment ou se ferment, l'application ouvre-t-elle de nouveaux sockets? Existe-t-il une sorte de logique de délai d'attente? Etc etc)

C'est bon marché, bien testé et "fonctionne principalement". Comme dans la plupart des cas, votre kilométrage peut varier.

Il y a beaucoup de gens qui nous utilisent (Dyn) pour le basculement. C'est la même raison pour laquelle les sites peuvent créer une page de statut lorsqu'ils ont un temps mort (pensez à Fail Whale, par exemple, sur Twitter) ... ou simplement rediriger le trafic en fonction des TTL. Certaines personnes peuvent penser que DNS Failover est un ghetto ... mais nous avons sérieusement conçu notre réseau avec basculement depuis le début ... afin qu'il fonctionne aussi bien que le matériel. Je ne sais pas comment DME le fait, mais 3 de nos 17 points de présence les plus proches diffusés sur 17 surveillent votre serveur depuis l'emplacement le plus proche. Lorsqu'il détecte une panne sur deux des trois, nous redirigeons simplement le trafic sur l'autre IP. Le seul temps d'arrêt concerne ceux qui étaient à la demande du reste de cet intervalle TTL.

Certaines personnes aiment utiliser les deux serveurs à la fois ... et dans ce cas, peuvent effectuer un équilibrage de la charge alternatif ... ou un équilibrage de charge basé sur la géo. Pour ceux qui s'intéressent réellement aux performances ... notre gestionnaire de trafic en temps réel surveillera chaque serveur ... et si l'un est plus lent ... redirigez le trafic sur le plus rapide en fonction des adresses IP que vous associez à vos noms d'hôte. Encore une fois ... cela fonctionne sur la base des valeurs que vous avez mises en place dans notre interface utilisateur / API / portail.

Je suppose que ce que je veux dire, c’est que… nous avons conçu exprès le basculement DNS. Alors que le DNS n’était pas conçu pour le basculement lors de sa création, notre réseau DNS a été conçu pour le mettre en œuvre dès le départ. Il peut généralement être aussi efficace que le matériel .. sans amortissement ni coût du matériel. J'espère que cela ne me fera pas sembler boiteux d'avoir branché Dyn ... il y a beaucoup d'autres entreprises qui le font ... je parle simplement du point de vue de notre équipe. J'espère que cela t'aides...

Une autre option consisterait à configurer le serveur de noms 1 à l’emplacement A et le serveur de noms 2 à l’emplacement B, mais de configurer chacun d’entre eux de manière à ce que tous les enregistrements A sur le trafic de points NS1 vers les adresses IP de l’emplacement A et sur NS2 tous les enregistrements A pointent sur les adresses IP de emplacement B. Définissez ensuite vos TTL pour un nombre très bas et assurez-vous que votre enregistrement de domaine chez le registraire a été configuré pour NS1 et NS2. De cette façon, la charge sera automatiquement équilibrée et basculera en cas de panne d’un serveur ou d’un lien vers un emplacement.

J'ai utilisé cette approche d'une manière légèrement différente. J'ai un emplacement avec deux fournisseurs de services Internet et utilise cette méthode pour diriger le trafic sur chaque lien. Maintenant, il s’agit peut-être d’un peu plus de maintenance que vous ne le souhaitez ... mais j’ai pu créer un simple logiciel extrayant automatiquement les enregistrements NS1, mettant à jour les adresses IP des enregistrements pour certaines zones et les poussant vers NS2.

L'alternative est un système de basculement basé sur BGP. Ce n'est pas simple à mettre en place, mais ça devrait être à l'épreuve des balles. Configurez le site A dans un emplacement, le site B dans une seconde, tous avec des adresses IP locales, puis obtenez un bloc d'adresses portables de classe C ou portable et configurez la redirection des adresses IP portables vers les adresses IP locales.

Il y a des pièges, mais c'est mieux que les solutions basées sur DNS si vous avez besoin de ce niveau de contrôle.

Une option pour le basculement de plusieurs centres de données consiste à former vos utilisateurs. Nous annonçons à nos clients que nous fournissons plusieurs serveurs dans plusieurs villes et dans nos courriels d'inscription. Ces liens incluent des liens directs vers chaque "serveur" pour que les utilisateurs sachent que si un serveur est en panne, ils peuvent utiliser le lien vers l'autre.

Cela contourne totalement le problème du basculement DNS en ne conservant que plusieurs noms de domaine. Les utilisateurs qui accèdent à www.company.com ou company.com et se connectent sont redirigés vers server1.company.com ou server2.company.com et ont le choix de mettre en favori l'un de ceux-ci s'ils s'aperçoivent qu'ils obtiennent de meilleures performances en utilisant l'un ou l'autre. . Si l'un d'eux tombe en panne, les utilisateurs sont formés pour accéder à l'autre serveur.

J'utilise l'équilibrage de site et le basculement basés sur DNS depuis dix ans. Il existe certains problèmes, mais ceux-ci peuvent être atténués. BGP, bien que supérieur à certains égards, n’est pas une solution à 100%, avec une complexité accrue, probablement des coûts matériels supplémentaires, des temps de convergence, etc.

J'ai constaté que la combinaison de l'équilibrage de charge local (basé sur le réseau local), de GSLB et de l'hébergement de zone en nuage fonctionnait assez bien pour résoudre certains des problèmes normalement associés à l'équilibrage de charge DNS.

Toutes ces réponses ont une certaine valeur, mais je pense que cela dépend vraiment de ce que vous faites et de votre budget. Ici, chez CloudfloorDNS, un grand pourcentage de notre activité est constitué de DNS et offre non seulement un DNS rapide, mais également des options TTL et un basculement DNS bas. Nous ne serions pas en affaires si cela ne fonctionnait pas et fonctionnait bien.

Si vous êtes une multinationale avec un budget illimité sur la disponibilité, les équilibreurs de charge GSLB et les centres de données de niveau 1 sont géniaux, mais votre DNS doit encore être rapide et solide. Comme beaucoup d'entre vous le savent, le DNS est un aspect essentiel de toute infrastructure. Outre le nom de domaine lui-même, il s'agit du service de niveau le plus bas sur lequel toutes les autres composantes de votre présence en ligne sont utilisées. En commençant par un bureau d'enregistrement de domaine solide, DNS est tout aussi important que de ne pas laisser votre domaine expirer. Le DNS tombe en panne, cela signifie que tout l’aspect en ligne de votre organisation est également en panne!

Lors de l'utilisation du basculement DNS, les autres aspects critiques sont la surveillance du serveur (toujours plusieurs emplacements géographiques à vérifier et toujours multiple (au moins 3) pour éviter les faux positifs) et la gestion correcte des enregistrements DNS lorsqu'un échec est détecté. Une faible durée de vie et certaines options associées au basculement peuvent en faire un processus transparent, et il est bien mieux de se réveiller un jour au cours d'un téléavertisseur au milieu de la nuit si vous êtes un administrateur système.

Dans l'ensemble, le basculement DNS fonctionne vraiment et peut être très abordable. Dans la plupart des cas, chez nous ou chez la plupart des fournisseurs de DNS gérés, vous bénéficiez du DNS Anycast ainsi que de la surveillance du serveur et du basculement pour une fraction du coût des options matérielles.

La vraie réponse est donc oui, cela fonctionne, mais est-ce pour tout le monde et pour tous les budgets? Peut-être que non, mais tant que vous n’avez pas essayé et fait les tests pour vous-même, il est difficile d’ignorer si vous êtes une PME / PMI disposant d’un budget informatique limité et qui souhaite bénéficier du meilleur temps de disponibilité possible.

"et pourquoi vous prenez vos risques en l'utilisant pour la plupart des environnements de production (bien que ce soit mieux que rien)."

En réalité, "mieux que rien" s’exprime mieux comme "la seule option" lorsque les présences sont géographiquement diverses. Les équilibreurs de charge matérielle sont parfaits pour un point de présence unique, mais un point de présence unique est également un point de défaillance unique.

Il y a beaucoup de sites à gros prix qui utilisent la manipulation du trafic basée sur le DNS à bon escient. Ce sont les types de sites qui savent toutes les heures si les ventes sont en baisse. Il semblerait qu'ils soient les derniers à «tenter leur chance en l'utilisant dans la plupart des environnements de production». En effet, ils ont soigneusement examiné leurs options, sélectionné la technologie et en ont payé le prix. S'ils pensaient que quelque chose allait mieux, ils partiraient sans hésiter. Le fait qu'ils choisissent encore de rester en dit long sur leur utilisation dans le monde réel.

Le basculement basé sur le DNS souffre d’une certaine latence. Il n'y a pas moyen de contourner cela. Cependant, il reste la seule approche viable de la gestion du basculement dans un scénario multi-pop. Comme seule option, c'est bien plus que "mieux que rien".

Aujourd'hui, de bons équilibreurs de charge mondiaux fonctionnent avec cette technique et fonctionnent assez bien. Vérifiez par exemple Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/

Si vous voulez en savoir plus, lisez les notes sur l’application à

http://edgedirector.com

Ils couvrent: le basculement, l’équilibrage de la charge globale et une foule de questions connexes.

Si votre architecture dorsale le permet, la meilleure option est l’équilibrage de la charge globale avec l’option de basculement. De cette façon, tous les serveurs et la bande passante sont en jeu autant que possible. Plutôt que d'insérer un serveur disponible supplémentaire en cas d'échec, cette configuration retire un serveur en panne du service jusqu'à ce qu'il soit récupéré.

La réponse courte: cela fonctionne, mais vous devez comprendre les limites.

Je pense que l'idée de basculement était destinée au clustering, mais le fait qu'il puisse également s'exécuter en solo permettait tout de même de fonctionner dans une disponibilité individuelle.

Je vous recommanderais soit de sélectionner un centre de données multi-hôte sur son propre AS, soit d’héberger vos serveurs de noms dans un cloud public. Il est VRAIMENT peu probable que EC2, HP ou IBM disparaisse. Juste une pensée. Alors que DNS fonctionne comme une solution, il s’agit simplement d’une solution à une mauvaise conception de la base réseau dans ce cas.

Une autre option, selon votre environnement, consiste à utiliser une combinaison de IPSLA, PBR et FHRP pour répondre à vos besoins en matière de redondance.