Failover testen und ausführen

Ein Notfallwiederherstellungsplan, der noch nie getestet wurde, ist lediglich eine Hypothese. Mit einem Testfailover können Sie überprüfen, ob Ihre VMs korrekt starten, Anwendungen gestartet werden und die Netzwerkverbindung in der Zielregion funktioniert – und das alles, ohne die Quellumgebung zu beeinträchtigen oder die laufende Replikation zu unterbrechen. Viele Organisationen stellen erst bei einem tatsächlichen Notfall fest, dass ihre Notfallwiederherstellungspläne Lücken aufweisen – genau dann, wenn ein fehlerhafter Plan den größten Schaden verursacht. Regelmäßige Testfailover sind in den meisten regulatorischen Rahmenwerken vorgeschrieben.

ASR unterstützt drei Arten von Failoveraktionen. Ein Testfailover erstellt Kopien der VMs nach dem Failover in einem isolierten Netzwerk (Sie geben das Ziel-VNet an), ohne die Replikation oder die Quellumgebung zu beeinträchtigen. Ein geplantes Failover wird für geplante Migrationen oder Wartungsarbeiten verwendet – zunächst werden alle verbleibenden Änderungen synchronisiert, anschließend wird die Quelle heruntergefahren und das Failover durchgeführt. Ein ungeplantes Failover (bei einem tatsächlichen Notfall) führt das Failover sofort vom aktuellsten Wiederherstellungspunkt aus durch, ohne auf eine abschließende Synchronisierung zu warten.

So führen Sie im Portal ein Testfailover aus: Wählen Sie das geschützte Element aus, klicken Sie auf Test Failover, wählen Sie einen Wiederherstellungspunkt aus (aktuellster absturzkonsistenter Punkt, aktuellster anwendungskonsistenter Punkt oder ein bestimmter Zeitpunkt) und wählen Sie ein virtuelles Zielnetzwerk aus (in der Regel ein dediziertes, isoliertes Test-VNet). ASR startet die VM in der Zielregion unter Verwendung der Replikadatenträger. Die Test-VM wird neben dem Replikat angezeigt, ist jedoch vollständig unabhängig – die Produktionsumgebung bleibt unbeeinträchtigt. Klicken Sie nach dem Test auf Cleanup test failover, um die Test-VMs zu löschen.

Während des Failovers wählen Sie einen Wiederherstellungspunkt aus dem Aufbewahrungszeitraum von ASR aus. Es stehen folgende Optionen zur Verfügung: Latest (lowest RPO) – der aktuellste absturzkonsistente Wiederherstellungspunkt, wodurch der Datenverlust minimiert wird. Latest processed – der zuletzt verarbeitete Punkt, der einige Minuten zurückliegen kann. Latest app-consistent – der aktuellste anwendungskonsistente Wiederherstellungspunkt, der zwar älter sein kann, aber eine saubere Wiederherstellung der Anwendung gewährleistet. Custom – ein bestimmter älterer Wiederherstellungspunkt, um einen bekannten, intakten Zustand vor einem Vorfall wiederherzustellen.

Ein Wiederherstellungsplan gruppiert mehrere geschützte VMs und legt die Reihenfolge und den Zeitpunkt ihres Failovers fest. Sie können angeben, welche VMs zuerst gestartet werden sollen (z. B. Datenbankserver vor Anwendungsservern), manuelle Genehmigungsschritte hinzufügen, um das Failover zur manuellen Überprüfung anzuhalten, und Azure Automation-Runbooks einfügen, die Skripts vor und nach dem Failover ausführen (z. B. zum Aktualisieren von DNS-Einträgen, Konfigurieren von Load Balancern oder Senden von Benachrichtigungen). Wiederherstellungspläne können unabhängig mit einem Testfailover getestet werden.

Ein Testfailover bietet die Möglichkeit, Ihr tatsächliches RTO (Recovery Time Objective) zu messen. Starten Sie eine Stoppuhr, sobald Sie das Failover einleiten, und stoppen Sie sie, wenn die Anwendung vollständig funktionsfähig und für Benutzer zugänglich ist. Ein typisches Azure-zu-Azure-Failover für eine einzelne VM ist in 15–30 Minuten abgeschlossen. Mehrschichtige Anwendungen mit Abhängigkeiten können jedoch länger benötigen. Dokumentieren Sie alle Schritte, die unerwartet viel Zeit beanspruchen (z. B. DNS-Propagation oder das Aufwärmen der Anwendung), und beheben Sie die Ursachen vor dem nächsten Test.

