DNS reverso e encaminhado configurado corretamente, mas às vezes o trabalho do MapReduce falha

1

Desde que trocamos nosso cluster para se comunicar por meio de interfaces privadas e criamos um servidor DNS com zonas de pesquisa direta e inversa corretas, recebemos essa mensagem antes da execução da tarefa de 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'

Um dig e um nslookup mostram que as pesquisas inversas e futuras obtêm boas respostas sem erros no cluster.

Logo após essas mensagens, o job é executado ... mas de vez em quando recebemos um 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

Alguém mais que configurou um cluster do CDH Hadoop em uma rede privada com servidor DNS obtém isso?

CDH 4.3.1 com MR1 2.0.0 e HBase 0.94.6

    
por phodamentals 19.09.2013 / 18:56

1 resposta

1

É provável que seus servidores DNS internos não estejam respondendo com rapidez suficiente para o número de solicitações que podem vir do ambiente do Hadoop (dependendo do tamanho).

Você pode fazer uma das várias coisas:

  1. Configure um servidor de nomes somente de armazenamento em cache que manipule apenas solicitações para seu cluster do Hadoop. Você precisará configurar este servidor de nomes antes de qualquer outro servidor de nomes em /etc/resolv.conf de cada host.
  2. Ative o nscd para fazer o armazenamento em cache de pesquisa de nome de host de curta duração em cada servidor em execução no cluster do hadoop.
  3. Edite / etc / hosts em cada servidor em seu cluster do Hadoop para conter uma lista completa de cada par de IP / nome de host para cada servidor em seu cluster.

Configurar um servidor de nomes somente de armazenamento em cache é bem trivial. Você deve ser capaz de encontrar um tutorial apropriado para fazê-lo adequado ao seu sistema operacional com um pouco de pesquisa.

Configurar o nscd também é bastante trivial, com a ressalva de que às vezes pode causar coisas complicadas (como alterações no nome do host que levam mais tempo do que o esperado). Se um tempo de cache suficientemente curto, isso não foi um problema para nós. Eu recomendaria desabilitar o cache passwd e group que o nscd pode habilitar. O tempo de cache não precisa ser muito longo. 600 segundos parece ser um bom equilíbrio para o nosso cluster e reduz significativamente as pesquisas reais de DNS. Mesmo 60 segundos seria melhor do que bater repetidamente no servidor DNS.

Meu arquivo de configuração é assim:

    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

Finalmente, indo a rota / etc / hosts: eu não recomendaria isso se você tivesse um cluster grande. É muito administrativamente caro garantir que todas as suas configurações estejam atualizadas.

    
por 24.10.2013 / 22:04

Tags