BlobSeerFS : un systme 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

Rsum
Alors que les grilles de calcul sont en plein essor, la gestion des donnes et en particulier les systmes de fichiers distribus optimiss 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 implmentation libre Hadoop (Apache) demandent,
en plus dalgorithmes performants, un accs rapide et concurrent de grandes quantits de donnes. Nous proposons dans ce document un systme de fichiers distribu
pour Hadoop, utilisant BlobSeer, un service de gestion de donnes grande chelle,
comme base de stockage. Nous comparons notre solution HDFS, le systme de fichier
de Hadoop, et nous testons notre implmentation sur le Grid5000.
Mots-cls : Grille, Gestion de donnes, Systme de fichiers distribu, MapReduce,
Hadoop, BlobSeer.

Remerciements

Je tiens remercier tout particulirement les personnes suivantes, pour leur accueil et pour
lexprience enrichissante quelles mont fait vivre au sein de lquipe KerData :
Luc Boug et Gabriel Antoniu, pour leur encadrement et leurs prcieux conseils.
Bogdan Nicolae, pour son aide et pour mavoir permis de participer un rel 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.

Table des matires

1

Introduction

Gestion de donnes grande chelle : BlobSeer et Hadoop

2.1 Cadre de travail : gestion de donnes sur grilles . . . . . .
2.1.1 Systmes de fichiers distribu . . . . . . . . . . . . .
2.1.2 Grilles de calcul . . . . . . . . . . . . . . . . . . . . .
2.2 BlobSeer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Objectifs de BlobSeer . . . . . . . . . . . . . . . . . .
2.2.2 Architecture gnrale . . . . . . . . . . . . . . . . .
2.2.3 Interface avec le client . . . . . . . . . . . . . . . . .
2.3 Hadoop MapReduce . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Le paradigme MapReduce . . . . . . . . . . . . . . .
2.3.2 Hadoop : une implmentation libre de MapReduce
2.3.3 Gestion des donnes sur HDFS . . . . . . . . . . . .

3
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

4
4
4
4
5
5
5
5
6
6
6
7

BlobSeerFS (BSFS) : un systme de fichiers pour Hadoop

3.1 Architecture de BlobSeerFS . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Composants de BSFS . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Connexion entre Hadoop et BlobSeer . . . . . . . . . . . . . . . . . . .
3.2.1 Objet FileSystem de Hadoop . . . . . . . . . . . . . . . . . . . .
3.2.2 Accs aux fichiers via BSFSInputStream et BSFSOutputStream
3.3 Gestion des mtadonnes . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Stockage des chemins et des informations . . . . . . . . . . . .
3.3.2 Protocole client-serveur BSFS . . . . . . . . . . . . . . . . . . .
3.3.3 Visualisation HTTP . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

7
7
7
8
9
9
9
9
9
10
11

Evaluation, amliorations et perspectives de BlobSeerFS

4.1 Problmes de cache . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Implmentation de caches de lecture et dcriture . .
4.1.2 Cohrence avec la smantique de Hadoop . . . . . .
4.2 Tests sur Grid5000 . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Upload/Download de fichiers . . . . . . . . . . . . .
4.2.2 Application MapReduce relle : inverted index . . . .
4.2.3 Interprtation des rsultats . . . . . . . . . . . . . . .
4.3 Perspectives pour BSFS . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Gestion, vrification et scurisation des mtadonnes
4.3.2 Localisation pour loptimisation du calcul . . . . . . .

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

11
11
11
11
12
12
12
13
13
13
14

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

Conclusion

14

A Annexe
A.1 Architecture de BlobSeer : schma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Procd MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16
16
17

Introduction

