Eu tenho uma infraestrutura de máquinas clientes CentOS 6 e CentOS 7 que dependem de autofs para montar automaticamente vários sistemas de arquivos NFS exportados por um serviço em outro lugar da minha organização. Recentemente, os clientes começaram a manifestar um comportamento problemático no qual a montagem automática desses sistemas de arquivos se tornou muito lenta - enquanto a montagem costumava ser feita em poucos segundos, começou a demorar quase dois minutos.
Acho que rastreei o problema a uma combinação de fatores:
- O nome do host do servidor tem um grande número de resoluções distintas (32)
- Quando o nome do host tem várias resoluções, o autofs sonda cada uma para tentar rejeitar as que não respondem e escolher aquela entre as outras que atualmente tem o melhor tempo de resposta
- Exatamente um dos dois RPCs de investigação emitidos para cada servidor por autofs parece estar atingindo o tempo limite de forma consistente para todos os meus servidores.
Aqui está um trecho representativo do log de depuração:
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 6 version 0x20 Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: nfs v3 rpc ping time: 0.000290 Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: host nfs.my.org cost 289 weight 0 Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 17 version 0x20 Jul 13 15:48:21 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.84) proto 6 version 0x20
Isso mostra uma sonda completa e o início, três segundos depois, da seguinte. Além do atraso, não vejo nenhuma informação sobre uma resposta ao segundo RPC. Isso diz "tempo limite" para mim. Embora os tempos limite sejam individualmente de apenas 3 segundos, multiplicar isso por 32 máquinas significa mais de um minuto e meio de tempo limite antes que a montagem em si seja realmente tentada.
Os clientes estão executando as pilhas de cliente NFS padrão para CentOS 6 e 7: nfs-utils 1.2.3 e autofs 5.0.5 ou nfs-utils 1.3.0 e autofs 5.0.7, respectivamente, conforme empacotado pelo CentOS. Os clientes estão sob gerenciamento de configuração, portanto, estou confiante de que eles não tiveram nenhuma alteração de software ou configuração desde muito antes de o problema começar a se manifestar.
Os servidores estão executando a pilha NFS do espaço de usuário do Ganesha e, em particular, pode ser relevante que eles não suportem NFS4, embora isso não tenha apresentado um problema no passado. O gerenciamento do servidor alega que nenhuma alteração de configuração foi feita intencionalmente, mas permite que atualizações de software de rotina possam ter sido instaladas.
Então, finalmente, a pergunta é dada no título: como posso resolver os atrasos de montagem causados pela sondagem do host? Existe uma configuração relevante no Ganesha cujo padrão pode ter mudado? Como alternativa, existe uma maneira de configurar autofs para evitar tentar os RPCs com falha? Ou talvez eu tenha identificado erroneamente o problema?
Ativar o parâmetro de configuração autofs use_hostname_for_mountsparece resolver o problema, mas pelo que entendi, isso tem o custo de perder a resiliência contra falhas e sobrecarga dos servidores individuais. Não há maneira melhor?
Parece que a pista chave nas mensagens de log é que as sondas registradas como tendo "proto 6" são bem-sucedidas e aquelas registradas como tendo "proto 17" falham. Os números 6 e 17 são os números do protocolo de transporte IP representando TCP e UDP, respectivamente.
Embora o NFS seja tradicionalmente servido sobre UDP, o serviço sobre TCP é suportado pela maioria das pilhas, e o servidor neste caso sempre foi configurado para servir NFS apenas sobre TCP. Isso não apresentou um problema, no entanto, até que uma alteração ainda não caracterizada entrou no servidor que resultou em que o tráfego nfs/udp foi posteriormente descartado silenciosamente em vez de ser rejeitado com a resposta ICMP apropriada. Isso pode muito bem ter surgido de uma mudança de firewall, mas neste momento não posso descartar uma mudança no nível do aplicativo no servidor.
De qualquer forma, resolvi o problema no lado do cliente, adicionando
proto=tcpas opções de montagem de cada sistema de arquivos afetado no arquivo de mapa autofs. O Autofs foi inteligente o suficiente para renunciar às sondagens de sabor UDP assim que essa opção estava em vigor. Não apenas o problema foi resolvido, mas o desempenho da montagem agora parece um pouco melhor do que era antes do início do problema de tempo limite.