A vSAN cluster is only as supportable as the hardware underneath it, and vSAN is unusually fussy about that hardware. Buy a server that merely looks adequate and you can end up with a configuration VMware will not support, a controller that behaves badly under load, or a node that cannot be matched when you expand. A vSAN ready node sidesteps all of that: it is a server configuration certified end to end for vSAN, and in the post-Broadcom world, where licensing and bundling have shifted, getting the hardware exactly right matters more than ever. This is how the certification, the disk-group model and node sizing actually work.
What a ready node actually is
A vSAN ready node is not a special product line, it is a specific, validated server configuration. The server vendor takes a model, fixes the CPU, memory, storage controller, cache and capacity devices, boot device and network adapter to a tested recipe, and certifies the whole bill of materials against a vSAN version. The value is that every component is on the compatibility list together, with firmware and driver combinations that have been tested, rather than each part being individually compatible but never validated as a set.
That matters because vSAN problems are usually not about a single bad part, they are about a combination: a controller that is fine on paper but queues poorly, a drive firmware that interacts badly with the driver, a mismatch nobody tested. A ready node removes that risk and makes support straightforward, because you can point at a certified configuration rather than defending a bespoke build. We size ready-node-equivalent servers on certified hardware from the Dell and HPE ranges.
OSA vs ESA: two architectures, two recipes
vSAN now has two architectures and they want different hardware. The original storage architecture, OSA, uses disk groups: each group pairs one cache device with several capacity devices, and writes land on the cache tier before destaging to capacity. It works with a mix of flash and, historically, hybrid drives, and it puts real weight on the endurance and speed of the cache device because every write passes through it.
The express storage architecture, ESA, introduced with the newer vSAN generations, drops the cache-plus-capacity disk group in favour of a single tier of high-performance NVMe where every drive contributes to both performance and capacity. ESA expects an all-NVMe node with fast drives and a capable network, and it changes the sizing maths because there is no separate cache device to specify. Decide which architecture you are building for first, because the certified node lists and the component recipe differ between them.
- •OSA: disk groups of one cache device plus capacity devices; cache endurance and speed are critical
- •ESA: single tier of high-performance NVMe; every drive serves performance and capacity
- •ESA wants all-NVMe nodes and a fast, low-latency network; OSA tolerates more mixed media
- •Certified ready-node lists are version- and architecture-specific; match the list to your build
The storage controller is the part people get wrong
On OSA in particular, the storage controller makes or breaks a cluster. vSAN wants the controller in pass-through mode so each device is presented natively, and it cares about the controller's queue depth because a shallow queue throttles the whole node under concurrent load. A controller that is technically on the list but has a low queue depth or a quirky driver is a classic cause of disappointing vSAN performance, which is why the certified recipe pins an exact controller and firmware.
ESA leans on NVMe drives connected more directly, reducing the controller's role, but the principle stands: you do not improvise the storage path on a vSAN node. Use the controller, mode and firmware the certification specifies, and present devices to vSAN the way it expects, exactly as we insist on host bus adapter pass-through for other software-defined storage builds using parts from our host bus adapters range.
Sizing a node and a cluster
Size from usable capacity after the resilience policy, not from raw drives. vSAN protects data with a storage policy, commonly mirroring for smaller clusters or erasure coding for larger ones, and that policy consumes capacity: a mirror roughly halves usable space, erasure coding costs less but needs more nodes. Decide the policy, then work back to raw capacity per node, and always leave slack capacity so the cluster can rebuild after a host failure without filling up, since a vSAN datastore that runs too full degrades and limits rebuilds.
At the cluster level, three nodes is the practical floor and four is a far healthier minimum because it lets you lose a host and still rebuild comfortably. Balance the nodes identically so the cluster is predictable, give each node enough cache or NVMe and a fast network, and plan the next node at the same time as the first build. We size both the node and the cluster, with the right drives from our SSD and NVMe range, in our server configuration service.
Why certification matters more after Broadcom
The Broadcom acquisition reshaped how vSAN is licensed and bundled, with capacity-based entitlements changing the economics of how much storage you put in each host. That makes right-sizing the hardware to the licensed capacity a commercial decision, not just a technical one: over-provisioning drives you are not licensed to use wastes money, and under-provisioning forces an early expansion. Getting the node configuration to match the entitlement is now part of the buying conversation.
It also raises the cost of an unsupported configuration. With the platform consolidated, you want a clean, certified hardware story so support is never in question, and so a future expansion can match the existing nodes. Build on certified ready-node configurations, document the exact recipe, and keep nodes identical, so the cluster stays supportable and expandable for its whole life.