Two SCADA Servers vs Three: The Quorum Decision
A redundant SCADA pair has a hidden weakness: with only two votes, the servers cannot reliably agree on which one should be primary when the link between them drops. This page compares the plain two-server pair against a three-node arrangement, whether a full third server or a lightweight witness, and helps you decide when the odd vote is worth the extra host and when a two-node design with a good tiebreaker is enough.
Two-server pair vs three-node quorum in one line: A two-server pair is simplest but cannot break a tie on its own, so a lost heartbeat can trigger split-brain where both nodes claim primary. Adding a third vote, either a full server or a lightweight quorum witness, gives an odd number that always resolves who leads. Choose two nodes plus a witness for most sites; choose three full servers only when you also need the third node to carry load or survive losing any one machine.
Understand Why Two Votes Cannot Break a Tie
The core problem with a bare pair is arithmetic. When the two servers lose contact with each other, each one sees the same ambiguous situation: my partner is unreachable. It cannot tell whether the partner is dead, in which case it should take over, or merely unreachable across a broken link, in which case the partner may already be serving. With no third opinion, a naive pair can end up with both nodes active, the split-brain condition that corrupts historian data and confuses every downstream client about which server to trust.
A third vote removes the ambiguity by making the total number of voters odd. Whichever partition of the system can still see a majority of votes is allowed to be primary; the minority side stands down. This is the job of a quorum witness, which does not need to be a full SCADA server at all. It can be a small service on a separate machine or site whose only role is to be the tiebreaking vote, so that a two-server pair gains the decisiveness of a three-node cluster without the cost of a third full server.
Compare the Three Practical Arrangements
There are really three options on the table, not two, and the witness variant is the one projects most often overlook.
| Factor | Two servers only | Two servers plus witness | Three full servers |
|---|---|---|---|
| Can break a tie | No - needs a tiebreaker rule | Yes - witness casts the odd vote | Yes - majority of three |
| Split-brain risk | High if link drops | Low | Low |
| Hardware cost | Two hosts | Two hosts plus a small witness | Three full hosts |
| Survives losing one node | Yes, if the survivor is chosen | Yes | Yes |
| Survives losing two nodes | No | No | Sometimes, if one has quorum |
| Extra capacity from third node | N/A | None - witness carries no load | Yes - third node can serve |
The witness option is deliberately cheap. Because it only votes, it can run on hardware far smaller than a SCADA server, often at a different location, and its failure does not take down the pair; it only removes the tiebreaker, returning you to the two-node situation you would otherwise be designing around anyway.
Three full servers is the heavier answer and is justified when the third node earns its keep beyond voting. If you need capacity to spread active-active load, or you must survive losing a whole node and still have a redundant pair left, the third server is doing real work rather than only casting a vote. If the third box would sit idle except at election time, a witness delivers the same tie-breaking for a fraction of the cost.
When Each Arrangement Wins
A two-server pair with no third vote wins only when the link between the servers is genuinely reliable and you have an explicit, tested tiebreaking rule, such as a designated preferred node plus a shared resource that only one can hold. This works but it is fragile, and it demands that the tiebreak be drilled as part of every failover drill so you know it resolves the way you expect under a real link failure.
Two servers plus a witness wins for the large majority of redundant SCADA sites. It gives clean, majority-based election with minimal added cost, and placing the witness on separate infrastructure or at another site protects you against a single event taking out both a server and the tiebreaker together. This is the pragmatic default when you have decided you need redundancy at all.
Three full servers wins when the extra node is load-bearing or when your availability target requires surviving the loss of any single node while still holding a redundant pair. Large control rooms, multi-site consolidations, and systems with high client counts that benefit from spreading sessions are the cases where the third server is a capacity decision as much as a quorum one.
Pitfalls in Quorum Design
The most damaging pitfall is placing the witness on the same host, hypervisor, or power feed as one of the servers. When that shared element fails, you lose a server and the tiebreaker at once, and the survivor may not have a majority to act on, defeating the entire purpose. The witness must fail independently of the nodes it arbitrates, which usually means separate hardware and ideally a separate location.
A second trap is assuming three servers automatically survive two failures. Quorum needs a majority, so losing two of three normally leaves the last node in the minority and unable to act on its own. If a two-node-failure tolerance is a real requirement, you need five voting members, not three, and most SCADA sites do not. The final pitfall is treating quorum as a set-and-forget configuration; the election logic must be exercised in drills, because a witness that has silently died turns your three-vote design back into the two-vote problem you were trying to avoid.
Frequently Asked Questions
Why can't two SCADA servers just decide between themselves?
Because when the link between them drops, each server sees only that its partner is unreachable and cannot tell whether the partner is dead or simply cut off. Both can conclude they should be primary, producing split-brain. Two votes cannot form a majority, so there is no reliable way for the pair alone to break the tie without an external tiebreaker rule or a third vote.
Is a quorum witness the same as a third SCADA server?
No. A witness only casts a vote to break ties; it does not run the SCADA application, carry client load, or store the historian. That lets it run on much smaller hardware, often at a separate site, at a fraction of the cost of a full server. Add a full third server instead only when you need that node to carry load or to survive losing a whole node while keeping a redundant pair.
Does three servers let me survive two failures?
Usually not. Quorum requires a majority, and losing two of three leaves one node in the minority, which normally stands down rather than running unsafely. Surviving the loss of any two voting members requires five members. Three nodes tolerate one failure well; if a genuine two-failure tolerance is required, size the cluster for it explicitly rather than assuming three is enough.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.