MapReduce tol erant les fautes byzantines

Jonathan Lejeune et Madeleine Piffaretti

Le 28 juillet 2010
Table des mati` eres
1 R esum e 3
1.1 But du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 R esultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Les m etriques . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Tol erance aux pannes byzantines . . . . . . . . . . . . . . . . 6
2 D eploiement de la plate-forme 7
3 Guide dutilisation 8
3.1 Pr erequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Lancer le MapReduce avec OAR . . . . . . . . . . . . . . . . . . . . 8
4 Lancement des scripts pour la gestion des pannes franches 9
4.1 Pr ecautions dutilisation . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Scripts de lancement et explications . . . . . . . . . . . . . . . . . . 9
5 Lancement des scripts pour la gestion des pannes byzantines 11
5.1 Lancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1 1` ere exp erience . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.2 2` eme exp erience . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.3 3` eme exp erience . . . . . . . . . . . . . . . . . . . . . . . . 14
6 Modications 15
6.1 Modications des scripts shell . . . . . . . . . . . . . . . . . . . . . 15
6.2 Sondes pour la mesure des m etriques . . . . . . . . . . . . . . . . . . 15
6.3 Gestion des pannes franches . . . . . . . . . . . . . . . . . . . . . . 17
6.4 Gestion des pannes byzantines . . . . . . . . . . . . . . . . . . . . . 17
6.4.1 Lalgorithme . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4.2 Au niveau de HADOOP . . . . . . . . . . . . . . . . . . . . 17
6.4.3 Au niveau de la machine matre . . . . . . . . . . . . . . . . 18
6.4.4 Au niveau des machines esclaves . . . . . . . . . . . . . . . 22
7 Perspectives 27
7.1 Injections de pannes . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1.1 Th eorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1.2 Suggestion dimpl ementation . . . . . . . . . . . . . . . . . 27
8 Annexes 28
8.1 Les schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1.1 JobQueueTaskScheduler . . . . . . . . . . . . . . . . . . . . 28
8.1.2 LimitTaskPerJobTaskScheduler . . . . . . . . . . . . . . . . 30
8.2 M etriques suppl ementaires . . . . . . . . . . . . . . . . . . . . . . . 32
2
1 R esum e
1.1 But du stage
Le stage est la prolongation dun travail commenc e en projet de master1 SAR ayant
pour intitul e : R eplication de t aches dans le framework MapReduce de Hadoop.
Le but du stage etait dans un premier temps de fournir des mesures de m etriques as-
sez d etaill ees en comparant plusieurs congurations : Sans R eplication Avec Sp eculation,
Avec R eplication Avec Sp eculation, Sans R eplication Sans Sp eculation, Avec R eplication
Sans Sp eculation. Nous devions mesurer la latence de plusieurs exp eriences et d etailler
les messages echang es en faisant varier la taille du split (donc le nombre de maps).
Dans un second temps nous avons essay e de rendre MapReduce tol erant aux pannes by-
zantines, cest-` a-dire de proposer une strat egie pour ecarter les r esultats erron es, voire
les noeuds malicieux qui les produisent.
1.2 R esultats
1.2.1 Les m etriques
Pour le d etail de limpl ementation, se r eferer ` a la section 6.2 : Sondes pour la me-
sure des m etriques.
Voici une s election des r esultats que nous avons obtenu :
N.B :vous trouverez dautres courbes en annexe : d etails pour les messages et ecarts-
types.
100
119
139
158
177
4
236 maps
8
118 maps
12
79 maps
16
59 maps
24
40 maps
32
30 maps
48
20 maps
64
15 maps
L
a
t
e
n
c
e

(
s
e
c
o
n
d
e
s
)
taille du split Mo et nombre de maps
Latence du MapReduce en fonction de la taille dun split
Taille des donnees en entree: 989118464 octets
ARAS
SRAS
ARSS
SRSS
FIGURE 1 Latence du MapReduce
3
11
17
22
27
33
4
236 maps
8
118 maps
12
79 maps
16
59 maps
24
40 maps
32
30 maps
48
20 maps
64
15 maps
L
a
t
e
n
c
e

(
s
e
c
o
n
d
e
s
)
taille du split Mo et nombre de maps
Latence des maps en fonction de la taille dun split
Taille des donnees en entree: 989118464 octets
ARAS
SRAS
ARSS
SRSS
FIGURE 2 Latence des maps
20
40
60
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
L
a
t
e
n
c
e

(
s
e
c
o
n
d
e
s
)
.
Latence des reduces (shuffle + sort + reduce) en fonction de la taille dun split
Taille des donnees en entree: 989118464 octets
SHUFFLE
SORT
REDUCE
split: 4 M
236 maps
split: 8 M
118 maps
split: 12 M
79 maps
split: 16 M
59 maps
split: 24 M
40 maps
split: 32 M
30 maps
split: 48 M
20 maps
split: 64 M
15 maps
FIGURE 3 Latence des reduces
4
1000
2000
3000
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
T
a
i
l
l
e

d
e
s

d
o
n
n
e
e
s

e
c
h
a
n
g
e
e
s

(
k
i
l
o

o
c
t
e
t
s
)
.
Taille des donnees echangees(classees par type de message) en fonction de la taille dun split
Taille des donnees en entree: 989118464 octets
Mapred
Service
HDFS
Autres
split: 4 M
236 maps
split: 8 M
118 maps
split: 12 M
79 maps
split: 16 M
59 maps
split: 24 M
40 maps
split: 32 M
30 maps
split: 48 M
20 maps
split: 64 M
15 maps
FIGURE 4 Taille des donn ees echang ees
0
1000
2000
3000
4000
5000
6000
7000
8000
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
N
o
m
b
r
e

d
e

