piloter. De manière générale, du fait de l’utilisation deplusieurset non d’un code de simu-lation, ces applications ont besoin d’une infrastructure matérielle d’exécution telle que les grilles de calcul.
La deuxième catégorie d’applications correspond à des applications dites multiparamé-triques. Une telle application consiste en un ensemble de tâches indépendantes relativement simples, mais qui peuvent être parallèles et nécessiter plusieurs machines. L’avantage de l’utilisation des grilles de calcul est alors de distribuer ces tâches sur un nombre toujours plus grand de machines afin d’augmenter le degré de parallélisme de l’application. Elles ne diffèrent entre elles que par de légers changements, par exemple une valeur différente pour un paramètre d’entrée de l’algorithme utilisé pour effectuer le calcul. L’application Grid-TLSE [67] est un exemple d’application multiparamétrique. Elle permet de tester de nombreux algorithmes de résolution de systèmes linéaires, en faisant varier leurs multiples paramètres. Les données qui entrent en jeu sont des matrices pouvant aller jusqu’à plusieurs centaines de mégaoctets, qu’il faut déplacer et partager entre les différents serveurs de calcul. L’application Grid-TLSE est décrite plus en détail à la section 8.2.2.
2.5 Convergence entre les intergiciels pour grilles et les
environ-nements pair-à-pair
Dans cette section, nous discutons de la convergence des intergiciels pour grilles avec les systèmes P2P [84, 170]. Plus précisément, nous présentons la tendance actuelle à utiliser des techniques P2P pour la conception d’intergiciels pour grilles.
En effet, ces deux types de systèmes visent un même objectif : la mise en commun de ressources informatiques. Leur principale différence réside dans les caractéristiques des in-frastructures qu’ils visent. Alors que les systèmes P2P visent l’échelle d’Internet, c’est-à-dire des millions de machines connectées avec intermittence et appartenant généralement à des particuliers, les intergiciels pour grilles visent eux actuellement une échelle entre 1 000 et 10 000 machines disponibles par l’interconnexion de plusieurs grappes de calcul, apparte-nant à différentes institutions. La conséquence est une plus grande volatilité (voir défini-tion 2.6) des entités constituant un système P2P, par rapport aux entités constituant un inter-giciel pour grille. Par ailleurs, les caractéristiques réseaux des grilles de calcul sont très dif-férentes d’Internet. Un système P2P s’exécute généralement sur une topologie réseau plate en latence (de l’ordre de plusieurs dizaines de millisecondes), alors que les grilles de calcul que nous considérons15 ont une topologie réseau hiérarchique en termes de latence (voir section 2.2). Enfin, l’hétérogénéité déjà présente dans les grilles de calcul est largement ac-centuée dans un système P2P. La diversité des machines (en termes de matériel : processeur, mémoire, etc.) constituant Internet est plus grande par rapport à des machines constituant une grille. En effet, les machines formant une grille de calcul sont généralement achetées dans une période de temps réduite, typiquement de 1 à 3 ans, alors que les machines for-mant Internet peuvent avoir des différences d’âge plus importantes.
Malgré la contrainte de volatilité, les systèmes P2P ont démontré leur capacité de pas-sage à l’échelle. Par exemple, les réseaux P2P de partage de fichiers tels que KaZaA [224] ou EDonkey/Overnet [205] supportent plusieurs millions d’utilisateurs. Cette propriété de
passage à l’échelle manque aux intergiciels pour grilles. Ainsi, à mesure que l’échelle des grilles de calcul augmente, l’utilisation de techniques P2P pour la conception d’intergiciels pour grilles est naturelle. L’objectif est de tirer parti des capacités des systèmes P2P en termes de support de la volatilité et de passage à l’échelle dans les intergiciels de gestion et d’ac-cès aux ressources des grilles de calcul. Zorilla [75] est le parfait exemple d’utilisation de techniques P2P dans la mise en œuvre d’un intergiciel pour les grilles. Il s’agit d’un gestion-naire de ressources qui utilise pour sa mise en œuvre la table de hachage distribuée (DHT) Bamboo [148], issue des recherches du domaine des systèmes P2P. Un autre exemple est le projet SP2A [19] qui utilise JXTA [181] pour mettre en œuvre des algorithmes de recherche de services P2P sur les grilles de calcul. À terme, ce projet offrira un intergiciel de gestion et d’accès aux ressources pour grilles de calcul, bâti sur JXTA.
2.6 Conclusion
Dans ce chapitre, nous avons tout d’abord présenté les origines des grilles de calcul et donné notre définition de ce terme. Puis à titre d’exemple, nous avons décrit deux grilles de calcul : la grille expérimentale Grid’5000 [210, 51] et TeraGrid [140], avant de généraliser les caractéristiques des ces infrastructures. Ensuite, nous avons défini et présenté les différents intergiciels utilisés sur les grilles de calcul. Nous avons également décrit les applications scientifiques qui motivent les recherches dans le domaine des grilles de calcul. Enfin, nous avons justifié l’utilisation de techniques P2P pour la conception d’intergiciels pour grilles.
L’analogie avec les réseaux de distribution d’énergie est cependant loin d’être complète pour les grilles de calcul. Actuellement un utilisateur ne peut pas simplement « brancher » son application sur une grille de calcul. Il doit se soucier de détails techniques et donc connaître les intergiciels pour grilles utilisés. En particulier, la gestion des données au sein de ces environnements est de trop bas niveau. Le programmeur doit explicitement localiser les données, les transférer d’un site à un autre, gérer la cohérence des différentes copies d’une donnée, etc. Le chapitre suivant est précisément consacré à la présentation des différentes solutions actuelles pour la gestion de données sur les grilles de calcul.
Chapitre
3
Gestion des données dans les grilles
de calcul
Sommaire3.1 La problématique . . . 23 3.2 Panorama des solutions proposées . . . 25
3.2.1 Gestion à base de catalogues : l’approche Globus . . . 25 3.2.2 Dépôts logistiques de données : l’approche IBP . . . 27 3.2.3 Système de fichiers : l’approche GFarm . . . 29 3.2.4 Accès unifié aux données : l’approche SRB . . . 32
3.3 Critères d’évaluation et limites des systèmes présentés . . . 33 3.4 Conclusion . . . 34
Dans ce chapitre, nous présentons un panorama des solutions utilisées pour la gestion des données sur les grilles de calcul, infrastructures qui ont été présentées au chapitre pré-cédent. Nous établissons tout d’abord la problématique de la gestion de données dans les grilles de calcul. Nous présentons ensuite quatre projets typiques : Globus [86], Internet Backplane Protocol (IBP [33, 143]), Grid DataFarm(GFarm [173]) et Storage Resource Broker
(SRB) [146, 32], ayant chacun une approche différente. À partir de nos critères d’évaluation, nous déterminons leur adéquation avec les besoins des applications scientifiques et leurs limites.
3.1 La problématique
Le chapitre précédent a montré que les grilles de calcul sont des infrastructures qui peuvent offrir une importante puissance de calcul. Toutefois, elles sont également complexes
car constituées de machines diverses et variées. Cependant, les grilles de calcul ont un ob-jectif en termes detransparence d’utilisationpour l’utilisation de leurs ressources. La « prise » d’accès à une grille doit être en mesure de minimiser l’impact sur les applications de l’en-semble complexe des mécanismes de gestion interne.
Cette propriété de transparence doit également s’appliquer sur l’accès et la gestion des données nécessaires pour l’exécution des applications sur les grilles de calcul. Il est souhai-table de décharger les développeurs d’applications de ces aspects afin de leur permettre de se concentrer sur le code métier de leurs applications, mais également de limiter les change-ments d’interface pour les applications existantes. Le développement d’intergiciels pour la gestion de données sur les grilles est donc nécessaire.
Ces intergiciels sont soumis à diverses contraintes. La première est la quantité de données produites. En effet, à mesure que les applications scientifiques qui s’exécutent au-dessus des grilles de calcul effectuent des simulations de plus en plus précises, le volume de données engendrées augmente vertigineusement. Par exemple, l’expérience CMS (Compact Muon So-lenoid [98]) réalisée grâce au détecteur de collisions (en anglaisLarge Hadron Collider [116]) du CERN (Centre Européen de Recherche Nucléaire) va générer, à partir de 2007 et quoti-diennement, des pétaoctects de données à analyser. Dans ce contexte, comment stocker de manière pérenne ces données ?
Une autre contrainte est la nécessité de garder ces données constamment accessibles de-puis n’importe quel site d’une grille. Dans ce cas, quand et comment les stocker de manière efficace ? En effet, ces données peuvent être directement accédées par de nombreux physi-ciens à travers le monde. Mais elles peuvent également servir d’entrée à des applications de couplage de code ou des applications multiparamétriques, telles que nous les avons décrites à la section 2.4.
Dans ces deux types d’applications des données intermédiaires peuvent être produites. Celles-ci sont susceptibles d’être partagées par les différents processus des multiples codes de simulation répartis sur plusieurs sites d’une grille. Par ailleurs et d’après [100], seule-ment 10 % de données produites par les expériences du CERN sont modifiables. Toutefois, l’ensemble des métadonnées doit être modifiable par différents processus applicatifs. Dans ce cas, commentpartager de manière cohérenteces données entre les différents processus ap-plicatifs ? En effet, chaque processus a besoin de mettre à jour tout ou partie de la donnée partagée. Supposons qu’un processusAmodifie une donnée partagée D. Un processusB doit alors être en mesure de s’assurer de la lecture de la dernière version de la donnéeD. Dans notre cas, cela correspond à la valeur écrite par le processusA.
Afin de mettre en œuvre ce partage cohérent, la donnée doit-elle être migrée ou bien répliquée ? La solution choisie est généralement de répliquer la donnée, à la fois pour des raisons de performances mais également de disponibilité. Sur ce dernier point et de manière plus générale, des mécanismes de tolérance aux fautes doivent être mis en place afin de supporter la perte d’une copie de la donnée. En effet, les grilles de calcul sont des infrastruc-tures sujettes à des contraintes de volatilité de par leur échelle (voir section 2.2 pour une estimation sur la grille expérimentale Grid’5000).
Pour terminer, d’autres contraintes viennent encore complexifier le problème. Les grilles de calcul sont des infrastructures hétérogènes. Il faut donc pouvoir être indépendant du format de stockage local d’une machine : 32 ou 64 bits, petit-boutiste (en anglaislittle endian) ou gros-boutiste (en anglaisbig endian). Par ailleurs, la solution mise en œuvre doit passer à