04.02.2008 | Autor / Redakteur: Harley Stagner / Ulrich Roderer
Wie kann man einen VMware ESX Server retten, wenn der physische Server ausfällt, ohne dass Failover-Lösungen zum Einsatz kommen? Dazu muss nur ein redundanter Fileserver in einer virtuellen Maschine verfügbar sein, der per Skripts gesichert wird.
Im ersten Artikel dieser Serie (Redundante virtuelle Maschinen als Alternative zu Hochverfügbarkeit mit Vmware HA oder Vmotion) wurde gezeigt, wie ein Dateiserver in einer virtuellen Maschine installiert wird. Fällt ein Server aus, lässt sich der iSCSI-Plattenspeicher mit einem anderen Server verbinden. Aber das dazu notwendige Mappen der Laufwerke bedeutet eine längere Downtime für Anwender. Da in unserem Szenario der Dateiserver in einer virtuellen Maschine läuft, wäre es ideal, wenn er ohne große Verzögerung auf einem anderem ESX-Server kurz nach dem Ausfall zum Laufen käme. Da die beiden ESX-Server aber auf keinen gemeinsam verwendeten Speicher zugreifen können, muss eine Kopie der virtuellen Maschine des Fileservers auf beiden ESX-Servern vorhanden sein. Diese beiden VMs müssen synchronisiert sein, sofern eine Änderung an einer Maschine durchgeführt wird. Meist geschehen solche Änderungen durch das Einspielen von Patches.
Dazu reicht es, die Dateien der virtuellen Maschine einmal im Monat nach dem Patchen manuell zu kopieren. Dabei sollte die virtuelle Maschine zuvor heruntergefahren werden. Die hier vorgestellte Lösung umgeht das Problem der Auszeit durch den Einsatz von Vmware Converter 3.0.1 Enterprise. Diese Lösung führt zeitgesteuert die Aufgabe aus, die Kopie einer virtuellen Maschine bei laufendem Betrieb auf einen anderen ESX Server zu erstellen.
Dafür lässt sich unter dem Converter 3.0.1 Enterprise das Tool p2vtool.exe einsetzen. Dabei handelt es sich um ein Kommando-orientiertes Interface des Converter 3.0.1. Allerdings besteht nur ein experimenteller Support für p2vtool.exe. Doch die hier gezeigten Skript haben sich im Test als gut funktionierend erwiesen. Damit das p2vtool.exe eine existierende VM konvertieren kann, müssen einige Vorbedingungen erfüllt sein:
Es muss der Zugriff auf einen Account bestehen, der Administratorrechte auf der Quell-VM besitzt.
Um eine Email nach Beenden der Konversion versenden zu können, muss eine Scripting-Sprache wie Powershell oder VBscript zum Einsatz kommen.
Der Converter 3.0.1 muss mit einer Enterprise-Lizenz auf einem Windowsrechner installiert sein
Die Parameter der Konversion für p2vtool.exe muss in einer XML-Datei gespeichert sein.
Nachdem der Converter 3.0.1 auf dem Windows XP Managementrechner installiert ist, wird es Zeit für das Sccripting. Zuerst wird die XML-Datei für p2vtool.exe angelegt, die die Konversion startet:
Laden Sie hier die XML-Datei für p2vtool.exe herunter.
Die verwendeten Parameter sind in der Hilfedokumentation des Converters erklärt. Die Verwendung des P2vtool.exe finden sich am Ende der Hilfedatei in einem Appendix. Die virtuelle Maschine wird als physische Maschine behandelt, damit sie während der Kopie weiterlaufen kann. Denn eine Kopie von einer VM auf eine andere ist nur möglich, wenn die Quell-VM beendet ist. Im Beispiel wurden alle Scripts und die XML-Datei im Verzeichnis C:\p2v gespeichert.
Da immer mehr Administratoren Powershell einsetzen, folgt ein Skript sowohl für Powershell als auch VBscript. The Powershell-Skript besteht aus mehreren Dateien:
Die Datei p2v.cmd wird benötigt, weil „.ps1“-Dateien (Powershell-Script) keine standardmäßige Verknüpfung in Windows XP haben. Administratoren können ein „ps1“-Script auch direkt über die cmd-Kommandozeile aufrufen, aber die Lösung mit „p2v.cmd“ vereinfacht das Vorgehen. Nachfolgend die p2v.cmd-Datei:
Das p2v.ps1-Script lautet folgendermaßen:
Laden Sie hier das p2v.ps1-Script herunter.
Eine Einstellung muss noch vorgenommen werden, damit p2v.ps1 startet. Powershell interpretiert standardmäßig nur Befehle, die in die Kommandozeile eingetippt werden, aber keine Scripts. Deshalb muss ein Administrator zumindest die Option „Remote Signed“ einstellen. Damit laufen dann lokal erzeugte Scripte aber keine geladenen Scripte. Dafür muss die Option „Set-ExecutionPolicy RemoteSigned“ eingestellt werden. Genauere Informationen können Administratoren abrufen durch den Befehl „help about_signing“. Um dieses Script als zeitgesteuerter Task auszuführen, reicht es, p2v.cmd entsprechend oft laufen zu lassen
Soll VBscript zum Einsatz kommen, so lautet das Listing folgerndermaßen:
Laden Sie hier das passende p2v.vbs-Script herunter.
Das p2v.vbs-Script belastet den Prozessor stärker, weil das „p2vtool.exe“-Tool die Ausführung überwacht um festzustellen, zu welchem Zeitpunkt die Konversion beendet ist.
Beide Skripte senden eine Email-Benachrichtigung an den Administrator. Das ist deshalb notwendig, weil eine manuelle Nachbearbeitung notwendig ist. Erstens existieren nach der Konversion zwei VMs mit gleichem Namen. Deshalb muss eine gelöscht werden. Da die Quell-VM als physchiche Maschine bei der Konversion behandelt wurde, müssen jetzt einige Treiber aus der Konfiguration der VM entfernt werden und sie muss mit dem entsprechenden vSwitch verbunden werden. Die Bildstrecke zeigt die einzelnen Schritte der Nachbearbeitung.
Damit ist ein redundanter Dateiserver geschaffen. Fällt der ESX Server aus, läßt sich dieser Dateiserver manuell auf einem anderen ESX Server booten.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2009923)
