Domaine scientifique de la Doua
Bâtiment Paul Dirac
4, Rue Enrico Fermi
69622 Villeurbanne Cedex
Accueil Tel: +33 (0) 4 72 43 13 46
Direction : +33 (0) 4 72 44 84 57
Fax: +33 (0) 4 72 43 15 40


Nous contacter


organigramme


annuaire


intranet


Réservations

Nos tutelles

CNRS

Rechercher




Accueil > Support > Soutien technique > Informatique > TIER 3

Fonctionnement du Tier3, comment l’utiliser ?

Qui peut utiliser les ressources de l’IPNL ?

Tous les groupes de l’IPNL ayant des besoins en calcul peuvent utiliser le TIER3.

De quoi ai-je besoin pour utiliser le TIER3 ?

Pour pouvoir envoyer des jobs sur les machines du TIER3, il vous faut trois choses :

  • Un certificat électronique personnel GRID2-FR. Ce certificat servira à vous identifier sur la grille. La procédure de demande de certificat GRID-FR est présentée dans l’article Demande de certificat GRID-FR
  • Appartenir à une Organisation Virtuelle supportée par l’IPNL. Une Organisation Virtuelle (VO) est une communauté d’utilisateurs de la grille. Il existe de multiples VO, en particulier pour les expériences LHC (ALICE, ATLAS, CMS, LHCB). L’IPNL supporte les VOs LHC « alice » et « cms », mais aussi les VOs « calice », « dzero », « vo.agata.org », « vo.formation.idgrilles.fr » (pour organiser des formations sur l’utilisation de la grille), « vo.france-grilles.fr » (la VO nationale Française du GIS France Grilles) et la VO « vo.rhone-alpes.idgrilles.fr » (VO régionale Cidra2 - Calcul Intensif et Données en Auvergne-Rhône-Alpes-). Pour permettre aux groupes "non LHC" d’utiliser les ressources de calcul de l’IPNL seulement, une VO « vo.ipnl.in2p3.fr » a été crée. Celle-ci est susceptible d’accueillir toute personne appartenant à un groupe de recherche de l’IPNL ayant besoin de temps de calcul.

Donc, pour pouvoir utiliser les ressources d’une VO, c’est à dire utiliser pouvoir lancer des jobs dans les sites qui supportent cette VO et accéder aux stockages associés, vous devez vous enregistrer auprès de cette VO.

Une fois en possession de votre certificat GRID-FR et si vous n’appartenez pas aux VO Alice ou CMS, vous pouvez demander votre inscription à la VO vo.ipnl.in2p3.fr.

La liste complète des VO supportées par notre site est disponible sur EGI.

Liens aux inscription aux VO supportées par l’IPNL :
* CMS
* ALICE
* calice
* vo.agata.org
* vo.ipnl.in2p3.fr
* vo.france-grilles.fr
* vo.rhone-alpes.idgrilles.fr
* vo.formation.idgrilles.fr

Remarque : Après que votre demande d’inscription ait été validée, il faut attendre environ 8 heures avant de pouvoir envoyer un job. Ce delai est nécessaire pour la prise en compte de votre inscription sur toutes les machines de la grille.

  • Avoir accès à une interface utilisateur (UI). Vous pouvez vous connecter sur lyoserv.in2p3.fr. Cette machine dispose des commandes nécessaires pour utiliser la grille de calcul. Cependant, lyoserv.in2p3.fr n’est pas une machine de calcul, mais uniquement une machine passerelle SSH, c’est à dire que pour pouvoir se connecter sur un des serveurs internes du laboratoire, il faut d’abord se connecter sur lyoserv.in2p3.fr, puis se connecter sur le serveur interne au laboratoire.
  • D’autres UI sont disponibles en plus grand nombre et sans limite de temps CPU ou RAM contrairement aux lyoserv.in2p3.fr, les lyoui.in2p3.fr : ces serveurs interactifs sont accessibles quel que soit votre équipe ou votre groupe d’appartenance pour vos calculs interactifs. Elles sont gérées en load-balancing : à votre connexion, vous serez dirigé vers la machine la moins chargée.

Installation du certificat (à ne faire qu’une seule fois !)

  • Depuis le navigateur, exporter le certificat en .p12 :
    • Firefox :
      • Edition/Préférences
      • Onglet "Privacy & security"
      • Dans le paragraphe "Certificats"
      • Bouton "Afficher les certificats"
      • Onglet "Vos certificats"
      • Sélectionner le certificat et cliquer sur "Exporter"
      • Donner un nom au fichier et l’enregistrer (un mot de passe vous est demandé pour le protéger)
  • Copier le certificat sur votre HOME NFS (compte Unix)
  • Créer un répertoire .globus
    $ mkdir ~/.globus
  • Copier le fichier .pk12 dans ce répertoire
  • Convertir le certificat dans un format utilisable pour la grille (le mot de passe qui protège le fichier .pk12 vous sera demandé ainsi qu’un nouveau mot de passe qui vous servira à créer votre proxy) :
    $ cd ~/.globus
    $ openssl pkcs12 -in <nom du fichier>.p12 -clcerts -nokeys -out usercert.pem
    $ openssl pkcs12 -in <nom du fichier>.p12 -nocerts -out userkey.pem
  • Supprimer le fichier .p12
  • Modifier les droits des nouveaux fichiers (étape indispensable !) :
    $ chmod 400 userkey.pem
    $ chmod 444 usercert.pem
  • Si tout s’est bien passé, la commande suivante :
    $ grid-cert-info

    doit afficher les informations relatives à votre certificat.

Envoyer un job sur les machines de l’IPNL

Création du fichier de description du job

Pour envoyer un job, vous devez créer un fichier de description de ce job (JDL - Job Description Language) qui indiquera l’exécutable, les fichiers de sortie, les fichiers de données éventuels, etc...

Exemple d’un fichier JDL simple :

[
 Type = "Job";
 JobType = "Normal";
 Executable = "/bin/echo";
 Arguments = "Hello World";

 StdOutput = "hw.out";
 StdError = "hw.err";
 OutputSandbox = {"hw.out", "hw.err"};
 # 
 # pour envoyer le job directement sur un CREAMCE, l'une des options
 # OutputSandboxDestURI ou OutputSandboxBaseDestURI est obligatoire :
 # 
 # exemple : pour stocker l'OutputSandbox sur un SE (10Mo < fichiers volumineux, ...)
 # remplacer VO par le nom de votre VO (exemple vo.ipnl.in2p3.fr) :
 # OutputSandboxBaseDestUri = "gsiftp://lyogrid06.in2p3.fr/dpm/in2p3.fr/home/VO/mytest";
 # Dans ce cas, on recuperera les fichiers correspondant a StdOutput StdError avec la commande :
 # gfal-copy gsiftp://lyogrid06.in2p3.fr/dpm/in2p3.fr/home/VO/hw.out file:hw.out
 # 
 # exemple : pour laisser le CREAMCE gerer l'OutputSandbox (dans le cas d'une soumission directe a un CREAMCE *et* pour des fichiers < 10Mo) :
 # OutputSandboxBaseDestUri="gsiftp://localhost";
 # dans ce cas, on recuperera l'OutputSandbox avec la commande :
 # glite-ce-job-output JobID
]

- L’exécutable est "/bin/echo". Il est déjà sur le worker node, donc pas besoin de l’envoyer.
- On lui passe en argument la chaîne de caractères "Hello World".
- La sortie standard est enregistrée dans le fichier hw.out.
- Les erreurs sont enregistrées dans le fichier hw.err.
- OutputSanbox : C’est la liste des fichiers que l’on va pouvoir récupérer après exécution. Ici ce sont les fichiers hw.out et hw.err.

Notre job doit donc exécuter un "/bin/echo Hello World" sur le worker node et enregistrer la sortie dans le fichier hw.out.

Un autre fichier JDL :

[
  Type = "Job";
  JobType = "Normal";
  Executable = "test2.sh";
  StdInput = "test2-input.txt";
 InputSandbox = {"test2.sh","test2-input.txt","mon_executable"};

  StdOutput = "test2-message.txt";
  StdError = "test2-error.txt";
  OutputSandbox = {"test2-message.txt", "test2-error.txt"};

 # pour envoyer le job directement sur un CREAMCE, l'une des options
 # OutputSandboxDestURI ou OutputSandboxBaseDestURI est obligatoire
 # exemple : pour stocker l'OutputSandbox sur un SE (fichiers volumineux...)
 # remplacer VO par le nom de votre VO :
 # OutputSandboxBaseDestUri = "gsiftp://lyogrid06.in2p3.fr/dpm/in2p3.fr/home/VO/mytest";
 #
 # exemple : pour stocker laisser le CREAMCE gerer l'OutputSandbox :
 # OutputSandboxBaseDestUri="gsiftp://localhost";
]

