In einer GTM-Architektur kann eine Änderung des Health-Check-Status die DNS-Antwort ändern — doch ein Vorfall ist selten nur eine DNS-Antwort. Geht ein Rechenzentrum offline, müssen das Alarmsystem, das Ticketing, die DR-Automatisierung, die Audit-Pipeline und das Anwendungsteam alle Bescheid wissen. Ohne diese Verbindung trifft GTM die Entscheidung, während der Rest der operativen Kette der Organisation erst zu spät davon erfährt.
Eine separate Orchestrierungsschicht zu betreiben ist möglich, bedeutet aber einen neuen Dienst, neue Credentials, neues Monitoring und einen neuen Fehlerpunkt. Der Health Check läuft bereits in GTM; die Propagation von Statusänderungen an externe Systeme sollte aus derselben Plattform gesteuert werden.
Auf der DNS-Forwarding-Seite ist das Problem ähnlich. Einige Domains gehören ins interne DNS, einige an einen externen Resolver, einige in TR7s eigene autoritative Zone. Wenn ein einfacher Forwarder alles an ein einziges Ziel sendet, kollidieren Split-DNS, interne Zonen, Partner-Domains und Geo-Routing-Verhalten.
Geht ECS-Information verloren, verschärft sich das Problem. Geo- und topologiebasierte Entscheidungen hängen vom Client-Netzwerkkontext ab; entfernt der Forwarder diesen Kontext, kann das Upstream-Geo-Routing am falschen Standort getroffen werden. Ein Forwarder sollte nicht nur die Anfrage tragen — er sollte auch den Entscheidungskontext bewahren.
TR7 GTM-Trigger und -Forwarder verknüpfen Health-Check-Statuswechsel mit HTTP/HTTPS- oder Oracle-DB-Aktionsketten und machen DNS-Forwarding über selektives Domain-Forwarding, localhost-Zone-Forward und ECS-Pass-Through betrieblich beherrschbar.
TR7 entwirft GTM nicht nur als DNS-Engine, die Anfragen beantwortet, sondern als aktive Betriebsschicht, die auf Health-Zustand reagiert und DNS-Anfragen kontextabhängig weiterleitet.
Wechselt der Basiszustand des HC-Szenarios, können Turn- oder Return-Aktionen laufen. Aktiviert sich das Szenario, läuft triggerTurnActions der Reihe nach; kehrt es in den Normalbetrieb zurück, läuft triggerReturnActions der Reihe nach.
HTTP/HTTPS-Trigger werden mit Methode, URI, Headern, Body, erwarteten Statuscodes und Timeout definiert. Der Response-Body kann mit einer JSONata- oder Basic-Content-Prüfung validiert werden, um zu bestimmen, ob die Aktion erfolgreich war.
Oracle-Trigger arbeiten mit einem Connection-String und einem Szenario-Schritt-Array. wait- und executeCmd-Schritte können Prüfungen oder Aktionen gegen die Datenbank durchführen; erwartete Row-Counts oder erwartete Textwerte können verifiziert werden.
Der Forwarder kann bestimmte Domains an bestimmte DNS-Ziele senden; für die Root-Domain kann ein Default-Ziel definiert werden. Das ECS-Pass-Through bewahrt den Client-Subnet-Kontext, sodass Geo-Routing-Entscheidungen nicht gebrochen werden.
GTM-Trigger und -Forwarder vereinen Health-Check-Aktionen, HTTP/HTTPS- und Oracle-Validierung, verkettete Trigger-Flows und selektives DNS-Forwarding in einem einzigen Management-Modell.
Ein HTTP-Trigger wird mit Zieladresse, Port, Request-Methode, URI, Header-Liste und Request-Body definiert. Eine Liste erwarteter Statuscodes bestimmt, ob der Aufruf erfolgreich war. Ein Timeout begrenzt langlaufende Aufrufe an externe Systeme. HTTP-basierte Ziele wie DR-Runbooks, Audit-Endpunkte oder Alarmsysteme können alle über dieses Modell ausgelöst werden.
Ein HTTPS-Trigger wendet dasselbe Request-Modell wie HTTP über TLS an. Das Flag verifyCertificate bestimmt, ob das Zielzertifikat validiert wird. Die Zertifikatsvalidierung in Produktion aktiviert zu lassen, wird empfohlen. Dieses Muster wird genutzt, um GTM-Szenario-Wechsel an sichere externe Aktionssysteme zu übermitteln.
HTTP/HTTPS-Trigger-Antworten können als JSON oder XML geparst und mit einem JSONata-Ausdruck validiert werden. Der Ausdruckskontext umfasst body, bodyRaw, headers und status. Beispielsweise kann auch dann, wenn das externe Runbook-System 200 zurückgibt, ein Feld success=true im Response-Body separat geprüft werden. Das ermöglicht robustere Trigger-Validierung, die sich nicht allein auf den Statuscode verlässt.
Wo JSONata nicht nötig ist, kann eine Basic-Content-Prüfung verwendet werden. Der Response-Body wird mit der Semantik von .includes() auf das Vorhandensein eines bestimmten Strings getestet. Das reicht für kleine Integrationen, Legacy-Systeme oder Endpunkte, die eine einfache Health-Antwort liefern. Operatoren können schnell validieren, ohne einen komplexen Ausdruck zu schreiben.
Ein Oracle-Trigger verbindet sich mit der Datenbank über Benutzer, Passwort und Connection-String. Szenario-Schritte können wait- und executeCmd-Operationen enthalten. Erwartete Row-Counts oder erwartete Textwerte aus executeCmd können verifiziert werden. Dieses Modell wird genutzt, um den Anwendungs-Datenbankzustand quer zu validieren oder kontrollierte Aktionen auf Datenbankseite auszuführen.
Die Arrays triggerTurnActions und triggerReturnActions führen mehrere Trigger-IDs der Reihe nach aus. Schlägt eine Aktion fehl, bricht die Kette ab und nachfolgende Aktionen laufen nicht. Das verhindert, dass abhängige Runbook-Schritte unkontrolliert weiterlaufen. Flows wie zuerst an einen Audit-Endpunkt schreiben und dann einen DR-Job starten lassen sich so aufbauen.
turn steht für den Moment, in dem das Szenario aktiviert wird; return für den Moment, in dem es deaktiviert und in den Normalbetrieb zurückkehrt. Für jede Richtung lässt sich eine eigene Trigger-Liste und Bedingung definieren. Während des Failovers und der Wiederherstellung können unterschiedliche Aktionen ausgelöst werden. Diese Trennung erlaubt einen sauberer entworfenen Betriebsfluss.
Sobald ein neuer Group-Key eintrifft, können alte Trigger-Prozesse gestoppt werden. Der Trigger-Lebenszyklus wird mit started-, succeeded- und failed-Log-Einträgen nachverfolgt; nach einer kurzen Verzögerung wird das activeTrigger-Event gelöscht. Dieses Verhalten reduziert das Risiko, dass alte Aktionen mit einem neuen Flow kollidieren, wenn Health-Statuswechsel in schneller Folge eintreten. Der Hauptdienst bleibt vom Trigger-Fork isoliert.
In einem Cluster laufen Trigger nur auf dem Master-Knoten. Andere Knoten, die denselben Health-Statuswechsel sehen, lösen die externe Aktion nicht erneut aus. Das verhindert das doppelte Auslösen von Webhook- oder DB-Aktionen. Das Clusterverhalten wird deterministischer.
Die Forwarder-Schicht ist als separater Recursor-Prozess platziert. Sie empfängt DNS-Anfragen über den forwarderInnerPort-Bereich und leitet sie an definierte Upstream-Ziele. Autoritatives DNS und Recursor-Forwarding-Verhalten sind entkoppelt. Diese Trennung erlaubt TR7, eigene Zonen und externe DNS-Auflösung kontrolliert innerhalb derselben Architektur zu verwalten.
Die Liste domainBasedForwarding erlaubt es, bestimmte Domains an bestimmte DNS-Adressen zu lenken. Interne Domains können an das Unternehmens-DNS gehen; andere Anfragen an den Default-Upstream-Resolver. Dieses Design ist für Split-DNS- und Hybrid-DNS-Architekturen wichtig. Es geht über einen groben Forwarder hinaus, der jede Anfrage an ein einziges Ziel sendet.
Der Forwarder reicht ECS-Informationen an Upstream-Resolver weiter, damit diese mit Client-Subnet-Kontext entscheiden können. Das ECS-Verhalten wird über ecs-ipv4-bits-, ecs-add-for- und Allow-Liste-Einstellungen gesteuert. Dieser Kontext ist für Geo-Routing oder topologiebasierte Upstream-Entscheidungen entscheidend. Geht ECS verloren, kann Geo-Routing am falschen Resolver-Standort getroffen werden.
GTM-Trigger und Forwarder werden zusammen mit Timeout-Verhalten, Lebenszyklus-Tracking, Child-Prozess-Isolation, Parse-Priorität, Forward-Zonen-Reihenfolge und Metadaten-Zeilen betrieben.
Das Default-Timeout für einen HTTP-Trigger kann 120 Sekunden betragen. Ein Oracle-Trigger kann je nach eigener Verarbeitungszeit länger laufen. Der gesamte Trigger-Prozess kann auf 24 Stunden begrenzt sein — eine wichtige obere Grenze für lange Runbooks oder mehrstufige Datenbank-Szenarien.
Es gibt keinen automatischen Retry in der Trigger-Kette. Schlägt ein Trigger fehl, bricht die Kette ab und nachfolgende Aktionen laufen nicht. Zielsysteme sollten daher idempotent und zuverlässig entworfen sein.
Trigger werden mit den Zuständen started, succeeded und failed protokolliert. Diese Einträge zeigen, welche Aktion während eines Failover- oder Recovery-Ereignisses lief. Der aktive Trigger-Zustand wird nach einer kurzen Verzögerung gelöscht.
Die Trigger-Ausführung kann als separater Child-Prozess laufen. Dieses Modell verhindert, dass der Haupt-GTM-Dienst von langlaufenden externen Aufrufen oder DB-Operationen beeinträchtigt wird. Ein fehlschlagender Trigger reißt den Hauptdienst nicht mit.
Der HTTP-Response-Body wird zuerst als JSON, dann als XML basierend auf dem Content-Type geparst. Schlägt beides fehl, wird ein Raw-String-Fallback verwendet. Der JSONata-Ausdruck wird auf diesen Kontext angewendet.
Die Zeilen forward-zones-recurse werden in einer definierten Reihenfolge erzeugt. Die erste Domain-Forward-Definition wird als Primary-Zeile geschrieben; nachfolgende Definitionen als zusätzliche Zeilen. Diese Reihenfolge ist für die saubere Anwendung selektiven Forwarding-Verhaltens wichtig.
Das Feld forwarder.metaData trägt zusätzliche Recursor-Konfigurationszeilen. Es bietet einen Erweiterungspunkt für eigene Cache-, Policy- oder Betriebseinstellungen. In Betrieb befindliche Metadatenzeilen sollten sorgfältig validiert werden.
Wenn das Health-Check-Szenario aktiviert wird, feuert ein HTTP-POST-Trigger. Das Alarm- oder Incident-Management-System erhält die Rechenzentrums-Down-Benachrichtigung. Die DNS-Failover-Entscheidung wird zeitgleich für das externe Betriebssystem sichtbar.
Wird ein DR-Szenario aktiviert, kann ein HTTPS-Trigger einen Job in der Automatisierungsplattform starten. Der erste Trigger erstellt einen Audit-Eintrag; der zweite Trigger führt den DR-Bring-Up-Job aus. Schlägt die Trigger-Kette fehl, läuft der nächste Schritt nicht unkontrolliert weiter.
Bei jedem Turn- und Return-Event kann ein HTTP-Trigger einen Event-Eintrag an den Audit-Endpunkt senden. Informationen darüber, in welcher Zone, in welchem Szenario und wann der Wechsel stattfand, werden an das externe Log-System gepusht. GTM-Entscheidungen werden auditierbar.
Wenn ein Anwendungs-Heartbeat fehlschlägt, kann ein Oracle-Trigger eine unabhängige DB-Prüfung ausführen. Werden der erwartete Row-Count oder Textwert zurückgegeben, wird das Ereignis cross-validiert. Das ergibt ein stärkeres Entscheidungssignal, ohne sich allein auf das HTTP-Health-Check-Ergebnis zu verlassen.
Domains wie internal.example.com können über domainBasedForwarding an Unternehmens-DNS-Ziele weitergeleitet werden. Andere Anfragen gehen an das Default-Upstream-DNS. TR7s eigene autoritative Zonen können per localhost an den lokalen DNS-Prozess geforwardet werden.
Interne Clients können interne Anwendungsdomains über den Unternehmens-Recursor auflösen, während externe Clients TR7-GTM-autoritative Antworten erhalten. Selektives Forwarding und ECS-Pass-Through gemeinsam eingesetzt entkoppeln das Auflösungsverhalten von intern und extern. Die DNS-Architektur ist nicht in einseitiges Forwarding gezwängt.
HTTP/HTTPS- und Oracle-DB-Trigger-Ketten, selektives DNS-Forwarding und ein ECS-bewusster Recursor. Gehen wir gemeinsam ein Live-Setup in Ihrer eigenen Umgebung durch.