VCF Demystified, Part 6: vSAN - Storage as a Platform Service
How vSAN fits into VCF 9: policy-based storage, capacity and failure planning, lifecycle dependencies, and why storage design cannot be separated from private-cloud operations.
vSAN is the storage layer in many VCF designs, but it is more than a datastore beneath the management domain and workload domains. It is a policy-driven distributed system whose capacity, network, hardware, and failure behaviour affects every service above it.
Storage policy becomes a platform decision
vSAN stores VM data as objects and places their components according to storage policy. That means the platform must decide what different workload classes require: failure tolerance, capacity efficiency, site placement, and performance behaviour.
Application request
-> storage class or policy
-> vSAN object placement
-> capacity, network, and failure-domain consumptionThe policy is not a property to choose after a VM is created. It is part of the service definition. VCF Automation and operating teams need a shared understanding of which policies map to which workload classes and what they cost in usable capacity.
Capacity is resilience capacity
Free space is not automatically safe capacity. vSAN needs room to satisfy policy, rebuild failed components, process resync, and absorb planned maintenance. A cluster that is technically running but cannot place a rebuilt component is carrying risk even if applications are currently available.
An effective VCF capacity conversation includes:
- Actual workload data, growth, snapshots, and policy overhead.
- The usable capacity remaining after a host or fault domain failure.
- Network headroom for normal I/O and resync.
- Hardware support and lifecycle alignment with the VCF release.
vSAN and VCF operations
VCF Operations brings storage health into the fleet view, but it does not remove the need to interpret it. Operators should connect object compliance, resync state, host capacity, policy changes, and planned lifecycle activity. A storage warning may be the earliest visible signal of a broader platform constraint.
The design rule
Treat vSAN as a service with an explicit resilience budget. The cluster must have enough devices, hosts, network, and spare capacity to keep the policy promises made by the workloads above it. The vSAN for Dummies series and the vSAN storage policy explainer go deeper into that logic.