...
| Table of Contents |
|---|
- Master/Agent do not require a permanent connection
- each component works asynchroneously and independently
- a connection should be established at least once per day
- Master
- control a number of Agents
- act as the central access point to Agents, e.g. for the GUI
- can be terminated and restarted during ongoing operations
- control the daily plan (calendar), what to run, when, where (but not how)
- operate as a singular instance
- multiple Master instances are operated independent from each other
- multiple Agent instances can be shared across a number of Master instances
- Agent
- execute tasks from the daily plan independently
- operate in a high-availability cluster
Components
Cockpit
Target Architecture
| Status | ||||
|---|---|---|---|---|
|
JOC Cockpit
- manage job configuration, optionally with a repository service
- manage release procedure for job configuration to Master
- accept job events and job history from Master
- report job events to event queue
- report job history to reporting database
- run authentication and authorization service
- run web server and web services
- run JobScheduler Controller Web GUI
- bundle a number of Masters and delegate commands to Master
Explantion of Drawing
JOC Cockpit
- JobScheduler JOC Cockpit distributes configuration to Master Cluster members
- JOC Cockpit accepts job events and job history events and stores them persistently
- JOC Cockpit is the user interface for monitoring and taking action
Master Cluster
- Primary and Backup JobScheduler Master are synchronized in a Cluster
- Cluster members address job execution requests to Agent Clusters
- Cluster members report job events and the job history to the Web Service
Autonomous Agent Cluster
- A number of Agents is grouped in a Cluster for:
- fixed priority scheduling
- round-robin scheduling
- An Agent Cluster manages outages of Agents autonomously
Master
- control the job plan (calendar), what to run, when and where
- forward daily plan to Autonomous Agent Cluster
- accept task execution result, job history and log information from Agents
- optionally operate in an active-passive cluster
...
Explantion of Drawing
Controller
- The Controller presents the user interface (GUI)
- The Controller makes use of web services provided by the Supervisor to retrieve status information
Web Services
- Web Services enforce authentication and authorization
- Web Services provide information on
- job events
- job history
- Master/Agent status
Supervisor
- Supervisor manages job release procedure for a repository (Git, subversion etc.) or file system
- Supervisor sends job control commands to Master
- Supervisor accepts job events and job history and stores them persistently
Autonomous Agents
- implement a fault-tolerant peer-to-peer network of Agents
- accept daily plan from Master
- available for active-passive and active-active clustering:
- fixed priority scheduling
- round-robin scheduling
- execute job chains independently from Master availability
- resolve more complex dependencies with Master, e.g. for checks of the job history or of external events from other machines
- report job history and log information back to Master
- run distributed recovery files for recovery purposes
- allow access by a number of Master instances
- provide resilience features for reconciliation after Master connection loss
...
Explantion of Drawing
Master Cluster
- Primary and Backup JobScheduler Master are synchronized in a Cluster
Autonomous Agent Cluster
- Master contacts one of the Members in an Agent Cluster to check Agent availability and to forward the daily plan for job execution
- Agent Cluster Members synchronize the execution of jobs and job chains:
- Fixed priority scheduling
- Round-robin scheduling
- Agent Cluster Members implement a peer-to-peer network to synchronize status updates and to report back to the Master
- Agent Cluster Members use Recovery Files for restart capability should no Cluster Member be available on restart
...