Einheit 3.7: DNS und Failover-Routing

Einführung

Wenn ein kompletter Endpunkt, eine Zone oder eine Site verloren geht, kann keine einzelne IP-Adresse eingreifen, um sie zu retten, und IONOS CLOUD bietet keine verwaltete Failover-Appliance an, die das Routing für Sie übernimmt. Die Lösung liegt eine Ebene höher, bei dem Namen: Ein DNS-Eintrag, der Clients auf einen gesunden Endpunkt verweist und neu gerichtet wird, wenn dieser Endpunkt nicht mehr gesund ist. Die wichtige architektonische Tatsache ist, dass Cloud DNS weder die Gesundheitsprüfung noch die Neuausrichtung für Sie durchführt. Cloud DNS ist nicht gesundheitsbewusst; es liefert den Eintrag, den Sie festgelegt haben. Die Gesundheitsprüfung, die feststellt, dass ein Endpunkt ausgefallen ist, sowie der API-Aufruf, der den Eintrag neu ausrichtet, sind Automatisierungen, für die Sie selbst verantwortlich sind. Dadurch ist das DNS-basierte Endpunkt-Failover ein vom Kunden erstelltes Muster, bei dem Cloud DNS eine (hochverfügbare) Komponente ist, aber kein natives Failover-Produkt. Diese Einheit legt das gut dokumentierte Fundament, eine Primärzone und deren Einträge, legt die eigentlichen Stärken von Cloud DNS offen und behandelt das Failover-Verhalten ehrlich: was die Plattform nativ bereitstellt und was Sie selbst gegenüber der API orchestrieren.

1. Cloud DNS: Was es bereitstellt und wo Failover tatsächlich stattfindet

Cloud DNS ist ein anycast-basierter, voll verwalteter autoritativer DNS-Dienst: Seine Zonen werden von 14 Präsenzen in Europa und den USA bereitgestellt, und der Dienst bietet eine SLA-Garantie von 99,995 Prozent Verfügbarkeit. Anycast ist entscheidend, da jeder Resolver automatisch den nächstgelegenen gesunden Knoten erreicht, sodass die DNS-Ebene selbst unabhängig von den Endpunkten, auf die sie verweist, hochverfügbar ist. Seine inhärenten Stärken sind klar zu benennen, da sie die Grundlage bilden, auf der Sie aufbauen: anycast-basierter autoritativer Dienst, Primär- und Sekundärzonen, eine TTL, die so niedrig wie 60 Sekunden gesetzt werden kann, DNSSEC und Reverse DNS.

Zwei dieser Stärken werden leicht verwechselt, daher sollten sie klar getrennt werden.

Resilienz der autoritativen Server ist inhärent: Sekundärzonen. Eine Sekundärzone ist ein AXFR-Spiegel einer Primärzone. Ihre Aufgabe ist die Notfallwiederherstellung für den autoritativen Namensserver selbst: Wenn der primäre Namensserver offline geht, beantwortet die Sekundärzone weiterhin Abfragen mit den zuletzt übertragenen Datensätzen. Sekundärzonen werden von einem eigenen Namensserversatz (nscs.ui-dns.*) bereitgestellt und sind eine echte, plattforminhärente Resilienz-Funktion. Was sie nicht sind: Endpunkt-Health-Failover. Eine Sekundärzone liefert weiterhin dieselben Datensätze; sie überwacht nicht, ob der Endpunkt, auf den diese Datensätze zeigen, noch aktiv ist, und sie ändert eine Antwort nicht, weil ein Backend ausgefallen ist.

Endpunkt-Failover ist nicht inhärent, da Cloud DNS nicht health-aware ist. Cloud DNS überwacht keine Endpunkt-Health-Status und ändert keine Datensätze automatisch basierend auf dem Health-Status. Es gibt keinen Record-Typ für Health-Check-Failover. Wenn von „DNS Failover“ die Rede ist, ist damit auf IONOS CLOUD ein Muster gemeint, das der Kunde selbst aufbaut: Ein externer Monitor oder ein Skript führt den Health-Check durch und ruft bei einem Fehler die Cloud DNS API auf, um einen Datensatz mit niedriger TTL auf einen gesunden Endpunkt umzuleiten. Cloud DNS liefert einfach den Datensatz, den Sie gesetzt haben. Die Automatisierung für Health-Checks und Umleitung liegt in Ihrer Verantwortung; Cloud DNS stellt den anycast-basierten, SLA-gesicherten Datensatz mit niedriger TTL bereit, der das Muster schnell und zuverlässig macht, sobald Sie es steuern.

