Agent Open Source sur une architecture Autosys

Agent open source pour Autosys : Communications Serveur/Agent

Cet article est le troisième volet de l’utilisation d’Open Source Job Scheduler en agent distant d’un ordonnanceur, dans notre cas l’implémentation est réalisée avec Autosys mais le système est assez ouvert pour être utilisé avec n’importe quel autre produit. Ce volet présente le script Perl et son rôle dans la communication entre les deux ordonnanceurs. Le script a été simplifié au maximum pour la maquette afin de pouvoir être porté dans n’importe quel langage ou shell. Ce nouveau script s’appuie entièrement sur les services web et n’utilise plus de bases de données, il peut dont s’installer sur un superviseur OpenScheduler quelque soit l’architecture choisie.

Commandes Relai

Ces commandes seront utilisées par le script perl et peuvent être jouées directement en commande en ligne grâce au script perl jobscheduler_client.pl. Ce commandes permettent de se familiariser avec le système et ainsi mieux comprendre le script Perl proposé.

Suppression du job

$  /atsprdweb03/scheduler/bin/jobscheduler_client.pl --host=atsprdweb03  --port=5556 --message='<modify_job job="eric" cmd="remove" />'

Réponse :

Job Scheduler response:
ok

Si le job n’existe pas :

$  /atsprdweb03/scheduler/bin/jobscheduler_client.pl --host=atsprdweb03  --port=5556 --message='<modify_job job="eric" cmd="remove" />'

Réponse :

ERROR-101: Job Scheduler reports error:
SCHEDULER-161  There is no Job '/eric'

Création du traitement

On définit directement le job en message en précisant le process_class :

$  /atsprdweb03/scheduler/bin/jobscheduler_client.pl --host=atsprdweb03  --port=5556 --message='<add_jobs><job name="eric" process_class="apherese" ><script language="shell"><![CDATA[hostname]]></script></job></add_jobs>'

Réponse :

Ok

Lancement du traitement

On démarre en suite le traitement :
$  /atsprdweb03/scheduler/bin/jobscheduler_client.pl --host=atsprdweb03  --port=5556 --message='<start_job job="eric" />'

Réponse :

Ok

Informations du Job

/atsprdweb03/scheduler/bin/jobscheduler_client.pl --host=atsprdweb03  --port=5556 --message='<show_job job="eric" />'

Réponse :

<?xml version="1.0" encoding="ISO-8859-1"?>
<spooler>
        <answer time="2009-06-12 16:51:06.242">
                <job path="/eric" name="eric" job="eric" state="running" process_class="/apherese" all_steps="0" all_tasks="1" log_file="/atsprdweb03/scheduler/logs/job.eric.log" order="no" tasks="1" in_period="yes">
                        <file_based state="active">
                                <requisites>
                                        <requisite type="Process_class" path="/apherese"/>
                                </requisites>
                        </file_based>
                        <tasks count="1">
                                <task job="/eric" id="20123" task="20123" state="running_remote_process" name="" running_since="2009-06-12 16:50:23.676" enqueued="2009-06-12 16:49:49.000" start_at="2009-06-12 16:49:49.000" cause="queue_at" steps="0" log_file="/atsprdweb03/scheduler/logs/task.eric.log" force_start="yes">
                                        <log level="info" highest_level="info" last_info="SCHEDULER-987  Starting process: '/tmp/autosys/sosACAmFa44K'" smtp="smtp-gw" mail_from="scheduler@atsprdweb03" mail_to="itec-gls-eur-pts-scheduling@smtp-gw"/>
                                </task>
                        </tasks>
                        <queued_tasks length="0"/>
                        <log level="info" highest_level="info" last_info="SCHEDULER-930  Task 20123 started - cause: queue_at" smtp="smtp-gw" mail_from="scheduler@atsprdweb03" mail_to="itec-gls-eur-pts-scheduling@smtp-gw"/>
                </job>
        </answer>
</spooler>

Lorsque le traitement est terminé :

/atsprdweb03/scheduler/bin/jobscheduler_client.pl --host=atsprdweb03  --port=5556 --message='<show_job job="eric" />'

Réponse :

