it-swarm.com.de

Es werden Datenknoten ausgeführt, und in dieser Operation werden keine Knoten ausgeschlossen

Ich habe einen Hadoop-Cluster mit mehreren Knoten eingerichtet. Der NameNode und der Secondary-Namenknoten werden auf derselben Maschine ausgeführt, und der Cluster verfügt nur über einen Datanode. Alle Knoten sind auf Amazon EC2-Computern konfiguriert.

Folgende Konfigurationsdateien befinden sich auf dem Master-Knoten:

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>

Nun befinden sich die Konfigurationsdateien auf dem 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>

die JPS-Lauf auf der Namenode geben Folgendes:

5696 NameNode
6504 Jps
5905 SecondaryNameNode
6040 ResourceManager

und jps auf datanode:

2883 DataNode
3496 Jps
3381 NodeManager

was mir richtig erscheint.

Wenn ich jetzt versuche, einen Put-Befehl auszuführen:

hadoop fs -put count_inputfile /test/input/

Es gibt folgende Fehlermeldung:

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.

Die Protokolle auf dem Datanode besagen Folgendes:

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)

garn-Nodemanager-Protokoll:

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)

Die Web-Benutzeroberfläche von Node Manager (50070) zeigt, dass es 0 aktive Knoten und 0 tote Knoten gibt und dass die DFS-Werte 100% betragen

Ich habe auch IPV6 deaktiviert.

Auf einigen Websites habe ich herausgefunden, dass ich auch die /etc/hosts-Datei bearbeiten sollte. Ich habe sie auch bearbeitet und sie sehen so aus:

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

Warum bekomme ich immer noch den Fehler?

19
Learner

Zwei Dinge funktionierten für mich, 

SCHRITT 1: Stoppen Sie hadoop und reinigen Sie temporäre Dateien von hduser

Sudo rm -R /tmp/*

Außerdem müssen Sie möglicherweise/app/hadoop/tmp löschen und neu erstellen (meistens wenn ich die hadoop-Version von 2.2.0 in 2.7.0 geändert habe)

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

SCHRITT 2: Formatname

hdfs namenode -format

Jetzt kann ich DataNode sehen

[email protected]:~$ jps
19135 NameNode
20497 Jps
19477 DataNode
20447 NodeManager
19902 SecondaryNameNode
20106 ResourceManager
22
prayagupd

Ich hatte das gleiche Problem, nachdem der Knoten nicht ordnungsgemäß heruntergefahren wurde. Auch in der Benutzeroberfläche geprüft, wird der Datanode nicht aufgelistet. 

Nach dem Löschen der Dateien aus dem Ordner "datanode" und dem Neustart von Diensten funktioniert es jetzt.

stop-all.sh

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

start-all.sh

8
Tamilkumaran S

@Lerner, 
Ich hatte dieses Problem mit Datanodes, die nicht in der Web-Benutzeroberfläche von Namenode angezeigt werden. Gelöst durch diese Schritte in Hadoop 2.4.1. 

tun Sie dies für alle Knoten (Master und Slaves) 

1. Entfernen Sie alle temporären Dateien (standardmäßig in/tmp) - Sudo rm -R /tmp/*.
2. Versuchen Sie nun, über ssh eine Verbindung zu allen Knoten herzustellen, indem Sie ssh [email protected] verwenden. Fügen Sie Schlüssel in Ihrem Master hinzu. Verwenden Sie ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected], um dem Master uneingeschränkten Zugriff auf die Slaves zu gewähren.
3. Formatieren Sie den Namen mit hadoop namenode -format und starten Sie die Daemons neu. 

5
kishorer747

In meiner Situation wurde ein Firewall-Dienst ausgeführt. Es war eine Standardkonfiguration. Und es erlaubt keine Kommunikation zwischen Knoten. Mein Hadoop-Cluster war ein Testcluster. Aus diesem Grund habe ich den Dienst eingestellt. Wenn sich Ihre Server in der Produktion befinden, sollten Sie hadoop-Ports auf firewalld zulassen 

service firewalld stop
chkconfig firewalld off
3
mustafacanturk

In meiner Situation fehlten mir die erforderlichen Eigenschaften in hdfs-site.xml (Hadoop 3.0.0), die mit HomeBrew unter MacOS installiert wurden. (Der file:/// ist kein Tippfehler.)

<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

Ich hatte den gleichen Fehler. Ich hatte keine Erlaubnis zum HDFS-Dateisystem. Also gebe ich meinem Benutzer die Erlaubnis:

chmod 777 /usr/local/hadoop_store/hdfs/namenode
chmod 777 /usr/local/hadoop_store/hdfs/datanode

Ich habe das gleiche Problem in meinem Einzelknoten-Cluster.

Ich habe die folgenden Schritte ausgeführt, um dieses Problem zu beheben:
1. Das überprüfte Datenknotenprotokoll im Protokollverzeichnis hat ergeben, dass Namensknoten-Cluster-ID und Datenknoten-Cluster-ID unterschiedlich sind.
2. Erstellen Sie ein leeres Datenknotenverzeichnis:
rm -rvf/hadoop/hdfs/datanode/*
3. stop-all.sh
4. hdfs namenode -format
5. start-all.sh
6. jps
27200 NodeManager
26129 NameNode
26595 SecondaryNameNode
5539 GradleDaemon
2355 Main
2693 GradleDaemon
27389 Jps
26846 ResourceManager
26334 DataNode

Das funktioniert bei mir.

0

Dies liegt wahrscheinlich daran, dass die Cluster-ID der Datenknoten und der Namensknoten oder der Knotenmanager nicht übereinstimmen. Die Cluster-ID ist in der VERSION-Datei zu sehen, die sich sowohl im Namensknoten als auch in den Datenknoten befindet.

Dies geschieht, wenn Sie den Namennamen formatieren und dann den Cluster erneut starten, die Datenknoten jedoch weiterhin versuchen, die Verbindung mit der vorherigen Cluster-ID herzustellen. Für eine erfolgreiche Verbindung benötigen Sie die korrekte IP-Adresse und eine entsprechende Cluster-ID auf den Knoten.

Versuchen Sie daher, den Namen der Namen und der Datenanoden neu zu formatieren, oder konfigurieren Sie einfach die Datenanoden und den Namen der neu erstellten Ordner. 

Das sollte dein Problem lösen.

Durch das Löschen der Dateien aus dem aktuellen datanodes-Ordner wird auch die alte VERSION-Datei entfernt und eine neue VERSION-Datei angefordert, während die Verbindung mit dem Namenscode wiederhergestellt wird. 

Das Datenverzeichnis in der Konfiguration lautet beispielsweise/hadoop2/datanode 

$ rm -rvf /hadoop2/datanode/*

Und starten Sie dann die Dienste erneut Wenn Sie Ihren Namensnamen neu formatieren, tun Sie dies vor diesem Schritt. Bei jeder Neuformatierung Ihres Namensnamens erhält er eine neue ID. Diese ID wird zufällig generiert und stimmt nicht mit der alten ID in Ihren Datanodes überein 

Folge also jedes Mal dieser Reihenfolge 

wenn Sie namenode .__ formatieren. Löschen Sie anschließend den Inhalt des Datenanordnungsverzeichnisses OR. Starten Sie dann Ihren Namen und die Datenknoten 

0
rajat

Haben Sie versucht, den Ordner/tmp zu löschen.

Vor der Bereinigung wurde kein Datanode angezeigt

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

Nach dem Aufräumen

Sudo rm -rf /tmp/*

Es hat für mich funktioniert

89200 Jps
88859 DataNode
0
MagnumCodus

Der Wert für die Eigenschaft {fs.default.name} in core-site.xml auf dem Master- und dem Slave-Computer muss auf den Master-Computer zeigen. So wird es ungefähr so ​​sein:

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

dabei ist Master der Hostname in der Datei/etc/hosts, die auf den Master-Knoten zeigt.

0
Prabhat Swami

@mustafacanturk Lösung, das Deaktivieren der Firewall funktionierte für mich ..__ Ich dachte, dass Datanodes anfingen, weil sie beim Ausführen von jps auftauchten, aber beim Versuch, Dateien hochzuladen, erhielt ich die Meldung "0 Nodes running" ..__ Webschnittstelle zu ( http: // nn1: 50070 ) funktionierte wegen der Firewall . Ich habe die Firewall bei der Installation von hadoop deaktiviert, aber aus irgendeinem Grund war es nicht ..__ Temp-Ordner (hadoop.tmp.dir) oder sogar die Ordner dfs.data.dir und dfs.namenode.name.dir und das Neuformatieren des Namenservers war die Lösung.