Einheit 7.1: Resilienz und Business Continuity

Einführung

Resilienz ist kein Produkt, das Sie auf IONOS CLOUD kaufen; sie ist eine Eigenschaft, die Sie selbst zusammenstellen. Die Plattform stellt Ihnen Verfügbarkeitszonen, eine Load-Balancer-Ebene mit Health-Checks, einen Anycast-DNS-Dienst, eine Datenbanksicherung mit Wiederherstellung zu einem bestimmten Zeitpunkt sowie einen Sicherungsdienst zur Verfügung, verkauft aber keinen einzelnen „Failover"-Button, der all diese Komponenten orchestriert. Dieses Fehlen ist das zentrale Designmerkmal dieser Einheit. Ihre Aufgabe als Architekt besteht darin, eine Anforderung an die Business Continuity in eine Anordnung dieser Bausteine zu übersetzen und anschließend nachzuweisen, dass sie funktioniert.

Diese Einheit schließt mit dem Aufbau der steuernden Hälfte dieser Anordnung im Data Center Designer: ein von der Kundenseite orchestriertes Cloud DNS-Record-Paar mit niedriger TTL über zwei Zonen hinweg, sowie der Validierungsschritt, der bestätigt, dass ein Failover den Datenverkehr tatsächlich umleitet. Cloud DNS führt keine Health-Checks eigenständig durch, daher ist der Health-Check, der diesen Umschaltvorgang steuert, einer, den Sie selbst bereitstellen. Der Aufbau festigt, was Sie in den Einheiten 3.6 und 3.7 (Hybrid-Connectivity und DNS) provisioniert haben, nun betrachtet durch die Brille des Disaster Recovery. FinCorp, unser deutsches Finanzdienstleistungsunternehmen unter DSGVO- und BSI-Pflichten, verankert jede Entscheidung: ein zahlungsnahe Dienst, dessen Kontinuitätsziele von einem Regulierer und nicht von einer Engineering-Präferenz vorgegeben werden.

1. RTO, RPO und die drei Wiederherstellungsstrategien

Zwei Zahlen steuern jedes Kontinuitätsdesign, und das Unternehmen ist für beide verantwortlich. Das Recovery Time Objective (RTO) gibt an, wie lange der Dienst ausgefallen sein darf, bevor der Ausfall einen wesentlichen Schaden verursacht. Das Recovery Point Objective (RPO) gibt an, wie viel Daten, gemessen in Zeit, Sie sich leisten können zu verlieren. Ein Architekt, der diese Zahlen festlegt, trifft eine geschäftliche Entscheidung ohne die entsprechende Befugnis. Die Risikofunktion und die Compliance-Funktion von FinCorp legen sie fest; Sie entwerfen die Lösung so, dass sie diese Ziele erfüllt, und Sie legen offen dar, was jedes Ziel kostet.

Diese zwei Ankerpunkte bestimmen die Wiederherstellungsstrategie. Drei Strategien spannen den Bereich zwischen Kosten und Geschwindigkeit ab, und jede lässt sich klar auf IONOS CLOUD-Grundbausteine abbilden.

Die Strategie ist ebenso eine Budgetentscheidung wie eine Verfügbarkeitsentscheidung. Aktiv-aktiv verdoppelt den laufenden Fußabdruck und verlangt die engste Datenreplikation; Backup-Wiederherstellung ist günstig, aber langsam bei der Wiederherstellung und verliert die meisten Daten. Der zahlungsnahe Dienst von FinCorp kann ein RTO von mehreren Stunden nicht tolerieren, daher ist Backup-Wiederherstellung als primäre Strategie für diese Ebene ausgeschlossen, auch wenn sie für die Berichts- und Archivworkloads des Unternehmens die richtige Antwort bleibt. Das realistische Design für FinCorp ist Pilot-Light für den regulierten Kern: ein dauerhaft laufender Datenbankcluster mit einem Standby-Knoten, Rechenleistung, die vordefiniert ist und bei Failover hochskaliert, sowie DNS für die Umleitung.

