During a planned power-down of one AHV node in an EC-X-enabled cluster, Prism shows data reconstruction in progress. What impact should the administrator expect while EC-X rebuilds data on the surviving nodes?
Select an answer to reveal the explanation.
Short Explanation
Think of EC-X like a shared puzzle: if one piece is missing, the other pieces have to do extra reading and writing to recreate it. You’ll see more load on the surviving nodes, so latency can climb while rebuild traffic runs. Don’t expect the cluster to pause VM I/O or automatically switch to RF=3 just because one node is down.
Full Explanation
Erasure coding stores data and parity fragments across nodes, so when a node fails the cluster reconstructs missing blocks by reading surviving fragments and writing recovered blocks to remaining nodes. That rebuild path consumes CPU, disk bandwidth, and network capacity on healthy nodes, which can increase storage latency and reduce headroom for normal VM I/O during recovery. A full VM I/O pause is not the expected behavior because Nutanix continues serving I/O from available fragments and parity, though performance may degrade while rebuild proceeds. Treating the event as an immediate conversion to RF=3 is also wrong; EC-X and RF are different space-efficiency and redundancy models, and a failed node does not automatically change container protection settings. Rebuild traffic is not confined to the failed node's local cache, because that node is unavailable and reconstruction requires reads from surviving nodes and writes to the remaining cluster. Exam caveat: Focus on EC-X's trade-off—lower steady-state capacity overhead in exchange for higher reconstruction and failure-path I/O. Operational check: Review container protection settings, monitor cluster IOPS, latency, and capacity headroom during reconstruction, and confirm spare capacity before removing or replacing the failed node.