Un client voia un cluster VMware rezistent la caderea unui server intreg, fara sa cumpere un SAN extern scump. Am construit un vSAN hiperconvergent pe 2 noduri, cu un al 3-lea host mic drept witness. Iata configuratia reala, cu comenzile folosite.
Cerinta: HA fara SAN extern
Doua servere care sa tina VM-urile, cu regula clara: daca pica un server intreg, aplicatiile continua fara pierdere de date. Bugetul nu permitea un storage array dedicat, deci am mers pe vSAN hiperconvergent — discurile din cele doua servere formeaza un singur pool replicat.
Pe scurt: daca un server se strica de tot, celalalt tine in continuare toate masinile virtuale — datele exista pe ambele.
Hardware si topologie
Doua Dell PowerEdge R7615 (AMD EPYC, 384 GB RAM fiecare), cu stocare pe niveluri: 2x NVMe 2TB (cache) + 4x HDD 12TB (capacitate) per nod — vSAN hibrid. Al treilea host ESXi (mai mic) ruleaza vSAN Witness Appliance si vCenter. Retea: 4 placi per server, doua switch-uri Dell S5148F-ON (25GbE).
Reteaua: 4 placi, 2 switch-uri, redundanta
Cele doua switch-uri S5148F-ON le-am legat in VLT (Virtual Link Trunking) — apar ca unul singur, deci o placa sau un switch poate cadea fara intrerupere. Cele 4 placi per server: doua dedicate vSAN + vMotion, doua pentru management + trafic VM, fiecare pereche cu cate un fir spre fiecare switch. VLAN-uri separate si jumbo frames (MTU 9000) pe reteaua vSAN.
# vmkernel dedicat pt vSAN, cu jumbo frames (pe fiecare nod)
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
# test MTU end-to-end (nu trebuie fragmentare)
vmkping -I vmk2 -d -s 8972 10.10.30.12
Instalare ESXi + vCenter
Am instalat ESXi pe cele 3 hosturi (2 noduri de date + witness). vCenter Server Appliance l-am pus pe al treilea ESXi, ca sa nu depinda de clusterul pe care il gestioneaza. Tot acolo am desfasurat vSAN Witness Appliance (un ESXi nested special, care tine doar metadate — nu date reale).
Distributed switch si port groups
Un vSphere Distributed Switch (vDS) peste cele doua noduri, cu port-group-uri pe VLAN-uri: management, vMotion, vSAN, VM. Teaming pe ambele switch-uri pentru redundanta.
# PowerCLI — vDS + port group pt vSAN
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,esx02
Configurare vSAN 2-noduri: disk groups
Pe fiecare nod am creat 2 disk groups, fiecare cu 1x NVMe drept cache + 2x HDD drept capacitate. Asa NVMe-ul accelereaza scrierile si citirile, iar HDD-urile dau capacitatea ieftina.
# PowerCLI — disk group (repeta pt al doilea NVMe + urmatoarele 2 HDD)
New-VsanDiskGroup -VMHost esx01 \
-SsdCanonicalName naa.<nvme1> \
-DataDiskCanonicalName naa.<hdd1>, naa.<hdd2>
# verificare din ESXi
esxcli vsan storage list
esxcli vsan cluster get
Witness + politica de stocare
Un cluster vSAN de 2 noduri foloseste un witness (al treilea vot) ca sa evite split-brain. Politica de stocare e FTT=1 mirror: fiecare bloc are o copie pe fiecare nod, iar witness-ul tine doar componenta de martor.
# PowerCLI — asociezi witness-ul la clusterul 2-node
Set-VsanClusterConfiguration -Configuration (Get-Cluster CL01) \
-WitnessHost witness01 -WitnessDiskGroup (Get-VsanDiskGroup -VMHost witness01)
# politica implicita: FTT=1 (RAID-1), Force provisioning off
Get-SpbmStoragePolicy -Name 'vSAN Default Storage Policy'
Validare
Inainte de productie: vSAN Health tot verde, teste proactive (VM creation, network performance), si o simulare de cadere — am oprit un nod si am confirmat ca VM-urile raman disponibile (HA le reporneste daca e nevoie).
# sanatate + teste
Get-VsanView; Test-VsanClusterHealth -Cluster CL01
esxcli vsan health cluster list
# HA + DRS pe cluster
Set-Cluster CL01 -HAEnabled $true -DrsEnabled $true -DrsAutomationLevel FullyAutomated
Rezultat
Un cluster hiperconvergent care supravietuieste la caderea unui server intreg, fara SAN extern, cu ~48 TB utilizabili (dupa mirror) si NVMe pentru viteza. Managementul e centralizat in vCenter, iar vSAN Health monitorizeaza permanent starea. Il proiectam, il instalam si il dam in monitorizarea noastra 24/7.