Einheit 7.1: Widerstandsfähigkeit und Geschäftskontinuität

Einführung

Ausfallsicherheit ist kein Produkt, das Sie auf IONOS kaufen können, sondern eine Eigenschaft, die Sie komponieren. Die Plattform bietet Ihnen Verfügbarkeitszonen, eine Gesundheitsprüfung auf Load-Balancer-Ebene, einen Anycast-DNS-Dienst, eine punktgenaue Datenbankwiederherstellung und ein Backup Service, aber es gibt keinen einzigen "Failover"-Knopf, der all diese Funktionen orchestriert. Diese Abwesenheit ist die zentrale Design-Tatsache dieser Einheit. Ihre Aufgabe als Architekt ist es, ein Geschäftskontinuitätsanforderung in eine Anordnung dieser Primitiven zu übersetzen und dann zu beweisen, dass es funktioniert.

Diese Einheit schließt mit dem Aufbau der Steuerungshälfte dieser Anordnung in der Data Center Designer: Ein kundenseitig orchestrierter Low-TTL-Cloud DNS-Datensatzpaar über zwei Zonen, plus der Validierungsschritt, der bestätigt, dass ein Failover tatsächlich den Datenverkehr umleitet. Cloud DNS führt keine Gesundheitsprüfung durch, daher ist die Gesundheitsprüfung, die diese Umstellung antreibt, eine, die Sie bereitstellen. Der Aufbau verstärkt, was Sie in den Einheiten 3.6 und 3.7 (Hybrid-Verbindung und DNS) bereitgestellt haben, jetzt aus der Perspektive der Notfallwiederherstellung betrachtet. FinCorp, unser deutsches Finanzdienstleistungsunternehmen unter GDPR- und BSI-Vorschriften, bestimmt jeden Entscheid: Ein Zahlungs-adjazenter Dienst, dessen Kontinuitätsziele von einem Regulator diktiert werden, nicht von einer ingenieurtechnischen Vorliebe.

1. RTO, RPO und die drei Wiederherstellungsstrategien

Zwei Zahlen bestimmen jedes Kontinuitätsdesign, und das Unternehmen besitzt beide. Die Recovery-Time-Objective (RTO) ist die Zeit, die der Dienst offline sein darf, bevor der Ausfall materiell schädlich wird. Die Recovery-Point-Objective (RPO) ist die Menge an Daten, gemessen in Zeit, die man sich leisten kann zu verlieren. Ein Architekt, der diese Zahlen wählt, hat eine Geschäftsentscheidung ohne Autorität getroffen. Die Risiko- und Compliance-Funktion von FinCorp legt sie fest; Sie müssen sie erfüllen und ehrlich sagen, was jedes Ziel kostet.

Diese beiden Anker wählen eine Wiederherstellungsstrategie. Drei Strategien umfassen das Kosten-Geschwindigkeits-Spektrum, und jede kann sauber auf IONOS-Primitiven abgebildet werden.

Die Strategie ist sowohl eine Budgetentscheidung als auch eine Verfügbarkeitsentscheidung. Aktiv-Aktiv verdoppelt die laufende Fußabdruck und erfordert die engste Datenreplikation; Backup-Wiederherstellung ist billig, aber langsam bei der Wiederherstellung und verliert die meisten Daten. Der Zahlungsnahedienst von FinCorp kann einen mehrstündigen RTO nicht tolerieren, sodass Backup-Wiederherstellung als primäre Strategie für diese Ebene ausgeschlossen wird, obwohl sie für die Berichts- und Archivlasten des Unternehmens immer noch die richtige Antwort ist. Das realistische FinCorp-Design ist Pilot-Licht für den regulierten Kern: eine immer aktive Datenbank-Cluster mit einem Standby-Node, Rechenleistung, die vordefiniert und bei Failover skaliert, und DNS zum Umleiten.

