BlobSeerFS : un système de fichiers pour le calcul hautes performances sous Hadoop MapReduce

Transcription

1 BlobSeerFS : un système de fichiers pour le calcul hautes performances sous Hadoop MapReduce Rapport de Stage Matthieu DORIER matthieu.dorier@eleves.bretagne.ens-cachan.fr Sous la direction de : Luc Bougé, Bogdan Nicolae {Luc.Bouge,Bogdan.Nicolae}@irisa.fr ENS de Cachan antenne de Bretagne, IFSIC, IRISA, Equipe KerData Juillet 2009 Résumé Alors que les grilles de calcul sont en plein essor, la gestion des données et en particulier les systèmes de fichiers distribués optimisés pour les calculs haute performance constituent un point clé pour profiter de la puissance de ces architectures. Des outils tels que MapReduce (Google) ou son implémentation libre Hadoop (Apache) demandent, en plus d algorithmes performants, un accès rapide et concurrent à de grandes quantités de données. Nous proposons dans ce document un système de fichiers distribué pour Hadoop, utilisant BlobSeer, un service de gestion de données à grande échelle, comme base de stockage. Nous comparons notre solution à HDFS, le système de fichier de Hadoop, et nous testons notre implémentation sur le Grid Mots-clés : Grille, Gestion de données, Système de fichiers distribué, MapReduce, Hadoop, BlobSeer.

2 Remerciements Je tiens à remercier tout particulièrement les personnes suivantes, pour leur accueil et pour l expérience enrichissante qu elles m ont fait vivre au sein de l équipe KerData : Luc Bougé et Gabriel Antoniu, pour leur encadrement et leurs précieux conseils. Bogdan Nicolae, pour son aide et pour m avoir permis de participer à un réel projet de recherches. Diana Moise, Alexandra Carpen-Amarie, Jing Cai, Viet Trung Tran et Benjamin Girault pour les échanges instructifs, pour leur aide et leurs conseils. 1

3 Table des matières 1 Introduction 3 2 Gestion de données à grande échelle : BlobSeer et Hadoop Cadre de travail : gestion de données sur grilles Systèmes de fichiers distribué Grilles de calcul BlobSeer Objectifs de BlobSeer Architecture générale Interface avec le client Hadoop MapReduce Le paradigme MapReduce Hadoop : une implémentation libre de MapReduce Gestion des données sur HDFS BlobSeerFS (BSFS) : un système de fichiers pour Hadoop Architecture de BlobSeerFS Objectifs Composants de BSFS Connexion entre Hadoop et BlobSeer Objet FileSystem de Hadoop Accès aux fichiers via BSFSInputStream et BSFSOutputStream Gestion des métadonnées Stockage des chemins et des informations Protocole client-serveur BSFS Visualisation HTTP Evaluation, améliorations et perspectives de BlobSeerFS Problèmes de cache Implémentation de caches de lecture et d écriture Cohérence avec la sémantique de Hadoop Tests sur Grid Upload/Download de fichiers Application MapReduce réelle : inverted index Interprétation des résultats Perspectives pour BSFS Gestion, vérification et sécurisation des métadonnées Localisation pour l optimisation du calcul Conclusion 14 A Annexe 16 A.1 Architecture de BlobSeer : schéma A.2 Procédé MapReduce

4 1 Introduction Les grilles de calcul sont perçues de plus en plus comme un moyen simple, économique et efficace pour la réalisation de super-calculateurs à grande échelle. Ces architectures, réunissant les ressources hétérogènes d ordinateurs personnels, de serveurs et de clusters, sont étudiées et largement employées tant au sein des instituts de recherche que par des sociétés comme Google qui doivent chaque jour effectuer de lourds calculs sur une masse importante de données. Dans ce contexte, la gestion des données est un point crucial. Tout comme les calculs, les données doivent être distribuées et accessibles de manière hautement concurrente. Les systèmes de fichiers distribués, développés dans le but de satisfaire aux exigences de la programmation sur grilles de calcul, doivent fournir autant que possible une vision cohérente d un système pourtant décentralisé. L accès aux fichiers doit être efficace, de manière à éviter la nécessité d une copie locale des données, et tolérant vis à vis des pannes, pour ne pas pénaliser l avancement du calcul lors de l indisponibilité de certaines ressources. Des paradigmes particuliers de programmation à grande échelle font l objet de nombreuses recherches. Hadoop [2], implémentation libre de MapReduce, a pour vocation de travailler sur de grandes quantités de données suivant un paradigme inspiré des langages de programmation fonctionnels. Les algorithmes se réduisent à l implémentation de deux fonctions map et reduce, executées en parallèle au sein de grilles de calcul. Les fichiers traités ont une taille de l ordre de quelques Go à quelques To, et le système de fichiers a donc autant d importance au sein de ce framework que l optimisation des calculs. Nous nous proposons d utiliser BlobSeer [8, 9], un service de gestion de blobs (Binary Large OBjects) sur grilles, développé par l équipe KerData, comme base d un système de fichiers distribué pour Hadoop. Nous espérons principalement adjoindre à Hadoop les capacités de versionning de BlobSeer pour permettre une reprise des calculs en cas de panne majeure, tout en conservant l efficacité actuelle en terme d accès concurrents. Dans un premier temps nous décrivons le fonctionnement de BlobSeer et de Hadoop MapReduce, en donnant les principales caractéristiques de chacun, les interfaces utilisateurs et en listant les avantages et inconvénients du système de fichiers actuellement utilisé : HDFS. Nous décrivons ensuite l architecture et l implémentation d un système de fichiers distribué, BlobSeerFS, au travers de ses principaux agents. Enfin nous testons le système de fichiers réalisé sur l upload et le download de gros fichiers, ainsi qu une application MapReduce réelle : l Inverted Index. Nous indiquerons les problèmes majeurs rencontrés et les solutions apportées, puis les évolutions futurs de notre système. 3

