Die zuverlässige, schnelle und leistungsfähige Wiederherstellung nach einem Totalausfall kann für virtualisierte Umgebungen ebenso unternehmenskritisch sein wie für herkömmliche physikalische. Die Hersteller Double-Take und Vizioncore haben entsprechende Lösungen für Vmware Virtual Infrastructure 3 parat.
Die Virtualisierungslösung Vmware Virtual Infrastructure 3 (VI3) auf Basis des ESX Server 3 erfreut sich in Unternehmen unterschiedlichster Grössenordnungen zunehmender Beliebtheit. Was jedoch bisher noch fehlte, war eine einfache Lösung, um einen zuverlässigen, preiswerten und effizienten Disaster-Recovery-Mechanismus für die virtuellen Maschinen zu realisieren.
SAN-basierte Lösungen, die zu diesem Zweck in grösseren Unternehmen zum Einsatz kommen, sind zwar sehr leistungsfähig, dabei jedoch häufig kostspielig oder komplex in der Bedienung.
Abhilfe versprechen die softwarebasierten Replikationswerkzeuge «Double-Take for Vmware Infrastructure» (DTVI) und «vReplicator». Diese Tools kopieren die Inhalte der virtuellen Festplatten sowie die benötigten Konfigurationsparameter über das LAN von einem ESX Server auf einen zweiten. SAN-Speicher ist hierfür nicht erforderlich.
Damit die replizierten Virtuellen Maschinen (VM) stets auf dem Stand der Produktivsysteme sind, nutzen die Tools die Fähigkeit von VI3 zur Erzeugung von Snapshots im laufenden Betrieb. Die Snapshots werden automatisch in konfigurierbaren Intervallen auf den Reserve-ESX-Server übertragen und anschliessend mit den dort vorhandenen Daten verschmolzen.
Da die Replikation nicht in Echtzeit geschieht, muss im Katastrophenfall bei beiden Lösungen mit einem Datenverlust gerechnet werden, dessen Umfang vom Replikationsintervall abhängt. Dafür lässt sich die Replikation jedoch über nahezu beliebige Distanzen durchführen, solange ausreichend Bandbreite zur Verfügung steht.
Vor der Installation der Double-Take-Lösung waren auf den beiden ESX-Systemen vorbereitende Tätigkeiten notwendig, die
im erfreulich kurz gefassten und gut lesbaren Handbuch beschrieben sind. So mussten wir die Secure-Shell-Konfiguration (SSH) der beiden ESX-Server so ändern, dass Remote-Login mit Root-Rechten möglich wurde. Zudem mussten wir die Firewall-Konfiguration anpassen, um SSH-Client-Verbindungen zuzulassen.
Anschliessend installierten wir die Client- und die Serverkomponente von Double-Take for Vmware Infrastructure auf einem Windows-2003-Server, was innerhalb weniger Minuten erledigt war. Mit der übersichtlichen, klar gegliederten und über Assistenten bedienbaren Oberfläche kamen wir sofort und intuitiv zurecht und begannen damit, Replikationsjobs für die virtuellen Maschinen einzurichten. Mit Hilfe einer übersichtlich gestalteten Monitor-Ansicht behält der Systemverwalter den Überblick über alle eingerichteten Jobs, kann deren Status erkennen und bei Bedarf eingreifen.
Um einen Fehlerfall zu simulieren, setzten wir die virtuellen Maschinen anschliessend unter Last, indem wir per Skript bei beiden virtualisierten Datenbanksystemen in schneller Folge Tabelleneinträge hinzufügten. Anschliessend warteten wir, bis DTVI die Replikation startete und etwa 25 Prozent des zu replizierenden Datenvolumens übertragen hatte. Zu diesem Zeitpunkt schalteten wir den primären ESX-Server einfach ab, warteten ein paar Minuten und klickten dann in der DTVI-Oberfläche auf «Live Failover» – aber nichts passierte. Als auch nach zunächst einer Stunde und einer Nacht des Wartens noch immer keinerlei Reaktion erfolgte, brachen wir die Replikationsjobs ab und versuchten, die replizierten VMs auf dem Reservesystem von Hand zu starten.
Dies wurde vom ESX-Server zunächst mit einer Fehlermeldung und dem Hinweis auf eine defekte vmdk-Datei quittiert. Nach dem Löschen des Redo-Logs liessen sich die VMs zwar starten, aber die NTFS-Dateisysteme der VMs waren in Mitleidenschaft gezogen. Wir konnten sie zwar mit Hilfe des chkdsk-Kommandos reparieren und auch auf die Datenbanken zugreifen, jedoch wirkte dieser Test nicht gerade vertrauenserweckend. Hinzu kam, dass wir das Problem beliebig oft nachstellen konnten. Es handelt sich hierbei also definitiv um einen Bug. Der eilends hinzugezogene Hersteller-Support bestätigte nach einigem Hin und Her das Fehlerbild und versprach, dass sich die Entwickler des Problems annehmen würden. Eine Lösung lag bis zur Drucklegung dieses Artikels allerdings nicht vor.
Die vorbereitenden Tätigkeiten für die Installation des Vizioncore-Produkts unterschieden sich nur geringfügig von denen bei DTVI. Auch hier war es nötig, Anpassungen an der Secure-Shell- und Firewall-Konfiguration des ESX-Servers vorzunehmen. Allerdings waren die entsprechenden Informationen im Handbuch nur mit etwas Mühe zu finden. Anders als DTVI benötigt vReplicator für den Betrieb zusätzlich eine Datenbank, in der Konfigurationsinformationen und Logging-Daten abgelegt sind. Sofern im Unternehmen kein Microsoft-SQL-Server vorhanden ist, installiert vReplicator Microsoft SQL 2005 Express.
Trotz des zusätzlichen Aufwands für die Datenbank nahm die Installation nur wenige Augenblicke in Anspruch. Über einen Wizard konfigurierten wir unsere beiden ESX-Server und begannen mit der Einrichtung der Replikationsjobs. Dabei fiel auf, dass die Oberfläche des vReplicator einen weniger aufgeräumten und übersichtlichen Eindruck hinterliess wie der Mitbewerber. Es empfiehlt sich dringend, die Kommentarfelder zu nutzen, damit man später noch weiss, welche VM von welcher Quelle zu welchem Ziel repliziert wird.
Die Initialreplikation ging beim vReplicator allerdings spürbar schneller vonstatten als bei Double-Take. In unserem Fall dauerte der Vorgang knapp 25 Minuten und war damit fast doppelt so schnell. Ähnlich wie DTVI bietet auch vReplicator zwei Failover-Modi. Diese werden mit «Test Failover» und «Failover» bezeichnet und entsprechen in Funktionsweise ihren Pendants bei DTVI. Beide funktionierten im Normalbetrieb, also ohne den simulierten Ausfall eines ESX-Servers, problemlos. Die Replikationsrichtung lässt sich nach kurzem Deaktivieren des Replikationsjobs umdrehen, so dass die Ausfallsicherheit nach einem Failover wieder hergestellt werden kann. Um nach mehrfachem Hin- und Herschalten und bei mehreren VMs den Überblick nicht zu verlieren, muss der Systemverwalter allerdings genau hinsehen und eventuell mit Vmware Virtual Center gegenprüfen, welche VM denn nun wo läuft und wie die Replikation konfiguriert ist.
Abschliessend führten wir auch mit dem vReplicator noch den Ausfalltest durch, an dem DTVI gescheitert war. Überraschenderweise hatte auch das Vizioncore-Produkt ein Problem damit, wenn der primäre ESX-Server während eines Update-Replikationsdurchlaufs einfach ausgeschaltet wurde. Ein Klick auf den Failover-Button zeigte nämlich keinerlei Wirkung. Allerdings waren wir in der Lage, die replizierten virtuellen Maschinen von Hand zu starten, indem wir auf dem Ersatz-ESX-Server die Dateien mit der Endung *.DO-NOT-POWER-ON nach *.vmx umbenannt und die Rechte an der vmx-Datei mit dem Unix-Kommando chmod u=rwx,g=rx,o=rx *.vmx neu gesetzt hatten. Die Dateien finden sich auf dem ESX-Server unter /vmfs/volumes/GUID/VMname. Danach liessen sich die replizierten VMs problemlos starten. Da wir das Problem selbst recht einfach durch einen Workaround lösen konnten, verzichteten wir in diesem Fall auf eine Support-Anfrage beim Hersteller.
Beide Produkte konnten im Praxistest bei einem simulierten Ausfall nicht überzeugen, da der Failover nicht wie versprochen funktionierte. Dies führt zu einer deutlichen Abwertung bei den Kriterien Funktionalität und Bedienung. Bei Double-Take wurde die Situation noch dadurch verschärft, dass eine Datenkorruption nicht auszuschliessen war. Beim vReplicator liess sich die Situation zwar mit ein paar manuellen Handgriffen retten, was zu einer insgesamt besseren Bewertung führte, jedoch ist die Vor-
gehensweise in einer Stresssituation nur erfahrenen Systemverwaltern zuzumuten.
Da davon auszugehen ist, dass beide Hersteller ihre Produkte nachbessern werden, sollten Interessenten der an sich sinnvollen Lösungen auf jeden Fall die jeweils neueste Version nochmals auf Herz und Nieren prüfen.
Für den Praxistest haben wir folgende Testumgebung aufgebaut: Der primäre ESX-Server wurde auf einem Fujitsu-Siemens-Server Primergy RX 300 S2 installiert (2x3,6-Ghz-Xeon, 4 GB RAM). Der zweite ESX-Server lief auf einem Dell Poweredge 840 mit einer 2,4-GHz-Dual-Core-Xeon-CPU und zwei GByte RAM. Beim ESX-Server handelte es sich um die Version 3.0.2. Die Replikationssoftware wiederum installierten wir unter Windows 2003 Server auf einem Dell Poweredge 440SC mit einer 2,4-GHz-Dual-Core-Xeon-CPU und 4 GByte RAM. Um die Replikation zu testen, verwendeten wir zwei virtuelle Maschinen auf Basis von Windows 2003 Server, wobei eine mit Oracle 10g installiert war und die andere mit dem Microsoft SQL Server 2005. Jede der beiden virtuellen Maschinen verfügte dabei über eine Plattenkapazität von insgesamt 8 GByte.
Zwei Disaster-Recovery-Tools für Vmware Virtual Infrastructure 3 im Vergleich
