Modifié par Bouvet, le 26 Apr 2012

Soumission de jobs



  1. Créez un proxy à l'aide de la commande voms-proxy-init.

  2. Soumettez le job HelloWorld.jdl en utilisant la commande glite-wms-job-submit.
    Les commandes du « workload management » analysent les proxies VOMS et utilisent la VO indiquée par ces derniers. On peut aussi spécifier la VO avec l’option – vo.

Sauvegardez le jobID retourné ou utilisez l'option -o.

  1. 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).


  1. Lorsque le job est terminé, récupérez la sortie en utilisant glite-wms-job-output .

Si le job se termine dans l’état « Aborted », c’est qu’il ne passe pas. On peut alors trouver plus d’informations avec la commande glite-wms-job-logging-info .

  1. Vérifiez que tout s'est déroulé correctement en consultant les fichiers message.txt et stderror .
  1. 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 « Arguments » peut rester avec « Hello World »,
  • vous devez de plus définir le paramètre « InputSandbox » en ajoutant la ligne :

InputSandbox = {“HelloWorldScript.sh”};

  On peut utiliser n’importe quel script, cependant le  shell  utilisé par le script doit exister dans le WN.\\


  1. Modifiez 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 ».


Sur quel WN a tourné votre job ?

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

Votre job a-t-il tourné sur le même WN que précédemment ?

Il y a deux clés importantes dans les fichiers JDL : « Requirements » et « Rank ».
Les valeurs pour les clés Requirements et Rank sont des expressions.
Votre job va tourner uniquement sur une ressource qui a une valeur « true » pour l’expression Requirements . S’il y a plusieurs ressources qui ont une valeur « true », le système utilise l’expression Rank pour choisir la meilleure ressource.
La ressource qui a la plus grande valeur est choisie. S’il y a plusieurs ressources avec la même valeur Rank, la ressource utilisée est choisie aléatoirement entre ces ressources de même valeur Rank.

  1. Plusieurs valeurs peuvent être utilisées pour définir les expressions Requirements et Rank.

Par exemple, ajoutez l’expression ci-dessous dans le fichier HelloWorld.jdl pour choisir tous les sites qui permettent à un job d’utiliser plus d’une heure de temps CPU :

 Requirements    =  (other.GlueCEPolicyMaxCPUTime  > 60  );  \\


Pour voir la liste des ressources acceptables utilisez la commande glite-wms-job-list-match.
Combien de ressources autorisent les jobs de plus d’une heure de temps CPU ? Plus de 2 heures ? Plus de 10000 minutes ?

  1. Pour choisir des sites spécifiques, on peut utiliser le nom de la ressource. Pour choisir tous les sites en France, changez la valeur de Requirements comme suit :


 Requirement    s =   RegExp    (  “.*.  fr  :.*”,  other.GlueCEUniqueID  ) ;\\


Le premier argument est une expression régulière.
Modifiez la ligne Requirements pour choisir une ressource particulière. Trouvez la syntaxe correcte pour exclure un site.
Une option –r existe pour la commande glite-wms-job-submit qui permet de choisir une ressource spécifique. Cependant cette option évite tout le processus de MatchMaking du WMS et n’ajoute pas le fichier nécessaire ( .BrokerInfo ) pour la gestion des données. La technique avec other.GlueCEUniqueID est plus flexible et plus sûre.

  1. Ajoutez les lignes suivantes pour utiliser la ressource avec le plus grand nombre de CPU libres :


    Rank = other.GlueCEStateFreeCPUs;  \\


