Pourquoi le basculement DNS n'est-il pas recommandé?
À la lecture, il semble que le basculement DNS ne soit 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 du contenu redondant, quelles autres méthodes existe-t-il pour garantir que tout le trafic est acheminé vers le serveur en direct si un serveur tombe en panne?
Pour moi, il semble que le basculement DNS soit la seule option de basculement ici, 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 combiné à une surveillance, c'est-à-dire la publication de plusieurs adresses IP pour un nom d'hôte DNS et la suppression d'une adresse morte lorsque la surveillance détecte qu'un serveur est en panne. Cela peut être réalisable pour les petits sites Web moins trafiqués.
De par leur conception, lorsque vous répondez à une demande DNS, vous fournissez également un Time To Live (TTL) pour la réponse que vous distribuez. En d'autres termes, vous dites à d'autres serveurs DNS et caches "vous pouvez stocker cette réponse et l'utiliser pendant x minutes avant de revenir avec moi". Les inconvénients en découlent:
- Avec le basculement DNS, un pourcentage inconnu de vos utilisateurs verra vos données DNS mises en cache avec des quantités variables de TTL restantes. Jusqu'à l'expiration du TTL), elles peuvent se connecter au serveur mort. Il existe des moyens plus rapides de terminer le basculement que cela.
- En raison de ce qui précède, vous avez tendance à définir le TTL assez bas, disons 5-10 minutes. Mais le régler plus haut offre un (très petit) avantage en termes de performances et peut aider votre propagation DNS fonctionne de manière fiable même en cas de petit problème dans le trafic réseau. L'utilisation du basculement basé sur DNS va donc à l'encontre des TTL élevés, mais les TTL élevés font partie du DNS et peuvent être utiles.
Les méthodes les plus courantes pour obtenir une bonne disponibilité comprennent:
- Placer les serveurs ensemble sur le même LAN.
- Placez le LAN 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 basculer sur les pannes de serveur individuelles.
- Obtenez le niveau de redondance/disponibilité attendue dont vous avez besoin pour vos pare-feu, équilibreurs de charge et commutateurs.
- Avoir une stratégie de communication en place pour les défaillances du centre de données complet et la défaillance occasionnelle d'un commutateur/serveur de base de données/autre ressource qui ne peut pas être facilement reflétée.
Une très petite minorité de sites Web utilisent des configurations multi-centres de données, avec un "géo-équilibrage" entre les centres de données.
Le basculement DNS fonctionne très bien. Je l'utilise depuis de nombreuses années pour transférer manuellement le trafic entre les centres de données ou automatiquement lorsque la surveillance des systèmes a détecté 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 dans le monde réel qui peuvent être déplacés facilement - 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 pendant une situation de basculement DNS mettent fin à tous mes doutes. Il y a peut-être quelques FAI qui ignorent les TTL, et certains utilisateurs sont toujours là avec d'anciens navigateurs - mais lorsque vous regardez le trafic de millions de pages vues par jour sur 2 emplacements de centre de données et que vous effectuez un transfert de trafic DNS - le trafic résiduel entrant qui ignore les TTL est risible. Le basculement DNS est une technique solide.
Le DNS n'a pas été conçu pour le basculement - mais il a été conçu avec des TTL qui fonctionnent étonnamment 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 effectivement utilisé 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é ne le coupera pas. Cependant, powerdns fait l'affaire lorsqu'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 solide système de surveillance distribué auquel vous pouvez faire confiance pour l'intégration de basculement automatisée. Zabbix fonctionne pour moi - je peux vérifier les pannes de plusieurs systèmes Zabbix distribués presque instantanément - mettre à jour les enregistrements mysql utilisés par powerdns à la volée - 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 fonctionnement pour de grandes entreprises. Alors prenez mon avis avec un grain de sel. Si vous voulez voir des graphiques de trafic zabbix de sites à volume élevé pendant une panne - pour voir par vous-même comment fonctionne correctement le basculement DNS - écrivez-moi, je suis plus qu'heureux de partager.
Le problème avec le basculement DNS est qu'il est, dans de nombreux cas, peu fiable. Certains FAI ignoreront vos TTL, cela ne se produit pas immédiatement, même s'ils respectent vos TTL, et lorsque votre site revient, cela peut entraîner une certaine bizarrerie avec les sessions lorsque le cache DNS d'un utilisateur expire, et ils finissent par se diriger sur l'autre serveur.
Malheureusement, c'est à peu près la seule option, sauf si vous êtes assez grand pour faire votre propre routage (externe).
L'opinion répandue est qu'avec DNS RR, quand une IP tombe en panne, certains clients continueront d'utiliser l'IP cassée pendant quelques minutes. Cela a été indiqué dans certaines des réponses précédentes à la question et il est également écrit sur Wikipedia.
En tous cas,
http://crypto.stanford.edu/dns/dns-rebinding.pdf explique que ce n'est pas vrai pour la plupart des navigateurs HTML actuels. Ils essaieront la prochaine 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 ruse 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. Des applications telles que les navigateurs et les serveurs proxy et les serveurs de messagerie utilisent cette partie du protocole DNS.
Peut-être qu'un expert peut commenter et expliquer plus clairement pourquoi DNS RR n'est pas bon pour la haute disponibilité.
Merci,
Valentino
PS: désolé pour le lien cassé mais, en tant que nouvel utilisateur, je ne peux pas poster plus de 1
J'ai exécuté le basculement DNS RR sur un site Web de production à trafic modéré mais essentiel pour l'entreprise (sur deux zones 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 basculeront d'une IP non fonctionnelle vers une IP fonctionnelle après 30 secondes (la dernière fois que j'ai vérifié) 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 avoir "la moitié" de vos utilisateurs attend 30 secondes est inacceptable, donc vous voudrez probablement mettre à jour vos TTL enregistrements pour être quelques minutes, pas quelques jours ou semaines afin qu'en cas de panne, vous pouvez supprimer rapidement le serveur en panne de votre DNS. D'autres y ont fait allusion dans leurs réponses.
2) Si l'un de vos serveurs de noms (ou l'une de vos deux géographies entièrement) tombe en panne et sert votre domaine à tour de rôle, et si le principal d'entre eux tombe en panne, je me souviens vaguement que vous pouvez rencontrer d'autres problèmes en essayant de supprimer cela serveur de noms en panne du DNS si vous n'avez pas défini votre SOA TTL/expiration pour le serveur de noms à une valeur suffisamment basse également. Je pourrais avoir des détails techniques erronés ici, mais il y en a plus qu'un = TTL paramètre dont vous avez besoin pour bien vous défendre contre les points de défaillance uniques.
3) Si vous publiez des API Web, les services REST, etc.) ne sont généralement pas appelés par les navigateurs, et donc, à mon avis, le basculement DNS commence à montrer de vrais défauts. C'est peut-être la raison pour laquelle certains disent, comme vous le dites "ce n'est pas recommandé". Voici pourquoi je dis cela. Premièrement, les applications qui consomment ces URL ne sont généralement pas des navigateurs, elles n'ont donc pas les propriétés/logique de basculement de 30 secondes des navigateurs courants. Deuxièmement, qu'elles soient ou non la deuxième entrée DNS est appelée ou même DNS est interrogé à nouveau dépend beaucoup des détails de programmation de bas niveau des bibliothèques de mise en réseau dans les langages de programmation utilisés par ces clients API/REST, plus exactement comment ils sont appelés par le client API/REST (Sous leurs couvertures, la bibliothèque appelle-t-elle get_addr, et quand? Si les sockets se bloquent ou se ferment, l'application rouvre-t-elle de nouvelles sockets? Existe-t-il une sorte de logique de temporisation? etc etc)
C'est bon marché, bien testé et "fonctionne surtout". Donc, comme avec la plupart des choses, votre kilométrage peut varier.
Il y a un tas de gens qui nous utilisent (Dyn) pour le basculement. C'est la même raison pour laquelle les sites peuvent soit afficher une page d'état lorsqu'ils ont des temps d'arrêt (pensez à des choses comme Twitter Whale) ... soit simplement rediriger le trafic en fonction des TTL. Certaines personnes peuvent penser que le basculement DNS est un ghetto ... mais nous avons sérieusement conçu notre réseau avec un basculement depuis le début ... afin qu'il fonctionne aussi bien que le matériel. Je ne sais pas comment DME le fait, mais nous avons 3 des 17 de nos PoPs anycasted les plus proches qui surveillent votre serveur depuis l'emplacement le plus proche. Quand il détecte de deux des trois qu'il est en panne, nous redirigeons simplement le trafic vers l'autre IP. Le seul temps d'arrêt est pour ceux qui étaient à celui demandé pour le reste de cet intervalle TTL.
Certaines personnes aiment utiliser les deux serveurs à la fois ... et dans ce cas, peuvent faire quelque chose comme un équilibrage de charge à tour de rôle ... ou un équilibrage de charge géo-basé. Pour ceux qui se soucient réellement des performances ... notre gestionnaire de trafic en temps réel surveillera chaque serveur ... et si l'un est plus lent ... redirigez le trafic vers le plus rapide en fonction des IP que vous liez dans vos noms d'hôtes. Encore une fois ... cela fonctionne en fonction des valeurs que vous mettez en place dans notre interface utilisateur/API/portail.
Je suppose que mon point est ... nous avons conçu le basculement DNS à dessein. Bien que le DNS n'ait pas été conçu pour le basculement lors de sa création à l'origine ... notre réseau DNS a été conçu pour l'implémenter dès le départ. Il peut généralement être aussi efficace que le matériel ... sans dépréciation ni coût du matériel. J'espère que cela ne me rend pas boiteux pour brancher Dyn ... il y a beaucoup d'autres sociétés qui le font ... Je parle juste du point de vue de notre équipe. J'espère que cela t'aides...
Une autre option serait de configurer le serveur de noms 1 à l'emplacement A et le serveur de noms 2 à l'emplacement B, mais configurez chacun d'eux de sorte que tous les enregistrements A sur NS1 pointent le trafic vers les adresses IP pour l'emplacement A, et sur NS2, tous les enregistrements A pointent vers les adresses IP pour emplacement B. Ensuite, définissez vos TTL pour un nombre très faible et assurez-vous que votre enregistrement de domaine chez le registraire a été configuré pour NS1 et NS2. De cette façon, il équilibrera automatiquement la charge 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 FAI et j'utilise cette méthode pour diriger le trafic sur chaque lien. Maintenant, cela peut être un peu plus de maintenance que ce que vous êtes prêt à faire ... mais j'ai pu créer un simple logiciel qui extrait automatiquement les enregistrements NS1, met à jour les adresses IP d'un enregistrement pour certaines zones et les pousse vers NS2.
L'alternative est un système de basculement basé sur BGP. Ce n'est pas simple à configurer, mais il devrait être à l'épreuve des balles. Configurez le site A dans un emplacement, le site B dans un second avec des adresses IP locales, puis obtenez une classe C ou un autre bloc d'IP portables et configurez la redirection des IP portables vers les 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 multi-centre de données consiste à former vos utilisateurs. Nous annonçons à nos clients que nous fournissons plusieurs serveurs dans plusieurs villes et dans nos e-mails d'inscription et notamment des liens directement vers chaque "serveur" afin que les utilisateurs sachent si un serveur est en panne, ils peuvent utiliser le lien vers l'autre serveur.
Cela contourne totalement le problème du basculement DNS en conservant simplement plusieurs noms de domaine. Les utilisateurs qui se connectent à www.company.com ou company.com et se connectent sont dirigés vers server1.company.com ou server2.company.com et ont le choix de mettre en signet l'un ou l'autre s'ils remarquent qu'ils obtiennent de meilleures performances en utilisant l'un ou l'autre. . Si l'un 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, et il y a des problèmes, mais ceux-ci peuvent être atténués. BGP, bien que supérieur à certains égards, n'est pas non plus une solution à 100% avec une complexité accrue, probablement des coûts matériels supplémentaires, des temps de convergence, etc.
J'ai trouvé que la combinaison de l'équilibrage de charge local (basé sur LAN), du GSLB et de l'hébergement de zone basé sur le cloud 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 validité, mais je pense que cela dépend vraiment de ce que vous faites et de votre budget. Chez CloudfloorDNS, un grand pourcentage de notre entreprise est DNS, et offre non seulement un DNS rapide, mais un faible TTL options et basculement DNS. Nous ne serions pas en affaires si cela ne fonctionnait pas et fonctionnent bien.
Si vous êtes une multinationale avec un budget illimité sur le temps de fonctionnement, oui, les équilibreurs de charge GSLB et les centres de données de niveau 1 sont excellents, mais votre DNS doit toujours être rapide et solide. Comme beaucoup d'entre vous le savent, le DNS est un aspect essentiel de toute infrastructure, à part le nom de domaine lui-même, c'est le service de niveau le plus bas sur lequel toutes les autres parties de votre présence en ligne s'appuient. Commençant par un registraire de domaine solide, DNS est tout aussi essentiel 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 plusieurs (au moins 3) doivent être vérifiés pour éviter les faux positifs) et la gestion correcte des enregistrements DNS, une défaillance est détectée. De faibles TTL et certaines options avec le basculement peuvent en faire un processus transparent et vous évitent de vous réveiller avec un pager 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, de notre part ou de la plupart des fournisseurs de DNS gérés, vous obtiendrez Anycast DNS ainsi que la surveillance et le basculement du serveur pour une fraction du coût des options matérielles.
Donc, la vraie réponse est oui, cela fonctionne, mais est-ce pour tout le monde et pour tous les budgets? Peut-être pas, mais jusqu'à ce que vous l'essayiez et que vous fassiez les tests par vous-même, il est difficile d'ignorer si vous êtes une petite ou moyenne entreprise avec un budget informatique limité qui souhaite le meilleur temps de disponibilité possible.
Aujourd'hui, de bons équilibreurs de charge mondiaux qui fonctionnent en utilisant cette technique et fonctionnent plutôt bien. Vérifiez par exemple Azure Traffic Manager https://Azure.Microsoft.com/en-us/services/traffic-manager/
"et pourquoi vous tentez de l'utiliser en utilisant la plupart des environnements de production (même si c'est mieux que rien)."
En fait, "mieux que rien" est mieux exprimé comme "la seule option" lorsque les présences sont géographiquement diverses. Les équilibreurs de charge matériels sont parfaits pour un seul point de présence, mais un seul point de présence est également un point de défaillance unique.
Il existe de nombreux sites à gros prix qui utilisent à bon escient la manipulation du trafic basée sur DNS. Ils sont le type de sites qui savent sur une base horaire si les ventes sont en baisse. Il semblerait qu'ils soient les derniers à vouloir "tenter votre chance en l'utilisant pour la plupart des environnements de production". En effet, ils ont soigneusement examiné leurs options, sélectionné la technologie et bien payé. S'ils pensaient que quelque chose allait mieux, ils partiraient en un clin d'œil. Le fait qu'ils choisissent toujours de rester en dit long sur l'utilisation dans le monde réel.
Le basculement basé sur DNS souffre d'une certaine latence. Il n'y a pas moyen de contourner cela. Mais, c'est toujours 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".
Je crois que l'idée du basculement était destinée au clustering, mais parce qu'il pouvait également fonctionner en solo, il était toujours possible de fonctionner dans une disponibilité individuelle.
Si vous souhaitez en savoir plus, lisez les notes d'application sur
Ils couvrent: le basculement, l'équilibrage de charge global et une multitude de questions connexes.
Si votre architecture dorsale le permet, la meilleure option est l'équilibrage de charge global 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 supplémentaire disponible en cas d'échec, cette configuration retire un serveur défaillant du service jusqu'à ce qu'il soit récupéré.
La réponse courte: cela fonctionne, mais vous devez comprendre les limites.