5 2 Gestion de données à grande échelle : BlobSeer et Hadoop 2.1 Cadre de travail : gestion de données sur grilles Systèmes de fichiers distribué Dans le domaine du calcul distribué sur de grandes quantités de données, des systèmes comme NFS 1, système de fichiers utilisé sur presque tous les réseaux de machines Linux [10], ne sont plus suffisants. Si NFS permet de mettre à disposition des fichiers sans se préoccuper de leur localisation au sein du parc informatique, des problèmes évidents dus à la mise en cache et au stockage apparaissent lors d accès concurrents et d écritures massives. En effet, une expérience simple peut être réalisée sur un parc informatique utilisant NFS, consistant en une écriture et une lecture consécutives du même fichier sur deux machines différentes : si les deux opérations se suivent de trop près le cache d écriture n est pas envoyé sur le fichier et le lecteur obtient une ancienne version du fichier, bien que celui-ci ait été modifié. Les recherches se tournent donc plutôt vers des systèmes de fichiers de type objet (object based filesystems), comme GFarm [13, 11], qui représentent les fichiers sous forme d objet plutôt que sous forme d une suite de blocs de taille fixe. Une sémantique rigoureuse doit alors être définie pour autoriser des lectures, écritures et ajouts concurrents. Certaines caractéristiques sont importantes pour l implémentation d un système de fichiers distribué. Cohérence : la sémantique doit définir les protocoles d accès de manière à ce que les différentes copies d un même fichier soient identiques. L atomicité des opérations est un élément clé de cette sémantique. Utilisation à large échelle : le système doit pouvoir être déployé sur plusieurs centaines voire plusieurs milliers de machines. Tolérance aux fautes : dans un tel contexte si une machine tombe en panne, le système doit pouvoir, dans un certaine mesure, continuer à fonctionner. Absence de goulot d étranglement et l équilibrage : les différentes machines doivent être accédées de manière équilibrée par les utilisateurs des fichiers, au besoin en déplaçant dynamiquement les données pour rééquilibrer cette charge. Une machine ne doit pas devenir un goulot d étranglement pour le service, en étant indispensable ou en étant contactée à chaque requête, par exemple Grilles de calcul Notre travail se place dans le contexte du grid computing. Une grille informatique est un réseau de ressources (ordinateurs personnels, serveurs, clusters, etc.) hétérogènes délocalisées fournissant une infrastructure virtuelle et des services optimisés en terme de partage des ressources (mémoire, puissance de calcul). Grid 5000 [1] est une infrastructure distribuée sur neuf sites 2 en France, et mise à la disposition de la recherche. Les noeuds sont des machines standard, possédant des processeurs multicœurs cadencés à plus de 2 GHz, et une mémoire vive allant de 1Go à 8Go pour chaque noeud. La recherche dans le domaine des grilles de calcul tend à se développer. Les grilles sont en effet des architectures peu coûteuses, qui peuvent être mises en place au sein même d un parc informatique 1 Network FileSystem. 2 Bordeaux, Grenoble, Lille, Lyon, Nancy, Orsay, Rennes, Sophia et Toulouse. 4

