Contribution à la gestion des données dans les grilles de calcul à la demande : de la conception à la normalisation

Transcription

1 N d ordre 1106 THÈSE présentée à L U.F.R. DES SCIENCES ET TECHNIQUES DE L UNIVERSITÉ DE FRANCHE-COMTÉ pour obtenir le GRADE DE DOCTEUR DE L UNIVERSITÉ DE FRANCHE-COMTÉ Spécialité : Automatique et Informatique Contribution à la gestion des données dans les grilles de calcul à la demande : de la conception à la normalisation par Bruno DEL-FABBRO Soutenue le 24 novembre 2005 devant la Commission d Examen : Directeur L. PHILIPPE Professeur à l Université de Franche-Comté, LIFC Rapporteurs L. BRUNIE Professeur à l INSA Lyon, LISI J.-L. PAZAT Professeur à l INSA Rennes, IRISA Examinateurs J. BAHI Professeur à l Université de Franche-Comté, LIFC F. DESPREZ Directeur de recherche INRIA D. LAIYMANI Maître de Conférences à l Université de Franche-Comté, LIFC J.-M. NICOD Maître de Conférences à l Université de Franche-Comté, LIFC

2 2

3 Remerciements Je tiens à remercier les personnes suivantes : l ensemble des membres du jury et en particulier Lionel Brunie et Jean-Louis Pazat qui ont accepté de rapporter sur ma thèse. Leurs remarques ont largement contribué à améliorer la qualité de ce document ; Frédéric Desprez pour sa participation au jury et avec qui j ai eu un très grand plaisir à travailler ; Laurent Philippe qui a été mon directeur de thèse au cours de ces trois ans. Je le remercie pour sa confiance, sa disponibilité et ses fulgurances ; Jean-Marc Nicod et David Laiymani qui ont co-encadré mon travail avec patience et tact. l ensemble des membres du projet GRAAL sans qui cette thèse n aurait pu s inscrire dans un cadre aussi riche. Je remercie en particulier les collègues de l ENS de Lyon pour les nombreuses, productives et sympathiques réunions de travail ; les membres du LIFC pour leur accueil durant mes années de thèse, pour les conseils, les cafés, les encouragements et les discussions politico-footballistiques. Merci en particulier : à Sylvain Dahan pour ses conseils techniques et culinaires ; à Pierre-Alain Masson pour ses apports latexiens et son amitié ; aux membres du département Informatique de l IUT de Belfort pour leur accueil lors de mes vacations dans leur établissement ; la CNAM et la CPAM de Besançon qui m ont permis de réaliser cette thèse. Grand Boub, Petit Roro et Tonton Fred, pour leur amitié. Mes chefs encadrants adorés (encore!!), Laurent, Jean-Marc et David, parce que cela n a pas du être facile d encadrer un senior, ronchon en plus. David, je te promets, en 2007, je te cacherai. Ma famille et ma belle famille qui m ont supporté pendant ces trois ans ; Myriam mon coeur que j aime, pour son amour et sa patience qui ont été mis a rude épreuve et qui a du assumer seule plein de choses. Un petit mot pour toi Oriana. Je t aime. tous ceux que j ai oublié, et il y en a forcément. Qu il s agisse de ma famille, de mes collègues, de mes amis ou de personnes croisées à l occasion d un déplacement, nombreux sont ceux qui m ont apporté aide et soutient durant ces trois années. Merci à tous.

4 2

5 Résumé Les grilles offrent des moyens de collaboration et de partage de ressources pour une communauté scientifique répartie dans le monde. Elles répondent à deux conceptions sensiblement différentes : l une (public resource computing ou global computing) basée sur des relations d échanges entre les différents participants et les projets développés ; l autre (grid computing) basée sur des organisations propriétaires de ressources également appelées les Organisations Virtuelles (VO). Au sein de ces organisations virtuelles, des solutions ont émergé pour couvrir les besoins particuliers des scientifiques qui accèdent et manipulent des collections de données distribuées Ces solutions, appelées grilles de données, tendent à unifier et à rendre transparent l accès à ces données. Dans ce document, nous proposons des solutions pour la gestion des données pour les environnement ASP. Le paradigme ASP (Application Service Provider) est une approche particulière des grilles de calcul. Il consiste à offrir un accès transparent à un parc de serveurs de calculs, proposant chacun un ensemble de services, sur la base du paradigme d appel à distance RPC (Remote Procedure Call). Dans ce cadre, la problématique de gestion des données consiste à minimiser le nombre de transmissions des données entre un utilisateur et la plate-forme de calcul. Nos propositions ont été validées par une mise en œuvre pour DIET (Distributed Interactive Engineering Toolbox). Notre service utilise la persistance des données, leur redistribution entre les serveurs de calcul et leur réplication. Les résultats expérimentaux confirment la pertinence de notre approche. Sur la base de notre expérience, nous proposons de complèter la norme GridRPC du Global Grid Forum. La proposition que nous défendons au sein du GridRPC Working Group est détaillé en fin de document. Mots clés : grilles de calcul, gestion des données, persistance, réplication, GridRPC. Abstract Grids allow the world wide scientific community to collaborate and to share resources. They range over two distinct categories, one of which (public resource computing or global computing) is based on relationships to exchange between the various participants and the projects being developped. The other (grid computing) is based on ressources proprietary organisations called Virtual Organisations (VO). In the context of these virtual organisations, solutions have come out that correspond to the various needs of the scientists to access and manipulate distributed data collections. These solutions, called data grids, lean towards a unification and transparency of the data access. We propose, in this document, solutions for managing data in ASP environments. The ASP (Application Service Provider) paradigm is a particular approach to grid. It consists in offering a transparent acces to a pool of computational servers where each server provides a set of services. It is compliant with the RPC (Remote Procedure Call) paradigm. In this kind of framework, the data management problematic is to minimize the amount of data transmission between a user and the computing platform. Our propositions are validated by a implementation in the DIET (Distributed Interactive Engineering Toolbox) environment. Our service uses the data persistency, their redistribution between the computing servers and data replication. Experimental results show the soundness of our approach. Based on our experience, we propose to complete the GridRPC standard of the Global Grid Forum by adding a data management API. This proposition is detailed at the end of the document. Keywords. grid computing, data management, persistency, replication, GridRPC.

