VMware hat am 13. Juli ein neues Minor Release seiner Software vSphere 4 veröffentlicht, und Ralph Göpel, der Autor von Praxishandbuch VMware vSphere 4 zeigt hier einmal , was sich getan hat. Im Anschluss lesen Sie noch Einiges über das Upgrade von einer älteren Version.

Zunächst einmal: Die Namensgebung der neuen Version von VMware vSphere4, also 4.1, ist gerechtfertigt und richtig. Eine Versionsnummer mit einer „5“ wie bei Virtual Infrastructure 3.5 wäre zuviel gewesen, da sich die Änderungen und Neuheiten hier eher im Hintergrund abspielen. Hier als Erstes die von VMware selbst publizierten Neuheiten, ergänzt durch eigene Erfahrungen:

• Der vCenter Server kann nur noch auf 64-Bit-Plattformen installiert werden. Haben Sie noch eine Datenbank eines älteren vCenter Servers oder Virtual Center Servers auf 32-Bit-Basis, kann diese auf dem bisherigen PC beibehalten und genutzt werden.
• vSphere 4.1 ist das letzte Release, das den „vollständigen“ ESX-Server unterstützt. Demnächst wird es nur noch den ESXi Server (embedded oder installable) geben. Sie sollten also bei einem Upgrade auf diese Version bereits überlegen, ob Sie nicht in diesem Schritt sich schon mal an den ESXi gewöhnen wollen. Die Nachteile, die ich im aktuellen Buch „Praxiswissen VMware vSphere4“ beschreibe, sind zum Teil bei der neuen Version obsolet geworden.
• Für ESXi wird die Skript-gesteuerte Installation von CD auf lokale und entfernte Platten und die Installation über das Netzwerk (PXE) sowie die Installation auf einen USB-Stick (nicht Skript-gesteuert) unterstützt. Das war bisher nicht möglich.
• Der vSphere Client kann nun von der Webseite von VMware als ausführbare Datei (267 MByte) heruntergeladen werden – nicht mehr von einem ESX oder ESXi Server. Im vCenter Server ist er aber weiterhin enthalten.
• Der neue ESXi Server kann mittlerweile aus dem SAN gebootet werden. Das funktioniert über iSCSI, FCoE (Fibre Channel over Ethernet) und Fibre Channel.
• Es wurden neue erweiterte Performancegraphen und Ansichten für die Storages hinzugefügt. Sogar die Statistikdaten von NFS können jetzt über esxtop auf der Kommandozeile und der graphischen Oberfläche protokolliert werden.
• Jeder VM kann man Quality of Service über Anteile (Shares) mittels „Storage I/O Control“ zuweisen, unabhängig davon, auf welchem Host sie läuft. Selbst beim vMotion bleiben diese Anteile erhalten.
• 10-GBit-Netzwerkkarten werden jetzt auch für iSCSI unterstützt (Broadcom 57711).
• Die Übertragungsgeschwindigkeit von NFS wurde deutlich verbessert und die Belastung für die CPU des Hosts reduziert.
• Für den distributed vSwitch wurden Bandbreitenbeschränkungen für einzelne Ports und ein Load-Balancing mehrerer Adapter eingeführt.
• Für IPv6 werden nun die manuelle Konfiguration und mehr Sicherheit über IPsec möglich.
• Virtuelle Netzwerkkarten (vNICs) unterstützen nun auch Jumbo-Frames.
• VMware HA ermöglicht jetzt ebenfalls Microsoft Cluster. Diese können aber nicht mehr für den vCenter Server genutzt werden. Ein vCenter Server kann also nur noch mit dem Zusatzprodukt VMware Heartbeat und HA geclustert werden.
• Für HA gibt es über den vSphere Client ein neues Dashboard, über das mehr Informationen über den Zustand der Komponente aufgerufen werden können.
• Fault Tolerance wird nun auch mit allen Funktionen im DRS-Cluster unterstützt, und VMs können auch einen vmxnet3-Adapter haben.
• VMware Data Recovery Appliances können nun mehrfach installiert und eingesetzt werden.
• Das Command Line Interface (vCLI) wurde für SCSI, VAAI, Netzwerk und die Kontrolle über VMs erweitert. Hierüber kann z.B. eine nicht mehr reagierende VM auch hart beendet werden, was vorher nur über ssh oder lokal möglich war.
• Der ESXi Server kann so abgesichert werden, dass nur noch der Zugriff über einen vCenter Server oder den direkten root-Account möglich ist. Ein angelegter User kann dann nicht mehr auf den ESXi Server zugreifen.
• Der VM können serielle Schnittstellen über das Netzwerk zur Verfügung gestellt werden, z.B. Serial Port Concentrators.
• Ausgeschaltete Hyper-V-Maschinen von Microsoft können mittlerweile über den Converter importiert werden. Bisher musste man diese Maschinen im laufenden Betrieb über das Netzwerk migrieren.
• Die Host-Profile wurden erweitert: Nun können Administrator-Passwortänderungen verteilt werden, und die Unterstützung von Nexus 1000V Switches von Cisco sowie PCI-Gerätekonfigurationen wurden implementiert.
• vCenter Orchestrator wird nun auch auf 64-Bit-Systemen unterstützt und für eine bessere Performance sogar empfohlen. Da dieses bisher nicht möglich war, kommt man ggf. um eine Neuinstallation des vCenter Servers nicht herum.
• Der vCenter Update Manager kann Berichte über von VMware zurückgezogene ESX-Patches verschicken und ihre Installation verhindern. Bereits verteilte zurückgezogene Patches können erkannt werden.
• Es gibt jetzt einen License Reporting Manager, der alle Lizenzen überprüft und auch eine Historie der Nutzung anzeigt.
• Über den vSphere Client können vier verschiedene Power-Modi für den Host eingestellt und eine Historie darüber angezeigt werden.
• Der vCenter Server kann nun dreimal mehr VMs und Hosts unterstützen.
• Die Performance und Skalierbarkeit wurde allgemein für folgende Komponenten erhöht:
  • mehr gleichzeitige Zugriffe über vSphere Clients
  • mehr VMs pro Cluster
  • mehr und deutlich schnellere vMotion Vorgänge (in eigenen Tests bis zu drei mal schneller)
  • mehr distributed vSwitches
  • neue Optimierungen für AMD-V und Intel VT-x Architekturen
  • interessante neue Optimierungen des Arbeitsspeichers mit RAM Komprimierung
  • deutliche Optimierungen für NFS
• Der Overhead des Arbeitsspeichers für VMs wurde reduziert. In Verbindung mit AMD RVI oder Intel EPT wird dies deutlich sichtbar.
• In DRS gibt es neue einstellbare Regeln, die das Verschieben von VMs auf bestimmte Hosts arrangieren.
• Für VMs kann auf Platten ausgelagerter Arbeitsspeicher komprimiert werden, was die Performance erhöht.
• vMotion wurde in der Geschwindigkeit um das Achtfache verbessert, und es können vier bis acht Vorgänge gleichzeitig ausgeführt werden.
• ESX und ESXi haben Zugriff auf Active Directory und können dessen User und Gruppen authentifizieren. Hier kann in der Konfiguration des Hosts die Domäne dafür eingestellt werden.
• USB-Geräte am ESX-Host können VMs zugeordnet werden, auch wenn sie per vMotion verschoben werden.
• Zusatzprodukte im ESX Server wie EMC PowerPath Module können über den Update-Manager aktualisiert werden.
• VMs können mehrere Kerne eines physischen Prozessors nutzen und diese als eine CPU ansprechen.

Ausblick und Überlegung: VMware hat im Zusammenhang mit diesem Upgrade angekündigt, einige ältere Funktionen im nächsten Release nicht mehr zu unterstützen. Vielleicht überlegen Sie sich ja schon bei dieser Aktualisierung, gleich die nächsten Schritte vorweg zu nehmen:

• Im nächsten Release soll kein VMFS2 mehr unterstützt werden. Dann spätestens müssen Sie ihre „alten“ Dateisysteme auf den vorhandenen Volumes updaten.
• Der vCenter Server 4.1 unterstützt keine ESX Hosts der Version 2.x mehr.
• Den ESX Host wird es in der kommenden Version nicht mehr geben – nur noch den ESXi (embedded oder installable), wie bereits oben schon erwähnt.

Upgrade von vSphere 4.0 auf 4.1 Der Prozess des Upgrades von einer älteren auf eine neuere Version kann für keine der Komponenten (Client, Server und Host) rückgängig gemacht werden. Eine Datensicherung vor dem Aufspielen der jeweiligen neuen Version ist also angebracht und notwendig. Erkundigen Sie sich auf jeden Fall auf der Internetseite von VMware nach den Hardwarevoraussetzungen, die Ihre Systeme erfüllen müssen – natürlich vor dem Upgradeversuch. So brauchen Sie beispielsweise für den vCenter Server mindestens zwei 64-Bit-CPUs oder eine 64-Bit-CPU mit zwei Kernen (Dualcore) und jeweils mindestens 2 GHz Taktfrequenz. Der erforderliche Arbeitsspeicher des Systems wurde auf 3 GByte erhöht. Wenn Sie auf diesem Server auch den „VirtualCenter Management Webservices“ nutzen, müssen Sie sogar noch mehr Arbeitsspeicher zur Verfügung stellen. Für diese Komponente spricht VMware von 512 MB bis zu 4,4 GByte. Beachten Sie auch, dass für große Umgebungen deutlich mehr Ressourcen benötigt werden. Bei sehr großen Implementierungen brauchen Sie sogar 8 CPU-Kerne und 16 GByte RAM. Über die Reihenfolge beim Upgrade von 3.x auf 4.0 des Servers, der ESX Hosts und des Clients habe ich im oben erwähnten Buch schon ausführlich geschrieben. Bei der Aktualisierung auf die Version 4.1 empfehle ich wieder – entgegengesetzt zu VMware – die gleiche Reihenfolge. Laden Sie sich die ausführbare Datei des vSphere Clients von der Internetseite des Herstellers herunter und führen Sie diese aus. Mit diesem Client können Sie auch auf die alten Server und Hosts zugreifen. Nehmen Sie sich anschließend den Virtual Center Server oder vCenter Server vor und aktualisieren diesen. Sie können auch eine Neuinstallation durchführen und ggf. die alte Datenbank (auch Microsoft SQL 2005 Express) dafür nutzen. Wollen Sie vom Virtual Center Server 2.5 auf die neue Version umstellen, müssen Sie eine Neuinstallation durchführen und die Datenbank anschließend migrieren. Haben Sie den Server auf einem 32-Bit Betriebssystem aufgesetzt, kommen Sie um eine Neuinstallation nicht herum. Beachten Sie dabei unbedingt die Hinweise, die ich oben erwähnt habe. Vergessen Sie nicht, die ggf. zusätzlich installierten Komponenten wie z. B. vCenter Update Manager, vCenter Converter und vCenter Guided Consolidation ebenfalls auf den neuesten Stand zu bringen. Zuletzt können Sie ihre ESX- oder ESXi-Hosts auf den neusten Stand bringen. Das funktioniert meist problemlos mit dem Update-Manager (Upgrade-Baseline), dem vSphere CLI (vihostupdate) oder dem Befehl esxupdate auf der direkten Kommandozeile, wenn Sie mindestens die Version 3.5 einsetzen. Wollen Sie vom ESX auf den ESXi wechseln, müssen Sie über eine Neuinstallation aller Hosts nachdenken, da eine Änderung von ESX auf ESXi oder umgekehrt hier nicht unterstützt wird. Über das vMotion und Storage vMotion des Virtual Center Servers oder vCenter Servers sollte dies kein Problem sein. Haben Sie kein vMotion, überlegen Sie sich doch, eine 60-Tage-Version des vCenter Servers für Ihren Migrationsprozess einzusetzen. Das kann auch eine virtuelle Maschine sein, die Sie hinterher wieder löschen können. Nach der Installation können Sie sich mit den neuen Funktionen der Umgebung vertraut machen. Überprüfen Sie auch die Benutzerrechte, da diese auf die neuen Funktionen nicht automatisch vererbt werden. Aktualisierte Hosts müssen nach dem Upgrade wieder mit dem vCenter Server verbunden werden, neu aufgesetzte müssen aus der Bestandsliste entfernt und als neue Hosts hinzugefügt werden. Beachten Sie auch die erneute Zuweisung der Lizenzen nach dem Upgradeprozess. Überprüfen Sie unbedingt die Zugriffe des Hosts auf Netzwerkswitche und zentrale Speichergeräte. Diese müssen üblicherweise neu zugeordnet werden. Auch jegliche Software von Drittanbietern ist erst mal deaktiviert. Diese müssen Sie bei Bedarf erneut installieren. Haben Sie alle ESX oder ESXi Hosts aktualisiert, sollten Sie als letzten Schritt die virtuellen Maschinen überprüfen. Ein Update der VMware Tools können Sie in der VM oder über den Update Manager durchführen. Seien Sie vorsichtig mit einem erzwungenen Neustart nach der Installation. Die Hardware Version 7 der VM ist bei vSphere 4.1 gleich geblieben. Haben Sie noch die ältere Version 4 im Einsatz, sehen Sie sich unbedingt die Empfehlungen in dem o.g. Buch an.

Abschließend betrachtet ist eine Migration von der alten Version 3.5 auf 4.1 sehr sinnvoll und von 4.0 auf 4.1 empfehlenswert. Die vielen neuen Funktionen und der gehörige Performancegewinn sollten genutzt werden. Überlegen Sie sich dabei, ob Sie nicht gleich von ESX auf ESXi umsteigen, denn im nächsten Release werden Sie sowieso dazu gezwungen.