Ging es in den ersten Versionen nur um die statische Server-Partitionierung, dann um zentrale Verwaltungsschichten für mehrere Virtualisierungssysteme, dreht sich jetzt alles um verteilte Infrastrukturen. Nach dem Einzug von "ESX Server 2" in Verbindung mit "Virtual Center 1" in viele Rechenzentren musste VMware einige Funktionen aus dem Hut zaubern, um seinem Marketing-Slogan zur Unterstützung verteilter Infrastrukturen gerecht zu werden. Es galt außerdem, schlagende Argumente zu finden, um Bestandskunden dafür zu gewinnen, möglichst schnell auf die jetzt verfügbaren Produkte ESX Server 3 und Virtual Center 2 zu wechseln. Die beiden Lösungen hat der Hersteller kombiniert unter der Bezeichnung "VMware Virtual Infrastructure 3" (kurz: VI 3) auf den Markt gebracht.

Mehr Prozessoren, mehr Speicher

Beginnt man mit der wichtigsten Komponente einer virtuellen Infrastruktur, der virtuellen Maschine, so wurden in der aktuellen Version die Prozessor- und Hauptspeichergrenzen deutlich angehoben, so dass bis zu vier virtuelle Prozessoren statt wie bisher zwei und bis zu 16 GB Hauptspeicher (bislang 3,6 GB) unterstützt werden. Gerade beim Einsatz in großen Umgebungen erlaubt diese Anhebung der Leistungsgrenzen, bisher nicht virtualisierbare Systeme wie Datenbanken mit 8 GB Hauptspeicher in die virtuelle Welt zu migrieren. Außerdem ist es nun möglich, neue Festplatten zur Laufzeit des Gastsystems hinzuzufügen, was Ausfallzeiten reduziert. Administratoren, die dringend auf die Unterstützung von 64-Bit-Betriebssystemen im Gast gewartet haben, werden von VI 3 nicht enttäuscht. Es herrscht nun für viele 64-Bit-Windows- und Linux-Plattformen vorerst experimentelle Unterstützung seitens VMware.

Bezüglich des Gastsystems der virtuellen Maschine wurden zwei sehr unschöne Aspekte beseitigt, die eine unbeaufsichtigte Installation der VMware-Tools erschwerten. Zum einen hat VMware die Treiber für die virtuelle Hardware von Microsoft signieren lassen, so dass die in der Standardeinstellung von neueren Windows-Systemen aufblendende Meldung des nichtsignierten Treibers der Vergangenheit angehört. Der wichtigere Aspekt ist jedoch die Möglichkeit, die VMware-Tools mehrerer virtueller Maschinen gleichzeitig über das Virtual Center zu installieren beziehungsweise zu aktualisieren. Diese Installation kann unbeaufsichtigt erfolgen, erfordert also keinen Eingriff durch den Administrator. Bei der Nutzung von Wechselmedien (Diskette, CD) im Gastsystem ist es nun außerdem möglich, physikalische Laufwerke des administrierenden Systems der virtuellen Maschine über das Netzwerk zuzuordnen.

Snapshot für virtuelle Maschinen

Darüber hinaus ist eine Funktion aus der VMware-Workstation in die Virtual Infrastructure 3 gewandert: der "Snapshotmanager". Damit lassen sich mehrere Snapshots (definierte Zustände eines Systems zu einem bestimmten Zeitpunkt) einer virtuellen Maschine anlegen und bei Bedarf auf einen dieser Stände wechseln.

Ein Blick auf die Neuerungen des ESX Servers beginnt bei der veränderten Service Console. Basierte diese in vergangenen Versionen auf Red Hat 7.2 beziehungsweise auf Red Hat AS 2 und war zwischen Hardware und VMkernel (Hypervisor) ansässig, so ist sie nun komplett virtualisiert und benutzt Red Hat ES 4. Dieser Schritt ist sehr wichtig, da die Service Console für Sicherungen und Skripte genutzt wurde sowie die API und Dienste zur Kommunikation zwischen Applikationen (zum Beispiel Virtual Center) und VMkernel zur Verfügung stellte. Dadurch wurde sie zum Nadelöhr. Mit VI 3 ist dieser Aspekt erheblich entschärft, da die Service Console nun die erste virtuelle Maschine eines jeden ESX Servers ist und die virtuelle Infrastruktur nutzt. Allerdings hat dies die Einschränkung zur Folge, dass nur noch von VMware unterstützte Hardware nutzbar ist, was in früheren Versionen für die Service Console umgangen werden konnte.

Veränderte Service Console

