HDFS - interaction entre namenode et datanodes

Hadoop et MapReduce en Java

Ce site ne sera plus alimenté de contenu après août 2014. Tous les nouveaux articles seront redigés pour www.waitingforcode.com
Dans l'introduction à l'Hadoop et MapReduce on a brièvement présenté le concept de Hadoop Distributed Filesystem. Maintenant on va le présenter un peu plus.

Au tout début de l'article on verra les concepts déjà introduits : namenode et datanode. On montrera également un composant important, secondary namenode. Ensuite on montrera comment se présentent les opérations de lecture et d'écriture des fichiers dans HDFS.

Qu'est-ce que c'est namenode ?
Dans l'introduction on a brièvement dit que namenode est un peu le shérif du système qui maintient l'ordre dans les méta-données et distribue les tâches. Il stocke l'emplacement de tous les fichiers dans le système de fichiers local. Le client communique donc avec lui à chaque fois quand il demande un fichier à travers des opérations de lecture et d'écriture.

Chaque namenode est composé de parties suivantes :

- VERSION : le fichier qui contient les informations sur le namenode. On y retrouve : l'identifiant pour le système de fichiers, le temps de création, le type de stockage, la version de la structure des données HDFS.

- edits : le fichier très important qui regroupe toutes les opérations effectuées dans le système. Chaque fois quand une action d'écriture est effectuée, elle est d'abord placée dans ce fichier de logs. Ce n'est que par la suite que la mémoire est notifiée de cette nouvelle opération. Les données stockées dans la mémoire sont utilisées pour les opérations de la lecture. Le fichier edits sert un peu comme le backup qui doit permettre à reconstruire l'état de fichiers si le système plante.

- fsimage : c'est un fichier binaire utilisé comme un point de contrôle pour les méta-données. Il joue aussi un rôle important dans la récupération des données dans le cas d'une défaillance de système. Mais on verra ce point de plus près dans un des articles suivants.

- fstime : il est aussi un fichier binaire. Il stocke les inforamtions sur la dernière opération de contrôle sur les données.

Quand namenode démarré, le safe mode est activé. Cela veut dire que pendant un certain moment (même long si beaucoup de données sont à traiter)les fichiers ne peuvent être accédés qu'à la lecture. C'est parce que pendant le démarrage, namenode charge ses fichiers fsimage et edits. Ensuite il attend que datanodes le tiennent informé quant à l'état des blocks stockés. Une fois quand un certain pourcentage des datanodes a rapporté les informations nécessaires, le safe mode est relaché et le système devient à nouveau disponibles pour les requêtes d'écriture. Il faut prendre ce point en considération pour éviter des débugages inutiles.

Qu'est-ce que c'est datanode ?
On a dit que datanode est un worker. Cela veut dire qu'il effectue les opérations demandées par namenode. Mais à part cela, c'est bien datanode qui stocke et retrouve les blocks demandés par namenode. Egalement c'est lui qui apporte au namenode une liste des blocks stockés. Ce rapport est envoyé périodiquement.

En ce qui concerne la structure des répertoires datanode, elle possède aussi un fichier VERSION. A part les mêmes informations que celles stockées dans ce fichier dans namenode, il contient un champ storageID. Cet identifiant permet au namenode d'identifier le datanode. En plus de cela, les fichiers des blocks y sont stockés (noms constitués d'un préfixe blk_ et d'un suffixe sous forme d'identifiant du block) :

- le premier fichier est un fichier sans extensions qui représente le block en lui-même (par exemple : blk_1)

- le second fichier est un fichier des méta-données du block

Qu'est-ce que c'est secondary namenode ?
Ce namenode secondaire est important dans le processus de récupération du système au cas de plantage du namenode principal. Il ne s'agit donc pas d'un remplacant du namenode primaire.

Secondary namenode vérifie périodiquement l'état du namenode principal. A chaque vérification il copie les fichiers de backup : edits et fsimage. Sa structure des dossiers est donc quasi identique que celle du namenode principal. La seule différence se trouve dans le sous-répertoire previous.checkpoint. C'est là où secondary namenode place le dernier état du namenode principal récupéré.

Cependant, les informations collectées ne doivent pas être forcément à jour. Secondary namenode n'est pas une réplication du namenode principal et il peut contenir des données périmées suite à des opérations effectuées après la création de son point de contrôle. L'intervalle de création du checkpoint (point de contrôle) peut être précisé dans la propriété de configuration fs.checkpoint.period.

Comment namenode et datanode marchent ensemble ?
La lecture d'un fichier placé dans le système HDFS se base sur plusieurs étapes composées d'interactions entre namenode et datanode. Les voici :

  1. Le client se connecte à l'HDFS. Le système demande alors namenode.

  2. Namenode répond et indique les emplacements des blocks composant le fichier recherché par le client. Il retourne les adreses les plus proches de la machine du cluster qui effectue l'appel.

  3. Datanodes choisis retournent ensuite les données au client. Une fois le retour des données terminé, la connexion du client est fermée.



L'écriture est également fondée sur les interactions entre namenode et datanodes. Elle se schématise par ces points :

  1. Le client demande la création d'un nouveau fichier. Le système informe alors namenode de cette demande. Namenode crée le nouveau fichier sans aucun block associé (donc sans datanodes).

  2. Si les données à écrire sont correctes (fichier n'existe pas et le client a les droits d'écrire dans le système), le fichier est divisé en plusieurs paquets. Ils sont ensuite placés dans la queue interne appelée data queue (queue des données).

  3. L'écriture se fait ensuite par paquets, dans les datanodes. Chaque paquet est répliqué dans plusieurs datanodes (nombre déterminé par l'entrée de configuration dfs.replication.min). Une fois la réplication terminée, le paquet est alors supprimé d'une autre queue, acknowledged queue (la queue de reconnaissance).

  4. Quand tous les blocks sont écrits, datanodes envoient les informations avec les emplacements de ces blocks au namenode. Grâce à cette information, namenode pourra à l'avenir retrouver les fichiers demandés par le client.



Dans cet article on a pu voir comment se comportent les composants de base de l'HDFS. Les deux sont très liés et permettent aussi bien de lire qu'à écrire les fichiers demandés par le client. Il faut donc veiller à ce qu'ils soient toujours fonctionnels.
Bartosz KONIECZNY 08-09-2013 15:57 Hadoop
Moi

Développeur d'applications Internet et journaliste passionné par l'adjectif français. Un aigle polonais orienté vers la progression, volant très haut et écoutant du zouk après les matches du foot français.

Vous appréciez mon travail ?

Pour contribuer au développement de ce site, ou pour remercier pour des articles rédigés, vous pouvez faire un don.

Un conseil Android

Afficher les logs sous Android.

Les logs d'Android s'avèrent très utiles lors du développement de notre application. La commande suivante permet de les afficher rapidement (exemple issu du Cygwin) : cd /cygdrive/c/Program\ Files\ \(x86\)/Android/android-sdk/platform-tools/ ./adb.exe logcat