vSphere-Cluster-Design für 10 bis 60 Hosts: wie viele Cluster, wie viele Hosts pro Cluster und warum

Wie viele Cluster 10 bis 60 Hosts brauchen

Beim vSphere-Cluster-Design für 10 bis 60 Hosts braucht die Umgebung so wenige Cluster, wie es ihre Ausfallbereiche, Workload-Typen und Lizenzgrenzen zulassen. Die Zahl der Hosts pro Cluster ergibt sich aus dem Bedarf der Workloads bei Ausfall eines Hosts, mit mindestens 3 Hosts unter vSAN oder 2 mit NFS oder Fibre Channel, weit unter den 96 Hosts je Cluster (64 mit vSAN) in Broadcoms Configuration Maximums. In den meisten Umgebungen dieser Größe sind das ein Management-Cluster, ein oder zwei allgemeine Produktionscluster und ein eigener Cluster nur dort, wo ein bestimmter Grund vorliegt: Datenbanken und ERP, deren Lizenzen je Host gezählt werden, eine DMZ, virtuelle Desktops oder GPU-Hosts. Jeder zusätzliche Cluster hält mindestens einen weiteren Host für Failover und Wartung zurück, daher braucht jede Aufteilung einen Grund, der diesen Host aufwiegt.

Mit VMware Cloud Foundation 9 ist die Management-Domain der erste Cluster: Broadcoms Designbibliothek verlangt 3 Hosts mit vSAN im Bereitstellungsmodell Simple und 4 im Modell High Availability. Mit vSphere Foundation können Management-VMs einen Produktionscluster mitnutzen.

Gründe für einen eigenen Cluster, Typ für Typ

Broadcom TechDocs, Designbibliothek zu VCF 9.0: Single-Rack-Clustermodell, Management-Domain-Modell, vCenter-Design (29. September 2026); Ressourcenverwaltung in vSphere 8.0 (16. September 2026). Die Gründe für Datenbanken, DMZ und VDI sind unsere Lesart.

Ein Cluster ist die Grenze von vSphere HA, DRS, EVC und, unter vSAN, eines Datastores. VMs darin teilen sich die Failover-Kapazität und wechseln ohne Unterbrechung zwischen den Hosts.

Abteilungen, Test und Produktion oder VMs mit unterschiedlichen Backup-Zeitplänen können sich einen Cluster teilen, getrennt durch Ressourcenpools, Tags und Berechtigungen. Unser Leitfaden zur NSX Distributed Firewall und zu vDefend behandelt die Netzwerktrennung innerhalb eines Clusters, die unter VCF das Add-on vDefend braucht und unter VVF nicht verfügbar ist. Wo die Sicherheitsrichtlinie diese logische Trennung akzeptiert, kann die DMZ in einem Produktionscluster bleiben; wo sie eigene Hardware verlangt, wird die DMZ zu einem eigenen Cluster.

GPU-Hosts bekommen meist einen eigenen Cluster, da vGPU-VMs nur auf Hosts mit demselben GPU-Typ wechseln und die vGPU-Einstellungen für DRS für den ganzen Cluster gelten, wie unser Leitfaden zu GPUs in vSphere erklärt.

Management-Cluster und die Management-Domain von VCF 9

Broadcoms Management-Domain-Modell vom 29. September 2026 führt auf, was die Management-Domain enthält: ESX-Hosts, vCenter, einen dedizierten NSX Manager und SDDC Manager für alle Workload-Domains der VCF-Instanz sowie in der ersten Instanz einer Fleet VCF Operations und VCF Automation. Sie kann auch Geschäfts-Workloads betreiben, und für diesen Fall empfiehlt Broadcom vier Ressourcenpools (Management, NSX-Edge-Knoten, Benutzer-Edges, Benutzer-VMs) und nennt als Folge: „Sie müssen die vSphere-Ressourcenpools manuell erstellen und ihre Einstellungen fortlaufend verwalten.“