6 pré-existant, comme c est le cas chez Google. Lorsque la grille est constituée d ordinateurs de bureau, on parle de desktop grid. 2.2 BlobSeer Objectifs de BlobSeer Un blob (Binary Large OBject) peut être vu comme une chaîne binaire de taille potentiellement grande (quelques Mo à quelques To). BlobSeer [8, 9], outil créé au sein de l équipe KerData, est un service de stockage et de gestion de données distribuées sous la forme de blobs. Il permet un accès rapide aux données et une forte concurrence dans les opérations de lecture, écriture et ajout (read, write, append). De plus, BlobSeer gère le versioning et utilise des politiques de réplication de données pour la tolérence aux fautes. Au sein de BlobSeer, chaque blob est identifié par un id unique. Les blobs sont divisés en pages de taille donnée (quelques Mo). La taille des pages peut être choisie en fonction de l application considérée [6]. Les requêtes de lecture et d écriture sont basées sur des quadruplets de la forme (id,version,offset,size) désignant, une certaine version d un segment commençant à offset et allant jusqu à offset+size-1. Lorsqu une requête correspond à une série de pages complètes consécutives, on dira que cette requête est alignée. Un tel service peut avoir de nombreuses applications : stockage et gestion d images, stockage et accès efficace à des données scientifiques [7] (vues du ciel, images satellites), etc., mais on peut également imaginer une utilisation en tant que système de fichiers adapté aux calculs distribués sur grilles comme nous allons le voir Architecture générale BlobSeer est constitué de quatre types d agents indépendants, généralement lancés sur des machines distinctes. Le schéma donné en annexe résume l architecture de BlobSeer ainsi que les connexions entre les différents agents. Le provider-manager se charge de gérer les connexions et déconnexions de providers et de noeuds dht. Il se charge également d indiquer, lors de la création d une page, quel provider est le plus apte à la stocker (équilibrage de charge). Le version-manager gère la publication des versions. Toute la cohérence du protocole est assurée par cet agent, ainsi que l atomicité des opérations read, write et append. Les providers fournissent l espace de stockage, ils stockent les pages en mémoire vive ou dans des fichiers (si la persistence est activée) sur le système de fichier local. Les sdht forment les noeuds d une DHT 3 qui stocke les paires page providers et ainsi localisent les pages au sein du service. Cette table de hachage distribuée utilise le principe du segment tree pour associer efficacement un couple (offset,size) à un ensemble de providers stockant les pages concernées par ce segment Interface avec le client Afin d interagir avec le service, le client utilise la classe C++ object_handler, initialisée avec le même fichier de configuration qui a servi au lancement des agents BlobSeer. Cette classe contient 3 Distributed Hash Table, ou table de hachage distribuée. Les données y sont gérées par un ensemble d ordinateurs interconnectés, chacun se chargeant du stockage des données correspondant à un sous-ensemble des clés possibles. 5

7 une variable désignant l id courant, et offre un ensemble de fonctions pour accéder au blobs. Les principales fonctions sont listées ci-dessous. bool create(page_size, replica_count = 1) crée un blob de taille de page et de nombre de copies 4 donnés, et change l id du blob courant pour désigner ce nouveau blob. bool get_latest(id = 0) change l id courant en l id spécifié, et récupère les informations sur la dernière version du blob désigné par le nouvel id. Si l id est à 0, cette fonction recharge juste les dernières informations sur le blob courant. bool read(offset, size, *buffer, version) lit dans le blob courant à l offset spécifié. bool append(size, *buffer) écrit à la fin du blob courant le contenu du buffer. bool write(offset, size, *buffer) écrit à l endroit spécifié le contenu du buffer. D autres fonctions sont disponibles pour récupérer la version courante, la taille d un blob ou son id. La gestion des versions telle que définie dans la sémantique de BlobSeer [8] assure une atomicité de toutes les opérations citées ci-dessus. 2.3 Hadoop MapReduce Le paradigme MapReduce MapReduce est un modèle de programmation proposé par Google [4] (qui en a réalisé une implémentation en C++). L objectif est de traiter de manière parallèle de grandes quantités de données suivant un paradigme inspiré des langages de programmation fonctionnels. Le traitement de ces données s effectue en deux étapes. Map : les données, lues dans un fichier en entrée, sont tout d abord converties en une liste de paires clé, valeur, et une fonction map associe à chaque paire une nouvelle liste de paires clé, valeur intermédiaires. Reduce : les paires intermédiaires sont regroupées par clé, une fonction reduce prend alors une liste de paires intermédiaires partageant la même clé, et procède à un calcul sur cet ensemble pour retourner un résultat. L ensemble des résultats (il y en a autant que de clées intermédiaires différentes) est alors écrit dans un fichier de sortie. Le schéma du processus MapReduce tel que présenté par Google est donné en annexe. L exemple le plus populaire est celui du comptage des mots dans un document [4, 2] : Le document est d abord converti en une liste de mots. La fonction map prend cette liste et la transforme en une nouvelle liste de paires mot, 1. La fonction reduce, prend en argument une liste dont les clés sont identiques (même mot), et renvoie la somme des valeurs. Nous verrons plus loin un autre algorithme célèbre par son implémentation MapReduce : l inverted index. Quel que soit le problème, la fonction map peut être facilement parallélisée : chaque machine disponible l applique à un sous-ensemble des données d entrée, indépendamment des traitements appliqués au reste des données. Il n en est pas de même pour la fonction reduce. En effet, selon l algorithme à implémenter, reduce peut ou non commencer son travail sur la base d une liste incomplète de paires intermédiaires. La section donne la solution apportée par Apache à ce problème Hadoop : une implémentation libre de MapReduce Si MapReduce a beaucoup de succès parmi les développeurs de la société Google, son implémentation n est malheureusement pas libre. Hadoop, initié en 2008 par Apache [2], est le framework de type Map/Reduce libre le plus utilisé. Il est implémenté en Java. 4 Les copies de pages sont effectuées sur des providers différents, de manière à éviter la perte de données en cas de panne de certains providers 6

