JS7 JobScheduler

Space shortcuts

Page tree

Introduction

  • The JS7 - Cluster Architecture 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).
  • Users should make use of the active JOC Cockpit instance:
    • an active instance receives near-real time information about order state transitions; a standby instance updates information about state transitions when pages are loaded or refreshed.
    • an active instance collects orders logs and task logs and makes them available from a running log; a standby instance has no access to task logs and order logs before completion of the task or order.
    • besides these differences users can manage and deploy the workflow inventory from a standby JOC Cockpit similarly to an active instance.
  • The JOC Cockpit can be configured to act as a Cluster Watch, see JS7 - Controller Cluster. In this scenario an active JOC Cockpit instance has to be available to support Controller Cluster fail-over.
  • 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.
  • Use of 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.
  • API Server instances of JOC Cockpit that can optionally be set up are not subject to cluster management. 


Background Services

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

  • 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 active JOC Cockpit instance receives state information from a Controller. This information is consumed by the History Service that for example receives 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 to its database.


Network Connections

There are no network connections between JOC Cockpit Cluster instances.

Resources



  • No labels