Sizing a Three-Year Fixed-Capacity Proposal
A manufacturing customer wants a Nutanix proposal for 150 VMs: 20 ERP application servers, four SQL databases, 90 general VMs, and 10 engineering workstations. Current usable data is 6 TB and the customer expects 30% growth over three years. They require RF2 and N+1 node redundancy, and want 20% free capacity for snapshots and operational headroom. A candidate node model has 2 x 1.92 TB SSDs and 4 x 4 TB HDDs, 512 GB RAM, and two 10 GbE ports. The customer's existing switch has four free 10 GbE ports and the rack has 10U free. The ERP vendor requires 8 vCPUs and 64 GB RAM per application server; the SQL servers require 16 vCPUs and 256 GB RAM each; the engineering workstations need 8 vCPUs and 32 GB RAM. General VMs are assumed at 4 vCPUs and 16 GB RAM. The customer has not provided IOPS data, and the CIO wants a three-year fixed-capacity quote.
1. Calculate the minimum node count from a capacity perspective and from a memory perspective, and state which drives the design.
Read the worked answer
Capacity calculation:
- Current usable: 6 TB.
- Three-year growth: 6 TB × 1.30 = 7.8 TB.
- Snapshot/headroom: 7.8 TB × 1.20 = 9.36 TB usable.
- Each node has 4 × 4 TB HDD = 16 TB raw; after RF2 roughly 8 TB usable before CVM/metadata overhead. Three nodes give about 24 TB usable raw-equivalent, but N+1 means one node can be lost; after losing one node, two nodes remain with 32 TB raw and about 16 TB usable. That still exceeds 9.36 TB. So capacity alone needs 3 nodes.
Memory calculation:
- ERP: 20 × 64 GB = 1,280 GB.
- SQL: 4 × 256 GB = 1,024 GB.
- General: 90 × 16 GB = 1,440 GB.
- Engineering: 10 × 32 GB = 320 GB.
- Total = 4,064 GB; with 20% headroom = 4,877 GB.
- With 512 GB per node and N+1, 10 nodes give 5,120 GB but lose one node leaves 4,608 GB, which is short. 11 nodes leave 5,120 GB after N+1, so memory needs 11 nodes.
Memory drives the design to at least 11 nodes; CPU and IOPS still need validation.
2. What missing discovery data could change the node count or model?
Read the worked answer
Missing discovery that could change the node count or model:
- IOPS and latency: peak/steady IOPS, read/write ratio, block size, working set, and whether the SQL databases are latency-sensitive. Without this, SSD cache sizing and node count are guesses.
- CPU: actual cores/GHz and oversubscription policy; 664 vCPUs may fit 11 nodes, but only if the CPU model and contention targets are acceptable.
- Memory: confirmed per-VM reservations, not just configured RAM; SQL and ERP often have minimum memory requirements.
- Growth and retention: snapshot retention, replication, and backup copies on the cluster.
- Physical: 10U and four free 10 GbE ports may constrain the model; check power and cooling per node.
- Support: ERP/SQL vendor support on AHV, cluster support, and whether the customer needs N+2 or rack awareness.
A three-year fixed-capacity quote should state assumptions; otherwise it is a price, not a design.
3. Explain why RF2 plus N+1 does not permit losing two nodes without impact.
Read the worked answer
RF2 protects data by keeping two copies, so one node failure should not lose data. N+1 protects capacity and compute by reserving enough for one node. Together they still describe only one failure. After a node fails, the cluster must rebuild copies onto surviving nodes; during that rebuild, some vDisks may have reduced redundancy and performance is degraded. A second node failure before rebuild completes can make data unavailable or lost. N+1 does not mean two nodes can be lost, and it does not cover a block or rack failure. The design should state the tolerated failure scenario, monitor rebuild completion, and avoid overlapping maintenance. If the business needs two simultaneous failures, the answer is RF3/N+2 or a different fault-domain design, not a reinterpretation of RF2+N+1.