Die Service Console bleibt weiterhin in einer Sonderstellung und ist höher berechtigt als andere virtuelle Maschinen, so dass ein Zugriff durch die Service Console auf die physikalische Hardware und das Dateisystem VMFS möglich ist. Viele der alten Kommandozeilenprogramme funktionieren in der neuen Service Console nicht mehr, und einige neue Kommandos sind hinzugekommen, so etwa für den Bereich Sicherheit und die Einrichtung einer Firewall.

Auch das auf Version 3 angehobene Dateisystem kommt mit Neuerungen und bietet jetzt die Möglichkeit einer Verzeichnisebene. Was auf den ersten Blick wenig spektakulär klingt, ist ein Meilenstein in Sachen Disaster Recovery virtueller Maschinen. Bisher ließen sich nur die Festplattendateien der virtuellen Maschinen in einer VMFS-Partition ablegen, die Konfigurationsdateien (.vmx) sowie virtuelles Bios (nvram) und Protokolldateien der virtuellen Maschinen waren bis dato dem Dateisystem der Service Console vorbehalten. Der Administrator war deshalb gezwungen, neben den Festplattendateien auch die Konfigurationsdateien zu sichern. Kam es zu einem Ausfall des ESX Servers, musste eine Wiederherstellung der Konfigurationsdateien stattfinden oder deren Neuanlage, bevor die virtuelle Maschine nutzbar war. Mit VI 3 können alle für die virtuelle Maschine notwendigen Dateien innerhalb eines Verzeichnisses zusammen abgelegt werden. Fällt nun ein ESX Server aus, kann ein anderer, der Zugriff auf die gleiche VMFS-Partition hat, die virtuellen Maschinen innerhalb kürzester Zeit wieder betreiben.

Ablage von VMFS-Partitionen

VMFS-Partitionen konnten bisher nur im SAN abgelegt werden, was den Einsatz des ESX Servers verteuerte. VI 3 ermöglicht nun auch die Nutzung von Logical Unit Numbers (LUNs) über das iSCSI-Protokoll, welches sogar als Softwareinitiator im VMkernel von ESX 3 vorhanden ist. Natürlich empfiehlt es sich, in Produktivumgebungen mit Hardwarelösungen, also iSCSI-gestützten Host-Bus-Adaptern (HBAs), zu arbeiten. Eine weitere Neuerung ist die Nutzung von NAS-Freigaben zur Ablage von virtuellen Maschinen. Dabei kommt das NFS-3-Protokoll zum Einsatz, und die Freigabe lässt sich wie eine VMFS-Partition verwenden, wird allerdings nicht wie diese formatiert. Dabei gilt auch die Beschränkung auf eine Verzeichnisebene. Ferner wurde die Leistungsfähigkeit des VMFS-Dateisystems verbessert sowie der Umgang mit SCSI-Reservations entschärft, der oft zu Leistungsengpässen führte.

Die Verwaltungswerkzeuge der virtuellen Infrastruktur haben sich ebenfalls verändert. Konnte man bei der ESX-Version 2 mittels Browser die Web-Administrationsoberfläche zur Verwaltung nutzen, musste diese nun dem Windows-basierenden Virtual Infrastructure Client weichen. Dieser wird sowohl zur Verwaltung des ESX Server 3 als auch des Virtual Center 2 genutzt. Die Vorteile eines einheitlichen Admin-Werkzeugs wie des VI-Clients liegen zwar auf der Hand, allerdings haben Linux-Anwender damit keine native Möglichkeit mehr, ihre ESX-Server zu organisieren. Lediglich die Administration virtueller Maschinen ist immer noch über eine Web-Oberfläche möglich.

Grafische Konfiguration

Die Konfigurationsmöglichkeiten des ESX Servers und der virtuellen Maschinen wurden ebenfalls deutlich ausgebaut, so dass viele der vormals nur über Kommandozeile zugänglichen Konfigurationsänderungen in die grafische Oberfläche übernommen wurden. Nachteil dabei ist, dass die grafische Oberfläche für Einsteiger schwieriger und unübersichtlicher geworden ist. Trotzdem war dieser Schritt notwendig und richtig, da so Konfigurationsfehler durch Falscheingaben eingeschränkt werden.

Nutzt man Virtual Center zur Verwaltung der ESX Server, ergeben sich ebenfalls eine Vielzahl von Neuerungen, die teilweise mit gesonderten Lizenzkosten verbunden sind. Dabei wird deutlich, dass VMware sein Virtual Center mittlerweile zur strategischen Verwaltungsplattform für virtuelle Infrastrukturen beziehungsweise VI 3 gekürt hat.