Eine entscheidende Plattformwahrheit zieht sich durch alle drei Strategien. Der Backup Service (Acronis) deckt VMs und Block Storage ab; er sichert verwaltete Datenbanken nicht und bietet keine unveränderlichen Sicherungen. Die Datenbankkontinuität ist daher ein separater Mechanismus: Point-in-Time-Recovery innerhalb des Aufbewahrungsfensters des Clusters, plus Dump und Restore für alles, was darüber hinausgeht. Den Backup Service als Datenbank-DR-Plan zu behandeln, ist der teuerste Fehler in diesem Bereich, weil die Lücke erst während einer echten Wiederherstellung entdeckt wird. Snapshots verschärfen die Verwirrung: ein Block Storage-Snapshot ist eine regionale, nicht inkrementelle, VM-Ebene-Rollback-Funktion, keine datenbankkonsistente Sicherung. Planen Sie die Datenkontinuitätsebene um PITR und Dump/Restore für Datenschichten herum, und um den Backup Service nur für die VMs und Volumes, die er tatsächlich abdeckt.

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

Resilienz beginnt damit, wo Komponenten physisch platziert werden. IONOS CLOUD stellt Verfügbarkeitszonen als Platzierungsprimitive bereit, und die Redundanz, die Sie erhalten, hängt vollständig davon ab, dass gepaarte Ressourcen in verschiedenen Zonen platziert werden. Die Plattform wird Ihre Absicht nicht selbst ableiten.

Beachten Sie eine Asymmetrie, die Architekten häufig in die Falle lockt. Die Verfügbarkeitszonen für Compute sind Zone 1, Zone 2 und Auto. Die Verfügbarkeitszonen für Block Storage sind Zone 1, Zone 2, Zone 3 und Auto. Es gibt keine Compute Zone 3, sodass ein in Zone 3 platziertes Volume keinen Server in derselben Zone hat, an den es angebunden werden kann. Für ein redundantes Compute- und Storage-Paar sollten Sie innerhalb der Zonen planen, die beide Ebenen gemeinsam nutzen.

Die Falle liegt im Wort „Auto“. Die Auswahl der Auto-Verfügbarkeitszone ist eine Platzierungshinweis für eine einzelne Verfügbarkeitszone, die IONOS CLOUD erlaubt, eine Zone für Sie auszuwählen; es handelt sich nicht um eine Multi-Zone- oder „auf Zonen verteilen“-Anweisung. Wenn Sie zwei Server als HA-Paar anlegen und beide auf Auto belassen, ist nicht garantiert, dass sie in verschiedenen Zonen landen, und sie können dieselbe Zone teilen. Ein gemeinsamer Fehlerbereich ist genau das, was ein HA-Paar ausschalten soll. Die Regel ist eindeutig: Für jedes Paar, das einen Zonenausfall überstehen muss, müssen Sie explizit verschiedene Zonen festlegen. Auto ist für eine einzelne, nicht gepaarte Ressource akzeptabel, bei der Sie keine Zonenpräferenz haben; für Redundanz ist es falsch.

Für FinCorp bedeutet dies, dass der Standby-Datenbankknoten in einer explizit anderen Zone als der Primärknoten platziert wird, und dass das Pilot-Light-Compute-Template in einer benannten Zone bereitgestellt wird, die sich von der Produktionsebene unterscheidet. Die Disziplin der expliziten Zonenfestlegung ist im Design leicht umzusetzen und nach einem Ausfall, der belegt, dass das Paar kolloziert war, nicht mehr sauber nachzurüsten.

3. Health-basiertes Steering: LB-Health Checks, IP-Failover und kundenseitig orchestriertes DNS

