VMware hat auf der Explore 2022 (ehemals VMworld) das nächste Major Release von vSphere und vSAN vorgestellt. Zu den wichtigsten Neuerungen zählen Device Virtualization Extensions (DVX), die höhere Skalierbarkeit mit vHardware 20, Gerätegruppen, eine Bereitstellungsrichtlinie für vTPMs und vSphere Datasets.
In früheren Versionen von vSphere war die Mobilität von VMs, welche physische Hardware-Geräte mit Direktpfad-I/O nutzten, eingeschränkt. DVX führt ein neues API und ein Framework für Anbieter ein, das Hardware-gestützte virtuelle Geräte mit vMotion, DRS, HA oder Suspend and Resume kompatibel macht. DVX unterstützt auch Festplatten- und Speicher-Snapshots, sofern ein DVX-Treiber in ESXi und gleichzeitig auf VM-Ebene installiert wird.
Virtuelle Maschinen, die in Zukunft DirectPath I/O verwenden, profitieren somit von mehr Virtualisierungsfunktionen wie etwa vMotion, anstatt an den ursprünglichen Host gebunden zu bleiben. Diese Funktion setzt die neue virtuelle Hardware-Version 20 voraus.
vHardware 20 mit neuen Maximalwerten
Die virtuelle Hardware-Ebene 20 erhöht die Zahl der zulässigen DirectPath-I/O-Geräte von 16 auf 32. Erwartungsgemäß unterstützt die aktuelle Version auch die neuesten Intel- und AMD-CPUs und Gastbetriebssysteme. Die maximale Anzahl von VMs pro Cluster ist ebenfalls gestiegen, von 8000 auf 10.000. Zudem kann der Lifecycle Manager jetzt bis zu 1000 Hosts verwalten.
Mehr Power für AI und Machine Learning (ML)
Virtuelle Maschinen lassen sich zwar nur mit der gleichen Anzahl an vCPUs und vRAM bestücken wie bisher, verkraften jetzt aber mit 8 virtuellen GPUs doppelt so viele wie vSphere 7, weil VMware damit KI- und ML-Anwendungen beschleunigen will. Dazu hat VMware nach eigener Aussage mit NVIDIA zusammengearbeitet.
Plattform- oder MLOPs-Teams könnten damit beispielsweise Workload-Konstrukte wie VMs oder Container erstellen und dabei partielle GPU-Ressourcen nutzen. Am anderen Ende des Spektrums lassen sich mit Multi-GPU-Konfigurationen ML-Workloads effizient trainieren.
VMware bietet diese Technologien bekanntlich sowohl Host-lokal als auch remote im Rahmen von VMware Bitfusion an, das ein schnelles Anschließen sowie Trennen von Workloads und HardwareRessourcen ermöglicht.
Gerätegruppen
Früher musste der Administrator ein GPU-Gerät nach PCI-Standort angeben und daher stets nachverfolgen, welche ESXi-Hosts welche Geräte bereitstellen können und welche VMs welche Geräte benötigen. Dann musste er eine bestimmte PCI-Adresse auswählen, was die VM zum Beispiel bei vMotion einschränkte, weil sie nur auf diesem spezifischen Host ausgeführt werden konnte.
Mit Einführung von Hardware-Labels in vSphere 7 ermöglichte Dynamic DirectPath I/O (DDIO), die Art des Geräts anzugeben, das einer VM hinzugefügt werden soll. Das Problem mit DDPIO ist aber, dass es sich nur auf ein Gerät bezieht.
Mit Version 8 unterstützt vSphere aber das gesamte Spektrum an ML-Beschleunigern. Was also, wenn ein Data-Science-Team eine Multi-GPU-Konfiguration für verteiltes Training bzw. Deep Learning benötigt? Die Arbeitslastverteilung erfolgt zwischen GPUs innerhalb eines ESXi-Hosts oder über mehrere ESXi-Hosts hinweg. Hier kommen die neuen Gerätegruppen ins Spiel, die über eine Hochgeschwindigkeitsverbindung verbunden sind oder sich auf demselben PCI-Switch befinden. Diese Gruppen werden dann ESXi präsentiert und automatisch von vCenter erkannt, wobei jede Gruppe als Einheit erscheint und nicht als einzelne Geräte.
So kann der Admin nun NICs und GPUs kombinieren oder einen gemeinsamen PCIe-Switch sowie eine direkte Verbindung nutzen und als eine Einheit an VMs anhängen. vSphere HA und DRS erkennen Gerätegruppen, womit sichergestellt ist, dass VMs stets auf Hosts platziert werden, welche die benötigten Gerätegruppen bereitstellen können.
Arbeitslasten, die auf GPUs über mehrere ESXi-Hosts verteilt ausgeführt werden, brauchen allerdings eine möglichst geringe Latenz. Dabei erhält die Verbindung zwischen den ESXi-Hosts die meiste Aufmerksamkeit, aber auch der Pfad von der GPU zur externen Verbindung ist von entscheidender Bedeutung.
Um die Latenz zu minimieren, muss vSphere die NUMA-Lokalität sowohl der GPU als auch der NICs berücksichtigen. Moderne CPUs haben PCI-Controller eingebaut, so dass NUMA-PCI-Lokalität gegeben ist. Um eine konsistente Leistung bereitzustellen, muss der Admin also Geräte auswählen, die mit demselben PCI-Controller oder PCI-Switch (in großen Systemen verfügbar) verbunden sind.
So ermöglicht eine Hochgeschwindigskeitsverbindung zwischen GPU-Beschleunigern immer eine stabile, konsistent hohe Bandbreite und stellt die maximale Leistung der verfügbaren lokalen Hardware sicher. NVIDIA beispielsweise bietet mit NVLINK eine direkte GPU-zu-GPU-Verbindung an. Eine nVIDIA A30-Karte verfügt über einen Link pro Karte. Eine A100 ist mit drei Verbindungen ausgestattet und erreicht eine GPU-zu-GPU-Bandbreite von 150 GB/s, d. h. jeder Link stellt theoretisch 50 GB/s zur Verfügung.
Vereinfachte virtuelle NUMA-Konfiguration
Die virtuelle NUMA-Topologie wird in vSphere 8 auch im vSphere Client verfügbar gemacht, während man bisher dies über die CLI erledigen musste. Voraussetzung dafür ist ebenfalls die virtuelle Hardware-Version 20.
Die Gerätezuweisungsfunktion in der neuen vSphere- 8-GUI zur vNUMA-Topologie hilft Admins und MLOPs-Teams, die vCPU und GPU einer VM demselben NUMA-Knoten zuzuweisen. Dies erhöht die Wahrscheinlichkeit, dass der Arbeitsspeicher der VM auf dem gleichen NUMA-Knoten wie die GPU bleibt. Nutzer können das Verhalten im Assistenten zum Erstellen neuer VMs konfigurieren oder die CPU-Topologie der bestehenden VM bearbeiten.
vSphere Datasets
Die oben erwähnten Datasets in vSphere 8 stellen eine neue Methode zum Teilen von (Konfigurations-)Daten zwischen vSphere und dem Gastbetriebssystem dar, wobei Daten zusammen mit der VM gespeichert und auf andere Hosts verschoben werden können.
Potenzielle Anwendungsfälle könnten etwa der Bereitstellungsstatus, die Agent-Konfiguration oder die Bestandsverwaltung des Gastes sein. Der Mechanismus funktioniert mit installierten VMware-Tools und der vHardware 20.