Eu preciso migrar cerca de 1 TB de dados compostos de arquivos menores (a maioria abaixo de 100 KB) para outro servidor. Eu nem sequer listei completamente os arquivos, mas as estimativas são entre 1-2 milhões.
A cópia inicial usando o SCP levou mais de uma semana. Agora temos que sincronizar as alterações. Centenas a milhares de arquivos são adicionados diariamente.
Eu tentei usar o rsync (v3), mas está demorando muito. Quando terminar, voltaremos a ter dados fora de sincronia novamente.
Eu já vi perguntas semelhantes aqui, mas elas são um pouco antigas e pergunto se há novas ferramentas para ajudar nesse processo.
Os problemas são mais complicados pelos dados de origem que estão em um sistema iSCSI compartilhado com baixo desempenho de leitura.
A estratégia mais recente pode ser a de refazer a migração de dados e fazer com que os desenvolvedores gravem uma ferramenta para registrar todos os novos arquivos adicionados durante o processo de migração. As chaves de estrutura de diretórios de um identificador exclusivo são muito amplas e profundas, portanto, os novos arquivos estão espalhados nessa estrutura e a reescrita do aplicativo para colocar novos arquivos em um diretório específico não funcionará.
Qualquer estratégia apreciada.
OS é o RHEL 5 que vai para o RHEL 6.
Isso está sendo feito em fases:
1) transer inicial usando scp 2) alguns dados atualizados com rsync 3) devs estão escrevendo um script para puxar arquivos adicionados desde o passo 1 para o sistema 4) irá proxy dados do servidor original para novo servidor durante a mudança de dns 5) mudar o dns e se livrar de serviços iSCSI compartilhados.
Eu ficaria tentado a responder "pare de abusar do sistema de arquivos tratando-o como um banco de dados", mas tenho certeza de que isso não ajudaria muito;)
Primeiro, você precisa entender que, se sua limitação estiver na largura de banda disponível na leitura, não há nada que você possa fazer para melhorar o desempenho usando um simples comando de sincronização. Nesse caso, você terá que dividir os dados quando forem gravados, alterando a maneira como os arquivos são criados (o que significa, como você adivinhou corretamente, pedindo que os desenvolvedores alterem o programa de origem) ou usando um produto que faz geo-espelhamento (como, por exemplo, double-take : verifique como eu ' Você certamente encontrará alternativas, isso é apenas um exemplo).
Em casos semelhantes, a principal causa do problema não é normalmente os dados do arquivo, mas sim o acesso aos metadados. Sua primeira estratégia, portanto, será dividir a carga em vários processos que agem em diretórios (completamente) diferentes: isso deve ajudar o sistema de arquivos a acompanhar os metadados que você precisa.
Outra estratégia é usar seu sistema de backup para isso: reproduzir seus últimos backups incrementais no destino para manter o banco de dados em sincronia.
Finalmente, existem mais estratégias exóticas que podem ser aplicadas em casos específicos. Por exemplo, eu resolvi um problema semelhante em um site do Windows, escrevendo um programa que carregava os arquivos no sistema de arquivos a cada poucos minutos, mantendo assim o FS limpo.
Eu não acho que nada tenha mudado. Se você puder quiesce os dados no sistema de origem, acho que alguns variante do tar serão os mais rápidos. Caso contrário, o rsync ainda é a melhor maneira, assegurando-se de usar a opção de arquivo inteiro e um algoritmo de compactação com menos uso da CPU (por exemplo, arcfour). Você tem alguma opção para realizar uma cópia em nível de bloco? Você menciona o armazenamento iSCSI. O novo sistema também terá armazenamento anexado ao iSCSI?