• Aucun résultat trouvé

6.2 Présentation des services de base de JXTA

7.1.1 Structuration en couches

7.1.3 Le cœur de JUXMEM: le noyaujuk . . . 89

7.2 Gestion de la volatilité . . . 91 7.3 Gestion des ressources mémoire . . . 94

7.3.1 Découverte et allocation mémoire . . . 94 7.3.2 Stockage des blocs de données . . . 96 7.3.3 Publication et découverte de ressources . . . 99

7.4 Gestion des communications . . . 100 7.5 Micro-évaluation expérimentale . . . 102 7.6 Conclusion . . . 107

Dans ce dernier chapitre de la deuxième partie du manuscrit, nous présentons la mise en œuvre de notre proposition d’architecture de service de partage de données pour grille décrite au chapitre 5. Une description de la spécification JXTA et de ses implémentations a été donnée dans le chapitre précédent.

Dans un premier temps, nous présentons une description de l’architecture générale en couches de notre implémentation et l’utilisation des services JXTA. Puis, dans un second temps, nous nous concentrons sur les fonctionnalités offertes par le cœur de cette implémen-tation : son noyau appeléjuk, pour JUXMEM micro-kernel. Nous aborderons en particulier la gestion des ressources mémoire et des communications ainsi que la prise en compte de la volatilité dans un réseau virtuel JUXMEM. Enfin, avant de conclure sur une discussion de

l’implémentation de ce prototype, une micro-évaluation du surcoût de ce noyau et de ses performances est présentée.

7.1 Architecture générale

Dans cette section, nous décrivons la structuration générale de l’implémentation de notre proposition d’architecture JUXMEM. Nous énumérons les couches logicielles présentes dans son implémentation et nous détaillons leurs rôles. Enfin, nous nous attardons sur la couche la plus basse dans les implémentations de JUXMEM : le noyaujuk.

Tout d’abord, éclaircissons l’existence des termes JUXMEM-C et JUXMEM-J2SE. Notre premier prototype implémentant l’architecture de JUXMEM, telle qu’elle a été définie au cha-pitre 5, repose sur la bibliothèque JXTA-J2SE et a donc été codé en Java. Cette implémen-tation est appelée JUXMEM-J2SE. Toutefois, en raison de l’utilisation de JUXMEM par des intergiciels principalement développés en utilisant les langages C/C++ et pour des raisons de performance (voir chapitre 10), nous avons progressivement basculé vers l’utilisation de la bibliothèque JXTA-C. Cette autre implémentation est appelée JUXMEM-C. Notons que ces implémentations sont compatibles entre elles. Ainsi, un réseau JUXMEM peut être com-posé d’une utilisation mixte des implémentations JUXMEM-C et JUXMEM-J2SE : un client JUXMEM-C peut dialoguer avec un fournisseur JUXMEM-J2SE par exemple.

Dans ce chapitre, nous axons notre présentation sur l’implémentation JUXMEM-C, ver-sion la plus aboutie du cœur de notre contribution : le noyaujuk.

7.1.1 Structuration en couches

Les implémentations JUXMEM-C et JUXMEM-J2SE sont constituées de trois couches pré-sentes sur l’ensemble des pairs : le noyaujuk, la couche de tolérance aux fautes et enfin la couche des protocoles de cohérence. La figure 7.1 présente cette hiérarchie des couches du service JUXMEM, leurs rôles étant décrits ci-dessous, en partant du bas de la pile des couches.

Noyaujuk. Le noyaujukest constitué de deux parties : 1) la partie haute disponible pour les applications utilisatrices de JUXMEMet 2) la partie basse disponible pour les couches des protocoles de cohérence et de tolérance aux fautes. L’objectif du noyaujuk, appelé par la suite simplementjuk, est en effet double. Premièrement, il s’agit de fournir aux applications une implémentation des spécifications de l’interface de programmation du service de partage de données. C’est l’objectif de la partie haute dejuk. Deuxièment, il s’agit de mettre à disposition des briques de bases adaptées concernant la publication et la découverte de ressources, les communications ainsi que le stockage des données dans l’espace d’adressage des pairs. En outre, ces briques de bases doivent s’abstraire de l’environnement pair-à-pair (P2P) choisi pour l’implémentation dejuk. Cette indé-pendance des couches supérieures vis-à-vis du choix de la bibliothèque P2P est préci-sément l’un des objectifs de la partie basse dejuk.