IONOS CLOUD bietet kein verwaltetes Failover-Produkt an. Es gibt keinen Orchestrator, der eine Primärinstanz überwacht, deren Ausfall feststellt und eine Sekundärinstanz über den gesamten Stack hinweg befördert, und es gibt keinen verwalteten Failover-Dienst über Zonen oder Standorte hinweg. Es ist wichtig, präzise zu sein, welches Element das health-bewusste Steering übernimmt, denn es ist nicht Cloud DNS.

Die automatisierten, health-basierten Steering-Elemente der Plattform sind zwei. Erstens: Load-Balancer-Health Checks: Der Managed Application Load Balancer führt aktiv Health Checks für seine Backend-Ziele über TCP oder HTTP durch, während der Managed Network Load Balancer seine Ziele ausschließlich über TCP prüft (HTTP-bewusste Health Checks sind eine Fähigkeit, die nur dem ALB zur Verfügung steht); beide unterstützen konfigurierbare Intervalle und Wiederholungen und leiten den Traffic von ungesunden Zielen innerhalb des eigenen Backend-Pools des Load Balancers ab. Dies ist ein echtes automatisiertes Failover, es ist jedoch auf Region und LAN beschränkt: Es verschiebt den Traffic zwischen Zielen innerhalb eines Pools, nicht über Zonen oder Standorte hinweg. Zweitens: IP-Failover-Gruppen: Eine reservierte IP, die über VMs in einem LAN geteilt wird, für kundenseitig aufgebaute, anwendungsebene IP-Failover; auch diese ist LAN-lokal. Die Multi-Zone-Platzierung (Abschnitt 2) ist das dritte Element, handelt sich aber um Platzierung, nicht um Steering.

Failover über Zonen und Standorte hinweg liegt über all diesen Elementen, und hier gibt es keinen nativen, health-bewussten Mechanismus. Cloud DNS ist nicht health-bewusst: Es überwacht die Gesundheit von Endpunkten nicht und ändert einen Datensatz nicht von selbst. Failover über Zonen hinweg ist daher kundenseitig orchestriert: Ihr eigener Health Check (ein externer Monitor oder ein Signal, das aus dem Health-Zustand des Load Balancers abgeleitet wird) erkennt, dass der Endpunkt einer Zone ausgefallen ist, und ruft die Cloud DNS API auf, um einen Datensatz mit niedriger TTL auf die gesunde Zone neu zu zeigen. Der Beitrag von Cloud DNS besteht darin, dass der Datensatz Anycast ist, von einem SLA gedeckt ist und eine sehr niedrige TTL tragen kann; die Automatisierung zur Erkennung und Neuverweisung liegt bei Ihnen. Dies ist der Failover-Ersatz, der in Einheit 1.3 eingeführt wurde, und wird hier ehrlich umgesetzt: Kombinieren Sie ein health-bewusstes Element (den Load Balancer innerhalb einer Zone) mit einer kundenseitig gesteuerten DNS-Neuverweisung mit niedriger TTL über Zonen hinweg.

Cloud DNS ist gut für den DNS-Anteil dieser Kombination geeignet. Es läuft auf einem Anycast-Netzwerk über 14 Präsenzpunkte, bietet ein Verfügbarkeits-SLA von 99,995 Prozent pro Dienst und unterstützt eine TTL so niedrig wie 60 Sekunden. Diese TTL-Untergrenze ist der entscheidende RTO-Hebel für jedes DNS-basierte Failover, da ein Resolver eine zwischengespeicherte Antwort weiterverwendet, bis die TTL abläuft. Wenn Ihr Datensatz eine TTL von einer Stunde hat, kann Ihre DNS-gesteuerte Wiederherstellung eine Stunde nicht unterbieten, egal wie schnell Sie den Ausfall erkennen. Senken Sie die TTL für Datensätze, die am Failover beteiligt sind, und akzeptieren Sie die moderate Zunahme des Abfragevolumens als Preis für einen schnelleren Umschaltvorgang.

