Disaster Recovery für die virtualisierte Infrastruktur

ITMAGAZINE
Disaster Recovery für die virtualisierte Infrastruktur
15. Februar 2008 - Weder Double-Take for VMware Infrastructure noch vReplicator haben im Failover-Test
vollständig überzeugt. 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.
Disaster Recovery mit Hindernissen
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.
Replikation ohne SAN
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
Konfigura-tionsparameter ü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.
Double-Take for VMware Infrastructure
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. Obwohl beide ESX-Server per Gigabit-Ethernet miteinander verbunden waren, nahm die erste Übertragung von
zwei insgesamt 16 GByte grossen virtuellen Maschinen (VM) mit je einer Oracle- und einer
Microsoft-SQL-Server-Datenbank gut eine Stunde in Anspruch. Dabei blieb die optionale Datenkompression
deaktiviert, wodurch sich die CPU-Auslastung der ESX-Server in Grenzen hielt. Verzögerungsfreies Arbeiten mit
den VMs war so auch während des Replikationsvorgangs möglich.
Die nach Abschluss der Replikation durchgeführten Umschaltversuche über die Failover-Funktion von
Double-Take verliefen zunächst ebenfalls erfolgreich. Die Software bietet zwei Failover-Varianten an: Zum einen
den «Test Failover», bei dem die VM auf dem Reserve-ESX-Server ohne Netzwerkanbindung gestartet wird,
während die Original-VM weiterläuft. Diese Variante eignet sich dazu, festzustellen, ob die Replikation
erfolgreich war und sich die replizierte Maschine überhaupt starten lässt.
Zum anderen gibt es den «Live Failover», bei dem die Original-VM zunächst heruntergefahren wird und
Double-Take dann die replizierte VM startet. Sofern kein Fehler vorliegt, kann der Systemverwalter sogar
angeben, ob ein gegebenenfalls noch offener Replikationszyklus noch zu Ende geführt werden soll oder nicht.
Wurde ein Live Failover erfolgreich durchgeführt und die replizierte VM erfolgreich gestartet, kann der
Systemverwalter zu jedem beliebigen Zeitpunkt auf «Reverse Protection» klicken, um die Replikation
umzukehren und den Urzustand wiederherzustellen.
Probleme in der Praxis
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.
vReplicator
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
Replika-tionsjobs. 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.
Ausfalltest ebenfalls problematisch
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/ /. 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.
Fazit: Nicht perfekt
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 ma-nuellen Handgriffen retten,
was zu einer insgesamt besseren Bewertung führte, jedoch ist die Vorgehensweise 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.
So wurde getestet
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 ins-talliert 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
Copyright by Swiss IT Media 2017