Cet article est la deuxième partie du compte-rendu du Hadoop Summit, qui a eu lieu à Amsterdam début avril. Elle est consacrée aux retours d’expérience sur l’exploitation d’Hadoop, dans la vraie vie, et en particulier en contexte multi-tenant.

Capacity planning in multi-tenant Hadoop deployments

(Sumeet Singh, Yahoo!)

Un modèle de pragmatisme, qui montre “par quels bouts” prendre une plateforme aussi variée et complexe qu’Hadoop lorsque l’on veut la dimensionner. En fait, on ressort de là avec l’impression qu’on aurait aussi bien pu faire cette présentation, puisqu’il s’agissait d’un bon mélange de bon sens et de règles de 3. Seulement voilà, tout le monde n’a pas le recul de Yahoo! sur l’exploitation d’Hadoop.

En interne, Yahoo! offre un accompagnement architecture à ses projets, avec une offre d’hébergement multi-tenant. Les services offerts sont MapReduce, YARN, HDFS, HBase et Storm.

En pratique 3 types de clusters isolés existent : MapReduce sur HDFS, HBase et Storm. Cette isolation vient du constat que les facteurs limitants (importants pour le dimensionnement) ne sont pas les mêmes selon les services :

• pour MapReduce, ce sont par ordre décroissant d’importance : le stockage, la mémoire, le débit, puis enfin la latence
• pour HBase, ce sont : le débit, la latence, la mémoire, le stockage
• pour Storm enfin, ce sont : le débit, la consommation CPU, la latence

Pour chaque service et chaque facteur, et par ordre de priorité, les exigences projet sont traduites en métriques, qui sont ensuite croisées avec les caractéristiques de l’offre matérielle standard pour aboutir à un nombre de serveurs. Facile non ? Toute l’intelligence, et la beauté de l’exercice, est dans le choix de ces métriques intermédiaires. En effet Hadoop est une machine complexe et identifier les quelques chiffres qui comptent n’est pas simple...

Il n’est pas question de détailler ici toute la méthode, qui a été exposée en toute transparence et que vous trouverez sur les slides de la présentation quand ils seront publiés. Donnons un exemple pour MapReduce.

Le débit et la latence dépendent du nombre de mappers et de reducers. Le nombre de mappers provient du nombre de splits (unités de découpage technique) du fichier d’entrée, donc de la taille de celui-ci ; le nombre de reducers est spécifié par le projet. Pour les traitements complexes enchaînant plusieurs étapes, il faut les combiner pour obtenir un débit et une latence globale. Ajouter une pincée d’extrapolation à partir d’échantillons, des heuristiques sur l’exécution spéculative et l’impact du shuffle & sort, et vous obtenez un nombre de serveurs. Les autres facteurs (stockage, mémoire) ont donné lieu à un calcul similaire, il reste à prendre le nombre de serveur maximum donné pour savoir combien l’IT doit provisionner au projet demandeur.

Au final, l’IT de Yahoo! a ouvert aux projets des calculateurs (un par type de service), qui simplifient l’exécution des règles. Les IHM des services techniques ainsi que les logs historisés permettent de s’assurer a posteriori que le SLA demandé est bien rempli, et donc d’ajuster si nécessaire.

Enfin, Yahoo! prévoit de mettre fin à l’isolation des clusters par service, avec l’amélioration des gestionnaires de ressources fournis par YARN.

Hadoop operations powered by… Hadoop

(Adam Kawa, Spotify)

Le titre est à double sens : une source essentielle des indicateurs d’exploitation est bien sûr le monitoring d’Hadoop, mais on peut aussi exploiter ses capacités analytiques pour suivre l’utilisation de son cluster en consolidant les données qu’il produit - monitoring mais pas seulement. C’était une session très proche du terrain, en provenance du plus gros client européen d’Hortonworks à ce jour (694 noeuds, 12.000 jobs).

Patterns d’usage HDFS