6 4

7 Table des matières Introduction 1 1 La grille et les données Contexte Le calcul global SETI Condor XtremWeb Les machines parallèles virtuelles Legion Globus Le calcul à la demande Le paradigme GridRPC NetSolve Ninf DIET Les standards pour la grille La gestion des données dans les grilles de calcul Les grilles de données Le stockage et le transfert La réplication L ordonnancement Des exemples de grilles de données Les environnements de résolution de problèmes et les données NetSolve Ninf

8 6 TABLE DES MATIÈRES JuxMem Conclusion La problématique de gestion des données dans les environnements ASP La vision du client Cas standard Une séquence de requêtes pour un seul serveur Une séquence de requêtes avec plusieurs serveurs Les données externes Le parallélisme de tâches Cas d utilisation Premiers enseignements La Persistance des données Définition Les gains attendus Les solutions existantes La redistribution des données Localité et localisation La localisation des données La transparence de la gestion des données La conservation des données La réplication Les gains apportés par la réplication La création des réplicats La tolérance aux fautes Le pré-placement des données et la réservation Le pré-placement des données La réservation Aperçu d architecture d un service de gestion des données Autres aspects de la gestion des données La persistance et la redistribution dans DIET Architecture DIET Le service de gestion des données dans DIET Contexte d implantation du service

9 TABLE DES MATIÈRES L architecture du Data Tree Manager Le DataMover Le LocManager L identifiant de la donnée L API cliente Le mode de persistance Le fonctionnement du DTM Les échanges dans l infrastructure Initialisation du DTM La gestion des données par le DTM Fonctionnement d une requête utilisant la persistance Les concurrences d accès Propositions Durée de persistance L extensibilité de la plate-forme Choix d implémentation L API de gestion des données et le Global Grid Forum Enjeux La réplication dans DIET Le service de réplication La structure et l organisation Le service d estimation du temps de transfert Exemple d ajout d un réplicat La réplication intelligente Le client Le SeD L agent L ordonnancement L ordonnanceur pour le placement des données L algorithme de réplication et d ordonnancement Architecture fonctionnelle L implantation Synthèse

10 8 TABLE DES MATIÈRES 5 Mise en oeuvre du service DTM Le DTM sans réplication Coût de mise en place de l infrastructure Opérations sur les données DTM et NetSolve Cas d utilisation : extraction de surfaces en imagerie médicale La gestion de la réplication avec le DTM Opérations sur les données Synthèse Conclusion et perspectives 121 A Proposition d API de gestion des données au sein du Global Grid Forum 125 Proposition d API de gestion des données au sein du Global Grid Forum125 A.1 L API de gestion des données A.1.1 Le data handle A.1.2 Les fonctions de gestion des données A.1.3 La fonction init A.1.4 La fonction bind A.1.5 La fonction write A.1.6 La fonction read A.1.7 La fonction free data A.1.8 La fonction inspect data A.2 Exemples d utilisation A.2.1 Les données d entrée A.2.2 Les données temporaires et les résultats A.3 Exemple de code A.4 A.3.1 Sans persistance des données A.3.2 Simple appel RPC dans lequel les données d entrée et les résultats sont stockés dans la plate-forme A.3.3 Deux appels RPC successifs sur le même serveur A.3.4 Deux appels successifs sur des serveurs différents État d avancement de la proposition et discussion en cours Liste des publications personnelles 137

11 Table des figures 1.1 L architecture du Globus Toolkit Soumission de problème dans un environnement de type GridRPC Architecture de grille Architecture de SRM Architecture de Giggle Ordonnancement des transferts de données avec Stork Architecture de SRB Un DAG pour le request sequencing Distributed Storage Infrastructure Exemple de soumission standard du produit matriciel A = B C Exécution de D = B C + C sur un serveur Exécution de D = B C + C sur deux serveurs Exemple de soumission standard de plusieurs requêtes successives - données non présentes chez le client Calcul asynchrone de A = 2 i=0 (α B + β B)) Application de Cinétique de Monte-Carlo (KMC) en physique suivie d une phase de visualisation Modèle Numérique de Terrain Extraction d Iso Surface Les sources des données dans les environnements de résolution de problèmes Exemple dans lequel la persistance des données est utile Exemple dans lequel la redistribution des données est utile Importance de la localité des données dans le choix du serveur Exemple dans lequel la réplication des données est utile L architecture d un service de gestion des données dans les PSE Vue générale de DIET