Zwei ehrliche Einschränkungen bestimmen, wie Sie dies aufbauen. Erstens: DNS steuert nur neue Verbindungen. Ein Client, der bereits eine Verbindung zum ausgefallenen Endpunkt hält, wird durch eine DNS-Änderung nicht verschoben; er muss sich neu verbinden, wobei er die neue Adresse auflöst. Aus diesem Grund müssen die Anwendungsebenen hinter einem DNS-Failover zustandslos sein, wobei Sitzungszustand und geteilter Zustand in der In-Memory-Ebene externalisiert werden, anstatt auf der Instanz gehalten zu werden. Zweitens: Die Fähigkeit zur Health-Check-Erfüllung liegt auf der Load-Balancer-Ebene (oder in Ihrem eigenen externen Monitor), niemals in Cloud DNS: Es gibt keinen Health-Check-Failover-Datensatztyp, weil Cloud DNS überhaupt keine Health Checks durchführt. In der Praxis kombinieren Sie die Ebenen: Ein Load Balancer bestimmt die Gesundheit innerhalb einer Zone, und ein kundenseitig gestufter API-Aufruf weist den DNS-Datensatz zwischen zonenweiten Endpunkten neu zu. Da dieser Umschaltvorgang über Zonen hinweg von Ihrem Monitoring- oder Orchestrierungstooling gesteuert werden muss und nicht von Cloud DNS, behandeln Sie die Datensatzaktualisierung als API-Ebenen-Design, nicht als einen Punkt-und-Klick-Konsolen-Assistenten; der Konsolenweg dient der Verwaltung von Zonen und Datensätzen, und Cloud DNS löst die Änderung niemals selbst aus.

4. Zwei Ebenen: Steuerung und Datenkontinuität

Ein dauerhaft resilientes Design trennt zwei Anliegen, da sie auf unterschiedlichen Zeitskalen und durch unterschiedliche Mechanismen ausfallen und wiederhergestellt werden.

Die Verkehrsebene für die Steuerung (Traffic-Steering) entscheidet, wohin Anfragen geleitet werden. Sie besteht aus Cloud DNS-Einträgen, TTL-Einstellungen und den Health Checks des Load Balancers, die den Zustand der Endpunkte bestimmen. Ihre Aufgabe besteht darin, neue Verbindungen schnell von einem ausgefallenen Standort wegzuleiten. Ihre Wiederherstellungsgeschwindigkeit ist durch den TTL-Mindestwert und die Health-Check-Intervalle begrenzt, nicht durch die Geschwindigkeit, mit der Daten kopiert werden können.

Die Datenkontinuitätsebene entscheidet, ob die Daten am Zielstandort aktuell und korrekt sind. Sie besteht aus dem Datenbank-Replikationsmodus und PITR, dem Backup Service für VMs und Block Storage, Dump/Restore für Datenbanken und Object Storage als Archivende. Ihre Wiederherstellungsmerkmale sind der RPO, der tatsächlich erreichbar ist, und die Dauer, die eine Wiederherstellung in Anspruch nimmt.

Das Vermischen beider Ebenen ist ein klassischer Fehler. Das Umleiten des Verkehrs auf einen Standby-Server innerhalb von Sekunden bringt nichts, wenn die Daten auf dem Standby-Server Stunden alt sind, und ein perfekt aktueller Replikationsstand ist nutzlos, wenn kein Mechanismus die Clients dorthin umleitet. Gestalten Sie jede Ebene für ihr eigenes Ziel: die Steuerungsebene für den RTO, die Kontinuitätsebene für den RPO. Das Pilot-Light-Design von FinCorp macht diese Trennung konkret: Health Checks des Load Balancers plus ein Cloud DNS-Eintrag mit niedriger TTL, der von einer externen Prüfung neu zugewiesen wird, bilden die Steuerungsebene, die den RTO erfüllt, während der dauerhaft aktive Standby-Datenbankknoten und sein PITR-Fenster die Kontinuitätsebene bilden, die den RPO erfüllt. Die beiden Ebenen sind nur im Moment des Wechsels (Cutover) miteinander verbunden.

