Hadoop Datanodes ne peut pas trouver NameNode
J'ai mis en place un environnement Hadoop distribué dans VirtualBox: 4 installations virtuelles Ubuntu 11.10, l'une agissant en tant que nœud maître, les trois autres en tant qu'esclaves. J'ai suivi ce tutoriel pour que la version à nœud unique soit opérationnelle et ensuite convertie en version entièrement distribuée. Cela fonctionnait très bien quand je courais 11.04; Cependant, lorsque je suis passé à 11.10, il est tombé en panne. Maintenant, tous les journaux de mes esclaves affichent le message d'erreur suivant, répété ad nauseum:
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).
Etc. J'ai trouvé d'autres occurrences de ce message d'erreur sur Internet (et StackOverflow ) mais aucune des solutions n'a fonctionné (tentative de modification des entrées core-site.xml et mapred-site.xml en adresses IP /etc/hosts quadruple-vérifié sur tous les esclaves et maître; maître peut SSH sans mot de passe sur tous les esclaves). J'ai même essayé de remettre chaque esclave dans une configuration à un seul noeud, et tout fonctionnerait bien dans ce cas (sur cette note, le maître fonctionne toujours bien en tant que Datanode et Namenode).
Le seul symptôme que je trouve qui semble donner l’avance est que, lorsque je tente un telnet 192.168.1.10 54310, j’obtiens Connection refused, ce qui suggère que certaines règles bloquent l’accès (qui doit être entré en vigueur lors de la mise à niveau vers 11.10).
Mon /etc/hosts.allow n'a pas changé, cependant. J'ai essayé la règle ALL: 192.168.1., mais cela n'a pas changé le comportement.
Oh oui, et netstat sur le maître indique clairement que les ports TCP 54310 et 54311 sont à l’écoute.
Quelqu'un a-t-il des suggestions pour que les Datanodes esclaves reconnaissent le Namenode?
EDIT # 1: En faisant quelques recherches avec nmap (voir les commentaires sur ce message), je pense que le problème est dans mes fichiers /etc/hosts. Voici ce qui est indiqué pour la machine virtuelle principale:
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
Pour chaque machine virtuelle esclave:
127.0.0.1 localhost
127.0.1.1 slaveX
192.168.1.10 master
192.168.1.1X slaveX
Malheureusement, je ne suis pas sûr de ce que j'ai changé, mais le NameNode est toujours en train de mourir, sauf d'essayer de lier un port "déjà utilisé" (127.0.1.1:54310). Il est clair que je fais quelque chose de mal avec les noms d'hôte et les adresses IP, mais je ne suis vraiment pas sûr de ce que c'est. Pensées?
Je l'ai trouvé! En commentant la deuxième ligne du fichier /etc/hosts (celle avec l'entrée 127.0.1.1), netstat affiche les ports NameNode qui se lient à l'adresse 192.168.1.10 au lieu de l'adresse locale, et les machines virtuelles esclaves l'ont trouvée. Ahhhhhhhh. Mystère résolu! Merci pour l'aide de tous.
Cette solution a fonctionné pour moi. Assurez-vous que le nom que vous avez utilisé dans les propriétés dans core-site.xml et mapred-site.xml:
<property>
<name>fs.default.name</name>
<value>hdfs://master:54310</value>
<final>true</final>
</property>
par exemple, maître est défini dans/etc/hosts en tant que maître xyz.xyz.xyz.xyz sur les DEUX nœuds maître et esclave . Redémarrez ensuite le namenode et vérifiez-le à l'aide de netstat -tuplen il est lié à l'adresse IP "externe"
tcp 0 xyz.xyz.xyz.xyz:54310 0.0.0.0:* LISTEN 102 107203 -
et PAS l'adresse IP locale 192.168.x.y ou 127.0.x.y
J'ai eu le même problème. La solution @Magsol a fonctionné, mais il convient de noter que l’entrée à commenter est
127.0.1.1 masterxyz
sur la machine maître, pas le 127.0.1.1 sur l'esclave, bien que je l'aie fait aussi. Aussi, vous devez arrêter-all.sh et start-all.sh pour hadoop, probablement évidente.
Une fois que vous avez redémarré hadoop, vérifiez ici le nodemaster: http: // masterxyz: 50030/jobtracker.jsp
et regardez le nombre de nœuds disponibles pour les travaux.
J'ai également fait face à un problème similaire. (J'utilise Ubuntu 17.0) Je n'ai gardé que les entrées de maître et d'esclaves dans le fichier /etc/hosts. (dans les machines maîtres et esclaves)
127.0.0.1 localhost
192.168.201.101 master
192.168.201.102 slave1
192.168.201.103 slave2
d'autre part, > Sudo gedit /etc/hosts.allow et ajoutez l'entrée: ALL:192.168.201.
troisièmement, désactivé le pare-feu à l'aide de Sudo ufw disable
enfin, j'ai supprimé les dossiers namenode et datanode de tous les nœuds du cluster, puis j'ai réexécuté
$HADOOP_HOME/bin> hdfs namenode -format -force
$HADOOP_HOME/sbin> ./start-dfs.sh
$HADOOP_HOME/sbin> ./start-yarn.sh
Pour vérifier le rapport de santé à partir de la ligne de commande (ce que je recommanderais)
$HADOOP_HOME/bin> hdfs dfsadmin -report
et j'ai tous les nœuds fonctionnent correctement.
Bien que cette réponse ne soit pas la solution recherchée par l'auteur, d'autres utilisateurs pourraient se poser sur cette page en pensant le contraire. Par conséquent, si vous utilisez AWS pour configurer votre cluster, il est probable que les règles de sécurité ICMP n'aient pas été activées dans AWS Security. Page Groupes. Examinez les éléments suivants: Pinging EC2 instances
Ce qui précède a résolu le problème de connectivité des nœuds de données aux nœuds maîtres. Assurez-vous que vous pouvez effectuer un ping entre chaque instance.
J'exécute un cluster à 2 nœuds.
192.168.0.24 master
192.168.0.26 travailleur2
J'étais confronté au même problème de nouvelle tentative de connexion au serveur: maître/192.168.0.24: 54310 dans les journaux de mon ordinateur worker2. Mais les personnes mentionnées ci-dessus ont rencontré des erreurs lors de l'exécution de cette commande - telnet 192.168.0.24 54310. Cependant, dans mon cas, la commande telnet a bien fonctionné. Puis j'ai vérifié mon fichier/etc/hosts
master/etc/hosts
127.0.0.1 localhost
192.168.0.24 ubuntu
192.168.0.24 master
192.168.0.26 travailleur2
worker2/etc/hosts
127.0.0.1 localhost
192.168.0.26 ubuntu
192.168.0.24 master
192.168.0.26 travailleur2
Lorsque j'ai appuyé sur http: // localhost: 50070 sur master, j'ai vu des nœuds vivants: 2. Mais lorsque j'ai cliqué dessus, je n'ai vu qu'un seul code de données, celui de master. J'ai vérifié jps à la fois sur master et worker2. Le processus Datanode était en cours d'exécution sur les deux machines.
Puis, après plusieurs essais et erreurs, je me suis rendu compte que mes machines maître et worker2 avaient le même nom d’hôte "ubuntu". J'ai changé le nom d'hôte du worker2 de "ubuntu" en "worker2" et j'ai supprimé l'entrée "ubuntu" de la machine worker2.
Remarque: pour changer le nom d'hôte, éditez le fichier/etc/hostname avec Sudo.
Bingo! Cela a fonctionné :) J'ai pu voir deux datanodes sur la page de l'interface utilisateur de dfshealth (locahost: 50070)