Quand GTM bascule, le reste de l'organisation doit le savoir.
Dans une architecture GTM, un changement d'état de health-check peut changer la réponse DNS — mais une opération est rarement juste une réponse DNS. Quand un centre de données passe hors-ligne, le système d'alarme, le système de ticketing, l'automatisation DR, le pipeline d'audit et l'équipe applicative ont tous besoin de savoir. Sans cette connexion, GTM prend la décision tandis que le reste de la chaîne opérationnelle de l'organisation l'apprend trop tard.
Résoudre cela avec une couche d'orchestration séparée est possible, mais cela signifie un nouveau service, de nouveaux credentials, une nouvelle surveillance et un nouveau point de défaillance. Le health-check tourne déjà à l'intérieur de GTM ; propager les changements d'état aux systèmes externes devrait être géré depuis la même plateforme.
Côté forwarding DNS, le problème est similaire. Certains domaines appartiennent au DNS interne, certains à un résolveur externe, certains à la propre zone faisant autorité de TR7. Quand un simple forwarder envoie tout à une seule destination, le split-DNS, les zones internes, les domaines partenaires et les comportements de routage géo entrent en collision.
Si l'information ECS est perdue, le problème s'aggrave. Les décisions basées sur la géo et la topologie dépendent du contexte réseau client ; si le forwarder laisse tomber ce contexte, le routage géographique en amont peut être effectué contre la mauvaise localisation. Un forwarder ne doit pas simplement porter la requête — il doit aussi préserver le contexte de décision.
TR7 GTM Triggers and Forwarders lie les changements d'état de health-check à des chaînes d'actions HTTP/HTTPS ou Oracle DB, et rend le forwarding DNS opérationnellement gérable via le forwarding sélectif de domaines, le forward de zone vers localhost et le pass-through ECS.
Notre approche
TR7 conçoit GTM non pas simplement comme un moteur DNS qui répond aux requêtes, mais comme une couche d'opérations active qui réagit à l'état de santé et forward les requêtes DNS selon le contexte.
Un changement d'état de health-check démarre la chaîne de déclencheurs
Quand l'état de base du scénario HC change, les actions turn ou return peuvent s'exécuter. Quand le scénario s'active, triggerTurnActions s'exécute dans l'ordre ; quand il revient à la normale, triggerReturnActions s'exécute dans l'ordre.
Les déclencheurs HTTP et HTTPS peuvent valider le contenu de la réponse
Les déclencheurs HTTP/HTTPS sont définis avec méthode, URI, en-têtes, corps, codes de statut attendus et timeout. Le corps de la réponse peut être validé avec une vérification de contenu JSONata ou basique pour déterminer si l'action a réussi.
Les déclencheurs Oracle DB exécutent des scénarios de base de données
Les déclencheurs Oracle fonctionnent avec une chaîne de connexion et un tableau d'étapes de scénario. Les étapes wait et executeCmd peuvent exécuter des checks ou des actions contre la base ; les nombres de lignes attendus ou les valeurs texte attendues peuvent être vérifiés.
Le forwarder DNS fournit du routage par domaine et la préservation ECS
Le forwarder peut envoyer des domaines spécifiques vers des cibles DNS spécifiques ; une cible par défaut peut être définie pour le domaine racine. Le pass-through ECS préserve le contexte de subnet client afin que les décisions de routage géo ne soient pas cassées.
Capacités
GTM Triggers and Forwarders réunissent les actions de health-check, la validation HTTP/HTTPS et Oracle, les flux de déclencheurs chaînés et le forwarding DNS sélectif dans un seul modèle de gestion.
Les déclencheurs HTTP sont configurés avec méthode, URI, en-têtes et corps
Un déclencheur HTTP est défini avec adresse de destination, port, méthode de requête, URI, liste d'en-têtes et corps de requête. Une liste de codes de statut attendus détermine si l'appel a réussi. Un timeout limite les appels longs aux systèmes externes. Les cibles HTTP telles que les runbooks DR, les endpoints d'audit ou les systèmes d'alarme peuvent tous être déclenchés via ce modèle.
Une action de déclencheur qui fait plus qu'un changement DNS
Un déclencheur GTM ne se limite pas à orienter des noms. La même décision de santé qui déplace le DNS peut exécuter l'action qui lui est attachée — y compris un switchover Oracle Data Guard : la base suit le trafic au lieu d'attendre une seconde décision d'une seconde équipe. Ce qui serait autrement une conférence téléphonique sur l'ordre des opérations devient un unique mouvement automatique et tracé — déclencheur, action et résultat dans le même journal d'audit.
Les déclencheurs HTTPS effectuent des appels sécurisés avec contrôle de validation de certificat
Un déclencheur HTTPS applique le même modèle de requête que HTTP, sur TLS. Le flag verifyCertificate détermine si le certificat cible est validé. Garder la validation de certificat activée est recommandé en production. Ce motif est utilisé pour livrer les changements de scénario GTM à des systèmes d'action externes sécurisés.
La vérification de contenu JSONata rend la validation du corps de réponse flexible
Les réponses des déclencheurs HTTP/HTTPS peuvent être parsées comme JSON ou XML et validées avec une expression JSONata. Le contexte de l'expression inclut body, bodyRaw, headers et status. Par exemple, même si le système runbook externe renvoie 200, un champ success=true à l'intérieur du corps de réponse peut être vérifié séparément. Cela permet une validation de déclencheur plus robuste qui ne dépend pas du seul code de statut.
La vérification de contenu basique fournit une validation simple par sous-chaîne
Là où JSONata n'est pas nécessaire, une vérification de contenu basique peut être utilisée. Le corps de la réponse est testé pour la présence d'une chaîne spécifique en utilisant la sémantique .includes(). C'est suffisant pour les petites intégrations, les systèmes legacy ou les endpoints qui renvoient une réponse de santé simple. Les opérateurs peuvent valider rapidement sans écrire une expression complexe.
Les déclencheurs Oracle DB exécutent des connexions et des étapes de scénario
Un déclencheur Oracle se connecte à la base avec utilisateur, mot de passe et chaîne de connexion. Les étapes de scénario peuvent inclure des opérations wait et executeCmd. Les nombres de lignes attendus ou les valeurs texte attendues depuis executeCmd peuvent être vérifiés. Ce modèle est utilisé pour cross-valider l'état de la base applicative ou pour exécuter des actions contrôlées côté base de données.
Le chaînage de déclencheurs exécute plusieurs actions en séquence
Les tableaux triggerTurnActions et triggerReturnActions exécutent plusieurs IDs de déclencheur dans l'ordre. Si une action échoue, la chaîne s'interrompt et les actions suivantes ne s'exécutent pas. Cela empêche les étapes de runbook dépendantes d'avancer de manière incontrôlée. Des flux tels qu'écrire d'abord à un endpoint d'audit puis démarrer un job DR peuvent être construits ainsi.
Les directions turn et return gèrent séparément les transitions de scénario
turn représente le moment où le scénario s'active ; return représente le moment où il se désactive et revient à la normale. Une liste de déclencheurs et une condition distinctes peuvent être définies pour chaque direction. Différentes actions peuvent se déclencher pendant le failover et pendant la récupération. Cette séparation permet une conception plus propre des flux opérationnels.
Le nettoyage actif des déclencheurs empêche les anciens processus d'entrer en collision
Quand une nouvelle clé de groupe arrive, les anciens processus de déclencheur peuvent être arrêtés. Le cycle de vie du déclencheur est suivi avec les entrées de log started, succeeded et failed ; après un court délai, l'événement activeTrigger est effacé. Ce comportement réduit le risque que d'anciennes actions entrent en collision avec un nouveau flux quand des changements d'état de santé se produisent en succession rapide. Le service principal reste isolé du fork du déclencheur.
L'exécution du déclencheur est confinée au nœud maître
Dans un cluster, les déclencheurs s'exécutent uniquement sur le nœud maître. Les autres nœuds qui voient le même changement d'état de santé ne re-déclenchent pas l'action externe. Cela empêche le double déclenchement des actions webhook ou DB. Le comportement du cluster devient plus déterministe.
Le forwarder PowerDNS Recursor tourne comme processus séparé sur son propre port
La couche forwarder est positionnée comme un processus recursor séparé. Elle reçoit les requêtes DNS sur la plage forwarderInnerPort et les forward vers les cibles amont définies. Le DNS faisant autorité et le comportement de forwarding recursor sont découplés. Cette séparation permet à TR7 de gérer ses propres zones et la résolution DNS externe de manière contrôlée au sein de la même architecture.
Le forwarding sélectif de domaines définit une cible différente par domaine
La liste domainBasedForwarding permet aux domaines spécifiques d'être dirigés vers des adresses DNS spécifiques. Les domaines internes peuvent aller au DNS corporate ; les autres requêtes peuvent aller au résolveur amont par défaut. Cette conception compte pour les architectures split-DNS et DNS hybrides. Elle dépasse un forwarder grossier qui envoie chaque requête à une seule destination.
Le pass-through ECS préserve le contexte client pour les décisions géo
Le forwarder passe l'information ECS aux résolveurs amont afin qu'ils puissent prendre des décisions avec le contexte de subnet client. Le comportement ECS est contrôlé via les paramètres ecs-ipv4-bits, ecs-add-for et allow-list. Ce contexte est critique pour le routage géo ou les décisions amont basées sur la topologie. Si ECS est abandonné, le routage géographique peut être effectué contre la mauvaise localisation du résolveur.
Profondeur opérationnelle
Les déclencheurs GTM et le forwarder sont exploités conjointement avec le comportement de timeout, le suivi du cycle de vie, l'isolation des processus enfants, la priorité de parsing, l'ordre des forward zones et les lignes de métadonnées.
Comportement de timeout du déclencheur
Le timeout par défaut d'un déclencheur HTTP peut être de 120 secondes. Un déclencheur Oracle peut s'exécuter plus longtemps selon son propre temps de traitement. Le processus global de déclencheur peut être plafonné à 24 heures — une borne supérieure importante pour les runbooks longs ou les scénarios de base multi-étapes.
Comportement de retry
Il n'y a pas de retry automatique dans la chaîne de déclencheurs. Si un déclencheur échoue, la chaîne s'interrompt et les actions suivantes ne s'exécutent pas. Les systèmes cibles doivent donc être conçus pour être idempotents et fiables.
Journalisation du cycle de vie du déclencheur
Les déclencheurs sont journalisés avec les états started, succeeded et failed. Ces enregistrements montrent quelle action a tourné pendant un événement de failover ou de récupération. L'état du déclencheur actif est effacé après un court délai.
Exécution dans un processus séparé
L'exécution du déclencheur peut tourner comme processus enfant séparé. Ce modèle empêche le service GTM principal d'être affecté par des appels externes longs ou des opérations DB. Un déclencheur échouant ne fait pas tomber le service principal.
Priorité de parsing de la réponse
Le corps de réponse HTTP est parsé d'abord comme JSON, puis comme XML, selon le content type. Si ni l'un ni l'autre ne réussit, un fallback en chaîne brute est utilisé. L'expression JSONata est évaluée contre ce contexte.
Ordre des forward zones
Les lignes forward-zones-recurse sont produites dans un ordre défini. La première définition de forward de domaine est écrite comme ligne principale ; les définitions suivantes sont écrites comme lignes additionnelles. Cet ordre compte pour l'application propre du comportement de forwarding sélectif.
Métadonnées du forwarder
Le champ forwarder.metaData porte des lignes de configuration recursor supplémentaires. Il fournit un point d'extension pour des paramètres de cache, politique ou opérationnels personnalisés. Les lignes de métadonnées en usage doivent être soigneusement validées.
Quand l'utiliser
Alarme webhook quand le centre de données primaire tombe
Quand le scénario de health-check s'active, un déclencheur HTTP POST se déclenche. Le système d'alarme ou de gestion d'incidents reçoit la notification de DC down. La décision de failover DNS devient visible pour le système d'opérations externe au même moment.
Lancement automatique de runbook quand le scénario DR s'active
Quand un scénario DR s'active, un déclencheur HTTPS peut démarrer un job dans la plateforme d'automatisation. Le premier déclencheur crée un enregistrement d'audit ; le second déclencheur exécute le job de bring-up DR. Si la chaîne de déclencheurs échoue, l'étape suivante n'avance pas de manière incontrôlée.
Écrire les changements de health-check vers un endpoint d'audit
À chaque événement turn et return, un déclencheur HTTP peut envoyer un enregistrement d'événement vers l'endpoint d'audit. L'information sur quelle zone, quel scénario et à quel moment le changement s'est produit est poussée vers le système de log externe. Les décisions GTM deviennent auditables.
Cross-valider l'état de la base applicative avec un déclencheur Oracle
Quand un heartbeat applicatif échoue, un déclencheur Oracle peut exécuter un check DB indépendant. Si le nombre de lignes attendu ou la valeur texte est renvoyé, l'événement est cross-validé. Cela produit un signal de décision plus fort sans s'appuyer uniquement sur le résultat du health-check HTTP.
Forwarder les requêtes de domaine interne vers le DNS corporate
Les domaines tels que internal.example.com peuvent être forwardés vers des cibles DNS corporate via domainBasedForwarding. Les autres requêtes vont au DNS amont par défaut. Les propres zones faisant autorité de TR7 peuvent être forwardées vers le processus DNS local via localhost.
Utiliser un forwarder sélectif dans une architecture DNS split-horizon
Les clients internes peuvent résoudre les domaines applicatifs internes via le recursor corporate tandis que les clients externes reçoivent les réponses faisant autorité TR7 GTM. Le forwarding sélectif et le pass-through ECS utilisés ensemble découplent les comportements de résolution interne et externe. L'architecture DNS n'est pas verrouillée dans un forwarding unidirectionnel.
Questions fréquentes
Quels types de déclencheurs GTM supporte-t-il ?
Que se passe-t-il quand une chaîne de déclencheurs échoue sur une action ?
Quel nœud exécute les déclencheurs dans un cluster ?
Comment le forwarder DNS préserve-t-il l'information ECS ?
Comment le forwarding sélectif de domaines est-il configuré ?
Comment fonctionne la validation de réponse des déclencheurs HTTP/HTTPS ?
Connectez les décisions de failover GTM à vos systèmes externes
Chaînes de déclencheurs HTTP/HTTPS et Oracle DB, forwarding DNS sélectif et un recursor conscient d'ECS. Parcourons un déploiement en direct dans votre propre environnement.