<?xml version="1.0" encoding="ISO-8859-1"?>
<spooler>
        <answer time="2009-06-12 16:54:38.964">
                <job path="/eric" name="eric" job="eric" state="pending" process_class="/apherese" all_steps="1" all_tasks="1" log_file="/atsprdweb03/scheduler/logs/job.eric.log" order="no" tasks="1" in_period="yes">
                        <file_based state="active">
                                <requisites>
                                        <requisite type="Process_class" path="/apherese"/>
                                </requisites>
                        </file_based>
                        <tasks count="0"/>
                        <queued_tasks length="0"/>
                        <log level="info" highest_level="debug9" last_info="SCHEDULER-930  Task 20123 started - cause: queue_at" smtp="smtp-gw" mail_from="scheduler@atsprdweb03" mail_to="itec-gls-eur-pts-scheduling@smtp-gw"/>
                </job>
        </answer>
</spooler>

Log sur la machine distante :

2009-06-12 16:50:23.681 [info]   (TCP connection to 184.7.14.39:46231) SCHEDULER-933  TCP connection accepted
2009-06-12 16:50:23.682 [info]   (TCP connection to 184.7.14.39:46231) SCHEDULER-965  Executing command <?xml version="1.0" encoding="ISO-8859-1"?><remote_scheduler.start_remote_task tcp_port="59999" kind="process"/>
2009-06-12 16:50:23.683 [info]   (TCP connection to 184.7.14.39:46231) SCHEDULER-848  Task pid=0 started for remote scheduler
2009-06-12 16:52:23.738 [info]   (TCP connection to 184.7.14.39:46231) SCHEDULER-965  Executing command <?xml version="1.0" encoding="ISO-8859-1"?><remote_scheduler.remote_task.close process_id="15"/>

On dispose du log courant (dans cet exemple : task.eric.log)

2009-06-12 16:50:23.678 [info]   SCHEDULER-918  state=starting (at=2009-06-12 16:49:49.000)
2009-06-12 16:50:23.697 [info]   SCHEDULER-987  Starting process: '/tmp/autosys/sosACAmFa44K'
2009-06-12 16:52:23.781 [info]   SCHEDULER-918  state=closed
2009-06-12 16:52:23.924 [info]   SCHEDULER-962  Protocol ends in /atsprdweb03/scheduler/logs/task.eric.log

Le relai peut utiliser ce fichier pour attendre la fin du traitement.

$ ls -rtl *eric*
-rw-r--r--   1 autosys  autosys      221 Jun 12 17:13 job.eric.log
-rw-r--r--   1 autosys  autosys      354 Jun 12 17:15 task.eric.log

Contenu du log du traitement :

$ cat  job.eric.log
2009-06-12 17:11:58.030 [info]   SCHEDULER-893  Job is 'active' now
2009-06-12 17:13:27.371 [info]   SCHEDULER-919  Task 20128 enqueued
2009-06-12 17:13:27.379 [info]   SCHEDULER-930  Task 20128 started - cause: queue_at

Contenu du log de la tâche :

$ cat task.eric.log
2009-06-12 17:13:27.382 [info]   SCHEDULER-918  state=starting (at=2009-06-12 17:13:27.305)
2009-06-12 17:13:27.401 [info]   SCHEDULER-987  Starting process: '/tmp/autosys/sosDCApFa44K'
2009-06-12 17:15:27.500 [info]   SCHEDULER-918  state=closed
2009-06-12 17:15:27.664 [info]   SCHEDULER-962  Protocol ends in /atsprdweb03/scheduler/logs/task.eric.log

$  ./jobscheduler_client.pl --host=apocope --port=5556 --message='<start_job  job="test"/>'

Réponse :

ok

./jobscheduler_client.pl --host=apocope --port=5556 --message='<show_history  job="test" />'

