VHD-Replication

Zwei Hyper-V-Hosts mit Disks und etwas VHD-Replication und schon ist mein hochverfügbares System fertig. Auf dem Papier könnte das stimmen aber in Realität sollten Sie auch die Grenzen dieser Technik kennen. Darum geht es auf dieser Seite.

Anforderung

Verfügbarkeit ist auch für mittlere und kleine Firmen eine Anforderung und Herausforderung. Domaincontroller, DNS/DHCP-Server und andere Dienste lassen sich durch mehrere unabhängige Server oder VMs relativ einfach "hochverfügbar" bereitstellen. Kniffliger wird das, wenn große Datenmengen (SQL, Exchange) oder zeitkritische Funktionen (z.B. Skype for Business) bereitgestellt werden. Für diese Dienste gibt es auch Lösungen in Form von Failover Cluster, die aber gleich um ein mehrfaches teurer sind.

Die Herausforderung ist ja nicht immer gleich die 24x7 nonstop Verfügbarkeit bei ungeplanten Fehlern oder geplanten Wartungsarbeiten. Viele Firmen könnte mit einem Single Server ja wunderbar arbeiten, wenn es denn da einen Plan-B gäbe, wenn der Server doch mal ausfallen sollte. Dann wäre es nett, wenn man sehr schnell einen möglichst aktuellen Stand online nehmen kann.

Ein Backup jede Nacht ist aus heutigen Überlegungen nicht mehr "aktuell genug". Können Sie auf die Mails des Tages verzichten, wenn der Server im 17:00 Uhr bei einem Windows Update kaputt geht? Selbst wenn die Daten auf den Disks in so einem Fall meist nicht beschädigt sind, dauert das "Wiederherstellen" oft zu lange. Aber auch wenn die Hardware ausfällt, kann eine funktionsfähige Reparatur zu lange dauern. Wenn Sie aber für den Fall schon eine "Ersatzhardware" vor Ort haben, dann wäre es doch schickt diese entsprechend für den Desaster-Fall schon vorbereitet zu haben.

Für mein Beispiel ist es aber nicht erforderlich, dass die Systeme "sofort" oder im Bereich von Sekunden oder maximal ein paar Minuten mit den aktuellsten Daten wieder online sind. Das ist dann wieder der klassische "Ansatz einer "Hochverfügbarkeit". Dazu brauchen Sie nicht nur passende Software, Hardware und Konfiguration sondern vor allem auch ein "Automatismus", der zuverlässig einen Ausfall erkennt und die richtigen Schritte zur Wiederherstellung übernimmt. Ein Mensch ist hier dann immer zu langsam. Aber das ist nicht das Ziel der Lösung.

Failover Cluster oder VHD-Replikation

Exchange hat es mit der Database Availability Group (DAG) vorgemacht, wie zwei oder mehr Server Daten miteinander replizieren ohne dass man einen gemeinsamen Speicher benötigt. Denn alles, was sich mehrere Server teilen, ist eine gemeinsame Komponente, die bei einem Problem mehrere Server betreffen kann. Das ist der klassische Failover Cluster, bei denen die Daten quasi in der "Mitte liegen" und immer nur ein Server von mehreren Servern mit den Teildaten arbeitet. Fällt der Server aus oder wird geplant gepatched, dann kann in der Zwischenzeit ein anderer Server die Arbeit übernehmen und die Anwender bedienen.

Das ist der klassische Failover-Cluster, der aber allein durch den gemeinsamen Storage anspruchsvoller in der Planung und Umsetzung ist. Das gilt um so mehr, wenn der Abstand dazwischen größer wird und weitere "Zeugendienste" dazu kommen. Dann müssen Sie auch noch die Netzwerkanbindung u.a. redundant auslegen. Damit sind wir dann gleich wieder beim Thema Kosten.

Die Exchange DAG macht es vor, wie Daten auf mehreren Server redundant und verfügbar vorgehalten werden. Auch für SQL gibt es seit 2008 die "Mirroring-Funktion". Sie wissen aber auch, dass dies natürlich eine Funktion der Software ist und auch der Client damit arbeiten muss.

