FAQ zu Hyper-V Replica: Exchange, SQL Server, Domain Controller, Wiederherstellungspunkte

    Hyper-V Replica für SQL-Server und Domain ControllerDie Replikation von virtuellen Maschinen für das Disaster Recovery ist ein wichtiges neues Feature von Windows Server 2012, das im Release 2 erweitert wurde. Doch Replica ist nicht für alle Anwendungen geeignet und wird in diesen Fällen von Microsoft auch nicht unterstützt. Folgende FAQ behandelt einige problematische Aspekte dieses Features.

    Die Annahme liegt nahe, dass all jene Anwendungen, die selbst über Replikations- oder Synchronisierungsfunktionen verfügen, keine geeigneten Kandidaten für Hyper-V Replica sind. Das träfe etwa auf Exchange, SQL Server oder Domänen Controller zu. In dieser allgemeinen Form stimmt das aber nicht, weil bestimmte Konfigurationen trotzdem unterstützt werden, andere aber wiederum nicht.

    Dürfen Domänen Controller repliziert werden?

    Ja. Diese Frage ist heikel, weil das Active Directory natürlich das Rückgrat der Infrastruktur darstellt. Virtuelle Domänen Controller ab Windows Server 2012 dürfen theoretisch asynchron durch Hyper-V Replica übertragen und im Disaster-Failover mit einem Zeitversatz angeschaltet werden.

    Durch die VM-GenerationID (VMGenID) soll bei einem ungeplanten Failover ein USN Rollback verhindert werden, wenn Hyper-V 3.0 von der entsprechenden Situation Kenntnis hat und die ID ändern kann. Bei einem Zeitversatz von max. 15 Minuten bzw. verschiedenen Wiederherstellungspunkten, die bereitgehalten werden, um auf einen früheren Zeitpunkt zurückspringen zu können, sollte man weiterhin Vorsicht walten lassen.

    Bei einem geplanten Failover verhält sich das Ganze anders, da hier vor dem eigentlichen Failover alle Deltas übertragen werden und die Maschine auf dem Replikatserver vollständig konsistent ist.

    Ist Exchange für die Hyper-V-Replikation freigegeben?

    Nein. Exchange zu virtualisieren wird offiziell ab Version 2007 SP2 unterstützt, und die Versionen 2010 sowie 2013 wurden dafür weiter angepasst. Exchange bringt sein eigenes DR mit, die Database Availability Group (DAG, übersetzt Datenbank­verfügbarkeits­gruppen). Checkpoints (Snapshots) von Exchange-Gästen unterstützt Microsoft generell nicht, und das bedeutet auch das k.o. für Hyper-V Replica mit seinen verschiedenen Wiederherstellungspunkten.

    Bei einer komplexen Applikation wie Exchange mit gegebenenfalls verteilten Rollen auf unterschiedlichen Servern wäre der Aufwand bei einem asynchronen Failover schwer bis gar nicht abzuschätzen. Es bleibt aber abzuwarten, ob der Support für Exchange 2016 in Bezug auf Hyper-V Replica Änderungen bringt.

    Kann man virtuelle SQL Server replizieren?

    Man kann und darf, aber nur unter bestimmten Voraussetzungen. Virtuelle SQL Server erhalten ab der Version 2005 allgemein technische Unterstützung durch Microsoft. Hyper-V Replica mit SQL Server wird nur unterstützt, wenn das Replikations-Flag EnableWriteOrderPreservationAcrossDisks der SQL VM vorher auf aktiv gesetzt wurde. Über PowerShell wird das mit dem Cmdlet Set-VMReplication erledigt:

    Set-VMReplication –VMName <VM-NAME> -EnableWriteOrderPreservationAccrossDisks 1

    Durch dieses aktivierte Flag wird gewährleistet, dass alle für die Replikation ausgewählten VHD(X) Laufwerke zum richtigen Zeitpunkt übertragen werden. Wichtig wird dies, wenn z.B. die Logfiles getrennt von der Applikation auf einem dedizierten VHD(X) Laufwerk liegen.

    Folgende Features von SQL Server werden in Hyper-V Replica nicht unterstützt:

    • Datenbankspiegelung
    • Failover-Cluster
    • Replikation
    • Log Shipping
    • Availability Groups

    Wie schütze ich mich gegen beschädigte primäre VMs?

    Wie bereits in einem anderen Beitrag erwähnt, können Sie dafür zusätzliche Wiederherstellungs­punkte und anwendungskonsistente Checkpoints einer virtuellen Maschine anlegen.

    Neben standardmäßigen Wiederherstellungspunkten kann man zusätzlich applikationskonsistente Schattenkopien erstellen.

    Wird die primäre VM inkonsistent, z.B. durch einen Virenbefall, überträgt der primäre Server diese 30 Sekunden (bzw. 5 Min. oder 15 Min.) später an den Replikatserver mit dem Resultat, dass Sie von nun an zwei befallene virtuelle Systeme haben (produktive VM und Replikat). Halten Sie jedoch einen Wiederherstellungspunkt aus der Vergangenheit bereit, dann besteht die Möglichkeit eines Rollback bis zu diesem evtl. konsistenten Zustand.

    Was passiert im Detail, wenn zusätzlich Wiederher­stellungs­punkte erstellt werden?

    Vorab: Der Erstsendung der VHD(X)-Laufwerke geht eine Momentaufnahme der VM auf dem primären Server voraus, um im laufenden Betrieb eine konsistente Schattenkopie der VM für die erstmalige Replikation zu erstellen. Ist die Erstübertragung abgeschlossen, wird mithilfe der HRL Dateien (Hyper-V Replica Logfile) in regelmäßigen Intervallen das Delta zum Replikatserver gesendet.

    Was passiert bei Ausfall der Netzverbindung?

    Fällt die LAN- oder WAN-Verbindung für eine Zeit aus, versucht Replica immer wieder die Deltas zu übertragen. Funktioniert das in einer festgelegten Zeitspanne nicht, gelangt die Replikation in einen kritischen Zustand.

    HRL- und HRU-Dateien liegen bei Server 2012 R2 im Verzeichnis des replizierten VHD(X) Laufwerkes.

    Jeder Wiederherstellungspunkt wird im Hyper-V Replica Dateisystem in einer HRU Datei (Hyper-V Replica Undo file) festgehalten, dieses Verfahren ist neu in Windows Server 2012 R2 und löst das Snapshot-Verfahren von Windows Server 2012 ab. Löschen Sie HRU-Dateien niemals manuell im Dateisystem, sondern passen Sie die Konfiguration der nötigen Wiederherstellungspunkte an.

    Wozu dienen anwendungskonsistente Wiederherstellungspunkte?

    Zusätzlich zu Standard- können anwendungs­konsistente Wieder­herstellungs­punkte erstellt werden. Hier wird in der VM selbst eine Schattenkopie der laufenden Anwendung (z.B. SQL Server) erstellt, um einen konsistenten Punkt zu erreichen. Man kann mindestens auf einen eine Stunde alten konsistenten Anwendungs-Snapshot zurückgreifen.

    Test-Failover wahlweise mit Standardwiederherstellungspunkt oder anwendungskonsistentem Wiederherstellungspunkt.

    Im Falle eines virtuellen SQL Servers, der zuerst Daten in den flüchtigen Speicher und erst danach in die Transaktionsprotokolle schreibt, wird so die Anwendung durch Leeren des RAM und Übertragen der Operationen in die Transaktionsprotokolle in eine konsistente Lage versetzt. Der "harte" Absturz der VM wird so abgefedert. Wichtig für konsistente Snapshots ist, dass die Integrationsdienste im Gast aktuell sind.

    Bedenken Sie auch, dass häufig zu erstellende Wiederher­stellungs­punkte bei einer großen Anzahl an virtuellen Maschinen sich auf die Host- und VM-Performance auswirken und natürlich Speicherplatz verbrauchen.

    Keine Kommentare