Ausprobiert: VMware vSphere 5.0
VMware hat vSphere 5.0 veröffentlicht. Wir konnten im Vorfeld eine Betaversion ausprobieren. Bei der Beurteilung der neuen Version sollten IT-Manager vor allem folgende Funktionserweiterungen beachten, die neu dazugekommen sind: HA (High Availability), VMware DRS (Distributed Resource Scheduler), die neuen Netzwerk-Monitoring-Werkzeuge und die Umstellung auf den ESXi Hypervisor. Trotz Änderungen am Lizenz-Modell von VMware besteht eine Tatsache fort: Firmen zahlen einen hohen Preis für die Enterprise-Class-Komponenten in vSphere 5.0.
IT-Manager, die bereits vSphere 4.1 oder 4.0 einsetzen, werden sich jedoch schnell in die neue Version einarbeiten können. Erfahrene Benutzer werden merken, dass sich die nur verbesserten Funktionen nicht wesentlich von den früheren Versionen unterscheiden. Das gilt auch für die Verbesserungen beim CLI (Command-Line Interface) und der HA sowie VMwares-Implementierung von ESXi. Der ESX Server wird nicht mehr weiterentwickelt und bei vSphere 5.0 ist nur noch ESXi verfügbar.
Ein Bereich, der einige Planung erfordert, ist die Dimensionierung und Ausstattung des physikalischen Hosts. Das neue System ermöglicht die Erstellung von virtuellen Maschinen mit bis zu 1 TByte Speicher und bis zu 32 virtuellen CPUs. Es ist schwer zu sagen, wie diese riesigen Systeme funktionieren. Unsere Testszenarien auf mittel-bis langsamen iSCSI-Speichern verliefen gut.
So wurde getestet
Zum Test wurden vier Intel-basierte Server sowie Cisco 3560G-Switches und eine OpenFiler iSCSI NAS-SAN-Lösung eingesetzt. Dazu kam die Vorabversion von VMware vSphere 5.0. Die beiden HP-Server (DL360 G6 und DL380 G6) sind mit Intel Xeon-Prozessoren (Nehalem) ausgestattet. Die anderen Systeme – ein Lenovo RD210 und ein Acer AR380 F1 – sind mit modernen Intel-Prozessoren und mehr Arbeitsspeicher ausgerüstet (12 GByte und 24 GByte RAM).
Im ersten Testdurchlauf wurden die beiden HP-Systeme aktualisiert – von vSphere ESX 4.1 auf ESXi 5.0. Die Migration verlief problemlos.
Bei der Umstellung auf das VMFS (Virtual Machine File System) ist allerdings viel mehr Planung erforderlich. Das VMFS wird dabei von Version 3.0 auf 5.0 umgestellt. VMFS 5.0 verwendet nur 1 MByte große Blöcke. vSphere 5.0 kann jedoch nach wie vor beide Dateisysteme verwenden. Es würde weitere Tests und viel praktische Erfahrung erfordern, um hier die beste Vorgehensweise herauszubekommen und eine Empfehlung aussprechen zu können. Der Umstieg gelingt, aber er erfordert ein ausführliches Handbuchstudium und mehrere Einzelschritte.
Auch der Einsatz der neuesten Version des VMware vDS (vSphere Distributed Switch) wurde getestet. Dabei wurden alle bestehenden Netzwerkkonfigurationen von Grund auf neu erstellt.
Es ist möglich, von vNetwork Standard Switches zu einem vDS zu migrieren, doch auch hier ist viel Planung erforderlich. Ein vSphere Distributed Switch fasst einzelne vSphere-Hosts zusammen.
vDS wurde mit vSphere 4.0 eingeführt. Wer den vDS schon verwendet, kann die Aktualisierung relativ leicht vornehmen. Wer hingegen von Standard-Switches umstellt, hat einiges vor. Im Test wurden mehrere Migrationen durchgeführt, bei denen die VMs vorher herunter gefahren und dann einzeln nacheinander an den vDS angebunden wurden. Es gibt außerdem Hostprofile, mit deren Hilfe man physikalische Hosts auf das vDS überführen kann.
Zu den größten Veränderungen im vDS von vSphere 5.0 zählen neue Werkzeuge zur Fehleranalyse und -beseitigung. Mit dem neuen Netzwerk-Monitor kann der virtuelle Netzwerkverkehr analysiert werden, ohne ihn erst auf ein externes, physikalisches Netzwerk umzuleiten. Der neue Monitoring-Port ist eine signifikante Verbesserung des vDS.
Trotzdem ist es klar, dass die Netzwerkfunktionen in vSphere 5.0 nur die zweite Geige spielen und der Schwerpunkt bei der Erstellung und Verwaltung von VMs liegt. Um auf vDS umzustellen, sind unbedingt umfangreiche Netzwerkkenntnisse erforderlich.
Hohe Verfügbarkeit
Die Wartung von VMs wurde in vSphere 5.0 durch die neuen HA-Funktionen verbessert. Die primären und sekundäre Nodes sind verschwunden, stattdessen wurde ein Master-Slave-Konzept eingeführt, dass die Planung der Nodes überflüssig macht. Auch die Abhängigkeit vom DNS (Domain Name System) ist weggefallen. Ein Wizard-basiertes Interface erleichtert den HA-Betrieb.
Im Testcluster wurde mit Hilfe der HA-Funktion der Host-Status überwacht. Damit kann sich der Administrator zum Beispiel die Zahl der physischen Hostsysteme ansehen, die derzeit mit dem HA-Master verbunden sind. Auch die Menge der geschützten und offenen VAs wird angezeigt. Die HA-Einrichtung ließ sich in wenigen Minuten vornehmen. Beim Abschalten von verschiedenen Hosts funktionierte die Failover-Funktion innerhalb des Clusters wie erwartet.
Mehr Managementfunktionen
Zum ersten Mal hat VMware den DRS (Distributed Resource Scheduler) erweitert, um auch Storagefunktionen einzugliedern. Die Einrichtung des Storage-DRS war einfach. Im Laufe der Zeit fällte das Storage DRS Entscheidungen über den besten Host für bestimmte VMs und sorgte für einen ausgewogenen Zugriff der VMs auf die Storage-Ressourcen, wie es in den Service Levels der Policies spezifiziert wurde.
Zum ersten Mal kann der vCenter Server als virtuelle Maschine betrieben werden. Es gibt zwar kleine Unschönheiten (zum Beispiel muss der DNS über die Kommandozeile definiert werden und nicht über die Weboberfläche), aber ansonsten funktioniert der virtualisierte vCenter Server sehr gut.
vSphere 5.0 ist die erste Version, die nur den ESXi-Host-Hypervisor verwendet. VMware wurde von einigen Anwender gedrängt, ESXi anstelle von ESX zu verwenden, und das aus gutem Grund. ESXi benötigt nur ungefähr 100 MByte auf dem physischen Host. ESXi bietet außerdem ein grundlegendes Netzwerk-Konfigurations-Interface. In den meisten Fällen wird der IT-Manager jedoch das neue, überarbeitete CLI, Batch-Dateien und den vCenter verwenden, um mit physischen Hosts zu interagieren.