Servervirtualisierung auf höchstem Niveau

Mit der aktuellen dritten Version der Virtualisierungsplattform Virtual Infrastructure 3 verschiebt Hersteller Vmware die Messlatte für den Mitbewerb ein weiteres Stück nach oben. Zahlreiche neue Funktionen und eine überarbeitete Benutzeroberfläche ermöglichen dabei grössere und einfacher zu bedienende virtuelle Welten.
In vielen Unternehmen haben Virtualisierungslösungen von VMware oder anderen Anbietern mittlerweile Einzug ins Rechenzentrum gehalten. Während die meisten dieser Lösungen jedoch ein Host-Betriebssystem in Form eines Windows- oder Linux-Rechners erfordern, kommt die Enterprise-Lösung ESX Server 3.0.1 von VMware ohne eine solches Host-Betriebssystem aus und wird direkt auf der bereitgestellten Hardware installiert. Der ESX-Server bildet zusammen mit dem Management-Tool Virtual Center 2.0.1 die Basis für VMware Virtual Infrastructure 3. Im Gegensatz zu früher sind die beiden Produkte nicht mehr separat erhältlich, sondern werden nur noch zusammen verkauft.

Server verschmelzen zu Ressourcen-Pools

Der ESX-Server verfügt über einen eigenen Kernel, der die virtuellen Maschinen steuert. Mit Hilfe dieses Kernels schafft es der Hersteller, eine symmetrische Multiprozessor-Umgebung (Virtual SMP) mit bis zu vier CPUs je virtueller Maschine zu realisieren. Bei Bedarf kann der Systemverwalter regeln, wie viele der physikalischen Speicher- und CPU-Ressourcen eine virtuelle Maschine in Anspruch nehmen darf, und so dafür sorgen, dass diese auch bei einer hohen Gesamtauslastung des physikalischen Systems stets genügend Speicher und Prozessorleistung zur Verfügung hat. Dazu organisiert der ESX-Server alle Ressourcen in einem Pool, aus dem sich die verschiedenen virtuellen Maschinen bedienen können. Stehen mehrere ESX-Server zur Verfügung, kann dieser Ressourcenpool systemübergreifend aufgebaut werden. Sind beispielsweise vier Server mit je zwei 3-GHz-Prozessoren und je acht GByte Hauptspeicher verfügbar, so könnte der Systemverwalter über das neu hinzugekommene Dynamic Resouce Scheduling (DRS) einen Pool mit insgesamt 24 GHz CPU-Leistung und 32 GByte RAM aufbauen.

Flexibler Speicherzugriff dank Cluster-Filesystem

Zusätzlich zur Serverhardware wird für den Aufbau eines solchen Pools Festplattenspeicher benötigt, auf den alle physikalischen Systeme zugreifen können. Dieser Speicher muss entweder per Fibre-Channel-SAN oder über iSCSI beziehungsweise NFS-3 (Network File System) erreichbar sein. Die iSCSI-Anbindung kann entweder kostengünstig über den integrierten Software-Initiator erfolgen oder über leistungsfähige iSCSI-Host-Bus-Adapter, die die CPU des Host-Systems entlasten. Auf dem gemeinsam genutzten Speicher legt der ESX-Server das VMware-eigene VMFS-Cluster-File-System an, welches über Locking-Mechanismen verfügt, so dass gleichzeitig mehrere physikalische Server darauf zugreifen können. Kreiert der Systemverwalter innerhalb des Ressourcenpools neue virtuelle Maschinen und startet diese, so sorgt DRS dafür, dass sie automatisch auf der Hardware mit den meisten verfügbaren Ressourcen laufen. Sollte sich zur Laufzeit einer virtuellen Maschine herausstellen, dass der jeweilige Server in einen Ressourcenengpass läuft, kann DRS die virtuelle Maschine per VMotion-Funktion im laufenden Betrieb auf ein anderes System verschieben. Anwender merken von dem Umschaltvorgang ausser einer möglichen kurzen Verzögerung nichts.

