Aller au contenu principal

Ordonnanceurs < Les incontournables < Workload Automation Autosys Edition < Administration Autosys

Installation d’un agent Autosys sur un service cluster

La documentation officielle d’Autosys indique que la seule configuration supportée pour l’installation des agents sur un cluster est la suivante :
-  Installation des agents sur les nœuds physiques
-  Ajout d’un disque partagé accessible en lecture/écriture à partir des 2 agents
-  Les alias permettent d’accepter les requêtes sur les adresses physiques et logiques

E. Angenault

6 janvier 2012

 POPULARITE : 334 visites

L’intérêt de la configuration officiellement supportée est d’avoir une continuité de service car les 2 agents sont disponibles à tout moment quelque soit l’état des services du cluster.

L’inconvénient est qu’un disque partagé en lecture/écriture par différentes machines à un même disque demande une technologie généralement coûteuse comme le GPFS.

D’un point de vue fonctionnel, les utilisateurs peuvent demander que leur traitement soit, ou non, lié directement au service afin de retrouver l’ensemble des fichiers, comme les journaux de l’agent ou des traitements, sur le système de fichiers de leur service.

Installation

Nœud physique

L’installation de l’agent sur le nœud physique suit la procédure standard, cette installation permet de conserver un point d’entrée sur les machines physiques du cluster.

Pour dédier cette installation à l’utilisation exclusive de la soumission sur l’adresse physique, l’agent doit être configuré pour n’écouter que sur cette adresse. Cette configuration est réalisée par le paramètre communication.bindaddress.

On édite le fichier agentparm.txt pour y indiquer l’adresse la machine : communication.bindaddress=machine1

Au démarrage de l’agent, on peut vérifier qu’il écoute bien sur l’adresse dédiée

netstat &#8211;na | grep 11601
tcp        0      0  10.184.49.81.11601    *.*                     LISTEN

Nœud du cluster

A partir du moment ou le service est défini avec une adresse IP et un File System dédiés, on installera l’agent strictement de la même manière que pour un nœud physique.

L’ensemble des fichiers de l’agent est dans la même arborescence, ce qui signifie que les fichiers de configuration, les données et les journaux basculeront en même temps.

La bascule de l’agent et de sa base de données est la condition indispensable pour être supportée par l’éditeur.

netstat &#8211;na | grep 11601
tcp        0      0  10.184.49.81.11601     *.*                     LISTEN
tcp        0      0  10.184.49.101.11601    *.*                     LISTEN

Définitions

Machine

/* ----------------- SERVICE ----------------- */

insert_machine: SERVICE
type: a
factor: 1.00
port: 11601
node_name: SERVICE
agent_name: SERVICE
/* key_to_agent: *** masked value ***/
encryption_type: AES
heartbeat_attempts: 1
heartbeat_freq: 5
provision: n
character_code: ASCII

Traitement

/* ----------------- TEST_CLUSTER ----------------- */

insert_job: TEST_CLUSTER   job_type: CMD
command: sleep 33
machine: SERVICE
owner: root
permission:
date_conditions: 0
description: "SERVICE"
std_out_file: /tmp/${AUTO_JOB_NAME}_${AUTORUN}.out
std_err_file: /tmp/${AUTO_JOB_NAME}_${AUTORUN}.err
alarm_if_fail: 1

Service indisponible

Lorsque le service est indisponible, le traitement passe en état PENDING. sendevent -E STARTJOB -J TEST_CLUSTER

Le journal du serveur indique clairement l’absence de réponse de l’agent.

[2012/01/06 12:45:04]      CAUAJM_I_40245 EVENT: STARTJOB         JOB: TEST_CLUSTER
[2012/01/06 12:45:04]      CAUAJM_I_40188 Pending job TEST_CLUSTER due to offline machine(s).

Cet état pending peut être visualisé par un autorep.

autorep -J TEST_CLUSTER

Job Name                                                         Last Start           Last End             ST Run/Ntry Pri/Xit
________________________________________________________________ ____________________ ____________________ __ ________ _______
TEST_CLUSTER                                                     2012/01/06 12:38:19  2012/01/06 12:38:49  PE 4040/1   0

Au démarrage, l’agent envoie une notification de mise en ligne au manager.

[2012/01/06 12:50:48]      CAUAJM_I_40245 EVENT: MACH_ONLINE      MACHINE: SERVICE TEXT: <Machine <SERVICE> automatically brought online due to detected status change.>
[2012/01/06 12:50:48]      CAUAJM_I_40119 Bringing job <TEST_CLUSTER> out of the pending state due to online machine <SERVICE>.
[2012/01/06 12:50:48]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: STARTING        JOB: TEST_CLUSTER    MACHINE: SERVICE
[2012/01/06 12:50:48]      CAUAJM_I_40120 Completed 1 job start(s) for online machine <SERVICE>.
[2012/01/06 12:50:50]      CAUAJM_I_10082 [SERVICE connected for TEST_CLUSTER 2568.4042.1]
[2012/01/06 12:50:51]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: RUNNING         JOB: TEST_CLUSTER    MACHINE: SERVICE TEXT: <Executing at SERVICE>

A la réception de la notification, le manager liste les traitements en attente et les passe en mode STARTING.

Arrêt/redémarrage de l’agent

Lorsqu’un agent est stoppé alors que des traitements tournent, l’exécution continue et stocke les informations sur l’agent.

L’exemple suivant est un arrêt d’agent alors qu’un traitement est en exécution.

[2012/01/06 12:52:27]      CAUAJM_I_40245 EVENT: STARTJOB         JOB: TEST_CLUSTER
[2012/01/06 12:52:27]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: STARTING        JOB: TEST_CLUSTER    MACHINE: SERVICE
[2012/01/06 12:52:27]      CAUAJM_I_10082 [SERVICE connected for TEST_CLUSTER 2568.4043.1]
[2012/01/06 12:52:28]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: RUNNING         JOB: TEST_CLUSTER    MACHINE: SERVICE TEXT: <Executing at SERVICE>
[2012/01/06 12:52:46]      CAUAJM_I_40245 EVENT: MACH_OFFLINE     MACHINE: SERVICE TEXT: <Machine <SERVICE> automatically brought offline due to detected status change.>

Le traitement reste en RUNNING jusqu’à ce que l’agent soit disponible.

autorep -J TEST_CLUSTER

Job Name                                                         Last Start           Last End             ST Run/Ntry Pri/Xit
________________________________________________________________ ____________________ ____________________ __ ________ _______
TEST_CLUSTER                                                     2012/01/06 12:52:28  -----                RU 4043/1

La remise en ligne de l’agent notifie le manager et renvoie le statut final. Dans cet exemple, le job a continué son exécution alors que l’agent n’était plus disponible.

[2012/01/06 12:54:21]      CAUAJM_I_40245 EVENT: MACH_ONLINE      MACHINE: SERVICE TEXT: <Machine <SERVICE> automatically brought online due to detected status change.>
[2012/01/06 12:54:21]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: SUCCESS         JOB: TEST_CLUSTER    MACHINE: SERVICE   EXITCODE:  0
[2012/01/06 12:54:21]      CAUAJM_I_40120 Completed 0 job start(s) for online machine <SERVICE>.

Kill des processus

Le kill des processus est remonté au niveau de l’agent, suivant l’ordre il peut s’agir :
-  d’un kill de l’agent
-  d’un kill du cybspawn
-  d’un kill du traitement

Dans le cas d’un kill applicatif, le cybspawn reprend le kill du shell, dans notre exemple 137.

Dans le cas d’un process de l’agent, c’est le signal qui est renvoyé, le processus est killé par un kill -9, c’est l’exit code 9 qui est renvoyé.

[2012/01/06 13:00:21]      CAUAJM_I_40245 EVENT: STARTJOB         JOB: TEST_CLUSTER
[2012/01/06 13:00:21]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: STARTING        JOB: TEST_CLUSTER    MACHINE: SERVICE
[2012/01/06 13:00:23]      CAUAJM_I_10082 [SERVICE connected for TEST_CLUSTER 2568.4047.1]
[2012/01/06 13:00:24]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: RUNNING         JOB: TEST_CLUSTER    MACHINE: SERVICE TEXT: <Executing at SERVICE>

Différents process pouvant être killés :

ps -ef | grep cyb
   root 18411 18410  0 13:00:24 ?         0:00 -sh -c /waae/SystemAgent/SERVICE/cybspawn 7 /waae/SystemAgent/SERVICE 16 "AUTOSERV=L03" "AUTO_J
   root 27218     1  0 12:36:44 ?         0:06 ./cybAgent.bin -a MACHINE
   root 18410 17921  2 13:00:23 ?         0:00 /waae/SystemAgent/SERVICE/cybspawn.bin 6 /waae/SystemAgent/SERVICE 20120106 13002167-0100 cl-at
   root 17921     1  0 13:00:04 ?         0:03 ./cybAgent.bin -a SERVICE
root@MACHINE:/waae/SystemAgent/SERVICE# kill -9 17921
root@MACHINE:/waae/SystemAgent/SERVICE# kill -9 18411

Le démarrage de l’agent permet de renvoyer le signal :

[2012/01/06 13:02:00]      CAUAJM_I_40245 EVENT: MACH_ONLINE      MACHINE: SERVICE TEXT: <Machine <SERVICE> automatically brought online due to detected status change.>
[2012/01/06 13:02:00]      CAUAJM_I_40120 Completed 0 job start(s) for online machine <SERVICE>.
[2012/01/06 13:02:01]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: FAILURE         JOB: TEST_CLUSTER    MACHINE: SERVICE   EXITCODE:  9 TEXT: <Aborted, Signal 9>
[2012/01/06 13:02:02]      CAUAJM_I_40245 EVENT: ALARM            ALARM: JOBFAILURE       JOB: TEST_CLUSTER    MACHINE: SERVICE

Conclusion

Une très bonne intégration d’un agent d’ordonnanceur sur un cluster mais dont la procédure d’installation n’est curieusement pas documentée et dont la version supportée est radicalement différente. De même le paramètre bindaddress n’apparait dans aucun documentation, elle nous a été fournie directement par le niveau 2.

Si vous mettez en place ce type de configuration, nous vous conseillons fortement de la faire valider par l’éditeur avant toute mise en production.


Doc
A la une

Article d’actualité publié en première page du site.

Voir aussi...
autotrad, Cas pratique, Communiqué de Presse, Documentation, Eyrolles, FAQ, Fiche technique, Forum utilisateur, graphique, news, Procédure d’installation, Scripts

Le document issu de http://Ordonnancement.org est mis à disposition sous les termes de la licence Creative Commons, vous pouvez l'utilisez dans vos documents à condition de citer l'auteur E. Angenault, vous êtes aussi libre de le modifier. Par contre, vous devez le redistribuer dans les mêmes conditions et la commercialisation ne peut se faire qu'avec l'accord de l'auteur.