Es gibt aber viel mehr Services, deren Entwickler sich nicht viel Gedanken zum Thema Verfügbarkeit oder Desaster-Schutz gemacht haben. Schon lange Zeit war es daher eine Option, solche Dienste "virtuell" zu betreiben. Als Gast auf einem Host können leistungsstarke Server besser ausgenutzt werden, wenn Dienste nur einen Bruchteil der Leitung brauchen. Zudem konnte auch ein Hyper-V-Cluster die Gäste zwischen verschiedenen Hosts über unterschiedliche Wege verlagern. Der Gast konnte per "Live Migration" quasi ohne gefühlte Unterbrechung verlagert werden. Wenn Gäste dies nicht unterstützen, z.B. Skype for Business oder Exchange, dann kann der Server immer noch schnell heruntergefahren und auf dem nächsten System hochgefahren werden. Denkbar ist auch ein ""anhalten" (Save State) und Resume nach dem Schwenk. Bei allen Optionen war lange Zeit aber der "Shared Storage das Problem

So funktioniert VHD-Replikation

Seit Windows 2012 können mit Hyper-V Server die VHD-Dateien, d.h. die virtuellen Disks, die der Gast als seine Festplatte sieht, auf andere Server repliziert werden. Damit ist klar, dass es sich um VHD-Dateien handeln muss. Echte Disks, die z.B. per "Passthrough" durchgereicht werden gehen nicht. Wo die VHD-Dateien letztlich liegen, ist dann aber wieder egal. Wobei es natürlich nur mit lokalem Storage richtig sinnvoll erscheint.

Wenn die VHD-Datei auf einem SAN, Shared Storage oder per iSCSI auf einem NAS liegt, dann gibt es vermutlich andere effektivere Techniken eine VHD-Datei zu duplizieren. Aber wenn Sie all das nicht haben, sondern einfach nur zwei Hyper-V-Hosts mit lokalem, Storage, dann ist VHD-Replikation vielleicht ein Teil ihrer Verfügbarkeitsstrategie.

  • Aktiver Gast auf Host1
    Technisch gibt es einen Master, auf dem der Gast auch aktiv ist und die VHD-Datei natürlich permanent verändert.
  • Instanz auf Hyper-V Host 2
    Durch die eingerichtete Replikation wird die VHD-Datei auf einen anderen Server über das dazwischen liegende LAN (oder WAN) repliziert. Ziel kann auch Azure sein. Die beiden Hyper-V Server müssen nicht im gleichen Forest sein.
  • Die Replikation erfolgt asynchron
    Dabei werden lokale Änderungen quasi gesammelt und dann zum Zielsystem per HTTP gesendet. Es ist also kein "synchroner" Transfer und entspricht keinen RAID. Die Kopplung ist "locker" und wenn das Zielsystem nicht verfügbar ist dann puffert die Quelle die Änderungen in einer Datei. Sehen Sie also entsprechend Disk-Space vor. Sie können erst mal nicht sicher sein, dass das Zielsystem "konsistent" ist.
    Die kürzeste Zeit ist 5 Minuten (2012) bzw. 30 Sekunden (ab 2012R2). Maximale geplante Verzögerung ist 15 Minuten.
  • VSS Snapshots
    Für einen konsistenten Status im Ziel muss auf der Quelle ein VSS-Snapshot gemacht werden. Wenn der dann im Ziel angekommen ist, kann ein Administrator diesen Snapshot im Ziel aktivieren. Es können mehrere Snapshots vorgehalten werden und die Zeitspanne kann zwischen 1-12 Stunden liegen. Das bedeutet aber bei einem ungeplanten Aktivieren im Ziel einen Verlust bis zu diesem Zeitraum

Wenn Sie sich das System also genau anschauen, dann hat es schon den Charakter eines "Backup2Disk" auf einen anderen Server. Nur dass hier das Backup auf dem anderen Server im Falle eines Falles direkt als VM wieder hochgefahren werden kann. Hier noch ein paar Zitate zur Untermauerung

Recovery points: When you configure replication settings for a virtual machine, you specify the recovery points you want to store from it. Recovery points represent a snapshot in time from which you can recover a virtual machine
Set up Hyper-V Replica https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/set-up-hyper-v-replica

Decide how often you need to synchronize data: The data on the Replica server is synchronized updated according to the replication frequency you configure (30 seconds, 5 minutes, or 15 minutes)
Set up Hyper-V Replica https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/set-up-hyper-v-replica

Failover-Szenarien

