Utilisation et évaluation de J UXMEM dans le modèle Grid-RPC 

Spécifications

A vant de proposer une architecture pour la notion de service de partage de données pour grilles, nous nous définissons l’interface de programmation (en anglais API) qu’un tel service doit offrir aux processus applicatifs.
L ’objectif de cette interface de programmation est double. T out d’abord, nous souhaitons permettre une utilisation transparente des propriétés offertes par un tel service. Par exemple, la volatilité des ressources de stockage mémoire du service doit être gérée de manière transparente vis-à-vis des processus applicatifs. Ensuite, l’utilisation d’un tel service doit être simple et la plus naturelle possible.

Allocation mémoire

L ’interface de programmation pour l’allocation et la libération d’espace mémoire est composée de 8 primitives. Afin de répondre aux objectifs précédemment mentionnés, l’interface de programmation proposée s’inspire des fonctions standard du langage C, familières aux développeurs d’applications. Dans la suite de cette section, nous détaillons ces ensembles de primitives en fournissant, à titre indicatif, leurs prototypes dans le langage C.
Nous les présentons sous la forme de trois groupes. Le premier permet d’allouer et de libérer des espaces mémoire dans notre service de partage de données. Le deuxième ensemble permet : 1) de projeter une donnée partagée dans l’espace d’adressage de processus qui souhaitent y accéder et 2) de détruire localement cette projection. Enfin, le troisième et dernier groupe permet : 1) de projeter une donnée de l’espace d’adressage d’un processus dans desespaces mémoire au sein de notre service de partage de données et 2) de détruire localement cette projection. Ce dernier groupe de primitives n’est pas présenté dans cette section.
Toutefois, l’annexe A.1 présente en détail l’ensemble des primitives de l’interface de programmation offerte par J UXMEM.

Objectif et contraintes

L ’objectif de J UXMEM est de minimiser les temps d’accès aux données partagées. Compte tenu des caractéristiques des grilles de calcul, deux contraintes se dressent face à cet objectif : 1) l’échelle grandissante de ces environnements et 2) la volatilité des machines formant une grille. En effet, la première contrainte nécessite par exemple la mise en place d’un algorithme de localisation d’une donnée partagée adapté à l’architecture des grilles de calcul. La deuxième contrainte, elle, peut ajouter des délais supplémentaires pour effectivement contacter l’entité responsable d’une donnée partagée. Compte tenu de ces contraintes, nous pensons que plusieurs aspects de J UXMEM peuvent être gérés en utilisant des algorithmes inspirés par les systèmes P2P . En effet, ceux-ci ont démontré pouvoir supporter ces contraintes et même les transformer en avantages pour améliorer l’efficacité des services qu’ils offrent.
Cet objectif de performance ne peut être atteint que par une prise en compte des caractéristiques physiques des grilles de calcul, notamment au niveau des performances des liens réseau. En effet, dans une grille de calcul, les machines d’une grappe d’un site sont interconnectées par des réseaux haute performance, appelé System Area-Network (SAN) en anglais.
Ces réseaux ont une latence de l’ordre de quelques microsecondes et un débit pouvant aller à 20 Gb / s. Par exemple, un réseau Myrinet Myri-10G dispose d’une latence de 2 µs et d’un débit de 10 Gb / s dans ses dernières versions. En revanche, les différents sites sont connectés entre eux par des réseaux longue distance, en anglais Wide Area Network (WAN). Les caractéristiques de ces réseaux sont différentes de celles des SAN, en particulier sur le plan de la latence. Celle-ci peut varier d’une dizaine jusqu’à plusieurs dizaines de millisecondes, en fonction de la distance géographique séparant les sites d’une grille et de la charge réseau globale. Ainsi, il existe une différence d’ordre de grandeur pouvant aller de 2 000 à 25 000 pour les latences si l’on compare un réseau SAN et un réseau WAN !
Cette topologie physique hiérarchique est prise en compte au niveau de J UXMEM par l’utilisation de la notion de groupes, issue des systèmes P2P . En effet, à chaque grappe de machines correspond un groupe appelé CLUSTER dont l’ensemble des processus s’exécutant sur cette grappe fait partie. La figure 5.4 représente trois groupes CLUSTER A, B et C audessus d’une grille constituée de trois grappes de machines A, B et C . La connaissance de la topologie réseau sous-jacente permet d’en tenir compte pour l’implémentation des protocoles de cohérence ou de gestion de verrous. L ’objectif est alors de minimiser le nombre des coûteuses communications WAN et de privilégier les communications SAN à faible latence.
Par ailleurs, la notion de groupe permet de repousser la contrainte sur l’échelle des grilles de calcul. En effet, la cardinalité maximale des groupes CLUSTER correspond à la taille d’un site d’une grille de calcul considérée. Cette cardinalité peut même être réduite par division d’un site en différentes sous-grappes virtuelles. Ainsi, le nombre d’entités entrant en jeu dans la gestion d’un tel type de groupe est limité, permettant la mise en place de mécanismes adaptés aux caractéristiques généralement homogènes sous-jacentes. De plus, la notion de groupe permet de limiter les effets de bord avec l’extérieur . En effet, la gestion interne d’un groupe n’est pas visible depuis l’extérieur . Par exemple, la volatilité des fournisseurs d’un groupe CLUSTER n’impacte pas celle de fournisseurs d’un autre groupe CLUSTER.
Toutefois, les différents groupes CLUSTER doivent communiquer entre eux. Ainsi, l’ensemble des processus présents dans J UXMEM font partie du groupe appelé J UXMEM, représenté à la figure 5.4. Ce groupe définit ce que nous appelons le réseau virtuel J UXMEM, ou plus simplement et par abus de langage, le réseau J UXMEM. Cet empilement hiérarchique des groupes présents dans J UXMEM est un élément supplémentaire pour repousser la contrainte sur l’échelle des grilles de calcul. En effet, l’hypothèse que nous pouvons faire sur la cardinalité du groupe J UXMEM et la répartition des processus permettent par exemple de choisir un mécanisme d’allocation mémoire adapté à la fois : 1) à la taille d’une grille et 2) à la présence de communications WAN entre les sites d’une grille. Cet algorithme est détaillé à la section 5.2.3.1. Notons, que pour poursuivre l’utilisation de termes issus des systèmes P2P , nous utiliserons de manière indifférenciée dans la suite de ce manuscrit le terme pair et le terme processus. Enfin, nous abordons la prise en compte de la contrainte de volatilité à la section 5.2.4.

Au sein des communications

Les communications entre les différentes entités du système doivent s’abstraire de la localisation physique des pairs dans le système. En effet, la volatilité des ressources mémoire doit être transparente pour les clients du service. L ’utilisation d’un identifiant logique, pour désigner un canal de communication d’un client ou d’un fournisseur , va permettre de répondre à ce besoin de transparence pour dialoguer avec un fournisseur ou un ensemble de fournisseurs. Le système va dynamiquement résoudre à l’exécution cet identifiant logique en identifiant physique tel qu’un couple adresse IP et port.
Prenons ainsi l’exemple d’un client qui souhaite accéder à une donnée présente dans le service. La figure 5.6 illustre cet exemple, avec une donnée D répliquée sur 3 sites avec 2 copies par site (n = 3 et m = 2). Initialement, un tel client ne dispose que de l’identifiant global et unique de la donnée partagée. Le service doit « résoudre », en interne et de manière transparente, cet identifiant logique en un (ou plusieurs) identifiant(s) physique(s), afin que le client puisse utiliser la donnée partagée. Par ailleurs, ce mécanisme est également utile pour tolérer la volatilité des fournisseurs hébergeant une copie de cette donnée. Ainsi, si par suite d’une défaillance technique le groupe CLUSTER A2 disparaît, le système va être amené à répliquer la donnée sur un autre site afin de maintenir le degré de cohérence souhaité par le client. Afin de pouvoir dialoguer avec ces fournisseurs qui disposent d’une copie de la donnée, il est nécessaire de résoudre à nouveau l’identifiant logique de la donnée. Cette résolution doit être toujours transparente pour le client, qui doit juste noter une éventuelle latence supplémentaire lors de l’accès à la donnée partagée.

Mémoire et l’interface de programmation d’un service de partage de données

De nombreux raffinements ont été nécessaires afin de définir cette interface de programmation. Notons que cette interface est de bas niveau : elle ne considère des blocs de données que sous la forme d’une suite d’octets. Cela s’explique par le type d’application visé, des applications scientifiques où les données à partager sont généralement des tableaux ou des matrices d’octets. T outefois dans un prolongement de ce travail, il serait intéressant de fournir une interface de plus haut niveau, au-dessus de l’interface actuelle, intégrant par exemple des données typées et structurées. Par ailleurs, il est compréhensible de s’interroger sur le choix d’une interface de programmation de type mémoire plutôt que de type fichier . Notre but étant de fournir un paradigme de programmation similaire aux systèmes à MVP, la réponse est relativement simple. En outre, il n’y a pas opposition entre ces deux interfaces de programmation possibles, mais plutôt complémentarité. En effet, il est tout à fait possible de fournir l’interface de programmation de type fichier en s’appuyant sur une interface de type mémoire, via par exemple le projet FUSE [207]. Ainsi, les applications utilisant une interface de programmation par fichier pourraient, et cela de manière transparente, bénéficier des fonctionnalités de notre service de partage de données. Un travail dans ce sens a été initiémais n’est pas encore actuellement achevé et stable.
Dans un deuxième temps, nous avons introduit notre proposition d’architecture, appelée J UXMEM, s’inspirant des techniques P2P , pour la conception d’un tel service de partage de données. L ’utilisation dès le début de telles techniques est nécessaire pour obtenir une architecture extensible et tolérante à la volatilité des ressources participant au service. Nous avons illustré un tel besoin sur la gestion des ressources mémoire et des communications entre les entités de l’architecture. Enfin, nous avons discuté et motivé notre choix d’une plate-forme P2P pour l’implémentation de J UXMEM : la spécification J XTA. Un tel choix nous est apparu clair au vu des fonctionnalités offertes par cet environnement et par la nécessité d’éviter un nouveau développement coûteux des mécanismes P2P nécessaires pour l’élaboration de J UXMEM. Les deux chapitres suivants présentent en détail la spécification J XTA et ses implémentations, puis son utilisation pour l’implémentation de J UXMEM. Nous pouvons conclure que notre service de partage de données répond aux besoins des applications scientifiques qui s’exécutent sur les grilles de calcul : transparence d’utilisation, stockage persistant, partage cohérent et tolérance à la volatilité (voir section 3.1). Comme nous l’avons montré dans notre panorama des solutions utilisées pour la gestion des données sur les grilles de calcul (voir chapitre 3), aucun système actuel ne combine toutes ces propriétés de manière simultanée. Notre service fournit ces propriétés de manière transparente aux applications grâce une approche hybride s’inspirant des systèmes à MVP et des
systèmes P2P (voir chapitre 4). L ’objectif est de conserver les points forts des systèmes à MVP grâce à une conception fondée sur une approche P2P . Cette réponse aux besoins est dans la suite de ce manuscrit évaluée dans deux modèles de programmation utilisés sur les grilles de calcul (voir chapitres 8 et 9).

Un aperçu des protocoles et des services JXTA

La spécification J XTA définit le format des six protocoles qui travaillent ensemble pour la découverte, l’organisation, la surveillance et les communications entre les pairs. Ces protocoles ainsi que leurs rôles sont décrits ci-dessous. La figure 6.3 présente la hiérarchie des protocoles J XTA, leurs dépendances ainsi que leur appartenance aux protocoles noyau de J XTA ou non. Les protocoles noyau sont ceux qu’il est impératif qu’un pair implémente pour qu’il respecte la spécification J XTA. Chaque protocole décrit dans cette section est implémenté sous la forme d’un service réseau de groupe.
Protocole de routage (en anglais Endpoint Routing Protocol). Ce protocole permet à un pair de découvrir la route à suivre pour envoyer un message à un autre pair . Ce mécanisme est utilisé lorsqu’il n’existe pas de route directe entre deux pairs souhaitant communiquer . Il va alors permettre de trouver le(s) pair(s) par lequel le message doit transiter . Ce protocole est l’un des deux protocoles noyau.
Protocole de rendez-vous (en anglais Rendez-V ous Protocol). Ce protocole permet aux pairs standards de s’abonner à un service de réception des messages qui sont propagés dans un groupe J XTA. Il permet également de propager des messages aux pairs membres d’un groupe. Enfin, il permet d’organiser la structure du réseau logique des pairs rendez-vous et cela toujours dans le contexte d’un groupe. Ce protocole repose sur le protocole de routage pour l’envoi et la réception de messages.
Une description plus détaillée du service implémentant ce protocole (service de rendezvous, appelé rendezvous dans le code des implémentations) et de son fonctionnement interne est proposée en section 6.2.1
Protocole de résolution (en anglais Peer Resolver Protocol). Ce protocole permet d’envoyer des requêtes à un ou plusieurs pairs d’un groupe J XTA. Zéro, une ou plusieurs réponses par requête peuvent également être retournées via ce protocole. Ce protocole a pour objectif de permettre l’implémentation de services de plus haut niveau, applicatifs par exemple. C’est à ce niveau de la spécification des protocoles qu’est introduite la possibilité pour un pair de participer à un mécanisme d’index distribué des ressources partagées, en anglais Shared Resource Distributed Index (SRDI). Un tel index est réparti au sein d’un groupe sur le réseau de pairs rendez-vous et permet aux requêtes d’être mieux guidées dans leur diffusion. Le protocole de résolution repose sur le protocole de rendez-vous pour l’envoi et la réception de messages.
Le service de résolution (appelé resolver dans le code des implémentations) implémente ce protocole. Ce protocole est le deuxième protocole noyau.
Protocole de découverte (en anglais Peer Discovery Protocol). Le protocole de découverte repose sur le protocole de résolution pour l’envoi de ses requêtes et des réponses associées.
Ce protocole permet aux pairs de mettre à disposition leurs ressources sur un réseau J XTA, mais également de les découvrir . Comme nous l’avons vu précédemment, chaque ressource est décrite par une annonce. Chaque type d’annonce possède des attributs qui sont utilisés lors de la publication ou de la recherche de ces documents associés aux ressources.
Le fonctionnement interne de ce service (service de découverte, appelé discovery dans le code des implémentations), notamment l’utilisation du mécanisme d’index distribué pour le placement des index des annonces sur le réseau de pairs rendez-vous d’un groupe, est détaillé à la section 6.2.2.
Protocole de liaisons de canal virtuel (en anglais Pipe Binding Protocol). Ce protocole permet à un pair d’établir un canal de communication virtuel avec un ou plusieurs pairs.
Plus précisément, il est utilisé pour mettre en relation les extrémités d’un canal de communication par leur(s) résolution(s) en adresses réseau. C’est le mécanisme au cœur du fonctionnement des communications entre pairs dans la spécification J XTA. Ce protocole utilise le protocole de résolution pour déterminer le(s) pair(s) en écoute sur l’extrémité d’un canal.
Le fonctionnement de ce service (service de canaux virtuels, appelé pipe dans le code des implémentations) est détaillé à la section 6.2.3.
Protocole d’information (en anglais Peer Information Protocol). Ce protocole permet à un pair d’obtenir des informations à propos des autres pairs d’un réseau J XTA. De telles informations peuvent être la charge réseau, la durée de vie du pair , ses capacités, etc. Il repose également sur le protocole de résolution.
En pratique, ce protocole n’est que partiellement supporté par J XTA- J 2SE et n’est donc pas plus détaillé.

Service de découverte

