Como resolver identificadores de ficheiro NFS obsoletos após mudar o nome de um conjunto de dados

Os identificadores de ficheiros NFS obsoletos após a mudança do nome de um conjunto de dados geralmente significam que o cliente ainda mantém referências a objetos ou identidades de exportação que foram alterados no servidor.

A recuperação mais segura consiste em confirmar se apenas um cliente está obsoleto ou se a própria identidade da exportação foi alterada, parar as aplicações que estão a utilizar ativamente a montagem, verificar se o conjunto de dados com o novo nome é exportado a partir do caminho pretendido e, em seguida, voltar a montar os clientes por uma ordem controlada. Não reinicie todas as máquinas nem recrie o conjunto de dados antes de saber se o identificador obsoleto está limitado a uma montagem em cache num cliente ou se afeta todos os clientes que acedem à exportação com o novo nome.

Confirme que o erro começou quando o conjunto de dados mudou de nome

Registe o nome e o ponto de montagem antigos do conjunto de dados, o novo nome e ponto de montagem, o caminho exportado e a primeira operação do cliente que devolveu ESTALE. Compare um cliente afetado com um cliente que tenha montado a partilha apenas depois da mudança de nome.

Um artigo recente sobre resolução de problemas NFS explica que obsoleto significa que o identificador mudou, não indicando simplesmente que o caminho de rede está indisponível.

Se uma montagem nova funcionar enquanto um cliente antigo falhar, é provável que a exportação com o novo nome esteja acessível e que o problema imediato seja o estado em cache no cliente antigo. Se as montagens novas também falharem, mantenha a investigação centrada na exportação do servidor e na identidade do conjunto de dados.

Verifique se a exportação aponta agora para o conjunto de dados pretendido

Verifique a lista de exportações ativas do servidor e a tabela de montagens do sistema de ficheiros depois da mudança de nome. Um caminho pode continuar a existir, mas passar a resolver para outro conjunto de dados, para um ponto de montagem vazio ou para um diretório dentro do sistema de ficheiros errado.

A OneUptime observa que as alterações nas exportações podem invalidar identificadores quando objetos, exportações, IDs de sistemas de ficheiros ou dados restaurados são alterados sob uma referência existente do cliente.

Corrija o destino da exportação antes de intervir nos clientes. Uma nova montagem no caminho errado do servidor pode parecer resolver o erro ESTALE, apontando, contudo, silenciosamente, as aplicações para uma árvore de diretórios diferente.

Pare os processos que ainda mantêm a montagem antiga aberta

Utilize as ferramentas de montagem e de processos do cliente para identificar shells, servidores multimédia, tarefas de cópia de segurança, contentores ou processos de bases de dados que ainda tenham a montagem NFS antiga aberta. Pare o serviço afetado de menor dimensão antes de forçar a desmontagem.

Um guia de recuperação focado em Linux recomenda localizar os processos antes de voltar a montar, para que uma etapa de recuperação não deixe um processo preso numa vista do sistema de ficheiros parcialmente desligada.

Se apenas um contentor for proprietário do caminho obsoleto, pare primeiro esse contentor. Se a montagem for partilhada por vários serviços, agende uma breve janela de manutenção em vez de recorrer imediatamente a desmontagens preguiçosas numa pilha de aplicações em funcionamento.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Volte a montar o cliente depois de estabilizar o caminho do servidor

Depois de corrigir a exportação do servidor e parar os serviços dependentes, desmonte e volte a montar a partilha NFS num cliente de teste. Utilize o mesmo endereço do servidor, caminho de exportação, versão NFS e opções de montagem que permanecerão em produção.

Um caso de migração NFS demonstra que os clientes precisam de uma montagem nova depois de uma migração do armazenamento, mesmo quando as permissões e os dados copiados estão corretos.

Teste a listagem do diretório, uma leitura, uma escrita reversível e o caminho real da aplicação antes de voltar a montar todos os outros clientes. Se o mesmo cliente voltar a ficar obsoleto imediatamente, retome a investigação da identidade do servidor em vez de repetir a montagem.

Verifique se a mudança de nome alterou a identidade do identificador de ficheiro

Os identificadores de ficheiros NFS não são simples cadeias de texto com caminhos. Codificam uma identidade definida pelo servidor, que pode incluir informações relacionadas com o sistema de ficheiros e o inode; por isso, substituir, restaurar ou mover o sistema de ficheiros subjacente pode ser relevante, mesmo quando o caminho de exportação visível parece semelhante.

Uma análise aprofundada dos identificadores de ficheiros demonstra que estes mapeiam a identidade do servidor, não funcionando como marcadores para um caminho de texto.

Se a mudança de nome tiver feito parte de uma operação de destruição e recriação, receção, clonagem ou restauro do conjunto de dados, documente essa alteração de identidade mais abrangente. A solução correta poderá ser voltar a montar todos os clientes de forma coordenada, em vez de tentar preservar indefinidamente os identificadores antigos.

Verifique se todos os clientes utilizam a nova exportação depois de reiniciar

Depois de o primeiro cliente passar nos testes, volte a montar os restantes clientes um de cada vez, reative os serviços dependentes e verifique se as respetivas unidades de montagem configuradas ou caminhos de bind dos contentores fazem referência à exportação pretendida. Em seguida, reinicie um cliente não crítico como teste de persistência.

Um artigo sobre resolução de problemas de armazenamento explica que as montagens obsoletas sobrevivem às aplicações até que os processos consumidores e o estado das montagens sejam efetivamente atualizados.

A reparação está concluída quando os clientes novos e reiniciados montarem o conjunto de dados com o novo nome sem apresentarem ESTALE e as aplicações lerem os ficheiros esperados. O guia relacionado da ZimaSpace sobre caminhos de montagem estáveis para servidores domésticos é a referência complementar quando as mudanças de nome dos conjuntos de dados também alteraram caminhos locais de bind ou das aplicações.

Perguntas frequentes

Um identificador de ficheiro NFS obsoleto pode significar que o disco está a falhar?

Não por si só. ESTALE significa que o identificador em cache do cliente já não identifica o objeto no servidor que este espera encontrar. Verifique o estado do armazenamento separadamente se o servidor também comunicar erros de E/S ou do sistema de ficheiros.

Reiniciar o serviço NFS resolve sempre o problema?

Não. Se a exportação apontar agora para uma identidade de conjunto de dados diferente, os identificadores antigos do cliente continuarão errados. Verifique primeiro a exportação e, em seguida, atualize deliberadamente as montagens dos clientes.

Todos os clientes devem ser reiniciados depois de mudar o nome de um conjunto de dados?

Normalmente, não. Parar os serviços de forma controlada e voltar a montar é suficiente quando a exportação do servidor está correta. Reinicie apenas quando um cliente não conseguir libertar corretamente a montagem obsoleta ou como teste final de persistência.