Einheit 3.7: DNS und Failover-Routing

Einführung

Wenn ein gesamter Endpunkt, eine Zone oder ein Standort verloren geht, kann kein einzelnes IP ihn retten, und IONOS bietet kein gemanagtes Failover-Gerät an, um die Steuerung für Sie durchzuführen. Die Antwort liegt eine Ebene höher, beim Namen: Ein DNS-Eintrag, der Clients auf einen gesunden Endpunkt verweist und umgeleitet wird, wenn dieser Endpunkt nicht mehr gesund ist. Die wichtige architektonische Wahrheit ist, dass Cloud DNS weder die Gesundheitsprüfung noch die Umleitung für Sie durchführt. Cloud DNS ist nicht gesundheitsbewusst, es dient dem von Ihnen festgelegten Eintrag. Die Gesundheitsprüfung, die entscheidet, dass ein Endpunkt tot ist, und der API-Aufruf, der den Eintrag umleitet, sind Automationen, die Sie selbst besitzen. Das macht das DNS-basierte Endpunkt-Failover zu einem kundenbasierten Muster, bei dem Cloud DNS ein (hochverfügbarer) Bestandteil ist, aber kein natives Failover-Produkt. Diese Einheit baut die gut dokumentierte Grundlage auf, eine primäre Zone und ihre Einträge, hebt die tatsächlichen Stärken von Cloud DNS hervor und behandelt das Failover-Verhalten ehrlich: Was die Plattform nativ bietet und was Sie selbst gegen die API orchestrieren.

1. Cloud DNS: Was es bietet und wo Failover tatsächlich lebt

Cloud DNS ist ein anycast-gesteuerter, vollständig gemanagter autorisierter DNS-Dienst: seine Zonen werden von 14 Präsenzpunkten in Europa und den USA aus bedient, und der Dienst verfügt über eine Verfügbarkeit von 99,995 Prozent. Anycast ist wichtig, weil jeder Resolver automatisch den nächstgelegenen gesunden Node erreicht, sodass die DNS-Ebene selbst unabhängig von den Endpunkten, die sie steuert, hochverfügbar ist. Seine natürlichen Stärken sind es wert, sie einfach auszudrücken, weil sie das sind, was Sie tatsächlich nutzen: anycast-gesteuerter autorisierter Dienst, primäre und sekundäre Zonen, eine TTL, die Sie auf 60 Sekunden festlegen können, DNSSEC und umgekehrte DNS.

Zwei dieser Stärken sind leicht zu verwechseln, daher sollten Sie sie sauber trennen.

Autorisierter-Server-Resilienz ist nativ: sekundäre Zonen. Eine sekundäre Zone ist ein AXFR-Spiegel einer primären Zone. Ihre Aufgabe ist die Notfallwiederherstellung für den autorisierenden Nameserver selbst: wenn der primäre Nameserver offline geht, behält die sekundäre Zone die Beantwortung von Anfragen mit den zuletzt übertragenen Aufzeichnungen bei. Sekundäre Zonen werden von einer separaten Nameserver-Gruppe (nscs.ui-dns.*) bedient und sind ein echtes, plattform-natives Resilienz-Feature. Was sie nicht sind, ist Endpoint-Health-Failover. Eine sekundäre Zone behält die gleichen Aufzeichnungen bei; sie überwacht nicht, ob der Endpunkt, auf den diese Aufzeichnungen verweisen, am Leben ist, und sie ändert keine Antwort, weil ein Backend heruntergefahren wurde.

Endpoint-Failover ist nicht nativ, weil Cloud DNS nicht gesundheitsbewusst ist. Cloud DNS überwacht die Endpunktgesundheit nicht und ändert keine Aufzeichnungen automatisch basierend auf der Gesundheit. Es gibt keinen Aufzeichnungstyp für die Gesundheitsprüfung und das Failover. Wenn Menschen von "DNS-Failover" sprechen, meinen sie auf IONOS ein Muster, das der Kunde aufbaut: ein externer Monitor oder Skript führt die Gesundheitsprüfung durch, und im Falle eines Fehlers ruft es die Cloud DNS-API auf, um eine Aufzeichnung mit niedriger TTL auf einen gesunden Endpunkt umzuleiten. Cloud DNS dient einfach die Aufzeichnung, die Sie festlegen. Die Automatisierung der Gesundheitsprüfung und Umleitung ist Ihre Aufgabe; Cloud DNS bietet den anycast-gesteuerten, SLA-gestützten, niedrigen-TTL-Aufzeichnung, der das Muster schnell und zuverlässig macht, sobald Sie es steuern.

Zwei Eigenschaften bestimmen, wie Sie um das kundenseitig aufgebaute Muster herum entwerfen.

Erstens, DNS steuert nur neue Verbindungen. Das Umleiten einer Aufzeichnung ändert, wo zukünftige Auflösungen gelöst werden; es tut nichts für Verbindungen, die bereits gegen den fehlgeschlagenen Endpunkt hergestellt wurden, und es tut nichts für Clients, die immer noch eine zwischengespeicherte Antwort halten. Die harte Konsequenz ist, dass jede Ebene, die von DNS-Failover vorgeschaltet wird, zustandslos sein muss: ein Client, der zum sekundären Endpunkt umgeleitet wird, muss in der Lage sein, ohne serverseitige Sitzungsaffinität fortzufahren, weil die Plattform keinen Versuch unternimmt, den Zustand über den Wechsel zu tragen. Sitzung und andere Zustände müssen in einer gemeinsamen Ebene (der In-Memory-Cache-Ebene von Modul 5) leben, nicht auf dem Endpunkt, der gerade fehlgeschlagen ist.

Zweitens, TTL ist der dominierende Hebel für die Wiederherstellungszeit. Die TTL, die Sie für eine Aufzeichnung festlegen, ist die Zeit, die Resolver die alte Antwort im Cache halten dürfen, sodass sie effektiv ein Boden für die Zeit ist, die umgeleitete Clients benötigen, um den neuen Endpunkt nach der Änderung der Aufzeichnung zu entdecken. Cloud DNS ermöglicht TTLs von 60 Sekunden bis 604800 Sekunden (7 Tage). Eine niedrige TTL verkürzt das Zeitfenster, während dessen Clients weiterhin den toten Endpunkt treffen, was das ist, wofür Ihr RTO-Budget tatsächlich bezahlt; der Kompromiss ist, dass die Resolver häufiger aufgerufen werden. Für eine Failover-vorgeschaltete Aufzeichnung sollten Sie absichtlich eine niedrige TTL festlegen und sie als die Wiederherstellungszeit-Hebel behandeln, den Sie ist, und nicht als Standard, den Sie geerbt haben. Beachten Sie auch, dass die Namensserver-Verbreitung bis zu 48 Stunden dauern kann, was die Delegation einer neuen Zone betrifft, nicht den pro-Aufzeichnung-Failover-Schritt, also planen Sie die Delegation gut im Voraus.

DCD Implementierung Schritt-für-Schritt

Sie werden die autoritative Zone von FinCorp erstellen, die Aufzeichnungen hinzufügen, die ihren öffentlichen Dienst auflösen, und dann einen kundenorchestrierten Failover über ein Paar mit zwei Endpunkten einrichten (zum Beispiel den Endpunkt der primären Region und den Endpunkt der sekundären Region). Die Erstellung der Zone und der Aufzeichnungen ist ein gut dokumentierter Konsolenpfad; die gesundheitsüberwachungsgesteuerte Neupunktierung wird auf der Design- und API-Ebene behandelt, da Cloud DNS nicht gesundheitsüberwachungsfähig ist und keinen Failover-Aufzeichnungstyp bereitstellt, der seinen eigenen Gesundheitsüberwachungsmonitor ausführt. Die Gesundheitsüberwachung und die Neupunktierung sind Ihre Aufgabe.

Ziel: Eine Zone und ihre Aufzeichnungen erstellen und dann einen kundenorchestrierten Failover (externe Gesundheitsüberwachung plus eine API-Neupunktierung) über ein Paar mit zwei Endpunkten einrichten.

Voraussetzung: Sie müssen ein Vertragsadministrator, Besitzer oder ein Benutzer mit dem Privileg "Zugriff und Verwaltung von DNS" sein, um Zonen und Aufzeichnungen zu erstellen und zu verwalten.

Schritte (in der Data Center Designer):

