vSAN for Dummies, Part 3: Failures, Quorum, and Rebuilds

The value of a distributed storage system is revealed during a failure. vSAN behaviour is predictable once you separate three questions: is the object accessible, does it still meet policy, and should vSAN rebuild it now?

Quorum: why a witness exists

Take a common mirrored FTT=1 object:

data component A  - host 01
data component B  - host 03
witness           - host 02

The witness does not hold a copy of VM data. It participates in the voting logic that lets vSAN decide which components form a valid object. This prevents a split-brain style situation where two isolated pieces of a cluster both believe they should accept writes.

If host 03 disappears, the object can remain accessible through data component A and the witness on host 02. It is still accessible, but it no longer has the full redundancy that the policy requested.

Absent is not degraded

State	Meaning	Typical response
Absent	vSAN cannot currently see a component and waits for it to return	Observe and allow the repair timer to work
Degraded	A component is treated as failed or the repair delay has expired	Rebuild components elsewhere if placement allows

The repair delay exists to avoid unnecessary rebuilds for short interruptions such as a host reboot or transient network outage. Rebuilding a large object moves real data and consumes capacity and bandwidth. Starting immediately for every brief absence would make routine maintenance needlessly disruptive.

Resync: vSAN returning to the policy promise

Resync is the process of bringing an object back into compliance. It can occur after a component failure, a policy change, rebalancing, or some maintenance operations.

Object is accessible but reduced protection
  -> missing component remains absent past the repair delay
  -> vSAN finds compliant placement on remaining resources
  -> data is copied and a new component is created
  -> object returns to policy compliance

Resync is good and necessary. It is also background I/O that competes with normal VM workloads. That is why operational teams check resync state before putting another host into maintenance or making broad policy changes.

Maintenance mode is a declaration of intent

When an administrator puts a host into maintenance mode, vSAN needs to know how much data movement is appropriate. The options describe a trade-off, not a universally correct choice:

Option	What it prioritizes	Typical use
Ensure accessibility	Keeps affected objects available with minimal movement	Short, controlled host work
Full data migration	Moves all relevant components away first	Long absence or host retirement
No data migration	Moves nothing	Exceptional cases with a conscious risk decision

The right choice depends on the policy, cluster capacity, expected maintenance duration, and whether another failure during the work would be tolerable. A short firmware reboot and a host decommission are different problems even though both begin with maintenance mode.

How to reason about a failure

1. Is the object accessible to the VM?
2. Does the object meet its assigned storage policy?
3. Is the missing component absent, degraded, or actively rebuilding?
4. Is resync making progress without harming production latency?
5. Does the cluster still have capacity and fault domains for compliant placement?

This sequence keeps the response proportional. A brief absent component may need only observation. A degraded component with no remaining placement capacity is a design risk that needs attention before the next failure turns it into an outage.

What’s next

Part 4 compares mirroring and erasure coding, showing how policy, cluster size, and capacity efficiency constrain each other.