Sincronizando estruturas de pastas muito grandes

14

Temos uma estrutura de pastas em nossa intranet, que contém cerca de 800.000 arquivos divididos em cerca de 4.000 pastas. Precisamos sincronizar isso com um pequeno cluster de máquinas em nossos DMZs. A profundidade da estrutura é muito superficial (nunca excede dois níveis de profundidade).

A maioria dos arquivos nunca muda, a cada dia há alguns milhares de arquivos atualizados e 1-2 mil novos arquivos. Os dados são dados de relatórios históricos sendo mantidos onde os dados de origem foram eliminados (ou seja, são relatórios finalizados para os quais os dados de origem são suficientemente antigos para serem arquivados e excluídos). Sincronizar uma vez por dia é suficiente, dado que isso pode acontecer em um prazo razoável. Os relatórios são gerados durante a noite e nós sincronizamos a primeira hora da manhã como uma tarefa agendada.

Obviamente, como poucos arquivos são alterados regularmente, podemos nos beneficiar bastante com a cópia incremental. Nós tentamos o Rsync, mas isso pode levar de 8 a 12 horas apenas para completar a operação "Building File List". É claro que estamos superando rapidamente o que o rsync é capaz (o intervalo de 12 horas é muito longo).

Estávamos usando outra ferramenta chamada RepliWeb para sincronizar as estruturas, e ela pode fazer uma transferência incremental em cerca de 45 minutos. No entanto, parece que ultrapassamos o seu limite, ele começou a ver arquivos aparecer como exclusões quando eles não são (talvez alguma estrutura de memória interna foi esgotada, não temos certeza).

Alguém mais se deparou com um projeto de sincronização de grande escala desse tipo? Existe algo projetado para lidar com estruturas de arquivos massivas como essa para sincronização?

    
por MightyE 23.02.2010 / 20:26

5 respostas

9

Se você pode confiar nos registros de data e hora da última modificação do sistema de arquivos, pode acelerar o processo combinando o Rsync com o utilitário 'localizar' do UNIX / Linux. 'find' pode montar uma lista de todos os arquivos que mostram horários da última modificação no dia anterior, e então canalizar SOMENTE a lista abreviada de arquivos / diretórios para o Rsync. Isso é muito mais rápido do que fazer com que o Rsync compare os metadados de todos os arquivos do remetente com o servidor remoto.

Em suma, o comando a seguir executará Rsync SOMENTE na lista de arquivos e diretórios que foram alterados nas últimas 24 horas: (O Rsync NÃO se incomodará em verificar quaisquer outros arquivos / diretórios.)

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

Caso você não esteja familiarizado com o comando 'find', ele recursiva através de uma subárvore específica do diretório, procurando arquivos e / ou diretórios que atendam aos critérios especificados. Por exemplo, este comando:

find . -name '\.svn' -type d -ctime -0 -print

iniciará no diretório atual (".") e passará por todos os subdiretórios, procurando:

  • qualquer diretório ("-type d"),
  • com o nome ".svn" ("-name '.svn'"),
  • com metadados modificados nas últimas 24 horas ("-ctime -0").

Imprime o nome do caminho completo ("-print") de qualquer coisa que corresponda a esses critérios na saída padrão. As opções '-name', '-type' e '-ctime' são chamadas de "testes", e a opção '-print' é chamada de "ação". A página man do 'find' tem uma lista completa de testes e ações.

Se você quiser ser realmente inteligente, pode usar o teste '-cnewer' do comando 'find', em vez de '-ctime' para tornar esse processo mais tolerante a falhas e flexível. '-cnewer' testa se cada arquivo / diretório na árvore teve seus metadados modificados mais recentemente do que algum arquivo de referência. Use 'touch' para criar o arquivo de referência da corrida NEXT no início de cada corrida, antes do 'find ... | O comando rsync ... 'é executado. Aqui está a implementação básica:

#!/bin/sh
curr_ref_file='ls /var/run/last_rsync_run.*'
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

Esse script sabe automaticamente quando foi executado pela última vez e transfere apenas arquivos modificados desde a última execução. Embora isso seja mais complicado, ele protege você contra situações em que você pode ter perdido a execução do trabalho por mais de 24 horas, devido ao tempo de inatividade ou a algum outro erro.

    
por 23.02.2010 / 22:00
7

Experimente uníssono , ele foi projetado especificamente para resolver esse problema mantendo as listas de alterações (arquivo de construção lista), localmente para cada servidor, acelerando o tempo para calcular o delta e a quantidade de redução que é enviada pelo fio depois.

    
por 23.02.2010 / 21:47
3

link é projetado para esse tipo de coisa, eu daria uma chance.

    
por 24.02.2010 / 00:18
2

Se você estiver usando o comutador -z no rsync, tente executar sem ele. Por alguma razão eu vi isso acelerar a enumeração inicial de arquivos.

    
por 23.02.2010 / 21:58
2

Retirando-o do comando rsync, que não é compactação, a "lista de arquivos de recebimento" ficou muito mais rápida e tivemos que transferir cerca de 500 GB. Antes de levar um dia com o interruptor -z.

    
por 26.01.2015 / 03:44