Install Exasol - step by step

Introduction

You can install Exasol as an application on Linux hosts running either on hardware or on VM instances on a cloud service such as AWS, Azure, or Google Cloud Platform (GCP). The system requirements and procedures for installation and administration are essentially the same regardless of which platform the Linux host is running on.

If your system will be hosted on a cloud service, refer to the documentation from the cloud service provider for information about how to configure network and security settings for your Exasol deployment on that platform.

The installation procedure can be broken down into three major stages: the Preparation stage, where you prepare the installation environment, the Installation stage, where you download the deployment tool and run the installation on the hosts, and the Post-Installation stage, where you can connect to the cluster, upload a license, and carry out any other additional actions to prepare the database for use.

The following diagram is a schematic overview of the installation procedure. You can click in the diagram to navigate directly to the corresponding section in the documentation.

You can run the installation process from a separate Linux system (jump host) or from one of the database host systems. In both cases the host running the installation will require access to the other hosts over SSH.

If you install Exasol on a single host system without using a jump host, SSH is not required for the installation process. We recommend setting up SSH anyway, as this enables passwordless login and makes it easier to extend the installation at a later stage by adding more hosts.

Prerequisites

The database hosts must be pre-installed with one of the recommended Linux distributions and meet the minimum system requirements for an Exasol installation. The following requirements must be checked:

• The nodes must run on a supported CPU type

• Storage devices must be of a supported type with RAID configuration as required

• Each node must have enough storage space for installation and updates

• The nodes must have a supported operating system version installed and configured as required

• All software dependencies must be fulfilled for the database nodes (and optional jump host)

For details about the requirements for installing Exasol, see System Requirements.

The following procedure describes how to install Exasol with a user having root privileges on the database hosts. To install Exasol for a non-root user, additional configuration steps are required. For more information, see Rootless Installation.

Step 2: Create the installation user

Step 3: Set up SSH authentication

Step 4: Prepare storage devices

# this system is not using a volume manager:
lsblk -p
NAME     MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
/dev/sda   8:0    0 388.5M  1 disk
/dev/sdb   8:16   0     4G  0 disk [SWAP]
/dev/sdc   8:32   0   256G  0 disk /mnt/wslg/distro