Les grilles de calcul sont perues de plus en plus comme un moyen simple, conomique et efficace pour la ralisation de super-calculateurs grande chelle. Ces architectures, runissant les
ressources htrognes dordinateurs personnels, de serveurs et de clusters, sont tudies et largement
employes tant au sein des instituts de recherche que par des socits comme Google qui doivent
chaque jour effectuer de lourds calculs sur une masse importante de donnes.
Dans ce contexte, la gestion des donnes est un point crucial. Tout comme les calculs, les donnes
doivent tre distribues et accessibles de manire hautement concurrente. Les systmes de fichiers
distribus, dvelopps dans le but de satisfaire aux exigences de la programmation sur grilles de
calcul, doivent fournir autant que possible une vision cohrente dun systme pourtant dcentralis.
Laccs aux fichiers doit tre efficace, de manire viter la ncessit dune copie locale des donnes,
et tolrant vis vis des pannes, pour ne pas pnaliser lavancement du calcul lors de lindisponibilit
de certaines ressources.
Des paradigmes particuliers de programmation grande chelle font lobjet de nombreuses
recherches. Hadoop [2], implmentation libre de MapReduce, a pour vocation de travailler sur de
grandes quantits de donnes suivant un paradigme inspir des langages de programmation fonctionnels. Les algorithmes se rduisent limplmentation de deux fonctions map et reduce, executes
en parallle au sein de grilles de calcul. Les fichiers traits ont une taille de lordre de quelques Go
quelques To, et le systme de fichiers a donc autant dimportance au sein de ce framework que loptimisation des calculs.
Nous nous proposons dutiliser BlobSeer [8, 9], un service de gestion de blobs (Binary Large OBjects)
sur grilles, dvelopp par lquipe KerData, comme base dun systme de fichiers distribu pour
Hadoop. Nous esprons principalement adjoindre Hadoop les capacits de versionning de BlobSeer
pour permettre une reprise des calculs en cas de panne majeure, tout en conservant lefficacit actuelle
en terme daccs concurrents.
Dans un premier temps nous dcrivons le fonctionnement de BlobSeer et de Hadoop MapReduce,
en donnant les principales caractristiques de chacun, les interfaces utilisateurs et en listant les avantages et inconvnients du systme de fichiers actuellement utilis : HDFS. Nous dcrivons ensuite
larchitecture et limplmentation dun systme de fichiers distribu, BlobSeerFS, au travers de ses
principaux agents. Enfin nous testons le systme de fichiers ralis sur lupload et le download de gros
fichiers, ainsi quune application MapReduce relle : lInverted Index. Nous indiquerons les problmes
majeurs rencontrs et les solutions apportes, puis les volutions futurs de notre systme.

Gestion de donnes grande chelle : BlobSeer et Hadoop

2.1
2.1.1

Cadre de travail : gestion de donnes sur grilles

Systmes de fichiers distribu

Dans le domaine du calcul distribu sur de grandes quantits de donnes, des systmes comme
NFS1 , systme de fichiers utilis sur presque tous les rseaux de machines Linux [10], ne sont plus
suffisants. Si NFS permet de mettre disposition des fichiers sans se proccuper de leur localisation
au sein du parc informatique, des problmes vidents dus la mise en cache et au stockage apparaissent lors daccs concurrents et dcritures massives. En effet, une exprience simple peut tre
ralise sur un parc informatique utilisant NFS, consistant en une criture et une lecture conscutives
du mme fichier sur deux machines diffrentes : si les deux oprations se suivent de trop prs le cache
dcriture nest 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 plutt vers des systmes de fichiers de type
objet (object based filesystems), comme GFarm [13, 11], qui reprsentent les fichiers sous forme dobjet
plutt que sous forme dune suite de blocs de taille fixe.
Une smantique rigoureuse doit alors tre dfinie pour autoriser des lectures, critures et ajouts
concurrents. Certaines caractristiques sont importantes pour limplmentation dun systme de
fichiers distribu.
Cohrence : la smantique doit dfinir les protocoles daccs de manire ce que les diffrentes
copies dun mme fichier soient identiques. Latomicit des oprations est un lment cl de
cette smantique.
Utilisation large chelle : le systme doit pouvoir tre dploy sur plusieurs centaines voire
plusieurs milliers de machines.
Tolrance aux fautes : dans un tel contexte si une machine tombe en panne, le systme doit
pouvoir, dans un certaine mesure, continuer fonctionner.
Absence de goulot dtranglement et lquilibrage : les diffrentes machines doivent tre accdes de manire quilibre par les utilisateurs des fichiers, au besoin en dplaant dynamiquement les donnes pour rquilibrer cette charge. Une machine ne doit pas devenir un
goulot dtranglement pour le service, en tant indispensable ou en tant contacte chaque
requte, par exemple.

2.1.2

Grilles de calcul

Notre travail se place dans le contexte du grid computing. Une grille informatique est un rseau
de ressources (ordinateurs personnels, serveurs, clusters, etc.) htrognes dlocalises fournissant
une infrastructure virtuelle et des services optimiss en terme de partage des ressources (mmoire,
puissance de calcul).
Grid5000 [1] est une infrastructure distribue sur neuf sites2 en France, et mise la disposition de la
recherche. Les noeuds sont des machines standard, possdant des processeurs multicurs cadencs
plus de 2 GHz, et une mmoire vive allant de 1Go 8Go pour chaque noeud.
La recherche dans le domaine des grilles de calcul tend se dvelopper. Les grilles sont en effet des
architectures peu coteuses, qui peuvent tre mises en place au sein mme dun parc informatique
1 Network

FileSystem.
Grenoble, Lille, Lyon, Nancy, Orsay, Rennes, Sophia et Toulouse.

2 Bordeaux,

pr-existant, comme cest le cas chez Google. Lorsque la grille est constitue dordinateurs de bureau,
on parle de desktop grid.

2.2
2.2.1

BlobSeer
Objectifs de BlobSeer