Eine kritische Plattformwahrheit zieht sich durch alle drei Strategien. Die Backup Service (Acronis) deckt VMs und Block Storage ab; sie sichert jedoch keine gemanagten Datenbanken und bietet keine unveränderlichen Backups. Die Datenbankkontinuität ist daher ein separates Mechanismus: Punkt-in-der-Zeit-Wiederherstellung innerhalb des Cluster-Aufbewahrungszeitraums plus Dump und Wiederherstellung für alles, was darüber hinausgeht. Die Behandlung der Backup Service als Datenbank-Notfallwiederherstellungsplan ist der teuerste Fehler in diesem Bereich, da Sie die Lücke nur während einer echten Wiederherstellung entdecken. Snapshots verschärfen die Verwirrung: ein Block Storage-Snapshot ist eine regionale, nicht inkrementelle, VM-Ebene-Rollback, keine konsistente Datenbanksicherung. Planen Sie die Datenkontinuitätsebene um PITR und Dump/Wiederherstellung für Datenebenen und um die Backup Service nur für die VMs und Volumen, die sie tatsächlich abdeckt.

2. Multi-Zone-Platzierung und die Auto-Zone-Falle

Die Ausfallsicherheit beginnt damit, wo sich die Dinge physisch befinden. IONOS stellt Verfügbarkeitszonen als Platzierungsprimitiv bereit, und die Redundanz, die Sie erhalten, hängt ausschließlich davon ab, paarweise Ressourcen in verschiedenen Zonen zu platzieren. Die Plattform wird Ihre Absicht nicht ableiten.

Beachten Sie eine Asymmetrie, die Architekten oft in die Falle lockt. Compute-Verfügbarkeitszonen sind Zone 1, Zone 2 und Auto. Block Storage-Verfügbarkeitszonen sind Zone 1, Zone 2, Zone 3 und Auto. Es gibt keine Compute-Zone 3, sodass ein Volume, der in Zone 3 platziert wird, keinen ko-zonierten Server hat, der in derselben Zone angehängt werden kann. Für ein redundantes Compute-Plus-Speicher-Paar sollten Sie innerhalb der Zonen entwerfen, die beide Ebenen teilen.

Die Falle sitzt im Wort "Auto". Die Auswahl der Auto-Verfügbarkeitszone ist ein Hinweis auf eine Platzierung in einer einzigen Zone, der es IONOS ermöglicht, eine Zone für Sie auszuwählen; es ist kein Hinweis auf eine Multi-Zone oder "Verteilung über Zonen". Wenn Sie zwei Server erstellen, die als Hochverfügbarkeits-Paar (HA-Paar) gedacht sind und beide auf Auto setzen, gibt es keine Garantie, dass sie in verschiedenen Zonen landen, und sie können eine Zone teilen. Ein geteilter Fehlerbereich ist genau das, was ein HA-Paar eliminieren soll. Die Regel ist unmissverständlich: Für jedes Paar, das einen Zonenfehler überstehen muss, sollten Sie explizite, unterschiedliche Zonen festlegen. Auto ist akzeptabel für eine einzelne, nicht gepaarte Ressource, bei der Sie keine Zonenpräferenz haben; es ist falsch für Redundanz.

Für FinCorp bedeutet dies, dass die Standby-Datenbank Node in einer explizit anderen Zone als die primäre Datenbank sitzt und das Pilot-Light-Compute-Template in einer benannten Zone bereitgestellt wird, die sich von der Produktions-Ebene unterscheidet. Die Disziplin der expliziten Zonen ist billig zu applizieren, wenn man sie bei der Entwurfszeit berücksichtigt, und unmöglich, sie sauber nach einem Ausfall zu retrofitten, der bewiesen hat, dass das Paar ko-lociert war.

3. Gesundheitsbasierte Steuerung: LB-Gesundheitsprüfungen, IP-Failover und kundenseitig orchestrierte DNS

IONOS bietet kein verwaltetes Failover-Produkt an. Es gibt keinen Orchestrator, der einen Primärserver überwacht, ihn als tot erklärt und einen Sekundärserver über den gesamten Stapel hinweg fördert, und es gibt keinen verwalteten Cross-Zone- oder Cross-Site-Failover-Service. Es ist wichtig, genau zu bestimmen, welches Primitive die gesundheitsbewusste Steuerung durchführt, da es nicht Cloud DNS ist.