5. Abgleich von dediziertem VMware HA mit der plattformseitigen Multi-Zone-Architektur

FinCorp betreibt eine große VMware-Umgebung, und ein Teil davon läuft auf IONOS CLOUD Private Cloud, der dedizierten, verwalteten VMware SDDC. Hybrid-Umgebungen tragen daher gleichzeitig zwei verschiedene Resilienzmodelle, und eine Architektin oder ein Architekt muss wissen, wo jeweils welches Modell greift.

Innerhalb eines Private-Cloud-Clusters ist die Fehlertoleranz eine VMware-Eigenschaft, keine Eigenschaft der Verfügbarkeizone der Plattform. vSAN (Version 8.0, Enterprise Edition gemäß der Private-Cloud-Dokumentation, auf vSphere 8.0 Enterprise Plus) schützt vor Host- und Festplattenausfällen durch Erasure Coding und Spiegelung. Die Matrix listet drei Methoden zur Fehlertoleranz: RAID-1-Spiegelung (mindestens 3 Hosts), RAID-5-Erasure Coding (mindestens 4 Hosts) und RAID-6-Erasure Coding (mindestens 6 Hosts). vSAN benötigt mindestens 3 Hosts, um den RAID1-Schutz (zwei vollständige Kopien der Daten) aufrechtzuerhalten, was die minimale Clustergröße darstellt. vSphere HA startet VMs auf verbliebenen Hosts neu, wenn ein Host ausfällt. Dies ist Resilienz innerhalb des Clusters: Sie hält die SDDC bei Hardwarefehlern innerhalb eines Clusters am Laufen und ist das native VMware-Betriebsmodell, das die Umgebung bereits kennt.

Was vSAN und vSphere HA nicht bereitstellen, ist Resilienz über Standorte hinweg. Sie schützen eine Workload vor dem Verlust eines Hosts innerhalb des Clusters; sie sorgen nicht dafür, dass eine Workload den Verlust des gesamten Standorts oder Clusters übersteht. Die Kontinuität über Standorte hinweg für die VMware-Umgebung ist eine Replikationsfrage, die von VMware Cloud Director Availability (VCDA, Version 4.7.x) behandelt wird. VCDA führt asynchrone Replikation und Failover zwischen Standorten durch, zu einem Preis von rund 50 EUR pro geschützter VM pro Monat. Die ehrliche Grenze, die in Einheit 4.4 genannt und in 7.4 fortgeführt wird, ist, dass das einzige VMware-Tooling, das IONOS CLOUD dafür auflistet, VCDA, NSX-T L2 VPN für die Layer-2-Erweiterung und vMotion innerhalb des Clusters ist. Es gibt keine Live-Mobilitätsfunktion über Standorte hinweg und keine weiteren VMware-Zusatzmodule, die man voraussetzen könnte.

Für ein hybrides FinCorp-Design ergänzen sich die beiden Modelle, anstatt miteinander zu konkurrieren. Innerhalb des dedizierten VMware-Kerns stützt man sich auf vSAN und vSphere HA für die Fehlertoleranz innerhalb des Clusters. Für die plattformnative Ebene (Standard-Compute, verwaltete Datenbanken, Container) stützt man sich auf eine explizite Multi-Zone-Platzierung, Load-Balancer-Health-Checks innerhalb einer Zone sowie von der Kundenseite orchestriertes DNS-Umleiten mit niedriger TTL über Zonen hinweg und Datenbank-PITR. Die Kontinuität über Standorte hinweg für die VMware-Umgebung ist die VCDA-Replikation; die Kontinuität über Zonen hinweg für die native Umgebung ist die Zusammensetzung aus DNS und Daten-Ebene aus den Abschnitten 3 und 4. Der Abgleichspunkt besteht darin zu erkennen, dass „HA" auf jeder Seite etwas anderes bedeutet und dass der Mechanismus einer Seite den der anderen nicht ersetzt.

