Capacity Runway After a Node Failure
A six-node NX-1065 cluster runs AHV and Prism Element, managed by Prism Central. Each node has 8 TB raw SSD. All storage containers use RF2. Prism shows 74% used, and the customer expects 1.5 TB per month of new thick-provisioned VM disks. Last week node 4 was down for six hours after a NIC firmware fault; latency rose but no VM went offline. The customer asks whether adding one node next quarter is enough and whether dedupe and compression should be enabled on all containers now. The cluster has 140 VMs, many with 500 GB disks that are only 30% written. Prism Central reports a capacity runway of four months, and NCC shows no failures.
1. Calculate the usable capacity and runway at RF2, and determine whether one additional 8 TB node buys enough time.
Read the worked answer
Raw capacity is 6 × 8 TB = 48 TB. At RF2, usable capacity is roughly half, about 24 TB before reserve. Prism reports 74% used, so approximately 17.8 TB is consumed and about 6.2 TB remains. At 1.5 TB per month, that is roughly four months of runway, matching Prism Central. Adding one 8 TB node raises raw capacity to 56 TB and RF2 usable to about 28 TB. Free capacity becomes about 10.2 TB, or roughly 6.8 months of runway. That buys only about 2.7 extra months. If the node arrives next quarter, the cluster may be near 90% before the expansion completes, leaving little room for rebuilds, snapshots, or growth spikes. One node is therefore not a comfortable fix; two nodes or a combination of one node plus real capacity reclamation is safer. Thick-provisioned disks also mean adding capacity without fixing provisioning may simply repeat the problem.
2. The customer wants dedupe and compression enabled on every container. What would you check, and what benefit is realistic for these VMs?
Read the worked answer
First separate provisioning waste from data reduction. The 500 GB disks that are only 30% written may still consume full capacity because they are thick-provisioned. Moving new workloads to thin provisioning and reclaiming unused space can recover capacity without any dedupe overhead. Compression is generally the safer first gain and can be enabled per container; dedupe is post-process, requires fingerprinting, consumes CPU and cache, and works best on clone-heavy or highly repetitive data such as VDI. For 140 general server VMs, dedupe may find little duplicate data and can add load. Check peak CPU headroom, container advanced settings, and NCC health before changing all containers at once. Pilot on a non-production container, measure savings and latency, then roll out compression broadly; enable dedupe only where the data profile justifies it.
3. What does the six-hour node outage imply about RF2 and future maintenance windows?
Read the worked answer
RF2 kept all VMs online with one node down, which is expected: one copy remained available. However, during that outage there was no tolerance for a second failure. When node 4 returned, the cluster had to rebuild missing replicas, which explains the latency increase. Before any future firmware or hardware maintenance, confirm Prism shows data resiliency as healthy and that no rebuild or curator task is active. Take one node out at a time, wait for full resiliency to return, and only then proceed to the next node. Do not schedule simultaneous upgrades across nodes, and avoid starting maintenance when capacity is near a threshold, because rebuilds need free space and IO. If a second node fails during a rebuild, some data could become unavailable or the cluster could lose writes.