Creating a Cluster Slave Console Instance

A cluster slave instance has a number of unique properties, the most significant of which is that no repositories are allowed.

To set up a cluster slave console, install a clean Composable Architecture Platform instance and start it up. Log in as admin and click on the Console setup function:

Administration folder

Change the Console type to Cluster Slave Console. You will receive a warning:

alert

Click on OK to accept the change. There is now a new Slave tab showing:

Slave tab

Enter the URL that you would normally use to access the master console (we recommend using HTTPS). You also need to enter the ID by which the slave console is going to be defined in the master console and the password:

Slave tab

Then click on Save:

Save button

You will receive a further warning:

Alert content

Click on OK. An information box appears:

alert content

Click on OK. Your console will go gray and the slave console server will terminate. Make sure you restart it to complete the process. Restarting it will result in applications (such as Qwerty, the Test Server and so on) being removed from the installation.

Verifying the installation

You can verify that the slave console installed correctly by logging into it as normal. You should see a cut down console with the ID of the slave console shown in the header:

Cluster 1

At this point you can now turn to the master console and create a new Cluster Node definition as described earlier in this manual. If the cluster shows up as available in the master console and you can maintain it from there, then you should now log out of the slave console and reset the passwords for all of the built in user accounts (admin, super and security) using the forgot password feature. There is no need to have normal user access to a slave console.

Slave server definitions

The next step is to create a new server definition for each server that is attached to the slave. The slave will automatically detect the status of each of those servers and will ensure that the rules are synchronized with the master and that the X Engine state (started/stopped) follows the desired state as decided in the master console.

Whenever a change is made to the source repository in the master console, those changes are automatically deployed to the slaves and subsequently to the servers defined within each slave.

Co-locating master and slave consoles

If it is intended to co-locate master and slave consoles on the same server (by using different ports), then you MUST create an individual server name for each slave. The best way to achieve this is to set an entry in the systems HOSTS file for each slave. Failure to follow this step will result in the transfer from the master console to the slave console causing a log-out on the master console.