Un blob (Binary Large OBject) peut tre vu comme une chane binaire de taille potentiellement
grande (quelques Mo quelques To). BlobSeer [8, 9], outil cr au sein de lquipe KerData, est un
service de stockage et de gestion de donnes distribues sous la forme de blobs. Il permet un accs
rapide aux donnes et une forte concurrence dans les oprations de lecture, criture et ajout (read,
write, append). De plus, BlobSeer gre le versioning et utilise des politiques de rplication de donnes
pour la tolrence aux fautes.
Au sein de BlobSeer, chaque blob est identifi par un id unique. Les blobs sont diviss en pages
de taille donne (quelques Mo). La taille des pages peut tre choisie en fonction de lapplication
considre [6]. Les requtes de lecture et dcriture sont bases sur des quadruplets de la forme
(id,version,offset,size) dsignant, une certaine version dun segment commenant offset et allant
jusqu offset+size-1. Lorsquune requte correspond une srie de pages compltes conscutives,
on dira que cette requte est aligne.
Un tel service peut avoir de nombreuses applications : stockage et gestion dimages, stockage et
accs efficace des donnes scientifiques [7] (vues du ciel, images satellites), etc., mais on peut galement imaginer une utilisation en tant que systme de fichiers adapt aux calculs distribus sur grilles
comme nous allons le voir.

2.2.2

Architecture gnrale

BlobSeer est constitu de quatre types dagents indpendants, gnralement lancs sur des machines distinctes. Le schma donn en annexe rsume larchitecture de BlobSeer ainsi que les connexions entre les diffrents agents.
Le provider-manager se charge de grer les connexions et dconnexions de providers et de noeuds
dht. Il se charge galement dindiquer, lors de la cration dune page, quel provider est le plus
apte la stocker (quilibrage de charge).
Le version-manager gre la publication des versions. Toute la cohrence du protocole est assure
par cet agent, ainsi que latomicit des oprations read, write et append.
Les providers fournissent lespace de stockage, ils stockent les pages en mmoire vive ou dans
des fichiers (si la persistence est active) sur le systme de fichier local.
Les sdht forment les noeuds dune DHT3 qui stocke les paires page providers et ainsi
localisent les pages au sein du service. Cette table de hachage distribue utilise le principe
du segment tree pour associer efficacement un couple (offset,size) un ensemble de providers
stockant les pages concernes par ce segment.

2.2.3

Interface avec le client

Afin dinteragir avec le service, le client utilise la classe C++ object_handler, initialise avec le
mme fichier de configuration qui a servi au lancement des agents BlobSeer. Cette classe contient
3 Distributed

Hash Table, ou table de hachage distribue. Les donnes y sont gres par un ensemble dordinateurs interconnects, chacun se chargeant du stockage des donnes correspondant un sous-ensemble des
cls possibles.

une variable dsignant lid courant, et offre un ensemble de fonctions pour accder au blobs. Les
principales fonctions sont listes ci-dessous.
bool create(page_size, replica_count = 1) cre un blob de taille de page et de nombre
de copies4 donns, et change lid du blob courant pour dsigner ce nouveau blob.
bool get_latest(id = 0) change lid courant en lid spcifi, et rcupre les informations sur
la dernire version du blob dsign par le nouvel id. Si lid est 0, cette fonction recharge juste
les dernires informations sur le blob courant.
bool read(offset, size, *buffer, version) lit dans le blob courant loffset spcifi.
bool append(size, *buffer) crit la fin du blob courant le contenu du buffer.
bool write(offset, size, *buffer) crit lendroit spcifi le contenu du buffer.
Dautres fonctions sont disponibles pour rcuprer la version courante, la taille dun blob ou son id.
La gestion des versions telle que dfinie dans la smantique de BlobSeer [8] assure une atomicit de
toutes les oprations cites ci-dessus.

2.3
2.3.1

Hadoop MapReduce
Le paradigme MapReduce

MapReduce est un modle de programmation propos par Google [4] (qui en a ralis une implmentation en C++). Lobjectif est de traiter de manire parallle de grandes quantits de donnes
suivant un paradigme inspir des langages de programmation fonctionnels. Le traitement de ces
donnes seffectue en deux tapes.
Map : les donnes, lues dans un fichier en entre, sont tout dabord converties en une liste de
paires h cl, valeur i, et une fonction map associe chaque paire une nouvelle liste de paires
h cl, valeur i intermdiaires.
Reduce : les paires intermdiaires sont regroupes par cl, une fonction reduce prend alors une
liste de paires intermdiaires partageant la mme cl, et procde un calcul sur cet ensemble
pour retourner un rsultat. Lensemble des rsultats (il y en a autant que de cles intermdiaires
diffrentes) est alors crit dans un fichier de sortie. Le schma du processus MapReduce tel que
prsent par Google est donn en annexe.
Lexemple le plus populaire est celui du comptage des mots dans un document [4, 2] : Le document
est dabord converti en une liste de mots. La fonction map prend cette liste et la transforme en une
nouvelle liste de paires h mot, 1 i. La fonction reduce, prend en argument une liste dont les cls sont
identiques (mme mot), et renvoie la somme des valeurs. Nous verrons plus loin un autre algorithme
clbre par son implmentation MapReduce : linverted index.
Quel que soit le problme, la fonction map peut tre facilement paralllise : chaque machine
disponible lapplique un sous-ensemble des donnes dentre, indpendamment des traitements
appliqus au reste des donnes. Il nen est pas de mme pour la fonction reduce. En effet, selon lalgorithme implmenter, reduce peut ou non commencer son travail sur la base dune liste incomplte
de paires intermdiaires. La section 2.3.2 donne la solution apporte par Apache ce problme.