Utilisez la commande glite-wms-job-list-match pour visualiser le résultat. (L'ordre indique le Rank. La ressource la plus intéressante est la première)
Si on utilise la valeur -other.GlueCEStateFreeCPUs, quelle ressource le WMS va-t-il choisir ?
Que fait le WMS si on utilise la valeur rank = 1 ?

Chaque utilisateur de la grille est mappé dans 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.

  1. Visualisez le contenu du fichier JDL whoami.jdl. Lancez le job et récupérez la sortie. Visualisez le fichier std.out. Sur quel compte êtes-vous mappé ?


  1. Visualisez le contenu du script envvar.jdl. Soumettez un job qui lance ce script sur la grille. Regardez la liste des variables. Combien de variables concernent la grille ?


  1. Ecrivez un job qui liste les versions des logiciels disponibles dans le WN. On peut utiliser la commande rpm pour le faire.


  1. Initialisez un nouveau proxy en utilisant le rôle Tutorial1 ou Tutorial2, suivant celui que vous avez le droit d'utiliser, et reexécutez le fichier JDL whoami.jdl.

 Collection de jobs (bulk submission)

La bulk submission permet de soumettre une collection de jobs indépendants en une seule commande. Pour cela, il faut mettre tous les JDL dans un même répertoire (et uniquement des JDL) et utiliser l'option –collection avec glite-wms-job-submit en donnant comme argument le nom du répertoire contenant les JDL. Ce mécanisme est très performant et préférable à la soumission individuel d'un grand nombre de jobs.

Pour soumettre la collection de 3 jobs dans le sous-répertoire ./jdl, faire :

glite-wms-job-submit -a --collection jdl

Le jobID affiché est l'identifiant de la collection de job (collID). Comme pour un job seul, il faut utiliser cet identifiant pour connaître l'état des jobs ainsi que les jobID correspondants aux jobs de la collection.

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-répertoire par job.

Dans le répertoire contenant les logs des différents jobs, le fichier ids_nodes.map indique quel sous-répertoire est utilisé pour chaque jobID.

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

Les jobs paramétriques

Pour soumettre des jobs identiques en tous points sauf pour un seul paramètre d'exécution, on peut utiliser un job paramétrique : plutôt que de créer un JDL par job, on crée un seul fichier .jdl dont la soumission va générer automatiquement la collection de jobs. C'est une variante des collections de job décrites précédemment.

Les attribut JDL suivants sont utilisés pour définir un job paramétrique :

Parameters : une liste d'éléments (ex: {a, b, c}, {2, 7, 20}) ou un entier représentant la valeur maximale du paramètre ParameterStart : un entier représentant la valeur minimale du paramètre ParameterStep : un entier représentant l'incrément du paramètre

Si Parameters est un entier, le nombre de jobs générés est :

 N = (Parameters - ParameterStart) / ParameterStep

Pour que tous les jobs tournent sur le même CE, mettre la ligne suivante dans le .jdl :

NodesCollocation = true;

Exemple 1 :

Un programme exécuté avec 4 fichiers différents Input1.txt, Input2.txt, Input3.txt, Input4.txt.

Créez le script correspondant au programme :

~> cat ParametricNum.sh
#!/bin/sh
MyParam=$1
echo "Debut execution du programme"
echo "Parametre = ${MyParam}"
  • Créez le JDL suivant (_PARAM_ vaudra successivement 1, 2, 3 puis 4) :
~> cat ParametricNum.jdl
JobType = "Parametric";
Executable    = "ParametricNum.sh";
Arguments     = "_PARAM_";
StdOutput     = "std.out";
StdError      = "std.err";
InputSandbox = {"ParametricNum.sh", "Input_PARAM_.txt"};
OutputSandbox = {"std.out", "std.err", "Output_PARAM_.txt" };
MyProxyServer = "myproxy.cern.ch";
Parameters = 5;
ParameterStart = 1;
ParameterStep = 1;
#NodesCollocation = true;

Soumettez le job :

~> glite-wms-job-submit -a -o jid ParametricNum.jdl
  • Vérifiez le status du job et l'existence de 4 sous-jobs :
~> glite-wms-job-status -i jid

*************************************************************
BOOKKEEPING INFORMATION:
Status info for the Job : https://grid02.lal.in2p3.fr:9000/7X5T_8XEcxUjDeng1q92Wg
Current Status:     Running
Submitted:          Fri Jun  6 16:31:52 2008 CEST
*************************************************************
- Nodes information for:
    Status info for the Job : https://grid02.lal.in2p3.fr:9000/6zsSfE0nVOVyrWCQPga6fw
    Current Status:     Running
    Status Reason:      Job successfully submitted to Globus
    Destination:        ipngrid12.in2p3.fr:2119/jobmanager-pbs-ipno
    Submitted:          Fri Jun  6 16:31:52 2008 CEST
*************************************************************
    Status info for the Job : https://grid02.lal.in2p3.fr:9000/DFqOECrwMEWmmpZs65oG3Q
    Current Status:     Running
    Status Reason:      Job successfully submitted to Globus
    Destination:        ipngrid12.in2p3.fr:2119/jobmanager-pbs-ipno
    Submitted:          Fri Jun  6 16:31:52 2008 CEST
*************************************************************
    Status info for the Job : https://grid02.lal.in2p3.fr:9000/Ez2DyOUSDxCof9Sh0pQPog
    Current Status:     Running
    Status Reason:      Job successfully submitted to Globus
    Destination:        ipngrid12.in2p3.fr:2119/jobmanager-pbs-ipno
    Submitted:          Fri Jun  6 16:31:52 2008 CEST
*************************************************************
    Status info for the Job : https://grid02.lal.in2p3.fr:9000/FxUda1Mz5DyB7SglhMDBEw
    Current Status:     Scheduled
    Status Reason:      Job successfully submitted to Globus
   Destination:        ipngrid12.in2p3.fr:2119/jobmanager-pbs-ipno
    Submitted:          Fri Jun  6 16:31:52 2008 CEST
*************************************************************

Quand le statut de la collection de jobs est Done, récupérez l'output des différents jobs en utilisant la procédure habituelle. Comme dans toutes les collections de job, il y a un répertoire par sous-job et le fichier ids_nodes.map indique le nom du répertoire associé à chaque sous-job :

~> glite-wms-job-output  -i jid

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/7X5T_8XEcxUjDeng1q92Wg
have been successfully retrieved and stored in the directory:
/tmp/JobOutput/tuto_7X5T_8XEcxUjDeng1q92Wg
================================================================================
  • Visualisez l'output du 3ème job et vérifier qu'il a bien reçu la valeur 3 en paramètre :
~> cat /tmp/JobOutput/tuto_7X5T_8XEcxUjDeng1q92Wg/Node_3/std.out
Debut execution du programme
Parametre = 3

Exemple 2 :

Un programme de simulation my_sim.exe doit faire trois simulations alpha, beta et gamma. Dans ce cas on n'utilise que l'attribut Parameters et le JDL sera :

JobType = "Parametric";
Executable = "my_sim.exe";
Arguments = "_PARAM_";
Parameters = {alpha, beta, gamma};
InputSandbox = {"my_sim.exe", ...};
...

Note : il ne faut pas mettre de “” autour des éléments contenus dans Parameters.





Utilisation du paramètre "requirements" dans le JDL

Pour spécifier dans le JDL un site particulier pour la soumission :

Requirements = other.GlueCEUniqueID=="<CEHostname>:2119/<QueueName>"

Soumission d'un job en ligne de commande

$ glite-wms-job-submit --vo <voname> -a <file.jdl>

Si la soumission se passe bien, la sortie doit ressembler à :

Selected Virtual Organisation name (from --vo option): gilda
Connecting to host grid004.ct.infn.it, port 7772
Logging to host grid004.ct.infn.it, port 9002 
********************************************************************************
                               JOB SUBMIT OUTCOME
 The job has been successfully submitted to the Network Server.
 Use edg-job-status command to check job current status. Your job identifier (edg_jobId) is: 

 - https://grid004.ct.infn.it:9000/ybnyOZ9O-5A-kanmY2zyEA  

********************************************************************************

Récupération du statut d'un job

$ glite-wms-job-status <jobID>

Selon le statut du job, la sortie doit ressembler à :

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

Status info for the Job : https://grid004.ct.infn.it:9000/ybnyOZ9O-5A-kanmY2zyEA
Current Status:     Submitted 
reached on:         Thu Nov  4 08:19:36 2004
********************************************************************************

Récupération de la sortie d'un job

$ glite-wms-job-output <jobID>

Liste des sites sur lesquels un job peut être soumis

$ glite-wms-job-list-match --vo vo.formation.in2p3.fr -a <file.jdl>
  • soumission_de_jobs.txt
  • Dernière modification: 2018/08/30 16:37
  • par David BOUVET