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 standardisation with data centre 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 data centre. For AWS-specific security group rules, see the section later in this topic.

The web tier is a public DMZ subnet that will handle inbound HTTPS requests and proxy the requests to the application tier. This design provides a layer of defence from malware that may be targeted at your organisation. The web tier blocks access to the application/data tier.

TrafficTypeProtocolPort rangeSource

Inbound

SSHTCP22Bastion subnet (for cloud deployments)
InboundHTTPTCP80Internet (0.0.0.0/0)
InboundHTTPSTCP443Internet (0.0.0.0/0)
OutboundAll trafficAllAll 

The application subnet is where the Tableau Server deployment resides. The application subnet includes the Tableau application servers (Node 1 and Node 2). The Tableau application servers process user requests to the data servers and run core business logic.

The application subnet also includes the Tableau data servers (Node 3 and Node 4).

All client traffic to the application tier is authenticated at the web tier. Administrative access to the application subnet is authenticated and routed through the bastion host.

TrafficTypeProtocolPort rangeSource

Inbound

SSHTCP22Bastion subnet (for cloud deployments)
InboundHTTPSTCP443Web tier subnet
OutboundAll trafficAllAll 

The data subnet is where the external PostgreSQL database server resides.

TrafficTypeProtocolPort rangeSource

Inbound

SSHTCP22Bastion subnet (for cloud deployments)
InboundPostgreSQLTCP5432Application tier subnet
OutboundAll trafficAllAll 

Most enterprise security teams do not allow direct communication from the on-premises administrative system to the nodes deployed in the cloud. Instead, all administrative SSH traffic to the cloud nodes is proxied through a bastion host (also referred to as a "jump server"). For cloud deployments, we recommend bastion host proxy connection to all resources in the reference architecture. This is an optional configuration for on-premises environments.

The bastion host authenticates administrative access and only allows traffic over SSH protocol.

TrafficTypeProtocolPort rangeSourceDestination

Inbound

SSHTCP22Admin computer IP address 
OutboundSSHTCP22 Web tier subnet
OutboundSSHTCP22 Application tier subnet

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 data centre.

  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, 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, VPCSubnets > [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 GroupsCreate 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, (e.g. https, https, etc.), protocol (TCP or UDP) and ports or port range (e.g. 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
TypeProtocolPort rangeSource
HTTPTCP800.0.0.0/0
HTTPSTCP4430.0.0.0/0
SSHTCP22Bastion security group

 

Outbound rules
TypeProtocolPort rangeDestination
All trafficAllAll0.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
TypeProtocolPort rangeSource
HTTPTCP80Public security group
HTTPSTCP443Public security group
PostgreSQLTCP5432Data security group
SSHTCP22Bastion security group
All trafficAllAllPrivate security group

 

Outbound rule
TypeProtocolPort rangeDestination
All trafficAllAll0.0.0.0/0
PostgreSQLTCP5432Data security group
SSHTCP22Bastion security group

Data security group rules

Inbound rules
TypeProtocolPort rangeSource
PostgreSQLTCP5432Private security group
SSHTCP22Bastion security group

 

Outbound rules
TypeProtocolPort rangeDestination
All trafficAllAll0.0.0.0/0
PostgreSQLTCP5432Private security group
SSHTCP22Bastion security group

Bastion host security group rules

Inbound rules
TypeProtocolPort rangeSource
SSHTCP22The IP address and net mask of the computer that you will use to log in to AWS (admin computer).
SSHTCP22Private security group
SSHTCP22Public security group

 

Outbound rules
TypeProtocolPort rangeDestination
SSHTCP22The IP address and net mask of the computer that you will use to log in to AWS (admin computer).
SSHTCP22Private security group
SSHTCP22Public security group
SSHTCP22Data security group
HTTPSTCP4430.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

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 to 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 initialise TSM for implementation details.

Example: Install and prep host computers in AWS

This section explains how to install EC2 hosts for each server type in the Tableau Server reference architecture.

The reference architecture requires eight hosts:

  • Four instances for Tableau Server.
  • Two instances for proxy servers (Apache).
  • One instance for bastion host.
  • One or two EC2 PostgreSQL database instances

Host instance details

Install host computers according to the details below.

Tableau Server

  • Amazon Linux 2
  • Instance Type: m5a.8xlarge
  • Security group ID: Private
  • Storage: EBS, 150 GiB, gp2 volume type. If your deployment will make use of external storage for the Tableau File Store, you will need to calculate the appropriate disk space. See Install Tableau Server with External File Store (Linux(Link opens in a new window)).
  • Network: install two EC2 hosts in each private subnet (10.0.30.0/24 and 10.0.31.0/24).
  • Copy the latest maintenance release of Tableau Server 2021.2 (or later) rpm package from Tableau Downloads page(Link opens in a new window) to each Tableau host.

Bastion host

  • Amazon Linux 2
  • Instance Type: t3.micro
  • Security group ID: Bastion
  • Storage: EBS, 50 GiB, gp2 volume type
  • Network: Bastion subnet 10.0.0.0/24

Tableau Server Independent Gateway

  • Amazon Linux 2
  • Instance Type: t3.xlarge
  • Security group ID: Public
  • Storage: EBS, 100 GiB, gp2 volume type
  • Network: Install one EC2 instance in each public subnet (10.0.1.0/24 and 10.0.2.0/24)

PostgreSQL EC2 host

  • Amazon Linux 2
  • Instance Type: r5.4xlarge
  • Security group ID: Data
  • Storage: 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)).
  • Network: Data subnet 10.0.50.0/24. (If you are replicating PostgreSQL in a HA cluster, then install the second host in the 10.0.51.0/24 subnet)

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.

Example: Connect to bastion host in AWS

  1. Set up your admin computer for ssh-agent. This allows you to connect to hosts in AWS without placing your private key file on any EC2 instances.

    To configure ssh-agent on a Mac, run the following command:

    ssh-add -K myPrivateKey.pem or for latest Mac OS, ssh-add --apple-use-keychain myPrivateKey.pem

    For Windows, see the topic, Securely Connect to Linux Instances Running in a Private Amazon VPC(Link opens in a new window).


  2. Connect to the bastion host by running the following command:

    ssh -A ec2-user@<public-IP>

  3. You can then connect to other hosts in the VPC from the bastion host, using the private IP address, for example:

    ssh -A ec2-user@10.0.1.93

Thanks for your feedback!