Comment utiliser CiGri ,

Introduction à la grille de calcul CiGri

L’objectif de ce tutoriel est de configurer et exécuter une campagne de calcul sur grille sur les clusters GRICAD en utilisant la grille de calcul CiGri et le stockage “cloud” Irods (Mantis2). Les étapes sont généralement les suivantes :

  • tester votre application sur un cluster : faire un script de démarrage (start.bash)
  • déployer votre application sur la grille : adapter (éventuellement) le script de démarrage afin qu’il puisse s’exécuter sur chacun des clusters de la grille, créer un fichier de paramètres et un fichier de description de la campagne (fichier jdl).
  • démarrer et surveiller vos tâches
  • obtenir les résultats
  • post-traiter éventuellement les résultats

CiGri est le middleware (intergiciel) de la grille utilisé pour gérer les travaux et Irods est le middleware de stockage pour gérer les données distribuées.

L’application que nous allons utiliser comme exemple est POV (Persistence Of Vision). C’est un logiciel libre de lancer de rayons (raytracer) pour la synthèse d’images synthétiques en 3D. Nous allons réaliser une vidéo haute définition d’une scène virtuelle POV. Chaque tâche (chaque job CiGri) sera le calcul d’une image de notre vidéo.

Cigri en un (tout petit) résumé

CiGri est une grille légère dédiée au traitement des applications de type “bag-of-tasks” (ou “jobs embarrassingly parallel”), comme les applications multi-paramétriques (où vous devez exécuter le même programme avec un grand nombre de paramètres d’entrée “inputs” et obtenir un résultat par paramètre) ou le traitement massif de données (même traitement appliqué sur de nombreuses données, de façon indépendante les unes des autres, pas d’ordre à respecter ni d’interdépendance entre les jobs).

Sa particularité est de pouvoir fonctionner sur les ressources de calcul inutilisées d’un ensemble de supercalculateurs d’un centre de calcul, de manière “best-effort”. Mais elle peut également être utilisée pour gérer un grand nombre de tâches à exécuter sur un cluster particulier, sans forcément activer la contrainte de priorité “best-effort” (en effet un grand nombre de tâches surcharge habituellement l’ordonnanceur local d’un cluster ; la grille est aussi conçue pour résoudre ce problème).

Les jobs bestefforts

Les jobs best-effort sont des jobs de priorité nulle qui peuvent être tués sans préavis si un job normal (prioritaire) a besoin des ressources. C’est un moyen de calculer de manière transparente sur des clusters qui ne vous sont pas dédiés, uniquement lorsque les cpus sont inactifs. CiGri est un outil utile pour gérer de tels travaux car CiGri permet de resoumettre encore et encore le même job jusqu’à ce qu’il s’exécute en totalité sans être tué (de tels jobs sont de type idempotent). Nous appelons cela la re-soumission et CiGri le fait automatiquement.

Prérequis à l’utilisation de la grille de calcul CiGri

Avoir un compte GRICAD actif

Vous devez avoir un compte PERSEUS actif, et être membre d’au moins un projet actif (par exemple le projet formation-ced-calcul).

Etre dans le groupe cigri

Votre compte GRICAD doit être actif et faire partie du groupe cigri. Vous pouvez le vérifier avec la commande id <agalanlogin> ou la commande groups depuis un cluster GRICAD:

lecoinal@dahu:~$ groups
... m-cigri ...

Pour être membre de ce groupe, vous devez être membre d’un projet PERSEUS ayant spécifié l’usage de CiGri.

Accéder à l’hôte CiGri

L’hôte de soumission CiGri de GRICAD (appelé aussi la frontale CiGri) est la machine ciment-grid.u-ga.fr alias killeen. Vous pouvez vous connecter à cet hôte avec ssh depuis votre machine locale (localhost) en traversant un des deux bastions GRICAD (rotule ou trinity):

locallogin@localhost:~$ ssh agalanlogin@access-gricad.univ-grenoble-alpes.fr
agalanlogin@trinity:~$ ssh ciment-grid.u-ga.fr
agalanlogin@killeen3:~$

Ou, directement, depuis votre machine locale:

> ssh killeen.ciment

si vous avez configuré localement votre .ssh/config ainsi (dans votre répertoire personnel sur votre machine locale) :

> cat ~/.ssh/config
Host *.ciment
  User agalanlogin
  ProxyCommand ssh -q agalanlogin@access-gricad.univ-grenoble-alpes.fr "nc -w 60 `basename %h .ciment` %p"

Pour davantage d’infos, voir la page sur l’accès aux clusters GRICAD

Avoir accès à irods (Mantis2)

Irods est accessible depuis tous les clusters de CiGri (dahu, bigfoot, luke, ceciccluster) et l’hôte CiGri (killeen).

Dans le cadre de ce tutoriel, nous nous limiterons à l’usage des clusters dahu, bigfoot et luke en mode grille. Nous n’utiliserons pas ceciccluster car GUIX n’y est pas disponible.

Un usage plus avancé de Cigri peut permettre d’utiliser les 5 clusters pour une même campagne, en mixant les gestionnaires de paquets utilisés selon les clusters cibles (Guix et Nix par exemple). Cet usage n’est pas détaillé ici.

Pour utiliser irods (Mantis2), vous devez exécuter une fois sur chaque cluster :

> /applis/site/mantis_init.sh

et, afin de maintenir votre token d’authentification actif, faire au moins une fois toutes les deux semaines sur chaque cluster :

> source /applis/site/guix-start.sh   # ou nix.sh (pour avoir accès au i-commands)

