Raw Capacity Is Not Usable Capacity, and Usable Is Not Deployable

Written and maintained by Haink's infrastructure team · Resiliency figures verified against Microsoft and VMware documentation, 29 August 2026 · authorized-channel sourcing, serial-verified

Hyperconverged sizing goes wrong in a specific and repeatable way. Someone adds up the virtual machines, divides by what a node holds, adds one for resiliency, and produces a number. That number is almost always too small, because it skips two deductions that the storage layer takes before any workload sees a byte — and because the platform's own minimum may already be higher than the answer.

This page works through all three, with the numbers from the vendors rather than from a rule of thumb.

Deduction one: the resiliency scheme

Every hyperconverged storage layer keeps more than one copy of your data, or the parity equivalent. How much more depends on the scheme, and the schemes are not comparable across platforms without doing this arithmetic explicitly.

Two things fall out of this table that catch people. First, erasure coding gets more efficient as the cluster grows — S2D dual parity runs at 50% on four servers and 80% at sixteen with all-flash, so a small cluster pays a materially worse ratio than the marketing figure. Second, tolerating two failures roughly doubles the storage bill on mirroring schemes. If the requirement says "must survive two node failures", that is a capacity decision as much as an availability one.

Deduction two: the rebuild reserve

This is the one that gets left out. When a node fails, the cluster rebuilds the missing copies onto the surviving nodes — which requires somewhere to put them. A cluster sized to be exactly full at steady state cannot rebuild, which means the first failure leaves you degraded until hardware is replaced rather than for the length of a rebuild.

Practically: reserve roughly one node's worth of usable capacity in a cluster that must self-heal from a single failure, and two nodes' worth if the requirement is to survive a second failure during the rebuild window. On a six-node cluster that is 17–33% of usable capacity that never holds workload. It is not waste; it is the thing that makes the availability number true.

The smaller the cluster, the worse this ratio — which is a large part of why very small HCI clusters are less economical than they look.

Deduction three: the platform's own floor

Before any of the above, the stack has a minimum. VMware Cloud Foundation requires four nodes for a management domain; vSphere Foundation three hosts, or two plus a witness appliance for remote sites; Nutanix runs single-node at the edge but three for production; Azure Local starts at one machine and scales to sixteen. Those floors and the appliance families that serve them are compared in which ThinkAgile series for which hypervisor.

The floor frequently exceeds what the workload needs. A modest estate on Cloud Foundation buys a fourth node because the platform says so, not because the VMs require it.

A worked example

The requirement. Three hundred virtual machines averaging 4 vCPU, 12 GB RAM and 120 GB of disk. That is 1,200 vCPU, 3.6 TB of RAM and 36 TB of virtual machine data.

The node. A current-generation 2U host configured with two 32-core processors (64 physical cores), 1 TB of memory and all-flash NVMe. Note the deliberate choice of a mid-range processor rather than the 86-core maximum — under per-core licensing the largest part is rarely the right buy, for reasons worked through in choosing a generation under per-core licensing.

Reading the result. The binding constraint is CPU at five nodes — until the resiliency scheme is chosen. On vSAN ESA with RAID-6 the scheme itself demands six, so the cluster is six nodes before N+1. Add the resiliency node and it is seven. On Nutanix RF2 the scheme allows three, so CPU still binds at five, plus N+1 makes six — but the storage bill is 72 TB raw against 54 TB, because mirroring is less efficient than erasure coding.

That is the whole point of doing this arithmetic per platform: the same workload lands on a different node count and a very different storage purchase depending on a scheme chosen at design time. Sizing on "300 VMs, so eight nodes" produces a number with no relationship to any of these.

Where the ratios come from, and how to get them right

• Use committed resources, not allocated. The single largest error in HCI sizing. VM configurations describe what was requested; sustained utilisation describes what is used, and the gap is routinely two to three times. Size on the second and keep the first as a sanity check.
• Consolidation ratio is a policy, not a fact. Four vCPU per physical core is conservative and safe for mixed enterprise workloads. Six to eight is achievable on light workloads with good monitoring. Latency-sensitive and licensed-by-core database workloads may want one-to-one. Pick the ratio deliberately, per workload class, and write it down — it is the number auditors of the design will ask about.
• Memory is more often the binding constraint than CPU on general virtualization, and it is the one that cannot be oversubscribed comfortably. When memory binds, more cores per node do not help and you are buying licence obligation for nothing. How you reach the capacity target also decides bandwidth — see memory population rules.
• Check the drive fit, not just the capacity. A node can be short of drive bays before it is short of terabytes, particularly on 1U hosts and on liquid-cooled configurations where the internal layout changes — the gap between chassis is larger than most designs assume, as the 1U against 2U comparison sets out.
• Network is a constraint at rebuild time, not at steady state. Storage replication traffic is modest in normal operation and heavy during a rebuild. Size the fabric for the rebuild, or accept that a failure degrades production performance for as long as the rebuild takes.