Das Workload-Domain-Modell empfiehlt das Gegenteil, „Workload-Domains für Kunden-Workloads verwenden“, mit der Folge „Erfordert zusätzliche Hardware.“ Jeder Workload-Domain werden ein vCenter und ein NSX Manager zugewiesen, wobei die NSX-Instanz dediziert oder gemeinsam genutzt ist, und die vCenter-Appliances der Workload-Domains laufen in der Management-Domain.

Broadcom TechDocs, Designbibliothek zu VCF 9.0, vSphere-Single-Rack-Clustermodell, Anforderung VCF-CLS-REQD-CFG-002 (29. September 2026). Weitere Cluster: zusätzliche Management-Cluster und Cluster von Workload-Domains.

Broadcom bietet für die Management-Komponenten die Modelle Simple und High Availability an: Sein Single-Site-Blueprint betreibt Cluster mit drei Knoten für VCF Operations, VCF Automation und NSX Manager. Der Blueprint mit minimalem Footprint betreibt VCF Operations und VCF Automation mit je einem Knoten, geschützt durch vSphere HA, und stellt „alle Management- und Workload-Komponenten“ in einem vSphere-Cluster bereit. Unter vSphere Foundation können vCenter, VCF Operations und Backup-Appliances den Produktionscluster mitnutzen, mit einer HA-Neustartpriorität über der der Geschäfts-VMs.

Unsere VMware-Optimierung umfasst Architektur-Updates von vSphere, vSAN, NSX und VCF, in vereinbarten Wartungsfenstern mit Rollback-Plan. Nennen Sie uns, welche VCF- oder VVF-Version Sie betreiben und wo Ihre Management-Appliances heute laufen.

HA- und DRS-Einstellungen je Clustertyp

Das Single-Rack-Clustermodell von VCF 9.0 verlangt vSphere HA, „um alle virtuellen Maschinen vor Ausfällen zu schützen“, und Images von vSphere Lifecycle Manager für alle Cluster. Es empfiehlt Admission Control „für den Ausfall eines (1) ESX-Hosts und prozentuale Failover-Kapazität“, mit der Folge: „In einem Cluster mit vier (4) ESX-Hosts stehen nur die Ressourcen von drei (3) ESX-Hosts zur Nutzung zur Verfügung.“ VM Monitoring wird für jeden Cluster empfohlen; es hilft nur Anwendungen, die nach einem Neustart sauber wieder anlaufen.

Für DRS empfiehlt Broadcom auf allen Clustern „den standardmäßigen vollautomatisierten Modus mit mittlerem Schwellenwert“. Als Folge nennt Broadcom, dass die Zuordnung von VMs zu Hosts nach einem Ausfall von vCenter „schwer zu ermitteln sein könnte“; exportieren Sie die Platzierung der VMs daher nach einem festen Zeitplan. EVC wird für alle Cluster der Management-Domain empfohlen, mit „der höchsten verfügbaren Baseline, die für die niedrigste CPU-Architektur unterstützt wird“, und nur dort, wo alle Hosts CPUs desselben Herstellers haben. Für die vCenter-Appliances der Workload-Domains empfiehlt das vCenter-Design eine hohe HA-Neustartpriorität.

Datenbank-Hosts werden nach der Kernzahl je Sockel gewählt, damit große VMs in einen NUMA-Knoten passen. Wie viel Admission Control zurückhält und warum sie Reservierungen statt der Nutzung prüft, behandelt unser Leitfaden zur Host-Konsolidierung und HA Admission Control.

VM-Host-Regeln und Cluster, die an Anwendungslizenzen gebunden sind

Manche Datenbank- und ERP-Lizenzen zählen die Kerne jedes Hosts, auf dem eine VM läuft oder laufen darf. Die beiden Designs sind ein eigener Cluster für diese Software oder eine Hostgruppe in einem größeren Cluster mit einer VM-Host-Regel. Welches davon der Lizenzvertrag akzeptiert, ist eine rechtliche Bewertung für die Rechtsabteilung des Unternehmens.

