Introduction

The JOC Cockpit Cluster brings high-availability by fail-over (automated) and switch-over (by user intervention) capabilities.
- A number of JOC Cockpit instances are operated for different servers with one JOC Cockpit instance taking the active role and any other instances acting as a standby.
- Automated fail-over guarantees high-availability and restart capabilities of a JOC Cockpit Cluster (passive cluster).
JOC Cockpit itself does not ´take an active part in job or workflow execution that are performed by the Controller and Agents. Therefore unavailability of JOC Cockpit or of the database service does not affect job or workflow execution, however, it affects monitoring and control of jobs.
The JOC Cockpit Cluster is subject to the agreements of the JS7 - License.

Cluster Management

The architecture applies to the clustering of two or more JOC Cockpit instances:

The Cluster Service running in JOC Cockpit manages fail-over and switch-over to the next available instance.
Cluster operation of JOC Cockpit instances relies on the availability of the database service.

JOC Cockpit can be used from a single instance or from any number of clustered instances to connect to a Controller:

JOC Cockpit makes use of the built-in Proxy Service to connect to the Controller. In case of fail-over or switch-over of JOC Cockpit the Proxy Service of the next active JOC Cockpit instance will establish the connection with the Controller.
JOC Cockpit receives state information from a Controller that is consumed by the History Service, e.g. log events. In case of fail-over or switch-over the History Service of the next active JOC Cockpit instance will resume the Controller's event stream and will write the history.

There are no network connections between JOC Cockpit Cluster instances.