Test-Failover in Microsoft Azure

Ein Test-Failover ist ein wichtiger Bestandteil der DRaaS-Strategie (Disaster Recovery as a Service) in Microsoft Azure. Damit können Unternehmen Wiederherstellungsprozesse validieren, ohne die Produktionsumgebungen zu beeinträchtigen. Dazu wird die Wiederherstellung einer virtuellen Maschine (VM) von einem ausgewählten Recovery-Punkt (einem Backup) simuliert. Der Prozess erstellt eine temporäre VM in einem isolierten virtuellen Azure-Netzwerk (auch VNet genannt), um die Recovery-Prozeduren, -Konfigurationen und die Funktionsfähigkeit der Applikationen zu testen. Obwohl Test-Failover optional sind, wird ihre regelmäßige Durchführung dringend empfohlen, um zu gewährleisten, dass die Recovery-Prozesse zuverlässig funktionieren und aktuell sind. Sie können einen Testplan erstellen, der auf den Kosten- und Sicherheitsanforderungen Ihres Unternehmens basiert.

Sie können mehrere Recovery-Server gleichzeitig testen und deren Interaktion überprüfen. In dem Testnetzwerk kommunizieren die Server über ihre Produktions-IP-Adressen, können jedoch keine TCP- oder UDP-Verbindungen zu den Workloads in Ihrem lokalen Netzwerk initiieren.

Test-Recovery-Netzwerk

Um sicherzustellen, dass ein Test-Failover zu keinen Beeinträchtigungen für den Produktionsbetrieb führt, sollten Sie in Azure ein isoliertes virtuelles Netzwerk (VNet) für Testzwecke konfigurieren. Stellen Sie sicher, dass das Test-VNet keine Routing- oder Peering-Verbindungen zum Produktions-VNet hat. Testen Sie die Konnektivität von einer virtuellen Maschine im Test-VNet, um sicherzustellen, dass diese auf keine Produktionsressourcen zugreifen kann.

Test-Failover-Prozess

Der automatisierte Test-Failover-Prozess besteht aus den nachfolgenden Phasen.

Initiierung

In dieser Phase wählen Sie einen Recovery-Punkt aus und starten das Test-Failover.

Worker-Bereitstellung (temporärer Agent)

Während dieser Phase wird automatisch ein Worker (manchmal auch Arbeiter oder Arbeitsprozess genannt) bereitgestellt, der für die Test-Failover-Aktion verwendet wird. Die erste Bereitstellung des Workers für einen Test- oder Produktions-Failover kann einige Minuten dauern. Das Starten von Workern für nachfolgende Failover sollte dann schneller gehen.

Datenwiederherstellung

Während dieser Phase werden die Daten aus dem Backup Storage zu einem temporären Azure Blob Storage-Container kopiert. Die Zeit, die zum Kopieren oder Wiederherstellen der Daten benötigt wird, hängt von der Workload-Größe ab. Nachdem die Daten kopiert wurden, wird der Inhalt des Azure Blob Storage in ein verwaltetes Laufwerk konvertiert, das dann zum Starten der temporären VM verwendet wird.

Erstellen der Recovery-VM

Die Recovery-VM wird mit dem vorkonfigurierten isolierten Azure-VNet und -Subnetz verbunden. Standardmäßig wird der VM eine IP-Adresse zugewiesen, bei der das letzte Oktett mit der IP-Adresse der ursprünglichen Maschine übereinstimmt. Sie können die IP-Adresse vor dem Test-Failover in den Einstellungen des Recovery-Servers ändern. Während des Test-Failovers können Sie dies direkt im Azure-Portal tun.

Stellen Sie sicher, dass das VNet vom Produktionsnetzwerk isoliert ist, um unbeabsichtigte Interaktionen zu verhindern.

Verifizierung

Nachdem die VM erstellt wurde, werden Sie zur entsprechenden VM im Azure-Portal weitergeleitet, wenn Sie auf die Schaltfläche Verbinden klicken.

Führen Sie alle erforderlichen Tests durch, um das Verhalten der Applikationen, die Konnektivität und Ihre Wiederherstellungsvorgaben in der isolierten Umgebung zu überprüfen.

Das Test-Failover überschreibt keine bestehenden Recovery-Punkte, sodass Ihre Backups unverändert bleiben.

Das Test-Failover stoppen

Wenn Sie das Test-Failover beenden, werden die temporäre VM und die damit verbundenen Ressourcen sowie der Worker gelöscht. Wenn ein Verschlüsselungskenntwort verwendet wurde, wird es aus dem Anmeldedaten-Speicher automatisch wieder gelöscht, wenn das Test-Failover beendet oder abgeschlossen wurde.

Sie können das Test-Failover jederzeit über das Azure-Portal beenden.