Objectif. Comme nous l’avons vu précédemment, dans un réseau J XTA, chaque ressource disponible est décrite sous la forme d’une annonce. L ’objectif du protocole de découverte est de permettre aux pairs de trouver de telles annonces, toujours au sein d’un groupe. Ce protocole utilise le protocole de résolution pour la propagation des requêtes sur le réseau de pairs rendez-vous. En guise de réponse, le pair émetteur peut recevoir zéro ou plusieurs messages qui contiennent les éventuelles annonces répondant aux critères de la requête. Algorithmique. Les implémentations de J XTA utilisent une table de hachage dite faiblement cohérente (en anglais Loosely-Consistent DHT) pour la mise en œuvre de l’algorithmique du service de découverte. Dans la suite de ce manuscrit nous utilisons le terme LC-DHT pour désigner une telle table de hachage. L ’algorithmique utilisée pour le fonctionnement de la LC-DHT est détaillée à l’annexe A.2.2.
Complexité. Les DHT classiques ont une complexité en O(log n) pour la publication, alors que la LC-DHT a une complexité en O(1) pour cette même opération (2 messages dans lepire des cas). T outefois pour la recherche, une approche basée sur une LC-DHT n’offre pas une garantie équivalente, en O(log n), à celle des autres systèmes à base de DHT. En effet, les implémentations actuelles de J XTA offrent une garantie de recherche en O(r), où r est le nombre de pairs rendez-vous. En effet, le pire cas correspond à une ressource située sur un pair rendez-vous à l’opposé dans l’espace de hachage du pair rendez-vous contacté
sur l’anneau. Le nombre de messages alors émis est en O(r). T outefois, s’il y a convergence des vues locales des r pairs rendez-vous, elle est en O(1) (4 messages dans le pire des cas).
En cas d’absence de cette convergence les paramètres de contrôle du mécanisme du parcours de l’anneau des pairs rendez-vous permettent en pratique de grandement la réduire.
En revanche, cette approche évite d’avoir à maintenir les tables d’une DHT en évitant un trafic fréquent, coûteux et d’une latence relativement élevée. En contrepartie, il est possible d’obtenir des résultats incomplets dans le cas de vues locales très incohérentes. C’est la reconnaissance et la prise en compte de la nature très souvent volatile d’un réseau P2P qui a poussé les concepteurs de J XTA à fournir cette LC-DHT.

