Le bon fonctionnement d’un cluster Hadoop dépend de plusieurs facteurs tels que la configuration des ressources matérielles, la mémoire, le disque dur (stockage I / O) et le réseau. Cela reste une tâche compliquée qui exige des connaissances minimales sur l’architecture de l’écosystème Hadoop et son principe de fonctionnement. Pour faciliter cette phase primordiale, nous allons poser quatre questions qui nous aideront à prendre des décisions en estimant le dimensionnement d’un cluster.

  • Comment planifier mes besoins en stockage?
  • Comment planifier mes besoins en CPU?
  • Comment planifier mes besoins en mémoire?
  • Comment planifier mes besoins réseau?

Pour exécuter des traitements Hadoop et obtenir une performance maximale, le cluster doit être configuré correctement. Il faut envisager le volume de données que les utilisateurs finaux traiteront sur le cluster, estimer son taux de croissance attendu et établir une politique de rétention (combien de temps conserver les données). Cela conduira à déterminer le nombre de machines (nœuds) dont nous avons besoin pour traiter les données d’entrée de manière efficace et par la suite déterminer la capacité du mémoire disque de chacune.

Il faut se rappeler que l’architecture maître-esclave d’ Hadoop est très gourmande en mémoire et CPU. Elle comporte deux composants principaux:

  • JobTracker: la composante essentielle dans cette architecture qui surveille les tâches en cours d’exécution sur le cluster
  • TaskTracker: exécute des tâches sur chaque nœud du cluster

Aussi, hadoop est une plateforme de calcul basée sur le modèle de programmation parallèle de la couche MapReduce qui, pour être efficiente, exige deux conditions :

  • Les jeux de données doivent pouvoir être découpés en petits blocs unitaires et indépendants les uns des autres (par exemple, un fichier texte de 10Go peut être divisé en 40.960 blocs de 256 Mo chacun, et chaque ligne de texte dans n’importe quel bloc de données peut être traitée indépendamment)
  • La deuxième condition est qu’elle doit tenir compte de la localisation des données (data locality) c’est-à-dire les traitements doivent pouvoir être déplacés là où se trouvent les données, pas le contraire.

 

En outre, pour une meilleure performance, il faut penser à HDFS qui nécessite trois conditions :

  • Des disques rapides en terme de débit sur des lectures et écritures séquentielles de gros blocs de données (64Mo, 128Mo ou encore 256Mo)
  • Un système de fichiers sous-jacent (le système de fichiers du système d’exploitation) supportant ce mode d’utilisation de manière intensive
  • Un réseau performant pour transférer les jeux de données et gérer la réplication

 

HDFS, lui-même, est basé sur une architecture Maître/Esclave avec deux composantes principales:

  • NameNode / NameNode secondaire :
  • Gèrent les méta-informations (répertoires, noms, attributs et localisation des fichiers) ainsi que la réplication des blocs du cluster
  • Nécessite beaucoup de mémoire (memory bound)
  • Des DataNodes.
  • Gère l’état d’un nœud HDFS et permet d’interagir avec ses blocs
  • Nécessite beaucoup d’I/O lors des traitements et des transferts de données (I/O bound)

En ce qui concerne la bande passante, elle est utilisée en deux instances:

  • au cours du processus de la réplication et suite à une écriture de fichier (phase shuffle du programme Map Reduce)
  • pendant le rééquilibrage du facteur de réplication lorsqu’un nœud ne répond pas ou bien suit à un ajout de fichier

Pour mieux comprendre le dimensionnement d’un cluster Hadoop, prenons l’exemple suivant:

Un client souhaite alimenter son cluster de 100Go par jour et souhaite également répliquer 3 fois les blocs HDFS sur les datanodes. Ce client possède des disques de 3 To.

Avec cela, nous sommes en mesure de prévoir l’espace de stockage nécessaire ainsi que le nombre de DataNodes. Les règles de calculs sont simples. Puisque l’alimentation quotidienne est de 100 Go et le facteur de réplication est de 3, donc, l’espace occupé sur le cluster est de 300 Go par jour. Notons bien que 30% de la taille d’un disque est réservé hors HDFS, c’est à dire 0,9 To (taille HDFS est 2,1 To).

Le Nombre de DataNodes à 1 an (sans croissance mensuelle) correspond à l’espace occupé sur le cluster par l’alimentation quotidienne multiplié par 365 jours (par an) que l’on divise par la suite par  2,1 To (taille d’un disque dédié à HDFS). Cela correspond à 48 datanodes (100 To / 2,1 To = 48).

Sur le NameNode et Secondary NameNode, 4 coeurs physiques à 2Ghz suffiront amplement.

Sur les datanodes, le nombre de cœurs physique dépend du nombre maximum de tâches ou traitements. Il ya des traitements intensifs en I/O comme l’indexation, la recherche, l’import, l’export des données et des traitements en CPU comme les statistiques, l’analyse…etc. Pour les travaux en I/O, un CPU entre 2Ghz et 2,4Ghz suffit. Pour les travaux en CPU, un CPU entre 2,6Ghz et 3Ghz suffit.

Pour ce qu’il en est de la mémoire, le namenode et le secondarynamenode doivent être à l’identique, leurs RAM doivent contenir la RAM pour gérer le Cluster HDFS, 2Go de RAM pour le processe namenode et 4Go pour l’OS.

Concernant la mémoire des datanodes, les clients en général souhaitent réaliser des traitements sur des Cluster CPU bound, donc la RAM doit être 8Go multiplié par le nombre de cœurs physiques en ajoutant à cela 2Go pour le process datanode, 2Go pour le process Tasktracker et 4 Go pour l’OS.

Besma Ben Rhouma, consultante Big Data.