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 :
- 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
- Le DataNode replique ensuite les données et informe le NameNode
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 :
- Le NameNode actif envoie les « edits » aux JounalNodes de sorte que les métédonnées puissent être maintenues sur les autres NameNodes
- Les NameNodes de Standby collectent les « edits » depuis les JournalNodes et maintiennent une copie des métadonnées
- 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
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
fuserest 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.defaultFSdecore-site.xmlpour 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
greenpour qu’il se synchronise avec le NameNode suryellow
# 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.
