John Bollinger's questions

Estou tentando usar systemd-tmpfiles para gerenciar arquivos no "disco temporário" de uma VM Linux (CentOS Stream 8) no Azure. A systemd-tmpfilesconfiguração parece estar correta, conforme julgado pela execução systemd-tmpfiles --createmanual quando o sistema está ativo. No entanto, ele não está funcionando com o systemd-tmpfiles-setupserviço, pois esse serviço cria os arquivos no diretório do ponto de montagem em vez de no sistema de arquivos montado. Claro, isso discute todo o exercício.

Presumo que isso esteja acontecendo porque systemd-tmpfiles-setupé executado antes da montagem do disco temporário, então tentei resolvê-lo aplicando uma RequiresMountsForpropriedade por meio de uma substituição de configuração:

/etc/systemd/system/systemd-tmpfiles-setup.service.d/override.conf

[Unit]
RequiresMountsFor=/mnt/resource

O Systemd parece reconhecer isso, conforme julgado pela systemctl list-dependencies systemd-tmpfiles-setuplista da unidade de montagem apropriada, mas na reinicialização, ele ainda cria os arquivos desejados no diretório do ponto de montagem em vez de no disco temporário montado.

Possivelmente é relevante que a unidade de montagem desejada não tenha um arquivo de unidade explícito; Estou contando com o systemd para gerar a unidade digitalizando /etc/fstab, como de fato parece estar fazendo.

/etc/fstab :

# ...
/dev/disk/cloud/azure_resource-part1    /mnt/resource   auto    defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig       0       2

o que estou perdendo? Existe uma boa razão para que o que estou fazendo não funcione?

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?