Private Cloud und Hyper-V Replika-Teil 1

Mit Windows Server 2012 und Hyper-V kommt ein sehr wichtiges Feature für hoch-verfügbare virtuelle Systeme mit: Hyper-V Replika. Damit kann eine virtuelle Maschine (VM) im laufenden Betrieb von Host A zu Host B transportiert werden. Damit steht ein (asynchrones) Backup einer VM an einem zweiten Server bereit um im Falle eines Ausfalls den Betrieb fortzusetzen.

Es gibt viele Szenarien, wo ein ausfallsicheres System Sinn macht. Je nach Hardware und Aufwand kann dies auch in einer Private Cloud vollautomatisiert oder manuell erfolgen. Das coole dabei ist, dass der Partner-Host sowohl im eigenen LAN als auch entfernt, etwa irgendwo im Internet - im WAN – stehen kann.

Für einen Überblick über Hyper-V Replikation empfehle ich eine Lektüre in TechNet in Hyper-V Replica Feature Overview und Hyper-V Replica Overview .

Replikation

Hyper-V Replikation kommt in vielerlei Geschmacksrichtungen. In vielen Fällen wird die Replikation innerhalb eines Netzwerkes (LAN) erfolgen. Hier steht dann im Regelfall ein Domaincontroller zur Verfügung, der sich um Authentifizierung kümmert. Hyper-V Cluster können den IT-Betrieb von virtuellen Maschinen vollständig automatisieren und sicherstellen.

Ein Szenario: Replikation ohne Domain

Neben dieser Umgebung im eigenen Unternehmen habe ich jedoch ein Szenario, wo Hyper-V Hosts außerhalb meines LANs – und ohne Domaincontroller – mit Hyper-V Replikation laufen sollen, etwa bei einem Internet-Provider. In meinem Fall sollen VMs ge-backupt werden. Bei Ausfall ist es ausreichend, ein manuelles Failover durchzuführen.

Die Besonderheit dabei: Die Replikation erfolgt ohne Domaincontroller über WAN.

Bei Bedarf wird eine VM auf dem Partner-Host aktiviert – man spricht hierbei von Failover.

Wenn etwa VM1 auf Host A nicht mehr funktioniert, wird die Replik (die Kopie) auf Host B in Betrieb genommen. Wenn Host A wieder funktioniert, kann die VM wieder zurückverschoben werden und wieder auf dem Original-Host A weiterlaufen.

Hierzu empfiehlt es sich, etwa gleich starke Hosts zu verwenden, welche die Kapazität haben, alle VMs zu übernehmen. Natürlich kann das Szenario auch auf mehrere Partner-Hosts ausgeweitet werden, etwa mit 3 oder 4 Hosts, wo VMs aufgeteilt werden. Die Host-Hardware muss nicht gleich sein, das empfinde ich als großen Vorteil. Als Software kommt auf beiden Seiten Windows Server 2012 R2 zum Einsatz.

Die Verbindung machts

Der erste Schritt besteht darin, die Hyper-V Replikation zu aktivieren. Das erfolgt in den Hyper-V Settings.

…und in Replication Configuration. Hier stehen zwei Transport-Mechanismen zur Verfügung:

• Kerberos über HTTP funktioniert nur in einer Active Directory (AD) Umgebungen – und kann somit nur mit einem vorhandenen Domaincontroller verwendet werden, wenn alle Hosts Mitglied derselben Domain (oder des Forests) sind.
• Zertifikat-basierende Authentication über HTTPS kann auch im WAN – ohne AD - verwendet werden. Die Zertifikate müssen auf allen Hosts bekannt (importiert) sein.

Für mein Szenario muss also Zertifikat-basierende Authentication zum Einsatz kommen. Die zu erreichende Konfiguration sieht so aus:

Zertifikate verwenden

Ohne AD benötigen wir also Zertifikate auf den Hyper-V Servern. Hierbei gibt es wieder zwei Möglichkeiten: Man kauft offizielle Zertifikate, oder man erstellt sie einfach selbst. Ich habe mich für Weg zwei entschieden: Selbst erstellte Zertifikate. Wir gehen dabei von zwei Hyper-V Hosts aus.

Selbst-signierte Zertifikate erstellen

