Guia de migração de conjuntos de dados ZFS: mover dados sem alterar os caminhos dos contentores

A abordagem segura consiste em tratar a replicação, a verificação e a mudança atómica do ponto de montagem original, mantendo um conjunto de dados de reversão, como uma sequência de etapas observáveis, não como um único comando.

Num conjunto de dados ZFS que suporta uma pilha de contentores num servidor doméstico, o risco prático consiste em ter de mover um conjunto de dados ZFS preservando os caminhos de montagem vinculada utilizados pelos contentores. Registe a identidade atual e o ponto de recuperação, comece pelo discriminador menos invasivo, interprete os resultados de aprovação e falha antes de alterar outra variável e pare quando o armazenamento se tornar instável ou quando a única cópia recuperável ficar exposta. O fluxo de trabalho abaixo só termina quando a carga de trabalho original funciona com êxito ou quando as evidências atingem um limite de escalada.

Faça o inventário do conjunto de dados e do contrato de caminhos

Registe o conjunto de dados de origem, os descendentes, os instantâneos, o ponto de montagem, o valor de canmount, a raiz de encriptação, as quotas, as reservas, o comportamento das ACL e cada montagem vinculada de contentor que fique dentro dele. O contrato é o caminho do anfitrião que os contentores veem; o nome do pool e do conjunto de dados pode mudar por baixo desse caminho.

A replicação ZFS pode preservar instantâneos e propriedades, pelo que um fluxo recursivo exige uma revisão deliberada das propriedades, em vez de uma receção cega. Uma migração independente com ZFS send e receive mostra como send e receive são utilizados para a migração interna de conjuntos de dados e por que motivo a hierarquia de destino merece ser inspecionada antes da mudança.

Crie uma cópia de segurança externa atual ou comprove uma restauração existente antes da migração. Pare se a origem tiver conjuntos de dados descendentes ocultos, uma dependência desconhecida de chave de encriptação ou um ponto de montagem que se sobreponha a outro conjunto de dados ativo; essas condições podem fazer com que um fluxo correto seja montado no local errado.

Receba a primeira cópia sem a montar sobre a produção

Crie um instantâneo recursivo, como zfs snapshot -r oldpool/apps@move-0, e envie-o para um conjunto de dados de destino recebido com a montagem desativada ou com um ponto de montagem temporário. Utilize as opções adequadas aos seus requisitos de encriptação e propriedades; não presuma que um fluxo encriptado bruto e uma receção desencriptada têm o mesmo comportamento relativamente às chaves.

Após a receção, compare zfs list -r -t filesystem,snapshot e zfs get -r mountpoint,canmount,encryptionroot,quota,reservation em ambas as árvores. Uma discussão num fórum sobre propriedades de pontos de montagem replicadas ilustra por que motivo as propriedades de pontos de montagem replicadas podem surpreender numa migração que, de outro modo, foi bem-sucedida.

A primeira cópia é aprovada quando a ascendência dos conjuntos de dados e dos instantâneos coincide e o destino permanece isolado do caminho de produção. Se for montada sobre a origem ou alterar os ficheiros visíveis pelos contentores, exporte ou desmonte o destino e corrija as propriedades antes de qualquer envio incremental.

Feche a lacuna de escrita e mude o ponto de montagem

Faça outro instantâneo da origem e envie a diferença incremental enquanto a aplicação continua em execução. Para a mudança final, pare todos os processos de escrita, confirme que nenhum processo tem ficheiros abertos no caminho da montagem vinculada, faça um instantâneo final e envie apenas esse delta. Mantenha o período de indisponibilidade limitado à sincronização final e à mudança do caminho.

Defina a origem com um ponto de montagem que não seja de produção ou com canmount=noauto, atribua depois o caminho original do anfitrião ao destino e monte-o. Nunca deixe dois conjuntos de dados a reclamar o mesmo ponto de montagem. Inicie a base de dados e os serviços dependentes antes do front-end da aplicação, para que os erros apontem para a camada correta.

Se o envio final falhar, volte a montar a origem no caminho original e reinicie a pilha; não misture novas escritas entre as duas cópias. A condição de reversão é explícita: a origem permanece intacta e nenhuma escrita de produção é aceite no destino até que o fluxo final e as verificações de propriedades sejam aprovados.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valide os contentores no caminho inalterado

Inspecione as montagens vinculadas no runtime de contentores, abra ficheiros representativos, crie e remova um ficheiro descartável através da aplicação e confirme a propriedade, as ACL, os atributos estendidos e a comunicação do espaço livre. Reinicie a pilha duas vezes e verifique se o ZFS é montado antes do arranque dos contentores.

Execute um scrub ou outra verificação do estado do pool de acordo com o seu plano de manutenção, mas não o utilize como única prova da migração. Compare os GUID dos instantâneos ou um manifesto de hashes representativo, restaure um item pequeno e utilize o teste ZimaSpace para verificar se a replicação ZFS pode continuar após uma interrupção antes de descontinuar a linhagem da origem.

Mantenha a origem em modo só de leitura até que pelo menos um ciclo normal de cópia de segurança e aplicação seja concluído com êxito. Descontinue-a apenas quando os contentores utilizarem os caminhos originais, as tarefas agendadas apontarem para o novo conjunto de dados, a replicação continuar a partir da linhagem pretendida e a reversão já não for necessária; caso contrário, reverta o ponto de montagem e preserve ambos os históricos.