Comment désactiver le mode sans échec pour le service NameNode sur mon cluster Amazon EMR ?

Brève description

Lorsque j'essaie d'exécuter une tâche Apache Hadoop ou Apache Spark sur un cluster Amazon EMR, je reçois l'un des messages d'erreur suivants :

« Impossible de créer file/user/test.txt._COPYING_. Le nœud de nom est en mode sans échec. »

« org.apache.hadoop.hdfs.server.namenode.SafeModeException : Impossible de supprimer /user/hadoop/.sparkStaging/application_15xxxxxxxx_0001. Le nœud de nom est en mode sans échec. Il a été activé manuellement. Utilisez « hdfs dfsadmin -safemode leave » pour désactiver le mode sans échec. NamenodeHostName:ip-xxx-xx-xx-xx.ec2.internal »

Le mode sans échec pour NameNode est un mode en lecture seule pour le cluster de système de fichiers distribué Hadoop (HDFS). Dans Safemode, vous ne pouvez apporter aucune modification au système de fichiers ou aux blocs. Une fois que les DataNodes indiquent que la plupart des blocs du système de fichiers sont disponibles, le NameNode quitte automatiquement Safemode. Toutefois, le NameNode peut entrer en Safemode pour les raisons suivantes :

• L'espace disponible est inférieur à la quantité d'espace requise pour le répertoire de stockage NameNode. La quantité d'espace requise pour le répertoire NameNode est définie dans le paramètre dfs.namenode.resource.du.reserved.
• NameNode n'est pas en mesure de charger FsImage et EditLog en mémoire.
• NameNode n'a pas reçu le rapport de blocage provenant de DataNode.
• Certains nœuds du cluster sont peut-être hors service. Les blocs des nœuds ne sont donc pas disponibles.
• Certains blocs sont peut-être endommagés.

Vérifiez les journaux NameNode pour trouver la cause racine du problème dans l'emplacement du journal /var/log/hadoop-hdfs/.

Solution

Avant de quitter Safemode, confirmez que vous savez et comprenez pourquoi le NameNode est bloqué dans Safemode. Vérifiez l'état de tous les DataNodes et des journaux NameNode.

Important : Dans certains cas, la désactivation manuelle du mode Safemode peut entraîner une perte de données.

Pour désactiver manuellement Safemode, exécutez la commande suivante :

sudo -u hdfs hadoop dfsadmin -safemode leave

En fonction de la cause première de l'erreur, effectuez une ou plusieurs des étapes de dépannage suivantes pour désactiver Safemode.

Passer à un cluster disposant de plusieurs nœuds principaux

La vérification des points de contrôle n'est pas automatique dans les clusters dotés d'un seul nœud principal. Cela signifie que les journaux de modification HDFS ne sont pas sauvegardés sur un nouvel instantané (FsImage) et supprimés. HDFS utilise les journaux de modification pour enregistrer les modifications du système de fichiers entre les instantanés. Il est recommandé de supprimer manuellement les journaux de modification d'un cluster comportant un seul nœud principal. Si vous ne supprimez pas manuellement les journaux de modification, ils risquent d'utiliser tout l'espace disque de /mnt. Pour résoudre ce problème, lancez un cluster disposant de plusieurs nœuds principaux. Les clusters dotés de plusieurs nœuds principaux assurent la haute disponibilité de HDFS NameNode. La haute disponibilité du NameNode résout le problème du point de contrôle.

Pour en savoir plus, consultez Planifier et configurer des nœuds principaux.

Supprimer les fichiers inutiles de /mnt

L'espace disque minimum disponible pour /mnt est spécifié par le paramètre dfs.namenode.resource.du.reserved. Lorsque la quantité de disque disponible dans le répertoire /mnt tombe à une valeur inférieure à la valeur définie dans dfs.namenode.resource.du.reserved, NameNode entre en mode sans échec. La valeur par défaut de dfs.namenode.resource.du.reserved est de 100 Mo. Lorsque NameNode est en mode sans échec, aucune modification du système de fichiers ou des blocs n'est autorisée. Par conséquent, la suppression des fichiers inutiles de /mnt peut aider à résoudre le problème.

Pour supprimer les fichiers dont vous n'avez plus besoin, procédez comme suit :

1.    Connectez-vous au nœud principal via SSH.

2.    Pour vérifier que NameNode est en mode sans échec en raison d'un espace disque insuffisant, vérifiez les journaux NameNode. Ces journaux se trouvent dans /var/log/hadoop-hdfs. Les journaux peuvent ressembler à ce qui suit si l'espace disque est suffisant :

2020-08-28 19:14:43,540 WARN org.apache.hadoop.hdfs.server.namenode.NameNodeResourceChecker (org.apache.hadoop.hdfs.server.namenode.FSNamesystem$NameNodeResourceMonitor@5baaae4c): Space available on volume '/dev/xvdb2' is 76546048, which is below the configured reserved amount 104857600

Les journaux peuvent ressembler à ce qui suit si l'espace disque est insuffisant :

2020-09-28 19:14:43,540 WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem (org.apache.hadoop.hdfs.server.namenode.FSNamesystem$NameNodeResourceMonitor@5baaae4c): NameNode low on available disk space. Already in safe mode.

3.    Vérifiez que NameNode est toujours en mode sans échec en exécutant la commande suivante :

[root@ip-xxx-xx-xx-xxx mnt]# hdfs dfsadmin -safemode get
Safe mode is ON

4.    Supprimez les fichiers inutiles de /mnt.