Zwei Eigenschaften bestimmen, wie Sie um dieses kundenseitig aufgebaute Muster herum designen.

Erstens: DNS steuert nur neue Verbindungen. Das Umleiten eines Datensatzes ändert, wo zukünftige Lookups aufgelöst werden; es hat keinen Einfluss auf bereits etablierte Verbindungen zum ausgefallenen Endpunkt und auch keinen auf Clients, die noch eine zwischengespeicherte Antwort halten. Die harte Konsequenz ist, dass jede Ebene, die durch DNS-Failover abgesichert wird, stateless sein muss: Ein Client, der zum sekundären Endpunkt umgeleitet wird, muss in der Lage sein, ohne serverseitige Session-Affinität fortzufahren, da die Plattform keinen Versuch unternimmt, Zustand über den Wechsel hinweg zu übertragen. Sessions und andere Zustände müssen in einer geteilten Ebene (der in-memory-Cache-Ebene von Modul 5) liegen, nicht auf dem gerade ausgefallenen Endpunkt.

Zweitens: TTL ist der dominierende Hebel für die Wiederherstellungszeit. Die TTL, die Sie für einen Datensatz setzen, bestimmt, wie lange Resolver die alte Antwort zwischenspeichern dürfen; sie ist daher effektiv eine Untergrenze dafür, wie schnell umgeleitete Clients den neuen Endpunkt nach einer Änderung des Datensatzes entdecken können. Cloud DNS erlaubt TTLs von 60 Sekunden bis 604800 Sekunden (7 Tage). Eine niedrige TTL verkürzt das Zeitfenster, in dem Clients weiterhin den toten Endpunkt ansteuern, was genau das ist, wofür Ihr RTO-Budget bezahlt wird; der Nachteil sind häufigere Resolver-Lookups. Für einen durch Failover abgesicherten Datensatz sollten Sie eine niedrige TTL bewusst setzen und sie als den Regler für die Wiederherstellungszeit behandeln, den sie ist, nicht als einen ererbten Standard. Beachten Sie auch, dass die Namensserver-Propagation bis zu 48 Stunden dauern kann, was die Delegierung einer neuen Zone betrifft, nicht den Failover-Schritt pro Datensatz; planen Sie die Delegierung daher gut vor jedem Cutover ein.

Implementierungsdurchlauf für DCD

Sie erstellen die autoritative Zone von FinCorp, fügen die Einträge hinzu, die seinen öffentlichen Dienst auflösen, und richten anschließend ein kundenseitig gesteuertes Failover über ein Endpunkt-Paar mit zwei Endpunkten ein (zum Beispiel den Endpunkt der Primärregion und den Endpunkt der Sekundärregion). Die Erstellung der Zone und der Einträge ist ein gut dokumentierter Pfad in der Konsole; das durch Health Checks gesteuerte Umleiten wird auf Design- und API-Ebene behandelt, da Cloud DNS keine Health-Awareness besitzt und keinen Failover-Eintragstyp bereitstellt, der einen eigenen Health Monitor ausführt. Den Health Check und das Umleiten müssen Sie selbst erstellen.

Ziel der Implementierung: Erstellen Sie eine Zone und deren Einträge, und verdrahten Sie anschließend ein kundenseitig gesteuertes Failover (externer Health Check plus API-Umleitung) über ein Endpunkt-Paar mit zwei Endpunkten.

Voraussetzung: Sie müssen Vertragsadministrator, Owner oder ein Benutzer mit dem Privileg „Access and manage DNS“ sein, um Zonen und Einträge zu erstellen und zu verwalten.