2.3.2

Hadoop : une implmentation libre de MapReduce

Si MapReduce a beaucoup de succs parmi les dveloppeurs de la socit Google, son implmentation nest malheureusement pas libre. Hadoop, initi en 2008 par Apache [2], est le framework de
type Map/Reduce libre le plus utilis. Il est implment en Java.
4 Les copies de pages sont effectues sur des providers diffrents, de manire viter la perte de donnes en
cas de panne de certains providers

F IG . 1 Architecture de HDFS
Hadoop utilise un paradigme que lon devrait plutt nommer Map-Combine-Reduce. En effet,
le travail est divis en trois tapes.
Une fonction map prend une partie de lentre et cre une liste de paires intermdiaires.
Une fonction combine est appele localement la fin dun processus map pour effectuer un prtraitement des paires intermdiaires, il sagit en fait dun faux reduce, capable de travailler
sur la base dune liste incomplte.
Une fonction reduce est appele sur une seule machine, une fois que toutes les machines ont
termin les processus map et combine.

2.3.3

Gestion des donnes sur HDFS

Hadoop est fourni avec le systme de fichier HDFS5 [12], proche de Google FileSystem [5]. Deux
agents principaux composent ce systme de fichiers : le NameNode qui gre larborescence et les mtadonnes et les DataNodes qui fournissent lespace de stockage pour des blocs de fichiers. Au sein
des DataNodes, les donnes sont stockes par le systme de fichiers de la machine (en gnral ext2 ou
ext3 sur les machines Unix) par blocs de 64 Mo. La figure 1 prsente larchitecture de HDFS.

BlobSeerFS (BSFS) : un systme de fichiers pour Hadoop

3.1
3.1.1

Architecture de BlobSeerFS
Objectifs

Comme nous lavons vu plus haut, les calculs effectus par Hadoop sont bass sur un accs concurrent de grandes quantits de donnes. Le systme de fichiers tient donc une part trs importante
dans la rapidit du traitement. Si HDFS possde de bonnes proprits en ce qui concerne la cohrence
5 Hadoop

Distributed FileSystem.

F IG . 2 Architecture de BSFS
et la tolerance aux fautes [2, 12], aucun systme de version ou de snapshot nest pour le moment
disponible. Si le systme de fichiers est corrompu au cours du processus, il ny a aucun moyen de
restaurer ltat du systme un point antrieur. En utilisant un systme de fichiers bas sur BlobSeer,
notre objectif est avant tout dajouter un systme de versioning tout en conservant les aspects daccs
hautement concurrents. Paralllemment cela, nous esperons avoir une efficacit quivalente voire
suprieure en terme de calculs, en laborant un systme de fichiers utilisant majoritairement la mmoire vive des machines plutt que le systme de fichier local, et proposant un paramtrage fin du
grain (taille des pages).

3.1.2

Composants de BSFS

De la mme manire que dans le cas de HDFS, la gestion des mtadonnes se fait par lintrmdiaire dun unique agent, le NameNode. Ce server utilise le protocole TCP pour couter et rpondre
aux requtes provenant de deux ports (lun pour les accs aux informations de fichiers, lautre pour
la visualisation en HTML du systme).
Les fichiers sont stocks par BlobSeer. Un fichier correspond un blob. La figure 2 prsente larchitecture gnrale de BSFS. Deux threads grent sparment les requtes daccs aux informations
et les requtes daffichage HTML. Ces deux threads partagent laide dun mutex laccs au systme
de fichier proprement dit. Le traitement des reqtes est atomique : lorsque deux clients demandent la
cration dun fichier portant le mme nom, par exemple, lun deux se voit diffrer la requte.

3.2

Connexion entre Hadoop et BlobSeer

Hadoop tant programm en Java, nous avons commenc par raliser un binding de BlobSeer pour
Java. Ce binding donne accs une classe ObjectHandler suivant le mme modle que la classe
object_handler de la librairie C++.

3.2.1

Objet FileSystem de Hadoop

