Tableau Server Enterprise Deployment Guide

Part 3 describes the requirements for preparing your infrastructure to deploy the Tableau Server reference architecture. Before you begin, we recommend reviewing, Part 2 - Understanding the Tableau Server Deployment Reference Architecture.

In addition to requirement descriptions, this topic provides an implementation example of the reference architecture in an AWS environment. The remainder of this Guide builds on the AWS reference architecture example started in this topic.

A core principle of the reference architecture is standardization with data center security best practices. Specifically, the architecture is designed to segregate services into protected network subnets. Inter-subnet communication is restricted to specific protocol and port traffic.

The following diagram illustrates the reference architecture subnet design for an on-premises deployment or a customer-managed cloud deployment. For an example cloud deployment, see the section below, Example: Configure subnets and security groups in AWS.

Subnets

Create three subnets: 

• A web tier
• An application tier
• A data subnet.

Firewall/Security group rules

The tabs below describe the firewall rules for each tier of the datacenter. For AWS-specific security group rules, see the section later in this topic.

Example: Configure subnets and security groups in AWS

This section provides step-by-step procedures to create and configure the VPC and network environment for the Tableau Server reference architecture deployment in AWS.

The slides below show the reference architecture in four layers. As you progress through the slides, component elements are layered onto the topology map:

1. VPC subnet topology and EC2 instances: one bastion host, two reverse proxy servers, four Tableau servers, and at least one PostgreSQL server.
2. Protocol flow and internet connectivity. All inbound traffic is managed through the AWS internet gateway. Traffic to the internet is routed through the NAT.
3. Availability zones. The proxy, Tableau Server, and PostgreSQL hosts are evenly deployed across two Availability Zones.
4. Security groups. Four security groups (Public, Private, Data, and Bastion) protect each tier at the protocol level.

AWS Availability Zones and high availability

The reference architecture as presented in this Guide specifies a deployment that provides availability through redundancy when any single host fails. However, in the AWS case where the reference architecture is deployed across two Availability Zones, availability is compromised in the very rare case where an Availability Zone fails.

VPC configuration

This section describes how to:

• Install and configure the VPC
• Configure internet connectivity
• Configure subnets
• Create and configure security groups

Configure VPC

The procedure in this section maps to the UI in the "classic" VPC Experience. You can toggle the UI to display the classic view by turning off the New VPC Experience in the upper-left corner of the AWS VPC Dashboard.

Run VPC wizard to create default Private and Public subnets and default routing and network ACL.

1. Before you configure a VPC, you must create an Elastic IP. Create an allocation using all defaults.
2. Run VPC wizard > "VPC with Public and Private Subnets"
3. Accept most defaults. Except for the following: 
   • Enter a VPC name.
   • Specify the Elastic IP Allocation ID.
   •  Specify the following CIDR masks:
     • Public subnet's IPv4 CIDR: 10.0.1.0/24, rename this subnet to Public-a.
     • Private subnet's IPv4 CIDR: 10.0.30.0/24, rename this subnet to Private-a.
   • Availability Zone: for both subnets, select the a option for the region that you are in.

     Note: For the purposes of this example, we use a and b to distinguish between Availability Zones in a given AWS datacenter. In AWS, Availability Zone names may not match the examples shown here. For example, some Availability Zones include c and d zones within a datacenter.

4. Click Create VPC.
5. After VPC is created, create Public-b, Private-b, Data, and Bastion subnets. To create a subnet, click Subnets > Create subnet.

   • Public-b: For Availability Zone, select the b option for the region that you are in. CIDR block: 10.0.2.0/24

   • Private-b: For Availability Zone, select the b option for the region that you are in. CIDR block: 10.0.31.0/24
   • Data: For Availability Zone, select the a zone for the region that you are in. CIDR block: 10.0.50.0/24. Optional: If you plan to replicate the external database across a PostgreSQL cluster, then create a Data-b subnet in Availability Zone b with a CIDR block of 10.0.51.0/24.
   • Bastion: For Availability Zone, select either zone. CIDR block: 10.0.0.0/24
6. After the subnets are created, edit the route tables on the Public and the Bastion subnets to use the route table that is configured for the associated internet gateway (IGW). And edit the Private and Data subnets to use the route table that is configured for the network address translator (NAT).
   • To determine which route table is configured with the IGW or the NAT, click Route Tables in AWS dashboard. Select one of the two route table links to open the property page. Look at the Target value at Routes > Destination> 0.0.0.0/0. The Target value differentiates the type of route and will either start with the igw- or nat- string.
   • To update route tables, VPC > Subnets > [subnet_name] > Route table > Edit route table association.

Configure security groups

The VPC wizard creates a single security group that you will not use. Create the following security groups (Security Groups > Create security group). The EC2 hosts will be installed into these groups across two Availability Zones as shown in the slide-diagram above.

• Create a new security group: Private. This is where all 4 nodes of Tableau Server will be installed. Later in the installation process, the Private security group will be associated with the 10.0.30.0/24 and 10.0.31.0/24 subnets.
• Create a new security group: Public. This is where proxy servers will be installed. Later in the installation process, the Public security group will be associated with the 10.0.1.0/24 and 10.0.2.0/24 subnets.
• Create a new security group: Data. This is where the PostgreSQL external Tableau repository will be installed. Later in the installation process, the Data security group will be associated with the 10.0.50.0/24 (and optionally, 10.0.51.0/24) subnet.
• Create a new security group: Bastion. This is where you'll install the bastion host. Later in the installation process, the Bastion security group will be associated with the 10.0.0.0/24 subnet.

