Hadoop pour les DBAs (4/13) : Introduction à HDFS

HDFS est le système de fichiers distribué de Hadoop. Sa disponibilité en cas de panne est assurée par des mécanismes de réplication et de bascules automatiques des processus et connexions. Ce 4e article consacré à Hadoop pour les DBAs décrit plusieurs concepts de fonctionnement de HDFS. C’est, soit dit en passant, probablement la partie la plus amusante pour les DBAs. C’est aussi, très certainement, la partie la plus proche de ce que vous connaissez par ailleurs. HDFS vient avec plusieurs dizaines de fonctionnalités auxquelles s’intéresser. Cet article se concentre sur quelques concepts et fonctionnements internes. Il démontre également comment sont assurés la disponibilité des DataNodes et NameNodes. Il est constité de 3 sections distinctes : o A la découverte de structures de HDFS; o Réplication HDFS et perte d’un DataNode; o Quorum Journal Manager et perte d’un NameNode.
HDFS est un système de fichiers et ressemble, dans une certaine mesure, aux outils que vous manipulez. Il fournit des paramètres pour bypasser les caches ou forcer les données en cache. Vous pouvez impacter la répartition des blocs, y compris géographiquement. Vous pouvez également modifier le niveau de réplication. HDFS est construit pour alimenter des processus qui fonctionnent en parallèle. Il peut être accédé de différentes manière, y compris en ligne de commande, en Java, en C ou via une API REST. Il offre des fonctionnalités avancées comme les snapshots ou des mises à jour sans indisponibilité. Vous avez la possibilité de déplacer les données dynamiquement mais aussi d’étendre ou de réduire un cluster. HDFS est bluffant !
D’un autre côté, vous ne connaissez surement rien comme HDFS. C’est peut-être parce qu’il n’existe que peu de système de fichiers distribué. En plus, il est écrit en Java et conçu pour stocker les blocs de fichiers sur des milliers de serveurs. Il est construit pour de larges fichiers écrit par un seul processus à la fois. Il ne supporte, encore aujourd’hui, que l’ajout de données à la fin des fichiers existants et s’appuie sur des système de fichiers locaux sur chacun des noeuds qui composent le cluster. Ce n’est probablement pas quelquechose dontvous avez eu besoin jusqu’à présent, à moins que vous n’ayez la nécessité de traiter des teraoctets de données et que vous ne vouliez pas investir sur du matériel et du logiciel propriétaire. Mais descendons dans le détail… Et avant d’aller plus loin, assurez-vous d’avoir installé et démarré HDFS comme décrit dans Hadoop pour les DBAs (3/13) : Construire un cluster Hadoop.

A la découverte de structures de HDFS

Comme vous aurez pu vous en rendre compte en l’installant et en le démarrant, HDFS s’appuie sur 2 composants principaux :

  • Le NameNode gère les métadonnées dont les fichiers et répertoire, les correspondances entre les fichiers et les blocs, les opérations en cours et passées ou le status des différents DataNode
  • Les DataNodes stockent, comme vous pouvez vous y attendre, les blocs qui sont des morceaux des fichiers

Le nombre d’opérations réalisé par le NameNode est réduit au minimum pour permettre à HDFS de monter en charge par l’ajout de serveurs et sans complexifier l’infrastructure par l’ajout d’espaces de nommage. En conséquence, les clients envoient et récupèrent les données directement des DataNodes. Le schéma ci-dessous montre comme le client interagit avec HDFS lorsqu’un fichier est stocké dans HDFS :

  1. Il se coordonne avec le NameNode pour ajouter et collecter les métadonnées. One fois l’opération réalisée, le client envoie les blocs du fichier à un DataNode
  2. Le DataNode replique ensuite les données et informe le NameNode

hdfs put command
Pour vérifier le détail de ces opérations, nettoyez votre système de fichier HDFS et redémarrer le namenode. Vous pourrez retrouver un fichier fsImage dans le répertoire des métadonnées. A partir du serveur yellow, exécutez :

