GEDEON, un Intergiciel pour Grille de Données

Transcription

1 RenPar 17 / SympA 2006 / CFSE 5 / JC 2006 Canet en Roussillon, 4 au 6 octobre 2006 GEDEON, un Intergiciel pour Grille de Données Olivier Vanlentin, Fabrice Jouanot, Laurent d Orazio, Yves Denneulin, Claudia Roncancio, Cyril Labbe, Christophe Blanchet +, Pierre Sens ++ et Claude Bonnard +++ Laboratoire ID-IMAG (Grenoble, France), Laboratoire LSR-IMAG (Grenoble, France), + IBCP (lyon, France), ++ Laboratoire Regal-Inria (Paris, France), +++ ISREC (Lausanne, Suisse) Résumé Les grilles de calcul sont souvent utilisées dans le cadre du calcul intensif avec des applications existantes qui nécessitent de pouvoir accéder leurs données de différentes manières : fichiers ou requêtes plus évoluées. Leurs besoins sont variés mais incluent souvent la sélection de données sur des critères relatifs aux métadonnées associées, ces métadonnées étant de type système, nom d un fichier par exemple, ou applicatives. Par ailleurs, l utilisation des grilles permet un passage à l échelle en terme de stockage et d accès ainsi que la coopération entre des sites. Elle n est cependant viable que si les performances sont au rendez-vous. Dans cet article, nous proposons une infrastructure pour la gestion de données scientifiques sur une grille, Gedeon. Elle se compose d une bibliothèque d entrée/sortie bas niveau, d un fédérateur d accès distant et de différentes interfaces d accès. Aux différents niveaux de manipulation de données se trouvent des caches divers, de données et de requêtes, qui garantissent l efficacité. Les domaines applicatifs visés sont la bio-informatique et l imagerie microscopique. Mots-clés : Intergiciel, Fichiers, Grilles, Interrogation, métadonnées, Cache 1. Introduction Depuis 1995 les projets de séquençage de génomes complets ont dépassé le millier et les séquences complètes publiées sont de l ordre de plusieurs centaines. Des analyses de différents types (structural, biochimique, biophysique, etc.) sont réalisées quotidiennement par la communauté de recherche en Biologie et Bioinformatique. Ces résultats sont maintenus dans des banques de données de grandes tailles, le plus souvent annotées, et distribuées géographiquement. Cette évolution a induit un facteur d échelle important tant du point de vue des données que des analyses à conduire. L imagerie médicale,gros producteur et consommateur de données distribuées et massives, n est pas en reste. L évolution de la technologie et de la recherche dans ces domaines se concentre sur les difficultés liées au stockage, à la gestion, à l interrogation et à l exploitation de ces masses de données. Le biologiste désire accéder le plus facilement et le plus efficacement possible à ces données pour leur appliquer des traitements ou réaliser des croisements. La distribution des données et des traitements sur une grille est une réponse favorable à ce problème. Le besoin d un intergiciel pour exploiter efficacement et simplement ces masses de données scientifiques est la motivation première du projet Gedeon. L objectif de ce projet est construction d un système de gestion de données hybride pour permettre un accès intelligent et efficace à des données de grandes tailles, massivement distribuées et/ou dupliquées. Par intelligence, nous entendons une exploitation à grain très fin des méta- données et annotations stockées avec les données. Par efficacité, nous voulons atteindre des performances d accès aux données comparables à celle obtenues avec des outils systèmes d accès à des fichiers, et en prenant en considération les nombreuses pertes de performances non controlables et induies par une forte distribution ( serveur saturé, réseaux encombrés). Par système hybride, nous fusionnons des fonctionnalités des SGFs (données à gros grain : le fichier, et peu de métadonnées) et des SGBDs (données à grain fin : les n-uplets, aspect sémantique des métadonnées). Ces systèmes de gestion de données traditionnels sont Ce projet est financé par l ACI Masse de Données 2004.

