Como você sincroniza arquivos esparsos enormes (imagens de disco da VM) entre máquinas?

22

Existe um comando, como o rsync, que pode sincronizar arquivos enormes e esparsos de um servidor linux para outro?

É muito importante que o arquivo de destino permaneça escasso. Pode ser mais longo (mas não maior) do que a unidade que o contém. Somente blocos alterados devem ser enviados através do fio.

Eu tentei o rsync, mas não tenho alegria. https://groups.google.com/forum/#!topic/mailing.unix.rsync/lPOScZgFE9M

Se eu escrever um programa para fazer isso, estou apenas reinventando a roda? http://www.finalcog.com/synchronise-block-devices

Obrigado,

Chris.

linux rsync kvm-virtualization

— fadedbee
fonte

O rsync é extremamente ineficiente com arquivos enormes. Mesmo com --inplace primeiro irá ler todo o arquivo no host de destino e então começar a ler o arquivo na máquina local e transferir as diferenças (basta executar dstat ou similar durante a execução rsync e observar)

— ndemou

21

rsync --ignore-existing --sparse ...

Para criar novos arquivos no modo esparso

Seguido por

rsync --inplace ...

Para atualizar todos os arquivos existentes (incluindo os esparsos criados anteriormente) no local.

— Steve P
fonte

3

Invertê-la para ter rsync --existing --inplacee, em seguida, rsync --ignore-existing --sparseter um aumento de velocidade de sincronização

— Mike

2

Alguém pode explicar o comentário de Mikes e como isso deve acelerar a sincronização?

— Preexo

Acho que Mike quer dizer primeiro a mudança no local e, em seguida, adicionar novos, para que os novos não precisem estar - no local novamente devido à diferença de horário entre a primeira e a segunda chamada. Só é verdade se você sincronizar diretamente fora do armazenamento de dados e as VMs estiverem em execução. A menos que ele queira dizer outra coisa?

— Yuan

Eu concordo com Yuan. O segundo comando do Steves irá sincronizar novamente os novos arquivos, você pode garantir isso usando a sequência de comandos do Mikes.

— falstaff

O rsync é extremamente ineficiente com arquivos enormes. Veja meu comentário sobre a questão.

— ndemou 26/09

5

O Rsync transfere apenas as alterações para cada arquivo e com --inplace deve reescrever os blocos que foram alterados sem recriar o arquivo. Na página de recursos .

rsync é um programa de transferência de arquivos para sistemas Unix. O rsync usa o "algoritmo rsync", que fornece um método muito rápido para sincronizar arquivos remotos. Isso é feito enviando apenas as diferenças nos arquivos através do link, sem exigir que os dois conjuntos de arquivos estejam presentes em uma das extremidades do link antes.

Usar --inplace deve funcionar para você. Isso mostra o progresso, compacta a transferência (no nível de compactação padrão), transfere o conteúdo do diretório de armazenamento local recursivamente (a primeira barra é importante), faz as alterações nos arquivos existentes e usa ssh para o transporte.

rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
user@remote.machine:/path/to/remote/storage/

Costumo usar também a bandeira -a, que faz mais algumas coisas. É equivalente a -rlptgoD. Vou deixar o comportamento exato para você procurar na página de manual.

— reconectar
fonte

1

O '-S' é para arquivos esparsos, não para 'cortar linhas longas'. Na página do manual: -S, --sparse lida com arquivos esparsos com eficiência. Vou tentar, obrigado.

— Fadedbee 18/09/09

Obrigado, eu consertei isso - eu estava saindo de algo que foi dito no link que você deu.

— reconbotou 18/09/09

Não, infelizmente isso não resolve o problema. Ele faz sincronização do arquivo, mas transforma o arquivo esparso na extremidade em um arquivo não-esparsos. Estou usando o ssh / rsync, que vem com o Ubuntu 9.04.

— Fadedbee 26/09/09

Meu comentário acima estava incorreto. O problema era que o rsync cria arquivos não esparsos em sua primeira cópia. O --inplace rsync funciona corretamente, desde que o arquivo de destino já exista e seja tão longo (não grande) quanto o arquivo de origem. Agora tenho uma solução, mas é necessário verificar se cada arquivo já existe no servidor de destino. Se isso acontecer, eu faço um --inplace, se isso não acontecer, eu uso --sparse. Isso não é o ideal, mas funciona.

— Fadedbee 26/09/09

O rsync é extremamente ineficiente com arquivos enormes. Veja meu comentário sobre a questão

— ndemou 26/09

4

Acabei escrevendo software para fazer isso:

http://www.virtsync.com

Este é um software comercial que custa US $ 49 por servidor físico.

Agora, posso replicar um arquivo esparso de 50 GB (com 3 GB de conteúdo) em menos de 3 minutos na banda larga residencial.

chris@server:~$ time virtsync -v /var/lib/libvirt/images/vsws.img backup.barricane.com:/home/chris/
syncing /var/lib/libvirt/images/vsws.img to backup.barricane.com:/home/chris/vsws.img (dot = 1 GiB)
[........>.........................................]
done - 53687091200 bytes compared, 4096 bytes transferred.

real    2m47.201s
user    0m48.821s
sys     0m43.915s

