vSphere Memory Tiering mit NVMe: Anforderungen, Verhältnis, Einrichtung und Sizing in VCF 9.0 und 9.1

Wie vSphere Memory Tiering mit NVMe arbeitet

vSphere Memory Tiering, in Broadcoms Dokumentation Memory Tiering over NVMe genannt, erweitert die Arbeitsspeicherkapazität eines ESX-Hosts um NVMe-Geräte, die lokal in ihm eingebaut sind, und nutzt NVMe so als Arbeitsspeicher. DRAM ist Tier 0 und das NVMe-Gerät Tier 1; ESX hält die aktiven Seiten jeder VM im DRAM und verschiebt kalte Seiten auf NVMe. Die Funktion ist standardmäßig deaktiviert, und die Dokumentation zu vSphere 9.1 begrenzt den NVMe-Tier standardmäßig auf die Größe des DRAM, also auf ein Verhältnis von 1:1, bis zu 4 TB.

Broadcoms KB 311934 beschreibt Memory Tiering in vSphere 8.0 Update 3 als Technical Preview, und die Performance Best Practices for vSphere 9.1, Revision 20260624, nennen es ab vSphere 9.0 unterstützt. Für 9.1 führt die vSphere 9.1 FAQ vom Mai 2026 auf: kein Neustart zum Aktivieren, Zustand und Verschleiß der Geräte in der Oberfläche sowie Spiegelung nach RAID 1. Den Rest des Releases behandelt unser Überblick über die Neuerungen in VCF 9.1.

Die Seite zu Überlegungen und Best Practices für 9.1, aktualisiert am 12. Oktober 2026, hält fest, dass „Kernel-Speicher nie getiert wird“, und dass kalte Seiten verschoben werden, sobald der Speicherverbrauch des Hosts etwa 80 % der DRAM-Kapazität erreicht.

Anforderungen an Memory Tiering in vSphere 9.0 und 9.1

Broadcom TechDocs, Memory Tiering over NVMe, vSphere 9.0 (24. August 2026) und 9.1 (12. Oktober 2026); Broadcom KB 311934.

Die Dokumentation zu 9.1 beschreibt das Gerät als „ein Laufwerk ähnlich dem vSAN-Cache (Mixed Use mit 3 DWPD)“ und verweist für unterstützte Geräte auf den Broadcom Compatibility Guide. Hot-Plug und Prepare to Remove werden für ein Tier-Gerät nicht unterstützt, und Memory Tiering muss auf dem Host deaktiviert werden, bevor das Gerät entfernt oder ersetzt wird.

Auf vSAN-Hosts ist das Tier-Gerät ein eigenes Laufwerk: entweder ein neuer Datenträger, hinzugefügt bei abgeschaltetem automatischem Claiming, ein nicht beanspruchter Datenträger oder ein Datenträger, der nach einer Vorabprüfung aus vSAN entfernt wurde.

Verhältnis von NVMe zu DRAM und Größe des Tiers

In vSphere 9.0 ist die Größe des Tiers die erweiterte Host-Einstellung Mem.TierNvmePct, ein Prozentsatz des gesamten DRAM. Broadcom rät zu 100 % oder weniger, damit der DRAM mindestens so groß ist wie der Tier, begrenzt die Tier-Partition auf 4 TB und verlangt nach einer Änderung einen Neustart.

In vSphere 9.1 heißt derselbe Wert tier_size_pct in der Cluster-Konfiguration und --tier-size-pct in ESXCLI. Die ESXCLI-Referenz schreibt „Set maximum tiering size with respect to DRAM (Value must be between 1 and 400)“, und die Seite zur Konfiguration empfiehlt für optimale Leistung den Standardwert 100. Die Dokumentation zu 9.1 nennt das Maximum von 4 TB beim Standardwert und sagt nicht, wie es oberhalb von 100 gilt. Ist das Gerät kleiner als der DRAM, wird die kleinere Kapazität genutzt, und die Best-Practices-Seite hält fest: „Im Allgemeinen müssen NVMe-Größen mindestens so groß sein wie der DRAM des Systems.“

