Skip to end of metadata
Go to start of metadata

Introduction

  • The JOC Cockpit Cluster brings high-availability through fail-over (automated) and switch-over (by user intervention) capabilities.
    • A number of JOC Cockpit instances are operated on different servers with one JOC Cockpit instance taking the active role and the other instances acting as standbys.
    • Automated fail-over guarantees high-availability and restart capabilities of a JOC Cockpit Cluster (passive cluster).
  • The JOC Cockpit itself does not ´take an active part in job or workflow execution, which are performed by the Controller and Agents. Therefore unavailability of the JOC Cockpit or of the database service does not affect job or workflow execution. However, it does affect 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 the 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.


Background Services

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

  • The JOC Cockpit makes use of the built-in Proxy Service to connect to the Controller. In the event of fail-over or switch-over of a JOC Cockpit instance, the Proxy Service of the next active JOC Cockpit will establish the connection with the Controller.
  • The JOC Cockpit receives state information from a Controller. This information 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.


Network Connections

There are no network connections between JOC Cockpit Cluster instances.


  • No labels