2012-01-15 9 views
21

He configurado un entorno Hadoop distribuido dentro de VirtualBox: 4 instalaciones virtuales de Ubuntu 11.10, una que actúa como nodo maestro y las otras tres como esclavas. Seguí this tutorial para poner en funcionamiento la versión de un solo nodo y luego convertirla a la versión completamente distribuida. Estaba funcionando bien cuando estaba ejecutando 11.04; sin embargo, cuando actualicé a 11.10, se rompió. Ahora los registros de todos mis esclavos muestran el mensaje de error, que se repite hasta la saciedad:Hadoop Datanodes no puede encontrar NameNode

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). 

Y así sucesivamente. He encontrado otras instancias de este mensaje de error en Internet (y StackOverflow) pero ninguna de las soluciones ha funcionado (intenté cambiar las entradas core-site.xml y mapred-site.xml para que sean la dirección IP en lugar del nombre de host; cuádruple -comprobado /etc/hosts en todos los esclavos y maestro; maestro puede SSH sin contraseña en todos los esclavos). Incluso traté de revertir cada esclavo a una configuración de un solo nodo, y todos funcionarían bien en este caso (en esa nota, el maestro siempre funciona bien como un Datanode y el Namenode).

El único síntoma que he encontrado que parece dar una pista es que de cualquiera de los esclavos, cuando intento un telnet 192.168.1.10 54310, obtengo Connection refused, sugiriendo que hay algún acceso de bloqueo de reglas (que debe haber entrado en vigor cuando actualicé a 11.10).

Mi /etc/hosts.allow no ha cambiado, sin embargo. Probé la regla ALL: 192.168.1., pero no cambió el comportamiento.

Oh sí, y netstat en el maestro muestra claramente que están escuchando los puertos 54310 y 54311 de tcp.

¿Alguien tiene alguna sugerencia para que los esclavos Datanodes reconozcan el Namenode?

editar # 1: Al hacer un poco de hurgar con nmap (véanse los comentarios de esta entrada), estoy pensando en el problema está en mis archivos /etc/hosts. Esto es lo que se muestra para el maestro VM:

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 

Para cada esclavo VM:

127.0.0.1 localhost 
127.0.1.1 slaveX 
192.168.1.10 master 
192.168.1.1X slaveX 

Por desgracia, no estoy seguro de lo que he cambiado, pero el NameNode está siempre muriendo con la excepción de intentar vincular un puerto "que ya está en uso" (127.0.1.1:54310). Claramente estoy haciendo algo mal con los nombres de host y las direcciones IP, pero realmente no estoy seguro de qué se trata. ¿Pensamientos?

+0

¿Está ejecutando un firewall? Además, ¿el IP del Maestro sigue siendo 192.168.1.10? Preguntas estúpidas, pero a veces las personas pierden lo obvio. –

+0

