Hadoop Datanodes не может найти NameNode

Question

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

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

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

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

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

О, да, и netstat на ведущем устройстве ясно показывает, что порты TCP 54410 и 54311 прослушивают.

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

РЕДАКТИРОВАТЬ # 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-адресами, но я действительно не уверен, что это такое. Мысли?

Answer 1

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

Answer 2

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

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

т.е. Мастер определяется в / etc / hosts как мастер xyz.xyz.xyz.xyz на обоих главных и подчиненных узлах. Затем перезапустите 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

Answer 3

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

127.0.1.1 masterxyz

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

После того, как вы перезапустили hadoop, проверьте хозяина узла здесь: http://masterxyz:50030/jobtracker.jsp

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

Answer 4

Я тоже сталкивался с подобной проблемой. (Я использую 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

и все узлы работают правильно.

Answer 5

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

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

Answer 6

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

192.168.0.24 мастер
192.168.0.26 работник2

Я столкнулся с той же проблемой при повторном подключении к серверу: master / 192.168.0.24: 54310 в журналах моей машины worker2. Но упомянутые выше люди столкнулись с ошибками при выполнении этой команды - 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 работник2

worker2 / etc / hosts
127.0.0.1 localhost
192.168.0.26 Ubuntu
192.168.0.24 мастер
192.168.0.26 работник2

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

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

Примечание. Чтобы изменить имя хоста, отредактируйте / etc / hostname с помощью sudo.

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