Funktion

Bidirektionale Health-Check-Szenarien

Getrennte Richtlinien für den Eintritt in den Failover und die Rückkehr in den Normalbetrieb — Symmetrie ist eine Wahl, kein Standard.

Die meisten GSLB-Plattformen behandeln Health-Check-Szenarien als einseitige Zustandsautomaten: Eine Bedingung wird wahr, der Datenverkehr verschiebt sich. Dieselbe Bedingung wird falsch, der Datenverkehr verschiebt sich zurück. Diese Symmetrie ist bequem — und häufig falsch. Der reale Weg in einen Failover ist selten derselbe wie der Weg zurück. TR7 GTM-Szenarien definieren die Aktivierungs- und die Deaktivierungsrichtung unabhängig voneinander. Jede Richtung trägt ihren eigenen Bedingungsausdruck (kombinierte AND/OR-Gruppen über Health-Check-Ergebnisse hinweg), ihren eigenen Satz an auszulösenden Triggern und ihre eigene Gating-Prüfung. Operatoren entscheiden: Kehren wir zurück in den Normalbetrieb, sobald das Primärsystem wiederhergestellt ist, oder warten wir auf ein erweitertes Stabilitätsfenster? Führen wir vor der Rückleitung des Datenverkehrs eine synthetische Transaktion erneut aus? Verschickt ein Aktivierungsereignis eine E-Mail an das SRE-Team, während ein Deaktivierungsereignis zusätzlich einen Deployment-Hook auslöst? Dieses Design ermöglicht es Unternehmen, die asymmetrischen Richtlinien auszudrücken, die sie tatsächlich wollen — schnell rein, langsam raus aus Sicherheitsgründen; vorsichtig rein, schnell raus unter SLA-Druck; manuelle Bestätigung auf dem Rückweg, während der Failover automatisiert bleibt. Das Szenario selbst ist wiederverwendbar: an mehrere DNS-Records gebunden, an Disaster-Recovery-Flows angehängt, über Rechenzentrumspaare hinweg referenziert. Operatoren beschreiben den Zustandsautomaten einmal; die Plattform wendet ihn überall an, wo er referenziert wird.

2-fach

Unabhängige Aktivierungs- und Deaktivierungspfade

AND / OR

Kombinierter Bedingungsausdruck mit Negation

Auto + Benutzer

Auto-generierte DC-Paar-Szenarien + benutzerdefinierte Szenarien

Wiederverwendbar

Ein Szenario an viele Records, DR-Flows und DCs binden

Einseitige Szenarien erzwingen symmetrische Richtlinien dort, wo die geschäftliche Realität asymmetrisch ist.

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.

Unser Ansatz

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.

Aktivierungsrichtung — wenn das Szenario eingeschaltet wird

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.

Deaktivierungsrichtung — wenn das Szenario abgeschaltet wird

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.

Kombinierte Bedingungen mit AND/OR-Gruppen

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.

Wiederverwendbar über Records, Domains und Rechenzentrumspaare hinweg

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.

Funktionen

Bidirektionale Szenarien sind die Grundlage der Failover- und Recovery-Richtlinien von TR7 GTM.

Aktivierungsausdruck mit kombinierter Bedingung

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.

Deaktivierungsausdruck mit kombinierter Bedingung

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.

Unabhängige Trigger-Sätze pro Richtung

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.

Gating-Prüfung vor dem Auslösen der Trigger

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.

Drei Schaltmodi pro Richtung: auto / on / off

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).

Automatisch generierte Szenarien für DC-Paare

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.

Szenariogesteuerter Health-Status von DNS-Records

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.

Szenariogesteuertes Disaster Recovery

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.

HTTP-, HTTPS- und Oracle-Trigger

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.

Audit-Trail pro Zustandsübergang

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.

Betriebliche Tiefe

Szenarien werden gemeinsam mit Health-Check-Definitionen, Trigger-Konfigurationen, DNS-Record-Bindungen und Disaster-Recovery-Konfigurationen betrieben.

Semantik der Bedingungsgruppen

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.

Gemeinsamer ID-Raum für Prüfungen

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.

Wechselwirkung des Schaltmodus mit der Deaktivierung

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-Payload und Retry-Verhalten

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.

Auswertungsfrequenz der Szenarien

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.

Sichtbarkeit des aktuellen Szenariozustands

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.

Wann einsetzen

Schnell-rein / langsam-raus Failover

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.

Automatischer Failover, manuelles Failback

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.

Asymmetrische Inter-DC-Failover-Richtlinie

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.

Datenbankbewusste Szenarien

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.

Häufig gestellte Fragen

Kann ich Aktivierungs- und Deaktivierungsbedingungen identisch machen?

Ja — das ergibt das klassische einseitige Verhalten. Die bidirektionale Struktur ist opt-in; verwenden beide Richtungen denselben Bedingungsausdruck, verhält sich das Szenario wie ein klassisches On/Off-Szenario. Die Architektur erlaubt es, asymmetrische Richtlinien dort auszudrücken, wo Sie sie wollen, ohne sie zu erzwingen.

Was passiert, wenn Aktivierungs- und Deaktivierungsbedingungen gleichzeitig true ergeben?

Die Aktivierung gewinnt. Das Szenario wechselt in den aktiven Zustand und bleibt aktiv, bis die Deaktivierungsbedingung true und die Aktivierungsbedingung false ist. Dies verhindert Oszillationen in Randfällen, in denen sich Bedingungen überlappen.

Wie unterscheiden sich Trigger von den zugrunde liegenden Health Checks?

Health Checks bewerten den Endpunktstatus. Trigger sind Aktionen, die beim Szenarioübergang ausgelöst werden. Trigger können HTTP/HTTPS-Aufrufe (Webhooks) oder Oracle-Datenbankaufrufe sein. Health Checks bestimmen den Szenariozustand; Trigger kommunizieren diesen Zustandswechsel an externe Systeme.

Erhöhen bidirektionale Szenarien die Failover-Latenz?

Nein. Zustandsübergänge werden bei jedem Health-Check-Wechsel ausgewertet, nicht auf einem Polling-Timer. Das erste Health-Check-Ergebnis, das den Schwellwert überschreitet, kippt das Szenario. Die bidirektionale Struktur fügt Richtlinienausdrucksstärke hinzu, keine Latenz.

Kann ein Szenario ein anderes Szenario referenzieren?

Bedingungen referenzieren Health Checks (manuell oder automatisch). Eine Szenario-of-Szenarien-Komposition ist nicht direkt ausdrückbar; komplexe Richtlinien werden stattdessen durch Bindung von Szenarien an Records und Disaster-Recovery-Konfigurationen aufgebaut, die selbst an einer übergeordneten Entscheidungslogik teilnehmen.

Definieren Sie den Weg hinein und den Weg zurück unabhängig voneinander.

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.