wiki:Tutorial/JobSubm

Context Navigation

Version 49 (modified by /C=FR/O=CNRS/OU=UMR8608/CN=Christophe Diarra/emailAddress=diarra@…, 16 years ago) (diff)
--

Soumission des Jobs

TracNav

Tutoriel

Pour effectuer cette partie du tutorial, il faut télécharger le tarfile contenant les fichiers utilisés dans les exercices et le désarchiver dans votre répertoire de travail. S'il n'y a pas de browser web accessible sur l'UI, il est possible d'utiliser la commande :

wget http://quattor.web.lal.in2p3.fr/packages/tutorial/tutorial-lal.tar.gz

Premiers pas…

Principales Commandes

Les commandes permettant de soumettre et gérer un job commencent toutes par glite-wms-job- et utilise les services d'un gLite WMS.

Note : pour soumettre et gérer un job avec l'ancien LCG RB, il faut utiliser les commandes edg-job-. Ces commandes sont obsolètes et il faut préférer l'utilisation d'un WMS, sauf raisons très particulières. De même il ne faut pas utiliser les commandes glite-job-xxx, elles-mêmes obsolètes.

Les principales commandes sont :

glite-wms-job-submit : soumission d'un job. Cette commande nécessite un delegation proxy qui peut être créé automatiquement si on utilise l'option -a ou être créé avec la commande glite-wms-job-delegation-proxy et être spécifié avec l'option -d identifieur. L'utilisation de -d doit être préférée si on soumet plusieurs jobs car elle est beaucoup plus efficace.

glite-wms-job-status : affichage de l'état d'un job (en attente, en cours d'exécution, terminé...). L'option --all permet d'afficher l'état de tous les jobs de l'utilisateur, si le LB (Logging and Bookkeeping, l'un des services du WMS) utilisé fait partie des LBs configurés par défaut sur l'UI.

glite-wms-job-output : récupération de l'output du job. Le répertoire utilisé pour stocker les résultats dépend de la configuration du site. Au LAL, le répertoire est ~/JobOutput/. Ce répertoire doit exister avant l'exécution de la commande : il faut le créer si nécessaire.

glite-wms-job-logging-info : affichage d'informations détaillées sur l'exécution du job et les éventuelles erreurs rencontrées.

glite-wms-job-delegate-proxy -d identifieur : obtention d'un delegation proxy pour soumettre plusieurs jobs. identifieur est un nom arbitraire qui sera utilisé pour désigner le delegation proxy et l'utiliser dans avec les commandes comme glite-wms-job-submit.

Note: l'utilisation des commandes glite-wms-job-xxx nécessite d'avoir un proxy valide.

Toutes les commandes ont une aide en ligne accessible en utilisant l'option --help ou la commande man.

La commande glite-wms-job-submit retourne un jobid qui est un URL. Ce jobid devra être utilisé pour désigner le job dans les autres commandes. Il doit être conservé sans quoi il n'est plus possible d'interagir avec le job (connaitre son état ou récupérer son output). Quand on soumet plusieurs jobs, il peut être plus pratique d'utiliser l'option -o fichier lors du submit : dans ce cas, le jobid sera écrit dans le fichier. Le même fichier pourra être utilisé à la place du paramètre jobid dans les autres commandes en utilisant l'option -i.

Les commandes glite-wms-job-xxx nécessitant d'avoir un proxy valide, il n'y a pas besoin de spécifier la VO utilisée pour ces commandes. Elle est obtenue à partir du proxy.

Il existe également des APIs (Java, C, C++) qui permettent la gestion des jobs depuis une application. Ce tutorial ne couvre pas la description de ces APIs.

Soumission d'un Job "Hello World"

Cette exercice consiste à soumettre un job très simple qui écrira "Hello World" dans le fichier d'output. Le job en lui-même n'a pas d'intérêt particulier mais permet d'illuster la soumission et le suivi de l'exécution d'un job. Un job grille est décrit dans un langage particulier appelé JDL], décrit dans la partie suivante.

Si ce n'est pas déjà fait, créez un proxy à l'aide de la fonction voms-proxy-init.
Soumettez le job HelloWorld.jdl se trouvant dans le matériel du tutorial récupéré précédemment, en utilisant la commande glite-wms-job-submit. Sauver le jobid retourné ou utiliser l'option -o.
Vérifiez le statut du job en utilisant la commande glite-wms-job-status. On peut utiliser la commande watch pour exécuter une commande dans une boucle (pour effectuer la commande glite-wms-job-status toutes les 15 secondes, utilisez watch -n 15 glite-wms-job-status <jobid> et taper ctrl-c pour sortir).
- Suivez les modifications de l'état du job jusqu'à l'état "Done(Success)".
- Combien d'états différents pouvez-vous distinguer ?
- Si le job se termine dans l'état "Aborted", c'est qu'il y a eu une erreur. On peut trouver plus d'informations avec la commande glite-wms-job-get-logging-info.
Lorsque le job est terminé (Status: Done (Success)), récupérez les données générées à l'aide de la commande glite-wms-job-output.
Vérifiez que tout s'est déroulé correctement en consultant les fichiers std.out et std.err. Le fichier std.err doit être vide et std.out doit contenir "Hello World". Cette procédure simple est utilisée pour le suivi de tous les jobs.