<?xml version="1.0" encoding="ISO-8859-1"?>
<spooler>
<answer time="2009-06-11 17:57:09.589">
<history>
<history.entry task="19824" id="19824" spooler_id="apocope" job_name="test" start_time="2009-06-11 17:45:45" end_time="2009-06-11 17:45:45" cause="queue_at" steps="0" error="0" exit_code="0" pid="12867"/>
<history.entry task="19819" id="19819" spooler_id="apocope" job_name="test" start_time="2009-06-11 17:33:34" end_time="2009-06-11 17:33:34" cause="queue_at" steps="0" error="0" exit_code="0" pid="7588"/>
<history.entry task="19817" id="19817" spooler_id="apocope" job_name="test" start_time="2009-06-11 17:33:04" end_time="2009-06-11 17:33:04" cause="period_once" steps="0" error="0" exit_code="0" pid="7583"/>
</history>
</answer>
</spooler>
../bin/jobscheduler_client.pl --host=atsprdweb03 --port=5556 --message='<show_job job="ORAR-_TEST_-CUX-Simple_ID" />'
<?xml version="1.0" encoding="ISO-8859-1"?>
<spooler>
<answer time="2009-06-17 12:52:18.932">
<job path="/ORAR-_TEST_-CUX-Simple_ID" name="ORAR-_TEST_-CUX-Simple_ID" job="ORAR-_TEST_-CUX-Simple_ID" state="pending" process_class="/adbtstdb01" waiting_for_process="yes" all_steps="0" all_tasks="0" log_file="/atsprdweb03/scheduler/logs/job.ORAR-_TEST_-CUX-Simple_ID.log" order="no" tasks="1" in_period="yes"><file_based state="active">
<requisites>
<requisite type="Process_class" path="/adbtstdb01" is_missing="yes"/>
</requisites>
</file_based>
<tasks count="0"/>
<queued_tasks length="2"/>
<log level="info" highest_level="info" last_info="SCHEDULER-919  Task 21483 enqueued" smtp="smtp-gw" mail_from="scheduler@atsprdweb03" mail_to="itec-gls-eur-pts-scheduling@smtp-gw"/>
</job>
</answer>
</spooler>

Exécution du script

Environnement

Le script ne prend pas d’arguments, il utilise les variables d’environnement initialisées par Autosys. L’intérêt est d’alléger la commande Autosys finale lors de l’encapsulation pour la soumission sur OSS. En passant les informations en variable, on se limite à indiquer le nom du script devant la commande nominale.

$ ./ats2oss.pl

Affichage des informations :

===================================================================
 Supervisor : atsprdweb03
 Port :       5556
===================================================================
2009/06/17 12:32:03 : Configuration
----------------------------------
 Path :       /atsprdweb03/scheduler
 Mail :       itec-gls-eur-pts-scheduling@sgcib.com

Environment variable to define :
 __job_name       job name             (undefined)
 __machine        remote agent         (undefined)
 __owner          user                 (undefined)
 __command        command to execute   (undefined)

Les variables indispensables sont les suivantes :

Variable Utilisation
__job_name Nom du job
__run_machine Superviseur
__machine Machine distante (qui exécutera le traitement).
__command Command a exécuter
__owner Compte de soumission

On utilise le champ __machine qui permet d’extraire la machine distante à partir du nom de la machine virtuelle. D’autres paramètres peuvent être relayés pour fournir plus d’informations au job distant comme la description ou les paramètres de max_run_time pour modifier le comportement.

Si on veut tester le script en dehors du contexte d’Autosys, on initialise directement ces variables au niveau du système.

$ export __job_name=ATSR-TSTOSS-CUX-Sleep  
$ export __machine=apherese
$ export __owner=auto_PE1
$ export __command=sleep 120

Exécution :

./ats2oss.pl

Affichage des variables :

Environment variable to define :
 __job_name       job name             (ATSR-TSTOSS-CUX-Sleep)
 __machine        remote agent         (apherese)
 __owner          user                 (undefined)
 __command        command to execute   (sleep 120)

Configuration

Les paramètres de configuration de base sont stockés dans un fichier de configuration nommé ats2oss.cfg.

scheduler=/atsprdweb03/scheduler
port=5556
mail=itec-gls-eur-pts-scheduling@sgcib.com
polling=30
scheduler emplacement du superviseur
port port du supervieur
mail mail en cas de probleme sur le script
polling fréquence de verification du log

Profile

