VMware-Host-Konsolidierung: wie viele Hosts ein vSphere-Cluster bei Lizenzierung pro Kern braucht

Wie Host-Konsolidierung die Zahl der lizenzierten Kerne senkt

VMware-Host-Konsolidierung senkt die Zahl der lizenzierten Kerne, weil VVF und VCF auf jedem physischen Kern jedes Servers lizenziert werden, auf dem die Software installiert ist, mit einem Minimum von 16 Kernen je Prozessor. Sechs Hosts mit zwei 16-Kern-CPUs brauchen 192 Kernlizenzen, vier brauchen 128. Wie weit ein Cluster schrumpfen kann, hängt von seiner gemessenen Spitze bei Ausfall eines Hosts ab, von HA Admission Control und der Reserve für Wartung und, mit vSAN, von der Zahl der Hosts, die die Speicherrichtlinie braucht.

Die Zählregeln stehen in unserem Leitfaden zur VMware-Lizenzierung nach Broadcom, die Zählung einer bestehenden Umgebung in unserem Leitfaden zur Kernzählung. Ob eine niedrigere Kernzahl zusätzlichen Arbeitsspeicher, zusätzliche Speichergeräte oder Server rechtfertigt, ist eine Rechnung mit Ihren eigenen Zahlen.

Was die Konsolidierung begrenzt, Faktor für Faktor

Broadcom TechDocs (vSphere 8.0, vSAN 8.0, VCF 9.1), vSphere-API-Referenz 9.0, KB 438023 und 326889, Programmdokumentationen zu VVF und VCF (Juni 2026).

HA Admission Control und N+1 in einem kleineren Cluster

vSphere HA Admission Control hält Kapazität zurück, um die VMs eines ausgefallenen Hosts neu zu starten. Sie setzen Host failures cluster tolerates und legen die Reserve über den Prozentsatz der Clusterressourcen, eine Slot-Richtlinie oder dedizierte Failover-Hosts fest, oder Sie deaktivieren sie. Für die Prozentsatz-Richtlinie schreibt Broadcoms API-Referenz zu 8.0 und 9.0, die Standardberechnung verwende „die Ressourcen der failoverLevel-Hosts“. Bei gleichen Hosts und einem tolerierten Ausfall sind das 25 % eines Clusters mit vier Hosts und etwa 17 % eines Clusters mit sechs.

HA prüft diese Reserve gegen Reservierungen, nicht gegen die Nutzung. Laut Broadcoms Seite zur Prozentsatz-Richtlinie summiert HA die CPU-Reservierungen eingeschalteter VMs, 32 MHz für eine VM ohne Reservierung, und ihre Arbeitsspeicherreservierungen plus Overhead, auf Hosts, die verbunden sind, nicht im Wartungsmodus stehen und keine HA-Fehler haben. Nutzt eine VM mehr Arbeitsspeicher, als sie reserviert, ist laut der Seite zu Admission Control „nicht genügend Failover-Kapazität verfügbar, was beim Failover zu Leistungseinbußen führt“. Ein Cluster mit wenigen Reservierungen kann die Admission Control auf vier Hosts bestehen, während drei Hosts seine Spitze nicht tragen könnten.

Die Einstellung Performance degradation VMs tolerate, die DRS voraussetzt, vergleicht die Nutzung mit der Kapazität. Ihr Standardwert von 100 % „erzeugt keine Warnungen“; bei 0 % „wird eine Warnung erzeugt, wenn die Clusternutzung die verfügbare Kapazität übersteigt“. Ein dedizierter Failover-Host nimmt bis zu einem Ausfall keine VMs auf, doch alle seine Kerne werden lizenziert.

Reserve für den Wartungsmodus und DRS

