L’objectif de ce tutoriel est de prendre en main, dans sa forme la plus simple, la grille de calcul CiGri. Il s’agit d’une version allégée de ce guide.
Les étapes sont généralement les suivantes :
Vous devez avoir un compte PERSEUS actif, et être membre d’au moins un projet actif (par exemple le projet test).
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.
L’hôte de soumission CiGri de GRICAD (appelé aussi la frontale CiGri) est la machine killeen.u-ga.fr alias cigri ou ciment-grid. Vous pouvez vous connecter à cet hôte avec ssh depuis votre machine locale de la même manière que pour accéder aux clusters
Dans la mesure où une des grandes forces de CiGri est de pouvoir exploiter de manière transparente et automatique le temps de calcul disponible sur tous les calculateurs auxquels il à accès, il peut être très intéressant de mettre toutes les données qui seront nécessaires sur un espace de stockage accessible depuis tous les clusters.
À l’heure actuelle, les clusters Dahu, Bigfoot et Luke ont tous accès à Bettik et Mantis, qui sont aussi disponibles depuis CiGri.
Nous nous limiterons ici à l’exploitation d’une ressource de stockage simple mais il faut adapter cet exemple en fonction de vos besoins et des infrastructures disponibles.
Nous allons utiliser un code extrêmement simple (la fonction système hostname qui renvoie le nom de l’hôte sur lequel elle est exécutée) pour nous abstraire de tous les aspects liés au fonctionnement du code sur les différents clusters.
Nous appellerons notre script de lancement start.sh :
#!/usr/bin/env bash
echo $(hostname)
Nous n’avons aucun output conservé ici ce qui simplifie l’exemple mais ne correspondra nécessairement pas à la réalité.
Nous allons simuler un exemple de campagne. Notre exemple ne prend aucun paramètre pour son lancement mais dans le cas d’une campagne CiGri ce seraient ces paramètres qui discrimineraient les jobs soumis.
Pour soumettre une campagne CiGri deux fichiers sont requis, le fichier de paramètres de la campagne CiGri et le fichier de description de la campagne (le fichier JDL).
Une campagne CiGri est un ensemble de jobs de calcul indépendants les uns des autres.
Ceux ci vont être définis dans un fichier de description de paramètres.
Ce fichier, au format texte simple (attention aux caractères spéciaux tels que les retours à la ligne sous Windows, CRLF, qui posent problème à l’interpréteur) avec un ensemble de paramètres de job par ligne. Une seule contrainte existe : le premier paramètre d’une ligne doit impérativement toujours être un nom unique.
Dans notre exemple extrêmement simple nous n’avons aucun paramètre à passer à notre code, nous allons donc mettre une valeur quelconque unique à chaque ligne dans un fichier que nous allons abitrairement nommer cigri-short-params.txt :
run01
run02
run03
L’orchestration des opérations de CiGri est faite grace à un fichier au format JDL (Job Description Language). Ce fichier suit la syntaxe JSON. Voici le fichier de notre exemple (nous l’appelerons cigri-short.jdl):
{
"name": "cigri-short",
"resources": "/core=1",
"project": "test",
"exec_directory": "{HOME}",
"exec_file": "{HOME}/start.sh",
"param_file": "{HOME}/cigri-short-params.txt",
"test_mode": "true",
"type": "best-effort",
"prologue": [
"ls",
"uptime"
],
"epilogue": [
"ls",
"uptime"
],
"clusters": {
"luke": {
"walltime": "00:10:00"
},
"bigfoot": {
"walltime": "00:05:00"
},
"dahu": {
"walltime": "00:05:00"
}
}
}
Du point de vue de la logique, nous pouvons découper ce fichier en deux parties: les directives générales et la définition des clusters à utiliser.
Trois paramètres sont obligatoires : name, clusters et un parmis param_file, nb_jobs' params ou “jobs_type”: “desktop_computing”.
Les autres champs ne sont pas obligatoires mais sont utiles en fonctionnement normal.
-l dans oarsub. Si la campagne doit tourner sur plusieurs clusters il faut que ce paramètre soit suffisamment générique pour fonctionner partout.Notez que nous les avons placés globalement mais ils peuvent aussi bien être définis au niveau de chaque entrée cluster.
La section cluster qui suit possède une entrée pour chaque cluster sur lequel faire tourner le code. Nous avons placé ici la variable walltime pour chaque cluster mais elle pourrait elle aussi être définie globalement tout comme les paramètres globaux qui peuvent être définis au niveau de chaque entrée de cluster.
Une documentation plus complète du fichier JDL se trouve sur le dépôt du code.
Sur l’hôte CiGri (killeen) se trouvent:
cigri-short-params.txt dans notre exemple) : 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.cigri-short.jdl dans notre exemple).Dans un dossier accessible depuis les clusters cibles se trouvent:
start.sh dans notre exemple).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 :
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
Lancement de la campagne
Sur killeen :
gridsub -f cigri-short.jdl
Si le lancement se passe bien vous aurez :
Campaign successfully submitted
CAMPAIGN_ID=xxxxxx
N’oubliez pas de modifier test_mode à false pour que votre campagne s’exécute normalement après une première exécution réussie en mode test.
Cet identifiant sera important pour toutes les autres commandes que vous pourrez utiliser sur le serveur pour suivre et interagir avec votre campagne.
L’ensemble de ces commandes est listé dans le dépôt du code.
La principale commande utile est gridstat, qui permet d’avoir la liste des campagnes en cours et leur état, indiqué dans la colonne S (‘R’ pour ‘Running’, T pour ‘Terminated’, ‘C’ pour ‘Canceled’, ‘P’ pour ‘Paused’. S’il y a un petit “e” à côté de la lettre de l’état, cela signifie qu’il y a des evènements en cours).
Le tutoriel complet avec un exemple utilisant Guix et Mantis.
Le code source et sa documentation.