Glossary
Hyper-converged infrastructure (HCI)
Hyper-converged infrastructure (HCI) runs compute, storage and virtualization on one cluster of standard servers. Software pools the local drives of every node into shared storage for the virtual machines running there, and the cluster grows by adding nodes that each bring processors, memory and drives together.
From three tiers to one cluster
A conventional virtualization stack has three layers: servers running virtual machines, a storage area network, and an external array. HCI collapses them. Each node contributes its local drives to a pool every node can use, and a write is copied to other nodes as it lands, so a node can fail without data loss while its virtual machines restart elsewhere. The pooling is a form of software-defined storage.
The draw is operational: one platform, one team, one upgrade path, components validated together and fast deployment. For a fleet of virtual machines with steady, balanced growth, that simplicity holds up.
How HCI compares with neighboring models
| Model | Where data lives | How it grows |
|---|---|---|
| Three-tier with SAN | External array shared over a storage network | Compute and storage separately; the array within its controller limits |
| HCI | Local drives of every cluster node | Compute and storage together, node by node |
| Disaggregated flash | Shared enclosures reached over NVMe over Fabrics | Compute and storage separately, over the network |
| Scale-out object storage | Dedicated storage nodes reached over an S3 API | Capacity without compute |
The column that separates them is the last one: whether storage can grow without buying compute. HCI answers no by design, which suits steady virtualization estates and strains wherever data grows faster than processing demand.
Why is usable capacity lower than raw?
Protection by full copies costs space. A four-node cluster with 100 TB of raw drives per node, 400 TB in all, keeping three copies of every block holds about 133 TB of data, before free space is reserved for rebuilding after a node failure. Usable capacity often lands below half of raw, so sizing by drive count alone overstates what the cluster holds. Erasure coding lowers the overhead where the platform supports it, at some cost in processing.
The coupling problem
Every node adds compute and storage in fixed proportion. Workloads where both grow together fit that. Data growing on its own does not: more storage means more servers, with processors, memory and per-core or per-node software licenses that nothing else needed. Licensing can outweigh the hardware. Storage-heavy node types ease the imbalance without removing it.
Failures also cost more than a single drive. When a node goes down, the cluster re-creates its missing copies from the survivors over the same network that carries production traffic, and the virtual machines it hosted restart on nodes that now carry extra load. Small clusters feel this most, because each node holds a large share of the data and of the compute.
What tends to stay off the cluster
Large datasets that grow independently and are written once and read rarely, such as backups, archives, media libraries and analytics data, sit poorly on HCI. They usually live on a separate scale-out platform, often object storage. Keeping backups off the cluster also keeps them out of the failure and administrative domain of the production systems they protect, a principle covered under secondary storage. Many organizations run HCI for virtual machines beside a separate capacity platform rather than choosing one model for everything.