Introduction

• The Controller Cluster brings high-availability including fail-over capabilities for the deployment of scheduling objects and for execution of workflows.
  
  • Two Controller instances are operated on different servers to synchronize JS7 - Order State Transitions and log events.
  • Automated fail-over guarantees high-availability and restart capability of a Controller Cluster (passive cluster).
• Use of the Controller Cluster is subject to the agreements of the JS7 - License.

Cluster Management

The architecture applies to the clustering of two Controller instances acting as a passive cluster:

• Controller instances synchronize order state information and perform fail-over (automated) and switch-over (by user intervention).
• There is no need for use of an active cluster that aims at scalability: a single Controller instance offers unlimited scalability.

There are situations when cluster members need an arbitrator to decide which member should take the active role:

• If both Controller instances are shutdown and are restarted then the previously active instance cannot know if in between the standby instance was active. It is pointless to rely on operating system timestamps to clarify this situation.
• If a Controller instance continues to run but is isolated in the network in a way that no network connection can be established by the partner instance then this situation requires an arbitrator.

The role of the arbitrator is to act as a Cluster Watch and to add a vote in situations for which Controller instances cannot decide about the active role.

• The Cluster Watch is connected to both Controller instances and keeps track of cluster events.
• If the active Controller instance cannot be reached then the Cluster Watch is consulted by the standby Controller instance to decide if fail-over should be performed.
• A Controller Cluster works fine without a Cluster Watch during normal operation, however, for start-up of Controller instances and for fail-over the Cluster Watch is required.

The Cluster Watch role is available from JOC Cockpit and alternatively from an Agent:

• It is generally recommended to use JOC Cockpit as Cluster Watch as this provides high availability and fail-over of the Cluster Watch role if a JOC Cockpit Cluster is used.
• In a scenario when a number of Controller instances are managed by JOC Cockpit users might tend to use individual Agents acting as Cluster Watch per Controller.

Using JOC Cockpit as Cluster Watch

Any number of JOC Cockpit instances can act as Cluster Watch to determine the active Controller instance.

• Network connections are established from the active JOC Cockpit instance to the Controller.
• This scenario offers high availability for the JOC Cockpit instance acting as a Cluster Watch.
  • In case of switch-over or fail-over in a JOC Cockpit Cluster the next available JOC Cockpit instance will take the active role and will act as a Cluster Watch.
  • Should both Controller Cluster and JOC Cockpit Cluster fail-over at the same time then the user has to decide about the active Controller instance. In this situation JOC Cockpit displays an alarm bell and the user has to check and to confirm that the current standby Controller instance is not up and running.
• FEATURE AVAILABILITY STARTING FROM RELEASE 2.5.2
  • JS-2016 - Getting issue details... STATUS   JOC-1457 - Getting issue details... STATUS

Using an Agent as Cluster Watch

A single Cluster Watch Agent can be used to determine the active Controller instance.

• Network connections are established from both Controller instances to the Cluster Watch Agent.
• This scenario does not offer high availability for the Agent acting as a Cluster Watch.
• The Cluster Watch Agent is required to be available at the point in time when a Controller Cluster fail-over should occur.
• FEATURE AVAILABILITY ENDING WITH RELEASE 2.6.0

Integration with JOC Cockpit

A single JOC Cockpit instance or a JOC Cockpit Cluster can be used to connect to a Controller:

• JOC Cockpit makes use of the built-in Proxy Service to connect to the Controller. This includes automatically switching the active Controller instance in the case of fail-over or switch-over of a Controller.
• JOC Cockpit receives state information from a Controller that is added to the history, for example log events, and that is visualized in the GUI (order state events).

Network Connections

Network connections use the HTTP protocol and can be secured by TLS/SSL certificates.

Connections are:

• bidirectional between Controller instances,
• unidirectional from JOC Cockpit to Controller instances.

For details consider the JS7 - System Architecture.