Les scénarios unidirectionnels imposent une politique symétrique là où la réalité métier est asymétrique.
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à.
Notre approche
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.
Direction d'activation — quand le scénario s'active
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.
Direction de désactivation — quand le scénario se désactive
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.
Conditions combinées avec groupes AND/OR
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.
Réutilisable sur les enregistrements, domaines et paires de centres de données
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.
Capacités
Les scénarios bidirectionnels sont le fondement de la politique de failover et de récupération de TR7 GTM.
Expression d'activation à conditions combinées
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.
Expression de désactivation à conditions combinées
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 ».
Ensembles de déclencheurs indépendants par direction
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.
Contrôle de gating avant l'émission des déclencheurs
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.
Trois modes de bascule par direction : auto / on / off
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).
Scénarios auto-générés pour les paires de DC
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.
État de santé des enregistrements DNS piloté par scénario
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.
Reprise après sinistre pilotée par scénario
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.
Déclencheurs HTTP, HTTPS et Oracle
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.
Piste d'audit par transition d'état
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.
Profondeur opérationnelle
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.
Sémantique des groupes de conditions
À 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.
Espace d'ID de checks combiné
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.
Interaction du mode de bascule avec la désactivation
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.
Charge utile des déclencheurs et comportement de retry
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.
Cadence d'évaluation des scénarios
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.
Visibilité de l'état courant du scénario
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.
Quand l'utiliser
Failover rapide-entrée / lent-sortie
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.
Failover auto, failback manuel
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.
Politique de failover inter-DC asymétrique
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.
Scénarios sensibles à la base de données
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.
Questions fréquentes
Puis-je rendre les conditions d'activation et de désactivation identiques ?
Que se passe-t-il si les conditions d'activation et de désactivation sont vraies en même temps ?
En quoi les déclencheurs diffèrent-ils des health-checks sous-jacents ?
Les scénarios bidirectionnels ajoutent-ils de la latence au failover ?
Un scénario peut-il référencer un autre scénario ?
Définissez le chemin aller et le chemin retour, indépendamment.
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.