NVMe ist langsamer als DRAM, daher begrenzt Broadcom, wie viel aktiver Arbeitsspeicher davon abhängen darf. Die Performance Best Practices für 9.1 raten, den aktiven Arbeitsspeicher bei höchstens 50 % des DRAM zu halten, wobei manche Workloads erst leiden, wenn er sich 75 % nähert. Für die Leselatenz von NVMe raten sie zu Werten unter 200 Mikrosekunden, mit demselben Vorbehalt bei 400. Außerdem verlangen sie CPU-Reserve, und die TechDocs zu 9.1 beziffern den Aufwand auf kleineren Hosts mit etwa einem Achtel eines Kerns.

VMs und Funktionen, die vom Memory Tiering ausgeschlossen sind

Die Regeln für VM-Typen unterscheiden sich zwischen den Versionen. Die Seite zu VM-Profilen für 9.0 (24. August 2026) sagt, dass fünf Typen, aufgeführt in der Sizing-Tabelle unten, „nicht auf einem ESX-Host platziert werden können, der für Memory Tiering konfiguriert ist“; unter 9.0 brauchen sie also Hosts ohne Tiering. Die Seite für 9.1 (12. Oktober 2026) lässt sie auf einem Host mit Tiering laufen, doch sie sind „weiterhin vom Memory-Tiering-Prozess ausgeschlossen“; von diesen lassen sich nur VBS-VMs tieren, mit sched.mem.enableNestedTiering auf TRUE. Für VMs mit mehr als 512 GB und 64 vCPUs warnt die Seite für 9.1 vor Leistungseinbußen und rät, Tiering abzuschalten und ihren gesamten Arbeitsspeicher zu reservieren.

Unter 9.0 bleiben VMs mit 1-GB-Seiten, vorab zugewiesenem Arbeitsspeicher, PCI-Passthrough, UPT oder vQAT automatisch im DRAM. Um eine weitere VM im DRAM zu halten, schalten Sie sie aus, fügen sched.mem.enableTiering mit dem Wert FALSE hinzu und wählen Reserve all guest memory (All locked), wie es die Seite zur Konfiguration für 9.1 beschreibt.

Die Best-Practices-Seite sagt, dass Arbeitsspeicherreservierungen, nicht aber gepinnter Arbeitsspeicher, auf DRAM und NVMe aufgeteilt werden können, wenn die reservierten VMs mehr verbrauchen, als der DRAM fasst. Sie sagt außerdem „Verwenden Sie keine Speicherüberbelegung, wenn Memory Tiering aktiviert ist“, was wir so lesen, dass der konfigurierte Arbeitsspeicher der VMs innerhalb von DRAM plus Tier bleibt. Ballooning und Swapping auf Host-Ebene behandelt unser Leitfaden zu Speicherüberbelegung, Ballooning und Swapping in vSphere.

vMotion „dauert länger (1,5X bis 2X)“, weil die Seiten zuerst von NVMe geholt werden, und DRS unterstützt Cluster, in denen Hosts mit und ohne Tiering gemischt sind.

Die Seite zu NVMe-Ausfallszenarien für 9.1 sagt: „Wird ein Seitenfehler für eine Seite auf dem ausgefallenen Gerät ausgelöst und kann er nicht bedient werden, schaltet sich die virtuelle Maschine aus.“ VMs, die nur DRAM nutzen, laufen weiter, und die Neustartrichtlinien von HA können die anderen auf Hosts mit freier Kapazität neu starten; das spricht für gespiegelte Geräte und eine HA-Reserve, die mit dem Tier dimensioniert ist.

Welche Ihrer Hosts infrage kommen, hängt von ihrem aktiven Arbeitsspeicher ab und davon, wie viele VMs im DRAM bleiben müssen. Beschreiben Sie Ihre Cluster und ihr Speicherprofil im Formular unten, und wir gehen die Kandidaten mit Ihnen durch.

Memory Tiering in vSphere 9.1 und 9.0 aktivieren

