De nombreux utilisateurs ont besoin d’accéder de façon uniforme à des grilles d’envergures différentes (locale, régionale, nationale, internationale) et s’adressant à différentes communautés (académiques/industrielles, recherche/production). Ces grilles ont différents atouts et lacunes, et le choix de l’utilisateur de soumettre sur l’une ou l’autre dépend de différents critères comme les caractéristiques et la quantité de ressources matérielles requises, les contraintes de licence des logiciels utilisés, le niveau de confidentialité requis, le degré d’urgence, la charge de ces grilles, etc.
A moyen terme, un accès uniforme sera possible entre certaines grilles académiques d’envergure nationale ou internationale, grâce à divers projets d’interopérabilité en cours. Cependant, les approches choisies pour ces projets (modifications côté serveurs) ne permettent pas d’envisager une utilisation uniforme de ces grilles et des grilles en dehors de ces projets d’interopérabilité.
Dans le cadre du projet IGTMD financé par l’ANR, le Centre de Calcul de l’IN2P3/CNRS (CC-IN2P3) développe JSAGA ; une API qui suit une approche complémentaire à celles de ces projets d’interopérabilité. Cette approche (encapsulation côté client) permet un accès uniforme à potentiellement n’importe quelle grille. De plus, elle permet d’avoir une solution sur le court terme puisqu’elle s’affranchit des contraintes de déploiement des infrastructures de grille, et elle bénéficie sur le long terme des avancées des autres projets afin de conserver un niveau de complexité interne raisonnable.
JSAGA est actuellement intégrée dans divers outils : le portail de grilles industrielles et académiques Elis@ (CS-SI), l’outil de soumission de collections de jobs JJS (CC-IN2P3) et l’explorateur de fichiers JUX (CC-IN2P3).
Hétérogénéité des interfaces ...
L’obstacle le plus évident à l’utilisation uniforme de plusieurs grilles est l’hétérogénéité des interfaces de leurs intergiciels. Il était donc nécessaire d’encapsuler ces interfaces dans une interface commune. Parmi les différentes alternatives possibles, la spécification SAGA (Simple API for Grid Applications) a été choisie. Cette spécification est définie par l’Open Grid Forum, structure internationale dont le rôle est d’élaborer et préconiser des standards pour les grilles informatiques. Comme son nom l’indique, SAGA est une API simple d’utilisation. Elle n’est associée à aucun des intergiciels existants et peut servir d’interface commune à ceux-ci.
JSAGA est une implémentation de la spécification SAGA en Java (d’où le "J" de JSAGA, vous l’aurez deviné…). Cette implémentation permet une utilisation uniforme des mécanismes et composants de sécurité, de gestion des données et de gestion de l’exécution, provenant de différents intergiciels de grille (Globus Toolkit, Unicore, gLite, etc.) et de technologies plus classiques (certificats X509, PKI, HTTPS, SFTP, SSH, etc.). La liste des technologies supportées par JSAGA est extensible par l’ajout de plug-ins. Les plug-ins actuellement proposés bénéficient d’une contribution significative de CS-SI / British Telecom.
Enfin, les API clientes des intergiciels ont des approches différentes pour résoudre un même problème (e.g. transfert de données, suivi de l’exécution). Ces différences conduisent souvent à une perte d’efficacité lorsque l’on contraint ces API à être utilisées au travers d’une interface commune. La conception de JSAGA et la définition des interfaces de ses plug-ins prennent en compte les différentes approches possibles afin d’utiliser efficacement les différents intergiciels, et ainsi de ne pas être sujet à cette perte d’efficacité.
... et des infrastructures
JSAGA s’affranchit de l’hétérogénéité des intergiciels grâce à son implémentation de la spécification SAGA, mais il ne se résume cependant pas à cette implémentation… Généralement sous-estimé, un autre obstacle important à l’utilisation uniforme de plusieurs grilles est l’hétérogénéité de leurs infrastructures. Les infrastructures en place se distinguent, par exemple, par les autorités de certification supportées, les politiques de filtrage réseau, les commandes déployées sur les nœuds de calcul, les variables d’environnement initialisées sur ces nœuds, etc. Ainsi, même si elles sont basées sur le même intergiciel, les infrastructures de deux grilles distinctes ne pourront généralement pas être utilisées de la même façon.
Il faut donc permettre, entre autres, une utilisation transparente de plusieurs contextes de sécurité, de plusieurs versions ou modes d’utilisation des technologies déployées, d’environnements d’exécution possédant des possibilités et contraintes très différentes. Par exemple, le chemin emprunté pour transporter jusqu’au nœud de calcul les données nécessaires à l’exécution du job peut dépendre de nombreux paramètres liés à la grille ou au site ciblés (e.g. commandes déployées sur les nœuds de calcul, règles de filtrage réseau), aux technologies employées (e.g. modes d’accès du protocole, possibilité de transfert tierce partie, de délégation des droits d’accès) et aux données elles-mêmes (e.g. taille des fichiers, partage des fichiers entre plusieurs jobs).
La particularité de JSAGA est de prendre en compte ces paramètres afin de s’affranchir de l’hétérogénéité des infrastructures. JSAGA s’appuie sur son implémentation de la spécification SAGA pour permettre la soumission efficace d’une collection de jobs sur différentes infrastructures de grilles (e.g. < a href="http://www.eu-egee.org/" target="_blank">EGEE, OSG, DEISA, NAREGI), à partir d’une description unique de cette collection. Cette description peut être écrite dans différents langages, dont le JSDL (Job Submission Description Language), standard défini par l’Open Grid Forum.
Pour en savoir plus, voir le site web de JSAGA.
Sylvain Reynaud (CC-IN2P3)
