Ein Kunde wollte einen VMware-Cluster, der den Ausfall eines ganzen Servers uebersteht, ohne ein teures externes SAN zu kaufen. Wir bauten ein hyperkonvergentes 2-Knoten-vSAN, mit einem kleinen dritten Host als Witness. Hier ist die reale Konfiguration, mit den verwendeten Befehlen.
Die Anforderung: HA ohne externes SAN
Zwei Server fuer die VMs, mit klarer Regel: faellt ein ganzer Server aus, laufen die Anwendungen ohne Datenverlust weiter. Das Budget erlaubte kein dediziertes Storage-Array, also gingen wir hyperkonvergent mit vSAN — die Datentraeger der zwei Server bilden einen einzigen replizierten Pool.
Kurz gesagt: faellt ein Server komplett aus, haelt der andere alle virtuellen Maschinen am Laufen — die Daten liegen auf beiden.
Hardware und Topologie
Zwei Dell PowerEdge R7615 (AMD EPYC, je 384 GB RAM), mit gestuftem Storage: 2x NVMe 2TB (Cache) + 4x HDD 12TB (Kapazitaet) pro Knoten — hybrides vSAN. Ein dritter (kleinerer) ESXi-Host betreibt die vSAN Witness Appliance und vCenter. Netzwerk: 4 NICs pro Server, zwei Dell S5148F-ON (25GbE)-Switches.
Das Netzwerk: 4 NICs, 2 Switches, Redundanz
Die zwei S5148F-ON-Switches haben wir mit VLT (Virtual Link Trunking) verbunden — sie erscheinen als einer, sodass eine NIC oder ein Switch ohne Unterbrechung ausfallen kann. Die 4 NICs pro Server: zwei dediziert fuer vSAN + vMotion, zwei fuer Management + VM-Verkehr, jedes Paar mit je einem Link zu jedem Switch. Getrennte VLANs und Jumbo Frames (MTU 9000) im vSAN-Netz.
# dediziertes vSAN-vmkernel mit Jumbo Frames (auf jedem Knoten)
esxcli network ip interface add -i vmk2 -p vSAN-PG
esxcli network ip interface ipv4 set -i vmk2 -I 10.10.30.11 -N 255.255.255.0 -t static
esxcli network ip interface set -i vmk2 -m 9000
esxcli vsan network ip add -i vmk2
# End-to-End-MTU-Test (keine Fragmentierung)
vmkping -I vmk2 -d -s 8972 10.10.30.12ESXi- + vCenter-Installation
Wir installierten ESXi auf allen 3 Hosts (2 Datenknoten + Witness). Die vCenter Server Appliance haben wir auf den dritten ESXi gelegt, damit sie nicht vom verwalteten Cluster abhaengt. Dort haben wir auch die vSAN Witness Appliance ausgerollt (ein spezielles nested ESXi, das nur Metadaten haelt — keine echten Daten).
Distributed Switch und Port-Groups
Ein vSphere Distributed Switch (vDS) ueber die zwei Knoten, mit Port-Groups auf VLANs: Management, vMotion, vSAN, VM. Teaming ueber beide Switches fuer Redundanz.
# PowerCLI — vDS + vSAN-Port-Group
New-VDSwitch -Name vds-vsan -Location DC -Mtu 9000 -NumUplinkPorts 4
New-VDPortgroup -VDSwitch vds-vsan -Name vSAN-PG -VlanId 30
Add-VDSwitchVMHost -VDSwitch vds-vsan -VMHost esx01,esx022-Knoten-vSAN-Konfiguration: Disk-Groups
Auf jedem Knoten erstellten wir 2 Disk-Groups, je mit 1x NVMe als Cache + 2x HDD als Kapazitaet. So beschleunigt das NVMe Schreib- und Lesevorgaenge, und die HDDs liefern guenstige Kapazitaet.
# PowerCLI — Disk-Group (fuer das zweite NVMe + naechste 2 HDDs wiederholen)
New-VsanDiskGroup -VMHost esx01 \
-SsdCanonicalName naa.<nvme1> \
-DataDiskCanonicalName naa.<hdd1>, naa.<hdd2>
# Pruefung vom ESXi
esxcli vsan storage list
esxcli vsan cluster getWitness + Storage-Policy
Ein 2-Knoten-vSAN-Cluster nutzt einen Witness (die dritte Stimme), um Split-Brain zu vermeiden. Die Storage-Policy ist FTT=1 Mirror: jeder Block hat eine Kopie auf jedem Knoten, und der Witness haelt nur die Witness-Komponente.
# PowerCLI — Witness an den 2-Knoten-Cluster anbinden
Set-VsanClusterConfiguration -Configuration (Get-Cluster CL01) \
-WitnessHost witness01 -WitnessDiskGroup (Get-VsanDiskGroup -VMHost witness01)
# Standard-Policy: FTT=1 (RAID-1), Force Provisioning off
Get-SpbmStoragePolicy -Name 'vSAN Default Storage Policy'Validierung
Vor der Produktion: vSAN Health komplett gruen, proaktive Tests (VM-Erstellung, Netzwerkleistung) und eine Ausfallsimulation — wir schalteten einen Knoten aus und bestaetigten, dass die VMs verfuegbar bleiben (HA startet sie bei Bedarf neu).
# Health + Tests
Get-VsanView; Test-VsanClusterHealth -Cluster CL01
esxcli vsan health cluster list
# HA + DRS am Cluster
Set-Cluster CL01 -HAEnabled $true -DrsEnabled $true -DrsAutomationLevel FullyAutomatedErgebnis
Ein hyperkonvergenter Cluster, der den Ausfall eines ganzen Servers uebersteht, ohne externes SAN, mit ~48 TB nutzbar (nach Mirror) und NVMe fuer Geschwindigkeit. Das Management ist in vCenter zentralisiert, und vSAN Health ueberwacht den Zustand kontinuierlich. Wir entwerfen, installieren und nehmen ihn in unser 24/7-Monitoring auf.