DCD-Implementierungsanleitung

Sie werden einen DNS-Failover über zwei Zonen für einen FinCorp-Endpunkt einrichten und validieren, dass er den Datenverkehr steuert. Das Architekturziel ist die Steuerungsebene aus Abschnitt 4: ein Name, der auf einen primären Endpunkt in einer Zone aufgelöst wird und zu einem Standby-Endpunkt in einer anderen Zone verschoben werden kann. Dies kombiniert die Cloud DNS-Arbeit aus Einheit 3.7 mit der expliziten Zonen-Disziplin aus Abschnitt 2. Voraussetzungen: zwei Backend-Endpunkte (zum Beispiel zwei Load-Balancer- oder Serveradressen), die in explizit verschiedenen Verfügbarkeitszonen bereitgestellt werden, sowie das Berechtigungsniveau „Access and manage DNS“ oder die Rolle des Vertragsadministrators, die erforderlich ist, um Zonen und Datensätze zu verwalten.

Bauziel: Einen von der Kundensteuerung orchestrierten DNS-Failover-Datensatz mit niedriger TTL über ein Zonenpaar einrichten und validieren, wobei zu beachten ist, dass Cloud DNS keine eigenen Health-Checks durchführt.

Schritte (im Data Center Designer):

1. Bestätigen Sie, dass sich die beiden Endpunkte in verschiedenen Zonen befinden. Bevor Sie DNS berühren, verifizieren Sie im DCD, dass die primären und Standby-Ressourcen explizite, verschiedene Verfügbarkeitszonen (nicht Auto) aufweisen. Falls einer von beiden auf Auto gesetzt ist, korrigieren Sie die Platzierung zuerst; ein Failover-Datensatz vor einem gemeinsam platzierten Paar ist Theater.
2. Öffnen Sie den DNS Manager und wählen Sie „Create primary DNS zone“. Geben Sie den Zonennamen ein (die FinCorp-Domain oder Subdomain, die den Dienst fronten wird). Die Zone ist der Container für die Failover-Datensätze.
3. Nach der Bereitstellung der Zone öffnen Sie sie aus der Liste „Primary Zones“ über „Details & Records“.
4. Erstellen Sie den primären Datensatz. Fügen Sie einen Datensatz hinzu (zum Beispiel einen A-Datensatz), dessen Name der Dienst-Hostname und dessen Inhalt die Adresse des primären Endpunkts in Zone 1 ist. Setzen Sie die TTL niedrig (am oder nahe dem 60-Sekunden-Minimum), damit ein späterer Cutover schnell propagiert wird; diese TTL ist Ihr dominierender RTO-Hebel.
5. Notieren Sie die Adresse des Standby-Endpunkts in Zone 2. Während eines Failovers werden Sie denselben Datensatznamen auf diese Adresse zeigen. Halten Sie die Details des Standby-Endpunkts dokumentiert, damit der Cutover eine einzelne, eindeutige Änderung ist.
6. Definieren Sie die Health-Quelle auf der Load-Balancer-Ebene. Da Cloud DNS keinen paketierten Health-Check-Failover-Datensatz bereitstellt, hängen Sie den Health-Check dort an, wo er lebt: Konfigurieren Sie auf der Managed ALB oder NLB Target Group, die jeden Endpunkt frontet, den periodischen Health-Check, damit der Balancer nur gesunde Ziele bedient. Dies ist das Erkennungssignal, auf das Ihr Failover reagieren wird.
7. Verdrahten Sie den automatisierten Cutover auf API-Ebene. Um den Failover automatisch statt durch den Operator ausgelöst zu machen, steuern Sie die Datensatzaktualisierung von Monitoring oder Orchestration: Bei einem anhaltenden ungesunden Signal für Zone 1 rufen Sie die Cloud DNS API auf, um den Datensatzinhalt auf die Zone-2-Adresse zu aktualisieren. Der Konsolenaufbau ist das Zonen- und Datensatzmanagement; die Automatisierung ist die API-Änderung, daher halten Sie diesen Unterschritt auf Design- und API-Ebene, statt einen Konsolen-Assistenten zu erfinden.
8. Validieren Sie durch Simulation eines Ausfalls. Nehmen Sie den primären (Zone 1) Endpunkt aus dem Dienst oder lassen Sie seinen Health-Check fehlschlagen, dann lösen Sie die Datensatzaktualisierung auf die Standby-Adresse aus oder führenen Sie sie durch. Von einem externen Client aus bestätigen Sie nach Ablauf der TTL, dass der Name nun auf die Zone-2-Adresse aufgelöst wird und dass neue Verbindungen den Standby erreichen. Bestätigen Sie, dass eine bereits offene Verbindung nicht umgezogen wird, bis sie neu verbunden wird, was die Anforderung der zustandslosen Ebene beweist.

