Hadoop Datanodes не могут найти NameNode

Я установил распределенную среду Hadoop в VirtualBox: 4 виртуальные установки Ubuntu 11.10, один из которых действует как master node, а остальные три - в качестве подчиненных. Я выполнил этот учебник, чтобы запустить версию single- node, а затем преобразован в полностью распределенную версию. Он работал отлично, когда я работал 11.04; однако, когда я обновился до 11.10, он сломался. Теперь все журналы моих подчиненных операторов показывают следующее сообщение об ошибке, повторяющееся объявление tause:

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

И так далее. Я нашел другие экземпляры этого сообщения об ошибке в Интернете (и qaru.site/info/246302/...), но ни одно из этих решений не сработало (попробовал изменить core-site.xml и Записи mapred-site.xml должны быть IP-адресом, а не именем хоста, проверено в четыре раза /etc/hosts на всех ведомых устройствах и master, мастер может SSH без пароля на все подчиненные устройства). Я даже попробовал возвратить каждого подчиненного обратно к одиночной настройке node, и все они будут работать нормально в этом случае (в этой заметке мастер всегда отлично работает как Datanode, так и Namenode).

Единственный признак, который я нашел, который, кажется, дает преимущество, заключается в том, что из любого из ведомых, когда я пытаюсь выполнить telnet 192.168.1.10 54310, я получаю Connection refused, предполагая, что есть некоторый запрет доступа к правилам (который должен иметь вступил в силу, когда я обновился до 11.10).

Однако мой /etc/hosts.allow не изменился. Я попробовал правило ALL: 192.168.1., но это не изменило поведение.

О да, и netstat на главном экране четко отображаются TCP-порты 54310 и 54311.

У кого-нибудь есть предложения, чтобы заставить подчиненные Datanodes распознавать Namenode?

РЕДАКТИРОВАТЬ # 1. В процессе работы с nmap (см. комментарии к этому сообщению), я думаю, что проблема в моих файлах /etc/hosts. Это то, что указано для главной виртуальной машины:

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

Для каждой подчиненной виртуальной машины:

127.0.0.1    localhost
127.0.1.1    slaveX
192.168.1.10 master
192.168.1.1X slaveX

К сожалению, я не уверен, что я изменил, но NameNode теперь всегда умирает, за исключением попытки связать порт "уже используемый" (127.0.1.1:54310). Я явно делаю что-то неправильно с именами хостов и IP-адресами, но я действительно не уверен, что это такое. Мысли?

Ответ 1

Я нашел его! Комментируя вторую строку файла /etc/hosts (тот, у которого есть запись 127.0.1.1), netstat показывает привязку портов NameNode к адресу 192.168.1.10 вместо локального, и подчиненные виртуальные машины нашли его. Ahhhhhhhh. Тайна решена! Спасибо за помощь всем.

Ответ 2

Это решение сработало для меня. i.e убедитесь, что имя, которое вы использовали в свойстве в core-site.xml и mapred-site.xml:

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

то есть. master определяется в /etc/hosts как мастер xyz.xyz.xyz.xyz на главных и подчиненных узлах BOTH. Затем перезапустите namenode и проверьте использование netstat -tuplen и убедиться, что он связан с "внешним" IP-адресом

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

и НЕ локальный IP 192.168.x.y или 127.0.x.y

Ответ 3

У меня были такие же проблемы. Решение @Magsol работало, но следует отметить, что запись, которую нужно прокомментировать, -

127.0.1.1 masterxyz

на главном компьютере, а не на 127.0.1.1 на подчиненном устройстве, хотя я тоже это сделал. Также вам нужно stop-all.sh и start-all.sh для hadoop, вероятно, очевидно.

Как только вы перезапустили hadoop, проверьте nodemaster здесь: http://masterxyz:50030/jobtracker.jsp

и посмотрите количество узлов, доступных для заданий.

Ответ 4

Хотя этот ответ не является решением, которое ищет автор, другие пользователи могут приземляться на этой странице, думая иначе, поэтому, если вы используете AWS для настройки вашего кластера, вполне вероятно, что правила безопасности ICMP не были включены на странице групп AWS Security. Посмотрите на следующее: Pinging экземпляры EC2

Вышеописанная проблема решена из узлов данных на ведущие узлы. Убедитесь, что вы можете выполнять ping между каждым экземпляром.

Ответ 5

Я также столкнулся с подобной проблемой. (Я использую ubuntu 17.0) Я сохранил только записи мастера и ведомых в файле /etc/hosts. (как в ведущей, так и в ведомой машинах)

127.0.0.1  localhost
192.168.201.101 master
192.168.201.102 slave1
192.168.201.103 slave2

во-вторых, > sudo gedit /etc/hosts.allow и добавьте запись: ALL:192.168.201.

в-третьих, отключить брандмауэр с помощью sudo ufw disable

наконец, я удалил как папки namenode, так и datanode из всех узлов в кластере и перезапустил

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

Чтобы проверить отчет о работоспособности из командной строки (что я бы рекомендовал)

$HADOOP_HOME/bin> hdfs dfsadmin -report

и я правильно использовал все узлы.

Ответ 6

Я запускаю кластер из двух узлов.

192.168.0.24 мастер
192.168.0.26 worker2

У меня возникла проблема с повторной попыткой подключения к серверу: master/192.168.0.24: 54310 в машинных журналах work2. Но упомянутые выше люди столкнулись с ошибками, выполняющими эту команду: telnet 192.168.0.24 54310. Однако в моем случае команда telnet работала нормально. Затем я проверил файл /etc/hosts

master/etc/hosts
127.0.0.1 localhost
192.168.0.24 ubuntu
192.168.0.24 мастер
192.168.0.26 worker2

worker2/etc/hosts
127.0.0.1 localhost
192.168.0.26 ubuntu
192.168.0.24 мастер
192.168.0.26 worker2

Когда я нажал http://localhost:50070 на master, я увидел Live узлы: 2. Но когда я нажал на него, я увидел только один datanode который был мастером. Я проверил jps как на хозяина, так и на работника2. Процесс обработки данных был запущен на обеих машинах.

Затем после нескольких проб и ошибок я понял, что мои машины master и worker2 имеют одно и то же имя хоста "ubuntu" . Я изменил имя хоста worker2 с "ubuntu" на "worker2" и удалил запись "ubuntu" с машины worker2.

Примечание. Чтобы изменить имя хоста, измените имя /etc/hostname на sudo.

Бинго! Это сработало:) Я смог увидеть два datanodes на странице пользовательского интерфейса dfshealth (locahost: 50070)