Sincronizzazione ZFS tramite WAN lenta e inaffidabile. Replica ZFS o rsync?

Mi è stato assegnato il compito di eseguire un backup off-site sulla WAN. Entrambe le scatole di memoria sono scatole NAS basate su FreeBSD che eseguono ZFS.

Una o due volte alla settimana, 15-60 concerti di dati fotografici vengono scaricati nel NAS dell'ufficio. Il mio compito è capire come ottenere questi dati fuori sede nel modo più affidabile possibile utilizzando la connessione DSL MOLTO LENTO (caricamento ~ 700Kb / s). La scatola di ricezione ha una forma molto migliore, a 30 Mb / s in basso, 5 Mb / s in su.

So che trasportare un disco rigido fuori sede sposta i dati molto più rapidamente, ma in questo caso non è un'opzione.

Le mie opzioni sembrano essere:

• Invio incrementale ZFS tramite ssh
• rsync

rsync è una soluzione consolidata nel tempo e ha l'abilità fondamentale di riprendere un invio se qualcosa viene interrotto. Ha lo svantaggio di scorrere su molti file e di non conoscere il dedup.

L'invio di snapshot ZFS potrebbe trasferire un po 'meno dati (sa molto di più sul file system, può fare il dedup, può impacchettare i cambiamenti dei metadati in modo più efficiente di rsync) e ha il vantaggio di duplicare correttamente lo stato del filesystem, piuttosto che semplicemente copiare file individualmente (che è più intenso su disco).

Sono preoccupato per le prestazioni di replica di ZFS [1] (sebbene l'articolo sia vecchio di un anno). Sono anche preoccupato di essere in grado di riavviare il trasferimento in caso di problemi: la capacità dell'istantanea non sembra includerlo. L'intero sistema deve essere completamente a mani libere.

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

Utilizzando entrambe le opzioni, dovrei essere in grado di deselezionare le priorità del traffico instradandolo attraverso una porta specifica, quindi utilizzando il QOS sui router. Devo evitare un grave impatto negativo sugli utenti di entrambi i siti durante ogni trasferimento, poiché ci vorranno diversi giorni.

Quindi ... questo è il mio pensiero sul problema. Ho perso qualche buona opzione? Qualcun altro ha creato qualcosa di simile?

1. Se riesci a trasferire un massimo di 6 GB al giorno (presupponendo zero sovraccarico e zero traffico in concorrenza) e devi spostare "15-60 concerti" con una frequenza di "una o due volte a settimana", che va da 15 a 120 GB a settimana o ovunque da 2-17 GB al giorno. Poiché è necessario pianificare il picco della domanda e 17 GB superano di gran lunga anche il massimo teorico di 6 GB, è probabile che tu abbia un problema di larghezza di banda molto grave. Cosa ci vorrà per aggiornare la connessione? Se l'aggiornamento della connessione è impossibile, prendere in considerazione l'opzione di inviare supporti fisici su base programmata (ad es. Settimanalmente).

2. Supponendo che tu possa ottenere che la matematica della larghezza di banda abbia un po 'più senso, rsync è probabilmente l'opzione migliore. La consapevolezza della deduplicazione sarebbe estremamente preziosa quando si replicano dati altamente ridondanti (ad es. Immagini di macchine virtuali), ma dovrebbe avere pochi o nessun vantaggio quando si tratta di contenuti digitali unici (audio, video, foto) ... a meno che, naturalmente, gli utenti non lo siano memorizzare inavvertitamente copie duplicate di file identici.

Dopo aver fatto qualche ricerca, credo che tu abbia ragione sull'invio di istantanee. ZFS SENDe i RECEIVEcomandi possono essere reindirizzati in bzip2 e quindi quel file può essere risincronizzato sull'altra macchina.

Ecco alcune fonti che ho usato:

• La Guida dell'amministratore di Oracle Solaris ZFS a pagina 211 (o versione Web qui ) inizia a parlarne.

• Ho anche trovato un post sul blog che ne ha fornito un semplice esempio. Questo blog ha anche mostrato il piping del flusso di bit attraverso bzip2 e l'invio.

Non avevo trovato alcun post con script di replica pubblicati, ma ho trovato qualcuno che ha pubblicato il loro script di backup . Detto questo, non l'ho capito, quindi potrebbe essere spazzatura.

Molti siti Web hanno parlato di come impostare un lavoro cron per farlo frequentemente. In tal caso, è possibile replicare / eseguire il backup con un impatto minore sulla larghezza di banda e sugli utenti ed essere una buona funzionalità di ripristino di emergenza poiché i dati offsite sono più aggiornati. (Cioè, dopo il blocco iniziale di dati quando si inizia.)

Ancora una volta, penso che tu abbia avuto l'idea giusta di inviare istantanee, sembra che ci siano molti vantaggi nell'uso di SEND/ RECEIVE.

EDIT: Appena guardato un video1 video2 che possono aiuta Suports l'uso della SEND/ RECEIVEe parla di rsync (inizia a 3m49s). Ben Rockwood è stato il relatore ed ecco un link al suo blog .

Qual è lo scopo dei backup e come sarà necessario accedervi?

Se i tuoi backup sono principalmente per il ripristino di emergenza, le istantanee di ZFS potrebbero essere preferibili in quanto sarai in grado di riportare un filesystem allo stato esatto in cui si trovava al momento dell'ultimo incremento.

Tuttavia, se si suppone che anche i backup forniscano agli utenti l'accesso a file che potrebbero essere stati accidentalmente eliminati, danneggiati, ecc. Rsync potrebbe essere un'opzione migliore. Gli utenti finali potrebbero non comprendere il concetto di snapshot o forse il NAS non fornisce agli utenti finali l'accesso agli snapshot precedenti. In entrambi i casi è possibile utilizzare rsync per fornire un backup facilmente accessibile all'utente tramite il filesystem.

Con rsync è possibile utilizzare il flag --backup per conservare i backup dei file che sono stati modificati, e con il flag --suffix è possibile controllare il modo in cui le versioni precedenti dei file vengono rinominate. Ciò semplifica la creazione di un backup in cui potresti aver datato vecchie versioni di file come

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

Puoi facilmente combinarlo con un cronjob contenente un comando find per eliminare tutti i vecchi file, se necessario.

Entrambe le soluzioni dovrebbero essere in grado di conservare una metainformazione sufficiente sui file per funzionare come backup (rsync fornisce flag --perms, --owner ecc.). Uso rsync per eseguire il backup di grandi quantità di dati tra datacenter e sono molto soddisfatto della configurazione.

ZFS dovrebbe ricevere la funzione "invio ripristinabile", che consentirà di continuare una replica interrotta entro marzo di quest'anno. La funzione è stata completata da Matt Ahrens e alcune altre persone e dovrebbe essere pubblicata a breve.

Forse il dispositivo di compressione WAN sarebbe una soluzione ...? usiamo Riverbed e ne siamo abbastanza soddisfatti (ad es. NetApp SnapMirror viene compresso molto bene, fino all'80-90%)