Öffnen Sie Cloud DNS und wählen Sie Primäre DNS-Zone erstellen.
Im Fenster "Primäre Zone erstellen" setzen Sie Aktiviert/Deaktiviert (lassen Sie es aktiviert), den Namen (die Domäne oder Subdomäne, zum Beispiel app.fincorp.example) und eine optionale Beschreibung. Klicken Sie auf Zone erstellen. (Das Deaktivieren einer Zone entfernt ihre SOA-Aufzeichnung und trennt sie von den IONOS-Nameservern, also lassen Sie sie aktiviert.)
Von der Zone-Erstellungsbestätigung kopieren Sie die zugewiesenen IONOS-Nameserver (die ns-ic.ui-dns.*-Menge) und konfigurieren Sie sie bei Ihrem Registrar, um die Domäne zu delegieren. Lassen Sie Zeit für die Verbreitung vor einem möglichen Start.
Öffnen Sie die Zone (Primäre Zonen, dann die Zone oder Details und Aufzeichnungen) und klicken Sie auf Aufzeichnung erstellen.
Im Fenster "Aufzeichnung erstellen" setzen Sie: Aktiviert, den Namen (leer lassen, um eine Apex-/Zonenwurzelaufzeichnung zu erstellen; * erstellt eine Wildcard), die TTL in Sekunden (der Standardwert ist 3600, aber für eine Failover-vorgeschaltete Aufzeichnung setzen Sie einen niedrigen Wert, zum Beispiel 60, als Wiederherstellungszeithebel), den Typ (zum Beispiel A für die primäre Endpunkt-IPv4) und den Inhalt (die Endpunktadresse). Speichern Sie.
Fügen Sie die Aufzeichnungen für den sekundären Endpunkt hinzu, sodass beide Zieladressen als verwaltete Aufzeichnungen existieren, zwischen denen Sie umschalten können.

Der Failover-Schritt (kundenorchestriert; Cloud DNS ist nicht gesundheitsüberwachungsfähig): Cloud DNS hat keinen Failover-Aufzeichnungstyp, der seinen eigenen Gesundheitsüberwachungsmonitor ausführt und das Ziel automatisch umschaltet, da der Dienst die Endpunktgesundheit überhaupt nicht überprüft. Erstellen Sie keinen Konsolenfluss, der dies tut. Stattdessen orchestrieren Sie es: Führen Sie eine Gesundheitsüberwachung von außerhalb des DNS-Dienstes (einen externen Monitor oder eine Überwachung in Ihrem Betriebstooling) gegen den primären Endpunkt durch, und wenn dieser fehlschlägt, rufen Sie die Cloud DNS-API auf, um den Inhalt der Aufzeichnung auf den sekundären Endpunkt zu aktualisieren. Da jede Aufzeichnung die niedrige TTL aus Schritt 5 trägt, nehmen umgeleitete Clients das neue Ziel schnell auf. Eine Aufzeichnungsaktualisierung ist ein einzelner authentifizierter API-Aufruf gegen die Zone- und Aufzeichnungs-UUIDs; der Aufzeichnungsstatus wechselt von "In Bearbeitung" zu "Verfügbar", wenn die Änderung wirksam wird. Dies ist die ehrliche Form des "DNS-Failovers" auf der Plattform heute: Zonen- und Aufzeichnungsverwaltung sind native und gut dokumentiert, und die Gesundheitsüberwachungs- und Neupunktierungsautomatisierung ist Ihre Aufgabe, die um diese API herum aufgebaut wird. Cloud DNS dient die Aufzeichnung, die Sie festgelegt haben; es entscheidet nicht, wann sie geändert wird.

Häufige Fehler:

Das Standard-TTL von 3600 Sekunden auf einer failover-vorgeschalteten Aufzeichnung beibehalten. Die TTL ist Ihre Wiederherstellungszeituntergrenze; ein veralteter hoher TTL hält Clients an einem toten Endpunkt fest, lange nachdem Sie die Aufzeichnung umgeschaltet haben.
Annahme, dass Cloud DNS die Gesundheitsüberwachung oder den Failover für Sie durchführt. Es tut dies nicht; es ist nicht gesundheitsüberwachungsfähig. Bauen Sie die Gesundheitsüberwachung und die API-Neupunktierung selbst, anstatt anzunehmen, dass ein nativer Failover-Aufzeichnungstyp existiert.
Verwechslung von sekundären Zonen mit Endpunkt-Failover. Sekundäre Zonen sind ein AXFR-Spiegel für die Notfallwiederherstellung von Nameservern (sie beantworten weiterhin, wenn der primäre Nameserver stirbt); sie erkennen einen toten Endpunkt nicht oder ändern eine Aufzeichnung. Endpunkt-Failover ist die kundenorchestrierte Neupunktierung.
Ein stateful-Tier mit DNS-Failover vorbereiten. DNS lenkt nur neue Verbindungen um, also externalisieren Sie die Sitzung/Zustand in die gemeinsame Cache-Ebene oder umgeleitete Benutzer verlieren ihre Sitzung.
Vergessen der Nameserver-Delegation und ihrer bis zu 48-stündigen Verbreitung, wenn Sie eine neue Zone einrichten; dies ist eine Aufgabe vor dem Start, nicht während des Failovers.

Zusammenfassung

Cloud DNS ist ein anycast-, SLA-gestützter autorisierter Dienst und ein starkes Komponente in einem Failover-Design, aber es ist kein Failover-Produkt selbst. Es ist nicht gesundheitsbewusst: es dient jedem Datensatz, den Sie festlegen, und ändert nie eine Antwort von selbst. Zwei Dinge, die es nativ bereitstellt, sind hier wichtig: anycast, das die DNS-Ebene hochverfügbar hält, und sekundäre Zonen, die den Nameserver beantworten lassen, wenn der primäre offline geht. Endpoint-Failover ist anders und wird vom Kunden erstellt: ein externer Gesundheitscheck, den Sie ausführen, erkennt einen toten Endpunkt und ruft den Cloud DNS API auf, um einen Low-TTL-Datensatz auf einen gesunden Endpunkt umzuleiten. Zonen- und Datensatzverwaltung ist der gut dokumentierte Konsolenbereich; der Gesundheitscheck und die Umleitung sind Automationen, die Sie besitzen, und werden durch eine bewusst niedrige TTL beschleunigt. Da der Mechanismus nur neue Verbindungen steuert, muss jede Ebene, die es vorne hat, zustandslos sein, wobei der Sitzungszustand auf eine gemeinsame Ebene verschoben wird.

Wichtige Punkte:

Cloud DNS ist nicht gesundheitsbewusst: es führt keine Endpunktgesundheitsprüfung durch und kein automatisches Failover. Es dient jeden Datensatz, den Sie festlegen.
Endpoint-Failover ist ein vom Kunden erstelltes Muster: Ihre eigene externe Gesundheitsprüfung plus ein Cloud DNS API-Datensatz, der umgeleitet wird, wenn es kein gemanagtes Failover-Produkt gibt.
Sekundäre Zonen sind nativ, aber sie sind autorisierter Server-Notfallwiederherstellung (ein AXFR-Spiegel, der weiterhin beantwortet, wenn der primäre Nameserver stirbt), nicht Endpunktgesundheits-Failover.
TTL ist der dominierende RTO-Hebel (Cloud DNS erlaubt 60 bis 604800 Sekunden); setzen Sie es absichtlich niedrig auf Failover-vorgelagerten Datensätzen.
DNS steuert nur neue Verbindungen, sodass DNS-vorgelagerte Ebenen zustandslos sein und Sitzung/Zustand auf einen gemeinsamen Cache externalisieren müssen.
Cloud DNS ist anycast über 14 Präsenzpunkte (Europa und USA) mit einer 99,995-prozentigen Uptime-SLA; die Delegation des Nameservers kann bis zu 48 Stunden dauern und ist eine vorherige Aufgabe.

Wichtige Begriffe:

TTL (Time To Live): Wie lange Resolver einen Datensatz im Cache speichern dürfen; bei einem Failover-Datensatz begrenzt es, wie schnell umgeleitete Clients den neuen Endpunkt entdecken.
Apex (Zonenwurzel)-Datensatz: Ein Datensatz am nackten Zonenname, der durch Leeren des Datensatznamens erstellt wird.
Anycast: Bedienen der gleichen Adresse von vielen Präsenzpunkten aus, sodass Resolver den nächstgelegenen gesunden Node erreichen, wodurch die DNS-Ebene selbst hochverfügbar wird.

Weiterführende Literatur