Configuring CT-VL Nodes
To set up a CT-VL system, a single Virtual Machine (VM) or multiple VMs can be used to form a cluster of nodes operating as one coherent CT-VL system.
A cluster of nodes is useful to achieve scalability and high availability. You can set up a CT-VL cluster manually, or using an automated process.
It is highly recommended to use the automated process. It is easier to follow and less error-prone, especially when setting up a cluster of more than two nodes.
A CT-VL system is set up by creating the first node in the cluster. At a minimum, a CT-VL system can run with just one node. It is still considered a cluster, but with only one node. Additional nodes can then be added to the cluster.
Note
CT-VL supports up to 16 nodes in a cluster.
Automated Cluster Setup
To automatically set up a cluster:
Log into the CLI and enable the
apiadminuser on all nodes will join the CT-VL cluster. Enabling theapiadminuser requires setting a password. By enabling theapiadminuser, the primary node will be able to access a remote node and join it to the cluster:main> cluster apiadmin [--enable] [--setpasswd PASSWORD]Choose a node to start your cluster. Log into the CLI and run the command below. This
createcommand will initialize the node as the first node of the cluster:main> cluster createOn the same node, start joining other nodes to the cluster, by running the
remotejoincommand specifying the IP addresses of the other nodes you wish to join the cluster:main> cluster remotejoin NODE_IP [NODE_IP ...}It is recommended to disable the
apiadminuser after you have finished the automated cluster setup. Run the command below on all nodes to disableapiadminaccess:main> cluster apiadmin --disableTo add a new node to the cluster at a later time, re-enable the
apiadminuser on all nodes of the cluster. Run theremotejoincommand as before to add more nodes to that cluster:Note
The
remotejoincommand can be run from any active node in the cluster.Warning
Since a node joining a cluster will mirror the data of the cluster, any existing data in that node will be destroyed.
main> cluster remotejoin NODE_IP [NODE_IP ...}
Manual Cluster Setup
Similar to automated setup above, choose a node to start your cluster. Run the cluster create command to initialize the node as the first node of the cluster. The command requires the following parameters:
IP - IP address of this node. It is highly recommended to use the internal IP, for example, the VPC IP address of this node. The IP address is optional if creating a cluster node using existing data (with the
--preserveoption).USERNAME - WebUI Admin username.
PASSWORD - WebUI Admin password.
EMAIL - WebUI Admin email.
The cluster create command supports both interactive and non-interactive modes. See the --help option output for details on how to use:
main> cluster create --help
usage: create [-h] [-u USERNAME] [-p PASSWORD] [-e EMAIL] [--preserve] [-y]
[IP]
usage: create [-h] [-u USERNAME] [-p PASSWORD] [-e EMAIL] [--preserve] [-y]
[IP]
Once this command completes, you can log in to the CT-VL Web UI using the credentials entered above. Load the Web UI by loading the node IP address or the external IP address of the VM:
https://node_IP
https://external_IP
Manually Adding Nodes to a Cluster
Unlike the automated process above, manually adding nodes to a cluster is more complicated. This process does not require apiadmin access. A node joining a cluster must be initiated from the node that is joining.
Although the node joining will only contact one active node in the cluster, all other acive nodes in the cluster must be informed of the new node that is joining.
Similarly, the node that is joining must be informed of all the active nodes in the cluster. This aspect is crucial since data from each node in the cluster must be able to replicate on all nodes in the cluster. Informing a node is done by using the cluster add command.
Similar to the automated process, a cluster is created by choosing the first node of the cluster. This is done by running the cluster create command. This will create a cluster but with only one node.
Note
Before running the join command, the add command must be run on the first node. This is a way of telling the first node that an additional node will be joining the cluster. Simply running the join command on the new node will not work. The first node must know about the new node by running the add command.
To add a second note to a cluster:
Log in to the CLI of the first node and run the cluster add command:
main> **cluster add NODE2_IP**where
NODE2_IPis the IP address of the new (second) node joining the cluster.Log in to the CLI of the second node. Run the
addcommand for the first node, and then thejoincommand:main> **cluster add NODE1_IP** main> **cluster join NODE2_IP NODE1_IP**
The join command requires two parameters: NODE2_IP (the current, new node IP) and NODE1_IP (the existing cluster node IP).
The add command is optional and not necessary since the join command will take care if it. However, if you are joining a cluster already having more than one node in the cluster, you must run the add command for all nodes already in the cluster.
The join command only lets you select one node_ip to join for connectivity purposes, but you will need to tell the system all the other nodes in the cluster you are joining and that is accomplished by running the add command.
Example: Manually Setting up a Four-node CT-VL Cluster
The following procedure shows how to manually set up a CT-VL system with four nodes, with IPs NODE1_IP, NODE2_IP, NODE3_IP, and NODE4_IP.
On node1, run the
createcommand:main> **cluster create NODE1_IP**On node1, run the
addcommand for all nodes:main> **cluster add NODE1_IP** main> **cluster add NODE2_IP** main> **cluster add NODE3_IP** main> **cluster add NODE4_IP**Note
The
add NODE1_IPcommand above is redundant since NODE1 is already joined to the cluster. But for clarity, this repetition shows that the system must be told of all nodes joining the cluster.Repeat the same
addcommands shown in Step 2 on nodes NODE2, NODE3, and NODE4.Log in to NODE2 and run the
joincommand:main> **cluster join NODE2_IP NODE1_IP**Log in to NODE3 and run the
joincommand:main> **cluster join NODE3_IP NODE1_IP**Note
NODE3 can also be joined to the cluster using NODE2_IP as the second parameter instead of NODE1_IP. This is because NODE2 is already joined to the cluster. Any node can be used as the second parameter as long as that node is already joined to the cluster. For example, the following is equivalent to the preceding example above:
main> **cluster join NODE3_IP NODE2_IP**Repeat the
joincommand for NODE4.main> **cluster join NODE4_IP NODE2_IP**
Log in to the GUI on all nodes and verify that they are all replicating. Changing a value in the GUI of one node should be reflected in the same changes on all other nodes.
Note
To add a new node to a cluster, all nodes in the cluster must be online. No new nodes can be added if not all nodes in the cluster are online.
Remove a Node from a Cluster
The process of removing a cluster node is the same for a manually-created cluster as it is for an automatically-created one.
To remove a node from a cluster, run the remove command from one node -- any node except the node that will be removed. You only need to run the remove command on one node. All other nodes see this command and remove the node from their system.
As with adding a node to a cluster, to remove a node from the cluster, all nodes must be online so that they will know that a node is being removed.
Note
The order of the list of the CipherTrust Managers used by CT-VL does not matter. CT-VL picks a CipherTrust Manager to be used in a round-robin manner.
The CipherTrust Manager used to register CT-VL does not have preference for usage. After a CT-VL is registered, it only retains the certificate of the CipherTrust Manager when registered. That certificate is present on all the CipherTrust Managers in the cluster (due to replication), thus CT-VL thinks all of them are the same.
CT-VL may continue to add more CipherTrust Managers to the CipherTrust Manager cluster without registering. It may even remove the original CipherTrust Manager from the cluster when registered without having any impact.