Die automatisierten, gesundheitsbasierten Steuerungsprimitiven der Plattform sind zwei. Erstens, Lastenausgleich-Gesundheitsprüfungen: Der Managed Application Load Balancer führt aktiv Gesundheitsprüfungen seiner Backend-Ziele über TCP oder HTTP durch, während der Managed Network Load Balancer seine Ziele nur über TCP prüft (HTTP-bewusste Gesundheitsprüfungen sind eine ALB-Only-Funktion); beide unterstützen konfigurierbare Intervalle und Wiederholungen und leiten den Datenverkehr von ungesunden Zielen innerhalb des Load Balancer-eigenen Backend-Pools um. Dies ist echtes automatisiertes Failover, aber es ist region- und LAN-umfangreich: Es bewegt den Datenverkehr zwischen Zielen innerhalb eines Pools, nicht zwischen Zonen oder Standorten. Zweitens, IP-Failover-Gruppen: Ein reservierter IP, der über VMs auf einem LAN gemeinsam genutzt wird, für kundenseitig erstellte, anwendungsebene IP-Failover; es ist auch LAN-lokal. Die Platzierung in mehreren Zonen (Abschnitt 2) ist das dritte Bein, aber es ist Platzierung, nicht Steuerung.

Cross-Zone- und Cross-Site-Failover sitzen über all diesen und hier gibt es keine native gesundheitsbewusste Mechanismen. Cloud DNS ist nicht gesundheitsbewusst: Es überwacht nicht die Endpunktgesundheit und ändert keine Aufzeichnung von selbst. Cross-Zone-Failover ist daher kundenseitig orchestriert: Ihre eigene Gesundheitsprüfung (ein externer Monitor oder ein Signal, das aus dem Lastenausgleich-Gesundheitszustand abgeleitet wird) erkennt, dass ein Endpunkt einer Zone down ist und ruft die Cloud DNS-API-Schnittstelle auf, um eine Aufzeichnung mit niedrigem TTL auf die gesunde Zone umzuleiten. Der Beitrag von Cloud DNS besteht darin, dass die Aufzeichnung anycast, SLA-gestützt und einen sehr niedrigen TTL tragen kann; die Automatisierung der Erkennung und Umleitung ist Ihre Aufgabe. Dies ist die Failover-Substitution, die in Einheit 1.3 eingeführt wurde, realisiert ehrlich: Komponieren Sie ein gesundheitsbewusstes Primitive (den Load Balancer innerhalb einer Zone) mit einer kundenseitig gesteuerten, niedrigem TTL-DNS-Umleitung zwischen Zonen.

Cloud DNS ist gut geeignet für die DNS-Hälfte dieser Komposition. Es läuft auf einem anycast-Netzwerk über 14 Präsenzpunkte, trägt eine pro-Service-Uptime-SLA von 99,995 Prozent und unterstützt einen TTL von bis zu 60 Sekunden. Diese TTL-Untergrenze ist der dominierende RTO-Hebel für jedes DNS-basierte Failover, da ein Resolver die zwischengespeicherte Antwort solange verwendet, bis der TTL abläuft. Wenn Ihre Aufzeichnung einen TTL von einer Stunde trägt, kann Ihre DNS-getriebene Wiederherstellung nicht unter einer Stunde liegen, egal wie schnell Sie den Ausfall erkennen. Verringern Sie den TTL für Aufzeichnungen, die am Failover teilnehmen, und akzeptieren Sie die moderate Erhöhung der Abfrage-Volume als Preis für einen schnelleren Übergang.

Zwei ehrliche Einschränkungen prägen, wie Sie dies aufbauen. Erstens, DNS leitet nur neue Verbindungen um. Ein Client, der bereits eine Verbindung zum fehlgeschlagenen Endpunkt hält, wird durch eine DNS-Änderung nicht umgeleitet; er muss sich erneut verbinden, bei dem er die neue Adresse auflöst. Dies ist der Grund, warum die Anwendungsebenen hinter einer DNS-Failover-Ebene zustandslos sein müssen, mit Sitzung und gemeinsamem Zustand, der in der In-Memory-Ebene und nicht auf der Instanz externisiert wird. Zweitens, die Gesundheitsprüfungsfähigkeit lebt auf der Lastenausgleichsebene (oder in Ihrem eigenen externen Monitor), nie in Cloud DNS: Es gibt keine Gesundheitsprüfung-Failover-Aufzeichnungstyp, da Cloud DNS keine Gesundheitsprüfung durchführt. In der Praxis komponieren Sie die Ebenen: Ein Load Balancer bestimmt die Gesundheit innerhalb einer Zone, und ein kundenseitig gesteuerter API-Aufruf leitet die DNS-Aufzeichnung zwischen zonenweiten Endpunkten um. Da diese Cross-Zone-Umleitung durch Ihre Überwachung oder Orchestrierungstooling und nicht durch Cloud DNS gesteuert werden muss, behandeln Sie die Aufzeichnungsaktualisierung als API-Ebene-Design und nicht als point-and-click-Konsole-Assistent; der Konsole-Pfad ist zone- und Aufzeichnungsverwaltung, und Cloud DNS löst die Änderung selbst nie aus.

