Lab: Deploy 3-Node vSAN Cluster with ESA

VCF 9.0Intermediatevcp-foundation⏱ 135 min

Objectives

Lab: Deploy 3-Node vSAN Cluster with ESA

Prerequisites

VCF lab environment deployed and operational

Lab Environment

Standard VCF lab environment for vSphere Foundation 9.0 Administrator

Tasks

Task 1 Lab: Deploy 3-Node vSAN Cluster with ESA

vSAN cluster deployment with ESA requires understanding the single-tier NVMe architecture, host compatibility, and the critical importance of network validation before enabling vSAN. A single misconfigured host can prevent cluster formation.

Step 1

Provision 3x ESXi 9.0 hosts with ≥2 NICs (management/vSAN) each

Step 2

Create vDS with vSAN port group (VLAN 100, MTU 9000)

Step 3

vCenter UI → Clusters → Create new cluster → Enable vSAN (Intelligent Storage Management)

Step 4

Add all 3 hosts to cluster

Step 5

Mark disks: vSAN UI → Disk Management → Select SSD as cache, HDD as capacity

Step 6

Verify quorum: vSAN cluster UI → vSAN health check → Cluster quorum = 3/3 healthy

Step 7

Create VM storage policy: vCenter UI → Policies → VM Storage Policies → Create → Set FTT=1 (RAID-1), Dedup/Compression enabled

Step 8

Deploy test VM on vSAN datastore using policy

Step 9

Monitor: vSAN cluster → Performance → Latency/Throughput graphs

Validation Gate

Check: After enabling vSAN ESA on 3 nodes, verify: vSAN health is green, all disks are claimed, storage policy matches design, and cross-host vmkping with jumbo frames succeeds

Expected: vSAN health dashboard shows all checks green, 3 hosts contributing capacity, default storage policy matches design specification (RAID-1 or RAID-5 as planned)

Common Errors

Enabling vSAN before verifying network connectivity between all hosts

Fix: vSAN requires dedicated VMkernel adapters on a shared VLAN with MTU 9000. Before enabling vSAN, run: vmkping -d -s 8972 <peer_vSAN_IP> from each host to every other host. If any ping fails, do not enable vSAN — the cluster will form in a degraded state with split-brain risk.

Mixing NVMe and SAS/SATA drives in an ESA cluster

Fix: vSAN ESA requires ALL-NVMe drives. Mixing NVMe with SAS/SATA forces the cluster into OSA mode (or fails entirely). Verify all drives are NVMe via: esxcli storage core device list | grep -i nvme. If any non-NVMe drives are present, remove them from vSAN claim before enabling ESA.

Not setting the correct storage policy after cluster creation

Fix: Default vSAN storage policy is RAID-1 FTT=1. If your design calls for RAID-5 (capacity-optimized), you must create a custom storage policy and set it as default. VMs deployed with the wrong policy consume more capacity than planned (RAID-1 = 2× vs RAID-5 = 1.33×).

Forgetting to enable deduplication and compression on ESA

Fix: vSAN ESA supports inline deduplication and compression with minimal performance impact (unlike OSA where it was a significant overhead). Enable it during cluster creation — enabling post-deployment triggers a full data rewrite that can take hours and impact I/O performance.

Final Validation

Lab completed successfully

✓ All steps completed → No errors observed

Cleanup / Restore

• Revert to snapshot if needed

Design Reflection (VCDX)

vSAN cluster design decisions — RAID level, dedup/compression, disk group configuration — are common VCDX defense questions. Be prepared to justify your RAID choice with capacity waterfall math and performance data.

Requirements

Deploy 3-node vSAN ESA cluster with all-NVMe
Configure appropriate RAID policy per workload tier
Enable deduplication and compression for space efficiency

Constraints

ESA requires all-NVMe — no mixed drive types
Minimum 3 hosts for RAID-1, 4 for RAID-5
MTU 9000 required on vSAN network end-to-end

Assumptions

All NVMe drives pass VMware Compatibility Guide check
Network infrastructure supports jumbo frames

Risks

Split-brain from vSAN network misconfiguration
Capacity planning error from wrong default storage policy

⚠ Known Pitfalls (from Community KB)

Enabling vSAN without verifying jumbo frame (MTU 9000) connectivity — vSAN will work with MTU 1500 but at significantly reduced performance.

Enabling dedup/compression after deployment triggers a full data rewrite — always enable during initial cluster creation.

Mark complete