1. Introduction

L'intergiciel (middleware) utilisé par la Grille Régionale de Calcul Strasbourg Grand-Est est gLite. Le rôle de cet intergiciel est de faciliter l'utilisation de ressources informatiques (calcul et stockage) distribuées géographiquement. La soumission d'un calcul sur une grille utilisant cet intergiciel nécessite l'utilisation de logiciels spécifiques, fournit par l'interface utilisateur gLite.

Ce document détaille l'utilisation de l'interface utilisateur gLite pour la soumission, le suivi et la récupération des résultats d'un calcul.

2. Les services de grille utilisés

Cette section présente les différents services utilisés lors de la soumission d'une tâche sur la grille de calcul. La figure 1 présente une vue schématique de ces services ainsi que leurs interactions. Les acronymes sont expliqués dans le tableau 1.

L'utilisateur gère les calculs depuis l'interface utilisateur gLite (UI). Avant de soumettre le calcul au WMS, il peut copier des données sur le SE (voir section Section 5, « Gestion des données sur un SE »). Ces données seront accessibles depuis les noeuds de calcul. Une fois le calcul transféré sur le WMS, ce service décide du site devant effectuer les calculs. Pour effectuer ce choix, il se base sur la disponibilité du site et le respect des pré-requis du calcul explicitées par l'utilisateur[1]. Une fois qu'un site est sélectionné, le WMS soumet le calcul au CE de ce site. Le CE distribue les calculs sur les noeuds de calcul (WN) et collecte les résultats qui sont ensuite transférés sur le WMS. Durant ce temps, l'utilisateur peut interroger le WMS pour connaître l'état du déroulement de son calcul. Enfin, les résultats sont disponibles et peuvent être récupérés sur le WMS et/ou sur les SE.

Figure 1. Les différents services gLite utilisés lors de la soumission d'un calcul.

Gestion des calculs avec gLite

Tableau 1. Les services utilisés lors de la soumission d'un calcul

ÉlémentRôle
UI L'UI (User Interface) est l'interface utilisateur gLite. Il s'agit de l'ordinateur à partir duquel l'utilisateur va soumettre des calculs sur la grille. A travers cette interface, l'utilisateur interagit principalement avec le WMS pour la soumission des calculs et avec le SE pour le transfert des données volumineuses. Cette interface permet de :
  • gérer un calcul (soumission, suivi de l'état, annulation) ;

  • récupérer les résultats d'un calcul ;

  • copier, répliquer ou supprimer des données sur la grille.

SE Le SE (Storage Element) est l'élément d'une grille gérant le stockage. Il permet de récupérer les résultats des calculs ou bien de fournir au calcul des fichiers de données volumineux. Il est accessible via différents protocoles.
WMS Le WMS (Workload Manager) est le serveur avec lequel interagit l'utilisateur lors de la soumission, le suivi et la récupération des résultats d'un calcul. Le serveur choisit le noeud de grille correspond au pré-requis du calcul et donc à même à faire fonctionner le calcul. Il interagit principalement avec le CE pour la soumission des calculs, le transfert des sandbox et le suivi de l'état d'un calcul.
CE Le CE (Computing Element) est le serveur interagissant directement avec le gestionnaire de queues. Dans le cas de la grille régionale, le service PBS/Torque est utilisé.
WN Le WN (Worker Node) est le serveur effectuant le calcul. Il se connecte au SE pour récupérer les données nécessaires au calcul. Il peut également copier les résultats du calcul sur le SE.

 

 

3. Pré-requis à l'utilisation de la grille

Afin de pouvoir soumettre un calcul, les deux pré-requis suivants sont nécessaires :

La partie privée et la partie publique du certificat doivent être placées dans le répertoire $HOME/.globus sur le serveur à partir duquel les calculs seront soumis. Ces fichiers ne doivent être lisible que par leur propriétaire :

# ls -l $HOME/.globus
-r-------- 1 user group 1935 Feb 16 2010 usercert.pem
-r-------- 1 user group 1920 Feb 16 2010 userkey.pem

4. Gestion d'un calcul

Avant toute opération sur la grille régionale, il est nécessaire d'avoir un proxy valide. Il peut être généré avec la commande suivante :

# voms-proxy-init --voms vo.grand-est.fr

La commande voms-proxy-info -all permet de vérifier la durée de validité de son proxy :

# voms-proxy-info --all
subject : /O=GRID-FR/C=FR/O=CNRS/OU=UDS/CN=Prenom Nom/CN=proxy
issuer : /O=GRID-FR/C=FR/O=CNRS/OU=UDS/CN=Prenom Nom
identity : /O=GRID-FR/C=FR/O=CNRS/OU=UDS/CN=Prenom Nom
type : proxy
strength : 1024 bits
path : /tmp/x509up_u1234
timeleft : 11:59:36
=== VO vo.grand-est.fr extension information ===
VO : vo.grand-est.fr
subject : /O=GRID-FR/C=FR/O=CNRS/OU=UDS/CN=Prenom Nom
issuer : /O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=grid12.lal.in2p3.fr
attribute : /vo.grand-est.fr/Role=NULL/Capability=NULL
timeleft : 11:59:36
uri : grid12.lal.in2p3.fr:20018

4.1. Soumission d'un calcul

La soumission d'un calcul sur la grille régionale, ainsi que sur toute grille équipée avec l'intergiciel gLite, nécessite un fichier texte contenant des instructions au format JDL (Job Description Language). Ce type de fichier détaille les caractéristiques du calcul ainsi que ses besoins. Le fichier JDL présenté dans l'exemple 1 est fonctionnel et utilisable pour la réalisation d'un calcul simple.

Exemple 1. Contenu du fichier my.jdl

JobType = "Normal";
Executable = "/bin/sh";
Arguments = "myscript.sh";
StdOutput = "stdout.out";
StdError = "stderr.err";
InputSandbox = { "myscript.sh" };
OutputSandbox = { "stdout.out", "stderr.err" };
VirtualOrganisation = "vo.grand-est.fr";

 

Chaque attribut du fichier JDL exemple a un rôle bien précis :

  • JobType décrit le type de tâche réalisé (Normal, Collection ou Parametric).

  • Executable définit la commande à exécuter sur les noeuds de calcul.

  • Arguments spécifie les arguments à passer au programme définit par l'attribut Executable. Le contenu du script myscript.sh est ce que vous auriez tapé en interactif pour effectuer votre calcul.

  • StdOutput indique le nom du fichier vers lequel est redirigé la sortie standard

  • StdError indique le nom du fichier vers lequel est redirigé les messages d'erreur

  • InputSandbox indique les fichiers qui seront envoyés avec le fichier JDL au WMS. Ces fichiers seront utilisables par le serveur (WN) exécutant le calcul. Il est important de noter que la taille totale de l'InputSandbox est limitée. Ainsi, si la taille de l'ensemble des fichiers à envoyer devait dépasser 20 Mo, il est nécessaire d'utiliser un SE, ou de pré-installer les logiciels nécessaires au calcul.[2].

  • OutputSandbox indique les fichiers que nous souhaitons récupérer après l'exécution du calcul. Par défaut, il est conseillé de récupérer les fichiers stdout.out et stderr.err qui contiennent les sorties standard et erreur. Ces fichiers seront téléchargés depuis le WMS. De même que pour l'InputSandbox, le volume retourné ne doit pas dépasser 20 Mo. Si la taille totale des fichiers de l'OutputSanbox dépasse cette valeur, il est nécessaire de copier les fichiers de sortie (résultats, journaux du calcul) sur un SE puis de les récupérer par la suite, pour éviter leur troncation.

  • VirtualOrganization renseigne sur la VO dans laquelle va être effectué le calcul. Dans le cas de la grille régionale, il s'agit de vo.grand-est.fr.

Exemple 2. Contenu du fichier myscript.sh

#!/bin/sh

echo "===== Begin ====="
date
echo "The program is running on $HOSTNAME"
date
echo "===== End ====="

 

Une fois que les fichiers my.jdl et myscript.sh sont créés, le calcul peut être soumis sur la grille avec la commande suivante :

# glite-wms-job-submit -a my.jdl

Connecting to the service https://sbgwms1.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://sbgwms1.in2p3.fr:9000/aTErUbHR8adHN9e8Pi7tug

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


Il est important de conserver l'identifiant de la tâche https://sbgwms1.in2p3.fr:9000/aTErUbHR8adHN9e8Pi7tug. En effet, cet identifiant est utilisé pour suivre les différentes étapes d'une tâche, ainsi que pour récupérer l'OutputSandbox.

Note

L'utilisation de l'option -e permet de spécifier le serveur WMS sur lequel va être soumis le calcul :

# glite-wms-job-submit -e https://sbgwms3.in2p3.fr:7443/glite_wms_wmproxy_server -a my.jdl

4.2. Suivi de l'état d'un calcul

Pour connaître l'état d'un calcul, la commande suivante est utilisée avec l'identifiant du calcul :

# glite-wms-job-status https://sbgwms1.in2p3.fr:9000/aTErUbHR8adHN9e8Pi7tug


======================= glite-wms-job-status Success =====================
BOOKKEEPING INFORMATION:

Status info for the Job : https://sbgwms1.in2p3.fr:9000/aTErUbHR8adHN9e8Pi7tug
Current Status: Ready
==========================================================================

Une fois que le calcul est terminé, la commande précédente indique :

# glite-wms-job-status https://sbgwms1.in2p3.fr:9000/aTErUbHR8adHN9e8Pi7tug


======================= glite-wms-job-status Success =====================
BOOKKEEPING INFORMATION:

Status info for the Job : https://sbgwms1.in2p3.fr:9000/aTErUbHR8adHN9e8Pi7tug
Current Status: Done (Success)
==========================================================================

4.3. Récupération des résultats d'un calcul

Pour récupérer le contenu décrit par le paramètre OutputSandbox :

# glite-wms-job-output --dir JobOutput https://sbgwms1.in2p3.fr:9000/aTErUbHR8adHN9e8Pi7tug

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


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

JOB GET OUTPUT OUTCOME

Output sandbox files for the job:
https://sbgwms1.in2p3.fr:9000/aTErUbHR8adHN9e8Pi7tug
have been successfully retrieved and stored in the directory:
/home/user/JobOutput/user_aTErUbHR8adHN9e8Pi7tug

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


Le rapatriement des fichiers de sortie peut être vérifié avec :

# ls -rtl
/home/user/JobOutput/user_aTErUbHR8adHN9e8Pi7tug

-rw-r--r-- 1 user group 13 Oct 28 09:30 stdout.out
-rw-r--r-- 1 user group 0 Oct 28 09:30 stderr.err

5. Gestion des données sur un SE

5.1. Généralités

Les SE sont des points d'entrées vers des dispositifs de stockages accessibles depuis une UI ou un WN. Ils permettent de stocker des volumes de données importants (jusqu'à plusieurs dizaines de To). Si les tâches peu consommatrices d'espace disque peuvent ne pas en faire usage, dès que les données mobilisées en entrée ou en sortie dépassent la dizaine de Mo, ils sont indispensables.

Les données stockées sur un SE sont accessibles en utilisant des commandes spécifiques, telles que lcg-cp ou rfcp. De manière générale, il est plus efficace de faire appel au protocole RFIO (rfcp, rfdir, ...) lorsque le stockage local est adressé (par exemple, lorsque des données produites sur les WN de l'IPHC doivent être copiées sur le site de l'IPHC).

5.2. Les commandes usuelles

  • Copier des données sur un SE

    En mode distant :

    # lcg-cp my_dataset.tar.gz srm://sbgse1.in2p3.fr/dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/my_dataset.tar.gz

    Commande conseillée depuis une UI ou un WN local :

    # rfcp my_dataset.tar.gz /dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/my_dataset.tar.gz
    30914560 bytes in 1 seconds through local (in) and eth0 (out) (30190 KB/sec)

    Cette seconde commande sera souvent placée dans le script d'une tâche de calcul afin d'en conserver le résultat.

    Note

    Il existe une différence importante entre les commandes lcg-cp et rfcp. En effet, les données copiées par lcg-cp sont par défaut considérées comme permanentes, alors que les données copiées par rfcp sont considérées comme temporaires, avec une durée de vie de 6 mois.

  • Récupérer des données depuis un SE

    En mode distant :

    # lcg-cp  srm://sbgse1.in2p3.fr/dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/my_dataset.tar.gz my_dataset.tar.gz

    Commande conseillée depuis une UI ou un WN local :

    # rfcp /dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/my_dataset.tar.gz my_dataset.tar.gz
    30914560 bytes in 1 seconds through eth0 (in) and local (out) (30190 KB/sec)

    Cette commande permet de récupérer le résultat d'un calcul sur une UI, ou des données pour une tâche en cours, par exemple.

  • Lister le contenu d'un répertoire sur un SE

    En mode distant :

    # lcg-ls -l  srm://sbgse1.in2p3.fr/dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/
    -rw-rw-r-- 1 2 2 30914560 ONLINE /dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/my_dataset.tar.gz

    Commande conseillée depuis une UI ou un WN local :

    # rfdir /dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/
    -rw-rw-r-- 1 633 211 30914560 Mar 25 09:18 /dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/my_dataset.tar.gz