Broadcoms Dokumentation zur Ressourcenverwaltung in vSphere 8.0, aktualisiert am 16. September 2026, nennt Regeln, nach denen die zugeordneten VMs auf der Hostgruppe laufen müssen („must run on“) oder nicht laufen dürfen („must not run on“), erforderlich und „should“-Regeln bevorzugt. Sie hält fest: „DRS, vSphere HA und vSphere DPM ergreifen niemals eine Maßnahme, die zur Verletzung erforderlicher Affinitätsregeln führt.“ Dieselbe Seite führt auf, was dann unterbleibt: „DRS evakuiert keine virtuellen Maschinen, um einen Host in den Wartungsmodus zu versetzen“, und „vSphere HA führt keine Failovers durch.“ Sie warnt: „Bei unsachgemäßer Verwendung können erforderliche VM-Host-Affinitätsregeln den Cluster fragmentieren und die ordnungsgemäße Funktion von DRS beeinträchtigen“, ebenso die von HA und DPM.

Eine erforderliche Hostgruppe aus drei Hosts braucht daher einen eigenen Reservehost: Fällt einer aus, startet HA dessen VMs nur auf den beiden verbleibenden Hosts der Hostgruppe neu. Eine bevorzugte Regel hält HA funktionsfähig, doch die VM kann dann auf einem Host außerhalb der Hostgruppe laufen. Ein eigener Cluster bietet dieselbe Isolation mit gewöhnlichen HA- und DRS-Einstellungen.

Clustergrößen und vSAN je Cluster

Broadcoms Tool Configuration Maximums, gelesen im Oktober 2026, nennt für vSphere 8.0 96 Hosts und 8.000 VMs je Cluster. Die Grenze von 96 Hosts gilt ab 7.0 U1 und nur für Cluster ohne vSAN. Für vSAN in VCF 9.1.1 nennt das Tool 64 Hosts und 6.400 VMs je Cluster sowie 200 VMs je Host unter OSA und 500 unter ESA. KB 317882 beschreibt diese Werte als „getestete, empfohlene Grenzwerte“, und jeder Cluster in einer Umgebung mit 60 Hosts bleibt darunter.

Jeder vSAN-Cluster hat einen eigenen Datastore, und seine Speicherrichtlinien legen eine Mindestzahl an Hosts fest: drei Hosts für RAID-5 2+1 unter ESA und sechs für RAID-6 4+2 oder RAID-5 4+1, wobei 4+1 fünf Hosts umfasst und der sechste seine Reserve ist. Broadcoms vSAN-FAQ vom 6. Oktober 2026 empfiehlt einen Host mehr, als die Richtlinien verlangen. Unser Leitfaden zum vSAN-ESA-Sizing rechnet belegte Kapazität in Rohkapazität und eine Zahl von Hosts je Cluster um.

Kleine Cluster müssen kein eigenes vSAN tragen. Die FAQ beschreibt vSAN-Speichercluster, früher vSAN Max, als „eine zentralisierte, gemeinsam genutzte Speicherlösung für Ihre vSphere-Cluster“ und das Datastore-Sharing zwischen vSAN-HCI-Clustern als Option, die meist ad hoc genutzt wird. Ein GPU-Cluster mit zwei oder drei Hosts kann einen Speichercluster einbinden, der an einem Standort selbst mindestens 4 Hosts braucht, oder NFS oder Fibre Channel nutzen, wo ein eigenes vSAN mehr Hosts bräuchte als die Rechenlast. Ein DMZ-Cluster kann dasselbe nur dort, wo die Sicherheitsrichtlinie Speicher und ein Speichernetz akzeptiert, die er mit internen Clustern teilt.

Ein großer Cluster oder mehrere kleine

Jeder auf N+1 ausgelegte Cluster hält einen Host in Reserve, unabhängig von seiner Größe. In einem Cluster mit 4 Hosts sind das 25 % der Hardware, in einem mit 16 Hosts etwa 6 %. Im Lizenzmodell von VCF 9.0 sind laut Broadcom ESX-Hosts die einzigen Assets, die Lizenzkapazität verbrauchen, für die meisten Produkte mit „einer Mindestverbrauchsregel von 16 Kernen je physischer CPU“, Reservehosts tragen also lizenzierte Kerne wie jeder andere Host. Wer einen Cluster in zwei aufteilt, fügt der Reserve einen Host samt seinen Kernen hinzu.

Ein Cluster betreibt ein einziges Image von vSphere Lifecycle Manager. Ein Cluster mit 32 Hosts, der Host für Host gepatcht wird, läuft also auf zwei Builds, bis alle 32 Hosts fertig sind, und ein Fehler in seinem Cluster-Image oder seinem vSAN-Datastore erreicht jede VM darin. Ein Ausfall, während ein anderer Host in Wartung ist, ist bei 32 Hosts wahrscheinlicher als bei 8; erwägen Sie daher ab etwa 30 Hosts, zwei Hosts in Reserve zu halten. Primärlizenzen werden vCenter-Instanzen zugewiesen, eine Aufteilung zwischen VVF und VCF verläuft also entlang der vCenter-Grenzen, wie unser Vergleich von VVF und VCF erklärt.

Durchgerechnete Layouts für 12, 30 und 60 Hosts

Die Layouts unten dienen der Veranschaulichung und sind keine Kundenfälle; jeder Cluster hält einen Host für einen Ausfall zurück.

Beispielhafte Layouts, unsere Rechnung; Mindestzahl an Hosts nach dem Single-Rack-Clustermodell von VCF 9.0 (29. September 2026).

Bei 12 Hosts passt ein Cluster zu vSphere Foundation oder zu VCF mit Geschäfts-Workloads in der Management-Domain und den vier Ressourcenpools. Zwei Cluster geben VCF eine eigene Management-Domain, um den Preis eines zweiten Reservehosts. Bei 30 Hosts gibt es den Datenbank-Cluster nur, wenn eine Lizenz Hosts zählt; andernfalls gehen seine 4 Hosts in die Produktion. Bei 60 Hosts spart ein einziger Produktionscluster mit 32 Hosts einen Host, mit zwei Hosts in Reserve liegt die Umgebung aber wieder bei sieben.

Die Reihenfolge der Designschritte stammt von uns:

1. Listen Sie die Workloads mit ihrem Spitzenbedarf, ihren an Hosts gebundenen Lizenzen, ihrer Sicherheitszone und ihrem GPU-Typ auf.
2. Markieren Sie die Gründe, die einen eigenen Cluster erzwingen, und streichen Sie die, die Ressourcenpools oder Tags abdecken können.
3. Wählen Sie VVF oder VCF je vCenter und unter VCF das Management-Modell Simple oder High Availability.
4. Dimensionieren Sie jeden Cluster auf seine Spitze bei Ausfall eines Hosts und unter vSAN auf das Minimum der Richtlinie plus einen Host.
5. Prüfen Sie jeden Cluster gegen die Configuration Maximums Ihres Releases und die 64 Hosts von vSAN.
6. Vergleichen Sie vor der Entscheidung die Reservehosts des Layouts mit denen eines Layouts mit einem Cluster weniger.

Unsere VMware-Optimierung umfasst die Host- und Cluster-Konsolidierung, in vereinbarten Wartungsfenstern. Schicken Sie uns Ihre Cluster, Hosts und Workloads je Cluster über das Formular unten.

Was wir tun

Eurokommerz hält den Vertrag und liefert die Hardware zur Lösung, mit EU-Rechnungsstellung, Lieferung und Garantie nach europäischem Recht; die Arbeit übernimmt unser Engineering-Partner Vixen.UNO. Im Rahmen der VMware-Optimierung auditiert Vixen.UNO Ihre VMware-Umgebung und Ihre Lizenzen, konsolidiert Hosts und Cluster und modernisiert vSphere, vSAN, NSX und VCF, clusterübergreifende Migrationen eingeschlossen. Änderungen laufen in vereinbarten Wartungsfenstern mit einem Rollback-Plan für jede Etappe, danach folgt Support unter einem vereinbarten SLA. Das erste Gespräch ist kostenlos, und der Preis des technischen Assessments steht vor Beginn fest.

FAQ