Introduction

Users might choose to convert a Standalone Controller to a Controller Cluster:

• the The Controller Cluster provides high availability,
• Use of the Controller Cluster is subject to the JS7 - License. Both JOC Cockpit and Controller instance instances require a license keying key being present:

Converting a Standalone Controller to a Controller Cluster offers to revert the Cluster at any later point in time, see JS7 - How to convert revert a Controller Cluster to a Standalone Controller.

Converting the Standalone Controller

Stopping the Controller Cluster

As a prerequisite both active and standby Controller instances have to be terminated.

Reverting the Controller Journal

Users decide which Controller instance should become the Standalone Controller to continue operations.

Steps for converting a Standalone Controller correspond to the steps performed during JS7 - Initial Operation for Controller Cluster.

Starting the Primary Controller Instance

The Standalone Controller automatically becomes the active Primary Controller instance in a cluster. This change of role does not require the Standalone Controller being restarted.

For successful execution of the subsequent steps the Controller instance has to be up and running.

Preparing the Secondary Controller Instance

Users have to prepare the standby Secondary Controller instance to its role:

• Users should specify the standby role from the Controller instance's controller.conf file:

  Code Block
  title controller.conf file for Secondary Controller Instance
  # Cluster configuration js7.journal.cluster { node { is-backup = yes } }

  For details see JS7 - Controller Configuration Items

• Users should remove an existing journal of the Secondary Controller instance
• In most situations this will be the previously active Controller instance.
• Users should remove the journal of the Controller instance that is no longer in use. More precisely users should remove the contents of the unused Secondary Controller instance's state folder. This measure prevents a situation when later on the unused Controller instance will be started by chance and will invite the Standalone Controller instance to re-establish the cluster.

Starting the Secondary Controller Instance

In a next step the Secondary Controller instance is started like thisReverting the Controller journal can be performed with the following command:

# starting the revertingStandby Controller journalinstance for Unix withfrom nothe runningcommand Controller instancesline
./controller_instance.sh revokestart

# revertingstarting Controller journal for Unix with a running the Standby Controller instance thatfor isUnix stoppedfrom andsystemd
sudo reverted (available starting from release 2.5.1)
./controller_instance.sh stop --revokesystemctl start controller.service

@rem starting revertingthe Standby Controller journalinstance for UnixWindows withfrom nothe runningcommand Controller instancesline
./\controller_instance.cmd revokestart

@rem revertingstarting Controller journal for Unix with a running the Standby Controller instance that is stopped and reverted (available starting from release 2.5.1) Windows Service from the command line
.\controller_instance.cmd stop --revoke

Explanation:

• Running the above script will remove any cluster related items from the Controller instance's journal.
• This allows the Controller instance to be started as a Standalone Controller.
• Standalone Controllers
  • do not connect to a Cluster Watch Agent,
  • do not connect nor can be connected to/from a second Controller instance acting in a standby role.

Configuring the Standalone Controller

...

Image Removed

...

Image Removed

...

Image Removed

...

 start-service

@rem alternatively the Standby Controller instance can be started from the Windows Service Panel

For details see JS7 - Controller - Command Line Operation.

Operating the Cluster Watch

A Controller Cluster requires the role of a Cluster Watch to be present, see JS7 - Controller Cluster.

This role can be taken either by JOC Cockpit or from an Agent.

Starting JOC Cockpit for Cluster Watch

For Unix JOC Cockpit is started from its Start Script or from JS7 - systemd Service Files for automated Startup and Shutdown with Unix Systems.

For Windows JOC Cockpit is started from its Windows Service.

For details see JS7 - JOC Cockpit - Command Line Operation

JOC Cockpit can be assigned the Cluster Watch starting from this release:

Starting the Cluster Watch Agent

Users choose an existing Standalone Agent or Primary Director Agent in a JS7 - Agent Cluster to act as a Cluster Watch for the Controller Cluster.

An existing Agent can be re-used and does not require to be restarted. A new Agent is started

Image Removed

At the point in time when submitting the changes the Controller will not be started. Therefore the Test Connection function cannot be used.

Starting the Standalone Controller

With the Controller type being reverted users can start the Standalone Controller from the command line like this:

# starting the StandaloneCluster Watch ControllerAgent for Unix from the command line
./controlleragent_instance<port>.sh start

# starting the StandaloneCluster Watch ControllerAgent for Unix from systemd
sudo systemctl start controlleragent.service

@rem starting the Cluster StandaloneWatch ControllerAgent for Windows from the command line
.\controlleragent_instance<port>.cmd start

@rem starting the Cluster StandaloneWatch ControllerAgent Windows Service from the command line
.\controlleragent_instance<port>.cmd start-service

@rem alternatively the Cluster StandaloneWatch ControllerAgent can be started from the Windows Service Panel

For details see JS7 - Agent Command Line Operation

Configuring the Controller Cluster

The Controller's administrative menu is invoked from the JOC Cockpit user interface as follows:

Image Added

From the list of Controllers displayed users select the "Edit" action menu item for the respective Controller:

Image Added

When editing the Controller configuration the following popup window is offered:

Image Added

The Standalone and Cluster radio buttons determine the Controller type.

• Users should modify the Controller Type to Cluster.
• For the Primary Controller instance users should enter the URL of the current Standalone Controller that is intended to act as the active Controller instance in a cluster.
• For the Secondary Controller instance users should enter the URL of the standby Controller instance.
• The Test Connection buttons can be used to verify if JOC Cockpit can establish a connection to both Controller instances.
• For the Cluster Watch Role either JOC Cockpit or an Agent is specified, see next chapters.

Configuring JOC Cockpit a Cluster Watch

The Cluster Watch role for JOC Cockpit can be configured from a radio button like this:

Image Added

Configuring an Agent as Cluster Watch

The Cluster Watch role can be assigned an Agent from a radio button like this:

Image Added

Operating the Controller Cluster

With the previous steps being performed the Controller Cluster should become available within approx. 60s. 

• The active and standby Controller instances will connect to each other and will perform coupling of the cluster.
• The proxy service running in JOC Cockpit will connect to both Controller instances and will report status information with JOC Cockpit's Dashboard view.
  • Should this operation fail, then restart JOC Cockpit.
  • Consider that a JOC Cockpit cluster might automatically fail-over to the next JOC Cockpit instance and might require to restart all JOC Cockpit instances.
• The JS7 - History Service might take up to 90s to connect to the Controller Cluster.
  • Should this operation fail, then restart the History Service from the JOC Cockpit's Dashboard view.

Further Resources

• JS7 - Controller Configuration Items
• JS7 - Controller - Command Line Operation
• JS7 - Agent Command Line Operation
• JS7 - How to revert a Controller Cluster to a Standalone Controller