Hadoop met notre disposition une classe abstraite FileSystem. Pour laborer un nouveau systme de fichier, nous avons cr une classe BlobSeerFileSystem hritant de FileSystem et surchargeant les principales fonctions de cette dernire : cration de fichiers et de rpertoires (create,
mkdirs, etc.), vrification dexistence (exists, etc.), rcupration des mtadonnes (getFileStatus, etc.),
et rcupration des flux dentre-sortie sur les fichiers (append, etc.). Cet objet BlobSeerFileSystem
possde, entre autre, une instance dun objet BSClient charg de communiquer avec le NameNode.
Cette classe est construite trs simplement sur le modle des clients TCP classiques : envoi de la requte, attente dune rponse, fermeture de la liaison. Le protocole utilis sera dcrit dans la section
3.3.2.

3.2.2

Accs aux fichiers via BSFSInputStream et BSFSOutputStream

La concurrence engendre par Hadoop au niveau du systme de fichiers est de type write-onceread-many : le crateur dun fichier est le seul crivain, il ne fait quajouter des donnes et ne reviendra
pas en arrire dans cette tche (seule une fonction append est donc ncessaire pour contrler le flux
dcriture). Puis le fichier est lu de manire concurrente par un grand nombre de clients. Cette politique est minimaliste, compare aux capacit de BlobSeer (lecture, criture et ajouts concurrents). La
classe abstraite FileSystem ne nous demande donc quun nombre restreint de fonctions : une fonction create capable de crer un fichier et de retourner un flux dcriture pour y accder, une fonction
read retournant un flux de lecture sur un fichier et une fonction append retournant un flux dcriture
pointant la fin du fichier (bien que cette dernire semble ne pas tre utilise par Hadoop).

3.3

Gestion des mtadonnes

La gestion des mtadonnes se fait sur un NameNode cod en Ruby. De mme que pour la partie
connectant Hadoop et BlobSeer nous avions ralis un binding Java, nous avons ralis 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 sockets6 , et la gestion des tableaux, chanes de
caractres et tables de hachage. Ce server pourrait cependant tre rcrit en Java pour uniformiser
lensemble du systme, en terme de langages utiliss.

3.3.1

Stockage des chemins et des informations

Le serveur ne travaille que sur la base de chemins absolus. Mme si une vrification de validit
des chemins est faite avant le traitement des requtes, nous partons du principe que le client a dj
converti les chemins en chemins absolus, ne sachant pas quel est le rpertoire courant du client. Le
serveur met disposition une table de hachage qui tout chemin (exprim sous la forme dune
chane de caractres) associe un objet BSFile ou BSDir. Ces deux objets contiennent les informations
relatives aux fichiers et aux rpertoires : date de modification, id du blob (dans le cas dun fichier), etc.
et contiennent galement des fonctions membres permettant leur srialisation dans un format simple
6 Ruby

est un langage interprt orient objet qui est surtout connu pour le framework Ruby on Rails, trs
utilis dans lindustrie du Web.

utilisable dans les rponses du serveur au client. Cette table pouvant tre accessible par plusieurs
threads en mme temps, elle est protge par un mutex.

3.3.2

Protocole client-serveur BSFS

HDFS utilise des RPC pour communiquer avec son NameNode. Nous avons choisi dutiliser un
protocole plus simple, bas sur lenvoi de chanes de caractres comprhensibles. De cette manire,
le systme a pu tre test lors de sa cration en utilisant telnet. Une requte correspond donc une
chane de caractres termine par un retour la ligne (\n).
Les neuf requtes suivantes ont ainsi t dfinies.
EXISTS:path vrifie lexistence dun chemin.
CREATE:path:replica:psize cre un fichier (un blob) en prenant en compte le nombre de
copies et la taille des pages.
BLOBID:path demande lid du blob correspondant au fichier donn.
ISFILE:path vrifie si un chemin correspond ou non un fichier.
RENAME:old_path:new_path renomme un fichier ou un rpertoire.
DELETE:path supprime un fichier ou un rpertoire.
STATUS:path renvoie les informations sur le chemin.
MKDIRS:path cre le rpertoire demand, en crant les rpertoires parents si ncessaire.
LISTDIR:path liste des informations sur les objets contenus dans un rpertoire.
SETSIZE:path:size indique au serveur la taille relle du fichier.
La plupart des trames de rponses sont de la forme COMMAND:TRUE ou COMMAND:FALSE. Exemple :
CREATE:TRUE indique que lopration de cration de fichier sest bien passe. CREATE:FALSE indique
que le fichier na pas pu tre cr. Aucune prcision nest donne dans ce cas, Hadoop nayant pas
utilit de savoir si un fichier na pas pu tre cr parce quil existait dj ou pour une autre raison.
Certaines commandes renvoient des informations plus compltes, comme STATUS, qui renvoie une
rponse de la forme STATUS:FILE:time:replica:psize ou STATUS:DIR:time. toute requte ne
correspondant pas un modle cit ci-dessus, le serveur rpond ERROR.
ce stade, il est important de noter le choix que nous avons fait concernant la cration dun fichier.
En effet, deux possibilits soffrent nous : la cration dun blob peut tre laisse la charge du client
ou tre ralise par le serveur. Nous avons choisi de raliser lopration en mme temps que la cration des mtadonnes du ct du serveur. De cette manire, nous empchons certains phnomnes
dincohrence, comme labsence de mtadonnes sur un blob, ou la mauvaise liaison entre un blob et
ses informations sur le serveur. Ces incohrences peuvent survenir facilement lors du crash dun des
agents au cours du protocole de cration. En laissant au serveur le soin de crer le blob, on rend le protocole cohrent. Si BlobSeer ne rpond pas, le serveur ne pourra pas crer de blob mme sil parvient
crer les mtadonnes. Il effacera ces mtadonnes et renverra false. Si le serveur de mtadonnes
ne rpond plus, aucun client ne pourra crer de blob qui ne serait alors pas rpertori.
La primitive SETSIZE a t ajoute pour que lcrivain puisse indiquer au server lorsquil modifie
la taille dun fichier. La taille du fichier est trs importantes, puisque BlobSeer stocke un nombre
entier de pages ; la taille dun fichier nest pas forcment un multiple de la taille des pages, et il faut
donc savoir arrter la lecture au bon moment.

10

3.3.3

Visualisation HTTP

HDFS propose un service de visualisation du systme via un navigateur Web. Nous avons ajout
cette mme fonctionnalit au serveur de BlobSeerFS qui peut rpondre aux requtes HTTP pour
renvoyer une page HTML contenant une visualisation de larborescence. Cette fonctionnalit est trs
pratique pour visualiser en temps rel la structure du systme sans passer par les outils FsShell de
Hadoop. De plus, nous pourrions envisager la possibilit de crer et duploader des fichiers, voire de
contrler Hadoop depuis ce service.

Evaluation, amliorations et perspectives de BlobSeerFS

4.1
4.1.1

Problmes de cache
Implmentation de caches de lecture et dcriture

Dans la plupart des systmes de fichiers, bien que les fichiers soient stocks dans des blocs dune
taille dfinie, la lecture et lcriture se font toujours par lintermdiaire dun tampon, en gnral de
quelques ko [10]. Limplmentation des trois classes prcdemment dcrites tant ralise, les premiers tests ont montr de gros problmes 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 BlobSeer et rechargera 64 Mo inutilement pour chaque morceau. (Mme si du point de vue de lutilisateur
il est possible denvoyer une requte pour charger un segment plus petit quune page, dans BlobSeer
un nombre entier de pages est charg). Nous avons donc repens la gestion des flux dentre-sorties
en rendant abstraites les classes BSFSInputStream et BSFSOutputStream, et en crant deux classes
filles BSFSCachedInputStream et BSFSCachedOutputStream implmentant un systme de cache, de
manire contacter BlobSeer le moins possible. De plus, nous avons rendu paramtrable la taille des
pages dans BlobSeer, et nous avons effectu les tests avec une taille de 8 Mo plutt que 64 Mo. Dans
les tests qui suivent, la taille du cache est gale la taille dune page, bien que cette donne soit galement paramtrable. Un cache de lecture est donc caractris par un offset et une version, et reflte ltat
des pages correspondantes dans le blob.

4.1.2

Cohrence avec la smantique de Hadoop

Lors dune requte de lecture, un segment lire est pass en paramtre. 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 requte nest envoye BlobSeer, le contenu du cache est simplement lu. Si la requte de lecture concerne un segment en dehors du cache, ou partiellement en
dehors, il suffit de charger dans le cache la page approprie. Cest uniquement dans ce cas que BlobSeer est contact. Hadoop ne modifie pas les informations une fois crite (modle write-once-readmany, cest dire un seul crivain ne faisant quajouter des donnes sans rcrire sur les prcdentes,
puis plusieurs lecteurs en mme temps) Nous navons donc pas besoin que le cache corresponde la
dernire version connue : une version non nulle suffit. Si la fin du blob est atteinte pour une certaine
version, on recharge alors la dernire version pour vrifier si dautre pages nont pas t ajoutes. Le
cache de lecture est donc en permanence cohrent avec le contenu du blob.
Lors dune requte dcriture, toutes les donnes sont galement ajoutes dans un cache dcriture.
Ds que ce cache est plein, il est envoy BlobSeer. Un seul crivain tant autoris dans le modle
de Hadoop, il ny a pas de conflit dcriture. Lajout dune fonction flush appele lors de la fermeture
du flux permet de grer le cas dune taille de fichier non-multiple de la taille des pages, en envoy-

11

ant au server la taille relle du fichier et en compltant ventuellement (au choix de lutilisateur de
configurer cela ou non) le cache avec un caractre particulier (nul, en gnral).

4.2

Tests sur Grid5000

4.2.1

Upload/Download de fichiers

