In the context of a Tableau Server high-availability setup, what is a crucial consideration when con- figuring a coordination ensemble?

The Tableau Server Coordination Service, which is based on Apache ZooKeeper, is responsible for maintaining state and ensuring consistency across a distributed cluster. To achieve high availability and prevent a "split-brain" scenario—where a network partition could lead to two active but inconsistent cluster leaders—the ensemble relies on a quorum-based system. Configuring an odd number of nodes (typically 3 or 5) ensures that a clear majority can always be established. For an ensemble to function, more than half of its nodes must be running. An odd number guarantees that even with a network partition, only one partition can ever contain the majority (the quorum), thus preventing data inconsistency.

A. The ensemble should be configured on a single node to centralize coordination control

This creates a single point of failure, which is the antithesis of a high-availability architecture.

B. Ensemble nodes should be distributed across different physical locations for geographical redundancy

While a valid disaster recovery strategy, high latency between geographically distant nodes can degrade the performance of the latency-sensitive Coordination Service, and it is not the most crucial consideration for preventing split-brain.

D. Coordination ensemble nodes require significantly more storage than other nodes in the cluster

This is incorrect. The Coordination Service stores state and configuration metadata, which is very small compared to the data extracts and workbooks managed by the File Store and Data Engine nodes.

---

1. Tableau Server Documentation: In the section on high availability

the official documentation explicitly states the requirement for an odd number of nodes. "For high availability

a new Coordination Service ensemble should include an odd number of nodes

3 or 5. While it is possible to have more nodes in the ensemble

more than 5 is not recommended... A majority of the Coordination Service nodes (a quorum) must be functional for the ensemble to work."

Source: Tableau Help. (2023). Deploy a Coordination Service Ensemble. Section: "Deploy a three-node ensemble".

2. Apache ZooKeeper Documentation: Since Tableau's Coordination Service is built on Apache ZooKeeper

its principles apply directly. The ZooKeeper documentation explains the concept of quorums. "For a ZooKeeper service to be active

there must be a majority of non-failing machines that can communicate with each other. To create a deployment that can tolerate the failure of F machines

you should count on deploying 2xF+1 machines." This formula inherently leads to an odd number of servers.

Source: Apache ZooKeeper™ 3.8 Documentation. ZooKeeper Administrator's Guide. Section: "ZooKeeper Internals" -> "Guarantees

Properties

and Definitions".

3. University Courseware on Distributed Systems: Academic materials on distributed consensus algorithms confirm this principle. Quorum-based protocols like Zab (used by ZooKeeper) and Raft require a majority vote to proceed. An odd number of voters prevents ties and ensures a clear majority can be formed

which is essential for preventing split-brain conditions.

Source: Ongaro

D.

& Ousterhout

J. (2014). In Search of an Understandable Consensus Algorithm. Stanford University. Section 3.2: "Leader election". (This paper on the Raft algorithm

which shares principles with ZooKeeper's Zab

explains the necessity of a majority for leader election and log consistency). DOI: https://doi.org/10.1145/2628074.2628093