Description des Jobs (JDL)

Modification et Edition

Le fichier de description des jobs (JDL) utilise 1 langage particulier pour décrire les attributs et besoins du job. Ces informations sont utilisés par le WMS pour sélectionner le CE approprié à l'exécution du job et par le CE pour lancer l'application de l'utilisateur.

Le format de ce fichier est un ensemble de définition attribut/valeur, en utilisant le format suivant :

Attribut: Valeur;

Note: Attribut n'est pas case sensitive. Certaines valeurs le sont, par exemple des noms de fichiers. Les chaines de caractères doivent être entre '.

Les principaux attributs sont:

Executable (obligatoire) : définit la commande à exécuter. S'il s'agit d'un shell script, le shell utilisé par le script (indiqué dans la ligne #!) doit exister dans le worker node.
Argument (facultatif) : une chaine de caractère passée comme argument de la commande, en utilisant la syntaxe attendue par la commande.
InputSandbox (facultatif) : liste des fichiers locaux à transférer avec le job.
OutputSandbox (obligatoire) : liste des fichiers produits par le job et devant être retournés par la commande glite-wms-job-output. Il doit y avoir au moins stdout et stderr.

Pour plus d'information, consulter la liste des attributs JDL valides.

Exercices :

Modifiez le fichier HelloWorld.jdl de manière à ce qu'il n'appelle plus /bin/echo mais le script HelloWorldScript.sh. Pour cela :
- la ligne Executable doit être HelloWorldScript.sh
- la ligne Argument peut rester avec Hello World
- Il faut définir le paramètre InputSandbox. Tous les fichiers listés dans InputSandbox sont transfèrés avec le job. Quand on soumet plusieurs jobs avec les mêmes fichiers d'entrée, une nouvelle copie des fichiers est créée pour chaque job.
Modifier de nouveau HelloWorld.jdl de manière à ce qu'il appelle cette fois l'exécutable myhostname. Vous pouvez visualiser la source de cet exécutable, qui est un programme C : myhostname.c. Vous n'avez cette fois pas besoin de définir d'argument. Il faut modifier la ligne InputSandbox. Exécutez le job et vérifiez que tout fonctionne. Sur quel ordinateur a tourné votre job ?
L'exécution d'un programme en C compilé n'est pas forcément pratique : l'exécutable peut être d'une grande taille, dépendre de plusieurs fichiers, ou dépendre d'un environnement d'exécution particulier. Une solution consiste à compiler le programme directement sur le CE. Modifier une nouvelle fois HelloWorld.jdl de manière à ce qu'il appelle le script buildandrun.sh, avec pour argument myhostname.
- Testez ce script seul pour comprendre l'argument nécessaire.
- Exécutez le job et vérifiez qu'il fonctionne toujours.
- Votre job a-t-il tourné sur le même ordinateur que précédemment?

Note : si la VO que vous utilisez est acceptée par plusieurs CE, il peut être utile d'ajouter la ligne suivante dans votre JDL pour forcer le job à aller sur un CE particulier (au LAL dans l'exemple) :

Requirements = regexp(`.*\.lal\.in2p3\.fr:.*`, other.GlueCEUniqueID)

Requirements et Rank

Il y a deux mots-clés très importants dans les fichiers JDL : Requirements et Rank . Leurs valeurs sont des expressions. Ces 2 mot-clés servent à sélectionner le CE auxquels sera envoyé le job.

Requirements : ce mot-clé permet de sélectionner les CE qui ont les ressources requises pour exécuter le job. L'expression des ressources peut porter sur n'importe quelle informati" on publié dans le système d'information (BDII). En particulier, le nombre de CPUs libres, le temps d'exécution minimum, la quantité de mémoire... La valeur est une condition logique utilisant une syntaxe assez habituelle (proche de celle du langage C). On peut utiliser des regular expressions avec les chaines de caractères, en utilisant la fonction RegExp(pattern,attribut). Par exemple, pour sélectionner un CE appartenant au domaine lal.in2p3.fr, on pourra utiliser l'expression :
```
Requirements = regexp(".*\.lal\.in2p3\.fr:.*", other.GlueCEUniqueID);
```

Rank : cet mot-clé définit l'ordre de classement des CEs sélectionnés par la clause Requirements . Le CE sélectionné pour exécuter le job est celui ayant le meilleur classement suivant le critère défini par Rank. En cas d'ex-aequo, le CE est choisi aléatoirement parmi eux. Par exemple pour trier sur le nombre de CPUs libres dans le CE :
```
Rank = other.GlueCEStateFreeCPUs;
```

Le résultat de l'évaluation de Requirements et Rank est différent suivant la VO utilisée car toutes les sites n'acceptent pas les mêmes VOs. On peut connaitre le résultat de l'évaluation de Requirements et Rank avant de soumettre le job en utilisant la commande glite-wms-job-list-match et en indiquant le fichier JDL en paramètre. Cette commande retourne la liste des CEs sélectionnés par Requirements, classés dans l'ordre indiqué par Rank. On peut exécuter cette commande pour une VO pour laquelle on a pas de proxy en ajoutant l'option --vo voname (par exemple : --vo dteam).

