Migration de cluster et de traitements entre Hadoop 2 et 3

La migration de Hadoop 2 vers Hadoop 3 est un sujet brûlant. Comment mettre à niveau vos clusters, quelles fonctionnalités présentes dans la nouvelle version peuvent résoudre les problèmes actuels et apporter de nouvelles opportunités, comment vos traitements actuels sont-ils impactés, quelle stratégie de migration est la plus appropriée pour votre entreprise ?

Cet article traite d’une conférence donnée à l’édition 2018 de Dataworks Summit à San José en Californie, donnée par Suma Shivaprasad (Hortonworks Staff Engineer) et Rohith Sharkma (Hortonworks Senior Software Engineer). Hadoop 3 est une montée de version majeure. Il vient avec beaucoup de nouvelles fonctionnalités importantes et certaines incompatibilités. La dernière version majeure, Hadoop 2, est arrivée en 2012. Dans de nombreuses entreprises, la migration a pris plusieurs années. De nos jours, les clusters exécutant Hadoop 2 sont plus nombreux que ceux qui exécutent Hadoop 1 et atteignent des SLA plus élevés.

La mise à niveau constitue également un défi pour les équipes d’assistance et d’ingénierie de Hortonworks. Pour assurer la mise à niveau la plus fluide possible, les instructions et les notes de mise à jour doivent être les plus précises possible. Défi accepté (en leur nom).

Motivations de cette nouvelle version

Petit rappel sur les raisons justifiant que nous envisagions de passer à la version 3.x.

HDFS

HDFS est livré avec de nombreuses nouvelles fonctionnalités qui sont :

Fédération GA (General Availability)
Erasure Coding
- Économies de coûts significatives sur le stockage
- Réduction dans l’utilisation des ressources de 200% à 50%
Intra-DataNode Disk-Balancer

Erasure Coding réduit considérablement l’utilisation du disque par HDFS au prix de plus de traitement (lecture d’un fichier). Avant Hadoop 3, le mécanisme d’Intra-DataNode Disk-Balancer n’était efficace que lors de la création de fichiers. Maintenant, le comportement du Balancer sera similaire au Balancer Inter-DataNode (et évitera d’utiliser des outils externes pour le faire).

YARN

Les nouvelles fonctionnalités incluent :

Améliorations du planificateur de tâche (YARN Scheduler)
- Nouveaux types de Resources : GPUs, FPGAs
- Fast and Global scheduling
Containerisation - Docker
Long-running Services rehash
Nouvelle interface graphique UI2
Timeline Server v2

À mon avis, à l’exception de la fédération HDFS, YARN est la principale raison justifiant la migration vers Hadoop 3. Docker Scheduling, conteneurisation, services GPU, … ce sont des fonctionnalités qui manquaient cruellement aux clusters Hadoop actuels en production. Cela fera d’Hadoop un ordonnanceur viable et plus complet pour répondre aux différents cas d’utilisation existants et émergents.

Principaux points de considération

Mécanisme de mise à jour

Il y a principalement deux types de mise à niveau :

Mises à jour express
- Mise à niveau “Stop the world” incluant une interruption de service
- Arrêt complet du cluster
- Mise à jour de tous les composants en une fois
Rolling Upgrade
- Préserver la disponibilité du cluster
- Minimise l’impact et les temps d’immobilisation
- Peut prendre beaucoup de temps pour terminer
- Met à jour chaque processus indépendamment (master et slave par lot)

Pour la migration de Hadoop 2 vers Hadoop 3. Une mise à jour progressive sera impossible.

Pourquoi ? -_-'

Ceci est principalement dû au fait que les composants embarquent des changements incompatibles :

HDFS-13596
Changements dans le format du journal d’édition. Si un JournalNode est mis à jour, l’autre ne parviendra pas à échanger des informations avec le premier.
HDFS-6440
Modifications de l’API MetricsPlugin. Il est impossible de lire les métriques des services mis à jour sans mise à jour du code (pour les applications ou les services HDFS)
HDFS-6440
Changements dans le protocole de transfert d’image. Cela signifie que si un nœud NameNode est mis à niveau, l’autre (NN de secours pour HA ou NN secondaire) échouera à obtenir le fsimage.

L’incompatibilité signifie qu’un DataNode HDFS fonctionnant avec la version 2.x ne parviendra pas à communiquer avec un NameNode HDFS fonctionnant avec la version 3.x. Par conception, Hadoop n’offre pas de garanties pour préserver les compatibilités de protocole entre versions majeures. Ainsi, la mise à niveau de HDFS est impossible et par conséquent tous les services qui en dépendent.

Cluster Environment

JAVA
- JAVA >= 8
Shell
- Bash >= 3
Docker
- Docker >= 1.12.5
  Ainsi, l’utilisation dans YARN 3 de la conteunerisation Docker implique une mise à jour vers Docker 1.12.5 ou supérieure.

Fichiers Hadoop Env

Pour chaque utilisateur Hadoop (développeurs ou administrateurs), les fichiers d’environnement constituent un gros problème. Comme vous l’aviez sans doute remarqué, c’était un bazar car il y avait des fichiers hadoop-env.sh (fonctionnant pour HDFS, MapReduce, YARN) et un autre comme yarn-env.sh (YARN seulement) mapreduce-env.sh (MR seulement). Et les noms des variables étaient également désordonnés.

Hadoop 3.x est l’occasion de mettre de l’ordre. Maintenant nous aurons :

hadoop-env.sh
- common placeholder
- Règle de précédence
  (yarn|hdfs)-env.sh > hadoop-env.sh > hard-coded default
hdfs-env.sh
Celui-ci est nouveau, il permet d’isoler l’environnement HDFS comme le fait le fichier dédié à YARN.
- HDFS_* remplace HADOOP_*
- Règle de précédence
  hdfs-env.sh > hadoop-env.sh > hard-coded default
yarn-env.sh
- YARN_* remplace HADOOP_*
- Règle de précédence
  yarn-env.sh > hadoop-env.sh > hard-coded default
HADOOP_HEAPSIZE
- JIRA HADOOP-10950
- déprécié
- remplacé par HADOOP_HEAPSIZE_MAX et HADOOP_HEAPSIZE_MIN
  ce qui est plus logique pour les configurations JAVA Xmx et Xms
- les unité seront exprimées en MB by default
  HADOOP_HEAPSIZE_MAX=4096
  HADOOP_HEAPSIZE_MAX=4g
- sera autotuné en fonction de la ressource hôte

Changements de configuration

Certaines configurations par défaut ont également changé (contenu de hdfs-site et yarn-site).

YARN

RM maximum d’applications complétée en State/Memory
- property : yarn.resourcemanager.max-completed-applications
  valeur : 10000 -> 1000
- property : yarn.resourcemanager.state-store.max-completed-application
  valeur : 10000 -> 1000

HDFS

Changement dans les ports daemon par défault. Tous les ports principaux ont changé par exemple :
- Namenode UI
  50470 -> 9871 (sécurisé)
  50070 -> 9870 (non sécurisé)
- Datanode UI
  50475 - > 9865 (sécurisé)
  50075 -> 9864 (non sécurisé)

Vous pouvez consulter la liste complète de la page HDFS-9427.

Ne vous inquiétez pas pendant la mise à jour : comme la configuration est déjà spécifiée, les ports ne changeront pas. Ainsi, l’interface utilisateur sera toujours disponible sur le même lien, MAIS si vous créez un nouveau cluster avec Apache Ambari par exemple, les ports seront les nouveaux par défaut.

Changements de classpath

Nous disposons désormais de l’isolement de classpath !

Les utilisateurs doivent reconstruire leurs applications avec des fichiers jar Hadoop-clients. Comme les classes Java serveur et client ont été séparées, les fichiers JAR ne contiennent pas les mêmes dépendances.

Les dépendances Hadoop ont fui vers le classpath de l’application - Goyave, Protobuf, Jackson, ne sont plus …
Chaque développeur Hadoop a déjà rencontré ces noms de classe.
Shaded jars disponibles - isole les clients en aval des dépendances tiers.
HADOOP-11804. C’est à propos de Hadoop-client 2.x qui tire les dépendances transitives de Hadoop et les injecte dans le classpath. Le problème est que la version des dépendances transitives peut être en conflit avec les dépendances de l’application. Ceci est résolu avec :
- hadoop-client-api pour les dépendances à la compilation
- hadoop-client-runtime pour les dépendances tierces à l’exécution
- hadoop-minicluster pour les dépendances de test
l’issue HDFS-6200 est résolue. hadoop-hdfs-jar contenait à la fois le serveur hdfs et les classes clientes. Maintenant, les clients devraient plutôt dépendre de hadoop-hdfs-client s’ils veulent faire une opération HDFS dans l’application. L’application sera isolée des classes de serveurs HDFS (donc moins de dépendances et des applications plus légères).
Aucune shaded jar YARN / MR.

