Comment démarrer ?

Cette page décrit les modalités d’accès à la grille ainsi que quelques exemples simples d’utilisation. Elle ne remplace pas une formation ou la lecture du guide utilisateur gLite plus complet, mais doit permettre à un utilisateur démarrant d’avoir une idée des premières étapes à effectuer pour utiliser les outils de base de la grille.

1. Modalités d’accès

Les modalités d’accès dépendent des grilles de production. Le site France Grilles indique les étapes à suivre pour accéder à la grille EGI. Les premières étapes dans l’utilisation des ressources grille est dans la définition des autorisations. Ceci implique que vous obteniez un "certificat" de votre "autorité locale de certification". Ensuite vous devez vous enregistrer dans une Organisation Virtuelle (VO) et finalement installer votre certificat et les clefs correspondantes sur la machine Interface Utilisateur sur laquelle l’intergiciel de la grille est installé.

  • Un certificat est un petit fichier qui contient des informations concernant son propriétaire (nom, prénom, adresse) ainsi qu’une clef publique. Il est signé par une autorité compétente qui garantit la validité des informations qu’il contient. Un certificat est associé à une clef privée qui n’est pas inclue dans le certifcat mais qui est généralement conservée sur l’interface utilisateur. Avec ce certifcat et la clef privée l’utilisateur peut signer ses courriers électroniques, accéder à des pages web restreintes et utiliser les ressources de la grille. Les instructions sont décrites ici. N’oubliez pas de récupérer et de sauvegarder votre certificat depuis le browser web. Par exemple sous FireFox
    # Edit -> Preferences -> Advanced -> View Certificates

    sélectionner votre certificat est cliquez BACKUP (et pas export).
  • appartenir à une Organisation Virtuelle.
  • se connecter à une Interface Utilisateur.
    • si vous n’avez pas de compte veuillez contacter les responsables du site auquel vous etes associé.
    • veuillez vous logguer sur votre compte et transférer votre certificat dans votre répertoire racine.
    • convertissez ce certificat à un format adéquat pour etre utilisé. Vous devez convertir le fichier .p12 ou .pfx en une paire de fichiers (le certifcat et le "proxy"), les deux dans un format .pem :

      Dans votre répertoire racine sur l’UI créez le répertoire :

      # mkdir .globus

      Copiez le certificat dans le répertoire racine et effectuez la conversion :

      # openssl pkcs12 -in your-cert-file -clcerts -nokeys -out $HOME/.globus/usercert.pem
      et
      # openssl pkcs12 -in your-cert-file -nocerts -out $HOME/.globus/userkey.pem

      où  your-cert-file est le chemin vers votre certificat. Notez que les fichiers de sortie vont dans le répertoire .globus de votre répertoire racine. Le fichier userkey.pem filedoit etre en lecture et écriture uniquement pour vous, ni par votre groupe ni par qui que ce soit, sinon les commandes "proxy" ne fonctionneront pas :
      # chmod 400 userkey.pem
      # chmod 444 usercert.pem

    • l’intergiciel (décrit ci-après) est généralement déjà installé sur l’UI; donc les commandes grille sont directement utilisables.

2. L’intergiciel

L’intergiciel (middleware) utilisé par GRIF 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.

La suite de cette page détaille l’utilisation de l’interface utilisateur avec gLite pour la soumission, le suivi et la récupération des résultats d’un calcul.

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

Services gLite utilisés lors de la soumission d'un calcul

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

Elément Rô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 GRIF, 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.

4. Gestion d’un calcul

Il est hautement recommandé de lire la section Workload Management de la documentation gLite.

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

# voms-proxy-init –voms vo.locale.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_u627
timeleft  : 11:59:44
=== VO vo.locale.fr extension information ===
VO        : vo.locale.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.locale.fr/Role=NULL/Capability=NULL
timeleft  : 11:59:44
url       : grid12.lal.in2p3.fr:20018

4.1. Soumission d’un calcul

La soumission d’un calcul sur la grille, 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.locale.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 GRID différentes VO sont à disposition (cf. ici); nous utiliserons dans la suite “vo.locale.fr” mais veuillez remplacer par la VO dans laquelle vous êtes inscrit.

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://node27.datagrid.cea.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://grid40.lal.in2p3.fr:9000/EF7GUrW-JVqZILy6KgWqCA

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

Il est important de conserver l’identifiant de la tâche https://grid40.lal.in2p3.fr:9000/EF7GUrW-JVqZILy6KgWqCA. 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://node27.datagrid.cea.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://grid40.lal.in2p3.fr:9000/EF7GUrW-JVqZILy6KgWqCA

======================= glite-wms-job-status Success ===================

BOOKKEEPING INFORMATION:

Status info for the Job : https://grid40.lal.in2p3.fr:9000/EF7GUrW-JVqZILy6KgWqCA
Current Status:     Ready
====================================================================

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

# glite-wms-job-status https://grid40.lal.in2p3.fr:9000/EF7GUrW-JVqZILy6KgWqCA

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

Status info for the Job : https://grid40.lal.in2p3.fr:9000/EF7GUrW-JVqZILy6KgWqCA

Current Status:     Done (Success)
Logged Reason(s):
    – job completed
    – Job Terminated Successfully
Exit code:          0
Status Reason:      Job Terminated Successfully
Submitted:          Mon Jul  4 17:25:17 2011 CEST
=====================================================================

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://grid40.lal.in2p3.fr:9000/EF7GUrW-JVqZILy6KgWqCA

Connecting to the service https://node27.datagrid.cea.fr:7443/glite_wms_wmproxy_server

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

            JOB GET OUTPUT OUTCOME

Output sandbox files for the job:
https://grid40.lal.in2p3.fr:9000/EF7GUrW-JVqZILy6KgWqCA
have been successfully retrieved and stored in the directory:
/home/user/JobOutput/user_EF7GUrW-JVqZILy6KgWqCA

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

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

# ls -rtl
/home/user/JobOutput/user_EF7GUrW-JVqZILy6KgWqCA

-rw-r–r– 1 user group 144 Jul 5 10:17 stdout.out
-rw-r–r– 1 user group 0 Jul 5 10:17 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.

Il est hautement recommandé de lire la section Data Management de la documentation gLite.

5.2 Les commandes usuelles

  • Les fichiers sont répertoriés dans un catalogue appelé LFC (LCG File Catalog)

    # export LFC_HOST=lfc.grif.fr

  • Créer un répertoire de travail :

    # lfc-mkdir -p /grid/vo.local.in2p3.fr/user/workspace

  • Copier un fichier local sur un SE et l’enregistrer dans le catalogue :

    # lcg-cr -l lfn:/grid/vo.local.in2p3.fr/user/workspace/test_file file://home/user/test_file

  • Faire une deuxième copie sur un autre SE spécifié :

    # lcg-rep -d grid05.lal.in2p3.fr lfn:/grid/vo.locale.fr/user/workspace/test_file

  • Lister le répertoire dans le catalogue :

    # lcg-ls -l lfn:/grid/vo.local.in2p3.fr/user/workspace

  • Supprimer une copie sur un SE spécifié :

    # lcg-del -s grid05.lal.in2p3.fr lfn:/grid/vo.locale.fr/user/workspace/test_file

  • Supprimer toutes les copies "grille" d’un fichier et l’enlever du catalogue :

    # lcg-del -a lfn:/grid/vo.locale.fr/user/workspace/test_file

  • Récupérer un fichier :

    # lcg-cp lfn:/grid/vo.locale.fr/user/workspace/output_file file://home/user/output_file

  • Lister les copies disponibles :

    #lcg-lr lfn:/grid/vo.locale.fr/user/workspace/test_file

Autres commentaires :

  • rfio/xroot sont restreint par les pare-feux, donc sont utiles seulement depuis les WNs d’un site vers les SE du même site.

  • Dans les SE de GRIF tous les fichiers sont permanents.

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 l’élément suivant :

MyProxyServer = "myproxy.grif.fr";

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

# voms-proxy-init -voms vo.lpnhe.in2p3.fr
#
myproxy-init -d -n
#
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.grif.fr). 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 valeur 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.lpnhe.in2p3.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 :

Comments are closed.