Sizing a Proxmox cluster: the rules that prevent bad surprises
A virtualization cluster is not sized by adding up servers: it is sized by rules. How many nodes to survive a failure, how many virtual machines per physical core, which storage at which scale, which networks must never mix. Here are those rules, and why each one exists.
Estimate my cost →Three nodes, not two: the quorum rule #
A cluster makes its decisions by majority: that is the quorum. With two nodes there is no possible majority: if one goes down, or the link between them is cut, each node cannot tell whether the other is dead or merely unreachable, so the cluster freezes to avoid both writing at once. Three nodes is therefore the floor for high availability. With two or four nodes, a quorum witness (a small machine at a third site, called a QDevice) restores an odd number of votes.
N+1 capacity: plan for the failure, don't hope #
The most profitable sizing rule: the cluster must carry the whole workload with one node down, without exceeding roughly 80% utilisation. A stopped node is not only a failure: it is also every system update, planned and stress-free. A cluster sized to the edge turns the smallest maintenance into a negotiation.
The consolidation ratio: from vCPUs to real cores #
Virtual machines do not use all their processor at once, so you can allocate more vCPUs than there are physical cores. Common orders of magnitude: 3 vCPUs per core for general production, 4 and more for development and testing, but 1.5 to 2 for databases and latency-sensitive applications. Memory, however, is never overcommitted in production: promised RAM must exist, otherwise the system starts paging and everything slows down.
Storage follows the node count #
Below 3 nodes, local ZFS storage replicated to the other node is simple and fast, but replication is asynchronous: after a failover you restart from the last copy, with a few minutes potentially lost. From 3 nodes, Ceph turns the servers' disks into shared storage that keeps three copies of every piece of data: a node can burn, nothing is lost. In exchange, Ceph demands a fast dedicated network and server-grade disks, and it needs free space to rebuild after a failure.
The RAM storage claims before the first virtual machine #
This is the costliest sizing mistake, because it only shows up months later. When the servers' disks form the shared storage, each disk is driven by a process that demands its own memory: budget roughly 8 GB of RAM per disk, plus 1 GB per terabyte of raw capacity, plus 2 GB for the hypervisor itself, and at least one dedicated CPU core per disk. That reserve is not comfort margin: after a node fails, the surviving processes carry the rebuild and their memory need goes up. If nothing is left to take, the system kills the largest consumer, often one of those very processes, and the cluster falls over entirely while it was trying to repair itself. A twelve-disk, twenty-terabyte server therefore reserves close to a hundred and twenty gigabytes before hosting anything at all.
The networks that must never mix #
A cluster carries very different flows: virtual machine traffic, storage, live migration, and the cluster heartbeat (corosync) that constantly checks each node is alive. The heartbeat needs stable latency more than bandwidth: if it shares the storage network and a large copy saturates the link, nodes believe each other dead and the cluster fails over for nothing. Beware the most common shortcut: a VLAN is not enough. A VLAN separates logically but shares the cable, therefore the queue; under load the heartbeat waits its turn like everything else. It needs two physically dedicated links, and two 1 Gbit/s links are plenty, because it does not ask for throughput, it asks never to wait. Avoid bonding it too: it manages its own links and switches over in milliseconds, whereas a bond can keep alive a link that is silently dropping packets.
Backup lives outside the cluster #
Replicated storage protects against a disk failure, not against deletion, malicious encryption or human error: replication copies the mistake as faithfully as everything else. Backup therefore lives on a machine separate from the cluster, with an off-site copy: the so-called 3-2-1 rule (three copies, two media, one off-site). And a backup that has never been restored is only a hope: schedule the restore test before going live.
The same subscription level on every node #
A contractual rule nothing hints at, and an expensive one to ignore: within a cluster, every node must carry the same subscription level. As soon as one node has one, all of them must. Putting the top level on a single server and leaving the others bare saves nothing: it makes every subscription invalid and closes access to stabilised updates for the whole cluster. The processor count, on the other hand, may differ from server to server: it is the level that must be uniform, not the hardware.
Run the numbers on your own estate #
These rules can be computed: our Digital Architect sizes your cluster (nodes, storage, backup, subscriptions at the vendor's public price list) from your number of virtual machines, outputs the memory and CPU reserve storage takes per node and the number of disks to order, and ends with the hosting requirement sheet, space, power and cooling, directly comparable in the comparator.
FAQ #
With no possible majority, an outage freezes the cluster: each node cannot tell whether the other is dead or merely unreachable. With 2 nodes, add a quorum witness (QDevice) at a third site, even a small virtual machine is enough.
It depends on the profile: for general production, around 3 vCPUs per physical core and never more memory allocated than physically present. Databases demand a lower ratio, development tolerates a higher one.
Under 3 nodes: local replicated ZFS, simple and fast, but asynchronous. From 3 nodes: Ceph provides true shared storage with three copies of every piece of data, at the cost of a fast dedicated network and server-grade disks.
Replication protects against hardware, not mistakes: a deletion or ransomware replicates too. You need a backup separate from the cluster, with an off-site copy, and a scheduled restore test.
Written on 10 September 2026.
From reading to comparing: relevant data centers
Estimate my cost → Compare data centers