Unité 3.7 : DNS et routage de basculement

Introduction

Lorsqu'un point de terminaison, une zone ou un site entier est perdu, aucun seul IP ne peut le sauver, et IONOS ne vend pas d'appliance de basculement géré pour effectuer la direction pour vous. La réponse se trouve un niveau au-dessus, au niveau du nom : un enregistrement DNS qui dirige les clients vers un point de terminaison sain et est redirigé lorsque ce point de terminaison cesse d'être sain. La vérité architecturale importante est que Cloud DNS ne réalise pas le contrôle de santé ni la redirection pour vous. Cloud DNS n'est pas conscient de la santé ; il sert tout enregistrement que vous définissez. Le contrôle de santé qui décide qu'un point de terminaison est mort, et l'appel API qui redirige l'enregistrement, sont une automatisation que vous possédez. Cela fait du basculement de point de terminaison basé sur DNS un modèle construit par le client, dans lequel Cloud DNS est un composant (très disponible), et non un produit de basculement natif. Cette unité construit la fondation bien documentée, une zone principale et ses enregistrements, met en avant les véritables forces de Cloud DNS, puis traite le comportement de basculement honnêtement : ce que la plateforme fournit de manière native et ce que vous orchestrez vous-même contre le API.

1. Cloud DNS : ce qu'il offre, et où réside réellement le basculement

Cloud DNS est un service d'autorité DNS entièrement géré et anycast : ses zones sont servies à partir de 14 points de présence en Europe et aux États-Unis, et le service offre un SLA de disponibilité de 99,995 pour cent. L'anycast est important car chaque résolveur atteint automatiquement le Node sain le plus proche, donc le plan DNS lui-même est hautement disponible de manière indépendante des points de terminaison qu'il dirige. Ses forces natives valent la peine d'être énoncées clairement, car ce sont elles que vous construisez réellement : service d'autorité anycast, zones principales et secondaires, un TTL que vous pouvez définir aussi bas que 60 secondes, DNSSEC, et DNS inversé.

Deux de ces forces sont faciles à confondre, alors séparez-les nettement.

La résilience du serveur d'autorité est native : zones secondaires. Une zone secondaire est un miroir AXFR d'une zone principale. Son rôle est la reprise après sinistre pour le serveur d'autorité de nom lui-même : si le serveur de nom principal est hors ligne, la zone secondaire continue de répondre aux requêtes avec les derniers enregistrements transférés. Les zones secondaires sont servies à partir d'un ensemble de serveurs de noms distinct (nscs.ui-dns.*) et constituent une fonction de résilience réelle et native de la plateforme. Ce qu'elles ne sont pas, c'est le basculement de la santé des points de terminaison. Une zone secondaire continue de servir les mêmes enregistrements ; elle ne surveille pas si le point de terminaison vers lequel ces enregistrements pointent est actif, et elle ne modifie pas une réponse parce qu'un backend est tombé en panne.

Le basculement des points de terminaison n'est pas natif, car Cloud DNS n'est pas conscient de la santé. Cloud DNS ne surveille pas la santé des points de terminaison et ne modifie pas automatiquement les enregistrements en fonction de la santé. Il n'y a pas de type d'enregistrement de basculement de santé. Lorsque les gens disent "basculement DNS", ce qu'ils veulent dire sur IONOS, c'est un modèle que le client construit : un moniteur externe ou un script exécute la vérification de santé, et en cas d'échec, il appelle l'API de Cloud DNS pour rediriger un enregistrement à faible TTL vers un point de terminaison sain. Cloud DNS sert simplement l'enregistrement que vous définissez. L'automatisation de la vérification de santé et de la réorientation est la vôtre ; Cloud DNS fournit l'enregistrement anycast, avec SLA, à faible TTL, qui rend le modèle rapide et fiable une fois que vous le gérez.

Deux propriétés dictent la façon dont vous concevez autour de ce modèle construit par le client.

Tout d'abord, DNS ne dirige que les nouvelles connexions. La réorientation d'un enregistrement modifie l'endroit où les futures recherches se résolvent ; elle ne fait rien pour les connexions déjà établies contre le point de terminaison défaillant, et elle ne fait rien pour les clients qui tiennent toujours une réponse mise en cache. La conséquence difficile est que tout niveau situé derrière le basculement DNS doit être sans état : un client qui est redirigé vers le point de terminaison secondaire doit être en mesure de continuer sans affinité de session côté serveur, car la plateforme ne tente pas de conserver l'état à travers le commutateur. L'état de session et d'autres états doivent résider dans un niveau partagé (le niveau de cache en mémoire du Module 5), et non sur le point de terminaison qui vient de défaillir.

