Le schéma GSLB standard ressemble à ceci : surveiller un endpoint, lorsqu'il devient malsain basculer les réponses DNS vers le secours, lorsqu'il redevient sain rebasculer. Les implémentations des principaux fournisseurs GSLB traitent les deux transitions comme l'inverse de la même condition.
La réalité de production n'est pas symétrique. Basculer vers un secours est un geste défensif exécuté sous pression ; revenir au primaire est un geste offensif exécuté en confiance. Les conditions, les fenêtres d'attente, les approbations opérateur et les déclencheurs qui doivent être émis sont différents dans chaque direction.
Exemples : rapide-entrée / lent-sortie — failover dès la première erreur détectée pour protéger l'utilisateur, mais exiger 15 minutes de santé propre avant de revenir afin d'éviter un flap. Conservateur-entrée / rapide-sortie — exiger trois échecs consécutifs avant d'initier le failover, mais revenir immédiatement quand le primaire récupère pour respecter les engagements RPO/RTO. Auto-entrée / manuel-sortie — le failover est automatisé, mais le chemin de retour requiert l'acquittement SRE après revue du runbook.
Aucun de ces cas n'est exprimable dans un scénario unidirectionnel. L'opérateur choisit une direction et vit avec la mauvaise politique dans l'autre, ou bricole des scripts personnalisés fragiles qui dérivent de la source de vérité du GSLB.
Les scénarios bidirectionnels TR7 GTM permettent à l'activation et à la désactivation de porter des conditions indépendantes, des contrôles de gating indépendants et des actions de déclencheur indépendantes — la structure de politique que votre runbook de réponse aux incidents suppose déjà.
Un scénario est une machine d'état nommée et réutilisable avec deux directions. Chaque direction est définie par une expression de condition combinée et un ensemble de déclencheurs ; les deux directions n'ont pas besoin d'être inverses.
Une expression de condition combinée évalue les health-checks sous-jacents. Quand elle renvoie vrai, le scénario s'active. Des déclencheurs optionnels exécutent des actions (webhooks HTTP/HTTPS, requêtes Oracle) et un contrôle de gating optionnel confirme que le déclencheur doit s'exécuter.
Une expression de condition combinée distincte évalue un ensemble distinct de health-checks. Le chemin de désactivation peut être l'inverse de l'activation, ou peut exiger une stabilité supplémentaire, des sondes supplémentaires, ou des déclencheurs entièrement différents.
Les conditions ne sont pas de simples booléens — ce sont des groupes de résultats de health-check joints par AND à l'intérieur d'un groupe et par OR entre les groupes, avec négation optionnelle. Le même DSL qui pilote la logique des règles de trafic sur l'ADC pilote également l'évaluation des scénarios ici.
Un scénario est défini une fois et référencé par son nom depuis les enregistrements DNS, les configurations de reprise après sinistre et la politique de failover inter-DC. Les opérateurs ne réécrivent pas la même logique à plusieurs endroits.
Les scénarios bidirectionnels sont le fondement de la politique de failover et de récupération de TR7 GTM.
La condition d'activation est construite à partir des résultats de health-check d'un ou plusieurs profils. Les groupes joignent les checks par AND ; plusieurs groupes se joignent par OR. Chaque check individuel peut être nié. Les opérateurs expriment des conditions comme « (API est up AND base est up) OR (chemin failover A est up AND chemin failover B est up) » sans scripting.
La condition de désactivation est indépendante de l'activation. Les opérateurs expriment des conditions comme « le primaire est sain depuis 15 minutes AND la latence est sous le seuil » alors que l'activation peut avoir été simplement « le primaire est down ».
Les déclencheurs d'activation et de désactivation sont des ensembles sélectionnables distincts. Un événement d'activation peut notifier le SRE d'astreinte ; un événement de désactivation peut notifier le SRE, exécuter une transaction synthétique et émettre un webhook vers le système de déploiement.
Une condition de gating optionnelle s'exécute avant que les déclencheurs de chaque direction ne s'exécutent. Si le gating renvoie faux, la transition d'état a tout de même lieu mais les déclencheurs ne sont pas émis. Cas d'usage : les transitions d'état sont automatiques, mais les notifications externes ne sont émises qu'en heures ouvrées.
Chaque direction supporte trois modes sélectionnables par l'opérateur. Auto suit l'expression de condition. On force la direction à s'activer indépendamment des conditions (surcharge manuelle). Off désactive entièrement la direction (par exemple, désactiver le failback pendant une fenêtre de maintenance).
Lorsque deux centres de données sont définis, TR7 GTM génère automatiquement quatre scénarios par paire : from-active, to-active, from-backup, to-backup — chacun avec une logique de condition appropriée basée sur l'accès WAN, l'accès LAN et l'accessibilité Internet. Les opérateurs peuvent utiliser les scénarios auto-générés tels quels, les personnaliser ou créer les leurs.
Les enregistrements DNS peuvent voir leur état sain/malsain piloté par un scénario plutôt que par un booléen statique ou un health-check unique. Le champ `cond` par enregistrement accepte une référence de scénario : lorsque le scénario s'active, l'enregistrement est exclu des réponses ; lorsqu'il se désactive, l'enregistrement revient.
Les enregistrements de reprise après sinistre peuvent spécifier `drCond` — un scénario qui détermine quand l'ensemble d'enregistrements DR remplace l'ensemble primaire dans les réponses. L'évaluation du scénario DR est bidirectionnelle, supportant un failover et un failback contrôlés.
Les déclencheurs s'exécutent sous forme d'appels HTTP/HTTPS (URI, méthode, en-têtes, corps, codes de statut attendus, requête de correspondance de contenu personnalisés) ou d'appels de base Oracle (SQL configuré). Les opérateurs branchent les activations de scénarios sur les pipelines existants de gestion d'incidents, de déploiement ou d'audit.
Chaque changement d'état de scénario est enregistré : quelle direction s'est déclenchée, quelles conditions ont été évaluées vraies/fausses, quels déclencheurs ont été exécutés, quel contrôle de gating a été validé. La revue post-incident reconstruit la séquence exacte des décisions automatisées sans archéologie manuelle des logs.
Les scénarios sont exploités conjointement avec les définitions de health-check, les configurations de déclencheurs, les liaisons d'enregistrements DNS et les configurations de reprise après sinistre.
À l'intérieur d'un groupe de conditions, tous les checks listés doivent être évalués vrais (AND). Entre groupes, qu'un seul groupe soit vrai suffit (OR). Le suffixe `!` sur un ID de check le nie. La structure de regroupement est symétrique pour l'activation et la désactivation ; chaque direction a son propre ensemble de groupes.
Les conditions référencent les health-checks par ID. Les profils de health-check définis par l'utilisateur et les checks auto-générés des paires DC partagent le même espace d'ID. Les opérateurs mixent checks manuels et auto dans le même groupe de conditions.
Lorsque l'activation est forcée à on (surcharge manuelle), l'évaluation de la désactivation continue généralement — les opérateurs peuvent activer manuellement, puis laisser la condition de désactivation décider quand restaurer. Forcer les deux directions à on crée un état bloqué et est journalisé comme avertissement de configuration.
Les déclencheurs émettent une charge utile structurée portant l'ID du scénario, la direction, l'horodatage d'évaluation et le snapshot de configuration au moment du déclenchement. L'échec d'un déclencheur (HTTP non-2xx, erreur Oracle) est journalisé et optionnellement réessayé selon le profil du déclencheur.
Les scénarios sont évalués à chaque changement d'état de health-check, et non sur une horloge de polling. Le premier changement d'état qui franchit un seuil d'activation ou de désactivation déclenche la transition. Le coût d'évaluation reste faible car les conditions référencent des états de santé pré-calculés.
Les opérateurs voient l'état courant de chaque scénario (activé / désactivé), l'heure de la dernière transition, le dernier résultat d'évaluation pour chaque groupe de conditions et les résultats des déclencheurs. Le tableau de bord met en évidence les transitions bloquées et les surcharges conflictuelles.
Activer le failover dès la première erreur détectée pour protéger l'utilisateur. Désactiver seulement après 15 minutes de santé primaire propre pour éviter un flap. Conditions différentes, timing différent — même objet scénario.
Le failover est automatisé ; le chemin de retour requiert l'acquittement SRE. La direction de désactivation est placée à off ; un opérateur la bascule manuellement à on après revue du runbook. L'activation continue à s'évaluer automatiquement.
Le failover DC A → DC B déclenche un webhook HTTP vers le système de gestion d'incidents. Le failback DC B → DC A déclenche le même webhook plus un appel au système de déploiement pour réchauffer les caches. Les déclencheurs dans chaque direction sont indépendants.
Utilisez le déclencheur Oracle pour interroger une base de données avant le failover — par exemple, confirmer que la base de secours a rattrapé via le log shipping. Le résultat du déclencheur conditionne la transition d'état réelle.
Parcourez un scénario bidirectionnel construit sur votre propre runbook : rapide-entrée / lent-sortie, failback manuel, ensembles de déclencheurs asymétriques — votre politique, pas celle par défaut de la plateforme.