8.2.1 Besoins pour la gestion de données . . . 114 8.2.2 Application motivante . . . 115 8.2.3 Propositions existantes pour la gestion des données . . . 116
8.3 Utilisation de JUXMEMau sein de l’intergiciel Grid-RPC DIET . . . 117
8.3.1 Présentation de l’environnement DIET . . . 117 8.3.2 Mise en œuvre de l’utilisation de JUXMEM . . . 119
8.4 Évaluation de JUXMEMau sein de DIET . . . 122
8.5 Discussion et conclusion . . . 125
Dans cette troisième partie du manuscrit, nous présentons l’utilisation et l’évaluation de JUXMEMau sein de deux modèles de programmation : le modèle Grid-RPC (ce chapitre) et les modèles composant (chapitre 9).
Le premier chapitre de cette partie décrit l’utilisation de JUXMEM dans le modèle de programmation Grid-RPC. Dans un premier temps, le modèle Grid-RPC et les propositions actuelles pour la gestion des données dans ce modèle sont présentés. Au vu des lacunes des différentes solutions, nous proposons dans un deuxième temps l’utilisation de notre concept de service de partage de données pour la gestion des données persistantes dans ce modèle de programmation. Nous détaillons l’utilisation de JUXMEM au sein de l’intergiciel DIET, qui implémente le modèle Grid-RPC. Enfin, dans un dernier temps, une évaluation des bé-néfices de notre proposition pour la gestion des données est présentée. Cette évaluation est effectuée via un code synthétique. Par ailleurs, nous avons également exécuté avec succès
une application réelle s’exécutant au-dessus de l’intergiciel Grid-RPC DIET et utilisant JUX -MEM pour la gestion de ses données. Ce travail a été réalisé en collaboration avec Eddy Caron1.
8.1 Le modèle de programmation Grid-RPC
Le modèle Grid-RPC [155] est né d’un effort duGlobal GridForum(GGF) pour standar-diser et implémenter, dans le contexte des grilles de calcul, le modèle de programmation par appel de procédures (Remote Procedure Call, RPC [131]). Comparé au modèle RPC classique d’Unix, le modèle Grid-RPC inclut également la possibilité d’effectuer des tâches parallèles à gros grain de manière asynchrone. Les requêtes de calcul à distance peuvent en effet être traitées par des serveurs séquentiels ou parallèles. Toutefois, ce parallélisme potentiel au niveau des serveurs n’est pas visible au niveau des clients.
Le modèle Grid-RPC a été défini dans le cadre du groupe de travailGRIDRPC-WG [212], dirigé par Craig Lee. L’objectif visé par ce groupe de travail est de définir la syntaxe ainsi que la sémantique des opérations disponibles dans l’interface de programmation du côté client de ce modèle [155]. Ainsi, les programmeurs d’applications basées sur le modèle Grid-RPC peuvent utiliser différentes implémentations sans avoir à se soucier de la portabilité de leur code. Cette spécification précise également les entités impliquées dans le modèle Grid-RPC ainsi que leur rôle. Le modèle Grid-RPC vise à mettre en place une infrastructure logicielle pour l’utilisation des ressources de calcul d’une grille par différentes applications s’exécutant de manière concurrente. Nous appelonsplate-forme de calcul(en anglaisNetwork Enabled Server, NES) un intergiciel déployé sur une grille de calcul qui offre l’interface de programmation du modèle Grid-RPC aux développeurs d’applications. Des exemples de tels intergiciels sont par exemple DIET [54], Ninf [130], NetSolve [26], OmniRPC [154] ou XtremWeb [52]. Dans la suite de ce manuscrit nous les notonsintergiciel Grid-RPC.
La figure 8.1 présente de manière conceptuelle les différentes entités du modèle Grid-RPC ainsi que leurs interactions sous la forme d’étapes. Unservice s’enregistre dans un ré-pertoireafin d’être disponible dans la plate-forme de calcul (étape 1). Notons qu’un service est hébergé au sein d’un processus d’une machine appelée serveur et que plusieurs services peuvent s’exécuter dans un processus (par utilisation de processus légers). Par ailleurs, un service peut par exemple lancer un ensemble de processus MPI afin de résoudre un pro-blème. Pour simplifier cette multitude de configurations possibles et par abus de langage, nous utilisons le termeserveurpour désigner le processus d’un serveur qui héberge poten-tiellement plusieurs services. Afin de découvrir le service qu’il recherche, un processusclient
d’une machine contacte un répertoire (étape 2) qui va éventuellement lui retourner une réfé-rence de fonctionsur le service recherché (étape 3) s’il est connu. Notons que le modèle Grid-RPC ne spécifie pas les mécanismes à utiliser pour la découverte des services. Le client peut alors utiliser cette référence de fonction pour appeler le service (étape 4) qui va effectuer le calcul et éventuellement retourner un résultat (étape 5). À l’étape 3, l’objectif des intergiciels Grid-RPC est de trouver un serveur approprié (si ce n’est le meilleur !) pour chacune des requêtes à traiter, et cela parmi un ensemble de serveurs candidats. Ce choix s’effectue en prenant en compte des informations sur l’efficacité des différents serveurs disposant du ser-vice recherché. Ces informations peuvent être statiques, telles que par exemple la fréquence
8.1 – Le modèle de programmation Grid-RPC 113 Appel Grid−RPC Répertoire 1 5 4 Client Service Enregistrement Résultats 2 3 Référence de fonction Recherche
FIG. 8.1 – Illustration des entités conceptuellement présentes dans le modèle Grid-RPC.
du processeur de la machine et la taille de sa mémoire vive, mais également dynamiques comme les services installés, la charge de la machine, la localisation des données nécessaires aux calculs, etc. Cet équilibrage de charge au sein de la plate-forme de calcul est réalisé par un ou des agents qui implémentent de manière distribuée la fonctionnalité de répertoire. L’objectif de ces agents est alors d’optimiser le débit global de la plate-forme de calcul.
Dans la terminologie Grid-RPC, une référence de fonction (en anglaisfunction handle) re-présente une association entre une chaîne de caractères correspondant au nom d’un service, appelé également problème, et une instance d’une fonction implémentant ce service sur un serveur. Une fois l’association entre une fonction et un serveur établie, tous les appels à cette fonction sont réalisés sur le serveur ainsi spécifié. Dans la suite de ce chapitre, nous utili-sons les termesappel Grid-RPC pour désigner un appel sur une telle référence de fonction distante. Un identifiant de session est associé à chaque requête non bloquante et permet de récupérer l’état de la requête, d’attendre la fin de l’appel, d’annuler la requête, d’obtenir le code d’erreur de l’appel, etc. À partir de ces deux concepts, l’interface de programmation du modèle Grid-RPC est principalement constituée des deux fonctions suivantes :grpc_call
etgrpc_call_asyncqui permettent respectivement d’effectuer un appel Grid-RPC d’une
ma-nière synchrone et asynchrone. Le lecteur intéressé par une description plus détaillée de cette interface de programmation peut se référer à [131].
Par ailleurs, la plupart des intergiciels Grid-RPC (DIET et Ninf-G au moins) spécifient troismodes d’accèspour les paramètres d’un appel Grid-RPC. Les paramètres en entrée d’un calcul sont notés être des données enin. Ils ne sont pas modifiables. Les paramètres produits par un calcul sont indiqués être des données enout. Enfin, les paramètres qui peuvent être modifiés pendant un calcul sont des données eninout. Toutefois, le concept de mode d’accès d’un paramètre ne fait pas partie de la spécification du modèle Grid-RPC.
D2
D3 D2
Client C
Serveur Serveur Serveur
2 1 4 4 3 3 D1 S1 S2 S3 D4 D2
FIG. 8.2 – Illustration de la gestion des données dans l’état actuel de la spécification du modèle Grid-RPC pour une série de requête de calculs.