A Three-Node Proxmox HA Cluster on ThinkCentre Tiny: Layout, Power, and Racking

Three ThinkCentre Tiny boxes is the canonical homelab Proxmox cluster, and it got that way for unglamorous reasons: the machines are cheap on the used market, they are quiet, they idle in the single-digit watts, and three of them is the smallest number that gives you a quorum worth having. A used M720q with an i5-8500T, 16 GB of RAM, and an NVMe slot lands somewhere around a hundred dollars in 2026, which means an entire high-availability cluster costs less than a single new 1U server that would drown out the room.

What follows is the build as it actually goes: which generation to buy, why quorum shapes every other decision, the networking that makes HA meaningful rather than decorative, the power and thermal numbers, and how three Tiny boxes end up occupying rack space without becoming a nest of adapters.

The mount for this build:

10" Lenovo ThinkCentre Tiny Rack Mount - Fits M70q-M90q & M710q-M920q - 1U

Picking the generation

The Tiny chassis has held a footprint of roughly 179 x 183 x 37 mm across a long run of generations, which is the reason a single mount design covers M710q through M90q. The 37 mm height is the number that matters: it fits a 1U opening (44.45 mm per EIA-310-D) lying flat, with a few millimeters of clearance.

The generations worth considering, and what separates them:

• M710q / M720q (7th/8th gen Core). The value floor. The M720q's i5-8500T is six cores, 35 W TDP, and plenty for a cluster node. DDR4 SODIMM to 32 GB (64 GB works on many boards despite the official spec), one NVMe slot, one 2.5-inch bay.
• M920q (8th/9th gen). Same era, better board — the M920q is the one people hunt for because it has a proper PCIe x8 slot behind the riser, which means a real NIC.
• M70q / M80q / M90q (10th gen and later). Newer, faster, more expensive, and the later Gen 3 and Gen 4 variants have their own riser situation. Better idle power on the newest ones.

Here's the gotcha that decides the build: the riser slot. A Tiny with a usable PCIe riser can take a dual-port 2.5G or 10G NIC, which changes what the cluster can do. A Tiny without one is stuck with its single onboard gigabit port plus whatever USB Ethernet you are willing to trust, and USB NICs in a cluster that fences nodes based on network reachability is a decision you will regret at 3 a.m. Buy the riser-capable model, or accept a gigabit-only design and configure accordingly.

Why three, and what quorum actually demands

Proxmox clustering uses Corosync, which requires a majority of votes to keep the cluster operable. With three nodes, quorum is two. Lose one node and the surviving pair still has 2 of 3 votes; the cluster stays up and HA can restart the dead node's guests elsewhere.

Two nodes cannot do this. With two votes total, losing one leaves a single vote out of two, which is not a majority, and the survivor goes read-only rather than risk split-brain. You can paper over it with a QDevice — a tiny external vote, often a Raspberry Pi — but the moment you are buying a third device anyway, buying a third node is a better use of the money.

Practical consequences that follow from quorum:

• Corosync wants low, consistent latency far more than bandwidth. It is sending small packets constantly and it makes life-or-death decisions on their timing. Sub-millisecond and steady is the requirement.
• Corosync should not share a link with bulk traffic. A backup job saturating the same wire that carries cluster heartbeats is the classic way to fence a healthy node.
• Two Corosync rings are strongly preferred. Corosync supports up to eight links with automatic failover. Two is the practical number: primary on the dedicated cluster network, secondary on the management LAN.

This is where the riser NIC earns its money. With a dual-port card, one port carries the cluster and storage network on an isolated segment, the onboard port carries management and VM traffic, and Corosync gets a ring on each.

Storage: the part that decides whether HA is real

HA means a guest that was running on a dead node restarts somewhere else. That only works if the other nodes can read its disk. Local storage on a dead machine is not readable by anyone, so shared or replicated storage is not an optional refinement — it is the feature.

Three approaches on hardware this small:

• ZFS with replication. Each node runs local ZFS; Proxmox replicates guest volumes to peers on a schedule, as often as every minute. Cheap, simple, and works over gigabit. The cost is data loss on failover equal to your replication interval — a one-minute schedule means up to a minute of writes gone. For a homelab, usually acceptable.
• Ceph. Genuinely shared storage, no data loss on failover, and the thing everyone wants to run. It is also hungry: Ceph wants a dedicated network, ideally 10G, meaningful RAM per OSD, and enterprise-ish SSDs with power-loss protection to avoid dreadful write latency. Three nodes is the documented minimum and it is a real minimum, not a comfortable one.
• External NFS or iSCSI. Point all three nodes at a NAS. Simplest to reason about, and it moves the single point of failure to the NAS. Plenty of homelabs accept that trade.

On ThinkCentre Tiny hardware, ZFS replication is usually the right answer. Ceph on three gigabit-connected nodes with consumer NVMe is a well-documented way to build something that technically works and feels awful. If you want Ceph, budget for 2.5G at absolute minimum and 10G if the riser allows it, and buy drives with power-loss protection.

The network in the middle

A three-node cluster needs more switch ports than people plan for. Minimum sane count: three management/VM ports plus three cluster/storage ports, six total, plus an uplink. That is a five-port switch overflowing on day one and an eight-port switch being exactly right.

