Hyperconverged Infrastructure and AOS Architecture
What the domain tests
This domain tests AOS architecture: the Controller VM (CVM), Distributed Storage Fabric (DSF), I/O path, and the cluster services that make HCI work.
Core rules
- Every node runs a CVM. The CVM is a service VM that owns the node's local disks and runs AOS software; it is not for customer workloads.
- DSF pools local disks across nodes into a single distributed datastore. Guest I/O goes through the hypervisor to a CVM, then to the extent store.
- Key services: Stargate handles data I/O; Curator runs background scans and disk scrubbing; Cassandra stores cluster metadata; Genesis handles cluster membership and configuration; Chronos schedules jobs; Zookeeper supports coordination.
- RF2 mirrors data to a second node before write acknowledgement. RF3 keeps three copies.
- ILM moves colder data to lower-cost media in hybrid clusters; all-flash clusters use different tiering behavior.
- Containers are logical storage groupings; vDisks are the block devices presented to VMs.
Worked example
A VM writes a block. AHV passes the I/O to the local CVM. Stargate writes it to the local extent store and mirrors it to a remote CVM for RF2. The write is acknowledged only after the required copies are safe. If the local node fails, the remote copy still serves the data. This explains why RF2 needs at least three nodes for availability during maintenance and failure.
Traps
The CVM is not a general-purpose VM; do not size or schedule user workloads on it. Cassandra is metadata, not the data path. Curator is background maintenance, not front-end I/O. Do not confuse a storage container with a protection domain.