Cluster Architecture and Components
The moving parts
A Nutanix node is hardware + hypervisor + CVM. The CVMs across nodes form a distributed system, and each service has a specific job:
- Genesis - bootstrap and cluster-formation service; it starts CVMs and coordinates cluster services.
- Prism Element - the per-cluster UI/API and alerting layer.
- Cassandra - distributed metadata store (the "ring"); it needs a quorum of nodes to stay healthy.
- Zookeeper - cluster configuration and leader election.
- Stargate - data I/O layer; owns vDisk access and mediates reads/writes.
- Curator - background scanner for disk balancing, ILM, and capacity reclamation.
- Acropolis - the management/scheduling layer that AHV uses to place and run VMs.
Fault domains
A failure domain is the unit that can fail together - a node, or a block if block awareness is enabled (requires at least three blocks). Replication factor (RF2/RF3) determines how many copies exist and therefore how many failures you can absorb before data becomes unprotected.
Traps
- Confusing Cassandra (metadata) with Zookeeper (configuration/election) with Curator (background scanning).
- Assuming a healthy cluster always has full redundancy: after a node loss under RF2, data is still available but temporarily unprotected until re-protection completes.
- Forgetting that cluster services need quorum - losing too many CVMs impacts management even if VMs keep running.
- Block awareness is not automatic; it must be planned around physical block layout.
Worked example
Four nodes, RF2, one node down: VMs keep running, data is served from the surviving copy, and the cluster re-protects once the node returns (or Curator rebuilds elsewhere). A second simultaneous failure in the same window risks data loss. That is why large clusters are often RF3.