Notion de service de partage de données pour la grille

Chapitre

6

Une approche conjointe Sommaire

6.1 Cadre : le service de partage de données JUXMEM . . . 70

6.1.1 Notion de service de partage de données pour la grille . . . 70 6.1.2 Architecture générale . . . 72 6.1.3 Le noyau JuxMem . . . 74

6.2 Proposition : une architecture en couches . . . 75

6.2.1 Un double besoin de réplication . . . 75 6.2.2 La couche de communication de groupe . . . 79 6.2.3 La couche d’adaptation aux fautes . . . 80 6.2.4 Les protocoles de cohérence . . . 80

6.3 Interactions entre le protocole de cohérence et les mécanismes de tolé-rance aux fautes . . . 81 6.4 Vers une approche générique . . . 82

Dans les chapitres 3 et 4, nous avons vu que plusieurs approches ont été proposées sé-parément, aussi bien pour la gestion de la tolérance aux fautes que pour la gestion de la cohérence des données. Dans le chapitre 5, nous avons montré sur un exemple des solutions pour adapter certaines de ces approches à la grille.

Dans le cadre d’un service de partage de données pour les grilles de calcul, il est néces-saire d’offrir un support pour la tolérance aux fautesetpour la gestion de la cohérence des données.

Ce chapitre décrit une architecture dont le but est de permettre une gestionconjointede la tolérance aux fautes et de la cohérence des données au sein d’un service de partage de données pour la grille. Avant de détailler notre solution, nous décrivons le cadre dans lequel s’inscrit notre contribution : le service de partage de données JUXMEM. Notre approche pour faire face aux problèmes liés au passage à l’échelle sera abordée dans le chapitre suivant.

6.1 Cadre : le service de partage de données JUXMEM

Comme nous l’avons vu à la section 2.2, les applications scientifiques utilisent des quanti-tés de données distribuées de plus en plus grandes. La gestion de la localisation, du transfert et de la cohérence de ces données est devenue un facteur limitant lors de la conception de telles applications. Or il n’existe actuellement aucun système permettant un partage de don-nées modifiables offrant un accès transparent et des garanties de cohérence pour les grilles de calculs. Ces besoins ainsi que les lacunes des mécanismes de partage de données pour les grilles existants sont détaillés dans la section 2.3. Une nouvelle approche consiste à externali-ser la gestion des données partagées par les applications s’exécutant sur la grille. Le concept de service de partage de données pour la grille a été introduit par [4], la section suivante en donne notre vision.

6.1.1 Notion de service de partage de données pour la grille

Au vu des problèmes soulevés par la section 2.3, il apparaît que les propriétés recherchées pour le partage de données pour les grilles de calcul sont : 1) la persistance des données, 2) la cohérence des données, et 3) la transparence d’accès aux données.

Persistance des données. Les données partagées entre différentes entités doivent être per-sistantes. En effet, dans un système distribué, les opérations peuvent être asynchrones. Cela implique qu’une donnée utilisée par une entité d’une application distribuée pourra être utilisée à nouveau, plus tard, par une autre entité. La donnée, ainsi que les éventuelles modifications qui lui ont été apportées, doit rester disponible au cours du temps, jusqu’à ce quelle soit explicitement supprimée. Or, dans un environnement de type grille, les occurrences de fautes sont courantes. Le service de partage de don-nées doit donc mettre en place des mécanismes de tolérance aux fautesafin d’assurer que les données ne seront pas perdues en cas de fautes.

Considérons l’exemple de DIET (pourDistributed Interactive Engineering Toolbox [28]) qui est une plate-forme de calcul développée à l’ENS Lyon au sein du projet de re-cherche GRAAL. Une donnée (une matrice par exemple) utilisée ou produite par un calcul peut être utilisée à nouveau par des calculs qui s’exécuteront plus tard. Entre temps, la donnée doit persister (rester disponible) dans le système afin de permettre aux calculs ultérieurs utilisant cette donnée de s’exécuter correctement. Si le service de partage de données n’offre pas cette propriété, c’est aux clients que revient le rôle de conserver les données, de se les transmettre et donc de maintenir la cohérence entre les différentes copies ainsi créées.

Cohérence de données. Une donnée partagée va, par définition, être accédée par de mul-tiples entités d’une application distribuée et ce à la fois en lecture et en écriture (les écritures peuvent notamment être concurrentes). Un service de partage de données pour la grille doit prendre en compte cette possibilité et mettre en œuvre des proto-coles de cohérence implémentant des modèles de cohérence, à l’image de ce qui a été fait dans les systèmes à mémoire virtuellement partagée (voir section 4.1). Cela signi-fie que le service doit assurer la cohérence des différentes copies de chaque donnée partagée par les clients (ordonner et propager les mises à jour, mettre en attente les processus lorsque cela est nécessaire, etc.).

6.1 – Cadre : le service de partage de données JUXMEM 71 Accès transparent. Un des facteurs limitant dans le développement d’applications

scienti-fiques distribuées à l’échelle de la grille est la gestion explicite de la localisation et du transfert des données (et par conséquence, de leur cohérence). À l’image de ce qui existe dans les systèmes à mémoire virtuellement partagée et dans les systèmes pair-à-pair (P2P pour l’anglaispeer-to-peer), un service de partage de donnée pour la grille se doit d’offrir un accès transparent aux données, par exemple en associant à chaque donnée un identifiant global unique. Cet identifiant peut être utilisé pour accéder à la donnée par chacune des entités de l’application sans avoir à connaître la localisation de la donnée, ni le mode de transfert utilisé.

À la frontière entre deux mondes. L’architecture physique visée par notre service de par-tage de données est celle des grilles de calcul et plus particulièrement celle des fédérations de grappes. Nous visons donc une échelle de l’ordre de quelques milliers de nœuds regroupés en grappes interconnectées. Il est intéressant de noter que cette architecture se situe à la fron-tière entre deux mondes : celui des systèmes à mémoire virtuellement partagée (MVP) d’une part et celui des systèmes pair-à-pair d’autre part. Ceci vaut en terme d’échelle, de volatilité, de degré de confiance et d’homogénéité, comme résumé sur le tableau 6.1. En effet, l’échelle que nous visons se situe entre les échelles généralement visées par ces deux mondes. De même le degré de volatilité, considéré comme nul dans les MVP et comme très élevé dans les systèmes pair-à-pair, est dans notre cas intermédiaire. Les nœuds sur lesquels s’exécute notre service font partie de grappes de calculateurs dédiés et sont moins volatiles que ceux considérés dans les systèmes pair-à-pair. En revanche, l’échelle visée implique tout de même un certain degré de volatilité, comme expliqué dans la section 3.1. Le degré de confiance (et par conséquence le niveau de contrôle des ressources) se situe également à mi-chemin : une fédération de grappe correspond généralement à la mise en commun de ressources entre différentes institutions qui se font confiance.

Les principales différences avec les systèmes à mémoire virtuellement partagée sont : 1) la présence de fautes, et 2) la structure hiérarchique du réseau. Ceci implique qu’il n’est plus possible de considérer des nœuds comme étant stables ni de supposer l’existence d’une connaissance globale de la plate-forme.

La principale différence avec les systèmes pair-à-pair classiques de partage de fichiers en lecture seule est que les données gérées par notre service de partage sontmodifiables. Ce dernier point induit une grande complexité. En effet, il ne s’agit plus seulement de stocker de multiples copies en lecture seule puis de pouvoir en localiser au moins une. Il devient nécessaire de gérer la cohérence de ces données, c’est-à-dire detoutes les copies dechaque

donnée.

Nous ne cherchons pas à concevoir un système pair-à-pair pour la grille, ni un système à MVP passant à l’échelle. Notre service de partage de données se situe au niveau intermé-diaire. Il s’agit d’un service de grille s’inspirant :

1. des MVP pour leurs modèles et protocoles de cohérence de données ;

2. des systèmes pair-à-pair pour leurs propriétés de passage à l’échelle, notamment en terme de support de la volatilité et de localisation des ressources.

Dans la conception de notre service de partage de données pour la grille, nous avons ex-ploité l’aspect hiérarchique des fédérations de grappes afin de faire le lien entre les deux mondes. Nous nous sommes également appuyés sur des résultats théoriques provenant de

MVP Service de données pour la grille ^P2P Échelle (nombre de nœuds) 101–102 103 104–106 Degré de

volatilité ^{Nul Moyen Fort} Contrôle des

ressources et Degré de confiance

Fort Moyen Nul

Homogénéité

des ressources ^Homogènes(grappes) ^{Hiérarchique}(fédérations de grappes) ^{Hétérogènes (Internet)}

Type de

données gérées ^{Modifiables Modifiables Non modifiables} Applications

typiques ^{Calcul numérique Calcul numérique et}stockage de données ^{Partage et stockage de}fichiers TAB. 6.1 – Caractéristiques d’un service de partage de données inspiré des MVP et du P2P.

la recherche sur les systèmes distribués tolérants aux fautes, notamment pour la conception de mécanismes de réplications.