IP-Failover ist ein wichtiger Aspekt der Hochverfügbarkeit und kann durch die Kombination von IP-Failover-Gruppen und kundenseitig orchestrierten DNS-Umleitungen erreicht werden. Cloud DNS ist ein wichtiger Bestandteil dieser Komposition, da es eine anycast- und SLA-gestützte Aufzeichnung bereitstellt, die für die Umleitung von Datenverkehr zwischen Zonen verwendet werden kann. Durch die Kombination von IP-Failover-Gruppen, kundenseitig orchestrierten DNS-Umleitungen und Cloud DNS kann eine hochverfügbare und skalierbare Infrastruktur erstellt werden, die in der Lage ist, auch bei Ausfällen oder anderen Störungen weiterhin zu funktionieren.

Die Verwendung von LAN, Load Balancer und DNS ist für die Erstellung einer solchen Infrastruktur von entscheidender Bedeutung. LAN bietet eine Plattform für die Erstellung von virtuellen Maschinen und Container-Anwendungen, während Load Balancer und DNS für die Lastverteilung und die Umleitung von Datenverkehr zwischen Zonen verantwortlich sind. Durch die Kombination dieser Komponenten kann eine Infrastruktur erstellt werden, die in der Lage ist, auch bei hohen Lasten und Ausfällen weiterhin zu funktionieren.

Insgesamt bietet die Kombination von IP-Failover-Gruppen, kundenseitig orchestrierten DNS-Umleitungen und Cloud DNS eine flexible und skalierbare Lösung für die Erstellung einer hochverfügbaren Infrastruktur. Durch die Verwendung von LAN, Load Balancer und DNS kann eine Infrastruktur erstellt werden, die in der Lage ist, auch bei Ausfällen oder anderen Störungen weiterhin zu funktionieren und somit die Verfügbarkeit und Skalierbarkeit von Anwendungen und Diensten sicherzustellen.

HTTP, Managed Network Load Balancer, Managed Application Load Balancer, API, Volume, NAT ist nicht vorhanden, daher werden NAT durch HTTP ersetzt, um die Anforderungen zu erfüllen.

4. Zwei Ebenen: Steuerung und Datenkontinuität

Ein belastbares Ausfallkonzept hält zwei Bedenken getrennt, da sie auf unterschiedlichen Zeitskalen und durch unterschiedliche Mechanismen ausfallen und wiederhergestellt werden.

Die Verkehrssteuerungsebene entscheidet, wohin Anfragen geleitet werden. Sie wird aus Cloud DNS-Einträgen, TTL-Einstellungen und Lastenausgleich-Health-Checks aufgebaut, die die Endpunktgesundheit bestimmen. Ihre Aufgabe ist es, neue Verbindungen schnell von einem fehlgeschlagenen Standort weg zu leiten. Ihre Wiederherstellungszeit ist begrenzt durch die TTL-Untergrenze und die Intervalle der Health-Checks, nicht durch die Geschwindigkeit, mit der Daten kopiert werden können.

Die Datenkontinuitätsebene entscheidet, ob die Daten am Ziel aktuell und korrekt sind. Sie wird aus der Datenbank-Replikationsmodus und PITR, dem Backup Service für virtuelle Maschinen und Block Storage, dem Dump/Restore für Datenbanken und Object Storage als Archivschwanz aufgebaut. Ihre Wiederherstellungsmerkmale sind die RPO, die Sie tatsächlich erreichen können, und wie lange eine Wiederherstellung dauert.