Table des matières
Liste des définitions 
1 Introduction
PartieI – Contexte d’étude : la gestion de données à grande échelle 
2 Les grilles de calcul
2.1 Origine et définitions
2.2 Infrastructures matérielles des grilles de calcul
2.3 Intergiciels pour les grilles de calcul
2.4 Utilisation des grilles de calcul pour les applications scientifiques
2.5 Convergence entre les intergiciels pour grilles et les environnements pair-à-pair
2.6 Conclusion
3 Gestion des données dans les grilles de calcul
3.1 La problématique
3.2 Panorama des solutions proposées
3.2.1 Gestion à base de catalogues : l’approche Globus
3.2.2 Dépôts logistiques de données : l’approche IBP
3.2.3 Système de fichiers : l’approche GFarm
3.2.4 Accès unifié aux données : l’approche SRB
3.3 Critères d’évaluation et limites des systèmes présentés
3.4 Conclusion
4 Deux approches pour la gestion des données dans les systèmes distribués
4.1 Les systèmes à mémoire virtuellement partagée
4.1.1 Définition et principe de fonctionnement
4.1.2 Modèles et protocoles de cohérence
4.1.3 Les limites
4.2 Les systèmes de partage de données pair-à-pair
4.2.1 Définition et principe de fonctionnement
4.2.2 Localisation des données et routage
4.2.3 Les limites
4.3 Conclusion
PartieII – Notre contribution : le service J UXMEM 
5 J UXMEM : un service de partage de données pour grilles fondé sur une approche pair-à-pair
5.1 Notion de service de partage de données
5.1.1 Sources d’inspiration
5.1.2 Définitions
5.1.3 Propriétés
5.1.4 Spécifications
5.2 Conception fondée sur une approche pair-à-pair
5.2.1 Objectif et contraintes
5.2.2 Architecture générale
5.2.3 Gestion des ressources mémoire
5.2.4 Gestion de la volatilité
5.2.5 Discussion des choix de mise en œuvre
5.3 Discussion et conclusion
6 Présentation de l’environnement pair-à-pair J XTA
6.1 Présentation générale
6.1.1 Objectifs
6.1.2 Définitions
6.1.3 Un aperçu des protocoles et des services J XTA
6.2 Présentation des services de base de J XTA
6.2.1 Service de rendez-vous
6.2.2 Service de découverte
6.2.3 Service de canal virtuel
6.3 Discussion et conclusion
7 Implémentation de J UXMEM sur l’environnement pair-à-pair J XTA
7.1 Architecture générale
7.1.1 Structuration en couches
7.1.2 Présentation générale de l’utilisation des concepts de J XTA
7.1.3 Le cœur de J UXMEM : le noyau juk
7.2 Gestion de la volatilité
7.3 Gestion des ressources mémoire
7.3.1 Découverte et allocation mémoire
7.3.2 Stockage des blocs de données
7.3.3 Publication et découverte de ressources
7.4 Gestion des communications
7.5 Micro-évaluation expérimentale
7.6 Conclusion
8 Utilisation et évaluation de J UXMEM dans le modèle Grid-RPC
8.1 Le modèle de programmation Grid-RPC
8.2 Gestion des données dans le modèle de programmation Grid-RPC
8.2.1 Besoins pour la gestion de données
8.2.2 Application motivante
8.2.3 Propositions existantes pour la gestion des données
8.3 Utilisation de J UXMEM au sein de l’intergiciel Grid-RPC DI ET
8.3.1 Présentation de l’environnement DI ET
8.3.2 Mise en œuvre de l’utilisation de J UXMEM
8.4 Évaluation de J UXMEM au sein de DI ET
8.5 Discussion et conclusion
9 Utilisation et évaluation de J UXMEM dans les modèles composant
9.1 Les modèles de programmation à base de composants logiciels
9.1.1 Objectifs et définitions
9.1.2 Gestion des données dans les modèles composant existants
9.1.3 Application motivante : problème à N corps
9.2 Extension des modèles composant pour un partage transparent des données
9.2.1 Notion de ports de données
9.2.2 Passage en paramètres de données partagées
9.3 Mise en œuvre au sein du modèle composant CCM
9.3.1 Le modèle composant CCM
9.3.2 Proposition de mise en œuvre
9.3.3 Évaluation
9.4 Discussion et conclusion
Partie IV – T ravaux annexes : adaptation de JXTA pour les grilles de calcul 
10 Optimisation des performances des couches de communication de J XTA
10.1 Présentation des couches de communication de J XTA
10.1.1 Présentation générale
10.1.2 La couche la plus basse : le service point-à-point
10.1.3 Le cœur des communications : le service de canaux virtuels
10.2 Optimisation des performances pour les environnements de type grille
10.2.1 Motivations et méthodologie de test
10.2.2 Optimisation des protocoles J XTA et évaluations
10.2.3 Utilisation de la plate-forme haute performance de communication pour grilles PadicoTM
10.3 Discussion et conclusion
11 Déploiement d’applications J XTA sur une infrastructure de type grille
11.1 Utilisation d’une approche pair-à-pair sur les grilles de calcul
11.2 Déploiement d’applications basées sur J XTA
11.2.1 Une première approche : JDF
11.2.2 Proposition d’un langage de description
11.2.3 Mise en œuvre au sein de l’outil de déploiement ADAGE
11.3 Évaluation du passage à l’échelle de J XTA
11.3.1 Protocole de gestion de vue
11.3.2 Conditions expérimentales et résultats
11.4 Discussion et conclusion
PartieV – Conclusion et perspectives 
12 Conclusion et perspectives
Bibliographie
PartieVI – Annexes 
A.1 Description complète de l’interface de programmation de J UXMEM
A.2 Encore plus sur J XTA !
A.2.1 Performances initiales des couches de communications
A.2.2 Algorithmique du service de découverte
A.2.3 Algorithmique du service de canal virtuel
A.3 Mise en œuvre du modèle d’accès transparent aux données dans le modèle composant CCA
A.4 Définition du langage de description J DL

Lire le rapport complet