Cette fois-ci, l’exécutable est un script que nous avons écrit : test2.sh. Celui-ci n’étant pas présent sur le worker node, il est important d’indiquer qu’il faut l’envoyer, ce sera aussi le cas de(s) exécutable(s) appelé(s) depuis ce script. Ceci est fait par l’intermédiaire de l’instruction "InputSandbox". Tout les fichiers listés dans InputSandbox seront envoyés sur le worker node.

Nous voyons aussi apparaître la directive OutputSandboxBaseDestUri qui nous sera utile dans le cas de l’envoi du job directement sur un CREAMCE ou alors quand les fichiers sont volumineux.

Attention : La taille totale des fichiers placés dans InputSandbox est limitée à environ 10 Mo. Il en va de même pour OutputSandbox. Si vos données sont plus importantes, reportez-vous à la section accès aux données.

Utilisation d’un paramètre :

Voir Ganga

Soumission du job

Pour soumettre un job, vous devez disposer d’une machine configurée à cet effet. Depuis l’IPNL, vous pouvez utiliser lyoserv avec votre compte UNIX.

Gestion du proxy

Pour soumettre le job, vous devez créer un proxy qui vous permettra de vous identifier sur la grille et d’indiquer la VO à laquelle vous appartenez :

$ voms-proxy-init --voms vo.ipnl.in2p3.fr

Votre mot de passe vous est demandé puis un proxy est créé. Celui-ci a une durée de validité de 12 heures par défaut. La durée peut être fixée jusqu’à 24h avec l’option "-valid 24:00". Pendant cette période, vous pouvez soumettre des jobs et exécuter des jobs. Attention ! Votre proxy doit être valide jusqu’à la fin de vie de votre job !
Pour obtenir des informations sur votre proxy, utilisez la commande :

$ voms-proxy-info --all

En cas de problème lors de la création du proxy, vérifiez que votre certificat est bien installé. La commande

$ grid-cert-info

doit afficher les informations relatives à votre certificat.
Vérifiez également que vous êtes bien inscrits auprès de la VO.

Envoi direct des jobs sur un CREAMCE

Guide des commandes pour lancer des jobs sur un CREAMCE :

PDF - 427.1 ko

Pour connaitre le nom du CREAMCE sur notre site, nous permettant d’envoyer les jobs directement à ce CREAMCE :

lcg-infosites -f IN2P3-IPNL ce

ou (informations plus complètes) :

lcg-infosites -f IN2P3-IPNL voview

ou alors pour connaitre le nom de la queue correspondante à une autre vo ("vo.ipnl.in2p3.fr" dans l’exemple ci dessous) :

lcg-infosites -f IN2P3-IPNL --vo vo.ipnl.in2p3.fr ce

Donc envoyer le job directement à notre CREAMCE (ici la queue IPNL correspondant à la VO vo.ipnl.in2p3.fr) :

glite-ce-job-submit -a -o JID -r lyogrid07.in2p3.fr:8443/cream-pbs-ipnl test1.jdl

Autres commandes relatives au CREAMCE :

  • glite-ce-job-list lyogrid07.in2p3.fr:8443 : liste de vos jobs sur notre CREAMCE
  • glite-ce-service-info lyogrid07.in2p3.fr:8443 : Vérifier si le CREAMCE fonctionne correctement
  • glite-ce-job-cancel -i JID : arrêter l’exécution d’un ou plusieurs jobs
  • glite-ce-job-suspend : suspends l’exécution d’un ou plusieurs jobs précédemment soumis au CREAMCE
  • glite-ce-job-resume : reprends l’exécution d’un ou plusieurs jobs précédemment suspendus avec glite-ce-job-suspend
  • glite-ce-job-purge : supprime les références des jobs du CREAMCE, après cette commande, les jobs mentionnés ne seront plus gérés par le CREAMCE

Etat des jobs

Pour connaître l’état d’avancement de vos jobs, vous pouvez utiliser la commande glite-ce-job-status (si vous avez envoyé votre job directement à un CREAMCE) :

$ glite-ce-job-status {job_id}

Si vous avez utilisé l’option "-o JID" lors de la soumission, vous pouvez utiliser ce fichier :

$ glite-ce-job-status -i JID

Ce qui vous permettra d’obtenir l’état de chaque job inscrit dans le fichier JID.

Un job envoyé à un CREAMCE peut avoir les états suivants :

REGISTERED le job a été enregistré, mais n’est pas encore entré en exécution
PENDING le job a été entré dans le CREAMCE, et il doit être soumis au gestionnaire de batch du site
IDLE Le job est en attente dans la file d’attente du gestionnaire de batch du site
RUNNING le jdl est lancé dans le gestionnaire de batch du site
REALL RUNNING : l’exécutable est en cours d’exécution sur un des workers du site
HELD le job est suspendu dans le gestionnaire de batch du site
CANCELLED le job à été stoppé
DONE-OK le job a été correcement exécuté, sans erreur relative au système de batch
DONE-FAILED le job a été exécuté, mais une erreur est survenue
ABORTED une erreur dans le système de batch est survenue
UNKNOWN le statut du job est dans un état inconnu

Remarque : Les horaires indiqués par la commande glite-ce-job-status sont en UTC (-2 h en été, -1 heure en hiver) !

Etat du Tier3

Pour connaitre l’état actuel du Tier 3 (combien de jobs sont en train d’être exécutés par exemple), vous pouvez utiliser la commande qstat :

Liste des jobs en cours :

$ qstat

Résumé des jobs par file d’attente :

$ qstat -q

Liste des machines sur lesquelles tournent les jobs :

$ qstat -n -1

Statistiques de calcul des dernières 24h du Tier 3 :

Récupération des fichiers de sortie du job

Une fois que votre job est en état DONE, vous pouvez récupérer les fichiers de l’OutputSandbox avec la commande glite-ce-job-output (pour un CREAMCE :

$ glite-ce-job-output {job_id}

Vous pouvez également utiliser l’option "-i JID".
Cette commande va effacer le job du système de la grille et copier les fichiers de l’OutputSandbox dans le répertoire /scratch/ de l’UI.
L’état du job doit maintenant être CLEARED. Il est important de toujours effectuer cette étape afin de ne pas laisser les fichiers de l’OutputSandbox sur le site de calcul.

Si tout c’est bien passé pour notre exemple helloWorld, nous devrions récupérer 2 fichiers : hw.err et hw.out.
hw.err devrait être vide et hw.out devrait contenir la chaîne de caractères "Hello World", résultat de notre commande "/bin/echo Hello World".

Annulation d’un job

L’annulation d’un job se fait par la commande :

$ glite-ce-job-cancel {job_id}

Accès aux données

Afin de faciliter l’utilisation de la grille pour les utilisateurs locaux, 2 solutions ont été mises en place.

  • Un répertoire /gridgroup/ est accessible depuis l’UI et les worker nodes. Ce répertoire peut être utilisé pour les entrées/sorties des jobs. Pour l’instant, cette zone de stockage n’est pas aussi performante que le stockage de type grille (SRM, DPM, xrootd), aussi il n’est pas recommandé de l’utiliser pour stocker les entrées/sortie d’un grand nombre de jobs simultanés. Ce répertoire /gridgroup est maintenant sauvegardé sur bande au CC-IN2P3, comme le sont aussi les répertoires /gridsoft, /home et /group.
  • Les répertoires NFS des groupes de l’institut (/group) sont aussi accessibles depuis les UI et les worker nodes sous certaines conditions :
    • Lors de la création du proxy, vous devez préciser votre groupe par l’intermédiaire d’un rôle. Par exemple :
      voms-proxy-init --voms vo.ipnl.in2p3.fr:/vo.ipnl.in2p3.fr/Role=theorie

      Cette commande vous identifie comme un utilisateur du groupe Théorie. Evidemment, la commande ne sera un succès que dans le cas où vous êtes bien un membre du groupe Théorie !
      A partir de là, vos jobs pourront accéder aux répertoires /group/theorie/ et /wingroup/theorie/ avec les droits du groupe theorie (attention à bien donner les droits au groupe pour les fichiers que vous souhaitez utiliser et pas seulement à l’utilisateur propriétaire du fichier !).

Files d’attente

Il existe 3 files d’attente pour la VO vo.ipnl.in2p3.fr :

  • ipnl : La file par défaut. Les jobs envoyés sur cette file pourront accéder à toutes les machines du Tier3. Un job pourra utiliser jusqu’à 24h de CPU ou rester jusqu’à 36h sur la machine.
  • ipnl_long : Seulement 4 jobs pourront être exécutés en parallèle sur cette file. Par contre, un job pourra utiliser jusqu’à 168h de CPU ou rester jusqu’à 170h sur la machine.

Pour choisir la file d’attente, utilisez l’option -r de la commande de soumission (attention, on ne peut pas lancer des jobs paramétriques en utilisant l’option -r) :


$ glite-ce-job-submit -a -o JID -r lyogrid07.in2p3.fr:8443/cream-pbs-<nom_de_la_file> <votre fichier JDL>.jdl

Il est également possible de remplacer l’option -r par la ligne :

Requirements = other.GlueCEUniqueID=="lyogrid07.in2p3.fr:8443/cream-pbs-<nom_de_la_file>";

dans votre fichier JDL. Ceci est supporté par les jobs paramétriques.

Jobs longs

Pour des raisons de sécurité, la durée de vie maximale d’un proxy est de 24 heures.
Toutefois, si vos jobs ont besoin de plus de temps, il est possible de mettre en place un service qui renouvellera automatiquement votre proxy avant que celui-ci n’arrive à expiration.

Pour cela, créer un proxy à durée limitée (par défaut 12 heures) :

$ voms-proxy-init --voms vo.ipnl.in2p3.fr

Donnez l’autorisation à un serveur MyProxy de renouveler votre proxy :


$ myproxy-init -s myproxy.cern.ch -d -n -c 192

Le serveur myproxy.cern.ch pourra maintenant renouveler votre proxy pendant 192 heures (8 jours).

Dans votre fichier JDL, vous devez indiquer le nom du serveur ayant l’autorisation de renouveler votre proxy :


Executable = "script.sh";
InputSandbox = "script.sh";
MyProxyServer = "myproxy.cern.ch";
StdOutput = "std.out";
StdError = "std.err";
OutputSandbox = {"std.out", "std.err"};

Il ne reste plus qu’à soumettre le job. Le serveur MyProxy devrait renouveler le proxy avant que celui-ci n’expire. Toutefois, la durée de vie d’un job dans la file ipnl (file par défaut) étant limitée à 24 heures de temps CPU (ou 36 heures de présence sur la machine), vous devez envoyer le job sur la file ipnl_long qui permettra l’exécution du job pendant 1 semaine (168 heures).


$ glite-ce-job-submit -a -o JID -r lyogrid07.in2p3.fr:8443/cream-pbs-ipnl_long <votre fichier JDL>.jdl

Une fois les jobs terminés, pour supprimer l’autorisation sur le serveur MyProxy :


$ myproxy-destroy -s myproxy.cern.ch -d

Remarque :

  • Les jobs envoyés sur la file ipnl_long seront exécutés sur 2 serveurs spécifiques. Jusqu’à 16 jobs pourront être exécutés en concurrence, les suivants seront mis en attente.

Jobs MPI

Il est possible de faire de la programmation parallèle en utilisant MPI. Pour cela vous aurez besoin :

  • D’un script mpi-start-wrapper.sh pour lancer votre processus MPI. Vous pouvez utiliser celui-ci :
    #!/bin/bash

    # Pull in the arguments.
    MY_EXECUTABLE=`pwd`/$1
    MPI_FLAVOR=$2

    # Convert flavor to lowercase for passing to mpi-start.
    MPI_FLAVOR_LOWER=`echo $MPI_FLAVOR | tr '[:upper:]' '[:lower:]'`

    # Pull out the correct paths for the requested flavor.
    eval MPI_PATH=`printenv MPI_${MPI_FLAVOR}_PATH`

    # Ensure the prefix is correctly set.  Don't rely on the defaults.
    eval I2G_${MPI_FLAVOR}_PREFIX=$MPI_PATH
    export I2G_${MPI_FLAVOR}_PREFIX

    # Touch the executable.  It exist must for the shared file system check.
    # If it does not, then mpi-start may try to distribute the executable
    # when it shouldn't.
    touch $MY_EXECUTABLE

    # Setup for mpi-start.
    export I2G_MPI_APPLICATION=$MY_EXECUTABLE
    export I2G_MPI_APPLICATION_ARGS=
    export I2G_MPI_TYPE=$MPI_FLAVOR_LOWER
    export I2G_MPI_PRE_RUN_HOOK=mpi-hooks.sh
    export I2G_MPI_POST_RUN_HOOK=mpi-hooks.sh

    # If these are set then you will get more debugging information.
    export I2G_MPI_START_VERBOSE=1
    #export I2G_MPI_START_DEBUG=1

    # Invoke mpi-start.
    echo $I2G_MPI_START
    $I2G_MPI_START
  • D’un script mpi-hooks.sh qui permet de compiler votre programme avant l’exécution et de traiter les résultats après l’exécution :
    #!/bin/sh

    #
    # This function will be called before the MPI executable is started.
    # You can, for example, compile the executable itself.
    #
    pre_run_hook () {

     # Compile the program.
     echo "Compiling ${I2G_MPI_APPLICATION}"

     # Actually compile the program.
     cmd="$MPI_OPENMPI_PATH/bin/mpicc ${MPI_MPICC_OPTS} -o ${I2G_MPI_APPLICATION} ${I2G_MPI_APPLICATION}.c"
     echo $cmd
     $cmd
     if [ ! $? -eq 0 ]; then
       echo "Error compiling program.  Exiting..."
       exit 1
     fi
     export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MPI_OPENMPI_PATH/lib/
     # Everything's OK.
     echo "Successfully compiled ${I2G_MPI_APPLICATION}"

     return 0
    }

    #
    # This function will be called before the MPI executable is finished.
    # A typical case for this is to upload the results to a storage element.
    #
    post_run_hook () {

     echo "Executing post hook."
     echo "Finished the post hook."

     return 0
    }
  • De votre fichier source (dans notre exemple testMPI.c)
    #include <stdio.h>
    #include <mpi.h>

    int main(int argc, char *argv[]) {
     int numprocs, rank, namelen;
     char processor_name[MPI_MAX_PROCESSOR_NAME];

     MPI_Init(&argc, &argv);
     MPI_Comm_size(MPI_COMM_WORLD, &numprocs);
     MPI_Comm_rank(MPI_COMM_WORLD, &rank);
     MPI_Get_processor_name(processor_name, &namelen);

     printf("Process %d on %s out of %d\n", rank, processor_name, numprocs);

     MPI_Finalize();
    }
  • D’un fichier JDL pour soumettre votre job :
    [
    type             ="job";
    JobType        = "MPICH";
    #Nombre de CPUs à utiliser
    CPUNumber      = 5;
    Executable     = "mpi-start-wrapper.sh";
    Arguments      = "testMPI OPENMPI";
    StdOutput      = "testMPI.out";
    StdError       = "testMPI.err";
    InputSandbox   = {"/path/to/mpi-start-wrapper.sh","/path/to/mpi-hooks.sh","/path/to/testMPI.c"};
    OutputSandbox  = {"testMPI.err","testMPI.out"};
    Requirements =
     Member("MPI-START", other.GlueHostApplicationSoftwareRunTimeEnvironment)
     && Member("OPENMPI", other.GlueHostApplicationSoftwareRunTimeEnvironment)
     && other.GlueCEUniqueID=="lyogrid07.in2p3.fr:8443/cream-pbs-ipnl";

La soumission se fait comme pour n’importe quel autre job :

glite-ce-job-submit -a -o JID testMPI.jdl

Contact

Pour toute question concernant l’utilisation du Tier3, envoyez un mail à gridsupport@ipnl.in2p3.fr

Les annonces et discussions concernant le Tier3 se font sur grid@ipnl.in2p3.fr. Pour vous inscrire, envoyez un mail à sympa@ipnl.in2p3.fr avec dans le sujet ou le corps du message :

subscribe grid Prénom Nom