Ensuite, le TTL est le levier dominant sur le temps de récupération. Le TTL que vous définissez pour un enregistrement est la durée pendant laquelle les résolveurs peuvent mettre en cache l'ancienne réponse, il est donc effectivement un plancher sur la rapidité avec laquelle les clients redirigés peuvent découvrir le nouveau point de terminaison après la modification de l'enregistrement. Cloud DNS permet des TTL allant de 60 secondes à 604800 secondes (7 jours). Un TTL faible raccourcit la fenêtre pendant laquelle les clients continuent de frapper le point de terminaison mort, ce qui est ce que votre budget RTO paie réellement ; le compromis est des requêtes de résolveur plus fréquentes. Pour un enregistrement avec basculement, définissez un TTL faible intentionnellement et traitez-le comme le réglage du temps de récupération qu'il est, et non comme une valeur par défaut que vous avez héritée. Notez également que la propagation des serveurs de noms peut prendre jusqu'à 48 heures, ce qui concerne la délégation d'une nouvelle zone, et non l'étape de basculement par enregistrement, donc planifiez la délégation bien à l'avance de tout changement.

DCD Marche à suivre pour la mise en œuvre

Vous allez créer la zone d'autorité de FinCorp, ajouter les enregistrements qui résolvent son service public, puis organiser un basculement orchestré par le client sur une paire de points de terminaison à deux extrémités (par exemple, le point de terminaison de la région principale et un point de terminaison de la région secondaire). La création de la zone et des enregistrements est un chemin de console bien documenté ; le re-pointage basé sur les vérifications de santé est traité au niveau de la conception et de API, car Cloud DNS n'est pas conscient de la santé et n'expose aucun type d'enregistrement de basculement qui exécute son propre moniteur de santé. La vérification de santé et le re-pointage sont à votre charge.

Objectif de construction : Créer une zone et ses enregistrements, puis configurer un basculement orchestré par le client (vérification de santé externe plus un re-pointage API) sur une paire de points de terminaison à deux extrémités.

Prérequis : Vous devez être un administrateur de contrat, un propriétaire ou un utilisateur disposant du privilège « Accéder et gérer DNS » pour créer et gérer des zones et des enregistrements.

Étapes (dans Data Center Designer) :

Ouvrez Cloud DNS et sélectionnez Créer une zone DNS principale.
Dans la fenêtre Créer une zone principale, définissez Activé/Désactivé (laissez Activé), le Nom (le domaine ou le sous-domaine, par exemple app.fincorp.example), et une description facultative. Cliquez sur Créer la zone. (Désactiver une zone supprime son enregistrement SOA et la détache des serveurs de noms IONOS, donc laissez-la activée.)
À partir de l'acknowledgement de création de zone, copiez les serveurs de noms IONOS attribués (l'ensemble ns-ic.ui-dns.*) et configurez-les chez votre registrar pour déléguer le domaine. Prévoyez une propagation avant toute mise en production.
Ouvrez la zone (Zones principales, puis la zone, ou Détails et enregistrements) et cliquez sur Créer un enregistrement.
Dans la fenêtre Créer un enregistrement, définissez : Activé, le Nom (laisser vide crée un enregistrement Apex/zone-Root ; * crée un wildcard), le TTL en secondes (la valeur par défaut est 3600, mais pour un enregistrement à basculement, définissez une valeur faible, par exemple 60, comme levier de temps de récupération), le Type (par exemple A pour l'adresse IP du point de terminaison principal IPv4), et le Contenu (l'adresse du point de terminaison). Enregistrez.
Ajoutez les enregistrements pour le point de terminaison secondaire afin que les deux adresses cibles existent en tant qu'enregistrements gérés que vous pouvez basculer.

L'étape de basculement (orchestrée par le client ; Cloud DNS n'est pas conscient de la santé) : Cloud DNS n'a pas de type d'enregistrement de basculement qui exécute son propre moniteur de santé et bascule automatiquement la cible, car le service ne vérifie pas la santé du point de terminaison. Ne créez pas un flux de console qui le fait. Au lieu de cela, orchestrez-le : exécutez une vérification de santé à l'extérieur du service DNS (un moniteur externe ou une vérification dans vos outils d'exploitation) contre le point de terminaison principal, et lorsque celui-ci échoue, appelez l'API Cloud DNS pour mettre à jour le contenu de l'enregistrement vers le point de terminaison secondaire. Puisque chaque enregistrement porte un TTL faible défini à l'étape 5, les clients redirigés récupèrent rapidement la nouvelle cible. Une mise à jour d'enregistrement est un appel API authentifié unique contre les UUID de zone et d'enregistrement ; l'état de l'enregistrement passe de « Provisionnement » à « Disponible » lorsque le changement prend effet. C'est la forme honnête du « basculement DNS » sur la plateforme aujourd'hui : la gestion de zone et d'enregistrement est native et bien documentée, et l'automatisation de la vérification de santé et du re-pointage est à votre charge, construite autour de ce API. Cloud DNS sert l'enregistrement que vous définissez ; il ne décide pas quand le changer.