8 FIG. 1 Architecture de HDFS Hadoop utilise un paradigme que l on devrait plutôt nommer Map-Combine-Reduce. En effet, le travail est divisé en trois étapes. Une fonction map prend une partie de l entrée et crée une liste de paires intermédiaires. Une fonction combine est appelée localement à la fin d un processus map pour effectuer un prétraitement des paires intermédiaires, il s agit en fait d un faux reduce, capable de travailler sur la base d une liste incomplète. Une fonction reduce est appelée sur une seule machine, une fois que toutes les machines ont terminé les processus map et combine Gestion des données sur HDFS Hadoop est fourni avec le système de fichier HDFS 5 [12], proche de Google FileSystem [5]. Deux agents principaux composent ce système de fichiers : le NameNode qui gère l arborescence et les métadonnées et les DataNodes qui fournissent l espace de stockage pour des blocs de fichiers. Au sein des DataNodes, les données sont stockées par le système de fichiers de la machine (en général ext2 ou ext3 sur les machines Unix) par blocs de 64 Mo. La figure 1 présente l architecture de HDFS. 3 BlobSeerFS (BSFS) : un système de fichiers pour Hadoop 3.1 Architecture de BlobSeerFS Objectifs Comme nous l avons vu plus haut, les calculs effectués par Hadoop sont basés sur un accès concurrent à de grandes quantités de données. Le système de fichiers tient donc une part très importante dans la rapidité du traitement. Si HDFS possède de bonnes propriétés en ce qui concerne la cohérence 5 Hadoop Distributed FileSystem. 7

9 FIG. 2 Architecture de BSFS et la tolerance aux fautes [2, 12], aucun système de version ou de snapshot n est pour le moment disponible. Si le système de fichiers est corrompu au cours du processus, il n y a aucun moyen de restaurer l état du système à un point antérieur. En utilisant un système de fichiers basé sur BlobSeer, notre objectif est avant tout d ajouter un système de versioning tout en conservant les aspects d accès hautement concurrents. Parallèlemment à cela, nous esperons avoir une efficacité équivalente voire supérieure en terme de calculs, en élaborant un système de fichiers utilisant majoritairement la mémoire vive des machines plutôt que le système de fichier local, et proposant un paramétrage fin du grain (taille des pages) Composants de BSFS De la même manière que dans le cas de HDFS, la gestion des métadonnées se fait par l intérmédiaire d un unique agent, le NameNode. Ce server utilise le protocole TCP pour écouter et répondre aux requêtes provenant de deux ports (l un pour les accès aux informations de fichiers, l autre pour la visualisation en HTML du système). Les fichiers sont stockés par BlobSeer. Un fichier correspond à un blob. La figure 2 présente l architecture générale de BSFS. Deux threads gèrent séparément les requêtes d accès aux informations et les requêtes d affichage HTML. Ces deux threads partagent à l aide d un mutex l accès au système de fichier proprement dit. Le traitement des reqêtes est atomique : lorsque deux clients demandent la création d un fichier portant le même nom, par exemple, l un d eux se voit différer la requête. 8

10 3.2 Connexion entre Hadoop et BlobSeer Hadoop étant programmé en Java, nous avons commencé par réaliser un binding de BlobSeer pour Java. Ce binding donne accès à une classe ObjectHandler suivant le même modèle que la classe object_handler de la librairie C Objet FileSystem de Hadoop Hadoop met à notre disposition une classe abstraite FileSystem. Pour élaborer un nouveau système de fichier, nous avons créé une classe BlobSeerFileSystem héritant de FileSystem et surchargeant les principales fonctions de cette dernière : création de fichiers et de répertoires (create, mkdirs, etc.), vérification d existence (exists, etc.), récupération des métadonnées (getfilestatus, etc.), et récupération des flux d entrée-sortie sur les fichiers (append, etc.). Cet objet BlobSeerFileSystem possède, entre autre, une instance d un objet BSClient chargé de communiquer avec le NameNode. Cette classe est construite très simplement sur le modèle des clients TCP classiques : envoi de la requête, attente d une réponse, fermeture de la liaison. Le protocole utilisé sera décrit dans la section Accès aux fichiers via BSFSInputStream et BSFSOutputStream La concurrence engendrée par Hadoop au niveau du système de fichiers est de type write-onceread-many : le créateur d un fichier est le seul écrivain, il ne fait qu ajouter des données et ne reviendra pas en arrière dans cette tâche (seule une fonction append est donc nécessaire pour contrôler le flux d écriture). Puis le fichier est lu de manière concurrente par un grand nombre de clients. Cette politique est minimaliste, comparée aux capacité de BlobSeer (lecture, écriture et ajouts concurrents). La classe abstraite FileSystem ne nous demande donc qu un nombre restreint de fonctions : une fonction create capable de créer un fichier et de retourner un flux d écriture pour y accéder, une fonction read retournant un flux de lecture sur un fichier et une fonction append retournant un flux d écriture pointant à la fin du fichier (bien que cette dernière semble ne pas être utilisée par Hadoop). 3.3 Gestion des métadonnées La gestion des métadonnées se fait sur un NameNode codé en Ruby. De même que pour la partie connectant Hadoop et BlobSeer nous avions réalisé un binding Java, nous avons réalisé un binding Ruby pour le NameNode. Le langage Ruby a été ici choisi pour sa simplicité, notamment pour tout ce qui concerne les threads, la communication par sockets 6, et la gestion des tableaux, chaînes de caractères et tables de hachage. Ce server pourrait cependant être réécrit en Java pour uniformiser l ensemble du système, en terme de langages utilisés Stockage des chemins et des informations Le serveur ne travaille que sur la base de chemins absolus. Même si une vérification de validité des chemins est faite avant le traitement des requêtes, nous partons du principe que le client a déjà converti les chemins en chemins absolus, ne sachant pas quel est le répertoire courant du client. Le serveur met à disposition une table de hachage qui à tout chemin (exprimé sous la forme d une chaîne de caractères) associe un objet BSFile ou BSDir. Ces deux objets contiennent les informations relatives aux fichiers et aux répertoires : date de modification, id du blob (dans le cas d un fichier), etc. et contiennent également des fonctions membres permettant leur sérialisation dans un format simple 6 Ruby est un langage interprété orienté objet qui est surtout connu pour le framework Ruby on Rails, très utilisé dans l industrie du Web. 9

