Como reorganizar conjuntos de dados NFS sem alterar os caminhos de exportação visíveis para os clientes

Os conjuntos de dados NFS podem ser reorganizados sem identificadores obsoletos nos clientes, desde que o espaço de nomes das exportações visível para os clientes permaneça estável enquanto o armazenamento é movido por trás desse limite.

O design preventivo consiste em separar o caminho montado pelos clientes do nome físico do conjunto de dados que poderá ser alterado mais tarde. Crie uma árvore de exportações estável, mapeie deliberadamente os conjuntos de dados para essa árvore, preserve a identidade do sistema de ficheiros sempre que possível, desligue os clientes antes de substituições destrutivas e verifique o mesmo caminho de exportação após a transição. Se o servidor tiver de destruir e recriar o sistema de ficheiros subjacente, trate isso como uma alteração de identidade e planeie uma remontagem coordenada nos clientes, em vez de prometer continuidade invisível.

Crie um espaço de nomes de exportação estável acima dos conjuntos de dados

Utilize uma raiz de exportação NFS dedicada, cujos nomes visíveis para os clientes não reproduzam todos os nomes internos dos conjuntos de dados ZFS ou Btrfs. Assim, os administradores de armazenamento podem reorganizar os conjuntos de dados de backend sem ensinar um novo caminho de montagem a cada cliente.

Uma discussão sobre NFSv4 explica como as montagens bind criam exportações estáveis sob um pseudo-sistema de ficheiros gerido deliberadamente.

Documente o caminho do cliente como contrato de compatibilidade. Os nomes internos dos conjuntos de dados podem ser alterados mais tarde, mas apenas depois de a camada de exportação ter sido remapeada e testada com o mesmo caminho.

Fixe a identidade da exportação em vez de depender da ordem de descoberta

Registe o UUID do sistema de ficheiros, o caminho de exportação, a versão do NFS e as definições explícitas de fsid utilizadas pelo servidor atual. O mesmo nome de diretório visível não é suficiente quando o servidor NFS identifica o sistema de ficheiros subjacente de forma diferente após uma deslocação.

A SUSE explica que o NFS identifica cada sistema de ficheiros exportado, em vez de tratar uma exportação como um simples alias de caminho.

Utilize identificadores explícitos apenas quando a sua implementação de NFS os suportar e mantenha cada valor exclusivo. Não copie um fsid para dois sistemas de ficheiros exportados em simultâneo apenas para que pareçam idênticos.

Prepare o novo conjunto de dados por trás do mesmo caminho de exportação

Crie ou receba o conjunto de dados de substituição num caminho temporário no servidor, copie ou replique o respetivo conteúdo, verifique as permissões e, em seguida, mapeie-o para a árvore de exportação estável durante uma janela de manutenção. Mantenha o conjunto de dados antigo disponível para reversão, mas não ativo com a mesma identidade de exportação.

Um exemplo de exportação NFS mostra como os subdiretórios montados exigem exportações deliberadas quando vários sistemas de ficheiros aparecem sob um único espaço de nomes NFS.

A transição deve alterar um único mapeamento no servidor, e não simultaneamente a definição de montagem do cliente e a identidade do conjunto de dados. Assim, as evidências de resolução de problemas permanecem intactas caso a nova árvore esteja incorreta.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Interrompa as escritas antes de substituir o sistema de ficheiros subjacente

Pare ou pause os serviços que escrevem ativamente através da montagem NFS e confirme que nenhum cliente importante mantém uma operação de ficheiros prolongada durante a transição. Conclua a sincronização final apenas depois de as escritas terem sido suspensas.

A IBM explica que o estado do NFSv4 necessita de armazenamento estável, porque o estado do cliente faz parte da continuidade, não sendo apenas uma questão do conteúdo dos ficheiros no servidor.

Num servidor doméstico, o objetivo é mais simples do que numa comutação de cluster: evite alterar a identidade dos ficheiros enquanto as aplicações estão ativas. Uma breve pausa controlada é mais segura do que obrigar clientes de bases de dados, multimédia ou cópias de segurança a sobreviver a uma substituição do sistema de ficheiros em funcionamento.

Saiba quando uma remontagem no cliente é inevitável

Se a reorganização destruir e recriar o sistema de ficheiros, restaurar um instantâneo como um novo sistema de ficheiros ou alterar a identidade do identificador de ficheiro no servidor, planeie uma desmontagem e remontagem coordenadas depois de o caminho do servidor estar estável.

Um guia atual de resolução de problemas de NFS afirma que as alterações da identidade do servidor tornam os identificadores obsoletos e recomenda verificar a identidade estável do servidor quando a falha se repete.

Não anuncie uma manutenção “sem remontagem” quando a identidade subjacente muda efetivamente. Uma janela de remontagem documentada é preferível a permitir que as aplicações descubram um erro ESTALE durante escritas normais.

Teste o caminho do cliente antes de retirar o conjunto de dados antigo

Monte a exportação a partir de um cliente novo e de um cliente existente não crítico e, em seguida, compare a identidade do diretório, as permissões, leituras representativas, uma escrita reversível e o caminho esperado pela aplicação. Reinicie um cliente para comprovar que a configuração de montagem persistente não foi alterada.

Um caso no Arch Linux concluiu que uma raiz NFS estável evita ESTALE após alterações no sistema de ficheiros de backend.

A reorganização está concluída quando os clientes continuam a utilizar o caminho exportado original e o conjunto de dados antigo pode ser retirado sem referências ocultas. O artigo relacionado da ZimaSpace sobre identificadores obsoletos após a alteração do nome de um conjunto de dados é a opção de recuperação caso o erro ESTALE já tenha surgido.