Der Vorgang ist nicht schwer – wenn man weiß wie. Ich habe nach etwas Recherche eine gute Anleitung von Bonn Tee im australischen blog.powerbiz.net.au gefunden: How to create Self-Signed Certificates for Hyper-V Replication. Hier sind die wesentlichen Schritte dokumentiert.

Dazu benötigt man zunächst auf beiden Servern das Tool MakeCert.exe. Informationen über MakeCert.exe sind in im MSDN unter Makecert.exe (Certificate Creation Tool) und in Working with Certificates zu finden. Entwickler habens gut, das Tool kommt automatisch mit Visual Studio mit (etwa in C:\Program Files (x86)\Windows Kits\8.1\bin\x64). Alternativ kann es von hier MSDN: MakeCert bzw. direkt von hier downgeloadet werden.

Nun muss auf jedem Server ein mit MakeCert ein Zertifikat erstellt werden. Für Host A lautet dies mycompanyFirstReplica und für Host B mycompanySecondReplica.

Achtung: Der CommonName (CN) des Zertifikates muss dabei exakt wie der FQDN (Full Qualified Domain Name) in System lauten!

Nun wird – auf beiden Hosts – ein Command Prompt als Administrator geöffnet und diese Schritte ausgeführt (Host beachten und die Parameter auf die eigene Firma und CN´s anpassen):

1. Auf Host A:
   makecert -pe -n "CN=mycompanyFirstReplica" -ss root -sr LocalMachine -sky signature -r "mycompanyFirstReplica.cer"
2. makecert -pe -n "CN=HOST4.atwork.at" -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 "mycompanyFirstReplica" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 FirstServer.cer
3. Auf Host B:
   makecert -pe -n "CN=mycompanySecondReplica" -ss root -sr LocalMachine -sky signature -r "mycompanySecondReplica.cer"
4. makecert -pe -n "CN=HOST5.atwork.at" -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 "mycompanySecondReplica" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 SecondServer.cer
5. Auf Host A:
   Kopieren Sie mycompanySecondReplica.cer von Host B
6. certutil -addstore -f Root "mycompanySecondReplica.cer"
7. reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
8. Auf Host B:
   Kopieren Sie mycompanyFirstReplica.cer von Host A
9. certutil -addstore -f Root "mycompanyFirstReplica.cer"
10. reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

Wenn mehr als zwei Hyper-V Hosts beteiligt werden sollen, sind die Schritte oben für alle Partner anzupassen bzw. auszuführen, etwa mycompanyThirdReplica usw. Alle Partner müssen die Zertifikate der anderen beteiligten Server besitzen und ihnen vertrauen.

Zertifikat Kontrolle mit MMC

Wenn die Zertifikate erstellt und in den Computer-Zertifikatsstore importiert wurden, sollten wir kontrollieren, ob auch alles geklappt hat:

MMC.exe starten und mit File/Add/Remove Snap-in (oder CTRL-M) das Snap-In Certificates hinzufügen und Computer account und Local Computer auswählen. In Certificates (LocalComputer) / Personal / Certificates muss nun das eigene Zertifikat aufscheinen, wie hier:

Zweitens muss in den Trusted Root Certification / Certificates das hinzugefügte Zertifikat des Partner-Hosts vorhanden sein, wie hier:

Wir sehen in denTrusted Root Certification sind die Zertifikate beider Hosts vorhanden. Und wir vertrauen diesen Zertifikaten. Dasselbe Szenario auch auf dem Partner-Host kontrollieren. Das wars dann mit den Zertifikaten.

Firewall

Nicht zu vergessen, ist dass der Hyper-V Replikationsdienst durch die Windows Firewall kommen muss.

Dazu die Windows Firewall with Advanced Security öffnen und in den Inbound Rules den Dienst für Hyper-V Replica HTTPS aktivieren (Enable Rule). Die Firewall soll wie im Screenshot konfiguriert sein und den HTTPS Listener aktiviert haben.

Nicht vergessen, die Firewall-Einstellungen auf ALLEN Hosts zu setzen…!

Das waren die Voraussetzungen für Hyper-V Replika

Wenn diese Voraussetzungen erfüllt sind, gehts los mit dem Einrichten der Hyper-V Replika für einzelne VMs. Das zeigen wir in Teil 2!