Exercices :

Dans les exercices proposés, vous allez éditer le fichier HelloWorld.jdl pour modifier les expressions Requirements et Rank. Pour voir l'effet de la modification, utiliser la commande glite-wms-job-list-match puis essayer de soumettre le job en utilisant la commande glite-wms-job-submit. Pour soumettre le job, vous devez avoir un proxy valide.

Sélectionner les sites qui acceptent des jobs nécessitant plus de 1 heure de CPU :
```
Requirements = (other.GlueCEPolicyMaxCPUTime > 60);
```
Essayer de modifier la clause Requirements pour demander plus de 2h, plus de 12h. Indiquer le besoin en temps d'exécution total plutôt qu'en temps CPU (other.GlueCEPolicyMaxWallClockTime).
Choisir uniquement des sites francais. Pour cela on peut utiliser la valeur suivante (d'abord seule puis en la combinant avec la précédente avec l'opérateur &&) :
```
RegExp(`.*\.fr:.*`,other.GlueCEUniqueID)
```
Ajoutez les lignes suivantes pour utiliser la ressource avec le plus grand nombre des CPUs libres et comparer le CE qui sera sélectionné.
```
Rank = other.GlueCEStateFreeCPUs;
```
Utiliser la valeur -other.GlueCEStateFreeCPUs : quelle est l'effet ?
Que se passe-t-il si on utilise Rank = 1;?

Note : Une option -r existe pour la commande glite-wms-job-submit qui permet de choisir une ressource spécifique. Cependant cette option court-circuite le processus de match-making du Resource Broker (sélection du CE approprié à partir des différents requirements) et ne crée pas le fichier nécessaire (BrokerInfo) pour la gestion de données. Il faut donc préférer l'utilisation de other.GlueCEUniqueID dans la ligne Requirements.

L'environnent d'exécution sur le Worker Node

Chaque utilisateur de la grille est associé à un compte local, spécifique à chaque site. L'accès aux ressources locales est contrôlé par les droits de ce compte. Si on soumet plusieurs jobs en utilisant des proxies différents (VO et/ou groupe/rôle), on n'est pas associé au même compte sur le worker node. L'exercice suivant permet de l'illustrer.

Exercices :

Initialiser votre proxy sans utiliser de groupe/rôle particulier.
Visualisez le contenu du fichier JDL whoami.jdl. Lancez le job et récupérez l'output. Visualisez le fichier std.out. Sur quel compte êtes-vous mappé?
Visualisez le contenu du script envvar.jdl. Soumettez un job qui lance ce script dans la grille. Regardez la liste des variables. Combien de variables concernent la grille?
Ecrivez un job qui liste les versions des logiciels disponibles dans le Worker Node. On peut utiliser la commande rpm pour le faire.
Initialiser un nouveau proxy en utilisant le rôle Tutorial1 ou Tutorial2, suivant celui que vous avez le droit d'utiliser et reexécuter le fichier JDL whoami.jdl.

Renouveler le proxy en cours de job

Par défaut, la validité d'un proxy est relativement courte, généralement entre 12 et 96h. La durée maximale est fixée par le serveur VOMS de la VO. Si le proxy expire avant la fin du job, il ne sera pas possible de récupérer les résultats. S'il expire avant le début du job, le job échouera.

Pour permettre à un job de s'exécuter sans problème quelque soit son temps d'attente et sa durée, il faut utiliser un service de renouvellement de proxy, appelé MyProxy. Son utilisation est très simple. Il faut d'abord ajouter la ligne suivante dans le JDL du job (la valeur du paramètre doit être un serveur MyProxy acceptant la VO utilisée pour le voms-proxy-init et le resource broker utilisé pour soumettre le job, myproxy.grif.fr est le serveur MyProxy de GRIF) :

MyProxyServer = `myproxy.grif.fr`;

Après avoir fait le voms-proxy-init et avant de soumettre le job, il faut exécuter la commande myproxy-init, comme suit :

myproxy-init -d -s myproxy.grif.fr

La configuration d'un serveur MyProxy détermine les resource brokers autorisés à utiliser le service pour renouveler des proxies. Le serveur MyProxy de GRIF, myproxy.grif.fr, accepte les demandes de renouvellement en provenance du RB de GRIF, grid09.lal.in2p3.fr.