Häufige Fehler:

• Paarierte Endpunkte in der Auto-Verfügbarkeitszone zu belassen. Auto ist ein Hinweis auf eine einzelne AZ, keine Anweisung zur Verteilung über Zonen; setzen Sie explizite, verschiedene Zonen für beide Mitglieder des Paares, bevor Sie den Failover aufbauen.
• Eine lange TTL auf dem Failover-Datensatz zu setzen. Eine hohe TTL begrenzt Ihren erreichbaren RTO auf den TTL-Wert, da Resolver die zwischengespeicherte Antwort behalten; senken Sie sie auf nahe am 60-Sekunden-Minimum für Datensätze, die am Failover teilnehmen.
• Annahme, dass Cloud DNS einen verwalteten Failover oder einen nativen Health-Check-Datensatz hat. Das tut es nicht; die Erkennung liegt in den Load-Balancer-Health-Checks und der automatische Cutover ist eine API-gesteuerte Datensatzaktualisierung. Warten Sie nicht auf einen Konsolenknopf, der nicht existiert.
• Erwartung, dass DNS aktive Verbindungen verschiebt. DNS steuert nur neue Verbindungen; wenn die App-Ebene Sitzungszustand auf der Instanz hält, brechen diese Sitzungen ab. Externisieren Sie den Zustand in die In-Memory-Ebene, damit die Ebene wirklich zustandslos ist.
• Den Backup Service als Datenbank-DR-Plan zu behandeln. Er deckt VMs und Block Storage ab, nicht verwaltete Datenbanken; Datenbankkontinuität ist PITR plus Dump/Restore. Validieren Sie die Datenkontinuitätsebene separat von der Steuerungsebene.

