Tableau Blueprint Help

Note: This topic applies to Tableau Server only.

Tableau Server can be installed on-premises with physical or virtual machines or in the cloud and supports Windows or Linux operating systems. To determine your hardware platform and sizing, consider these variables: your environment, sources of data and management to provide self-service data access, potential workload from all users, and actual usage data. If this is the first time you are deploying Tableau Server, you should focus on your environment standards and sources of data. For existing deployments, you will analyze Tableau Server data to evaluate workload and usage in addition to environment and sources of data.

Hardware requirements

Regardless of where you choose to deploy Tableau Server, properly-sized hardware is critical. Your planning should be aligned with evolving business needs by assessing server utilization and user engagement more frequently, scaling more frequently, and changing topology more frequently than other software applications. Review the corresponding link to the hardware platform that fits your enterprise standards:

• Recommended Baseline Configurations (Windows | Linux)
• Tableau Server on VMware VSphere
• AWS Instance Type and Size (Windows | Linux)

• Google Compute Engine Virtual MachineType and Size  (Windows | Linux)

• Microsoft Azure Virtual Machine Type and Size  (Windows | Linux)
• Alibaba Cloud ECS Instance Type and Size (Windows | Linux)

If you deploy Tableau Server in the cloud, using Dedicated Hardware and static allocation of RAM eliminates varied performance due to resource contention. If cost is a consideration, Virtual Hardware is also viable. We recommend testing your own infrastructure to find the configuration that best fits your needs. For an example of how to conduct such a test, please see the Tableau at the Speed of EC2 Whitepaper. (This experiment was conducted in AWS, but the testing theory extends to any cloud provider.)

Initial Sizing

Your Tableau account team is available to assess your requirements and assist with sizing. In an initial deployment of Tableau, you should estimate 600-800 Explorers per 8-core node, assuming 10% active users (interactive, concurrent requests made to Tableau Server, including consuming dashboards on a laptop or mobile device, web authoring, and connecting to and querying Published Data Sources). This is only a starting point and should not be considered a hard sizing rule beyond the initial deployment. Memory should be at least 8GB of RAM per core for a production server. For less than 40-core clusters, use 8-core nodes, and in clusters greater than 40-cores, use 16-core nodes. The relative workload of each license type must be factored into hardware sizing. Assuming an Explorer counts as 1 user, a Creator has a relative workload of 2.4 users, while a Viewer has a relative workload of 0.75 of a user. Using these workload coefficients, you can estimate the cluster’s capacity. The following table shows examples of equivalent workloads on each row:

	Creators	Explorers	Viewers
Workload 1	25	300	586
Workload 2	50	333	462
Workload 3	75	234	514
Workload 4	100	171	518

 

Actual workload of Creators, Explorers, and Viewers may vary with usage of Tableau Server features, such as frequency of connecting to data and web authoring, as well as viewing and interacting with content. As users are onboarded and start creating and consuming content, you should monitor the hardware and content utilization to make informed decisions on server sizing with data from hardware monitoring tools and Tableau Server’s Repository. For more information, see Tableau Monitoring and Measurement of Tableau User Engagement and Adoption

Scalability

In both new and existing deployment scenarios, the goal is to proactively maintain sufficient availability, capacity, and headroom and minimize resource contention. Like other enterprise platforms, Tableau Server scales up by adding processor, memory, and/or disk or scales out by adding more nodes to a cluster. Tableau Server scales nearly linearly with the addition of hardware resources, according to your unique environment, data, workload, and usage mix. Load testing and capacity planning should be conducted regularly, as outlined in Tableau Maintenance.

Scalability and performance are heavily dependent on external systems, such as sources of data, volume of data, and network speeds, user workloads, and workbook design, which can change rapidly as deployments progress. For example, assuming a correctly-sized hardware configuration for the initial deployment, unplanned user onboarding, unmonitored utilization, inefficient workbooks, suboptimal data extract design, and peak-hour refresh schedules can have a major impact on server performance and user experience, causing performance to degrade from the cumulative effect of the separate incidents. For more information, see Tableau Server Scalability whitepaper.

When deploying Tableau Server in the cloud, you can leverage all existing scaling abilities of the Tableau platform including Hot Topology. With a simple restart of the server, you can also change the underlying machines supporting the platform as long as their Public IP Address does not change.

For single-node deployments, you may also turn off Tableau Server machines during downtimes to reduce machine costs. Doing so with a multi-node cluster will put Tableau in a degraded state. But you can utilize Hot Topology to responsively adjust Tableau Server process allocation, allowing you to tune the balance of machine costs and capacity needs. Auto-scaling functionality that terminates or instantiates machines based on demand is not supported.

Server Environments

In addition to your production environment, Tableau recommends one test environment for testing upgrades and server topology changes. Your production environment will support modern analytics using production and sandbox projects with content validation, promotion, and certification processes—all in one environment. For more information on these content management processes, see Tableau Governance. The production and test environments should have identical hardware specs, server topology, and configuration. This will allow administrators to test upgrades and participate in beta programs in the test environment by restoring back production content.

