Jobs avancés

De MaGridWiki
Aller à : Navigation, rechercher

Sommaire

Utilisation des SE dans les jobs

Il est souvent nécessaire de fournir un volume de données important en entrée ou de collecter un volume de données important en sortie d'un job.

Comme la taille de l'InputSandbox et de l'OutputSandbox est limitée, il est nécessaire d'utiliser les SE pour stocker les données en entrée ou en sortie de ces jobs. Les jobs exécutés sur la grille consistent le plus souvent en des scripts qui réalisent tout un ensemble de taches et ne se contente pas d'exécuter un code.

Par la suite un exemple qui va copier des données depuis un SE vers le CE sur lequel il s'exécute, va lancer un l'exécution d'un code, puis va copier les résultats de cette exécution depuis le CE vers un SE.

Il suffit ensuite de copier les résultats des SE vers l'UI pour pouvoir en faire usage localement.

Les commandes de gestions des données présentées par ailleurs peuvent être utilisées de la même façon sur un CE et sur une UI.

Ce sont ces commandes que nous utilisons dans le script d'exemple suivant.

Fichier: tuto2.sh
#!/bin/sh
 
# Date / heure de debut
echo "Execution de tuto2.sh"
date
 
# Lecture des arguments
infile=$1
outfile=$2
 
# Definition de quelques variables d'environnement
VORG=magrid
export LFC_HOME=/grid/magrid/tutoriel/
 
 
# Recuperation de l'executable tuto2 compilé sur l'UI et placé sur un SE
# l'executable a ete placé sur le SE dans le repertroire LFC_HOME
# avant la soumission du job
echo "Copie de tuto2 depuis les SE"
lcg-cp --vo $VORG lfn:tuto2 file:tuto2
 
# Recuperation du fichier de donneés passé en argument (infile) sur le SE
# Le fichier a été placé sur le SE dans le repertroire LFC_HOME
# avant la soumission du job
echo "Copie de "$infile" depuis les SE vers le fichier file.dat"
lcg-cp --vo $VORG lfn:$infile file:input.dat
 
# Execution de tuto2 qui prend le fichier input.dat en entrée et produit le
# fichier output.dat en sortie
echo "Execution de tuto2"
# On s'assure que tuto2 est executable
chmod +x tuto2
./tuto2
 
# Si le fichier output.dat existe, donc si l'execution s'est bien passée, on
# le copie vers un SE
if [ -f output.dat ]; then
echo "Copie de output.dat vers "$outfile
lcg-cr --vo $VORG -l lfn:$outfile file:output.dat
fi
 
# Tout s'est termine correctement
echo "Fin de l'execution"
date

Ce script prend deux paramètres en entrée, le nom du fichier de données situé sur un SE et le nom que l'on souhaite donner au fichier de sortie qui sera copié sur un SE. Ce script peut être lancé par le .jdl suivant :

Fichier: job.jdl
Type = "Job";
JobType = "Normal";
Executable = "tuto2.sh";
Arguments = "-i Test-grid.txt -o Tuto2-out.txt";
StdOutput = "std.out";
StdError = "std.err";
OutputSandbox = {"std.out", "std.err"};
InputSandbox = {"tuto2.sh"};
Requirements = other.GlueCEInfoHostName=="ce2.cnrst.magrid.ma";

On voit dans ce fichier .jdl une nouvelle option : Requirements.

Cette option permet de décrire des conditions que doit remplir l'élément de calcul sur lequel vous voulez que votre job soit exécuté. La seule condition décrite ici est simple : le CE doit avoir pour nom "ce2.cnrst.magrid.ma:8443/cream-pbs-magrid".

En d'autres termes, je souhaite que mon job soit exécuté sur le 2éme site de MaGrid.

Jobs longs et utilisation de MyProxy

Les proxys standards ne durent que 12h. Si un job n'est pas terminé au bout de ces 12h, alors il échoue.

Il existe un moyen de demander au proxy de se renouveler automatiquement pour permettre à un job de durer jusqu'à 7 jours.

Il faut pour cela demander un proxy longue durée. D'abord il faut avoir un proxy standard valide :

[ui2 ~]$voms-proxy-init --voms magrid

puis créer un proxy de longe durée à l'aide de la commande

