VMware vSphere 8: die wichtigsten Neuerungen im Überblick


    Tags: , , ,

    vSphere 7 LogoVMware 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

    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.

    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

    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)

    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

    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

    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.

    Die neuen Datasets in vSphere 8

    Bereitstellungs­richtlinie für Windows 11 Virtual TPM

    Das Klonen von VMs mit TPM kann ein Sicherheitsrisiko darstellen. Deswegen können Admins in vSphere 8 angeben kann, ob sie das TPM-Gerät kopieren oder ersetzen möchte.

    Wählt man die Option Ersetzen aus, dann wird der VM-Klon wird mit einem brandneuen TPM-Gerät erstellt, das keinen Zugriff auf die Geheimnisse der Quell-VM hat.

    Beim Klonen einer vorhandenen VM kann nun ein neues TPM erstellt werden.

    Migrationsfähige Anwendungen

    In der Vergangenheit vertrugen sich insbesondere zeitkritische VoIP- oder geclusterte Anwendungen nicht gut mit vMotion. Programme können jetzt aber so geschrieben werden, dass sie vMotion-fähig sind. Dazu werden etwa bestimmte Dienste vor dem Start einer vMotion-Operation gestoppt und danach wieder fortgesetzt.

    Alternativ könnte die Anwendung auf ein anderes Cluster-Mitglied umschalten und den Beginn eines vMotion-Vorgangs bis zu einem bestimmten Punkt verzögern. Dabei verzögert die Anwendung selbst die Migration bis zu einem konfigurierbaren Timeout, aber sie kann die Migration nicht stoppen.

    Latenzempfindliche Anwendungen

    Die ebenfalls in vSphere 8 neue Latenz­empfindlichkeit mit Hyperthreading ermöglicht die Planung der vCPUs auf demselben physischen CPU-Kern. Der physische Host muss dafür Hyperthreading unterstützen. Auch diese Funktion benötigt die neueste virtuelle Hardware.

    Außerdem muss der Admin für eine solche VM eine CPU- und Arbeits­speicher­reservierung von 100 Prozent festlegen. Jeder virtuellen CPU wird dann exklusiver Zugriff auf einen Thread eines physischen Kerns gewährt.

    Virtuelle Maschine für latenzempfindliche Anwendungen konfigurieren

     

    Kubernetes / Tanzu

    Nachdem es zuletzt mehrere Varianten von vSphere mit Tanzu gab, einschließlich TKG (Supervisor- und Guest-Cluster nur für vSphere), TKGm (Verwaltungs- und Workload-Cluster für Multi-Cloud einschließlich vSphere), vereint VMware in vSphere 8 wieder alle bisherigen Optionen in einer einzigen TKG-Laufzeitumgebung, die überall ausgeführt werden kann.

    Ebenfalls neu in Tanzu Kubernetes Grid 2.0(3) sind die so genannten Workload-Verfügbarkeitszonen. Damit kann der Admin Workloads über vSphere-Cluster isolieren. Supervisor- und Tanzu-Kubernetes-Cluster lassen sich dann in diesen Zonen bereitstellen. Dadurch ist sichergestellt, dass sich Worker-Knoten nicht in denselben vSphere-Clustern befinden, was letztendlich die Verfügbarkeit verbessert.

    Verfügbarkeitszonen für Tanzu in vSphere 8

    Schließlich bietet der neue Cloud Consumption Interface-Service Entwicklern und DevOps-Ingenieuren einen Kubernetes-basierten gemeinsamen API-Endpunkt und eine Benutzeroberfläche, die einen schnellen und einfachen Zugriff auf IaaS-Services in der gesamten VMware Cloud bereitstellen.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling

    Thomas Drilling arbeitet seit mehr als 20 Jahren selb­ständig als Redakteur und Autor für viele ehe­malige und aktuelle IT-Magazine sowie Blogs. Thomas ist zudem Buch­autor und IT-Consultant.

    Seit 5 Jahren ist Thomas neben seiner journa­listischen Tätig­keit haupt­beruflicher, selb­ständiger IT-Trainer für VMware und Microsoft.

    Seine Themen­schwer­punkte sind Virtua­lisierung und Cloud Com­puting, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zerti­fi­zierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas ist außerdem zertifi­zierter AWS Solu­tions Archi­tect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Admini­strator.

    Thomas führt aktuell jeden zwei­ten Mon­tag einen 4-tägigen Grund­lagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Infor­mationen und Anmel­dung über sein AWS-Blog.

    Ähnliche Beiträge

    Weitere Links