Tags: Hyper-V, Synchronisierung
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äftsleitung 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>
Täglich Know-how für IT-Pros mit unserem Newsletter
Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infrastructure Architect unter anderem für den japanischen Konzern JTEKT/TOYODA mit Verantwortung über die Europastandorte Krefeld und Paris. Darüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Lokationen des Konzerns mit und ist spezialisiert auf hochverfügbare virtualisierte Microsoft-Umgebungen plus Hybrid Cloud Solutions. Zertifizierungen: MS Specialist und MCTS für Hyper-V/SCVMM, MCSE, MCITP, MCSA. Zusätzlich zertifiziert für PRINCE2 Projektmanagementmethode.
// Kontakt: E-Mail, Twitter, LinkedIn //
Ähnliche Beiträge
- FAQ zu Hyper-V Replica: Exchange, SQL Server, Domain Controller, Wiederherstellungspunkte
- Hyper-V Replica: VM-Replikation mit Zertifikaten verschlüsseln
- Hyper-V Replica: Virtuelle Maschinen auf USB-Medium zum Ziel-Host transportieren
- Hyper-V Replica: Virtuelle Maschinen an andere Standorte übertragen
- Passwortänderungen und Kennwortschutz von Azure AD in das lokale Active Directory zurückschreiben