Page History

Introduction

There are a number of methods available for controlling job execution on remote servers with JobScheduler. The most important of these are:

• SSH;Agentless Scheduling using SSH
• Using (a) JobScheduler agent(s) (Dynamic (setting of the) JobScheduler agent).JobScheduler Agents, see How to dynamically assign JobScheduler Agents to a job

Whilst the possibilities offered by SSH execution are limited (see What is the difference between SSH -Job job execution and remote JS-JobScheduler Agents?), the possibilities offered by Agents or remote JobSchedulers is also somewhat restricted, in that require some prerequisites as they rely on process classes.
Process classes have the disadvantage that instances of the job chain and job have to exist (and be maintained) on every JobScheduler that the job is to be (potentially) executed on Process Classes.

The scheduler.remote_scheduler technique described on this page has been introduced with JobScheduler version 1.7 and allows a job in a job chain to be executed on a remote JobScheduler without the need for a job chain or the job itself to be installed in the live folder of the remote JobScheduler. It is also not necessary for a process class to be defined.
The remote JobScheduler is simply defined by setting the scheduler.remote_scheduler order parameter:

The ease with which of this method allows remote JobScheduler's to be set means that job execution on remote JobSchedulers can be more flexibly allocated than with process class based methods. In particular, it allows the decision about which JobScheduler a job is to be executed on to be made dynamically, for example, depending on the result of the preceding job.
In addition, only one instance of the job and job chain need to be defined in the live folder of the 'main' JobScheduler, thereby considerably increasing flexibility and reducing maintenance.

Operation details

• The remote JobScheduler can be either a workload instance or an Agent.
• Job, job chain and order configuration data is only transferred to the remote JobScheduler as required, JobScheduler objects are not saved on the remote JobScheduler.
• The operations carried out on the remote JobScheduler are recorded in log files in the $SCHEDULER_DATA/logs directory as defined in the JobScheduler Master - Installation Guide.
• Log information for the operations carried out on the remote JobScheduler is also saved in the $SCHEDULER_DATA/logs directory of the 'main' JobScheduler.

A simple scheduler.remote_scheduler example

A scheduler.remote_scheduler example has been prepared and can be downloaded from:

• remote_scheduler_variable_demo.zip
  Note that this example will only work with JobScheduler version 1.7 and newer.

used to set up a simple remote scheduling demonstration.

To run the example you only need two JobSchedulers, one of which is to be used as the 'main' JobScheduler and the other as the remote.

Note that scheduler.remote_scheduler only works when both the main and remote JobSchedulers are version 1.7 or newer.

Download the example

• remote_scheduler_variable_demo.zip

To get the example ready to use, simply unpack the 'remote_scheduler_variable_demo.zip' file into your JobScheduler's the 'live' folder of the 'main' JobScheduler that will be controlling the remote one(s).

If you then open the folder containing the example in JobScheduler's JOE interface you will see that the example consists of a job chain ("Job_Chain_1") with three nodes ("Start", "Job_1" & "End") and two orders:

...

These objects can be seen in the following screenshot from JOE:

The job chain used for this example is quite simple as can be seen in the following diagram:

digraph \{

graph [rankdir=TB]
node [shape=Mrecord,style="filled",fillcolor=lightblue]
node [fontsize=10]
ranksep=0.3
	subgraph cluster_0 \{

		style=filled;
		color=lightgrey;
		node [style=filled,color=white];
		label = "JobSchedulerJob_Chain_1";
		labeljust = "l";
		pad = 0.1;

StartProcessing [label= "\{<f0>Start&#92; Processing\}"];
Job1Job_1[label= "\{<f0>Job1\<f0>Job_1}"];
EndProcessing [label= "\{<f0>End&#92; Processing\}"];

StartProcessing -> Job1Job_1 -> EndProcessing [weight=4];
	\}

\}

...

TODO: Add description of job & shell script .....

Running the example

When "Order_1_Local" is started - for example, using JobScheduler's JOC interface, "Job_Chain_1" will be executed on the local host - i.e. the JobScheduler in whose file system the demo files were unpacked.

...

Alternatively, the XML code in the the {{Job_Chain_1,Order_2_Homer-4432.order.xml<code> xml file can be edited as follows:<source>
<params>
<param

 <params>
          <param name="scheduler.remote_scheduler" value="homer.sos:4432" />

...

 </params>

</source>To get "Order_2" to be executed on a remote JobScheduler in your network simply change the <code>schedulerscheduler.remote_scheduler}} parameter in either JOE or directly in the "Job_Chain_1,Order_2_Homer-4432.order.xml" file to a suitable address and start the order in JOC. This was shown in the next screenshot above.:

Image Added

Once the order has run, open the log file and you will see that in the example "Job_1" causes either {{COMPUTERNAME = yourConputerName }} yourComputerName  (for a Windows computer) or {{HOSTNAME = yourHostName }}  (for a Linux computer) to be written to the file.

A scheduler.remote_scheduler parameter is not set in the "Order_1_Local" order and therefore when started with this order "Job_1" will be executed by default on your local computer. The name of your local computer or host (depending on the operating system - see above) will be entered in the log file.

Application in a Production Environment

...

In a production environment, particularly one where a large number or remote servers were being addressed, the scheduler.remote_scheduler parameters would be saved in an .inc file, which would be loaded as required.

See Also:

Example with dynamic order generation

We have prepared a second, more complex, example showing use of scheduler.remote_scheduler with dynamically generated orders containing remote_scheduler parameters:

• Example for complex dynamic setting of remote JobSchedulers

See also

• How to dynamically assign JobScheduler Agents to a jobDynamic (setting of the) JobScheduler agent