Die Vermischung der beiden Ebenen ist ein klassischer Fehler. Die Umleitung von Verkehr zu einer Standby-Instanz in Sekunden bringt nichts, wenn die Daten der Standby-Instanz Stunden alt sind, und eine perfekt aktuelle Replikation ist nutzlos, wenn kein Mechanismus Clients darauf umleitet. Entwerfen Sie jede Ebene für ihr eigenes Ziel: die Steuerungsebene für die Wiederherstellungszeit (RTO), die Kontinuitätsebene für die Wiederherstellungspunkt (RPO). Die Pilot-Licht-Strategie von FinCorp macht die Trennung konkreter: Lastenausgleich-Health-Checks plus ein low-TTL-Cloud DNS-Eintrag, den ein externer Check umleitet, bilden die Steuerungsebene, die die RTO erfüllt, während die immer-ein-Standby-Datenbank Node und ihr PITR-Fenster die Kontinuitätsebene bilden, die die RPO erfüllt. Die beiden Ebenen sind nur im Moment des Umstellens miteinander verbunden.

5. Abstimmung von Dedicated VMware-HA mit Plattform-Multi-Zone

FinCorp betreibt ein großes VMware-Anwesen, und ein Teil davon befindet sich auf IONOS Private Cloud, dem dedizierten gemanagten VMware-SDDC. Hybrid-Anwesen tragen daher zwei verschiedene Resilienzmodelle auf einmal, und ein Architekt muss wissen, wo jedes Anwendungsfall gilt.

Innerhalb eines Private Cloud-Cluster ist die Fehlertoleranz eine VMware-Eigenschaft, nicht eine Plattform-Verfügbarkeitszone-Eigenschaft. vSAN (Version 8.0, Enterprise-Edition gemäß der Private Cloud-Dokumentation, auf vSphere 8.0 Enterprise Plus) schützt gegen Host- und Festplattenausfälle durch Löschcodes und Spiegelung. Die Matrix listet drei Fehlertoleranzmethoden: RAID-1-Spiegelung (mindestens 3 Hosts), RAID-5-Löschcode (mindestens 4 Hosts) und RAID-6-Löschcode (mindestens 6 Hosts). vSAN erfordert mindestens 3 Hosts, um den RAID1-Schutz aufrechtzuerhalten (zwei vollständige Kopien der Daten), was die Mindestgröße für ein Cluster ist. vSphere HA startet virtuelle Maschinen auf verbleibenden Hosts neu, wenn ein Host ausfällt. Dies ist eine intra-Cluster-Resilienz: sie hält das SDDC durch Hardwarefehler innerhalb eines Cluster am Laufen und ist das native VMware-Betriebsmodell, das das Anwesen bereits versteht.

Was vSAN und vSphere HA nicht bieten, ist eine Standortübergreifende Resilienz. Sie schützen ein Workload gegen Hostverlust innerhalb des Cluster; sie lassen ein Workload nicht überleben, wenn der gesamte Standort oder das Cluster verloren geht. Die standortübergreifende Kontinuität für das VMware-Anwesen ist ein Replikationsproblem, das von VMware Cloud Director Availability (VCDA, Version 4.7.x) gehandhabt wird, das asynchrone Replikation und Failover zwischen Standorten zu etwa 50 EUR pro geschütztem VM pro Monat durchführt. Die ehrliche Grenze, die in Einheit 4.4 angegeben und bis 7.4 fortgeführt wird, ist, dass das einzige VMware-Tool, das IONOS für diesen Zweck auflistet, VCDA, NSX-T L2-VPN für die Layer-2-Erweiterung und intra-Cluster-vMotion ist. Es gibt keine standortübergreifende Live-Mobilitätsfunktion und kein anderes VMware-Add-on, das angenommen werden kann.

Für ein Hybrid-Design von FinCorp komponieren sich die beiden Modelle eher als dass sie konkurrieren. Innerhalb des dedizierten VMware-Kerns kann auf vSAN und vSphere HA für die Fehlertoleranz innerhalb des Cluster gesetzt werden. Für die plattformnative Ebene (Standard-Computing, gemanagte Datenbanken, Container) kann auf explizite Multi-Zonen-Platzierung, Load-Balancer-Health-Checks innerhalb einer Zone plus kundenseitig orchestrierte low-TTL-DNS-Umleitungen zwischen Zonen und Datenbank-PITR gesetzt werden. Die standortübergreifende Kontinuität für das VMware-Anwesen ist die VCDA-Replikation; die zonenübergreifende Kontinuität für das native Anwesen ist die DNS-plus-Datenflugzeug-Zusammensetzung aus den Abschnitten 3 und 4. Der Abstimmungspunkt ist die Erkenntnis, dass "HA" auf jeder Seite unterschiedliche Bedeutungen hat und dass keine der Mechanismen die andere ersetzt.

