Das Standard-GSLB-Muster sieht so aus: einen Endpunkt überwachen, wenn er unhealthy wird, DNS-Antworten auf das Backup verlagern, wenn er healthy wird, zurückverlagern. Implementierungen großer GSLB-Anbieter behandeln beide Übergänge als Umkehrung derselben Bedingung.
Die Produktionsrealität ist nicht symmetrisch. Ein Failover auf ein Backup ist ein defensiver Schritt unter Druck; die Rückkehr zum Primärsystem ist ein offensiver Schritt unter Vertrauen. Die Bedingungen, die Wartezeiten, die Operator-Freigaben und die auszulösenden Trigger unterscheiden sich in jeder Richtung.
Beispiele: schnell rein / langsam raus — Failover beim ersten erkannten Fehler, um den Benutzer zu schützen, aber 15 Minuten saubere Health-Werte vor der Rückkehr verlangen, um Flapping zu vermeiden. Vorsichtig rein / schnell raus — drei aufeinanderfolgende Fehler vor dem Failover verlangen, aber sofort zurückkehren, sobald das Primärsystem wiederhergestellt ist, um RPO/RTO-Zusagen einzuhalten. Auto rein / manuell raus — Failover ist automatisiert, der Rückweg erfordert jedoch SRE-Bestätigung nach Runbook-Prüfung.
Keines dieser Muster lässt sich in einem einseitigen Szenario ausdrücken. Der Operator wählt entweder eine Richtung und lebt mit der falschen Richtlinie in der anderen, oder verkettet brüchige Custom-Skripte, die von der Wahrheitsquelle des GSLB abweichen.
Bidirektionale Szenarien von TR7 GTM erlauben Aktivierung und Deaktivierung mit unabhängigen Bedingungen, unabhängigen Gating-Prüfungen und unabhängigen Trigger-Aktionen — die Richtlinienstruktur, die Ihr Incident-Response-Runbook bereits voraussetzt.
Ein Szenario ist ein benannter, wiederverwendbarer Zustandsautomat mit zwei Richtungen. Jede Richtung wird durch einen kombinierten Bedingungsausdruck und einen Trigger-Satz definiert; die beiden Richtungen müssen keine Umkehrungen voneinander sein.
Ein kombinierter Bedingungsausdruck wertet die zugrunde liegenden Health Checks aus. Wenn er true zurückgibt, aktiviert sich das Szenario. Optionale Trigger lösen Aktionen aus (HTTP/HTTPS-Webhooks, Oracle-Abfragen) und eine optionale Gating-Prüfung bestätigt, dass der Trigger fortgesetzt werden soll.
Ein separater kombinierter Bedingungsausdruck wertet einen separaten Satz von Health Checks aus. Der Deaktivierungspfad kann die Umkehrung der Aktivierung sein oder zusätzliche Stabilität, zusätzliche Sonden oder gänzlich andere Trigger verlangen.
Bedingungen sind keine einzelnen Booleans — sie sind Gruppen von Health-Check-Ergebnissen, die innerhalb einer Gruppe mit AND und über Gruppen hinweg mit OR verknüpft sind, mit optionaler Negation. Dieselbe DSL, die die Traffic-Rule-Logik auf dem ADC steuert, steuert hier auch die Szenarioauswertung.
Ein Szenario wird einmal definiert und namentlich von DNS-Records, Disaster-Recovery-Konfigurationen und Cross-DC-Failover-Richtlinien referenziert. Operatoren erstellen dieselbe Logik nicht an mehreren Stellen neu.
Bidirektionale Szenarien sind die Grundlage der Failover- und Recovery-Richtlinien von TR7 GTM.
Die Aktivierungsbedingung wird aus Health-Check-Ergebnissen über ein oder mehrere Health-Check-Profile gebildet. Gruppen verknüpfen Prüfungen mit AND; mehrere Gruppen werden mit OR verbunden. Jede einzelne Prüfung kann negiert werden. Operatoren drücken Bedingungen wie "(API ist up AND Datenbank ist up) OR (Failover-Pfad A ist up AND Failover-Pfad B ist up)" ohne Skripte aus.
Die Deaktivierungsbedingung ist unabhängig von der Aktivierung. Operatoren drücken Bedingungen wie "Primärsystem ist seit 15 Minuten gesund AND Latenz liegt unter dem Schwellwert" aus, während die Aktivierung möglicherweise einfach "Primärsystem ist down" war.
Aktivierungstrigger und Deaktivierungstrigger sind separat auswählbare Sätze. Ein Aktivierungsereignis kann den diensthabenden SRE benachrichtigen; ein Deaktivierungsereignis kann den SRE benachrichtigen, eine synthetische Transaktion ausführen und einen Webhook an das Deployment-System senden.
Eine optionale Gating-Bedingung läuft vor der Ausführung der Trigger jeder Richtung. Gibt die Gating-Prüfung false zurück, findet der Zustandsübergang dennoch statt, die Trigger werden jedoch nicht ausgelöst. Anwendungsfall: Zustandsübergänge laufen automatisch, externe Benachrichtigungen jedoch nur während der Geschäftszeiten.
Jede Richtung unterstützt drei vom Operator wählbare Modi. Auto folgt dem Bedingungsausdruck. On erzwingt die Aktivierung der Richtung unabhängig von den Bedingungen (manueller Override). Off deaktiviert die Richtung vollständig (z. B. Failback während eines Wartungsfensters deaktivieren).
Wenn zwei Rechenzentren definiert sind, generiert TR7 GTM automatisch vier Szenarien pro Paar: from-active, to-active, from-backup, to-backup — jedes mit passender Bedingungslogik auf Basis von WAN-Zugriff, LAN-Zugriff und Internet-Erreichbarkeitsprüfungen. Operatoren können die generierten Szenarien unverändert übernehmen, anpassen oder eigene von Grund auf erstellen.
Der healthy/unhealthy-Status von DNS-Records kann durch ein Szenario statt durch einen statischen Boolean oder einen einzelnen Health Check bestimmt werden. Das Per-Record-Feld `cond` akzeptiert eine Szenarioreferenz: Wenn das Szenario aktiviert wird, wird der Record aus den Antworten ausgeschlossen; wenn es deaktiviert wird, kehrt der Record zurück.
Disaster-Recovery-Records können `drCond` angeben — ein Szenario, das bestimmt, wann der DR-Record-Satz den Primär-Record-Satz in den Antworten ersetzt. Die DR-Szenarioauswertung ist bidirektional und unterstützt kontrollierten Failover und kontrolliertes Failback.
Trigger werden als HTTP/HTTPS-Aufrufe (benutzerdefinierte URI, Methode, Header, Body, erwartete Statuscodes, Content-Match-Abfrage) oder Oracle-Datenbankaufrufe (konfiguriertes SQL) ausgeführt. Operatoren binden Szenarioaktivierungen an bestehende Incident-Management-, Deployment- oder Audit-Pipelines an.
Jeder Szenario-Zustandswechsel wird aufgezeichnet: welche Richtung ausgelöst hat, welche Bedingungen true/false ausgewertet wurden, welche Trigger gelaufen sind, welche Gating-Prüfung bestanden wurde. Die Post-Incident-Analyse rekonstruiert die exakte Abfolge automatischer Entscheidungen ohne manuelle Log-Archäologie.
Szenarien werden gemeinsam mit Health-Check-Definitionen, Trigger-Konfigurationen, DNS-Record-Bindungen und Disaster-Recovery-Konfigurationen betrieben.
Innerhalb einer Bedingungsgruppe müssen alle aufgeführten Prüfungen true ergeben (AND). Über Gruppen hinweg reicht eine einzelne Gruppe, die true ergibt (OR). Das Suffix `!` an einer Prüf-ID negiert sie. Die Gruppierungsstruktur ist symmetrisch für Aktivierung und Deaktivierung; jede Richtung hat ihren eigenen Gruppen-Satz.
Bedingungen referenzieren Health Checks per ID. Benutzerdefinierte Health-Check-Profile und automatisch generierte DC-Paar-Prüfungen teilen denselben ID-Raum. Operatoren mischen manuelle und automatische Prüfungen in derselben Bedingungsgruppe.
Wenn die Aktivierung auf on gezwungen wird (manueller Override), läuft die Deaktivierungsauswertung typischerweise weiter — Operatoren können manuell aktivieren und dann die Deaktivierungsbedingung entscheiden lassen, wann wiederhergestellt wird. Beide Richtungen auf on zu zwingen erzeugt einen festgefahrenen Zustand und wird als Konfigurationswarnung protokolliert.
Trigger werden mit einer strukturierten Payload ausgeführt, die Szenario-ID, Richtung, Auswertungs-Timestamp und den Konfigurations-Snapshot zum Triggerzeitpunkt enthält. Trigger-Fehler (HTTP non-2xx, Oracle-Fehler) werden protokolliert und optional pro Trigger-Profil wiederholt.
Szenarien werden bei jedem Health-Check-Statuswechsel ausgewertet, nicht auf einem Polling-Timer. Der erste Statuswechsel, der eine Aktivierungs- oder Deaktivierungsschwelle überschreitet, löst den Übergang aus. Die Auswertungskosten bleiben gering, da Bedingungen vorab berechnete Health-Zustände referenzieren.
Operatoren sehen den aktuellen Zustand jedes Szenarios (aktiviert / deaktiviert), den Zeitpunkt des letzten Übergangs, das letzte Auswertungsergebnis für jede Bedingungsgruppe und die Trigger-Ergebnisse. Das Dashboard zeigt festgefahrene Übergänge und konfliktäre Overrides.
Failover beim ersten erkannten Fehler aktivieren, um den Benutzer zu schützen. Erst nach 15 Minuten sauberer Primär-Health deaktivieren, um Flapping zu vermeiden. Unterschiedliche Bedingungen, unterschiedliches Timing — dasselbe Szenarioobjekt.
Der Failover ist automatisiert; der Rückweg erfordert eine SRE-Bestätigung. Die Deaktivierungsrichtung steht auf off; ein Operator setzt sie nach Runbook-Prüfung manuell auf on. Die Aktivierung läuft weiterhin automatisch.
DC A → DC B Failover löst einen HTTP-Webhook an das Incident-Management-System aus. DC B → DC A Failback löst denselben Webhook plus einen Aufruf des Deployment-Systems zur Cache-Aufwärmung aus. Trigger sind in jeder Richtung unabhängig.
Verwenden Sie den Oracle-Trigger, um vor dem Failover eine Datenbank abzufragen — etwa um zu bestätigen, dass die Backup-Datenbank per Log-Shipping aufgeholt hat. Das Trigger-Ergebnis steuert den tatsächlichen Zustandsübergang.
Gehen Sie ein bidirektionales Szenario auf Basis Ihres eigenen Runbooks durch: schnell rein / langsam raus, manuelles Failback, asymmetrische Trigger-Sätze — Ihre Richtlinie, nicht der Plattform-Standard.