2 contraignants et ils restent souvent inadaptés à la gestion de grandes masses de données (interrogation, duplication, cohérence). Les SGBD, bien qu offrant différents niveaux d abstraction, ainsi que des langages de définition et de manipulation de données, imposent une structuration forte des données et une architecture souvent monolithique. Avec Gedeon, nous cherchons aussi à minimiser l effort de déploiement de l infrastructure qu il s agisse d une grille "grande échelle" ou "légère" (construite sur quelques serveurs et sources de données). L architecture de l intergiciel a été pensée dès le départ comme un ensemble de modules coopérants. Les différents modules du noyau de base de Gedeon prennent en charge la lecture des données, l indexation et le tri en exploitant les méta- données, la transparence d accès aux données distantes et à leur distribution, l interfaçage avec les utilisateurs finaux et les applications (Ad-hoc ou Gedeon) et, enfin, la gestion d une infrastructure de cache transversale pour maximiser les performances. Cet article présente ces différents composants dans les sections qui suivent après une comparaison avec d autres travaux ( section 2) et un résumé de l infrastructure Gedeon (section 3): la librairie d accès aux données (section 4 et 5), les interfaces proposées (section 6) et le Cache Dual (section 7). La section 8 présente quelques résultats d expérimentation du premier prototype de l intergiciel basé sur un contexte applicatif d accès à des banques de séquences de protéines pour les biologistes 2. La section 9 conclut cet article en exposant le travail qui reste à fournir et les pistes intéressantes. 2. État de l art Gedeon n est pas le seul intergiciel qui s intéresse à la manipulation de données scientifiques distribuées sur une grille de données. De nombreuses solutions sont apparues et nous nous proposons de situer Gedeon par rapport à quelques unes des plus connues et à quelques projets prometteurs. Il est impossible de ne pas présenter l alliance Globus [3], communauté qui fédèrant l utilisation et le développement de logiciels autour de ce qui est devenu un standard quant aux solutions pour le calcul distribué et la fédération de ressources. Le coeur de Globus est sa boîte à outil (Globus Toolkit [12]) qui s apparente à un intergiciel configurable et adaptable en fonction de l application et des données cibles. Cet intergiciel regroupe un ensemble de librairies, de programmes et de services, développés au sein de la communauté, qui adresse la majorité des problèmes liés à la distribution à grande échelle. Les services se décomposent en quatre catégories qui vont de la gestion des moteurs d exécution (Java, Python, C), de la découverte et la surveillance des services et ressources, à la gestion des données en passant par la gestion de l environnement d exécution et de la sécurité. Globus est une architecture orientée service; les services de base proposés dans chaque catégorie peuvent être étendues par de nouveaux services nécessaires à une application ou une source de données particulière. Gedeon possède aussi cet aspect modulaire permettant d étendre un noyau de base, mais avec une granularité de l information au niveau enregistrement. Gedeon vise les grilles légères qui réclame une facilité de déploiement, une transparence d accès aux données stockées dans des fichiers, et une performance optimale. L architecture complexe de Globus, difficile à déployer et à configurer, devient alors une solution souvent trop lourde pour ce type de grilles. glite [2] se définit comme un intergiciel de nouvelle génération proposant le meilleur de la technologie et des services pour construire une application de type grille de calcul et données. glite est issu d un projet européen EGEE [1]. Les services mis à disposition pour exploiter la distribution se composent d un gestionnaire de Job, de données, de services de sécurité et de déploiement. L architecture ressemble beaucoup à celle proposée par Globus, les services sont plus nombreux et se veulent plus avancés. Cependant l intergiciel est toujours en développement et la première révision n intègre pas tous les services. L architecture semble encore assez lourde à mettre en place et paraît peu adaptée à des grilles de données légères. Au niveau gestion des données, glite considère uniquement une granularité de niveau fichier. La prise en compte des métadonnées, partie intégrante de Gedeon pour l interrogation et l exploitation des données, se limite à un catalogue de métadonnées permettant la recherche de fichiers et l utilisation d un système de fichier virtuel dans glite. Il est intéressant de noter que cette notion de système de fichier virtuel est un point commun à beaucoup d approches, mais la granularité de niveau fichier en limite souvent l utilisabilité. 2 en collaboration avec l Institut de Biologie et Chimie des Protéines (IBCP). 2

3 SRB [5] est un intergiciel largement utilisé dans différentes communautés scientifiques. L objectif est d offrir un accès transparent et uniforme aux données distribuées sur une grille. SRB fournit une panoplie très complète d interface pour manipuler les données, de la ligne de commande permettant la navigation dans un système de fichier virtuel à l interface Web Ad-hoc en passant par de multiples API. Le service le plus important est le catalogue de métadonnées (MCAT) qui permet d interroger de manière transparente la collection d informations mise à disposition. Ces informations peuvent être aussi bien des fichiers que des données provenant de bases de données. La granularité des métadonnées est le fichier et ne permet pas d atteindre indépendamment les informations au sein d un fichier. SRB autorise des architectures complexes en fédérant des zones, c est-à-dire des méta-catalogues. Gedeon cible les mêmes objectifs mais s attache à extraire les informations des fichiers, indexées par les méta- données. Gedeon intègre une utilisation des caches plus avancée que SRB pour maximiser les performances. Plus généralement, SRB est une solution bien adaptée à l indexation d images alors que Gedeon exploite de manière intrinsèque les fichiers au contenu complexe, et qui sont nombreux dans certains domaines (banques de génomes, de protéines, etc.). Mobius [4] propose une architecture proche de SRB. Le modèle GME (Global Model Exchange) représente les métadonnées et les données disponibles sous la forme de schémas d échange XML. L interrogation et la recherche de ressources et de services utilisent un langage de type XPath. Cette solution semble encore peu avancée, mais présente la particularité de se baser sur un modèle de type XML pour exploiter les données et les services distribuées sur une grille. Le chercheur est chargé de produire un schéma XML représentant les données qu il désire partager et suivre une démarche assez lourde pour rendre opérationnelle l architecture. Ce type de choix trouve difficilement sa place sur la paillasse des chercheurs, Gedeon vise un déploiement bien plus souple. Les points forts de Gedeon, qui ressortent et qui nous ont motivé dans cette voie, sont d abord une architecture légère mais modulable, ensuite un modèle simple pour représenter et stocker les métadonnées, enfin une granularité de manipulation des données au niveau enregistrement et une préoccupation de performance à tous les niveaux. L objectif est de fournir les services minimums et une infrastructure support souple pour répondre aux besoins immédiat des grilles légères. 3. Infrastructure Gedeon L entité au coeur de Gedeon est l enregistrement construit sur un modèle (attribut, valeur), chaque couple de ce type formant une méta-donnée. Ses enregistrements sont stockés dans des fichiers qui peuvent être distribués sur plusieurs sites. Le résultat de chaque opération est un fichier, ou un ensemble de fichiers, qui peuvent être manipulés par les autres composants de Gedeon, par d autres outils systèmes classiques (grep, cat, perl, sed,...), ou encore par des programmes Ad-hoc. Le noyau Gedeon se décompose en quatre couches logicielles spécialisées dans la manipulation de ces enregistrements, et qui peuvent évoluer en fonction de besoins spécifiques : couche fuple en charge des entrées/sorties sur fichiers de données et métadonnées, couche lowerg en charge de la distribution des données et de la gestion du plan d exécution d une requête, couche caching dont les caches sont en charge de l optimisation des communications et enfin une couche interface qui définit les mécaniques de communication avec le client (application ou utilisateur). La figure 1 illustre le déploiement d une infrastructure Gedeon type sur une grille légère. Un client possédant son propre serveur de données désire exploiter des données disponibles sur des serveurs distants en plus de ses propres données. La majorité des accès optimisés au sein de Gedeon se font en lecture, mais l écriture reste possible (ajouts ou modifications d annotations sur des données). Chaque serveur de données doit intégré le noyau de base de l intergiciel, c est- à-dire au minimum les couches fuple et lowerg. Ces couches exploitant les méta- données, une étape préalable de réécriture de celles-ci dans le modèle propre à Gedeon est nécessaire. Toutes les métadonnées associées à une donnée constitue un enregistrement qui possèdera, en plus des annotations déjà citées, un identifiant permettant de localiser la donnée elle-même. Un enregistrement ne contient donc que la description d une donnée, la gestion de celle-ci étant laissé à la charge de l utilisateur. Les enregistrements sont placés dans un ou plusieurs fichiers, répartis sur un ou plusieurs serveurs. Ce choix est suffisamment expressif et souple pour permettre une gestion plus fine et efficace des données tout en autorisant des requêtes avancées. Gedeon n impose aucun critère quant à la répartition des données mais peut bénéficier de stratégies 3

4 Cluster local stockage disque serveur local lowerg fuple réseau cache/proxy App. cache serveur distant lowerg fuple réseau Application sys. fichiers lowerg fuple réseau lowerg fuple réseau WAN serveur distant lowerg fuple Machine client réseau local réseau FIG. 1 Infrastructure Gedeon sur grille légère particulières de placement (architecture Peer-to-Peer [15]). La couche fuple modèlise les métadonnées et évalue localement les requêtes, elle joue le rôle de bibliothèque d entrée/sortie (section 4). De manière à minimiser les accès disque, la bibliothèque fuple assure un accès direct aux données en intègrant des capacités d indexation. Gedeon permet également d agréger des sources de données provenant de différents fichiers. Cette agrégation peut répondre à plusieurs problématiques : accès distant, répartition de charge, ou agrégation "sémantique" de sources. Ces fédérations de sources de données sont rendues possibles par la couche lowerg présentée dans la section 5. Dans notre exemple trois serveurs sont définis : un local et deux distants. Enfin pour limiter au maximum les coûts d entrée/sortie, les coûts de communication et les coûts liés à l évaluation de requêtes, l utilisation de caches est proposée. Un cache, appelé Cache Dual, est composé, d une part, d un cache de données classique et, d autre part, d un cache sémantique. La coopération de ces deux composants offre un niveau de performance maximale. Le cache de données permet d économiser les coûts de lecture disque et les communications alors que le cache sémantique permet d économiser les coûts liés à l évaluation de requêtes. Les caches s appuient sur la couche lowerg et sont détaillés dans la section 7. Les interfaces permettant à des applications ou à des utilisateurs d accéder à Gedeon sont de plusieurs natures. Les applications déjà existantes qui manipulent des fichiers sont toujours utilisables et peuvent bénéficier de certaines fonctionnalités de Gedeon (agrégation de source, caching généralisé, etc.). Ceci est possible grâce à la vue système de fichiers virtuels proposée par Gedeon. Cependant de nouvelles applications peuvent être développées via une API en utilisant pleinement les fonctionnalités des couches fuple et lowerg de Gedeon. Ces interfaces sont présentées dans la section 6. Dans notre exemple un cluster local se compose du serveur de données, du serveur de cache et d une machine client. On retrouve sur chaque serveur les couches principales fuple et lowerg, le cache reste optionnel. A noter sur la machine client la présence d une couche système de fichier virtuel servant d interface entre un utilisateur ou une application et l intergiciel sans modification coté client. Le client décrit sa requête par une navigation au sein des annotations (associées à des répertoires virtuels), cette requête est prise en charge par lowerg qui la décompose en expressions destinées à la machine locale (s il possède ses propres annotations et données), au serveur local et au serveur de cache. Le serveur de cache décomposera l expression reçue en expressions interrogeant le contenu du cache et en expressions destinées aux serveurs distants (si les données sont absentes du cache). Les résultats seront agrégés par la couche lowerg de chaque serveur contribuant à la résolution du plan d exécution sur la grille. Le client obtiendra généralement comme résultat une liste d identifiants de données. Ces identifiants pourront alors être utilisés pour récupérer les données. Des expériences dans le domaine de la bio-informatique ont été effectuées pour valider la solution. Les résultats de ces expériences sont basées sur un premier prototype disposant des fonctionnalités essentielles de l infrastructure ( couches Fuple, LowerG, Caching et interface d accès de type système de fichier virtuel), une évaluation est présentée section 8. 4

