CRITICAL INFRA
Loading critical CVEs…
ALL EXPLOITED
Loading…

Studiu de caz: cluster VMware vSAN pe 2 noduri (Dell R7615)

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).

S5148F-ON #1 S5148F-ON #2 VLT R7615 — nod 1AMD EPYC · 384 GB RAM2x NVMe 2TBcache4x HDD 12TBcapacitate4x placi reteaR7615 — nod 2AMD EPYC · 384 GB RAM2x NVMe 2TBcache4x HDD 12TBcapacitate4x placi reteaal 3-lea ESXivSAN Witness + vCenter trafic witness (metadata)

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.

Discutam despre proiectul tau →