11 utilisable dans les réponses du serveur au client. Cette table pouvant être accessible par plusieurs threads en même temps, elle est protégée par un mutex Protocole client-serveur BSFS HDFS utilise des RPC pour communiquer avec son NameNode. Nous avons choisi d utiliser un protocole plus simple, basé sur l envoi de chaînes de caractères compréhensibles. De cette manière, le système a pu être testé lors de sa création en utilisant telnet. Une requête correspond donc à une chaîne de caractères terminée par un retour à la ligne (\n). Les neuf requêtes suivantes ont ainsi été définies. EXISTS:path vérifie l existence d un chemin. CREATE:path:replica:psize crée un fichier (un blob) en prenant en compte le nombre de copies et la taille des pages. BLOBID:path demande l id du blob correspondant au fichier donné. ISFILE:path vérifie si un chemin correspond ou non à un fichier. RENAME:old_path:new_path renomme un fichier ou un répertoire. DELETE:path supprime un fichier ou un répertoire. STATUS:path renvoie les informations sur le chemin. MKDIRS:path crée le répertoire demandé, en créant les répertoires parents si nécessaire. LISTDIR:path liste des informations sur les objets contenus dans un répertoire. SETSIZE:path:size indique au serveur la taille réelle du fichier. La plupart des trames de réponses sont de la forme COMMAND:TRUE ou COMMAND:FALSE. Exemple : CREATE:TRUE indique que l opération de création de fichier s est bien passée. CREATE:FALSE indique que le fichier n a pas pu être créé. Aucune précision n est donnée dans ce cas, Hadoop n ayant pas utilité de savoir si un fichier n a pas pu être créé parce qu il existait déjà ou pour une autre raison. Certaines commandes renvoient des informations plus complètes, comme STATUS, qui renvoie une réponse de la forme STATUS:FILE:time:replica:psize ou STATUS:DIR:time. À toute requête ne correspondant pas à un modèle cité ci-dessus, le serveur répond ERROR. À ce stade, il est important de noter le choix que nous avons fait concernant la création d un fichier. En effet, deux possibilités s offrent à nous : la création d un blob peut être laissée à la charge du client ou être réalisée par le serveur. Nous avons choisi de réaliser l opération en même temps que la création des métadonnées du côté du serveur. De cette manière, nous empêchons certains phénomènes d incohérence, comme l absence de métadonnées sur un blob, ou la mauvaise liaison entre un blob et ses informations sur le serveur. Ces incohérences peuvent survenir facilement lors du crash d un des agents au cours du protocole de création. En laissant au serveur le soin de créer le blob, on rend le protocole cohérent. Si BlobSeer ne répond pas, le serveur ne pourra pas créer de blob même s il parvient à créer les métadonnées. Il effacera ces métadonnées et renverra false. Si le serveur de métadonnées ne répond plus, aucun client ne pourra créer de blob qui ne serait alors pas répertorié. La primitive SETSIZE a été ajoutée pour que l écrivain puisse indiquer au server lorsqu il modifie la taille d un fichier. La taille du fichier est très importantes, puisque BlobSeer stocke un nombre entier de pages ; la taille d un fichier n est pas forcément un multiple de la taille des pages, et il faut donc savoir arrêter la lecture au bon moment. 10

