Neu in vSphere 7 Update 3: NSX-Integration, NVMe über TCP, Update für DRS, Precision Time

Wer bereits Storage-Systeme oder Server-Hardware mit NVMe-SSDs nutzt, verzichtet auf real erziel­bare Performance, wenn das Speicher­netzwerk nicht mitspielt. Speicher­schnittstellen und die im Speicher­netzwerk ausgeführten Protokolle können Workloads unnötig verlangsamen.

Zwar konnte man auch bisher schon Host-based Adapter (HBA) für Fibre Channel und RDMA-fähige Netzwerk­karten verwenden, diese ziehen aber in jedem Fall zusätzliche Investitionen nach sich.

VMware hat sich des Problems angenommen und unterstützt in der neuen Version nun auch nativ NVMe over TCP. So können Admini­stratoren nun gewöhnliche Ethernet-NICs verwenden, um ihr NVMe-Array mit vSphere zu verbinden.

In diesem Zusammenhang erwähnens­wert ist die Einführung eines neuen vmnic-Tags. Diese Einstellung für VMkernel-Adapter erlaubt die Weiterleitung von NVMe-over-RDMA-Datenverkehr über eine derart getaggte Schnittstelle.

Natürlich lässt sich das Tag auch über die Kommandozeile aktivieren:

esxcli network ip interface tag add -i <interface name> -t NVMeRDMA

Verbesserungen in DRS

Der Distributed Resource Scheduler (DRS), die Last­ausgleich­funktion für vSphere-Host-Cluster, wird mit jeder Version smarter, was insbesondere bei großen Workloads zum Tragen kommt. Deren Verschiebung auf andere Hosts ist kostspielig, denn vMotion verbraucht bei sehr großen VMs oder VMs mit vielen I/Os erhebliche Netzwerk­bandbreite, CPU-Leistung und damit Zeit.

Bisher hat DRS bei Wartungs­vorgängen VMs auf verschiedene Hosts verschoben, ohne die Arbeitslast oder die Konfiguration der jeweiligen VMs zu berücksichtigen. Mit vSphere 7 U3 wird eine große VM nur einmal verschoben und verbleibt dann auf diesem Host, sofern dieser bereits aktualisiert wurde.

Darüber hinaus verfügt der Wartungs­modus nun über eine intelligentere Logik, so dass vSphere DRS Workloads verfolgt, die schwer zu verschieben sind. Tritt beim Versetzen von Hosts in den Wartungs­modus ein Fehler auf, versucht das System es nun mehrmals, bevor es aufgibt.

Intelligentere Cluster-Dienste

VMware hat mit in vSphere 7 Update 1 die vSphere Cluster Services (vCLS)-VMs eingeführt, welche unter anderem dazu beitragen, DRS unabhängiger von der Verfügbarkeit von vCenter zu machen.

Diese so genannten Agent-VMs sind obligatorisch, sobald DRS im Cluster aktiviert ist. Da deren Namen aus "vCLS" plus einer entsprechenden Nummer in Klammern bestanden, waren die VMs beim Vorhandensein mehrerer Cluster aus Sicht der Benutzer­oberfläche identisch. Ferner konnte man nicht beeinflussen, wo diese VMs ausgeführt werden sollen.

In vSphere 7 U3 führt VMware eine eigene Kennung (UUIDs) für jede Agent-VM ein, sodass jede von ihnen aus der vCenter-Perspektive eindeutig ist. Damit entfällt im Inventar-Namen auch die in Klammern angehängte Zahl.

Ferner können Admins nun auswählen, welcher Datenspeicher sie für die Platzierung von Agent-VMs verwenden. Dies bedeutet auch, dass sich bestimmte Datenspeicher von der Platzierung dieser Agent-VMs ausnehmen lassen.

Analog dazu unterstützen die Agent-VMs nun Anti-Affinitätsregeln. So lassen sich bestimmte Hosts von vCLS-VMs freihalten.

In der Praxis wählt man dazu eine Compute-Richtlinie aus und markiert diejenigen (anderen) VMs, die man nicht zusammen mit der vCLS-VM ausführen möchte. Der vCLS-Scheduler verteilt dann die VMs auf verschiedene Hosts.

Precision Time

Mit vSphere 7 U2 hat VMware die Unterstützung für das Precision Time Protocol (PTP) eingeführt, um die Zeit­genauigkeit auf Mikro­sekunden­ebene anzuheben. Die neue Version bringt diesbezüglich einige Verbesserungen.

So gibt es jetzt eine Konfigurations­option, mit der man NTP als Failback festlegen kann, sollte PTP nicht verfügbar sein. So können die Systeme weiterhin Zeitdienste nutzen, auch ohne PTP.

Ebenfalls neu in vSphere 7.0 Update 3 ist, dass unter­nehmens­kritische VMs, die von VMware vSphere Fault Tolerance (FT) geschützt werden, einen MCE-Hardware-Fehler (Machine Check Exception) ohne Ausfallzeiten und Datenverlust überstehen. Workloads greifen dann nämlich auf die sekundäre virtuelle Maschine zurück, anstatt fehlzuschlagen.

Verbesserungen bei Tanzu

Auch bei der nativen Kubernetes-Integration mit Tanzu gibt es Neuerungen zu vermelden. Um die Integration für mehr Netzwerke zu ermöglichen, führt VMware mit Update 3 eine flexible DHCP-Unterstützung ein.

Das funktioniert sowohl für das Management- als auch für das Workload-Netzwerk. Der Admin kann dabei die verschiedenen Optionen nebeneinander nutzen. Zum Beispiel lassen sich für das Verwaltungs­netzwerk statische und das Workload-Netzwerk dynamische DHCP-Werte verwenden.

Das klappt durch den Einsatz von DHCP-Client-IDs mit DHCP-Reservierungen. Man kann dann die Client-IDs in Tanzu konfigurieren und diese auf dem DHCP-Server reservieren, damit die Adressen auch dann gleich bleiben, wenn sich die MAC-Adressen der Cluster-VMs ändern.

Lifecycle Manger

Verbesserungen gab es auch beim neuen vSphere Lifecycle Manager, der nach und nach immer mehr Aspekte übernimmt. So lassen sich Depots nun auch bearbeiten, etwa wenn Treiber oder andere Komponenten von VMware zurückgerufen werden müssen.

Dabei wird nun eine Benachrichtigung gesendet, die es dem Nutzer ermöglicht, Maßnahmen zu ergreifen.

Auch hat VMware die Hardware-Kompatibilität von E/A-Controllern auf die Treiber-Firmware ausgedehnt. Die Liste der Anbieter, die bereits mit dem Hardware-Support-Manager für Lifecycle Manager arbeiten, wurde zudem auf neue Partner erweitert.

Anwender sind dann in der Lage, Hardware und Software gemeinsam zu patchen. Zudem lassen sich deklarative Images erstellen, welche auch Aspekte wie BIOS-Versionen spezifiziert.