On peut voir la liste des proxies valides avec la commande myproxy-info et on peut mettre fin au renouvellement du proxy (avant ou pendant l'exécution du job) avec la commande myproxy-destroy. L'option -d doit être toujours être utilisée avec l'ensemble des commandes myproxy-*.

Note : les commandes myproxy-xxx utilisent un nom de fichier différent des autres commandes gLite si on utilise un fichier unique pour le certificat et la clé privée (extension .p12). Pour résoudre le problème, il faut créer le lien symbolique suivant :

cd ~/.globus
ln -s usercert.p12 usercred.p12

Soumission d'un job MPI

Beaucoup de disciplines utilisent des jobs parallèles. MPI (Message PassingInterface) est un protocole qui permet la communication entre les tâches parallèles. Les jobs MPIs sont supportés dans la grille. La grille permet d'utiliser les différentes versions et implémentations de MPI :

MPI v1 : LAM MPICH
MPI v2 : openMPI et MPICH2

Le logiciel mpi-start développé par le projet européen int.eu.grid facilite l'utilisation du MPI dans la grille. L'utilisateur peut définir :

Un script à exécuter avant le binaire MPI (par exemple pour compiler le programme),
Le programme lui-même, et
Un script à exécuter après le binaire MPI (par exemple pour enregistrer les résultats dans un SE).

Le fichier mpi-hooks.sh définit les scripts à exécuter avant et après le binaire MPI. Le fichier JDL définit les paramètres comme des nombres de CPU pour le job.

Lancez un job avec mpi-start-lam.jdl Regardez la sortie du job. S'il a fonctionné correctement, on pourra lire des lignes telles que:
- Hello world! from processor 3 out of 8
Changez le nombre de CPUs utilisé par le job. Vérifiez que le job marche toujours. Fonctionne t-il aussi si vous spécifiez 1000 CPU?

La grille supporte les jobs MPI sur un seul site. MPI avec esclaves sur plusieurs sites n'est pas supporté. Le support du MPI évolue très rapidement dans la grille en ce moment. Ceci va se stabiliser dans quelques mois.

Les informations officielles à jour pour l'utilisation de MPI sur la grille EGEE sont disponibles sur le site EGEE UIG. Plus de détails sont disponibles sur le site du MPI Working Group.

Soumission de jobs via le WMS

Introduction

En gLite 3.1 le WMS (Workload Management System) remplace le RB. Il comprend deux services : le WMS lui-même et le Logging and Bookkeeping service (LB). Ces deux services peuvent être sur des machines séparés. C'est pourquoi votre jobId contient le nom du LB quit être différent de celui du WMS utilisé.

Le WMS permet une meilleure gestion des jobs : meilleure temps de réponse, meilleure tenue de la charge.

Les commandes edg-job-* qui utilisaient le RB peuvent donc être avantageusement remplacées par leurs équivalents glite-wms-job-* . Pour avoir de l'aide sur une commande, utiliser man ou l'option --help de la commande (Exemple: man glite-wms-job-submit ou glite-wms-job-submit --help). Par ailleurs, il est recommandé d'utiliser l'option -o avec la commande glite-wms-job-submit pour mémoriser les jobIds dans un seul ou plusieurs fichiers. L'option -i des autres commandes glite-wms-job-* permet de relire les jobIds dans un de ces fichiers.

Chaque job soumis au WMS doit être associé à un proxy délégué au WMSProxy server par l'utilisateur. Le WMProxy (un composant du WMS) s'en sert pour toute interaction avec les autres services grille en rapport le job.

Le proxy de l'utilisateur peut être délégué au WMS (WMSProxy), soit automatiquement (option -a) soit explicitement (option -d). Si vous soumettez des centaines de jobs, il est préférable d'utiliser la délégation explicite car l'auto-délégation est plus consommatrice de ressources.

Dans les différents exemples, nous utiliserons la délégation automatique. Un paragraphe sera consacré à la délégation explicite.

Le WMS utilisé est celui de GRIF (wms.grif.fr i.e grid09.lal.in2p3.fr). Le LB associé est grid02.lal.in2p3.fr

Soumission d'un job

On peut vérifier d'abord (facultatif) qu'il n'y a pas d'erreur dans le jdl et afficher la liste des CE candidats pour le job.

diarra@ipngrid01 ~/work]$ glite-wms-job-list-match -a HelloWorld.jdl
Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
==========================================================================
                     COMPUTING ELEMENT IDs LIST
 The following CE(s) matching your job requirements have been found:
        *CEId*
 - ipnls2001.in2p3.fr:2119/jobmanager-pbs-ipno
==========================================================================

Pour soumettre un job, utiliser glite-wms-job-submit :

diarra@ipngrid01 ~/work]$ glite-wms-job-submit -o jobId -a HelloWorld.jdl
Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
====================== glite-wms-job-submit Success ======================
The job has been successfully submitted to the WMProxy
Your job identifier is:
https://grid02.lal.in2p3.fr:9000/Rw0lve7pSId8-DBP2jiatw
The job identifier has been saved in the following file:
/home/diarra/work/jobId
==========================================================================

[diarra@ipngrid01 ~/work]$ cat jobId
###Submitted Job Ids###
https://grid02.lal.in2p3.fr:9000/Rw0lve7pSId8-DBP2jiatw

La delegation automatique de proxy au WMSProxy

Il suffit d'utiliser l'option -a comme vu ci-dessous avec les commandes glite-wms-job-submit ou glite-wms-job-list-match.

La délégation explicite de proxy au WMSProxy

Nous avons déjà utilisé la délégation automatique (simple et pratique) plus haut avec l'option -a des commandes glite-wms-job-submit et glite-wms-job-list-match. Mais l'inconvenient de cette méthode est que la délégation est repétée pour chaque job. Avec la délégation explicite, la délégation est faite une seule fois, ce qui est plus performant car les jobs suivants seront soumis plus rapidement.

