Architektur der Notfallwiederherstellung von Hyper-V zu Azure

  • Artikel

Dieser Artikel beschreibt die Architektur und Prozesse, die mithilfe des Diensts Azure Site Recovery bei der Replikation, bei der Ausführung eines Failovers und beim Wiederherstellen von virtuellen Hyper-V-Computern (VMs) zwischen lokalen Hyper-V-Hosts und Azure verwendet werden.

Hyper-V-Hosts können optional in den privaten Clouds von System Center Virtual Machine Manager (VMM) verwaltet werden.

Architekturkomponenten – Hyper-V ohne VMM

Die folgende Tabelle und Grafik bietet eine Übersicht der Komponenten, die für die Hyper-V-Replikation in Azure verwendet werden, wenn die Hyper-V-Hosts nicht durch VMM verwaltet werden.

Komponente Anforderung Details
Azure Ein Azure-Abonnement, ein Azure-Speicherkonto und ein Azure-Netzwerk Replizierte Daten von lokalen VM-Workloads werden im Speicherkonto gespeichert. Azure-VMs werden mit den replizierten Workloaddaten erstellt, wenn ein Failover von Ihrer lokalen Site erfolgt.

Die Azure-VMs stellen eine Verbindung mit dem virtuellen Azure-Netzwerk her, wenn sie erstellt werden.
Hyper-V Während der Bereitstellung von Site Recovery sammeln Sie Hyper-V-Hosts und -Cluster in Hyper-V-Standorten. Sie installieren den Azure Site Recovery-Anbieter und den Recovery Services-Agent auf jedem eigenständigen Hyper-V-Host bzw. jedem Hyper-V-Clusterknoten. Der Anbieter orchestriert die Replikation mit Site Recovery über das Internet. Der Recovery Services-Agent verarbeitet die Datenreplikation.

Sowohl die Kommunikation vom Anbieter als auch vom Agent ist sicher und verschlüsselt. Die replizierten Daten im Azure-Speicher werden ebenfalls verschlüsselt.
Virtuelle Hyper-V-Computer Mindestens eine VM, die auf Hyper-V ausgeführt wird. Auf virtuellen Computern muss nichts explizit installiert werden.

Hyper-V-in-Azure-Architektur (ohne VMM)

Diagramm: Lokale Hyper-V-Standort-in-Azure-Architektur ohne VMM

Architekturkomponenten – Hyper-V mit VMM

Die folgende Tabelle und Grafik bieten eine Übersicht der Komponenten, die für die Hyper-V-Replikation in Azure verwendet werden, wenn die Hyper-V-Hosts durch VMM-Clouds verwaltet werden.

Komponente Anforderung Details
Azure Ein Azure-Abonnement, ein Azure-Speicherkonto und ein Azure-Netzwerk Replizierte Daten von lokalen VM-Workloads werden im Speicherkonto gespeichert. Azure-VMs werden mit den replizierten Daten erstellt, wenn ein Failover von Ihrer lokalen Site auftritt.

Die Azure-VMs stellen eine Verbindung mit dem virtuellen Azure-Netzwerk her, wenn sie erstellt werden.
VMM-Server Der VMM-Server verfügt über mindestens eine Cloud mit Hyper-V-Hosts. Auf dem VMM-Server installieren Sie den Site Recovery-Anbieter, um die Replikation mit Site Recovery zu orchestrieren. Außerdem registrieren Sie den Server im Recovery Services-Tresor.
Hyper-V-Host Mindestens ein von VMM verwalteter Hyper-V-Host/-Cluster. Sie installieren den Recovery Services-Agent auf jedem Hyper-V-Host bzw. Clusterknoten.
Virtuelle Hyper-V-Computer Mindestens eine VM, die auf einem Hyper-V-Hostserver ausgeführt wird. Auf VMs muss nichts explizit installiert werden.
Netzwerk Logische und VM-Netzwerke, die auf dem VMM-Server eingerichtet sind. Das VM-Netzwerk sollte mit einem logischen Netzwerk verbunden sein, das der Cloud zugeordnet ist. VM-Netzwerke sind virtuellen Azure-Netzwerken zugeordnet. Wenn Azure-VMs nach dem Failover erstellt werden, werden sie dem Azure-Netzwerk hinzugefügt, das dem VM-Netzwerk zugeordnet ist.