Nach einem geplanten Failover (z. B. bei der Migration in eine neue Region) führen Sie Commit aus, um das Failover abzuschließen. Durch das Übernehmen wird die Replikation von der Quelle beendet und die Ziel-VMs werden als neue primäre VMs markiert. Anschließend können Sie den Replikationsschutz aktivieren, um die Replikationsrichtung umzukehren und die ursprüngliche Quellregion zum neuen Notfallwiederherstellungsziel zu machen. So können Sie nach Behebung des Vorfalls ein Failback in die ursprüngliche Region durchführen.

Failback bezeichnet den Vorgang, bei dem Workloads nach einem Notfall oder einer geplanten Migration in die ursprüngliche Region zurückgeführt werden. Die Schritte sind: Schützen Sie die VMs nach dem Failover erneut (dadurch wird die Replikation umgekehrt und von der neuen primären Region zurück in die ursprüngliche Region durchgeführt), warten Sie, bis die erste Synchronisierung abgeschlossen ist, und führen Sie anschließend ein geplantes Failover zurück in die ursprüngliche Region durch. Für ein Failback muss die ursprüngliche Quellinfrastruktur noch intakt sein. Wenn sie zerstört wurde, müssen Sie möglicherweise zunächst die Landing Zone neu erstellen.

Nach einem Testfailover müssen Sie im Portal Cleanup test failover ausführen, um die Test-VMs und die zugehörigen Datenträger zu löschen. Ohne Bereinigung laufen die Test-VMs weiter und verursachen zusätzliche Computekosten. Durch die Bereinigung wird außerdem der Testfailoverstatus des geschützten Elements zurückgesetzt, sodass Sie künftig einen weiteren Test ausführen können. Eine automatisierte Bereinigung (z. B. durch die zeitgesteuerte Ausführung eine Stunde nach Testbeginn über ein Automation-Runbook) verhindert, dass vergessene Test-VMs tagelang laufen.

Jeder Test der Notfallwiederherstellung sollte einen Bericht zur Notfallwiederherstellungsübung hervorbringen, der Folgendes festhält: das Datum und das getestete Szenario, die verwendeten Wiederherstellungspunkte, die erreichten RTO- und RPO-Werte, festgestellte Probleme sowie ergriffene Maßnahmen zur Behebung. Diese Dokumentation erfüllt die Anforderungen von Prüfern für Rahmenwerke wie ISO 27001 und SOC 2, die regelmäßige Tests der Notfallwiederherstellung vorschreiben. Speichern Sie die Berichte zu den Übungen an einem sicheren Ort, auf den sowohl die IT- als auch die Geschäftskontinuitätsteams zugreifen können.

Die Preise für Azure Site Recovery werden pro geschützter Instanz und Monat berechnet – die Gebühr deckt sowohl den Replikationsdienst als auch die Orchestrierung ab. Zusätzlich werden Ihnen der von den verwalteten Replikadatenträgern in der Zielregion belegte Speicher sowie das Cache-Speicherkonto während der Replikation berechnet. Der ausgehende Datentransfer zwischen Azure-Regionen für Replikationsdaten wird zu den normalen Egress-Tarifen berechnet (anders als bei Azure Backup, bei dem der Egress zwischen gekoppelten Regionen kostenlos ist). Bei der Replikation von lokalen Umgebungen nach Azure können Sie für Azure-VMs mit Windows Server den Azure Hybrid Benefit nutzen, um Kosten zu reduzieren.

In dieser Lektion haben Sie gelernt: Mit einem Testfailover überprüfen Sie Ihren Notfallwiederherstellungsplan in einem isolierten Netzwerk, ohne die Produktionsumgebung zu beeinträchtigen. Wiederherstellungspläne legen die Reihenfolge eines Failovers für mehrere VMs mithilfe manueller Genehmigungsschritte und automatisierter Runbook-Aktionen fest. Ein Failback führt Workloads nach einem Notfall durch Umkehrung der Replikationsrichtung in die ursprüngliche Region zurück. Als Nächstes sehen wir uns Azure CDN zur Beschleunigung der globalen Inhaltsübermittlung an.