12 10 TABLE DES FIGURES 3.2 Intéraction entre FAST et DIET Initialisation d un système DIET L architecture générale du Data Tree Manager Structure de la liste des données conservées dans le DataManager La connexion DataManager au SeD Le DataMover La connexion LocManager à l agent L infrastructure du DTM Initialisation du DTM Ajout d une donnée Suppression d une donnée Déplacement d une donnée La récupération de données par le DataManager Opérations réalisées par le LocManager La donnée n est plus dans la plate-forme d origine Recherche d une donnée par un MA invoqué par un client Opérations réalisées par un MA contacté par un autre MA pour une recherche de données Gestion des données avec réplication L architecture du Data Tree Manager étendue à la réplication Architecture de réplication Les choix possibles de structuration des réplicats Fonction estimtransfer DataManager Les cliques Ajout d un réplicat Fonction récupèredonnée du DataManager Architecture fonctionnelle liée à DynSRA Cycle d une requête Interactions DTM/SRA Résultats de la soumission de l opération B = α A + β Résultats de la soumission de l opération A = α A + β Résultats pour la séquence C = A B, D = E + C, F = t D Séquence d appels : A = B C, D = E + F, G = A D

13 TABLE DES FIGURES Plate-forme de tests Résultats expérimentaux pour la séquence d opérations : C = A B, D = C + E, A = t A en utilisant NetSolve et DIET Temps de calcul d une surface extraite en fonction de la taille de l image en entrée Temps de calcul de l application en fonction du nombre de requêtes pour une séquence synchrone Temps de calcul de l application en fonction du nombre de requêtes pour une séquence asynchrone A.1 Simple appel RPC avec des données en entrée A.2 Ajout d une donnée sur un serveur spécifique A.3 Donnée temporaire conservée dans la plate-forme A.4 Résultat retourné au client A.5 Résultat sur un serveur de stockage A.6 Appel RPC dans lequel A, B et C sont conservées dans la plate-forme A.7 Deux appels successifs sur le même serveur A.8 Deux appels successifs sur des serveurs différents

14 12 TABLE DES FIGURES

15 Liste des tableaux 2.1 Temps de transfert d une chaine en secondes Latence réseau en ms Débit du réseau en MBits/s Modes de persistance Le coût d ajout du DTM à DIET Nombre de transferts de la donnée d entrée

16 14 LISTE DES TABLEAUX

17 Introduction La naissance de l Internet a ouvert de considérables horizons à la communauté scientifique. En effet, il est devenu envisageable d accroître considérablement les possibilités d échanges d informations mais aussi la puissance de calcul potentielle à l ensemble du parc informatique mondial. L apparition des grilles de calcul est issue de ce dernier postulat. Une nouvelle ère est née tendant à essayer d inverser le rapport entre les besoins et la puissance de calcul offerte au bénéfice de cette dernière. Une des réponses apportée par la communauté informatique aux sollicitations des scientifiques d autres disciplines a été de répartir les calculs sur un ensemble de calculateurs distribués à travers le monde et globalement sous-exploitées. En effet, il est très rare qu un ordinateur personnel, un ensemble de stations réparties sur un réseau local ou un supercalculteur parallèle, soient utilisés continuellement en exploitant complètement les ressources matérielles et logicielles. Le terme de grille décrit ainsi une infrastructure de calcul répartie permettant d exploiter des ressources de calcul éventuellement sous-exploitées. Une grille de calcul est donc développée à grande échelle tout en garantissant une haute qualité de service et un faible coût économique. La création de l Internet a été un facteur déterminant dans le développement des grilles. Ainsi, simultanément aux grilles de calcul, sont apparus les concepts de grilles d informations et de grilles de données. Les grilles d information sont les sites Web qui offrent une relative transparence d accès à l information. Les grilles de données offrent également l accès à des données, telles que de la vidéo ou de la musique par exemple, en proposant des systèmes de stockage et de partage des données. L ensemble de ces types de grilles sont développés autour de deux modèles de déploiement : le modèle client-serveur et le modèle pair-à-pair. Le modèle client-serveur peut être soit centralisé soit distribué alors que le modèle pair-à-pair développe un paradigme ou chaque pair peut être à la fois client et serveur. Les choix issus de ces modèles répondent à des besoins particuliers. Il n existe pas en effet de client standard d une grille, ni d application standard pour la grille. Un client peut être un utilisateur qui désire simplement consulter un site quelconque ou un scientifique qui a besoin de pouvoir effectuer des simulations à très large échelle. L offre d un serveur peut être un fichier de données de même qu une application parallèle. L offre et la demande étant variées, les solutions proposées varient aussi et cherchent à répondre au mieux aux besoins des clients potentiels de ces infrastructures. Les grilles de calcul Lorsque nous parlons de grille de calcul, il est relativement commun de classer les nombreux projets en différentes approches. A l heure actuelle, cette démarche nous

