This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Deploy AWS instances for your Vertica database cluster

After you Configure Your Network, you can create AWS instances and deploy Vertica.

1: Configure and launch an instance
2: Connect to an instance
3: Prepare instances for cluster formation
4: Change instances on AWS
5: Configure storage
6: Create a cluster
7: Management Console on AWS

After you Configure your network, you can create AWS instances and deploy Vertica. Follow these procedures to deploy and run Vertica on AWS.

1 - Configure and launch an instance

After you configure your network settings on AWS, configure and launch the instances where you will install Vertica.

After you configure your network settings on AWS, configure and launch the instances where you will install Vertica. An Elastic Compute Cloud (EC2) instance without a Vertica AMI is similar to a traditional host. Just like with an on-premises cluster, you must prepare and configure your cluster and network at the hardware level before you can install Vertica.

When you create an EC2 instance on AWS using a Vertica AMI, the instance includes the Vertica software and the recommended configuration. Vertica recommends that you use the Vertica AMI unmodified. The Vertica AMI acts as a template, requiring fewer configuration steps:

Choose a Vertica AMI Operating Systems
Configure EC2 instances.
Add storage to instances.
Optionally, configure EBS volumes as a RAID array.
Set the security group and S3 access.
Launch instances and verify they are running.

OpenText provides Vertica and Management Console AMIs on the Red Hat Enterprise Linux 8 operating system.

You can use the AMI to deploy MC hosts or cluster hosts. For more information, see the AWS Marketplace.

Configure EC2 instances in AWS

Select a Vertica AMI from the AWS marketplace.For instance type recommendations for Eon Mode databases, see Choosing AWS Eon Mode Instance Types.
Select the desired fulfillment method.
Configure the following:
- Supported instance type
- Number of instances to launch. A Vertica cluster usually uses identically configured instances of the same type.
- VPC placement group

Add storage to instances

Consider the following issues when you add storage to your instances:

Add a number of drives equal to the number of physical cores in your instance—for example, for a c3.8xlarge instance, 16 drives; for an r3.4xlarge, 8 drives.
Do not store your information on the root volume.
Amazon EBS provides durable, block-level storage volumes that you can attach to running instances. For guidance on selecting and configuring an Amazon EBS volume type, see Amazon EBS Volume Types.

Configure EBS volumes as a RAID array

You can configure your EBS volumes into a RAID 0 array to improve disk performance. Before doing so, use the vioperf utility to determine whether the performance of the EBS volumes is fast enough without using them in a RAID array. Pass vioperf the path to a mount point for an EBS volume. In this example, an EBS volume is mounted on a directory named /vertica/data:

[dbadmin@ip-10-11-12-13 ~]$ /opt/vertica/bin/vioperf /vertica/data

The minimum required I/O is 20 MB/s read and write per physical processor core on
each node, in full duplex i.e. reading and writing at this rate simultaneously,
concurrently on all nodes of the cluster. The recommended I/O is 40 MB/s per
physical core on each node. For example, the I/O rate for a server node with 2
hyper-threaded six-core CPUs is 240 MB/s required minimum, 480 MB/s recommended.

Using direct io (buffer size=1048576, alignment=512) for directory "/vertica/data"

test      | directory     | counter name        | counter | counter   | counter       | counter       | thread | %CPU  | %IO Wait  | elapsed | remaining
          |               |                     | value   | value (10 | value/core    | value/core    | count  |       |           | time (s)| time (s)
          |               |                     |         | sec avg)  |               | (10 sec avg)  |        |       |           |         |
