This is the multi-page printable view of this section.
Click here to print.
Return to the regular view of this page.
Configure your network
Before you deploy your cluster, you must configure the network on which Vertica will run.
Before you deploy your cluster, you must configure the network on which Vertica will run. Vertica requires a number of specific network configurations to operate on AWS. You may also have specific network configuration needs beyond the default Vertica settings.
Important
You can create a Vertica database that uses IPv6 for internal communications running on AWS. However, if you do so, you must identify the hosts in your cluster using IP addresses rather than host names. The AWS DNS resolution service is incompatible with IPv6.
The following sections explain which Amazon EC2 features you need to configure for instance creation.
1 - Create a placement group, key pair, and VPC
Part of configuring your network for AWS is to create the following:.
Part of configuring your network for AWS is to create the following:
Create a placement group
A placement group is a logical grouping of instances in a single Availability Zone. Placement Groups are required for clusters and all Vertica nodes must be in the same Placement Group.
Vertica recommends placement groups for applications that benefit from low network latency, high network throughput, or both. To provide the lowest latency, and the highest packet-per-second network performance for your Placement Group, choose an instance type that supports enhanced networking.
For information on creating placement groups, see Placement Groups in the AWS documentation.
Create a key pair
You need a key pair to access your instances using SSH. Create the key pair using the AWS interface and store a copy of your key (*.pem) file on your local machine. When you access an instance, you need to know the local path of your key.
Use a key pair to:
for information on creating a key pair, see Amazon EC2 Key Pairs in the AWS documentation.
Create a virtual private cloud (VPC)
You create a Virtual Private Cloud (VPC) on Amazon so that you can create a network of your EC2 instances. Your instances in the VPC all share the same network and security settings.
A Vertica cluster on AWS must be logically located in the same network. Create a VPC to ensure the nodes in you cluster can communicate with each other in AWS.
Create a single public subnet VPC with the following configurations:
Note
A Vertica cluster must be operated in a single availability zone.
For information on creating a VPC, see Create a Virtual Private Cloud (VPC) in the AWS documentation.
2 - Network ACL settings
Vertica requires the following network access control list (ACL) settings on an AWS instance running the Vertica AMI.
Vertica requires the following basic network access control list (ACL) settings on an AWS instance running the Vertica AMI. Vertica recommends that you secure your network with additional ACL settings that are appropriate to your situation.
Inbound Rules
Type |
Protocol |
Port Range |
Use |
Source |
Allow/Deny |
SSH |
TCP (6) |
22 |
SSH (Optional—for access to your cluster from outside your VPC) |
User Specific |
Allow |
Custom TCP Rule |
TCP (6) |
5450 |
MC (Optional—for MC running outside of your VPC) |
User Specific |
Allow |
Custom TCP Rule |
TCP (6) |
5433 |
SQL Clients (Optional—for access to your cluster from SQL clients) |
User Specific |
Allow |
Custom TCP Rule |
TCP (6) |
50000 |
Rsync (Optional—for backup outside of your VPC) |
User Specific |
Allow |
Custom TCP Rule |
TCP (6) |
1024-65535 |
Ephemeral Ports (Needed if you use any of the above) |
User Specific |
Allow |
ALL Traffic |
ALL |
ALL |
N/A |
0.0.0.0/0 |
Deny |
Outbound Rules
Type |
Protocol |
Port Range |
Use |
Source |
Allow/Deny |
Custom TCP Rule |
TCP (6) |
0–65535 |
Ephemeral Ports |
0.0.0.0/0 |
Allow |
You can use the entire port range specified in the previous table, or find your specific ephemeral ports by entering the following command:
$ cat /proc/sys/net/ipv4/ip_local_port_range
For detailed information on network ACLs within AWS, refer to Network ACLs in the Amazon documentation.
For detailed information on ephemeral ports within AWS, refer to Ephemeral Ports in the Amazon documentation.
3 - Configure TCP keepalive with AWS network load balancer
AWS supports three types of elastic load balancers (ELBs):.
AWS supports three types of elastic load balancers (ELBs):
Vertica strongly recommends the AWS Network Load Balancer (NLB), which provides the best performance with your Vertica database. The Network Load Balancer acts as a proxy between clients (such as JDBC) and Vertica servers. The Classic and Application Load Balancers do not work with Vertica, in Enterprise Mode or Eon Mode.
To avoid timeouts and hangs when connecting to Vertica through the NLB, it is important to understand how AWS NLB handles idle timeouts for connections. For the NLB, AWS sets the idle timeout value to 350 seconds and you cannot change this value. The timeout applies to both connection points.
For a long-running query, if either the client or the server fails to send a timely keepalive, that side of the connection is terminated. This can lead to situations where a JDBC client hangs waiting for results that would never be returned because the server fails to send a keepalive within 350 seconds.
To identify an idle timeout/keepalive issue, run a query like this via a client such as JDBC:
=> SELECT SLEEP(355);
If there’s a problem, one of the following situations occurs:
-
The client connection terminates before 355 seconds. In this case, lower the JDBC keepalive setting so that keepalives are sent less than 350 seconds apart.
-
The client connection doesn’t return a result after 355 seconds. In this case, you need to adjust the server keepalive settings (tcp_keepalive_time and tcp_keepalive_intvl) so that keepalives are sent less than 350 seconds apart.
You can adjust the keepalive settings on the server, or you can adjust them in Vertica.
For detailed information about AWS Network Load Balancers, see the AWS documentation.
4 - Create and assign an internet gateway
When you create a VPC, an Internet gateway is automatically assigned to it.
When you create a VPC, an Internet gateway is automatically assigned to it. You can use that gateway, or you can assign your own. If you are using the default Internet gateway, continue with the procedure described in Create a security group.
Otherwise, create an Internet gateway specific to your needs. Associate that internet gateway with your VPC and subnet.
For information about how to create an Internet Gateway, see Internet Gateways in the AWS documentation.
5 - Assign an elastic IP address
An elastic IP address is an unchanging IP address that you can use to connect to your cluster externally.
An elastic IP address is an unchanging IP address that you can use to connect to your cluster externally. Vertica recommends you assign a single elastic IP to a node in your cluster. You can then connect to other nodes in your cluster from your primary node using their internal IP addresses dictated by your VPC settings.
Create an elastic IP address. For information, see Elastic IP Addresses in the AWS documentation.
6 - Create a security group
The Vertica AMI has specific security group requirements.
The Vertica AMI has specific security group requirements. When you create a Virtual Private Cloud (VPC), AWS automatically creates a default security group and assigns it to the VPC. You can use the default security group, or you can name and assign your own.
Create and name your own security group using the following basic security group settings. You may make additional modifications based on your specific needs.
Inbound
Type |
Use |
Protocol |
Port Range |
IP |
SSH |
|
TCP |
22 |
The CIDR address range of administrative systems that require SSH access to the Vertica nodes. Make this range as restrictive as possible. You can add multiple rules for separate network ranges, if necessary. |
DNS (UDP) |
|
UDP |
53 |
Your private subnet address range (for example, 10.0.0.0/24). |
Custom UDP |
Spread |
UDP |
4803 and 4804 |
Your private subnet address range (for example, 10.0.0.0/24). |
Custom TCP |
Spread |
TCP |
4803 |
Your private subnet address range (for example, 10.0.0.0/24). |
Custom TCP |
VSQL/SQL |
TCP |
5433 |
The CIDR address range of client systems that require access to the Vertica nodes. This range should be as restrictive as possible. You can add multiple rules for separate network ranges, if necessary. |
Custom TCP |
Inter-node Communication |
TCP |
5434 |
Your private subnet address range (for example, 10.0.0.0/24). |
Custom TCP |
|
TCP |
5444 |
Your private subnet address range (for example, 10.0.0.0/24). |
Custom TCP |
MC |
TCP |
5450 |
The CIDR address of client systems that require access to the management console. This range should be as restrictive as possible. You can add multiple rules for separate network ranges, if necessary. |
Custom TCP |
Rsync |
TCP |
50000 |
Your private subnet address range (for example, 10.0.0.0/24). |
ICMP |
Installer |
Echo Reply |
N/A |
Your private subnet address range (for example, 10.0.0.0/24). |
ICMP |
Installer |
Traceroute |
N/A |
Your private subnet address range (for example, 10.0.0.0/24). |
Note
In Management Console (MC), the Java IANA discovery process uses port 7 once to detect if an IP address is reachable before the database import operation. Vertica tries port 7 first. If port 7 is blocked, Vertica switches to port 22.
Outbound
Type |
Protocol |
Port Range |
Destination |
IP |
All TCP |
TCP |
0-65535 |
Anywhere |
0.0.0.0/0 |
All ICMP |
ICMP |
0-65535 |
Anywhere |
0.0.0.0/0 |
All UDP |
UDP |
0-65535 |
Anywhere |
0.0.0.0/0 |
For information about what a security group is, as well as how to create one, see Amazon EC2 Security Groups for Linux Instances in the AWS documentation.