18 2 Introduction semble hasardeuse car même si les projets de grille commencent à atteindre une certaine maturité, les besoins des clients (les industriels, les universitaires) sont encore relativement méconnus. Les projets présentent malgré tout des orientations : ce projet est une boite à outils pour construire des applications parallèles hautement distribuées, celui-ci implante une offre d ordonnancement, celui-là offre un support pour le calcul à la demande, etc. Nous orientons plutôt notre présentation des grilles sur la différence entre le concept d organisation virtuelle et le calcul global. Le calcul global permet l utilisation de ressources publiques : les moyens matériels et logiciels des particuliers. La notion de confiance est ici importante puisque l utilisation de ressources publiques signifie un accord du propriétaire du matériel sans qu il ait la garantie que son ordinateur ne soit pas dégradé. Cela implique également le risque pour le consommateur que les données nécessaires aux calculs soient corrompues. La plupart des outils développés dans les grilles de calcul sont utilisés dans des domaines administratifs aux contours bien définis même s ils peuvent être éloignés géographiquement et utiliser des ressources matérielles et logicielles fortement hétérogènes. Ce sont les organisations virtuelles. L offre multiple, le peu de liens entre les différents projets ont longtemps été un frein à la popularité des grilles. Néanmois, depuis quelques années, des efforts de standardisation œuvrant à la définition de normes communes contribuent à fédérer les différents projets. Un de ces organismes est le Global Grid Forum. Notons que, dans cette thèse, nous ne parlerons pas des projets commerciaux liés à la grille qui commencent à se développer fortement. Dans le cadre de nos travaux nous nous focalisons sur une des approches de la grille de calcul : celle qui consiste à offrir à un client non spécialiste, un ensemble de services de calcul à travers des mécanismes d appels de procèdures à distance (Remote Procedure Call ou RPC). Ces platesformes répondent au paradigme GridRPC défini au sein du Global Grid Forum. On parle alors de plates-formes GridRPC ou encore ASP (Application Service Provider) ou PSE (Problem Solving Environment) ou enfin SCE (Scientific Computing Environment). Les données et la grille La gestion des données dans les grilles de calcul est apparue relativement tardivement par rapport au calcul sur la grille. Cependant, avec l augmentation quasi exponentielle des données produites par des super-calculateurs ou issues d appareils de mesures, il est devenu nécessaire de répondre aux demandes d accès à ces données. Ainsi, la gestion des données dans les grilles est réellement née avec l apparition des besoins issus de la communauté scientifique, à travers des projets développés, par exemple la gestion de nombreuses données de grande taille au CERN (Centre d Etudes sur la Recherche Nucléaire). La question initiale était : comment partager des données de très grande taille produites par des supercalculateurs ou des appareils de mesures, entre des scientifiques très éloignés géographiquement mais appartenant au même domaine administratif. Ainsi, les premières grilles de données sont apparues, et les premières architectures de grilles de données ont été développées. La communauté s intéressant aux données produites et le nombre de ces données étant en croissance exponentielle, il a fallu également réfléchir à l extensibilité de ces environnements mais aussi à la manière de rendre transparente l utilisation d environnements de plus en plus nombreux et hétérogènes. Dans le modèle ASP, la problématique de gestion des données est relativement différente. Ici, la donnée est initialement fournie par le client. Elle est donc connue, localisée et utilisée directement

19 Introduction 3 par le service de calcul puis le résultat est retourné au client. Cette utilisation de la donnée peut en revanche devenir très fastidieuse et coûteuse dès lors que la donnée est de grande taille et qu elle doit être émise plusieurs fois vers le système. De plus, lorsque le client soumet une suite de calcul, il doit gérer l ensemble des phases du calcul puisqu à chaque étape il doit réceptionner les résultats du calcul et retransmettre les données nécessaires au calcul suivant. Lorsqu il s agit de données intermédiaires qui à priori ne l intéressent pas, il est obligé, malgré tout, de les gérer. L idée d offrir un service de gestion des données repose donc sur l importance de limiter au maximum les échanges entre le client et la plate-forme. Notre thèse est centrée sur l étude et la conception d un service qui permette de limiter les transferts de données entre le client et la plate-forme de calcul. Plan du document Ce document débute par une présentation générale des grilles de calcul puis des différentes approches de gestion des données dans les grilles de calcul. Nous nous attachons à décrire le concept de Data Grid ou grille de données qui est la vue la plus communément employée pour gérer les données. Nous détaillons les différents niveaux de gestion définis et présentons certaines solutions développées. Nous montrons que les problématiques abordées diffèrent sensiblement de celles inhérentes aux environnements de résolution de problémes, cadre de notre étude, et nous exprimons la problématique liée à la gestion des données dans ces environnements dans le chapitre 2. Ainsi, nous soulignons l importance du client et la simplicité qui doit régir toute politique de gestion des données assurant la limitation du nombre de transferts de données entre ce client et la plate-forme de calcul. Des exemples accompagnent ces explications et mettent en lumière les différentes contraintes liées à la définition d un service de gestion des données. Le chapitre 3 présente la solution que nous avons implantée dans la plate-forme DIET (Distributed interactive Engineering Toolbox). Nous discutons les choix de conception effectués ainsi que les limites actuelles de ce service. La fin du chapitre est consacrée à la présentation de la proposition d API de gestion des données que nous avons conçue pour le groupe de travail GridRPC du Global Grid Forum. Parmi les limites du service de gestion des données que nous avons implanté, la présence d instances uniques de données empêche d optimiser l exécution de tâches indépendantes et partageant des données communes. Dans ce cadre, nous avons développé un service de réplication que nous présentons dans le chapitre 4. Ce service permet, entre autre, le pré-placement de réplicats en s appuyant sur un outil d estimation des performances réseau. L ensemble de ce service est utilisé par un ordonnanceur dans le cadre du projet GriPPS. Nous présentons les détails d implantation de ce service et de son utilisation. Les résultats expérimentaux présentés dans le chapitre 6 démontrent la faisabilité et les gains apportés par la gestion des données en terme de nombre de transferts et de temps de calcul. Nous concluons finalement par la présentation des travaux en cours tendant à améliorer le service et des perspectives de recherche visant à le développer.