Why three-node clusters behave worse than the number suggests

Three nodes satisfies the minimum for several schemes, which makes it look like the economical answer. In operation it has a particular weakness: during planned maintenance the cluster is running on two nodes, which means it is simultaneously at reduced capacity and unable to tolerate a failure. A three-node cluster does not really have N+1 during a patching window — it has N.

Four nodes changes that materially, and it is the reason a lot of production designs land there even when three would technically run. If budget forces three, the compensating control is scheduling: maintenance windows during genuinely low-risk periods, with the acceptance written down rather than assumed.

The sizing checklist

1. Pull committed CPU, memory and storage consumption, not allocated.
2. Choose the consolidation ratio per workload class, deliberately.
3. Compute node count from CPU and from memory separately — take the larger.
4. Choose the resiliency scheme, then multiply data volume by its raw factor from the table above.
5. Add the rebuild reserve: one node's worth of usable capacity, or two if surviving a second failure during rebuild is required.
6. Apply the platform's minimum node count — and use it if it is higher than everything above.
7. Add N+1 for resiliency, and consider four nodes as the practical floor for anything with a maintenance window.
8. Check drive bays and network fabric against the resulting configuration.
9. Price the licence at the resulting total core count over the full term, before the processor model is fixed.

Frequently asked questions

How many nodes do we need for an HCI cluster?

Compute the number four ways and take the largest: node count from committed CPU, node count from committed memory, the minimum required by the resiliency scheme you have chosen, and the platform's own floor. Then add N+1. For anything with a maintenance window, four nodes is a better practical floor than three.

How much raw storage do we need per terabyte of data?

It depends entirely on the scheme. Two terabytes for a two-way mirror or Nutanix RF2, three for a three-way mirror or RF3, 1.5 for vSAN ESA RAID-6 (4+2) or RAID-5 (2+1), and 1.25 for RAID-5 (4+1). Azure Local dual parity runs at 2.0 on four servers and improves to 1.25 for all-flash at sixteen or more.

What is the rebuild reserve and how much should it be?

Free usable capacity kept so the cluster can rebuild missing copies after a node failure. Reserve roughly one node's worth for self-healing from a single failure, two nodes' worth if a second failure during the rebuild must be survivable. Without it the cluster stays degraded until hardware is physically replaced.

Why does erasure coding get more efficient on bigger clusters?

Because parity is spread across more nodes, so the proportional cost of protection falls. Microsoft documents Azure Local dual parity at 50% efficiency on four servers, 66.7% at seven, and up to 80% for all-flash at sixteen or more. A small cluster does not get the headline ratio.

What consolidation ratio should we assume?

Four vCPU per physical core is conservative and safe for mixed enterprise workloads; six to eight is achievable on light workloads with good monitoring; latency-sensitive or core-licensed database workloads may need one-to-one. Choose it per workload class and record the choice — it is the assumption that most changes the answer.

Is a three-node cluster enough?

It satisfies several platform minimums, but during planned maintenance it runs on two nodes, which means reduced capacity and no failure tolerance at the same time. Four nodes removes that condition, which is why many production designs land there even when three would technically run.

Does the network matter for sizing?

At steady state, less than people expect. During a rebuild, a great deal — replication traffic spikes and the fabric determines how long the cluster stays degraded. Size the network for the rebuild case, not the average.

Related

• Which ThinkAgile series for which hypervisor — the platform floors and the node specifications behind them
• HPE four-socket scale-up — DL580 Gen12 against two DL380, and why 4U buys only memory
• HPE memory population rules — why 12 DIMMs per processor runs at half the bandwidth of 8
• HPE DL360 vs DL380 Gen12 — 1U or 2U, and why memory is not the reason
• Choosing an HCI platform — whether hyperconverged is the right shape at all
• VxRail vs Nutanix — the platform comparison underneath the sizing
• VMware exit — the hardware decision — why node counts do not survive a platform change unchanged
• Cloud repatriation for VMs and storage — translating a cloud bill into physical demand before sizing
• ThinkSystem V3 vs V4 — why the largest processor is rarely the right node
• Four-socket and scale-up — when a single workload will not fit in one two-socket node
• Server refresh and consolidation · buying at project scale · stock and lead times

Sources

• Microsoft Learn — fault tolerance and storage efficiency on Azure Local and Windows Server clusters (two-way mirror 50%, three-way 33.3%, dual parity 50–80%, minimum server counts)
• Microsoft Learn — plan volumes on Azure Local
• vSAN ESA and the minimum number of hosts with RAID-1/5/6 (host minimums and capacity overhead per scheme; adaptive RAID-5)
• VMware — vSAN design guide
• The Nutanix Bible — AOS data efficiency (replication factor and erasure coding behaviour)
• Lenovo Press — ThinkSystem SR650 V4 product guide (node capacity figures used in the worked example)