vSAN for Dummies, Part 5: Running It for Real

You can build a cluster, break it intelligently, and reason about policies and capacity. What separates that from running vSAN is mostly habits — plus three or four pieces of context this final part fills in. By the end you’ll be past “dummy” and into “dangerous enough to be useful.”

The network is the backplane — treat it like one

Here’s the reframe that makes vSAN networking intuitive: in the old world, the storage array had an internal backplane moving data between controllers and shelves. In vSAN, your Ethernet network is that backplane. Every write your VMs make crosses it at least once (to reach the second copy). Nobody would accept a flaky backplane in a storage array; that’s the standard your vSAN network inherits.

Practically, for production:

• 10 Gbps minimum, 25 GbE standard for new builds — and dedicated or properly QoS-protected, not sharing a congested trunk with everything else.
• Two uplinks, always — a single NIC failure shouldn’t turn into a storage event.
• Low, stable latency matters more than bandwidth. Resyncs eat bandwidth; VMs feel latency. A network that spikes under load produces the vSAN weirdness that’s hardest to diagnose, because it looks like storage.

Smaller environments can demonstrate the concepts, but production performance numbers must come from the workload, hardware, and network design in front of you.

Read the health check like an operator, not a dashboard

Monitor → vSAN → Skyline Health runs dozens of checks, and beginners treat it as a green-light/red-light. Operators read it differently — as three families of question:

1. Cluster agreement (partitions, unicast agent lists, time sync): do all hosts share the same view of reality? Failures here explain almost everything downstream.
2. Hardware health (disk state, controller firmware, HCL): is the physical layer telling me something early? This is where you catch a dying capacity device weeks before it dies — the graphs found my failing NVMe at home nine days before SMART complained.
3. Data state (objects out of compliance, resync backlog): is the machine currently keeping its promises, and if not, is it converging?

# Anything resyncing? (should usually be zero)
esxcli vsan debug resync summary get

# Any objects not meeting policy?
esxcli vsan debug object health summary get

OSA vs ESA in one honest paragraph each

Everything this series taught used the Original Storage Architecture (OSA): disk groups, a cache device fronting capacity devices. It remains common in existing estates.

Express Storage Architecture (ESA) — available from vSAN 8 on qualified all-NVMe hardware — removes disk groups entirely: every device serves capacity, caching happens in a new log-structured layer, and the RAID-5/6 write penalty from part 4 largely evaporates, making capacity-efficient policies the default choice. If you’re deploying new hardware that qualifies, ESA is the answer. The concepts you’ve learned — objects, components, witnesses, policies, quorum, slack space — carry over unchanged; it’s the disk-group plumbing that disappears.

Two-node and stretched: the same idea, relocated

Part 1 promised this. Both designs solve the same problem — what if I only have two places to put data? — with the same tool: an external witness.

• Two-node vSAN (branch offices): two hosts hold the data copies; a small witness appliance runs somewhere else (typically the main datacenter) and votes. Quorum math from part 3, unchanged — the witness just lives outside the cluster.
• Stretched clusters (two buildings/sites): each site holds a full copy of every object, the witness sits at a third location, and a whole site can fail with VMs restarting at the survivor. The costs are real: inter-site bandwidth, latency limits (≤5 ms round trip), and a design discipline all its own.

You now know enough to see these for what they are: quorum arithmetic wearing different topologies.

The day-2 routine

Everything else this series taught, compressed into the habits that keep clusters boring:

• Weekly: glance at Skyline Health trends and capacity growth — you’re watching the slope, not the value. Slack space (part 4) erodes gradually, then suddenly.
• Before every host operation: resync zero? Objects healthy? Correct maintenance mode option for the duration? (Part 3’s table.)
• Before every upgrade: vSAN, ESXi and vCenter versions move together; check compatibility, upgrade vCenter first, and let the health check’s “build recommendation” do its job. Disk format upgrades that follow major versions are online but generate resync — schedule them like the I/O events they are.
• After every significant change: validate an agreed test flow and review object health, resync state, and alerts. Planned validation is safer than learning during an unplanned incident.

Where you are now, and where to go

Five parts ago, “the disk group’s cache tier is saturated” was noise. Now you can reason about cluster behaviour, predict failure outcomes, choose policies with reasons attached, plan capacity so self-healing works, and approach a maintenance window with the right questions. That’s a genuinely useful level of understanding.

From here, two directions depending on what you need next: operations depth — the resync storm post-mortem reads very differently now than it would have five parts ago; automation — the PowerCLI lifecycle patterns apply directly to vSAN maintenance gating. From there, use the current Broadcom design and operations guidance for your exact vSAN version and architecture before making implementation decisions.