[ui2 ~]$ myproxy-init -d -n -s myproxy.magrid.ma Your identity: /C=MA/O=MaGrid/OU=CNRST/CN=Abderrahman El kharrim Enter GRID pass phrase for this identity: Creating proxy .................................................................................. Done Proxy Verify OK Your proxy is valid until: Sat Nov 5 19:48:25 2011 A proxy valid for 168 hours (7.0 days) for user /C=MA/O=MaGrid/OU=CNRST/CN=Abderrahman El kharrim now exists on myproxy.magrid.ma.

L'existence d'un proxy longue durée permet au Workload Management System de demander automatiquement un renouvellement de votre proxy standard afin de permettre aux jobs en cours de se poursuivre.

L'option -d signifie que vous voulez associer l'identité inscrite dans votre certificat à ce proxy, l'option -n signifie que vous voulez pouvoir accéder à ce proxy longue durée sans passphrase (ce qui permet au WMS d'accéder au proxy longue durée) et l'option -s précise le serveur MyProxy sur lequel vous voulez stocker votre proxy longue durée.

Pour pouvoir initialiser un proxy longue durée, vous devez tout d'abord créer un proxy standard.

Pour qu'un job utilise ce proxy longue durée pour pouvoir s'exécuter pendant plus de 12h, vous devez ajouter une ligne à votre fichier .jdl :

Fichier: joblong.jdl
[
Type = "Job";
JobType = "Normal";
Executable = "tuto2.sh";
Arguments = "-i Test-grid.txt -o Tuto2-out.txt";
StdOutput = "std.out";
StdError = "std.err";
OutputSandbox = {"std.out", "std.err"};
InputSandbox = {"tuto2.sh"};
Requirements = other.GlueCEInfoHostName=="ce2.cnrst.magrid.ma";
MyProxyServer = "myproxy.magrid.ma";
]

Pour obtenir des informations sur votre proxy longue durée, vous devez utiliser la commande

[ui2 ~]$ myproxy-info -d -s myproxy.magrid.ma username: /C=MA/O=MaGrid/OU=CNRST/CN=Abderrahman El kharrim owner: /C=MA/O=MaGrid/OU=CNRST/CN=Abderrahman El kharrim timeleft: 167:36:40 (7.0 days)

Vous pouvez détruire ce proxy longue durée avec la commande

[ui2 ~]$ myproxy-destroy -d -s myproxy.magrid.ma Default MyProxy credential for user /C=MA/O=MaGrid/OU=CNRST/CN=Abderrahman El kharrim was successfully removed.

Jobs paramétriques

La réalisation d'études paramétriques est particulièrement adaptée à l'architecture distribuée de la grille. Il existe une classe de jobs spéciale pour lancer un job paramétrique extrêmement simplement.

Exécuter un job paramétrique consiste à exécuter N jobs différant seulement par la valeur d'un paramètre _PARAM_ dont on peut préciser les valeurs.

Voici un exemple de script permettant de soumettre un job paramétrique simple :


Ce .jdl permet de lancer l'exécution de la commande /bin/echo avec comme argument la chaîne de caractères "Bonjour du job _PARAM_ !" où _PARAM_ prend toutes les valeurs entre "ParameterStart" (= 1) et Parameters (= 11) non compris par incrément de ParameterStep (= 1). Dans ce cas précis, _PARAM_ prend donc toutes les valeurs entières entre 1 compris et 10 compris.

Les valeurs de _PARAM_ peuvent également être choisies dans une liste donnée en valeur de Parameters :

Parameters = { 1, 2, 3 } ;

Fichier: jobparam.jdl
[
Type = "Job";
JobType = "Parametric";
Executable = "/bin/echo";
Arguments = "Bonjour du job _PARAM_ !";
Parameters = 101;
ParameterStart = 1;
ParameterStep = 1;
StdOutput = "std.out";
StdError = "std.err";
OutputSandbox = {"std.out", "std.err"};
InputSandbox = {};
]

La soumission de ce .jdl se déroule de la même façon que celle d'un job simple

[ui2 ~]$ glite-wms-job-submit -a -o idparam param.jdl Connecting to the service https://wms.magrid.ma:7443/glite_wms_wmproxy_server ====================== glite-wms-job-submit Success ====================== The job has been successfully submitted to the WMProxy Your job identifier is: https://wms.magrid.ma:9000/6XhstLuxZz5d2lE5oboXKQ The job identifier has been saved in the following file: /home/elkharrim/idparam ==========================================================================