m
e
s
s
a
g
e
s
.
Nombre de messages (classes par type) en fonction de la taille dun split
Taille des donnees en entree: 989118464 octets
Mapred
Service
HDFS
Autres
split: 4 M
236 maps
split: 8 M
118 maps
split: 12 M
79 maps
split: 16 M
59 maps
split: 24 M
40 maps
split: 32 M
30 maps
split: 48 M
20 maps
split: 64 M
15 maps
FIGURE 5 Nombre de messages echang es
5
1.2.2 Tol erance aux pannes byzantines
Voici les r esultats que nous obtenons en comparant trois exp eriences diff erentes :
Gestion des byzantins en relacant hadoop et un nouveau job ` a chaque fois quune
incoh erence est constat ee.
Gestion des byzantins en lancant hadoop une seule fois mais en relancant un
nouveau job ` a chaque incoh erence.
Gestion des byzantins au sein m eme du job (notre impl ementation)
Pour chaque exp erience la conguration du syst` eme est la m eme, nous avons privil egi e
au maximum la conguration par d efaut : notamment pour la taille du split (64 Mo).Par
contre nous avons chang e le nombre de reduce (10 au lieu de 1 par d efaut).De plus le
mapReduce offre le choix entre deux schedulers, nous navons pas pris le scheduler par
d efaut mais LimitTaskPerJobTaskScheduler (pour ne pas limiter le nombre de reduce
scheduler, cf.Annexes sur les schedulers). Pour le d etail de limpl ementation se r ef erer
` a la section 5.Lancement des scripts pour la gestion des pannes byzantines.
Ci-dessous diff erents tableaux contenant les latences mesur ees pour les trois exp eriences
en fonction de la taille du chier dentr ee avec 0 faute inject ee. Cela nous permet donc
de voir le co ut de nos modications.
Exp erience 1 Exp erience 2 Exp erience 3
427 35 43
FIGURE 6 Latence du MapReduce BF - taille chier :1 Mo - 0 faute inject ee
Exp erience 1 Exp erience 2 Exp erience 3
348 36 101
FIGURE 7 Latence du MapReduce BF - taille chier :10 Mo - 0 faute inject ee
Exp erience 1 Exp erience 2 Exp erience 3
409 39 169
FIGURE 8 Latence du MapReduce BF - taille chier :300 Mo - 0 faute inject ee
Probl` eme :Dans l etat actuelle des choses, la plateforme est encore relativement
instable lors du passage ` a l echelle. Blocages observ es lors des tests pour lexp erience
3. Il y donc s urement des choses ` a revoir dans notre impl ementation.
6
2 D eploiement de la plate-forme
D eploiement de la plate-forme sur une machine frontale dun cluster fonctionnant
avec OAR
D ezipper larchive fourni ` a la racine de votre home.
Vous obtenez un dossier contenant entre autre les sources, les binaires (jar et
scripts) et les chiers de conguation de Hadoop.
Congurer le .bashrc en y rajoutant les lignes suivantes :
export HADOOP INSTALL= /hadoop-0.20.2
export HADOOP HOME=$HADOOP INSTALL
export HADOOP INPUT=$HADOOP INSTALL/INPUT
export HADOOP BENCH=$HADOOP INSTALL/BENCH
Cr eer un chier .hadooprc ` a la racine de votre home et y ecrire ces m eme lignes.
Dans le chier $HADOOP HOME/conf/hadoop-env.sh d enir dans $JAVA HOME
le chemin vers la machine virtuelle java la plus r ecente (version 1.6 requise).
7
3 Guide dutilisation
3.1 Pr erequis
Connatre les commandes de reservation de noeuds et de soumission de jobs avec
OAR.
http ://oar.imag.fr/users/user documentation.html
https ://ciment.ujf-grenoble.fr/docs/tp-utilisateur-oar2/tp-oar2/
3.2 Lancer le MapReduce avec OAR
La premi` ere chose ` a laquelle il faut faire attention est que lors de la reservation, les
noeuds doivent avoir des IP diff erentes.
La deuxi` eme est quil existe deux modes de fonctionnement dOAR : interactif :
oarsub -I -l nodes= <nombre de machines voulues>,walltime=<temps de r eservation>
et passif :
oarsub -l nodes=<nombre de machines voulues>,walltime=<temps de r eservation>
/chemin/vers/commande/a/lancer
En mode interactif vous allez lancer le script de lancement, i.e. les sorties standards
et erreurs seront celle de votre terminal. En mode passif, ces deux sorties seront ecrites
respectivement dans les chiers OAR<idjob> .stdout OAR<idjob> .stderr. Ces -
chiers sont cr e es automatiquement dans le r epertoire o` u la commande oarsub a et e
lanc ee.
Copier un chier dentr ee sur lequel le wordcount se fera dans $HADOOP INPUT.
Attention : ne mettre quun seul chier dans ce r epertoire.
8
4 Lancement des scripts pour la gestion des pannes franches
4.1 Pr ecautions dutilisation
Assurez-vous que les properties mapred.max.split.size (chier $HADOOP HOME/conf/mapred-
conf.xml) et dfs.block.size (chier $HADOOP HOME/conf/hdfs-conf.xml) soient bien
d enies. Il est conseiller de les mettre ` a leur valeur par d efaut (cf. doc).
On fait varier la taille du split. Cependant il est possible de faire varier la taille dun
bloc hdfs. Dans ce cas, la taille dun bloc est egale ` a la taille du split. Pour activer cette
option, d ecommenter les lignes correspondantes au d ebut du script launch bench.sh.
La listes des points que lon veut mod eliser correspond ` a la variable $abscisses qui est
format ee de la mani` ere suivante : abscisse1 abscisse2 ... abscisseN. Ces valeurs sont
exprim ees en octets . Attention : la valeur max doit etre inf erieure ou egale ` a la taille
du bloc HDFS.
4.2 Scripts de lancement et explications
Lancer le script launch bench.sh <nombre de test> sur la machine qui fera ofce
de matre pour Hadoop.
Ce script :
Congure Hadoop en fonction des machines allou ees par OAR.
G en ere le r epertoire de r esultat ainsi que le r epertoire de logs.
Lance ` a la suite le wordcount sur les quatre congurations.
R ecup` ere les donn ees ` a partir des logs pour g en erer ensuite les courbes corres-
pondantes aux m etriques. Ces courbes seront pr esentes dans $HADOOP BENCH/pdf
et $HADOOP BENCH/ps. Leur script gnuplot seront dans $HADOOP BENCH/gnuplot.
Les .dat permettant de g en erer les courbes sont dans $HADOOP BENCH/result bench.
Attention : penser ` a sauvegarder tous les r esultats dun bench pr ec edent, car ceux-ci
seront ecras es au lancement dun nouveau bench.
Pour chaque conguration de HADOOP, il existe un dossier dans our logs. Dans cha-
cun de ces dossiers, il y a nb test dossiers correspondant au log de chaque job lanc e sur
la plateforme. Qui eux m eme contiennent les chiers suivants :
checksums : checksums du r esultat nal du wordcount
un chier xml r ecapitulant la conguration avec laquelle le test est lanc e
un chier de log du jobtracker g en erer par Hadoop
un chier contenant des informations sur le lancement du job et de ses t aches .
un chier contenant des informations sur le nom, le nombre et la taille des mes-
sages echang es durant le job.
Ces deux derniers chiers sont g en er es par les sondes que nous avons cod e directement
dans le code source.
Il est a not e que si il y a eu un probl` eme dincoh erence au niveau des checksums,
le chier $HADOOP BENCH/result bench/report checksum sera cr e e.
N.B : A chaque changement de conguration, Hadoop est format e et red emarr e. Un
premier job est lanc e mais nest pas pris en compte car linitialisation r ecente peut
fausser les performances.
9
Pour un bench le nombre de job lanc e se calcul de la mani` ere suivante :
(nombre de test+1) x nb conguration o` u nb conguration= 4 x nb abscisses
4 car on a quatre congurations de base (ARAS, SRAS, ARSS, SRSS).
10
5 Lancement des scripts pour la gestion des pannes by-
zantines
5.1 Lancement
5.2 Explications
En lancant le script launch bench byzantin.sh nous comparons trois types de ges-
tion des pannes byzantines.
Pour ces trois congurations diff erentes nous nous servons dun checksum pour
v erier lint egrit e des chiers de sortie lors dun mapReduce de type WordCount.
5.2.1 1` ere exp erience
Nous calculons le nombre de jobs minimal ` a lancer initialement pour etre s ur de
tol erer N fautes. Si on rep` ere une faute, ce nombre augmente jusqu` a une valeur maxi-
male :
nb job a lancer=nb fautes + 1
nb job max a lancer=(2xnb fautes) + 1
`
A chaque nouveau job, hadoop est relanc e.
Voici la suite dinstructions (en pseudo code) effectu ees pour cette 1` ere exp erience :
Algorithme 1 Algorithme 1ere experience
Prenons nb fautes tolerees = 1
pour (num test = 0 ;num test nb tests ; num test++) faire
nb job a lancer = nb fautes + 1 = 2
nb job max a lancer = (2 nb fautes) + 1 = 3
pour (i = 1 ; i nb job a lancer et nb job a lancer nb job max a lancer ; i++)
faire
lancer Hadoop
lancer JOB i
copier son historique
calcul checksum pour JOB i et verication avec autres jobs
si Counter checksum k : C chk k tel que C chk k C chk i alors
nb job a lancer ++
nsi
copier les chiers de logs
n pour
n pour
11
5.2.2 2` eme exp erience
Nous calculons le nombre de jobs minimal ` a lancer initialement pour etre s ur de
tol erer N fautes. Si on rep` ere une faute, ce nombre augmente jusqu` a une valeur maxi-
male.
nb job a lancer=nb fautes + 1
nb job max a lancer=(2xnb fautes) + 1
Hadoop nest lanc e quune fois.
Voici la suite dinstructions (en pseudo code) effectu ees pour cette 2` eme exp erience :
12
Algorithme 2 Algorithme 2eme experience
Prenons nb fautes tolerees = 1
next test = ok
pour (num test = 0 ; num test nb tests ; num test++) faire
nb job a lancer = nb fautes + 1 = 2
nb job max a lancer = (2 nb fautes) + 1 = 3
si premier test alors
lancer Hadoop
nsi
pour (i = 1 ; i nb job a lancer ; i++) faire
lancer JOB i en parallele
recuperer le pid de ce processus (JOB i)
n pour
si next test=ok alors
pour (i = 1 ; i nb job a lancer ; i++) faire
attendre n processus pid = pid JOB i
copier son historique
ajouter le num ero du Job dans chaine jobs ni
calcul checksum Chk i pour JOB i et verication avec autres jobs
si Counter checksum k : C chk k tel que C chk k C chk i et que
lon a pas atteint le nb job max a lancer alors
nb job a lancer ++
lancer nouveau JOB k en parallele
recuperer son pid dans une variable qui lui est propre pid job k
recuperer son num ero et lajouter a la liste jobs en cours
nsi
n pour
next test = ko
nsi
pour i dans la liste des jobs en cours ((nouveaux jobs schedul e si erreur) faire
si i nest pas dans la liste jobs ni alors
attendre n processus pid = pid JOB i
copier son historique
ajouter le numero du Job dans la liste jobs ni
calcul checksum pour JOB i et verication avec autres jobs
si checksum different et que lon a pas atteint le nb job max a lancer alors
nb job a lancer ++
lancer nouveau JOB k en parallele
recuperer son pid dans une variable qui lui est propre pid job k
recuperer son numero et lajouter ` a la liste job en cours
nsi
nsi
si aucun job schedule et on a lance nb job a lancer alors
next test = ok
nsi
n pour
n pour
copier les logs
13
5.2.3 3` eme exp erience
Cette derni` ere exp erience est la m ethode que nous proposons pour g erer les fautes
byzantines. Les fautes sont trait ees au sein m eme du job (cf. section 6.4 :Modications.
Gestion des pannes byzantines).
Voici la suite dinstructions (en pseudo code) effectu ees pour cette 3` eme exp erience :
Algorithme 3 Algorithme 3eme experience
pour (num test = 0 ;num test nb tests ; num test++) faire
si premier test alors
lancer Hadoop
nsi
lancer JOB
copier les log
n pour
14
6 Modications
N.B. : Une bonne connaissance de larchitecture interne de HADOOP est indispen-
sable pour cette partie.
6.1 Modications des scripts shell
Pour pouvoir faire laiguillage entre les diff erents types de r eplications de t ache,
nous avons d enit une variable. Elle sappelle MR replication et est d eclar ee dans le
chier $HADOOP HOME/conf/hadoop env.sh. Elle peut prendre trois valeurs :
desactive : le chier $HADOOP HOME/hadoop-0.20.2-core-sans-replication.jar
sera utilis e, pas de r eplication des t aches
active : le chier $HADOOP HOME/hadoop-0.20.2-core.jar sera utilis e, r eplication
pour tol erer uniquement les pannes franches gr ace au m ecanisme de la sp eculation
byzantin : le chier $HADOOP HOME/hadoop-0.20.2-core-replication-byzantin.jar
sera utilis e. Les pannes byzantines sont tol er ees.
6.2 Sondes pour la mesure des m etriques
Latence : Les classes JobInProgress et TaskInProgress ont et e modi ees pour
loguer les d ebuts et ns de Jobs, t aches. Pour sauvegarder ces donn ees sur le
disque la m ethode statique writeLatence de la classe ServerLog (cf. paragraphe
suivant) est appel ee. Ces logs sont pars es ` a la n de lexp erience pour calculer
les latences.
Compteur de messages : Trois classes java ont et e rajout ees pour compter les
messages et des classes de Hadoop ont d u etre modi ees.
ServerLog : Cette classe mise dans le package org.apache.hadoop.ipc est as-
soci e ` a chaque serveur RPC de Hadoop (NameNode, Datanode, Jobtracker,
Tasktracker). Il est inutile de prendre en compte les messages sur chaque
Tasktracker car ce ne sont que des messages en provenance des children ,
donc que des messages en local, ce qui ne co ute rien en bande passante du
r eseau. Apr` es quelque tests, nous nous sommes rendu compte que les mes-
sages echang es entre les datanodes etaient n egligeables par rapport aux mes-
sages recu sur la machine matre. Par cons equent nous navons gard e que deux
instances de ServerLog : Namenode et Jobtracker. La premi` ere t ache que ce
thread fait est denvoyer sur un autre serveur java pr esent sur le matre, le port
sur lequel il est en train d ecouter. Ensuite il se met en attente de messages. Ces
messages renseignent sur le commencement dun nouveau test car au niveau
RPC Hadoop il est impossible de d etecter ceci.
ServerRpcCollector : Cette classe d emarre un serveur sur le port 35000 du
noeud matre apr` es chaque d emarrage dHadoop. Son r ole est de collecter les
ports de chaque serveur de log pour que lon puissent par la suite les informer
quun nouveau job a et e lanc e.
NotierNextJob : Cette classe envoie un message ` a chaque serveur de log
collect e par le ServerRpcCollector ` a la n de chaque test.
org.apache.hadoop.ipc.Server Un attribut de type ServerLog a et e ajout e
dans cette classe. On a donc un serveur log associ e ` a chaque serveur RPC.
Cette r ef erence est nulle par d efaut et est instanci ee si il sagit du Serveur
RPC du Jobtracker ou du Namenode.
15
1 protected ServerLog sl=null;
Listing 1 D eclaration de lattribut ServerLog
D eclaration de lattribut ServerLog
1 if(sl!=null)
2 sl.writeLog(call.connection.getNameMethod(), res.
length,false)
Listing 2 M ethode setupResponse
Loguer le nom de la m ethode et la taille du r esultat de lappel sortant.
org.apache.hadoop.ipc.Server.Connection
1 private long size_param=0;
2 private String nameMethod="";
3 private Object locknameMethod=new Object();
4 private Object lock=new Object();
5 //ici suit les getters et setters de ces attributs
Listing 3 Rajout de deux attributs ainsi que leur objets de verrou
Nous avons ajout e deux attributs dans cette classe : une chaine de caract` ere
pour le nom de la m ethode en question ainsi quun entier de type long pour
sauvegarder la taille des param` etres dun appel entrant. Lacc es ` a ces attributs
se font de mani` ere synchronis ee.
1 this.setSizeParam(count);
Listing 4 M ethode readAndProcess()
Sauvegarder la taille des param` etres dentr ee pour la connection.
org.apache.hadoop.ipc.Server.Handler
1 if(sl!=null){
2 Invocation invoc = (Invocation)call.param;
3 call.connection.setNameMethod(invoc.
getMethodName());
4 }
Listing 5 Sauvegarder le nom de la m ethode durant lappel
Sauvegarder le nom de lappel dans la m ethode run du handler.
1 if(sl!=null){
2 sl.writeLog(call.connection.getNameMethod(),
call.connection.getSizeParam(),true);
3 }
Listing 6 Loguer lappel entrant
Loguer le nom de la m ethode et la taille des param` etres de lappel entrant.
org.apache.hadoop.ipc.RPC.Server
1 if(!(instance instanceof TaskTracker) && !(instance
instanceof DataNode)){
2 System.out.println("
**********
RPC: instance
server: "+instance.getClass().toString()+"
*********
");
16
3 this.sl=new ServerLog();
4 new Thread(sl).start();
5 }
Listing 7 Instanciation et d emarrage du ServerLog
Le serveur log est d emarr e ` a la construction du Serveur RPC en v eriant que
lh ote est bien Jobtracker ou Namenode.
La classe interne Invocation de RPC etait d eclar ee priv ee initialement. Nous
avons d u la rendre publique pour sauvegarder le nom de la m ethode dans le
code de la classe m` ere Server.
6.3 Gestion des pannes franches
cf . Rapport PSAR : R eplication de t aches dans le framework MapReduce.
6.4 Gestion des pannes byzantines
Attention : ne pas activer les codecs et numReduce>0
6.4.1 Lalgorithme
Nous rappelons lalgorithme sous forme de pseudo-code qui permet de tol erer en
plus des pannes franches, les pannes byzantines.
Pour tol erer f fautes
Id ee g en erale :
On d emarre pour chaque Map f+1 r eplications.
Lorsquune r eplication se termine, elle envoie lensemble de ses digests au Job-
tracker.

`
A la r eception des digests dun map, le Jobtracker les compare avec les r esultats
d ej` a recus des autres r eplications.
Si la majorit e actuelle nest pas ce r esultat ou bien si un autre r esultat poss` ede la
m eme valeur : resch eduler une autre r eplication.
Lorsque toutes les Maps sont termin ees : elire le bon r esultat pour chaque Map
et sch eduler les reduces en leur indiquant la liste des digests elus.
Les reduces copient les r esultats pour chaque r eplication, calculent le digest de
ce r esultat et le comparent avec celui que le Jobtracker a elu.
Si il existe une incoh erence ` a ce niveau, les reduces t el echargent le r esultat dune
autre r eplication de ce map, sinon ils consid` erent que cest le bon r esultat.
La gestion des reduces se fait de la m eme mani` ere que celles des maps. Elles
ne peuvent committer leur r esultat que lorsque toute reduce sest termin ee et
quapr es que le Jobtracker ait pris connaissance du bon r esultat ` a la majorit e.
! ! ! ! ! ! ! ! ! ! ! ICI ALGO! ! ! ! ! ! ! ! ! ! !
6.4.2 Au niveau de HADOOP
Deux param etres modiables dans le chier de conguration mapred-site.xml ont
et e ajout es.
17
mapred.job.timer : timeout des timers pour d etecter la non-r eponse des esclaves
(vaut 15 minutes par d efaut)
mapred.job.BFT : nombre de fautes byzantines tol er ees, equivalent ` a la variable
f de lalgorithme (vaut 1 par d efaut)
6.4.3 Au niveau de la machine matre
Au niveau du Jobtracker nous avons rajout e deux classes supl ementaires pour impl ementer
la tol erance aux pannes byzantines.
Une classe BFTmanager : g` ere lensemble des traitements ` a faire sur un Job. Il fait
ofce de serveur pour acceuillir les digests des t aches.
Une classe BFTinfoTask : qui maintient des informations en temps r eel sur les t aches
dun Job. Cette classe contient principalement des tables de hachage <digest,entier>,
des compteurs qui permettent le scheduling des r eplications etc.
Au moment de linitialisation dun Job, on instancie un objet de la classe BFTmanager
et on d emarre le serveur. Un nouvel attribut de type BFTmanager a donc et e ajout e
dans la classe JobInProgress.
1 this.bftmanager= new BFTmanager(this);
2 Thread t=new Thread(this.bftmanager);
3 t.start();
Listing 8 M ethode initTasks() de JobInProgress : instanciation et d emarrage du
BFTmanager
Description de la classe BFTmanager :
Cette classe contient des attributs qui font ofce de constantes tels que, le port sur
lequel le serveur tourne, le minimum et le maximum de r eplications que lon peut lan-
cer (respectivement f+1 et 2f+1), le nombre de fautes tol er ees (i.e. f) et la valeur du
timeout des timers.
Elle poss` ede egalement deux tableaux de BFTinfoTask : un tableau pour les maps et un
tableau pour les r educes. Ainsi si un job poss` ede m maps et r reduces, la taille de ces
tableaux sera respectivement m et r.
Description de la classe BFTinfoTask :
Les principaux attributs :
digests : un tableau de HashMap<String,Integer>qui permet de stocker le nombre
doccurrences des digests recus. Si lobjet repr esente une t ache map, la taille de
ce tableau sera egale au nombre de reduces du Job sinon la taille sera egale ` a 1.
En effet, nous rappelons que les r esultats des maps sont divis es en n partitions
o` u n est le nombre de reduces du Job. Ainsi les digests de la partition p seront
stock e dans la p ` eme case du tableau. La HashMap associe un compteur ` a chaque
digest recu et permettra par la suite de d eterminer le digest qui a la majorit e.
attemptToDigests : une HashMap<TaskAttemptID,String[]> qui associe ` a une
r eplication les digests quelle a envoy e.
18
hosts : une HashMap<String,Timer> qui associe un nom dh ote, sur lequel
est ex ecut ee une r eplication, ` a son timer. Ceci permet didentier les timers de
mani` ere unique puisque nous garantissons que chaque r eplication sex ecute sur
une machine diff erente. Lobjectif second est de pouvoir ainsi stocker des infor-
mations sur les h otes d efaillants.
hostTimeout : Set<String> est un ensemble qui stocke les noms dh otes sur
lequel le timer sest d eclench e. Cet attribut nest pas utilis e dans l etat actuel des
chose mais pourra servir par exemple dans un d eveloppement futur pour interdir
de sch eduler des t aches sur des h otes qui seront dans cet ensemble.
shouldReply : un bool een qui vaut vrai quand une t ache doit etre r epliqu ee.
Initialis e ` a faux, il passe ` a vrai lorsque la premi` ere tentative a et e distribu ee sur
le site.
Des compteurs pour contr oler la r eplication dune t ache sont egalement n ecessaires :
numReplicationToLaunch : initialis e ` a f+1, ce compteur est incr ement e ` a chaque
incoh erence de digest. Il sera egal au maximun ` a 2f+1.En r esum e ce compteur
est egal au nombre de r eplication ` a sch eduler.
numReplicationLaunched : initialis e ` a 0, ce compteur est incr ement e d` es quune
r eplication a et e attribu ee sur une machine.
`
A linverse, il est d ecr ement e d` es
quun timer se d eclenche. Lorsquil est egal ` a numReplicationToLaunch, le bool een
shoulReply passe ` a faux et indique que la t ache nest plus ` a r epliquer.
numReplicationFinished : initialis e ` a 0, ce compteur est incr ement e lorsque
le BFTmanager recoit les digests dune r eplication, ceci indique donc quune
r eplication vient de se terminer. Lorsque sa valeur est egale ` a numReplicationTo-
Launch, ceci indique que toutes les r eplications se sont termin ees. Il est possible
ainsi de d ecider quels sont les digests qui poss` edent la majorit e pour valider le
r esultat dune t ache.
Tout acc` es sur ces attributs se fait de mani` ere synchronis ee pour eviter les probl` emes
de concurence.
Dans le code initial dHadoop, d` es quune r eplication se terminait avec succ` es, les
autres tentatives etaient tu ees. Pour la gestion des pannes byzantines, il est indispen-
sable de bloquer ce m ecanisme, car il faut en effet attendre que toutes les r eplications
dune t ache se terminent pour faire une election. Il a fallu donc ajouter un nouvel etat
de t ache dans la classe TaskStatus ainsi que dans TaskCompletionEvent. Ce nouvel
etat que nous avons appel e DIGEST SENT, indique que la t ache vient denvoyer ses
digests au BFTmanager, et est en attente de pouvoir se terminer.
Cas des MAPS :
An de pr eserver le r esultat de chaque r eplication jusqu` a la n du MapReduce, les
maps sont mis ` a SUCCEEDED localement sur chaque Tasktracker mais ne sont pas
toujours termin es aux yeux du JobTracker. Lors du passage dans la m ethode update-
TaskStatus, le statut de la t ache sera ` a SUCEEDED mais ne sera pas mis a jour sur le
Jobtracker. Le code ci-dessous permet cela.
1 if(status.getIsMap()){
2 if( !tip.isJobCleanupTask() && !tip.isJobSetupTask() && !
tip.isCleanupAttempt(status.getTaskID())){
3
4 if( ((finishedReduceTasks + failedReduceTIPs) !=
numReduceTasks)
19
5 && this.bftmanager.digestReceived(taskid,status.
getIsMap())
6 && status.getRunState() != TaskStatus.State.
DIGEST_SENT){
7 return;
8 }
9 }
10 }
Listing 9 M ethode updateTaskStatus de JobInprogress : blocage de la terminaison
des maps
1 if(state == TaskStatus.State.DIGEST_SENT){
2 System.out.println("PASSAGE dans DIGEST_SENT pour "+
taskid);
3 taskEvent = new TaskCompletionEvent(
4 taskCompletionEventTracker,
5 taskid,
6 tip.idWithinJob(),
7 status.getIsMap() &&
8 !tip.isJobCleanupTask() &&
9 !tip.isJobSetupTask(),
10 TaskCompletionEvent.Status.DIGEST_SENT,
11 httpTaskLogLocation
12 );
13 if(status.getIsMap())
14 finishedMapTasks++;
15
16 }
Listing 10 M ethode updateTaskStatus de JobInprogress : notication de la
localisation du r esultat dune t ache map pour les reduces
D es quune t ache de map passe ` a DIGEST SENT avant de passer ` a SUCCEE-
DED, un ev enement TaskCompletionEvent est cr e e sur le matre indiquant aux re-
duces (thread interne GetMapsEventsThread du ReduceCopier) la localisation du -
chier contenant le r esultat du map. Les maps se terminent d esormais apr` es les reduces
lors de la t ache de cleanup du JOB. De ce fait il nexiste plus de maps qui sont d eclar ees
SUCCEEDED dans le compte rendu nal du map-reduce. Elles sont tu ees par la t ache
de cleanup du Job. Or cette t ache de cleanup ne pouvait se d eclencher que si toutes
les maps et les reduces etaient d eclar ees termin ees. Il a fallu donc contourner ceci en
supprimant la prise en compte de la nalit e des maps, lors du lancement du cleanup.
1 // Check if all maps and reducers have finished.
2 boolean launchCleanupTask =
3 ((finishedMapTasks + failedMapTIPs) == (numMapTasks));
4 /
**
Modification 9/07/2010 : task replication
**
/
5 launchCleanupTask=true;
6 /
**********************************************
/
7 if (launchCleanupTask) {
8 launchCleanupTask =
9 ((finishedReduceTasks + failedReduceTIPs) ==
numReduceTasks);
10 }
20
11 return launchCleanupTask;
Listing 11 M ethode canLaunchJobCleanup de JobInprogress : non-prise en compte
de la nalit e des maps
Cas des REDUCES :
Les reduces sont lanc ees lorsque toute les t aches de maps ont termin e. Lorsque quelles
auront ni leur traitement, elles passeront ` a l etat DIGEST SENT puis ` a l etat COM-
MIT PENDING. Nous avons rajout e un m ecanisme sur lautorisation de committer.
Initialement il sufsait d etre la premi` ere r eplication ` a faire la demande de commit.
Avec notre code il faut bien s ur que les autres r eplications soient termin ees et avoir un
digest egal ` a celui qui a et e elu. Il a fallu modier le code de la m ethode updateTaskS-
tatus.
1
2 if (!wasComplete /
***
Modification
3 INITIALEMENT && !wasPending
*
/
4 ) {
5 /
**
Modification 9/07/2010 : task replication
**
/
6 //check if we have received all digests and if the
digest of tip is correct
7 if(!this.bftmanager.canCommit(taskid, status.getIsMap
())){
8
9 return;
10 }
11 System.out.println(""+taskid+" can commit");
12 /
**********************************************
/
13 tip.doCommit(taskid);
14 }
15 return;
Listing 12 M ethode updateTaskStatus de JobInprogress : contr ole du commit
La m ethode canCommit du BFTmanager r epond faux si le digest nal na pas en-
core et e calcul e (i.e. toute les r eplications nont pas encore envoy e leurs digests), ou
bien si le digest de la tentative qui fait la demande de commit ne correspond pas au
digest calcul e. Cette m ethode r epond vrai dans les autres cas. Lappel ` a tip.doCommit
reprend ensuite le m ecanisme initial qui etait dautoriser uniquement la premi` ere de-
mande. Apr` es toute demande qui a et e accept ee suit la copie des r esultats sur le HDFS.
Les reduces passeront comme pr evu initialement ` a COMMIT PENDING avant de pou-
voir transf erer leur r esultat sur le HDFS.
Ordonnancement des t aches :
Contrairement aux pannes franches nous privil` egeons maintenant la r eplication au lan-
cement de nouvelle t aches. Les m ethodes ndNewMapTask et ndNewReduceTask ont
et e modi ees en cons equence. Au d ebut de ces fonctions, la fonction getIdMapForRe-
plication (ou getIdReduceForReplication) de la classe BFTmanager retourne un iden-
tiant de t ache ` a r epliquer. Si ces fonctions retourne -1, cela signie quaucune t ache
d ej` a lanc ee nest ` a r epliquer (getIdReduceForReplication peut renvoyer -2 si toutes les
21
t aches de map nont pas termin e). Ainsi le code initial s ex ecute pour lancer une nou-
velle t ache. Lorsquune nouvelle t ache est lanc ee, la m ethode taskLaunched de BFT-
manager est appel ee pour indiquer quune nouvelle t ache a et e lanc ee (mise ` a jour des
compteurs et du bool een shouldReply de BFTinfoTask).
1
2 /
**
Modification 9/07/2010 : task replication
**
/
3 //first, check if exists reduces that should be replicated.
This implies that reduces tasks are already launched
4 // in the cluster
5 int idtaskforreplic=this.bftmanager.
getIdReduceForReplication(tts);
6 if(idtaskforreplic ==-2)//block reduce task if all map
tasks are not finished
7 return -1;
8 if(idtaskforreplic!=-1){
9 return idtaskforreplic;
10 }
11 /
**********************************************
/
Listing 13 M ethode ndNewReduceTask de JobInprogress : Sch eduler les
r eplications
1 tip = findTaskFromList(nonRunningReduces, tts, numUniqueHosts,
false);
2 if (tip != null) {
3 scheduleReduce(tip);
4 /
**
Modification 9/07/2010 : task replication
**
/
5 //notify to bftmanager that a map has been scheduled for
the first time
6 this.bftmanager.taskLaunched(tip.getIdWithinJob(), tts,
false);
7 /
**********************************************
/
8 return tip.getIdWithinJob();
9 }
Listing 14 M ethode ndNewReduceTask de JobInprogress :Lancer la premi` ere
tentative
6.4.4 Au niveau des machines esclaves
Etant donn e quun nouvel etat DIGEST SENT a et e ajout e, il etait indispensable
de changer le code du Tasktracker ainsi que linterface RPC TaskUmbilicalProtocol
qui permet la communication entre les t aches et le Tasktracker. Nous avons rajout e la
m ethode digestSent qui permet de notier au Tasktracker que le child a bien envoy e ses
digests au JobTracker. La m ethode transmitHeartbeat a et e l eg erement modi ee apr es
la r eception du heartbeatResponse. Si l etat est ` a DIGEST SENT il ne faut pas enlever
de la liste runningTask la t ache en question.
1
2 heartbeatResponseId = heartbeatResponse.getResponseId();
3
4 synchronized (this) {
22
5 for (TaskStatus taskStatus : status.getTaskReports()) {
6 if (taskStatus.getRunState() != TaskStatus.State.
RUNNING &&
7 taskStatus.getRunState() != TaskStatus.State.
UNASSIGNED &&
8 /
***
Modification 9/07/2010 : task replication
***
*
/
9 taskStatus.getRunState() != TaskStatus.State.
DIGEST_SENT &&
10 /
*************************************************
*
/
11 taskStatus.getRunState() != TaskStatus.State.
COMMIT_PENDING &&
12 !taskStatus.inTaskCleanupPhase()) {
13 if (taskStatus.getIsMap()) {
14 mapTotal--;
15 } else {
16 reduceTotal--;
17 }
18 try {
19 myInstrumentation.completeTask(taskStatus.getTaskID
());
20 } catch (MetricsException me) {
21 LOG.warn("Caught: " + StringUtils.
stringifyException(me));
22 }
23 runningTasks.remove(taskStatus.getTaskID());
24 }
25 }
Listing 15 M ethode transmitHeartbeat de TaskTracker : Ne pas enlever de lensemble
des t aches en cours dex ecution celles qui sont DIGEST SENT
La classe abstraite Task qui mod elise une t ache ex ecutable sur un noeud esclave a
et e modi ee : un attribut entier qui stocke le port sur lequel ecoute le BFTmanager du
Job correspondant. Deux m ethodes ont et e ajout ees : la m ethode sendDigestToBFTma-
nager et la m ethode abstraite getDigest().
Les sous-classes MapTask et ReduceTask ont par cons equent et e modi ees. Lappel
` a la m ethode sendDigestToBFTmanager() a et e ajout ee ` a la n de chaque m ethode run
de ces classes. Il est a noter quun sleep a et e ajout e pour le cas des maps. En effet
nous endormons le thread un temps sup erieur ` a lintervalle de hearbeat (qui est par
d efaut de trois secondes) pour que le statut DIGEST SENT soit envoy e au JobTracker.
Si ce sleep etait absent, l etat passerai de DIGEST SENT ` a SUCCEEDED sans avoir
le temps de le transmettre via le heartbeat. Ce concept serait ` a am eliorer ` a terme.Une
solution qui pourrait eviter cela serait de modier la classe TaskTracker. Du code a d ej` a
et e ecrit pour cette solution mais na pas et e test e. Il est actuellement comment e dans
la classe Tasktracker entre des commentaires signal es par des etoiles et portant le tag
IMPROVE END MAP.
Les m ethodes write et readFields ont d u etre modi ees car nous avons ajout e des
attributs qui sont initialis es sur le Jobtracker et qui doivent transiter sur le r eseau tels
que le num ero de port du BFTmanager ou bien les digests des maps pour les reduces.
1 if (useNewApi) {
2 runNewMapper(job, split, umbilical, reporter);
23
3 } else {
4 runOldMapper(job, split, umbilical, reporter);
5 }
6 /
**
Modification 9/07/2010 : task replication
**
/
7 if(!this.isJobCleanupTask() && !this.isJobSetupTask() && !
this.isTaskCleanupTask()) {
8 sendDigestToBFTmanager(umbilical);
9 Thread.sleep(4000);
10 }
11 /
**********************************************
/
12 done(umbilical, reporter);
13 }
Listing 16 M ethode run de MapTask : envoi des digests
MapTask : Pour calculer les digests des diff erentes partitions, il a fallu ins erer du
code dans la m ethode mergeParts() de la classe interne MapOutput de MapTask.
Cette m ethode prend trois cas de gure pour g en erer le chier de sortie de map.
En effet le traitement est diff erent en fonction du nombre de chier de spill qui
ont et e cr e es pendant l ex ecution du map. Nous rappelons quun chier de spill
est un chier qui a et e cr e e par la t ache ` a chaque fois que son buffer a d epass e
un certain seuil de sa capacit e. Nous avons donc ins er e notre m ethode collectDi-
gest(Path indexFile, Path outputFile) trois fois. Les partitions sont cr e ees de la
mani` ere suivante. Il y a deux chiers : un chier de sortie contenant le r esultat et
un chier dindex. Ce chier dindex nest compos e que de long Java cod e sur
64 bits. Pour une partition, il y a trois long, le premier pour indiquer loffset dans
le chier du d ebut de la partition, le deuxi` eme pour indiquer la taille en octets
de la partition (d eplacement ` a partir de loffset), et le troisi` eme pour indiquer la
taille compress ee de la partition. Dans le chier dindex si nous devons diviser
le chier en p partitions nous avons donc 3p longs dans le chier dindex.
FIGURE 9 M ecanisme du chier dindex
Remarque : Entre chaque partition dans le chier nal, nous avons remarqu e
quil y avait un en-t ete de 4 octets entre chaque partition, do` u la pr esence de
la variable locale byte buftmp[] dans collectDigests. La m ethode getDigest de
MapTask renvoie juste un attribut propre ` a cette classe et qui est initialis e par la
m ethode collectDigest.
24
ReduceTask : Le ReduceCopier a bien entendu et e modi e. Premi` ere modica-
tion : Prise en compte de l etat DIGEST SENT dans le GetMapEventsThread. Le
traitement ` a faire pour cet etat est exactement le m eme que pour l etat SUCCEE-
DED. Ceci permet de t el echarger les r esultats de plusieurs r eplications dune
m eme map, ce qui etait impossible initialement.
Deuxi` eme modication : le contr ole des digests lors de la r ecup eration dune
partition : m ethode copyOutput du thread MapOutputCopier.
Un test au d ebut de cette fonction a et e ajout e. Il permet d eviter la copie si toutes
les sortie des maps ont et e recues et d eclar ees valides.
1 // check if we still need to copy the output from this
location
2 /
****
Modification 9/07/2010 : task replication
*******
/
3 boolean allreceived;
4 synchronized (digestsReceived) {
5 allreceived=(NumMapReceived==digestsReceived.
length);
6 }
7 if ((copiedMapOutputs.contains(loc.getTaskId()) ||
8 obsoleteMapIds.contains(loc.
getTaskAttemptId()))
9 && allreceived ) {
10 return CopyResult.OBSOLETE;
11 }
12 /
****************************************
/
13
14
15 /
***
16 OLD INSTRUCTIONS
17
18 if (copiedMapOutputs.contains(loc.getTaskId()) ||
19 obsoleteMapIds.contains(loc.getTaskAttemptId())
20 ) {
21 return CopyResult.OBSOLETE;
22 }
23
**
/
Listing 17 M ethode copyOutput de ReduceTask.ReduceCopier.MapOutputCopier :
Rajout du test tout recu
1 /
**********
Modification 9/07/2010 : task replication
*************
/
2
3
4
5 try {
6
7 int MapidInJob=loc.taskId.getId();
8
9 String StringDigest ="";
10 if(mapOutput.inMemory){
11 StringDigest = DigestTool.getDigest(mapOutput.
data);
25
12 }else{
13 StringDigest = DigestTool.getDigest(localFileSys,
mapOutput.file);
14 }
15
16 if(!ReduceTask.this.Mapdigests[MapidInJob].equals(
StringDigest)){
17 LOG.info("Byzantine fault suspected from map "+loc.
taskAttemptId+
18 StringDigest+" not equals "+ReduceTask.this.
Mapdigests[MapidInJob]);
19 return CopyResult.OBSOLETE;
20 }else{
21 boolean neverseen;
22 synchronized (digestsReceived) {
23 neverseen=digestsReceived[MapidInJob].equals("")
;
24 if( neverseen){
25 digestsReceived[MapidInJob]=StringDigest;
26 NumMapReceived++;
27 }
28 }
29 if(!neverseen)
30 return CopyResult.OBSOLETE;
31 }
32 } catch (NoSuchAlgorithmException e) {
33 e.printStackTrace();
34 }
35
36
37
38
39 /
************************************
/
Listing 18 M ethode copyOutput de ReduceTask.ReduceCopier.MapOutputCopier :
Contr ole de la coh erence des digests
La n des reduces est identique ` a celle des maps sauf que le calcul du digest se
fait directement sur des chiers pr esents sur le HDFS dans le r epertoire tempo-
raire. Les reduces qui ne commiteront pas seront tu ees.
26
7 Perspectives
7.1 Injections de pannes
7.1.1 Th eorie
Linjection de pannes na pas et e impl ement ee mais lid ee est la suivante :
Pouvoir choisir d` es le d epart une ou plusieurs t ache(s) fautive(s). On peut vouloir choi-
sir dinjecter des pannes au niveau des t aches de map ou de reduce.
Une t ache d eclar ee comme fautive va,par exemple, au moment du calcul de l ecriture
de sa sortie faire un d ecalage de bit et donc renvoyer un r esultat incoh erent qui sera
percu au moment de la comparaison des digests. Cest une id ee de panne mais il pour-
rait y en avoir dautres (erreur sur le calcul du digest, etc)
7.1.2 Suggestion dimpl ementation
Une mani` ere assez simple pour choisir le num ero de la t ache d efaillante serait duti-
liser les chiers de conguration. En effet dans le chier $HADOOP HOME/conf/mapred-
site.xml on peut d enir certaines sp ecicit es du MapReduce : nombre de t aches de re-
duce, nombre de t aches max,... On pourrait donc se servir de ce m eme chier et cr eer
des nouvelles properties : num ero des t aches de map ou de reduce fautives. En
d enissant par exemple la property suivante :
<property>
<name>mapred.reduce.taskID BF</name>
<value>5</value>
</property>
On indique ici que la t ache de reduce num ero 5 sera fautive.
Dans le code Java on peut r ecuperer ces informations de la mani` ere suivante : int nu-
mID BF=conf.getInt( mapred.reduce.taskID BF ,1) ce qui signie que si la valeur
nest pas d enie elle est par d efaut ` a 1.
On doit aussi choisir parmis les r eplications dune t ache, laquelle va commettre la
panne. On peut le d ecider avec une propri et e comme pr ecedemment ou arbitrairement
(toujours la premi` ere, la deuxi` eme, ...).
Au moment de l ecriture ou lors du calcul du digest (selon le type de pannes choi-
sies) la t ache doit g en erer une erreur si son taskID et son taskAttemptID correspondent
` a ceux indiqu es dans les congurations.
27
8 Annexes
8.1 Les schedulers
8.1.1 JobQueueTaskScheduler
Ce scheduler va assigner des t aches selon une politique FIFO avec priorit e. Il utilise
la m ethode suivante :
public synchronized List <Task> assignTasks(TaskTrackerStatus taskTracker)
Lors dun heartbeat provenant dun taskTracker, la m ethode assignTasks du scheduler
va etre appel ee pour savoir combien de t aches vont pouvoir etre attribu ees au taskTra-
cker ` a lorigine du heartBeat.
Cette m ethode suit la d emarche (politique) suivante :
Alloue dans un premier temps les t aches de map puis les t aches de reduce pour
lensemble des jobs.
Les jobs sont trait es par ordre darriv ee
Un job est trait e si et seulement si son pr edecesseur la et e.
On assigne des t aches ` a un taskTracker seulement si ce dernier en a la capacit e
et sil na pas atteint le nombre max de t aches quil doit g erer.
Cependant si le cluster tout entier tend ` a etre trop charg e (par exemple : plus assez
de place pour cr eer des r eplications d ues ` a lex ecution sp eculative), seulement les
t aches provenant de jobs ` a haute priorit e seront ordonnanc ees.
Une s erie de calculs va etre effectu ee pour calculer le nombre de slots libres sur
le taskTracker, donc combien de t aches il va pouvoir lui assigner. Une synth` ese de ces
calculs est pr esent ee ci-dessous pour lattribution des t aches de map.
Voici les diff erents param etres des calcul :
nbJob : le nombre total de jobs en cours sur le cluster.
nbMapDesired(i) : le nombre de maps d eni ` a la cr eation du job i (cest une
constante).
nbMapFinished(i) : le nombre de maps, pour le job i, qui se sont bien termin ees
( etat SUCCEDED).
remainingMapLoad : pour tous les jobs, le nombre de t aches de map encore en
cours (running + pending) sur le cluster.
remainingMapLoad =
nbJob

i=0
(nbMapDesired(i) nbMapFinished(i))
clusterMapCapacity : le nombre max de t aches de map qui peuvent etre lanc ees
sur tout le cluster. Ce param etre d epend de la capacit e de tous les taskTrackers et
est recalcul e dynamiquement lorsquun taskTracker red emarre ou devient black-
listed.
mapLoadFactor : facteur repr esentant le taux de chargement du cluster (pour les
t aches de map).
28
mapLoadFactor =
remainingMapLoad
clusterMapCapacity
trackerMapCapacity : le nombre maximal de t aches de map que peut g erer un
taskTacker (param etre d eni dans les congurations du syst` eme sous le nom :
mapred.tasktracker.map.tasks.maximum).
trackerCurrentMapCapacity : capacit e courante du taskTracker en fonction de la
charge du cluster et de sa capacit e d enie dans les congurations (trackerMap-
Capacity). Si le cluster est charg e ` a 50% on ne va pas charger ` a plus de 50% le
taskTracker.
trackerCurrentMapCapacity = min(mapLoadFactor trackerMapCapacity ,
maxMapTasks)
trackerRunningMaps : le nombre de t aches de map qui sont actuellement en
cours sur le taskTracker
availableMapSlots : le nombre de slots libres sur le taskTracker pour des t aches
de map. Si la capacit e du taskTracker (trackerMapCapacity) a et e d enie ` a 10 et
que la charge du cluster est de 50%, alors la capacit e courante du taskTracker est
de 5. Si il y avait d ej` a 2 t aches assign ees au taskTracker alors il a (5-2) = 3 slots
disponibles.
availableMapSlots = trackerCurrentMapCapacity trackerRunningMaps
Si le taskTracker a des slots libres, on va pouvoir lui attribuer des t aches de map
(autant que de slots libres). Cest donc une liste de t aches ` a lancer qui va etre transmise
au taskTracker via la r eponse du heartBeat.
M emes calculs pour les reduces ` a une diff erence pr` es : au plus 1 t ache de reduce peut
etre assign ee.
29
8.1.2 LimitTaskPerJobTaskScheduler
Ce scheduler a pour r ole de limiter le nombre de t aches en cours pour un job au
moyen du param` etre de conguration :
mapred.jobtracker.scheduler.maxRunningTasksPerJob.
Comme pr ecedemment la m ethode assignTask de ce scheduler va etre appel e par un
taskTracker lors dun heartbeat et va renvoyer un liste de t aches de map et de reduce
que devra g erer le taskTracker.
Au sein de la m ethode assignTask, une autre m ethode va etre appel ee (getMaxMapAn-
dReduceLoad) pour calculer (de la m eme mani` ere que dans le scheduler pr ecedent) le
nombre de slots libres pour des t aches de map et de reduce (elle renvoie un tableau de
deux entiers correspondant ` a ces deux nombres de slots). Quelques diff erences sont ` a
noter :
Il est possible que plusieurs t aches de reduce soient renvoy ees ` a un taskTracker
(dans une m eme r eponse de hearbeat).
Ce scheduler ne prend pas en compte les eventuelles pannes des taskTracker : il
ny a pas de mise ` a jour de la capacit e du cluster ne fonction des taskTracker (ne
tient pas compte de la blacklist).
Comme pour le premier scheduler nous allons pr esenter les diff erents calculs effectu es
dans la m ethode getMaxMapAndReduceLoad pour savoir le nombre de slots libres pour
des t aches de map (le principe etant le m eme pour les t aches de reduce).
nbJob : le nombre total de jobs en cours sur le cluster.
nbMapDesired(i) : le nombre de maps d eni ` a la cr eation du job i (cest une
constante).
nbMapFinished(i) : le nombre de maps, pour le job i, qui se sont bien termin ees
( etat SUCCEDED)
neededMaps : pour tous les jobs, le nombre de t aches de map encore en cours
(running + pending) sur le cluster.
neededMaps =
nbJob