--------------------------------------------------------------------------------------------------------------------------------------------------------
Write     | /vertica/data | MB/s                | 259     | 259       | 32.375        | 32.375        | 8      | 4     | 11        | 10      | 65
Write     | /vertica/data | MB/s                | 248     | 232       | 31            | 29            | 8      | 4     | 11        | 20      | 55
Write     | /vertica/data | MB/s                | 240     | 234       | 30            | 29.25         | 8      | 4     | 11        | 30      | 45
Write     | /vertica/data | MB/s                | 240     | 233       | 30            | 29.125        | 8      | 4     | 13        | 40      | 35
Write     | /vertica/data | MB/s                | 240     | 233       | 30            | 29.125        | 8      | 4     | 13        | 50      | 25
Write     | /vertica/data | MB/s                | 240     | 232       | 30            | 29            | 8      | 4     | 12        | 60      | 15
Write     | /vertica/data | MB/s                | 240     | 238       | 30            | 29.75         | 8      | 4     | 12        | 70      | 5
Write     | /vertica/data | MB/s                | 240     | 235       | 30            | 29.375        | 8      | 4     | 12        | 75      | 0
ReWrite   | /vertica/data | (MB-read+MB-write)/s| 237+237 | 237+237   | 29.625+29.625 | 29.625+29.625 | 8      | 4     | 22        | 10      | 65
ReWrite   | /vertica/data | (MB-read+MB-write)/s| 235+235 | 234+234   | 29.375+29.375 | 29.25+29.25   | 8      | 4     | 20        | 20      | 55
ReWrite   | /vertica/data | (MB-read+MB-write)/s| 234+234 | 235+235   | 29.25+29.25   | 29.375+29.375 | 8      | 4     | 20        | 30      | 45
ReWrite   | /vertica/data | (MB-read+MB-write)/s| 233+233 | 234+234   | 29.125+29.125 | 29.25+29.25   | 8      | 4     | 18        | 40      | 35
ReWrite   | /vertica/data | (MB-read+MB-write)/s| 233+233 | 234+234   | 29.125+29.125 | 29.25+29.25   | 8      | 4     | 20        | 50      | 25
ReWrite   | /vertica/data | (MB-read+MB-write)/s| 234+234 | 235+235   | 29.25+29.25   | 29.375+29.375 | 8      | 3     | 19        | 60      | 15
ReWrite   | /vertica/data | (MB-read+MB-write)/s| 233+233 | 236+236   | 29.125+29.125 | 29.5+29.5     | 8      | 4     | 21        | 70      | 5
ReWrite   | /vertica/data | (MB-read+MB-write)/s| 232+232 | 236+236   | 29+29         | 29.5+29.5     | 8      | 4     | 21        | 75      | 0
Read      | /vertica/data | MB/s                | 248     | 248       | 31            | 31            | 8      | 4     | 12        | 10      | 65
Read      | /vertica/data | MB/s                | 241     | 236       | 30.125        | 29.5          | 8      | 4     | 15        | 20      | 55
Read      | /vertica/data | MB/s                | 240     | 232       | 30            | 29            | 8      | 4     | 10        | 30      | 45
Read      | /vertica/data | MB/s                | 240     | 232       | 30            | 29            | 8      | 4     | 12        | 40      | 35
Read      | /vertica/data | MB/s                | 240     | 234       | 30            | 29.25         | 8      | 4     | 12        | 50      | 25
Read      | /vertica/data | MB/s                | 238     | 235       | 29.75         | 29.375        | 8      | 4     | 15        | 60      | 15
Read      | /vertica/data | MB/s                | 238     | 232       | 29.75         | 29            | 8      | 4     | 13        | 70      | 5
Read      | /vertica/data | MB/s                | 238     | 238       | 29.75         | 29.75         | 8      | 3     | 9         | 75      | 0
SkipRead  | /vertica/data | seeks/s             | 22909   | 22909     | 2863.62       | 2863.62       | 8      | 0     | 6         | 10      | 65
SkipRead  | /vertica/data | seeks/s             | 21989   | 21068     | 2748.62       | 2633.5        | 8      | 0     | 6         | 20      | 55
SkipRead  | /vertica/data | seeks/s             | 21639   | 20936     | 2704.88       | 2617          | 8      | 0     | 7         | 30      | 45
SkipRead  | /vertica/data | seeks/s             | 21478   | 20999     | 2684.75       | 2624.88       | 8      | 0     | 6         | 40      | 35
SkipRead  | /vertica/data | seeks/s             | 21381   | 20995     | 2672.62       | 2624.38       | 8      | 0     | 5         | 50      | 25
SkipRead  | /vertica/data | seeks/s             | 21310   | 20953     | 2663.75       | 2619.12       | 8      | 0     | 5         | 60      | 15
SkipRead  | /vertica/data | seeks/s             | 21280   | 21103     | 2660          | 2637.88       | 8      | 0     | 8         | 70      | 5
SkipRead  | /vertica/data | seeks/s             | 21272   | 21142     | 2659          | 2642.75       | 8      | 0     | 6         | 75      | 0

If the EBS volume read and write performance (the entries with Read and Write in column 1 of the output) is greater than 20MB/s per physical processor core (columns 6 and 7), you do not need to configure the EBS volumes as a RAID array to meet the minimum requirements to run Vertica. You may still consider configuring your EBS volumes as a RAID array if the performance is less than the optimal 40MB/s per physical core (as is the case in this example).

Note

If your EC2 instance has hyper-threading enabled, vioperf may incorrectly count the number of cores in your system. The 20MB/s throughput per core requirement only applies to physical cores, rather than virtual cores. If your EC2 instance has hyper-threading enabled, divide the counter value (column 4 in the output) by the number of physical cores. See CPU Cores and Threads Per CPU Core Per Instance Type section in the AWS documentation topic Optimizing CPU Options for a list of physical cores in each instance type.

If you determine you need to configure your EBS volumes as a RAID 0 array, see the AWS documentation topic RAID Configuration on Linux the steps you need to take.