12 3.3.3 Visualisation HTTP HDFS propose un service de visualisation du système via un navigateur Web. Nous avons ajouté cette même fonctionnalité au serveur de BlobSeerFS qui peut répondre aux requêtes HTTP pour renvoyer une page HTML contenant une visualisation de l arborescence. Cette fonctionnalité est très pratique pour visualiser en temps réel la structure du système sans passer par les outils FsShell de Hadoop. De plus, nous pourrions envisager la possibilité de créer et d uploader des fichiers, voire de contrôler Hadoop depuis ce service. 4 Evaluation, améliorations et perspectives de BlobSeerFS 4.1 Problèmes de cache Implémentation de caches de lecture et d écriture Dans la plupart des systèmes de fichiers, bien que les fichiers soient stockés dans des blocs d une taille définie, la lecture et l écriture se font toujours par l intermédiaire d un tampon, en général de quelques ko [10]. L implémentation des trois classes précédemment décrites étant réalisée, les premiers tests ont montré de gros problèmes de rapidité dus à de nombreux appels inutiles à BlobSeer. En effet, si on imagine un fichier stocké dans des pages de 64 Mo, une lecture du fichier effectuera une copie successive de morceaux de pages de quelques ko seulement. Le client recontactera donc Blob- Seer et rechargera 64 Mo inutilement pour chaque morceau. (Même si du point de vue de l utilisateur il est possible d envoyer une requête pour charger un segment plus petit qu une page, dans BlobSeer un nombre entier de pages est chargé). Nous avons donc repensé la gestion des flux d entrée-sorties en rendant abstraites les classes BSFSInputStream et BSFSOutputStream, et en créant deux classes filles BSFSCachedInputStream et BSFSCachedOutputStream implémentant un système de cache, de manière à contacter BlobSeer le moins possible. De plus, nous avons rendu paramétrable la taille des pages dans BlobSeer, et nous avons effectué les tests avec une taille de 8 Mo plutôt que 64 Mo. Dans les tests qui suivent, la taille du cache est égale à la taille d une page, bien que cette donnée soit également paramétrable. Un cache de lecture est donc caractérisé par un offset et une version, et reflète l état des pages correspondantes dans le blob Cohérence avec la sémantique de Hadoop Lors d une requête de lecture, un segment à lire est passé en paramètre. Si ce segment intersecte le cache, et que la version du cache est positive (i.e. le contenu du cache correspond bien à ce qui se trouve dans le blob), alors aucune requête n est envoyée à BlobSeer, le contenu du cache est simplement lu. Si la requête de lecture concerne un segment en dehors du cache, ou partiellement en dehors, il suffit de charger dans le cache la page appropriée. C est uniquement dans ce cas que Blob- Seer est contacté. Hadoop ne modifie pas les informations une fois écrite (modèle write-once-readmany, c est à dire un seul écrivain ne faisant qu ajouter des données sans réécrire sur les précédentes, puis plusieurs lecteurs en même temps) Nous n avons donc pas besoin que le cache corresponde à la dernière version connue : une version non nulle suffit. Si la fin du blob est atteinte pour une certaine version, on recharge alors la dernière version pour vérifier si d autre pages n ont pas été ajoutées. Le cache de lecture est donc en permanence cohérent avec le contenu du blob. Lors d une requête d écriture, toutes les données sont également ajoutées dans un cache d écriture. Dès que ce cache est plein, il est envoyé à BlobSeer. Un seul écrivain étant autorisé dans le modèle de Hadoop, il n y a pas de conflit d écriture. L ajout d une fonction flush appelée lors de la fermeture du flux permet de gérer le cas d une taille de fichier non-multiple de la taille des pages, en envoy- 11

13 ant au server la taille réelle du fichier et en complétant éventuellement (au choix de l utilisateur de configurer cela ou non) le cache avec un caractère particulier (nul, en général). 4.2 Tests sur Grid Upload/Download de fichiers Pour tester BSFS, nous avons déployé BlobSeer sur le Grid 5000 [1]. Le système ne permettant pour le moment que la gestion de fichiers dont la taille est un multiple de la taille des pages utilisées, les tests se résument à l upload et au download de gros fichiers depuis et vers un système de fichiers local. Le premier test consiste en l envoi et la récupération d un fichier de 1 Go par un seul client. Pour tester BSFS, BlobSeer est déployé sur sept noeuds : un version-manager, un provider-manager, trois providers et deux sdhts. Un huitième noeud contient le NameNode, et un neuvième joue le rôle du client. En comparaison, la même expérience est réalisée avec HDFS déployé sur cinq noeuds : un NameNode, un SecondaryNameNode, et trois DataNodes. Il y a donc dans les deux cas trois noeuds de stockage. Le tableau ci-dessous montre les résultats (débit de lecture et d écriture) de cette expériences. BSFS HDFS Émission 76.6 MB/s 70.0 MB/s Réception 44.1 MB/s 42.5 MB/s Dans un deuxième temps, nous cherchons à comparer l aspect concurrent des deux systèmes. Dans les deux cas, nous utilisons dix unités de stockage pour cela. Dans le cas de l écriture, trois clients écrivent en même temps un fichier de 1 Go différent. Nous comparons ensuite la lecture concurrente du même fichier. Trois clients téléchargent le même fichier de manière concurrente. Dans les deux cas le débit moyen est mesuré. Le tableau ci-dessous présente les résultats obtenus : BSFS HDFS Émission 72.1 MB/s 76.3 MB/s Réception 49.5 MB/s 50.9 MB/s Application MapReduce réelle : inverted index Nous avons ensuite comparé BSFS à HDFS dans l application inverted index. Cet algorithme est la base des systèmes d indexation sur internet. Considerant un ensemble de documents (les contenus de pages web, par exemple), l application scanne ces documents et renvoie un index, c est à dire une liste associant à chaque mot un ensemble de paires nom du document, position dans le document. C est sur la base de ce genre d index que l on peut réaliser des algorithmes optimisés dans la recherche sur le web, fonctionnant principalement par intersection d ensembles. Les fonctions map et reduce fonctionnent de la manière suivant. Map : cette fonction prend le nom d un document en entrée, en lit le contenu et crée la liste des paires intermédiaires mot, (nom du document, position). Reduce : elle prend en argument la liste des paires mot, (nom du document, position) et ne fait que l écrire dans l index, avec éventuellement un pré-traîtement de tri par nom ou par position. Le déploiement de Hadoop est effectué sur 18 nœuds d un même cluster 7. Sur ces 18 nœuds, nous lançons 18 TaskTrackers de Hadoop, et nous utilisons ces mêmes 18 nœuds pour déployer le système 7 Un cluster est un ensemble de machines de mêmes caractéristiques. 12

