Hyper-V Replica: Replizierte VMs testen und wiederherstellen

Bei Ausfall der produktiven Umgebung soll es Hyper-V Replica möglich machen, mit wenigen Klicks und innerhalb von Sekunden an Datendifferenz mit den replizierten VMs wieder online zu gehen. Mit Testfailover und geplantem Failover können Administratoren der Geschäfts­leitung dokumentieren, dass das Disaster Recovery trainiert wurde und dass im Ernstfall funktioniert.

Ist der Replikationsvorgang aktiviert, dann liegt die VM auf dem Replikatserver im ausgeschalteten Zustand vor und die VHD(X) Dateien befinden sich dementsprechend im Dateisystem des Ziel-Hosts. Ein manuelles Anschalten dieses Replikats führt zu einem Fehler und fängt somit ein versehentliches paralleles Hochfahren ab. Konflikte können eine Folge doppelt vergebener IPs sein, wenn Failover-TCP/IP nicht konfiguriert ist, oder auch von identischen Hostnamen.

Test-Failover

Eine VM auf dem Replikatserver lässt sich testen, indem man aus dem Kontextmenü des Replikates ein Testfailover ausführt. In diesem Fall wird auf Basis eines Snapshots eine temporäre Test-VM angelegt, welche sich abgekoppelt vom Netzwerk hochfahren lässt. Es werden differenzierende AVHDX-Dateien erstellt und diese sollten nach erfolgreichen Tests wieder zurückgezogen werden. Dies geschieht erneut über das Kontextmenü der VM unter Replikation => Testfailover beenden.

Die zusätzliche VM bekommt den Namenszusatz "- Test" und kann nach erfolgreichem Anlegen gestartet werden, um zu überprüfen, ob sie konsistent und einsatzbereit ist. Erfüllt sie diese Anforderungen, dann darf man davon ausgehen, dass die eigentliche replizierte VM im Fall eines Desasters ebenfalls einwandfrei bootet und die Applikationen fehlerfrei laufen.

Der geplante Failover

Ein geplanter Failover geht vom aktiven primären Host aus und kann auch zu Wartungszwecken ausgeführt werden, etwa um ihn zum Einspielen von Updates und anschließendem Neustart freizumachen. Denken Sie dabei auch über die benötigten Lizenzen auf dem sekundären Host nach, da ein Anschalten der bisher passiven VMs entsprechende Lizenzen benötigt. Diese sollten für den Desaster-Fall von vorneherein eingeplant werden. Eine Software Assurance auf dem primären System erlaubt nur das Erstellen von Cold Backups, also nicht den produktiven Einsatz von Replikaten.

Voraussetzung für den geplanten Failover ist, dass man die aktive VM herunterfährt und unmittelbar danach auf dem sekundären Host startet. Es muss also eine kurze Auszeit einkalkuliert werden. Nach dem eingeleiteten geplanten Failover wechseln Sie zum Replikatserver und übernehmen den Vorgang über das Kontextmenü der VM unter Replikation => Failover. Lassen Sie die Maschine starten und kehren Sie die Replikationsrichtung optional um. Voraussetzung dafür ist die Konfiguration des primären Host als Replikatserver. Analog dazu bietet PowerShell zur Automatisierung folgende Cmdlets an: (beginnen Sie auf dem primären Host):

Stop-VM –Name <VM>
Start-VMFailover -VMName <VM> -prepare

Jetzt übernehmen Sie den geplanten Failover am Replikatserver:

Start-VMFailover -VMName <VM>
Start-VM -Name <VM>

So kehren Sie die Replikation um:

Set-VMReplication -reverse -VMName <VM>

Der Failover

Beim Eintreten eines Desasters, wenn der Hyper-V-Host z.B. durch einen Hardware-Defekt ausfällt, kann man nun in wenigen Schritten mit den replizierten VMs wieder online gehen. Der Failover startet nicht automatisch!

Starten Sie über das Kontextmenü der ausgeschalteten Replikatmaschine den Failover und entscheiden Sie sich für einen Wiederherstellungszeitpunkt.

Führen Sie den Failover aus und die Maschine startet. Der Datenverlust wird seit Windows Server 2012 R2 mindestens 30 Sekunden betragen. Starten Sie die PowerShell und führen Sie zum Abschluss folgendes Cmdlet aus:

Complete-VMFailover –VMName <VM>