web-dev-qa-db-fra.com

Des codes de données sont en cours d'exécution et aucun noeud n'est exclu de cette opération.

J'ai mis en place un cluster Hadoop à plusieurs nœuds. NameNode et Secondary Code s'exécutent sur le même ordinateur et le cluster ne comporte qu'un seul Datanode. Tous les nœuds sont configurés sur des machines Amazon EC2.

Voici les fichiers de configuration sur le nœud maître:

masters
54.68.218.192 (public IP of the master node)

slaves
54.68.169.62 (public IP of the slave node)

core-site.xml

<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://localhost:9000</value>
</property>
</configuration>

mapred-site.xml

<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>

hdfs-site.xml

<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.namenode.name.dir</name>
<value>file:/usr/local/hadoop_store/hdfs/namenode</value>
</property>
<property>
<name>dfs.datanode.name.dir</name>
<value>file:/usr/local/hadoop_store/hdfs/datanode</value>
</property>
</configuration>

Maintenant, les fichiers de configuration sur le datanode:

core-site.xml

<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://54.68.218.192:10001</value>
</property>
</configuration>

mapred-site.xml

<configuration>
<property>
<name>mapred.job.tracker</name>
<value>54.68.218.192:10002</value>
</property>
</configuration>

hdfs-site.xml

<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.namenode.name.dir</name>
<value>file:/usr/local/hadoop_store/hdfs/namenode</value>
</property>
<property>
<name>dfs.datanode.name.dir</name>
<value>file:/usr/local/hadoop_store/hdfs/datanode</value>
</property>
</configuration>

les jps sur le Namenode donnent ceci:

5696 NameNode
6504 Jps
5905 SecondaryNameNode
6040 ResourceManager

et jps sur datanode:

2883 DataNode
3496 Jps
3381 NodeManager

ce qui me semble juste.

Maintenant, quand j'essaie d'exécuter une commande put:

hadoop fs -put count_inputfile /test/input/

Cela me donne l'erreur suivante:

put: File /count_inputfile._COPYING_ could only be replicated to 0 nodes instead of minReplication (=1).  There are 0 datanode(s) running and no node(s) are excluded in this operation.

Les journaux du datanode indiquent ce qui suit:

hadoop-datanode log
INFO org.Apache.hadoop.ipc.Client: Retrying connect to server:      54.68.218.192/54.68.218.192:10001. Already tried 8 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1000 MILLISECONDS)

journal de fil-nodemanager:

INFO org.Apache.hadoop.ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8031. Already tried 9 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1000 MILLISECONDS)

L’UI Web du gestionnaire de nœuds (50070) indique qu’il existe 0 nœuds actifs et 0 nœuds morts et que le dfs utilisé est 100%.

J'ai également désactivé IPV6.

Sur quelques sites Web, j'ai découvert que je devrais également éditer le fichier /etc/hosts. Je les ai aussi édités et ils ressemblent à ceci:

127.0.0.1 localhost
172.31.25.151 ip-172-31-25-151.us-west-2.compute.internal
172.31.25.152 ip-172-31-25-152.us-west-2.compute.internal

Pourquoi je reçois toujours l'erreur?

ubuntuhadoopamazon-ec2hdfshadoop2
19
Learner

Deux choses ont fonctionné pour moi, 

STEP 1: arrêtez hadoop et nettoyez les fichiers temporaires de hduser