# Sur killeen, les i-commands (dont iinit) sont accessibles directement
# Sur les autres clusters, elles sont accessibles après avoir chargé l'environnement nix ou guix, ou encore après avoir ajouté ce chemin à votre variable d'environnement `$PATH` ainsi: `export PATH=/nix/var/nix/profiles/default/bin:$PATH`.
(donc la ligne ci dessus pour sourcer guix n'est pas utile sur killeen)

> iinit

Actuellement, cette commande iinit doit être répétée toutes les deux semaines, et sur chaque cluster (uniquement sur les frontales), c’est à dire que si vous rencontrez cette erreur lors de l’appel à une i-commande:

> ils 
[-]     /tmp/nix-build-irods-4.2.7.drv-0/source/plugins/auth/native/libnative.cpp:342:irods::error native_auth_client_response(irods::plugin_context &, rcComm_t *) :  status [CAT_INVALID_AUTHENTICATION]  errno [] -- message [Call to rcAuthResponseFailed.]

 failed with error -826000 CAT_INVALID_AUTHENTICATION

, il faut refaire iinit et fournir votre mot de passe GRICAD (mot de passe Agalan):

> iinit
Enter your current PAM password:
> ils
/mantis/home/lecoinal:
  C- /mantis/home/lecoinal/povray
  C- /mantis/home/lecoinal/povray_results

Nous allons donc vérifier notre accès à Irods depuis l’hôte CiGri :

agalanlogin@killeen3:~$ which ils
/nix/var/nix/profiles/default/bin/ils
agalanlogin@killeen3:~$ ils
/mantis/home/agalanlogin:
[...]

Sur killeen, les icommandes (documentation des icommandes iRODS) sont directement disponibles (sans besoin de sourcer explicitement nix.sh).

Sur les clusters de calcul dahu, bigfoot et luke, les icommandes sont disponibles après avoir chargé l’environnement GUIX.

agalanlogin@dahu|bigfoot|luke:~$ which ils
agalanlogin@dahu|bigfoot|luke:~$ source /applis/site/guix-start.sh
Default profile on
The following packages are currently installed in /home/lecoinal/.guix-profile/:
agalanlogin@dahu|bigfoot|luke:~$ which ils
/nix/var/nix/profiles/default/bin/ils
agalanlogin@dahu|bigfoot|luke:~$ iinit  # if necessary
Enter your current PAM password:        # Il s'agit de votre password Agalan
agalanlogin@dahu|bigfoot|luke:~$ ils
/mantis/home/agalanlogin:
[...]

La commande ils liste le contenu du répertoire personnel de votre espace irods (/mantis/home/agalanlogin). Ce répertoire est accessible depuis chaque cluster GRICAD, il est donc très utile pour le partage de données à l’échelle de la grille.

Documentation GRICAD de Mantis

Installer et tester l’application (povray) sur un seul cluster

Avant de lancer de nombreux jobs sur la grille, il est prudent de tester l’application sous la forme d’un seul job (interactif ou batch) sur un cluster donné.

Nous allons tester l’application povray sur le cluster Luke.

L’application povray est disponible en tant que paquet GUIX (NB: elle serait aussi disponible via les modules ou via nix, mais ici nous utiliserons GUIX). Nous allons donc nous connecter à Luke, créer un profil guix et y installer povray, puis tester le lancement manuel interactif de ce logiciel sur le cluster Luke.

> ssh luke.ciment  # connection au cluster luke
> source /applis/site/guix-start.sh  # chargement de Guix
> refresh_guix ced_cigri          # creation d'un nouveau profil: ced_cigri
This profile (ced_cigri) does not exist.
Try to install a new package in this profile to create it:

               guix install -p /var/guix/profiles/per-user/lecoinal/ced_cigri <some_package>

               
> guix search povray    # on cherche le paquet povray
name: povray
version: 3.7.0.8
outputs: out
systems: x86_64-linux i686-linux
dependencies: autoconf@2.69 automake@1.16.2 boost@1.72.0 libjpeg-turbo@2.0.5 libpng@1.6.37 libtiff@4.1.0 openexr@2.5.5
+ pkg-config@0.29.2 sdl@1.2.15 zlib@1.2.11
location: gnu/packages/graphics.scm:1285:2
homepage: http://www.povray.org/
license: AGPL 3+
synopsis: Tool for creating three-dimensional graphics  
description: `POV-Ray' is short for the Persistence of Vision Raytracer, a tool for producing high-quality computer graphics.
+ `POV-Ray' creates three-dimensional, photo-realistic images using a rendering technique called ray-tracing.  It reads in a text file
+ containing information describing the objects and lighting in a scene and generates an image of that scene from the view point of a
+ camera also described in the text file.  Ray-tracing is not a fast process by any means, but it produces very high quality images
+ with realistic reflections, shading, perspective and other effects.
relevance: 20

# installation de povray dans le profil ced_cigri
# L'option --with-patch rajoute un patch avant la compilation de povray, afin de résoudre un bug de la dépendance boost.
> guix install -p $GUIX_USER_PROFILE_DIR/ced_cigri povray --with-patch=povray=/applis/site/povray-fix-boost-1.77-math-tools-pragma.patch


The following package will be installed:
   povray 3.7.0.8

[...]

> guix package -p $GUIX_USER_PROFILE_DIR/ced_cigri -I  # verification de l'environnement
povray	3.7.0.8	out	/gnu/store/sgcsybpzkg9cn99fk0smwzimaw4m2b9b-povray-3.7.0.8
> which povray
> refresh_guix ced_cigri   # il faut encore activer le profil ced_cigri
Activate profile  /var/guix/profiles/per-user/lecoinal/ced_cigri
The following packages are currently installed in /var/guix/profiles/per-user/lecoinal/ced_cigri:
povray	3.7.0.8	out	/gnu/store/sgcsybpzkg9cn99fk0smwzimaw4m2b9b-povray-3.7.0.8
> which povray
/var/guix/profiles/per-user/lecoinal/ced_cigri/bin/povray

Le logiciel povray est donc maintenant disponible pour luke sous le profil ced_cigri dans l’environnement GUIX:

> povray -h
[...]
> povray -version
POV-Ray 3.7.0.8.unofficial
[...]
>

Nous allons maintenant soumettre un job interactif sur le cluster luke (sur un coeur d’un noeud de calcul de luke) afin de tester l’application povray:

agalanlogin@luke:~$ oarsub -I -l /core=1 --project formation-ced-calcul
[...]
OAR_JOB_ID=53038129
Interactive mode: waiting...
Starting...

Connect to OAR job 53038129 via the node luke57
agalanlogin@luke57:~$ which povray
agalanlogin@luke57:~$ 
# Il faut charger le bon profil GUIX
agalanlogin@luke57:~$ source /applis/site/guix-start.bash
agalanlogin@luke57:~$ refresh_guix ced_cigri
agalanlogin@luke57:~$ povray  +W320 +H200 +Ochess.png $GUIX_USER_PROFILE_DIR/ced_cigri/share/povray-3.7/scenes/advanced/chess2.pov   # calcul de rendu d'une image à partir de l'exemple chess2.pov
[...]
agalanlogin@luke57:~$ ls -l chess.png
-rw-r--r-- 1 lecoinal l-isterre 95328 Apr 27 14:25 chess.png

# On peut éventuellement tester quelque chose d'un peu plus long:

agalanlogin@luke57:~$ povray  +W640 +H400 +Obenchmark.png $GUIX_USER_PROFILE_DIR/ced_cigri/share/povray-3.7/scenes/advanced/benchmark/benchmark.pov
[...]
Render Time:
  Photon Time:      0 hours  0 minutes  1 seconds (1.350 seconds)
              using 27 thread(s) with 1.357 CPU-seconds total
  Radiosity Time:   No radiosity
  Trace Time:       0 hours  2 minutes 45 seconds (165.825 seconds)
              using 24 thread(s) with 165.519 CPU-seconds total
POV-Ray finished

Vous pouvez rapatrier (par exemple depuis votre machine locale rsync -av luke.ciment:<chemin-vers>/chess.png .) cette image localement pour la visualiser:

plot chess2

On a donc calculé le rendu d’une image à partir d’un fichier scene (fichier .pov) fourni comme exemple avec povray. La ligne de commande povray que nous avons lancée ci-dessus signifie “Rendre la scène d’exemple nommée chess2.pov dans un fichier png appelé chess.png à une résolution de 320x200”. On a donc validé que le lancement de l’application s’effectuait sans erreur sur une ressource de calcul de la grille CiGri. Nous allons passer à la préparation de la campagne.

Installer l’application (povray) sur les autres clusters de la grille

Afin de pouvoir exécuter povray à partir des noeuds de calcul de luke, nous avons créé un profil GUIX dédié sur luke HOME et nous y avons installé povray. Comme nous prévoyons d’utiliser les clusters luke + dahu + bigfoot pour notre campagne CiGri, nous devons faire en sorte de rendre le logiciel povray disponible sur chacun de ces clusters.

1) Cas des clusters dahu et bigfoot : Partage d’environnement Guix luke/dahu/bigfoot:

