Current Architecture
Architecture: Supervisor and Master / Universal Agent Cluster
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
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 Architecture
- 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 required
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
- Database independent architecture
- Recovery files used for restart of Master and Agent, consistency is provided at application level
- No dependency from database availability, common DBMS products are used for reporting purposes only
- No costly database management products for clustering required
- No administration and on-going management of database required