JS7 JobScheduler

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Introduction

Taking a backup includes to consistently store the following data in a JS7 environment:

  • Configuration Data
    • This includes installation options and configuration items that are updated after installation, for example certificates and settings for HTTPS connections.
  • Inventory Data
    • JS7 - Inventory of workflows, jobs and related objects managed with JOC Cockpit.
  • Transaction Data
  • Log Data
    • Log files are created and updated continuously and are mainly used for problem analysis. As past log files are not used at run-time many users consider them not be an immediate target of backups. 

JOC Cockpit

Configuration Data

The JOC Cockpit configuration data are stored to files in the JETTY_BASE/resources/joc directory hierarchy, for example:

Configuration data are created during installation and optionally are modified by users later on. This suggests that repeated backups of configuration data are required only in case of changes by users.

Inventory Data, Transaction Data

All objects managed with JOC Cockpit are stored in the JS7 - Database.

This includes data that are managed by the JOC Cockpit GUI:

Users should take backups of the JS7 database on a regular basis.

  • The database backup tool is required to create consistent backups, for example in case of concurrent transactions if new items are added to the JS7 History while a backup is performed.
  • The database backup tool should not interfere with JS7 database transactions and should not affect JS7 operations. 
  • If no decent backup tool is in place then users can shutdown JOC Cockpit to take a backup by exporting the JS7 database.

Log Data

JOC Cockpit log files are stored in the JETTY_BASE/logs directory.

Except for problem analysis log files are not too relevant, However, compliance reasons can suggest to backup log files.

Controller

Configuration Data

The Controller's configuration data are available from files in the JS7_CONTROLLER_DATA/config directory hierarchy, for example

Configuration data are created during installation and optionally are modified by users later on. This suggests that repeated backups of configuration data are required only in case of changes by users.

Transaction Data

Transaction data of Controller instances are available from the Controller's JS7_CONTROLLER_DATA/state directory that holds a journal of JS7 - Deployment operations and JS7 - Order State Transitions. This applies to Standalone Controller instances and to Controller Cluster instances.

  • It is pointless to backup transaction data as they can change every millisecond.
  • Restoring from a backup that is for example 30 minutes back is of no use as in between jobs will have been executed and orders will have proceeded which includes severe data loss and results in an inconsistent journal.

Standalone Controller

  • Use of a cluster file system for the Standalone Controller instance's journal is an option. However, this includes performance penalties and requires user intervention to restart a failed Standalone Controller instance from a clean copy of its journal.
  • Should transaction data of a Standalone Controller be lost then this affects the state of orders that are currently running or for which the execution status has not yet been reported back to JOC Cockpit. When a Standalone Controller is started with a new journal then
    • JOC Cockpit will automatically re-assign the Controller and related Agents,
    • users have to redeploy any related scheduling objects such as workflows from the JOC Cockpit's inventory,
    • users have to resubmit any orders from the JOC Cockpit's Daily Plan.

Controller Cluster

  • The JS7 - Controller Cluster guarantees redundancy and consistency of transaction data that are synchronized between Active and Standby Controller instances on different machines.
  • Should the Active Controller instance's journal be lost, for example due to disk failure, then the Standby Controller instance will pick up operation form a synchronized copy of the journal. If the failed Controller instance is started later on then it will be assigned the standby role and will synchronize its journal from the Active Controller Instance.

Log Data

Log files of the Controller (not: of workflows or jobs) are available from the Controller's JS7_CONTROLLER_DATA/logs directory.

Except for problem analysis the log files are not too relevant, However, compliance reasons can suggest to backup log files.

Agent

Configuration Data

The Agent's configuration data are available from files in the JS7_AGENT_DATA/config directory hierarchy, for example

Configuration data are created during installation and optionally are modified by users later on. This suggests that repeated backups of configuration data are required only in case of changes by users.

Transaction Data

Transaction data of Agents are available from the Agent's JS7_AGENT_DATA/state directory that holds a journal of JS7 - Deployment operations and JS7 - Order State Transitions.

  • It is pointless to backup transaction data as they can change every millisecond.
  • Restoring from a backup that is for example 30 minutes back is of no use as in between jobs will have been executed and orders will have proceeded which includes severe data loss and results in an inconsistent journal.

Standalone Agent

  • Use of a cluster file system for the Standalone Agent instance's journal is an option. However, this includes performance penalties and requires user intervention to restart a failed Standalone Agent from a clean copy of its journal.
  • Should transaction data of a Standalone Agent be lost then this affects the state of currently running orders until their execution status is reported back to the Controller. When a Standalone Agent is started with a new journal then the Controller will automatically forward workflows and orders to bring the Agent's journal in sync with information from the Controller's journal.

Agent Cluster

  • The JS7 - Agent Cluster guarantees redundancy and consistency of transaction data that are synchronized between Active and Standby Director Agent instances on different machines. Should the Active Director Agent's journal be lost, for example due to disk failure, then the Standby Director Agent will pick up operation form a synchronized copy of the journal. If the failed Director Agent instance is started later on then it will be assigned the standby role and will synchronize its journal from the Active Director Agent.
  • Subagents do not make use of a journal as they are used for job execution only. Workflows and order state transitions are managed by the Director Agent only.

Log Data

Log files of the Agent (not: of workflows or jobs) are available from the Agent's JS7_AGENT_DATA/logs directory.

Except for problem analysis the log files are not too relevant, However, compliance reasons can suggest to backup log files.



  • No labels