1. Overview

Versa Director supports a clustered, high-availability (HA) deployment model based on the Raft consensus protocol. In a Raft-based cluster, the cluster can only accept writes and remain fully operational while a quorum — a strict majority of cluster nodes — is reachable. This article explains how node placement across data centers (DCs) affects quorum behavior, compares a 2-DC-with-Arbiter design against a 3-DC design, and provides a detailed node/site up-down matrix showing resulting cluster behavior for each scenario.

2. Background: Raft Consensus and Quorum

A Versa Director cluster is typically deployed with an odd number of voting members (commonly 3: one Primary node, one Secondary node, and one Arbiter node) so that a clear majority can always be determined. Key points:

• Quorum = more than 50% of total voting nodes reachable and participating in the cluster.
• If quorum is lost, the cluster cannot elect/maintain a leader and stops functioning (read/write operations are not guaranteed) until quorum is restored.
• Latency between nodes should be kept under 50 ms to keep Raft consensus efficient and avoid election churn.

3. Why Deploy Across 3 Data Centers

Placing one voting node in each of three separate data centers is the recommended design because it provides true geographic redundancy without relying on any single site to keep the cluster alive.

• Quorum survives a full site loss: With one node in DC1, DC2, and DC3, losing any single DC still leaves 2 of 3 nodes (≈66%) alive, which is a majority — the cluster stays healthy.
• True geographic redundancy: No two voting nodes share a failure domain, so a single site outage (power, WAN, natural disaster) does not take down cluster write capability.
• Latency requirement: Inter-node latency should stay under 50 ms to keep Raft consensus efficient across all three sites.

3.1 Summary Comparison

Setup	Quorum If One DC Fails	Cluster Usability After DC Failure
2 DCs with Arbiter in one DC	≤50% nodes alive (quorum lost)	No (cluster stops)
3 DCs with one node each	>50% nodes alive (quorum maintained)	Yes (cluster continues running normally)

 

4. Scenario: 2 Data Centers with an Arbiter Node

A common alternate design places the Primary node in DC-1 and both the Secondary node and the Arbiter (tie-breaker) node in DC-2. Because two of the three voting nodes reside in the same physical site (DC-2), this design does not provide true geographic redundancy: if DC-2 as a whole becomes unreachable, only 1 of 3 nodes remains — quorum is lost and the cluster stops, even though DC-1 and its Primary node are fully healthy.

The table below walks through the possible up/down combinations of the Primary node (DC-1), the Secondary and Arbiter nodes (DC-2), and the underlay network, and the resulting cluster behavior. Note: this matrix reflects a 3-node (Primary/Secondary/Arbiter) deployment and should be re-derived if a different node count is used.

 

DC-1		DC-2			Underlay	Cluster Functionality
Site	Primary Node	Site	Secondary Node	Arbiter Node
Site Up	Up	Site Up	Up	Up	Up	DC1 Primary
Site Up	Up	Site Up	Up	Down	Up	DC1 Primary
Site Up	Up	Site Up	Down	Up	Up	DC1 Primary
Site Up	Up	Site Up	Down	Down	Up	Not-working
Site Up	Down	Site Up	Up	Up	Up	DC2 Primary
Site Up	Down	Site Up	Down	Up	Up	Not-working

 

5. Scenario: 3 Data Centers with One Node Each (Recommended)

In this design, the Primary node resides in DC-1, the Secondary node in DC-2, and the Arbiter node in DC-3 — one voting member per site. Because no two voting nodes share a physical location, the complete loss of any single DC removes only one vote; the remaining two DCs still hold 2 of 3 nodes, which is a majority. This is the design described in Section 3 and is the recommended topology wherever three independent sites are available.

The table below walks through the possible up/down combinations of the Primary node (DC-1), Secondary node (DC-2), and Arbiter node (DC-3), and the resulting cluster behavior.

 

DC-1		DC-2		DC-3		Underlay	Cluster Functionality
Site	Primary Node	Site	Secondary Node	Site	Arbiter Node
Site Up	Up	Site Up	Up	Site Up	Up	Up	DC1 Primary
Site Up	Up	Site Up	Up	Site Up	Down	Up	DC1 Primary
Site Up	Up	Site Up	Down	Site Up	Up	Up	DC1 Primary
Site Up	Down	Site Up	Up	Site Up	Up	Up	DC2 Primary
Site Up	Up	Site Up	Down	Site Up	Down	Up	Not-working
Site Up	Down	Site Up	Up	Site Up	Down	Up	Not-working
Site Up	Down	Site Up	Down	Site Up	Up	Up	Not-working
Site Up	Down	Site Up	Down	Site Up	Down	Up	Not-working

 

6. Key Takeaways / Recommendations

• Prefer a 3-DC deployment (one node per DC) whenever possible — it is the only design that keeps quorum intact after the complete loss of any single site.
• If only 2 data centers are available, be aware that co-locating the Secondary and Arbiter nodes in one DC means that DC's failure (not just a node failure) results in total loss of quorum and cluster downtime.
• Keep inter-node/inter-DC latency under 50 ms to avoid Raft election instability.
• Always validate the node-state matrix against the actual number of deployed nodes — the matrices above assume exactly 3 voting members (Primary, Secondary, Arbiter).
• Monitor underlay network connectivity between sites, since a healthy node with no underlay reachability behaves the same as a down node from a quorum perspective.