Solutions · Hyperconverged

Hyperconverged infrastructure — three nodes, no array

Hyperconverged infrastructure collapses the hosts and the array into one tier, with drives in the same chassis as the CPUs. The step size gets smaller and the purchase gets simpler; what you give up is a failure boundary, which is why the network and the node count matter more here.

• Three nodes — The practical floor
• Storage in the nodes — No separate array
• Network decides it — Sized for rebuild
• Pre-racked — Cabled and configured
• Burn-in tested — 24 to 72 hours

What it is

One tier where there were three

A traditional virtualisation estate has three tiers: hosts that run the workloads, an array that holds the disks, and a fabric between them. Hyperconverged infrastructure collapses the first two. The drives sit in the same chassis as the CPUs, software replicates them across nodes, and the array — along with its controllers, its licences and its separate support contract — is not bought at all.

What you get for that is a smaller step size and a simpler purchase. Growth is a node, which arrives with compute and capacity together. There is one vendor conversation instead of two, one firmware regime, one support call. For an estate of a few dozen virtual machines this is frequently the right answer and it is frequently cheaper.

What you give up is a boundary. In a three-tier estate, a storage problem is visible as a storage problem and the array is engineered by someone else to survive its own failures. In HCI, storage and compute share nodes, share a network, and share the consequences — which is why the specification matters more here than anywhere else in this catalogue.

The comparison

HCI or three-tier — where each one wins

Both are correct answers to different estates. Anyone who tells you one is obsolete is selling the other.

• Smallest sensible step — Hyperconverged: One node, compute and capacity together. Three-tier with an array: A host, or an array upgrade — two different budgets
• Capacity that outgrows compute — Hyperconverged: Awkward: you add nodes you do not need the CPUs of. Three-tier with an array: Natural: expand the array, leave the hosts alone
• Failure boundary — Hyperconverged: Shared — a node failure is also a storage event. Three-tier with an array: Separate — the array survives host failures by design
• Network — Hyperconverged: In the data path; must be sized for rebuild traffic. Three-tier with an array: Carries storage traffic on its own fabric, sized once
• Operational surface — Hyperconverged: One platform, one console, one support relationship. Three-tier with an array: Two platforms, and the boundary between them is yours
• Where it goes wrong — Hyperconverged: Undersized network, too few nodes, mixed drive sizes. Three-tier with an array: The array becomes a single point and a single supplier

Node layouts

Four shapes, and the estate each one suits

The mix of drives and cores is what makes a cluster suit its workload. These are the ones that recur.

• Standard three-node — The baseline. Three identical nodes, quorum without a witness, and enough spread that losing one leaves the redundancy scheme intact. Most estates start and stay here.
• Compute-heavy — More cores and memory per node, modest capacity. For VDI and application estates where the virtual machines are many and the data behind them is not.
• Storage-heavy — Fewer cores, more bays, hybrid or all-flash tiers. For file services, imaging and estates where the data grows faster than the workload does.
• Two nodes and a witness — For a branch or a small site where three chassis will not fit or will not be paid for. The witness is a small vote elsewhere — it is not a third copy of the data, and it should not be described as one.

What actually bites

Five decisions, and not one of them is CPU

In our experience an HCI cluster that disappoints is almost never short of CPU.

• Network bandwidth and topology — What goes wrong when it is guessed: Sized for steady state, a rebuild after a node failure crawls, and the cluster stays degraded through the window where a second failure is fatal.
• Node count against the redundancy scheme — What goes wrong when it is guessed: Too few nodes and the scheme tolerates drive loss but not node loss — which nobody discovers until a node goes.
• Drive count and uniformity — What goes wrong when it is guessed: Too few devices per node and the software cannot spread load. Mixed sizes and most implementations treat every drive as the smallest one present.
• Headroom for a node being down — What goes wrong when it is guessed: A cluster sized at capacity has none, so a planned patch becomes a capacity incident. The Nth node must be able to be absent.
• Licence model — What goes wrong when it is guessed: Per-core hypervisor licensing can make a fourth smaller node cheaper than a third larger one. The hardware and the licence decision are one decision.

What we ship

Delivered as a cluster, not as three servers

• Pre-racked and pre-cabled — A cluster arrives configured rather than as three servers in three boxes, with your choice of stack — VMware vSAN, Nutanix AHV or Microsoft Azure Stack HCI.
• Or open, on Proxmox VE — The same shape without per-socket licensing. We run more than 800 physical servers on Proxmox VE in SpectraCloud, our own production cloud, so the advice on that path is from operating it.
• What the burn-in is looking for — CPU, memory and storage stress with thermal checks and a SMART review, per node, before the cluster is integrated and validated as one.
• Firmware baseline recorded — Identical revisions across the nodes, written down and shipped — which is what makes the fourth node match the first three when you add it next year.
• Backup sized alongside — Replication across nodes is availability, not backup. A cluster without a separate target is one bad afternoon from a restore nobody can perform.
• Built, tested and supported here — Integrated and manufactured in India, burn-in tested before dispatch, and covered by the warranty and response terms set out on the services page — the same for every machine we build.

Straight answers

Two nodes, 10GbE, and choosing a stack

• Is two nodes enough? — Answer: For availability, with a witness, sometimes. For comfort, rarely. Two nodes cannot lose one and still rebuild redundancy, so you are running without a net until the replacement arrives.
• Does HCI replace our SAN? — Answer: It replaces the array for the workloads you move onto it. Estates commonly run both for years, and there is nothing wrong with that.
• Can we mix node specifications? — Answer: Yes, and it costs you. Most implementations plan against the smallest node, so an oversized one contributes less than it cost.
• What about 10GbE — is it enough? — Answer: Often, for a small cluster on spinning disks. Rarely, for all-flash or for a cluster you expect to rebuild quickly. It is the single most common thing we are asked to re-specify.
• Which stack should we pick? — Answer: The one your team can operate at 2am. The licensing difference is real, and it is still second to that.

Run the numbers

What a node really holds

• VM sizing calculator — Cores, memory and the reserves that decide what a node really holds.
• How many VMs fit on one host — The guide behind the calculator, including what to subtract before you start.
• All sizing tools — Six calculators running the same arithmetic our engineers do.

The bill of materials

What a three-node cluster is made of

The appliance, the open path, and the storage argument underneath both.

• Virtualization appliances — Pre-racked, pre-cabled three-node clusters, delivered configured.
• Proxmox VE platforms — The same shapes without per-socket licensing, from the estate we run.
• Software-defined storage — What SDS moves into software, and what it moves onto your nodes.