Le profile va permettre de passer les paramètres à travers le champ profile d’Autosys. Cela va permettre de configurer le relai à partir du job Autosys.

Exemple de profile pour un job de sauvegarde Oracle (RMAN) à travers un sudo :

#!/usr/bin/sh

if [ -z "$LOG" ]
then
       LOG=/tools/autosys/auto_PE1/out
fi
export LOG

OSS_export=__run_machine
OSS_sudo=oraexplo
OSS_shell=ksh
OSS_out=\\\$LOG/$AUTO_JOB_NAME-$AUTORUN
OSS_err=\\\$LOG/$AUTO_JOB_NAME-$AUTORUN
OSS_profile=~oraexplo/.profile
export OSS_sudo OSS_out OSS_err OSS_shell OSS_profile OSS_export

Ce profile exécutera les actions suivantes :
- Export de la variable __run_machine pour indiquer au script qu’il est lance par Autosys
- Sudo –H –u oraexplo
- Commande appelée dans un ksh (norme site)
- Localisation des journaux sur la machine distante
- Profile à sourcer oraexplo/.profile

Définition du Job

La structure du job OSS est la suivante :

<?xml version="1.0" encoding="UTF-8"?>
<job order="no">
 <script language="shell"><![CDATA[

- Commandes avant traitement
- Commandes autosys
- Commandes après traitement

]]></script>
 <run_time once="yes" />
</job>

Il est possible d’ajouter des commandes avant traitement et après traitements tels que le déplacement dans un répertoire particulier, l’utilisation d’un compte, l’authentification, la gestion des logs…

Le démarrage automatique se fait avec la commande once mais il peut arriver que le job existe déjà sur la machine distante, dans ce cas on force son démarrage avec l’envoi du XML suivant :

<start_job job="JOBNAME" at="now"></start_job>

Attention, dans ce cas c’est le job en cache sur la machine distante qui est pris en compte.

Tests

Attente de fin de fichier

Genéralement, la copie du fichier et l’exécution à distance se fait dans les 5 secondes. On attend donc 10 secondes pour avoir un premier statut.

Communication script

A chacun des tests on envoie une commande KILL –USR2 à l’agent afin de lui signifier que le job est toujours en cours. Le PID de l’agent est fourni dans les variables de l’agent :

kill -USR2 $__jc_pid

Cette information est remontée en base de données et accessible par une requête sur le serveur Autosys :

select
        job_name,
        status,
        heartbeat_interval,
        last_heartbeat,
        pid,
        jc_pid
from
        jobst
where
        status=1
        and job_name='JOB'
order by
        last_heartbeat desc

Code JIL

Le kill USR2 ne doit pas dégrader les performances du serveur, la règle est donc la suivante : on envoie un kill toutes les 10 boucles, c’est-à-dire toutes les 10 * frequence_polling avec une frequence de polling par défaut de 30 secondes.

heartbeat_interval: 1

Configuration Serveur

Pour mettre en place la surveillance sur le serveur, il est nécessaire d’ajouter l’option Check_Heartbeat.

# Check job heartbeat every 2 minutes.
#Check_Heartbeat=2

Tests heartbeat

Le test suivant concerne un job renvoyant un heartbeat régulier et souhaitant une alarme si le dernier heartbeat excède 5 minutes :

Code JIL

insert_job: ATSR-THEART-CUX-Test_Heart_Beat   job_type: c
box_name: ATSR-THEART-B  
command: sleep 600
machine: atststtt01
owner: auto_T01
permission:
description: "Test du heartbeat"
alarm_if_fail: 0
heartbeat_interval: 5

Event_demon

[14:11:13.8414] [1] Checking Heartbeats...
[14:11:24.0308] [3] EVENT: CHANGE_STATUS    STATUS: RUNNING         JOB: ATSC-TSTXIT-B  
[14:11:24.3002] [1] EVENT: ALARM            ALARM: MISSING_HEARTBEAT JOB: ATSR-THEART-CUX-Test_Heart_Beat

Logs

Agent