Si le répertoire in/mnt/namenode/current occupe une grande quantité d'espace sur un cluster avec un nœud principal, créez un nouvel instantané (FSImage). Supprimez ensuite les anciens journaux de modification.

Par exemple, vous exécutez un script qui exécute les actions suivantes :
Génère un nouvel instantané.
Sauvegarde les anciens journaux d’édition dans un compartiment Amazon Simple Storage Service (Amazon S3).
Supprime les journaux de modification.

Exemple de script :

#!/bin/bash
hdfs dfsadmin -safemode enter
hdfs dfsadmin -saveNamespace
sudo su - root -c "hdfs dfs -put /mnt/namenode/current/*edits_[0-9]* s3://doc-example-bucket/backup-hdfs/"
sudo su - root -c "rm -f /mnt/namenode/current/*edits_[0-9]*"
sudo su - root -c "rm -f /mnt/namenode/current/seen*"
hdfs dfsadmin -safemode leave

Remarque : Le script précédent ne supprime pas les journaux des modifications en cours.

5.    Vérifiez la quantité d'espace disque disponible dans /mnt. Si l'espace disponible est supérieur à 100 Mo, vérifiez à nouveau l'état de Safemode. Ensuite, désactivez Safemode :

[hadoop@ip-xxx-xx-xx-xxx ~]$ hdfs dfsadmin -safemode get
Safe mode is ON
[hadoop@ip-xxx-xx-xx-xxx ~]$ hdfs dfsadmin -safemode leave
Safe mode is OFF

Si /mnt dispose toujours de moins de 100 Mo d'espace disponible, effectuez l'une ou plusieurs des opérations suivantes :

• Supprimer d'autres fichiers.
• Augmentez la taille du volume /mnt.

Supprimer d'autres fichiers

1.    Connectez-vous au nœud principal via SSH.

2.    Parcourez le répertoire /mnt :

cd /mnt

3.    Déterminez quels dossiers utilisent le plus d'espace disque :

sudo du -hsx * | sort -rh | head -10

4.    Continuez à enquêter jusqu'à ce que vous trouviez la source du problème de l'espace disque. Par exemple, si le dossier var utilise une grande quantité d'espace disque, vérifiez les sous-dossiers les plus volumineux qui se trouvent dans var :

cd var
sudo du -hsx * | sort -rh | head -10

5.    Une fois que vous avez déterminé quel fichier ou dossier prend beaucoup d'espace disque, choisissez de supprimer ces fichiers. Assurez-vous de ne supprimer que les fichiers dont vous n'avez plus besoin. Les fichiers journaux compressés dans /mnt/var/log/hadoop-hdfs/ et /mnt/var/log/hadoop-yarn/ qui sont déjà sauvegardés dans le compartiment de journalisation d'Amazon S3 se prêtent bien à la suppression. Ces fichiers journaux sont de bons candidats à la suppression.

6.    Après avoir supprimé les fichiers inutiles, vérifiez à nouveau l'état du mode sans échec. Ensuite, désactivez Safemode :

[hadoop@ip-xxx-xx-xx-xxx ~]$ hdfs dfsadmin -safemode get
Safe mode is ON
[hadoop@ip-xxx-xx-xx-xxx ~]$ hdfs dfsadmin -safemode leave
Safe mode is OFF

Vérifiez la présence de blocs/fichiers corrompus ou manquants

1.    Exécutez la commande suivante pour afficher un rapport qui vous aidera à vérifier l'état du cluster. Le rapport indique également le pourcentage de blocs sous-répliqués et le nombre de répliques manquantes.

hdfs fsck /

2.    Pour chaque fichier de la liste, exécutez la commande suivante pour localiser le DataNode pour chaque bloc du fichier :

hdfs fsck example_file_name -locations -blocks -files

Remarque : remplacez example_file_name par le nom de votre fichier.

Les messages que vous voyez sont similaires aux messages suivants :

0. BP-762523015-192.168.0.2-1480061879099:blk_1073741830_1006 len=134217728 MISSING!
1. BP-762523015-192.168.0.2-1480061879099:blk_1073741831_1007 len=134217728 MISSING!
2. BP-762523015-192.168.0.2-1480061879099:blk_1073741832_1008 len=70846464 MISSING!

Dans les messages précédents, vous pouvez trouver le DataNode qui a stocké le bloc. Par exemple, « 192.168.0.2. » Vous pouvez ensuite consulter les journaux de ce DataNode pour rechercher les erreurs liées à l'ID du bloc (blk_xxx). Les nœuds sont souvent interrompus, ce qui entraîne des blocs manquants.

3.    Pour supprimer les fichiers endommagés, quittez Safemode. Exécutez ensuite la commande suivante :

hdfs dfs -rm example_file_name

Remarque : remplacez example_file_name par le nom de votre fichier.

Utilisez les métriques CloudWatch pour surveiller l'état de santé de HDFS

Les métriques Amazon CloudWatch suivantes peuvent aider à surveiller les causes potentielles de l'entrée d'un NameNode dans Safemode :

• HDFSUtilization: pourcentage de stockage HDFS utilisé.
• MissingBlocks : nombre de blocs pour lesquels HDFS ne possède aucune réplique. Il peut s'agir de blocs corrompus.
• UnderReplicatedBlocks : nombre de blocs qui doivent être répliqués une ou plusieurs fois.

---

Informations connexes

Guide de l'utilisateur de HDFS (depuis le site Web d'Apache Hadoop)