Étapes de mise à jour

Pour rappel, la mise à niveau de type express est recommandée. Ainsi, une fois que vous avez négocié des interruptions de service avec vos clients, les exploitants de cluster doivent procéder aux étapes suivantes :

Installation des nouveaux paquets
Téléchargement de tous les nouveaux paquets (pas de sélection HDP / HDF)
Arrêt des services
Début de l’indisponibilité des services
Mises à jour
Ecrire de nouveaux fichiers hdfs-site.xml, core-site.xml … hdfs-env.sh !
Lien vers la nouvelle version
Utilisez les commandes hdp-select et hdf-select pour lier la nouvelle version, très utile.
Démarrage des services
C’est le bon moment pour prendre un café, croiser les doigts et espérer que tout ira bien.

Pour les exploitants utilisant Ambari, toutes ces étapes seront prises en charge par Ambari, et vous verrez les étapes en cours et le statut de la mise à jour.

Activation des nouvelles fonctionnalités

C’est une approche bien venue. Passer à Hadoop 3 est compliqué, mais pour ne pas l’effectuer en mode Big Bang, toutes les nouvelles fonctionnalités peuvent être activées par la suite. Par conséquent, les administrateurs de cluster et les exploitants peuvent penser à comment / quoi / quand activer chaque fonctionnalité. Rappelons-nous quelles sont-elles :

Qu’en est-il des autres composants

Hive avec Tez

Hive 3.0 supporte Hadoop 3
Hive ne supporte pas les rolling upgrades
- La layout sur disque des tables acid a changé et n’est pas backward compatible avec les versions 2.x
Support d’Hadoop 3 dans Tez
- Planifié pour la release 0.10.0
  TEZ-3923 Support du master sur Hadoop 3+ et création d’une branche 0.9.x distincte
  TEZ-3252 Umbrella JIRA activer le support Hadoop 3.x

Spark

SPARK-23534 Umbrella JIRA pour construire / tester avec Hadoop 3, des efforts en cours dans la communauté pour le résoudre.

Apache HBase

HBase 2.0 supporte Hadoop 3 (la version distribuée dans HDP 2.6 est la 1.2.1)
Ne supporte pas la mise à jour de type rolling upgrade

Apache Slider

Slider est retiré de l’incubateur Apache et sera directement intégré à YARN 3.x. Les applications de type long running utilisant Slider devront être portées de Slider à YARN.

Pig/Oozie

PIG-5253 Activation du support HADOOP 3 (planifié pour Pig 0.18.0)
OOZIE-2973 S’assurer que Oozie fonctionne avec Hadoop 3 (planifié pour Oozie 5.1.0)

Conclusion

La migration de Hadoop 2 (HDP 2.x) vers Hadoop 3 (HDP 3.x) ne sera pas une tâche facile, que vous soyez un administrateur de cluster ou un développeur de logiciel. Les équipes et les directions devront se coordonner étroitement pour s’assurer que tout fonctionne correctement. Les administrateurs de cluster devront tester plusieurs fois les étapes et les procédures de migration, et une fois prêts, les développeurs de logiciels devront adapter leurs applications et effectuer des tests d’intégration complets. Apache Ambari soulagera les administrateurs car il prend en charge l’écriture de nouveaux fichiers de configuration et gère les services.

Avant d’activer de nouvelles fonctionnalités, vous devez d’abord tester que tout est correct et vous donner quelques semaines de recul. Aucun retour en arrière n’est possible car chaque format sur le disque change. Mais tout cela est théorique. Enfin, le meilleur moyen est de le tester vous-même, que vous soyez dev ou ops. En guise de dernier conseil, je dirais que les administrateurs devraient tester la mise à jour avec HDP 3.0 dès sa sortie, mais il est plus sage d’attendre la version 3.1 avant d’envisager une mise en production.

Partagez cet article