6. Paramètres avancés pour la soumission d'un calcul

Cette section détaille la soumission des tâches longues et des tâches paramétriques.

6.1. Soumission d'une tâche longue

Lorsqu'il est nécessaire de soumettre des tâches dont la durée dépasse la durée du proxy fourni (24 heures), il est possible d'utiliser un serveur de proxy afin de renouveler automatiquement le proxy. Pour ce faire, il est nécessaire d'ajouter dans le fichier JDL de la tâche la ligne suivante :

MyProxyServer="myproxy.cern.ch";

Puis d'utiliser les commandes suivantes pour soumettre la tâche :

# voms-proxy-init --voms vo.grand-est.fr
# myproxy-init -d -n -c 100
# glite-wms-job-delegate-proxy -a
# glite-wms-job-submit -a my.jdl

La commande myproxy-init permet d'enregistrer le proxy sur un serveur myproxy (dans notre cas, myproxy.cern.ch). La commande glite-wms-job-delegate-proxy permet de déléguer le renouvellement du proxy au WMS.

De cette manière, le proxy sera automatiquement renouvelé, que la tâche de calcul soit en attente en queue ou bien que le calcul soit en cours sur l'un des noeuds.

6.2. Soumission d'un ensemble paramétrique de calculs

La soumission d'une tâche de type Parametric est la soumission d'un ensemble de calculs dont les fichiers JDL sont identiques, mais qui pourront accéder à une valeur paramétrable unique à chaque calcul. Ce type de tâche est très utile lors le soumission d'une série de calculs ne différant que par la caleur d'un paramètre (par exemple, un paramètre numérique utilisé dans le nom des fichiers d'entrée et de sortie).

Exemple 3. Contenu du fichier parametric.jdl

JobType = "Parametric";

Parameters = 20;
ParameterStart = 1;
ParameterStep = 1;

Executable = "/bin/sh";
Arguments = "myparamscript.sh";
StdOutput = "stdout.out";
StdError = "stderr.err";
InputSandbox = { "myscript.sh" };
OutputSandbox = { "stdout.out", "stderr.err" };
VirtualOrganisation = "vo.grand-est.fr";

 

Exemple 4. Contenu du fichier myparamscript.sh

#!/bin/sh

BATCH_NB=$1
echo "===== Begin ====="
date
rfcp /dpm/in2p3/home/grand-est/iphc/user/dataset_${BATCH_NB}.dat dataset.dat
${VO_VO_GRAND_EST_FR_SW_DIR}/bin/mycode --input dataset --output output_file_${BATCH_NB}.dlg
rfcp output_file_${BATCH_NB}.dlg /dpm/in2p3/home/vo.grand-est.fr/lab/user/output_file_${BATCH_NB}.dlg
date
echo "===== End ====="

 

7. Références complémentaires

Cette section propose des références complémentaires pour approfondir la gestion des calculs avec l'intergiciel gLite :

 


[1] Actuellement, les calculs soumis sur la VO vo.grand-est.fr s'exécutent toujours sur le site de l'IPHC

[2] Le déploiement de logiciel préinstallé sur la grille dépasse le cadre de ce document, contacter votre administrateur grille pour plus d'informations