La recherche d’un changement dans ces patterns peut aider au diagnostic d’incidents ; ici la survenue un beau jour de pauses du name node, vite imputées au garbage collector. Les tendances (évolution de la distribution des tailles de fichiers) ont d’abord été visualisées à partir d’extraits du fichier fsImage, qui est la “base de données” sur disque du name node.

Chez Spotify, le changement de tendance a pu être corrélé a posteriori à la migration sur YARN : à partir de ce jour le cluster s’est mis à stocker de très nombreux petits fichiers (< 1 Mo), ce qui met une pression importante sur la mémoire name node. Un état des lieux avec HDFS-DU a permis de révéler qu’il s’agissait des logs YARN (répertoire /app-logs). CQFD...

Autres usages basés sur les mêmes techniques d’introspection sur HDFS :

• attribution du stockage par utilisateur ou par groupe propriétaire
• détection de fichiers dupliqués potentiels
• mesure de l’efficacité des jobs MapReduce (matérialisée par l’équilibre de la distribution des fichiers résultats)
• adaptation des durées de rétention, ou du taux de réplication, à l’usage réel (dates d’accès et de modification enregistrées dans le fsImage), pour favoriser les datasets “chauds”

Les tendances peuvent être injectées dans Ganglia.

[NDLR : la technique de base d’analyse de fsImage, et certaines des idées ci-dessus, sont expliquées sur le site Apache d’Hadoop. C’est vraiment simple à mettre en oeuvre]

Vers des jobs MapReduce auto-apprenants

En mesurant le “débit” de données des jobs (par ex. avec le temps d’exécution, ou la métrique Bytes/CPU), on peut tester des ajustements et ainsi faire évoluer le paramétrage de ces jobs vers une meilleure efficacité.

Spotify a pu montrer, sur des tests, qu’un gain de x 7 en temps d’exécution pouvait être obtenu en tunant la taille des splits. Le paramétrage était injecté automatiquement à chaque exécution, au moyen d’un hook.

Les mêmes métriques peuvent aussi servir à identifier les noeuds de calcul anormalement lents, en regardant la distribution du débit. Selon l’expérience de Facebook, 50% des incidents (alertes, lenteurs, …) seraient explicables par le comportement anormal de 3 ou 4% des machines. La technique a donc un intérêt certain sur les gros clusters.

Quelques outils pour mettre en oeuvre ces pratiques :

• Zlatanitor (outil interne Spotify, bientôt open source et supportant YARN)
• Replephant (non YARN)
• hRaven (non YARN)

Il y a enfin des informations intéressantes dans les logs des applications YARN, sur les tâches trop lentes ou en erreur, qui ralentissent les traitements. Ces logs sont des fichiers binaires (TFile). D’expérience, il suffit de regarder les quelques dernières lignes de la sortie d’erreur (stderr) pour qualifier beaucoup de problèmes.

Taux d’utilisation des files du Capacity Scheduler

Il s’agit de confronter l’usage réel des files, aux capacités déclarées dans la configuration du scheduler. L’exemple montre qu’on peut calculer cet usage, au moyen des métriques JMX exposées par le scheduler. En l’occurrence, l’outil jmxtrans permet d’interroger ces métriques et de les diffuser facilement vers des fichiers, vers Ganglia, …

Pour mesurer l’usage global du cluster

LinkedIn a écrit un outil dédié à l’agrégation d’informations sur tout un cluster : White Elephant (simplement cité en séance, sans plus de détails).

En résumé, un tour d’horizon sur les indicateurs essentiels et une très bonne base de départ pour réfléchir à la gouvernance d’un cluster multi-utilisateurs. Tous les outils sont là, il existe quantité d’API exposées par les composants d’Hadoop (Spotify ne les exploite pas à ce jour) permettant de faire un suivi fin de l’usage du cluster, au global ou par utilisateur/équipe.

Hadoop, from lab to turnkey deployed 24/7 production

(Jean-Baptiste Node, Criteo)

