Prise en main rapide de la grille de calcul CiGri

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 :

  • tester votre application sur un cluster : faire un script de démarrage
  • [optionnel] adapter le script de démarrage afin qu’il puisse s’exécuter sur chacun des clusters de la grille
  • déployer votre application sur la grille : créer un fichier de paramètres et un fichier de description de la campagne
  • démarrer et surveiller vos tâches, obtenir les résultats

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 test).

Être 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 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

[Optionnel] Avoir accès à un espace de stockage commun

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.

Préparation de la campagne de jobs CiGri

Code applicatif

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

Fichiers de campagne CiGri

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

Le fichier de paramètres de la campagne CiGri

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

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

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

  • name Le nom de la campagne, il est arbitraire.
  • clusters Une liste des clusters utilisés que nous détaillerons après.
  • param_file Vous utiliserez toujours ce paramètre pour le troisième champ obligatoire, les autres étant soit réservés à des usages très spécifiques sortant du cadre de l’utilisation nomale des ressources ou des fonctionalités plus basiques que param_file.

Les autres champs ne sont pas obligatoires mais sont utiles en fonctionnement normal.

  • resources : Ce paramètre est l’équivalent de -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.
  • project : Le projet Perseus.
  • exec_directory : Le répertoire d’exécution.
  • exec_file : Le fichier qui sera exécuté pour lancer le traitement.
  • test_mode : Positionnée sur “true”, un seul des jobs pour chaque cluster sera exécuté, en mode normal à haute priorité, pour valider le fonctionnement.
  • type : Par défaut à “best-effort”, géré automatiquement par CiGri. Ignoré en mode test.
  • prologue : Une liste de commandes exécutées une seule fois au début de la campagne sur chaque cluster, utile par exemple pour préparer l’environnement d’exécution de la campagne.
  • epilogue : Une liste de commandes exécutées une seule fois à la fin de la campagne sur chaque cluster, utile par exemple pour nettoyer l’environnement utilisateur à la fin de la campagne.

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.

Résumé: quels fichiers à quel endroit ?

Sur l’hôte CiGri (killeen) se trouvent:

  • Le fichier de decription des paramètres des jobs de votre campagne (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.
  • Le fichier JDL de description de la campagne CiGri (cigri-short.jdl dans notre exemple).

Dans un dossier accessible depuis les clusters cibles se trouvent:

  • Le script de lancement des jobs (start.sh dans notre exemple).
  • [optionnel] Le ou les fichiers de configuration des jobs.

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

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

Pour aller plus loin

Le tutoriel complet avec un exemple utilisant Guix et Mantis.

Le serveur ciment-grid.

Le code source et sa documentation.