Ein Host im Wartungsmodus nimmt seine Kapazität aus dem Cluster, wie es ein ausgefallener Host tut. Broadcoms Dokumentation zur Ressourcenverwaltung hält fest: „DRS empfiehlt keinerlei Migrationen virtueller Maschinen von einem Host, der in den Wartungs- oder Standby-Modus wechselt (und führt sie im vollautomatisierten Modus nicht aus), wenn die Failover-Ebene von vSphere HA verletzt würde, nachdem der Host in den angeforderten Modus gewechselt ist.“ Der Host bleibt dann im Zustand Entering Maintenance Mode, was in einem kleinen Cluster mit großen Reservierungen ein Patch-Fenster blockieren kann.

Ist ein Cluster auf N+1 ausgelegt, patcht er ohne Reservehost, daher gehören Patch-Fenster außerhalb der Spitzen zum Monatsende. Auf N+2 ausgelegt, behält er einen, was bei vier Hosts die Hälfte des Clusters zurückhält.

Unter vSAN verschiebt Ensure accessibility, der standardmäßige Evakuierungsmodus, nur die Daten, die nötig sind, damit jedes Objekt zugänglich bleibt, und Broadcom warnt, dass dieser Modus „den Schutz Ihrer Daten während eines Ausfalls nicht wiederherstellt und Sie unerwarteten Datenverlust erleiden könnten“. Full data migration hält die Daten richtlinienkonform, braucht aber einen Host, auf den sie verschoben werden.

Mindestzahl an vSAN-Hosts, Rebuild-Reserve und enthaltene TiB

Ein Standard-vSAN-Cluster braucht mindestens drei Hosts, die Kapazität beitragen (Dokumentation zu VCF 9.1), und die Speicherrichtlinie hebt diese Untergrenze an. Mit Spiegelung sind 2n+1 Fehlerdomänen für FTT=n nötig, für FTT=2 also fünf; RAID-5 braucht vier bei OSA und drei, als 2+1, bei ESA, und RAID-6 braucht sechs. Ein Cluster mit drei Hosts kann nach einem Ausfall den Schutz der Daten nicht wiederherstellen und Full data migration nicht nutzen, und Broadcom empfiehlt „einen Cluster mit vier oder mehr Hosts für maximale Verfügbarkeit“. Full data migration braucht einen Host mehr als das Layout selbst. KB 326857, deren Abschnitt zur Ursache sich auf OSA-Datenträgergruppen bezieht, nennt einen vierten Host für RAID-1, einen fünften für RAID-5 und einen siebten für RAID-6. Für ESA bezieht KB 405876 diesen zusätzlichen Host in die Wahl des RAID-5-Schemas ein, 2+1 auf vier Hosts und 4+1 ab sechs. Die Layouts behandelt unser Vergleich von vSAN ESA und OSA.

KB 326889 bemisst die Host-Rebuild-Reserve nach „der Kapazität eines Hosts im Verhältnis zur Gesamtzahl der Hosts im Cluster“, ein Sechstel der Kapazität bei sechs Hosts und ein Viertel bei vier, neben einer Betriebsreserve für Richtlinienänderungen und Rebalancing. Beide sind standardmäßig deaktiviert und laut der Dokumentation zu vSAN 8.0 mit Fehlerdomänen, auf Stretched- oder ROBO-Clustern und unter vier Hosts nicht unterstützt; dimensionieren Sie in jedem Fall für beide. Die enthaltene Kapazität folgt den lizenzierten Kernen, 0,25 TiB je VVF-Kern und 1 TiB je VCF-Kern, gerechnet gegen die gesamte Rohkapazität, die vSAN beansprucht.

Bedarf messen: 90-Tage-Spitzen statt Mittelwerte

Dimensionieren Sie auf die Spitze der Cluster-Summe, nicht auf Mittelwerte oder auf die Summe der Spitzen jeder VM, da nicht alle VMs gleichzeitig ihre Spitze erreichen. Neunzig Tage mit Messwerten im 5-Minuten-Takt, so gelegt, dass sie ein Quartalsende enthalten, erfassen dessen Läufe zum Monatsabschluss und Backup-Fenster. vCenter bewahrt 5-Minuten-Werte standardmäßig nur einen Tag lang auf, daher kommen die Messwerte aus VCF Operations oder einem externen Collector, wie unser Leitfaden zur Verschwendung in vSphere-Umgebungen erklärt.