Specify inbound and outbound rules

In AWS, security groups are analogous to firewalls in an on-prem environment. You must specify the traffic type, (eg, https, https, etc), protocol (TCP or UDP), and ports or port range (eg 80, 443, etc) that are allowed to pass in and/or out of the security group. For each protocol you must also specify the destination or source traffic.

Public security group rules

Inbound rules
Type	Protocol	Port range	Source
HTTP	TCP	80	0.0.0.0/0
HTTPS	TCP	443	0.0.0.0/0
SSH	TCP	22	Bastion security group

 

Outbound rules
Type	Protocol	Port range	Destination
All traffic	All	All	0.0.0.0/0

Private security group rules

The Private security group includes an inbound rule to allow HTTP traffic from the Public security group. Allow HTTP traffic only during the deployment process to verify connectivity. We recommend removing the HTTP inbound rule after you have finished deploying the reverse proxy and configuring SSL to Tableau.

Inbound rules
Type	Protocol	Port range	Source
HTTP	TCP	80	Public security group
HTTPS	TCP	443	Public security group
PostgreSQL	TCP	5432	Data security group
SSH	TCP	22	Bastion security group
All traffic	All	All	Private security group

 

Outbound rule
Type	Protocol	Port range	Destination
All traffic	All	All	0.0.0.0/0
PostgreSQL	TCP	5432	Data security group
SSH	TCP	22	Bastion security group

Data security group rules

Inbound rules
Type	Protocol	Port range	Source
PostgreSQL	TCP	5432	Private security group
SSH	TCP	22	Bastion security group

 

Outbound rules
Type	Protocol	Port range	Destination
All traffic	All	All	0.0.0.0/0
PostgreSQL	TCP	5432	Private security group
SSH	TCP	22	Bastion security group

Bastion host security group rules

Inbound rules
Type	Protocol	Port range	Source
SSH	TCP	22	The IP address and net mask of the computer that you will use to log into AWS (admin computer).
SSH	TCP	22	Private security group
SSH	TCP	22	Public security group

 

Outbound rules
Type	Protocol	Port range	Destination
SSH	TCP	22	The IP address and net mask of the computer that you will use to log into AWS (admin computer).
SSH	TCP	22	Private security group
SSH	TCP	22	Public security group
SSH	TCP	22	Data security group
HTTPS	TCP	443	0.0.0.0/0 (Optional: create this rule if you need to access the internet to download supporting software on the bastion host)

Enable auto-assign public IP

This provides you with an IP address for connecting to the proxy servers and bastion host.

For Public and Bastion subnets:

1. Select the subnet
2. Under Actions menu, select "Modify auto-assign IP settings."
3. Click "Enable auto-assign public IPv4 addresses."
4. Click Save.

Load balancer

Note: If you are installing into AWS and following the example deployment in this guide, then you should install and configure the AWS load balancer later in the deployment process, as described in Part 5 - Configuring Web Tier.

For on-premises deployments, work with your network administrators to deploy load balancers to support the web tier of the reference architecture:

• A web-facing application load balancer that accepts HTTPS requests from Tableau clients and communicates with the reverse proxy servers.
• Reverse proxy: 
  • We recommend a minimum of two proxy servers for redundancy and to handle client load.
  • Receives HTTPS traffic from load balancer.
  • Supports sticky session to Tableau host.
  • Configure proxy for round robin load balancing to each Tableau Server running the Gateway process.
  • Handles authentication requests from external IdP.
• Forward proxy: Tableau Server requires access to the internet for licensing and map functionality. Depending on your forward proxy environment, you may need to configure forward proxy safelists for Tableau service URLs. See Communicating with the Internet (Linux(Link opens in a new window)).

Configure host computers

Minimum recommended hardware

The following recommendations are based on our testing of real-world data in the reference architecture.

Application servers:

• CPU: 8 physical cores (16vCPUs),
• RAM: 128 GB (16 GB/physical Core)
• Disk space: 100 GB

Data servers

• CPU: 8 physical cores (16vCPUs),
• RAM: 128 GB (16 GB/physical Core)
• Disk space: 1 TB. If your deployment will make use of external storage for the Tableau File Store, you will need calculate the appropriate disk space. See Install Tableau Server with External File Store (Linux(Link opens in a new window)).

Proxy servers

• CPU: 2 physical cores (4vCPUs),
• RAM: 8 GB (4 GB/physical Core)
• Disk space: 100 GB

External repository database

• CPU: 8 physical cores (16vCPUs),
• RAM: 128 GB (16 GB/physical Core)
• Disk space requirement is dependent on your data load and how that will impact backup. See the section, Backup and restore processes, in the topic, Disk Space Requirements (Linux(Link opens in a new window)).

Directory structure

The reference architecture recommends installing the Tableau Server package and the data into non-default locations:

• Install package to: /app/tableau_server: Create this directory path before you install the Tableau Server package, and then specify this path during installation.
• Install Tableau data to: /data/tableau_data. Do not create this directory before you install Tableau Server. Instead, you must specify the path during installation, and then Tableau Setup will create and permission the path appropriately.

See Run installation package and initialize TSM for implementation details.

Example: Install and prep host computers in AWS

Verification: VPC connectivity

After you have installed the host computers, verify network configuration. Verify connectivity between the hosts by connecting with SSH from the host in the Bastion security group to the hosts in each subnet.