Migliore compressione per ZFS send / recv

Sto inviando snapshot ZFS incrementali su una linea T1 punto-punto e stiamo arrivando a un punto in cui un giorno di snapshot di un giorno riesce a malapena a passare sul filo prima che inizi il backup successivo. Il nostro comando send / recv è:

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | bzip2 -c | \
ssh offsite-backup "bzcat | zfs recv -F tank/vm"

Ho molti cicli di CPU da risparmiare. Esiste un algoritmo di compressione o un metodo alternativo migliore che posso usare per spingere meno dati sulla linea?

Sembra che tu abbia provato tutti i migliori meccanismi di compressione e che sia ancora limitato dalla velocità della linea. Supponendo che eseguire una linea più veloce sia fuori discussione, hai considerato di eseguire i backup con minore frequenza in modo da avere più tempo per l'esecuzione?

A parte questo, esiste un modo per ridurre la quantità di dati scritti? Senza conoscere lo stack dell'applicazione è difficile dire come, ma fare semplicemente cose come assicurarsi che le app sovrascrivano i file esistenti invece di crearne di nuovi potrebbe aiutare. E assicurandoti di non salvare i backup dei file temp / cache che non ti serviranno.

Ecco cosa ho imparato facendo esattamente la stessa cosa che stai facendo. Suggerisco di usare mbuffer. Durante i test nel mio ambiente ha aiutato solo la parte ricevente, senza di essa la mandata rallenterebbe mentre la ricezione raggiungeva.

Alcuni esempi: http://everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

Pagina iniziale con opzioni e sintassi http://www.maier-komor.de/mbuffer.html

Il comando send dal mio script di replica:

zfs send -i tank/pool@oldsnap tank/pool@newsnap | ssh -c arcfour remotehostip "mbuffer -s 128k -m 1G | zfs receive -F tank/pool"

questo esegue mbuffer sull'host remoto come buffer di ricezione, quindi l'invio viene eseguito il più velocemente possibile. Ho eseguito una linea a 20 mbit e ho scoperto che avere mbuffer anche sul lato di invio non mi ha aiutato, anche la mia casella zfs principale sta usando tutto il suo ram come cache, quindi dare anche 1g a mbuffer mi richiederebbe di ridurre alcune dimensioni della cache.

Inoltre, e questa non è davvero la mia area di competenza, penso che sia meglio lasciare che ssh faccia la compressione. Nel tuo esempio penso che tu stia usando bzip e quindi usando ssh che per impostazione predefinita usa la compressione, quindi SSH sta cercando di comprimere un flusso compresso. Ho finito per usare arcfour come codice poiché è il meno dispendioso in termini di CPU e questo è stato importante per me. Potresti avere risultati migliori con un altro codice, ma suggerirei sicuramente di lasciare che SSH esegua la compressione (o disattivare la compressione ssh se vuoi davvero usare qualcosa che non supporta).

Ciò che è veramente interessante è che l'uso di mbuffer durante l'invio e la ricezione su localhost velocizza anche le cose:

zfs send tank/pool@snapshot | mbuffer -s 128k -m 4G -o - | zfs receive -F tank2/pool

Ho scoperto che il 4g per i trasferimenti localhost sembra essere lo sweetspot per me. Ciò dimostra che zfs send / ricezione non gradisce molto la latenza o qualsiasi altra pausa nello stream per funzionare al meglio.

Solo la mia esperienza, spero che questo aiuti. Mi ci è voluto un po 'per capire tutto questo.

Questa è una risposta alla tua domanda specifica:

Puoi provare rzip , ma funziona in modi leggermente diversi da compress / bzip / gzip:

rzip prevede di poter leggere l'intero file, quindi non può essere eseguito in una pipeline. Ciò aumenterà notevolmente i requisiti di archiviazione locale e non sarà possibile eseguire un backup e inviare il backup tramite cavo in un unico tubo. Detto questo, i file risultanti, almeno secondo questo test, sono un po 'più piccoli.

Se il tuo vincolo di risorse è la tua pipe, eseguirai comunque i backup 24x7, quindi dovrai solo copiare le istantanee costantemente e sperare di tenerti comunque aggiornato.

Il tuo nuovo comando sarebbe:

remotedir=/big/filesystem/on/remote/machine/
while 
  snaploc=/some/big/filesystem/
  now=$(date +%s)
  snap=snapshot.$now.zfssnap
  test -f $snaploc/$snap
do
  sleep 1
done

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > $snaploc/$snap &&
rzip $snaploc/$snap &&
ssh offsite-backup "
        cat > $remotedir/$snap.rzip && 
        rzip -d $remotedir/$snap.rzip && 
        zfs recv -F tank/vm < $remotedir/$snap &&
        rm $remotedir/$snap " < $snaploc/$snap &&
