Ein Rechenzentrum kann gesund erscheinen, während Anwendung, Datenbank oder Zugriffspfad es nicht sind.
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.
Unser Ansatz
TR7 wertet GTM-Health-Entscheidungen aus, indem es automatische Rechenzentrumsprüfungen, manuelle Health Checks und Szenariologik in einem einheitlichen Modell kombiniert.
Automatische und manuelle Health Checks vereinen sich im selben Szenario
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.
Boolesche Bedingungen vereinfachen komplexe Entscheidungen
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.
Bei Health-Statuswechseln werden nur betroffene Records neu ausgewertet
Health Check, Szenario und DNS-Record-Beziehungen werden über graphartige Maps nachverfolgt. Bei einem Statuswechsel werden nur die betroffenen Szenarien und Records neu ausgewertet.
Content-Validierung prüft die Anwendungsschicht — nicht nur die Port-Verfügbarkeit
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.
Funktionen
TR7-Health-Check-Szenarien decken ein Spektrum an GTM-Anforderungen ab — von einfachen Zugriffsprüfungen bis hin zu mehrschichtigen Anwendungs- und Rechenzentrumsentscheidungen.
HTTP- und HTTPS-Health-Checks validieren Statuscodes und Response-Inhalte
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.
Szenario-Historie — welcher Schritt scheiterte und was zurückkam
Ein Szenario ist eine Kette von Schritten; "die Prüfung ist fehlgeschlagen" ist für sich genommen nie eine brauchbare Antwort. TR7 bewahrt die Zustandsübergänge jedes Backends zusammen mit dem gescheiterten Schritt und den Bytes auf, die die Probe in diesem Moment tatsächlich empfangen hat — der Ausfall am Dienstag um 03:40 wird nachgelesen, nicht erraten. Send/Expect-Ketten mit Hex- und Base64-Payloads sorgen dafür, dass ein Port, der antwortet, aber sein Protokoll nicht mehr spricht, am Szenario scheitert — und die gespeicherte Antwort zeigt genau, warum.
JSONata-Content-Checks validieren API-Antworten auf sinnvolle Weise
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.
Einfache Content-Checks bieten schnelles String-Matching
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-Health-Checks fügen dem Szenario eine Datenbankschicht hinzu
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.
Fünf automatische Health Checks pro Rechenzentrum verfügbar
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.
Boolesche Szenarien unterstützen AND, OR und negative Bedingungen
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.
Aufeinanderfolgende Success- und Failure-Schwellwerte reduzieren das Flapping-Risiko
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.
Lokale Health-State-Persistenz bietet Kontinuität nach Neustarts
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.
Elf Health-Check-Typen für GTM- und ADC-Koordination verfügbar
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.
Betriebliche Tiefe
Damit Health-Check-Szenarien zuverlässig arbeiten, müssen Identifier-Format, State-Persistenz, Trigger-Reihenfolge, Master-Node-Kontrolle und Änderungsausbreitung klar verwaltet sein.
Health-Check-Typen
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.
Format automatischer Identifier
Automatische Health Checks pro Rechenzentrum werden im Format `auto|
Identifier manueller Health Checks
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.
Trigger-Flow
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.
Standard-Szenariozustände
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.
Master-Node-Kontrolle
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.
Wann einsetzen
DNS-Entscheidung basierend auf WAN- und LAN-Zugriff
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`.
Nur antworten, wenn Anwendung und Datenbank beide gesund sind
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.
Traffic fernhalten, wenn der Wartungsmodus aktiv ist
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.
GTM-Routing basierend auf JSON-API-Health
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.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einem Health-Check-Szenario und einem einfachen Up/Down-Check?
Wie spiegele ich den Wartungsmodus in einer DNS-Entscheidung?
Was lässt sich gegen Flapping tun?
Wie binde ich die Oracle-Datenbank-Health an eine GTM-Entscheidung?
Kann derselbe Health Check für mehrere DNS-Records verwendet werden?
Werden Health-Check-Zustände beim Neustart von GTM zurückgesetzt?
Binden Sie Ihre DNS-Entscheidungen an die reale Service-Health
Kombinieren Sie HTTP-, HTTPS-, Oracle- und Rechenzentrums-Checks zu booleschen Szenarien. Gehen wir gemeinsam ein Live-Setup in Ihrer eigenen Umgebung durch.