Witness Node Calculator

Do you remember that time when you did everything right… Your high availability cluster just didn’t fail over, it failed entirely? You had two nodes and a network link, thought that was solid. Then a patch window came open at an inconvenient time or someone dropped a packet on the switch. Now neither will come up: each thinks the other is dead.

Welcome to the world of the split brain scenario, where small data centers and home labs alike gets hurt. It is not because hardware fails, but because the math surrounding who gets to speak becomes unclear.

How to Plan Quorum and Prevent Split Brain

After this, you specify your topology. The calculator above do all the tricky math on vote counting. You no longer need to hand-derive quorum threshold values for each potential failure case. Begin by specifying how many nodes are truly voting, i.e., not standby nor non-voting.

If there are an even number of voting node, then you’re deadlocked (waiting to happen). Making it odd (which is as easy as adding a witness node) flips the parity from even to odd and establishes basic requirement of a decisive majority. It’s nothing but a mathematical trick that keeps the cluster running with no communications between sites.

So how do you choose which kind of witness to use? Latency tolerance and your physical layout are big factors here. If you have another reliable server in the same rack as your cluster. Perhaps some sort of file share; that’s great for Windows clusters. However, what happens if whole rack loses power? What if a power zone failure take out your entire network? Then it provides zero protection.

In those cases (e.g., a stretched cluster spanning multiple buildings/cities) you need a dedicated QDevice or a cloud witness that lives outside both failure domains. You can vary these inputs, such as witness availability and WAN latency. The tool will then show you how latency affects reliability. For example, as latency increases beyond twenty milliseconds, the vote’s reliability drops quickley. This is why putting the arbiter so far away can actualy defeat the purpose.

The majority of admins fall down on maintenance windows. You can take a node offline for patching. If you don’t modify the quorum settings, you may end up with only a few votes left. This might not be enough to survive a single hardware failure. To account for that, the calculator allow you to specify both planned maintenance nodes (e.g., scheduled downtime) and unplanned failures (e.g., hardware fails). That tells you if you have enough spare votes to keep going with one server down, and shows the narrow margin many two-node setup operate at. It lets you know precisely what conditions calls for adding redundancy or pausing operations.

On the page you’ll find some reference tables that spell out individual risks for each type of witness technology. This helps you to not make a classic mistake such as putting a QNetd service onto same hypervisor as the thing you’re trying to protect. The key point is independence.

The witness must fail independently from the rest of your nodes in the cluster; if it shares a network switch or power source with one of them, then it hasn’t increased resilience. It’s merely complicated things. You need a witness that’s robust enough and independent enough to still cast a valid vote when all else fails.

In the end, quorum planning is about anticipating failure and planning for it. Think about your cluster’s makeup in terms of probability, not just the straight number of nodes. It means modeling your own constraints so that when a partition occur, your cluster will make the correct decision: to keep one side up but shut down the other in a safe manner. Because that’s how you get your workloads running even as the network falters. You should of planned for this sooner.