Dem Armin sei Seidn

Dem Armin sei Schmierzettel

2012R2 Hyper-V Replication und Zertifikate

leave a comment

Leitfaden für die Einrichtung:
http://www.it-administrator.de/themen/virtualisierung/fachartikel/191651.html

Hyper-V-Replica einrichten und betreiben (1)

Windows Server 2012 R2 verbessert die Ausfallsicherheit und Hochverfügbarkeit von Hyper-V deutlich. Bereits mit Windows Server 2012 führte Microsoft die Replikation von virtuellen Servern zwischen Hyper-V-Hosts ein, doch mit Hyper-V-Replica lassen sich virtuelle Server noch besser zwischen maximal drei Hyper-V-Hosts replizieren und synchron halten. Windows Server 2012 unterstützt in diesem Bereich nur zwei Hyper-V-Hosts für die Replikation. In der neuen Version können Administratoren die Replikation auch wie eine Serverkette anordnen. Dieser Workshop zeigt Ihnen, wie Sie Hyper-V-Replica für Stand-Alone-Server und Cluster einrichten und betreiben.
Hyper-V-Replica sind das doppelte Lottchen der Server-Virtualisierung.

Die Replikation der Serverdaten findet über das Dateisystem und das physische Netzwerk statt und benötigt weder spezielle Hardware noch Cluster. Die Replikationen lassen sich manuell oder nach einem Zeitplan durchführen. Produktiv ist Hyper-V-Replica sinnvoll, wenn Sie Hyper-V-Hosts vor Ausfall schützen wollen. Fällt ein Hyper-V-Server aus, können Sie die replizierten Server auf einem anderen Server aktiv schalten. Mit Hyper-V-Replica erlangen also auch kleine Umgebungen eine effiziente Ausfallsicherheit, ohne dazu auf spezielle Hardware oder einen Cluster zurückgreifen zu müssen.

In Windows Server 2012 ließ sich das kürzeste Synchronisierungsintervall auf fünf Minuten anpassen. Mit Windows Server 2012 R2 reduziert sich dieser Intervall auf 30 Sekunden, in denen die Daten zwischen den Hosts replizieren. Außerdem können Sie die Replikation auf bis zu 15 Minuten ausdehnen. Die Flexibilität hat sich also deutlich erhöht.

Hyper-V-Hosts für Replikation aktivieren
Hyper-V-Replica konfigurieren Sie entweder im Hyper-V-Manager, dem System Center Virtual Machine Manager 2012 R2 oder mit der PowerShell. Am einfachsten nehmen Sie die Einrichtung über einen Assistenten im Hyper-V-Manager vor. Dies ist auch im produktiven Betrieb möglich. Die Quell-VM läuft bei diesem Vorgang weiter und die Benutzer werden nicht beeinträchtigt. Natürlich kann die Übertragung der Serverdaten auf die Zielserver die Quell-Hosts etwas beeinträchtigen, Sie können nach der Einrichtung aber auch festlegen, dass die erste Übertragung zu den Ziel-Hyper-V-Hosts erst zu bestimmten Zeiten stattfinden soll, an denen keine Benutzer mit den virtuellen Servern auf dem Quellserver arbeiten.

Fällt ein Hyper-V-Host aus, lassen sich die replizierten Server online schalten, sobald diese eine aktuelle Kopie nutzen können. Da der Servername, die IP-Adresse und andere Einstellungen im virtuellen Server gespeichert sind, können die Benutzer nahezu uneingeschränkt weiter arbeiten. Nach der ersten Übertragung müssen nur noch Änderungen gesendet werden. Die erste Übertragung können Sie mit einem externen Datenträger vornehmen.

Die Replikation ist auch in Clustern möglich. In diesem Fall starten Sie die Replikation über das Kontextmenü des virtuellen Servers in der Failovercluster-Verwaltung. Die Einrichtung entspricht der Konfiguration ohne Cluster. Die Einstellungen für die Replikation nehmen Sie in diesem Fall ebenfalls in der Clusterverwaltung vor, indem Sie mit der rechten Maustaste auf den virtuellen Server klicken. In einem solchen Szenario können Sie virtuelle Server zum Beispiel zwischen einem Hyper-V-Cluster mit einem anderen Hyper-V-Cluster replizieren oder Sie lassen virtuelle Server von einem Cluster auf einen Standby-Server replizieren. Die Nutzung der Hyper-V-Replikation in einem Cluster ist allerdings optional. Alle Funktionen sind auch für alleinstehende Server verfügbar.

