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:
- 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.
- (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).
- 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.
- 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.
- 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.