Dans le modèle DNS primaire/secours traditionnel, une panne de centre de données est détectée, l'équipe d'exploitation reçoit une alerte, l'enregistrement de zone est mis à jour, le service est rechargé et les clients attendent que la nouvelle réponse DNS se propage. Cette chaîne paraît simple dans un runbook ; dans un incident réel, les délais introduits par la prise de décision, le contrôle d'accès, l'approbation et l'exécution étirent considérablement le RTO.
Dans de nombreuses organisations, le health checking et le DNS fonctionnent comme des systèmes distincts. Un outil de monitoring constate qu'un DC est inaccessible, mais le serveur DNS continue de répondre avec les mêmes adresses IP. Le pont entre les deux est généralement un script, un runbook manuel ou une couche d'automatisation séparée. Cet écart devient le maillon le plus faible au moment du failover.
Le failback comporte un risque équivalent. Si un DC oscille rapidement, la réponse DNS peut basculer à répétition — les clients sont éparpillés sur différents centres de données et le trafic peut revenir avant que la synchronisation d'état ne soit terminée. Une simple logique « retirer quand down, rajouter quand up » ne suffit pas.
Le bon modèle évalue la santé du DC via une logique de scénario booléenne, réduit le risque de flap avec des seuils de succès/échec consécutifs et fait de la réponse DNS la sortie naturelle de cette décision. Le même modèle doit aussi couvrir le basculement manuel pour la maintenance planifiée, une réponse fail-safe quand tous les DC sont malsains et les conditions DR.
TR7 DC Failover livre ce modèle : il rafraîchit automatiquement la réponse DNS quand un scénario de santé DC change et lie l'ensemble du processus de failover au TTL DNS et aux paramètres de santé définis par l'opérateur.
TR7 implémente les décisions de failover DC à travers des scénarios de santé, une logique de condition booléenne, une protection anti-flap et un mécanisme de basculement manuel.
Lorsque l'état du health check pour un DC change, le scénario associé est réévalué. Si le résultat du scénario change, les enregistrements DNS concernés sont régénérés et le DC malsain est retiré de la réponse.
Les groupes de conditions se combinent avec une logique AND ; les groupes se combinent avec une logique OR. Une condition négative peut aussi être définie pour chaque health check, permettant des scénarios inverses comme « activer cet enregistrement quand ce check est malsain ».
Tant qu'un DC est en transition, le résultat d'évaluation précédent peut être préservé. Ce comportement aide à empêcher les fluctuations up/down de courte durée de modifier en permanence la réponse DNS.
Pendant la maintenance planifiée, un opérateur peut mettre un DC hors ligne avec le mode maintenance. Même si le DC paraît sain, il peut être exclu de la réponse DNS afin que le trafic soit dirigé vers un autre DC.
DC Failover est la couche de failover GTM qui gère automatiquement les réponses DNS sur plusieurs centres de données en fonction de l'état de santé.
TR7 peut évaluer les enregistrements DC comme une chaîne de priorité ordonnée par position dans le tableau. Quand le DC primaire est malsain, le secondaire prend le relais ; quand le secondaire est aussi malsain, le tertiaire intervient — et des chaînes plus longues sont également supportées. Le modèle de code n'est pas théoriquement limité à deux endpoints. Cette structure simplifie la conception de continuité multi-étapes dans les environnements financiers, gouvernementaux et SaaS à grande échelle.
TR7 peut évaluer les signaux de santé au niveau DC : wanAccess, lanAccess, access, internet et maintenanceMode. L'accessibilité WAN, l'accessibilité LAN, l'état d'accès général, l'accès Internet et l'état de maintenance manuel sont chacun modélisés séparément. Un DC est donc évalué sur plusieurs dimensions d'accès, pas seulement sur un résultat de ping. La réponse DNS reflète une image plus réaliste de la santé du DC.
requiredSuccess et requiredFailure déterminent combien de résultats consécutifs sont nécessaires avant qu'un DC ne soit déclaré up ou down. Ce modèle empêche les changements DNS inutiles dus à une perte de paquets passagère, de brèves interruptions réseau ou des ralentissements momentanés de service. Les opérateurs peuvent utiliser des seuils plus stricts pour les services critiques et plus tolérants pour les liens plus bruyants. Le RTO est planifié conjointement avec ces seuils et l'intervalle de check.
Le mode noResponse garde un DC passif silencieux dans des conditions normales. Le mode onlyNew peut empêcher un DC qui a été down longtemps de répondre avec des données obsolètes à son retour. Ce comportement garantit que pendant le failover, seuls les DC dans le bon état produisent des réponses DNS — pas simplement ceux qui sont joignables. C'est une couche de protection importante dans les environnements où le risque de données obsolètes est une préoccupation.
Le mode DR par enregistrement permet à des enregistrements spécifiques de ne devenir actifs que lorsqu'une condition DR est remplie. Le scénario drCond ou le flag drIfNoRecords déclenche l'enregistrement DR quand les cibles primaires et secondaires sont épuisées. Ce modèle garde les adresses IP de reprise après sinistre distantes hors des réponses DNS normales tout en les maintenant en standby pour les situations critiques. La stratégie DR devient contrôlée au niveau DNS.
Si aucun DC n'est sain, une réponse peut être générée à partir du tableau fallbackRecords. Ces enregistrements peuvent pointer vers une page de maintenance, un endpoint d'urgence statique ou un service de récupération alternatif. Le comportement FailSafe garantit que le DNS produit une réponse de dernier recours contrôlée au lieu de ne rien renvoyer. Les opérateurs définissent ces enregistrements selon le plan de crise de leur organisation.
TR7 peut stocker les données d'état de health check et de scénario localement au niveau du fichier. Après un redémarrage ou un rechargement de service, l'état précédent est restauré afin que l'évaluation ne reparte pas de zéro. Cette approche réduit l'oscillation inutile dans les décisions de failover pendant un redémarrage passager. C'est particulièrement utile pour maintenir la cohérence pendant les opérations de maintenance qui redémarrent le service GTM.
Les listes de cibles wanAccess et lanAccess peuvent être définies par DC. Plusieurs cibles d'accès donnent une image plus précise de l'accessibilité externe et interne d'un DC. Un problème passager avec une seule cible ne marque pas nécessairement le DC entier comme down. Cette structure permet une modélisation plus complète de la santé du centre de données.
Quand maintenanceMode est activé, le DC concerné est mis hors ligne consciemment. C'est utile pendant les correctifs, les fenêtres de maintenance, les migrations ou les tests DR contrôlés. L'opérateur peut retirer le DC de la réponse DNS — même quand il est sain — et rediriger le trafic vers un autre DC. Quand la maintenance est terminée, le mode est désactivé et l'évaluation normale reprend.
L'état du DC peut être exprimé comme ok, noInternet, noAccess, noWan ou noLan. Cette classification montre quelle dimension d'accès est problématique au lieu de simplement dire « down ». Les équipes opérationnelles peuvent distinguer plus rapidement les problèmes de sortie Internet, d'accessibilité WAN et d'accessibilité LAN. La raison derrière une décision de failover devient plus lisible.
Quand l'état du health check change, le scénario associé peut être réévalué immédiatement. Les enregistrements liés au scénario entrent dans le pipeline de régénération de config dynamique et la réponse DNS est mise à jour. Ce comportement réduit le besoin d'éditions de zone manuelles ou de scripts externes. Les changements sont regroupés par un court debounce pour éviter une régénération répétée inutile.
Dans un scénario de cluster HA, les écritures de config DNS sont contrôlées via le rôle maître. Si le nœud maître échoue, le nœud standby peut prendre le rôle après une période de sécurité définie. Ce modèle aide à empêcher deux nœuds de produire simultanément des configs DNS différentes. Le comportement GTM reste aligné avec l'état du cluster.
Une opération de failover DC est planifiée conjointement avec l'intervalle de check, les seuils consécutifs, la structure d'ID HC, les conditions de scénario, le pipeline de régénération et les paramètres RTO.
accessPeriod définit la fréquence à laquelle les health checks DC s'exécutent. Il peut être configuré en secondes ou en minutes. Une période plus courte fournit une détection plus rapide ; une période plus longue donne une évaluation plus calme et moins bruyante.
requiredSuccess définit combien de succès consécutifs sont nécessaires avant qu'un DC ne soit considéré up. requiredFailure définit combien d'échecs consécutifs sont nécessaires avant qu'un DC ne soit considéré down. Ces deux valeurs établissent l'équilibre entre la vitesse du failover et la protection anti-flap.
Les listes wanAccess et lanAccess définissent les cibles d'accès pour un DC. Cela permet d'évaluer si un DC est joignable non seulement depuis l'extérieur mais aussi depuis le réseau interne. La distinction est particulièrement importante dans les scénarios de routage inter-DC et hybride.
Les enregistrements HC automatiques suivent le format `auto|
Les conditions au sein d'un groupe se combinent avec une logique AND ; les groupes se combinent avec une logique OR. Cette structure supporte un large éventail de modèles de décision, des simples vérifications primary-down aux scénarios de santé DC multi-dimensionnels complexes. Les opérateurs ne sont pas limités à un seul résultat de check.
Quand l'état HC change, le scénario est réévalué, les enregistrements liés sont identifiés et la régénération de config dynamique est déclenchée. Le pipeline s'exécute avec un court debounce afin que les changements successifs rapides soient fusionnés en une seule passe de régénération. La réponse DNS est re-rendue selon l'état de santé courant.
Le RTO dépend de accessPeriod, du compte requiredFailure, de la durée de debounce de régénération et du comportement TTL DNS client. Plutôt que de revendiquer un temps fixe unique, la fenêtre de failover doit être planifiée pour correspondre aux exigences de service. Les services critiques bénéficient d'un TTL plus court et de checks plus fréquents.
DC1 est défini comme primaire et DC2 comme standby passif. Quand le scénario Internet ou accès pour DC1 échoue, les enregistrements DC1 sont retirés de la réponse DNS et DC2 commence à répondre.
Les institutions financières peuvent construire une chaîne de failover séquentielle DC1 → DC2 → DC3. Chaque palier est évalué par son propre scénario de santé et un DC malsain est automatiquement retiré de la réponse DNS.
À la fenêtre de maintenance, DC1 est placé en mode maintenance et le trafic est dirigé vers DC2. Quand la maintenance est terminée, le mode maintenance est désactivé et l'évaluation de santé normale reprend.
Quand les DC primaires et secondaires sont tous les deux malsains, les enregistrements en mode DR peuvent être activés. Dans ce scénario, le site distant de reprise après sinistre reste passif dans des conditions normales et n'est ajouté à la réponse DNS que lorsque les conditions définies sont remplies.
Lorsqu'un DC down depuis longtemps revient en ligne, il peut être indésirable qu'il réponde avec des données périmées. Le comportement onlyNew garde un DC périmé passif, réduisant le risque de publier des enregistrements obsolètes.
Le DC le plus proche est d'abord sélectionné par pays ou région, puis si ce DC devient malsain, le DC standby est activé. Ce modèle combine le steering basé sur la performance avec les décisions de continuité dans une seule configuration GTM.
Scénario de santé, réponse DNS et basculement manuel unifiés dans un pipeline de décision unique. Parcourons un déploiement en direct avec votre propre architecture DC.