Esse problema está me deixando louco.
Tenho um servidor NFS com compartilhamentos NFS montados em vários clientes. No entanto, sempre que preciso reinicializar o servidor NFS, invariavelmente acabo com vários erros de "manipulador de arquivo obsoleto" nas montagens de todos os meus clientes, o que me obriga a desmontar e remontar manualmente meus compartilhamentos NFS nos clientes.
Verifiquei minhas exportações em meu servidor NFS cat /etc/exportse estou passando o mesmo fsid para cada exportação NFS nas reinicializações.
Minhas perguntas:
- Como a indústria lida com esse problema? Tenho dificuldade em imaginar administradores de sistemas entrando e desmontando/remontando manualmente cada cliente ou simplesmente reiniciando clientes conectados em massa. Ou é realmente assim que isso é tratado? (Além do padrão, "Nunca temos tempo de inatividade e nunca precisamos reiniciar os servidores NFS.")
- Por que isso acontece? Isso ocorre porque, mesmo que o fsid possa ser o mesmo, o servidor NFS recalcula identificadores de arquivos que podem não ser os mesmos nas reinicializações?
- Há algo que eu deveria fazer melhor na minha configuração de montagem para evitar isso?
/etc/fstab:
[NFSserver]:/mnt/backup /mnt/backup nfs bg,nfsvers=3,tcp 0 0
Poresta postagem, foi sugerido adicionar harde intrmontar opções, mas isso não parece ter feito diferença.
- Se tudo mais falhar, devo voltar a usar um script bash para monitorar a montagem/diretório em busca de um erro de arquivo obsoleto e fazer com que ele execute um ciclo de desmontagem/montagem?
Desde já, obrigado.
-Chave de torque
Responder1
Você está usando o NFS versão 3, que precisa de vários serviços auxiliares além do serviço NFS principal na porta 2049. Um deles é o rpc.statd, que tem um papel fundamental na detecção de reinicializações e na recuperação/limpeza de bloqueios NFS após uma reinicialização.
Esses serviços auxiliares podem estar localizados em portas aleatórias e são descobertos entrando em contato com o mapeador de portas RPC (geralmente um processo nomeado rpcbindem Linuxes modernos). Em redes modernas com firewalls, esse comportamento pode dificultar as coisas: mesmo que você possa encontrá-los em portas de aparência determinística após uma reinicialização, eles podem ser alocados para números de porta bem diferentes se/quando você reiniciar os serviços NFS.
Felizmente, em muitos sistemas modernos do tipo Unix, você pode bloquear os números de porta do gerenciador de bloqueio NFS (historicamente rpc.lockd, hoje em dia geralmente implementado no kernel) rpc.statde rpc.mountd. Isto é essencial se você deseja passar o NFSv3 através de firewalls com algum tipo de confiabilidade.
Para RHEL e distribuições relacionadas, você pode bloquear os números de porta auxiliar NFS adicionando estas linhas em /etc/sysconfig/network:
LOCKD_TCPPORT=4045
LOCKD_UDPPORT=4045
STATD_PORT=4046
MOUNTD_PORT=4047
Para Debian e distribuições relacionadas, você pode adicionar esta linha a /etc/modprobe.d/nfs.conf:
options lockd nlm_udpport=4045 nlm_tcpport=4045
... e esta linha em /etc/default/nfs-common:
STATDOPTS="-p 4046"
... e esta linha em /etc/default/nfs-kernel-server:
RPCMOUNTDOPTS="-p 4047" # you may want to add a --manage-gids option here
(Você pode usar números de porta diferentes se desejar, mas 4045 é a porta padrão para o gerenciador de bloqueio NFSv3 no Solaris e codificada para a mesma no HP-UX 11.31.)
Mas há outra armadilha no protocolo NFSv3. Embora você possa montar com êxito um compartilhamento NFS usando apenas endereços IP, o protocolo de bloqueio NFSv3 usa internamente nomes de host. Tanto o cliente quanto o servidor devem se conhecer pelos nomes corretos, caso contrário, o bloqueio do arquivo NFS e a recuperação do bloqueio após uma reinicialização não funcionarão. E o “nome correto” de cada sistema é o nome relatado por uname -n.
Portanto, se uname -nretornar server.exampleno servidor e respectivamente client.exampleno cliente, você deve certificar-se de que esses nomes exatos serão resolvidos para os endereços IP que os hosts precisam usar para NFS. Em outras palavras, o servidor deve ser capaz de entrar em contato com o cliente rpc.statdpelo nome client.examplee vice-versa.
Caso contrário, tudo pode parecer funcionar bem no início... mas quando uma das extremidades for reinicializada, você poderá receber esses Stale file handleerros.
Responder2
Além da excelente resposta da @telcoM, gostaria de sugerir outras duas soluções possíveis:
monte nfs com a
noacopção (cuidado que issovaicausar perda de desempenho ao emitirlsem diretórios grandes oustatem muitos arquivos)use o NFS v4.1 (a v4.0 tinha alguns bugs que levavam ao "manipulação de arquivos obsoletos", portanto, selecione o protocolo v4.1).