5 4. La bibliothèque d entrée/sortie fuple est une bibliothèque permettant d accéder et de gérer un ensemble d enregistrements stockés dans un fichier. Elle est utilisée comme base pour la manipulation des enregistrements au cœur de Gedeon et peut, dans ce contexte, être considérée comme sa bibliothèque d entrée/sortie. Cependant, fuple possède 3 couches d abstraction qui fournissent des fonctionnalités de niveau croissant, allant de l entrée/sortie structurée à l évaluation d une expression de sélection. fuple a été conçue et créée avec comme objectifs : la simplicité, la robustesse, mais aussi la performance ; nous nous attacherons à montrer que les compromis que ces objectifs entraînent inéluctablement ont joué un rôle permanent tout au long du travail de spécification de fuple. Dans la suite de cette section, nous détaillons les différentes couches logicielles proposées par fuple Entrée/sortie structurées La première, et la plus élémentaire, des fonctionnalités fournies par fuple consiste en un ensemble de méthodes permettant de créer et de parcourir des fichiers. Les fichiers en question contiennent une série d enregistrements qui contiennent à leur tour un ensemble d attributs. Un attribut est constitué d un couple (nom, valeur). Les attributs sont variables en taille et en nombre; en outre, il n y a pas de contrainte sur la présence de tel ou tel attribut dans un enregistrement. Ainsi, l interface fuple i/o ne fournit que le minimum nécessaire à la structuration d un fichier en enregistrements. Cette dernière caractéristique implique que la taille d un enregistrement est variable et qu il n est, par conséquent, pas possible d utiliser des espaces de taille fixe pour les stocker dans les fichiers. Nous avons pris le parti de concaténer simplement les enregistrements dans le fichier. La même remarque s applique aux attributs au sein d un enregistrement. Un avantage certain de cette technique réside dans le fait que nous sommes en mesure de réaliser l union des enregistrements de deux fichiers de façon triviale par la concaténation des fichiers eux-mêmes. fuple possède plusieurs méthodes d accès aux données; parmi elles, on notera la lecture sur un descripteur de fichiers en mode flux. Ceci ouvre des perspectives des plus intéressantes en permettant, par exemple, à une application de recevoir des enregistrements de la même façon, qu ils proviennent d un fichier local ou d une socket réseau. Lorsque c est possible, la bibliothèque utilise les techniques de memory mapping pour accélérer l accès aux enregistrements Fonctionnalités de sélection L une des fonctions de Gedeon est de fournir une interface de recherche au sein des métadonnées contenues dans le système. Le langage de recherche fourni est du second ordre : les expressions peuvent porter sur les noms des attributs eux-mêmes ainsi que sur les valeurs associées. Cela facilite l interrogation lorsque la connaissance des attributs n est pas complète. A l échelle de fuple, le problème se ramène à effectuer la recherche au niveau d un fichier. Nous avons élaboré un langage de requête permettant une grande souplesse, notamment en ce qui concerne les recherches par expressions régulières. La bibliothèque permet de compiler 3 une expression de sélection à partir d une chaîne de caractères ou bien de la construire directement au travers de l interface; il est alors possible, pour l utilisateur de l API, de laisser le système optimiser la requête, ou d expliciter complètement la structure qu il souhaite obtenir. Une expression ainsi compilée peut ensuite être évaluée sur un(des) enregistrement(s), mais, surtout, être sérialisée afin d être transmise à un autre site. 5. Fédérateur d accès distant lowerg est un dispositif permettant de construire un serveur de données réparti. Il s appuie sur fuple pour ce qui concerne la manipulation des données. Ce dispositif est constitué de briques élémentaires inter-connectées entre elles. Par le choix de l agencement géographique de ces briques, il est possible d élaborer des plans d exécution adaptés à l environnement de la grille (parallélisation, répartition de charge, disposition de caches, etc... ). Avant de décrire ces composants, il est important d introduire la notion de sources de données. 3 au sens, la transformer en une représentation canonique dont l évaluation sera plus efficace 5

6 5.1. Sources de données Une source de données est un alias qui est utilisé comme paramètre pour les requêtes. Celui-ci permet de déterminer quelles sont les données sur lesquelles la requête doit porter. En effet, chaque élément du système peut offrir l accès (publier) des sources de données sur lesquelles des requêtes pourront être posées. Le résultat d une requête de sélection, par exemple, est l ensemble des enregistrements de la source de données spécifiée qui vérifient l expression de sélection. Dans lowerg, chaque nœud participant au système ne possède qu une vision locale de l architecture globale. Cette représentation locale se retrouve sous la forme d une table de routage où le paramètre de routage est l alias de la source de données. Une règle de routage associe explicitement une source de données à une méthode de traitement et des paramètres utilisés. La règle de routage régit la manière dont les données seront obtenues ou produites. machine2 source méthode paramètres basea local /vers/fichierfuple machine cliente machine1 source base méthode paramètres remote machine1/base1 source base1 base1 1 base1 2 méthode union remote remote paramètres base1 1, base1 2 machine2/basea machine3/baseb source machine3 méthode paramètres baseb local /vers/fichierfuple FIG. 2 Exemple de routage de requête avec lowerg: proxy simple avec union La figure 2 illustre par un exemple un schéma d interconnexion où le nœud machine1 publie la source de données base1 qui est en fait le résultat de l union 4 des bases basea et baseb exportées par les machinesmachine2 etmachine3 qui possèdent chacune en local un fichier fuple associé. Il est à noter que certaines méthodes peuvent faire appel à une autre source de données; ainsi, la méthodeunion de notre exemple compose les résultats de deux sous-requêtes Types de requêtes A l heure actuelle, il existe deux types de requêtes : 1- les requêtes de sélection, qui utilisent une expression de sélection pour déterminer si un enregistrement fait partie du résultat, 2- les requêtes par liste qui sont paramétrées par le nom d un attribut (A) et une liste de valeurs; si un enregistrement a la valeur de son attribut (A) dans la liste, alors il est mis dans le résultat Méthodes de routage Nous donnons ici une définition du fonctionnement des différentes méthodes existantes ou prévues (dans le cas de la lecture) : 1. La méthode local : Cette méthode permet d effectuer la requête sur un fichier. C est toujours par une méthode local que la branche d un réseau de sources se termine; en d autres termes, c est par cette méthode que l on accède concrètement aux données. 2. La méthode remote : Cette méthode fait suivre la requête sur un machine distante en se basant sur le modèle client/serveur. 3. La méthode union : La méthodeunion exécute une ou plusieurs sous-requêtes et réalise l union des résultats (architecturalement: un Y). L intérêt essentiel de cette méthode est de rendre possible la répartition de travail par distribution des données. Nous avons créé des outils permettant de partitionner un fichier fuple afin d en répartir les morceaux sur plusieurs machines. L exécution d une requête se fait en parallèle sur des fichiers plus petits donc plus rapidement. 4 une description plus précise de cette opération se trouve à la section

