Viele Unternehmen betreiben für unterschiedliche Anwendungen eine ganze Armee von Servern mit verschiedenen Betriebssystemen wie Linux, Windows oder Netware. Doch die mit schnellen Xeon-CPUs, Gigabit-Ethernet-Verbindungen und reichlich Hauptspeicher ausgestattete Hardware ist oft bei weitem nicht ausgelastet. In solchen Fällen liegt es nahe, den auch in der Administration teuren Server-Park mit seinen Anwendungen auf ein angemessenes Maß an Rechenleistung zu reduzieren. Hardwarehersteller haben hierzu partitionierbare Hochleistungs-Server im Programm, die allerdings kostspielig sind. Eine Alternative kommt von der Softwareseite, die das Problem mit Virtualisierungsprogrammen angeht. Eine speziell für Intel-Server-Systeme entwickelte Lösung aus dem Highend-Bereich bietet das kürzlich von EMC übernommene US-amerikanische Unternehmen VMware mit dem Produkt ESX Server.
Dieser emuliert auf einem Standard-IA-32-System mehrere virtuelle Server. Dazu bildet die Software eine Hardwareumgebung mit virtueller CPU, Hauptspeicher, Festplatte, CD-ROM sowie Ein- und Ausgabeschnittstellen nach. Innerhalb dieser virtuellen Maschinen kann der Systemverwalter wiederum das gewünschte Betriebssystem mit der entsprechenden Anwendung installieren. Auf diese Weise lassen sich auf einer leistungsstarken Hardware beispielsweise mehrere Linux- und Windows-Server parallel betreiben.
Im Gegensatz zu anderen Lösungen benötigt der ESX Server kein so genanntes Host-Betriebssystem, in dessen Kontext die Virtualisierung stattfindet. Das VMware-Produkt verfügt stattdessen über einen eigenen Kernel, der die virtuellen Maschinen sogar als symmetrische Multiprozessor-Umgebung (Virtual SMP) mit zwei CPUs realisiert. Zusätzlich kann der Systemverwalter genau festlegen, wie viel von den physikalischen CPU-Ressourcen eine virtuelle Maschine in Anspruch nehmen darf. Dies wird über eine Unter- beziehungsweise Obergrenze definiert.
Ein anderer Vorteil der VMware-Lösung besteht darin, dass sich einmal erstellte virtuelle Maschinen ohne Änderungen auf jeder beliebigen Intel-Hardware ausführen lassen, sofern die passende ESX-Server-Version installiert ist. Ausgehend von einem Master-Betriebssystem-Image lassen sich beliebig viele Klone erzeugen, was die Bereitstellung zusätzlicher virtueller Maschinen deutlich vereinfacht. Ebenso kann der Systemverwalter sehr schnell das Recovery eines virtuellen Servers veranlassen, selbst wenn die physikalische Hardware beim Ausfall irreparable Schäden erlitten haben sollte. In der virtuellen Umgebung unterstützt ESX Server die Ausführung der Betriebssysteme Microsoft Windows NT/2000/2003/XP, Red Hat und Suse Linux sowie Novell Netware ab Version 5.1.
Einstieg mit preiswerter Hardware möglich
Die Hardwarevoraussetzungen für den ESX Server sind nach heutigen Maßstäben nicht sonderlich hoch. So werden mindestens zwei Pentium-III-Xeon-CPUs mit 700 Megahertz benötigt; soll Virtual SMP zum Einsatz kommen, muss die Taktrate 900 Megahertz betragen. Es werden bis zu 16 physikalische CPUs unterstützt, mit denen sich maximal 80 virtuelle CPUs nachbilden lassen. Die Speicherausstattung umfasst mindestens 512 MB und lässt sich auf maximal 64 GB ausbauen. Für die Netzanbindung schreibt der Hersteller zwei Ethernet-Adapter vor, wobei einer dediziert für die Steuerung von ESX Server vorgesehen ist, während der andere den virtuellen Maschinen dient.
Zur weiteren Performance-Steigerung und zur Erhöhung der Ausfallsicherheit kann der Systemverwalter die Netzwerkkarten zudem als NIC-Team (NIC = Network Interface Card) betreiben. Für die Speicherung der virtuellen Maschinen setzt ESX Server einen SCSI-Controller samt SCSI-Platte voraus.
Aus Gründen der Ausfallsicherheit ist jedoch der Einsatz eines Raid-Controllers oder eines Fibre Channel Host Bus Adapters (HBA) angeraten. Vor allem in größeren Umgebungen sollte die Datenablage in einem Storage Area Network (SAN) erfolgen, da VMware SAN-Failover unterstützt. Sollte ein HBA ausfallen, schaltet ESX transparent auf den zweiten um. Zudem bietet VMware über eine separat erhältliche Software namens Virtual Center die Möglichkeit, virtuelle Maschinen im SAN per VMotion-Funktion im laufenden Betrieb zwischen verschiedenen physikalischen ESX Servern hin- und herzuschieben. Ebenfalls für größere Umgebungen hilfreich ist die automatisierbare Installation weiterer ESX Server.
Alle für einen virtuellen Server erforderlichen Systemparameter kann der Administrator beim Einrichten einer virtuellen Maschine bequem angeben. Ein Assistent fragt die erforderlichen Daten ab und konstruiert daraus die gewünschte virtuelle Hardware. Notwendige Parameter betreffen beispielsweise die Hauptspeichergröße, die Art des Netzwerkzugriffs sowie Art und Größe der virtuellen Festplatte, auf der später das Betriebssystem installiert werden soll. Für jedes unterstützte Gast-Betriebssystem stellt VMware passende Tools zur Verfügung. Diese bieten einerseits einen entsprechenden Grafiktreiber, synchronisieren aber auch die Zeit zwischen dem Host- und dem Gastsystem, führen auf Wunsch Skripte aus und dienen dazu, den vom Gastsystem belegten Plattenplatz zu optimieren.
Virtualisierung im Härtetest
Installation und Konfiguration von ESX Server 2.1 erwiesen sich dank einer für diese Version vollkommen neu entwickelten grafischen Oberfläche als problemlos. Lediglich bei der Partitionierung des Speicherplatzes sollte man darauf achten, die Partitionsgrößen nicht zu klein zu wählen und gegebenenfalls noch Platz für den etwaigen Transfer vorhandener virtueller Maschinen bereitzustellen, die beispielsweise mit dem VMware GSX Server erzeugt wurden.
Als erste virtuelle Maschine richteten wir Windows 2000 Server ein. Dazu konfigurierten wir über die Web-Oberfläche des ESX Server zunächst die virtuelle Hardware. Anschließend legten wir die Windows-2000-Installations-CD ein und verbanden uns über die VMware Remote Console auf das ESX-System. Dort startete die virtuelle Maschine, um die Installation vorzunehmen, was auch problemlos funktionierte. Gleiches galt für die Installation des Suse Linux Enterprise Server in der Version 8.
Anschließend versuchten wir bereits vorhandene, mit dem zweiten Virtualisierungsprodukt von VMware, "GSX Server 2.51", erstellte virtuelle Maschinen auf den ESX Server zu migrieren. Da die Datenformate zwischen dem von uns verwendeten GSX Server 2.51 und dem ESX Server nicht hundertprozentig kompatibel sind, war eine Konvertierung notwendig, für die der ESX Server sorgte. Dazu mussten wir die GSX-Dateien zunächst per FTP auf das ESX-System transferieren. Anschließend verwendeten wir den VMware File Manager, um die Dateien vom Transferverzeichnis auf die mit dem VMware-eigenen VMFS-2 Dateisystem formatierten SAN-Platten abzulegen und die automatische Konvertierung in Gang zu setzen.
Was auch mit einer vorhandenen virtuellen NT-4.0-Installation problemlos funktionierte, schlug mit Windows 2003 jedoch zunächst fehl. Die Ursache hierfür war schnell ausgemacht. Der ESX Server setzt nämlich zwingend voraus, dass die virtuelle Maschine auf einer virtuellen SCSI-Disk installiert ist. Dies traf jedoch nur auf die virtuelle NT-Maschine zu. Nachdem wir Windows 2003 auf einer virtuellen SCSI-Platte installiert hatten, ließ sich die Installation nach einer weiteren kleineren Konfigurationsänderung auf den ESX Server übernehmen.
In der Konfigurationsdatei für den virtuellen Windows 2003 Server musste der Wert der Option "scsi0.virtualDev" von "vmxlsilogic" auf "vmxbuslogic" geändert werden, damit die virtuelle Maschine beim Booten nicht in einen "Bluescreen" lief. Unternehmen, die vorhaben, virtuelle Maschinen zwischen den unterschiedlichen Plattformen zu migrieren, sollten deshalb gleich im Vorfeld darauf achten, eine einheitliche SCSI-Konfiguration mit dem Adapter von Bus Logic zu verwenden. VMware wäre aber auch gut beraten, den Migrationsweg zwischen den unterschiedlichen VMware-Plattformen noch etwas einfacher zu gestalten. Zumindest über das optional erhältliche Zusatz-Tool Virtual Center soll dies besser gelöst sein.
Um zu sehen, wie die virtuellen Server unter Last reagieren, starteten wir vier virtuelle Maschinen gleichzeitig und ließen diese Disk-I/O-intensive sowie grafische Applikationen ausführen. Obwohl unser Dell-Server deutlich mit der Last beschäftigt war, blieben alle virtuellen Maschinen gut erreichbar und erledigten ihre Aufgaben problemlos.