Installation d’un agent Autosys sur un service cluster

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 –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 –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.

Article

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

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

Mise à jour :6 janvier 2012
Visites : 124
Auteur : E. Angenault
Site : Angenault.net

Administration Autosys

Cette rubrique présente des articles techniques à l’usage des administrateurs.

Liens commerciaux

Accès rapide

A la une

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

Diagnostic Autosys
Autosys propose différents outils en ligne pour interagir avec le gestionnaire d’évènements mais quelle commande doit on effectuer pour obtenir la bonne information ? autodiag est un script Perl qui exécute des séries de commandes pour afficher (...)
Evolutions de l’ordonnancement par Gartner Research
Le Gartner offre un panorama des offres d’automatisation à travers son fameux Magic Quadrant qui classe les éditeurs suivant 2 axes : sa capacité opérationnelle et sa vision d’ensemble.
Feuille de route WA Autosys Edition (Novembre 2011)
Le club utilisateur du 30 Novembre proposait différentes thèmes autour de Workload Automation Autosys Edition. La journée a débuté avec la session "l’actualité autour de CA Workload AE" animé par le product manager Charlie (...)
Groupe LinkedIN "Choix d’ordonnanceur"
Si vous souhaitez acquérir un automate de production mais que vous n’avez qu’une vague idée des critères de sélection, nous vous invitons à rejoindre le groupe dédié "choix d’ordonnanceur" afin d’échanger avec d’autres (...)
uniNews N°11 : Migrations « certifiées » 100% réussies !
Le marché des progiciels d’ordonnancement a deux particularités notables : Il est en croissance, C’est un marché de conversion : près de 7 dossiers sur 10 concernent l’acquisition d’une nouvelle solution en remplacement (...)
Version V5 OpCon™
OpCon™ fait évoluer son interface graphique et intègre de nouveaux Plugins

Dossier

> Ordonnanceurs > Les incontournables > Workload Automation Autosys Edition

Cette rubrique présente des articles techniques à l’usage des administrateurs.

Workload Automation Autosys Edition

La version 11.3 d’Autosys est en GA depuis Mars 2011, elle intègre le moteur Autosys 4.5.1 avec quelques nouvelles fonctionnalités comme la gestion des ressources ou des fonctions liés à JMO (TNG Workload), une nouvelle interface WCC et les agents cybermation.