— fadedbee
fonte

4

TBH, o momento em que você pode sincronizar é bastante sem sentido, porque obviamente depende da quantidade de dados alterados. O que seria mais preciso dizer é que o software leva três minutos para descobrir quais blocos foram alterados, e mesmo essa velocidade provavelmente depende da E / S do disco e talvez dos ciclos de CPU disponíveis.

— Reality Extractor

6

Você deve divulgar que este é um software comercial que custa US $ 98 ou mais pela funcionalidade de rede.

— Reid

Obrigado por nos indicar um software que funcionou bem para você, que as pessoas agora podem considerar e usar ou não usar conforme necessário. Não, obrigado pelas outras duas pessoas pela contribuição, nada de novo.

— Florian Heigl

3

Dê uma olhada no Zumastor Linux Storage Project, que implementa o backup "instantâneo" usando o binário "rsync" por meio da ddsnapferramenta.

Na página de manual:

O ddsnap fornece replicação de dispositivo de bloco, dado um recurso de captura instantânea no nível do bloco capaz de armazenar várias capturas instantâneas simultâneas com eficiência. O ddsnap pode gerar uma lista de blocos de snapshots que diferem entre dois snapshots e depois enviar essa diferença pela conexão. Em um servidor downstream, grave os dados atualizados em um dispositivo de bloco com captura instantânea.

— rkthkr
fonte

2

O lvmsync faz isso.

Aqui está uma transcrição de uso . Ele cria um instantâneo LVM na origem, transfere a partição lógica. Você pode transferir atualizações incrementais das alterações desde a criação da captura instantânea quantas vezes quiser.

— Tobu
fonte

Eu tentei, mas ele não funciona, e autor não está disposto a suporte

— user1007727

1

@ user1007727 não está disposto a apoiar ou não está disposto a apoiar gratuitamente?

— Fadedbee

Eu usei o lvmsync no passado, funcionou, mas não é um software "de nível superior". :-)

— Florian Heigl

1

A replicação de todo o sistema de arquivos pode ser uma solução? DRBD? http://www.drbd.org/

— James C
fonte

Não acho que o drbd seja uma boa solução aqui, mas a idéia de sincronizar - em todo o fs, em vez dos arquivos de imagem de disco, é interessante. Não estou certo se rsync permite isso - eu vou dar-lhe uma tentativa e relatório de volta ...

— fadedbee

1

Talvez um pouco estranho aqui, mas descobri recentemente que o NFS lida com isso.

Então você exporta um diretório em uma máquina, monta-o na outra e copia os arquivos com utilitários básicos, como cp. (Alguns utilitários antigos / antigos podem ter problemas com arquivos esparsos.)

Achei rsyncespecialmente ineficiente na transferência de arquivos esparsos.

— cstamas
fonte

1

Para sincronizar arquivos grandes ou dispositivos de bloco com diferenças baixas a moderadas, você pode fazer uma cópia simples ou usar o bdsync , o rsync não é absolutamente adequado para este caso em particular *.

bdsyncfuncionou para mim, parece maduro o suficiente, sua história de bugs é encorajadora (pequenos problemas, pronta resolução). Nos meus testes, a velocidade estava próxima do máximo teórico que você poderia obter ** (ou seja, você pode sincronizar o tempo necessário para ler o arquivo). Finalmente, é de código aberto e não custa nada.

bdsynclê os arquivos dos hosts e troca somas de verificação para compará-los e detectar diferenças. Tudo isso ao mesmo tempo . Finalmente, ele cria um arquivo de patch compactado no host de origem. Em seguida, você move esse arquivo para o host de destino e executa o bdsync uma segunda vez para corrigir o arquivo de destino.

Ao usá-lo em um link bastante rápido (por exemplo, 100Mbit ethernet) e para arquivos com pequenas diferenças (como costuma acontecer em discos de VM), reduz o tempo para sincronizar com o tempo necessário para ler o arquivo. Em um link lento, você precisa de um pouco mais de tempo, porque precisa copiar as alterações compactadas de um host para outro (parece que você pode economizar tempo usando um truque legal, mas não testou).

*: rsync é extremamente ineficiente com arquivos enormes. Mesmo com --inplace ele primeiro lê o arquivo inteiro no host de destino, o AFTERWARDS começa a ler o arquivo no host de origem e, finalmente, transfere as diferenças (apenas execute dstat ou similar ao executar o rsync e observe). O resultado é que, mesmo para arquivos com pequenas diferenças, leva cerca do dobro do tempo necessário para ler o arquivo para sincronizá-lo.

**: Supondo que você não tenha outra maneira de dizer quais partes dos arquivos foram alteradas. Os instantâneos do LVM usam bitmaps para registrar os blocos alterados, para que possam ser extremamente mais rápidos (o leia-me do lvmsync tem mais informações).

— ndemou
fonte

0

Não conheço esse utilitário, apenas as chamadas do sistema que podem lidar com isso; portanto, se você escrever esse utilitário, pode ser bastante útil.

o que você realmente pode fazer é usar o qemu-img convert para copiar os arquivos, mas só funcionará se o FS de destino suportar arquivos esparsos

— dyasny
fonte