Cette session avait pas mal de points communs avec celle de Spotify, relatée plus haut : un accent sur l’exploitation d’Hadoop (pour des clusters de taille identique), et un contenu en bonne partie technique -- accessible et fort utile. En revanche il s’agissait plutôt ici de bonnes pratiques, que d’un catalogue d’outils de suivi à mettre en place. Les deux sessions se complètent donc très bien. Et puis bon, cocorico quoi.

Criteo vise 1.000 noeuds Hadoop en production d’ici à la fin de l’année. On est donc dans un contexte de scalabilité, pas seulement technique mais avec 4 “facettes” : administration, tuning, réseau et usage.

Administration

Il ne faut pas que l’exploitant soit un goulet d’étranglement. Les pratiques tournent autour d’une automatisation maximale. Premier conseil : versionner les changements de configuration, et traiter celle-ci comme du code (pratique IaaC, Infrastructure as a Code). En l’occurrence, Criteo utilise Chef, et reste indépendant de la distribution Hadoop ; un passage de Cloudera à Hortonworks est d’ailleurs prévu et devrait être sans douleur. Le résultat est un délai de 3h (dont 2h30 de formatage disque) pour qu’une nouvelle machine déballée rejoigne le cluster.

Booter les machines sur le réseau (PXE et ramdisk) offre de nombreux avantages, au prix d’un petit coût en mémoire :

• gestion uniforme de tous les disques de la machine, sans se préoccuper des disques systèmes
• serveurs stateless au niveau de l’OS
• pas de concurrence d’I/O entre le système et les processus
• et un corollaire sympathique : l’obligation de centraliser les logs à travers le réseau

Les mises à jour d’Hadoop sont faites à froid dans des plages d’indisponibilité planifiées, pour éviter les surprises (apparemment fréquentes), qui arrivent lors des rolling upgrades et finissent par obliger à éteindre le cluster. Un cluster de pré-production permet de tester les mises à jour.

Tuning

Hadoop, par l’activité qu’il génère, met l’infrastructure à rude épreuve (un DDoS pour l’infrastructure, selon l’expression de l’intervenant). Le tuning de configuration est important. La session donne quelques éléments, sous forme de retours d’expérience : caches réseau (DNS et ARP), read-ahead des disques, bande passante de la mémoire, niveaux de log, … La difficulté est que l’usage variant beaucoup dans le temps, il est difficile de faire des benchmarks précis.

Le réseau

C’est un élément à prendre en compte tôt dans la conception car il est difficile à ajuster après coup. De plus, le fonctionnement d’Hadoop impose une topologie en mesh, différente de ce qu’on peut voir dans des infrastructures plus classiques comme le web et qu’on peut être tenté d’appliquer (là aussi cela sent le retour d’expérience…).

La topologie “logique” du cluster, au niveau de la configuration d’Hadoop (rack awareness), est importante pour les performances mais aussi pour la maintenance car elle permet d’effectuer des opérations rack par rack.

L’usage

La réponse à l’augmentation de l’usage est le multi-tenant, un des grands thèmes du Hadoop Summit. De ce point de vue, les possibilités de la plateforme sont simplement utilisés : quotas HDFS, Capacity Scheduler plutôt que le Fair Scheduler (qui repose sur des poids arbitraires à configurer a priori, sans offrir de garantie de ressources).

Concernant la sécurité, là aussi la recommandation est de s’y prendre en avance car la mise en place n’est pas simple, malgré le pilotage possible avec Chef. Le cluster est dans son “royaume” (domaine Kerberos) propre, avec ses propres comptes de service, et des relations de confiance avec les annuaires autorisent le SSO sans ajouter de charge d’administration sur le cluster.

Enfin, l’utilisation de proxies facilite l’utilisation du cluster par l’intégration avec des outils existants. Exemple avec HttpFS, qui permet d’accéder à HDFS en lecture/écriture (avec curl par exemple), avec un débit de 200 à 400 MB/s.