bin/hdfs dfs -rm -R -f -skipTrash /user/hadoop/*
bin/hdfs dfs -mkdir /user
bin/hdfs dfs -mkdir /user/hadoop
sbin/hadoop-daemon.sh stop namenode
sbin/hadoop-daemon.sh start namenode

Une fois le NameNode redémarré, vous trouverez un fichier fsImage utilisé en cas de crash du NameNode. Ce fichier contient l’image des fichiers et répertoires HDFS. Vous pouvez utiliser Hadoop Offline Image Viewer ou oiv pour vérifier le contenu de HDFS :

ls -tr /u01/metadata/current
[...]
fsimage_0000000000000000503
fsimage_0000000000000000503.md5
VERSION
edits_inprogress_0000000000000000504
seen_txid
bin/hdfs oiv -i /u01/metadata/current/fsimage_0000000000000000503 \
    -o /tmp/fsimage -p Indented
cat /tmp/fsimage
drwxr-xr-x  -   hadoop supergroup 1409403918690 0 /
drwxrwx---  -   hadoop supergroup 1409421293892 0 /tmp
drwxr-xr-x  -   hadoop supergroup 1409403927142 0 /user
drwxr-xr-x  -   hadoop supergroup 1409421326069 0 /user/hadoop

Stocker un fichier dans HDFS pour découvrir comment l’infrastructure se comporte. Vous pouvez exécuter hdfs dfs -put depuis le serveur pink :

dd if=/dev/zero of=/tmp/data bs=64M count=3
bin/hdfs dfs -put /tmp/data data
bin/hdfs dfs -ls /user/hadoop
Found 1 items
-rw-r--r-- 3 hadoop supergroup  201326592 2014-08-30 20:25 /user/hadoop/data

Une fois le fichier stocké dans HDFS, contrôlez comment il est stocké à l’aide de la commande hdfs fsck :

bin/hdfs fsck /user/hadoop/data -files -blocks -locations
Connecting to namenode via http://yellow:50070
FSCK started by hadoop (auth:SIMPLE) from /192.168.56.4 for path /user/hadoop/data at Sat Aug 30 20:34:11
 CEST 2014
/user/hadoop/data 201326592 bytes, 2 block(s):  OK
0. BP-6177126-192.168.56.3-1407174901393:blk_1073741890_1066 len=134217728 repl=3 [192.168.56.4:50010, 192.168.56.5:50010, 192.168.56.3:50010]
1. BP-6177126-192.168.56.3-1407174901393:blk_1073741891_1067 len=67108864 repl=3 [192.168.56.4:50010, 192.168.56.5:50010, 192.168.56.3:50010]
Status: HEALTHY
 Total size:    201326592 B
 Total dirs:    0
 Total files:   1
 Total symlinks:                0
 Total blocks (validated):      2 (avg. block size 100663296 B)
 Minimally replicated blocks:   2 (100.0 %)
 Over-replicated blocks:        0 (0.0 %)
 Under-replicated blocks:       0 (0.0 %)
 Mis-replicated blocks:         0 (0.0 %)
 Default replication factor:    3
 Average block replication:     3.0
 Corrupt blocks:                0
 Missing replicas:              0 (0.0 %)
 Number of data-nodes:          3
 Number of racks:               1
FSCK ended at Sat Aug 30 20:34:11 CEST 2014 in 11 milliseconds
The filesystem under path '/user/hadoop/data' is HEALTHY

Arrêtez à nouveau le NameNode et vérifiez le contenu du répertoire des métadonnées. Les fichiers edit conservent la trace des opérations effectuées par le NameNode. Vous pouvez utiliser Hadoop Offline Edit Viewer pour comprendre ce qui est géré par le NameNode et comment/quand les opérations sont réalisées sur les DataNodes :

sbin/hadoop-daemon.sh stop namenode
ls -tr /u01/metadata/current
[...]
fsimage_0000000000000000503
[...]
seen_txid
edits_inprogress_0000000000000000517
bin/hdfs oev -i /u01/metadata/current/edits_inprogress_0000000000000000517 \
   -o /tmp/edit.xml -p XML
cat /tmp/edit.xml
[...]
 <RECORD>
    <OPCODE>OP_CLOSE</OPCODE>
    <DATA>
      <TXID>525</TXID>
      <LENGTH>0</LENGTH>
      <INODEID>0</INODEID>
      <PATH>/user/hadoop/data._COPYING_</PATH>
      <REPLICATION>3</REPLICATION>
      <MTIME>1409423158612</MTIME>
      <ATIME>1409423152498</ATIME>
      <BLOCKSIZE>134217728</BLOCKSIZE>
      <CLIENT_NAME></CLIENT_NAME>
      <CLIENT_MACHINE></CLIENT_MACHINE>
      <BLOCK>
        <BLOCK_ID>1073741890</BLOCK_ID>
        <NUM_BYTES>134217728</NUM_BYTES>
        <GENSTAMP>1066</GENSTAMP>
      </BLOCK>
      <BLOCK>
        <BLOCK_ID>1073741891</BLOCK_ID>
      <NUM_BYTES>67108864</NUM_BYTES>
        <GENSTAMP>1067</GENSTAMP>
      </BLOCK>
      <PERMISSION_STATUS>
        <USERNAME>hadoop</USERNAME>
        <GROUPNAME>supergroup</GROUPNAME>
        <MODE>420</MODE>
      </PERMISSION_STATUS>
    </DATA>
  </RECORD>
[...]

Comme vous pouvez le deviner ci-dessus, les tailles des blocs par défaut est de 128Mo sauf pour le dernier bloc du fichier. Si vous cherchez ces blocs dans le système de fichier sous-jascent vous les trouverez sous le nom « blk_<blockid> » comme ci-dessous :

find /u01/files/current -iname "*107374189?"
.../BP-6177126-192.168.56.3-1407174901393/current/finalized/blk_1073741890
.../BP-6177126-192.168.56.3-1407174901393/current/finalized/blk_1073741891

Réplication HDFS et perte d’un DataNode

SI vous payez attention à la section précédente, vous constaterez que le facteur de réplication par défaut est de 3. Comme il n’y a que 3 noeud dans ce cluster, il n’est pas possible de visualiser le « rebalancing » automatique des blocs en cas de perte d’un DataNode. Pour cette nouvelle section, vous allez recréer un système de fichier HDFS avec un niveau de réplication par défaut de 2. Pour cela :

  • Arrêtez les DataNode et le NameNode
  • Ajoutez la propriété dfs.replication dans le fichier etc/hadoop/hdfs-site.xml et donnez-lui la valeur 2
  • Supprimez le contenu des répertoires data et metadata de tous les serveurs
  • Formatez le système de fichiers
  • Redémarrez le NameNode et les DataNodes
bin/hdfs dfs -mkdir /user
bin/hdfs dfs -mkdir /user/hadoop
dd if=/dev/zero of=/tmp/data bs=64M count=3
bin/hdfs dfs -put /tmp/data data
bin/hdfs fsck /user/hadoop/data -files -blocks -locations
Connecting to namenode via http://yellow:50070
FSCK started by hadoop (auth:SIMPLE) from /192.168.56.3 for path /user/hadoop/data at Sun Aug 31 06:47:24 CEST 2014
/user/hadoop/data 201326592 bytes, 2 block(s):  OK
0. BP-399541416-192.168.56.3-1409430021329:blk_1073741827_1003 len=134217728 repl=2 [192.168.56.4:50010, 192.168.56.3:50010]
1. BP-399541416-192.168.56.3-1409430021329:blk_1073741828_1004 len=67108864 repl=2 [192.168.56.3:50010, 192.168.56.5:50010]
Status: HEALTHY
 Total size:    201326592 B
 Total dirs:    0
 Total files:   1
 Total symlinks:                0
 Total blocks (validated):      2 (avg. block size 100663296 B)
 Minimally replicated blocks:   2 (100.0 %)
 Over-replicated blocks:        0 (0.0 %)
 Under-replicated blocks:       0 (0.0 %)
 Mis-replicated blocks:         0 (0.0 %)
 Default replication factor:    2
 Average block replication:     2.0
 Corrupt blocks:                0
 Missing replicas:              0 (0.0 %)
 Number of data-nodes:          3
 Number of racks:               1
FSCK ended at Sun Aug 31 06:47:24 CEST 2014 in 4 milliseconds
The filesystem under path '/user/hadoop/data' is HEALTHY

Comme vous vous en rendrez compte ci-dessus, HDFS ne conserve désormais que 2 copie de chaque bloc. Arrêtez un des DataNode qui contient des blocs du fichier. Par exemple, dans cet exemple, arrêtez yellow (192.168.56.3):

sbin/hadoop-daemon.sh stop datanode

Comme vous pouvez vous en rendre compte avec la commande hdfs dfsadmin -report le DataNode n’est pas marqué comme « dead » tout de suite. Par défaut, il faut attendre 10 minutes et 30 secondes pour que l’erreur soit détectée :

bin/hdfs dfsadmin -report
Configured Capacity: 72417030144 (67.44 GB)
Present Capacity: 61966094336 (57.71 GB)
DFS Remaining: 61560250368 (57.33 GB)
DFS Used: 405843968 (387.04 MB)
DFS Used%: 0.65%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
-------------------------------------------------
Datanodes available: 3 (3 total, 0 dead)
Live datanodes:
Name: 192.168.56.5:50010 (green.resetlogs.com)
Hostname: green
Decommission Status : Normal
Configured Capacity: 24139010048 (22.48 GB)
DFS Used: 67649536 (64.52 MB)
Non DFS Used: 3213279232 (2.99 GB)
DFS Remaining: 20858081280 (19.43 GB)
DFS Used%: 0.28%
DFS Remaining%: 86.41%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Last contact: Sun Aug 31 06:57:04 CEST 2014
Name: 192.168.56.3:50010 (yellow.resetlogs.com)
Hostname: yellow.resetlogs.com
Decommission Status : Normal
Configured Capacity: 24139010048 (22.48 GB)
DFS Used: 202915840 (193.52 MB)
Non DFS Used: 3726766080 (3.47 GB)
DFS Remaining: 20209328128 (18.82 GB)
DFS Used%: 0.84%
DFS Remaining%: 83.72%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Last contact: Sun Aug 31 06:56:23 CEST 2014
Name: 192.168.56.4:50010 (pink.resetlogs.com)
Hostname: pink
Decommission Status : Normal
Configured Capacity: 24139010048 (22.48 GB)
DFS Used: 135278592 (129.01 MB)
Non DFS Used: 3510890496 (3.27 GB)
DFS Remaining: 20492840960 (19.09 GB)
DFS Used%: 0.56%
DFS Remaining%: 84.90%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Last contact: Sun Aug 31 06:57:04 CEST 2014

Pendant cette période, vous pouvez continuer à accéder aux fichiers, le client rapportera probablement des exceptions ; Il sera néamoins capable de retrouver le fichier à partir des copies de blocks :

bin/hdfs dfs -get /user/hadoop/data /tmp/greg2
14/08/31 07:00:40 WARN hdfs.BlockReaderFactory: I/O error constructing remote block
reader.
java.net.ConnectException: Connection refused
[...]
14/08/31 07:00:40 WARN hdfs.DFSClient: Failed to connect to /192.168.56.3:50010 for
block, add to deadNodes and continue. java.net.ConnectException: Connection refused
java.net.ConnectException: Connection refused
[...]
14/08/31 07:00:40 INFO hdfs.DFSClient: Successfully connected to /192.168.56.4:50010
 for BP-399541416-192.168.56.3-1409430021329:blk_1073741827_1003

Après quelques minutes, le DataNode arrêté sera marqué « dead » par le NameNode :

bin/hdfs dfsadmin -report
Configured Capacity: 72417030144 (67.44 GB)
Present Capacity: 61966077952 (57.71 GB)
DFS Remaining: 61560233984 (57.33 GB)
DFS Used: 405843968 (387.04 MB)
DFS Used%: 0.65%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
-------------------------------------------------
Datanodes available: 2 (3 total, 1 dead)
Live datanodes:
Name: 192.168.56.5:50010 (green.resetlogs.com)
Hostname: green
Decommission Status : Normal
Configured Capacity: 24139010048 (22.48 GB)
DFS Used: 67649536 (64.52 MB)
Non DFS Used: 3213287424 (2.99 GB)
DFS Remaining: 20858073088 (19.43 GB)
DFS Used%: 0.28%
DFS Remaining%: 86.41%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Last contact: Sun Aug 31 07:09:01 CEST 2014
Name: 192.168.56.4:50010 (pink.resetlogs.com)
Hostname: pink
Decommission Status : Normal
Configured Capacity: 24139010048 (22.48 GB)
DFS Used: 135278592 (129.01 MB)
Non DFS Used: 3510898688 (3.27 GB)
DFS Remaining: 20492832768 (19.09 GB)
DFS Used%: 0.56%
DFS Remaining%: 84.90%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Last contact: Sun Aug 31 07:09:01 CEST 2014
Dead datanodes:
Name: 192.168.56.3:50010 (yellow.resetlogs.com)
Hostname: yellow.resetlogs.com
Decommission Status : Normal
Configured Capacity: 24139010048 (22.48 GB)
DFS Used: 202915840 (193.52 MB)
Non DFS Used: 3726766080 (3.47 GB)
DFS Remaining: 20209328128 (18.82 GB)
DFS Used%: 0.84%
DFS Remaining%: 83.72%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Last contact: Sun Aug 31 06:56:23 CEST 2014

Les blocs des fichiers sont alors rebalancés sur les DataNodes restant pour éviter les erreurs lorsque vous allez lire les fichiers :

bin/hdfs fsck /user/hadoop/data -files -blocks -locations
Connecting to namenode via http://yellow:50070
FSCK started by hadoop (auth:SIMPLE) from /192.168.56.3 for path /user/hadoop/data at Sun Aug 31 07:11:32 CEST 2014
/user/hadoop/data 201326592 bytes, 2 block(s):  OK
0. BP-399541416-192.168.56.3-1409430021329:blk_1073741827_1003 len=134217728 repl=2 [192.168.56.4:50010, 192.168.56.5:50010]
1. BP-399541416-192.168.56.3-1409430021329:blk_1073741828_1004 len=67108864 repl=2 [192.168.56.5:50010, 192.168.56.4:50010]
Status: HEALTHY
 Total size:    201326592 B
 Total dirs:    0
 Total files:   1
 Total symlinks:                0
 Total blocks (validated):      2 (avg. block size 100663296 B)
 Minimally replicated blocks:   2 (100.0 %)
 Over-replicated blocks:        0 (0.0 %)
 Under-replicated blocks:       0 (0.0 %)
 Mis-replicated blocks:         0 (0.0 %)
 Default replication factor:    2
 Average block replication:     2.0
 Corrupt blocks:                0
 Missing replicas:              0 (0.0 %)
 Number of data-nodes:          2
 Number of racks:               1
FSCK ended at Sun Aug 31 07:11:32 CEST 2014 in 1 milliseconds
The filesystem under path '/user/hadoop/data' is HEALTHY
bin/hdfs dfs -get /user/hadoop/data /tmp/copy3

A ce stade, si vous redémarrez le DataNode qui a échoué, le NameNode le découvre à nouveau fonctionnel et certains blocs ont désormais 3 copies dans le cluster :

bin/hdfs fsck /user/hadoop/data -files -blocks -locations
Connecting to namenode via http://yellow:50070
FSCK started by hadoop (auth:SIMPLE) from /192.168.56.3 for path /user/hadoop/data at Sun Aug 31 07:17:25 CEST 2014
/user/hadoop/data 201326592 bytes, 2 block(s):  OK
0. BP-399541416-192.168.56.3-1409430021329:blk_1073741827_1003 len=134217728 repl=2 [192.168.56.4:50010, 192.168.56.5:50010, 192.168.56.3:50010]
1. BP-399541416-192.168.56.3-1409430021329:blk_1073741828_1004 len=67108864 repl=2 [192.168.56.5:50010, 192.168.56.4:50010, 192.168.56.3:50010]
Status: HEALTHY
 Total size:    201326592 B
 Total dirs:    0
 Total files:   1
 Total symlinks:                0
 Total blocks (validated):      2 (avg. block size 100663296 B)
 Minimally replicated blocks:   2 (100.0 %)
 Over-replicated blocks:        0 (0.0 %)
 Under-replicated blocks:       0 (0.0 %)
 Mis-replicated blocks:         0 (0.0 %)
 Default replication factor:    2
 Average block replication:     2.0
 Corrupt blocks:                0
 Missing replicas:              0 (0.0 %)
 Number of data-nodes:          3
 Number of racks:               1
FSCK ended at Sun Aug 31 07:17:25 CEST 2014 in 1 milliseconds
The filesystem under path '/user/hadoop/data' is HEALTHY

Quorum Journal Manager et perte d’un NameNode

Dans la configuration précédente, le NameNode est un « single point of failure ». c’est particulièrement le cas si les disques sont locaux aux serveurs et qu’il ne sont pas sécurisé par un mécasnisme comme une carte RAID ou un Volume Manager. Gardez à l’esprit que les métadonnées de HDFS sont uniquement accessible par le NameNode. Pour sécuriser cette configuration, HDFS offre la possibilité de répliquer les métadonnées dans un NameNode dit de « standby ». Pour l’instant et, au moins jusqu’à la version 2.5.0, il ne peut y avoir que 2 NameNodes par configuration : l’un actif et l’autre de standby. En cas de perte d’un serveur ou pour une maintenance, vous pouvez basculer le NameNode actif sur le NameNode de standby. Cette infrastructure de réplication est appelée Quorum Journal Manager. Elle fonctionne comme décrit ci-desous :

  1. Le NameNode actif envoie les « edits » aux JounalNodes de sorte que les métédonnées puissent être maintenues sur les autres NameNodes
  2. Les NameNodes de Standby collectent les « edits » depuis les JournalNodes et maintiennent une copie des métadonnées
  3. Les DataNodes envoient les informations relatives au blocs pas seulement au NameNode actif mais à tous les NameNodes de la configuration de sorte qu’ils puissent basculer rapidement à l’aide dune simple commande failover

Quorum Journal Manager

Configuration du NameNode de Standby

Pour configurer le Quorum Journal Manager pour une bascule manuelle, procédez comme décrit ci-dessous :

  • Arrêtez le NameNode et les DataNodes
sbin/hadoop-daemon.sh stop namenode
sbin/hadoop-daemon.sh stop datanode
  • Créez un répertoire pour le Journal sur chaque noeud
for i in yellow pink green; do
   ssh $i mkdir /u01/journal
done
  • Créez un répertoire metadata sur green
ssh green mkdir /u01/metadata
  • Assurez-vous que fuser est installé sur chacun des serveurs
yum install -y psmisc
  • Ajoutez les propriétés suivantes dans etc/hadoop/hdfs-site.xml
 <property>
    <name>dfs.nameservices</name>
    <value>colorcluster</value>
  </property>
  <property>
    <name>dfs.ha.namenodes.colorcluster</name>
    <value>nn1,nn2</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.colorcluster.nn1</name>
    <value>yellow.resetlogs.com:8020</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.colorcluster.nn2</name>
    <value>green.resetlogs.com:8020</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.colorcluster.nn1</name>
    <value>yellow.resetlogs.com:50070</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.colorcluster.nn2</name>
    <value>green.resetlogs.com:50070</value>
  </property>
 <property>
    <name>dfs.namenode.shared.edits.dir</name>
    <value>qjournal://yellow.resetlogs.com:8485;pink.resetlogs.com:8485;green.resetlogs.com:8485/colorcluster</value>
  </property>
  <property>
    <name>dfs.journalnode.edits.dir</name>
    <value>/u01/journal</value>
  </property>
  <property>
    <name>dfs.client.failover.proxy.provider.colorcluster</name>
    <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
  </property>
  <property>
    <name>dfs.ha.fencing.methods</name>
    <value>sshfence</value>
  </property>
  <property>
    <name>dfs.ha.fencing.ssh.private-key-files</name>
    <value>/home/hadoop/.ssh/id_dsa</value>
  </property>

Note:
Pour les details associés à ces paramètres consultez HDFS High Availability Using the Quorum Journal Manager.

  • Changez la propriété fs.defaultFS de core-site.xml pour la faire correspondre au nom du cluster
cat etc/hadoop/core-site.xml
<configuration>
   <property>
        <name>fs.defaultFS</name>
        <value>hdfs://colorcluster</value>
    </property>
</configuration>
  • Distribuez les 2 fichiers modifiés précédemment sur l’ensemble des serveurs du cluster
for i in pink green; do
  scp etc/hadoop/hdfs-site.xml $i:/usr/local/hadoop/etc/hadoop/.
  scp etc/hadoop/core-site.xml $i:/usr/local/hadoop/etc/hadoop/.
done
  • Démarrez les processus journalnode et datanode
sbin/hadoop-daemons.sh start journalnode
sbin/hadoop-daemons.sh start datanode
  • Formatez les répertoires journalnode à partir du serveur yellow
bin/hdfs namenode -initializeSharedEdits
  • Démarrez le NameNode sur yellow
sbin/hadoop-daemon.sh start namenode
  • Configurez le NameNode sur green pour qu’il se synchronise avec le NameNode sur yellow
# on green
bin/hdfs namenode -bootstrapStandby
  • Démarrez le NameNode sur green
sbin/hadoop-daemon.sh start namenode
  • Vérifiez l’état des 2 NameNodes:
bin/hdfs haadmin -getServiceState nn1
standby
bin/hdfs haadmin -getServiceState nn2
standby
  • Activez l’un des NameNode
bin/hdfs haadmin -transitionToActive nn1
  • Testez HDFS; le client doit être capable d’accéder à HDFS
bin/hdfs dfs -ls /user/hadoop
-rw-r--r--   2 hadoop supergroup  201326592 2014-08-31 13:29 /user/hadoop/data

Bascule manuelle

Si vous perdez le NameNode actif sur yellow, vous ne serez plus capable d’accèder à HDFS :

ps -ef |grep [n]amenode |awk '{print "kill -9",$2}'|sh

Cependant, vous pourrez facilement basculer sur le NameNode de standby à l’aide de la commande ci-dessous :

bin/hdfs haadmin -failover nn1 nn2

Le client sera alors capable d’accéder à nouveau à HDFS:

bin/hdfs dfs -ls /user/hadoop
-rw-r--r--   2 hadoop supergroup  201326592 2014-08-31 13:29 /user/hadoop/data

Procédure de démarrage et d’arrêt

Lorsque vous avez configuré QJM, démarrer et arrêter le cluster HDFS changent un peu. Pour l’arrêtez depuis yellow, exécutez :

cd /usr/local/hadoop
ssh green `pwd`/sbin/hadoop-daemon.sh stop namenode
sbin/hadoop-daemon.sh stop namenode
sbin/hadoop-daemons.sh stop journalnode
sbin/hadoop-daemons.sh stop datanode

Pour redémarrer HDFS, exécutez:

cd /usr/local/hadoop
sbin/hadoop-daemons.sh start journalnode
sbin/hadoop-daemon.sh start namenode
ssh green `pwd`/sbin/hadoop-daemon.sh start namenode
sbin/hadoop-daemons.sh start datanode
bin/hdfs haadmin -failover nn2 nn1
bin/hdfs haadmin -getServiceState nn1

Conclusion

Cette 4e partie de cette série d’article montre comment HDFS fonctionne. Il présente également le fonctionnement de la réplication des blocs dans les DataNodes et comment configurer le Quorum Journal Manager pour gérer une bascule manuelle des NameNodes. Il existe de nombreux autres aspects liés à HDFS que vous voudrez creuser. Cela va de l’utilisation de Zookeeper pour automatiser les bascules à la configuration de la réplication dans des racks de serveurs différents. La semaine prochaine, vous découvrirez comment développer un programme MapReduce dans ce nouveau cluster colorcluster. A bientôt !

Bibliographie
Pour en savoir plus à propos de HDFS, lisez HDFS Users Guide.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *