Qualcuno ha raggiunto la vera sincronizzazione differenziale con rsync in ESXi?

Beratemi più tardi sul fatto che sto usando la console di servizio per fare qualsiasi cosa in ESXi ...

Ho un binario rsync funzionante (v3.0.4) che posso usare in ESXi 4.1U1. Tendo a utilizzare rsync su cp quando si copiano VM o backup da un archivio dati locale a un altro archivio dati locale. Ho usato rsync per copiare i dati da una scatola ESXi a un'altra, ma era solo per piccoli file.

Nel tentativo di eseguire sincere sincronizzazioni differenziali di backup eseguite tramite ghettoVCB tra la mia macchina ESXi primaria e una secondaria. Ma anche quando lo faccio localmente (un archivio dati su un altro archivio dati sulla stessa macchina ESXi) rsync sembra copiare i file nella loro interezza. Ho totalmente 80GB due di VMDK in termini di dimensioni, e rsync vuole ancora ovunque tra 1 e 2 ore, ma i di VMDK non crescono che tanto tutti i giorni.

Di seguito è riportato il comando rsync che sto eseguendo. Sto copiando localmente perché alla fine questi file verranno copiati su un archivio dati creato da un LUN su un sistema remoto. Non è un rsync che sarà servito da un demone rsync su un 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

Questo perché ESXi sta apportando così tante modifiche ai VMDK che per quanto riguarda rsync è necessario ritrasmettere l'intero file?

Qualcuno ha effettivamente raggiunto l'effettiva sincronizzazione diff con ESXi?

Sembra che tu abbia trasferito solo 2 GB di modifiche incrementali. Ricorda che rsync deve ancora leggere in un intero file e controllarlo, quindi deve leggere 80 GB di dati. Controlla le statistiche del tuo server durante rsync. Sei CPU o IO vincolato durante l'operazione? Quanto velocemente puoi leggere il file da 80 GB dal disco? Sarà vicino al tempo di trasferimento minimo assoluto.

Si noti inoltre che rsync esegue una copia del file durante il trasferimento, quindi sposta il file finale in posizione in un'operazione atomica. Puoi vederlo vedendo un nome di file simile con un suffisso casuale durante il trasferimento nella directory di destinazione. Ciò significa che devi leggere 160 GB di dati (80 GB ciascuno per ogni sorgente e destinazione) e scrivere 80 GB sul lato di destinazione. Hai guardato l'opzione --inplace? Potrebbe essere utile qui.

In breve, potresti avere solo 2 GB di modifiche, ma rsync sta facendo MOLTO lavoro. Probabilmente sei legato all'IO poiché tutto ciò che leggere e scrivere sullo stesso disco potrebbe causare molte contese e rallentamenti.

Questo thread è molto vecchio, ma può aiutare qualcuno.

Dato che ESX sta bloccando il filesystem ad ogni scrittura di nuovi blocchi, le prestazioni non sono così grandi, con l'opzione - invece puoi ottenere risultati migliori, ma fai attenzione, se annulli la sincronizzazione, il file non sarà coerente Di Più. Per quanto riguarda la coerenza, rsync di un file aperto potrebbe essere in qualche modo incoerente -> utilizzare meglio lo snapshot prima di rsync.

I migliori saluti Marc

A quanto pare, stai facendo una copia da locale a locale rsync. In tal caso, il comportamento predefinito di rsyncè disattivare l'algoritmo di trasferimento delta ed eseguire trasferimenti di "file interi". La logica di questo comportamento predefinito è che i trasferimenti da locale a locale che utilizzano l'algoritmo delta-xfer sarebbero generalmente più lenti della semplice copia di tutti i file, poiché l'algoritmo delta comporta molto più scricchiolio della CPU rispetto alla semplice copia di interi file.

Se ritieni che una copia da locale a locale trarrebbe beneficio dall'uso dell'algoritmo delta-xfer, puoi forzare rsynca usarlo specificando l' opzione --no-W(o --no-whole-file).