20 4 Introduction

21 CHAPITRE1 La grille et les données 1.1 Contexte Le concept de grille informatique rassemble un grand ensemble de domaines de recherche, plus ou moins indépendants. La notion de grille peut être ainsi déclinée de différentes manières selon les besoins. Généralement, nous distinguons trois axes principaux : les grilles d informations, les grilles de données et les grilles de calcul. Les grilles d informations ont été parmi les approches pionnières de la grille [47]. Elles permettent d accéder à une information à partir d un moteur de recherche en utilisant un protocole de communication tel que http. Le consortium W3C [33] a développé des standards et des protocoles pour les échanges d informations tels que extensible Markup Language (XML) [48] ou les Web Services [100] qui décrivent les moyens permettant la communication entre des applications exécutées sur différentes plates-formes. Les grilles de données permettent le partage et l accès à des données. Elles proposent le partage de ressources de stockage sur des ordinateurs individuels et volontaires. Ici, chaque client, encore appelé servant, peut accèder à des données stockées chez d autres clients. Chaque client étant aussi serveur de données. Généralement, nous parlons de systèmes pair-à-pair. Des projets comme Gnutella, Napster ou KaZaA sont autant d exemples offrant de telles fonctionnalités. Le concept des grilles de calcul est né du besoin grandissant en puissance de calcul qui augmente plus vite que la taille fournie par les architectures parallèles. L idée est donc d une part de faire évoluer les architectures parallèles, comme en témoigne l évolution du top 500 1, ou en agrégeant les moyens de calcul existant pour augmenter le potentiel des ressources disponibles. Le problème est alors de gérer l utilisation de ces puissances de calcul comme la sécurité, l authentification, la programmation, etc... Cette gestion, soustraite des limites de localisation des organisations les gérant, doit permettre d utiliser un ensemble de ressources globalement sousexploitées par n importe quel utilisateur depuis n importe quel endroit. Plusieurs définitions des grilles de calcul existent mais la plus connue et celle qui est généralement admise dans la communauté émane de Ian Foster [56] Une grille de calcul est une infrastructure matérielle et logicielle qui fournit des accès sûrs, cohérents, omniprésents et de faible coût à des ressources de calcul de haute-performance. L analogie avec la grille électrique est une des visions les plus communément employée pour 1

22 6 Chapitre 1. La grille et les données définir les grilles de calcul. Cependant, une grille de calcul rassemble un ensemble de composants qui la rend beaucoup plus complexe. Deux conceptions principales d utilisation de ces composants sont alors nées : l une (public resource computing ou global computing) basée sur des relations d échanges entre les différents participants et les projets développés ; l autre (grid computing) basée sur des organisations propriétaires de ressources autrement appelées les Organisations Virtuelles (VO). D une vision de la grille comme un ensemble de ressources unifiées, la communauté est passée à une vision plus large d Organisations Virtuelles (VO) [56]. Les VO sont des collections dynamiques de personnes, institutions et ressources pour lesquelles la grille fournit une infrastructure afin de résoudre leurs problèmes. Une grille de calcul peut dès lors se caractériser par les prérequis suivants [52] : coordonner des ressources qui ne sont pas soumises à un contrôle centralisé. Les ressources de la grille sont possédées et administrées par des institutions ou des entreprises différentes mais la grille doit en gérer l accès à travers des solutions de sécurité, d authentification... ; l utilisation de protocoles et d interfaces standards et ouverts. Les protocoles et interfaces doivent être standardisés et acceptés par tous, extensibles, portables et interopérables ; la garantie d une certaine qualité de service. La grille doit assurer un niveau requis de disponibilité des ressources, de sécurité et de performance afin que la combinaison des systèmes fournisse un service largement meilleur que leur simple agrégation ne le ferait. De nombreuses classifications des environnements de grilles de calcul existent. Nous nous intéressons ici aux deux concepts suivants : le calcul global basé sur le partage de ressources publiques et le calcul sur grille centré sur les organisations virtuelles. Après une présentation de ces deux concepts, nous nous focalisons sur la gestion des données dans les grilles de calcul. Nous présentons en particulier les grilles de données et les approches de gestion des données dans les environnements implantant le paradigme GridRPC sur lequel repose les travaux présentés dans la suite du document. 1.2 Le calcul global Dans le cas où de larges ensembles de données expérimentales à traiter sont indépendants, les calculs peuvent être découpés en tâches indépendantes de petites tailles, effectuant en général un traitement identique sur des sous-ensembles de données. Les calculs peuvent dans ce cas être effectués en parallèle sans que des communications ne soient nécessaires entre les différents nœuds de la grille. Dans le même temps, de nombreuses stations de travail dans le monde ne sont pas employées en permanence. L idée de l approche calcul global (desktop computing ou calcul hautdébit) est d exploiter les cycles processeurs inutilisés de ces stations pour augmenter le débit d une série de calculs indépendants. Le projet seti@home [107] utilise cette approche dans un cadre spécialisé. Nous présentons également XtremWeb [60] qui propose un support à la mise en œuvre d applications de calcul global.

23 1.2 Le calcul global SETI Le projet seti a pour objectif la détection d éventuels messages radio d origine extraterrestre. Les données, acquises par un radiotélescope, correspondent à un enregistrement continu de la bande passante dont la fréquence est de 2 MHz. Il est possible de diviser cet enregistrement en parcelles de petites tailles. Cette opération de division est effectuée par un serveur qui produit des échantillons dont le temps d exécution est de 50 secondes ce qui correspond à une taille de donnée de 250 Ko. Ces échantillons peuvent être distribués via Internet aux personnes désireuses de donner leurs cycles disponibles au projet. Pour ce faire, ces personnes n ont qu à télécharger un économiseur d écran nommé seti@home [107] qui, en plus de son rôle premier, effectue le traitement des tâches et transmet un rapport au serveur. Ce dernier vérifie les résultats par la suite. Cette opération est répétée tant que la machine reste inemployée et permet un traitement bien plus précis qui celui qui était possible auparavant. Le succès scientifique de ce projet est directement lié à son succès publicitaire qui a permis une large diffusion de l économiseur d écran seti@home. Aujourd hui la plate-forme Boinc (Berkeley Open Infrastructure for NetWork Computing) [14, 3] est considérée comme le successeur de seti@home. Boinc introduit de nouvelles fonctionnalités telles que la possibilité d utiliser la grille afin de résoudre plusieurs problèmes ou la mise en place de points de contrôles. Cette approche du calcul haut débit pose cependant certains problèmes : l approximation consistant à considérer une machine inemployée dès que son économiseur d écran tourne peut se révéler fausse dans de nombreux cas (les tâches de fond par exemple) ; les cycles perdus lorsque le propriétaire de la machine l utilise sans monopoliser son plein potentiel ne peuvent être volés de cette manière ; la fiabilité des résultats. Des résultats erronés ont été reportés après que des utilisateurs de l économiseur d écran aient optimisé certaines des routines de calcul sur lesquelles il repose. En dépit de ces limitations, le projet seti@home est la première réussite de déploiement à l échelle mondiale d un système de calcul haut débit. Le succès de seti@home a permis l émergence de projets basés sur le même concept tels que Folding@home [50] qui exécute des simulations d analyse de protéines dans le but de comprendre des maladies telles qu Alzheimer, climateprediction.net [30] qui explore le domaine des prédictions climatiques en rejouant des milliers de fois des simulations dont les paramètres changent faiblement Condor Le projet Condor [73, 112] fournit un environnement générique pour la mise en place d un mécanisme de calcul haut-débit sur un parc de machines. Si l agrégation de parcs Condors au niveau mondial a été étudiée et a donné des résultats encourageants [45], Condor est de par sa nature plutôt destiné à une utilisation au niveau local. Comme la plupart de systèmes de batch, Condor prévoit un mécanisme de file d attente, un schéma de priorité, une politique de régulation des tâches et une classification des ressources. Condor envoie les calculs à effectuer sur la (ou les) machine(s) dédiée(s), mais à la différence des systèmes traditionnels, Condor peut aussi se servir des machines dont l utilisation n a pas été spécifiée mais dont l activité (au moment du lancement du calcul) est nulle. Condor peut servir de base à la mise en place de nombreuses applications de calcul haut débit.

