With Tableau Server, having a system that's always available becomes mission-critical. However, we know things can—and do—go wrong in real life.
That’s why we’ve invested heavily in improving the High Availability architecture in Tableau Server 9.0. The architecture provides cluster management to maintain full quorum with a minimum of a three-node cluster and a clear elected leader. These improvements eliminate two-node, split-brain scenarios to enable decision-making during a failover.
When running Tableau Server in High Availability, the extracts have to be replicated across all nodes in the cluster to ensure they're available if one node becomes unavailable. To make sure extracts are always available across all nodes in a cluster, we've replaced rSynch (a tool for extract replication across cluster nodes) with a more efficient implementation in FileStore.
New & Improved Server Processes</strong>
To support the new features of Tableau Server 9.0, we’ve introduced new server processes that you’ll see on the server status page.
Here's a brief overview of these updates and how they help maintain High Availability with Tableau Server.
Cache Server: This is a distributed and shared query cache across the server cluster. It's an in-memory cache that other Tableau services can query for faster user experience across many scenarios.
This can easily be scaled by adding more Cache Servers in your cluster deployment. Our clients often ask us how to maintain data quality. There are two simple strategies for this. First, we invalidate the cache whenever a user hits refresh on the Tableau client, which means the user can always get the latest data when they want. Second, as an administrator, you can schedule a subscription run or use an external tool to load up the key workbooks after the data refresh is done, so caches are warmed up and available for your users in the morning.
Caches are persisted on server restart, and reloaded. For those of you familiar with server components, VizQL Server, Backgrounder, and Data Server make requests to the Cache Server on behalf of the end users.
API Server: This server process is used when you interact with the server via REST APIs. If this service is down for any reason, the overall health of the server would remain good in servicing requests (unless you're using REST API for supporting critical business processes).
Application Server: While the name remains the same, the Application Server has been completely revamped in Tableau Server 9.0 with a modern architecture for the server front-end.
Data Engine: When working with extracts, Data Engine is the key component responsible for loading, querying, and servicing end user requests for visualizations. In Tableau Server 9.0, you can now have multiple Data Engines on the same cluster node or run these services on every node in the cluster. This ensures that if one of the Data Engine processes is unavailable, the others can still service the users.
File Store, Cluster Controller & Coordination Service: These are new server processes that are part of the improved architecture for High Availability. Together, these provide improved availability and quorum during failover situations.
File Store and Cluster Controller will always be installed to support the distributed deployments, even when you aren't using High Availability. In addition, File Store and Data Engine are always required on every node, so you should get used to seeing these on your server status page. You'll be able to configure these like any other Tableau Server from the Tableau Configuration UI.
File Store will ensure that extracts are available on all nodes of the cluster and can scale to N nodes as active/active. On occasion, if you need to remove a file store from a cluster node, you'll be able to do so using a new administrative command in tabadmin (decommission and recommission). This command puts the specified nodes into read-only mode so new content cannot be added to the File Store. It also makes sure that all content on the node also exists on another File Store node. This command can be run while Tableau Server is running.
Coordination Service is installed on all nodes in a distributed cluster. It ensures quorum and leader election during failovers to enable decision-making. Coordination Service also holds all of the state information across all nodes in a cluster.
Cluster Controller manages the active and passive Postgres repositories. It detects any failover situations, and works with Coordination Service to ensure a failover occurs automatically and alerts you.
The Rest: The rest of the server processes (VizQL, Backgrounder, Search, Browse, Gateway) should already be familiar to you. If you are new to Tableau Server, the Tableau Server Administrator Guide should help clarify these processes and what they do.
When planning your upgrade to Tableau Server 9.0, check out our online videos for end-user training. For infrastructure upgrades, review the minimum hardware requirements and consider leveraging modern hardware with the support of SIMD instruction set for added benefits from our investments in vectorization.
In addition, you should review your monitoring scripts to ensure you include the new server processes. Once you're done, you'll be delivering a new level of analytics capabilities to your end users! Of course, we are always available to help. Just give us a call.
If you want to chime in with the broader server administration community, please check out our community forum to join the discussions with your peers.
We hope you're excited about the new server capabilities, and will enjoy them as much as we have enjoyed bringing them to you!
Want to Learn More?
Check out the rest of our Tableau 9.0 blog series: