Alguém conseguiu uma verdadeira sincronização diferencial com o rsync no ESXi?

Question

Mais tarde, faça-me a pergunta que estou usando o console de serviço para fazer qualquer coisa no ESXi ...

Eu tenho um binário de trabalho rsync (v3.0.4) que eu posso usar no ESXi 4.1U1. Eu costumo usar rsync sobre cp ao copiar VMs ou backups de um datastore local para outro datastore local. Eu usei o rsync para copiar dados de uma caixa do ESXi para outra, mas isso era apenas para arquivos pequenos.

Agora, estamos tentando fazer verdadeiras sincronizações diferenciais de backups feitos por ghettoVCB entre minha máquina principal do ESXi e uma secundária 1. Mas, mesmo quando eu faço isso localmente (um datastore para outro datastore na mesma máquina ESXi), o rsync parece copiar os arquivos na sua totalidade. Eu tenho dois VMDKs com 80GB de tamanho, e o rsync ainda leva entre 1 e 2 horas, mas os VMDK's não estão crescendo isso diariamente.

Abaixo está o comando rsync que estou executando. Estou copiando localmente porque, em última análise, esses arquivos serão copiados em um armazenamento de dados criado a partir de um LUN em um sistema remoto. Não é um rsync que será atendido por um daemon rsync em um sistema remoto.

rsync -avPSI VMBACKUP_2011-06-10_02-27-56/* VMBACKUP_2011-06-01_06-37-11/ --stats --itemize-changes --existing --modify-window=2 --no-whole-file
sending incremental file list
>f..t...... VM-flat.vmdk
 42949672960 100%   15.06MB/s    0:45:20 (xfer#1, to-check=5/6)
>f..t...... VM.vmdk
         556 100%    4.24kB/s    0:00:00 (xfer#2, to-check=4/6)
>f..t...... VM.vmx
        3327 100%   25.19kB/s    0:00:00 (xfer#3, to-check=3/6)
>f..t...... VM_1-flat.vmdk
 42949672960 100%   12.19MB/s    0:56:01 (xfer#4, to-check=2/6)
>f..t...... VM_1.vmdk
         558 100%    2.51kB/s    0:00:00 (xfer#5, to-check=1/6)
>f..t...... STATUS.ok
          30 100%    0.02kB/s    0:00:01 (xfer#6, to-check=0/6)

Number of files: 6
Number of files transferred: 6
Total file size: 85899350391 bytes
Total transferred file size: 85899350391 bytes
Literal data: 2429682778 bytes
Matched data: 83469667613 bytes
File list size: 129
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2432530094
Total bytes received: 5243054

sent 2432530094 bytes  received 5243054 bytes  295648.92 bytes/sec
total size is 85899350391  speedup is 35.24

É porque o próprio ESXi está fazendo tantas mudanças no VMDK que, no que diz respeito ao rsync, o arquivo inteiro precisa ser retransmitido?

Alguém realmente conseguiu sincronizar a diferença real com o ESXi?

    

Answer 1

Parece que você transferiu apenas 2 GB de alterações incrementais. Lembre-se que o rsync ainda tem que ler em um arquivo inteiro e soma-o para que ele tenha que ler 80GB de dados. Verifique as estatísticas do seu servidor durante o rsync. Você está cpu ou IO ligado durante a operação? Quão rápido você pode ler o arquivo de 80GB de disco? Isso estará perto do seu tempo de transferência mínimo absoluto.

Também é importante ressaltar que o rsync faz uma cópia do arquivo durante a transferência e, em seguida, move o arquivo final para o lugar em uma operação atômica. Você pode ver isso vendo um nome de arquivo semelhante com um sufixo aleatório durante a transferência no diretório de destino. Isso significa que você precisa ler 160 GB de dados (80 GB para cada origem e destino) e escrever 80 GB no lado do destino. Você já olhou para a opção --inplace? Pode ser benéfico aqui.

Em suma, você pode ter apenas 2 GB de alterações, mas o rsync está fazendo muito trabalho. Você provavelmente é IO ligado como tudo o que ler e escrever no mesmo disco poderia causar muita contenção e desaceleração.

    

Answer 2

Este Tópico é muito antigo, mas pode ajudar alguém.

Como o ESX está bloqueando o sistema de arquivos em cada gravação de novos blocos, o desempenho não é tão bom, com a opção --inplace você pode obter melhores resultados, mas esteja ciente, se você cancelar a sincronização, o arquivo não será mais consistente. Sobre a consistência, o rsync de um arquivo aberto pode ser inconsistente de qualquer maneira - > melhor usar o snapshot antes do rsync.

Atenciosamente Marc

    

Answer 3

Pelo que parece, você está fazendo uma cópia local para local com rsync . Nesse caso, o comportamento padrão de rsync é desativar o algoritmo de transferência delta e fazer transferências de "arquivo inteiro". A justificativa para esse comportamento padrão é que as transferências locais para locais usando o algoritmo delta-xfer normalmente seriam mais lentas do que simplesmente copiar os arquivos inteiros, já que o algoritmo delta envolve muito mais CPU do que apenas copiar arquivos inteiros.

Se você acha que uma cópia local para local se beneficiaria do uso do algoritmo delta-xfer, você pode forçar o rsync a usá-lo especificando a opção --no-W (ou --no-whole-file ).