24 8 Chapitre 1. La grille et les données Un environnement du type de Condor se rapproche des plates-formes de calcul pair-à-pair (peer to peer) dans lesquelles chaque machine peut assumer indifféremment un rôle de client ou de serveur. Ces plates-formes se caractérisent en général par leur nature fortement distribuée et leur forte orientation vers les performances à grande échelle. Condor-G [59] est un outil qui permet de combiner l utilisation de protocoles autorisant des communications sécurisées entre des domaines ainsi que l accès standardisé à des systèmes de batch distants offerts par Globus XtremWeb XtremWeb [60, 49, 20] est un effort français pour la mise en place de services génériques pour le calcul haut-débit. Il est développé au LRI, Paris XI, et utilise MPICH-V [15] qui fournit un environnement de programmation MPI tolérant aux fautes. XtremWeb est un environnement générique permettant la construction simplifiée d applications de calcul haut-débit. L ensemble des machines volontaires est accessible comme un unique parc de nœuds de calcul. Les communications entre ces nœuds n étant pas prises en charge, le système est ici aussi limité aux calculs pouvant être décomposés en plusieurs tâches indépendantes de petite taille. XtremWeb s appuie sur un ensemble de composants distribués. Le système assure aussi la sécurité, en particulier lors du chargement d un code sur une nouvelle machine, les points de contrôle et le passage des pare-feu. Pour offrir cette dernière fonctionnalité, XtremWeb utilise une connexion systématique du client au serveur pour tout type de message. 1.3 Les machines parallèles virtuelles Un des aspects de la croissance des besoins de calcul est l augmentation du nombre et de la taille des problèmes. Dans le domaine de la simulation, les résultats d une expérience en appellent souvent une autre de taille supérieure. Aujourd hui, les données expérimentales d un traitement peuvent atteindre plusieurs péta-octets [105]. L algorithmique parallèle permet de repousser les limites imposées par la puissance des processeurs. Cependant, qu il s agisse d une machine parallèle fortement couplée ou d une grappe de PC, il est toujours possible de trouver une simulation qui atteigne les limites de cette architecture Pour remédier à ce problème, l approche des machines parallèles virtuelles propose de créer une machine parallèle de plus grande taille, soit à partir d un parc hétérogène de stations de travail, soit, plus couramment, par l agrégation des nœuds de plusieurs machines parallèles. Les ressources sont ainsi virtualisées de telle sorte qu un programme écrit pour une machine parallèle classique puisse être soumis sans modification sur cette machine virtuelle. L utilisateur doit posséder des connaissances en programmation parallèle et écrire un programme haute performance qui sera soumis au système. Ce programme, s il existe déjà, doit autant que possible pouvoir être exécuté sur la machine parallèle virtuelle sans modification du code. Outre la difficulté de mise en œuvre de ces mécanismes, l approche machine parallèle virtuelle est également confrontée à des problèmes d environnement d exécution. Un programme parallèle est en effet généralement écrit pour fonctionner sur une plate-forme homogène dont les performances

25 1.3 Les machines parallèles virtuelles 9 sont aisément prédictibles et régulières. Portée sur une plate-forme plus complexe (comme par exemple une agrégation de grappes de PC inter-connectées par Internet), une application parallèle voit ses performances devenir plus irrégulières et dégradées. L application doit être repensée et reprogrammée pour cette architecture. Dans la suite, nous présentons deux systèmes de calcul sur grille orientés principalement vers cette approche et énumérons les services qu ils implémentent à différents niveaux Legion Legion est un système développé à l Université de Virginie qui vise à agréger un ensemble de ressources distribuées et hétérogènes en une unique machine virtuelle [85]. Cette agrégation a deux finalités. La première est la création de machines virtuelles de grande taille afin d augmenter la taille des problèmes traités. C est cette fonctionnalité qui nous intéresse particulièrement. La seconde vise à offrir un cadre adapté au travail coopératif entre utilisateurs distants. Legion introduit la notion de méta-système. Le méta-système est l ensemble des ressources qui doivent être agrégées. De même qu un système d exploitation est une abstraction de la machine destinée à faciliter l interaction avec l utilisateur, Legion est une abstraction du méta-système. Cette abstraction est basée sur un paradigme orienté objet. Chaque composant de Legion, qu il s agisse d une partie du système ou d une application utilisateur, est un objet. Legion propose des mécanismes à trois niveaux de transparence (Legion MPI, Native MPI et Mixed MPI). Il inclut donc des bibliothèques de communication (bas niveau) ainsi que divers outils d aide au développement ou au déploiement des applications (niveaux haut et intermédiaire). Le projet Legion a donné naissance à un produit commercial : AVAKI [64] qui est basé sur les concepts développés par Legion Globus Globus est un projet développé conjointement par l Université de Chicago et l Information Sciences Institute à l USC. Il est destiné à fournir un ensemble de services pour la construction de grilles de calcul [54]. A l opposé de Legion, qui se présente comme un système monolithique, Globus est un ensemble d outils pour le calcul sur grille. Si son usage principal est la construction et l exploitation de machines parallèles virtuelles, son champ d application est plus large du fait de la modularité du système. D autres fonctionnalités d un système Globus peuvent être l accès transparent à des ressources distantes, la connexion directe d outils de mesure aux applications de traitement ou le calcul collaboratif. La nouvelle version GT4 [53] étend ces concepts en fournissant des outils et des bibliothèques pour le développement d applications client-serveur compatibles avec les conventions WSRF (Web Service Resource Framework) et les Web Services, à savoir : une interface spécifiant la façon dont un service peut être accédé ; une implémentation fournissant les services spécifiés par cette interface. L architecture en couches de Globus est illustré figure 1.1 : En partant du bas de la figure, les core services représentent l infrastructure de base permettant la construction d autres services de grilles. Les Security Services utilisent les contrôles