i=0
(nbMapDesired(i) nbMapFinished(i))
numTaskTrackers : le nombre de taskTrackers (tous m eme ceux qui sont balck-
listed) sur tout le cluster.
mapLoadFactor : facteur repr esentant le taux de chargement du cluster (pour les
t aches de map).
mapLoadFactor = min(maxMapTasks,

neededMaps
numTaskTrackers

)
Cest ce param` etre (mapLoadFactor) qui va etre renvoy e (de m eme pour les re-
duces).
Ensuite les t aches de map et de reduce sont allou ees en fonction de plusieurs
param` etres :
30
mapLoadFactor
reduceLoadFactor
maxTasksPerJob correspondant au param` etre de conguration :
mapred.jobtracker.scheduler.maxRunningTasksPerJob
Il ne faut jamais exc eder le nombre de t aches par job ainsi que la charge des
taskTrackers.
31
8.2 M etriques suppl ementaires
0
100
200
300
400
500
600
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
T
a
i
l
l
e

m
o
y
e
n
n
e

d

u
n

m
e
s
s
a
g
e

d
e

t
y
p
e

m
a
p
r
e
d

(
o
c
t
e
t
s
)
.
Taille moyenne dun message de type mapred en fonction de la taille dun split
Taille des donnees en entree: 989118464 octets
split: 4 M
236 maps
split: 8 M
118 maps
split: 12 M
79 maps
split: 16 M
59 maps
split: 24 M
40 maps
split: 32 M
30 maps
split: 48 M
20 maps
split: 64 M
15 maps
FIGURE 10 Taille moyenne dun message de type mapred
32
0
100
200
300
400
500
600
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
T
a
i
l
l
e

m
o
y
e
n
n
e

d

u
n

m
e
s
s
a
g
e

d
e

t
y
p
e

h
d
f
s

(
o
c
t
e
t
s
)
.
Taille moyenne dun message de type hdfs en fonction de la taille dun split
Taille des donnees en entree: 989118464 octets
split: 4 M
236 maps
split: 8 M
118 maps
split: 12 M
79 maps
split: 16 M
59 maps
split: 24 M
40 maps
split: 32 M
30 maps
split: 48 M
20 maps
split: 64 M
15 maps
FIGURE 11 Taille moyenne dun message de type hdfs
0
20
40
60
80
100
120
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
T
a
i
l
l
e

m
o
y
e
n
n
e

d

u
n

m
e
s
s
a
g
e

d
e

t
y
p
e

s
e
r
v
i
c
e

(
o
c
t
e
t
s
)
.
Taille moyenne dun message de type service en fonction de la taille dun split
Taille des donnees en entree: 989118464 octets
split: 4 M
236 maps
split: 8 M
118 maps
split: 12 M
79 maps
split: 16 M
59 maps
split: 24 M
40 maps
split: 32 M
30 maps
split: 48 M
20 maps
split: 64 M
15 maps
FIGURE 12 Taille moyenne dun message de type service
33
0
50
100
150
200
250
300
350
400
450
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
A
R
A
S
S
R
A
S
A
R
S
S
S
R
S
S
T
a
i
l
l
e

m
o
y
e
n
n
e

d

u
n

m
e
s
s
a
g
e

d
e

t
y
p
e

a
u
t
r
e

(
o
c
t
e
t
s
)
.
Taille moyenne dun message de type autre en fonction de la taille dun split
Taille des donnees en entree: 989118464 octets
split: 4 M
236 maps
split: 8 M
118 maps
split: 12 M
79 maps
split: 16 M
59 maps
split: 24 M
40 maps
split: 32 M
30 maps
split: 48 M
20 maps
split: 64 M
15 maps
FIGURE 13 Taille moyenne dun message de type autre
0
500000
1e+06
1.5e+06
2e+06
2.5e+06
3e+06
3.5e+06
4e+06
8 12 16 24 32 48 64
t
a
i
l
l
e

t
o
t
a
l
e

d
e
s

m
e
s
s
a
g
e
s
taille du split Mo
Ecart type taille (totale) des messages
Legend
ARAS
SRAS
SRAS
SRAS
FIGURE 14 Ecart-type taille des messages
34
0
1000
2000
3000
4000
5000
6000
7000
8000
8 12 16 24 32 48 64
n
o
m
b
r
e

d
e

m
e
s
s
a
g
e
s
taille du split Mo
Ecart type nombre de messages
Legend
ARAS
SRAS
SRAS
SRAS
FIGURE 15 Ecart-type nombres de messages
0
20000
40000
60000
80000
100000
120000
140000
160000
180000
200000
8 12 16 24 32 48 64
l
a
t
e
n
c
e
taille du split Mo
Ecart type latence du MapReduce
Legend
ARAS
SRAS
SRAS
SRAS
FIGURE 16 Ecart-type latence
35
0
5000
10000
15000
20000
25000
30000
35000
8 12 16 24 32 48 64
l
a
t
e
n
c
e
taille du split Mo
Ecart type latence Map
Legend
ARAS
SRAS
SRAS
SRAS
FIGURE 17 Ecart-type latence map
0
10000
20000
30000
40000
50000
60000
8 12 16 24 32 48 64
l
a
t
e
n
c
e
taille du split Mo
Ecart type latence Shuffle
Legend
ARAS
SRAS
SRAS
SRAS
FIGURE 18 Ecart-type latence reduce en phase Shufe
36
0
1000
2000
3000
4000
5000
6000
7000
8 12 16 24 32 48 64
l
a
t
e
n
c
e
taille du split Mo
Ecart type latence Sort
Legend
ARAS
SRAS
SRAS
SRAS
FIGURE 19 Ecart-type latence reduce en phase Sort
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
8 12 16 24 32 48 64
l
a
t
e
n
c
e
taille du split Mo
Ecart type latence Reduce
Legend
ARAS
SRAS
SRAS
SRAS
FIGURE 20 Ecart-type latence reduce en phase Reduce
37