7 4. La méthode RR (Round Robin) : Cette méthode possède une liste de sources de données qu elle peut utiliser indifféremment (elles contiennent les mêmes données). D une requête à la suivante, elle change cette source. En utilisant cette méthode, la charge est répartie sur les machines qui hébergent les sources de la liste. C est architecturalement un aiguillage. 5. La méthode join : Cette méthode est destinée à fournir la fonctionnalité d enrichissement de Gedeon : un utilisateur doit pouvoir accoler ses données personnelles à des données du système. Pour ce faire, nous stockons ces données supplémentaires dans un fichier à part et nous réalisons une pseudo-jointure afin de publier une nouvelle source de données. La figure 3 montre, sur un exemple comment bases est utilisé pour enrichir basep. AP signifie Attributs Principaux; ils permettent d isoler les portions de l expression de sélection qui concernent basep (l exemple donné n est pas destiné à illustrer cette isolation). ID 0 ID 1 A valeur1 A valeur5 basep B valeur2 B valeur6... C valeur3 D valeur7 D valeur4 bases ID 0 X valeur10 Y valeur11 ID 1 X valeur12 Y valeur13... join clef: ID AP: A, B, C source Pri: basep source Sec: bases select(true) ID 0 A valeur1 B valeur2 C valeur3 D valeur4 X valeur10 Y valeur11 ID 1 A valeur5 B valeur6 D valeur7 X valeur12 Y valeur13... FIG. 3 Illustration de la transformation effectuée par la méthode join 6. La méthode cache : Cette méthode est un talon de communication avec un cache. Lorsqu une requête parviendra à cette source de données, elle sera fournie au cache correspondant. En cas de défaut celui-ci pourra consulter une autre source de données afin de pouvoir fournir son résultat Validation des couches basses Nous avons évalué les performances de lowerg et de fuple dans la configuration suivante : un client et trois serveurs (machines de type PowerPC bi-g5). Une base de séquences de protéines Swissprot a été découpée en trois parties que nous avons placées chacune sur un des trois serveurs. Le client envoie sur les trois serveurs une liste d identifiants et il réalise l union des enregistrements retournés en parallèle, le résultat est écrit sur disque. Trois requêtes différentes donnant 2952 (9.5Mo), (245Mo) et enregistrements (406Mo) sont évaluées respectivement en 0.3s, 7.1s et 12.4s. Nous pouvons constater un débit quasi constant de 34Mo/s qui correspond aux caractéristiques hautes du disque dur client (servant alors de goulot d étranglement). D autres expériences montrent que le débit des serveurs est quasiment proportionnel à leur nombre, et laisse une grande flexibilité de dimensionnement en fonction du nombre de clients. 6. Interfaces avec les applications Cette section présente différentes interfaces clientes proposées dans Gedeon : une interface de programmation bas niveau de type API et une interface haut niveau de type système de fichiers virtuel. Les principales fonctions d entrée/sortie sont concentrées dans une API utilisées par les autres interfaces clients : récupération de données via leurs métadonnées, découverte de métadonnées pertinentes (requête de deuxième ordre), modication des métadonnées. L architecture Gedeon est optimisée pour les accès en mode lecture, les fonctions d interrogation étant les plus importantes dans les applications visées. Une requête est toujours associée à une base Gedeon qui masque l organisation des données et des métadonnées. Cette base est à prendre au sens Gedeon, les fichiers (et donc les données) qui la compose peuvent être distribuées sur les serveurs de la grille. La requête suit le format du module fuple pour imposer des contraintes aux n-uplets résultats extraits des 7

