Core Platform Architecture and Distributed System Design
AOS as a distributed system
This domain tests the internals: how AOS places data, how I/O flows, and what happens when a component fails. Every node runs a CVM with distributed services. Stargate handles I/O and extent placement; Curator runs background scans, scrubbing, and rebalancing; Prism provides local management; Acropolis manages AHV. The storage model uses a storage pool (physical disks), containers (logical namespaces with policies), vDisks (VM disks), and extent groups (units of placement). Metadata maps vDisks to extent replicas.
I/O path and failure behavior
A VM write goes through the hypervisor to the local CVM. Stargate writes to the persistent op log on SSD and sends a replica to a peer CVM. Once the peer acknowledges, the write is committed; later it is destaged to the extent store. Reads are served locally when possible or redirected to a replica. If a node fails, replicas on surviving nodes continue serving data, and the cluster rebuilds redundancy when capacity allows. If a CVM fails, VMs on that host are restarted by HA; data remains available to other hosts from replicas.
Worked example
A VM issues a 4 KB write. The local Stargate logs it and forwards the replica to another node. The write is acknowledged only after the replica is safe. This is why SSD op-log capacity and low-latency network matter: the log absorbs bursts before destaging. If the peer is slow, write latency rises even if disks are healthy.
Traps
Do not describe a central metadata server or a single storage controller; the design is symmetric and distributed. Do not say a CVM failure is invisible to VMs on that host. Do not confuse a storage pool with a container, or a vDisk with an extent group.