Hyper-V-in-Azure-Architektur (mit VMM)

Diagramm: Lokale Hyper-V-Standort-in-Azure-Architektur mit VMM

Einrichten der ausgehenden Netzwerkkonnektivität

Damit Site Recovery erwartungsgemäß funktioniert, müssen Sie die ausgehende Netzwerkkonnektivität ändern, um Ihrer Umgebung das Replizieren zu ermöglichen.

Hinweis

Site Recovery unterstützt die Verwendung eines Authentifizierungsproxys zur Steuerung der Netzwerkkonnektivität nicht.

Ausgehende Konnektivität für URLs

Lassen Sie den Zugriff auf die folgenden URLs zu, wenn Sie einen URL-basierten Firewallproxy zum Steuern der ausgehenden Konnektivität verwenden:

Name Kommerziell Behörden Beschreibung
Speicher *.blob.core.windows.net *.blob.core.usgovcloudapi.net Ermöglicht das Schreiben von Daten aus der VM in das Cachespeicherkonto in der Quellregion.
Microsoft Entra ID login.microsoftonline.com login.microsoftonline.us Stellt die Autorisierung und Authentifizierung für Site Recovery-Dienst-URLs bereit.
Replikation *.hypervrecoverymanager.windowsazure.com *.hypervrecoverymanager.windowsazure.com Ermöglicht die Kommunikation der VM mit Site Recovery.
Service Bus *.servicebus.windows.net *.servicebus.usgovcloudapi.net Ermöglicht es der VM, die Site Recovery-Überwachung und -Diagnosedaten zu schreiben.

Replikationsprozess

Diagramm: Hyper-V-in-Azure-Replikationsprozess

Replikations- und Wiederherstellungsprozess

Schutz aktivieren

  1. Nachdem Sie den Schutz für eine Hyper-V-VM über das Azure-Portal oder lokal aktiviert haben, wird Schutz aktivieren gestartet.
  2. Im Rahmen des Auftrags wird überprüft, ob der Computer die Voraussetzungen erfüllt. Anschließend wird CreateReplicationRelationship aufgerufen, um die Replikation mit den konfigurierten Einstellungen einzurichten.
  3. Der Auftrag startet die erste Replikation durch Aufrufen der Methode StartReplication, um eine vollständige VM-Replikation zu initiieren, und übermittelt die virtuellen Datenträger der VM an Azure.
  4. Sie können den Auftrag auf der Registerkarte Aufträge überwachen. Screenshot: Auftragsliste auf der Registerkarte „Aufträge“Screenshot: Bildschirm „Schutz aktivieren“ mit weiteren Details

Erste Datenreplikation

  1. Wenn die erste Replikation ausgelöst wird, wird eine Schattenkopie Hyper-V-VM-Schattenkopie erstellt.
  2. Virtuelle Festplatten auf der VM werden einzeln repliziert, bis alle nach Azure kopiert wurden. Dies kann eine Weile dauern, abhängig von der Größe der VM und der Netzwerkbandbreite. Erfahren Sie, wie die Netzwerkbandbreite erhöht werden kann.
  3. Falls während der ersten Replikation Datenträgeränderungen auftreten, werden die Änderungen mit dem Replication Tracker für Hyper-V-Replikate in Form von Hyper-V-Replikationsprotokollen (.hrl) nachverfolgt. Diese Protokolldateien befinden sich im gleichen Ordner wie die Datenträger. Jeder Datenträger verfügt über eine zugeordnete HRL-Datei, die an den sekundären Speicher gesendet wird. Beachten Sie, dass die Momentaufnahme- und Protokolldateien Festplattenressourcen belegen, während die anfängliche Replikation durchgeführt wird.
  4. Nach Abschluss der ersten Replikation wird die VM-Schattenkopie gelöscht.
  5. Die im Protokoll erfassten Datenträgeränderungen werden synchronisiert und mit dem übergeordneten Datenträger zusammengeführt.