# this system is using a logical volume manager:
lsblk -p
NAME              MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
/dev/loop1          7:1    0 91.9M  1 loop
/dev/nvme0n1      259:0    0  100G  0 disk
|-/dev/nvme0n1p1  259:4    0 99.9G  0 part /etc/ssh
|-/dev/nvme0n1p14 259:5    0    4M  0 part
`-/dev/nvme0n1p15 259:6    0  106M  0 part
/dev/nvme3n1      259:1    0   50G  0 disk

Exasol Deployment Tool (c4) is a command-line application that is used to install Exasol on a single host or multiple hosts in a network. The c4 application can run either on a separate system (jump host) or on one of the database hosts.

Database and c4 version dependencies

The version of c4 used for installation must be compatible with the Exasol database version that you install. The latest version of the database is always compatible with the latest version of c4.

Exasol database and c4 version compatibility table

Exasol database version	Required c4 version
8.34.0	4.25.0
8.33.0	4.24.3
8.32.0	4.23.0
8.31.0	4.20.0
8.29.7	4.19.4
8.29.6	4.19.3
8.29.3	4.19.2
8.29.2	4.19.0
8.29.1	4.19.0
8.29.0	4.19.0
8.28.4	4.17.5
8.28.2	4.17.4
8.27.0	4.16.0
8.26.1	4.15.0
8.26.0	4.15.0
8.25.0	4.14.1
8.24.0	4.13.0
8.23.4	0.4.12
8.22.0	0.4.11
8.21.0	0.4.11
8.20.0	0.4.10
8.18.1	0.4.10
8.18.0	0.4.10

You must make the c4 binary executable for all users on the host by using chmod +x c4. Otherwise the application will not be able to run the installation. For more information, see Install c4.

On the host that will be used to run the installation, create a file with the filename config in the same directory as the c4 binary. For example, if you are using the nano text editor:

nano ./config

The configuration file should define the following parameters:

The username for the installation user can be any name allowed by the operating system. In the following examples, the user has the username exasol.

Example configuration

The following configuration file will result in a deployment with 3 database nodes and one reserve node.

CCC_HOST_ADDRS="10.0.0.11 10.0.0.12 10.0.0.13 10.0.0.14"
CCC_HOST_EXTERNAL_ADDRS="203.0.113.11 203.0.113.12 203.0.113.13 203.0.113.14"
CCC_HOST_DATADISK=/dev/mapper/exasol_disk_1,/dev/mapper/exasol_disk_2
CCC_HOST_IMAGE_USER=exasol
CCC_HOST_IMAGE_PASSWORD=exasol123
CCC_HOST_KEY_PAIR_FILE=id_rsa
CCC_PLAY_WORKING_COPY=@exasol-8.32.0
CCC_PLAY_DB_PASSWORD=exasol456
CCC_PLAY_RESERVE_NODES=1

Always replace the default passwords by setting unique, secure passwords in your configuration file. Never use the passwords that are used in the examples in this documentation.

Run diagnostic tool (optional)

Before you start the installation you can run a diagnostic tool on your configuration. By using this tool you can detect issues before starting the installation. The diagnostic tool will check things like ssh accessibility to the hosts, sudo password correctness (if the CCC_HOST_IMAGE_PASSWORD parameter is set), missing required parameters, etc.

To run the diagnostic tool, use c4 host diag -i <path to configuration>. For example:

./c4 host diag -i /path_to_config_file/myconfig
OK check_disks
OK check_external_dependencies
OK check_internal_dependencies
OK check_required_params
OK check_sudo

For more information about the diagnostic tool, use c4 host diag --help.

Create a local archive volume

1. On one of the nodes in the deployment, use c4 connect -t <DEPLOYMENT>[.<NODE]/cos to connect to the cluster operating system (COS). For example:
   

   ./c4 connect -t 1/cos

   In most cases it does not matter which node you connect to. If you do not specify a node, c4 will connect to the first active node in the deployment. The command prompt in COS indicates which node you are connected to. For example, if you are connected as root to node 11:

   [root@n11 ~]#

   For more information about how to use c4 connect, see How to use c4.

2. To create a local archive volume, use the ConfD job st_volume_create with the parameters described in the following table.

   Some parameters values for the new archive volume must match the corresponding values for the data volume. To find out the values used by the data volume, use the ConfD jobs db_info and st_node_list.

   Click to show example output from db_info

   confd_client db_info db_name: Exasol
   config:
   ...
     nodes:
     - 11
     - 12
     - 13
     - 14
     num_active_nodes: 3
   ...
     owner:
     - 500
     - 500
   ...
   nodes:
     active:
     - n11
     - n12
     - n13
     reserve:
     - n14
    ...

   Click to show example output from st_node_list

   confd_client st_node_list
   '0':
     hdd_free_space:
       disk1: 93.5566 GiB
     hdds:
       name: /dev/nvme2n1
       type: disk1
       ...
       name: /dev/nvme3n1
       type: disk1
       ...
     name: n11
      ...
   '1':
     hdd_free_space:
       disk1: 93.5566 GiB
     hdds:
       name: /dev/nvme2n1
       type: disk1
       ...
       name: /dev/nvme3n1
       type: disk1
       ...
     name: n12
       ...
   '2':
     hdd_free_space:
       disk1: 93.5566 GiB
     hdds:
       name: /dev/nvme2n1
       type: disk1
       ...
       name: /dev/nvme3n1
       type: disk1
       ...
     name: n13
       ...
    '3':
     hdd_free_space:
       disk1: 93.5566 GiB
     hdds:
       name: /dev/nvme2n1
       type: disk1
       ...
       name: /dev/nvme3n1
       type: disk1
       ...
     name: n14
       ...

   Required parameters

   Parameter name	Data type	Value
   disk	string	The disk name in Exasol for the storage disk where the data volume resides.
   owner	tuple, list	Owner tuple (or list of tuples) for the data volume.
   nodes	list	List of node IDs in the data volume.
   num_master_nodes	integer	The number of master nodes (active nodes) in the data volume.
   name	string	A name for the new archive volume.
   redundancy	integer	The redundancy level of the archive volume.
   size	string	Volume size for the archive volume as a string, with unit (MiB, GiB, or TiB). The size value depends on the database size and the backup schedule.
   partition_size	string, integer	4294967296 for volumes <250 GiB 34359738368 for volumes ≥ 250 GiB and <1TiB 274877906944 for volumes ≥ 1 TiB
   shared	boolean	true
   type	string	archive
   block_size	string	512 KiB
   stripe_size	string	512 KiB

   Master nodes

   The parameter num_master_nodes defines the number of master nodes that the volume will use. The number of master nodes must match the number of active nodes in the cluster. For example: in a cluster with 3 active nodes and 1 reserve node (3+1), the number of master nodes is 3.

   In the following example, we create a 1 TiB data volume with the name LocalArchiveVolume1 on the storage disk disk1 with 3 master nodes and redundancy 2. The command returns the volume ID for the new volume (vid: 3).

   confd_client st_volume_create name: LocalArchiveVolume1 disk: disk1 type: archive size: "1 TiB" num_master_nodes: 3 nodes: [11, 12, 13] redundancy: 2 partition_size: 274877906944 shared: true, owner: [500,500]
   # ConfD returns the volume ID of the new archive volume:
   vid: 3

   The ConfD job st_volume_create does not necessarily use the specified size, but does internal rounding. To check the actual size of the archive volume after creation to see if it is acceptable, use the ConfD job st_volume_info. If the rounding takes up too much space, contact Support.

3. To create the backup schedule, use the ConfD job db_backup_add_schedule.

   If a local archive volume runs out of free space, expired backups will be automatically deleted. Expired remote archive volumes will not be deleted by this function.

   A common backup schedule is a weekly backup with an expiration of 10 days, and incremental backups on the first 6 days of the week with an expiration time of 3 days. To set up this configuration, create two backup schedules. For example:

   confd_client db_backup_add_schedule db_name: MY_DATABASE backup_name: weekly_full_backup backup_volume_name: VOLUME_NAME enabled: true level: expire: '1w 3d'  minute: 0 hour: 0 day: '*' month: '*' weekday: 0

   confd_client db_backup_add_schedule db_name: MY_DATABASE backup_name: daily_incremental backup_volume_name: VOLUME_NAME enabled: true level: 1 expire: '3d'  minute: 0 hour: 0 day: '*' month: '*' weekday: '1,2,3,4,5,6'