rm $snaploc/$snap

Ti consigliamo di apportare una migliore correzione degli errori e ti consigliamo di utilizzare qualcosa come rsync per trasferire i file compressi, quindi se il trasferimento non riesce nel mezzo puoi riprendere da dove avevi interrotto.

Le cose sono cambiate negli anni da quando questa domanda è stata pubblicata:

1: ZFS ora supporta la replica compressa, basta aggiungere il flag -c al comando zfs send e i blocchi che sono stati compressi sul disco rimarranno compressi mentre passano attraverso la pipe all'altra estremità. Potrebbe esserci ancora più compressione da guadagnare, poiché la compressione predefinita in ZFS è lz4

2: Il miglior compressore da utilizzare in questo caso è zstd (ZStandard), ora ha una modalità 'adattiva' che cambierà il livello di compressione (tra i 19+ livelli supportati, più i nuovi livelli zstd-fast ad alta velocità) basato su la velocità del collegamento tra zfs send e zfs recv. Comprime il più possibile mantenendo la coda di dati in attesa di uscire dal pipe al minimo. Se il tuo collegamento è veloce, non perderà tempo a comprimere di più i dati e se il tuo collegamento è lento, continuerà a funzionare per comprimere di più i dati e alla fine ti farà risparmiare tempo. Supporta anche la compressione filettata, quindi posso sfruttare più core, cosa che gzip e bzip no, al di fuori di versioni speciali come pigzip.

Suppongo che semplicemente non puoi aumentare la larghezza di banda grezza del tuo sito ...

Potresti vedere i vantaggi del non usare la compressione sull'host.

Se usi qualcosa come un wan optimizer, sarà in grado di ottimizzare il trasferimento molto meglio se non comprimi il file prima di inviarlo, cioè fai esattamente quello che stai facendo ma rimuovi bzip2 dalla pipe. Dopo un paio di esecuzioni del backup, l'ottimizzatore WAN avrà memorizzato nella cache una frazione molto grande delle cose che vede nel trasferimento e vedrai enormi miglioramenti nelle velocità di trasferimento.

Se siete su un budge limitato, si potrebbe essere in grado di vedere un miglioramento simile utilizzando rsync e rsyncing la compresso snapshot, vale a dire:

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > /path/to/snapshotdir/snapshotfile
rsync /path/to/snapshotdir/snapshotfile offsite-backup:/remote/path/to/snapshotfile
ssh offsite-backup 'zfs recv -F tank/vm < /remote/path/to/snapshotfile'

Questo sarebbe più veloce perché rsync trasferiva solo le differenze tra l'istantanea di ieri e quella di oggi. A seconda di come funziona il processo di snapshot, potrebbe esserci ancora molta ridondanza tra i due anche se non sono proprio lo stesso file.

L'ottimizzatore wan è di gran lunga un modo più probabile per risolvere questo problema (beh, metro ethernet è il modo più probabile per risolvere questo problema, ma lo lasceremo fuori dal tavolo). Il rsync è solo uno scatto selvaggio al buio che vale la pena testare (localmente; rsync ti dirà quanto tempo ha risparmiato su una copia semplice) sui tuoi dati locali prima di scrivere il grande controllo per fibra o un'installazione riverbed.

Per quello che vale. Non farei un invio diretto | comprimere | decomprimere | ricevere questo può causare problemi alla fine della ricezione se la linea di trasferimento si blocca e i vostri pool rimarranno offline per molto tempo durante la ricezione. Inviamo a un file locale, quindi comprimiamo l'istantanea e trasferiamo usando rsync (con riverbed), quindi riceviamo dal file. Il letto del fiume non ottimizza il traffico MA se c'è un problema con il trasferimento e deve essere riavviato il letto del fiume accelera il rinvio.

Abbiamo cercato di non comprimere l'istantanea incrementale, usando la compressione Rsync e non usando alcuna compressione diversa dal letto del fiume. È difficile dire quale sia la migliore, ma quando trasferiamo archivi da oracle con compressione rsync, la velocità di trasferimento è circa il doppio di quella dei file semplici e del letto (con RSync).

Se hai un riverbed, usa rsync non ssh poiché il riverbed capisce rsync e proverà a ottimizzarlo e aggiungerà i dati alla cache (vedi sopra, riavvio dei trasferimenti).

La mia esperienza è zfs sendpiuttosto esplosiva nonostante sia molto più veloce (in media) del successivo passaggio di compressione. Il mio backup inserisce un notevole buffering dopo zfs sende altro dopo gzip:

zfs send $SNAP | mbuffer $QUIET -m 100M | gzip | mbuffer -q -m 20M | gpg ... > file