26 10 Chapitre 1. La grille et les données Other Grid Services Data Services RLS DAI RFT GRAM Base Services Trigger Service MDS Index service GRIS GIIS GridFTP Security Services GSI CORE Fig. 1.1 L architecture du Globus Toolkit 4 d accès GSI (Grid Security Infrastructure) pour des utilisateurs ou des groupes d utilisateurs (un mécanisme de cryptographie à clé publique est utilisé). La couche base services contient les services de gestion des tâches : elle fournit GRAM (Globus Resource Allocation Manager) pour contrôler et superviser les tâches, un service d index pour fournir des informations sur les ressources disponibles comme LSF, Load Sharing Facility, ou encore PBS, Portable Batch Systems, et GridFTP le service de transfert de fichiers. Le système de découverte et de surveillance MDS, Monitoring and Discovery System, est le composant des services d information. Il fournit des informations concernant les ressources disponibles de la grille ainsi que leur état. MDS est construit au dessus d un annuaire LDAP, Lightweight Directory Access Protocol. Il est constitué de manière hiérarchique et est composé de deux éléments : le Grid Index Information Service (GIIS) qui fournit un répertoire agrégeant les données de bas niveau (type de systèmes d exploitation, version, espace disque libre, RAM, etc...) et le Grid Resource Information Service (GRIS) qui rassemble toutes les informations des différents serveurs GRIS qu il supervise. MDS inclut deux nouveaux services basés sur WSRF : un service d index (Index Service) qui collecte des données à partir de différentes sources et fournit une interface de requète/souscription à ces données ainsi que le Trigger Service qui également collecte des données à partir de différentes sources et peut être configuré afin de prendre des décisions basées sur ces données. Les Data services permettent la localisation des données en utilisant RLS, Replica Location Service, le service de localisation de données et offre le découpage d ensembles de données en sousensembles, pour l exécution d une tâche par exemple. Les Other Grid Services permettent des manipulations de tâches de haut-niveau et des interfaces entre les couches de Grid Services et l application de l utilisateur. Globus est le projet standard permettant la construction de grilles de calcul. Il est à l origine des efforts de standardisation effectués dans le cadre du Global Grid Forum (voir le paragraph 1.5). Les approches que nous venons d étudier sont un moyen original et économique d agréger des ressources afin de construire de très grosses machines parallèles. Il apparaît cependant que de tels

27 1.4 Le calcul à la demande 11 systèmes sont relativement compliqués à utiliser pour des scientifiques qui ne sont pas forcément des spécialistes en programmation parallèle. Une autre solution existe dans ce cas, il s agit de permettre à des scientifiques d utiliser des ressources matérielles et logicielles disponibles et développées par des spécialistes à travers une interface relativement simple. 1.4 Le calcul à la demande Les problèmes complexes peuvent être calculés à travers l Internet grâce au calcul à la demande. Généralement, ces problèmes sont de type numérique et supposent l utilisation de bibliothèques spécifiques telles que BLAS, LAPACK, ScaLAPACK, PETSc. Ces bibliothèques permettent la programmation d applications hautes performances sur des machines parallèles ou sur des groupes de stations de travail. Malheureusement, l intégration de telles bibliothèques dans des applications de haut niveau développées en C ou Fortran est complexe. De plus, la puissance de calcul et les besoins mémoire de ces applications ne sont évidemment pas disponibles sur les stations de travail. L idée est donc de fournir un accès distant, simple et transparent à ces bibliothèques via des environnements de résolution de problèmes ou PSE (Problem Solving Environments) tels que Scilab, Matlab. L approche présentée ici ne correspond pas à une bibliothèque supplémentaire de programmation parallèle intégrant l accès distant via l internet mais consiste en une mise à disposition d un ensemble de ressources matérielles et logicielles accessibles à distance, en général par l intermédiaire du réseau internet. L utilisation des PSE est de ce fait la manière la plus accessible de profiter de la puissance d une grille de calcul. Aucune connaissance en programmation parallèle n est requise et des interfaces intuitives peuvent aisément être mises en place. Cependant, il est toujours possible d imaginer d autres accès à ces ressources, par exemple, en utilisant un programme écrit en langage C, Fortran ou une page Web comme nous le verrons dans la suite de ce document Le paradigme GridRPC L utilisation de serveurs de calcul disponibles dans des domaines administratifs différents en utilisant le paradigme classique des appels de procédures à distances (ou RPC pour Remote Procedure Call) a donné naissance au gridrpc. L appel RPC peut être réalisé depuis une simple station de travail et rend possible l exploitation de ressources distantes depuis cette machine. Les resoources distantes qui implantent ce paradigme sont généralement appelés Network Enabled Servers (NES) [77, 78]. Le déclenchement à distance d une suite de calculs à partir d une interface formelle est une des caractéristiques de ces environnements. Dans [77], les auteurs présentent un état de l art des environnements basés sur des NES qui permettent d accéder à des serveurs de calcul via le réseau. De tels environnements s articulent autour de cinq types de composants différents : les clients qui soumettent les problèmes aux serveurs, les serveurs qui résolvent les problèmes soumis par les clients, des moniteurs qui récupèrent des informations sur l état (logiciel et matériel) des ressources de calcul, une base de données qui