NetWorker: Práticas recomendadas para solução de problemas de resolução de nomes

O NetWorker depende da resolução de nomes. Se a resolução de nomes não estiver correta e totalmente consistente, poderão surgir problemas em muitas das operações do NetWorker. Como o NetWorker gerencia dados potencialmente confidenciais, ele deve garantir as identidades dos hosts com os quais ele interage por vários meios.

Qualquer número de sintomas no NetWorker pode ser resultado de falhas na resolução de nomes no NetWorker:

• Mensagens de erro indicando problemas de pesquisa de nomes direta ou inversa.
• Incapacidade de sondar clients durante o backup
• Incapacidade dos clients de salvar manualmente no servidor ou de se recuperar.
• Problemas ao clonar ou acessar dispositivos de nó de armazenamento
• Problemas de navegação ou registro de banco de dados de mídia.
• O servidor ou nó de armazenamento para de responder na inicialização ou durante a operação regular.
• Diretórios de índice com nomes incorretos ou aninhados
• Erros de client configurados incorretamente

Fluxo de trabalho de resolução de nomes

As tentativas de resolver um nome de host usado pelo comando ou pela configuração interna devem ser resolvidas em um endereço IP para serem usadas. Os recursos a seguir são verificados, na seguinte ordem, para ver se name :IP já foi armazenado em cache, interrompendo quando o nome é correspondido. 

1. Cache de nomes do NetWorker: A maioria dos daemons principais do NetWorker; Vida útil configurável no banco de dados nsrla 
2. Cache do resolvedor de host local: Varia de acordo com o sistema operacional e adia a carga de hosts ou pesquisas de DNS
3. Entradas do arquivo de hosts locais: Pesquisa local rápida, mas mantida manualmente; útil para substituir a resolução DNS
4. Pesquisas do servidor DNS: Preferido pelo setor devido à administração centralizada, mas mais lenta

1. Armazenamento em cache do NetWorker:

Os daemons do NetWorker mantêm caches de nomes internos. Os clients armazenam em cache nomes resolvidos em nsrexecd, enquanto os daemons de núcleo, como nsrd e nsmmdbd , mantêm seus próprios caches. Esta é a primeira tabela de IP verificada e a mais rápida. O tempo de vida do cache interno pode ser definido em cada banco de dados nsrla dos hosts do NetWorker usando: nsradmin:

Linux/UNIX

printf ". type: nsrla\nshow positive DNS cache TTL; negative DNS cache TTL\nprint\n" | nsradmin -p nsrexec -s remote_host

Windows

(echo . type: nsrla & echo show positive DNS cache TTL; negative DNS cache TTL & echo print) | nsradmin -p nsrexec -s remote_host

Deve retornar 30 minutos por padrão (1.800 segundos):

positive DNS cache TTL: 1800;
negative DNS cache TTL: 1800;

Esse valor controla quanto tempo antes de o NetWorker deliberadamente limpar o cache do processo em favor de informações atualizadas das próximas camadas sequencialmente. Dessa forma, aumentá-lo é apropriado para ambientes em que a pesquisa de DNS é lenta, mas o endereçamento de DNS é relativamente estático. Por outro lado, valores mais baixos podem ser desejáveis para ambientes com endereços que mudam com frequência. 

Se um nome necessário estiver presente no cache interno do NetWorker, ele será usado e a consulta adicional será interrompida. Para a solução de problemas, se os mapeamentos de nome para IP em cache parecerem errados, use comandos para registrar o cache atual e, em seguida, liberar ou resolver novamente as entradas:

• • dbgcommand -n nsrd PrintDnsCache=1 (despejar para daemon.raw)
  • dbgcommand -n nsrd FlushDnsCache=1 (Flush), ou, 
  • dbgcommand -n nsrd FlushDnsCache=9 (Faça flush e resolva/recrie imediatamente o cache)

• • Linux/UNIX: ps -ef | grep nsr 
  • Windows: tasklist | findstr nsr

2. Cache do solucionador:

• • O cache do resolvedor de flush varia de acordo com o sistema operacional/distribuição - consulte a documentação do fornecedor.
  • Windows: ipconfig /flushdns

3. Arquivos hosts:

• • UNIX/Linux: /etc/hosts
  • Windows: %systemroot%\System32\drivers\etc\hosts

4. Resolução direta:

• Execute nslookup sem argumentos para entrar no prompt interativo.
• Digite a iteração de nome para pesquisar e pressione Enter para recuperar o registro de encaminhamento do servidor DNS ao qual você se conectou.
• Digite o mesmo nome duas vezes mais para ver se o registro de nomes está fazendo rodízio silenciosamente entre diferentes hosts ou retorna os mesmos dados.
• Repita o mesmo processo para qualquer instância de qualquer nome que o host possa ser acionado por outros hosts ou considerado para o mesmo endereço IP.
• Repita o mesmo processo para qualquer outro servidor DNS que o host esteja configurado para uso potencial digitando o servidor next_dns_server.

