Mit Windows Server 2012 und dem damit verbundenen Hyper-V 3.0 wird eine neue Funktion namens Hyper-V-Replikat, besser bekannt unter der englischen Bezeichnung Hyper-V Replica, eingeführt.
Hyper-V-Replikat bietet die Möglichkeit, virtuelle Maschinen auf einen anderen Host replizieren zu lassen. Das besondere daran ist, das dazu kein shared storage notwendig ist. Somit lässt sich die neue Funktion mit Standard-Servern und ohne großen Aufwand einrichten. Diese neue Funktion ist ebenfalls im kostenlos erhältlichen Hyper-V Server 2012 enthalten.
Hyper-V-Replikat funktioniert innerhalb einer Domäne, aber auch mit unterschiedlichen Domänen als auch in der Arbeitsgruppe. Die Hyper-V Server müssen nicht in der gleichen Domäne oder Arbeitsgruppe sein.
Innerhalb einer Domäne kann die Replikation über Port 80 (http) mit Kerberos-Authentifizierung erfolgen. Allerdings wird dann der Datenverkehr nicht verschlüsselt. Alternativ kann eine Übertragung über Port 443 (https) erfolgen, dazu sind allerdings entsprechende Zertifikate notwendig. Letztgenannte Möglichkeit ist Voraussetzung für den Betrieb in einer oder unterschiedlichen Arbeitsgruppen als auch bei stand-alone Servern. Eine Anleitung für einen solchen Betrieb folgt weiter unten in diesem Artikel.
Ferner müssen die Server räumlich nicht unmittelbar in der Nähe sein. Eine Replikation in einen anderen Brandabschnitt eines Gebäudes oder Geländes oder gar an einen anderen Standort ist möglich.
Einen guten Einstieg bietet der Webcast von Carsten Rachfahl, der an dieser Stelle wärmstens empfohlen wird.
Was kann Hyper-V-Replikat?
- Automatische, intervall-gesteuerte Replikation von virtuellen Maschinen auf einen weiteren Hyper-V Host. Es können mehrere Wiederherstellungspunkte verwendet werden.
- Geplantes Failover von heruntergefahrenen virtuellen Maschinen.
- Ausführen eines Testfailovers. Eine replizierte, virtuelle Maschine kann ohne Netzwerk gestartet und dadurch überprüft werden.
Was kann Hyper-V-Replikat nicht?
- Es findet keine Echtzeit-Replikation statt. Das bedeutet, das zwischen dem Primär- und dem Replikat-Server immer eine Differenz im Datenbestand besteht.
- Kein automatisches Failover. Dafür ist ein Hyper-V-Cluster notwendig, der wiederum shared storage voraussetzt. Alternativ kann auf Lösungen wie z. B. Stratus Avance gesetzt werden.
- Keine Quick oder Live Migration. Das bedeutet, das keine laufenden, virtuellen Maschinen von einem Hyper-V-Host auf einen Anderen verschoben werden können. Dies gilt auch für die shared nothing live migration.
- Keine Lastverteilung.
Kurz gesagt: Hyper-V-Replikat ist keine HA(High Availability)- oder FT(Fault Tolerance)-Lösung.
Trotz der einen oder anderen Einschränkung ist Hyper-V-Replikat eine neue, interessante Funktion, mit der auch in (sehr) kleinen Umgebungen eine höhere Verfügbarkeit und ein Stück weit mehr Ausfallsicherheit erreicht werden kann.
Anleitung zu Hyper-V-Replikat in Arbeitsgruppen oder bei stand-alone Servern
Diese Anleitung bezieht sich auf zwei stand-alone Hyper-V Server 2012. Jeder Host ist in einer anderen Arbeitsgruppe. Für die Replikation kommt in dieser Konstellation nur die Authentifizierung mit Zertifikaten in Frage. Der Einfachheit halber werden selbstsignierte Zertifikate verwendet. Neben den zwei Hyper-V Servern wird eine Windows 8 Arbeitsstation für die Einrichtung und Verwaltung benötigt.
Windows 8
- Windows Software Development Kit (SDK) for Windows 8 herunterladen und installieren. Aus dem SDK wird das Tool “makecert.exe” benötigt um die Zertifikate für die Hyper-V Hosts erstellen zu können. Dieses Tool auf die Hyper-V Hosts kopieren.
- Unter “Systemsteuerung – Programme und Funktionen – Windows-Funktionen aktivieren und deaktivieren – Hyper-V” die “Hyper-V-Verwaltungstools” aktivieren.
- HVRemote herunterladen.
- In einer Eingabeaufforderung mit erhöhten Rechten folgende Befehle ausführen:
cscript hvremote.wsf /anondcom:grant cmdkey /add:HYPER-V-COMPUTERNAME /user:HYPER-V-COMPUTERNAME\Administrator /pass
Der cmdkey-Befehl muss für jeden Hyper-V angepasst und ausgeführt werden.
Hyper-V Server 2012
Auf allen Hyper-V Hosts muss die Remoteverwaltung aktiviert sein. Ferner sollten statische IP-Adressen konfiguriert werden. Damit die Firewall den Replikationsverkehr durchlässt muss folgender Befehl pro Host ausgeführt werden:
netsh advfirewall firewall set rule group="Hyper-V-Replikat - HTTPS" new enable=yes
Nachfolgend wird von einem primären und einem recovery Host ausgegangen. Bei den Befehlen muss “<FQDN>” pro Host angepasst werden, z.B. “host1.test.local”.
Auf dem primären Host folgende Befehle ausführen:
makecert -pe -n "CN=PrimaryTestRootCA" -ss root -sr LocalMachine -sky signature -r "PrimaryTestRootCA.cer"
makecert -pe -n "CN=<FQDN>" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "PrimaryTestRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 PrimaryTestCert.cer
Auf dem recovery Host folgende Befehle ausführen:
makecert -pe -n "CN=RecoveryTestRootCA" -ss root -sr LocalMachine -sky signature -r "RecoveryTestRootCA.cer"
makecert -pe -n "CN=<FQDN>" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "RecoveryTestRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 RecoveryTestCert.cer
Nun muss die “*.CA.cer”-Datei auf den jeweils anderen Host kopiert werden. Auf dem primären Host wird das Zertifikat mit dem Befehl
certutil -addstore -f Root "RecoveryTestRootCA.cer"
importiert. Auf dem recovery Host wird das Zertifikat mit dem Befehl
certutil -addstore -f Root "PrimaryTestRootCA.cer"
importiert. Abschließend muss auf beiden Hosts der Befehl
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
ausgeführt werden.
Damit sind die Voraussetzungen für Hyper-V-Replikat erfüllt. Nun kann für alle gewünschten virtuellen Maschinen die Replikation konfiguriert werden. Dazu den Hyper-V-Manager auf der Windows 8 Arbeitsstation starten, beide Hyper-V Hosts hinzufügen und die jeweilige virtuelle Maschine mit der rechten Maustaste anklicken. Anschließend “Replikation aktivieren…” auswählen und dem Assistenten folgen.
Wichtig dabei ist, das bei der Angabe des Replikatserver der FQDN verwendet wird, der NetBIOS-Name reicht nicht aus und führt zu einer Fehlermeldung!
Troubleshooting
Im Test gab es Probleme mit den Zertifikaten, da den Hyper-V Hosts das primäre DNS-Suffix fehlte. Dieses kann mit folgenden Schritten konfiguriert werden:
- “regedit” öffnen.
- Zu “HKLM – SYSTEM – CurrentControlSet – services – Tcpip – Parameters” wechseln.
- Eine neue Zeichenfolge (REG_SZ) mit dem Namen “NV DOMAIN” anlegen. Als Wert den Domänennamen wie im Zertifikat angegeben eingeben.
- Neustart.
Anmerkung: Das Eintragen des DNS-Suffix in den Einstellungen des Computers bzw. der Netzwerkverbindung, wie in den Kommentaren beschrieben, hat weder bei mir noch bei einem Kunden funktioniert.
Sollte es dennoch zu Problemen bei der Einrichtung der Replikation in Verbindung mit den Zertifikaten kommen, so sollte die Auflösung der FQDN beider Server via DNS oder hosts-Datei überprüft werden.
Folgende Änderung auf beiden Server vornehmen:
- Die Datei “C:\Windoiws\System32\drivers\etc\hosts” editieren.
- Folgende an die eigene Umgebung angepasste Einträge hinzufügen:
192.168.0.30 PrimaryTest.lab.local 192.168.0.31 RecoveryTest.lab.local
Zwischen der IP-Adresse und dem FQDN einen TAB verwenden!
Quellen und Informationen
Understand and Troubleshoot Hyper-V Replica in Windows Server “8” Beta
Vorführen von Hyper-V-Replikat
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Hallo,
leider bekomme ich nach diesen Vorbereitungen die eigentliche
Replikation nicht gestartet. Beim Aktivieren erhalte ich folgende
Fehlermeldung:
Enabling replication failed.
Hyper-V failed to enable replication.
Hyper-V failed to enable replication for virtual machine ‘xxx’: The handle is in the wrong state for the requested operation (0x00002EF3). (Virtual Machine ID …)
Leider finde ich weder zu der Fehlermeldung noch zu dem Fehlercode
eine Erklaerung.
Hat jemand diese Fehlermeldung schon mal gesehen?
MfG,
tm
Der Fehler ist mir auch neu. Vielleicht das Problem mal im TechNet-Forum posten.
Danke für diesen Artikel. Funktioniert wie eine eins.
BTW. Das Problem mit dem Hostname (FQDN benötigt) lässt sich auch durch eintragen des DNS Suffixes in den erweiterten Computereinstellungen ändern.
Liebe Grüße
Wolfgang
Vielen Dank für den Eintrag, ich scheitere am FQDN Namen.
Wo genau, muss welcher Wert eingegeben werden?
Hallo Thom,
an welcher Stelle bist du denn?
Jeder Host muss einen eigenen, eindeutigen FQDN haben.
Dieser ist relevant für die Zertifikate.
Habe die Anleitung bis zum Schluss durch, ich kann das Zertifikat auswählen, jefdoch nur das des eigenen Servers. Ich habe zwei Server, ich kann aber nur das Zertifikat Auswählen welches ich auf dem entsprechenden Server gemacht habe.
Also auf Server 1 steht nur das Zertifikat von Server1 zur Auswahl, auf Server2 das von Server 2.
Es erscheint beim Replizieren der Fehler, dass der DNS Name nicht stimmt. Wenn ich keine Domäne habe, ist der FQDN des Hosts doch der eindeutige Name. Z.B Server-01 ? Oder wie lautet der FQDN für ein Host welcher nicht in der Domäne ist? wen ich bicht über das Web replizieren müsste hätte ich längst eone Domain erstellt
> Nun muss die “*.CA.cer”-Datei auf den jeweils anderen Host kopiert werden.
Nachdem die Zertifikate erzeugt wurden, müssen Diese jeweils auf den anderen Host kopiert werden.
Also das Zertifikat von Host 1 auf Host 2 kopieren und vice versa.
Danach müssen die Zertifikate importiert werden:
> certutil -addstore -f Root “RecoveryTestRootCA.cer”
Den Befehl je nach Host anpassen.
Steht aber alles in der Anleitung 😉
FQDN bedeutet per Definition (immer): computername.domain.tld
Unabhängig vom Domänenbetrieb bzw. -zugehörigkeit würde ich das wegen den Zertifikaten auf jeden Fall einhalten.
Hallo!
Wenn dir das hilft:
Ich habe 2 Batchfiles Do_On_Primary.cmd und Do_On_Replicat.cmd. Das jeweilige Batchfile in ein Verzeichnis c:\Replica_In_A_Workgroup kopieren.
MakeCert.exe in das Verzeichnis kopieren. In beiden Batchfiles das FQDN ausbessern. Beide Batchfiles starten und den Anweisungen folgen.
Gruss Wolfgang
Do_On_Replika.cmd
————————————–
Pause FQDN’s setzen auf Replica
set FQDNPRIM=hypvB.domain.tld
set FQDNREP=hypva.domain.tld
Pause FQDN für Primary = %FQDNPRIM% Replica = %FQDNREP%
Pause Pruefen ob wir auf Primary zugreifen können
dir \\%FQDNPRIM%\c$\Replica_In_A_Workgroup
Pause check ob OK
Pause Firewall auf Replica setzen und Zertifikat generieren
netsh advfirewall firewall set rule group=”Hyper-V-Replikat – HTTPS” new enable=yes
makecert -pe -n “CN=RecoveryTestRootCA” -ss root -sr LocalMachine -sky signature -r “RecoveryTestRootCA.cer”
makecert -pe -n “CN=%FQDNREP%” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “RecoveryTestRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 RecoveryTestCert.cer
copy RecoveryTestRootCA.cer \\%FQDNPRIM%\c$\Replica_In_A_Workgroup
Pause Auf Primary fortsetzen
certutil -addstore -f Root “PrimaryTestRootCA.cer”
reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
Pause Zertifikat des Primary importiert – das wars
Do_On_Primary.cmd
————————————–
Pause FQDN’s setzen auf Primary
set FQDNPRIM=hypvB.domain.tld
set FQDNREP=hypva.domain.tld
Pause FQDN für Primary = %FQDNPRIM% Replica = %FQDNREP%
Pause Pruefen ob wir auf Replica zugreifen können
dir \\%FQDNREP%\c$\Replica_In_A_Workgroup
Pause check ob OK
Pause Firewall auf Primary setzen und Zertifikat generieren
netsh advfirewall firewall set rule group=”Hyper-V-Replikat – HTTPS” new enable=yes
makecert -pe -n “CN=PrimaryTestRootCA” -ss root -sr LocalMachine -sky signature -r “PrimaryTestRootCA.cer”
makecert -pe -n “CN=%FQDNPRIM%” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “PrimaryTestRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 PrimaryTestCert.cer
copy PrimaryTestRootCA.cer \\%FQDNREP%\c$\Replica_In_A_Workgroup
Pause Do_On_Replica.cmd auf Replica %FQDNREP% starten und solange durchfuehren bis aufforderung zum Wechsel
certutil -addstore -f Root “RecoveryTestRootCA.cer”
reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
Pause Zertifikat des Replica importiert – Auf Replica fortsetzen
Pause das wars
Hallo Thom,
ich konnte dein Problem (dank eines weiteren Kunden) nachstellen.
Ich habe den Artikel um ein paar Kleinigkeiten erweitert:
1. Bei der Angabe des Replikatservers muss der FQDN verwendet werden, der NetBIOS-Name reicht nicht aus!
2. Die Namensauflösung per DNS oder per hosts-Datei muss funktionieren, andernfalls kommt’s ebenso zu einem Fehler in Verbindung mit den Zertifikaten.
Hallo Andy
Vielen dank für deine Bemühungen!
Da wir ein Shared Volume für den zugriff auf die vhds angeschafft haben, habe ich mich entschlossen eine Domain zu bevorzugen!
Ich werde beim nächsten Kunden jedoch die Anleitung gerne nochmal durchgehen, und bescheid geben obs geklappt hat!
Hallo,
ich habe mir erlaubt deine Anleitung etwas abzuändern und auf meinen Blog zu stellen als Hilfe wenn ich es wieder mal brauchen sollte: http://c-fi.de/8-blog/8-hyper-v-2012-r2-replikation-mit-hilfe-von-selbst-signierten-zertifikaten-keine-domaene-benoetigt.html
Es hat bei mir alles Problemlos funktioniert! 🙂
Danke!
Hallo Andy,
vielen vielen vielen dank für diese Anleitung.
Da wir nun die Virtualisierung in unserem Unternehmen einführen wollen und wir hier eher learning-by-doing betreiben was das Angeht, hat uns diese Anleitung echt einiges an Arbeitsstunden und nerven gespart.
Funktioniert perfekt!
Viele Grüße und schöne Ostertage,
Kai
Schade daß man nicht auf das fehlende makecert eingegangen ist. Wenn ich den Befehl ausführen möchte, erhalte ich die Info, “Befehl unbekannt” muß jetzt erst einmal auf die Suche gehen wo man das herbekommt.
Wo man “makecert” her bekommt wird doch im Beitrag erwähnt:
“Windows Software Development Kit (SDK) for Windows 8 herunterladen und installieren. Aus dem SDK wird das Tool „makecert.exe“ benötigt um die Zertifikate für die Hyper-V Hosts erstellen zu können.”
hi, danke für die Antleitung habe das wie beschrieben mit einem 2012r2 und 2016 probiert, leider finden die sich nicht…
aber wäre es nicht so, dass in der HyperV beim Zertifikat das jeweilige des Partners angezeigt werden müsste?
also der 2012 das vom 2016 und anders rum?
> hi, danke für die Antleitung habe das wie beschrieben mit einem 2012r2 und 2016 probiert, leider finden die sich nicht…
Was ist mit “…finden die sich nicht…” gemeint?
Firewall-Regeln, Netzwerkkategorie, Namensauflösung, ggf. Routing usw. mal prüfen.
Ist der FQDN bei der Angabe des Replikatservers richtig geschrieben bzw. identisch mit den Angaben in den Zertifikaten?
> aber wäre es nicht so, dass in der HyperV beim Zertifikat das jeweilige des Partners angezeigt werden müsste?
Die Zertifikatsauswahl gibt an, welches Zertifikat der jeweilige Computer verwendet, um sich sozusagen auszuweisen bzw. die Verbindung zu verschlüsseln.
Gegenseitig vertrauen tun sich die beteiligten Server durch das zuvor importierte CA-Zertifikat des jeweils anderen Computer.
Links:
Windows Pro – Hyper-V Replica: VM-Replikation mit Zertifikaten verschlüsseln
Hi Andy, der Beitrag ist jetzt fast 10 Jahre alt und hat bei meinen beiden Windows Server 2016 prima funktioniert.
Vielen Dank für diese tolle Anleitung.
Vg, Andreas Wass