Some organizations have IT policies that require three environments—Development, QA, and Production—to isolate use cases for content development, testing and consumption into separate Tableau Server installations. If this is a requirement for your organization, each of the three environments must be licensed separately as they would be considered three Production Environments as defined in Tableau's End User License Agreement. The Production and QA environments should have identical specs, server topology, and configuration. If you are required to run three separate environments, try not to replicate a traditional waterfall development cycle with a modern analytics platform. Users may favor the QA environment to circumvent stringent policies or delays to get content into production, so work towards a good balance by automating content migration to the production server with the Content Migration Tool found in Tableau Advanced Management or custom workflow scripts using Tableau’s REST APIs. The development environment does not have to have identical hardware specs as the production and QA environments, unless the development environment is used for upgrade testing or participation in beta programs.

High Availability

You should install and configure Tableau based on your availability requirements and add additional nodes for capacity and/or for high availability (Windows | Linux). To support mission-critical use cases, you should deploy a high-availability (HA) cluster configuration with an external load balancer (Windows | Linux).

An HA installation of Tableau Server has a minimum of three nodes and multiple redundant instances of key processes (the Repository, File Store/Data Engine, and Coordination Service) on different nodes. The goal is to minimize system downtime by eliminating single points of failure and enabling detection of failures with failover where possible. For more information, see Tableau Server High Availability whitepaper.

Follow the pattern below to build your HA cluster:

1. Install the initial node and allow the architecture-aware smart installer to configure processes (Windows | Linux). The active Repository is on Node 1.
2. Replicate the process configuration to other VizQL nodes, ensuring redundancy (Windows | Linux). The passive Repository is on Node 2. Node 3 processes will mirror Nodes 1 and 2, except there will be no Repository process on it.
3. Add Coordination Service Ensemble and Client File Service (Windows | Linux).
4. Add the external load balancer (Windows | Linux).
   

A 3-Node Tableau Server HA Deployment (Note: Coordination Service and Client File Service are not explicitly shown)

The need for specialized nodes evolves over time. Extract-heavy and frequent extract refresh workloads should be isolated from the interactive visualization-rendering workload. In an extract-heavy environment, most of data sources are extracts. Having a few extremely large extracts could put your deployment in this category, as would having many small extracts. Deployments where extracts are frequently refreshed, such as several times a day during business hours, should be isolated on specialized Backgrounder nodes. To isolate the workload of the Backgrounder process, add specialized Backgrounder nodes, ensuring redundancy, as shown in Nodes 4 and 5 below. Using node roles, you can configure where certain types of workloads are processed on your Tableau Server installation. The node roles features allows you to dedicate and scale resources to specific workloads. For more information on configuring node roles for Backgrounder and File Store, see Workload Management through Node Roles.

A 5-Node Tableau Server HA Deployment (Note: Coordination Service and Client File Service are not explicitly shown)

 

Starting in 2019.3, you can deploy Tableau Server Repository to Amazon Relational Database Service (RDS). The Tableau Server Repository is a PostgreSQL database that stores data about all user interactions, extract refreshes, and more. Amazon RDS offers scalability, reliability, high availability and security built-in for PostgreSQL. By integrating with AWS to configure Tableau Server external repository, you will be able to take advantage of these additional benefits of deploying the cloud. For more information, see Tableau Server External Repository.

When deploying Tableau Server in the public cloud, you have a few options to further mitigate risk of downtime. For example; deploying each node of Tableau Server in its own Virtual Network or in different Availability Zones/Zones are both supported. However, separating your environment could come at the expense of increased latency across the system. Before finalizing your environment, consider testing both performance and availability to ensure you have the appropriate balance for your data community. Tableau Server does not support deploying a multi-node cluster across different Regions.

Disaster Recovery

When planning for disaster recovery (DR) in your Tableau environment, there are two main factors to consider: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). The RTO is a measure of how much downtime your business can accept before a full recovery, and it influences how often you restore your backups to an alternative cluster and the amount of infrastructure investment. The RPO, a measure of how much data loss your business can tolerate, influences how often you will need to take backups of your system. For Tableau Server the RPO cannot be shorter than the time it takes to complete a full backup of your server. The table below illustrates how to plan for a range of RTO requirements:

 

High RTO	Medium RTO	Low RTO
New hardware/VMs obtained in case of an outage	Machines are provisioned but not running	Dedicated hardware that is always running with identical configuration and topology as production
Install Tableau Server	Tableau Server installed	Backups are restored regularly to the DR environment
Restore backup to the new environment	Restore latest backup to the cold standby environment	External load balancer/DNS routing that can be updated to point to the DR environment
Several hours or days	A few hours	Within minutes

Whether you host Tableau Server on premise or in the cloud, the backup process is the same. Use the TSM Backup command to generate a backup of the Tableau Server and restore that backup on a new machine. Taking a snapshot of a Tableau Server machine, and restoring on a new machine is not supported. For more information, see Mission-Critical Reliability for high-availablity and disaster recovery concepts and whitepapers.