Kali, simplifier l`utilisation des clusters HPC

Kali, simplifier l'utilisation des clusters HPC
Rémi Michelas, Marc Vesin, Laurent Mirtain
Service Informatique de Centre (SIC)
Inria Sophia Antipolis - Méditerranée
David Rey, Jean-Luc Szpyrka
Service d’Expérimentation et de Développement (SED)
Inria Sophia Antipolis - Méditerranée
Résumé
Titre alternatif : Kali, les clusters pour les nuls
Kali propose de simplifier et d'homogénéiser l'accès à des ressources de calcul distantes par le biais d'un
portail web. L'accès aux ressources en SSH au nom de l'utilisateur permet un impact minimal sur
l'administration des clusters et simplifie l’ajout de plateformes hétérogènes. Kali assure entre autres
l'inscription à de nouveaux clusters, la compilation des codes, la synchronisation des données ou encore
la gestion des tâches de calcul.
Kali peut être utile aux utilisateurs novices comme aux plus aguerris.
Mots-clefs
Portail web, Clusters, Mésocentre distribué, Frontal d'accès, Développement agile, Ruby on Rails,
Architecture MVC, Redis, Sidekiq
1 Introduction
De nombreux clusters de calcul existent dans les centres et les équipes de recherche Inria. Ils peuvent être
communs avec des partenaires académiques comme accessibles à des partenaires industriels.
La diversité des parties prenantes, des besoins des scientifiques, des modèles de financement, des cycles de
vie et des modes de gestion technique parmi ces clusters complexifie l’homogénéisation des plateformes
ou l’intégration dans une grille.
Par ailleurs, certaines équipes de recherche n'ont pas encore franchi le pas de l'utilisation des clusters de
calcul. Ces équipes continuent à investir dans de grosses stations de calcul dédiées à un nombre réduit
d'utilisateurs (modèle sous-optimal).
L'argument de la complexité est souvent avancé par les utilisateurs de ces équipes, rebutés par la difficulté
d’apprentissage d’environnements spécifiques : modalités d’obtention des comptes (à commencer par leur
nom de login), configuration des accès aux plateformes, architectures matérielles et logicielles,
compilateurs et outils disponibles, soumission des tâches de calcul, gestion des données, etc.
Notre projet se donne pour objectif de :
̶
développer les usages croisés entre les clusters de calcul Inria en favorisant la découverte des
clusters existants, l'obtention d'accès sur ces clusters et leur utilisation ;
̶
attirer une population de « non-utilisateurs » des clusters, en permettant une utilisation
simplifiée via une interface homogène conçue pour un débutant ;
̶
être non intrusif pour les utilisateurs des clusters : rien ne change pour un utilisateur qui ne
souhaiterait pas utiliser nos outils ;
JRES 2015 - Montpellier
1/11
̶
être non intrusif pour les administrateurs des clusters : l'intégration d'un cluster dans le projet
est peu coûteuse, n'en modifie ni la gestion technique ni la politique d'utilisation (ex. : règles et
processus d'attribution de compte).
2 État de l'art, positionnement
Nous avons identifié de nombreux outils recouvrant partiellement les besoins du projet Kali. Nous
présentons ci-dessous certains d'entre eux en proposant une classification possible.
2.1
Les éditeurs de logiciels
Il existe une offre d'environnements logiciels produits par (ou adossés à) un éditeur logiciel, visant à faciliter
l'utilisation de plateformes de calcul existantes. Ces outils s'articulent souvent autour d'une couche
middleware à installer sur la plateforme (ex. : ProActive, SysFera-DS), ou bien autour d'un serveur et
d'agents sur les ressources de calcul (ex. : EnginFrame (1) de NICE, qui peut être intégré avec Moab HPC
Suite (2) de Adaptative Computing). Parfois il s'agit principalement d'un frontal web à la plateforme (ex. :
eQUEUE (3) de Advanced Clustering ; Compute Manager (4) de Altair/PBS Works). De façon générale,
ces outils assurent une large palette de fonctions (tâches, données, interfaces utilisateur, comptes et droits
d'accès, visualisation des résultats, statistiques, etc.) et prennent en charge des infrastructures variées :
clusters utilisant différents schedulers, grilles et, de plus en plus, les clouds publics et privés.
Par exemple, SysFera-DS (5) (6) est une solution de fédération et de gestion d'environnements HPC
hybrides, commercialisée par la société SysFera. Le portail web de SysFera-DS offre une interface unifiée
à l'utilisateur en s'appuyant sur les accès natifs de l'utilisateur à chaque infrastructure (compte utilisateur
sur le cluster, connexion et relais SSH). Le modèle d'utilisation est basé sur une notion de gestionnaire
mettant des applications à disposition des utilisateurs. SysFera-DS s'installe sur les calculateurs gérés en
utilisant un compte applicatif non privilégié ; il s'interface avec le scheduler déja actif sur l'infrastructure.
Autre exemple, ProActive Parallel Suite (7) (8) est un environnement de gestion de tâches développé par
le consortium OW2 qui met l'accent sur l'orchestration de workflows. Dans Proactive, le middleware est
installé et lancé sur les infrastructures gérées en utilisant un compte applicatif. ProActive utilise de
préférence son propre scheduler ; il gère ses propres comptes d'utilisateurs, qu'il interface optionnellement
avec les comptes natifs des utilisateurs sur les infrastructures lors de l'exécution des tâches (SSH, mot de
passe). ProActive permet l'exécution de codes en java, de scripts et de codes natifs (binaires) dont la
compilation a été par ailleurs assurée par un mécanisme à la charge de l'utilisateur.
2.2
Les clouds publics
L'offre commerciale dans le domaine du cloud est en plein développement, le HPC ne fait pas exception.
L'offre de HPC sur les clouds publics couvre classiquement l'infrastructure HPC, son déploiement et sa
gestion (ex. : MIT StarCluster sur Amazon Elastic Compute Cloud (EC2) (9)).
À côté sont apparues des offres de cloud HPC « clé en main » conçues autour du cycle de travail de
l'utilisateur final du HPC. L'aspect portail web en est donc naturellement un composant central comme dans
POD (10) de Penguin Computing ou Extreme Computing de Bull (11) ou encore HPC Spot. Ces portails
conçus pour une offre de cloud public sont parfois aussi proposés pour du cloud privé.
Par exemple, HPC Spot (12) est une offre de location de « HPC as a service » (matériel, système, logiciels,
outils de gestion) dans un cloud public commercialisée par la société OVH. HPC Spot vise à simplifier au
maximum la mise en œuvre, le dimensionnement et l'utilisation du HPC. Le portail web utilisé dans HPC
Spot est également commercialisé par la société Oxalya sous le nom de HPC Drive (13). Le portail web
permet de lancer des jobs pour des applications HPC pré-installées, de gérer les données et de visualiser les
résultats. Un accès en ligne de commande SSH et une API SOAP sont utilisables simultanément. L'accès
SSH permet à l'utilisateur de compiler ses propres applications via le lancement d'un job de compilation.
OVH propose d'accompagner au cas par cas un utilisateur qui souhaite intégrer une application au portail
web et la mettre à la disposition des autres utilisateurs.
JRES 2015 - Montpellier
2/11
2.3
Les communautés d'utilisateurs scientifiques
Une autre famille d'outils destinés à faciliter l'accès aux ressources de calcul est issue des besoins et des
réalisations de communautés d'utilisateurs du monde de la recherche scientifique. Dans un paysage
largement structuré autour de l'EGI (14) en Europe et de France Grilles (15) en France, les outils frontaux
sont souvent liés à un middleware de grille (ex. : gLITE, ARC, Globus). Aux USA, ces outils (ex. : Apache
Airavata) sont classiquement issus de projets menés dans des universités et adossés à des financements de
la NSF, du DARPA, etc.
Parmi ces outils, un grand nombre sont des portails web de communauté scientifique. Un portail de
communauté est un outil commun aux chercheurs d'un domaine pour fournir, via une interface conviviale,
un accès mutualisé à des applications utilisées dans leur domaine de recherche, à des ressources de calcul
et parfois à des catalogues de données. Citons par exemple VIP/Gate-Lab (16) pour l'organisation virtuelle
(VO), biomed de EGI (17), ou BioHPC de Cornell University pour la biologie computationnelle.
Une autre famille de portails répond à un besoin plus générique d'accès à des ressources de calcul. Par
exemple les portails web CHReME (18) créé par le C-DAC (Inde) pour ses besoins propres, ou SCMS.pro.
Le portail SCMS.pro (19), distribué sous licence Apache 2, simplifie l'utilisation et l'administration de
systèmes HPC utilisant différents schedulers (Torque, SLURM, PBS), middlewares de grille (gLITE, ARC)
et clouds (Amazon EC2). Les fonctionnalités pour l'utilisateur couvrent la gestion des données et des tâches,
la compilation, le suivi, ainsi qu’une messagerie instantanée intégrée. SCMS.pro se base sur un logiciel
agent à installer sur le frontal de chaque cluster géré en utilisant un compte applicatif. L'accès de l'utilisateur
aux clusters se fait avec ses accès natifs (SSH, compte utilisateur).
OpenMOLE (20) est pour sa part un moteur de workflows scientifiques qui s’interface avec différentes
ressources de calcul (serveurs, clusters, grille EGI, etc.). Il propose un autre choix d’architecture en
s’installant entièrement sur le poste client.
Citons enfin DIRAC (solution générale pour l'accès aux ressources distribuées de différents fournisseurs)
et iRODS (stockage) qui intègrent leur propre portail web. Utilisés dans l'offre de France Grilles et dans
EGI, ils peuvent aussi être déployés dans une instance privée.
2.4
Positionnement de Kali
Sans même aborder la question de la licence et du coût de ces solutions, aucune ne s’est avérée répondre
de manière satisfaisante aux besoins d'Inria, notamment :
̶
le cas de l'utilisateur non expert en HPC mais qui compile ses codes (par opposition à un modèle
où les applications sont installées par un tiers) est rarement pris en compte, alors qu'il est
prioritaire chez Inria ;
̶
ces outils s’avèrent pour la plupart intrusifs pour l'administrateur (installation de logiciel sur le
cluster, accès privilégiés depuis le frontal, modification des modalités d'administration), voire
pour l'utilisateur (l'accès usuel par SSH n'est plus possible).
Kali est notre réponse à ces deux exigences. C'est un outil développé en interne, initialement comme une
preuve de concept.
3 Démarche et organisation du projet
Pour mener à bien ce projet nous avons adopté une méthodologie agile pour les raisons suivantes :
-
cahier des charges et expression du besoin trop imprécis au lancement du projet ;
nécessité de présenter des maquettes fonctionnelles et incrémentales afin d’attirer et de fédérer des
utilisateurs et de provoquer des demandes d’évolution.
JRES 2015 - Montpellier
3/11
En effet, les méthodes agiles trouvent de plus en plus souvent leur place dans les projets de développement.
Elles sont à la fois plus pragmatiques et permettent de mieux répondre aux attentes du client en l’impliquant
tout au long du processus de développement.
De nombreuses méthodes agiles (21) existent, décrites et documentées sur Internet, comme Extreme
Programming (22) ou encore Scrum (23). Dans notre contexte, il a été nécessaire d’adapter la méthodologie,
en réutilisant plusieurs éléments issus de différentes méthodes spécifiques, notamment Scrum. Les sections
suivantes précisent plus concrètement notre mise en œuvre pour ce projet.
Les méthodes agiles tendent à privilégier :
L’équipe : le travail en équipe prime sur les « exploits » individuels. Chacun intervient sur les
différents aspects du projet et monte progressivement en compétence grâce aux échanges
permanents.
̶
L’application : elle fonctionne à tout moment du projet, quelles que soient les fonctionnalités
implémentées. On cherche donc à produire de façon incrémentale des prototypes fonctionnels.
̶
La collaboration : le client est impliqué très souvent, il affine ainsi ses besoins et précise ses
demandes en visualisant un produit fonctionnel (et non pas en conceptualisant un produit
fantasmagorique).
̶
L’acceptation du changement : l’équipe accepte les évolutions demandées par le client, quitte à
revenir sur (voire supprimer) les développements déjà réalisés. Ainsi le code jetable est autorisé.
3.1
̶
Les cycles de développement
Concrètement, l’activité de développement est cadencée par des cycles dont nous avons fixé la durée à
environ 1 mois. Nos cycles sont constitués de quatre temps principaux :
̶
La réunion de lancement, d’une durée de 1h30, où sont présents les développeurs et les clients.
Dans notre cas le responsable du Service de Développement (SED) a représenté les chercheurs
à travers les usages qu’il connait et les retours des tests d’utilisateurs. Nous avons également
impliqué le comité de pilotage des clusters d’Inria Sophia Antipolis pour montrer les maquettes
successives et pour des appels à contribution.
̶
Le développement, d’une durée de 3 semaines à 1 mois et demi : l’équipe de développement (1
ingénieur à temps plein et 2 ingénieurs à environ 10% de leur temps) se consacre aux tâches
fixées, en étant particulièrement attentive au respect du timing, quitte à réaliser les objectifs de
façon moins pérenne ou moins aboutie.
̶
La réunion de livraison, d’une durée de 30 minutes : une démonstration de l’application
fonctionnelle permet de présenter aux « clients » l’atteinte des objectifs fixés au début du cycle.
̶
Un temps « off », d’une durée d’une semaine environ : ce temps permet aux développeurs de
sortir du focus intense du projet et aussi de se consacrer à d’autres activités (veille
technologique, formation, mails, etc.). Ce temps de récupération est nécessaire pour éviter les
phénomènes de burn out.
La réunion de lancement est un temps particulièrement important. Dans notre situation, elle se décompose
comme suit :
̶
On fixe le début et la fin du cycle, ainsi que le nombre de jetons utilisables sur le cycle ; un
jeton représente une demi-journée de travail.
̶
Le client expose les fonctionnalités attendues pour ce cycle. Si besoin, les développeurs peuvent
demander aux clients de les classer par ordre de priorité.
̶
Un « poker planning » (24) (25) est effectué pour estimer une durée pour chaque tâche. Dans
notre cas, nous indiquons simultanément un nombre de jetons, représenté par le nombre de
JRES 2015 - Montpellier
4/11
doigts montrés. Cette étape permet de fixer la durée des tâches mais également de s’accorder
sur le niveau d’atteinte attendu. Par exemple, lorsqu'il y a une grande variation du nombre de
jetons alloués entre les votants, on s'aperçoit souvent que la description de la tâche était trop
floue et donc soumise à interprétation.
̶
3.2
Plusieurs scénarios à ce stade :
̶
pas assez de tâches : on indique aux clients de demander plus de fonctionnalités dans ce cycle
(cas rare) ;
̶
le timing estimé colle parfaitement avec le nombre de jetons disponibles (ça arrive) ;
̶
le nombre de jetons prévu initialement est trop petit, on peut : a) supprimer des tâches (les
moins prioritaires), b) faire certaines tâches plus rapidement (et moins bien aussi), c) ajouter
quelques demi-journées en décalant la réunion de fin de cycle.
Coding sprints occasionnels
Il est parfois utile d’organiser des sessions de développement collaboratif (coding sprints) de quelques jours
(typiquement une semaine) pour réaliser des avancées significatives de façon collective et ponctuelle. Dans
notre cas, ceci a été pertinent au démarrage du projet (choix des outils communs, co-écriture des premières
classes Ruby on rails, etc.), au moment de définir l’interface graphique utilisateur initiale ou encore pour
amorcer les développements de la partie administrateur du site. Il est important que lors de ces coding
sprints, tout le monde participe. Cela renforce la cohésion de l'équipe, la collaboration entre développeurs
et permet à chacun de s'exprimer, quel que soit son niveau d'expertise.
4 Kali du point de vue de l'utilisateur
Kali est un portail web HTTPS permettant de simplifier l'accès à un ensemble de clusters. Kali rassemble
en un unique point toutes les informations concernant ses clusters, ses codes sources, ses jobs, ses données
et ses informations de compte. Kali ne nécessite aucune installation sur le poste client, un navigateur web
suffit.
L'interface utilisateur propose cinq fonctionnalités principales accessibles au travers de pages web
distinctes :
̶
Le tableau de bord : permet d'avoir une vision d'ensemble de l'utilisation des clusters, de l’état
de compilation de ses codes et de ses jobs en cours.
JRES 2015 - Montpellier
5/11
Figure 1 - Le tableau de bord de Kali
̶
Les clusters : montre les informations disponibles pour chaque cluster (si l’on dispose d’un
compte, si la connexion est bonne, lien vers la documentation, etc.)
̶
La compilation : permet de lancer et de suivre ses compilations (qmake, cmake) sur le cluster
de son choix ou sur une plateforme d’intégration continue Jenkins.
̶
Les données : permet de charger ses données vers et depuis les différents clusters, ainsi que de
synchroniser ses données entre les clusters (mécanisme point à point avec vérification
d’incohérences). La gestion des données repose sur des notions de « dataset » (correspond à un
répertoire sur chaque cluster) et de « cluster de référence » (plateforme préférentielle d’un
utilisateur).
̶
Les tâches : permet de lancer ses jobs sur le cluster de son choix et de suivre leur état
d'avancement. Les jobs peuvent utiliser des codes séquentiels ou MPI, des scripts (Perl, Ruby,
Python), des applications tierces (MATLAB) ou un environnement Kadeploy (26). Le
paramétrage du job se fait via un formulaire graphique ou une représentation YAML.
Les fonctionnalités annexes comprennent :
̶
Les tickets : permet de soumettre un ticket d’incident qui est aiguillé vers un canal de support
externe (helpdesk, alias mail) spécifique à un cluster, ou par défaut vers le helpdesk de Kali.
̶
Les comptes utilisateur : permet de régler ses options comme l'activation du mode avancé de
l’interface utilisateur, le changement de mot de passe, l’ajout de clés SSH, etc.
̶
Les notifications : donnent accès à l’historique de son activité, qui peut aussi être reçue par mail.
5 Kali du point de vue de l’administrateur
L'administrateur Kali est distinct des administrateurs des clusters, dont le rôle reste inchangé.
JRES 2015 - Montpellier
6/11
L'administrateur Kali gère les utilisateurs Kali : création, paramétrage, régénération des clés SSH Kali, mise
sur liste noire, modification du rôle, etc. Il supervise également leurs tâches : synchronisation de données,
jobs en cours, tâches de fond (thread Sidekiq lancés par Kali).
L'intégration d'un cluster ne nécessite aucune installation logicielle ou création de compte sur le cluster. Le
mécanisme d'accès aux clusters se base sur des connexions SSH utilisant une paire de clés de session Kali
unique par utilisateur et les identifiants de connexion accordés à l’utilisateur par l'administrateur du cluster.
̶
pour l’administrateur de Kali : il faut s'assurer que le scheduler du cluster est supporté par Kali
(OAR, SGE, Torque), puis renseigner un formulaire avec les informations concernant le cluster
(page de documentation, lien vers les outils de supervision, alias mail du support, etc.) ;
̶
pour l’administrateur du cluster : il n’y a aucune opération à réaliser pour l’intégration. La
procédure d’ouverture de compte utilisateur reste inchangée : pas de différence entre un
utilisateur utilisant uniquement SSH ou Kali.
6 Kali du point de vue du développeur
L'application s'appuie sur le framework Ruby on Rails (RoR) (27). Celui-ci permet de développer
rapidement et efficacement une application web. Il utilise l’expressivité de Ruby et un ensemble de
conventions pour rendre le code concis et son écriture agréable. La philosophie du framework se base sur
le paradigme MVC (modèle-vue-contrôleur) et repose sur deux grands principes :
Don't Repeat Yourself : méthode de développement qui vise à minimiser la répétition
d’informations et permet d’obtenir un code plus maintenable, plus extensible et moins buggé.
̶
Convention Over Configuration : les conventions du framework contraignent le développeur
mais lui évitent d’écrire des fichiers de configuration.
6.1
̶
Frontend
La partie frontend de Kali correspond à la partie « Vue » de l'architecture MVC de RoR et utilise :
̶
des fichiers HTML avec de l'embedded Ruby (ERB) pour le contenu des pages web ;
̶
du CoffeeScript, méta-langage permettant d’écrire du JavaScript, notamment pour les
animations côté client ;
̶
du Sass, sucre syntaxique du CSS permettant d'ajouter un style aux différentes pages.
Le pipeline de RoR gère les conversions de langage, la concaténation et l’optimisation de la taille du code
qui sont effectuées à la volée dans l’environnement de développement et pré-compilées dans
l’environnement de production.
Le framework d’interface Bootstrap est utilisé en association avec le thème open source AdminLTE, qui
apporte un ensemble de widgets prédéfinis supplémentaires. Ceci permet de coder rapidement et de
s’assurer de la conformité du site aux normes W3C et Responsive design (adaptation à la taille de l’écran).
6.2
Les modules Rails
Le framework RoR permet l’installation de paquets additionnels, souvent distribués sous licence open
source. Certains sont incontournables et se retrouvent notamment dans des applications reconnues comme
Gitlab, Diaspora ou encore Discourse (28). Parmi ceux-ci, Kali utilise notamment :
̶
Devise : solution d'authentification modulaire compatible avec CAS et LDAP, et permettant
aussi la création de comptes locaux ;
̶
Sidekiq : gestionnaire de tâches de fond simple, efficace et s’intégrant facilement à Rails.
JRES 2015 - Montpellier
7/11
6.3
Backend
Le backend de Kali se décompose en :
―
un serveur Nginx couplé à un module Phusion Passenger pour Ruby ;
―
une base de données PostgreSQL ;
―
un orchestrateur Sidekiq pour les tâches asynchrones ;
―
un gestionnaire de données Redis pour les données temporaires en mémoire.
Sidekiq permet l’exécution de nombreux processus légers en parallèle, et s’appuie sur Redis pour la
gestion des données (accès performant, gestion simplifiée). Kali utilise les processus légers de Sidekiq
pour décorréler l’interface web de l’action à effectuer en tâche de fond.
Le serveur web d’application open source Phusion Passenger embarqué dans Nginx est une solution
robuste et optimisée, adaptée au déploiement d’applications RoR en production. L’ensemble inclut
notamment un cache HTTP, le lancement et l’arrêt de processus applicatifs en fonction du trafic ainsi
que des outils de suivi des processus et de l’activité mémoire.
6.4
Communications
Figure 2 - Les flux de communication de Kali
Kali associe à chaque utilisateur une paire de clés SSH qu’il utilise pour se connecter avec l’identité de
l’utilisateur sur les clusters et y effectuer les actions demandées via l’interface web.
Les interactions avec Jenkins s’appuient sur l'API REST de ce dernier, notamment pour la compilation.
6.5
Authentification
L’authentification s’appuie sur CAS, LDAP ou des comptes locaux.
JRES 2015 - Montpellier
8/11
6.6
Système
Kali est une application web conçue pour être facilement déployée sur un autre site. Il manque encore à ce
jour un outil automatisé de déploiement (ex. : cookbook chef, image docker).
L’instance actuellement déployée est sous Fedora 21, utilise Systemd (lancement initial, tâches récurrentes)
et les outils du backend Kali.
7 Avancement et perspectives
À ce jour, une instance de Kali est déployée en bêta-test chez Inria. Elle permet l’accès à cinq clusters dont
GRID5000 et les clusters des centres Inria de Sophia, Saclay et Grenoble.
La stabilité système et applicative de l'instance Kali est satisfaisante. Les tests du frontal effectués avec
l’outil Tsung (29) ont montré une bonne tenue en charge.
48 personnes ont déjà ouvert un compte sur Kali, mais le nombre d'utilisateurs actifs reste limité. Cette
inertie est liée à la tendance des nouveaux utilisateurs des clusters à démarrer en reproduisant les pratiques
de leurs prédécesseurs (copie et adaptation) puis à faire appel au support technique en cas de blocage.
L’effort porte donc actuellement sur le démarchage individuel (séance de découverte de Kali pour tout
nouvel utilisateur du cluster).
Les utilisateurs actifs actuels ont un profil de débutant. Ils apprécient l’accès via une interface graphique,
le chargement simplifié des données, l’utilisation simple de ressources de calcul intensif. Leur scénario
d’usage est mono-cluster et utilise peu la compilation (plutôt MATLAB, JavaScript, Python).
Parmi les développements de nouvelles fonctionnalités envisagés pour Kali, on peut citer :
̶
le support de la visualisation, par exemple via un job lançant un serveur ;
̶
la gestion de projet et de membres partageant des données ou des codes ;
̶
l’intégration avec des clouds publics (OVH HPCspot, Amazon EC2) et des outils middleware
de type OpenStack, ou Apache Mesos.
Scénarios d’utilisation identifiés
7.1
7.1.1
Mise en production entre centres Inria
Inria est réparti sur huit centres en France, possédant chacun des ressources de calcul, plus facilement
accessibles aux chercheurs locaux. On constate que les scientifiques d’un centre trouvent difficile d’accéder
à des ressources hébergées dans un autre. Que ce soit pour pallier une surcharge du cluster local ou utiliser
un matériel spécifique hébergé dans un autre centre, le déploiement généralisé de Kali à Inria offrira à nos
chercheurs l’accès à l’ensemble des ressources de calcul de l’Institut de façon simple et cohérente.
7.1.2
Mise en production pour les partenaires départementaux du CPER
Dans le cadre du prochain Contrat de Plan État Région (CPER), le centre Inria Sophia Antipolis Méditerranée est impliqué dans le projet d’Observatoire Pluridisciplinaire des Alpes-Maritimes (OPAL).
OPAL créera un mésocentre distribué, basé sur la mise en commun de plusieurs clusters institutionnels
(OCA, Mines Paristech, UNS, Inria). Dans ce contexte, le portail web Kali permettra prochainement aux
chercheurs de ces différents instituts d’accéder aux clusters de chaque partenaire comme à celui de son
établissement d’appartenance.
7.2
Les possibilités de diffusion et de transfert
Plusieurs modèles de diffusion et de maintenance du logiciel sont envisagés à ce jour :
̶
transfert vers une entreprise fournissant une offre sur ce domaine ;
JRES 2015 - Montpellier
9/11
̶
création d’une start-up proposant ce logiciel à des entreprises souhaitant utiliser des ressources
de calcul hétérogènes et /ou géographiquement distantes ;
̶
diffusion open source (éventuellement sous forme de consortium avec des partenaires
académiques et/ou industriels).
Bibliographie
1. [En ligne] http://www.nicesoftware.com/download/distributions/2015.0/documentation/EFAdminGuide2015.0.pdf.
2. [En ligne] http://docs.adaptivecomputing.com/.
3. [En ligne] http://www.advancedclustering.com/products/software/equeue/.
4. [En ligne]
http://resources.altair.com/pbs/documentation/support/Compute%20Manager%20Administrator
%27s%20Guide.pdf.
5. [En ligne] http://www.association-aristote.fr/Fichiers-2011/11-octobre/06-B-Depardon-JMLaymajoux.pdf.
6. Benjamin Depardon, Samuel Kortas, Boris Daix, Renaud Barate. SysFera-DS : Un portail d'acces
unifié aux ressources des centres de calcul. Mise en application à EDF R&D. [En ligne] Octobre 2012.
https://hal.archives-ouvertes.fr/hal-00766073/document. hal-00766073.
7. [En ligne] http://www.ow2.org/bin/view/ActivitiesDashboard/ProActive.
8. [En ligne] http://doc.activeeon.com/ProActiveAdminGuide.html.
9. [En ligne] https://aws.amazon.com/hpc/getting-started/.
10. [En ligne] https://pod.penguincomputing.com/hpc_on_demand.
11. [En ligne] http://www.bull.com/sites/default/files/docs-dl/f-xcs-en3.pdf.
12. [En ligne] https://docs.hpcspot.com/.
13. [En ligne] http://www.oxalya.com/?page_id=1441.
14. [En ligne] http://www.egi.eu/.
15. Geneviève Romier, Gilles Mathieu, Hélène Cordier. France Grilles,des opérations aux
utilisateurs. JRES 2013. [En ligne] https://2013.jres.org/archives/66/paper66_article.pdf.
16. Sorina Camarasu-Pop, Rafael Ferreira da Silva, Tristan Glatard. VIPet GateLab : retour
d'expérience. JRES 2013. [En ligne] https://2013.jres.org/archives/23/paper23_article.pdf.
17. [En ligne] http://biohpc.org.
18. [En ligne] http://cdac.in/index.aspx?id=hpc_hpcs_chreme.
19. [En ligne] http://scms.pro/.
20. [En ligne] http://www.openmole.org.
21. wikipedia. [En ligne] https://fr.wikipedia.org/wiki/Méthode_agile.
22. wikipedia. [En ligne] https://fr.wikipedia.org/wiki/Extreme_programming.
23. wikipedia. [En ligne] https://fr.wikipedia.org/wiki/Scrum_(méthode).
JRES 2015 - Montpellier
10/11
24. [En ligne] http://leblogdumanagementdeprojet.com/2011/03/23/le-planning-poker-dans-lamethode-agile-scrum/.
25. wikipedia. [En ligne] https://fr.wikipedia.org/wiki/Planning_poker.
26. [En ligne] http://kadeploy3.gforge.inria.fr.
27. [En ligne] http://rubyonrails.org.
28. [En ligne] http://www.opensourcerails.com.
29. [En ligne] http://tsung.erlang-projects.org/.
JRES 2015 - Montpellier
11/11