Dabei sind drei Fälle zu unterscheiden:

  • Geplanter Failover
    Dabei wird der aktive Server erst herunter gefahren, dann die letzten Änderungen übertragen und der Server im Ziel gestartet. Der Wechsel erfolgt also ohne Datenverlust aber natürlich mit einer, wenn auch kurzen, Downtime. Es ist aber durchaus ein Weg um VMs von einem Hyper-V Host auf einen neuen Host zu verlagern oder den Host selbst umzubauen, patchen etc. und wieder zurück zu belasten.
    Da es sich aber immer nur um genau den einen Server handelt, ist der Service kurze Zeit weg. VHD-Replikation ist also keine Hochverfügbarkeit.
  • Ungeplanter Failover
    Es kann ja aber passieren, dass die Umgebung mit dem aktiven Host ausgefallen ist. Sei es Stromausfall, RZ-Ausfall oder sonstiges Hardware, Software oder Bedienungsfehler. Dann haben Sie mit dem VHD-Replikat einen funktionsfähigen Server, der problemlos auf einem anderen Hyper-V-Host gestartet werden kann. Da sie aber nun nicht sicher sein können, dass die unterbrochene Replikation im Ziel einen konsistenten Stand hinterlassen hat, sollten Sie zuerst prüfen, ob die Quelle wirklich so weg ist, dass Sie das Ziel aktivieren wollen. Bei der Aktivierung im Ziel gehen Sie am besten auf den letzten Snapshot zurück, der zwischen 1-12 Stunden (je nach Einstellung) als sein kann. Selbst mit 1h Intervallen gehen also im Mittel 30 Min Daten verloren, damit der Server nach einigen Minuten wieder online ist. Aber ohne diese Option ist der Server offline, bis die Quelle repariert ist. Auch das kann Stunden oder Tage dauern.
    Die Abwägung kann aber keine Software vornehmen. Daher sind sie hier als Mensch und Entscheider gefragt.
  • Test-Aktivierung
    Jeder Notfallplan sollte auch getestet werden. Tatsächlich kann ein VHD-Replikat auch "Testweise" aktiviert werden. So startet auf dem anderen System der gleiche Server mit dem Stand nochmal, der vor Kurzem noch der aktive Server war. Da der aktive Server natürlich weiter seine Arbeit verrichtet, das das Testsystem nicht im produktiven Netzwerk erscheinen. Für einen echten Test sollten Sie diesen Server dann zusammen mit Abhängigkeiten (z.B. DC mit DNS) in einem eigenen VLAN starten.

Der Einsatz von Hyper-V und Replikation ist also nicht für alle Dienste sinnvoll einsetzbar. Insbesondere der "Rollback" beim ungeplanten Failover muss je nach Applikation genau überprüft werden. Insbesondere Datenbanken sind hier kritisch zu betrachten. Damit meine ich nicht nur die bekannten Datenbanken von Exchange und SQL. Datenbanken gibt es auch beim Active Directory, DHCP, DNS, WINS, WSUS und vielen anderen Diensten.

Hüten Sie sich davor bei einem ungeplanten Failover den aktuellen inkonsistenten Stand zu nutzen. Auch wenn der Server vielleicht startet und einen CHKDSK macht, so garantiert Hyper-V Replikation anscheinend nicht, dass die Blöcke in der gleichen Reihenfolge geschrieben werden. Das ganze System ist also nicht transaktionsorientiert. Bei einem ungeplanten Failover ist auf jeden Fall ein Snapshot zu nutzen, auch wenn dabei vielleicht einige Daten nicht mehr vorhanden sind. Es gibt aber durchaus Dienste, die damit dennoch sinnvoll betrieben werden können. Ein Domain Controller sollte dies erkennen und die fehlenden Änderungen replizieren. Auch ein Skype for Business Standard Server verliert dann nur die Änderungen in den Buddy-Listen und natürlich Meetings, die in der fraglichen Zeit angelegt wurden. In kleinen Umgebungen ist damit der Service aber immer noch besser verfügbar als ein Single Server ohne Absicherung, wenn die Kosten für einen HA-Pool sich nicht rechnen.

Bei Exchange hingegen sieht das Thema schon etwas kniffliger aus, da Outlook die Änderungen der lokalen OST-Datei nicht erneut zum Server überträgt. Hier ist eine keine DAG wohl doch der bessere Weg, wenn eine Datenreplikation gefordert wird und ein Single-Server nicht reicht. Wobei sie immer überlegen sollten, welche Dienste vielleicht besser in Office 365 abgebildet werden.

