Mécanisme de haute disponibilité et mécanisme de fédération de Hadoop

1. Mécanisme de haute disponibilité d'Hadoop

Le mécanisme de haute disponibilité consiste principalement à résoudre le problème de point de défaillance unique de NameNode

Dans Hadoop, l'emplacement du NameNode est très important. Les informations de métadonnées de l'ensemble du système de fichiers HDFS sont gérées par le NameNode. La disponibilité du NameNode détermine directement la disponibilité de Hadoop. Une fois que le processus NameNode échoue, il affectera l'ensemble cluster. Utilisation normale . Par conséquent, dans les applications pratiques, un cluster haute disponibilité (HA) est généralement utilisé et deux NameNodes sont configurés dans le cluster hadoop.

Dans un cluster HA typique, deux machines indépendantes sont configurées en tant que NameNodes. Dans un cluster de travail, l'une des machines NameNode est à l'état actif et l'autre à l'état de veille . Active NameNode est responsable de toutes les opérations client dans le cluster, tandis que Standby agit comme un serveur esclave. Les machines de secours conservent un état suffisant pour fournir un basculement rapide (si nécessaire).

Composants ZKFC:

• ZKFailoverController

  Il s'agit d'un contrôleur de basculement basé sur Zookeeper , qui est responsable du contrôle de la commutation active et en veille du NameNode. ZKFailoverController surveillera l'état de santé du NameNode . Lorsqu'une anomalie est détectée dans Active NameNode, il procède à une nouvelle élection via Zookeeper pour terminer le basculement entre les états Actif et Veille.

• HealthMonitor

  Appelez régulièrement l'interface HAServiceProtocol RPC (monitorHealth et getServiceStatus) de NameNode pour surveiller l'état d'intégrité de NameNode et des commentaires à ZKFailoverController

• ActiveStandbyElector

  Réception de la demande d'élection de ZKFC , complétez automatiquement les élections primaires et de réserve via Zookeeper et rappelez la méthode de commutation primaire / d'attente de ZKFailoverController pour basculer le NameNode entre Actif et Veille une fois l'élection terminée .

DataNode

Le NameNode contient des informations de métadonnées HDFS et des informations de bloc de données (blockmap). Les informations de bloc de données sont signalées activement aux Active NameNode et Standby NameNode via le DataNode.

Système de stockage partagé

Le système de stockage partagé est responsable du stockage des métadonnées HDFS (EditsLog). Active NameNode (écriture) et Standby NameNode (lecture) réalisent la synchronisation des métadonnées via le système de stockage partagé . Lors du basculement entre actif et veille, le nouveau Active NameNode doit garantir la synchronisation des métadonnées est terminée pour fournir des services externes

Le fonctionnement spécifique de la haute disponibilité est illustré dans la figure ci-dessus.

• Système de stockage partagé pour assurer la synchronisation des données entre deux NameNodes
• Réalisez le changement d'état de NameNode via ZKFC et Zookeeper
  1. HealthMonitor surveille l'état du NameNode actif et signale immédiatement à ZKFalloverController lorsqu'il constate que le NameNode est en panne.
  2. ZKFalloverController signale à ActiveStandbyElector que le NameNode est en panne
  3. ActiveStandbyElector dit à Zookeeper de réélire un nouveau NameNode
  4. Répondre aux nouveaux résultats de l'élection d'ActiveStandbyElector une fois l'élection de gardien de zoo terminée
  5. ActiveStandbyElector rapporte les nouveaux résultats des élections de ZKFalloverController
  6. ZKFalloverController modifie l'état du NameNode d'origine
  7. ZKFalloverController rend le statut NameNode nouvellement élu devient Actif

Un autre point à noter est que SecondaryNameNode n'est pas un NameNode de sauvegarde en haute disponibilité

La principale différence entre les deux peut être illustrée dans les deux figures suivantes

Pour connaître les différences spécifiques, veuillez consulter ce blog https://blog.csdn.net/andyguan01_2/article/details/88696239

2. Mécanisme de fédération de Hadoop

Le mécanisme de fédération consiste principalement à résoudre le problème de l'expansion horizontale de NameNode

L'architecture NameNode unique fait que HDFS a des problèmes potentiels d'évolutivité et de performances du cluster. Lorsque le cluster est suffisamment grand, la mémoire utilisée par le processus NameNode peut atteindre des centaines de G et le NameNode devient un goulot d'étranglement des performances. Par conséquent, le schéma d'expansion horizontale namenode -Federation, qui est le mécanisme de fédération, est proposé.

Il existe plusieurs NameNodes dans le fonctionnement de NameNode, et la situation de plusieurs NameNodes signifie qu'il existe plusieurs espaces de noms (espaces de noms), qui sont différents de plusieurs NameNodes en mode HA, qui ont le même espace de noms. Différents espaces de noms sont isolés et différents espaces de noms ont leurs numéros correspondants, et les répertoires correspondants sont créés dans les DataNodes correspondants, ce qui signifie que les données dans différents répertoires sous les DataNodes sont gérées par différents espaces de noms.

En résumé:

Plusieurs NN partagent les ressources de stockage dans un cluster et chaque NN peut fournir des services indépendamment.

Chaque NN définit un pool de stockage avec un ID distinct, et chaque DN fournit du stockage pour tous les pools de stockage.

Le DN rapportera les informations de bloc à son NN correspondant en fonction de l'ID du pool de stockage, et en même temps, le DN rapportera les ressources de stockage locales disponibles à tous les NN.

Fédération HDFS insuffisante

La fédération HDFS ne résout pas complètement le problème du point de défaillance unique. Bien qu'il y ait plusieurs namenode / namespaces, à partir d'un seul namenode / namespace, il y a toujours un seul point de défaillance: si un namenode échoue, les fichiers correspondants gérés par lui ne sont pas accessibles. Chaque namenode de la Fédération est toujours le même que l'implémentation précédente sur HDFS, équipé d'un namenode secondaire, de sorte que le namenode principal puisse être raccroché et utilisé pour restaurer les informations de métadonnées.

Par conséquent, lorsque la taille du cluster est vraiment grande, le schéma de déploiement HA + Federation sera adopté. Autrement dit, chaque namenodes articulaire est ha.