It is important to secure the ClusterControl node and the database cluster. We recommend user to isolate their database infrastructure from the public Internet and just whitelist the known hosts or networks to connect to the database cluster.

ClusterControl requires ports used by the following services to be opened/enabled:

ICMP (echo reply/request)

SSH (default is 22)

HTTP (default is 80)

HTTPS (default is 443)

MySQL (default is 3306)

CMON RPC (default is 9500)

CMON RPC TLS (default is 9501)

CMON Events (default is 9510)

CMON SSH (default is 9511)

CMON Cloud (default is 9518)

Streaming port for backups through netcat (default is 9999)

ClusterControl supports various database and application vendors and each has its own set of standard ports that need to be reachable. Following ports and services need to be reachable by ClusterControl on the managed database nodes:

It is recommended for users to setup a proper host definition file in /etc/hosts file. The file should be identical on all servers in your cluster. Otherwise, your database cluster might not work as expected with ClusterControl. Below is an example of a host definition file:

You need to separate the 127.0.0.1 entry from your real hostname, specifying it only to localhost or localhost.localdomain. To verify whether you have set up the hostname correctly, ensure the following command returns the primary IP address:

ClusterControl controller (cmon) process requires a dedicated operating system user to perform various management and monitoring commands on the managed nodes. This user which is defined as os_user or sshuser in CMON configuration file, must exist on all managed nodes and it should have the ability to perform super-user commands.

You are recommended to install ClusterControl as ‘root’, and running as root is the easiest option. If you perform the installation using another user other than ‘root’, the following must be true:

The OS user must exist on all nodes

The OS user must not be ‘mysql’

‘sudo’ program must be installed on all hosts

The OS user must be allowed to do ‘sudo’, i.e, it must be in sudoers

The OS user must be configured with proper PATH environment variable. The following PATH are expected for user myuser: PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/myuser/.local/bin:/home/myuser/bin

For sudoers, using passwordless sudo is recommended. To setup a passwordless sudo user, add following line into /etc/sudoers:

Edit the sudoers with the following command (as root):

visudo

And add the following line at the end. Replace [OSuser] with the sudo username of your choice:

[OS user]ALL=(ALL) NOPASSWD: ALL

Open a new terminal to verify it works. You should now be able to run the command below without entering a password:

$ sudo ls /usr

You can also verify this with SSH command line used by CMON (assuming passwordless SSH has been setup correctly):

$ ssh -qt [OS user]@[IP address/hostname]"sudo ls /usr"

where [OSuser] is the name of the user you intend to use during the installation, and [IPaddress/hostname] is the IP address or hostname of a node in your cluster.

Proper passwordless SSH setup from ClusterControl node to all nodes (including ClusterControl node) is mandatory. When adding a new node, the node must be accessible via passwordless SSH from ClusterControl beforehand.

To setup a passwordless SSH, make sure you generate a SSH key and copy it from the ClusterControl host as the designated user to the target host. Take note that ClusterControl also requires passwordless SSH to itself, so do not forget to set this up as described in the example below.

Most of the sampling tasks for controller are done locally but there are some tasks that require a working self-passwordless SSH e.g: starting netcat when performing backup (to stream created backup to the other node). There are also various places where ClusterControl performs the execution “uniformly” regardless of the node’s role or type. So, setting this up is required and failing to do so will result ClusterControl to raise an alarm.

Note

It is NOT necessary to setup two-way passwordless SSH, e.g: from the managed database node to the ClusterControl.

Examples below show how a root user on the ClusterControl host generates and copies a SSH key to a database host, 192.168.0.10:

Sudoers with or without password is possible with sudo configuration option. If undefined, CMON will escalate to sudoer without password. To specify the sudo password, add the following option inside the CMON configuration file:

sudo="echo 'thesudopassword' | sudo -S 2>/dev/null"

Attention

Having 2>/dev/null in the sudo command is compulsory to exclude stderr from the response.

If the sudo user’s home directory is encrypted, you might be facing following scenarios:

First SSH login will required password, even though you have copied the public key to the remote host authorized_keys

If you run another SSH session, while the first SSH session still active, you will able to authenticate without password and the key authentication is successful.

Encrypted home directories aren’t decrypted until the login is successful, and your SSH keys are stored in your home directory. The first SSH connection you make will require a password. While the subsequent connections will no longer need password since the SSH service is able to read the authorized_key (inside user’s homedir) in decrypted environment.

ClusterControl requires all servers’ time to be synchronized and to run within a same time zone. Verify this by using following command:

$ date
Mon Sep 17 22:59:24 UTC 2013

To change time zone, e.g from UTC to Pacific time:

$ rm /etc/localtime
$ ln -sf /usr/share/zoneinfo/US/Pacific localtime

UTC is however recommended. Configure NTP client for each host with a working time server to avoid time drifting between hosts which could cause inaccurate reporting or incorrect graphs plotting. To immediately sync a server’s time with a time server, use following command:

ClusterControl comes in 4 versions - Community, Standalone, Advanced and Enterprise editions, within the same binary. Please review the ClusterControl product page for features comparison between these editions. To upgrade from Community to Standalone, Advanced or Enterprise, you would need a valid software license. When the license expires, ClusterControl defaults back to the Community Edition.