Die zehn Top-Features von vSphere 5.5

Mit dem Schritt von Version 5.1 auf 5.5 hat VMware bei seiner Virtualisierungs-Plattform vSphere sozusagen eine „neue Evolutionsstufe“ hinzugefügt. Revolutionäre Verbesserungen bleiben aus, es stand vor allem eine höhere Skalierbarkeit auf der Agenda. Michael Otey spricht die wesentlichen zehn Punkte bei vSphere 5.5 an.

Zudem setzen Unternehmen mehr auf das Verschieben von VMs über Weitverkehrsstrecken. Hier bietet sich die Beschleunigung über Systeme wie BIG-IP an, damit vMotion in einem sinnvollen Ansatz ausgeführt werden kann.

Der Umstieg von Version 5.1 auf 5.5 bei vSphere verdeutlicht es: Keine revolutionären Entwicklungen sind dabei zu verzeichnen – es geht eher um evolutionäre Optimierungen. Dabei hat sich der Virtualisierungs-Marktführer auf eine Erweiterung der Skalierbarkeit konzentriert – auch um in einigen Bereichen zur aktuellen Version des Hyper-V aufzuschließen.

Denn Microsoft war mit seinem Hypervisor in einigen Bereichen an vSphere vorbeigezogen. Bei der Vorstellung von vSphere 5.5 hat Pat Gelsinger, der Chef bei VMware, dieses Release als die „2X“-Version bezeichnet. Der Grund: die Skalierbarkeit wurde in vielen Bereichen verdoppelt.

Bei der Angabe des maximalen Arbeitsspeichers und der maximalen Anzahl von vCPUs (virtuelle CPUs) pro Virtualisierungs-Host hat vSphere 5.5 nun doppelt so viel aufzuweisen als vSphere 5.1. Konkret bedeutet das: 4 anstelle von 2 TByte maximaler Arbeitsspeicher (RAM) im Host und nun 320 logische CPUs pro Host (anstelle der vorherigen 160). Damit zieht vSphere 5.5 bei diesen Parametern mit dem Hyper-V gleich.

Bei den Maximalwerten für die virtuellen Maschinen sind ebenfalls Verbesserungen zu vermelden: Auf einem Host können nun insgesamt 4096 virtuelle CPUs (also virtuelle Prozessoren in den jeweiligen virtuellen Maschinen) definiert sein – bei der Version 5.1 waren es nur deren 2048.

Im Bereich der virtualisierten Arbeitslasten zeigt sich eines sehr häufig: Der Arbeitsspeicher ist die wichtigste Ressource. Die meisten Server-Architekturen verfügen über eine NUMA-Architektur (Non-Uniform Memory Access). Dieser Ansatz ist entwickelt, um die Performance zu verbessern und weist dazu jedem Prozessor bestimmte Speicherbereiche zu. Ein jeder Speicherblock, der einem Prozessor zugeordnet ist, wird als NUMA-Knoten bezeichnet. Eine CPU kann auf den Speicherbereich im lokalen NUMA-Knoten weitaus schneller zugreifen als auf einen im nicht-lokalen NUMA-Knoten. Bei vSphere 5.5 wird die Anzahl der unterstützten NUMA-Knoten von vorher 8 auf nun 16 NUMA-Knoten erhöht.

Um die Stromaufnahme der Prozessoren zu reduzieren, wenn wenig Arbeit zu verrichten ist, gibt es „Sparbetriebsmodi“ bei den physischen Prozessoren. Bereits bei vSphere 5.1 wurde der P-State unterstützt, dabei läuft der Prozessor mit einer geringeren Taktfrequenz und geringeren Spannungseinstellungen. Zudem kann der Prozessor bei höheren Anforderungen seitens der Arbeitslast dann diese Einstellungen wieder erhöhen. Bei vSphere 5.5 ist nun sogar die Unterstützung des C-State gegeben. Dabei wird noch mehr Energie gespart, wenn die CPU inaktiv ist.

Erweiterungen in Bezug auf die Skalierbarkeit sind bei vSphere 5.5 auch für den kostenlosen vSphere-Hypervisor zu verzeichnen. Vor allem kleinere und mittlere Unternehmen werden sich freuen, dass es nun keine zusätzlichen Begrenzungen beim physischen Arbeitsspeicher mehr gibt: Die Vorgängerversion zu 5.5 war noch auf 32 GByte Arbeitsspeicher (RAM) auf dem Virtualisierungs-Host begrenzt. Diese Limitierung fällt nun weg.

Die VDMK (Virtual Machine Disk) bekam bei vSphere 5.5 mehr Speicherkapazität spendiert: Eine VDMK-Datei darf nun bis zu 62 TByte groß sein (beim Dateisystem NFS und bei VMFS-5). Früher betrug die maximale Kapazität einer VMDK-Datei 2 TByte – hier wurde also ein großer Schritt nach vorne vollzogen.

Der Einsatz von Hot-pluggable PCIe SSDs erweist sich heutzutage als eine massive Performance-Verbesserung – zumal die Preise für diese Art der Massenspeicher sich deutlich reduzieren. Die früheren Versionen von vSphere haben bereits hot-pluggable S-ATA- und SAS-Laufwerke unterstützt, Doch mit vSphere 5.5 kommt nun auch die Unters5ützung von Hot-pluggable SSDs (über das PCIe-Interface) ins Spiel.

Der Einsatz von 40-Gigabit-Ethernet-Netzwerkadaptern legt den Grundstein, um auch beim Durchsatz über das Netwzerk Verbesserungen zu erzielen. Aber auch 16-GBIt/s-Fibre-Channel (End-to-End) sind bei vSphere 5.5 möglich. Das war bei der Vorgängerversion noch anders: Dort konnte man nur die Verbindung vom Host bis zum Switch mit 16 GBit/s abwickeln, doch die Verbindung vom Switch zum Array war auf 8 GBit/s beschränkt. Doch das ist bei vSphere 5.5 nun passe‘: Es wird die 16 GBit/s E2E-Fibre Channel Verbindung unterstützt.

Bei vSphere 5.1 kam erstmals die Unterstützung für Hardware-beschleunigtes 3D-Grafik ins Spiel. Dazu wurde eine virtuelle GPU (vGPU) in einer virtuellen Maschine (VM) eingestezt. Doch diese Unterstützung funktionierte nur für die NVIDIA-Grafikprozessoren. Bei vSphere 5.5 ist nun auch noch die Unterstützung von GPUs aus dem Hause AMD und Intel dazu gekommen. Auch beim Verschieben von VMs auf Systeme, in denen andere GPU-Hersteller ihre Grafikprozessoren zum Einsatz bringen, mit vMotion ist nun machbar. Hier ist allerdings eine Einschränkung zu vermelden: Ist eine vGPU so konfiguriert, dass sie das Hardware-Rendering nutzt, muss die GPU auch auf dem Ziel-Hostsystem (bei einem Verschieben) existieren. Ansonsten wird die vMotion-Operation fehlschlagen.

Zu den wichtigsten Verbesserungen bei vSphere 5.5 gehört das App-HA-Feature. Es erweitert die Betriebsüberwachungsfunktionen von VMware und bezieht dabei einige typische unternehmenskritische Anwendungen mit ein. So ist der neue App-HA in der Lage, die Softwaremodule SQL Server 2012, 2008 R2, 2008, und 2005, ebenso die Internet-Informationsdienste (IIS 8.0, 7.0, und 6.0), sowie die Tomcat-Middleware (Version 7.0 und 6.0) und natürlich auch den Apache HTTP Server (in den Versionen 2.2, 2.0 und 1.3) zu überwachen.

Unterschied zwischen vSphere ESX und vSphere ESXi

vSphere ESX und vSphere ESXi sind Bare-Metal-Hypervisor-Architekturen, die direkt auf der Serverhardware installiert werden. Die Unterschiede liegen in den Architekturkomponenten und im Betriebsmanagement des vSphere-Hosts.

Obwohl bei keiner der Hypervisor-Architekturen das Ressourcenmanagement über ein Betriebssystem erfolgt, nutzt die vSphere ESX-Architektur ein Linux-Betriebssystem – Konsolenbetriebssystem (COS) oder Servicekonsole genannt – zur Ausführung von zwei Managementfunktionen: Dazu gehören die Skriptausführung und die Installation von Drittanbieter-Agent-Software für Hardwareüberwachung, Backups und Systemmanagement.