14 de fichiers. Dans le cas de HDFS, 17 nœuds sont utilisés pour le stockage, 1 nœud est utilisé comme NameNode. Dans le cas de BSFS, nous utilisons 12 providers, 3 nœuds sdht, un provider manager et un version manager. De plus le NameNode est déployé sur un 18 eme nœud. Contraîrement à la précédente expérience, où nous cherchions à utiliser le même nombre de nœuds gérant les données, nous cherchons ici à déployer l intégralité du système sur un même nombre de nœuds. L algorithme est lancé sur un ensemble de 20 livres numériques au format txt, provenant de la base de données du projet Gutemberg. Ces entrées remprésentent un volume d environ 16 Mo. Les résultats obtenus sont très encourageants, puisque l inverted index s est terminé en 52,2sec avec BSFS, contre 57,5sec avec HDFS Interprétation des résultats Au vu des résultats, notre objectif est atteint. En effet nous arrivons à des débits équivalents en utilisant BSFS et en utilisant HDFS pour le transfert de fichiers. BlobSeer nous apporte le système de versionning manquant à HDFS, ce genre de résultat est prometteur quant à l avenir du travail. Nous noterons que le cache de BSFS étant fixé à la taille des pages, nous ne profitons pas de tous les aspects de parallélisation des requêtes de BlobSeer. Lorsque plusieurs pages sont requises, elles sont envoyées en parallèle par tous les providers concernés. Ici nous ne demandons qu une seule page à la fois. La dernière version de BSFS permet de paramétrer le cache pour avoir une taille différente de celle des pages. De plus, un système de cache intelligent, anticipant les opérations pour charger de nouvelles pages dans un thread avant qu elles ne soient effectivement requises, serait une bonne perspective d amélioration de ce système. De nouveaux tests devront être menés afin de déterminer la taille de cache optimale. Le lecteur prendra garde à ne pas faire de rapprochement entre les deux tableaux : les résultats ayant été obtenus dans des conditions différentes (nombre de DataNodes différent, et ressources différentes sur Grid 5000). Les résultats obtenus sur l algorithme inverted index sont les premiers d une série d expérience qui devrat être réalisée pour situer BlobSeer par rapport aux systèmes existents comme HDFS. Nous envisageons à l avenir d étudier notre système sur tous les plans possibles : taille des pages, taille du cache, nombre de nœuds, etc. 4.3 Perspectives pour BSFS Gestion, vérification et sécurisation des métadonnées Actuellement, la gestion des métadonnées se fait sur le même modèle que pour HDFS, à savoir un serveur gérant les informations sur le système de fichiers. Une sauvegarde au format YAML des métadonnées est faite à chaque modification. (Dans le cas de HDFS il s agit d un serveur à part entière, le SecondaryNameNode, qui télécharge périodiquement toutes les informations et les sauvegarde). Une possible amélioration de la gestion des métadonnées consisterait en une interaction plus forte entre BlobSeer et le NameNode, permettant de vérifier la cohérence des informations (principalement l existence du blob). Un système de somme de contrôle (checksum) permettrait également d améliorer la fiabilité de notre système, d autant plus qu Hadoop prévoit les classes abstraites pour cela. Nous avons pris exemple sur HDFS et GFS dans notre modèle de gestion des informations. Ce modèle possède pourtant l inconvénient de centraliser les informations au sein d un seul nœud qui peut alors devenir un goulet d étranglement. Une solution pour empêcher cela serait de remplacer 13

