Bei der Virtualisierung von Server-Systemen durch VMware vSphere, Citrix XenServer oder Microsoft Hyper-V werden mehrere physische Server in virtuelle Instanzen eines einzigen Gerätes beziehungsweise Hosts gepackt. Dies führt zu den bekannten Vorteilen wie einer besseren Auslastung der Systeme und weniger Hardwarebedarf durch die Konsolidierung der Server.
Bei einer Konsolidierungsrate von 10:1 werden beispielsweise zehn Server-Systeme auf eines reduziert. Allerdings erhöht sich gleichzeitig auch das Risiko bei einem möglichen Hardwareausfall. Da nunmehr ein einziges physisches Gerät zehn logische Server – die virtuellen Maschinen – verwaltet, multipliziert sich das Risiko beim Hardware-Crash mit der Anzahl der virtuellen Maschinen. Denn Ausfälle des physischen Hosts oder dessen einzelner Bauteile betreffen nunmehr alle virtuellen Gastsysteme. Dies lässt sich durch eine zuverlässiger Hardware oder eine Duplizierung von systemkritischen Bauteilen wie Netzteile, Speicher oder Netzwerkschnittstellen teilweise auffangen. So kann der Anwender zum Beispiel mehr Netzwerkkarten bereitstellen und diese dann dediziert den virtuellen Maschinen zuweisen. Allerdings widerspricht diese Vorgehensweise dem Prinzip der Konsolidierung und Virtualisierung, denn genau genommen stellt man dabei aus Gründen der Fehlertoleranz die doppelte Hardware bereit.
Ein anderer Weg zur Ausfallsicherung ist die Bildung von Cluster. Hierbei teilen sich mehrere Server die gleiche Aufgabe. Bei Clustern wird in der Regel die gesamte Hardware mehrfach bereitgestellt. Cluster werden entweder im Aktiv/Aktiv-Mode oder im Aktiv/Passiv-Mode betrieben. Bei der Aktiv/Aktiv-Variante sind beide Systeme immer aktiv. Fällt einer der bedienten Server aus, übernimmt der andere die Last des ausgefallen Gerätes und stemmt damit die Last allein. In der Aktiv/Passiv-Variante ist nur einer der Server aktiv. Das zweit – passive – Gerät überwacht dabei immer den aktiven Partner. Fällt dieser aus oder ist nicht mehr erreichbar, dann – und nur dann – übernimmt der passive Rechner die Arbeit.
Double-Take repliziert Server und Datenbereiche
Das Cluster-Verfahren stellt auch das Prinzip dar, nach dem die Double-Take-Produkte operieren. So ist die Systemlösung Double-Take für Hyper-V im Kern ein Toolset, das einen vollständigen Quell-Server oder ausgewählte Datenbereiche auf ein zweites Zielsystem zeitnah repliziert und die Erreichbarkeit des Quell-Servers laufend überwacht. Durch systemnahe Treiber werden dabei die Daten laufend vom Quell-Server abgegriffen und auf den Sicherungs-Server kopiert. Dabei ist bei der Replikation der Quelle zum Ziel prinzipiell unerheblich, im welchen Format die Quelldaten vorliegen. Gleichzeitig überwacht der Ziel-Server die Verfügbarkeit des Quell-Servers.
Ist der Quell-Server nicht mehr über das Netzwerk erreichbar, so geht der Ziel-Server davon aus, dass das Quell-System auch für die Benutzer nicht mehr verfügbar ist. Daraufhin schaltet das Tool den bis dato inaktiven Ziel-Server aktiv, und dieser übernimmt sofort den Dienst.
Wie erwähnt, liefert das Unternehmen verschiedene Ausprägungen seiner Software. Die traditionelle Version des Tools sichert einen physischen Server durch einen zweiten Server ab. Dabei erfolgt die Replikation vom physischen Quell-Server auf den ebenfalls physischen Ziel-Server. Daneben lässt sich aber auch ein physischer Quell-Server in eine virtuelle Umgebung sichern. Der Ziel-Server läuft dann als virtuelle Maschine in einer Virtualisierungsumgebung.
Eine weitere Variante der Replikation ist die Sicherung einer virtuellen Maschine auf einem Host in eine virtuelle Maschine auf einen weiteren Host. Dies ist die Variante, die bei Double-Take für Hyper-V verwendet wird. Durch die Replikation der virtuellen Maschine erfolgt dabei die geforderte Absicherung des Hyper-V und seiner entsprechenden virtuellen Maschinen gegen einen Ausfall.
Verschiedene Verfahren der Replikation
Durch die universelle Auslegung von Double Take für Hyper-V sind auch andere Topologien mit weitaus komplexeren Szenarien möglich. Die Replikation muss sich auch nicht immer auf eine 1:1-Abbildung zwischen Quelle und Ziel beschränken. Stattdessen können auch beliebige Konstellationen mit mehreren Quell- und Zielsystemen gebildet werden.
Die 1:n-Abbildung ermöglicht es beispielsweise, mehrere virtuelle Maschinen eines Hyper-V auf unterschiedliche Hyper-V-Hosts zu spiegeln. Der umgekehrte Weg der n:1-Abbildung erlaubt die Absicherung mehrere Hyper-V-Host auf ein einziges System. Dies ist in der Praxis auch das gängigste Verfahren, denn dabei lassen sich die virtuellen Maschinen von drei Hosts auf einem einzigen Server zusammenfassen. Natürlich wird dieser Server kaum die Last der drei Quell-Hosts vernünftig stemmen können, aber für den Notfall mag es reichen. Ferner müssen nicht immer alle virtuellen Maschinen eines Host gesichert werden, sondern nur die, die für einen Notbetrieb benötigt werden.
Als Voraussetzung für Double-Take für Hyper-V gilt Windows Server 2008 mit Hyper-V. Wird keine Mehrfachreplikation oder auch keines der erwähnten komplexeren Modelle gewählt, so genügen im Praxisbetrieb zwei Hyper-V-Host. Dies ist auch die Variante, die wir für unseren Test auswählten. Die Software ist sowohl auf dem Quell- als auch auf den Ziel-Servern eingerichtet. Eine andere Variante wäre die Installation von Double-Take in einer virtuellen Maschine. Doch bei besagtem Modell kann nur diese eine virtuelle Maschine gesichert werden.
Nach dem Setup der Software, das schnell durchlaufen ist, finden sich im Windows-Startmenü zwei Menüs zur Double-Take Software. In diese Menüs sind unter anderem zwei Konsolen eingeblendet: die Managementkonsole und die Double-Take-Konsole. Allerdings führen diese doppelten Menüs und Konsolen beim Benutzer eher zu Verwirrung. Laut Aussage des Herstellers soll diese doppelte Programmstruktur in Zukunft in ein Menü zusammengeführt werden.
Die Managementkonsole bildet die übergeordnete Konsole für den Einsatz von Double-Take in größeren Szenarien mit mehreren Servern. Ferner werden in diesem Menüpunkt erstmalig die Server dem Anwender bekannt gemacht. Der Großteil der Arbeit aber erfolgt mittels der Double-Take-Konsole. Prinzipiell sollte man die beiden Verwaltungskonsolen in kleineren Szenaren auf beiden Rechner einrichten. Denn wenn einer der Server ausfällt, kann immer noch von der Konsole des anderen Servers administriert werden. Allerdings wird idealerweise die Verwaltung des Systems vom Ziel-Server vorgenommen, denn wenn das Quell-Gerät ausfällt, wäre die Konsole auf dem Quell-Server nicht mehr verfügbar.
Zentrale Verwaltung durch die Double-Take-Konsole
Nach dem Aufruf der Double-Take-Konsole präsentiert sich diese sehr aufgeräumt und übersichtlich. Am oberen Rand finden sich unter anderem die Bereiche zur Server-Verwaltung Manage Servers der Replikationsverbindungen Monitor Connections, eine Option Get Started und der „Home-Knopf“, der zur Startseite der Konsole verweist.
Im ersten Schritt müssen die Double-Take-Server eingebunden werden. Sofern man dies nicht schon in der Managementkonsole durchgeführt hat, sind sie unter der Option Manage Servers oder Get Started einzutragen. Double-Take für Hyper-V braucht kein Active Directory und auch keinen FQN (Full Qualified Name), es genügen die einfachen Windows-Rechner-Namen. Im Rahmen unseres Tests haben wird unsere beiden Hyper-V-Testmaschinen nur hier eingetragen. Das ließ sich schnell und problemlos durchführen..
Anschließend ist unter Get Started eine Replikation einzurichten. Hier finden sich die Optionen, einen physischen oder virtuellen Server in eine virtuelle Maschine zu sichern – Protect a server to a Hyper-V virtual machine – oder eine virtuelle Maschine eines Hyper-V auf einen anderen Hyper-V zu sichern – Protect a virtual machine –.Für den Test wählten wir letztgenannte Option.
Nach dieser Auswahl ist eine Dialogfolge zu durchlaufen, die nach den notwendigen Parametern für die Replikation fragt. Dazu gehören der Quell-Server und dessen virtuelle Maschine, die gesichert werden soll, und der Ziel-Server und das Verzeichnis, in dem die virtuelle Maschine abzuspeichern ist, sowie die Berechtigungen für den Zugriff und der Port, den Double-Take zur Replikation verwenden soll. Ferner müssen die Netzwerkzugänge angeben werden. Falls der Quell- und der Ziel-Server eine unterschiedliche Netzwerkkonfiguration aufweisen, kann man diese hier anpassen.
Zu den weiteren Konfigurationseinstellungen gehören die Netzwerkkarte und ihre IP-Adresse, über die die Replikation erfolgen soll. Außerdem lässt sich hier die Bandbreite für die Replikation festlegen. Dadurch wird verhindert, dass während der Dauer der Replikation andere Systeme zu wenig Bandbreite erhalten und damit ausgebremst werden. Nach dem Durchlauf der Dialogfolge beginnt das Programm die Replikation der virtuellen Maschine auf den Ziel-Host. Die Dauer hängt natürlich von der Größe der virtuellen Maschine und der Netzwerkbandbreite ab. Im Test benötigte die Replikation einer virtuellen Maschine mit Windows Server 2008 bei einer 100-Mbit-Leitung etwas mehr als zehn Minuten. Der Fortschritt der Replikation läst sich unter dem Eintrag Monitor Connections verfolgen.
Initialer Abgleich der Daten
Nach dem Anlegen des „Server-Spiegels“ auf eine zweite Rechnerkopie werden alle Änderungen auf Bytelevel-Ebene repliziert. Gleichzeitig wird der Überwachungsmodus aktiviert. Zur Replikation klinkt sich das Werkzeug in die IO-Prozesse des Betriebssystems ein. Aufgrund dieser Unabhängigkeit von Applikationen können somit jegliche Inhalte in der virtuellen Maschine repliziert werden.
Über die Option Monitor Connection kann die Replikation in Echtzeit verfolgt werden. Das Tool liefert dabei die Informationen, welche virtuellen Maschinen von welchem Quell-Servern auf welchen Ziel-Server repliziert werden. Ferner gibt die Konsole Aufschluss über die Dauer der Replikation und die Menge der übertragenen Daten sowie weitere Statusinformationen. Dabei bleibt die VM auf dem Source-Server bestehen und ist auch im Hyper-V-Manager sichtbar, solange die Replikation läuft. Während der Replikation wird nur der Inhalt der Datei der VM (der VHD) übertragen. Die VM ist in dieser Zeit auf dem Zielsystem nicht aktiv. Dies lässt sich durch den Hyper-V-Manager kontrollieren. Allerdings fanden sich auf dem Zielsystem im Hyper-V Manager dazu keine Hinweise.
Failover und Failback in der Praxis
Im Connections-Fenster des Programms sind dem Anwender mehrere Knöpfe zugänglich. Diese dienen den folgenden Zwecken:
• Configure – liefert die Konfigurationseinstellungen zur Replikation.
• Delete – um eine Replikation zu löschen.
• Start / Resume – Starten oder Fortführen der Replikation.
• Pause der Replikation – unterbricht eine laufende Replikation.
• Stop – Beenden der Replikation.
• Failover – Umschalten des aktiven Servers für eine virtuelle Maschine.
• Undo Failover – Rückgängigmachen des Failovers.
• Reverse Protection – Diese Funktion kehrt die Replikation von Quelle–Ziel nach einem Failover um.
Im Rahmen des Tests war allerdings die Icon-Leiste mit diesen Schaltknöpfen nach mehreren Arbeitsschritten plötzlich nicht mehr sichtbar. Nach Rückfrage bei der Hotline von Double-Take stellte sich heraus, dass dieses Problem bereits bekannt war und in der kommenden Version behoben sein soll. In der Zwischenzeit empfiehlt Double-Take den folgenden Workaround: Löschen der Server unter Manage Servers und anschließend neues Einfügen der Server. Bereits erzeugte Replikationen bleiben dabei erhalten.
Generell zeigt sich bei dem Test, dass die Abstimmung der Replikationssoftware von Double-Take mit Windows Server 2008 und Hyper-V noch nicht ganz ausgereift ist. Das Produkt Double-Take ist recht neu, gleichzeitig patcht Microsoft sein Betriebssystem und den Hyper-V noch, daher sind für die Zukunft Änderungen und Updates zu erwarten. Beim Einsatz von Double-Take sollten daher ausgiebige Tests in dem jeweils gewählten anwenderspezifischen Szenario vorgenommen werden.
Überwachungsfunktionen des aktiven Servers
Im nächsten Schritt führen wir in unserem Test den Failover einer VM durch. Dieser wird über das Icon unter Monitor Connection angestoßen. Die Option Failover Control Center im Menüeintrag der Startleiste von Windows darf dabei nicht verwendet werden, denn diese bezieht sich nur auf andere Cluster-Verfahren beziehungsweise Einsatzgebiete von Double-Take, wie eingangs erwähnt. Stößt man den Failover durch das Icon Monitor Connection an, so bietet das Tool zwei Varianten:
• Live: Dabei erfolgt ein Shutdown der virtuellen Maschine auf dem Quell-Server. Gleichzeitig wird die virtuelle Maschine auf dem Ziel-Server gestartet und mit einer aktiven Netzanbinddung versehen.
• Test: Hierbei wird die VM auf dem Source-System nicht heruntergefahren, sondern läuft weiter. Allerdings wird die virtuelle Maschine auf dem Ziel-Server gestartet. Damit sich die beiden Kopien derselben VM nicht in die Quere kommen, wird die VM auf dem Ziel-System ohne Netzanbindung gestartet.
Im Rahmen des Tests entschieden wir uns zuerst für einen experimentellen Failover. Nach der Initiierung war bereits nach wenigen Sekunden die VM auf dem Ziel-Server sichtbar. Das kann der Anwender im Hyper-V-Manager des Windows Servers in Echtzeit verfolgen. Gleichzeitig war die VM auf der Quelle noch vorhanden und lief weiter, da es sich um einen Test-Failover handelte. Allerdings erscheint die VM auf dem Ziel-Server mit einem erweiterten Namen. Der Hyper-V-Manager führt die neue VM mit der Namenserweiterung „_Replica“. Der Rechnername der VM beziehungsweise der Windows-Name des Servers innerhalb der VM ist allerdings identisch mit jenem auf dem Quell-Server.
Anschließen haben wir mit Windows Server 2008 eine weitere Replikation einer virtuellen Maschine eingerichtet. Nach deren intialem Abgleich konnte das System hierbei ebenfalls einen Failover erfolgreich ausführen. Auch die Failback-Operationen wurden in unserem Test korrekt ausgeführt. Darüber hinaus testeten wir das Live-Failover, indem wir die Replikationsrichtung durch die Option Reverse Protection umkehrten. Die gewählten Aktionen wurden von Double-Take fehlerfrei ausgeführt. Das gilt auch für die entsprechenden Einträge im Hyper-V-Manager.
Zur Optimierung der Replikation und des Failovers bietet Double Talke zusätzliche Einstellungen zur Optimierung dieser Funktionen. So kann der User beispielsweise das Monitoring-Intervall von standardmäßig drei Sekunden frei variieren. Auch der Kommunikations-Port lässt sich an die Anwenderbedürfnisse anpassen. Als Standard verwendet das Replikationswerkzeug den Port 6320.
Fazit
Double-Take für Hyper-V ermöglicht die Absicherung von Hyper-V-Systemen und dessen virtuelle Maschinen. Wenngleich, wie im Test erwähnt, das GUI und die Bereinigung der Menüs noch nicht endgültig abgeschlossen sind, so bietet Double-Take für die virtuellen Maschinen des Hyper-V eine abgesicherte Umgebung. Allerdings sollten ausgiebige Tests, bezogen auf den eigenen Einsatzzweck, vorausgehen – diese Vorgehensweise gilt eigentlich für jegliches Tool dieser Art.
Wie bei unserem Test sollte der Anwender auch eine paar Randbedingungen von Windows beachten. So hatten wir in unserem Testumfeld Windows Server so eingerichtet, dass automatische Updates von der Microsoft-Website durchgeführt wurden. Nach dem initialen Abgleich und nach der Aktualisierung des Hyper-V sollte der Anwender die Auto-Update-Funktion für die virtuellen Maschinen vorzugsweise abschalten. Ansonsten holt sich der Source-Server, insbesondere bei Tests, die über mehrere Tage laufen, immer wieder neue Updates, die dann natürlich auf den Ziel-Server ständig repliziert werden. Dies kann die Leistungsfähigkeit und die Arbeit mit dem Werkzeug durchaus verfälschen beziehungsweise erschweren. (hal