Nel mio caso il dispositivo di output è collegato tramite USB (non di rete), ma il buffering è importante per un motivo simile: il tempo di backup complessivo è più veloce quando l'unità USB è occupata al 100%. Non è possibile inviare un numero inferiore di byte complessivi (come richiesto), ma è comunque possibile terminare prima. Il buffering impedisce al passo di compressione associato alla CPU di diventare IO-associato.

Uso pbzip2 sempre (parallel bzip2) quando invio tramite WAN. Poiché è thread, è possibile specificare il numero di thread da utilizzare con l'opzione -p. Installare prima pbzip2 su entrambi gli host di invio e ricezione, le istruzioni di installazione sono disponibili all'indirizzo http://compression.ca/pbzip2/ .

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
ssh offsite-backup "pbzip2 -dc | zfs recv -F tank/vm"

La chiave principale è creare istantanee a intervalli frequenti (~ 10 minuti) per ridurre le dimensioni dell'istantanea, quindi inviare ogni istantanea. ssh non riprenderà da un flusso di snapshot interrotto, quindi se si ha un'istantanea enorme da inviare, reindirizzare il flusso su pbzip2, quindi dividerlo in blocchi di dimensioni gestibili, quindi rsincronizzare i file divisi sull'host ricevente, quindi reindirizzare a zfs recuperare i file concatenati pbzip2.

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
split -b 500M - /somedir/snap-inc-10-to-12.pbzip2--

questo produrrà file denominati in blocchi da 500 MB:

/somedir/snap-inc-10-to-12.pbzip2--aa
/somedir/snap-inc-10-to-12.pbzip2--ab
/somedir/snap-inc-10-to-12.pbzip2--ac
...

rsync per ricevere l'host più volte (è possibile rsync anche prima che zfs invii completato o non appena si vede un blocco completo da 500 MB), premere ctrl + c in qualsiasi momento per annullare:

while [[ true ]]; do rsync -avP /somedir/snap-inc-10-to-12.pbzip2--* offsite-backup:/somedir ; sleep 1; done;

zfs riceve:

cat /somedir/snap-inc-10-to-12.pbzip2--* | pbzip2 -dc | zfs recv -Fv tank/vm

Freind utente menzionato: per quello che vale. Non farei un invio diretto | comprimere | decomprimere | ricevere questo può causare problemi alla fine della ricezione se la linea di trasferimento si blocca e i vostri pool rimarranno offline per molto tempo durante la ricezione. - In precedenza ho riscontrato problemi con versioni precedenti di zfs <28 nell'host ricevente se un invio / recv in corso è interrotto da interruzioni di rete ma non nella misura in cui i pool sono off-line. Interessante. Invia nuovamente l'istantanea solo se "zfs recv" è uscito alla fine della ricezione. Se necessario, uccidi manualmente "zfs recv". zfs send / recv ora è molto migliorato in FreeBSD o Linux.

Puoi prendere un codice più veloce per ssh forse blowfish-cbc, prova anche gli interruttori -123456789

-1 (or --fast) to -9 (or -best)

Dovrai testare con i tuoi dati. Basta inviarlo a un file e comprimerlo con ogni metodo.

Per noi, gzip ha fatto un'enorme differenza e abbiamo analizzato tutto ciò, ma non c'era nemmeno una differenza dell'1% tra gzip e bzip o 7z.

Se hai un T1 lento, dovrai memorizzarlo in un file e risincronizzarlo.

Per quelli (non tu) che sono limitati un po 'di più dalla CPU rispetto alla larghezza di banda, come lstvan ha detto che una cifra diversa come arcfour128 accelera le cose. Lo usiamo internamente quando spostiamo le cose.

Prova a attivare dedup per zfs invia con -D. Il risparmio dipende ovviamente da quanta duplicazione c'è nei tuoi dati.

L'algoritmo di compressione "migliore" dipende dal tipo di dati che hai - se stai spingendo una compressione della raccolta MP3 probabilmente rallenterà il processo, mentre i file di testo / log possono essere compressi in modo significativo gzip -9.

Quanti dati stai spingendo ogni giorno?

Hai preso in considerazione l'ottimizzazione dello stack TCP / IP in modo che il buffer TCP e le dimensioni della finestra siano un po 'più grandi? è possibile utilizzare lo nddstrumento su Solaris per questo o lo sysctlstrumento su Linux / BSD / Mac OSX. Su Solaris, si sta cercando la /dev/tcp tcp_max_bufe /dev/tcp tcp_cwnd_maxvalori, e su Linux sysctl, siete alla ricerca di net.ipv4.tcp_mem, net.ipv4.tcp_rmeme net.ipv4.tcp.wmemvalori.

Inoltre, questi collegamenti potrebbero essere di ulteriore aiuto:

Ottimizzazione delle prestazioni di Solaris TCP

C'è una serie di collegamenti in fondo a quella pagina che spiegheranno come fare lo stesso anche per Linux / BSD / OSX.