Damit Hyper-V-Hosts eine solche Replikation erlauben, müssen Sie diese zunächst für die einzelnen Hyper-V-Hosts aktivieren. Danach wählen Sie die virtuellen Server aus, die Sie replizieren lassen wollen. Dazu starten Sie den Assistenten über das Kontextmenü des gewünschten virtuellen Servers auf dem Quellserver, geben den Zielserver ein – also den Hyper-V-Host, auf den Sie den virtuellen Server replizieren wollen – und legen danach noch Zeitplan und weitere Einstellungen fest. Der virtuelle Server auf dem Quellserver bleibt aber weiterhin verfügbar und aktiv. Auf die Details kommen wir gleich zu sprechen. Sie müssen natürlich nicht alle virtuellen Server auf einem Hyper-V-Host replizieren lassen. Außerdem können Sie virtuelle Server zu verschiedenen Hyper-V-Hosts replizieren.

Damit ein Hyper-V-Host für Replikate zur Verfügung steht, müssen Sie auf dem Server in den Hyper-V-Einstellungen im Bereich „Replikationskonfiguration“ die Funktion aktivieren und an Ihre Bedürfnisse anpassen. Sie legen in diesem Bereich zum Beispiel die Verschlüsselung und Authentifizierung fest und von welchen Hyper-V-Hosts der aktuelle Server Replikate annimmt. Im ersten Schritt aktivieren Sie daher zunächst die Funktion, Einstellungen nehmen Sie noch keine vor.

Hyper-V-Replica steht uneingeschränkt auch auf Servern mit Hyper-V-Server 2012 R2 zur Verfügung. Setzen Sie diesen ein, lässt sich dieser Server optional über den Hyper-V-Manager von einem anderen Hyper-V-Host verwalten. Einstellungen bezüglich der Replikation können Sie auch über das Netzwerk vornehmen. Es gibt hier keine Unterschiede zu Windows Server 2012 R2.


Die zertifikatsbasierte Authentifizierung der Hyper-V-Replikation
muss zunächst auf dem entsprechenden Host eingerichtet werden.

Achten Sie während der Einrichtung von Hyper-V-Replica auch darauf, die notwendigen Regeln in der erweiterten Konfiguration der Firewall zu aktivieren. Der Einrichtungsassistent übernimmt nur die notwendigen Einstellungen in Hyper-V, ändert aber keinerlei Sicherheitseinstellungen auf dem Server oder aktiviert Firewall-Regeln. Die Firewall-Regel hat die Bezeichnung „Hyper-V-Replica HTTP-Listener“. Es gibt auch einen Listener für HTTPS, wenn Sie die Daten verschlüsselt übertragen wollen. Das ist in jedem Fall sinnvoll, vor allem in Produktivumgebungen. Bei den Regeln handelt es sich um eingehende Netzwerkregeln, für den ausgehenden Datenverkehr müssen Sie keine Änderungen vornehmen, da die Windows-Firewall diesen Verkehr ohnehin nicht blockiert.

Bei der Kerberos-Authentifizierung und der Verwendung von HTTP werden die replizierten Daten während der Übertragung nicht verschlüsselt. Nur bei der zertifikatbasierten Authentifizierung mit HTTPS verschlüsselt Hyper-V die Daten während der Übertragung. Den Namen der Firewall-Regel für HTTP sehen Sie in der Firewall-Verwaltung. Die Verwendung des Befehls ist analog zur http-Regel. Arbeiten Sie mit Hyper-V-Replica über HTTP, aktivieren die Firewall-Regel in der PowerShell mit

Enable-Netfirewallrule -displayname "Hyper-V Replica HTTP Listener (TCP-In)"

Hyper-V-Replikation mit SSL konfigurieren
In Produktions-Umgebungen sollten Sie die Daten virtueller Server SSL-verschlüsselt mit HTTPS übertragen. Das ist wesentlich sicherer und nicht sehr viel komplizierter in der Einrichtung. In diesem Fall weisen Sie den beteiligten Hyper-V-Hosts ein Zertifikat zu. Dazu müssen Sie Zertifikate verwenden, die Clients und Server authentifizieren können. Das Zertifikat muss dem Namen des Hyper-V-Hosts entsprechen. Sie haben hier die Möglichkeit, mit selbst signierten Zertifikaten zu arbeiten oder greifen auf Zertifikate der Active Directory-Zertifikatsdienste zurück. Wir zeigen Ihnen nachfolgend wie Sie die Einrichtung vornehmen.

