Cet article est pensé pour vous aider à affronter le baptême du feu : l’installation de la plate-forme.
Quelle distribution choisir ?
La première question à se poser lorsque l’on choisit sa distribution Hadoop est celle du support. En effet, sur la version packagée par Apache, il est difficile de se procurer un support efficace et digne de ce nom. Les principaux contributeurs au projet Hadoop sont tous salariés d’entreprises offrant un support commercial, mais uniquement sur leur propre distribution.
Les trois principaux acteurs de ce marché sont :
- Cloudera, avec la Cloudera Hadoop Distribution, actuellement en version 4 (CDH4), qui package Hadoop 2.0 ;
- HortonWorks, qui package Hadoop 1.0.3 ;
- MapR, qui propose lui aussi une distribution autour de Hadoop 2.
Hormis l’accès à un support, ces distributions offrent toutes un gros effort de packaging de l’écosystème Hadoop, c’est à dire Hadoop en lui même, mais aussi ses satellites, comme HBase, Hive ou encore Pig.
De plus, ces entreprises tentent d’apporter, en avance de phase, les fonctionnalités manquantes à la distribution Apache : console de management, outils intégrés de monitoring, haute disponibilité complète…
Ces distributions proposent toutes un mode gratuit et une licence commerciale. Ces éditions diffèrent par les outils proposés et / ou le nombre de nœuds supportés.
Dans cet article, nous n’entrerons pas dans le détail de ces différentes distributions. Elles reposent toutes sur le cœur open-source Apache Hadoop. Il nous semble donc important de bien expliquer comment installer le produit depuis les binaires Apache. Dès lors, vous serez à même d’installer et de configurer n’importe quelle distribution.
Le choix des machines
On l’a dit, la force d’Hadoop est sa capacité à exploiter des grappes de serveurs d’entrée de gamme. C’est pourquoi votre première installation ne devrait pas vous imposer des coûts exorbitants. Pour une configuration basique, on peut partir sur des serveurs de ce type :
- 2 CPU dual-core de moyenne fréquence, par exemple 2 Ghz ;
- 32 Go RAM ;
- 2 à 6 disques SATA 7200 RPM de 2 To.
Lorsque vous calculez vos besoins en disques, n’oubliez pas que :
- Hadoop ne requiert pas de RAID, la fiabilité de HDFS étant assuré par le stockage redondant des fichiers.
- Les fichiers étant dupliqués par défaut trois fois sur le cluster, votre taille utile est égale à : ( capacité totale – taille des disques système) / redondance.
Pour une première installation et pour se rendre compte de la puissance de Hadoop, nous recommandons un minimum de 3 machines (1 namenode et 2 datanodes, ce qui implique de baisser le niveau de réplication à 2), idéalement 4 machines (1 namenode et 3 datanodes, on laisse la réplication par défaut, à 3).
Commençons l’installation : installer HDFS
Le seul prérequis à l’installation d’Hadoop est d’avoir installé un JDK récent et correctement paramétré son JAVA_HOME.
Le premier “module” Hadoop à installer est le système de fichiers distribué, HDFS. Il est composé de deux types de nœuds :
- le nameNode, unique, le chef d’orchestre qui stocke et gère les méta données ;
- les dataNodes, multiples, qui portent les données.
Les configurations du nameNode et des dataNodes sont légèrement différentes.
Après avoir téléchargé et dézippé la dernière version stable de Hadoop (1.0.4 à l’écriture de cet article), nous allons configurer le nameNode. Dans le répertoire conf, nous allons éditer le fichier hadoop-site.xml, qui contient les éléments de paramétrage de HDFS.
Chaque propriété de ce fichier est de la forme
<property>
<name>nom de la propriété</name>
<value>valeur de la propriété</value>
</property>
Les éléments indispensables au bon fonctionnement du cluster sont :
fs.default.name : C’est l’URI du nameNode, qui devra être connue de tout le système. Elle est de type protocole://ip:port. Par exemple, hdfs://mynamenode:9000
dfs.name.dir : C’est le répertoire physique où le nameNode stocke les métadonnées. Par exemple /HadoopDir/nameDir/
dfs.replication : le nombre de réplicas de chaque fichier sur le cluster. Il devra être inférieur ou égal au nombre de dataNodes. Par défaut, il est de 3.
Comme tout système de fichiers, il est nécessaire de le formater avant son utilisation. Dans le cas de HDFS, cela consiste à l’initialisation du répertoire de métadonnées du nameNode. Il suffit d’exécuter une commande hadoop système :
$ <HADOOP_HOME>/bin/hadoop namenode -format
Le nameNode est maintenant prêt à l’usage. Nous pouvons le démarrer en mode ‘console’, à l’aide de la commande
$ <HADOOP_HOME>/bin/hadoop namenode
Pour le démarrer en démon en arrière plan, on préférera la commande
$ <HADOOP_HOME>/bin/hadoop-daemon.sh start namenode
Il est maintenant possible de consulter le bon fonctionnement du cluster à l’aide d’une interface graphique. Par défaut, elle est disponible sur http://mynamenode:50070
Pour installer les dataNodes, la procédure est la même : télécharger, décompresser l’archive et éditer le fichier <HADOOP_HOME>/conf/hadoop-site.xml.
Les propriétés à paramétrer sont les suivantes :
fs.default.name : l’URI du nameNode. C’est grâce à cette dernière que le dataNode rejoint le cluster.
dfs.data.dir : C’est le(s) répertoire(s) physique(s) où le dataNode stocke les fichiers. Si il y a plusieurs répertoires (plusieurs points de montage pour plusieurs disques), il est nécessaire de les séparer par des ‘,’. Cette valeur peut bien entendu être différente en fonction du dataNode que l’on configure.
Nous pouvons démarrer chaque dataNode à l’aide de la commande
$ <HADOOP_HOME>/bin/hadoop datanode
En se connectant sur le nameNode, vous devriez voir apparaître les dataNodes
Il est aussi possible d’obtenir des statistiques intéressantes sur votre cluster HDFS en utilisant la commande d’administration :
$ <HADOOP_HOME>/ bin/hadoop dfsadmin -report
Premier contact avec HDFS
Hormis le fait qu’il est distribué, HDFS a tout d’un fileSystem classique du point de vue de l’utilisateur. Il propose donc les commandes classiques d’un fileSystem Unix, comme cat, mkdir, ls, chmod, chown …, ainsi que son mécanisme arborescent. La principale différence est qu’il faut systématiquement passer par Hadoop pour exécuter ces commandes. Chacune des commandes sera donc précédée par :
$ <HADOOP_HOME>/bin/hadoop fs -commande
Par exemple, vous pouvez créer votre premier répertoire :
$ <HADOOP_HOME>/bin/hadoop fs -mkdir /myuser
puis lister le contenu de la racine
$ <HADOOP_HOME>/bin/hadoop fs -mkdir /
Il est temps de copier un premier fichier dans votre HDFS :
$ <HADOOP_HOME>/bin/hadoop fs -put /tmp/myLocalFile.txt /myuser/myDistantFile.txt
Vous pouvez visualiser vos fichiers sur l’interface web, via le lien Browse FileSystem.
Et vous pouvez afficher le contenu de ce fichier dans la console :
$ <HADOOP_HOME>/bin/hadoop fs -cat /myuser/myDistantFile.txt
Terminons l’installation : MapReduce
Si vous avez bien retenu la présentation d’Hadoop du numéro 159, vous n’aurez pas manqué de constater qu’il manque à notre cluster un pan important de la plate-forme: la partie Map/Reduce. Nous allons l’installer maintenant que notre HDFS est pleinement fonctionnel.
Dans un cluster simple, le jobTracker est généralement colocalisé avec le NameNode et les taskTrackers sont nécessairement colocalisés avec leurs équivalents HDFS, à savoir les dataNodes.
Ils suivent la même architecture chef d’orchestre / exécutants : la JVM qui exécute le job le découpe en unités de traitement, qui sont réparties et orchestrées par le JobTracker sur les différents taskTackers. En colocalisant DataNode et taskTracker, on respecte le premier principe d’Hadoop : le code métier est exécuté au plus près des données.
Comme pour HDFS, nous allons commencer par installer le jobTracker.
Nous nous rendons donc sur les machines qui hébergent le NameNode et les DataNodes.
Le fichier à éditer est :
$ <HADOOP_HOME>/conf/mapred-site.xml
L’unique propriété à paramétrer est la suivante, aussi bien sur le jobTracker que sur les tasksTrackers :
mapred.job.tracker : l’URI du jobTracker, qui devra être connue de tout le système. Elle est de type ip:port. Par exemple, mynamenode:9001
Il est ensuite possible de démarrer le jobTracker :
$<HADOOP_HOME>/bin/hadoop-daemon.sh start jobtracker
et les taskTrackers :
$<HADOOP_HOME>/bin/hadoop-daemon.sh start tasktracker
Comme pour le nameNode, une interface web permet de récupérer quelques métriques. Par défaut, elle est disponible sur
http://mynamenode:50030
Nous n’aborderons la rédaction des jobs et leur exécution que dans un article ultérieur, nous n’irons donc pas plus en détails ici dans le fonctionnement de Map/Reduce sur le cluster.
Le monitoring
Comme nous l’avons vu, un cluster Hadoop est un système relativement complexe. De plus, il est généralement ouvert à de nombreux utilisateurs et son état évolue rapidement.
Il est donc vital de le monitorer correctement.
Tout d’abord, pour s’assurer de son bon fonctionnement : le cluster est prévu pour résister à tout type de panne, et continue donc de fonctionner de manière transparente en cas de défaillance d’un ou deux éléments (grâce à la réplication automatisée de chaque fichier). Mais en l’absence de monitoring et de détection des pannes, si le nombre de pannes dépasse le nombre de réplicas des fichiers, il est possible de perdre des données, et ce de manière irréversible.
Ensuite, on l’a dit, l’état du cluster évolue rapidement. Et si votre projet BigData est un succès, la croissance du FileSystem sera exponentielle. Il est par conséquent capital de pouvoir anticiper, afin de cibler vos achats et ne pas vous retrouver à court d’espace disque et /ou de puissance de calcul au moment le plus critique (lors de votre pic saisonnier de ventes par exemple).
Hadoop offre plusieurs types de monitoring par défaut. Nous nous concentrerons sur le plus flexible d’entre eux, un monitoring via JMX. Dans une installation réelle, il est souhaitable d’utiliser un outil de collecte de mesures JMX, comme par exemple JmxTrans, qui, couplé à un outil de statistiques comme Graphite, vous donne une vision graphique, de votre cluster dans la durée. Dans cet article, nous utiliserons plus archaïquement VisualVm.
Pour activer les métriques JMX sur votre cluster, il est nécessaire d’éditer sur tous vos nœuds le fichier :
$ <HADOOP_HOME>/conf/hadoop-env.sh
Au dessus du bloc définissant les options spécifiques de chaque membre du cluster (fig. x), nous allons ajouter l’activation JMX
### JMX settings
export JMX_OPTS=" -Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.port"
export HADOOP_NAMENODE_OPTS="$JMX_OPTS=8006 $HADOOP_NAMENODE_OPTS"
export HADOOP_DATANODE_OPTS="$JMX_OPTS=8006 $HADOOP_DATANODE_OPTS"
export HADOOP_JOBTRACKER_OPTS="$JMX_OPTS=8007 $HADOOP_JOBTRACKER_OPTS"
export HADOOP_TASKTRACKER_OPTS="$JMX_OPTS=8007 $HADOOP_TASKTRACKER_OPTS"
Il faut ensuite redémarrer chaque process du cluster pour la prise en compte de ce paramétrage.
En se connectant via VisualVm sur le nameNode, on peut consulter les ‘constantes vitales’ de HDFS, par exemple l’espace disque.
Il est aussi possible d’accéder aux mêmes statistiques au format JSon via le servlet de la webapp :
curl -i http://mynamenode:50070/jmx
L’automatisation
Comme expliqué ci-dessus, l’administration d’une grappe de serveurs Hadoop peut vite devenir fastidieuse avec l’ajout d’un port JMX sur tous les nœuds du cluster.
C’est pour cette raison que nous recommandons d’automatiser installation, configuration et maintenance en condition opérationnelle au plus vite.
Tous les systèmes d’automatisation sont bons, et les cadors du marché, Puppet et Chef, proposent dans leur forge respective des recettes toutes faites pour Hadoop.
Ne faites pas l’impasse sur cet effort initial, vous vous en féliciterez une fois que vous devrez réaliser une montée de version mineure sur les 50 nœuds de votre cluster.
A noter : les distributions commerciales proposent toutes un outil “maison” pour faciliter le déploiement et l’administration du cluster. L’effort d’intégration au sein de votre propre SI est plus ou moins important, en fonction de votre niveau de maturité sur le sujet.
Il existe aussi un projet Apache, Ambari, encore dans l’incubateur, qui vise à faciliter la gestion du cluster pour les administrateurs système.
La partie émergée de l’iceberg
Nous n’avons abordé ici que la surface des choses et nous avons volontairement laissé de côté quelques points importants, voire vitaux lorsque votre projet BigData atteint son plein essor :
- la haute disponibilité du NameNode. C’est le SPOF de votre HDFS en version 1.x ;
- la mise en place de la sécurité ;
- le paramétrage avancé du cluster, qui peut vous faire gagner de précieuses heures lors de l’exécution de vos jobs ;
- la taille des blocks et le problème des petits fichiers, qui peuvent faire exploser la mémoire de votre NameNode.
Le champ exploratoire est vaste, et le succès de votre projet BigData devrait vous amener rapidement sur ces sujets.
A la fin de cet article, vous devriez néanmoins avoir un cluster fonctionnel, qui vous permettra d’aborder notre prochain sujet, autrement plus intéressant et important : le développement de vos jobs Map/Reduce, ou comment transformer vos données brutes en valeur pour votre entreprise.
Liens :
Apache Hadoop: http://hadoop.apache.org/
Apache Ambari : http://incubator.apache.org/ambari/
Graphite : http://graphite.wikidot.com/
JmxTrans : https://github.com/lookfirst/jmxtrans
VisualVm : http://visualvm.java.net/