it-swarm.com.de

Hadoop-Datanodes können NameNode nicht finden

Ich habe eine verteilte Hadoop-Umgebung in VirtualBox eingerichtet: 4 virtuelle Ubuntu 11.10-Installationen, von denen eine als Master-Knoten und drei als Slaves fungieren. Ich folgte diesem Tutorial , um die Einzelknotenversion zum Laufen zu bringen und dann in die vollständig verteilte Version zu konvertieren. Es lief einwandfrei, als ich 11.04 lief; Als ich jedoch auf 11.10 aufrief, ging es kaputt. Nun zeigen alle Protokolle meiner Slaves die folgende Fehlermeldung, die sich wiederholt, jedoch nicht wiederholt:

INFO org.Apache.hadoop.ipc.Client: Retrying connect to server: master/192.168.1.10:54310. Already tried 0 time(s).
INFO org.Apache.hadoop.ipc.Client: Retrying connect to server: master/192.168.1.10:54310. Already tried 1 time(s).
INFO org.Apache.hadoop.ipc.Client: Retrying connect to server: master/192.168.1.10:54310. Already tried 2 time(s).

Und so weiter. Ich habe andere Instanzen dieser Fehlermeldung im Internet gefunden (und StackOverflow ), aber keine der Lösungen hat funktioniert (versucht, die Einträge core-site.xml und mapred-site.xml als IP-Adresse zu ändern als Hostname; vierfach überprüft /etc/hosts für alle Slaves und Master; Master kann SSH-kennwortlos in alle Slaves einfügen). Ich habe sogar versucht, jeden Slave auf ein Single-Node-Setup zurückzusetzen, und sie würden in diesem Fall alle einwandfrei funktionieren (in diesem Sinne funktioniert der Master immer als Datanode und als Namenode).

Das einzige Symptom, das ich gefunden habe, scheint eine Spur zu sein, ist, dass von einem der Slaves, wenn ich einen telnet 192.168.1.10 54310 versuche, Connection refused angezeigt wird, was darauf hindeutet, dass es einige Regeln gibt, die den Zugriff blockieren 11.10).

Mein /etc/hosts.allow hat sich jedoch nicht geändert. Ich habe die Regel ALL: 192.168.1. ausprobiert, aber das Verhalten wurde nicht geändert.

Ach ja, und netstat auf dem Master zeigt deutlich, dass die TCP-Ports 54310 und 54311 zuhören.

Hat jemand Anregungen, um die Slave-Datanodes dazu zu bringen, die Namenode zu erkennen?

EDIT # 1: Wenn ich mit nmap herumstöbere (siehe Kommentare zu diesem Beitrag), denke ich, dass das Problem in meinen /etc/hosts-Dateien liegt. Folgendes ist für die Master-VM aufgeführt:

127.0.0.1    localhost
127.0.1.1    master
192.168.1.10 master
192.168.1.11 slave1
192.168.1.12 slave2
192.168.1.13 slave3

Für jede Slave-VM:

127.0.0.1    localhost
127.0.1.1    slaveX
192.168.1.10 master
192.168.1.1X slaveX

Leider bin ich nicht sicher, was ich geändert habe, aber der NameNode stirbt jetzt immer mit der Ausnahme, dass versucht wird, einen Port zu binden, "der bereits verwendet wird" (127.0.1.1:54310). Ich mache offensichtlich etwas falsch mit den Hostnamen und IP-Adressen, aber ich bin mir wirklich nicht sicher, was es ist. Gedanken?

21
Magsol

Ich habe es gefunden! Durch das Auskommentieren der zweiten Zeile der /etc/hosts-Datei (der mit dem 127.0.1.1-Eintrag) zeigt netstat die NameNode-Ports, die an die 192.168.1.10-Adresse und nicht an die lokale Adresse gebunden sind. Ahhhhhhhh. Geheimnis gelüftet! Danke für die Hilfe aller.

37
Magsol

Diese Lösung hat für mich funktioniert. Vergewissern Sie sich, dass der Name, den Sie in core-site.xml und mapred-site.xml in property angegeben haben:

<property>
   <name>fs.default.name</name>
   <value>hdfs://master:54310</value>
   <final>true</final>
 </property>

dh master ist in/etc/hosts als xyz.xyz.xyz.xyz master auf BEIDEN Master- und Slave-Knoten definiert .. _. Starten Sie anschließend den namenode neu und überprüfen Sie mit netstat -tuplen.__ die "externe" IP-Adresse

tcp        0      xyz.xyz.xyz.xyz:54310         0.0.0.0:*                   LISTEN      102        107203     - 

und NICHT lokale IP 192.168.x.y oder 127.0.x.y

5
devl

Ich hatte das gleiche Problem. Die @Magsol-Lösung hat funktioniert, aber es sollte beachtet werden, dass der Eintrag auskommentiert werden muss 

127.0.1.1 masterxyz

auf der Master-Maschine nicht die 127.0.1.1 auf dem Slave, obwohl ich das auch getan habe. Sie müssen auch stop-all.sh und start-all.sh für hadoop einstellen, wahrscheinlich offensichtlich.

Nachdem Sie hadoop neu gestartet haben, überprüfen Sie den Knotenmaster hier: http: // masterxyz: 50030/jobtracker.jsp

und sehen Sie sich die Anzahl der für Jobs verfügbaren Knoten an.

3
pferrel

Ich war auch mit einem ähnlichen Problem konfrontiert. (Ich verwende Ubuntu 17.0) Ich habe nur die Einträge von Master und Slaves in der /etc/hosts-Datei behalten. (sowohl in Master- als auch in Slave-Maschinen)

127.0.0.1  localhost
192.168.201.101 master
192.168.201.102 slave1
192.168.201.103 slave2

zweitens > Sudo gedit /etc/hosts.allow und fügen Sie den folgenden Eintrag hinzu: ALL:192.168.201.

drittens die Firewall mit Sudo ufw disable deaktiviert

schließlich löschte ich sowohl den namenode- als auch den datanode-ordner von allen Knoten im Cluster und führte ihn erneut aus

$HADOOP_HOME/bin> hdfs namenode -format -force
$HADOOP_HOME/sbin> ./start-dfs.sh
$HADOOP_HOME/sbin> ./start-yarn.sh

So prüfen Sie den Integritätsbericht von der Befehlszeile aus (was ich empfehlen würde)

$HADOOP_HOME/bin> hdfs dfsadmin -report

und ich habe alle Knoten richtig funktionieren.

1
Raxit Solanki

Obwohl diese Antwort nicht die Lösung ist, die der Autor sucht, können andere Benutzer auf dieser Seite anders denken. Wenn Sie AWS zum Einrichten Ihres Clusters verwenden, ist es wahrscheinlich, dass ICMP-Sicherheitsregeln in AWS Security nicht aktiviert wurden Gruppen-Seite Sehen Sie sich Folgendes an: Pinging EC2-Instanzen

Mit dem Vorstehenden wurde das Verbindungsproblem von Datenknoten zu Master-Knoten gelöst. Stellen Sie sicher, dass Sie zwischen den einzelnen Instanzen pingen können.

1
MasterV

Ich verwende einen Cluster mit 2 Knoten. 

192.168.0.24 master 
192.168.0.26 worker2 

Ich hatte das gleiche Problem des Wiederholens der Verbindung zum Server: master/192.168.0.24: 54310 in meinen Worker2-Computerprotokollen. Bei den oben genannten Personen sind jedoch Fehler aufgetreten - telnet 192.168.0.24 54310. In meinem Fall funktionierte der telnet-Befehl jedoch einwandfrei. Dann habe ich meine/etc/hosts-Datei überprüft

master/etc/hosts 
127.0.0.1 localhost
192.168.0.24 ubuntu 
192.168.0.24 master 
192.168.0.26 worker2 

worker2/etc/hosts 
127.0.0.1 localhost 
192.168.0.26 ubuntu 
192.168.0.24 master 
192.168.0.26 worker2 

Als ich http: // localhost: 50070 am Master traf, sah ich Live-Knoten: 2. Aber als ich darauf klickte, sah ich nur eine Datanode, die vom Master war. Ich habe jps sowohl auf master als auch auf worker2 geprüft. Der Datanode-Prozess wurde auf beiden Maschinen ausgeführt.

Nach mehreren Versuchen und Fehlern bemerkte ich, dass meine Master- und Worker2-Maschinen den gleichen Hostnamen "ubuntu" hatten. Ich änderte den Hostnamen von Worker2 von "Ubuntu" in "Worker2" und entfernte den Eintrag "Ubuntu" vom Worker2-Computer. 

Hinweis: Um den Hostnamen zu ändern, bearbeiten Sie den/etc/hostname mit Sudo. 

Bingo! Es hat funktioniert :) Ich konnte zwei Datanodes auf der Dfshealth-UI-Seite sehen (locahost: 50070)

0
Vignesh Iyer