In vSphere 9.1 wird Memory Tiering je Cluster im vSphere Client unter Configure, Desired State, Configuration eingestellt: Auf der Registerkarte Draft setzen Sie unter esx, memtier, nvme, Configure Settings enable auf True und wählen mindestens ein NVMe-Gerät, optional ein Spiegelgerät, Verschlüsselung und tier_size_pct. Der Configuration Manager versetzt die Hosts automatisch in den Wartungsmodus, ohne Neustart. Für einen Host, in einem Cluster, der mit einem Image und vSphere Configuration Profiles verwaltet wird, sind dies die Schritte mit ESXCLI.

1. Versetzen Sie den Host in den Wartungsmodus.
2. Ermitteln Sie mit esxcli memtier device list das NVMe-Gerät; -a listet nur die verfügbaren.
3. Führen Sie esxcli memtier enable -d <device_1> aus; für Software-Spiegelung übergeben Sie beide Geräte an -d als <device_1,device_2>.
4. Ergänzen Sie -c t für die Verschlüsselung des Tiers und -r mit einem Prozentsatz, um die Größe des Tiers zu ändern, wie im Beispiel -c t -r 50.
5. Prüfen Sie das Ergebnis mit esxcli memtier status get und esxcli memtier config get und beenden Sie dann den Wartungsmodus.

Spätere Änderungen erfolgen mit esxcli memtier config set auf einem Host im Wartungsmodus, etwa mit --tier-size-pct 25 für ein Verhältnis von 4:1, und esxcli memtier disable schaltet Tiering ab. Broadcom warnt, dass dies den im Cluster verfügbaren Arbeitsspeicher verringert.

In vSphere 9.0 legt esxcli system tierdevice create -d, gefolgt von /vmfs/devices/disks/ und dem Gerätenamen, die Tier-Partition an, wenn der Host im Wartungsmodus ist und alle Partitionen vom Gerät gelöscht sind; esxcli system tierdevice list zeigt sie an. Danach wird VMKernel.Boot.memoryTiering unter Configure, System, Advanced System Settings auf true gesetzt und der Host neu gestartet. Broadcoms VCF-Blog vom 25. September 2026 schreibt, dass 9.1 alle diese Vorgänge in den Namensraum esxcli memtier verlagert; prüfen Sie Skripte für 9.0 daher vor dem Upgrade.

Memory Tiering auf ESX-Hosts überwachen

Meldet esxcli memtier config get Enable als True, während esxcli memtier status get Disabled meldet, verweist die Dokumentation zu 9.1 auf die Systemprotokolle und Alarme. Im vSphere Client zeigt die Karte Memory auf der Registerkarte Summary des Hosts dessen Memory-Tiering-Konfiguration, und die Registerkarte Hosts des Clusters kann eine Spalte Memory Tiering anzeigen, die bei konfigurierten Hosts Software lautet.

KB 449016 nennt vier Zähler in der Ansicht Memory der erweiterten Leistungsdiagramme: Memory type read bandwidth, read latency, write bandwidth und write latency. Wir würden die Leselatenz mit den 200 Mikrosekunden von oben vergleichen. Je VM führt die KB auf dem Host per SSH memstats -r vmtier-stats -u mb aus, wobei -s die Spalten name, memSize, active, tier1Target und tier1Consumed auswählt.

Lizenzierung von Memory Tiering in VVF und VCF

Memory Tiering ist Teil von vSphere 9, und die vSphere 9.1 FAQ hält fest: „Funktionen von vSphere 9.0 und 9.1 sind nur als Teil von VMware vSphere Foundation 9.0 und 9.1 und VMware Cloud Foundation 9.0 und 9.1 verfügbar.“ Dieselbe FAQ beschränkt vSphere Standard und vSphere Enterprise Plus auf Version 8 Update 3 und älter. Mit Stand Oktober 2026 haben wir kein Broadcom-Dokument gefunden, das den NVMe-Tier, DRAM oder Memory Tiering gesondert lizenziert.

VVF und VCF werden auf jedem physischen Kern jedes Servers lizenziert, auf dem die Software installiert ist, mit mindestens 16 je Prozessor; wo der Arbeitsspeicher die Zahl der Hosts bestimmt, kann ein größerer Memory-Tier daher die Zahl der Hosts und der lizenzierten Kerne senken. Unser Leitfaden zur Host-Konsolidierung bei Lizenzierung pro Kern behandelt HA Admission Control und die Mindestzahl an vSAN-Hosts, die eine eigene Untergrenze setzen.

Memory Tiering für 10 bis 60 Hosts dimensionieren

Broadcoms Best-Practices-Seite rät, mit Hosts oder Clustern zu beginnen, deren aktiver Arbeitsspeicher zwischen 0 % und 50 % des vorhandenen DRAM liegt, und unser Leitfaden zur Kapazitätsplanung für vSphere erklärt, wie Sie je Cluster 90 Tage Messwerte im 5-Minuten-Takt erfassen.

Broadcom TechDocs, Memory Tiering Considerations and Best Practices, 9.1 (12. Oktober 2026); Virtual Machine Profiles and Performance with Memory Tiering, 9.0 (24. August 2026) und 9.1 (12. Oktober 2026).

Das Beispiel dient der Veranschaulichung und ist kein Kundenfall. Ein Cluster aus 16 Hosts mit je zwei 32-Kern-CPUs und 1.024 GB DRAM betreibt 1.000 VMs mit 14.000 GB konfiguriertem Arbeitsspeicher. Die 95. Perzentile über 90 Tage liegen bei 12.000 GB verbrauchtem und 2.400 GB aktivem Arbeitsspeicher sowie 420 Kernen CPU-Bedarf. Mit einer Obergrenze von 80 % und einem Host in Reserve braucht der Arbeitsspeicher 12.000 ÷ (0,8 × 1.024) = 14,6, aufgerundet 15, plus einen: alle 16 Hosts. Die CPU braucht 420 ÷ (0,8 × 64) = 8,2, also 9 plus einen: 10 Hosts.

Mit einem Tier im Verhältnis 1:1 bietet jeder Host 2.048 GB, und der Arbeitsspeicher braucht 12.000 ÷ (0,8 × 2.048) = 7,3, also 8 plus einen: 9 Hosts. Die Zahl bestimmt dann die CPU mit 10 Hosts, also 10 × 64 = 640 lizenzierte Kerne statt 16 × 64 = 1.024. Bei Ausfall eines Hosts liegt der aktive Arbeitsspeicher bei 2.400 ÷ 9 = 267 GB je Host, etwa 26 % des DRAM, und die 14.000 GB konfigurierter Arbeitsspeicher passen ohne Überbelegung in 9 × 2.048 = 18.432 GB. Ein gespiegelter Tier braucht je Host zwei Mixed-Use-NVMe-Geräte mit mindestens 1.024 GB, und der Arbeitsspeicher von VMs, die im DRAM bleiben müssen, zählt allein gegen den DRAM. Ob das weniger Hosts rechtfertigt, ist eine Rechnung mit Ihren eigenen Zahlen; neue Server behandelt unser Leitfaden zum VMware-Host-Austausch.

Kommt ein Cluster mit Memory Tiering mit weniger Hosts aus, gehört die Konsolidierung zu unserer VMware-Optimierung und läuft in vereinbarten Wartungsfenstern mit einem Rollback-Plan. Schicken Sie uns den DRAM je Host und 90 Tage verbrauchten und aktiven Arbeitsspeicher.

Was wir tun

Für Memory Tiering beginnt die VMware-Optimierung mit dem Audit von Umgebung und Lizenzen durch unseren Engineering-Partner Vixen.UNO, das Versionen, Abonnements und die tatsächliche Ressourcennutzung jedes Clusters erfasst. Auf dieser Grundlage stimmt das Team Editionen und Abonnements auf Ihre realen Workloads ab und konsolidiert Hosts und Cluster, mit allen Änderungen in vereinbarten Wartungsfenstern und einem Rollback-Plan für jeden Schritt. Eurokommerz hält den Vertrag und liefert die Hardware zur Lösung, die NVMe-Geräte eingeschlossen. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments steht vor Beginn fest.

FAQ