Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Introduction & Options sections modified

Table of Contents
outlinh1. true
outlinh1. true
1printablefalse
2stylh1. none
3indent20px

Introduction

Two types of JobScheduler cluster can be configured, depending on the type of behavior required:

  • Passive Clusters provide backup and fail-over functions
  • Active Clusters.use the JobScheduler's Distributed Orders feature to provide load balancing.

The architecture of these clusters is described in the following diagrams:

Note that both types of cluster can be used to provide:

The configuration of both passive and active clusters is covered in this article.

JobScheduler Cluster Options

  • Two or more JobSchedulers can be operated as a cluster.
  • All JobSchedulers in a cluster have to:
    • be identified by the same JobScheduler ID and 
    • use the same database.
  • Furthermore, each JobScheduler in a cluster has to be started with one of the following cluster options:
    • -exclusive
    • -exclusive -backup
    • -distributed-orders
  • See http://www.sos-berlin.com/doc/en/scheduler.doc/command_line.xml for more information about JobScheduler start options.
  • The following types of JobScheduler clusters can be configured, depending on the cluster start options used.

JobScheduler

...

Passive Clusters

Two types of JobScheduler cluster can be configured, depending on the type of behavior required:

  • Passive Clusters provide backup and fail-over functions
  • Active Clusters.use the JobScheduler's Distributed Orders feature to provide load balancing.

The architecture of these clusters is described in the following diagrams:

The configuration of both types of cluster is covered in the following sections.

JobScheduler Passive Cluster

  • We assume a Primary JobScheduler with the start option -exclusive.
  • Backup JobSchedulers will use the start options:
    • -exclusive 
    • -backup 
    • -backup-precedence=n 
      • where n is a number.
      • The option -backup-precedence is optional and the number n defines the order in which the Backup JobSchedulers become active.
  • Exclusively the Primary JobScheduler will be active once all the JobSchedulers have been started.
  • All JobSchedulers in the cluster use the same configuration (jobs, job chains, orders, etc.)
  • A Backup JobScheduler will not become active if the Primary JobScheduler terminates in a normal way.
  • If the Primary JobScheduler is aborted or its process is killed (e.g. the server crashes) then the (next) Backup JobScheduler will become active and will be aware of the job states and order states. That is, the 'new' JobScheduler will be aware of whether 
    • jobs or job chains are stopped or active, 
    • job chain nodes are stopped, skipped or active,
    • orders are suspended or active and 
    • what their current state is.
  • If a Backup JobScheduler is active and the primary JobScheduler is restarted then the Backup JobScheduler has to be terminated in order to reactivate the Primary JobScheduler.
  • See also http://www.sos-berlin.com/doc/en/scheduler.doc/backupscheduler.xml

JobScheduler Active

...

Clusters

How can I set the cluster start option?

  • You can set cluster options during installation of the JobScheduler.
  • Edit the ./bin/jobscheduler_environment_variables file.(sh|cmd) as described below to change the cluster options after installation has been completed and the cluster been made operational:

Unix

  • stop the JobScheduler

  • edit ./bin/jobscheduler_environment_variables.sh

    Code Block
    languagebash
     SCHEDULER_CLUSTER_OPTIONS=-exclusive
    
  • start the JobScheduler

Windows

  • stop the JobScheduler service
  • remove the JobScheduler service

    Code Block
    languagebash
     .\bin\jobscheduler.cmd remove
    

...