Migrando servidor NFS (Linux)

Migrando servidor NFS (Linux)

Temos um servidor NFS (Linux) que armazena arquivos em uma matriz de disco iSCSI. Este servidor está em produção. O servidor e o array são muito antigos e precisam ser substituídos em breve (o array já está com sérios problemas).

Tenho o servidor e o array substitutos prontos em uma rede diferente.

Estou pensando em sincronizar novamente os compartilhamentos e depois fazê-lo novamente para sincronizar os dados. Não sei se isso poderia causar inconsistências de dados... Como os compartilhamentos são montados em um lvm, talvez eu pudesse fazer um snapshot primeiro?

PERGUNTA:

Qual é a melhor abordagem para migrar todos os dados? Você tem algum conselho?

Responder1

Sua abordagem é adequada, se você planeja desabilitar a gravação no array antes do segundo rsync. Isso (deveria) levar a uma cópia limpa.

Dependendo das circunstâncias, para minimizar o tempo de inatividade, faça um rsync triplo:

  1. sincronize novamente os sistemas de arquivos enquanto o servidor de origem está sendo executado como está. Isso levará algum tempo e você obterá uma cópia aproximada, possivelmente com muitas inconsistências.
  2. (opcional) Se o número 1 demorar muito e você tiver muitas gravações nesse meio tempo, sincronize-o novamente com o servidor de origem ainda em execução como está. Esta etapa levará menos tempo e você obterá uma cópia muito melhor (menos gravações aconteceram durante a execução).
  3. Pare de gravar no nó de origem. A melhor maneira é montá-lo somente leitura, como sugere o stoned. Mas desligar serviços ou usar o modo de usuário único também pode funcionar.
  4. sincronize novamente pela última vez. Desta vez deve ser bem rápido. Não deve haver muitas inconsistências (a etapa 2 é muito mais curta que a etapa 1), portanto, não há muito para sincronizar.
  5. Faça suas verificações e inicie o novo servidor no lugar do antigo.

Há várias coisas a serem observadas:

  • Se você tiver muitos arquivos pequenos (milhões), cada rsync levará algum tempo de qualquer maneira. (o mesmo vale para linhas lentas, armazenamentos lentos/degradados, etc.)
  • Se o seu armazenamento de origem já estiver apresentando problemas (unidades com falha ou algo que possa tornar o volume ilegível), comece no número 3. Você terá um longo tempo de inatividade, mas minimizará o risco de falha no meio da transferência.
  • Acabei de ter a ideia maluca de sincronizar novamente todo o dispositivo, onde o sistema de arquivos reside. O que poderia funcionar se o alvo fosse maior que a origem. Mas não recomendo isso, pois ainda não tentei.

Responder2

Rsync + rsync ou snapshot + rsync não farão muita diferença - com o rsync talvez sendo mais útil, já que você pode eventualmente compactar/criptografar dados durante a transferência sem o incômodo de ter que usar comandos extras. Em ambos os casos, você sempre tentará acompanhar o que seus usuários podem ter copiado no compartilhamento desde o último rsync, incluindo arquivos parciais ainda em trânsito. Sinceramente, o que eu recomendaria a você é fazer uma primeira cópia com o rsync em um período de baixo uso. Em seguida, avise seus usuários que haverá uma pequena interrupção devido à necessidade de manutenção. Pare a gravação de serviços no disco. Remonte o compartilhamento antigo no modo somente leitura, faça um rsync final e substitua completamente o compartilhamento nfs antigo pelo novo. Se quiser/puder, você pode conceder aos clientes acesso somente leitura durante esse período. 100% de disponibilidade é um sonho puro, e é melhor parar seus clientes por 1 hora do que correr atrás de possíveis reclamações intermináveis ​​de dados perdidos/corrompidos e falhas de aplicativos.

informação relacionada