Tableau Server - Enabling Performant High-Availability (PHA)

One of many attributes of Tableau Server that has been historically praised is its ease of setup and maintenance. Set up a machine, run the installer, set up a service account, and you’re good to go. Using a public cloud like Amazon’s AWS or Google Cloud? Then it’s even easier, as these platforms now offer an (almost) one-click solution to spin up a default Tableau Server environment in minutes. 

If your team has already found success in fostering a Tableau-forward culture at your organization, have an active developer community in your Slack or Teams, and have an established and formal devops process in place: first off - congrats! Secondly, you may have started to think about how to ensure that your environment maintains a proper enterprise-level uptime now that you are maintaining enterprise-level insights that are critical to running your business.

If you’ve encountered an outage before during the middle of the night, with colleagues blowing up your phone (or even worse, clients,) you know exactly what I’m talking about. Once you establish trust in your data, the next step is to establish trust in your infrastructure - the confidence in your clients and colleagues to know that their data will be available when they need it.

Background

The setup for High-Availability (HA) requires at least a three-node cluster. There is an initial node and two worker nodes with a few shared services that provide redundancy in case of failure on one of the nodes. A snippet of Tableau’s recommended architecture for a three-node cluster is below.

Three-node setup

This configuration is functional, and enables HA in case of failover by assigning VizQL (generally speaking, the dashboard compute service) and backgrounder (generally speaking, the backend data compute service) services in each node. However, that same redundancy has some less-than-obvious limitations. 

The services in Tableau server are assigned tasks via a round robin approach, meaning that at times, a single node will have both their VizQL and Backgrounder services active, leading to a contention for resources. Unfortunately, there is not currently a setting to configure a service as “failover only”--meaning that any node with both VizQL and Backgrounder services active is at risk of performance degradation, especially for environments serving a large set of users and/or assets.

Enabling PHA for Tableau server requires two configuration changes (in order of importance):

1. Enabling high availability with redundant services on at least two nodes (VizQL and Backgrounder are two resource-intensive services, but there are other redundant services required as well)

2. Complete isolation of high-compute (VizQL or Backgrounder) services on each node

---

Applying the Solution

To maintain a performant environment during failover, you need a minimum of four Tableau Server nodes.

1. Two nodes with VizQL Services and no Backgrounders (and no other services to be maximally performant)

2. Two nodes with Backgrounders and no VizQL

A simplified example of high-availability architecture optimizing for VizQL performance is shown in the image above. All services that are non-dashboard rendering are isolated to their own nodes, while the VizQL services are isolated as much as possible from other services.

This solution can be applied in a few easy steps:

1. Navigate and log in to the Tableau Services Manager (TSM) at https://<servername>:8850

2. Click on the configuration tab

3. From this screen, you can add nodes, process, change process counts, etc.

4. Once you’re finished, click Apply Changes and Restart on the upper right corner

Key Takeaways

Compared to the standard HA architecture, this solution:

1. Reduces resource contention between the demanding VizQL and Backgrounder services, compared to a single-node or three-node HA configuration

2. Enables HA with isolated VizQL and Backgrounder task queues

3. And most importantly: Even in the event of single node failure, VizQL and Backgrounder isolation is maintained.

As your organization (and Tableau Cluster usage) grows, this multi-node architecture allows independent scaling of your VizQL or Backgrounder services, without them impacting each other. 

“Are you seeing outages or planning to scale your Tableau cluster? Contact us at info@gomagus.com. ”