TLDR-Box
Ein ESXi-Cluster verbindet mehrere ESXi-Hosts über einen vCenter-Server. Der Server ist Voraussetzung für HA, DRS und vMotion. Ohne vCenter läuft kein Cluster.
Die Dimensionierung richtet sich nach dem Workload-Profil. Zählen Sie CPU-Kerne, RAM, Festplatten und deren Typ (NVMe, SAS, SSD). Das Verhältnis von VM-Ressourcen zu Host-Ressourcen bestimmt die Anzahl der Hosts.
Lizenzierung beeinflusst die verfügbaren Features. HA ist Standard, DRS und vMotion benötigen Enterprise-Plus. Für Shared Storage wählen Sie vSAN, das für 2‑ bis 3‑Node-Cluster geeignet ist und einen Witness-Host erfordert.
Ein gut geplantes Cluster senkt Ausfallzeiten, nutzt Ressourcen effizient und erleichtert Wartung. Für Details lesen Sie die Nakivo-Blog (Englisch) und die Nakivo-Blog (Deutsch).
Bei der Auswahl von vSAN achten Sie auf die HCL-Kompatibilität und die erforderliche Witness-Appliance. Die Netzwerk-Topologie sollte mindestens zwei physische NICs pro Host für Management, vMotion und Storage enthalten. 10 GbE-Verbindungen sind für die meisten KMU ausreichend, um Replikation und HA-Heartbeats ohne Latenz zu gewährleisten.
Definition
Ein ESXi-Cluster ist eine logische Gruppe von ESXi-Hosts, die von einem vCenter Server verwaltet wird. Durch Cluster-Features wie HA, DRS und vMotion können virtuelle Maschinen automatisch auf verfügbare Hosts verschoben werden, um Ausfallzeiten zu minimieren und Ressourcen effizient zu nutzen. Der Cluster bildet die Basis für weitere Funktionen wie vSAN, NSX und Cloud-Integration.
Die HA-Funktion überwacht Hosts und startet VMs neu, wenn ein Host ausfällt. DRS verteilt die Workloads gleichmäßig, basierend auf CPU‑ und RAM-Auslastung. vMotion verschiebt laufende VMs ohne Unterbrechung, was Wartungsfenster verkürzt.
Ein Cluster ermöglicht auch die Nutzung von Shared Storage. vSAN bündelt lokale Laufwerke zu einem verteilten Datenspeicher, der ohne dedizierte SAN-Hardware auskommt. NSX erweitert die Netzwerk‑ und Sicherheitsfunktionen, indem es virtuelle Netzwerke und Firewalls bereitstellt.
Durch die zentrale Verwaltung im vCenter können Administratoren Policies definieren, Snapshots planen und Updates zentral ausrollen. So bleibt die Infrastruktur konsistent und skalierbar, während die Betriebszeit steigt.
Wie funktioniert ein ESXi-Cluster? – Schritt-für-Schritt-Liste
Ein ESXi-Cluster lässt sich nur über einen vCenter Server aufbauen und verwalten. Ohne diese zentrale Instanz bleiben HA, DRS und vMotion inaktiv. Der folgende Pfad hat sich in der Praxis bewährt.
- vCenter Server bereitstellen und Datacenter anlegen. Installieren Sie die Appliance (VCSA) oder nutzen Sie eine vorhandene Instanz. Im Inventory erstellen Sie zuerst ein Datacenter-Objekt als logischen Container. Die Nakivo-Anleitung zeigt die notwendigen Berechtigungen und DNS-Voraussetzungen.
- Cluster-Objekt erzeugen und Features einschalten. Im Datacenter legen Sie einen neuen Cluster an. Aktivieren Sie vSphere HA für Neustarts bei Host-Ausfall. DRS und vMotion setzen eine Enterprise Plus-Lizenz voraus – ohne diese Edition bleiben die Optionen ausgegraut. Die Broadcom-Dokumentation listet die genauen Abhängigkeiten.
- Hosts hinzufügen. Fügen Sie ESXi-Hosts per IP oder FQDN hinzu – entweder per Assistent (Import) oder manuell. Der Assistent prüft Kompatibilität, Networking und Lizenzschlüssel. Vinchin beschreibt typische Fehlerquellen wie abweichende Build-Nummern oder fehlende NTP-Sync.
- Cluster-Image (Desired State) zuweisen. Der vSphere Lifecycle Manager verwaltet ESXi-Basis, Vendor-Add-ons und Firmware in einem einzigen Image pro Cluster. Weisen Sie dieses Image dem Cluster zu, bevor Sie Hosts remediation durchführen – so bleibt der Desired State konsistent.
- Shared Storage bereitstellen. Binden Sie NFS-, iSCSI- oder vSAN-Datastores ein. Für KMU eignet sich vSAN ab zwei Knoten plus Witness-Appliance; achten Sie strikt auf die HCL. Legen Sie anschließend VM-Datastores an und prüfen Sie Multipathing-Policies.
- Netzwerk-Policies definieren. Erstellen Sie einen vSphere Distributed Switch (VDS) oder N-VDS. Definieren Sie getrennte VMkernel-Interfaces für Management, vMotion, vSAN/Storage und optional Fault Tolerance. 10 Gbit/s Uplinks sind für Cluster-Heartbeats und Replikation empfohlen.
- VMs migrieren und HA testen. Verschieben Sie Workloads per vMotion in den Cluster oder erstellen Sie neue VMs direkt auf dem Cluster-Datastore. Führen Sie einen kontrollierten HA-Test durch: Host in den Wartungsmodus versetzen und prüfen, ob VMs auf den verbleibenden Knoten neu starten.
Nach diesen sieben Schritten läuft der Cluster produktiv. Regelmäßige Image-Updates über den Lifecycle Manager und periodische HA-Drills halten den Betrieb stabil.
Cluster-Features und Lizenzierung
vCenter Server ist Voraussetzung für jeden ESXi-Cluster. Ohne ihn lassen sich HA, DRS oder vMotion nicht steuern.
Die Standard-Lizenz enthält High Availability. Damit können Hosts automatisch neu starten, wenn ein Knoten ausfällt. Für KMU reicht das häufig aus, wenn keine automatische Ressourcenverteilung gewünscht ist.
Distributed Resource Scheduler und Storage-DRS sind dagegen nur in vSphere Enterprise Plus oder in VMware Cloud Foundation verfügbar. Diese Features verteilen CPU, RAM und Speicher dynamisch, ohne dass Administratoren manuell VMs verschieben.
Die Lizenz bestimmt, wie viele Hosts ein Cluster aufnehmen kann. In der Standard-Lizenz sind bis zu 64 Hosts möglich, während Enterprise Plus die Grenze auf 128 Host-Knoten hebt. Außerdem steuert die Lizenz, welche Management-Tools zur Verfügung stehen, etwa vSphere Update Manager oder vSphere Replication.
Ein Cluster mit Standard-Lizenz kann also bis zu 64 Hosts betreiben, während Enterprise Plus bis zu 128 Hosts unterstützt. Für KMU, die keine DRS-Funktion benötigen, ist die Standard-Lizenz oft die kosteneffiziente Wahl.
Wenn Sie planen, DRS oder Storage-DRS einzusetzen, sollten Sie die Lizenzkosten prüfen. Die Entscheidung wirkt sich unmittelbar auf die Skalierbarkeit und die Automatisierung aus.
Enterprise Plus bietet zusätzlich vSphere Replication, vSphere Update Manager und vSphere Lifecycle Manager, die in der Standard-Lizenz fehlen. Diese Tools erleichtern Patch-Management und Replikation.
Für VCF-Umgebungen ist Enterprise Plus standardmäßig integriert, sodass Sie sofort alle erweiterten Funktionen nutzen können. Bei reinen ESXi-Hosts bleibt die Lizenzwahl entscheidend.
Weitere Details zur Lizenzierung finden Sie in der Artikelübersicht und im LinkedIn Learning-Kurs.
Dimensionierung nach Workload-Profil
Die Größe eines ESXi-Clusters richtet sich nach der Gesamtlast der virtuellen Maschinen. Dabei zählen CPU, RAM, Speicher-I/O und Netzwerk-Traffic. VMware empfiehlt, die Summe aller VM-Speicher‑ und CPU-Anforderungen zu ermitteln und einen Puffer für HA-Reservierung von ca. 10 % einzuplanen.
Für 2‑3 Hosts ist ein Minimum von 8 CPU-Kernen pro Host und 32 GB RAM sinnvoll, um typische KMU-Workloads abzudecken. Diese Werte decken die meisten Büro‑ und Anwendungsserver ab, die in kleinen bis mittleren Unternehmen eingesetzt werden. Weitere Empfehlungen betonen, dass die Host-Anzahl und die Ressourcen pro Host an die erwartete Last angepasst werden sollten.
Die Berechnung erfolgt in drei Schritten: Erstens, die aktuelle VM-Last erfassen. Zweitens, die Summe aller CPU‑ und RAM-Anforderungen bilden. Drittens, 10 % für HA-Reserven hinzufügen. Dieser Ansatz verhindert Engpässe und sorgt für ausreichende Redundanz.
Bei der Planung sollten Sie auch die Speicher-I/O-Kapazität berücksichtigen. SSD-basiertes Storage liefert höhere Durchsatzwerte, während SAS-Laufwerke für kostengünstigere, aber langsamere Workloads geeignet sind. Die Wahl des Speicher-Typs beeinflusst die benötigte Anzahl an Hosts, da SSD-Cluster oft weniger Hosts benötigen, um die gleiche Leistung zu erzielen.
Netzwerk-Traffic ist ein weiterer kritischer Faktor. Für Cluster-Interconnect und VM-Traffic empfiehlt VMware die Nutzung von 10 GbE-Verbindungen, um Latenz zu minimieren und die Leistung von vMotion und HA-Heartbeats zu sichern. Eine klare Trennung von Management‑, VM‑ und Storage-Traffic reduziert Störungen und erhöht die Zuverlässigkeit.
Zusammengefasst: Ermitteln Sie die Gesamtlast, addieren Sie einen 10 %‑Puffer, wählen Sie 8 CPU
vSAN-Cluster für KMU
vSAN liefert ein softwaredefiniertes Shared-Storage-System, das sich besonders für kleine Cluster mit zwei bis drei Nodes eignet. Für KMU hat sich die 2-Node-Konfiguration mit einem separaten Witness-Host oder einer Witness-Appliance bewährt, um das Quorum abzusichern. Die Witness-Instanz selbst trägt keine Workloads, sondern stellt lediglich das Tie-Breaker-Voting bereit. Dabei muss die Hardware strikt gegen den VMware Compatibility Guide (HCL) validiert werden – inkompatible Controller oder Laufwerke führen schnell zu Datenverlust oder Performance-Einbrüchen.
Ein 2-Node-vSAN-Cluster reduziert die Hardwarekosten gegenüber klassischen 3-Node-Setups, erfordert aber sorgfältige Kapazitätsplanung. Der Ausfall eines Nodes bedeutet 50 % Kapazitätsverlust, daher sollten Reserven für Rebuild-Vorgänge eingeplant werden. Die Witness-Appliance lässt sich als virtuelle Maschine auf einem bestehenden Host, auf einem Raspberry Pi oder als dediziertes Mini-System betreiben – Hauptsache, sie residiert in einer separaten Ausfallsdomain. Ein Community-Leitfaden zur ESXi-Cluster-Ersteinrichtung bestätigt, dass gerade bei ROBO-Szenarien die Witness-Platzierung über Erfolg oder Ausfall entscheidet.
Netzwerktechnisch verlangt vSAN ein dediziertes VMkernel-Interface für den vSAN-Traffic, idealerweise über 10 Gbit/s oder mindestens 25 Gbit/s bei All-Flash-Konfigurationen. Latenzen zwischen den Nodes und zum Witness dürfen 5 ms nicht überschreiten, sonst gefährdet das den Heartbeat-Mechanismus. Lizenzseitig setzt vSAN eine eigene Edition oder Enterprise Plus voraus; die Standard-Edition reicht nicht.
Bei der Inbetriebnahme hilft der vSAN-Cluster-Assistent im vCenter, der Validierungsschritte für Festplattengruppen, Claiming-Modus und Deduplikation/Compression durchläuft. Nach der Erstellung sollte ein Health-Check laufen, der Komponentenstatus, Resync-Aktivitäten und Kapazitätsauslastung prüft. Regelmäßige Firmware-Updates der Storage-Controller über vSphere Lifecycle Manager verhindern Kompatibilitätsprobleme im laufenden Betrieb.
Standardisierter Einrichtungs-Pfad
Der Aufbau eines ESXi-Clusters folgt einem reproduzierbaren Muster, das Fehlerquellen minimiert und die spätere Betriebssicherheit erhöht. Als erstes wird im vCenter Server ein Datacenter-Objekt angelegt, das als logischer Container für alle nachfolgenden Ressourcen dient. Darin erstellt der Administrator den Cluster und aktiviert vSphere HA; DRS wird nur bei entsprechender Enterprise-Plus-Lizenz freigeschaltet. Die Konfigurationsassistenten führen durch Admission-Control– und VM-Überwachungseinstellungen, die später den Failover-Verhalten bestimmen.
Im dritten Schritt werden die ESXi-Hosts dem Cluster hinzugefügt. Der vSphere Lifecycle Manager (vLCM) weist jedem Host das definierte Cluster-Image zu – ein „Desired State“, das ESXi-Basis, Vendor-Add-ons und Firmware versioniert bündelt. Damit entfällt das manuelle Patchen einzelner Server. Anschließend erfolgt die Anbindung des Shared Storage: NFS- oder iSCSI-Datastores werden gemountet, bei vSAN wird der Disk-Gruppen-Assistent durchlaufen und ein Witness-Host für Zwei- bis Drei-Knoten-Setups registriert. Die Speicher-Policies (Storage Policies) verknüpfen Kapazität mit Verfügbarkeitsregeln wie „FTT=1“.
Netzwerkseitig definiert der Administrator Distributed Switches (VDS/N-VDS) und legt VMkernel-Adapter für Management, vMotion und vSAN-Traffic auf getrennten physischen NICs oder VLANs an. MTU 9000 (Jumbo Frames) wird dort aktiviert, wo das Unterlay es unterstützt. Danach werden VMs per vMotion migriert oder neu provisioniert. Abschließend validiert ein HA-Test (gezielter Host-Ausfall) das Failover-Verhalten; Alarme für Heartbeat-Verlust, Datastore-Füllstand und vLCM-Compliance werden im vCenter oder via Monitoring-Integration (z. B. vRealize Operations) geschärft. Ein Runbook dokumentiert den gesamten Pfad für spätere Audits und Disaster-Recovery-Übungen.
Praxisbeispiele aus der KMU-Umgebung
Ein mittelständisches Finanzhaus betreibt einen 3-Host-Cluster mit vSAN und HA, auf dem rund 200 virtuelle Maschinen kritische Datenbanken hosten. Die hyperkonvergente Architektur spart teures externes Storage, während der Witness-Host im Quorum split-brain-Szenarien verhindert. Für die Dimensionierung der ESXi-Nodes orientierte sich das Team an den Vorgaben für Horizon-Workloads, um GPU- und Speicherlasten der VDI-Umgebung sauber abzubilden.
Ein produzierendes Unternehmen setzt auf einen 2-Host-Cluster mit DRS, der VMs der Produktionsplanung automatisch auf den leistungsstärkeren Host verschiebt, sobald Lastspitzen in der Fertigungssteuerung auftreten. Da DRS die Lizenz „Enterprise Plus“ voraussetzt, rechnete der IT-Leiter den Mehrpreis gegen manuelle Eingriffe und Ausfallzeiten gegeneinander auf. Die initiale Konfiguration folgte dabei einer praxisnahen Schritt-für-Schritt-Anleitung, die Netzwerk-Trennung für vMotion und Management bereits mit einbezieht.
Ein Managed-Service-Provider verwaltet einen 4-Host-Cluster über vSphere Lifecycle Manager (vLCM). Firmware-Updates und ESXi-Patches rollt er per Desired-State-Image zentral aus, ohne jeden Host einzeln zu patchen. Rolling Upgrades halten die Verfügbarkeit der Kundensysteme während des Wartungsfensters aufrecht. Die Erweiterung des Bestandsclusters dokumentierte der Anbieter in einer Referenzimplementierung, die Kapazitätsplanung, Netzwerk-Design und Compliance-Checks exemplarisch abbildet.