Part 3 - Preparing for Tableau Server Enterprise Deployment
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.
Traffic | Type | Protocol | Port range | Source |
---|---|---|---|---|
Inbound | SSH | TCP | 22 | Bastion subnet (for cloud deployments) |
Inbound | HTTP | TCP | 80 | Internet (0.0.0.0/0) |
Inbound | HTTPS | TCP | 443 | Internet (0.0.0.0/0) |
Outbound | All traffic | All | All |
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.
Traffic | Type | Protocol | Port range | Source |
---|---|---|---|---|
Inbound | SSH | TCP | 22 | Bastion subnet (for cloud deployments) |
Inbound | HTTPS | TCP | 443 | Web tier subnet |
Outbound | All traffic | All | All |
The data subnet is where the external PostgreSQL database server resides.
Traffic | Type | Protocol | Port range | Source |
---|---|---|---|---|
Inbound | SSH | TCP | 22 | Bastion subnet (for cloud deployments) |
Inbound | PostgreSQL | TCP | 5432 | Application tier subnet |
Outbound | All traffic | All | All |
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.
Traffic | Type | Protocol | Port range | Source | Destination |
---|---|---|---|---|---|
Inbound | SSH | TCP | 22 | Admin computer IP address | |
Outbound | SSH | TCP | 22 | Web tier subnet | |
Outbound | SSH | TCP | 22 | 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:
- VPC subnet topology and EC2 instances: one bastion host, two reverse proxy servers, four Tableau servers and at least one PostgreSQL server.
- Protocol flow and internet connectivity. All inbound traffic is managed through the AWS internet gateway. Traffic to the internet is routed through the NAT.
- Availability zones. The proxy, Tableau Server and PostgreSQL hosts are evenly deployed across two Availability Zones.
- 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.
- Before you configure a VPC, you must create an Elastic IP. Create an allocation using all defaults.
- Run VPC wizard > "VPC with Public and Private Subnets"
- 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
.
- Public subnet's IPv4 CIDR: 10.0.1.0/24, rename this subnet to
- 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.
- Click Create VPC.
- After VPC is created, create
Public-b
,Private-b
,Data
, andBastion
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/24Private-b
: For Availability Zone, select the b option for the region that you are in. CIDR block: 10.0.31.0/24Data
: 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
- 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-
ornat-
string. - To update route tables, VPC > Subnets > [subnet_name] > Route table > Edit route table association.
- 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
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, (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 | |||
---|---|---|---|
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 in to 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 in to 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:
- Select the subnet
- Under Actions menu, select "Modify auto-assign IP settings".
- Click "Enable auto-assign public IPv4 addresses."
- 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 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
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).
Connect to the bastion host by running the following command:
ssh -A ec2-user@<public-IP>
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