Schritte (im Data Center Designer):

Öffnen Sie Cloud DNS und wählen Sie Create primary DNS zone.
Setzen Sie im Fenster Create Primary Zone Enabled/Disabled (Enabled belassen), den Name (die Domain oder Subdomain, zum Beispiel app.fincorp.example) und eine optionale Beschreibung. Klicken Sie auf Create zone. (Das Deaktivieren einer Zone entfernt deren SOA-Eintrag und trennt sie von den IONOS CLOUD Nameservern, daher sollte sie aktiviert bleiben.)
Kopieren Sie aus der Bestätigung zur Zonenerstellung die zugewiesenen IONOS CLOUD Nameserver (das ns-ic.ui-dns.*-Set) und konfigurieren Sie diese bei Ihrem Registrar, um die Delegation der Domain vorzunehmen. Planen Sie die Ausbreitung (Propagation) vor jeder Produktivsetzung ein.
Öffnen Sie die Zone (Primary Zones, dann die Zone, oder Details & Records) und klicken Sie auf Create record.
Setzen Sie im Fenster Create Record: Enabled, den Name (leer lassen erstellt einen Apex/Zone-Root-Eintrag; * erstellt einen Wildcard), die TTL in Sekunden (der Standardwert ist 3600, aber für einen failover-geschützten Eintrag einen niedrigen Wert setzen, zum Beispiel 60, als Hebel für die Wiederherstellungszeit), den Type (zum Beispiel A für die IPv4-Adresse des primären Endpunkts) und den Content (die Endpunktadresse). Speichern.
Fügen Sie den/die Eintrag(e) für den sekundären Endpunkt hinzu, sodass beide Zieladressen als verwaltete Einträge vorliegen, zwischen denen Sie umschalten können.

Der Failover-Schritt (kundenseitig gesteuert; Cloud DNS ist nicht health-aware): Cloud DNS hat keinen Failover-Eintragstyp, der einen eigenen Health Monitor ausführt und das Ziel automatisch umschaltet, da der Dienst die Endpunktgesundheit überhaupt nicht prüft. Erfinden Sie keinen Konsole-Flow, der dies tut. Stattdessen orchestrieren Sie es: Führen Sie einen Health Check außerhalb des DNS-Dienstes (ein externer Monitor oder ein Check in Ihrer Betriebstooling) gegen den primären Endpunkt aus, und wenn er fehlschlägt, rufen Sie die Cloud DNS API auf, um den Content des Eintrags auf den sekundären Endpunkt zu aktualisieren. Da jeder Eintrag die niedrige TTL aus Schritt 5 trägt, übernehmen umgeleitete Clients das neue Ziel schnell. Eine Eintragsaktualisierung ist ein einzelner authentifizierter API-Aufruf gegen die UUIDs der Zone und des Eintrags; der Eintragszustand wechselt von Provisioning zu Available, während die Änderung wirksam wird. Dies ist die ehrliche Form von „DNS Failover“ auf der Plattform heute: Zonen- und Eintragsverwaltung sind nativ und gut dokumentiert, und die Automatisierung für Health Check und Umleitung liegt bei Ihnen, gebaut um diese API. Cloud DNS liefert den Eintrag, den Sie gesetzt haben; er entscheidet nicht, wann er geändert wird.

Häufige Fehler:

Die Standard-TTL von 3600 Sekunden für einen failover-geschützten Eintrag belassen. Die TTL ist Ihr RTO-Boden; eine veraltete hohe TTL hält Clients an einem toten Endpunkt fest, lange nachdem Sie den Eintrag umgeschaltet haben.
Die Annahme, dass Cloud DNS den Health Check oder das Failover für Sie durchführt. Es tut das nicht; es ist nicht health-aware. Erstellen Sie den Health Check und das API-Umleiten selbst, anstatt davon auszugehen, dass ein nativer Failover-Eintragstyp existiert.
Verwechslung von sekundären Zonen mit Endpunkt-Failover. Sekundäre Zonen sind ein AXFR-Spiegel für die Notfallwiederherstellung von Nameservern (sie antworten weiter, wenn der primäre Nameserver ausfällt); sie erkennen keinen toten Endpunkt und ändern keinen Eintrag. Endpunkt-Failover ist das kundenseitig gesteuerte Umleiten.
Ein stateful-Tier mit DNS-Failover zu schützen. DNS steuert nur neue Verbindungen, daher Session/Zustand in die gemeinsame Cache-Ebene externalisieren, sonst verlieren umgeleitete Benutzer ihre Session.
Die Nameserver-Delegation und ihre Ausbreitung von bis zu 48 Stunden bei der Einrichtung einer neuen Zone zu vergessen; dies ist eine Aufgabe vor dem Cutover, nicht eine zum Failover-Zeitpunkt.

Zusammenfassung

Cloud DNS ist ein Anycast-basierter, SLA-gestützter autoritativer Dienst. Er ist eine starke Komponente in einem Failover-Design, handelt sich aber nicht um ein Failover-Produkt. Er ist nicht health-aware: Er liefert den Record, den Sie festlegen, und ändert eine Antwort niemals von selbst. Zwei Funktionen, die er nativ bereitstellt, sind hier relevant: Anycast, der die DNS-Ebene hochverfügbar hält, und sekundäre Zonen, die sicherstellen, dass der Name Server antwortet, wenn der primäre Server offline geht. Endpoint-Failover ist etwas anderes und wird vom Kunden aufgebaut: Ein externer Health Check, den Sie ausführen, erkennt einen ausgefallenen Endpoint und ruft die Cloud DNS API auf, um einen Record mit niedriger TTL auf einen gesunden Endpoint umzuleiten. Die Verwaltung von Zonen und Records ist der gut dokumentierte Teil der Konsole. Der Health Check und die Umleitung sind Automatisierungen, die in Ihrer Verantwortung liegen und durch eine bewusst niedrige TTL beschleunigt werden. Da der Mechanismus nur neue Verbindungen steuert, muss jede Ebene, die er bedient, zustandslos sein, wobei der Sitzungszustand in eine gemeinsame Ebene verschoben wird.

Wichtige Punkte:

Cloud DNS ist nicht health-aware: Er führt keine Endpoint-Health-Checks und keinen automatisierten Failover durch. Er liefert den Record, den Sie festlegen.
Endpoint-Failover ist ein vom Kunden aufgebautes Muster: Ihr eigener externer Health Check plus eine Record-Umleitung über die Cloud DNS API, da es kein verwaltetes Failover-Produkt gibt.
Sekundäre Zonen sind nativ, stellen aber die Notfallwiederherstellung für autoritative Server dar (ein AXFR-Spiegel, der antwortet, wenn der primäre Name Server ausfällt), und keinen Health-Failover für Endpoints.
Die TTL ist der entscheidende Hebel für die RTO (Cloud DNS erlaubt 60 bis 604800 Sekunden). Legen Sie sie für Records, die einem Failover vorgelagert sind, bewusst niedrig fest.
DNS steuert nur neue Verbindungen, daher müssen Ebenen, die durch DNS bedient werden, zustandslos sein und Sitzungszustand/State in einen gemeinsamen Cache externalisieren.
Cloud DNS ist Anycast über 14 Standorte (Europa und USA) mit einer 99,995 Prozent Uptime-SLA. Die Delegation des Name Servers kann bis zu 48 Stunden dauern und ist eine Aufgabe vor dem Cutover.

Wichtige Begriffe:

TTL (Time To Live): Wie lange Resolver einen Record im Cache halten dürfen. Bei einem Failover-Record bestimmt sie, wie schnell umgeleitete Clients den neuen Endpoint erkennen.
Apex- (Zonenwurzel-)Record: Ein Record auf dem nackten Zonennamen, erstellt, indem der Record-Name leer gelassen wird.
Anycast: Bereitstellung derselben Adresse von vielen Standorten aus, sodass Resolver den nächsten gesunden Knoten erreichen. Dadurch wird die DNS-Ebene selbst hochverfügbar.

Weitere Lektüre