Auch die Datensicherung virtueller Maschinen profitiert vom neuen Cluster-File-System. Per Consolidated Backup ist es nun möglich, über einen Proxy Sicherungen zu erzeugen und diese unter Umgehung des lokalen Netzwerks direkt über das SAN auf Band zu schreiben. Der Proxy muss dazu auf einem Windows 2003 Server installiert werden, der über das SAN Zugriff auf dieselben Speicherbereiche benötigt wie die ESX-Server, deren virtuelle Maschinen gesichert werden sollen. Leider läuft der komplette Backup-Vorgang ausschliesslich über Kommandozeilenbefehle ab, so dass die Bedienung noch etwas umständlich wirkt.

Hochverfügbarkeit für virtuelle Server

Um die Verfügbarkeit virtueller Maschinen zu erhöhen, kann der Systemverwalter die Option High Availability (HA) aktivieren, mit der eine Cluster-Funktionalität zwischen verschiedenen Servern realisierbar ist. Fällt ein physikalischer Server aus, lässt sich per HA steuern, ob und wie die zum Zeitpunkt des Ausfalls auf der defekten Hardware ausgeführten virtuellen Maschinen auf die verbleibenden Host-Systeme verteilt werden sollen. Ermöglicht wird der Failover durch eine wichtige Neuerung des VMFS-3-Dateisystems. Im Gegensatz zu früheren Implementierungen legt der ESX-Server nun neben den virtuellen Festplatten (VMDK-Dateien) der virtuellen Maschinen auch die übrigen relevanten Konfigurationsdaten auf dem VMFS-Dateisystem ab.

Überarbeitet hat Vmware auch die Service-Konsole, die für die Remote-Administration der ESX-Servers eine zentrale Rolle spielt. Sie basiert in der aktuellen Implementierung auf Red Hat Enterprise Linux Advanced Server 3 und ist nun vollständig virtualisiert. Damit entfällt die in früheren Versionen vorhandene Gefahr, dass die Service-Konsole als Schnittstelle zwischen dem VM-Kernel und der Aussenwelt zum Flaschenhals gerät. Auch die frühere Notwendigkeit, der Service-Konsole eine dedizierte Netzwerkkarte für die Kommunikation mit der Aussenwelt zur Verfügung zu stellen, gibt es nicht mehr.
Die bislang gewohnte Administration des ESX-Servers per Web-Browser gehört ebenfalls weitgehend der Vergangenheit an. Lediglich Aufgaben wie das Starten und Stoppen virtueller Maschinen sowie ein rudimentäres Monitoring lassen sich per Web-Interface erledigen. Abgelöst hat den Web-Browser der VMware Virtual Infrastructure Client, mit dem sich der Systemverwalter sowohl auf einzelne ESX-Server als auch auf das Virtual Center verbinden kann. Nahezu alle Funktionen, die früher nur über Kommandozeilenbefehle realisierbar waren, sind nun in einer ansprechenden grafischen Oberfläche eingebettet. Vor allem das Einbinden zusätzlicher VMFS-Partitionen sowie die Einbindung und Konfiguration neuer Hardware, wie zum Beispiel Fibre-Channel-Host-Bus-Adaptern, werden hiermit deutlich erleichtert.

64-Bit-Unterstützung inklusive

Erwachsener ist der ESX-Server auch in Sachen unterstützter Gastbetriebssysteme geworden. So unterstützt Vmware nunmehr eine grosse Anzahl von 64-Bit-Betriebssystemen der Anbieter Microsoft, Red Hat, Suse und Sun. Jede virtuelle Maschine kann zudem nun über einen bis 16 GByte grossen Adressraum verfügen. Kombiniert man diesen Wert mit den bis zu vier verfügbaren virtuellen CPUs pro virtueller Maschine, so rückt nun auch die Virtualisierung sehr leistungshungriger Applikationen aus dem Datenbank- oder ERP-Umfeld in den Bereich des Möglichen. Voraussetzung ist natürlich der Einsatz einer entsprechend leistungsfähigen Hardwareplattform. VMware hat hierzu eine ganze Reihe von Serversystemen der grossen Hersteller wie Dell, Fujitsu Siemens, HP und anderer zertifiziert. Hinzugekommen ist ausserdem ein recht weitreichendes Rollenkonzept, mit dessen Hilfe Systemadministratoren zahlreiche Berechtigungen für unterschiedlichste Aufgabenbereiche definieren können. Ebenfalls neu ist die Möglichkeit zur Nutzung eines Lizenzservers, um alle VI3-Lizenzen innerhalb eines Unternehmens zentral zu verwalten. Der Systemverwalter braucht dann bei der Installation eines ESX- Servers nur noch die IP-Adresse des Lizenzservers anzugeben und die gewünschten Funktionalitäten freizuschalten. Alternativ bleibt auch eine Host-basierte Lizenzverwaltung möglich.