Tue Feb 10 18:06:36 2009: Executing cmd->AUTO_JOB_PID=11076; export AUTO_JOB_PID; AUTOSYS=/tools/autosys/autosys45; export AUTOSYS; AUTOUSER=/tools/autosys/auto_T02; export AUTOUSER; AUTOSERV=T02; export AUTOSERV; AUTOPID=11075; export AUTOPID; AUTO_JOB_NAME=ATSR-TSTOSS-ENT-srvparhar1; export AUTO_JOB_NAME; AUTORUN=0-6; export AUTORUN; . /etc/auto.profile 1 >> /tools/autosys/auto_T02/out/auto_rem_pro.116657.0.6 2>&1; if touch $AUTOUSER/out/$AUTO_JOB_NAME-$AUTORUN ;then true;else exit 122;fi; exec perl /atsprdweb04/scheduler/autosys/ats2oss.pl "echo fred&echo eric&hostname&sleep 60&exit 12" >>$AUTOUSER/out/$AUTO_JOB_NAME-$AUTORUN 2>&1
Tue Feb 10 18:06:36 2009: About to execl...
Tue Feb 10 18:06:36 2009: about to send_event
Tue Feb 10 18:06:36 2009: Sending Event: 101 Status: 1 ...
Tue Feb 10 18:06:36 2009: Attempting to Connect to: oparatst02.world
Tue Feb 10 18:06:36 2009: SENT Successfully !!!
Tue Feb 10 18:06:36 2009: AUTOSV not set
Tue Feb 10 18:07:36 2009: Heart Sig caught
Tue Feb 10 18:07:36 2009: about to send_event
Tue Feb 10 18:07:36 2009: Sending Event: 115 Status: 0 ...
Tue Feb 10 18:07:36 2009: Attempting to Connect to: oparatst02.world
Tue Feb 10 18:07:36 2009: SENT Successfully !!!
Tue Feb 10 18:07:36 2009: Got EINTR from waitpid() - Continuing.
Tue Feb 10 18:08:06 2009: Heart Sig caught
Tue Feb 10 18:08:06 2009: about to send_event
Tue Feb 10 18:08:06 2009: Sending Event: 115 Status: 0 ...
Tue Feb 10 18:08:06 2009: Attempting to Connect to: oparatst02.world
Tue Feb 10 18:08:07 2009: SENT Successfully !!!
Tue Feb 10 18:08:07 2009: Got EINTR from waitpid() - Continuing.
Tue Feb 10 18:08:07 2009: parent returned from wait, exit code 3072 (0 12)
Tue Feb 10 18:08:07 2009: User task exit code = 12
Tue Feb 10 18:08:07 2009: Sending the Completion Event...  
Tue Feb 10 18:08:07 2009: about to send_event
Tue Feb 10 18:08:07 2009: Sending Event: 101 Status: 5 ...
Tue Feb 10 18:08:08 2009: Attempting to Connect to: oparatst02.world
Tue Feb 10 18:08:08 2009: SENT Successfully !!!
Tue Feb 10 18:08:08 2009:  send_event() ret=0
Tue Feb 10 18:08:08 2009: auto_remote work complete, exiting

Serveur

[18:07:37.0643] [5] EVENT: HEARTBEAT        JOB: ATSR-TSTOSS-ENT-srvparhar1
[18:08:08.0471] [4] EVENT: HEARTBEAT        JOB: ATSR-TSTOSS-ENT-srvparhar1

Agent killé

L’un des problèmes d’autosys est qu’en cas de kill de l’agent les infirmations ne serton pas remontée, le job restera donc en running au niveau de la base de données.

Une solution est de profiter du kill –USR2 pour traiter le cas où l’agent de répond plus. Actuellement, un mail est envoyé mauis on pourrait imaginer nun changement de statut forcé en fin de batch avec un commentaire permettant d’indiquer l’exit code.

Attention ! le max exit success doit être géré car il ne sera pas pris en compte par l’event_demon.

Renvoi des informations

Log du script

L’obtention de la log peut se faire de deux manières :
- requête SQL sur le champs LOG de la table SCHEDULER_HISTORY puis unzip des informations
- requêtes http sur le serveur distant en précisant le numéro de la tâche.

Cette deuxième solution a l’avantage de la simplicité :

