N+1 Cluster Planner

Vendor-agnostic cluster resilience planner for Hyper-V, VMware vSphere, Proxmox, Nutanix, OpenStack, or any homogeneous-host cluster. Compare N+0, N+1, N+2, and 2N usable capacity side-by-side across cores, RAM, storage, and IOPS — with configurable operational headroom and shareable URL state.

Live Virtualization Planner N+1 Cluster Resilience Capacity Planning Failover

Cluster definition

Define your cluster of homogeneous hosts.

Total hosts in the cluster (including any reserved spare capacity).

Per-host specs

Raw local/SAN-attached storage. Set to 0 for compute-only clusters.
Sustained IOPS the storage subsystem of one host can deliver. Set to 0 to skip.

Operational headroom

Realistic operating ceiling per host. Designing to 100% leaves no room for memory ballooning, OS overhead, monitoring agents, or temporary spikes. 80% is a sensible default.

Resilience comparison

Side-by-side: how much capacity survives each failure model.

Total cluster (raw, no headroom)

Total cores —
Total RAM —
Total storage —
Total IOPS —

Usable capacity by resilience model

Model Spare hosts Cores RAM Storage IOPS % of total
Enter cluster specs to see comparison.
Values shown are at the configured target utilisation (80%). Raw numbers above ignore headroom — divide back by your target utilisation for theoretical maxima.

Resilience models explained

What each model actually buys you in production.

N+0 — No redundancy Every host runs production workloads. A single host failure means workload eviction or downtime — failed VMs cannot restart anywhere because there's no spare capacity. Acceptable for dev/test, lab clusters, or non-critical workloads. Not for production.
N+1 — Single host failure tolerance Reserves capacity equal to one host. If any single host fails, surviving hosts absorb the workload. Standard for most production clusters. Cost: one host's worth of capacity is "wasted" in steady state — but it's not actually wasted, it's insurance.
N+2 — Two simultaneous failures Reserves two hosts' capacity. Survives a host failure during a maintenance window where another host is already down. Worth the cost for high-criticality workloads, large clusters where simultaneous failure odds are non-trivial, or when patching cycles overlap with risk windows.
2N — Full duplication Half the cluster is "spare". Tolerates losing half the hosts simultaneously — extreme resilience for the most critical workloads. Common in financial/medical/regulated settings or for active-passive site-level designs. Effectively halves usable capacity.

Fields you should pay extra attention to

Inputs that materially change the planning outcome.

1. Target utilisation Designing to 100% looks great on paper and breaks the first time someone runs a backup. 70-85% is realistic for production. Lower for memory-bound workloads (databases) where ballooning hurts performance.
2. Number of hosts vs N+1 efficiency N+1 on a 3-host cluster means 33% reserved capacity. N+1 on a 10-host cluster means 10%. Larger clusters amortise the redundancy cost — but failure domains and blast radius grow too. There's a sweet spot around 6-12 hosts for most workloads.
3. Storage type matters more than capacity Local storage in N+1 doesn't migrate with VMs — losing a host with local-only storage means losing those VMs unless you have replication. Use shared SAN, hyperconverged (vSAN/Nutanix/Ceph), or per-VM replication. The "usable storage" number assumes the storage layer survives host failure.
4. Don't forget the network and management plane N+1 protects compute and storage. It doesn't protect the management cluster (vCenter, SCVMM, Nutanix Prism), the network fabric, or the storage controllers. A "N+1" cluster with single-pathed networking is N+0 in disguise.
5. N+2 vs 2N is rarely a true choice 2N usually means two physically separate clusters in different rooms or sites — not just twice the hosts in the same rack. If you can't physically separate them, you have N+(N/2) at best, vulnerable to shared failures (PDU, switch, room cooling).
6. Headroom and resilience compound A 5-host cluster at N+1 with 80% headroom doesn't give you 4 × 80% = 320% capacity. It gives you 4 × 80% = 3.2 hosts' worth of usable workload — about 64% of nominal total. Stack the constraints carefully when sizing.