5. Resolução inversa:

• Execute nslookup sem argumentos para entrar no prompt interativo.
• Inserir conjunto q=ptr para alterar o tipo de consulta para a Zona Inversa.
• Digite o endereço IP para reverter a resolução e pressione Enter.
• Certifique-se de que o nome retornado no registro inverso corresponda ao nome/IP do registro de encaminhamento.

[root@linux_a~]# nslookup linux_a
Server:         1.2.3.4
Address:        1.2.3.4#53
Name:   linux_a.domain.com
Address: 5.6.7.8
         
[root@linux_a~]# nslookup 5.6.7.8
Server:         1.2.3.4
Address:        1.2.3.4#53
Name:   linux_a.domain.com
Address: 5.6.7.8
         
[root@linux_a~]# nslookup
> set q=ptr
> 5.6.7.8
Server:         1.2.3.4
Address:        1.2.3.4#53
Non-authoritative answer:
8.7.6.5.in-addr.arpa        name = linux_a.domain.com.

Testando a resolução de nomes

Todos os hosts do NetWorker devem ter resolução de nomes direta e inversa consistente para qualquer host com o qual se comuniquem, com base em sua função de zona de dados. É essencial que os administradores do NetWorker garantam que todos os problemas de resolução do host sejam resolvidos de maneira completa e imediata.
Ao solucionar problemas de resolução de nomes ou para descartar esses problemas em sua zona de dados do NetWorker:
    1. Localize todos os hosts envolvidos na operação com falha: servidor, clients e, possivelmente, nós de armazenamento etc.
    2. Para cada um, determine os endereços IP configurados localmente e todos os nomes que possam ser resolvidos esperados para esses IPs.
    3. Configure todos os hosts para usar o arquivo de hosts antes do DNS para a resolução do host.
    4. No início do arquivo de hosts de um host, configure uma única entrada para cada IP, com cada nome correspondente na mesma linha.
    5. Copie essas linhas exatamente do primeiro host para os arquivos de hosts dos outros hosts envolvidos.
    6. Edite os objetos do client do NetWorker para ter aliases correspondentes corretamente aos IPs desejados.
    7. Desligue o NetWorker em todos os hosts envolvidos.
    8. Limpe o cache do resolvedor em cada host usando o mecanismo apropriado do sistema operacional.
    9. Reinicie o NetWorker e tente a operação problemática novamente.

Para provar que o nome foi resolvido por um determinado host, use este teste:
    1. A partir do primeiro host do NetWorker (por exemplo, o Client), conecte-se ao segundo (por exemplo, o servidor) usando nsradmin -s remote_host -p nsrexec - Deixe a sessão aberta.
    2. No mesmo host, determine o processo para nsradmin (por exemplo, Windows, tasklist | findstr nsradmin)
3º. Execute netstat para mostrar o soquete associado a esse processo (por exemplo, Windows, netstat -ao | findstr process_id)
4º. Determine o soquete de conexão desse host (o emparelhamento IP:port mais à esquerda no resultado)
5. No host remoto - execute netstat -a e findstr/grep para :calling_port_from_first_host.
    6. O nome do host antes dos dois pontos é como o segundo host resolve o primeiro host ao aceitar a conexão de entrada.
    7. Executar novamente com o comando -n switch adicionado ao comando netstat para verificar o IP do mesmo soquete, para verificar se o IP/rota é esperado.
    8. Inverta o mesmo teste para garantir que o segundo host esteja resolvendo o primeiro host dentro dos parâmetros esperados.

Sobre aliases de client do NetWorker

O NetWorker também tem um campo configurável que é global para todas as instâncias do client chamado "Aliases", que deve refletir todos os nomes que podem ser resolvidos para esse client. Isso permite que o NetWorker vincule vários nomes resolvidos a uma instância do client. Por exemplo, client1.domain.prod também pode aparecer como client1.domain.bkup ou client1, dependendo do IP usado.

Operações do NetWorker, como savegroup, usam vários soquetes TCP: um para cada para atualizações de controle, dados e índice. Se algum soquete usar um nome inconsistente (mas válido), a operação poderá falhar.

• Às vezes, o rodízio é usado e configurado deliberadamente, mas geralmente é inesperado e deve ser evitado
• netstat -a revela soquetes TCP abertos/ativos, que revelam o nome resolvido pelo SO do host externo - isso pode ser usado para identificar problemas
• Às vezes, o roteamento estático pode ser necessário quando o tráfego de rede usa um adaptador inesperado/indesejado, o que pode levar posteriormente a problemas de resolução de nomes.

Consulte também:  Processos e portas do NetWorker