Instala gufw usando el comando 'sudo apt-get install gufw' y verifica la configuración del firewall. También verifique el [tipo de conexión de red] (http://www.virtualbox.org/manual/ch06.html) en [VirtualBox] (http://www.virtualbox.org/manual/ch06.html). –

+0

'¿Alguien tiene alguna sugerencia para que los esclavos Datanodes reconozcan el Namenode?' - ¿Esto es más una consulta de Ubuntu que una de Hadoop? Debería ser 'cómo hacer que las máquinas virtuales esclavas hablen con la máquina virtual maestra'. –

Respuesta

36

¡Lo encontré! Al comentar la segunda línea del archivo /etc/hosts (la que tiene la entrada 127.0.1.1), netstat muestra los puertos NameNode vinculantes para la dirección 192.168.1.10 en lugar de la dirección local, y las máquinas virtuales esclavas lo encontraron. Ahhhhhhhh. ¡Misterio resuelto! Gracias por la ayuda de todos.

+0

gracias amigo, he estado intentando esto y eso durante horas ... tuve el mismo problema. vítores –

+0

¿Quiere decir, comentando 127.0.0.1 ip con localhost localhost.localdomain ...? – Techiee

+0

No, la entrada '127.0.1.1'. – Magsol

3

Tuve el mismo problema. @Magsol solución funcionó, pero hay que señalar que la entrada que necesita ser comentada es

127.0.1.1 masterxyz

en la máquina principal, no el 127.0.1.1 en el esclavo, aunque entonces lo que también . También necesita detener-all.sh y start-all.sh para hadoop, probablemente obvio.

Una vez que haya reiniciado hadoop comprobar el nodemaster aquí: http://masterxyz:50030/jobtracker.jsp

y observe el número de nodos disponibles para puestos de trabajo.

+1

Gracias pferrel para dejar en claro que es solo namenode el que está regresando al localhost y solo tenemos que modificar/etc/hosts (eliminar 127.0.1.1) y reiniciar todos los procesos de hadoop. – user1501382

5

Esta solución funcionó para mí. es decir, asegurarse de que el nombre que utilizó en la propiedad de núcleo-site.xml y mapred-site.xml:

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

es decir maestro se define en/etc/hosts como xyz.xyz.xyz.xyz de Maestro en las nodos maestro y esclavo. reinicie el NameNode y comprobar utilizando netstat -tuplen y para ver que está obligado a la dirección IP "externa"

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

y NO IP local o 192.168.xy 127.0.xy

1

Aunque esta respuesta no es la solución que el autor está buscando, otros usuarios pueden aterrizar en esta página pensando lo contrario, por lo que si usa AWS para configurar su clúster, es probable que las reglas de seguridad ICMP no se hayan habilitado en la página Grupos de seguridad de AWS. Mira lo siguiente: Pinging EC2 instances

Lo anterior resolvió el problema de conectividad desde los nodos de datos a los nodos maestros. Asegúrese de poder hacer ping entre cada instancia.

0

Estoy ejecutando un clúster de 2 nodos.

maestro 192.168.0.24 192.168.0.26
worker2

que estaba enfrentando el mismo problema de Reintentando conectar con el servidor: maestro/192.168.0.24: 54310 en los registros de mi máquina worker2. Pero las personas mencionadas anteriormente encontraron errores al ejecutar este comando - telnet 192.168.0.24 54310. Sin embargo, en mi caso, el comando telnet funcionó bien. Entonces revisé mi/etc/hosts

maestros/etc/hosts 127.0.0.1 localhost

192.168.0.24 ubuntu
192.168.0.24 192.168.0.26 maestro
worker2

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

Cuando llegué a http://localhost:50070 en el maestro, vi nodos en vivo: 2. Pero cuando hice clic en él, vi solo un nodo de datos que era del máster. Revisé jps tanto en master como en worker2. El proceso Datanode se estaba ejecutando en ambas máquinas.

Luego de varias pruebas y errores, me di cuenta de que mis máquinas master y worker2 tenían el mismo nombre de host "ubuntu". Cambié el nombre de host de worker2 de "ubuntu" a "worker2" y eliminé la entrada "ubuntu" de la máquina worker2.

Nota: Para cambiar el nombre de host edite el/etc/hostname con sudo.

¡Bingo!Funcionó :) Pude ver dos nodos de datos en la página de la interfaz de usuario dfshealth (locahost: 50070)

1

También me enfrenté a un problema similar. (Estoy usando ubuntu 17.0) Mantuve solo las entradas de maestro y esclavos en el archivo /etc/hosts. (En ambas máquinas maestro y esclavo)

127.0.0.1 localhost 
192.168.201.101 master 
192.168.201.102 slave1 
192.168.201.103 slave2 

en segundo lugar, > sudo gedit /etc/hosts.allow y agregar la entrada: ALL:192.168.201.

en tercer lugar, desactivado el firewall mediante sudo ufw disable

por último, he eliminado las dos carpetas NameNode y DataNode de todos los nodos en el clúster y vuelva a ejecutar

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

Para verificar el informe de salud desde la línea de comandos (que recomendaría)

y obtuve todos los nodos funcionando correctamente.

Cuestiones relacionadas