Sudo rm -R /tmp/*

aussi, vous devrez peut-être supprimer et recréer/app/hadoop/tmp (surtout lorsque je change de version hadoop de 2.2.0 à 2.7.0

Sudo rm -r /app/hadoop/tmp
Sudo mkdir -p /app/hadoop/tmp
Sudo chown hduser:hadoop /app/hadoop/tmp
Sudo chmod 750 /app/hadoop/tmp

ETAPE 2: format de nom de code

hdfs namenode -format

Maintenant, je peux voir DataNode

hduser@prayagupd:~$ jps
19135 NameNode
20497 Jps
19477 DataNode
20447 NodeManager
19902 SecondaryNameNode
20106 ResourceManager
22
prayagupd

J'ai eu le même problème après un arrêt incorrect du nœud. Également coché dans l'interface utilisateur, le datanode n'est pas répertorié. 

Cela fonctionne maintenant après la suppression des fichiers du dossier datanode et le redémarrage des services.

stop-all.sh

rm -rf/usr/local/hadoop_store/hdfs/datanode/*

start-all.sh

8
Tamilkumaran S

@Apprenant, 
J'ai eu ce problème de datanodes non montré dans l'interface utilisateur Web de Namenode. Résolu par ces étapes dans Hadoop 2.4.1. 

faire cela pour tous les nœuds (maîtres et esclaves) 

1. Supprimez tous les fichiers temporaires (par défaut dans/tmp) - Sudo rm -R /tmp/*.
2. Essayez maintenant de vous connecter à tous les nœuds via ssh en utilisant ssh username@Host et ajoutez des clés dans votre maître en utilisant ssh-copy-id -i ~/.ssh/id_rsa.pub username@Host pour accorder un accès illimité des esclaves au maître.
3. Formatez le namenode à l'aide de hadoop namenode -format et essayez de redémarrer les démons. 

5
kishorer747

Sur ma situation, le service firewalld était en cours d'exécution. C'était sur la configuration par défaut. Et cela ne permet pas la communication entre les nœuds. Mon cluster hadoop était un cluster de test. Pour cette raison, j'ai arrêté le service. Si vos serveurs sont en production, vous devez autoriser les ports hadoop sur firewalld au lieu de 

service firewalld stop
chkconfig firewalld off
3
mustafacanturk

Dans ma situation, il me manquait les propriétés nécessaires dans hdfs-site.xml (Hadoop 3.0.0) installé à l'aide de HomeBrew sur MacOS. (Le file:/// n'est pas une faute de frappe.)

<property>
    <name>dfs.namenode.name.dir</name>
    <value>file:///usr/local/Cellar/hadoop/hdfs/namenode</value>
</property>

<property>
    <name>dfs.datanode.data.dir</name>
    <value>file:///usr/local/Cellar/hadoop/hdfs/datanode</value>
</property>
1
smooth_smoothie

J'ai eu la même erreur. Je n'avais pas la permission de système de fichiers HDFS. Alors je donne la permission à mon utilisateur:

chmod 777 /usr/local/hadoop_store/hdfs/namenode
chmod 777 /usr/local/hadoop_store/hdfs/datanode
1
Halil İbrahim Oymacı

Cela est probablement dû au fait que l'ID de cluster des codes de données et des codes de nom ou du gestionnaire de noeud ne correspondent pas. L'ID de cluster peut être vu dans le fichier VERSION situé à la fois dans le nom de code et le code de données.

Cela se produit lorsque vous formatez votre nom de code, puis que vous redémarrez le cluster, mais que les codes de données essaient toujours de se connecter en utilisant le clusterID précédent. Pour être connecté avec succès, vous devez disposer de l'adresse IP correcte et d'un ID de cluster correspondant sur les nœuds.

Essayez donc de reformater le namenode et les datanodes ou configurez simplement les datanodes et le namenode sur les dossiers nouvellement créés. 

Ceci devrait régler votre problème.

La suppression des fichiers du dossier datanodes en cours supprimera également l'ancien fichier VERSION et demandera un nouveau fichier VERSION lors de la reconnexion au namenode. 

Exemple, votre répertoire datanode dans la configuration est/hadoop2/datanode 

$ rm -rvf /hadoop2/datanode/*

Et puis redémarrez les services Si vous reformatez votre nom-clé, faites-le avant cette étape. Chaque fois que vous reformatez votre nom-code, il reçoit un nouvel ID. Cet ID est généré de manière aléatoire et ne correspond pas à l'ancien ID de vos codes de données. 

Donc, à chaque fois, suivez cette séquence 

si vous mettez en forme namenode then Supprimer le contenu du répertoire datanode OR, configurez datanode sur le répertoire nouvellement créé Puis démarrez votre namenode et les datanodes 

0
rajat

Avez-vous essayé de vider le dossier/tmp?.

Avant le nettoyage, un code de données ne s'est pas présenté

86528 SecondaryNameNode
87719 Jps
86198 NameNode
78968 RunJar
79515 RunJar
63964 RunNiFi
63981 NiFi

Après le nettoyage

Sudo rm -rf /tmp/*

Ça a fonctionné pour moi

89200 Jps
88859 DataNode
0
MagnumCodus

La valeur de la propriété {fs.default.name} dans core-site.xml, à la fois sur l'ordinateur maître et sur l'ordinateur esclave, doit pointer sur l'ordinateur maître. Donc ce sera quelque chose comme ça:

<property>
     <name>fs.default.name</name>
     <value>hdfs://master:9000</value>
</property>

où maître est le nom d'hôte dans le fichier/etc/hosts pointant vers le nœud maître.

0
Prabhat Swami

La solution @ mustafacanturk, la désactivation du pare-feu a fonctionné pour moi . Je pensais que les datanodes ont commencé car ils sont apparus lors de l’exécution de jps, mais lorsqu’ils essayaient de télécharger des fichiers, je recevais le message "0 nœuds en cours d’exécution". L’interface Web de ( http: // nn1: 50070 ) fonctionnait à cause du pare-feu . J'ai désactivé le pare-feu lors de l’installation de hadoop, mais pour une raison quelconque, il fonctionnait . Neverthelsess a parfois nettoyé ou recréé le les dossiers temporaires (hadoop.tmp.dir) ou même les dossiers dfs.data.dir et dfs.namenode.name.dir et la reformulation du serveur de noms était la solution.

0
Panagiotis Piperopoulos