1. Exportieren Sie je Cluster 90 Tage Messwerte im 5-Minuten-Takt: CPU-Nutzung in MHz, verbrauchten Arbeitsspeicher, Balloon und belegten Swap, Ready-Zeit je vCPU und, unter vSAN, die belegte Rohkapazität.
2. Ermitteln Sie das 95. Perzentil und das Maximum der Cluster-Summen, jeweils mit dem Zeitpunkt.
3. Rechnen Sie die CPU-Werte in Kerne um, indem Sie die MHz durch den Takt eines Kerns teilen; vCenter zählt die Clusterkapazität als Kerne mal Prozessortakt und die Clusternutzung als Summe der VMs, ohne die Eigenlast von ESXi und vSAN.
4. Teilen Sie das 95. Perzentil durch die Auslastungsobergrenze, die Sie bei Ausfall eines Hosts akzeptieren, und durch die Kapazität eines Hosts, runden Sie auf, addieren Sie einen Host und prüfen Sie, ob das Maximum bei Ausfall eines Hosts passt.

KB 438023 wertet Ballooning ungleich null als Speicherdruck auf dem Host und Auslagern auf Host-Ebene als Konkurrenz, die in der Regel „schwerwiegend genug ist, um die VM-Leistung zu beeinträchtigen“. Für die Ready-Zeit nennt sie in der Branche anerkannte Schwellenwerte, nach denen unter etwa 5 % je vCPU unbedenklich sind und über 10 % eine spürbare Beeinträchtigung bedeuten. Wer 192 Kerne auf 128 konsolidiert, erhöht das Verhältnis von vCPU zu Kern um die Hälfte; die Zähler dahinter erklärt unser Leitfaden zu CPU Ready.

Unser Infrastruktur-Audit erfasst Cluster und ihre tatsächliche Ressourcennutzung anhand der Exporte, die Sie bereitstellen. Nennen Sie uns, welche Cluster Sie verkleinern möchten und welche Monitoring-Daten Sie aufbewahren.

CPU-Wahl für neue Hosts unter dem 16-Kern-Minimum

Ein Prozessor mit weniger als 16 Kernen wird mit 16 lizenziert, neue Hosts sollten also mindestens 16 Kerne je Sockel haben. Oberhalb dieser Untergrenze folgt die Lizenz der Gesamtzahl der Kerne, und die Zahl der Hosts entscheidet, wie viele davon in Reserve stehen. Jeder Aufbau unten lässt nach dem Ausfall eines Hosts 96 Kerne übrig.

Unsere Rechnung: mindestens 16 Kerne je Prozessor (Programmdokumentationen zu VVF und VCF, Juni 2026) und eine HA-Reserve von einem Host.

Weniger, größere Hosts halten einen größeren Anteil in Reserve, daher hat der kleinste Cluster nicht die wenigsten lizenzierten Kerne, während jeder zusätzliche Host ein weiterer Server ist, der betrieben werden muss. Weniger Kerne je Sockel bedeuten außerdem kleinere NUMA-Knoten, und ESXi hält vCPUs und Arbeitsspeicher einer VM innerhalb eines Knotens, wenn die VM hineinpasst (KB 438023); die breiteste VM setzt also eine Untergrenze für die Kerne je Sockel. Ein ausgemusterter Host, der mit installiertem Hypervisor als Reserve bereitsteht, zählt für die Lizenzierung weiterhin mit.

Durchgerechnetes Beispiel: von sechs auf vier Hosts

Das Beispiel dient der Veranschaulichung und ist kein Kundenfall. Sechs Hosts mit je zwei 16-Kern-CPUs und 512 GB Arbeitsspeicher betreiben VVF auf 192 lizenzierten Kernen. vSAN ESA speichert 30 TiB VM-Daten mit einer RAID-6-Richtlinie bei FTT=2. Über 90 Tage lag das 95. Perzentil der Cluster-Summen bei 55 Kernen CPU-Nutzung und 1.700 GB verbrauchtem Arbeitsspeicher.