Eine kurze API-Ebene-Illustration der Cutover-Änderung (der Architekturpunkt ist, dass die DNS-Hälfte des Failovers eine kundengesteuerte Aktualisierung des Datensatzinhalts ist, keine verwaltete Richtlinie und nichts, was 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

Resilience auf IONOS CLOUD wird aufgebaut, nicht gekauft. Man beginnt mit vom Unternehmen festgelegten RTO- und RPO-Werten, wählt eine von drei Wiederherstellungsstrategien, platziert redundante Paare in explizit verschiedenen Zonen und trennt die Steuerungsebene für den Datenverkehr (Health Checks des Load Balancers innerhalb einer Zone sowie ein von der Seite des Kunden orchestriertes Umleiten mit niedriger TTL über Cloud DNS zwischen Zonen) von der Ebene für die Datenkontinuität (PITR und Dump/Restore für Datenbanken, Backup Service für VMs und Block Storage, Object Storage Archive). Es gibt kein verwaltetes Failover-Produkt und keinen verwalteten Cross-Zone-Orchestrator. Das health-aware Steering der Plattform erfolgt über den Load Balancer (innerhalb dessen Pools) und IP-Failover-Gruppen (innerhalb eines LANs); das Cross-Zone-Failover ist ein von der Seite des Kunden getriebener API-Record-Update, den Cloud DNS bereitstellt, aber nicht auslöst, da Cloud DNS nicht health-aware ist. Für hybrite Umgebungen decken dedizierte VMware vSAN und vSphere HA die Fehlerresistenz innerhalb des Clusters ab, während die Multi-Zone-Architektur der Plattform, die Kombination aus LB und DNS sowie VCDA die Kontinuität zwischen Zonen bzw. zwischen Standorten sicherstellen.

Wichtige Punkte:

• RTO und RPO sind geschäftliche Entscheidungen; der Architekt plant entsprechend und legt dar, was jede Maßnahme kostet. Die drei Strategien (Backup-Restore, Pilot-Light, Active-Active) stellen Kosten gegen Wiederherstellungsgeschwindigkeit.
• Die Platzierung in Verfügbarkeitszonen muss für jedes redundante Paar explizit erfolgen. Auto ist ein Hinweis auf eine einzelne AZ, und Block Storage verfügt über eine Zone 3, die bei Compute nicht vorhanden ist.
• Die health-aware Steering-Primitiven der Plattform sind Load-Balancer-Health-Checks (innerhalb des LB-Backend-Pools) und IP-Failover-Gruppen (innerhalb eines LANs); es gibt keinen verwalteten Cross-Zone-Orchestrator.
• Cloud DNS (Anycast, 14 PoPs, 99,995 Prozent SLA, TTL-Untergrenze von 60 Sekunden) ist nicht health-aware und führt kein automatisches Failover durch. Das Cross-Zone-Failover ist ein von der Seite des Kunden orchestriertes Umleiten von Records mit niedriger TTL, das Cloud DNS bereitstellt, aber nicht auslöst; die TTL-Untergrenze ist der entscheidende Hebel für das RTO, und DNS steuert nur neue Verbindungen.
• Trennen Sie die Steuerungsebene von der Ebene für die Datenkontinuität; der Backup Service deckt verwaltete Datenbanken nicht ab, deren Kontinuität durch PITR plus Dump/Restore gewährleistet wird.
• Innerhalb von Private Cloud bieten vSAN (RAID-1/5/6, mindestens 3 Hosts für RAID1) und vSphere HA die Fehlerresistenz innerhalb des Clusters; die Kontinuität zwischen Standorten wird durch VCDA sichergestellt, und es gibt keine Live-Mobilität zwischen Standorten.

Wichtige Begriffe:

• RTO (Recovery Time Objective): die maximal zulässige Dauer einer Ausfallzeit; die Steuerungsebene wird so konzipiert, dass sie dieses Ziel erfüllt.
• RPO (Recovery Point Objective): der maximal zulässige Datenverlust, gemessen in Zeit; die Ebene für die Datenkontinuität wird so konzipiert, dass sie dieses Ziel erfüllt.
• Auto-Verfügbarkeitszone: ein Platzierungshinweis für eine einzelne AZ, mit dem IONOS CLOUD eine Zone auswählt; keine Anweisung für Multi-Zone-Redundanz.
• TTL-Untergrenze: die niedrigste Record-Lebensdauer (60 Sekunden bei Cloud DNS); sie begrenzt das bestmögliche, DNS-gesteuerte RTO.
• VCDA (VMware Cloud Director Availability): das VMware-eigene Tool für asynchrone Replikation und Failover zur Sicherstellung der Kontinuität zwischen Standorten für die dedizierte VMware-Umgebung.

Weitere Lektüre

• Einheit 3.7: DNS und Failover-Routing (die Zone und der Datensatz, die in dieser Einheit wiederverwendet werden)
• Einheit 3.6: Hybrid-Verbindlichkeit (die Gateways, die Standorte während eines Failovers verbinden)
• Einheit 5.7: Datensicherung und Lebenszyklus (die Ebene der Datenkontinuität im Detail)
• Einheit 4.4: Private Cloud (Dedicated VMware) und Einheit 7.4: Migration und Hybrid-Cutover (VCDA und das VMware-Umfeld)