Erreurs courantes :

Laisser la valeur TTL par défaut de 3600 secondes sur un enregistrement à basculement. Le TTL est votre plancher de temps de récupération ; une valeur TTL élevée et obsolète garde les clients fixés sur un point de terminaison mort longtemps après que vous ayez basculé l'enregistrement.
Supposer que Cloud DNS effectue la vérification de santé ou le basculement pour vous. Ce n'est pas le cas ; il n'est pas conscient de la santé. Construisez la vérification de santé et le re-pointage API vous-même plutôt que de supposer qu'un type d'enregistrement de basculement natif existe.
Confondre les zones secondaires avec le basculement de point de terminaison. Les zones secondaires sont un miroir AXFR pour la reprise après sinistre du serveur de noms (elles continuent à répondre si le serveur de noms principal meurt) ; elles ne détectent pas un point de terminaison mort ou ne changent pas d'enregistrement. Le basculement de point de terminaison est le re-pointage orchestré par le client.
Mettre en avant un niveau d'état avec un basculement DNS. DNS ne dirige que les nouvelles connexions, donc externalisez la session/état vers le niveau de cache partagé ou les utilisateurs redirigés perdent leur session.
Oublier la délégation de serveur de noms et sa propagation pouvant durer jusqu'à 48 heures lors de la mise en place d'une nouvelle zone ; c'est une tâche préalable à la mise en production, et non une tâche de basculement.

Résumé

Cloud DNS est un service autoritaire à tout moment, avec une garantie SLA, et il constitue un élément solide dans une conception de basculement, mais il n'est pas lui-même un produit de basculement. Il n'est pas conscient de la santé : il sert tout ce que vous configurez et ne modifie jamais une réponse de son propre chef. Deux choses qu'il fournit de manière native sont importantes ici : l'anycast qui maintient le plan DNS hautement disponible, et les zones secondaires qui maintiennent le serveur de noms en réponse si le principal est hors ligne. Le basculement des points de terminaison est différent et est construit par le client : une vérification de santé externe que vous exécutez détecte un point de terminaison mort et appelle le Cloud DNS API pour rediriger un enregistrement à faible TTL vers un point sain. La gestion des zones et des enregistrements est la partie console bien documentée ; la vérification de santé et la redirection sont une automatisation que vous possédez, rendue rapide par un TTL délibérément bas. Puisque le mécanisme ne dirige que les nouvelles connexions, chaque niveau qu'il précède doit être sans état, avec l'état de session poussé vers un niveau partagé.

Points clés :

Cloud DNS n'est pas conscient de la santé : il ne réalise pas de vérification de santé de point de terminaison et ne possède pas de basculement automatique. Il sert tout ce que vous configurez.
Le basculement des points de terminaison est un modèle construit par le client : votre propre vérification de santé externe plus un enregistrement Cloud DNS API de redirection, étant donné qu'il n'y a pas de produit de basculement géré.
Les zones secondaires sont natives, mais elles constituent une reprise après sinistre des serveurs autoritaires (un miroir AXFR qui continue de répondre si le serveur de noms principal meurt), et non un basculement de santé de point de terminaison.
Le TTL est le levier RTO dominant (Cloud DNS permet 60 à 604800 secondes) ; définissez-le bas sur les enregistrements qui précèdent le basculement à dessein.
DNS ne dirige que les nouvelles connexions, donc les niveaux qui précèdent DNS doivent être sans état et externaliser l'état/de la session vers un cache partagé.
Cloud DNS est à tout moment sur 14 points de présence (Europe et USA) avec une garantie de disponibilité de 99,995 pour cent ; la délégation de serveur de noms peut prendre jusqu'à 48 heures et est une tâche de pré-coupe.

Terminologie importante :

TTL (Temps de vie) : La durée pendant laquelle les résolveurs peuvent mettre en cache un enregistrement ; sur un enregistrement de basculement, il définit la rapidité avec laquelle les clients redirigés découvrent le nouveau point de terminaison.
Apex (enregistrement de zone-Root) : Un enregistrement au nom de zone nu, créé en laissant le nom d'enregistrement vide.
Anycast : Le fait de servir la même adresse à partir de plusieurs points de présence afin que les résolveurs atteignent le Node le plus proche en bonne santé, ce qui rend le plan DNS lui-même hautement disponible.

Lecture supplémentaire