vSAN for Dummies, Part 1: What vSAN Actually Is (No Buzzwords)

Welcome to the first part of a series that assumes exactly nothing about storage. If you’ve ever nodded along in a meeting while someone said “the disk group’s cache tier is saturated” — this series is for you. By the end of it you’ll be able to build, break and reason about a vSAN cluster.

The one-sentence version

vSAN takes the local disks sitting inside your ESXi hosts and pools them into one big shared datastore that every host in the cluster can use.

That’s it. That’s the product. Everything else is detail about how it does that safely and fast. But that sentence hides a genuinely radical idea, so let’s unpack it.

The old world: storage is a separate box

Traditionally, VM storage lives on a storage array — a dedicated appliance full of disks, connected to your hosts over a storage network (Fibre Channel or iSCSI). The array is its own product with its own management interface, its own firmware, its own support contract, and often its own dedicated administrator.

This works fine. It has worked fine for decades. But it means:

• Every VM read and write travels across a network to the array and back.
• Capacity planning, zoning, and LUN management are their own skill set.
• The array is a single (if usually redundant) box everything depends on.

The vSAN world: storage lives in the hosts

vSAN deletes the separate box. Instead, each ESXi host contributes its own local disks to a cluster-wide pool. The hosts talk to each other over a normal Ethernet network, and vSAN’s software keeps track of where everything is stored.

   ┌──────────┐   ┌──────────┐   ┌──────────┐
   │  esxi-01 │   │  esxi-02 │   │  esxi-03 │
   │  [disks] │   │  [disks] │   │  [disks] │
   └────┬─────┘   └────┬─────┘   └────┬─────┘
        └───────── vSAN network ──────┘
                       │
            one shared vSAN datastore

When a VM writes data, vSAN decides which hosts’ disks that data lands on — and here’s the key part — it always lands on more than one host.

So that’s what “HCI” means

You’ve seen the acronym: HCI, hyperconverged infrastructure. Strip the marketing and it means exactly what the diagram above shows — compute and storage converged into the same boxes, managed as one system. The servers that run your VMs are the storage array.

Why does the industry make such a fuss about it? Because it changes what scaling looks like. In the old world, running out of storage meant a forklift: size a new array, migrate onto it, retire the old one. In the HCI world, you add another host — and you get more compute and more storage and more storage performance in the same motion, because every host contributes disks to the pool. Growth becomes incremental instead of episodic.

The trade — and this series won’t hide it — is that compute and storage now share fate. Rebooting a host doesn’t just move VMs; it temporarily removes a slice of your storage. That coupling is where most real-world vSAN surprises come from, and it’s why parts 3 and 5 of this series spend so much time on host maintenance. HCI isn’t better or worse than the old world; it’s a different set of failure modes, and the whole point of this series is making those failure modes intuitive.

vSAN is VMware’s implementation of the idea (Nutanix being the other name you’ll hear). Its distinguishing feature is that it’s built into ESXi itself — not a virtual appliance bolted on top — which is why enabling it in part 2 will feel almost anticlimactic.

Why more than one host? Failures to Tolerate

If your VM’s data lived only on the host it runs on, losing that host would mean losing the data. So vSAN stores redundant copies, and the rule for how much redundancy is called FTT — Failures to Tolerate.

• FTT=1 means “this data must survive one host failing.” vSAN keeps two full copies of the data on two different hosts (plus a small tie-breaker called a witness on a third — more on that in part 3).
• FTT=2 means two hosts can die simultaneously; vSAN keeps three copies.

That last point is worth repeating, because it’s the thing that has no equivalent in the old world: on a traditional array, the RAID level was baked into the LUN when it was created. On vSAN, protection is a storage policy — a named set of rules you assign to VMs, change later, and let vSAN restructure data to match.

The vocabulary you need (and only this)

Five terms cover 90% of every vSAN conversation:

Term	Plain meaning
Object	A thing vSAN stores — a VM’s disk, its swap file, a snapshot.
Component	A piece of an object placed on a specific host’s disk. Copies are components.
Disk group	How a host’s disks are organized: one fast cache device fronting capacity devices.
Storage policy	The rules (FTT and friends) assigned to a VM.
Resync	vSAN copying data around to get back to what the policy promises.

Don’t memorize these — you’ll absorb them by use. Just know that when the vSAN UI says “3 of 9 components resyncing”, it means: some pieces of some VMs’ redundant copies are being rebuilt right now.

The cluster shape matters

Why three hosts? A common FTT=1 mirrored object needs two data copies plus a witness, each on a different host. Three hosts are therefore the smallest shape that can satisfy that policy locally. Two-node and stretched designs use an external witness to solve the same quorum problem; Part 5 returns to both topologies.

What’s next

In Part 2 we look at the cluster as an architecture: network, devices, datastore, capacity, and the storage-policy decisions that determine where objects can live.