Tipp: Wenn Sie die Replikation auch nutzen möchte, um z.B. ein fehlgeschlagenes Windows Update oder Server Update rückgängig zu machen, dann Daten und OS trennen. hilft bei Windows Updates.

Hyper-V-Cluster und VHD-Replikation

Sie können eine VHD-Replikation zwischen zwei beliebigen Hyper-V Servern einrichten. Die Server müssen sich nur untereinander authentifizieren können. Im internen LAN ist Kerberos dazu das Mittel der Wahl. Aber sie können auch eine Replikation zu anderen Servern, insbesondere Azure, herstellen. In all den Fällen sind die Hyper-V Server nicht in einem Failover-Cluster zusammen gefasst.

Wie können aber natürlich auch mehrere Hyper-V Server als Windows Cluster zusammen schalten. Ein Windows Cluster muss heute nicht mehr eine "Shared Disk" haben, die sich alle Server gemeinsam teilen. Sie kennen die Konfiguration vielleicht schon der Exchange Database Availability Group, bei der bis zu 16 Server in einem Verbund verschaltet sind und Datenbanken auf mehreren Servern vorgehalten werden. Die Funktion "Failover Cluster" wird primär zur Überwachung und Failover von Datenbanken auf diesen Servern genutzt ohne dass dazu aber "Clustergruppen" oder Ressourcen angelegt werden. Das mach Exchange hier alles alleine.

Ein klassischer Hyper-V Cluster besteht fast immer aus zwei oder mehr Hosts, die aber alle auf einen gemeinsamen Massenspeicher zugreifen können. Dieser zentrale hochverfügbare Store ist natürlich dennoch eine gemeinsame Komponente, die beim Fehlerfall den Cluster mächtig stören kann. Oft ist es ja nicht mal die Technik sondern der Mensch der im Fehlerfall an der falschen Stelle "repariert" und damit letztlich den Ausfall begründet. Der gemeinsame Storage hat natürlich den Vorteil, dass z.B. eine LiveMigration einer VM von einem zum anderen Host ohne Betriebsunterbrechung möglich ist. Selbst ein einem ungeplanten Ausfall eines Hosts kann die VM dann einfach auf einem anderen Host gestartet werden. die Daten sind ja auf der Festplatte bis zum Moment des Ausfalls vorhanden und wenn CHKDSK und die Transaktionsprotokolle keinen Mist machen, kommt der Server nach wenigen Minuten wird online.

Aber auch mit VHD-Replikation können Sie einen Failover Cluster für Hyper-V Server aufbauen. Die Verwaltung verlagert sich dann von dem Hyper-V MMC in die Cluster-MMC, in der sie die VMs als Cluster Ressource betreiben. Sie haben so einen sehr guten Überblick über die VMs auf diesem Failover-Cluster mit den Servern im Cluster.

Gäste und Hyper-V

Natürlich müssen sie auch mit VHD Replication immer noch einen Blick auf die Gäste werfen, die sie hier dann virtuell betreiben wolllen. Nicht alle Produkte sind für Hyper-V freigegeben. Das bedeutet ja niciht, dass Sie nicht doch laufen aber der Support sit dann ungewiss. Manchmal sind es auch nur bestimmte Betriebsarten. Exchange und Skype for Business mögen z.B. "Live Migration" überhaupt nicht. Die gibt es mit VHD-Replication aber auch nicht. Beide sind aber auch beim "ungeplanten Failover" gesondert zu berücksichtigen.

Generell zu hinterfragen sind Systeme mit Datenbanken. Neben SQL und Exchange betrifft dies generell auch alle Dienste mit der ESE-Engine wie DHCP, WINS, Domain Controller, Zertifizierungsstellen etc, die bei einem ungeplanten Failover auf einen früheren Zeitpunkt zurückgesetzt werden müssen. Diverse Funktionen sind z.B: mit Exchange und Skype for Business nicht möglich, z.B.

  • Dynamic Memory
  • Dynamic Disks
  • Andere Dynamische Ressourcen
  • VMotion oder LiveMigration
    Eine VM kann geschwenkt werden aber immer über „Down/Restart“
  • Mischung von Physik und Virtuell im gleichen Skype Pool
    Virtuelle Frontend Server und physische SQLs sind aber erlaubt

Auch bezüglich des Sizings und anderer Randparameter gilt es die Vorgaben der Hersteller zu beachten.

Weitere Links