Abschließen des Schutzprozesses

  1. Nach Abschluss der ersten Replikation wird der Auftrag Schutz auf dem virtuellen Computer abschließen ausgeführt. Dies konfiguriert Einstellungen für das Netzwerk und andere Einstellungen für die Zeit nach der Replikation, sodass die VM geschützt ist.
  2. In dieser Phase können Sie die VM-Einstellungen überprüfen, um sicherzustellen, dass sie bereit ist für das Failover. Sie können einen Notfallwiederherstellungstest (Testfailover) für die VM ausführen, um zu überprüfen, ob das Failover wie erwartet ausgeführt wird.

Deltareplikation

  1. Nach der ersten Replikation beginnt die Deltareplikation gemäß der Replikationsrichtlinie.
  2. Der Replication Tracker für Hyper-V-Replikate verfolgt die Änderungen einer virtuellen Festplatte als HRL-Dateien. Jedem für die Replikation konfigurierten Datenträger ist eine HRL-Datei zugeordnet.
  3. Das Protokoll wird an das Speicherkonto des Kunden gesendet. Beim Übermitteln eines Protokolls an Azure werden Änderungen am primären Datenträger in einer anderen Protokolldatei im gleichen Ordner nachverfolgt.
  4. Während der Erst- und Deltareplikation können Sie die VM im Azure-Portal überwachen.

Neusynchronisierungsprozess

  1. Falls die Deltareplikation nicht erfolgreich ist und eine vollständige Replikation viel Bandbreite oder Zeit beanspruchen würde, wird die VM für eine Neusynchronisierung markiert.

    • Wenn beispielsweise die Größe der HRL-Dateien 50 % des Festplattenspeichers erreichen, wird die VM für die Neusynchronisierung gekennzeichnet.
    • Standardmäßig ist die Neusynchronisierung so geplant, dass sie automatisch außerhalb der Geschäftszeiten durchgeführt wird.

  2. Die Neusynchronisierung sendet nur Deltadaten.

    • Dies minimiert die Menge der gesendeten Daten durch die Berechnung von Prüfsummen der Quell- und Ziel-VMs.
    • Sie verwendet einen Blockerstellungsalgorithmus mit festen Blöcken, durch den Quell-und Zieldateien in feste Blöcke unterteilt werden.
    • Für jeden Block werden Prüfsummen generiert. Sie werden verglichen, um zu ermitteln, welche Blöcke aus der Quelle auf das Ziel angewendet werden müssen.

  3. Nach Abschluss der Neusynchronisierung wird die normale Deltareplikation fortgesetzt.

  4. Wenn Sie nicht auf die Standardneusynchronisierung außerhalb der Geschäftszeiten warten möchten, können Sie eine VM manuell neu synchronisieren. Wenn z.B. ein Ausfall auftritt. Wählen Sie dazu im Azure-Portal die VM und >neu synchronisieren aus.

    Screenshot: Option „Resynchronisieren“

Wiederholungsprozess

Im Falle eines Replikationsfehlers wird die integrierte Wiederholungsfunktion verwendet. Das Wiederholen wird wie in der Tabelle beschrieben klassifiziert.

Kategorie Details
Nicht behebbare Fehler Es wird kein erneuter Versuch unternommen. Der Status der VM wird als Kritisch eingestuft sein, und ein Administrator muss eingreifen.

Beispiele für diese Fehler sind: Eine unterbrochene VHD-Kette, ein ungültiger Status der Replikat-VM, Netzwerkauthentifizierungsfehler, Autorisierungsfehler und „VM nicht gefunden“-Fehler (bei eigenständigen Hyper-V-Servern).
Behebbare Fehler In jedem Replikationsintervall wird ein weiterer erneuter Versuch unternommen. Dabei wird ein exponentielles Backoff verwendet, durch das sich das Wiederholungsintervall ab dem ersten Versuch immer weiter verlängert (1, 2, 4, 8 und 10 Minute(n)). Wenn ein Fehler auftritt, versuchen Sie es jede halbe Stunde erneut. Beispiele: Netzwerkfehler, Fehler aufgrund von geringem Speicherplatz und wenig Arbeitsspeicher.

Failover- und Failbackprozesse

  1. Sie können ein geplantes oder ungeplantes Failover von lokalen Hyper-V-VMs zu Azure ausführen. Wenn Sie ein geplantes Failover durchführen, werden die Quell-VMs heruntergefahren, um sicherzustellen, dass kein Datenverlust auftritt. Führen Sie ein ungeplantes Failover aus, wenn kein Zugriff auf Ihren primären Standort möglich ist.
  2. Sie können ein Failover für einen einzelnen Computer ausführen oder Wiederherstellungspläne erstellen, um das Failover von mehreren Computern zu orchestrieren.
  3. Sie führen ein Failover aus. Nachdem die erste Phase des Failovers abgeschlossen ist, sollten Sie die erstellten Replikat-VMs in Azure sehen können. Sie können der VM bei Bedarf eine öffentliche IP-Adresse zuweisen.
  4. Anschließend führen Sie ein Commit für das Failover durch, um von der Replikat-VM in Azure auf die Workload zuzugreifen.

Sobald Ihre lokale Infrastruktur wieder funktioniert und ausgeführt werden kann, können Sie ein Failback ausführen. Das Failback erfolgt in drei Phasen:

  1. Sie starten ein geplantes Failover von Azure zum lokalen Standort:

    • Weniger Ausfallzeiten: Wenn Sie diese Option verwenden, synchronisiert Site Recovery Daten vor dem Failover. Dies überprüft auf geänderte Datenblocks und lädt sie dann auf die lokale Site herunter, während die Azure-VM weiterhin ausgeführt wird, was die Downtime minimiert. Wenn Sie manuell angeben, dass das Failover abgeschlossen werden soll, wird die Azure-VM heruntergefahren, alle letzten Deltaänderungen werden kopiert und das Failover startet.
    • Vollständiger Download: Bei dieser Option werden Daten während des Failovers synchronisiert. Mit dieser Option wird der gesamte Datenträger heruntergeladen. Dies erfolgt schneller, da keine Prüfsummen berechnet werden. Jedoch kommt es zu mehr Downtime. Verwenden Sie diese Option, wenn Sie die Azure-Replikat-VM während einiger Zeit ausgeführt haben, oder wenn die lokale VM gelöscht wurde.
    • Erstellen einer VM: Sie können wählen, ob Sie ein Failback auf dieselbe VM oder auf eine andere VM ausführen wollen. Sie können angeben, dass Site Recovery die VM erstellen sollte, wenn sie nicht bereits vorhanden ist.

  2. Nach Beendigung der Erstsynchronisierung wählen Sie aus, dass das Failover abgeschlossen werden soll. Sobald dies abgeschlossen ist, können Sie sich bei der lokalen VM anmelden, um zu überprüfen, ob alles wie erwartet funktioniert. Im Azure-Portal können Sie sehen, dass die Azure-VMs beendet wurden.

  3. Anschließend committen Sie das Failover, um alles abzuschließen, und greifen wieder von der lokalen VM auf die Workload zu.

  4. Nachdem Failbacks für die Workloads ausgeführt wurden, aktivieren Sie die umgekehrte Replikation, sodass die lokalen VMs erneut in Azure replizieren.

Nächste Schritte

Absolvieren Sie dieses Tutorial, um sich mit der Hyper-V-zu-Azure-Replikation vertraut zu machen.