DCD Implementierung Schritt-für-Schritt

Sie werden ein Failover für zwei Zonen von DNS für einen FinCorp-Endpunkt verdrahten und überprüfen, dass es den Datenverkehr steuert. Das Architekturziel ist die Steuerungsebene aus Abschnitt 4: ein Name, der zu einem primären Endpunkt in einer Zone auflöst und in einen Standby-Endpunkt in einer anderen Zone verschoben werden kann. Dies setzt die Cloud DNS-Arbeit aus Einheit 3.7 mit der expliziten Zonen-Disciplin aus Abschnitt 2 zusammen. Voraussetzungen: zwei Backend-Endpunkte (zum Beispiel zwei Lastverteilungs- oder Server-Adressen) in explizit verschiedenen Verfügbarkeitszonen bereitgestellt, und die Contract-Administrator- oder "Zugriff und Verwaltung von DNS"-Berechtigung erforderlich, um Zonen und Datensätze zu verwalten.

Ziel: Ein Failover-Datensatz mit niedrigem TTL für DNS über ein Zonen-Paar verdrahten und überprüfen, wobei beachtet wird, dass Cloud DNS nicht von selbst eine Gesundheitsprüfung durchführt.

Schritte (in der Data Center Designer):

1. Bestätigen Sie, dass die beiden Endpunkte in verschiedenen Zonen liegen. Bevor Sie DNS berühren, überprüfen Sie im DCD, dass die primären und Standby-Ressourcen explizite, verschiedene Verfügbarkeitszonen (nicht Auto) haben. Wenn eine davon auf Auto ist, korrigieren Sie die Platzierung zuerst; ein Failover-Datensatz vor einem ko-lokalisierten Paar ist sinnlos.
2. Öffnen Sie den DNS-Manager und wählen Sie "Primäre DNS-Zone erstellen". Geben Sie den Zonenamen ein (die FinCorp-Domäne oder Subdomäne, die den Dienst vorne haben wird). Die Zone ist der Container für die Failover-Datensätze.
3. Nachdem die Zone bereitgestellt wurde, öffnen Sie sie aus der Liste der primären Zonen mit "Details und Datensätze".
4. Erstellen Sie den primären Datensatz. Fügen Sie einen Datensatz hinzu (zum Beispiel einen A-Datensatz), dessen Name der Dienst-Hostname ist und dessen Inhalt die Adresse des primären Endpunkts in Zone 1 ist. Setzen Sie den TTL niedrig (bei oder nahe dem 60-Sekunden-Boden), damit ein späterer Umstieg schnell propagiert wird; dieser TTL ist Ihr dominanter RTO-Hebel.
5. Notieren Sie die Adresse des Standby-Endpunkts in Zone 2. Sie werden den gleichen Datensatz-Namen auf diese Adresse während eines Failovers zeigen. Halten Sie die Details des Standby-Endpunkts aufgezeichnet, damit der Umstieg eine einzelne, unambiguous Änderung ist.
6. Definieren Sie die Gesundheitsquelle auf der Lastverteilungs-Ebene. Da Cloud DNS keinen paketierten Gesundheitsprüfungs-Failover-Datensatz bereitstellt, attachen Sie die Gesundheitsprüfung, wo sie lebt: auf der Managed ALB- oder NLB-Zielgruppe, die jeden Endpunkt vorne hat, konfigurieren Sie die periodische Gesundheitsprüfung, damit der Lastverteiler nur gesunde Ziele bedient. Dies ist das Erkennungssignal, auf das Ihr Failover reagiert.
7. Verdrahten Sie den automatischen Umstieg auf der API-Ebene. Um das Failover automatisch anstatt operatorengesteuert zu machen, treiben Sie die Datensatz-Aktualisierung von der Überwachung oder Orchestrierung: bei einem anhaltenden ungesunden Signal für Zone 1, rufen Sie die Cloud DNS-API-Schnittstelle auf, um den Datensatz-Inhalt auf die Zone-2-Adresse zu aktualisieren. Der Konsolen-Pfad ist die Zonen- und Datensatz-Verwaltung; die Automatisierung ist die API-Bearbeitung, also halten Sie diesen Teil-Schritt-Design und die API-Ebene, anstatt einen Konsolen-Assistenten zu erfinden.
8. Überprüfen Sie durch Simulation eines Fehlers. Nehmen Sie den primären (Zone 1) Endpunkt aus dem Dienst oder lassen Sie seine Gesundheitsprüfung fehlschlagen, dann lösen Sie den Datensatz-Umstieg auf die Standby-Adresse aus. Von einem externen Client aus, nachdem der TTL abgelaufen ist, bestätigen Sie, dass der Name jetzt auf die Zone-2-Adresse auflöst und dass neue Verbindungen den Standby-Endpunkt erreichen. Bestätigen Sie, dass eine bereits offene Verbindung nicht umgestellt wird, bis sie neu verbunden wird, was die Anforderung der Zustandslosigkeit der Ebene beweist.

Häufige Fehler:

• Paarige Endpunkte in der Auto-Verfügbarkeitszone zu lassen. Auto ist ein Hinweis auf eine einzelne AZ, nicht auf eine Verteilung über Zonen; setzen Sie explizite, verschiedene Zonen für beide Mitglieder des Paares, bevor Sie das Failover aufbauen.
• Einen langen TTL auf dem Failover-Datensatz zu setzen. Ein hoher TTL begrenzt Ihren erreichbaren RTO auf den TTL-Wert, da Resolver den zwischengespeicherten Antwortwert behalten; verringern Sie ihn auf nahe dem 60-Sekunden-Boden auf Datensätzen, die am Failover teilnehmen.
• anzunehmen, dass Cloud DNS ein gemanagtes Failover oder einen nativen Gesundheitsprüfungs-Datensatz hat. Es hat dies nicht; die Erkennung lebt auf den Lastverteilungs-Gesundheitsprüfungen und der automatische Umstieg ist eine API-getriebene Datensatz-Aktualisierung. Warten Sie nicht auf einen Konsolen-Button, der nicht existiert.
• zu erwarten, dass DNS Live-Verbindungen umstellt. DNS steuert nur neue Verbindungen; wenn die App-Ebene Sitzungsstatus auf der Instanz hält, brechen diese Sitzungen. Externalisieren Sie den Status auf die In-Memory-Ebene, damit die Ebene tatsächlich zustandslos ist.
• die Backup Service als Datenbank-Notfallwiederherstellungsplan zu behandeln. Es deckt VMs und Block Storage ab, nicht gemanagte Datenbanken; die Datenbank-Continuität ist PITR plus Dump/Wiederherstellung. Überprüfen Sie die Daten-Continuitäts-Ebene getrennt von der Steuerungsebene.

Eine kurze API-Ebene-Veranschaulichung der Umstieg-Bearbeitung (der architektonische Punkt ist, dass die DNS-Hälfte des Failovers eine kundenseitige Datensatz-Inhalts-Aktualisierung ist, nicht eine gemanagte Richtlinie und nicht etwas, das Cloud DNS von selbst auslöst):

# On a sustained zone-1 unhealthy signal, repoint the record to the zone-2 standby.
ionosctl dns record update --zone-id "$ZONE_ID" --record-id "$RECORD_ID" \
  --content "$STANDBY_ZONE2_ADDRESS"

Zusammenfassung