Couche de tolérance aux fautes. L’objectif de cette couche est de tolérer les pannes franches (ou crashs) et les fautes par omission (perte de messages) qui peuvent se produire au niveau des entités intervenant dans la gestion de la cohérence d’un bloc de don-nées. Cette couche de tolérance aux fautes repose sur l’utilisation de mécanismes clas-siques de l’algorithmique des systèmes distribués tels que la gestion des membres d’un

7.1 – Architecture générale 87

Plate−forme P2P Protocoles de cohérence

Protocoles de tolérances aux fautes

Noyau juk (interfaces bas−niveau) Noyau juk (interface utilisateur)

Application

FIG. 7.1 – Hiérarchie des couches de l’architecture JUXMEM.

groupe, la diffusion atomique, le consensus et des détecteurs de fautes. Par exemple, le nœud qui héberge la copie de référence d’un bloc de données va être répliqué sur un ensemble de fournisseurs afin de tolérer sa défaillance. Mais, cette couche utilise également un mécanisme original de gestion de groupe auto-organisant hiérarchique qui permet de maintenir un degré de réplication suffisant par site d’une grille de cal-cul. L’objectif est toujours de conserver la donnée accessible pour les clients JUXMEM, et cela malgré les fautes qui peuvent se produire. Cette couche s’appuie surjukpour ses besoins de communication mais également de découverte, par exemple des autres fournisseurs. Ainsi, dans le cas de l’exemple précédent, elle va notamment demander à

jukde lui fournir de nouveaux fournisseurs susceptibles d’accueillir une copie du bloc de données.

Couche de protocoles de cohérence. L’objectif de cette couche est de s’assurer du partage cohérent d’une donnée entre un ensemble de clients. Pour ce faire, elle fournit les pri-mitives de base pour l’implémentation de protocoles de cohérence définis dans le cadre des travaux menés sur les systèmes à MVP. Actuellement, cette couche offre un pro-tocole hiérarchique et tolérant aux fautes qui implémente le modèle de la cohérence à l’entrée. Cette couche s’appuie sur la couche de tolérance aux fautes pour répliquer les entités critiques, traditionnellement présentes dans les protocoles issus des systèmes à MVP. En outre, la couche des protocoles de cohérence interagit avec juk, pour sto-cker dans l’espace d’adressage des fournisseurs les données partagées, mais également pour la gestion de l’hétérogénéité des architectures des machines sur lesquelles s’exé-cutent les pairs.

La gestion hiérarchique et conjointe des protocoles de cohérence d’un côté, et les mé-canismes de tolérance aux fautes de l’autre, font l’objet des travaux de thèse de Sébastien Monnet. De ce fait, ces deux couches ne seront pas plus détaillées dans ce manuscrit. Le lecteur intéressé peut se reporter à [127].

Groupe JXTA de niveau 1 Client Fournisseur Gestionnaire Groupe JuxMem JuxMem JXTA Groupe data

Groupe cluster A Groupe cluster C

Groupe cluster B

Groupe net privé Groupe ID1

Groupe ID2

Groupe ID3 Pair standard

Pair rendez−vous Groupe JXTA de niveau 0

FIG. 7.2 – Projection des entités JUXMEMsur les entités JXTA.

Les deux implémentations JUXMEM-C et JUXMEM-J2SE représentent respective-ment 13 500 et 16 700 lignes de code. Elles reposent respectiverespective-ment sur JXTA-C 2.3 et JXTA-J2SE 2.3.5. La dernière version de JUXMEM(0.3) date du 7 août 2006.