VMware vSphere 8 die wichtigsten Neuerungen im Überblick

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 Skalier­barkeit mit vHardware 20, Gerätegruppen, eine Bereit­stellungs­richtlinie 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.

DVX verschiebt die Grenzen von DirectPath I/O
DVX verschiebt die Grenzen von DirectPath I/O.

Virtuelle Maschinen, die in Zukunft DirectPath I/O verwenden, profitieren somit von mehr Virtualisierungs­funktionen 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.  Erwartungs­gemäß unterstützt die aktuelle Version auch die neuesten Intel- und AMD-CPUs und Gastbetriebs­systeme. 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 zusammen­gearbeitet.

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 Hardware­Ressourcen 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 Hoch­geschwindigkeits­verbindung 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.

Gerätegruppen kombinieren zum Beispiel NICs mit GPUs oder teilen sich PCIe-Switches über den QPIC.
Gerätegruppen kombinieren zum Beispiel NICs mit GPUs oder teilen sich PCIe-Switches über den QPIC.

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.

Gerätegruppen in vSphere 8 konfigurieren
Gerätegruppen in vSphere 8 konfigurieren.

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 ent­scheidender Bedeutung.

Verteilte GPU-Arbeitslasten via NVLINK (nVidia) oder das Kombinieren von NIC und GPU (PCIe-Switch)
Verteilte GPU-Arbeitslasten via NVLINK (nVidia) oder das Kombinieren von NIC und GPU (PCIe-Switch).

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 bereit­zustellen, 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 Hoch­geschwindigs­keits­verbindung 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.

Virtuelles NUMA im vSphere-Client
Virtuelles NUMA im vSphere-Client.

Die Geräte­zuweisungs­funktion 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 Wahr­scheinlichkeit, dass der Arbeits­speicher 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.

Die CPU-Topologie aus Sicht der VM
Die CPU-Topologie aus Sicht der VM.

 

vSphere Datasets

Die oben erwähnten Datasets in vSphere 8 stellen eine neue Methode zum Teilen von (Konfigurations-)Daten zwischen vSphere und dem Gastbetriebs­system dar, wobei Daten zusammen mit der VM gespeichert und auf andere Hosts verschoben werden können.

Potenzielle Anwendungsfälle könnten etwa der Bereitstellungs­status, die Agent-Konfiguration oder die Bestands­verwaltung des Gastes sein. Der Mechanismus funktioniert mit installierten VMware-Tools und der vHardware 20.

Hier weiterlesen

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.