Storage Core Concepts — vSAN for VCF
Objectives
- List principal and supplemental storage options for VCF
- Compare vSAN OSA (disk groups, cache+capacity) vs ESA (single pool, all-NVMe)
- Explain vSAN data services including dedup, compression, encryption, erasure coding
- Describe SPBM and FTT requirements (3 hosts for FTT≤1, 5 hosts for FTT=2)
- Explain stretched vSAN cluster architecture and requirements (<5ms RTT, 10Gbps)
Prerequisites
Active Holodeck VCF 9.0 lab or access to VCF documentation
Required skills:
- Basic VMware terminology
Tasks
Task 1 VCF Storage Options & vSAN Architecture
Master storage options in VCF and deep-dive into vSAN OSA vs ESA
Principal storage (where VMs deploy): vSAN ESA, vSAN OSA, NFS v3/v4.1, VMFS on Fibre Channel, vSphere Virtual Volumes. Supplemental storage (additional capacity): NFS v3/v4.1, VMFS on FC, vVols. vSAN is preferred — fully integrated into VCF stack, no NFS share/permission config needed, VMs provisioned via built-in storage policies. NFS must be accessible from VCF network with read/write permissions. VMFS on FC: LUN must be pre-accessible and datastore pre-created.
OSA (Original Storage Architecture): two-tiered disk groups (cache tier + capacity tier), SSDs/NVMe for cache, SSDs/NVMe/magnetic for capacity. ESA (Express Storage Architecture): single storage pool, all-NVMe only, 4x better storage efficiency for compressible workloads, native zero-cost snapshots/clones without performance degradation. ESA designed for modern NVMe hardware evolution. ESA minimum host memory: 128 GB (significantly higher than OSA). The 'up to 4x storage efficiency' claim from VMware marketing refers to combined benefits of compression, deduplication, and single-tier architecture — actual efficiency varies by workload I/O pattern.
[HOLODECK NOTE] Holodeck simulates vSAN with virtual disks on the physical host's datastore. Neither OSA disk groups nor ESA NVMe pools use real physical disks — all I/O goes through the nested virtualization layer. vSAN performance metrics (IOPS, latency) in Holodeck are not representative of production. ESA's all-NVMe requirement is satisfied by virtual NVMe controllers in nested ESXi. Deduplication/compression ratios may differ from real workloads.
vSAN data services: deduplication and compression, encryption (at-rest + in-flight), RAID 5/6 erasure coding, high-performance snapshots (ESA). vSAN File Services: NFS/SMB file shares served directly from vSAN cluster. File Service resource requirements: ESX host minimum requirements must be met. Fault domains provide rack-level fault tolerance.
Validation Gate
Check: Calculate usable capacity for: 8 hosts × 6 NVMe × 3.84TB, RAID-1, including slack and metadata overhead
Expected: Raw: 184.32TB → RAID-1 (/2): 92.16TB → Slack (×0.75): 69.12TB → Metadata (~2%): ~67.7TB usable
Common Errors
Task 2 Storage Policy Based Management & Stretched Clusters
Understand SPBM and stretched vSAN cluster architecture
VM storage policies define performance, availability, and compliance requirements. Key capabilities: FTT (Failures to Tolerate — determines data copies), stripe width, force provisioning. Policies applied per-VM or per-VMDK. Policy compliance monitoring ensures VMs meet their storage SLA. FTT=0 or 1 requires minimum 3 hosts; FTT=2 requires minimum 5 hosts.
Architecture: two active availability zones + one witness site. Each AZ = own fault domain. Requirements: vSAN Enterprise license, <5ms RTT between sites, 10Gbps bandwidth minimum, third witness site (can be separate location). Witness host/appliance requirements: network connectivity to both AZs, sufficient resources. Provides resilience across geographic locations for DR.
[HOLODECK NOTE] Stretched vSAN clusters require <5ms RTT between sites and 10 Gbps witness link. Holodeck runs on a single physical host — you cannot meaningfully simulate cross-site latency, witness placement, or site failure scenarios. Stretched cluster configuration can be studied architecturally but not tested for real fault-domain behavior in Holodeck.
Beyond vSAN as principal storage, VCF supports supplemental storage: NFS v3 and v4.1 (network-attached, must be accessible from VCF network with read/write permissions), VMFS on Fibre Channel (LUN must be pre-provisioned and accessible to ESX hosts, datastore pre-created), and vSphere Virtual Volumes (vVols, policy-driven storage on compatible arrays). Supplemental storage can be added after workload domain creation — e.g., vSAN principal + NFS ISO store, or NFS principal + FC supplemental for specific workloads. For exam objective 5.7: understand troubleshooting iSCSI (network path, initiator config, CHAP auth), NFS (export permissions, firewall rules, DNS resolution), and FC (zoning, LUN masking, path failover via PSA/NMP).
Validation Gate
Check: Explain the capacity multiplier for: FTT=1 RAID-1, FTT=1 RAID-5, FTT=2 RAID-1, FTT=2 RAID-6
Expected: FTT=1 RAID-1: 2×, FTT=1 RAID-5: 1.33×, FTT=2 RAID-1: 3×, FTT=2 RAID-6: 1.5×
Common Errors
Design Reflection (VCDX)
vSAN capacity waterfall calculations are one of the most frequently asked VCDX questions. Be prepared to walk through raw → RAID → slack → usable on a whiteboard. Panelists also test whether you understand when to use RAID-1 vs RAID-5/6 for different workload tiers.
Requirements
- Understand vSAN ESA vs OSA architectures
- Calculate capacity waterfall from raw to usable
- Apply appropriate RAID policies per workload tier
Constraints
- RAID-5 requires 4+ hosts, RAID-6 requires 6+ hosts
- vSAN slack space (25%) is not configurable
- ESA requires all-NVMe — no HDD or SAS support
Assumptions
- All drives are same capacity within a cluster (homogeneous)
- Network bandwidth sufficient for rebuild operations (25GbE recommended)
Risks
- Capacity exhaustion during rebuild if slack space is consumed
- Double encryption overhead degrading performance without security benefit
⚠ Known Pitfalls (from Community KB)
References
- vSAN 9.0 Planning and Deployment GuideTier 1 — Official
- vSAN ESA Architecture OverviewTier 1 — Official