Discussion :

[Jidefix]

Hello, je suis en train de faire un plan d'upgrade d'un cluster hadoop qui en a bien besoin.
On utilise les composants suivants:
Hadoop 2.2
HBase 0.98
Spark 2.1.0

On voudrai faire une mise à jour à peu prêt "à jour", et donc passer aux versions suivantes:
Hadoop 2.7.3
HBase 1.2.6
Spark 2.1.1

Visiblement pour Hadoop le rolling upgrade n'existe pas en 2.2 , il faut donc faire un shutdown/restart en nouvelle version.
Pour HBase il semblerait que le rolling upgrade soit possible en suivant le chemin 0.98 => 1.0 => 1.2.6

MAIS
- HBase 0.98 n'est pas compatible avec hadoop 2.7.3
- Hbase 1.0 n'est pas compatible avec hadoop 2.2, et rien n'est dit à propos de la 2.7.3 (je considère donc que c'est mort)

La question est donc:
Est-ce que je peux brutalement arrêter mon cluster, le migrer en 2.7.3, puis faire mon rolling upgrade HBASE 1.0 puis 1.2.6 malgré l'incompatibilité, voire un full upgrade direct en 1.2.6? Il s'agit juste de l'utiliser le temps de faire l'upgrade.
Ou est-ce que je suis obligé de passer par hadoop 2.5.2 qui est la seule version compatible avec mes 3 HBase ?(la 2.4 aussi mais elle n'est plus en download sur leur site)

Je viens de voir que la 1.0/1.1 devrait supporter hadoop 2.2 en "Not Tested". Un autre plan pourrait être:
HBase 0.98 => HBase 1.0
HBase 1.0 => HBase 1.1
Hadoop 2.2 => 2.7.3
HBase 1.0 => 1.2.6

Mais c'est encore plus long...

Question bonus: une idée des temps que ça prend pour environ 300TB de données HBase? (avant replication HDFS)

Merci d'avance

[Jidefix]

Bon finalement ça s'est bien passé, petit récap de mon expérience pour les générations futures:
Le chemin d'upgrade finalement retenu a été le suivant:
Hadoop 2.2 -> hadoop 2.5.2 -> hadoop 2.7.4
Coté Hbase, coupure de hbase 0.98 avant le début de l'opération puis redémarrage normal avec les binaires de hbase 1.2.6

Préparation:
- Installation de toutes les versions de hadoop / hbase dans des répertoires séparés. Le plus simple est de créer un symlink vers la version "active". Comme ça tous les fichiers de config font référence à ce symlink, pas de risque d'erreur.

Opération:
Hadoop 2.2 -> 2.5.2
- Coupure de tous les service utilisant le cluster
- Passage de HDFS en safemode puis mise à plat du namespace, afin d'avoir un HDFS clean, sans transaction pending:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
hdfs dfsadmin -safemode enter
hdfs dfsadmin -saveNamespace

- shutdown de HDFS. Pour être tranquille, mieux vaut backuper les répertoires "nn" (fs image + edits) à ce stade. En cas d'embrouille ça permet de revenir en arrière (les rollbacks HDFS avec les commandes officielles, on en a essayé deux et ils n'ont pas marché)
- Démarrage du namenode en 2.5.2:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
hadoop-daemon.sh start namenode -upgrade

- Si présence d'un second namenode: démarrage en bootstrap standby:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

hdfs namenode -bootstrapStandby -force

- Redémarrage complet du service HDFS
- Le namenode envoie la commande d'upgrade à tous les datanodes. Cette opération peut prendre du temps (5 minutes par datanode, heureusement c'est en parallèle), et de la RAM côté namenode (on a du passer de 8GB à 16GB pour un cluster de 15 millions de blocks)
- finalization de l'upgrade:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

hdfs dfsadmin -finalizeUpgrade

Pour la migration 2.5.2 vers 2.7.4, on a utilisé la fonctionnalité de rolling upgrade, ce qui permet de ne pas avoir de coupure de service (même si dans l'absolu on s'en foutait on était déjà coupé mais c'est bien de savoir que ça marche). Le pré-requis est d'avoir 2 namenodes afin de basculer de l'un à l'autre:
- Coupure du namenode non actif puis redémarrage en 2.7.4:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

hadoop-daemon.sh start namenode -rollingUpgrade started

- Bascule sur le namenode 2.7.4:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

hdfs haadmin -failover nn1 nn2

(nn1 et nn2 sont des réferences dans la conf, elles peuvent changer selon la conf)
- Meme opération sur l'autre namenode (celui qui est toujours en 2.5.2)
- Lorsque les deux namenodes sont en 2.7.4, redémarrage progressifs de chaque datanode en 2.7.4 (nous sommes passés par un script SSH custom afin de maitriser la cadence de rolling restart). Chaque datanode reçoit alors la commande d'upgrade

Pour HBase, pas de migration réelle, un simple arrêt/redémarrage a fonctionné direct.


Les problèmes qu'on a vu:
1) HADOOP, CA SE BUILD!!!!! Des binaires sont téléchargeables sur le site d'Apache mais posent de nombreux problèmes (entre autres: ils sont compilés en java 8 alors que la 2.7.4 supporte java 7, et surtout la page d'accueil de yarn de marche pas). En buildant directement, pas de souci
2) Les librairies natives pour snappy (libhadoop.so, libsnappy.so...), c'est la *****. Bien faire attention à leur configuration (si on utilise snappy ou autre of course)
3) HBase 1.2.6 ne split plus au dela de 1000 regions par region server (limite dans la config). On en a à peu près 2000/region server donc on a du monter la limite. On s'est aussi lancés dans un projet de réduction du nombre de regions en passant la taille du HFile de 5GB à 20GB. C'est mieux mais on est quand même toujours TRÈS LOIN des 100 régions recommandées...
4) Un garbage collector, ça se tune. Beaucoup de problèmes de lenteur de GC sont remontés. Ce n'est pas lié à la migration mais du coup on en a profité pour rajouter des options sur le CMS, et ça va beaucoup mieux (on avait des pauses de JVM jusqu'à 12 minutes!!!)
5) Les symlink, c'est bon , mangez-en! Beaucoup plus facile de gérer les différents scripts

Voilou, total de downtime: 2 heures environ, dont 30 minutes passées à regarder un namenode faire des OutOfMemory.