Lista de verificação da migração NFS para conjuntos de dados renomeados e identificadores de ficheiro estáveis

A abordagem segura consiste em tratar uma migração de exportação em estado quiescente, que preserve tanto quanto possível o espaço de nomes visível para o cliente e remonte deliberadamente os clientes quando a identidade dos handles mudar, como uma sequência de etapas observáveis, e não como um único comando.

Num servidor NFS Linux que migra um conjunto de dados NAS utilizado por clientes de servidores domésticos, o risco prático é que mudar o nome ou mover um conjunto de dados exportado deixe os clientes com handles de ficheiro NFS obsoletos ou falhas ao remontar. Registe a identidade atual e o ponto de recuperação, comece pelo discriminador menos invasivo, interprete os resultados aprovados e falhados antes de alterar outra variável e pare quando o armazenamento ficar instável ou quando a única cópia recuperável pudesse ser exposta. O fluxo de trabalho abaixo só termina depois de a carga de trabalho original ser concluída com êxito ou de as evidências atingirem um limite de escalada.

Faça o inventário da exportação e das dependências dos handles de ficheiro

Registe a identidade do sistema de ficheiros ou conjunto de dados de origem, o caminho no servidor, a pseudo-raiz NFSv4, as opções de exportação, os valores explícitos de fsid, os caminhos de montagem dos clientes, as unidades autofs ou systemd e todos os contentores ou aplicações que utilizem a montagem. Capture as montagens ativas e os ficheiros abertos antes de planear a indisponibilidade.

Os handles de ficheiro NFS codificam a identidade do objeto selecionada pelo servidor, pelo que uma cadeia de caminho inalterada não garante um handle estável depois de mover um sistema de ficheiros. Uma explicação independente sobre o funcionamento dos handles de ficheiro NFS obsoletos explica como exportações eliminadas, recriadas ou remapeadas produzem handles obsoletos, mesmo quando o diretório existe visivelmente.

Decida se o objetivo é a estabilidade do espaço de nomes ou a continuidade dos handles ativos. Preservar o caminho visível para o cliente reduz as alterações de configuração, mas mover os dados para um sistema de ficheiros diferente pode ainda exigir que todos os clientes desmontem e obtenham novos handles.

Prepare o destino enquanto os clientes permanecem na origem

Crie o conjunto de dados de destino, copie os dados preservando ACLs, proprietários, atributos estendidos, hard links, ficheiros esparsos e marcas temporais, e compare as contagens e hashes representativos. Faça corresponder a segurança da exportação e o mapeamento de identidades antes de expor o destino aos clientes de produção.

Utilize o guia da ZimaSpace sobre mapeamento de identidades NFSv4 para alinhar as identidades NFSv4 entre servidores Linux. Handles de ficheiro estáveis não resolvem incompatibilidades de propriedade numérica ou de domínio de nomes, pelo que deve validar separadamente a camada de identidade dos ficheiros e a camada de identidade dos utilizadores.

Faça uma sincronização inicial enquanto a origem está ativa apenas se o método de cópia o suportar e, em seguida, planeie uma sincronização delta final com a origem parada. Não exporte ambas as cópias com acesso de escrita no mesmo espaço de nomes de cliente, porque as escritas podem divergir sem uma falha evidente.

Coloque os clientes em estado quiescente e altere a exportação

Pare as aplicações que efetuam escritas, os contentores e as tarefas agendadas em todos os clientes e, em seguida, verifique se nenhum processo importante mantém ficheiros abertos abaixo do ponto de montagem. Desmonte as montagens dos clientes de forma limpa. Depois da sincronização final, retire a exportação da origem ou torne-a só de leitura, altere a montagem ou exportação no servidor para o destino e recarregue as exportações.

Um relato de engenharia da GitLab sobre um caso de alteração de nome NFS e estado obsoleto mostra que o comportamento de alterações de nome e delegações pode produzir observações obsoletas ou inconsistentes nos clientes. A resposta operacional segura é a colocação planeada em estado quiescente e a remontagem, não a repetição de comandos para limpar caches enquanto as aplicações continuam a escrever.

Se o destino alterar a identidade do sistema de ficheiros, espere novos handles e monte novamente os clientes. Mantenha a exportação original disponível sob um nome de recuperação não produtivo, mas nunca permita que as árvores antiga e nova aceitem escritas concorrentes.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Remonte todos os clientes e verifique a nova identidade

Remonte primeiro um cliente de teste e verifique a listagem, leitura, criação, alteração de nome, eliminação, bloqueio de ficheiros e propriedade. Reinicie a aplicação dependente e verifique a carga de trabalho original. Em seguida, avance pelos restantes clientes, registando a origem da montagem, a versão NFS e a ausência de erros de handles obsoletos.

Reinicie o cliente ou o automount num cliente de teste para comprovar que a configuração persistente aponta para o espaço de nomes estável visível para o cliente. Verifique os registos do servidor, os kernels dos clientes, as tarefas de cópia de segurança e os contentores em busca de caminhos antigos ocultos. Uma montagem manual bem-sucedida não prova que a ordem de arranque ou as dependências dos serviços estejam corretas.

Retire a origem apenas depois de todos os clientes remontarem, as tarefas normais serem concluídas com êxito, uma cópia de segurança ser concluída e uma restauração ser testada. Reverta antes de aceitar novas escritas se o cliente de teste falhar; depois de começarem as escritas no destino, pare e reconcilie deliberadamente, em vez de alternar repetidamente entre as exportações.