Disaster Recovery, vor allem in virtuellen Umgebungen ist in aller Munde. Mit dem entsprechenden Budget in der Hinterhand, kann man diese Herausforderung auf das SAS Thema auslagern. In kleineren und mittelgroßen Umgebungen hält Microsoft Hyper-V 3 vom Windows Server 2012 eine hübsche Lösung bereit. Die Hyper-V Replikation.
Hyper-V Replikation bietet die Möglichkeit eine virtuelle Maschine eines Hyper-V 3 Hosts als „lose gekoppelte“ Kopie auf einen weiteren Hyper-V 3 Host zu replizieren. Lose gekoppelt soll hier bedeuten, dass die Maschinen sich nicht im Sync befinden. Die Latenz liegt hier bei 5 Minuten, bei Verbindungsproblemen kann sie selbstverständlich höher sein.
Die replizierte VM kann jederzeit manuell (!) nach einem Ausfall der originalen virtuellen Maschine gestartet werden. Die replizierte, dann im Disaster-Fall verwendete VM ist nur minimal älter als die zuvor ausgefallene Maschine. Ich halte das für einen echten Gewinn für kleinere und mittelgroße Unternehmen.
Wie wird die Replikation konfiguriert und worauf sollte man achten?
Zu allererst: Die Replikation wird zur Zeit über den Hyper-V Manager konfiguriert, bei Failover-Clustern im Cluster-Manager oder selbstverständlich über die PowerShell. Leider noch nicht über den System Center Virtual Machine Manager 2012 SP1 Beta, vielleicht tut sich bis zum Release ja noch was.
Um eine Maschine replizieren zu können, müssen zunächst entsprechende Einstellungen in den Hyper-V Einstellungen des Hosts vorgenommen werden. In den Einstellungen des empfangenden Hosts wird die Replikationskonfiguration vorgenommen. Die Einstellungen sind eher selbsterklärend. In meiner Testumgebung habe ich mich für die deutlich schnellere Variante entschieden und das HTTP Protokoll gewählt. Je nach Anforderungen des Kunden sollte man den Mehraufwand eines SSL Zertifikates nicht scheuen.
Wichtig ist, dass für das gewählte Übertragungsprotokoll auch der entsprechende Port in der Windows Firewall geöffnet wird – natürlich nur, falls diese verwendet wird. Irreführend ist die Warnmeldung. Diese meldet bei Verwendung des Ports 80, dass man den „Hyper-V-Replikat – HTTPS-Listener“ zulassen soll. Nach kurzem Nachdenken wird klar, dass das nur falsch sein kann.
Das zugelassene Feature sollte dann entsprechend „Hyper-V-Replikat – HTTP“ und NICHT HTTPS sein:
Anschließend kann man mit einem Rechts-Klick auf die gewünschte Maschine über das Kontextmenü die Replikation aktivieren.
Mögliche Replikations-Wege sind hier: Stand-Alone-Host zu Stand-Alone-Host, Cluster zu Stand-Alone-Host und Stand-Alone-Host zum Cluster.
Die Konfigurationsschritte sind weitgehend selbsterklärend, sodass ich die Inhalte der Screenshots nicht durch eigene Worte wiederholen werde:
Nach erfolgreicher Konfiguration und sauberen Firewall-Einstellungen läuft dann die Aktivierung der Replikation und anschließend die Erstreplikation.
Die Erstreplikation kann, wie den Screenshots zu entnehmen ist, alternativ zur Netzwerkübertragung auch in Form von Wechseldatenträgern oder in Form einer schon auf dem Zielsystem vorhandenen virtuellen Maschine stattfinden. Letztere Option kann man z.B. dann verwenden, wenn man die zu replizierende Maschine auf dem Ziel-System wiederhergestellt hat.
Die Ersteplikation sieht auf dem Quell-Host so aus:
Und auf dem Ziel-Host sieht die Hyper-V Replikation folgendermaßen aus:
Ist der Zielhost für einen längeren Zeitraum (> 5 Minuten) nicht erreichbar, wechselt der Replikationsstatus auf „Kritisch“:
Auch wenn der Ziel-Host über Stunden nicht erreichbar ist, wird in einem 30-minütigen Intervall versucht, das Ziel zu kontaktieren um die Replikation wieder aufzunehmen.
Das primäre Szenario, für welches Microsoft diese Funktion gestaltet hat, ist sicherlich die Replikation einer laufenden VM zu einem entfernten Standort. Ja nach Funktion der zu replizierenden VM, fällt bei einer Typischen Maschine wie z.B. bei meinem WSUS, innerhalb des 5-Minuten Replikationsintervalls ein Replikationsvolumen im unteren KB-Bereich an. Das Replikationsintervall von 5 Minuten ist zur Zeit nicht konfigurierbar.
Zu Wartungszwecken kann aus dem Hyper-V Manager heraus auch ein geplantes Failover durchgeführt werden.
Die Volle Replikationsfunktionalität funktioniert natürlich auch mit dem freien Hyper-V Server 2012, der im übrigen ja auch Failover-Cluster tauglich ist.
Hyper-V Replikation ist kein Ersatz fürs Clustering oder die Live-Migration. Es ist eine Lösung für Disaster-Recovery Situationen. Die Latenz der VM zu ihrem Replikat beträgt in der Regel etwas mehr als 5 Minuten und das Replikat muss im Disaster-Fall manuell in Betrieb genommen werden.
Ich persönlich sehe die Hyper-V Replikation als sinnvolle Disaster-Recovery-Lösung bei vielen kleineren und mittelgroßen Kunden.
Das Thema Hyper-V Replikation wird im MOC Kurs „MOC 20412 Configuring Advanced Windows Server 2012 Services“ im Modul 6 „Implementing Failover Clustering with Hyper-V“ im Thema „6.3 – Implementing Hyper-V Virtual Machine Movement“ behandelt.
Schreibe einen Kommentar