vSAN for Dummies, Part 2: How a vSAN Cluster Comes Together

Part 1 established the important shift: vSAN stores VM data as objects, then places components to satisfy storage policy. Before looking at failures and resync, it helps to understand the cluster as a system.

A vSAN cluster is four things at once

Hosts        -> provide CPU and local storage devices
Network      -> moves object data and cluster traffic between hosts
Datastore    -> presents the combined capacity to vSphere
Policy       -> decides how each VM object's components are placed

The cluster is not one large hard drive. Each object still lives on physical devices in specific hosts. The datastore is the convenient vSphere view of that distributed layout.

The network is part of the storage system

Every host contributes storage, and object components often live on different hosts. That means a VM write can involve network traffic even when the VM itself is local to an ESXi host.

For this reason, vSAN networking is not an afterthought. It needs predictable latency, sufficient bandwidth, redundancy appropriate to the design, and a clear failure-domain story. The exact link speed depends on workload and architecture, but a design should ask: what happens to VM I/O and resync traffic when one uplink, switch, or host is lost?

Hosts and disks: capacity is not the only limit

In Original Storage Architecture (OSA), disks are organized into disk groups with a cache device and capacity devices. In Express Storage Architecture (ESA), qualified NVMe devices participate differently and there are no traditional disk groups. The architecture changes, but the planning questions do not:

• How much usable capacity remains after policy overhead and operational headroom?
• Can the remaining hosts absorb a failure and the associated rebuild work?
• Are the devices and controllers supported for the chosen vSAN architecture?
• Does the network sustain normal VM I/O while objects resync?

The datastore is the view; objects are the reality

vSphere presents vsanDatastore as a single place to put VM files. Underneath, a VM disk is an object made of components. For a mirrored FTT=1 policy, a simplified layout is:

VM disk object
  |- data component on host A
  |- data component on host B
  `- witness component on host C

The datastore may show 1 TB free, but a new 200 GB protected disk does not simply need 200 GB of raw capacity. vSAN must have somewhere to place each required component while respecting the policy and host boundaries.

Storage policy is a design contract

Policy answers questions such as:

• How many failures must this object survive?
• Should protection use mirroring or erasure coding?
• Does placement need to span sites or fault domains?
• Is performance, availability, or capacity efficiency the priority?

Do not start with defaults because they are easy. Start with workload classes. A database, a disposable development VM, and a management appliance may not deserve identical protection or capacity cost. The policy is where that difference becomes explicit.

The design questions that prevent surprises

Question	Why it matters
What failure must it survive?	Determines FTT and possible cluster shapes
What is its actual used data and growth rate?	Drives capacity planning
How latency-sensitive is it?	Shapes device and network expectations
How long can it run reduced-protection?	Shapes repair and maintenance decisions
Which hosts or sites may hold components?	Determines fault-domain and stretched-cluster choices

The vSAN configuration wizard is the easy part. This reasoning is the part that keeps a cluster healthy after the first real failure.

What’s next

Part 3 explains what happens when components disappear: quorum, absent versus degraded states, repair timers, resync, and maintenance-mode choices.