Pour déléguer explicitement un proxy au WMProxy, la commande à utiliser est : glite-wms-job-delegate-proxy -d <delegID>

<delegID> est un nom (une chaine) choisi par l'utilisateur. Les futures invocations de glite-wms-job-submit et glite-wms-job-list-match peuvent bypasser la délégation du proxy avec l'option -d <delegID> .

Par exemple, pour déléguer un proxy (qu'on nomme ici mydelegID):

[diarra@ipngrid01 ~/work]$ glite-wms-job-delegate-proxy -d mydelegID

Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
================== glite-wms-job-delegate-proxy Success ==================
Your proxy has been successfully delegated to the WMProxy:
https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
with the delegation identifier: mydelegID
==========================================================================

On peut alors soumettre un job en utilisant le <delegID> mydelegID :

[diarra@ipngrid01 ~/work]$ glite-wms-job-submit -d mydelegID HelloWorld.jdl

Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
====================== glite-wms-job-submit Success ======================
The job has been successfully submitted to the WMProxy
Your job identifier is:
https://grid02.lal.in2p3.fr:9000/ro9Lu7b0CtgKAYhua0HZ2A
==========================================================================

L'option -a de glite-wms-job-delegate-proxy permet de demander au système de choisir pour nous un <delegID> :

[diarra@ipngrid01 ~/work]$ glite-wms-job-delegate-proxy -a

Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
================== glite-wms-job-delegate-proxy Success ==================
Your proxy has been successfully delegated to the WMProxy:
https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server

with the delegation identifier: cFdr8WvkFirUHQs2sUpyGQ
==========================================================================

Note: A cause d'un bug, si le UI est configuré avec une liste de WMS, glite-wms-job-delegate-proxy ne delegera le proxy qu'a un seul de la liste. Ceci est une limitation de la delegation explicite.

Status des jobs / Récupération des outputs (OutpuSandbox)

Pour connaître le status d'un job :

[diarra@ipngrid01 ~/work]$ glite-wms-job-status -i jobId
ou
[diarra@ipngrid01 ~/work]$ glite-wms-job-status https://grid02.lal.in2p3.fr:9000/Rw0lve7pSId8-DBP2jiatw

*************************************************************
BOOKKEEPING INFORMATION:
Status info for the Job : https://grid02.lal.in2p3.fr:9000/Rw0lve7pSId8-DBP2jiatw
Current Status:     Scheduled
Status Reason:      Job successfully submitted to Globus
Destination:        ipnls2001.in2p3.fr:2119/jobmanager-pbs-ipno
Submitted:          Tue Jun  3 16:27:26 2008 CEST
*************************************************************

Attendre que le job soit Running puis Done (Success) pour pouvour récupérer les résultats avec glite-wms-job-status :

[diarra@ipngrid01 ~/work]$ glite-wms-job-status -i jobId
(ou glite-wms-job-status https://grid02.lal.in2p3.fr:9000/Rw0lve7pSId8-DBP2jiatw)

*************************************************************
BOOKKEEPING INFORMATION:
Status info for the Job : https://grid02.lal.in2p3.fr:9000/Rw0lve7pSId8-DBP2jiatw
Current Status:     Done (Success)
Exit code:          0
Status Reason:      Job terminated successfully
Destination:        ipnls2001.in2p3.fr:2119/jobmanager-pbs-ipno
Submitted:          Tue Jun  3 16:27:26 2008 CEST
*************************************************************

Le job est terminé, on peut récupérer les résultats (OutputSandbox)avec glite-wms-job-output :

[diarra@ipngrid01 ~/work]$ glite-wms-job-output -i jobId
(ou glite-wms-job-output https://grid02.lal.in2p3.fr:9000/Rw0lve7pSId8-DBP2jiatw)

Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
================================================================================
                        JOB GET OUTPUT OUTCOME
Output sandbox files for the job:
https://grid02.lal.in2p3.fr:9000/Rw0lve7pSId8-DBP2jiatw
have been successfully retrieved and stored in the directory:
/home/diarra/JobOutput/diarra_Rw0lve7pSId8-DBP2jiatw
================================================================================

[diarra@ipngrid01 ~/work]$ ls -l /home/diarra/JobOutput/diarra_Rw0lve7pSId8-DBP2jiatw
total 0
-rw-r--r--  1 diarra sii  0 Jun  3 16:51 std.err
-rw-r--r--  1 diarra sii 12 Jun  3 16:51 std.out

Tuer un job

[diarra@ipngrid01 ~/work]$ glite-wms-job-cancel <jobID> ou glite-wms-job-cancel -i <jobIdFile>

Exemple:

[diarra@ipngrid01 ~/work]$ glite-wms-job-cancel https://grid02.lal.in2p3.fr:9000/Rw0lve7pSId8-DBP2jiatw

Obtenir des détails (logging information) sur un job

Pour avoir des détails sur la vie d'un job, utiliser la commande glite-wms-job-logging-info <jobID> . Pour un mode plus verbeux, utiliser les option -v 1 ou -v 2 ou -v 3

[diarra@ipngrid01 ~/work]$ glite-wms-job-logging-info -v 2 https://grid02.lal.in2p3.fr:9000/1TEI3X2ZtLJ5SEyqrZ4B8A

Collection de jobs (bulk submission)

Vous pouvez utiliser le bulk submission pour soumettre une collections de jobs indépendants. Pour cela, il faut mettre tous les .jdl dans un même directory et utiliser l'option --collection avec glite-wms-job-submit. Ce mécanisme est très performant et préférable à la soumission individuel d'un grand nombre de jobs.

Ici nous avons par exemple trois fichiers .jdl dans le directory jdl :

[diarra@ipnlinux2 ~/work]$ ls -l jdl/*
-rw-r--r--  1 diarra sii 247 Jun  3 17:25 jdl/job1.jdl
-rw-r--r--  1 diarra sii 247 Jun  3 17:25 jdl/job2.jdl
-rw-r--r--  1 diarra sii 247 Jun  3 17:25 jdl/job3.jdl

Pour soumettre la collection des 3 jobs, faire :

[diarra@ipngrid01 ~/work]$ glite-wms-job-submit -a --collection jdl

Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
====================== glite-wms-job-submit Success ======================
The job has been successfully submitted to the WMProxy
Your job identifier is:
https://grid02.lal.in2p3.fr:9000/6zqZkrgnQ2vYkPaeNabbiQ
==========================================================================

Je jobId affiché est l'identifiant de la collection (<collID>). Il faut utiliser <collID> pour pouvoir connaitre l'état individuel des jobs ainsi que les vrais jobIDs.

diarra@ipngrid01 ~/work]$ glite-wms-job-status https://grid02.lal.in2p3.fr:9000/6zqZkrgnQ2vYkPaeNabbiQ


*************************************************************
BOOKKEEPING INFORMATION:

Status info for the Job : https://grid02.lal.in2p3.fr:9000/6zqZkrgnQ2vYkPaeNabbiQ
Current Status:     Running
Submitted:          Tue Jun  3 17:25:54 2008 CEST
*************************************************************

- Nodes information for:
    Status info for the Job : https://grid02.lal.in2p3.fr:9000/-nUgO-prNqqBNn1JL5i-uA
    Current Status:     Running
    Status Reason:      Job successfully submitted to Globus
    Destination:        ipnls2001.in2p3.fr:2119/jobmanager-pbs-ipno
    Submitted:          Tue Jun  3 17:25:54 2008 CEST
*************************************************************
    Status info for the Job : https://grid02.lal.in2p3.fr:9000/0Zits9wf2vkNLmk2eVUaMg
    Current Status:     Running
    Status Reason:      Job successfully submitted to Globus
    Destination:        ipnls2001.in2p3.fr:2119/jobmanager-pbs-ipno
    Submitted:          Tue Jun  3 17:25:54 2008 CEST
*************************************************************
    Status info for the Job : https://grid02.lal.in2p3.fr:9000/74kheBpT3e3qV-vq7dkG1A
    Current Status:     Running
    Status Reason:      Job successfully submitted to Globus
    Destination:        ipnls2001.in2p3.fr:2119/jobmanager-pbs-ipno
    Submitted:          Tue Jun  3 17:25:54 2008 CEST
*************************************************************

La commande glite-wms-job-output sur la <collID>, permet d'obtenir les sorties des jobs qui se sont terminés sans erreur. Les sorties sont rangées dans un sous-directory par job.

[diarra@ipngrid01 ~/work]$ glite-wms-job-output  https://grid02.lal.in2p3.fr:9000/6zqZkrgnQ2vYkPaeNabbiQ

Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
================================================================================
                        JOB GET OUTPUT OUTCOME
Output sandbox files for the DAG/Collection :
https://grid02.lal.in2p3.fr:9000/6zqZkrgnQ2vYkPaeNabbiQ
have been successfully retrieved and stored in the directory:
/home/diarra/JobOutput/diarra_6zqZkrgnQ2vYkPaeNabbiQ
================================================================================

Les résultats ont été enregistrés dans /home/diarra/JobOutput/diarra_6zqZkrgnQ2vYkPaeNabbiQ. Nous y retrouvons les sorties de chaque job dans un directory différent :

[diarra@ipngrid01 ~/work]$ ls /home/diarra/JobOutput/diarra_6zqZkrgnQ2vYkPaeNabbiQ
ids_nodes.map  Node_job1_jdl  Node_job2_jdl  Node_job3_jdl

[diarra@ipngrid01 ~/work]$ ls /home/diarra/JobOutput/diarra_6zqZkrgnQ2vYkPaeNabbiQ/Node_job1_jdl/
std.err  std.out

Le fichier ids_nodes.map indique quel sous-directory est utilisé pour chaque jobId.

Les commandes glite-wms-job-cancel et glite-wms-job-logging-info s'appliquent également sur les collections.

Examen en temps réel des fichiers de sortie : Job Perusal

Avec le gLite WMS, on peut voir les fichiers produits par un job pendant qu'il est encore en exécution. C'est la fonctionnalité Job Perusal. Avec le RB il fallait attendre que le job soit terminé.

Pour activer le Job Perusal pour un job, il faut mettre les deux lignes suivantes dans le .jdl :

PerusalFileEnable = true;
PerusalTimeInterval = 120;

La valeur fournie à PerusalTimeInterval est en secondes. C'est l'intervalle entre deux uploads des fichiers sur le WMS par le WN. Eviter de mettre des valeurs trop petites. Mettre plutôt plusieurs minutes. Pour des jobs courts, cen'est pas la peine d'utiliser cette fonctionnalité sauf pour debugger des problèmes de plantage de job. De facçon générale, ne pas abuser de cette fonctionnalité car elle est augmente la charge du WMS.

Dans l'exemple ci-dessous nous allons lancer le job perusal.jdl et récupérer des fichiers pendant que le job tourne. Il y a un upload toutes les 2 minutes (120 secondes) du WN vers le WMS.

diarra@ipnlinux2 ~/work]$ cat perusal.jdl
Executable    = "perusal.sh";
Arguments     = "10";
StdOutput     = "std.out";
StdError      = "std.err";
InputSandbox = {"perusal.sh"};
OutputSandbox = {"std.out","std.err", "perusal.log"};
PerusalFileEnable = true;
PerusalTimeInterval = 120;
#Requirements = RegExp("ipnls2001.*\.fr:2119/jobmanager.*ipno$", other.GlueCEUniqueID);

N.B.: on peut utiliser l'attribut PerusalFilesDestURI dans le .jdl pour demander l'upload vers un serveur GridFTP plus que que vers le WMS.

La soumission :

[diarra@ipngrid01 ~/work]$ glite-wms-job-submit -o pjid -a perusal.jdl
https://grid02.lal.in2p3.fr:9000/1nX3gfh6Ba9NLtxy5FKe2g
The job identifier has been saved in the following file:
/home/diarra/work/pjid

On indique au WMS avec la commande 'glite-wms-job-perusal --set -f ... jodID', la liste des fichiers qu'on veut inspecter (ici std.err, std.out, perusal.log) :

[diarra@ipngrid01 ~/work]$ glite-wms-job-perusal --set -f std.err -f std.out -f perusal.log -i pjid
Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
====================== glite-wms-job-perusal Success ======================
Files perusal has been successfully enabled for the job:
https://grid02.lal.in2p3.fr:9000/1nX3gfh6Ba9NLtxy5FKe2g
==========================================================================

On récupère par exemple le fichier perusal.log :

[diarra@ipngrid01 ~/work]$ glite-wms-job-perusal --get --nodisplay -f perusal.log -i pjid

Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server

====================== glite-wms-job-perusal Success ======================

The retrieved files have been successfully stored in:
/home/diarra/JobOutput/diarra_1nX3gfh6Ba9NLtxy5FKe2g

==========================================================================

Ici, le fichier se trouvera dans /home/diarra/JobOutput/diarra_1nX3gfh6Ba9NLtxy5FKe2g . Le nom du fichier contient en plus la fenêtre de temps couverte. A chaque récupération, un nouveau fichier est créé. Après plusieurs inspections des fichiers, on a par exemple :

[diarra@ipngrid01 ~/work]$ ls -l /home/diarra/JobOutput/diarra_1nX3gfh6Ba9NLtxy5FKe2g
total 6900
-rw-r--r--  1 diarra sii 1689998 Jun  5 11:34 perusal.log-20080605094053_1-20080605100318_12
-rw-r--r--  1 diarra sii 5207599 Jun  5 11:34 perusal.log-20080605100520_13-20080605111856_49
-rw-r--r--  1 diarra sii     213 Jun  5 09:41 std.err-20080605094051_1-20080605094051_1
-rw-r--r--  1 diarra sii    6887 Jun  6 10:41 std.err-20080605094254_2-20080605111855_49
-rw-r--r--  1 diarra sii   21097 Jun  5 09:56 std.out-20080605094052_1-20080605095508_8
-rw-r--r--  1 diarra sii  103003 Jun  6 10:42 std.out-20080605095710_9-20080605111856_49

Si l'option --nodisplay n'est pas utilisé, le fichier sera en plus affiché à l'écran (pas toujours commode). Par ailleurs à chaque récupération, seule le delta depuis le dernier upload est transmis. Pour récupérer à chaque fois l'intégralité du fichier, utiliser l'option --all de glite-wms-job-perusal.

L'option --unset de glite-wms-job-perusal permet de desactiver le Job Perusal :

[diarra@ipngrid01 ~/work]$ glite-wms-job-perusal --unset -i pjid

Reading the jobId from the input file: /home/diarra/work/pjid
Connecting to the service https://grid09.lal.in2p3.fr:7443/glite_wms_wmproxy_server
====================== glite-wms-job-perusal Success ======================
File(s) perusal has been successfully disabled for the job:
https://grid02.lal.in2p3.fr:9000/1nX3gfh6Ba9NLtxy5FKe2g
==========================================================================

Le renouvellement automatique de proxy

Pour des raisons de sécurité, il est recommandé de ne pas crée des proxies de plusieurs jours. Par ailleurs la durée de l'extension VOMS du proxy est limitée par les VOs, en général à 24h. Si un job dure plus longtemps que la validitée du proxy associé, il peut échouer ('Aborted' avec la raison 'the userproxy expired' ).

Le serveur proxy permet d'enregistrer son proxy pour une longue durée. Le proxy enregistré peut ensuite servir au WMS pour renouveler automatiquement le proxy des jobs.

Pour utiliser un service myproxy il faut :

Créer un proxy VOMS et l'enregistrer pour plusieurs jours ou semaines dans le serveur myproxy (myproxy.grif.fr pour GRIF)
Déclarer le serveur myproxy dans le .jdl. Par exemple mettre la ligne suivante dans le .jdl

MyProxyServer = "myproxy.grif.fr";

Avant d'enregistrer son proxy, en crér un valide :

[diarra@ipngrid01 work]$ voms-proxy-init --voms vo.ipno.in2p3.fr --valid 24:00

Pour supprimer un ancien proxy déjà enregistré dans le serveur myproxy :

[diarra@ipngrid01 work]$ myproxy-destroy -s myproxy.grif.fr -d

Pour enregistrer son proxy dans le serveir myprosy :

[diarra@ipngrid01 work]$ myproxy-init -s myproxy.grif.fr -d -n -t 24 -c 800

Les options :

-d : Le DN sera utilisé par défaut comme le username
-n : On peut récupérer le proxy sans donner de mot de passe
-t : Validité (lifetime) en heures du proxy récupéré (délégué). La valeur par défaut est 12h.
-c : Validité (lifetime) en heures du proxy sur le serveur myproxy. La valeur par defaut est 1 semaine.

On vérifie avec myproxy-info :

[diarra@ipngrid01 work]$ myproxy-info -s myproxy.grif.fr -d
username: /O=GRID-FR/C=FR/O=CNRS/OU=IPNO/CN=Christophe Diarra
owner: /O=GRID-FR/C=FR/O=CNRS/OU=IPNO/CN=Christophe Diarra
  timeleft: 799:58:55  (33.3 days)

Ensuite il suffit de soumettre un job avec un proxy VOMS valide. Même si le job dure plusieurs jours, son proxy n'expirera pas. Bien sûr il faut que le temps d'exécution job n'excède la durée de vie totale du proxy enregistré sur le serveur myproxy.

Ressoumission automatique

Le WMS peut resoumettre automatiquement les jobs s'ils sont 'aborted' par la grille. Deux types de ressoumission sont disponibles en gLite 3.1 WMS:

deep resubmission : pour les jobs échouent qui après démarrage sur un WN
shallow resubmission : dans les autres cas

Les attributes RetryCount et ShallowRetryCount permettent de limiter le nombre de tentatives de ressoumission des jobs, respectivement pour les modes deep et shallow. Une valeur à zéro (0) dévalide la resoumission.

Il est recommandé dévalider le deep resubmission car le WMS peut resoumettre unjob qu'il croit (à tort) aborted ou bien un job qui a échoué peut déjà avoir effectué un certains nombre d'opérations incompatibles avec un deuxième lancement. Par contre il est recommandé d'utiliser shallow resubmission pour donner plus de chance à votre job d'être soumis.

Dans l'exemple ci-dessous, on devalide le deep resubmission et on limite les tentatives de shallow resubmission à 3:

RetryCount = 0; ShallowRetryCount = 3;

Références utiles

Consulter les documents ci-dessous pour plus d'informations. Vous pourrez apprendre par exemple dans le 1er document (comment gLite 3.1 User Guide) :

utiliser GridFTP pour le transfert des SandBox
utiliser les DAG (direct acyclic graphs) : jobs dépendants
utiliser les Parametric jobs : collection de josb identiques sauf pour un parametre d'exécution.

gLite 3.1 User Guide: https://edms.cern.ch/file/722398/1.2/gLite-3-UserGuide.html

Submission and monitoring of jobs via WMProxy using the command line interface: http://wiki.egee-see.org/index.php/SG_Running_Jobs_WMProxy_CLI

Tutorial: Submitting jobs : http://www-numi.fnal.gov/offline_software/srt_public_context/GridTools/docs/jobs_tutorial.html#submitting_jobs

Download in other formats:

Plain Text

Context Navigation

Soumission des Jobs

TracNav

Tutoriel

FAQ...

Software des VOs...

Utilisation de la grille...

Table of Contents

Premiers pas…

Principales Commandes

Soumission d'un Job "Hello World"

Description des Jobs (JDL)

Modification et Edition

Requirements et Rank

L'environnent d'exécution sur le Worker Node

Renouveler le proxy en cours de job

Soumission d'un job MPI

Soumission de jobs via le WMS

Introduction

Soumission d'un job

La delegation automatique de proxy au WMSProxy

La délégation explicite de proxy au WMSProxy

Status des jobs / Récupération des outputs (OutpuSandbox)

Tuer un job

Obtenir des détails (logging information) sur un job

Collection de jobs (bulk submission)

Examen en temps réel des fichiers de sortie : Job Perusal

Le renouvellement automatique de proxy

Ressoumission automatique

Références utiles

Download in other formats: