vSAN for Dummies, Part 4: Policies Beyond Mirroring (and Where Your Capacity Goes)
RAID-5/6 erasure coding explained with actual arithmetic, when stripe width helps, why thin provisioning is the default, and the capacity planning rule that keeps clusters healthy.
So far every protected object in our examples has been a RAID-1 mirror: FTT=1 with RAID-1 means two full copies, so 100 GB of VM consumes 200 GB of cluster capacity. Simple, fast — and at scale, expensive. This part is about the other tools in the policy box, and about the question every vSAN admin gets asked monthly: where did all the capacity go?
OSA RAID-5/6: paying with math instead of copies
Erasure coding stores your data plus computed parity instead of full copies. If a piece goes missing, vSAN recalculates it from what survives — same guarantee as mirroring, less capacity spent. In the traditional OSA model, the common layouts look like this:
| Policy | Layout | 100 GB VM consumes | Overhead | Min hosts |
|---|---|---|---|---|
| FTT=1, RAID-1 | 2 copies + witness | 200 GB | 100% | 3 |
| FTT=1, RAID-5 | 3 data + 1 parity | 133 GB | 33% | 4 |
| FTT=2, RAID-1 | 3 copies + witnesses | 300 GB | 200% | 5 |
| FTT=2, RAID-6 | 4 data + 2 parity | 150 GB | 50% | 6 |
Read the last column twice: OSA RAID-5 needs four hosts because the data-plus-parity stripe has four pieces, and each must live on its own host. A three-node OSA lab cannot do that erasure-coded layout — which itself is the lesson: policies are constrained by cluster shape. Many production design meetings are secretly about this table’s last column.
ESA changes the RAID-5 shape
Express Storage Architecture changes the practical answer. ESA can use adaptive RAID-5 2+1 on three hosts or fault domains, and 4+1 on larger eligible topologies.
| ESA policy | Layout | 100 GB VM consumes | Overhead | Min hosts |
|---|---|---|---|---|
| FTT=1, RAID-5 | 2 data + 1 parity | 150 GB | 50% | 3 |
| FTT=1, RAID-5 | 4 data + 1 parity | 125 GB | 25% | 5 |
| FTT=2, RAID-6 | 4 data + 2 parity | 150 GB | 50% | 6 |
So why doesn’t everyone use RAID-5/6 everywhere? In OSA, the price is paid in writes. Updating a mirrored block means writing it twice. Updating an erasure-coded block means reading old data and parity, computing, and writing multiple pieces — several I/O operations per write, plus more work during rebuilds. The OSA-era rule of thumb:
- RAID-1 for write-heavy, latency-sensitive things (databases, VDI).
- RAID-5/6 for capacity-hungry, read-mostly things (file servers, backups, archives).
Stripe width: the setting you probably shouldn’t touch
Policies have a “Number of disk stripes per object” setting that splits each copy across multiple capacity devices. More parallelism sounds free — it isn’t. Wider stripes mean more components per object (remember the per-host and per-cluster component limits), more coordination, and rebuilds that touch more devices. Modern vSAN already distributes hot objects sensibly.
Leave it at 1 unless you’ve measured a specific bottleneck. A beginner series tells you this bluntly so a consultant doesn’t have to tell you expensively.
Thin by default, and the day that surprises you
vSAN objects are thin-provisioned unless a policy says otherwise: a 500 GB virtual disk consumes what’s written to it, not 500. This is the right default — and it means the datastore’s “free space” is a promise, not a fact. Ten VMs with 500 GB disks on a 3 TB datastore all fit comfortably at 20% full and catastrophically don’t at 80%.
The policy’s “Object space reservation” setting exists for the exceptions — set 100% for that one database whose disk must never hit a full datastore. For everything else, the fix isn’t reservations; it’s watching growth, which brings us to the rule that actually matters.
The capacity rule: rebuilds need somewhere to go
Think back to part 3. When a host died for good, vSAN rebuilt its components onto the remaining hosts’ free space. Now the punchline: if your cluster is nearly full, vSAN can survive a failure but not repair it. You’d run at reduced redundancy until a human adds capacity — under time pressure, which is the worst procurement strategy known.
The old field rule was to keep something like 25–30% free as slack space. Treat that as legacy OSA sizing shorthand, not a universal modern product rule. From vSAN 7 U1 onward, capacity reserve separates this into operations reserve and host rebuild reserve. In VCF 9.1, Effective Capacity and Auto-RAID make the capacity conversation more policy-aware. The design principle is unchanged: leave enough usable headroom for resync, rebuild, and maintenance, and use the current version’s capacity model to prove it.
Read compliance as a design signal
An object can be accessible while not complying with its policy. For example, a RAID-5 policy may be valid in principle but impossible for a three-host cluster to satisfy. vSAN reports that the desired layout cannot currently be achieved; it does not invent extra hosts or silently weaken the policy. This distinction — desired state versus current state — is the mental model for everything vSAN does.
What you’ve learned
Erasure coding trades some write/rebuild complexity for capacity and demands the right cluster shape; stripe width is best left alone; thin provisioning makes free space a forecast, not a fact; and reserved capacity is what makes the self-healing from part 3 actually work. In Part 5, the finale: the network vSAN deserves, reading health as an operator, ESA versus OSA, where stretched and two-node clusters fit, and what “decent at vSAN” looks like from here.