Distributed Storage Fabric and Data Resilience
What this domain tests
NDFS questions focus on how Nutanix protects data without RAID: replication factor, erasure coding, checksums, rebuild, failure domains, and capacity accounting.
Core rules and concepts
- RF2 keeps two copies; RF3 keeps three. RF is set per container or storage policy and applies cluster-wide in practice.
- Failure domains are node, block, and disk. RF2 tolerates one node or block failure; RF3 tolerates two. A two-node cluster can run but has no node-failure tolerance with RF2.
- Erasure coding (EC-X) reduces capacity overhead for cold data. It is not a replacement for RF and has minimum cluster requirements.
- Every write is checksummed. Scrubbing detects and repairs silent corruption.
- Rebuild is automatic after a failure. Rebuild priority can be tuned, and reserve capacity is needed to rebuild safely.
- Snapshots are redirect-on-write and metadata-based; they are restore points, not independent backups.
- Capacity reporting separates raw, usable, reserved, and overprovisioned capacity.
Worked example
A customer has six nodes at 10 TB raw each, or 60 TB. RF2 gives about 30 TB before overhead. If 20% goes to metadata and reserve, and snapshots consume 5 TB, roughly 19 TB remains usable. A 25 TB requirement fails the design. Adding nodes is the correct fix. Dedupe or EC might help, but EC only applies to cold data and must not be assumed to close a general capacity gap.
Traps
Do not confuse RF with RAID or with remote replication. Do not promise erasure coding as a performance capacity fix. Do not ignore reserve. Do not claim RF2 survives two simultaneous failures.