L'utilisation de la commande glite-wms-job-status donne lieu quant à elle à un affichage qui peut rapidement devenir peu lisible dans les cas où le paramètre prend un grand nombre de valeurs (ne sont présentées ici que les affichages correspondant aux 5 premiers jobs du job paramétrique) :

[ui2 ~]$ glite-wms-job-status -i idparam ======================= glite-wms-job-status Success ===================== BOOKKEEPING INFORMATION: Status info for the Job : https://wms.magrid.ma:9000/Qkv7-v9s_Dm7Kb3i4S1RyA Current Status: Running Submitted: Sat Oct 29 20:21:33 2011 WET ========================================================================== - Nodes information for: Status info for the Job : https://wms.magrid.ma:9000/0AA0eMWsBSzWJnsUXntX3A Current Status: Ready Destination: ce2.cnrst.magrid.ma:8443/cream-pbs-magrid Submitted: Sat Oct 29 20:21:33 2011 WET ========================================================================== Status info for the Job : https://wms.magrid.ma:9000/55PxMeYcWgjsF06mddQtug Current Status: Running Status Reason: unavailable Destination: ce2.cnrst.magrid.ma:8443/cream-pbs-magrid Submitted: Sat Oct 29 20:21:33 2011 WET ========================================================================== Status info for the Job : https://wms.magrid.ma:9000/9E4_eJbkvMbTAYSgjAFXvw Current Status: Scheduled Status Reason: unavailable Destination: ce2.cnrst.magrid.ma:8443/cream-pbs-magrid Submitted: Sat Oct 29 20:21:33 2011 WET ========================================================================== Status info for the Job : https://wms.magrid.ma:9000/ASPmeiU2kS9O1YZJcJOh3g Current Status: Scheduled Status Reason: unavailable Destination: ce1.cnrst.magrid.ma:8443/cream-pbs-magrid Submitted: Sat Oct 29 20:21:33 2011 WET ========================================================================== Status info for the Job : https://wms.magrid.ma:9000/Yfq9cA4-nRV957V9FlH69g Current Status: Scheduled Status Reason: unavailable Destination: ce3.cnrst.magrid.ma:8443/cream-pbs-magrid Submitted: Sat Oct 29 20:21:33 2011 WET ==========================================================================

La récupération des fichiers contenus dans la OutputSandbox se déroule de la même façon que pour un job normal.

Jobs avec perusal

Il est également possible de visualiser les fichiers de sortie durant l’exécution du job en utilisant la propriété: Persual.

Dans le fichier JDL ajouter les lignes:

Fichier: /jobperusal.jdl
[..]
# permettre à l'utilisateur de voir les fichier output durant l’exécution job
PerusalFileEnable = true;
# Le téléchargement du fichier output change chaque 1000 secs. C'est l'intervalle minimum toléré.
PerusalTimeInterval = 1000;

Ayant ajouté ces deux lignes, une fois le job est en état de Running, nous pouvons demander au WMS de commencer à récupérer le fichier de sortie en exécutant la commande suivante:

[ui2 ~]$ glite-wms-job-perusal --set -i jobId -f std.out Reading the jobId from the input file: /home/elkharrim/jobId Connecting to the service https://wms.magrid.ma:7443/glite_wms_wmproxy_server ====================== glite-wms-job-perusal Success ====================== File perusal has been successfully enabled for the job: https://wms.magrid.ma:9000/0AA0eMWsBSzWJnsUXntX3A ==========================================================================

Ensuite, nous pouvons émettre la commande --get pour obtenir la première copie complète (avec --all) du fichier.

[ui2 ~]$ glite-wms-job-perusal --get -i jobId -f std.out --all --dir . Reading the jobId from the input file: /home/elkharrim/jobId Connecting to the service https://wms.magrid.ma:7443/glite_wms_wmproxy_server ====================== glite-wms-job-perusal Success ====================== The retrieved files have been successfully stored in: /home/elkharrim ========================================================================== -------------------------------------------------------------------------- file 1/1: std.out-20111029021521_1-20111029021521_1


Pour actualiser le fichier téléchargé omettre le -all:

[ui2 ~]$ glite-wms-job-perusal --get -i jobId -f std.out --dir .

Si vous obtenez : "No files to be retrieved for the job:" ceci veut dire que le fichier n'a pas été mis à jour lors de la dernière exécution de --get.

Quand c'est fait, exécuter la commande de nettoyage:

[ui2 ~]$ glite-wms-job-perusal --unset -i jobId
Navigation
Administrateur
Utilisateur
Applications
Autorité de Certification