Cluster Quorum Calculator
Model majority quorum for real home-server clusters: Proxmox, Ceph, etcd, MongoDB, Consul, Patroni, witness-assisted pairs, and stretched rack labs.
Named cluster presets
Cluster inputs
Quorum results
Reference table: majority thresholds
| Total votes | Quorum threshold | Failures tolerated | Design note |
|---|---|---|---|
| 2 | 2 | 0 | Needs both voters unless a third witness vote is added. |
| 3 | 2 | 1 | Classic small HA cluster and the simplest home-lab target. |
| 4 | 3 | 1 | Same failure tolerance as 3 votes, with more split possibilities. |
| 5 | 3 | 2 | Good for storage or consensus clusters that can spare hardware. |
| 7 | 4 | 3 | Useful when multiple racks or rooms must be represented. |
Reference table: named platform behavior
| Platform | Common voter set | Witness option | Operational consequence |
|---|---|---|---|
| Proxmox VE | 3 Corosync voters | QDevice | No quorum means cluster-wide management and HA actions stop. |
| Ceph MON | 3 or 5 monitors | Usually none | Monitor quorum protects the cluster map and client coordination. |
| etcd | 3 or 5 members | No normal witness | Losing majority blocks writes to Kubernetes control-plane state. |
| MongoDB | 3 data-bearing voters | Arbiter possible | Primary election requires a majority of votes. |
| Consul | 3 or 5 servers | No lightweight witness | Raft leadership needs a majority of server votes. |
| Patroni | 3 DCS voters | DCS dependent | PostgreSQL failover safety depends on consensus health. |
Spec comparison grid
| Spec | 3 voters | 2 voters + witness | 5 voters | 4 voters stretched |
|---|---|---|---|---|
| Quorum threshold | 2 | 2 of 3 votes | 3 | 3, or 3 of 5 with witness |
| Single-node failure | Survives | Survives if witness remains reachable | Survives | Survives, but rack split must be modeled |
| Maintenance comfort | Moderate | Low to moderate | High | Moderate with a tie-breaker |
| Home-lab cost | Medium | Low | High | Medium to high |
| Split-brain resistance | Good | Good when witness is independent | Very good | Depends on domain placement |
Failure-domain reading guide
| Domain count | Typical layout | What to check | Preferred adjustment |
|---|---|---|---|
| 1 | All nodes on one shelf, switch, or UPS | Power and switch failure can remove every vote. | Add a second power/network path before trusting HA. |
| 2 | Two racks, rooms, or hosts plus shared services | Even splits can leave no clear owner. | Add a witness in a third domain. |
| 3 | Three small servers or two nodes plus witness | Each voting side should fail independently. | Keep vote weights simple and visible. |
| 5 | Storage or consensus lab with many voters | Latency and maintenance sequencing matter more. | Use odd voters and document patch order. |
Take an example of a three-server cluster that is going through a routine update where one of those server freezes. High availability goes out the window and management locks up. Home lab enthusiasts is used to it and tend to purchase additional hardware to prevent such downtime. But this just adds a brittle dependency rather than adding stability. And while quorum logic generaly does work as intended, you might still have an optimistic mental model about how voting should work.
With Quorum, there’s no split brain, each node either thinks it’s leading, or not. A majority vote are needed for systems to move forward, but that may sound easy enough until you add in maintenance windows and witness nodes into the mix. That’s where the calculator shines; it lets you model out different failure modes and get a clearer idea of what happens when.
How to Plan Your Cluster Votes
You might have a three-node Proxmox cluster, and want to know exactly how much of a blip a reboot causes (or guess). Or maybe you need to understand how many node you can lose before your cluster loses quorum. Just plug in how many nodes you have overall, plus any witness nodes you have (QDevices, say), and then remove the ones you’ve taken down for maintenance or lost because of a network outage. The calculator will spit back how many votes is left versus the minimum number needed, and you realize you burn through the same failure budget with planned downtime as unplanned crashes.
What most folks don’t realize is that patching is surprisingly quick to lose quorum (a three-node cluster require a majority of two votes). You take one down for maintenance and you have just two votes with no headroom. Then you lose connectivity to the quorum device on another node due to a glitch or whatever. Now it’s all read-only and everyone go home.
That’s why odd numbers are important when you’re dealing with a distributed system: a three-node cluster will tolerate one failure but a four-node cluster tolerates only one as well. Because you need three votes to keep a majority with four nodes, that fourth node buys you nothing but more complexity when it comes time to manage this thing.
A lightweight witness running on a cloud instance or even a Raspberry Pi require no full server, yet adds an external tie-breaker that changes the math. As long as each witness has its own independent network path and power, then a two-node pair will remain at quorum if one of the servers go down. In this case, the remaining node (plus the witness) still has two of three votes, but there’s a catch to placement. You don’t want the witness to go dark whenever power goes out in your home office. Having a witness share the same rack, UPS, or switch as the nodes it sits between is useless.
Ceph monitors, etcd clusters and MongoDB replica sets also use majority-based principles, but reference tables showing their respective trade-offs will help understand how they work. The impact of losing quorum varies: For Kubernetes, it stops all change to the cluster state (effectively pausing a deployment pipeline); for a database cluster it may only stop writes, allowing reads to keep happening against secondaries. Before you go mucking with vote weights, know your platform’s quirks. Notably, some permit lowering quorum temporarilly during maintenance. Risk increases if the cluster cannot automatically recover.
In wider or stretched out deployments the single biggest thing to worry about is split-brain risk. However, when nodes are spread across multiple rooms, network latency and partitioning issues also become a factor. And this is where most folks mess up. They think about raw performance instead of whether the cluster stays available through consensus. You can have the world’s fastest NVMe drives, but they’re all useless if your cluster isn’t agreeing who owns what. A stalemate condition arise from an even number of voters without a witness. To break this stalemate you should of had someone to step in manually.
Quorum is not a shopping list of additional gear; it’s a plan to limit the impact of a single failure. You don’t want any one incident to remove a majority of votes. So design your nodes in multiple locations using diverse networks and power circuits. Make your witness as independent as possible. Use this tool to check such designs (before deploying them) by translating theoretical cluster theory into specific risk analysis. Your cluster isn’t just insurance against hardware failures, it should survive your own errors too. Design with odd numbers of votes, keep your witnesses separated, and never trust redundancy without also confirming the quorum math.
