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.
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.
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/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 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
À 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.
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.
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.
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.
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.