Como posso resolver os atrasos de montagem do autofs relacionados à análise do host?

Question

Eu tenho uma infra-estrutura de máquinas clientes CentOS 6 e CentOS 7 que dependem de autofs para automontar vários sistemas de arquivos NFS exportados por um serviço em outro local da minha organização. Recentemente, os clientes começaram a manifestar um comportamento problemático no qual a automontagem desses sistemas de arquivos tornou-se muito lenta - enquanto a montagem costumava ocorrer em poucos segundos, ela começou a demorar quase dois minutos.

Acho que localizei o problema em 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 investiga cada um para tentar rejeitar os que não respondem e escolher aquele entre os demais que atualmente tem o melhor tempo de resposta
• Exatamente um dos dois RPCs de sondagem emitidos para cada servidor por autofs parece estar expirando de maneira consistente para todos dos 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 começo, 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 clientes NFS padrão para o 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, como empacotados pelo CentOS. Os clientes estão sob gerenciamento de configuração, por isso 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 Ganesha userspace e, em particular, pode ser relevante que eles não suportem o 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 as atualizações de software de rotina possam ter sido instaladas.

Então, finalmente, a questão é dada no título: como posso resolver os atrasos de montagem causados pela análise do host? Existe uma configuração relevante em Ganesha, cujo padrão pode ter mudado? Como alternativa, existe uma maneira de configurar o autofs para evitar a tentativa de RPCs com falha? Ou eu, talvez, identifiquei mal o problema?

Ativar o parâmetro de configuração do autofs use_hostname_for_mounts parece contornar o problema, mas, no meu entender, isso vem ao custo de perder a resiliência contra falhas e a sobrecarga dos servidores individuais. Não há melhor maneira?

    

Answer 1

Parece que a principal pista nas mensagens de log é que os probes logados como tendo "proto 6" são bem-sucedidos e aqueles registrados como tendo "proto 17" falham. Os 6 e 17 são os números de protocolo de transporte IP representando TCP e UDP, respectivamente.

Embora o NFS seja tradicionalmente servido por UDP, o serviço por TCP é suportado pela maioria das pilhas, e o servidor, nesse caso, sempre foi configurado para atender somente ao NFS em TCP. Isso não apresentou um problema, no entanto, até que uma mudança ainda não caracterizada ocorresse no servidor, o que resultou no descarte silencioso do tráfego nfs / udp, em vez de ser rejeitado com a resposta ICMP apropriada. Isso pode muito bem ter surgido de uma alteração de firewall, mas não posso descartar uma alteração no nível do aplicativo no servidor.

Em qualquer caso, resolvi o problema no lado do cliente, adicionando proto=tcp às opções de montagem de cada sistema de arquivos afetado no arquivo de mapeamento do autofs. O Autofs foi inteligente o bastante para abrir mão das sondas de sabor UDP quando a opção estava em vigor. Não apenas o problema está resolvido, mas o desempenho de montagem agora parece um pouco melhor do que antes do problema de tempo limite ter sido iniciado.