Three Nodes, Same as Your Three Hosts: A Sizing Sanity Check
A prospect runs 180 VMs on 3 ESXi hosts (2 × 20-core 2.6 GHz CPUs, 768 GB RAM each), with 640 vCPUs and 3.1 TB vRAM configured, and 55 TB consumed on a 70 TB SAN growing about 1.1 TB per month. vRealize reports a peak cluster CPU demand of 105 GHz at p95 host CPU of 58%, and a peak memory demand of 2.2 TB. They want N+1 resilience, three years of growth, and a single Nutanix cluster in one room. The account manager has already sent a quote for "three NX-1065 nodes - same as your three hosts," and the prospect is asking why that would not be fine, and whether they can keep RF2.
1. Is the three-node quote defensible on compute and memory? Walk through the sizing.
Read the worked answer
It fails on memory before CPU is even interesting.
- Memory: the sizing number is peak demand (2.2 TB), not configured vRAM (3.1 TB) - but even using demand, three nodes give 3 × 768 GB = 2.3 TB, minus roughly 20-32 GB per node reserved for the CVM and hypervisor overhead. Net usable is about 2.2 TB against 2.2 TB of demand: ~100% utilisation with zero headroom, and no failover room at all. N+1 on three nodes means running the estate on two nodes = ~1.5 TB, well under demand. Four nodes minimum (4 × 768 = 3.07 TB, ~2.9 TB usable, 2.2 TB demand ≈ 74% - tolerable with growth).
- CPU: 105 GHz peak across 3 × 104 GHz = 312 GHz looks generous, and even N+1 at 4 nodes leaves ~416 GHz. Configured vCPU:pCPU of 640:120 is aggressive but irrelevant if demand is measured; confirm with actual GHz, not vCPU counts.
- Rule: size on the binding constraint. Here it is memory plus storage, so the "same as your three hosts" mapping is a coincidence, not a design.
Also challenge the requirement: a single cluster in one room has no site resilience regardless of node count, and N+1 does not cover a room-level event.
2. Size the storage at RF2 with three years of growth, and state what could reduce the number.
Read the worked answer
Baseline math: 55 TB consumed + (1.1 TB/month × 36) = 94.6 TB usable at year three, before snapshots and any replication. At RF2, raw ≈ 2× usable ≈ 189 TB, and good practice keeps utilisation around 70-75%, so plan for roughly 250-270 TB raw - often more once snapshot retention and a second-site copy are added.
What can legitimately reduce it:
- Measure used, not provisioned. The 55 TB may include zeroed or thin-provisioned blocks; dedupe/compression on all-flash typically reclaims 1.3-2× on VDI and clone-heavy estates, less on media or encrypted data - verify with real data, not the datasheet ratio.
- Erasure coding (EC-X) on all-flash can push effective overhead closer to ~1.3-1.5× instead of 2× for cold, sequentially-written data, but only on healthy clusters and not for the hot working set.
- Separate growth assumptions for snapshots and archives - move cold data off the cluster rather than buying raw capacity for it.
What must not reduce it: RF3 ambitions. If the business later asks for two-node tolerance, minimum five nodes and ~1/3 usable - a completely different quote. Size RF at the start and write it into the design document.
3. What pre-sales questions and validation steps do you insist on before the quote is reissued?
Read the worked answer
Questions that change the number:
- Performance profile: peak IOPS, read/write ratio, working set, and latency SLOs per workload. Averages hide the 15-minute batch that defines the cluster.
- Peak vs. average demand: are the 105 GHz and 2.2 TB true peaks with concurrency, or averaged? Any seasonal peaks (year-end, month-end)?
- Growth composition: is 1.1 TB/month data, snapshots, or log/archive noise? How much is cold?
- Recovery expectations: local snapshot retention, offsite replication (adds a second site's capacity), backup integration.
- Dependencies that do not migrate: VMware-only features, raw device mappings, shared VMDK clusters, physical appliances, or appliances with strict L2 adjacency.
- Platform constraints: rack power and U space, 10/25 GbE availability, and whether a single-room cluster is acceptable or a second failure domain is required.
Validation: run the numbers through Nutanix Sizer with the real workload data rather than host-for-host mapping; present the sizing with assumptions written down and the N+1 and growth cases shown separately. Where the estate is unusual, propose a PoC or a performance benchmark rather than arguing from a spec sheet - and re-issue the quote with four nodes minimum plus a clear upgrade path.