Security group and access

Choose between your previously configured security group or the default security group.
Configure S3 access for your nodes by creating and assigning an IAM role to your EC2 instance. See AWS authentication for more information.

2 - Connect to an instance

Using your private key, take these steps to connect to your cluster through the instance to which you attached an elastic IPaddress:.

Using your private key, take these steps to connect to your cluster through the instance to which you attached an elastic IPaddress:

As the dbadmin user, type the following command, substituting your ssh key:
```
$ ssh --ssh-identity <ssh key> dbadmin@elasticipaddress
```
Select Instances from the Navigation panel.
Select the instance that is attached to the Elastic IP.
Click Connect.
On Connect to Your Instance, choose one of the following options:
- A Java SSH Client directly from my browser—Add the path to your private key in the field Private key path, andclick Launch SSH Client.
- Connect with a standalone SSH client**—**Follow the steps required by your standalone SSH client.

Connect to an instance from windows using putty

If you connect to the instance from the Windows operating system, and plan to use Putty:

Convert your key file using PuTTYgen.
Connect with Putty or WinSCP (connect via the elastic IP), using your converted key (i.e., the *ppk file).
Move your key file (the *pem file) to the root dir using Putty or WinSCP.

3 - Prepare instances for cluster formation

After you create your instances, you need to prepare them for cluster formation.

After you create your instances, you need to prepare them for cluster formation. Prepare your instances by adding your AWS .pem key and your Vertica license.

By default, each AMI includes a Community Edition license. Once Vertica is installed, you can find the license at this location:

/opt/vertica/config/licensing/vertica_community_edition.license.key

As the dbadmin user, copy your *pem file (from where you saved it locally) onto your primary instance.

Depending upon the procedure you use to copy the file, the permissions on the file may change. If permissions change, the install_vertica script fails with a message similar to the following:
```
FATAL (19): Failed Login Validation 10.0.3.158, cannot resolve or connect to host as root.
```
If you receive a failure message, enter the following command to correct permissions on your *pem file:
```
$ chmod 600 /<name-of-pem>.pem
```
Copy your Vertica license over to your primary instance, placing it in your home directory or other known location.

4 - Change instances on AWS

You can change instance types on AWS.

You can change instance types on AWS. For example, you can downgrade a c3.8xlarge instance to c3.4xlarge. See Supported AWS instance types for a list of valid AWS instances.

When you change AWS instances you may need to:

Reconfigure memory settings
Reset memory size in a resource pool
Reset number of CPUs in a resource pool

Reconfigure memory settings

If you change to an AWS instance type that requires a different amount of memory, you may need to recompute the following and then reset the values:

Note

You may need root user permissions to reset these values.

Reset memory size in a resource pool

If you used absolute memory in a resource pool, you may need to reconfigure the memory using the MEMORYSIZE parameter in ALTER RESOURCE POOL.

Note

If you set memory size as a percentage when you created the original resource pool, you do not need to change it here.

Reset number of CPUs in a resource pool

If your new instance requires a different number of CPUs, you may need to reset the CPUAFFINITYSET parameter in ALTER RESOURCE POOL.

5 - Configure storage

Vertica recommends that you store information — especially your data and catalog directories — on dedicated Amazon EBS volumes formatted with a supported file system.

Vertica recommends that you store information — especially your data and catalog directories — on dedicated Amazon EBS volumes formatted with a supported file system. The /opt/vertica/sbin/configure_software_raid.sh script automates the storage configuration process.

Caution

Do not store information on the root volume because it might result in data loss.

Vertica performance tests Eon Mode with a per-node EBS volume of up to 2TB. For best performance, combine multiple EBS volumes into a RAID 0 array.

For more information about RAID 0 arrays and EBS volumes, see RAID configuration on Linux.

Determining volume names

Because the storage configuration script requires the volume names that you want to configure, you must identify the volumes on your machine. The following command lists the contents of the /dev directory. Search for the volumes that begin with xvd:

$ ls /dev

Important

Ignore the root volume. Do not include any of your root volumes in the RAID creation process.

Combining volumes for storage

The configure_software_raid.sh shell script combines your EBS volumes into a RAID 0 array.

Caution

Run configure_software_raid.sh in the default setting only if you have a fresh configuration with no existing RAID settings.

If you have existing RAID settings, open the script in a text editor and manually edit the raid_dev value to reflect your current RAID settings. If you have existing RAID settings and you do not edit the script, the script deletes important operating system device files.

Alternately, use the Management Console (MC) console to add storage nodes without unwanted changes to operating system device files. For more information, see Managing database clusters.

The following steps combine your EBS volumes into RAID 0 with the configure_software_raid.sh script:

Edit the /opt/vertica/sbin/configure_software_raid.sh shell file as follows:
1. Comment out the safety exit command at the beginning .
2. Change the sample volume names to your own volume names, which you noted previously. Add more volumes, if necessary.
Run the /opt/vertica/sbin/configure_software_raid.sh shell file. Running this file creates a RAID 0 volume and mounts it to /vertica/data.
Change the owner of the newly created volume to dbadmin with chown.
Repeat steps 1-3 for each node on your cluster.

6 - Create a cluster

On AWS, use the install_vertica script to combine instances and create a cluster.

On AWS, use the install_vertica script to combine instances and create a cluster. Check your My Instances page on AWS for a list of current instances and their associated IP addresses. You need these IP addresses when you run install_vertica.

Create a cluster as follows:

While connected to your primary instance, enter the following command to combine your instances into a cluster. Substitute the IP addresses for your instances and include your root *.pem file name.
```
$ sudo /opt/vertica/sbin/install_vertica --hosts 10.0.11.164,10.0.11.165,10.0.11.166 \
  --dba-user-password-disabled --point-to-point --data-dir /vertica/data \
  --ssh-identity ~/name-of-pem.pem --license license.file
```
Note
- If you are using Vertica Community Edition, which limits you to three instances, you can specify -L CE with no license file.
- When you issue install_vertica or update_vertica on a Vertica AMI script, --point-to-point is the default. This parameter configures Spread to use direct point-to-point communication between all Vertica nodes, which is a requirement for clusters on AWS.
- If you are using IPv6 network addresses to identify the hosts in your cluster, use the --ipv6 flag in your install_vertica command. You must also use IP addresses instead of host names, as the AWS DNS server cannot resolve host names to IPv6 addresses.
After combining your instances, Vertica recommends deleting your *.pem key from your cluster to reduce security risks. The example below uses the shred command to delete the file:
```
$ shred name-of-pem.pem
```
After creating one or more clusters, create your database or connect to Management Console on AWS.

For complete information on the install_vertica script and its parameters, see Install Vertica with the installation script.

Important

Stopping or rebooting an instance or cluster without first shutting down the database down, may result in disk or database corruption. To safely shut down and restart your cluster, see Operating the database.

Check open ports manually using the netcat utility

Once your cluster is up and running, you can check ports manually through the command line using the netcat (nc) utility. What follows is an example using the utility to check ports.

Before performing the procedure, choose the private IP addresses of two nodes in your cluster.

The examples given below use nodes with the private IPs:

10.0.11.60 10.0.11.61

Install the nc utility on your nodes. Once installed, you can issue commands to check the ports on one node from another node.

To check a TCP port:

Put one node in listen mode and specify the port. The following sample shows how to put IP 10.0.11.60 into listen mode for port 480

[root@ip-10-0-11-60 ~]# nc -l 4804

From the other node, run nc specifying the IP address of the node you just put in listen mode, and the same port number.

[root@ip-10-0-11-61 ~]# nc 10.0.11.60 4804

Enter sample text from either node and it should show up on the other node. To cancel after you have checked a port, enter Ctrl+C.

Note
To check a UDP port, use the same nc commands with the –u option.
```
[root@ip-10-0-11-60 ~]# nc -u -l 4804
[root@ip-10-0-11-61 ~]# nc -u 10.0.11.60 4804
```

7 - Management Console on AWS

Management Console (MC) is a database management tool that allows you to view and manage aspects of your cluster.

Management Console (MC) is a database management tool that allows you to view and manage aspects of your cluster. Vertica provides an MC AMI, which you can use with AWS. The MC AMI allows you to create an instance, dedicated to running MC, that you can attach to a new or existing Vertica cluster on AWS. You can create and attach an MC instance to your Vertica on AWS cluster at any time.

After you launch your MC instance and configure your security group settings, you can log in to your database. To do so, use the elastic IP you specified during instance creation.

From this elastic IP, you can manage your Vertica database on AWS using standard MC procedures.

Considerations when using MC on AWS

Because MC is already installed on the MC AMI, the MC installation process does not apply.
To uninstall MC on AWS, follow the procedures provided in Uninstalling Management Console before terminating the MC Instance.

Deploy AWS instances for your Vertica database cluster

1 - Configure and launch an instance

Configure EC2 instances in AWS

Add storage to instances

Configure EBS volumes as a RAID array

Note

Security group and access

2 - Connect to an instance

Connect to an instance from windows using putty

3 - Prepare instances for cluster formation

4 - Change instances on AWS

Reconfigure memory settings

Note

Reset memory size in a resource pool

Note

Reset number of CPUs in a resource pool

5 - Configure storage

Caution

Determining volume names

Important

Combining volumes for storage

Caution

6 - Create a cluster

Note

Important

Check open ports manually using the netcat utility

Note

7 - Management Console on AWS

Considerations when using MC on AWS

Related topics