Назад | Перейти на главную страницу

Обратный и прямой DNS настроены правильно, но иногда задание MapReduce не выполняется

С тех пор, как мы переключили наш кластер на связь через частные интерфейсы и создали DNS-сервер с правильными зонами прямого и обратного просмотра, мы получаем это сообщение перед запуском задания M / R:

ERROR org.apache.hadoop.hbase.mapreduce.TableInputFormatBase - Cannot resolve the host name for /192.168.3.9 because of javax.naming.NameNotFoundException: DNS name not found [response code 3]; remaining name '9.3.168.192.in-addr.arpa'

Как dig, так и nslookup показывают, что и обратный, и прямой просмотр дают хорошие ответы без ошибок внутри кластера.

Вскоре после этих сообщений задание запускается ... но время от времени мы получаем NPE:

Exception in thread "main" java.lang.NullPointerException INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.net.DNS.reverseDns(DNS.java:93) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.hbase.mapreduce.TableInputFormatBase.reverseDNS(TableInputFormatBase.java:219) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.hbase.mapreduce.TableInputFormatBase.getSplits(TableInputFormatBase.java:184) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.mapred.JobClient.writeNewSplits(JobClient.java:1063) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.mapred.JobClient.writeSplits(JobClient.java:1080) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.mapred.JobClient.access$600(JobClient.java:174) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:992) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:945) INFO app.insights.search.SearchIndexUpdater - at java.security.AccessController.doPrivileged(Native Method) INFO app.insights.search.SearchIndexUpdater - at javax.security.auth.Subject.doAs(Subject.java:415) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1408) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.mapred.JobClient.submitJobInternal(JobClient.java:945) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.mapreduce.Job.submit(Job.java:566) INFO app.insights.search.SearchIndexUpdater - at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:596) INFO app.insights.search.SearchIndexUpdater - at app.insights.search.correlator.comments.CommentCorrelator.main(CommentCorrelator.java:72

Кто-нибудь еще, кто настроил кластер CDH Hadoop в частной сети с DNS-сервером, получает это?

CDH 4.3.1 с MR1 2.0.0 и HBase 0.94.6

Вероятно, что ваши внутренние DNS-серверы недостаточно быстро отвечают на количество запросов, которые могут поступать из вашей среды Hadoop (в зависимости от ее размера).

Вы можете сделать одно из нескольких:

  1. Настройте сервер имен только для кеширования, который обрабатывает запросы только для вашего кластера Hadoop. Вам нужно будет настроить этот сервер имен перед любым другим сервером имен в файле /etc/resolv.conf каждого хоста.
  2. Включите nscd для кратковременного кэширования поиска имени хоста на каждом сервере, работающем в вашем кластере hadoop.
  3. Отредактируйте / etc / hosts на каждом сервере в вашем кластере Hadoop, чтобы он содержал полный список каждой пары IP / Hostname для каждого сервера в вашем кластере.

Настройка сервера имен только для кеширования довольно тривиальна. Вы сможете найти учебное пособие, подходящее для вашей ОС, немного поискав.

Настройка nscd также довольно тривиальна, с той лишь оговоркой, что иногда она может вызывать странные вещи (например, изменение имени хоста занимает больше времени, чем вы ожидаете). Если достаточно короткое время кеширования, для нас это не проблема. Я бы порекомендовал отключить passwd и групповое кеширование, которое может включить nscd. Время кеширования не должно быть очень большим. 600 секунд кажутся хорошим балансом для нашего кластера и значительно сокращают фактические запросы DNS. Даже 60 секунд было бы лучше, чем повторное обращение к DNS-серверу.

Мой файл конфигурации выглядит так:

    logfile         /var/log/nscd.log
    threads         6
    max-threads     128
    server-user     nscd
#   stat-user       nocpulse
    debug-level     0
#   reload-count        5
    paranoia        no
#   restart-interval    3600

    enable-cache        passwd      no
    positive-time-to-live   passwd      600
    negative-time-to-live   passwd      20
    suggested-size      passwd      211
    check-files     passwd      yes
    persistent      passwd      yes
    shared          passwd      yes
    max-db-size     passwd      33554432
    auto-propagate      passwd      yes

    enable-cache        group       no
    positive-time-to-live   group       3600
    negative-time-to-live   group       60
    suggested-size      group       211
    check-files     group       yes
    persistent      group       yes
    shared          group       yes
    max-db-size     group       33554432
    auto-propagate      group       yes

    enable-cache        hosts       yes
    positive-time-to-live   hosts       600
    negative-time-to-live   hosts       20
    suggested-size      hosts       211
    check-files     hosts       yes
    persistent      hosts       yes
    shared          hosts       yes
    max-db-size     hosts       33554432

Наконец, переход по маршруту / etc / hosts: я бы не рекомендовал это, если у вас большой кластер. Это слишком дорого с административной точки зрения, чтобы убедиться, что все ваши конфигурации обновлены.