Erasure Coding Requested on an RF3 Cluster with a Failed Node
Six nodes run AOS 6.5.3 with a single RF3 container at 58% used. The container holds 40 TB of production data. Node 5 has been offline for three days awaiting a motherboard; rebuild is still in progress and NCC reports a degraded cluster. A compliance rule requires that the cluster tolerate two simultaneous node failures. The operations director wants to enable erasure coding now, or immediately after the replacement, to reclaim capacity and postpone a node purchase. The platform team is unsure whether erasure coding is compatible with the existing protection setting and with the current cluster state. The next budget cycle is four months away, and capacity is projected to reach 75% in eight weeks. All six nodes are identical, and there is no spare node.
1. Can erasure coding be enabled now or immediately after node 5 is replaced? Explain the constraints.
Read the worked answer
Reasoning: No. Two independent constraints apply. First, the container is configured for RF3, and Nutanix erasure coding is designed for RF2 containers; it is not a way to preserve two-failure tolerance in an RF3 container. Enabling it would require changing the container's protection model, which conflicts with the stated compliance rule.
Second, the cluster is degraded and rebuilding. Erasure coding adds background striping and parity work, and enabling it during a rebuild increases I/O contention and risk. The correct sequence is to restore node 5, let rebuild finish, and confirm NCC and Curator are clean. Even then, RF3 still blocks the EC request. The team should not clear the protection setting just to satisfy a capacity request. This is a design decision, not an upgrade checkbox.
2. What should the team do to address the capacity projection while preserving the two-failure requirement?
Read the worked answer
Reasoning: If the compliance rule genuinely requires tolerating two simultaneous node failures, RF3 is the relevant control and erasure coding does not replace it. The practical options are to add capacity, archive or delete cold data, or move data to another platform. Adding a seventh node improves headroom and rebuild capacity; it does not make EC compatible with RF3.
If the business decides one-failure tolerance is acceptable, the team can plan a deliberate move to RF2 plus erasure coding, but only after the cluster is healthy and with enough spare capacity for restriping. That is a separate change with its own risk review. Before either path, validate the 75% projection, identify large consumers, and set NCC capacity alerts. Postponing the node purchase without changing the protection model leaves the cluster exposed.
3. What conditions would you require before enabling erasure coding in a future RF2 design?
Read the worked answer
Reasoning: Treat EC as a capacity optimization, not a rescue action. Require a healthy cluster with at least four nodes, all CVMs and disks online, no active rebuild, and no outstanding NCC failures. Confirm the AOS version supports EC for the container type and that the container is RF2. Check that free space can absorb restriping and normal growth; EC does not eliminate the need for capacity headroom.
Schedule the change outside peak load, enable it per container, and monitor Curator, disk latency, and rebuild status afterward. Do not enable EC on a container holding data whose protection requirement is two node failures. Document the decision and test restore or failure scenarios if the compliance scope is sensitive.