In der lokalen Verwaltung von Zertifikaten auf einem Server mit Windows Server 2012 R2 installieren Sie im Active Directory Zertifikate auf einem Hyper-V-Hosts. Die Zertifikate kommen anschließend für die Authentifizierung der beteiligten Hyper-V-Hosts in der Replikation zum Einsatz.

Zunächst starten Sie über certlm.msc im Startbildschirm die Verwaltung der lokalen Zertifikate auf dem ersten Hyper-V-Host. Klicken Sie mit der rechten Maustaste auf „Eigene Zertifikate“ und wählen Sie „Alle Aufgaben / Neues Zertifikat anfordern“. Bestätigen Sie die Option „Active Directory-Registrierungsrichtlinie“ und aktivieren Sie danach die Option „Computer“ und klicken Sie dann auf „Registrieren“. Das Zertifikat wird jetzt in der Konsole angezeigt.

Sie können Zertifikate auch in der Befehlszeile erstellen. Das ist zum Beispiel für geskriptete Umgebungen sinnvoll. Um ein Zertifikat zu registrieren, erstellen Sie eine Text-Datei, mit der Sie danach eine Anfrage bei der Zertifizierungsstelle starten. Hierbei kann es sich um eine externe oder eine interne Zertifizierungsstelle handeln. Speichern Sie dazu die Textdatei mit dem folgenden Inhalt. Passen Sie den Servernamen in der vierten Zeile „Subject“ an Ihre Bedürfnisse an:

[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=SERVER.CONTOSO.COM"
Exportable = TRUE ; Private key is exportable
KeyLength = 2048 ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384
KeySpec = 1 ; AT_KEYEXCHANGE
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True ; The key belongs to the local computer account
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ;Server Authentication
OID=1.3.6.1.5.5.7.3.2 ;Client Authentication

Speichern Sie die Datei anschließend unter dem Namen replica.inf ab. Achten Sie auf die korrekte Endung der Datei. Auf Basis der Daten in dieser Datei erstellen Sie danach in der Befehlszeile eine weitere Datei mit der dazugehörigen Zertifikatsanfrage:

certreq -new replica.inf replica.req

Wechseln Sie dazu in das Verzeichnis, in dem Sie die INF-Datei gespeichert haben. Anschließend befinden sich zwei Dateien in diesem Verzeichnis. Mit der REQ-Datei stellen Sie bei Ihrer internen Zertifizierungsstelle – etwa den Active Directory-Zertifikatsdiensten – eine Online-Anfrage. Dazu verwenden Sie den Befehl:

certreq -submit -config "dc01.contoso.int\contoso-dc01-ca" 
 Replica.req replica.cer

Erhalten Sie eine Fehlermeldung, zum Beispiel, dass die Zertifikatvorlage nicht in Ordnung ist, verwenden Sie zusätzlich die Option „-attrib CertificateTemplate: Vorlage“. Alternativ erstellen Sie einen „Certifikate Signing Request“ (CSR). Mit dieser führen Sie eine Anfrage bei einer externen Zertifizierungsstelle durch. Aber auch von internen Zertifizierungsstellen können Sie diese Daten nutzen, zum Beispiel mit der Weboberfläche der Zertifikatsdienste. Dazu verwenden Sie den folgenden Befehl:

certutil -encode replica.req replica.csr

Anschließend öffnen Sie die CSR-Datei mit einem Texteditor und kopieren den Inhalt in die Zwischenablage. Mit diesen Daten schließen Sie die Anfrage ab. Rufen Sie dazu im lokalen Zertifikatespeicher des Servers (certlm.msc) die eigenen Zertifikate auf und lassen Sie sich die Eigenschaften des Zertifikats anzeigen. Sie sehen bei der erweiterten Verwendung des Schlüssels die „Client- und Serverauthentifizierung“, ohne die Sie ein Zertifikat nicht für Hyper-V-Replication nutzen können.

Im zweiten Teil des Workshops lesen Sie, wie Sie bei der Replikation mit selbstsignierten Zertifikaten arbeiten, virtuelle Server zwischen Hyper-V-Hosts replizieren und wie Sie ein Failover mit Hyper-V-Replica durchführen.

 

Hyper-V-Replica einrichten und betreiben (2)

Windows Server 2012 R2 verbessert die Ausfallsicherheit und Hochverfügbarkeit von Hyper-V deutlich. Bereits mit Windows Server 2012 führte Microsoft die Replikation von virtuellen Servern zwischen Hyper-V-Hosts ein, doch mit Hyper-V-Replica lassen sich virtuelle Server noch besser zwischen maximal drei Hyper-V-Hosts replizieren und synchron halten. Windows Server 2012 unterstützt in diesem Bereich nur zwei Hyper-V-Hosts für die Replikation. In der neuen Version können Administratoren die Replikation auch wie eine Serverkette anordnen. In diesem zweiten Teil des Workshops lesen Sie, wie Sie bei der Replikation mit selbstsignierten Zertifikaten arbeiten, virtuelle Server zwischen Hyper-V-Hosts replizieren und wie Sie ein Failover mit Hyper-V-Replica durchführen.
Hyper-V-Replica sind das doppelte Lottchen der Server-Virtualisierung.
Mit selbstsignierten Zertifikaten arbeiten
Alternativ zur Verwendung von richtigen Zertifikaten lässt sich auch mit selbstsignierten Zertifikaten auf den Hyper-V-Hosts arbeiten. In diesem Fall profitieren Sie von der Sicherheit der zertifikatsbasierte Authentifizierung, müssen aber keine komplizierten Maßnahmen vornehmen, um Zertifikate zu verwalten.

Dazu verwenden Sie makecert.exe aus dem Windows 8/8.1 SDK [1], das kostenlos zur Verfügung steht. Sie benötigen das Tool auf allen beteiligten Hyper-V-Hosts, um Zertifikate zu erstellen. Sie finden makecert.exe nach der Installation des Toolkits im Verzeichnis „C:\Program Files (x86)\ Windows Kits\8.0\bin\x64“. Die Installation kann auch auf einer Arbeitsstation erfolgen und lässt sich anschließend auf die beteiligten Server kopieren. Danach erstellen Sie zunächst auf dem ersten Server ein selbstsigniertes Zertifikat und dann auf den anderen Servern.

Für eine beispielhafte Replikation zwischen zwei Servern kopieren Sie zunächst makecert.exe auf alle beteiligten Hyper-V-Server. Nun öffnen Sie eine Befehlszeile auf dem ersten Server und geben den folgenden Befehl ein, um ein Zertifikat für eine Stammzertifizierungsstelle zu erstellen:

makecert -pe -n "CN=PrimaryRootCA" -ss root -sr LocalMachine 
 -sky signature -r "PrimaryRootCA.cer"

Geben Sie danach folgenden Befehl ein:

makecert -pe -n "CN=FQDN des Servers" -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 
 "PrimaryRootCA" -is root -ir LocalMachine 
 -sp "Microsoft RSA SChannel Cryptographic Provider" 
 -sy 12 PrimaryCert.cer

Wechseln Sie danach auf den zweiten Server und führen Sie folgenden Befehl aus, um dort ein selbstsigniertes Stammzertifizierungsstellenzertifikat zu erstellen:

makecert -pe -n "CN=SecondaryRootCA" -ss root -sr LocalMachine 
 -sky signature -r "SecondaryRootCA.cer"

Nutzen Sie dann das Kommando

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 "SecondaryRootCA " -is root -ir LocalMachine 
 -sp "Microsoft RSA SChannel Cryptographic Provider" 
 -sy 12 SecondaryCert.cer

Jetzt liegen auf den Servern alle notwendigen Zertifikate vor. Diese müssen Sie jetzt noch auf den anderen Server kopieren. Kopieren Sie die Datei SecondaryRoot-CA.cer vom zweiten Server auf den primären Server und geben Sie anschließend den folgenden Befehl ein:

certutil -addstore -f Root "SecondaryRootCA.cer"

Kopieren Sie danach PrimaryRootCA.cer vom primären Server auf den Replikatserver und geben Sie danach

certutil -addstore -f Root "PrimaryRootCA.cer"

ein. Jetzt vertrauen die beiden Server sich jeweils gegenseitig, was die Ausstellung von Zertifikaten betrifft. Öffnen Sie danach auf beiden Servern den Registry-Editor und navigieren Sie zu „HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Virtualization \ Replication“. Hier setzen Sie den Wert „DisableCertRevocationCheck“ auf „1“. Wenn vorhanden, navigieren Sie zu „HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Virtualization \ FailoverReplication“ und setzen auch hier den Wert „DisableCertRevocationCheck“ auf „1“.

Achten Sie darauf, dass die erstellten Zertifizierungsstellen auf den beiden Servern, auf denen Sie die selbst signierten Zertifikate erstellt haben, als vertrauenswürdig angezeigt werden. Sie sehen die Zertifikate im Zertifikatespeicher der Server. Diesen rufen Sie über certlm.msc auf. Ohne diese Zertifikate können Sie später Hyper-V-Replica nicht einrichten.

Wollen Sie Hyper-V-Replica im Cluster nutzen, müssen Sie zusätzlich einen Hyper-V-Replica Broker im Clustermanager von Windows Server 2012 R2 erstellen. Dabei gehen Sie vor wie bei jeder anderen Clusterressource auch. In diesem Fall sollten Sie aber erst ein neues Computerkonto im Snap-In „Active Directory-Benutzer und -Computer“ erstellen. Rufen Sie die Registerkarte „Sicherheit“ des neuen Kontos auf und geben Sie dem Computerkonto des Clusters „Vollzugriff „.

Um SSL für die Replikation zu nutzen, rufen Sie anschließend auf beiden Hyper-V-Servern die Hyper-V-Einstellungen auf und klicken auf „Replikationskonfiguration“. Dort aktivieren Sie die Option „Zertifikatbasierte Authentifizierung verwenden (HTTPS)“ und wählen das Zertifikat aus. Diese Einstellungen müssen Sie auf allen beteiligten Servern vornehmen. Richten Sie danach die Replikation ein. Erscheinen hier Fehler, sind die Zertifikate nicht korrekt. Überprüfen Sie in diesem Fall die vorangegangenen Schritte.

Virtuelle Server zwischen Hyper-V-Hosts replizieren
Um virtuelle Server zwischen Hyper-V-Hosts mit Windows Server 2012 R2 oder Hyper-V Server 2012 R2 zu replizieren, klicken Sie mit der rechten Maustaste auf den entsprechenden virtuellen Server und wählen „Replikation aktivieren“. Auch wenn Sie die Replikation generell für den Hyper-V-Hosts aktiviert haben, werden nicht automatisch alle virtuellen Server repliziert, sondern Sie müssen diese Einstellungen für jede einzelne VM wiederholen. Die Einrichtung erfolgt über einen Assistenten, mit dem Sie festlegen, wie Sie den ausgewählten virtuellen Server vom Quellserver auf den Zielserver replizieren wollen. Der virtuelle Server auf dem Quellserver bleibt dabei unverändert und muss auch nicht neu gestartet oder herunter gefahren werden.

Im Assistenten legen Sie danach die Zielserver und auch den Authentifizierungstyp für die Datenübertragung fest. Für Testumgebungen können Sie hier auch die Kerberos-HTTP-Übertragung verwenden. So sparen Sie sich die Einrichtung von Zertifikaten. Allerdings ist die Verwendung der zertifikatsbasierten Authentifizierung wesentlich besser geeignet, auch in einer Testumgebung. Welche Authentifizierung der Zielserver akzeptiert, legen Sie auf dem Zielserver in den Hyper-V-Einstellungen über „Replikationskonfiguration“ fest. Hier steuern Sie genau, welchen Datenverkehr der Zielserver überhaupt zulässt.


Für jede Replikation lassen sich die Verbindungsparameter einzeln festlegen.

Haben Sie, wie zuvor gezeigt, auf den Servern Zertifikate installiert und in den Hyper-V-Einstellungen hinterlegt sowie die zertifikatsbasierte Authentifizierung aktiviert, können Sie für die Datenübertragung auch diesen sicheren Authentifizierungstyp wählen. Zusätzlich steuern Sie während der Einrichtung auch, welche virtuellen Festplatten der Server Sie replizieren wollen. Sie müssen nicht unbedingt alle Festplatten zwischen Quell- und Zielserver replizieren. Außerdem legen Sie hier auch das Intervall für die Replikation fest.

Im Assistenten zur Einrichtung der Hyper-V-Replikation lassen sich die Snapshots des virtuellen Servers berücksichtigen. Hier legen Sie auch fest, ob Sie die erste Replikation nach der Einrichtung über ein Speichermedium wie eine externe Festplatte durchführen oder über das Netzwerk. Auch einen Zeitplan für die erste Übertragung legen Sie während der Einrichtung fest.

Wenn Sie die Replikation durchgeführt haben, befindet sich der virtuelle Server auf den konfigurierten Zielservern, bleibt aber ausgeschaltet. Das ist auch sinnvoll, da der replizierte Server über den gleichen Namen und die gleiche IP-Adresse wie der Quellserver verfügt. Über das Kontextmenü des virtuellen Servers auf dem Quellserver passen Sie das Replikationsverhalten an und erhalten den Status. Die Replikation von virtuellen Servern können Sie auch zwischen verschiedenen Editionen von Windows Server 2012 R2 durchführen oder Hyper-V Server 2012 R2 als Quell- und Zielserver zu nutzen.

Über das Kontextmenü des replizierten virtuellen Servers auf dem Zielserver können Sie auch ein Failover durchführen. In einem solchen Fall übernimmt das Replikat die Aufgaben des virtuellen Servers auf dem Quellserver. Natürlich lässt sich die Replikation jederzeit beenden oder pausieren. Bei jeder neuen Replikation legt Hyper-V auf dem Zielserver auch einen Snapshot des replizierten virtuellen Servers an. Mit dem Cmdlet „MeasureVMReplication“ erhalten Sie den Status der Replikate auf den einzelnen Hyper- V-Hosts in der PowerShell.

Failover mit Hyper-V-Replica durchführen
Der Sinn von Hyper-V-Replica ist, dass Sie bei Ausfall eines Hyper-V-Hosts ein Failover zu einem anderen Hyper-V-Host durchführen können. Dazu klicken Sie den entsprechenden virtuellen Server im Hyper-V-Manager an und wählen im Kontextmenü „Replikation / Failover“. Für ein geplantes Failover starten Sie das Failover vom Server, auf dem Sie die Quell-VM betreiben. Vorteil dabei ist, dass noch einmal eine Replikation stattfindet, sodass der Zielserver dann über alle aktuellen Daten des Quellservers verfügt.

Anschließend wählen Sie aus, zu welchem Wiederherstellungspunkt Sie den Failover durchführen wollen und starten diesen anschließend. Das funktioniert aber nur, wenn die Quell-VM ausgeschaltet ist. Während des Failovers startet der Assistent den replizierten Server, der im Netzwerk dann exakt mit den Daten der ursprünglichen Quell-VM zur Verfügung steht.

Auch bei einem geplanten Failover müssen Quell-VM und Ziel-VM ausgeschaltet sein. Der Vorteil bei einem geplanten Failover auf dem Quell-Hyper-V-Host ist, dass Hyper-V noch nicht replizierte Daten an den Zielserver senden kann. Dieser verfügt anschließend über den neuesten Stand aller Daten der Quell-VM. Wenn Sie ein geplantes Failover durchgeführt haben, ist die ursprüngliche Quell-VM anschließend die neue Ziel-VM und die bisherige Ziel-VM die neue Quell-VM für die Replikation. Das heißt, Sie können diesen Vorgang auch wieder umkehren. Alle dazu notwendigen Aufgaben steuern Sie über den Hyper-V-Manager oder die PowerShell.

Fazit
Unternehmen, die mehrere Hyper-V-Hosts einsetzen, aber keinen Cluster betreiben wollen, sollten einen Blick auf die Möglichkeiten von Hyper-V-Replica werfen. Denn damit erhalten IT-Verantwortliche hohe Verfügbarkeit quasi zum Nulltarif. Die Einrichtung ist schnell abgeschlossen und der Nutzen kann enorm sein, vor allem wenn ein Hyper-V-Host komplett ausfällt. Gleichzeitig bringen die neuen Features von Windows Server 2012 R2 in diesem Bereich ein neues Maß an Flexibilität für den Administrator.

 
 

Erstellung der Zertifikate:
http://www.c-fi.de/8-blog/8-hyper-v-2012-r2-replikation-mit-hilfe-von-selbst-signierten-zertifikaten-keine-domaene-benoetigt.html

 

Diese Kleine Anleitung schreibe ich für mich, quasi als Dokumentation der notwendigen Schritte…

Ich gehe davon aus, dass die Hyper-V Verwaltungstools bereits Verfügbar sind. Idealer Weise direkt bei einem Windows Server 2012R2, wo die Hyper-V Verwaltungstools installiert wurden bzw. dieser auch gleich als Hyper-V Host dient. Des weiteren wird von 2 Hyper-V Hosts ausgegangen. Diese müssen nicht in der gleichen Arbeitsgruppe sein.

  • Die lokalen Server müssen trotz nichtangehörigkeit einer Domäne einen eindeutigen Domänennamen haben und darüber im Netzwerk erreichbar sein. Der Name muss also erfolgreich auflösen. Das erreicht man, indem man bei den Computereigenschaften, wo man die Arbeitsgruppe oder Domöne einstellen kann, unter den erweiteren Einstellungen den Domänensuffix einträgt. In diesem Beispiel sei dies mal: yourdomain.ending. Zusätzlich sollte man beide Hyper-V Hosts in der HOSTS-Datei in Windows\System32\drivers\etc\hosts eintragen (zwischen IP und Name ein TAB). Dies ist vorallem wichtig, wenn ein Domain-Controller als Virtuelle Maschine läuft. Dann ist beim Start der Hyper-V Hosts kein DNS Server verfügbar und die beiden würden sich nicht finden!
    • 10.0.0.1     hypervhost1.yourdomain.ending
      10.0.0.2     hypervhost2.yourdomain.ending
  • Windows Software Development Kit (SDK) for Windows 8 herunterladen und installieren. Aus dem SDK das Tool “makecert.exe” extrahieren und auf die Hyper-V Hosts kopieren.
  • Auf beiden Hyper-V Hosts die Firewall für die Replizierung öffnen:
    • netsh advfirewall firewall set rule group="Hyper-V-Replikat - HTTPS" new enable=yes
  • Mit Hilfe des makecert – Tools nun die Zertifikate erstellen. Falls mal ein Hyper-V Host ausfällt sollte man gleich zwei CAs erstellen damit man, wenn nötig, neue Zertifikate ausstellen kann.
    • Auf dem ersten Host (hier: hypervhost1.yourdomainname.ending) folgende Befehle in der Powershell ausführen:
    • > makecert -pe -n "CN=HV1RootCA" -ss root -sr LocalMachine -sky signature -r "HV1RootCA.cer"
      > makecert -pe -n "CN=hypervhost1.yourdomainname.ending" -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 "HV1RootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 HV1Cert.cer
    • Auf dem zweiten Host (hier: hypervhost2.yourdomainname.ending) folgende Befehle in der Powershell ausführen:
    • > makecert -pe -n "CN=HV2RootCA" -ss root -sr LocalMachine -sky signature -r "HV2RootCA.cer"
      > makecert -pe -n "CN=hypervhost2.yourdomainname.ending" -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 "HV2RootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 HV2Cert.cer
  • Die “*.CA.cer”-Dateien auf den jeweils anderen Host kopieren. Auf dem ersten Host das Zertifikat importieren:
    • certutil -addstore -f Root "HV2RootCA.cer"
  • Auf dem zweiten Host ebenfalls:
    • certutil -addstore -f Root "HV1RootCA.cer"
  • Auf beiden muss noch die Überprüfung der Sperre eines Zertifikats ausgeschaltet werden, sonst klappt es nicht:
    • reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

Das war es. Nun kann die Replizierung konfiguriert werden. Der Rest sollte durch die Assistenten selbsterklärend sein.

https://developer.microsoft.com/en-us/windows/downloads/windows-8-sdk

sonstiges:
https://www.one-tab.com/page/4W2iTGnERdetIr51d0n0Mw

Suche nach Windows Updates dauert ewig? – Eine mögliche Lösung
windows 2012 r2 hyper v replication – Google-Suche
Windows Server 2012: Replizierung virtueller Maschinen | ZDNet.de
Step-By-Step: Virtual Machine Replication Using Hyper-V Replica – CANITPRO
Hyper-V-Replica einrichten und betreiben (1) | it-administrator.de
zertifikate hyper-v replikation erstellen – Google-Suche
Hyper-V 2012 R2 Replikation mit Hilfe von selbst signierten Zertifikaten (keine Domäne benötigt) – c-fi.de – IT Blog & more
Windows SDK for Windows 8 – Windows app development
 

Written by Armin Senger

September 28th, 2016 at 9:36 am

Posted in IT