wget http://atstmpap01:5556/show_log?task=id

Exit code

L’exit code est remonté par l’agent dans la base de données.
Le script relai se termine obligatoirement par l’exit code du job distant :

exit($exit_code);

Demande de kill

La demande de kill autosys doit être récupérée par le script pour exécuter un task_kill distant.

En perl, il suffit d’indiquer le nom d’un sous-programme dans le tableau SIG.

Configuration Autosys

La configuration Autosys (config.INS) indique quels types de signaux sont envoyés :

# List of Signals to Send to a Job for the KILLJOB event
KillSignals=2,9

Ce qui signifie qu’un kill -2 est envoyé puis un kill -9 si le précédent n’a pas répondu assez rapidement.

Si le signal 9 (SIGTERM) ne peut être récupéré, il est tout de même possible d’exécuter des commandes à la récpetion de l’avertissement : SIGINT (demande d’interruption). Pour information, le SIGINT est similaire à un Control-C.

Mise en place

La mise en place se fait en 2 temps :
- indication de la routine en début de script
- ajout de la routine qui relaira le kill sur l’agent distant.

# Routage du signal INT
$SIG{INT} = "trapINT";
&#8230;
# sous programme de kill
sub trapINT {
print "===================================================================\n";
print timestamp()."\n";
print "DEMANDE DE KILL\n";
print "-------------------------------------------------------------------\n";
print sendmessage($mac,$port,"<kill_task job=\"$job\" id=\"$id\" immediately=\"yes\"></kill_task>");
unlink($file);
print "===================================================================\n";
print timestamp()."\n";
print "FIN DE JOB - RETOUR AUTOSYS\n";
print "-------------------------------------------------------------------\n";
exit(-1);
}

Test de kill

sendevent -E KILLJOB -J ATSR-TSTOSS-EUX-Encapsulation

Journal du traitement :

===================================================================
2009/02/06 18:45:47
Prise en charge du script par OSS
       Autosys:        ATSR-TSTOSS-EUX-Encapsulation
       Machine:        atstmpap01
       Commande:       echo fred;echo eric;hostname;sleep 60;exit 12
-------------------------------------------------------------------
Environnement OSS
===================================================================
2009/02/06 18:45:47
Definition de la commande distante
       Commande:       echo fred;echo eric;hostname;sleep 60;exit 12
-------------------------------------------------------------------
Creation du traitement OSS
<?xml version="1.0" encoding="UTF-8"?>
<job order="no">
 <script language="shell"><![CDATA[echo fred;echo eric;hostname;sleep 60;exit 12]]></script>
 <run_time once="yes"/>
</job>
Sauvegarde
       /atsprdweb04/scheduler/config/remote/atstmpap01#5556/ATSR-TSTOSS-EUX-Encapsulation.job.xml
===================================================================
2009/02/06 18:45:47
Communication avec la base de donnees
       DB:     ATSX01
       Start:  2009/02/06 18:45:47
-------------------------------------------------------------------
===================================================================
2009/02/06 18:46:03
DEMANDE DE KILL
-------------------------------------------------------------------
<?xml version="1.0" encoding="ISO-8859-1"?>
<spooler><answer time="2009-02-06 18:46:02.846"><ok/></answer></spooler>
===================================================================
2009/02/06 18:46:03
FIN DE JOB - RETOUR AUTOSYS

Configuration relai

Machine virtuelle

Dans notre exemple, il s’agit d’une machine Windows 2003 utilisant le relai atsprdweb04 :

insert_machine: ATS-EW3-srvparhar1
machine: atsprdweb04
max_load: 100

Job de test

insert_job: ATSR-TSTOSS-ENT-srvparhar1   job_type: c
box_name: ATSR-TSTOSS-B-Test_OSS
command: $${ATS-OSS-UNX} "echo fred;echo eric;hostname;sleep 60;exit 12"
machine: ATS-EXS-srvparhar1
owner: autosys
permission:
description: "Test agent srvparhar1 par atsprdweb04"
std_out_file: $AUTOUSER/out/$AUTO_JOB_NAME-$AUTORUN
std_err_file: $AUTOUSER/out/$AUTO_JOB_NAME-$AUTORUN
alarm_if_fail: 0