15 le NameNode par une table de hachage distribuée. BlobSeer utilisant déjà une table de hachage distribuée, il serait possible d utiliser cette même table pour stocker les métadonnées concernant les fichiers. Ce principe est d ailleurs utilisé dans le système de fichiers BlobSeer-Fuse développé par Diana Moise au sein de l équipe KerData Localisation pour l optimisation du calcul Une autre optimisation possible consiste à donner à Hadoop la possibilité de localiser les pages au sein des différentes machines. Dans le modèle HDFS, chaque machine est à la fois un TaskTracker (là où se font les calculs) et un DataNode (là où sont stockées les données). HDFS communique à Hadoop la localisation des blocs de fichiers de manière à ce que les calculs soient lancés le plus proche possible des données utilisées. Ainsi, on minimise le déplacement des données. De la même manière les futures évolutions de BSFS intégreront un système de localisation des pages. Hadoop propose la classe BlockLocation dans ce but et la prochaine version de BlobSeer incluera une primitive de localisation des pages. 5 Conclusion En utilisant BlobSeer comme système de stockage sous-jacent à un système de fichiers distribué pour Hadoop, et en prenant pour modèle l architecture de HDFS en ce qui concerne la gestion des métadonnées, nous avons pu atteindre des performances équivalentes en terme de débits de lecture et d écriture des fichiers, et une amélioration des accès concurrents dans le cadre d une application réelle : l inverted index. Notre système a l avantage de disposer de capacités de versionning, qui devraient s avérer plus efficaces que le simple système de snapshot envisagé dans les futures versions de HDFS. En effet, dans notre perspective, la moindre modification de fichier est sauvegardée de manière efficace. Ces résultats encourageants, obtenus sur la plateforme Grid 5000, ont été réalisés sans pour autant que le système de cache que nous avons constaté si indispensable à l accélération des opérations ne soit optimisé. Les travaux futurs concerneront donc l optimisation des caches de lecture et d écriture. Les tests réalisés posent les premières pierres d une phase de tests systématique qui permettront de situer BlobSeer et BlobSeerFileSystem dans l univers des systèmes de fichiers distribués orientés calculs hautes performances. La mise en place d un système de localisation des données pour le lancement optimisé des calculs est également une amélioration à envisager si nous souhaitons encore gagner du terrain sur HDFS. Terminons en notant à ce titre qu Hadoop détient à l heure actuelle le Terabyte Sort Benchmark[3], qui consiste en un tri massif de données, avec un débit de TB/min. Nous avons vu l importance tenue par les systèmes de fichiers distribuées dans les opérations de traitement de gros fichiers. La question est donc : pourra-t-on à terme avoir un meilleur débit en utilisant BSFS? 14

16 References [1] Aladdin G5k. [2] Hadoop MapReduce. [3] [4] Jeffrey Dean and Sanjay Ghemawat. MapReduce: Simplified data processing on large clusters. UC Berkley and Intel Research, [5] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google Filesystem. 19th ACM Symposium on Operating Systems Principles, Lake George, NY, [6] Bogdan Nicolae, Gabriel Antoniu, and Luc Bougé. Distributed management of massive data: an efficient fine-grain data access scheme. International Workshop on High-Performance Data Management in Grid Environments (HPDGrid), Toulouse : France, [7] Bogdan Nicolae, Gabriel Antoniu, and Luc Bougé. Enabling lock-free concurrent fine-grain access to massive distributed data: application to supernovae detection. IEEE Cluster Poster Session, Tsukuba : Japan, [8] Bogdan Nicolae, Gabriel Antoniu, and Luc Bougé. Blobseer: how to enable efficient versionning for large object storage under heavy access concurrency. 2nd International Workshop on Data Management in Peer-to-peer systems (DaMaP 2009, Saint Petersburg, Russia, March 2009), [9] Bogdan Nicolae, Gabriel Antoniu, and Luc Bougé. Enabling hight data throughput in desktop grids through decentralized data and metadata management: the BlobSeer approach [10] Andrew S. Tanenbaum. Modern Operating Systems. Prentice Hall Press, Upper Saddle River, NJ, USA, [11] Yusuke Tanimura, Yoshio Tanaka, Satoshi Sekiguchi, and Osamu Tatebe. Performance Evaluation of Gfarm Version 1.4 as a Cluster Filesystem. Proceedings of the 3rd International Workshop on Grid Computing and Applications, [12] Wittawat Tantisiriroj, Swapnil Patil, and Garth Gibson. Data-intensive file systems for Internet services: A rose by any other name... Carnegie Mellon University Parallel Data Lab Technical Report CMU-PDL , [13] Osamu Tatebe, Noriyuki Soda, Youhei Morita, Satoshi Matsuoka, and Satoshi Sekiguchi. Gfarm v2: A Grid file system that supports high-performance distributed and parallel data computing. Proceedings of the 2004 Computing in High Energy and Nuclear Physics (CHEP04), Interlaken, Switzerland,

17 A Annexe A.1 Architecture de BlobSeer : schéma FIG. 3 Architecture de BlobSeer 16

18 A.2 Procédé MapReduce Le schéma suivant a été repris de [citer les references ici] FIG. 4 Processus MapReduce de Google 17