Speed matters most on the storage side. Replication of a 100 GB guest volume over gigabit takes roughly fifteen minutes at line rate; over 2.5G it is closer to six. Since replication runs on a schedule and only ships deltas after the first pass, gigabit is survivable — but the first sync of a fat VM is a long afternoon. A 2.5G switch has become cheap enough that there is little reason to build a new cluster on gigabit; the 10" MokerLink 2G080110GSM 2.5G Switch Mini Rack Mount - 1U gives you eight 2.5G ports in the same cabinet, which covers all six node connections and leaves room.

Two configuration notes that save grief:

• Give the cluster network its own subnet and, ideally, its own VLAN. Corosync does not need routing to anywhere; isolation is a feature.
• Set the migration network explicitly in /etc/pve/datacenter.cfg. By default, live migration uses the management network, which means a migration can saturate the same link Corosync is using. Point it at the storage network instead.

Power, heat, and the four bricks

Each Tiny idles somewhere around 8-12 W with an NVMe drive and a couple of light VMs, and peaks near its power supply's rating under sustained load — 65 W adapters on the 35 W-TDP models, 90 W on some configurations. A realistic three-node cluster with modest workloads sits around 35-45 W total at idle and perhaps 120 W under a heavy parallel load.

That is a small enough heat load that a 10-inch cabinet with passive venting handles it without fans, provided the boxes are not sealed against each other. Tiny machines pull air in through the side and front vents and exhaust out the rear, so lying flat in a rack the intake is along one edge — leave that edge clear. Stacking three 1U mounts directly on top of each other is fine; stacking them and then pressing the whole column against a solid side panel is not.

The power supplies are the real space problem. Three 65 W bricks, each with a barrel connector and a captive cord, is more physical volume than the three computers. Options, in order of tidiness:

• A shelf or tray at the bottom of the cabinet holding all three bricks, with short extension leads to the PDU so the transformers are not levering themselves out of the outlets.
• A single multi-output DC supply. The Tiny's input is 20 V DC on a slim-tip connector; consolidated supplies exist. This is neat and creates one failure that takes down all three nodes simultaneously — which, for a cluster whose entire purpose is surviving single failures, deserves a moment's thought.
• Leave them loose in the bottom of the cabinet. Honest, common, and it works until you need to trace which brick belongs to which node. Label them.

On UPS sizing: 45 W of idle draw plus a switch is a very small load, and almost any 600 VA consumer UPS will hold it long enough to ride out the outages that actually happen. What matters more is that all three nodes and the switch are on the same UPS — a cluster where one node loses power and the others do not is a fencing event, not a graceful shutdown.

Racking three of them

Three nodes at 1U each is 3U, plus 1U for the switch and 1U for a patch panel, so five rack units carries the whole cluster. In a 10-inch cabinet — 254 mm wide, roughly 220 mm of usable interior — a Tiny at 179 mm across fits with room for cable egress on one side but not for a second device beside it. One node per U is simply the geometry.

Front-facing decisions worth making before you screw anything in:

• Which face goes forward. Putting the rear I/O forward means Ethernet, power, and display all patch from the front, which is what you want in a rack you can only reach from one side. It also means the front panel button faces the wall — acceptable, since a cluster node should not need a power button often.
• Label the U positions, not the machines. Nodes get replaced; positions do not. A cluster where node2 lives in the middle slot forever is one you can troubleshoot over the phone.
• Leave the top node's intake clear. If anything in the cabinet exhausts upward, do not put a node directly above it.

In a 19-inch cabinet the same three nodes are swimming in a 450 mm opening, and a modular mount that fits two Tiny boxes side by side in one U is the right call — three nodes in 2U instead of 3U, with the third position available for the next machine. The 19" Lenovo ThinkCentre Tiny Rack Mount - Fits M70q-M90q & M710q-M920q - 1U handles that case.

What HA does and does not get you

Worth being precise, because expectations here run high. Proxmox HA restarts a guest on a surviving node after the cluster decides the original node is gone. That decision takes time — the failure has to be detected, the node fenced via watchdog, and the guest booted elsewhere. Expect a minute or two of downtime for the affected guest, not zero.

It is not live migration; that is a separate, planned operation where a running guest moves with no interruption. It is not a backup, either — replicated corruption replicates faithfully. And it does nothing for a failure that takes out all three nodes, which is to say the switch, the UPS, or the room.

What it does get you is the ability to unplug a node in the middle of the day, walk it to the bench, replace a stick of RAM, and put it back, while everything important keeps running. For a homelab that hosts things other people in the house depend on, that is the entire point.

Wrap-up

Three ThinkCentre Tiny boxes, a 2.5G switch, and five rack units gets you a genuine high-availability cluster for the price of a single mid-range server, drawing less power than a couple of light bulbs. Buy the riser-capable generation so the cluster network can be real, keep Corosync off the link that carries backups, use ZFS replication unless you are prepared to feed Ceph properly, put every node on the same UPS, and give the bricks a home before they give themselves one. The rest is Proxmox doing what it does well.

Mounts in this build