8 fichiers de la base. La fonction Get fournit la réponse à une requête sous la forme d un ensemble de n- uplets attributs/valeurs suivant aussi le modèle fuple. Aucune donnée n est retournée à moins qu elle ne fasse partie intégrante du n-uplet (valeur d un attribut). Dans le cas général, seule l identifiant d une donnée est présente dans un n-uplet (valeur de l attribut ID). Une fonction GetData permet alors de récupérer les données d une base en utilisant cette liste d identifiants. La fonction Delete supprime des métadonnées. Elle accepte une requête pour décrire les métadonnées qui seront supprimées. La fonction Put permet d ajouter des métadonnées aux n-uplets qui valide une requête. Dans beaucoup de domaines, des applications existantes et manipulées par des non spécialistes, rendent impossible l utilisation directe d une telle API. Gedeon propose la navigation au sein des métadonnées via un système de fichier. Un chemin navigationnel se compose d un ensemble de contraintes sur des métadonnées (appelées atomes) qui définissent un répertoire virtuel auquel sont associés les n-uplets et/ou les données correspondantes. Le chemin représente une requête, la sortie placée dans le répertoire virtuel est un fichier au format Gedeon contenant les enregistrements réponses. Cette notion de système de fichiers virtuel est très similaire aux travaux sur les systèmes LISFS et BLID [14]. La différence majeure réside dans l absence de base de données pour indexer les données dans Gedeon et dans la gestion distribuée des données. La flexibilité et la facilité d utilisation de cette approche sont particulièrement bien adaptées dans notre contexte applicatif ( biomédecine, génomique, imagerie médicale) où les applications Ad- hoc sont utilisées au quotidien. L ajout de nouveaux modules de présentation des données en sortie permet de s adapter facilement aux différents formats d entrée des applications utilisées (par exemple BLAST pour l analyse de séquences de protéines). La possibilité d enchaîner des traitements en utilisant un environnement standard basé sur les pipes est important pour l utilisateur final et garantit aussi une compatibilité complète avec les langages de script. Les commandes standards, accessibles dans la majorité des shell, comme em ls, cd, rm, mkdir sont utilisées pour manipuler les données de la base. La sémantique du chemin suit une syntaxe classique, mais enrichie pour la description des contraintes. La commande cd permet la navigation à l aide des métadonnées, ls liste le ou les fichiers réponses à une requête. >cd Gedeon/SwissProt >cd DT_Update= /GN_Name=jon99cii/GN_Synonyms=SER2,SER5 >Gedeon2blast * blast Dans l exemple ci-dessus on se place dans une base Gedeon SwissProt et on traduit la requête sur les métadonnées sous la forme d un chemin. Un fichier temporaire au format Gedeon est accessible via ce répertoire virtuel et transformé dans un format spécifique au programme BLAST qui n aura à subir aucune modification. Dans un second temps, les commandes mkdir et rmdir seront également prises en compte dans l interface shell Gedeon, elles permetteront respectivement de créer une nouvelle méta-donnée et de supprimer une méta-donnée Caches de données et de requêtes L intergiciel que nous proposons vise des systèmes à grande échelle, manipulant des volumes importants de données. Dans ce contexte, nous cherchons à optimiser l évaluation des requêtes supportées par lowerg afin d améliorer le temps d attente perçu par les utilisateurs. Cette section présente la solution de cache que nous proposons. D une manière générale, on distingue les caches de pages, les caches d objets et les caches sémantiques. L unité de transfert (du "serveur" vers le cache) et de gestion est respectivement la page, l objet et la région sémantique. Une telle région correspond à un ensemble de données reliées sémantiquement (par exemple, la réponse à une requête). Contrairement aux pages, la taille et la forme des régions peuvent varier dynamiquement. Les caches sémantiques permettent un raisonnement efficace sur les données en cache. Par exemple, supposons que 1) le cache contient la réponse à une requête portant sur un mot clé A, 2) une nouvelle 8

9 FIG. 4 Cache Dual requête portant sur les mots clés A ET B est posée. La réponse à cette requête est un sous-ensemble de la réponse à la requête A. Un cache sémantique permet de tirer profit de ce constat et évite l accès au serveur. Un autre type de cache aurait généré un défaut de cache. Les caches sémantiques sont particulièrement intéressants lorsque les requêtes ont une forte localité sémantique. Dans ce cas, il y a de fortes chances d avoir une succession de requêtes corrélées dont les réponses se recoupent. Dans un contexte grille, où la quantité de données manipulée est importante, nous cherchons à optimiser aussi bien le transfert des données que le calcul des requêtes. Les trois approches (pages, objets et régions) permettent de réduire les temps de transfert. Cependant, l approche sémantique permet en plus de réduire le temps de calcul. Les réponses aux requêtes évaluées par lowerg peuvent être mises en cache et utilisées pour répondre à la même requête ultérieurement sans calcul, ou à des requêtes non disjointes en minimisant les calculs. Cache Dual : un cache sémantique coopératif Notre proposition, appelée Cache Dual, est basée sur la coopération flexible de deux caches : un cache de requêtes et un cache d objets (voir figure 4). Dans l intergiciel, les requêtes portent sur les meta-données des fichiers/données. Le cache de requêtes est une sorte de cache sémantique, travaillant sur ces requêtes. Pour une requête R1, il garde l ensemble des identifiants des objets de la réponse à R1. Les objets eux-mêmes ne sont pas présents dans le cache de requêtes. En effet, le cache de requêtes est couplé à un cache d objets, qui, lui garde les objets à proprement parler. Les deux caches ne sont pas fortement intégrés, même si c est possible. Leurs stratégies de remplacement et de configuration sont gérées indépendamment. Cacher objets et requêtes séparément donne de la souplesse pour garder un grand nombre de requêtes précalculées tout en contrôlant les besoins en espace mémoire. Les requêtes avec des réponses non disjointes peuvent être mises en cache sans générer une multitude de copies des objets de l intersection. Il n y a pas de duplication d objets dans le cache. L utilisation de l espace alloué au cache est ainsi optimisée. Le nombre de requêtes en cache est plus grand, et donc la probabilité d avoir un hit est augmentée. Plusieurs cas de figure peuvent apparaître pour une requête en cache : 1) l ensemble complet des objets est présent dans le cache d objets; 2) cet ensemble est présent partiellement ou 3) aucun objet de la réponse n est présent dans le cache d objets à cet instant. Ce dernier cas est, bien entendu, le moins favorable. Cependant, la requête en cache évite des calculs. Les caches sémantiques permettent de maximiser l utilisation des ressources. Avec le cache d objets ils permettent d économiser du temps de calcul sur les serveurs ainsi que de la bande passante. Placer un Cache Dual sur site client ou sur un proxy utilisateur permettra ainsi de réduire les temps de réponse. Nous proposons dans [11] une description plus détaillé des principes du Cache Dual ainsi qu une mise en oeuvre à l aide du canevas de services de cache ACS [10]. 9

10 8. Expérimentation : bioinformatique Cette section présente les expériences réalisées avec l intergiciel Gedeon sur des données de bioinformatique. En effet depuis maintenant plusieurs années, les projets de séquençage de génomes complets ont dépassé le millier et les séquences complètes publiées sont de l ordre de plusieurs centaines. Des analyses de différents types (structural, biochimique, biophysique,...) sont réalisées quotidiennement par la communauté de recherche en Biologie et Bioinformatique. Ces différents résultats sont publiés, classés, analysés et référencés dans diverses sources géographiques et logiques sous forme de banques de données brutes ou annotées, c est-à-dire croisées et analysées au regard des données antérieures. Une grande partie des applications employées par les chercheurs en biologie utilise en entrées et en sorties des fichiers plats. Ces fichiers sont composés de séquences d entrées qui sont lues séquentiellement durant leur traitement. Un accès efficace à ces fichiers, associé à l utilisation de cache pour économiser le transfert de données et minimiser le grand nombre d entrées/sorties généré par ces traitements, est un besoin crucial dans ce domaine. L objectif de cette expérimentation est de montrer comment les performances de la couche d entrées/sorties fuple-lowerg et l utilisation d un Cache Dual valide ce besoin. Ce premier prototype de l intergiciel Gedeon met en oeuvre un sous-ensemble des fonctionnalités envisagées. Nous nous sommes concentrés sur deux aspects qualitatifs: 1) autoriser un accès intelligent à une banque de données (SwissProt), 2) assurer un haut niveau de performance dans le cas de requêtes complexes. Le canevas de services de cache ACS, développé en Java, a été utilisé pour la création des caches. ACS utilise la technologie à composants Fractal [7] qui permet la mise en oeuvre de l adaptabilité statique et dynamique des services de cache. L implantation de fuple et lowerg a été réalisée en langage C. Ce prototype est facilement portable et facile à installer. La banque Swiss-prot [6], qui nous sert de support d expérimentation, est une base de données biologiques de séquences de protéines pour différentes espèces. Elle fournit un haut niveau d annotation sur les protéines, tel que la description de la fonction d une protéine, sa structure de domaine, etc. La base Swiss-prot actuelle correspond à un gros fichier ASCII (750Mo) composé de séquences d entrées où apparaissent différents types de ligne. Chaque ligne commence par un code à deux caractères, qui indique le type de données contenues dans la ligne. Par exemple, une ligne contenant la chaîne AC P21215; contient l identification de la séquence, une ligne contenant la chaîne DT 01-AUG-1991 (Rel. 19, Created) informe sur la date de création (et modification) d une séquence, une ligne contenant la chaîne OC Bacteria; Firmicutes; Clostridia; Clostridiales; Clostridiaceae; correspond à la classification de l organisme et une chaîne de la forme SQ MIFDGKVAIITGGGKAKSIGY- GIAVAYAK définit la séquence elle-même. Ce fichier a la particularité de contenir un plus grand volume d informations relatives aux métadonnées que de données. Il est transformé dans un fichier au format Gedeon sous la forme attributs/valeurs. Les requêtes sont composées de conjonctions et de disjonctions de termes, où les termes sont de la forme Nom_d attribut op valeur. Dans le cas particulier de Swiss-prot, op correspond généralement à l opérateur contient, et la valeur à une chaîne de caractères. Par exemple, une requête qui retourne un fichier contenant toutes les entrées avec une ligne OC comprenant la chaîne"bacteria" et"clostridia" est"$oc==/bacteria/ && $OC==/Clostridia/". Il est important de noter qu une requête Gedeon peut toujours être écrite comme une conjonction de sous-requêtes appelées atomes. Il existe deux manières principales de générer une charge de travail pour ce genre de tests. La première est d utiliser des traces réelles comme dans [13]. Cette approche semble donner une bonne approximation d un cas d utilisation réel mais au final une trace n est qu un cas particulier, souvent non représentatif, de la réalité dans sa globalité. De plus, si le but est de comprendre pourquoi une solution est adaptée à un contexte donné, l utilisation de traces ne mettra pas en évidence les mécanismes en jeu. La seconde approche est d utiliser des charges de travail synthétiques comme dans [9]. Le principal inconvénient est l aspect synthétique, mais ce type de charge de travail peut être configuré facilement (si des traces sont disponibles elles peuvent être utilisées pour le choix du modèle et son calibrage). Le choix d un modèle est crucial pour une bonne représentation du contexte cible. Notre but est de montrer le gain de l utilisation d un Cache Dual et de comprendre comment il fonctionne. C est pourquoi nous avons choisi une charge de travail synthétique. Les requêtes synthétiques sont générées en utilisant un ensemble de 90 atomes. Des exemples d atomes sont :"$OC==/Bacteria/"; 10

11 "$DT==/91/". Le système a été évalué avec les approches suivantes. 1. Charge de travail uniforme Une charge de travail uniforme est composée de requêtes de trois atomes choisis aléatoirement parmi 90. Cette charge de travail est la plus intéressante pour les caches sémantiques car elle suppose que les requêtes ne sont pas corrélées les unes aux autres : si un cache sémantique est efficace dans ce contexte, cela assure que le cache est intéressant pour le système. Ce genre de charge de travail a été utilisé dans [9]. 2. Charge de travail sémantique Rx Dans cette charge de travail, les recherches sont des raffinements progressifs : la première requête est générale et les suivantes sont de plus en plus précises et, par conséquent, réduisent le nombre d éléments qualifiés. Une charge de travail appelée Rx, a été proposée dans [13] pour capturer cette propriété. Dans cette charge de travail, x est le taux de requêtes de raffinement. Par exemple, avec R50, la moitié des requêtes seront posées en rajoutant une contrainte aux requêtes précédentes. R0 est équivalent à une charge de travail uniforme. Dans cette expérience un serveur réparti et un Cache Dual ont été lancés sur Grid5000 [8]. L idée générale consiste à découper la base de données en trois fichiers de taille équivalente et de les placer sur trois noeuds appartenant à trois sites différents. Quand une requête est posée, elle est transférée à chaque noeud. Les résultats des évaluations sont ensuite regroupés pour former la même réponse que celle otenue avec un serveur centralisé utilisant une seule base de données. Les résultats sont issus d une expérience avec un client à Sophia Antipolis et le serveur réparti sur Bordeaux, Grenoble et Sophia Antipolis. Un noeud à Grenoble correspond à un bi-xeon 2.4Ghz avec 2Go de mémoire et un disque IDE UDMA, à Sophia Antipolis à un bi-opteron 2.2Ghz avec 4Go de mémoire et un disque SATA, enfin à Bordeaux à un bi-opteron 2.2Ghz avec 2Go de mémoire et un disque IDE UDMA. L espace alloué aux caches est de 20Mo. FIG. 5 Temps de réponse comparé au ratio de requêtes subsumées. FIG. 6 Ratio des succès (exacts and étendues) comparé au ratio de requêtes subsumées. La figure 5 montre que l utilisation du Cache Dual améliore le temps de réponse. Cette figure présente le taux de hit exact et le taux de hit étendu en fonction du taux de requêtes raffinées. Un hit exact a lieu quand la requête exacte est présente en cache. Un hit étendu a lieu quand le résultat d une requête est inclu dans une région présente en cache. Dans ce cas là, le résultat est calculé en cache. Le Cache Dual permet de garder un grand nombre de requêtes, et peut également mettre en cache une requête même si les objets correspondants ne peuvent être ajoutés en cache. Il faut noter que le serveur, reposant sur le couple fuple-lowerg, utilise une méthode d indexation qui optimise la résolution de défaut d objet (comparée à la résolution de défaut de requêtes). De plus le Cache Dual utilise la plus petite région contenant la réponse afin de minimiser les calculs. Comme attendu, plus les raffinements de requêtes sont fréquents, plus le Cache Dual est efficace. En effet, le taux de hit étendu augmente quand le pourcentage de raffinement de requêtes augmente. 11

12 9. Conclusion Gedeon est un intergiciel de gestion de données sur grille caractérisé par trois propriétés qui ont guidé notre travail : une manipulation intelligente des données en exploitant les annotations (ou métadonnées) disponibles, un souci de performances optimales à tous les niveaux constituant un goulot d étranglement potentiel dans l échange et le traitement des informations, un déploiement aisé de la solution bien adaptée aux environnements de tailles moyennes ou ne pouvant fournir un effort important d adaptation. Gedeon permet d exploiter les métadonnées à un grain très fin en comparaison de nombreuses solutions qui considèrent le fichier comme unité d annotation. Ici la notion d enregistrements permet d accéder de manière intelligente au contenu de fichiers complexes. Nous considérons comme exemple applicatif le problème de la bioinformatique et des banques de séquences (génome) qui ont servi de support d expérimentations à notre intergiciel. Nous envisageons d appliquer également cette solution à des collections d images médicales issues de microscopie cellulaire. L architecture en composants de Gedeon repose sur trois couches essentielles : les librairies d accès bas niveau fuple et lowerg, l architecture de cache sémantique et les interfaces de haut niveau dont la navigation dans les annotations via un système de fichier virtuel. Nous nous sommes appliqués à montrer les résultats obtenus avec notre premier prototype sur des données réelles. Beaucoup de travail reste à produire pour obtenir un intergiciel complet, mais des bases solides ont été posées. Nous nous attachons actuellement à déployer l intergiciel Gedeon sur des environnements de plus grande échelle (Grid5000). Bibliographie 1. Egee enabling grids for e-science glite lightweight middleware for grid computing The globus alliance The mobius project Srb the sdsc storage ressource broker The swiss-prot protein knowledgebase Eric Bruneton, Thierry Coupaye, Matthieu Leclerq, Vivien Quéma, and Jean-Bernard Stefani. An Open Component model and its support in Java. In Proc. of the Int l Symp. in Componentbased Software Engineering, Scotland, Franck Cappello. Grid 5000: A large scale, reconfigurable, controlable and monitorable grid platform. In Proceedings of the 6th IEEE/ACM International Workshop on Grid Computing, Boris Chidlovskii and Uwe M. Borghoff. Signature file methods for semantic query caching. In European Conference on Digital Libraries, pages , Laurent d Orazio, Fabrice Jouanot, Cyril Labbé, and Claudia Roncancio. Building adaptable cache services. In 3rd International Workshop on Middleware for Grid Computing, Grenoble, France, november Laurent d Orazio, Olivier Valentin, Yves Denneulin, Fabrice Jouanot, Cyril Labbé, and Claudia Roncancio. Services de cache et intergiciel pour grilles de données. In 22èmes Journées Bases de Données Avancées, Ian Foster. Globus toolkit version 4: Software for service-oriented systems. In IFIP International Conference on Network and Parallel Computing, pages 2 13, Qiong Luo, Jeffrey F. Naughton, Rajasekar Krishnamurthy, Pei Cao, and Yunrui Li. Active query caching for database web servers. In Selected papers from the Third International Workshop WebDB 2000 on The World Wide Web and Databases, pages , London, UK, Springer-Verlag. 14. Y. Padioleau, B. Sigonneau, O. Ridoux, and S. Ferré. Lisfs: a logical information system as a file system. In Véronique Benzaken, editor, Bases de données avancées, pages Université de Rennes 1, oct Maria Del Pilar Villamil, Claudia Roncancio, and Cyril Labbe. Pins: Peer to peer interrogation and indexing system. In IEEE International Symposium IDEAS,