Tableau Server Dynamic Topology Changes
Tableau Server on Windows now includes Tableau Services Manager (TSM), which replaces the Configuration Utility and the tabadmin command line tool. If you need help for an earlier version of Tableau Server, see the Tableau Help page.
With the introduction of TSM, Tableau Server also introduced the ability to make certain topology changes or updates without restarting the server. These are known as dynamic topology changes, and are possible with the backgrounder and VizQL Server processes.
You can increase or decrease the number of backgrounder or VizQL Server instances on a node that already has at least one of these processes running, without any Tableau Server downtime. If you have a node already running backgrounder, you add additional instances of backgrounder or VizQL Server to the node without restarting Tableau. You can do the same with VizQL Server node running VizQL Server, adding or removing instances of either backgrounder or VizQL Server. You must be only changing the number of instances of backgrounder or VizQL Server. If you also add or remove another process, you need to restart Tableau Server. For example, if you have a node running four instances of VizQL Server, you can remove all those instances and add one or more instances of backgrounder instead, without restarting Tableau Server, taking advantage of dynamic topology changes.
To better understand why this might be useful, consider these examples:
- Backgrounder—At the end of a sales quarter your sales team is using Tableau Server to keep track of their numbers. Dashboards that depend on extracts are showing sales people how they are doing. Any delay in extract refreshes means your team is not seeing the most up-to-date numbers. You can add additional backgrounders to any node that already has at least one backgrounder or VizQL Server, and increase the throughput of extract refreshes, helping to guarantee the numbers are up-to-date as your team finished up their quarter. Later, after the quarterly push, you can reduce the backgrounder instances again to return Tableau Server to its original configuration.
- VizQL Server—Similarly, if Tableau Server is unable to keep up with view refreshes, you can quickly add additional VizQL Server instances to any node that already has at least one instance of either VizQL Server or backgrounder configured. In the above backgrounder example, you might want to remove VizQL Servers temporarily, to accommodate additional backgrounders, and then re-add them back before your users arrive in the morning.
Making dynamic topology changes
You can make dynamic topology changes using the TSM Web UI, or on the command line. To use the Web UI, sign in to TSM using a browser, and on the Configuration tab, update the number of backgrounder or VizQL Server instances for the node you are updating. For details, see Configure Nodes. To make your changes using the TSM CLI, at a command prompt, run the tsm topology set-process command. For details, see Changing the number of processes on a node.
Impact of dynamic topology changes
When making dynamic topology changes that remove existing instances of VizQL Server or backgrounder, the instances are removed immediately. Be aware of the following potential impacts to users and currently running jobs:
Backgrounder—Any currently running jobs are terminated. The normal Tableau Server retry logic will restart these jobs, using another backgrounder instance.
VizQL Server—Any currently active sessions are terminated. Users may see an error message. Refreshing the browser should clear the error.
Tableau recommends you test any dynamic topology changes you plan on using, before implementing them in your production environment. This will help you fully understand potential impacts to your users and scheduled refreshes and subscriptions, and allow you to most efficiently take advantage of the flexibility offered by dynamic topology.
Automating dynamic topology changes
You can automate dynamic topology changes. For example, if you have most of your extract refreshes scheduled overnight, and know your server has extra capacity because users are not signed in, you can use a script or other automated deployment tool to add backgrounder instances when they can be most efficiently used, and then remove them before the start of the work day.
To automatically get the status of processes, use the
tsm status -v command and parse the output in your script. Alternately, you can use the TSM REST API get server status. The API is currently in alpha. For more details, see Get server status.
A sample script to set four instances of backgrounder on node2 might look like this:
echo Adding/Removing Processes tsm topology set-process -pr backgrounder -n node2 -c 4 tsm pending-changes apply echo Done!