Freigeben über

Failback von VMware-VMs nach der Notfallwiederherstellung in Azure

  • Artikel

Nach einem Failover zu Azure im Rahmen des Notfallwiederherstellungsprozesses können Sie ein Failback zu Ihrer lokalen Site durchführen. Bei Azure Site Recovery sind zwei Arten von Failback möglich:

  • Failback zum ursprünglichen Speicherort
  • Failback zu einem alternativen Speicherort

Wenn Sie ein Failover für einen virtuellen VMware-Computer durchgeführt haben, können Sie das Failback zum gleichen virtuellen lokalen Quellcomputer ausführen, sofern er lokal noch vorhanden ist. In diesem Szenario werden nur die Änderungen zurückrepliziert. Dieses Szenario wird als Wiederherstellung am ursprünglichen Speicherort bezeichnet. Wenn die lokale VM nicht vorhanden ist, handelt es sich um ein Szenario mit Wiederherstellung an einem alternativen Ort.

Hinweis

Ein Failback kann nur zum ursprünglichen vCenter- und Konfigurationsserver erfolgen. Sie können keinen neuen Konfigurationsserver bereitstellen und diesen zum Ausführen eines Failbacks verwenden. Darüber hinaus können Sie dem vorhandenen Konfigurationsserver kein neues vCenter hinzufügen und ein Failback zu diesem neuen vCenter ausführen.

Wiederherstellung am ursprünglichen Speicherort

Wenn Sie ein Failback zum ursprünglichen virtuellen Computer durchführen, müssen folgende Bedingungen erfüllt sein:

  • Wenn der virtuelle Computer von einem vCenter-Server verwaltet wird, muss der ESX-Host des Masterziels Zugriff auf den Datenspeicher des virtuellen Computers haben.
  • Wenn sich die VM auf einem ESX-Host befindet, aber nicht von vCenter verwaltet wird, muss sich die Festplatte in einem Datenspeicher befinden, auf den der Host des Masterziels zugreifen kann.
  • Wenn sich Ihr virtueller Computer auf einem ESX-Host befindet und nicht vCenter verwendet, müssen Sie für den ESX-Host des Masterziels eine Ermittlung ausführen, bevor Sie den erneuten Schutz ausführen. Dasselbe gilt auch bei einem Failback für physische Server.
  • Sie können ein Failback zu einem virtuellen Storage Area Network (vSAN) oder auf einen Datenträger, durchführen, der auf einem direktem Geräteverweis (RDM) basiert, wenn die Datenträger bereits vorhanden und mit dem lokalen virtuellen Computer verbunden sind.

Wichtig

Es ist wichtig, „disk.enableUUID= TRUE“ zu aktivieren, damit der Azure Site Recovery-Dienst während des Failbacks die ursprüngliche VMDK auf der VM identifizieren kann, auf den die ausstehenden Änderungen geschrieben werden. Wenn dieser Wert nicht auf TRUE festgelegt ist, versucht der Dienst, auf Grundlage der besten Leistung den entsprechenden lokalen virtuellen Datenträger zu ermitteln. Wenn der richtige virtuelle Datenträger nicht gefunden wird, erstellt der Dienst einen neuen Datenträger, auf den die Daten geschrieben werden.

Wiederherstellung an einem alternativen Speicherort

Wenn die lokale VM vor dem erneuten Schützen der VM nicht vorhanden ist, handelt es sich um ein Szenario, das als „Wiederherstellung an einem alternativen Ort“ bezeichnet wird. Mit dem Workflow zum erneuten Schützen wird die lokale VM neu erstellt. Dies verursacht auch einen vollständigen Datendownload.

  • Wenn Sie ein Failback zu einem alternativen Speicherort ausführen, wird der virtuelle Computer auf demselben ESX-Host wiederhergestellt, auf dem der Masterzielserver bereitgestellt ist. Der zum Erstellen des Datenträgers verwendete Datenspeicher ist derselbe Datenspeicher, der beim erneuten Schützen der VM ausgewählt wurde.
  • Sie können nur ein Failback nur auf einen VMFS- (Dateisystem für virtuelle Computer) oder vSAN-Datenspeicher ausführen. Wenn Sie über einen RDM verfügen, funktionieren das erneute Schützen und das Failback nicht.
  • Das erneute Schützen umfasst eine große anfängliche Datenübertragung gefolgt von den Änderungen. Dieser Prozess existiert, weil die VM lokal nicht vorhanden ist. Die vollständigen Daten müssen zurückrepliziert werden. Dieser erneute Schutz benötigt außerdem mehr Zeit als die Wiederherstellung am ursprünglichen Ort.
  • Sie können kein Failback auf RDM-basierte Datenträger durchführen. Nur neue virtuelle Datenträger (VMDKs) können in einem VMFS-/vSAN-Datenspeicher erstellt werden.

Hinweis

Bei einem physischen Computer kann nach einem Failover zu Azure das Failback nur als virtueller VMware-Computer erfolgen. Der Workflow ist dabei der gleiche wie bei der Wiederherstellung an einem anderen Speicherort. Stellen Sie sicher, dass Sie mindestens einen Masterzielserver und die erforderlichen ESX/ESXi-Hosts ermitteln, auf die Sie ein Failback ausführen müssen.

Nächste Schritte

Führen Sie die Schritte für den Failbackvorgang aus.