vSAN turns the disks inside your ESXi hosts into one shared datastore. It is simple to enable, which is exactly why it is often sized in a hurry. These four mistakes are the ones we see most when we are asked to fix a vSAN cluster after go-live.
1. Sizing on Raw Capacity
vSAN protects data by keeping more than one copy, or by using erasure coding. That protection uses space. With mirroring (RAID-1) and one failure to tolerate, every VM uses twice its size. RAID-5 erasure coding uses less: 1.33 times in the Original Storage Architecture (OSA, at least four hosts), and 1.5 or 1.25 times in the Express Storage Architecture (ESA), depending on how many hosts the cluster has.
Always size on usable capacity after the storage policy is applied, not on the raw total of the disks.
2. Leaving No Free Space
vSAN needs free space to work properly. It uses it for rebuilding data when a host or disk fails, for moving data during maintenance, and for snapshots and policy changes. Since vSAN 7 Update 1, VMware calls this Reserved Capacity: an Operations Reserve plus a Host Rebuild Reserve.
The right amount depends on your cluster size and disks, so use the official vSAN sizing tool to calculate it. The old rule of thumb of 25 to 30 percent free space applies to vSAN 6.7 Update 3 and earlier. In vSAN 9.1, the new Effective Capacity view already takes these overheads into account in the free capacity it shows. Whatever the version, a cluster that runs nearly full looks fine on a normal day and gets into trouble on a bad one.
3. Using Parts That Are Not Certified
vSAN is sensitive to the exact disks, controllers and network cards in each host, and to their firmware and driver versions. Every part should be on the Broadcom Compatibility Guide for vSAN, and the easiest way to get this right is to buy certified vSAN ReadyNodes.
4. Treating the Network as an Afterthought
Every write in vSAN crosses the network to reach another host. A slow or shared link becomes a slow datastore. All-flash vSAN OSA needs at least 10 GbE. vSAN ESA also needs at least 10 GbE, and VMware recommends 25 GbE or faster. Use redundant switches and keep vSAN traffic separate from busy traffic such as backups.
A Simple Example
Say your VMs need 40 TB today and grow 20 percent a year. Three years from now that is about 69 TB. With RAID-1 mirroring it becomes about 138 TB, and vSAN's reserved capacity comes on top of that. Sizing on the 40 TB figure alone would fill the cluster almost at once.
Common Questions
OSA or ESA?
vSAN Express Storage Architecture (ESA) is the newer design for all-NVMe hosts, with better performance and space efficiency. The Original Storage Architecture (OSA) still suits existing hardware. The right choice depends on your hardware, budget and vSAN version, and is best made at design time.
Can We Add Hosts Later?
Yes. vSAN grows by adding hosts or disks. Plan the network and host model up front, so new hosts match the old ones and the cluster stays balanced.
A Quick Checklist
- Capacity sized as usable space after the storage policy
- Free space reserved for rebuilds and maintenance
- Enough hosts to rebuild after one host failure
- Every component on the compatibility guide, ideally as ReadyNodes
- Network speed and redundancy checked for the vSAN architecture you use
How We Help
We size vSAN clusters from your real workload data, choose certified hardware with you, and build and test the cluster before go-live. For existing clusters, our health check shows whether capacity, policies and network are still right for today's load.