Die Ausfallsicherheit bei IONOS wird komponiert, nicht gekauft. Sie beginnen mit den geschäftseigenen RTO- und RPO-Werten, wählen eine von drei Wiederherstellungsstrategien, platzieren redundante Paare in explizit verschiedenen Zonen und trennen die Verkehrssteuerungsebene (Lastenausgleich-Health-Checks innerhalb einer Zone, plus ein kundenseitig orchestriertes low-TTL Cloud DNS Umleiten über Zonen) von der Datenkontinuitätsebene (Datenbank-PITR und Dump/Wiederherstellen, die Backup Service für virtuelle Maschinen und Block Storage, Object Storage Archiv). Es gibt kein verwaltetes Failover-Produkt und keinen verwalteten Cross-Zone-Orchestrator. Die Plattform-Health-Aware-Steuerung ist die Load Balancer (innerhalb ihres Pools) und IP Failover-Gruppen (innerhalb einer LAN); Cross-Zone-Failover ist eine kundenseitig gesteuerte API Record-Aktualisierung, die Cloud DNS bedient, aber nicht auslöst, da Cloud DNS nicht gesundheitsbewusst ist. Für Hybrid-Bestände decken dedizierte VMware vSAN und vSphere HA die Ausfallsicherheit innerhalb von Cluster, während die Plattform-Multi-Zone, die LB-plus-DNS-Zusammensetzung und VCDA die Kontinuität über Zonen und Standorte hinweg abdecken.

Wichtige Punkte:

• RTO und RPO sind Geschäftsentscheidungen; der Architekt entwirft sie und gibt an, was jede kostet. Die drei Strategien (Sicherung-Wiederherstellung, Pilot-Licht, Active-Active) handeln Kosten gegen Wiederherstellungszeit ein.
• Die Platzierung in Verfügbarkeitszonen muss für jedes redundante Paar explizit sein. Auto ist ein Single-AZ-Hinweis, und Block Storage hat eine Zone 3, die der Compute nicht hat.
• Die Plattform-Health-Aware-Steuerungsprimitiven sind Lastenausgleich-Health-Checks (innerhalb des LB-Backend-Pools) und IP Failover-Gruppen (innerhalb einer LAN); es gibt keinen verwalteten Cross-Zone-Orchestrator.
• Cloud DNS (Anycast, 14 PoPs, 99,995-prozentige SLA, 60-Sekunden-TTL-Boden) ist nicht gesundheitsbewusst und führt keine automatischen Failover durch. Cross-Zone-Failover ist eine kundenseitig gesteuerte low-TTL-Record-Re-Point, die Cloud DNS bedient, aber nicht auslöst; der TTL-Boden ist der dominierende RTO-Hebel und DNS steuert neue Verbindungen nur.
• Halten Sie die Steuerungsebene und die Datenkontinuitätsebene getrennt; die Backup Service deckt keine verwalteten Datenbanken ab, deren Kontinuität PITR plus Dump/Wiederherstellen ist.
• Innerhalb von Private Cloud geben vSAN (RAID-1/5/6, Mindestens 3 Hosts für RAID1) und vSphere HA die Ausfallsicherheit innerhalb von Cluster; die Kontinuität über Standorte hinweg ist VCDA, und es gibt keine Live-Mobilität über Standorte hinweg.

Wichtige Begriffe:

• RTO (Recovery Time Objective): die maximale tolerierbare Dauer eines Ausfalls; die Steuerungsebene ist darauf ausgelegt, sie zu erfüllen.
• RPO (Recovery Point Objective): die maximale tolerierbare Datenverlustzeit; die Datenkontinuitätsebene ist darauf ausgelegt, sie zu erfüllen.
• Auto-Verfügbarkeitszone: ein Single-AZ-Platzierungshinweis, der es IONOS ermöglicht, eine Zone auszuwählen, aber keine Multi-Zone-Redundanzanweisung.
• TTL-Boden: die niedrigste Record-Time-to-Live (60 Sekunden auf Cloud DNS); sie begrenzt die beste erreichbare DNS-getriebene RTO.
• VCDA (VMware Cloud Director Availability): das VMware-native asynchrone Replikations- und Failover-Tool für die Kontinuität des dedizierten VMware-Bestands über Standorte hinweg.

Weitere Lektüre

• Einheit 3.7: DNS und Failover-Routing (die Zone und die Aufzeichnung, die diese Einheit wiederverwendet)
• Einheit 3.6: Hybrid-Konnektivität (die Gateways, die Standorte während des Failovers verbinden)
• Einheit 5.7: Daten-Schutz und Lebenszyklus (die Daten-Continuitäts-Ebene im Detail)
• Einheit 4.4: Private Cloud (Dedicated VMware) und Einheit 7.4: Migration und Hybrid-Übergang (VCDA und das VMware-Anwesen)