Beispielwerte; unsere Rechnung mit 0,25 TiB je VVF-Kern (Programmdokumentation zu VVF, Juni 2026) sowie RAID-6 und RAID-5 2+1 mit dem 1,5-Fachen der Datenmenge (Dokumentation zu vSAN 8.0).

Nach Schritt 4 mit einer Obergrenze von 80 % braucht die CPU vier Hosts, der Arbeitsspeicher dagegen alle sechs Hosts mit 512 GB und vier mit 768 GB; der Arbeitsspeicher, der keinen lizenzierten Kern hinzufügt, bestimmt also die Zahl der Hosts.

Unter vSAN kann FTT=2 nicht auf vier Hosts bleiben, daher muss der Dateneigentümer FTT=1 akzeptieren, was auf vier ESA-Hosts RAID-5 2+1 mit demselben 1,5-Fachen der Datenmenge sein kann. Ohne neue Speichergeräte würden die belegte Kapazität und die Rebuild-Reserve von 16 TiB schon vor der Betriebsreserve 61 von 64 TiB belegen. Jeder verbleibende Host wird deshalb auf 24 TiB erweitert. Unter VVF wächst das Add-on für dieselben 96 TiB um 16 TiB, weil die enthaltene Kapazität mit den Kernen sinkt; unter VCF reichen die enthaltenen 128 TiB dafür weiterhin aus. Von Schritt 1 bis Schritt 4 unten beansprucht vSAN 128 TiB Rohkapazität, und die Programmdokumentation zu vSAN verlangt, dass alles davon lizenziert wird.

1. Bauen Sie Arbeitsspeicher und Speichergeräte in die vier Hosts ein, die bleiben, Host für Host in Wartungsfenstern.
2. Stellen Sie die Speicherrichtlinie auf FTT=1 um, solange alle sechs Hosts im Cluster sind; vSAN erstellt die neuen Komponenten, bevor es die alten löscht (KB 326857), prüfen Sie also vorher den freien Speicherplatz.
3. Versetzen Sie die beiden Hosts nacheinander mit Full data migration in den Wartungsmodus. Unter ESA folgt der zweite erst, wenn die Ansicht Resyncing Objects die RAID-5-Objekte als von 4+1 auf 2+1 umgestellt zeigt. Laut KB 405876 beginnt diese Umstellung 24 Stunden, nachdem die Zahl der Hosts mit verfügbaren Speicherpools gesunken ist, und sie kann mehrere Stunden dauern.
4. Beobachten Sie den nächsten Monatsabschluss auf vier Hosts, entfernen Sie dann die beiden Hosts aus dem Cluster und die Software von den Servern.

Bis dahin können die beiden Hosts den Wartungsmodus wieder verlassen, falls der Monatsabschluss einen Engpass zeigt. Das Ergebnis sind 128 lizenzierte Kerne statt 192, mehr Arbeitsspeicher je Host, dieselbe Rohkapazität und vSAN-Daten, die einen Ausfall statt zwei tolerieren.

Unsere VMware-Optimierung umfasst die Host- und Cluster-Konsolidierung, mit Änderungen in vereinbarten Wartungsfenstern und einem Rollback-Plan für jede Etappe. Schicken Sie uns Ihre Hostliste und 90 Tage Clusterdaten über das Formular unten.

Was wir tun

Eurokommerz hält den Vertrag und liefert Hardware und Lizenzen; die technische Umsetzung übernimmt unser Engineering-Partner Vixen.UNO. Im Rahmen der VMware-Optimierung auditiert das Vixen.UNO-Team die Umgebung und ihre Lizenzen, stimmt Editionen und Abonnements auf Ihre realen Workloads ab und konsolidiert Hosts und Cluster. Wir versprechen nicht, die alten Preise zurückzuholen: Sie sehen die Zahl nach dem Audit, bevor Sie das Renewal unterschreiben, und gibt es nichts zu optimieren, sagen wir das. Unser Infrastruktur-Audit ist ein eigenständiges Produkt mit Festpreis. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments steht vor Beginn fest.

FAQ