Configure and Manage Storage
Storage questions test whether you can choose container settings that match workload behaviour, and whether you understand where redundancy actually lives.
The hierarchy
- All disks in a cluster form the storage pool; there is no RAID - redundancy is set per container.
- Containers set the replication factor (RF2/RF3), compression, deduplication, EC-X, advertised and reserved capacity.
- Stargate handles I/O, Curator does disk balancing and scrubbing, Cassandra holds metadata. Nutanix Volumes exposes iSCSI to external hosts; Files serves NFS/SMB.
Feature rules
- Compression is inline and cheap; enable broadly.
- Deduplication pays off on clone-heavy or VDI data and costs memory/CPU on write.
- EC-X erasure-codes cold data for capacity; requires RF2 or better and at least four nodes, and is applied after a configurable delay so hot data stays replicated. It adds CPU cost and does not help write-heavy random I/O.
Worked example
An archive container holds files written once and rarely read. RF2, compression on, EC-X enabled with the delay left at default: the capacity saving is worthwhile because the data is cold, and write performance is not a constraint. The same settings on a heavily written database container would cost more CPU than the space saved.
Traps
- Choosing RF3 on a three- or four-node cluster - it cannot deliver the intended fault tolerance.
- Expecting dedupe to work on already-compressed or encrypted data.
- Forgetting that changing RF is an online but capacity-consuming operation.
- Deleting a container that still holds vDisks.