HDFS - Démarrage du NameNode

Bonjour à tous !

Je suis en train de me former sur HBase & co.

J'essaye de faire des schémas simples afin de me familiariser avec tous les mécanismes, j'ai commencé par la couche la plus basse, HDFS.

D'après les informations que j'ai pu ressortir, le schéma suivant contient les étapes du démarrage du NameNode :

Les étapes seraient donc :
(0. On démarre en safemode)
1. Récupération du fichier fsimage sur le filesystem local et chargement en mémoire dans le namenode ;
2. récupération du fichier editLog sur le filesystem local et application des actions qu'il contient sur les informations du fsimage chargées en mémoire ;
3. on vide le fichier editLog ;
4. On crée une nouvelle version du fichier fsimage qui remplacera la précédente ;
5. Si un secondary NameNode existe, on fait une copie du fsimage (du moins, sur tous les serveurs sur lesquels on a paramétré un backup du fsimage) ;
6. Le mapping 6 est créé (ou contenu ?) dans le fsimage ;
7. On attend les retours (BlockReport) des DataNode ;
8. Le NameNode remplit la cartographie des blocks avec les retours contenu dans les BlockReport ;
9. Si le pourcentage (paramètre) de réplication des blocks est atteint, le NameNode lance la réplication des blocks qui n'ont pas encore atteint leur facteur de réplication ;
10. Le NameNode quitte le safemode

Est-ce que ce schéma représente au mieux ce qu'il se passe ? Je pense bien qu'il y a d'autres étapes importantes a ajouter.
Autres questions :
- Est-ce que mon tableau de carthographie doit également contenir les blocks / serveurs des réplications des blocks ? (comment est-ce stocké dans ce fichier)
- Est-ce qu'il y a d'autres choses dans le secondary NameNode que je peux rajouter ? Même fonctionnement que le NameNode ?
- Le FsImage contient le tableau de l'étape 6 ?

Alors mon schéma est très moche mais c'est surtout pour me familiariser avec le concept !

Merci pour vos suggestions / retours et bonne journée !

on oubli le démarrage du serveur http au plus tot dans la séquence de boot, a fin que quand
le boot part en sucette que les utilisateurs puissent suivre les progrès du démarrage sans à avoir
à se poser des questions, si certaines des ressources sont lente pendant le chargement du fsimage,
un démarrage cluster peut prendre une heure pour quitter le safe mode.

exemple sequence de démarrage dans la distribution hortonworks

https://issues.apache.org/jira/secur...DFS-4249.1.pdf

il y a aussi a quoi sert la creation d'un nouvel fsimage, très bien expliqué par cloudera en ce qui concerne
les checkpoint (point de restauration)

http://blog.cloudera.com/blog/2014/0...ing-in-hadoop/

contexte de recovery
http://blog.cloudera.com/blog/2012/0...d-file-system/

chez hortonworks
http://hortonworks.com/blog/hdfs-met...ies-explained/

lors d'un boot production, voila une idée du temps que cela peut prendre, alors voir au plus tot l'activité du démarrage est vital.

Analysis of startup logs of a production cluster with aprx 2000 nodes, with and without "-upgrade", showed four primary time sinks:

Namenode read/process/write of FSImage and Edits logs (10-15 minutes)
If upgrading, waiting for Datanode snapshots to complete (45+ minutes)
Namenode processing of Datanode registrations and Initial Block Reports (20 minutes to 2 hours)
Delay in full functionality upon leaving Safe Mode, due to high-intensity processing of over- and under-replicated blocks (several more minutes)
The first issue addressed was the Datanode startup time, primarily for snapshotting during -upgrade processing. HDFS-1445 reduced this time from about 10 minutes per volume to aprx 30 seconds per volume. Other potential improvements are noted in HDFS-1443, but they are an order of magnitude smaller.

organisation replicas

Pièce jointe 191466

Hadoop - NameNode, Node Checkpoint et la sauvegarde des noeuds 11

NameNode

Le NameNode stocke les métadonnées du HDFS. L'état de HDFS est stockée dans un fichier appelé fsimage et est la base des métadonnées. Au cours de l'exécution des modifications sont simplement écrits dans un fichier journal nommé modifications. Sur le prochain démarrage de l'NameNode l'état est lu à partir fsimage, les changements de modifications sont appliquées à cela et le nouvel état ​​est réécrit fsimage. Après cette édite est effacé et contient est maintenant prêt pour de nouvelles entrées de journal.

Noeud Checkpoint

Un nœud Checkpoint a été introduite pour résoudre les inconvénients de l'NameNode. Les changements sont simplement écrites sur les modifications et non fusionné pour fsimage pendant l'exécution. Si le NameNode fonctionne pendant un moment modifications reçoit immense et le prochain démarrage sera encore plus long parce que plus de changements doivent être appliqués à l'État de déterminer le dernier état ​​des métadonnées.

Le Noeud Checkpoint récupère périodiquement fsimage et édite du NameNode et les fusionne. L'état résultant est appelé point de contrôle. Après ceci est le résultat de télécharge le NameNode.

Il y avait aussi un type semblable de nœud appelé "noeud secondaire" mais il n'a pas le "télécharger sur NameNode" caractéristique. Ainsi, le NameNode besoin d'aller chercher de l'état de la NameNode secondaire. Il a également été confussing parce que le nom suggère que la NameNode secondaire prend la demande si l'NameNode échoue qui est pas le cas.

La sauvegarde des noeuds

Le Noeud Backup offre les mêmes fonctionnalités que le nœud de Checkpoint, mais est synchronisée avec le NameNode. Il n'a pas besoin d'aller chercher régulièrement les changements parce qu'il reçoit un strem des modifications du système de fichiers. à partir de la NameNode. Il détient l'état actuel en mémoire et juste besoin d'enregistrer ce à un fichier image pour créer un nouveau point de contrôle.


Qu'est-ce que c'est secondary namenode ?

Ce namenode secondaire est important dans le processus de récupération du système au cas de plantage du namenode principal. Il ne s'agit donc pas d'un remplacant du namenode primaire.

Secondary namenode vérifie périodiquement l'état du namenode principal. A chaque vérification il copie les fichiers de backup : edits et fsimage. Sa structure des dossiers est donc quasi identique que celle du namenode principal. La seule différence se trouve dans le sous-répertoire previous.checkpoint. C'est là où secondary namenode place le dernier état du namenode principal récupéré.

Cependant, les informations collectées ne doivent pas être forcément à jour. Secondary namenode n'est pas une réplication du namenode principal et il peut contenir des données périmées suite à des opérations effectuées après la création de son point de contrôle. L'intervalle de création du checkpoint (point de contrôle) peut être précisé dans la propriété de configuration fs.checkpoint.period.


https://www.youtube.com/watch?v=CsYdlAwwGtE


https://www.youtube.com/watch?v=sLOS2maCyyc


https://www.youtube.com/watch?v=WBgiUB2Hny8

Bonjour Bordi,

Merci bien pour toute la documentation, je vais jeter un coup d'oeil à tout ça lorsque j'ai un peu de temps.

Bonjour,

pour répondre à toutes tes questions, je te recommande de suivre le tutoriel suivant :
https://juvenal-chokogoue.developpez.com/tutoriels/apprendre-travailler-hbase/

Il répondre à toutes tes questions.