Diese Servicekonsole wurde aus der vSphere ESXi-Architektur entfernt, sodass der resultierende Hypervisor wesentlich kleiner ist. Mit dem Wegfall der Servicekonsole folgt ESXi dem Trend, Managementfunktionen von der lokalen Befehlszeilenschnittstelle auf Remote-Management-Tools zu migrieren.

Die kleinere Code-Basis von vSphere ESXi bietet weniger „Angriffsfläche“, sodass weniger Code gepatcht werden muss. Dadurch werden Zuverlässigkeit und Sicherheit erhöht. Die Funktionalität der Servicekonsole wird durch die Remote-Befehlszeilenschnittstellen und die Einhaltung von Standards für das Systemmanagement ersetzt

Zusammenspiel von F5-Technologien mit vSphere

Stand heute ist vSphere die führende Technologie im Bereich der Virtualisierung von Rechenzentren und auch beim Aufbau von Cloud-basierten Infrastrukturen. Dazu nutzen Infrastrukturen, die mit vSphere aufgebaut sind, die Ressourcen besser aus, sie verbessern das Antwortverhalten der Infrastruktur und reduzieren dabei auch noch die Kosten für den Betrieb. Um diese Vorteile alle auszunutzen, bedarf es aber auch eines Application Delivery Networks (ADN), das allerdings flexibel genug ist, um die vSphere-Umgebung auch zu unterstützen.

Aufgrund der engen Partnerschaft von VMware und F5 Networks ist eine enge Integration der Technologien beider Unternehmen gelungen. Damit sollen die Anwender auch den größtmöglichen Nutzen aus dieser kombinierten Infrastruktur ziehen können. Ein wichtiger Aspekt ist dabei das Thema vMotion über WAN-Strecken.

vMotion über Weitverkehrsverbindungen

Das Verschieben von laufenden virtuellen Maschinen (VMs) innerhalb eines vSphere-Verbundes in einem lokalen Netzwerk gehört zu den grundlegenden Vorteilen von Servervirtualisierungs-Lösungen. Mit geeigneten Netzwerkverbindungen über mehrere 1-GBit/s-Ethernet- oder gar 10-GBit/s-Ethernet-Strecken, lassen sich alle Probleme gut meistern.

Einzig die „Prozessor-Kompatibilität“ erweist sich in der Praxis als eine Herausforderung, etwa wenn das Zielsystem mit AMD-Prozessoren arbeitet, das Ausgangssystem dagegen mit Intel-Prozessoren ausgestattet war.
Soll das Verschieben von VMs im laufenden Betrieb – also vMotion – über Weitverkehrsstrecken erfolgen, wird die Aufgabe schon kniffliger. Denn es kommen die Signallaufzeiten zwischen den beiden Standorten sowie unter Umständen auch noch mehr „Verzögerungsstrecken“ mit ins Spiel. Daher sollte man bei einer derartigen Aufgabenstellung auf Beschleuniger für die WAN-Verbindung setze, wie sie zum Beispiel F5 Networks mit seinen BIG-IP-Systemen anbietet.

Speziell für das Zusammenspiel mit vMotion von VMware gibt es beim BIG-IP-System das Softwaremodul „Application Acceleration Manager“ (AAM). In der Version 11.0 von BIG-IP sind dann noch die iApps Application Templates dazu gekommen, mit denen sich ein (oder auch mehrere) BIG-IP-System(e) schnell dazu konfigurieren lassen, um zwischen BIG-IP-Systemen vMotion ausführen zu können. Das passende Template dazu ist das „vMotion iApp template“.

In Bild 4 ist eine typisches Szenario zu sehen, das bei vMotion über WAN-Strecken zum Einsatz kommt. Dabei wird der Datenverkehr zum einen optimiert und zum anderen auch gesichert, da ein eigener sicherer Tunnel im Rahmen des iSession-Profils aufgebaut wird. Dazu sind allerdings zwei BIG-IP-Systeme – eines an einem jeden Ende der WAN-Strecke – notwendig. Zudem muss auf jedem der beiden Systeme das iApp Template laufen.

Rainer Huttenloher