Der häufigste GTM-Fehler ist, die Rechenzentrums-Health mit einem einzelnen up/down-Flag zu verwalten. In Wirklichkeit kann ein Rechenzentrum erreichbar sein, während die Anwendung down ist; die Anwendung kann antworten, während die Datenbank nicht arbeitet; der WAN-Link kann offen sein, während der LAN-seitige Zugriff ausgefallen ist. Ein Single-Flag-Health-Modell kann diese Unterschiede nicht erfassen.
In vielen Organisationen ist die Verbindung zwischen Health Checks und DNS-Antworten manuell oder fragmentiert. Ein Monitoring-System löst einen Alert aus, ein Operations-Team führt ein Skript aus, ein DNS-Record wird manuell aktualisiert oder eine separate Automatisierung übernimmt. Diese Kette reagiert langsam und ist in kritischen Momenten anfällig für menschliche Fehler.
Komplexe Szenarien sind noch schwieriger. Bedingungen wie "DC1 aktivieren, wenn es Internetzugriff hat und nicht in Wartung ist; sonst einen Backup-Record zurückgeben, wenn die Anwendungs-Health von DC2 oder der Zugriff von DC3 positiv ist" werden meist über YAML-Dateien, Skripte und manuelle Abhängigkeiten verwaltet. Das macht eine GTM-Entscheidung zu einem schwer verständlichen oder auditierbaren Betriebs-Labyrinth.
Flapping ist ein reales Risiko. Wenn ein Health Check kurz fehlschlägt und DNS sich sofort ändert, wird Benutzerverkehr unnötig in eine andere Region verschoben. Ebenso kann ein kurzer Erfolg Traffic zurückziehen, bevor das Problem vollständig gelöst ist. Schwellwerte für aufeinanderfolgende Erfolge und Fehler sowie State-Preservation-Logik sind daher essenziell.
TR7-Health-Check-Szenarien kombinieren Rechenzentrums-, Anwendungs-, Datenbank-, Wartungsmodus- und Custom-Checks zu einer einzigen booleschen Entscheidungsschicht und binden DNS-Antworten direkt an die reale Service-Health.
TR7 wertet GTM-Health-Entscheidungen aus, indem es automatische Rechenzentrumsprüfungen, manuelle Health Checks und Szenariologik in einem einheitlichen Modell kombiniert.
Automatische Prüfungen pro Rechenzentrum, benutzerdefinierte HTTP-/HTTPS-/Oracle-Checks und ADC-Health-Ergebnisse können alle innerhalb derselben Entscheidungsstruktur verwendet werden. Damit werden Infrastruktur- und Anwendungs-Health zu einer einzigen GTM-Entscheidung verbunden.
Szenarien werden mit AND- und OR-Gruppen aufgebaut. Das Anhängen von `!` an eine Health-Check-Kennung negiert die Bedingung, sodass Zustände wie der Wartungsmodus als negative Bedingungen in derselben Entscheidung verwendet werden können.
Health Check, Szenario und DNS-Record-Beziehungen werden über graphartige Maps nachverfolgt. Bei einem Statuswechsel werden nur die betroffenen Szenarien und Records neu ausgewertet.
HTTP- und HTTPS-Health-Checks können Statuscodes und Response-Inhalte verifizieren, nicht nur ob ein Port offen ist. JSONata-Ausdrücke oder einfache Content-Checks bestätigen, dass die Anwendung tatsächlich eine gesunde Antwort zurückgibt.
TR7-Health-Check-Szenarien decken ein Spektrum an GTM-Anforderungen ab — von einfachen Zugriffsprüfungen bis hin zu mehrschichtigen Anwendungs- und Rechenzentrumsentscheidungen.
TR7 unterstützt für HTTP- und HTTPS-Checks Parameter wie Methode, URI, Body, Header, erwartete Statuscodes, Zertifikatsprüfung und Timeout. Der Check misst daher nicht nur, ob eine Verbindung aufgebaut werden kann — er verifiziert auch, dass die Anwendung die korrekte Antwort vom korrekten Endpunkt zurückgibt, was die GTM-Entscheidung näher an das reale Anwendungsverhalten bringt.
Für Health-Endpunkte, die JSON zurückgeben, können bestimmte Felder mit einem JSONata-Ausdruck bewertet werden. Ein Ausdruck wie `status = "ok"` bestätigt nicht nur, dass die Anwendung antwortet, sondern dass sie den erwarteten Health-Status zurückgibt. Der Response-Body wird in die passende Struktur geparst und der Ausdruck darauf ausgewertet. Das ergibt eine zuverlässigere Health-Messung für moderne, JSON-API-basierte Anwendungen.
Für unkomplizierte Szenarien kann der Response-Body auf das Vorhandensein eines bestimmten Strings geprüft werden. Dieser Ansatz reicht für einfache Anwendungs-Health-Checks, die keinen vollständigen JSONata-Ausdruck benötigen. Operations-Teams können die DNS-Entscheidung an die Bestätigung binden, dass ein bekanntes Wort oder ein fester Zustand in der Anwendungsantwort erscheint, was die Prüfungen schnell und leicht verständlich macht.
Oracle-Checks werden über ein Szenario konfiguriert, das Schritte für Verbindungsaufbau, Warten und Befehlsausführung enthält. Ergebnisse werden anhand eines erwarteten Row-Counts oder erwarteten Texts bewertet. Damit lassen sich DNS-Antworten nicht nur an die Anwendungsschicht, sondern auch an die Datenbankerreichbarkeit binden, was den toten Winkel "Anwendung läuft, aber die Datenbank arbeitet nicht" in kritischen Geschäftsanwendungen reduziert.
TR7 kann pro Rechenzentrum die Checks `wanAccess`, `lanAccess`, `access`, `internet` und `maintenanceMode` verwenden. Diese Checks repräsentieren unabhängig verschiedene Zugriffs- und Betriebszustände jedes Rechenzentrums. Zustände wie der Wartungsmodus können in einem Szenario als negative Bedingungen statt als positive Health-Signale behandelt werden, sodass DNS-Entscheidungen die operative Realität näher abbilden.
Szenarien werden mit Bedingungsgruppenstrukturen aufgebaut; Bedingungen innerhalb einer Gruppe folgen AND-Logik, während Inter-Gruppen-Beziehungen OR oder AND sein können. Das Anhängen von `!` an eine Health-Check-Kennung invertiert die Bedingung und ermöglicht Konstrukte wie `dcAccess AND NOT maintenanceMode`. Komplexe GTM-Entscheidungen lassen sich ohne Skripte entwerfen.
Für Health Checks können die Werte `requiredSuccess` und `requiredFailure` konfiguriert werden. Der Default-Ansatz zählt aufeinanderfolgende Erfolge oder Fehler, bevor ein Statuswechsel akzeptiert wird. Das verhindert, dass kurzzeitiger Paketverlust, kurze Latenzspitzen oder vorübergehende Service-Schwankungen die DNS-Antwort sofort verändern, was das GTM-Verhalten stabiler macht.
Health-Check-Zustände können in einer lokalen Datei persistiert und beim Systemneustart wiederhergestellt werden. Damit müssen nicht alle Health-Zustände nach jedem Neustart neu gelernt werden. Diese Kontinuität ist besonders in größeren GTM-Umgebungen mit vielen Szenarien und Records wichtig und gibt Operations-Teams ein berechenbareres Verhalten nach einem Neustart.
TCP-, UDP-, HTTP-, HTTPS-, PING-, DNS-, FTP-, FTPS-, LDAP-, LDAPS- und Oracle-Health-Checks sind im TR7-Ökosystem verfügbar. Die Koordination von GTM- und ADC-Health-Ergebnissen lässt DNS-Entscheidungen den wahren Zustand der Service-Schicht widerspiegeln. Diese breite Typunterstützung erlaubt es, ein Health-Modell nicht nur für Webanwendungen, sondern für Multi-Protokoll-Unternehmensdienste aufzubauen. Auch skriptartige TCP-Send/Receive-Szenarien stehen für individuelle Prüfungsanforderungen zur Verfügung.
Damit Health-Check-Szenarien zuverlässig arbeiten, müssen Identifier-Format, State-Persistenz, Trigger-Reihenfolge, Master-Node-Kontrolle und Änderungsausbreitung klar verwaltet sein.
Die Szenario-Engine kann Health-Check-Typen wie static, dcCheck, http, https und oracle auswerten. Kombiniert mit der breiteren GTM- und ADC-Health-Check-Familie lassen sich Multi-Protokoll-Service-Zustände in die Entscheidungsstruktur bringen — wichtig für Service-Architekturen, die nicht auf einen einzigen HTTP-Check-Typ beschränkt sind.
Automatische Health Checks pro Rechenzentrum werden im Format `auto|
Benutzerdefinierte Health Checks werden mit eindeutigen Identifiern erstellt. Diese Identifier können direkt in Szenariobedingungen referenziert werden, sodass derselbe HTTP-, HTTPS- oder Oracle-Check in mehreren GTM-Szenarien ausgewertet werden kann.
Bei einem Health-Statuswechsel wird zuerst der entsprechende Health-Check-Zustand aktualisiert. Verknüpfte Szenarien werden dann neu ausgewertet und bei Bedarf wird die dynamische Konfiguration neu erzeugt. Dieser Flow stellt sicher, dass Änderungen kontrolliert in DNS-Antworten propagieren.
Integrierte Szenarien wie `ALWAYS` und `NEVER` sind verfügbar, um feste Entscheidungen zu erzeugen. Mit `ALWAYS` gilt ein Record stets als zulässig; mit `NEVER` wird deaktiviertes Verhalten erreicht. Das ist für Tests, vorübergehende Takedowns oder bedingungsloses Routing nützlich.
Trigger-Aktionen werden nur auf dem GTM-Master-Node ausgeführt. Das verhindert, dass dieselbe Aktion in einem Cluster wiederholt von mehreren Knoten ausgeführt wird. Bei Aktionen wie DR-Triggering, Webhooks oder Benachrichtigungen liefert diese Kontrolle Betriebssicherheit.
Organisationen mit mehreren Standorten möchten ein Rechenzentrum möglicherweise nicht auf Basis eines einzelnen Zugriffspfads als up betrachten. TR7 kombiniert unterschiedliche Zugriffswege in derselben DNS-Entscheidung mit Szenarien wie `wanAccess OR lanAccess`.
Für kritische Geschäftsanwendungen reicht die Rechenzentrumserreichbarkeit allein nicht. TR7 nutzt Szenarien wie `dcAccess AND appHC AND dbHC`, um die entsprechende IP nur dann in die DNS-Antwort aufzunehmen, wenn sowohl Anwendung als auch Oracle-Datenbank gesund sind.
Ein Operations-Team möchte möglicherweise nicht, dass ein Rechenzentrum während der Wartung Traffic erhält, selbst wenn es technisch erreichbar ist. TR7 kann einen Wartungsstandort mit einem Szenario wie `dcAccess AND NOT maintenanceMode` aus der DNS-Antwort entfernen.
Moderne Anwendungen können ihren Health-Status über einen JSON-Endpunkt veröffentlichen. TR7 bindet DNS-Antworten an die reale Anwendungs-Health, indem es einen HTTPS-Health-Check mit einem JSONata-Ausdruck wie `status = "ok"` kombiniert.
Kombinieren Sie HTTP-, HTTPS-, Oracle- und Rechenzentrums-Checks zu booleschen Szenarien. Gehen wir gemeinsam ein Live-Setup in Ihrer eigenen Umgebung durch.