/var/guix/profiles/per-user/agalanlogin/ étant commun à luke, bigfoot et dahu (/var/guix est un montage summer), le profil créé est donc directement disponible depuis le cluster dahu aussi (à l’exception de la partition virgo de bigfoot, que nous excluerons de notre campagne):

# Sur la frontale dahu, on explore les profils existants, on retrouve bien ced_cigri qui vient d'être créé depuis luke:

lecoinal@f-dahu:~$ guix package --list-profiles
/var/guix/profiles/per-user/lecoinal/ced_cigri
/var/guix/profiles/per-user/lecoinal/ced_gnu
/var/guix/profiles/per-user/lecoinal/ced_io
/home/lecoinal/.config/guix/current
/home/lecoinal/.guix-profile
/var/guix/profiles/per-user/lecoinal/iworms-synthetic
/var/guix/profiles/per-user/lecoinal/prepobspy
/var/guix/profiles/per-user/lecoinal/resolve_gnuhdf5
[...]
lecoinal@f-dahu:~$ refresh_guix ced_cigri
Activate profile  /var/guix/profiles/per-user/lecoinal/ced_cigri
The following packages are currently installed in /var/guix/profiles/per-user/lecoinal/ced_cigri:
povray	3.7.0.8	out	/gnu/store/sgcsybpzkg9cn99fk0smwzimaw4m2b9b-povray-3.7.0.8
lecoinal@f-dahu:~$ which povray
/var/guix/profiles/per-user/lecoinal/ced_cigri/bin/povray
lecoinal@f-dahu:~$

Nous n’avons donc rien à faire de particulier, l’environnement GUIX et le profil ced_cigri est déjà prêt pour dahu.

Remarque: il se peut que pour l’un des clusters grille (bigfoot ci-dessous par exemple), ce soit votre premier usage de GUIX. Dans ce cas il suffit de suivre les consignes et être patient:

agalanlogin@bigfoot:~$ source /applis/site/guix-start.sh 
This is your first usage of guix on this cluster, the setup must be initialized.
Be patient, this may take some time
Mise à jour du canal « guix » depuis le dépôt Git « https://git.savannah.gnu.org/git/guix.git »...
indexage des objets  27% [#####################################      
[...]

Préparation de la campagne de jobs CiGri

Le problème à résoudre:

Maintenant que nous avons testé povray sur un cluster, et créé un profil Guix dédié à la campagne povray sur luke|dahu|bigfoot, Voici ce que nous allons faire. Nous avons une scène 3D complexe qui nécessite beaucoup de calculs et nous voulons faire une animation de définition 640x400 basée sur un mouvement de caméra dans cette scène. Le mouvement est simple : la caméra tourne et s’élève lentement. Nous voulons faire 2 tours complets (2x360 degrés) et calculer un rendu de la scène pour chaque degré, donc une vidéo de 360x2+1=721 images. A 25 images/s, nous obtiendrons une vidéo de 28 secondes. Chaque job calcule une image, nous faisons donc une petite campagne de calcul sur grille de 721 jobs.

Voici un instantané de la scène :

plot benchmark

Cette image unique en résolution (640x400) a pris 2 minutes 45 seconds à calculer sur un coeur du noeud luke57.

Le code de la scène se trouve dans la distribution povray dans le fichier $GUIX_USER_PROFILE_DIR/ced_cigri/share/povray-3.7/scenes/advanced/benchmark/benchmark.pov. Nous allons éditer l’entête de ce fichier pour ajouter un paramètre d’horloge clock:

  • dans la définition de l’emplacement de la caméra (location <3.2, 3.2, 1.8+0.01*clock>),
  • dans la définition de la rotation (rotate <0,0,clock>) :

Depuis la frontale luke (ou dahu), on recopie localement le code de la scène benchmark.pov et le fichier d’initiatisation benchmark.ini:

> cd <chemin-vers>/trainings/grille
> cp $GUIX_USER_PROFILE_DIR/ced_cigri/share/povray-3.7/scenes/advanced/benchmark/benchmark.pov .
> cp $GUIX_USER_PROFILE_DIR/ced_cigri/share/povray-3.7/scenes/advanced/benchmark/benchmark.ini .

On ajoute le paramètre clock dans la position (location) et la rotation (rotate) de la camera (deux lignes à modifier/ajouter):

> chmod +w benchmark.pov   # il faut pouvoir éditer benchmark.pov
> vi benchmark.pov
     [...]
 213 camera {
 214    location  <3.2, 3.2, 1.8+0.01*clock>
 215    direction y
 216    sky       z
 217    up        z
 218    right    -x*image_width/image_height // keep propotions with any aspect ratio
 219    // right     -x
 220    look_at   <-1, -1, 0.9>
 221    angle     45
        rotate <0,0,clock>
 222 }
     [...]

Cette variable spéciale d’horloge (clock) est un paramètre que nous pouvons donner à povray avec l’option -K pour calculer une seule image pour une valeur de clock spécifique.

Données d’inputs:

Nous avons créé un fichier benchmark.pov qui doit être accessible depuis tous les clusters car ce sont les données d’entrée que chaque job va charger pour rendre une image. Nous allons utiliser le système de stockage distribué (IRODS Mantis2) pour répondre à ce besoin. Nous allons créer un répertoire dans le stockage distribué Mantis2 et y placer nos fichiers benchmark.pov et benchmark.ini (N’oubliez pas de remplacer lecoinal par votre login):

> ils
/mantis/home/lecoinal:
> imkdir /mantis/home/lecoinal/povray
> iput benchmark.pov /mantis/home/lecoinal/povray/.
> iput benchmark.ini /mantis/home/lecoinal/povray/.
> ils /mantis/home/lecoinal/povray  
/mantis/home/lecoinal/povray:
  benchmark.ini
  benchmark.pov
# Nous pouvons maintenant supprimer localement ces données d'input:
> rm ./benchmark.ini ./benchmark.pov

Ces données d’inputs seront maintenant accessibles depuis n’importe quel cluster de la grille CiGri.

Script de lancement:

Nous préparons maintenant un script de lancement, et nous testons son lancement en interactif sur un coeur de luke (ou dahu).

Nous utilisons ce script de lancement: start.bash.

Ce script start.bash (prenez le temps de l’ouvrir pour le lire en détail) prend 5 arguments en entrée:

  • output_file : nom du fichier image png à créer
  • input_file : nom du fichier de définition povray (fichier .pov)
  • x_size : résolution x de l’image
  • y_size : résolution y de l’image
  • clock : paramètre d’horloge (option -K de povray)

Ce script charge l’environnement GUIX et se place sur le profil ced_cigri.

Il est intéressant de noter que ce script ne contient pas d’entête OAR. En effet, CiGri lancera bien ce script avec oarsub, mais CiGri passera les options OAR en ligne de commande, car ces options OAR seront définies une et une seule fois par cluster, et seront définies dans un fichier jdl présent sur l’hôte CiGri (killeen ou ciment-grid.u-ga.fr). Nous expliciterons plus tard ce fichier jdl.

Nous rapatrions les données d’inputs (dans le $HOME car c’est la que le script de soumission les attend) et testons ce script sur un noeud de calcul en interactif:

> source /applis/site/guix-start.sh   # pour avoir les i-commandes
> cd $HOME
> iget -rf povray        # get the materials benchmark.pov and benchmark.ini
> # Nous demandons maintenant une ressource en interactif 
> oarsub -I --project formation-ced-calcul -l /core=1   # éventuellement -l /core=1,walltime=00:05:00 -t devel si vous testez sur dahu
[... acces à un noeud de calcul ...]
> cd <chemin-vers>/trainings/grille
> chmod +x start.bash  # si nécessaire
> ./start.bash test.png benchmark.pov  320 200 1  # crée l'image de résolution 320x200 avec un paramètre clock=1
[...]
Render Time:
  Photon Time:      0 hours  0 minutes  1 seconds (1.449 seconds)
              using 35 thread(s) with 1.454 CPU-seconds total
  Radiosity Time:   No radiosity
  Trace Time:       0 hours  0 minutes 43 seconds (43.583 seconds)
              using 32 thread(s) with 43.424 CPU-seconds total
POV-Ray finished
> exit  # on quitte le noeud de calcul
# retour sur la frontale
> ils -l /mantis/home/lecoinal/povray_results
/mantis/home/lecoinal/povray_results:
  lecoinal          0 imag;nigel3-r2-pt;nigel3-r2       137169 2021-04-28.10:39 & test.png

# l'image obtenue a bien été exportée sur irods, dans le dossier povray_results, sa taille est 137169 octets.

# on peut nettoyer les résultats sur Mantis
> irm -r povray_results
# on peut aussi nettoyer le répertoire de travail local dans le home
> cd $HOME
> rm -r povray

Ce script start.bash se place dans le répertoire de travail povray ($RUN_DIR), et y exécute la commande povray avec les 5 bons paramètres pour génèrer l’image test.png. Puis il exporte cette image dans povray_results sur Mantis, et nettoie localement (image locale test.png, fichiers stdout et stderr).

Remarque concernant ce répertoire de travail povray: Il aurait été possible de faire rapatrier ces données d’input (benchmark.ini et benchmark.pov) par le script start.bash (ci-dessus nous l’avons fait manuellement iget -r povray, avant de lancer le script en interactif). En effet, dans la campagne CiGri que nous souhaitons effectuer, les 2 fichiers d’inputs sont communs à tous les jobs CiGri. Il ne sera donc pas nécessaire que chaque job rapatrie ses propres inputs (cela occasionnerait une surcharge inutile en terme d’IO entre Mantis et l’espace de travail local). Nous verrons plus tard le concept de prologue d’une campagne CiGri qui permet d’effectuer une seule fois une action unique sur chaque cluster cible, avant d’y lancer des jobs.

Donc ce script start.bash fonctionne. Nous pouvons le pousser sur irods afin de le rendre disponible depuis chaque cluster :

> iput start.bash /mantis/home/lecoinal/povray/.
# notre espace irods contient donc maintenant:
> ils    
/mantis/home/lecoinal:
  C- /mantis/home/lecoinal/povray
> ils /mantis/home/lecoinal/povray
/mantis/home/lecoinal/povray:
  benchmark.ini
  benchmark.pov
  start.bash
>

Le fichier de paramètres de la campagne CiGri

Maintenant nous préparons la campagne CiGri. Nous allons donc sur la frontale CiGri : killeen

> ssh killeen.ciment

Nous devons définir les tâches (les jobs) qui composeront la campagne de calcul sur grille. Pour cela, CiGri lit un fichier de paramètres qui contient une ligne par job. Une ligne est simplement l’argument qui est donné à votre application (ou au script de lancement start.bash). Le nom du fichier de paramètres est celui que vous voulez. Le premier paramètre d’une ligne doit toujours être un nom unique pour chaque tâche (car CiGri utilise la première colonne pour identifier les jobs dans sa base de données). Ainsi, notre fichier de paramètres devrait ressembler à ceci :

benchmark_0000.png benchmark.pov 640 400 0
benchmark_0001.png benchmark.pov 640 400 1
benchmark_0002.png benchmark.pov 640 400 2
...
benchmark_0720.png benchmark.pov 640 400 720

Si vous vous souvenez les arguments passés à start.bash, pour mémoire :

./start.bash test.png benchmark.pov  320 200 1
# puis dans le script de soumission, on a:
povray +W${3} +H${4} -K$5 +O${1} ${2}

On a donc :

  • le nom du fichier d’output (png) en premier argument $1;
  • le fichier code de la scène en deuxième argument $2;
  • la résolution x et y en troisième et quatrième argument $3 et $4;
  • le paramètre clock en cinquième argument $5.

Voici une façon de le construire automatiquement, depuis la frontale de la grille (killeen) :

agalanlogin@killeen3:~$ for i in `seq 0 720` ; do printf "benchmark_%0.4d.png benchmark.pov 640 400 $i\n" $i ; done > povray_params.txt

Ceci a créé comme par magie le fichier povray_params.txt dans votre $HOME sur la frontale killeen.

NB: Si on fixe la résolution des images à 1280x720, les jobs durent 10min environ sur luke et dahu. A voir au moment du TP, si les clusters luke et dahu sont bien chargés, il peut être judicieux d’abaisser la resolution des images à 640x400 (jobs de ~200sec) afin de finir le TP rapidement.

Le fichier de description de la campagne (le fichier JDL)

L’étape principale avant de soumettre une campagne CiGri est de rédiger un fichier JDL (Job Description Langage). C’est un fichier de configuration au format JSON qui donne les consignes à CiGri. Nous utiliserons le fichier povray.jdl.

Dans ce fichier, il y a des options globales au début (le nom du fichier de paramètres et un nom pour la campagne de calcul sur grille). Ensuite, il y a une option appelée “clusters” qui définit une section pour chaque cluster de la grille que nous voulons utiliser. Dans chaque section de cluster, nous donnons le nom du cluster et les options qui peuvent remplacer les options par défaut données précédemment. Ici, nous définissons un walltime et le projet pour chaque cluster.

Jetons un coup d’oeil à certaines options particulières :

  • prologue : cette section définit un script bash qui sera exécuté une fois au tout début de la campagne sur la frontale de chaque cluster. Il s’agit d’un ensemble de commandes bash. Ici, nous utilisons ce prologue pour initialiser notre répertoire de travail depuis le stockage distribué, qui contient également le script que nous voulons lancer (start.bash). Nous créons également un répertoire dans irods pour y pousser des résultats (les fichiers png). Le prologue peut être redéfini dans une section du cluster. Notez que {CIGRI_CAMPAIGN_ID} et {HOME} sont des variables macro qui seront remplacées respectivement par l’id de la campagne en cours et le répertoire personnel de l’utilisateur qui soumet la campagne.
  • resources : dans la section principale, elle définit les ressources nécessaires pour vos travaux. Cette option a le même format que l’option --resource ou -l de la commande oarsub. Ici, nos jobs povray vont utiliser un seul cpu-core par processus.
  • test_mode : quand cette option est mise à “true”, cela signifie que vous allez lancer un seul job à la fois sur chaque cluster.
  • exec_file : ceci donne le chemin complet de l’application à lancer. Ici, nous donnons le chemin de notre script de lancement start.bash que nous venons de créer précédemment et qui sera récupéré de irods par le prologue.
  • type : généralement, vous utiliserez le type best-effort, mais cigriv3 pourrait aussi lancer des jobs normaux si vous êtes autorisé à le faire sur un cluster spécifique.

Maintenant, imaginons ce que cigri va faire : si le premier job est lancé sur dahu, la commande de soumission que cigri va générer ressemblera à ceci :

oarsub -l /core=1,walltime=00:10:00 --project=formation-ced-calcul "$HOME/povray/start.bash benchmark_0000.png benchmark.pov 1280 720 0"

Ensuite, si le deuxième travail est exécuté sur luke, il ressemblera à ceci :

oarsub -l /core=1,walltime=00:15:00 --project=formation-ced-calcul "$HOME/povray/start.bash benchmark_0001.png benchmark.pov 1280 720 1"

Et CiGri va générer autant de jobs qu’il y a de lignes dans le fichier param_file. Mais CiGri ne va pas envoyer tous les jobs en même temps. Cigri prend soin de ne pas surcharger les clusters. De plus, CiGri va automatiquement resoumettre les jobs tués ou vous avertir si un job a échoué.

Maintenant, copiez (plusieurs solutions: rsync, scp, Mantis, …) ce fichier JDL dans votre répertoire personnel de l’hôte de la grille (killeen) et nommez-le comme vous le souhaitez, par exemple povray.jdl.

Résumé: quels fichiers à quel endroit?

Dans votre HOME sur l’hôte CiGri (killeen) se trouvent:

  • povray_params.txt : le fichier de decription des paramètres des jobs de votre campagne : 1 ligne par job, et la première colonne sert d’identifiant de job CiGri, les valeurs le long de cette première colonne doivent être unique.
  • povray.jdl : le fichier de description de la campagne CiGri.

Dans le HOME des clusters cibles se trouvent:

  • le script de lancement d’un job : start.bash.
  • le ou les fichiers de configuration d’un job : benchmark.pov et benchmark.ini.

Ces fichiers sont poussés sur Mantis, et le prologue de la campagne se charge de les rapatrier sur chaque HOME de chaque cluster. Ainsi l’utilisateur n’a pas à dupliquer ces fichiers sur les HOME de chaque cluster cible.

Lancement et monitoring de la campagne CiGri

Notifications CiGri

CiGri offre un système de notification personnalisable. Cela signifie que si vous voulez que CiGri vous notifie lorsqu’un problème survient, ou simplement lorsque vos campagnes de travaux sont terminées, vous devez lui indiquer comment vous voulez être notifié. Actuellement, CiGri propose 2 méthodes :

  • notifications jabber : si vous utilisez un client de messagerie instantanée (comme gtalk), vous pouvez être notifié sur le compte spécifié
  • notifications par mail : cigri envoie des e-mails à l’adresse spécifiée.

Pour cet exemple, nous allons utiliser les notifications par e-mail, avec un niveau de sévérité faible afin d’être notifié de tous les événements qui se produisent. Depuis l’hôte de la grille, entrez la commande suivante:

# sur killeen
> gridnotify -m <your@email> -s low

Premier lancement de la campagne: le mode test

Nous allons faire notre premier lancement dans le mode test_mode comme vu précédemment dans le fichier JDL. Dans ce mode :

  • Un seul job par cluster est lancé. De cette façon, s’il y a une erreur dans le script de lancement de l’application, cela ne générera qu’une seule erreur.
  • Les travaux sont lancés avec une priorité très élevée. Cela signifie que si d’autres utilisateurs ont des campagnes en cours sur la grille, vous n’allez pas attendre la fin de leur campagne pour faire votre test.
# sur killeen
> gridsub -f povray.jdl
Campaign successfully submitted
CAMPAIGN_ID=19288

Vous pouvez vérifier le statut de votre nouvelle campagne sur la grille avec la commande gridstat qui affiche une liste des campagnes en cours:

> gridstat
Campaign id Name                User             Submission time     S  Progress
----------- ------------------- ---------------- ------------------- -- --------
[...]
19288       povray_demo         lecoinal         2021-04-28 11-29-42 R  0/721 (0%)

Si tout va bien, vous devriez voir “R” comme statut, et après un certain temps, le nombre de travaux terminés devrait augmenter. Vous pouvez voir plus de détails avec l’option -f de gridstat :

> gridstat -fc 19288 |less
Campaign: 19288
  Name: povray_demo
  User: lecoinal
  Date: 2021-04-28 11-29-42
  State: in_treatment  
  Progress: 0/721 (0%)
  Stats: 
    average_jobs_duration: 14.0
    stddev_jobs_duration: 
    jobs_throughput: ~ jobs/h
    remaining_time: ~ hours
    failures_rate: 0.0 %
    resubmit_rate: 0.0 %
  Clusters: 
    luke:
      active_jobs: 0
      queued_jobs: 1
      prologue_ok: true
      epilogue_ok: true
    dahu:
      active_jobs: 1
      queued_jobs: 0
      prologue_ok: true
      epilogue_ok: true

 Jobs:
  194250387: 38306637,15820850,running,dahu,benchmark_0000.png,benchmark_0000.png benchmark.pov 1280 720 0
  194250388: *,*,pending,*,benchmark_0001.png,benchmark_0001.png benchmark.pov 1280 720 1
  194250389: *,*,pending,*,benchmark_0002.png,benchmark_0002.png benchmark.pov 1280 720 2
[...]

Comme nous sommes en mode test, il n’y a qu’un seul travail qui est “en file d’attente” ou “en cours d’exécution” à la fois sur un cluster donné.

Si quelque chose se passe mal, vous verrez la lettre “e” dans la colonne d’état, ce qui signifie qu’il y a au moins un événement. Un événement signifie généralement qu’un job s’est terminé avec une erreur (statut non nul). Lorsqu’un événement se produit, il entraîne généralement un blacklist du cluster concerné pour votre campagne jusqu’à ce que vous corrigiez l’événement. De tels événements sont notifiés à l’adresse que vous avez souscrite avec la commande gridnotify.

Pour voir les détails des événements en cours sur une campagne en cours, vous pouvez utiliser la commande gridevents, depuis l’hôte CiGri :

> gridevents -c 19288
------------------------------------------------------------------------------
28312354: (open) PROLOG_EXIT_ERROR of job 38302881 at 2021-04-27T18:58:52+02:00 on dahu
The job exited with exit status 1792;
Last 5 lines of stderr_file:
[-]	/tmp/nix-build-irods-4.2.7.drv-0/source/plugins/auth/native/libnative.cpp:342:irods::error native_auth_client_response(irods::plugin_context &, rcComm_t *) :  status [CAT_INVALID_AUTHENTICATION]  errno [] -- message [Call to rcAuthResponseFailed.]

 failed with error -826000 CAT_INVALID_AUTHENTICATION 
------------------------------------------------------------------------------
28312355: (open) BLACKLIST at 2021-04-27T18:58:52+02:00 on dahu because of 28312354
------------------------------------------------------------------------------

Ici il y a eu un problème sur dahu, j’ai oublié de faire le iinit. Il faut donc retourner sur la frontale de dahu, faire le iinit, puis fixer l’évènement (depuis killeen), et la campagne repartira pour dahu.

Donc, supposons que j’ai réparé mon erreur et réactivé l’authentification d’irods sur dahu. Je dois alors corriger l’événement. Mais si je ne fais que corriger, le travail erroné est perdu ! Donc, tout en corrigeant, je vais aussi demander une re-soumission. Cela se fait de cette façon :

> gridevents -rfe 28312354

L’option -f permet de corriger l’événement, et l’option -r permet de soumettre à nouveau le travail impliqué dans cet événement. Ensuite, nous donnons l’identifiant de l’événement avec l’option -e.

> gridevents -c 19288
------------------------------------------------------------------------------
28312355: (open) BLACKLIST at 2021-04-27T18:58:52+02:00 on dahu because of 28312354
------------------------------------------------------------------------------

Nous pouvons voir que l’événement dahu a disparu, mais que la liste noire est toujours là. Mais normalement, la blacklist de dahu disparaîtra aussi, lorsque CiGri prendra en compte notre action. Quelques secondes plus tard :

> gridevents -c 19288
No events!

et la campagne repart pour le cluster dahu.

Suppression de la campagne

Maintenant que nous avons tout réglé et validé que notre campagne de test tourne, nous voulons annuler cette campagne test (qui tourne lentement, car un seul job à la fois par cluster), pour en redémarrer une nouvelle après avoir désactivé le mode test. Pour tuer une campagne et tous les travaux en attente et en cours, nous utilisons la commande griddel :

# sur killeen
> griddel 19288

Soumission en mode normal

Nous editons povray.jdl et remplacons test_mode par la valeur false

# sur la frontale CiGri (killeen)
> vi povray.jdl
[...]
 "test_mode": "false",
[...]

et nous resoumettons la campagne:

> gridsub -f povray.jdl
Campaign successfully submitted
CAMPAIGN_ID=19289

Maintenant nous observons qu’il y a plus d’un job à la fois par cluster:

> gridstat -fc 19289|less
Campaign: 19289
  Name: povray_demo
  User: lecoinal
  Date: 2021-04-28 11-54-13
  State: in_treatment  
  Progress: 0/721 (0%)
  Stats: 
    average_jobs_duration: 
    stddev_jobs_duration: 
    jobs_throughput: ~ jobs/h
    remaining_time: ~ hours
    failures_rate: 0.0 %
    resubmit_rate: 0.0 %
  Clusters: 
    luke:
      active_jobs: 0
      queued_jobs: 15
      prologue_ok: true
      epilogue_ok: true
    dahu:
      active_jobs: 124
      queued_jobs: 582
      prologue_ok: true
      epilogue_ok: true

 Jobs:
  194251108: 38307207,15820916,running,dahu,benchmark_0000.png,benchmark_0000.png benchmark.pov 1280 720 0
  194251109: 38307208,15820917,running,dahu,benchmark_0001.png,benchmark_0001.png benchmark.pov 1280 720 1
  194251110: 38307209,15820918,running,dahu,benchmark_0002.png,benchmark_0002.pn:
[...]

Quand tous les jobs ont été effectués, la campagne passe dans l’état Terminé:

Campaign: 19289
  Name: povray_demo
  User: lecoinal
  Date: 2021-04-28 11-54-13
  State: terminated  
  Progress: 721/721 (100%)
  Stats: 
    average_jobs_duration: 651.693481276006
    stddev_jobs_duration: 91.006862221132
    jobs_throughput: 2458.0 jobs/h
    remaining_time: 0.0 hours
    failures_rate: 0.7 %
    resubmit_rate: 0.7 %
  Clusters: 
    luke:
      active_jobs: 0
      queued_jobs: 0
      prologue_ok: true
      epilogue_ok: true
    dahu:
      active_jobs: 0
      queued_jobs: 0
      prologue_ok: true
      epilogue_ok: true

 Jobs:
  194251108: 38307207,15820916,terminated,dahu,benchmark_0000.png,benchmark_0000.png benchmark.pov 1280 720 0
  194251109: 38307208,15820917,terminated,dahu,benchmark_0001.png,benchmark_0001.png benchmark.pov 1280 720 1
  194251110: 38307209,15820918,terminated,dahu,benchmark_0002.png,benchmark_0002.png benchmark.pov 1280 720 2
  [...]

Postprocess des résultats

Si tout se passe bien, quand la campagne est terminée, vous devez obtenir 721 fichiers png dans Mantis2:

> ils povray_results/19289
/mantis/home/lecoinal/povray_results/19289:
  benchmark_0000.png
  benchmark_0001.png
  benchmark_0002.png
  benchmark_0003.png
  benchmark_0004.png
  benchmark_0005.png
  [...]
  benchmark_0720.png

Pour en construire un film, nous rapatrions toutes ces images sur le $SHARED_SCRATCH_DIR /bettik et utilisons ffmpeg pour assembler ces images dans un film:

# depuis luke ou dahu, en interactif
> source /applis/site/guix-start.sh
> refresh_guix ced_cigri
> cd /bettik/agalanlogin/tmp   # mkdir si besoin
> iget -rv povray_results/19289
> guix install -p $GUIX_USER_PROFILE_DIR/ced_cigri ffmpeg
guix install: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

The following package will be installed:
   ffmpeg 4.4.1
[...]

> refresh_guix ced_cigri
Activate profile  /var/guix/profiles/per-user/lecoinal/ced_cigri
The following packages are currently installed in /var/guix/profiles/per-user/lecoinal/ced_cigri:
povray	3.7.0.8	out	/gnu/store/sgcsybpzkg9cn99fk0smwzimaw4m2b9b-povray-3.7.0.8
ffmpeg	4.4.1  	out	/gnu/store/0sangid91i3vfxabkj3gd7amn0kb5w3d-ffmpeg-4.4.1
> cd 19289
> ls -1 | wc -l     # on obtient bien 721 fichiers images
721
> ffmpeg -r 25/1 -i benchmark_%04d.png -c:v libx264 -vf "fps=25,format=yuv420p" out.mp4
> ls -lh out.mp4
-rw-r--r-- 1 lecoinal l-isterre   30M Apr 28 12:28 out.mp4   # pour une resolution d'image 1280x720

Puis vous pouvez rapatrier ce film sur votre machine locale pour le visualiser (avec vlc ou autre…)

Nettoyage des espaces

On pense à nettoyer les espaces après avoir travaillé.

Sur Mantis2:

> irm -r povray_results

Sur /bettik (la ou vous avez construit le film):

> rm -r /bettik/<agalanlogin>/tmp

Sur les HOME des clusters cible (ici luke et dahu et bigfoot):

il peut rester des résidus correspondant à des jobs qui ont été best-effort killés. Par exemple pour dahu :

lecoinal@f-dahu:~/povray$ ls -1
OAR.cigri.19288.15820855.stderr
OAR.cigri.19288.15820855.stdout
OAR.cigri.19289.15821011.stderr
OAR.cigri.19289.15821011.stdout
OAR.cigri.19289.15821029.stderr
OAR.cigri.19289.15821029.stdout
OAR.cigri.19289.15821346.stderr
OAR.cigri.19289.15821346.stdout
OAR.cigri.19289.15821347.stderr
OAR.cigri.19289.15821347.stdout
OAR.cigri.19289.15821398.stderr
OAR.cigri.19289.15821398.stdout
benchmark.ini
benchmark.pov
benchmark_0255.pov-state
benchmark_0259.pov-state
benchmark_0579.png
benchmark_0707.pov-state
benchmark_0709.pov-state
benchmark_0711.pov-state
benchmark_0713.pov-state
benchmark_0715.pov-state
start.bash

On trouve ces deux fichiers :

OAR.cigri.19288.15820855.stderr / stdout

Il s’agit du job de la campagne en mode test_mode=true. Au moment ou l’on a supprimé cette campagne 19288, un job était en train de tourner, il n’a pas été au bout, il ne s’est donc pas auto-nettoyé (rappelez vous le rm OAR.cigri....std... en fin de start.bash)

On trouve aussi ces fichiers :

OAR.cigri.19289.xxxxxxxx.stderr / stdout
benchmark_yyyy.pov-state

Il s’agit de résidus de jobs best-effort killés, avec leurs images d’output incompletes.

On trouve enfin un fichier :

benchmark_0579.png

Il s’agit certainement d’un job besteffort-killé très peu de temps avant la fin. Image complète, mais pas eu le temps d’exporter vers Mantis2 (pas de chance). Et vraisemblablement, le job pour construire cette image 0579 a été resoumis sur l’autre cluster. Car s’il avait été resoumis sur ce même cluster, le png aurait été nettoyé lors du job complété en entier.

On peut donc nettoyer l’ensemble de tous ces résidus de campagne:

> rm OAR.cigri.*std* benchmark_*png benchmark_*.pov-state

Et faire de même sur tous les clusters utilisés.

Notes:

Bigfoot et les campagnes CiGri de jobs de type “normal”

Pour l’utilisation du cluster bigfoot en mode normal (c’est à dire en non best-effort, donc dans le cas où "type": "normal", dans le fichier JDL), il faut spécifier /gpu=1 dans les ressources demandées. C’est à dire que le champ resources ne peut pas être commun à tous les clusters ciblés, il faut indiquer "resources": "/nodes=1,gpu=1,core=1", pour le cluster bigfoot et "resources": "/core=1", pour les autres clusters.

Partition virgo (gpumodel T4) de Bigfoot

Dans ce tutoriel nous n’utilisons pas les ressources virgo de bigfoot car GUIX n’y est pas installé. C’est pour cela que le fichier jdl indique :

  "clusters": {
    [...]
    "bigfoot": {
      [...]
      "properties": "gpumodel!='T4'"
    }
  }

Du bon usage du WORKDIR

Dans ce tutoriel, pour simplifier nous travaillons dans les HOME des clusters (au RUNTIME d’un job, pendant sa durée d’exécution). Il est conseillé de plutôt travailler dans des espaces scratch (non sauvegardés, plus efficaces en IO, …). Il est possible d’utiliser les scratch distribués de chaque cluster ($SHARED_SCRATCH_DIR/$USER), ou les scratch locaux à chaque noeud ($LOCAL_SCRATCH_DIR/$USER). Attention à la volumétrie disponible dans le cas d’un usage de scratch locaux.

Merci à Albanne Lecointre pour cette page de documentation !