5.4 Mise en œuvre du serveur C O RDAG E
6.1.1 Génération de la représentation logique
6.1.3 Intégration du code CORDAGEdans JUXMEM. . . 114
6.2 Couplage de JUXMEMavec le système de fichiers GFARM . . . 115
6.2.1 GFARM: un système de fichiers distribué pour la grille . . . 116 6.2.2 Co-déploiement de JUXMEMet GFARM . . . 117 6.2.3 Vers une gestion coordonnée grâce à CORDAGE . . . 119
6.3 Valorisation dans le cadre du projet LEGO . . . 121 6.4 Conclusion . . . 123
La validation de l’outil de gestion du déploiement dynamique CORDAGE est effectuée dans le cadre du projet de recherche LEGO1 [149]. Ce projet a pour objectif de proposer des solutions algorithmiques pour le calcul haute performance sur des infrastructures à grande échelle. Ces solutions sont exprimées dans un modèle de programmation multi-paradigme pour applications parallèles, prenant en compte les spécificités des grilles de calculateurs. Ces paradigmes de programmation sont aussi divers que le modèle de composant, le modèle d’accès transparent aux données, le paradigme maître-travailleur ou encore le modèle de
workflow. Les applications clientes de ce projet sont issues de domaines de recherche variés, tels que la modélisation des échanges entre océan et atmosphère, la cosmologie ou encore
110
Chapitre 6– Validation : un service de partage de données et un système de fichiers distribué
la manipulation de matrices creuses. De telles applications clientes sont caractérisées par des besoins importants en terme de puissance de calcul, mais aussi en terme de stockage des données. En effet, la taille des données générées par ces applications peut varier du gigaoctet au téraoctet en fonction du type de simulation effectué et de la résolution de calcul demandée. Les données peuvent être transitoires, c’est-à-dire produites par un sous-calcul et consommées par le suivant. Elles doivent donc pouvoir être stockées et accédées de manière rapide pour ne pas ralentir le calcul global. Dans un premier temps nous nous focalisons sur le problème du stockage des données comme un exemple motivant pour valider l’approche CORDAGE.
Dans ce contexte, le stockage des données générées par les applications clientes est as-suré par JUXMEM2, un service de partage de données pour la grille introduit dans [10]. Ce service offre de l’espace de stockage distribué en mutualisant les mémoires physiques des différentes ressources du système. L’espace global est donc la somme des espaces physiques locaux. Il dépend donc directement du nombre de ressources impliquées dans le service. Ce nombre est difficilement prévisible car il n’est pas possible de connaître à l’avance les besoins en espace de stockage pendant l’exécution des applications scientifiques. De plus, avec la génération de données transitoires, ces besoins évoluent de manière significative pendant l’exécution des applications. Il n’est pas raisonnable de dimensionner JUXMEMde manière statique pour stocker l’ensemble de ces données transitoires pendant la durée to-tale de l’exécution. Une telle stratégie entraînerait la réservation de nombreuses ressources largement sous-utilisées.
La problématique du dimensionnement de JUXMEM s’avère donc être un cas d’étude pertinent pour évaluer l’approche proposée par CORDAGE. Celui-ci peut en effet prendre en charge le caractère dynamique du service de partage de données grâce à la reconfigura-tion de la topologie. Ce premier scénario permet de valider l’intégrareconfigura-tion de CORDAGEdans une application ainsi que son aptitude à gérer le déploiement additionnel.
Dans un deuxième scénario, le système de fichiers distribué GFARM [116, 117] est ajouté à JUXMEMafin d’en augmenter les capacités de stockage. L’idée est ici de construire une mé-moire hiérarchique distribuéecomposée d’un service de partage de données en mémoire phy-sique pour les accès rapides et d’un système de fichiers distribué pour le stockage à plus long terme. Du point de vue du déploiement, l’application GFARMdoit être déployée de manière coordonnée avec JUXMEM. Ce deuxième scénario est utilisé pour valider la fonctionnalité de co-déploiement offerte par CORDAGE.
6.1 Vers un JUXMEMdynamique grâce à CORDAGE
Dans le chapitre 3 nous avons montré toute la complexité de la mise en œuvre du déploie-ment de JUXMEM avec ADAGE et ce, malgré les efforts effectués pour rendre le pilotage d’ADAGE plus aisé. Les besoins en terme de dynamicité topologique du service de par-tage de données sont une motivation supplémentaire à l’utilisation de l’outil de gestion du déploiement CORDAGE. Dans le chapitre 5, nous avons montré que l’adaptation de CO R-DAGE à un type d’application se faisait en définissant des fonctions génériques virtuelles et des fonctions spécifiques. Dans cette section, nous montrons comment définir la fonction ayant la charge de la construction de la représentation logique puis comment ajouter des
6.1 – Vers un JUXMEMdynamique grâce à CORDAGE 111 Projection Site A Site B Client Gestionnaire Fournisseur Groupe "cluster" A Groupe "cluster" B Grille 1 Grille 2 Racine Site A Site B Grappe 1 Grappe 2 Déploiement Représentation logique Client Fournisseur Gestionnaire Fournisseurs Clients Gestionnaire
FIG. 6.1 –Vue générale des transformations, de la description de la topologie JUXMEMjusqu’au dé-ploiement sur les machines, en passant par la représentation logique et la projection sur les ressources physiques.
fonctions spécifiques pertinentes pour la gestion du système JUXMEM. Le travail suivant a été effectué pour les deux versions de JUXMEM, la version basée sur JXTAet la version géné-rique. Pour des raisons de clarté et parce que le principe reste le même, nous ne présentons ici que la deuxième version.
112
Chapitre 6– Validation : un service de partage de données et un système de fichiers distribué
6.1.1 Génération de la représentation logique
La première étape de l’adaptation de CORDAGEà JUXMEM est la définition des straté-gies de construction de la représentation logique à partir de la description de l’application3. Le travail principal consiste à établir les liens entre la topologie de l’application, composée degroupes clusteret les nœuds et groupes de l’arbre logique. Pour cela, il faut proposer le critère pertinent pour le placement des entités lors du déploiement. Dans le contexte de JUX -MEM, le critère le plus intuitif est la proximité réseau en terme de latence et débit. Le choix de ce critère est basé sur la connaissance fine du fonctionnement de l’application. Il doit per-mettre 1) d’optimiser les communications entre les clients et les gestionnaires pour garantir un service de partage de données efficace et 2) de distribuer lesgroupes clustersur des sites multiples pour tolérer les pannes sur un site complet.
La figure 6.1 montre une vue générale des transformations effectuées depuis la descrip-tion de l’applicadescrip-tion jusqu’au déploiement. L’idée est ici de placer chaquegroupe clusterde la description de l’application dans un nœud logique différent. Cette première contrainte permet d’exprimer que les groupes clusterne soient pas déployés sur un même groupe de ressources physiques. De plus, JUXMEMne définit aucun lien hiérarchique entre les groupes en terme de topologie ou d’affinité pour les interactions. Nous faisons donc le choix de placer les différents nœuds logiques sur un même niveau dans l’arbre. Cette deuxième contrainte garantit de déployer lesgroupes clustersur des groupes de ressources physiques différents et de même niveau dans la représentation physique.
Lesgroupes clusterpeuvent contenir trois types d’entités : les clients, les fournisseurs et le gestionnaire. La question est maintenant de savoir comment organiser ces différentes entités au sein de chaque nœud logique. Une première solution est de créer un groupe logique pour toutes les entités appartenant à ce nœud. Cette solution n’est cependant pas adaptée car ces entités ont des comportements différents, en particulier quant à la durée d’exécution. Ainsi le gestionnaire est-il amené à rester opérationnel pendant toute la période de disponibilité du service. Les fournisseurs doivent être déployés suivant les besoins en espace de stockage. Les clients doivent être déployés uniquement le temps d’effectuer leurs calculs. Le choix a donc été fait de placer ces trois types d’entités dans des groupes logiques différents. Les groupes logiques appartenant à un même nœud sont bien sûr tous projetés sur le même groupe physique ; ils bénéficient d’identifiants de réservation différents, ce qui permet plus de modularité dans la gestion des réservations. Ceci est notamment intéressant lors de la rétraction de fournisseurs ou de clients : il suffit alors de supprimer la réservation attachée à leur groupe logique.
La représentation logique ainsi fixée est mise en œuvre dans la fonction générique vir-tuellegenerate_logial_topology(voir section 5.4.3.4), en utilisant l’interface de gestion de la représentation décrite en section 5.4.2.1. Cette fonction est lancée lors du déploiement initial. La topologie adoptée peut être spécifiée par l’utilisateur à l’aide d’un fichier de description de l’application. Si aucun fichier n’est renseigné, la topologie déployée est minimale : elle consiste en un uniquegroupe cluster contenant un gestionnaire. L’aspect dynamique s’ex-prime dans JUXMEM, par l’ajout et le retrait degroupes cluster, de fournisseurs et de clients. Dans ce choix de représentation logique, ceci se traduit par l’ajout et le retrait de nœuds et de groupes logiques.
3Un exemple de description d’application JUXMEMest présenté dans le listing 3.12. L’architecture de JUX -MEMest présentée dans la section 3.2.1
6.1 – Vers un JUXMEMdynamique grâce à CORDAGE 113