Beginnend mit den möglichen hierarchischen Strukturen des Virtual Center fällt auf, dass aus den früheren Farmen so genannte Datacenter geworden sind. Die bekannten Beschränkungen bezüglich der Migrationen bestehen jedoch nach wie vor. Weitere neue Elemente stellen die Resource- und Cluster-Gruppen dar. Innerhalb einer Resscourcengruppe können Leistungsgrenzen angegeben werden, die alle virtuellen Maschinen einer Gruppe gemeinsam nicht überschreiten dürfen, was zum Beispiel für Hosting-Provider interessant sein dürfte.

Die Cluster-Gruppe

Innerhalb von Cluster-Gruppen werden ESX Server mit ihren virtuellen Maschinen eingruppiert und lassen sich mit verschiedenen Optionen belegen. Benannt sind diese Optionen mit HA (High Availability) und DRS (Dynamic Ressource Scheduling), welche zur Ausfallsicherheit und zur Lastverteilung dienen. Beide können auch zusammen in einer Cluster-Gruppe angewendet werden.

HA bedeutet, dass beim Ausfall eines ESX Servers alle darauf befindlichen virtuellen Maschinen anhand eines Regelwerks auf anderen aktiven ESX Servern neu gestartet werden. Bei DRS kommt die VMotion-Technik des Herstellers zum Einsatz, mit der sich anhand von Ressourcenregeln virtuelle Maschinen automatisch, halbautomatisch oder manuell zwischen ESX Servern verschieben lassen. Es handelt sich also um Load Balancing in der virtuellen Welt! Um auch in großen Umgebungen die Übersicht zu wahren, wurde die aus anderen Produkten bekannte Funktion Maps eingeführt. Innerhalb dieser Ansicht kann die komplette Struktur mit Host-Systemen, Netzen, Massenspeichern und natürlich virtuellen Maschinen grafisch in einer Karte angezeigt werden.

Bisher bestand bei der Nutzung von VMotion die Einschränkung, dass nur zwischen ESX-Systemen migriert werden konnte, wenn Family und Stepping der eingesetzten Prozessoren gleich waren. Mit VI 3 lassen sich nun bestimmte CPU-Register ausblenden, wodurch eine höhere Kompatibilität zwischen den CPU-Familien geschaffen werden soll. Wie diese Funktion genau zu nutzen ist, wird die Zukunft zeigen. VMware will nach und nach in der Knowledge Base Muster für die verschiedenen Einstellungen veröffentlichen, um manchen Problemfall zu lösen.

Feingliedriges Rollenkonzept

In Bezug auf Sicherheit unterteilt Virtual Center die Berechtigungen nicht mehr nur in vier grobe Rollen, sondern erlaubt eine feinstufige Gliederung nach Dutzenden von Berechtigungen, um eine Eingrenzung der IT-Mitarbeiter genau nach ihren Aufgaben zu erstellen.

Auch Entwickler profitieren von der neuen Version. Es wurde eine einheitliche Programmierschnittstelle (API) geschaffen, auf die alle Programme zugreifen. Diese besitzt den vollen Funktionsumfang.

Schließlich noch einige Worte zum Consolidated Backup: Diese Form der Sicherung wird mit VI 3 in der ersten Version eingeführt und verhält sich dementsprechend noch ein wenig anwenderunfreundlich. Consolidated Backup verfolgt allerdings ein heiß ersehntes Ziel, das die Sicherung der virtuellen Maschinen über das SAN, also unabhängig vom normalen Netzwerk beinhaltet. Dazu wird ein auf Windows 2003 basierender VCB-Proxy-Server in das SAN integriert, der den gleichen LUNs-Zugriff wie die ESX Server erhält.

Nutzung von Drittprodukten

Im Zusammenspiel von ESX, VMware-Tools und VCB-Proxy ist es dann möglich, über Drittherstellerprodukte wie IBM Tivoli oder Veritas BackupExec die virtuellen Windows-Maschinen datei- oder imagebasierend (Linux-Maschinen nur imagebasierend) zu sichern. Die größten Probleme entstehen allerdings bei der Rücksicherung, die entweder manuell oder mittels Sicherungsagent in der virtuellen Maschine erfolgen muss. Hier bleibt abzuwarten, wie die Hersteller von Sicherungs- und Disaster-Recovery-Software reagieren, damit die Technik für den Endanwender einfach und schnell nutzbar ist.

Es liegt nahe, dass aufgrund der vielen Neuerungen nur eine bedingte Kompatibilität zwischen den alten ESX- und Virtual-Center-Versionen gegeben ist. Eine Migration wird nicht ohne den Ausfall virtueller Maschinen möglich sein. Genaue Anleitungen mit Migrationspfaden finden sich im Handbuch und VMware-Forum. Außerdem haben inzwischen auch Dritthersteller dieses Problem erkannt und arbeiten mit Hochdruck an Lösungen. (ue)