Im klassischen Primary/Backup-DNS-Modell wird ein Rechenzentrumsausfall erkannt, das Operations-Team erhält einen Alert, der Zonen-Record wird aktualisiert, der Dienst neu geladen und Clients warten auf die Propagation der neuen DNS-Antwort. Diese Kette sieht im Runbook geradlinig aus; in einem realen Vorfall dehnen Entscheidungsfindung, Zugriffskontrolle, Freigabe und Ausführung die RTO erheblich aus.
In vielen Organisationen arbeiten Health Checking und DNS als getrennte Systeme. Ein Monitoring-Tool sieht, dass ein DC nicht erreichbar ist, der DNS-Server antwortet aber weiterhin mit denselben IP-Adressen. Die Brücke dazwischen ist typischerweise ein Skript, ein manuelles Runbook oder eine separate Automatisierungsschicht. Diese Lücke wird im Failover-Moment zum schwächsten Glied.
Failback birgt vergleichbares Risiko. Wackelt ein DC schnell hinein und hinaus, kann die DNS-Antwort wiederholt kippen — Clients verteilen sich auf verschiedene Rechenzentren, und der Traffic kehrt möglicherweise zurück, bevor die Zustandssynchronisation abgeschlossen ist. Eine einfache "Entfernen wenn down, wieder hinzufügen wenn up"-Logik genügt nicht.
Das richtige Modell wertet DC-Health über boolesche Szenariologik aus, reduziert das Flap-Risiko durch aufeinanderfolgende Success/Failure-Schwellwerte und macht die DNS-Antwort zum natürlichen Ergebnis dieser Entscheidung. Dasselbe Modell muss auch die manuelle Umschaltung für geplante Wartung, eine fail-safe Antwort, wenn alle DCs unhealthy sind, und DR-Bedingungen abdecken.
TR7 DC-Failover liefert dieses Modell: Es aktualisiert die DNS-Antwort automatisch, sobald sich ein DC-Health-Szenario ändert, und koppelt den gesamten Failover-Prozess an DNS-TTL und vom Operator definierte Health-Parameter.
TR7 setzt DC-Failover-Entscheidungen über Health-Szenarien, boolesche Bedingungslogik, Flap-Schutz und einen manuellen Umschaltmechanismus um.
Wenn sich der Health-Check-Status für ein DC ändert, wird das zugehörige Szenario neu ausgewertet. Ändert sich das Szenarioergebnis, werden die relevanten DNS-Records neu erzeugt und das unhealthy DC wird aus der Antwort entfernt.
Bedingungsgruppen werden mit AND-Logik kombiniert, Gruppen werden mit OR-Logik kombiniert. Für jeden Health Check lässt sich auch eine negative Bedingung definieren, die inverse Szenarien wie "diesen Record aktivieren, wenn diese Prüfung unhealthy ist" ermöglicht.
Während sich ein DC in einem Übergang befindet, kann das vorherige Auswertungsergebnis beibehalten werden. Dieses Verhalten hilft, kurzlebige Up/Down-Schwankungen davon abzuhalten, die DNS-Antwort kontinuierlich zu verändern.
Während geplanter Wartung kann ein Operator ein DC per Wartungsmodus offline nehmen. Selbst wenn das DC gesund erscheint, kann es aus der DNS-Antwort ausgeschlossen werden, sodass der Datenverkehr auf ein anderes DC umgeleitet wird.
DC-Failover ist die GTM-Failover-Schicht, die DNS-Antworten über mehrere Rechenzentren hinweg automatisch auf Basis des Health-Status verwaltet.
TR7 kann DC-Records als Prioritätskette nach Array-Position auswerten. Wenn das primäre DC unhealthy ist, übernimmt das sekundäre; wird auch das sekundäre unhealthy, springt das tertiäre ein — und längere Ketten werden ebenso unterstützt. Das Codemodell ist nicht theoretisch auf zwei Endpunkte begrenzt. Diese Struktur vereinfacht mehrstufige Kontinuitätsdesigns in Finanz-, Behörden- und großen SaaS-Umgebungen.
TR7 kann Health-Signale auf DC-Ebene auswerten: wanAccess, lanAccess, access, internet und maintenanceMode. WAN-Erreichbarkeit, LAN-Erreichbarkeit, allgemeiner Zugriffsstatus, Internetzugriff und manueller Wartungsstatus werden jeweils separat modelliert. Ein DC wird daher über mehrere Zugriffsdimensionen hinweg bewertet, nicht nur über ein einzelnes Ping-Ergebnis. Die DNS-Antwort spiegelt ein realistischeres Bild der DC-Health wider.
requiredSuccess und requiredFailure legen fest, wie viele aufeinanderfolgende Ergebnisse benötigt werden, bevor ein DC als up oder down gilt. Dieses Modell verhindert unnötige DNS-Änderungen durch vorübergehenden Paketverlust, kurze Netzwerkunterbrechungen oder momentane Dienstverlangsamungen. Operatoren können engere Schwellen für kritische Dienste und tolerantere für rauschigere Links verwenden. Die RTO wird gemeinsam mit diesen Schwellen und dem Prüfintervall geplant.
Der Modus noResponse hält ein passives DC unter normalen Bedingungen still. Der Modus onlyNew kann verhindern, dass ein lange ausgefallenes DC bei der Rückkehr mit veralteten Daten antwortet. Dieses Verhalten stellt sicher, dass während des Failovers nur DCs im korrekten Zustand DNS-Antworten erzeugen — nicht nur diejenigen, die erreichbar sind. Es ist eine wichtige Schutzschicht in Umgebungen, in denen das Risiko veralteter Daten relevant ist.
Der Per-Record-DR-Modus erlaubt es, dass bestimmte Records erst aktiv werden, wenn eine DR-Bedingung erfüllt ist. Das Szenario drCond oder das Flag drIfNoRecords löst den DR-Record aus, wenn primäre und sekundäre Ziele erschöpft sind. Dieses Modell hält entfernte Disaster-Recovery-IP-Adressen aus normalen DNS-Antworten heraus und hält sie für kritische Situationen in Bereitschaft. Die DR-Strategie wird auf DNS-Ebene kontrolliert.
Wenn kein DC gesund ist, kann eine Antwort aus dem fallbackRecords-Array generiert werden. Diese Records können auf eine Wartungsseite, einen statischen Notfall-Endpunkt oder einen alternativen Wiederherstellungsdienst verweisen. Das FailSafe-Verhalten sorgt dafür, dass DNS eine kontrollierte Last-Resort-Antwort erzeugt, statt nichts zurückzugeben. Operatoren definieren diese Records gemäß dem Krisenplan ihrer Organisation.
TR7 kann lokale Health-Check- und Szenariodaten auf Dateiebene speichern. Nach einem Neustart oder Service-Reload wird der vorherige Zustand wiederhergestellt, sodass die Auswertung nicht von vorne beginnt. Dieser Ansatz reduziert unnötige Oszillationen bei Failover-Entscheidungen während eines vorübergehenden Neustarts. Er ist besonders nützlich, um Konsistenz während Wartungsoperationen aufrechtzuerhalten, die den GTM-Dienst neu starten.
wanAccess- und lanAccess-Ziellisten lassen sich pro DC definieren. Mehrere Zugriffsziele liefern ein genaueres Bild der externen und internen Erreichbarkeit eines DC. Ein vorübergehendes Problem mit einem einzelnen Ziel markiert nicht zwangsläufig das gesamte DC als down. Diese Struktur ermöglicht eine umfassendere Modellierung der Rechenzentrums-Health.
Wenn maintenanceMode aktiviert wird, wird das betreffende DC bewusst offline genommen. Das ist während Patches, Wartungsfenstern, Migrationen oder kontrollierten DR-Tests nützlich. Der Operator kann das DC aus der DNS-Antwort entfernen — auch wenn es gesund ist — und den Datenverkehr auf ein anderes DC umleiten. Nach Abschluss der Wartung wird der Modus deaktiviert und die normale Auswertung wird fortgesetzt.
Der DC-Zustand kann als ok, noInternet, noAccess, noWan oder noLan ausgedrückt werden. Diese Klassifizierung zeigt, welche Zugriffsdimension problematisch ist, statt nur "down" zu sagen. Operations-Teams können Internet-Egress-, WAN-Erreichbarkeits- und LAN-Erreichbarkeitsprobleme schneller unterscheiden. Der Grund hinter einer Failover-Entscheidung wird besser lesbar.
Wenn sich der Health-Check-Status ändert, kann das zugehörige Szenario sofort neu ausgewertet werden. An das Szenario gebundene Records gelangen in die dynamische Konfigurations-Regenerierungspipeline und die DNS-Antwort wird aktualisiert. Dieses Verhalten reduziert den Bedarf an manuellen Zonen-Edits oder externen Skripten. Änderungen werden durch ein kurzes Debounce-Fenster gruppiert, um unnötig wiederholte Regenerierungen zu vermeiden.
In einem HA-Cluster-Szenario werden DNS-Konfigurations-Writes über die Master-Rolle gesteuert. Fällt der Master-Node aus, kann der Standby-Node die Rolle nach einer definierten Sicherheitsperiode übernehmen. Dieses Modell verhindert, dass zwei Nodes gleichzeitig unterschiedliche DNS-Konfigurationen erzeugen. Das GTM-Verhalten bleibt im Einklang mit dem Cluster-Zustand.
Eine DC-Failover-Operation wird gemeinsam mit Prüfintervall, aufeinanderfolgenden Schwellen, HC-ID-Struktur, Szenariobedingungen, Regenerierungspipeline und RTO-Parametern geplant.
accessPeriod legt fest, wie häufig DC-Health-Checks laufen. Es kann in Sekunden oder Minuten konfiguriert werden. Eine kürzere Periode liefert schnellere Erkennung; eine längere Periode ergibt eine ruhigere, geräuschärmere Auswertung.
requiredSuccess legt fest, wie viele aufeinanderfolgende Erfolge nötig sind, bevor ein DC als up gilt. requiredFailure legt fest, wie viele aufeinanderfolgende Fehler nötig sind, bevor ein DC als down gilt. Diese beiden Werte bestimmen das Gleichgewicht zwischen Failover-Geschwindigkeit und Flap-Schutz.
wanAccess- und lanAccess-Listen definieren die Zugriffsziele eines DC. Damit lässt sich bewerten, ob ein DC nicht nur von außen, sondern auch aus dem internen Netzwerk erreichbar ist. Diese Unterscheidung ist besonders bei Inter-DC- und Hybrid-Routing-Szenarien wichtig.
Automatische HC-Records folgen dem Format `auto|
Bedingungen innerhalb einer Gruppe werden mit AND-Logik kombiniert; Gruppen werden mit OR-Logik kombiniert. Diese Struktur unterstützt eine große Bandbreite an Entscheidungsmodellen, von einfachen Primary-Down-Prüfungen bis hin zu komplexen mehrdimensionalen DC-Health-Szenarien. Operatoren sind nicht auf ein einzelnes Prüfungsergebnis beschränkt.
Bei HC-Statusänderung wird das Szenario neu ausgewertet, gebundene Records werden identifiziert und die dynamische Konfigurations-Regenerierung wird ausgelöst. Die Pipeline läuft mit einem kurzen Debounce, sodass schnelle aufeinanderfolgende Änderungen zu einem einzigen Regenerierungsdurchlauf zusammengeführt werden. Die DNS-Antwort wird gemäß dem aktuellen Health-Status neu gerendert.
Die RTO hängt von accessPeriod, requiredFailure-Anzahl, Regenerierungs-Debounce-Dauer und Client-DNS-TTL-Verhalten ab. Statt eine einzige feste Zeit zu beanspruchen, sollte das Failover-Fenster passend zu den Service-Anforderungen geplant werden. Kritische Dienste profitieren von kürzeren TTL und häufigeren Prüfungen.
DC1 wird als primär, DC2 als passiver Standby definiert. Wenn das Internet- oder Zugriffsszenario für DC1 ausfällt, werden DC1-Records aus der DNS-Antwort entfernt und DC2 beginnt zu antworten.
Finanzinstitute können eine sequenzielle DC1 → DC2 → DC3 Failover-Kette aufbauen. Jede Stufe wird durch ihr eigenes Health-Szenario bewertet und ein unhealthy DC wird automatisch aus der DNS-Antwort entfernt.
Im Wartungsfenster wird DC1 in den Wartungsmodus versetzt und der Datenverkehr auf DC2 gelenkt. Nach Abschluss der Wartung wird der Wartungsmodus deaktiviert und die normale Health-Auswertung wird fortgesetzt.
Sind primäre und sekundäre DCs beide unhealthy, können DR-Modus-Records aktiviert werden. In diesem Szenario bleibt der entfernte Disaster-Recovery-Standort unter normalen Bedingungen passiv und wird nur dann zur DNS-Antwort hinzugefügt, wenn die definierten Bedingungen erfüllt sind.
Wenn ein DC nach längerer Ausfallzeit wieder online kommt, ist es möglicherweise nicht wünschenswert, dass es mit veralteten Daten antwortet. Das onlyNew-Verhalten hält ein veraltetes DC passiv und reduziert das Risiko, veraltete Records zu veröffentlichen.
Zunächst wird das nächstgelegene DC nach Land oder Region ausgewählt; wird dieses DC dann unhealthy, wird das Standby-DC aktiviert. Dieses Modell kombiniert performance-basierte Steuerung mit Kontinuitätsentscheidungen in einer einzigen GTM-Konfiguration.
Health-Szenario, DNS-Antwort und manuelle Umschaltung in einer einzigen Entscheidungspipeline vereint. Gehen wir gemeinsam ein Live-Setup mit Ihrer eigenen DC-Architektur durch.