Virtualisierung im Praxisbetrieb

Als Plattform für den Test von ESX 3.0 verwendeten wir einen Server vom Typ Primergy RX 300 S2 von Fujitsu Siemens Computers. Das System war mit zwei 3,6-GHz-Xeon-CPUs und vier GByte RAM ausgerüstet. Des weiteren kam ein Dell Poweredge Server mit einer 2,8-GHz-Xeon-CPU und zwei GByte Hauptspeicher zum Einsatz. Zur Aufnahme der virtuellen Maschinen fanden die Server über je einen Qlogic QLA2340-Fibre-Channel-Host-Bus-Adapter Anschluss an unser Labor-SAN. Dieses bestand aus einem Brocade Silkworm 3200 Switch und einem per Datacore SANmelody virtualisierten SATA-RAID-Array mit einer Gesamtkapazität von einem Terabyte. Für die Installation von Virtual Center und dem VMware-Lizenz-Server haben wir einen unter Vmware Workstation virtualisierten Windows 2003 Server eingesetzt.
Installation und Konfiguration des ESX Server 3.0 erwiesen sich dank der überarbeiteten grafischen Oberfläche als vollkommen problemlos. Lediglich der neuartige Lizenzierungsmechanismus kostete etwas Mühe und Nerven, da wir die von VMware bereitgestellte Lizenznummer nicht einfach eingeben konnten, sondern diese erst über das Internet registrieren und dann eine Lizenzdatei herunterladen mussten. Diese Datei musste dann wiederum auf dem Lizenzserver eingespielt werden, was alles in allem ein umständliches Prozedere ist.

Sowohl die Neuinstallation als auch der Transfer bereits vorhandener virtueller Maschinen auf die ESX-Server erwies sich als beinahe problemlos. Besonders vorteilhaft bei der Neuinstallation wirkte sich der Umstand aus, dass der ESX-Server auf lokale Ressourcen des Administrationsrechners zuzugreifen vermag. Damit kann der lästige Transfer von ISO-Images oder das Einlegen von Installationsmedien am Server entfallen. Für den Transfer bereits vorhandener virtueller Maschinen hat sich im Test der kostenlose VMware Virtual Machine Importer 2.0 bewährt. Mit dessen Hilfe konnten wir die meisten mit VMware Workstation oder VMware Server erzeugten virtuellen Maschinen bequem und problemlos auf die ESX-Server transferieren. Lediglich beim Versuch, eine virtualisierte Microsoft-Vista-Maschine zu übertragen, streikte das Tool mit dem Hinweis, dass es die virtuelle Platte nicht auslesen könne.

Beinahe ebenso einfach wie nützlich erwies sich der Einsatz der neuen Funktionen HA und DRS. Mit nur wenigen Konfigurationsschritten, die in der Dokumentation hervorragend beschrieben waren, konnten wir die Funktion innerhalb kürzester Zeit einrichten und nutzen. Insbesondere die HA-Funktion erwies sich als hilfreich, da sie nach dem Ausschalten eines der beiden ESX-Server dessen virtuelle Maschinen innerhalb kürzester Zeit wieder auf dem zweiten System startete.

Der Autor

Dipl. Ing. Dirk Pelzer ist Mitglied im Bundesverband Deutscher Sachverständiger und Fachgutachter. Er arbeitet als Consultant und Journalist in München. (dirk.pelzer@pelzer-consulting.de).