V - 1.
d’EGEE
Dans ce paragraphe, il est question de détailler la stratégie développée pour permettre l’exécution des modules de production et de transfert de l’application ALHTAÏR sur les ressources de calcul de l’infrastructure de grille EGEE. Ainsi, dans un premier temps, l’intergiciel de grille gLite, utilisé et développé dans le cadre du projet EGEE, est décrit. Une attention particulière est portée sur les fonctions dédiées à l’utilisation des ressources de calcul et de stockage par un utilisateur externe. Dans un second temps, la stratégie de recodage et de portage de l’application ALHTAÏR sur la grille EGEE sont développés. A ce niveau, étant donné le positionnement scientifique de cette recherche, les développements et les expérimentations qui suivent s’appuient sur les ressources informatiques de l’organisation virtuelle Earth Science Research1 dédiée aux problématiques des sciences de la Terre
au sein du projet EGEE.
Un intergiciel et l’ensemble de ses services permet donc de mettre en relation une communauté d’utilisateurs avec des ressources matérielles géographiquement distantes. D’autre part, « les services de l’intergiciel ont besoin de travailler ensemble de manière coordonnée, bien que ces services peuvent toujours être déployés et utilisés indépendamment » (LAURE et al., 2004).
En terme de services, il est possible de distinguer deux niveaux distincts, les services fondamentaux de l’intergiciel en charge des ressources matérielles (gestion des processus distants, co-allocation des ressources, accès aux stockages, découverte des ressources, sécurité et qualité de services) et ceux dédiés aux interactions avec l’utilisateur (environnements de développements, courtiers de ressources, planification des tâches) qui utilisent les interfaces fournies par les services de plus bas niveau (ASADZADEH et al., 2005 ; MAGOULES et al., 2009).
Le programme EGEE a développé son propre intergiciel de grille en s’appuyant sur les intergiciels Globus (SOTAMAYOR, 2005). Les fortes relations entre utilisateurs finaux et chercheurs en informatique,
chargés du développement de cet intergiciel, ont permis de perfectionner progressivement ce dernier pour en faire à l’heure actuelle un outil puissant et adaptable aux besoins des différentes communautés impliquées dans EGEE. Comme tout intergiciel, gLite (Lightweight Middleware for Grid Computing) offre de nombreuses interfaces entre les protocoles de bas niveau des différentes ressources matérielles et les ressources externes des utilisateurs, en se basant sur la technologie des services web.
Etant donné le caractère clairement utilisateur de cette présente recherche, une attention particulière est donnée aux services de haut niveau permettant la gestion des données et des exécutions, de la sécurité et des services d’information et de découverte des ressources. Sous EGEE, Il est important de considérer deux niveaux de structure, la composition d’un site (aspect matériel) et la composition de la grille (aspect intergiciel). Concernant un site de calcul, il est possible de distinguer :
1 https://cic.gridops.org/index.php?section=vo&vo=esr
- une interface utilisateur (UI) qui constitue le point d’accès au site et permet l’authentification des entrées externes.
- L’élément de calcul (CE) qui gère la file d’attente des tâches à exécuter sur le site - Les nœuds de travail (WN) qui exécutent proprement dit les algorithmes
- Les éléments de stockage (SE) qui donnent accès aux serveurs d’accès aux données
Ce vocabulaire est spécifique à EGEE, il peut différer d’une grille à l’autre bien que les structurations logicielles et matérielles soient souvent les mêmes et basées sur le standard OGSA (cf. §.II – 2.3.1.3).
Figure 61 : Services de l'intergiciel gLite (d'après LAURE et al., 2004)
Il est important de retenir que l’accès principal aux ressources de grille se fait par le biais d’une interface utilisateur, que l’organisation virtuelle, à laquelle l’utilisateur est inscrit et reconnu de confiance, met à disposition.
Au niveau de la grille dans son ensemble, il est possible d’identifier plusieurs services de haut niveau qui constituent gLite (Figure 61). Ils sont au nombre de 5 :
- Les services d’accès - les services de sécurité
- les services d’information et de surveillance des ressources - les services de gestion des données
- les services de gestion des tâches
V - 1.1. Les services d’accès
L’accès à la grille se fait au travers d’une interface utilisateur (UI) généralement installée sur un site de la grille mais pouvant être aussi installé sur le système local de l’utilisateur. Il s’agit d’une interface en ligne de commande accessible au travers d’une connexion sécurisée SSH2 qui est un protocole de
communication sécurisé. De cette interface, l’utilisateur prépare, soumet, surveille et récupère les tâches de calcul (job) envoyées à distance. Il existe des interfaces graphiques permettant de faciliter cette interaction, tels que ceux développés dans les projets Ganga (BROCHU et al., 2009) ou g-Eclipse
(GJERMUNDRØD et al., 2008).
V - 1.2. les services de sécurité
La sécurité est un point primordial dans une architecture de grille. En effet, le nombre d’utilisateurs d’institutions différentes et de ressources matérielles accessibles apparaissent a priori comme des facteurs critiques à la sureté d’une telle infrastructure. Il existe donc plusieurs mécanismes pour améliorer cette sécurité. Ainsi, tout utilisateur référencé doit posséder :
- un certificat électronique personnel
- une inscription dans une organisation virtuelle référencée dans EGEE - un compte sur une interface utilisateur
Un certificat électronique permet d’identifier univoquement une personne, une machine ou un programme sur la grille (KNOOPS, 2007). Il correspond à une véritable carte d’identité numérique. EGEE
s’appuie sur la norme X509 qui est un standard de cryptographie de l’union international des télécommunications. Ce certificat, à durée de validité limitée, est composé d’une clé publique et d’une clé privée. La première est signée par une autorité de certification (CA) et publiée sur le réseau de la grille. En France, l’autorité de certification officielle pour l’utilisation de la grille est GRID-FR3, une sous-
autorité de certification de l'autorité CNRS. La clé privée est déposée sur l’interface utilisateur de l’utilisateur (de la ressource en général) et est protégée par un mot de passe. Le chiffrement des communications repose sur l’utilisation d’algorithmes asymétriques permettant une authentification mutuelle : l’émetteur signe avec sa clé privée, alors que le destinataire vérifie la signature avec la clé publique de l'émetteur (CONTES, 2005).
Dans l’utilisation pratique de la grille, l’utilisateur accède aux ressources EGEE avec un courtier de sécurité (CONTES, 2005), appelé proxy dans gLite, valable 12h par défaut. Ce proxy accompagnera les
jobs tout au long de leur processus d’exécution de manière à certifier sa légitimité ainsi que celles des sous-tâches dépendantes. Cette délégation de certification permet ainsi à l’utilisateur de ne s’identifier qu’une seule fois au moment de la création du proxy (single sign-on).
2 http://tools.ietf.org/html/rfc4252 3 http://igc.services.cnrs.fr/GRID-FR
Quant à l’inscription dans une organisation virtuelle (comme d’ailleurs l’obtention d’un compte sur une interface utilisateur), elle résulte avant tout d’un accord multipartite autorisant de nouveaux utilisateurs à accéder aux ressources allouées à une VO. D’un point de vue technique, chaque utilisateur de l’organisation virtuelle est identifié dans un serveur VOMS interrogé au moment de la création du proxy.
V - 1.3. les services d’information et de surveillance des ressources
La gestion de l’information dans un système grand échelle telle que la grille EGEE est cruciale pour garantir son fonctionnement efficace. S’il est encore complexe d’actualiser ces informations en temps- réel, la fréquence de mise à jour doit toutefois être la plus faible possible. Ainsi, comme tout système d’information, l’intergiciel gLite est doté de fonctionnalités permettant à chacun des éléments de la grille de connaître l’existence et l’état des autres ressources. Par exemple, un utilisateur ou un service de l’intergiciel peut à tout moment :
- vérifier l’état d’une ressource
- découvrir les ressources de la grille et leurs caractéristiques - permettre le choix d’un nœud de calcul efficacement - spécifier des critères d’exécution de ces tâches
Il est donc obligatoire pour chaque administrateur de site de publier et d’actualiser l’ensemble de ces informations, c‘est à dire les informations générales relatives au site, la description et l’état des systèmes d’exploitation, des applications, et des données ainsi que les statistiques d’utilisation de l’ensemble des ressources.
Techniquement, deux mécanismes existent sur gLite pour gérer et accéder à ces informations de gestion :
- Globus Monitoring and Discovery Service (MDS) principalement utilisé pour la découverte et la publication de l’état des ressources,
- Relational Grid Monitoring Architecture (R-GMA) dont le fonctionnement, proche de celui du SQL (Structured Query Language), permet de surveiller et publier les informations des ressources au niveau utilisateur
Avec ces services, l’utilisateur accède aux informations relatives aux ressources matérielles dont il dispose dans sa VO :
- les éléments de calcul (CE) - les éléments de stockage (SE)
- les courtiers de ressources (Workload Management Server - WMS) -
V - 1.4. les services de gestion de données
Comme pour l’ensemble des ressources, les données utilisateur sont virtualisées sur la grille, c'est-à- dire que l’utilisateur ne sait pas exactement où ses données sont stockées. Ainsi, chaque fichier est identifié par un LFN (Logical File Name) et un GUID (Grid Unique IDentifier) qui identifient un fichier indépendamment de sa location physique. Alors que le SURL (Storage URL) (ou Physical File Name (PFN)) et le TURL (Transport URL) font référence aux informations physiques du fichier.
L’élément central de la gestion des données est le LFC (LCG File Catalog). Ce catalogue fait le lien entre un fichier, ses répliquas et ses différents types de nommage. Finalement, un ensemble de fonctions de base permettent, comme sur un système d’exploitation classique, de manipuler ces données de manière transparente. Elles sont regroupées sous le terme de LCG utils.
V - 1.5. Les services de gestion des tâches
V - 1.5.1. Un
V - 1.5.1. Unjob de grillejob de grille
Dans la suite de cet exposé, les termes « tâche » et « job » seront utilisés indifféremment pour faire référence aux traitements informatiques envoyés par l’utilisateur sur les ressources de la grille. Depuis l’interface utilisateur, les services de gestion des jobs permettent globalement à l’utilisateur :
- d’éditer les scripts des jobs grâce au langage JDL (Job Description Language) qui est un langage de haut niveau qui consiste à assigner des valeurs à des attributs (attribut = valeur) (PACINI et MARASCHINI, 2007)
- de soumettre ces scripts à la grille en le transmettant au courtier de ressources (WMS)
- de surveiller l’état de ces scripts tout au long de leur exécution (Waiting, Submitted, Ready,
Scheduled, Running, Cancelled, Aborted, Done, Cleared) (Figure 62)
- de retourner les résultats (sorties) de ces scripts
Submitted : job accepté par le WMS
Waiting : recherche d’un CE appropriée par le WMS Ready : WMS prépare la soumission
Scheduled : Mise en file d’attente du CE par le WMS Running : Copie des données d’entrée et exécution sur
le WN
Done : exécution terminée avec ou sans erreur Cleared : résultats récupérés par l’utilisateur
Figure 62 : États d'un job lors de son traitement par l'intergiciel (d’après BURKE et al., 2009 ; CHRISTODOULOPOULOS et al., 2008)
Schématiquement, la soumission de job aux nœuds de calcul de l’architecture EGEE correspond à l’envoi d’un paquet contenant la description du job en JDL, l’exécutable de l’algorithme, et éventuellement les données à traiter et les librairies nécessaires à l’exécution (InputSandbox). Si la
définition d’une grille s’apparente à une architecture distribuée grand échelle composée d’éléments hétérogènes, la grille EGEE impose aux sites fournisseurs de ressources une certaine homogénéité des sytèmes d’exploitation. En effet, il est fortement conseillé aux gestionnaires de sites de fournir des nœuds avec comme système d’exploitation la distribution Scientific Linux4. Par conséquence, un
utilisateur désirant soumettre ses algorithmes sur la grille doit s’assurer qu’ils sont compatibles avec un tel environnement. Type = "Job" ; JobType = "Normal" ; Executable = "/bin/sh" ; Arguments = "test.sh" ; InputSandbox = {"test.sh","input.txt”} ; StdOutput = "std.out" ; StdError = "std.err" ; OutputSandbox = {"std.out","std.err","output.txt"} ;
Figure 63: Exemple d’un job de grille avec gLite
La description du job de la Figure 63 permet d’exécuter le script test.sh qui prend en entrée le fichier
input.txt et génère la sortie output.txt. L’application qui permet d’exécuter ce script est le bash5
(langage de base d’un environnement linux). La présence des attributs InputSandbox et
OutputSandbox indique au courtier que l’utilisateur fournit un algorithme et une donnée d’entrée et
désire recevoir le fichier de sortie et les sorties standards, une fois le job exécuté. Quant aux attributs
StdOutput et StdError, ils permettent de recevoir les informations standards relatives à l’exécution du
job. Il existe de nombreux autres attributs pour spécifier l’environnement d’exécution d’un job dont l’attribut Requirements qui permet de spécifier les contraintes d’exécution du job en se basant sur les attributs du schéma GLUE6 (PACINI et MARASCHINI, 2007). A ce niveau, il est important de spécifier le
type de jobs existants (PACINI et MARASCHINI, 2007) :
- Job
o Normal
o Interactif, entre le job et l’utilisateur o MPICH, approche de parallélisme MPI
o Paramétrique, variation de paramètres et de données d’entrée - DAG (Direct Acyclic Graph), gestion de chaînes de traitements
- Collection, ensemble de jobs indépendants
4 https://www.scientificlinux.org/
5 http://www.gnu.org/software/bash/bash.html
6 Le schéma GLUE (Grid Laboratory for a Uniform Environment) est une description standardisée des ressources de calcul.
Grâce à l’attribut Requirements l’utilisateur peut spécifier le type de système d’exploitation, un élément de calcul, une vitesse de processeur, etc.
V
V- 1.5.2. Soumission d’un job- 1.5.2. Soumission d’un job
L’envoi d’un job sur la grille déclenche une série d’opérations automatiques sur les différents services de la grille (Figure 64). Le WMS accepte (Submitted) et interprète le script du job et se renseigne auprès du système d’information (BDII, Berkeley Database Information Index) de la disponibilité de CE pour exécuter l’algorithme fourni par l’utilisateur (Waiting). Dès qu’un élément de calcul répond aux critères de sélection de l’utilisateur (Ready), le job est mis en file d’attente sur ce CE avant que le LRMS (Local Resource Management System) le place sur un WN pour être exécuté (Scheduled). Concernant les données d’entrées de l’algorithme, l’utilisateur a le choix de les transmettre avec le job (Input Sandbox) ou de les déposer au préalable sur un SE. Dans ce cas, au moment de la réception du job, le WMS vérifie la présence de ces données en interrogeant le catalogue LFC. Enfin, tout au long du processus de traitement du job, l’utilisateur peut se renseigner sur son état en interrogeant le service d’enregistrement et de comptabilité (LB, Logging and Bookkeeping) (Figure 64).
Un tel fonctionnement est considéré comme asynchrone, dans le sens où l’opération de soumission se termine sans être contrainte d’attendre une réponse immédiate du courtier de ressource. Comme cela a déjà été abordé précédemment, le script du job, l’algorithme et les éventuelles données à traiter sont accompagnés du proxy temporaire permettant à ce paquet de transiter d’un élément de la grille à un autre en toute sécurité.
Figure 64 : Services de gLite impliqués dans la soumission d'un job (d’après BURKE et al., 2009 )
En conclusion, l’intergiciel gLite et les services de haut niveau qu’il fournit permet à l’utilisateur de disposer de nombreuses ressources de calcul et de stockage sans se préoccuper, s’il le souhaite, du choix de ces dernières (Attribut Requirement du JDL). En contrepartie, leur éloignement géographique et surtout les nombreuses interactions entre les services de l’intergiciel pour réaliser l’exécution demandée impliquent des temps de latence relativement long (GERMAIN-RENAUD et al., 2008) qui sont
susceptibles de détériorer la performance des applications temps réel. Finalement, en ce qui concerne la grillification des applications, il est important de rappeler la nécessité d’implémenter des exécutables Linux et de s’assurer de la disponibilité des librairies nécessaires à leur exécution sur les éléments de calcul7.
7 Seules les librairies par défaut des distributions Scientific Linux sont présentes sur les éléments de calcul