Current Architecture
Info
| Table of Contents |
|---|
Current Architecture
| Table of Contents |
|---|
Architecture: Supervisor and Master / Universal Agent Cluster
Explanation of Drawing
Master Cluster
- Master Cluster members use the same database
- Instances operate either in active-passive mode or in active-active mode
- Cluster members in active-active mode share the workload of local jobs
- Cluster members can use Agents to execute jobs on remote servers
Universal Agent Cluster
- Each Agent is addressed by a Master configuration
- A number of Agents is grouped in a Cluster for:
- fixed priority scheduling
- round-robin scheduling
Job Execution
- Jobs are executed locally per JobScheduler Master
- Jobs are executed locally per JobScheduler Agent
- No central resources required for job execution
Benefits of the current Architecture
Drawbacks of the current Architecture
Supervisor
- is an optional component for a central point of configuration should a number of JobScheduler Master instances be operated in parallel
Master
- controls the job plan (calendar), what to run, when and where
- can be operated in a cluster with active-passive and active-active mode
- controls a number of Agents
Universal Agent
- is operated with zero configuration, easy deployment and a perfectly small footprint, e.g. runs on a Raspberry Pi with Java SME
- is available for clustering with Master configuration and supports
- fixed priority scheduling
- round-robin scheduling
- can be accessed by a number of Master instances
- provides resilience features for reconciliation after Master connection loss
Drawbacks of the current Architecture
Master
Benefits of the current ArchitectureMaster
- depends on the availability of its database
- high-availability stacks for database products are not open source
- commercial high-availability stacks are costly, they often exceed the cost of a JobScheduler license
- requires clustering to prevent a single point of failure
- active-passive clustering requires an additional machine for backup with resources that remain unused during normal operation
- active-active clustering is used for local execution of jobs with a Master, it is irrelevant for execution of jobs with Agents
Universal Agent
- is completely dependent from its Master, it cannot act autonomously
- with the connection between Master and database or Master and Agent being lost then no jobs are executed on an Agent
- job dependencies are resolved by the Master only, therefore availability and frequent traffic between Master and Agent are
Architecture Change: Goals
- High-availability covered at architecture level
- Asynchroneous processing of Master and Agent components
- Outages of components/connections are covered at architecture level
- Distributed architecture replaces component clustering
- No single point of failure
- Automated reconciliation and recovery
- required
Architecture Change: Basic Requirements
- 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