Lancement du job

sendevent -E FORCE_STARTJOB  -J ATSR-TSTOSS-ENT-srvparhar1

Log Autosys :

===================================================================
2009/02/10 18:06:36
Prise en charge du script par OSS
       Autosys:        ATSR-TSTOSS-ENT-srvparhar1
       Machine:        srvparhar1
       Commande:       echo fred&echo eric&hostname&sleep 60&exit 12
-------------------------------------------------------------------
Environnement OSS
===================================================================
2009/02/10 18:06:36
Definition de la commande distante
       Commande:       echo fred&echo eric&hostname&sleep 60&exit 12
-------------------------------------------------------------------
Creation du traitement OSS
<?xml version="1.0" encoding="UTF-8"?>
<job order="no">
 <script language="shell"><![CDATA[echo fred&echo eric&hostname&sleep 60&exit 12]]></script>
 <run_time once="yes"/>
</job>
Sauvegarde
       /atsprdweb04/scheduler/config/remote/srvparhar1#5556/ATSR-TSTOSS-ENT-srvparhar1.job.xml
===================================================================
2009/02/10 18:06:36
Communication avec la base de donnees
       DB:     ATSX01
       Start:  2009/02/10 18:06:36
-------------------------------------------------------------------
       task 82 End: NULL
2009/02/10 18:07:36
       task 82 End: 2009-02-10 18:07:52
2009/02/10 18:08:06
===================================================================
2009/02/10 18:08:06
Traitement du retour
       Task:   82
       End time:       2009-02-10 18:07:52
       Exit code:      12
-------------------------------------------------------------------
2009-02-10 18:06:51.930 [info]   SCHEDULER-918  state=starting (at=never)
2009-02-10 18:06:51.930 [info]   SCHEDULER-987  Starting process: "C:\WINDOWS\TEMP\\sos1D3AF.cmd"
2009-02-10 18:06:52.961 [info]    
2009-02-10 18:06:52.961 [info]   C:\Program Files\scheduler>echo fred  &amp; echo eric  &amp; hostname &amp; sleep 60  &amp; exit 12  
2009-02-10 18:06:52.961 [info]   fred
2009-02-10 18:06:52.961 [info]   eric
2009-02-10 18:06:52.961 [info]   srvparhar1
2009-02-10 18:07:51.977 [info]   SCHEDULER-915  Process event
===================================================================
2009/02/10 18:08:06
FIN DE JOB - RETOUR AUTOSYS
       Exit:   12
-----------------------------------------------------------------

Conclusion

Open Source Job Scheduler est un produit ouvert proposant divers modes de connexions aussi bien lors de la définition du traitement que pour le contrôle de l’exécution à travers les services web.

L’utilisation du superviseur permet de disposer d’un référentiel des traitements en base de données, les statistiques d’exécution et les journaux des traitements peuvent être centralisé. Cette fonctionnalité, rarement offerte par les ordonnanceurs, facilite la publication des informations aux utilisateurs puisque une simple interface web permettra d’afficher statistiques et journaux.

L’avantage par rapport à une solution SSH et de pouvoir disposer d’une communication synchrone ou non entre le relai et l’agent. Il est possible de déléguer un traitement à OSS, conserver une surveillance à travers le superviseur puis récupérer le statut en fin d’exécution. Ce type de mécanisme est optimal pour les sites distants avec une bande passante faible.

Sur le même principe, on peut utiliser ce type d’agent sur une DMZ, le traitement est délégué et le relai teste régulièrement la fin d’exécution, la connexion est ainsi toujours ouverte à partir du réseau interne et jamais de la DMZ. Cet avantage pallie le défaut de certains ordonnanceurs dont l’agent ouvre des connexions pour renvoyer le statut vers le serveur.

L’étude portait sur un parc Autosys mais cela peut aussi bien être réalisé avec n’importe quel autre ordonnanceur. Si le principe vous intéresse mais que vous souhaitez un outil plus adapté à la production, nous vous invitons à nous contacter pour étudier une solution avec des produits matures dans ce domaine.

5 mars 2011