Pour tester BSFS, nous avons dploy BlobSeer sur le Grid5000 [1]. Le systme ne permettant pour
le moment que la gestion de fichiers dont la taille est un multiple de la taille des pages utilises, les
tests se rsument lupload et au download de gros fichiers depuis et vers un systme de fichiers local.
Le premier test consiste en lenvoi et la rcupration dun fichier de 1 Go par un seul client. Pour
tester BSFS, BlobSeer est dploy sur sept noeuds : un version-manager, un provider-manager, trois
providers et deux sdhts. Un huitime noeud contient le NameNode, et un neuvime joue le rle du client.
En comparaison, la mme exprience est ralise avec HDFS dploy 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 rsultats (dbit de lecture et dcriture) de cette expriences.

mission
Rception

BSFS
76.6 MB/s
44.1 MB/s

HDFS
70.0 MB/s
42.5 MB/s

Dans un deuxime temps, nous cherchons comparer laspect concurrent des deux systmes. Dans
les deux cas, nous utilisons dix units de stockage pour cela. Dans le cas de lcriture, trois clients
crivent en mme temps un fichier de 1 Go diffrent. Nous comparons ensuite la lecture concurrente
du mme fichier. Trois clients tlchargent le mme fichier de manire concurrente. Dans les deux cas
le dbit moyen est mesur. Le tableau ci-dessous prsente les rsultats obtenus :

mission
Rception

4.2.2

BSFS
72.1 MB/s
49.5 MB/s

HDFS
76.3 MB/s
50.9 MB/s

Application MapReduce relle : inverted index

Nous avons ensuite compar BSFS HDFS dans lapplication inverted index. Cet algorithme est la
base des systmes dindexation sur internet. Considerant un ensemble de documents (les contenus
de pages web, par exemple), lapplication scanne ces documents et renvoie un index, cest dire une
liste associant chaque mot un ensemble de paires h nom du document, position dans le document i. Cest
sur la base de ce genre dindex que lon peut raliser des algorithmes optimiss dans la recherche
sur le web, fonctionnant principalement par intersection densembles. Les fonctions map et reduce
fonctionnent de la manire suivant.
Map : cette fonction prend le nom dun document en entre, en lit le contenu et cre la liste des
paires intermdiaires h mot, (nom du document, position)i.
Reduce : elle prend en argument la liste des paires h mot, (nom du document, position) i et ne fait
que lcrire dans lindex, avec ventuellement un pr-tratement de tri par nom ou par position.
Le dploiement de Hadoop est effectu sur 18 nuds dun mme cluster7 . Sur ces 18 nuds, nous
lanons 18 TaskTrackers de Hadoop, et nous utilisons ces mmes 18 nuds pour dployer le systme
7 Un

cluster est un ensemble de machines de mmes caractristiques.

12

de fichiers. Dans le cas de HDFS, 17 nuds sont utiliss pour le stockage, 1 nud est utilis comme
NameNode. Dans le cas de BSFS, nous utilisons 12 providers, 3 nuds sdht, un provider manager et un
version manager. De plus le NameNode est dploy sur un 18eme nud. Contrarement la prcdente
exprience, o nous cherchions utiliser le mme nombre de nuds grant les donnes, nous cherchons ici dployer lintgralit du systme sur un mme nombre de nuds.
Lalgorithme est lanc sur un ensemble de 20 livres numriques au format txt, provenant de la
base de donnes du projet Gutemberg. Ces entres remprsentent un volume denviron 16 Mo. Les
rsultats obtenus sont trs encourageants, puisque linverted index sest termin en 52,2sec avec BSFS,
contre 57,5sec avec HDFS.

4.2.3

Interprtation des rsultats

Au vu des rsultats, notre objectif est atteint. En effet nous arrivons des dbits quivalents en
utilisant BSFS et en utilisant HDFS pour le transfert de fichiers. BlobSeer nous apporte le systme
de versionning manquant HDFS, ce genre de rsultat est prometteur quant lavenir du travail.
Nous noterons que le cache de BSFS tant fix la taille des pages, nous ne profitons pas de tous les
aspects de paralllisation des requtes de BlobSeer. Lorsque plusieurs pages sont requises, elles sont
envoyes en parallle par tous les providers concerns. Ici nous ne demandons quune seule page
la fois. La dernire version de BSFS permet de paramtrer le cache pour avoir une taille diffrente
de celle des pages. De plus, un systme de cache intelligent, anticipant les oprations pour charger
de nouvelles pages dans un thread avant quelles ne soient effectivement requises, serait une bonne
perspective damlioration de ce systme. De nouveaux tests devront tre mens afin de dterminer
la taille de cache optimale.
Le lecteur prendra garde ne pas faire de rapprochement entre les deux tableaux : les rsultats
ayant t obtenus dans des conditions diffrentes (nombre de DataNodes diffrent, et ressources diffrentes sur Grid5000).
Les rsultats obtenus sur lalgorithme inverted index sont les premiers dune srie dexprience qui
devrat tre ralise pour situer BlobSeer par rapport aux systmes existents comme HDFS. Nous
envisageons lavenir dtudier notre systme sur tous les plans possibles : taille des pages, taille du
cache, nombre de nuds, etc.

