
Contexto: Estamos trabalhando em um projeto de migração de dados que envolve a sincronização de dados entre um sistema de arquivos NFS local e um compartilhamento de arquivos baseado em NFS do Azure. O objetivo é garantir uma transição perfeita do ambiente local para o Azure, mantendo a integridade e a eficiência dos dados.
Fundo:
Fonte: sistema de arquivos NFS local.
Destino: partilha de ficheiros baseada no Azure NFS.
Tamanho dos dados: Aproximadamente 350 GB.
Uso da ferramenta:
AzCopy (sem suporte): inicialmente tentamos usar o AzCopy para migração de dados, mas descobrimos que ele não tem suporte com sistemas de arquivos NFS do Azure.
Rsync (problema de crescimento de armazenamento): Em seguida, recorremos ao Rsync para sincronização de dados. No entanto, encontrámos um crescimento significativo do armazenamento no destino Azure e o processo nunca foi concluído. O armazenamento continuou aumentando sem motivo aparente, obrigando-nos a abandonar o processo Rsync.
Fpsync (primeira tentativa bem-sucedida): para resolver o problema de crescimento do armazenamento, fizemos a transição para o Fpsync para sincronização de dados. Na primeira tentativa, mostrou-se promissor ao concluir com êxito a sincronização inicial.
O problema: crescimento inexplicável do armazenamento: Nosso principal desafio é o crescimento inexplicável na utilização do armazenamento no destino Azure NFS, especialmente com o Rsync. Mesmo quando o tamanho dos dados de origem permanece o mesmo, o armazenamento de destino aumenta significativamente, tornando o processo difícil de gerenciar.
Objetivo: Estamos buscando insights, conselhos ou soluções da comunidade para ajudar a solucionar esse problema de crescimento do armazenamento. Nosso objetivo é garantir a sincronização eficiente de dados e o uso mínimo de armazenamento no destino Azure.
Informações Adicionais: Os dados de origem, incluindo arquivos e diretórios ocultos, estão formatados e nomeados corretamente.
As permissões são preservadas durante a sincronização.
Embora tenhamos tido sucesso inicial com o Fpsync na primeira sincronização, as sincronizações subsequentes ainda apresentavam problemas de crescimento de armazenamento. Quaisquer sugestões, insights ou experiências relacionadas a este problema serão muito apreciadas. Queremos resolver este desafio e garantir uma migração de dados bem-sucedida para o Azure NFS.
Atualizar:
Agora usei o utilitário rclone e encontrei o mesmo problema.
Responder1
Leia man rsync
cuidadosamente. Experimente algumas opções para --dry-run --itemize-changes
ver o que exatamente seria feito.
Não fornecer nenhuma opção de exclusão significa que uma exclusão na origem não será refletida no destino. Ótimo para casos de uso de arquivamento, não tão bom para algo com retenção limitada, como arquivos de log com data marcada. Além disso, evite * curingas se quiser excluir arquivos, por página de manual:
--delete
This tells rsync to delete extraneous files from the receiving side (ones that aren't on the sending
side), but only for the directories that are being synchronized. You must have asked rsync to send
the whole directory (e.g. "dir" or "dir/") without using a wildcard for the directory's contents
(e.g. "dir/*") since the wildcard is expanded by the shell and rsync thus gets a request to transfer
individual files, not the files' parent directory.
"O comportamento padrão é criar cada arquivo temporário no mesmo diretório do arquivo de destino associado." Esses arquivos temporários permitem abortar a transferência, mas requerem espaço extra significativo. De forma conservadora, assuma o dobro do tamanho da fonte, para os piores cenários de necessidade de atualizar tudo. Das maneiras de alterar esse comportamento, talvez a mais agressiva seja --inplace
a que sobrecarrega os arquivos diretamente. Perigo: isso corromperá os arquivos em uso no destino, não é para casos de uso ativo/ativo.
Em relação ao desempenho, descubra quais são os fatores limitantes dos sistemas locais e remotos. Se eu inventar os números do pior caso, um milhão de arquivos em fusos lentos de 100 IOPS pode levar horas apenas para enumerar e comparar a lista de arquivos. No entanto, quando se trata de copiar dados de arquivos, gargalos podem fazer a transição para a largura de banda da rede e para a CPU para ssh e compactação.
Crie planos alternativos para uma cópia inicial que não sejam ferramentas de sincronização de arquivos. Por exemplo, faça um backup local do compartilhamento e restaure-o em um host no Azure com esse NFS montado. Mais rápido e simples de copiar um arquivo (.tar ou qualquer outro) pela rede e extrair tudo, em comparação com a sincronização incremental de arquivos.
Falando nisso, o rsync pode ser útil como incremental para atualizar as coisas após a cópia inicial. Ainda levará algum tempo para comparar, mas muito mais rápido se a taxa de alteração for baixa e não houver muito para copiar.