CiGri

Fiche logiciel validé
  • Création ou MAJ importante : 27/02/12
  • Correction mineure : 09/01/13
  • Rédacteur de la fiche : Bruno Bzeznik - un des développeurs de CiGri - LIG (Université Joseph Fourier (Grenoble I))
  • Relecteur(s) : Pierre Girard (Centre de Calcul de l'IN2P3/CNRS)
    Nadia Lajili (CC IN2P3)
  • Responsable thématique : Geneviève Romier (Institut des Grilles et du Cloud)
Mots-clés
Pour aller plus loin

CiGri : grille de calcul “légère”

Une fiche Dév Ens Sup est en relation avec cette fiche, consultez-la pour plus d'informations : CiGri
Description
Fonctionnalités générales

CiGri permet de mettre en place une grille de calcul capable d'exploiter les ressources disponibles d’un ensemble de calculateurs préexistants. Il est spécialisé dans la gestion de grandes campagnes de jobs de type "bag-of-tasks" (sac de taches). Les campagnes de ce type sont composées de nombreuses taches (plus de 100000 par exemple) indépendantes. Il peut s'agir de simulations monte-carlo ou de taches paramétriques (un résultat doit être évalué pour de nombreuses valeurs d'un ou plusieurs paramètres).
Le fonctionnement de CiGri repose sur l'utilisation du gestionnaire de ressources OAR (voir la fiche plume OAR) qui est déployé au dessus des infrastructures de calcul existantes. Utilisé dans le mode “best-effort” ("au mieux"), OAR affecte et libère les ressources de calcul de façon à ce que CiGri ne les utilise jamais aux dépens d'un usage local. De ce fait, une tâche "grille" peut donc être tuée sans préavis. Elle sera soumise à nouveau dès qu'une nouvelle ressource sera disponible.

Par opposition à d'autres intergiciels de grille, comme Globus, Glite, etc., CiGri se veut un outil pour la mise en place de grilles de calcul dites "légères". Notamment, il ne propose pas de modèle complexe d'authentification/autorisation des utilisateurs mais repose simplement sur une gestion classique de comptes locaux qui doit être commune aux différents calculateurs intégrés à la grille. Cette gestion de comptes peut être unifiée par la mise en place d'un annuaire LDAP commun aux calculateurs.

Privilégiant la confiance dans la collaboration entre sites, CiGri convient particulièrement à des structures de type "mésocentre" (par exemple CIMENT : https://ciment.ujf-grenoble.fr ou FLCHP : http://www.flchp.univ-lyon1.fr/).

Le modèle de communication et de sécurité de CIGRI repose actuellement sur l'utilisation de SSH et de SUDO. Le logiciel OAR proposera bientôt une API qui permettera à CiGri de communiquer sur HTTPS avec éventuellement des certificats au lieu du couple SSH/SUDO.

L'architecture est centralisée, c'est à dire qu'il y a un serveur CIGRI central depuis lequel les utilisateurs soumettent les jobs et suivent l'évolution de ces derniers.

Une gestion évoluée des évènements assure un fonctionnement optimum: les jobs tués sont soumis à nouveau automatiquement, les erreurs survenues sur un calculateur donné peuvent suspendre ce calculateur de la grille (blacklist) et l'utilisateur en est informé par mail si nécessaire, certains évènement temporaires sont pris en compte (indisponibilité réseau passagère), etc...

La mise en oeuvre de CiGri nécessite que OAR soit installé sur les grappes de la grille, mais celui-ci peut être couplé à un autre gestionnaire de batch si nécessaire. Des couplages ont déja été testés avec SGE, PBSPro et Torque. Le reste de la mise en oeuvre est simple puisque les communications s'appuient sur "ssh" et l'authentification sur "sudo".

Même si CiGri ne gère qu'un type précis de calculs (sacs de taches), elle permet de décharger localement les grappes de ces taches en les passant à un niveau plus transparent réparti sur les différentes grappes d'un mesocentre de calcul.

Caractéristiques principales:

  • Supporte des grands ensembles de taches (>100k) appelés "campagnes de jobs".
  • Traitement des erreurs, re-soumissions automatiques.
  • Checkpointing (expérimental).
  • Collecte automatique des résultats.
  • Interface web pour la gestion des campagnes de jobs.
  • Estimation de la durée des campagnes.
  • Authentification LDAP possible.
  • Synchronisation automatique de fichiers en début de campagne.
  • Meta-ordonnanceur permettant la création d'ordonnanceurs spécifiques.
  • Ordonnanceur FIFO (premier arrivé, premier servi).
  • Prise en compte des campagnes de mise au point (éxécution d'une seule tache par cluster avec priorité ultra élevée).
  • Support des tâches parallèles (utilisant plusieurs noeuds d'un calculateur distribué, dans une certaine mesure car plus ces tâches sont grandes et moins CiGri sera efficace à cause du taux de re-soumission).
Autres fonctionnalités
  • Enregistrement et affichage de statistiques sur l'utilisation des grappes de la grille
  • Supervision des grappes de la grille
  • En cours de développement :
    • Gestion de priorités entre utilisateurs.
    • Support des contraintes sur les ressources (exemple: "mon job ne fonctionne que sur des machines qui ont au moins 2Go de RAM").
    • API RestFul
  • Groupement des tâches courtes (optimisation, réduction du temps de soumission)
  • Ce que CIGRI NE FAIT PAS :
    • Déploiement des applications : les utilisateurs (ou administrateurs) doivent installer les applications sur chaque cluster potentiellement exploité par une campagne.
    • Gestion des données d'entrée : les données doivent être accessibles sur tous les clusters d'une campagne. Des solutions pragmatiques sont disponibles, comme l'exploitation d'un système de gestion de données distribuées: IRODS (http://www.irods.org). Le projet CIMENT a l'expérience de cette solution couplée à CiGri.
    • Les aspects dépendances des tâches par rapport aux données ne sont pas écartés, mais leur complexité les rends peu prioritaires dans nos développements.
Interopérabilité

CiGri s'appuie sur le gestionnaire de batch OAR qui doit être installé sur les grappes de la grille. Mais ce dernier peut-être facilement couplé en mode meilleurs effort avec d'autres gestionnaires. Cela a déja été réalisé avec SGE, PBSPro et Torque.

La définition d'une campagne de taches est faite dans un fichier au format JDL (Job Description Language). Toutes les données de la grille (jobs, ressources, grappes, évènements,...) sont stockées dans une base SQL, ce qui rend facile l'exploitation de ces données par des logiciels tiers (interfaçage graphique, scripts, ...)

Contexte d'utilisation dans mon laboratoire/service

Le logiciel CiGri est utilisé sur toutes les grappes du mesocentre de calcul de l'Université Joseph Fourier (CIMENT) depuis 2002. Entre 2002 et 2008, cette grille a exécuté plus de 3 millions de taches. Elle exploite actuellement (fin 2008) près de 2000 coeurs de processeurs répartis sur 13 grappes. Les applications touchent des domaines très variés, comme l'astrophysique, la biologie ou l'imagerie médicale. Les utilisateurs sont satisfaits par la facilité d'usage et l'efficacité du système. Les administrateurs sont satisfaits de l'optimisation des machines qui est obtenue.

Limitations, difficultés, fonctionnalités importantes non couvertes

L'installation consiste essentiellement en un travail de configuration (sudo, ssh, ...) à effectuer sur le serveur central et sur les grappes. Si OAR n'est pas déja installé sur les grappes, il faudra d'abord satisfaire ce prérequis. Même si cela n'est pas trivial, c'est à la portée de tout administrateur système ayant des compétences sous Unix et c'est assez bien documenté (voir la fiche plume de OAR). L'installation de CiGri en lui-même est moins bien documentée que celle de OAR, mais la communauté de développeurs OAR/CiGri est prête à donner la main à qui le souhaite. Il ne faut pas hésiter à poser des questions sur la liste des utilisateurs de OAR car ce sont les mêmes personnes qui développent CiGri et qui répondront.

Environnement du logiciel
Plates-formes

Toute plateforme supportant Perl/MySQL/PHP

Logiciels connexes

Le gestionnaire de ressources OAR est nécessaire sur les grappes. C'est via OAR que la grille soumettra les taches. Cependant, OAR peut éventuellement être couplé à un autre gestionnaire de ressources.

Environnement de développement
Type de structure associée au développement

CiGri est développé au sein d'une équipe de recherche en informatique distribuée (LIG/MESCAL) en collaboration avec un mesocentre de calcul (CIMENT)

Eléments de pérennité

Utilisation importante dans l'université Joseph Fourier (projet CIMENT bénéficiant d'une ingénierie dédiée à CiGri).
CiGri est également une plateforme expérimentale pour la recherche en informatique distribuée et est le sujet de plusieurs publications.
CiGri fait l'objet d'un stage Google Summer of Code en 2009 (dans le cadre du projet OAR qui a obtenu 2 stages GSOC en 2008 et 4 stages GSOC en 2009).
CiGri a été choisi par la grille expérimentale française Grid5000 pour la gestion de ses jobs meilleurs-effort. Un développeur de Grid5000 contribue actuellement à temps partiel sur le développement de la prochaine version.
La version 3.0 est actuellement en cours d'écriture. Il s'agit d'une réécriture complète du code, dans un nouveau langage (Ruby). La nouvelle architecture du code inclue une API REST pour faciliter l'intégration à d'autres environnements tels que des portails de gestion de jobs. Cette réécriture est l'occasion de mettre en place des tests unitaires et une documentation de développements, nécessaires à la pérénité du code.

Références d'utilisateurs institutionnels

Université Joseph Fourier - CIMENT (Grenoble)
Fédération Lyonnaise de Calcul à Haute Performance (Lyon)
ENS Lyon (prochainement)
Slovak Academy of Sciences - Institute of Inorganic Chemistry (Slovaquie)
BRGM (Orléans)
GRID5000 (prochainement)

Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
Documentation utilisateur

Doc d'installation : voir le fichier INSTALL dans le répertoire Doc des sources
Doc d'utilisation : voir la page d'accueil de l'interface utilisateur une fois installée.
Support possible via l'ingénierie de CIMENT qui organise des TP. Contactez gridmaster [at] ujf-grenoble [dot] fr pour plus d'informations.

Divers (astuces, actualités, sécurité)

CiGri est actuellement en cours de réécriture complète. Le langage Perl a été abandonné au profit de Ruby. La structure générale du nouveau code est similaire (plusieurs modules communiquant via une base de données) mais de nouvelles techniques seront employées pour améliorer son évolutivité et sa stabilité, en particulier en utilisant des API RestFul. Cette réécriture va aussi permettre d'améliorer l'ordonnancement et d'apporter de nouvelles fonctionnalités qui sont nécessaires à une exploitation de CiGri au sein de Grid5000 en particulier.