4.3
4.3.1

Perspectives pour BSFS

Gestion, vrification et scurisation des mtadonnes

Actuellement, la gestion des mtadonnes se fait sur le mme modle que pour HDFS, savoir un
serveur grant les informations sur le systme de fichiers. Une sauvegarde au format YAML des mtadonnes est faite chaque modification. (Dans le cas de HDFS il sagit dun serveur part entire,
le SecondaryNameNode, qui tlcharge priodiquement toutes les informations et les sauvegarde). Une
possible amlioration de la gestion des mtadonnes consisterait en une interaction plus forte entre
BlobSeer et le NameNode, permettant de vrifier la cohrence des informations (principalement lexistence du blob). Un systme de somme de contrle (checksum) permettrait galement damliorer la
fiabilit de notre systme, dautant plus quHadoop prvoit les classes abstraites pour cela.
Nous avons pris exemple sur HDFS et GFS dans notre modle de gestion des informations. Ce
modle possde pourtant linconvnient de centraliser les informations au sein dun seul nud qui
peut alors devenir un goulet dtranglement. Une solution pour empcher cela serait de remplacer

13

le NameNode par une table de hachage distribue. BlobSeer utilisant dj une table de hachage distribue, il serait possible dutiliser cette mme table pour stocker les mtadonnes concernant les
fichiers. Ce principe est dailleurs utilis dans le systme de fichiers BlobSeer-Fuse dvelopp par
Diana Moise au sein de lquipe KerData.

4.3.2

Localisation pour loptimisation du calcul

Une autre optimisation possible consiste donner Hadoop la possibilit de localiser les pages
au sein des diffrentes machines. Dans le modle HDFS, chaque machine est la fois un TaskTracker
(l o se font les calculs) et un DataNode (l o sont stockes les donnes). HDFS communique
Hadoop la localisation des blocs de fichiers de manire ce que les calculs soient lancs le plus proche
possible des donnes utilises. Ainsi, on minimise le dplacement des donnes. De la mme manire
les futures volutions de BSFS intgreront un systme 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.

Conclusion

En utilisant BlobSeer comme systme de stockage sous-jacent un systme de fichiers distribu

pour Hadoop, et en prenant pour modle larchitecture de HDFS en ce qui concerne la gestion des
mtadonnes, nous avons pu atteindre des performances quivalentes en terme de dbits de lecture
et dcriture des fichiers, et une amlioration des accs concurrents dans le cadre dune application
relle : linverted index. Notre systme a lavantage de disposer de capacits de versionning, qui devraient savrer plus efficaces que le simple systme de snapshot envisag dans les futures versions
de HDFS. En effet, dans notre perspective, la moindre modification de fichier est sauvegarde de
manire efficace.
Ces rsultats encourageants, obtenus sur la plateforme Grid5000, ont t raliss sans pour autant
que le systme de cache que nous avons constat si indispensable lacclration des oprations ne
soit optimis. Les travaux futurs concerneront donc loptimisation des caches de lecture et dcriture.
Les tests raliss posent les premires pierres dune phase de tests systmatique qui permettront
de situer BlobSeer et BlobSeerFileSystem dans lunivers des systmes de fichiers distribus orients
calculs hautes performances.
La mise en place dun systme de localisation des donnes pour le lancement optimis des calculs
est galement une amlioration envisager si nous souhaitons encore gagner du terrain sur HDFS.
Terminons en notant ce titre quHadoop dtient lheure actuelle le Terabyte Sort Benchmark[3],
qui consiste en un tri massif de donnes, avec un dbit de 0.578 TB/min. Nous avons vu limportance
tenue par les systmes de fichiers distribues dans les oprations de traitement de gros fichiers. La
question est donc : pourra-t-on terme avoir un meilleur dbit en utilisant BSFS ?

14

References
[1] Aladdin G5k. https://www.grid5000.fr/.
[2] Hadoop MapReduce. http://hadoop.apache.org/.
[3] http://sortbenchmark.org/.
[4] Jeffrey Dean and Sanjay Ghemawat. MapReduce: Simplified data processing on large clusters.
UC Berkley and Intel Research, 2005.
[5] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google Filesystem. 19th ACM
Symposium on Operating Systems Principles, Lake George, NY, 2003.
[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, 2008.
[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 2008 Poster Session, Tsukuba : Japan, 2008.
[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), 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. 2009.
[10] Andrew S. Tanenbaum. Modern Operating Systems. Prentice Hall Press, Upper Saddle River, NJ,
USA, 2007.
[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, 2007.
[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-08-114, 2008.
[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, 2004.

15

A
A.1

Annexe
Architecture de BlobSeer : schma

F IG . 3 Architecture de BlobSeer

16

A.2

Procd MapReduce

Le schma suivant a t repris de [citer les references ici]

F IG . 4 Processus MapReduce de Google

17