Sincronizzazione di strutture di cartelle molto grandi

14

Abbiamo una struttura di cartelle sulla nostra intranet che contiene circa 800.000 file suddivisi in circa 4.000 cartelle. Dobbiamo sincronizzarlo con un piccolo gruppo di macchine nelle nostre DMZ. La profondità della struttura è molto bassa (non supera mai i due livelli di profondità).

La maggior parte dei file non cambia mai, ogni giorno ci sono alcune migliaia di file aggiornati e 1-2 mila nuovi file. I dati sono dati di report storici mantenuti laddove i dati di origine sono stati eliminati (ovvero si tratta di report finalizzati per i quali i dati di origine sono sufficientemente vecchi da archiviarli ed eliminarli). La sincronizzazione una volta al giorno è sufficiente dato che può avvenire in tempi ragionevoli. I report vengono generati durante la notte e sincronizziamo la prima cosa al mattino come attività pianificata.

Ovviamente, poiché così pochi file cambiano su base regolare, possiamo trarre grandi benefici dalla copia incrementale. Abbiamo provato Rsync, ma possono essere necessarie dalle otto alle dodici ore solo per completare l'operazione "Elenco file di costruzione". È chiaro che stiamo rapidamente superando le capacità di rsync (il periodo di tempo di 12 ore è troppo lungo).

Avevamo utilizzato un altro strumento chiamato RepliWeb per sincronizzare le strutture e può eseguire un trasferimento incrementale in circa 45 minuti. Tuttavia sembra che abbiamo superato il limite, ha iniziato a vedere i file mostrati come eliminati quando non lo sono (forse una certa struttura di memoria interna è stata esaurita, non ne siamo sicuri).

Qualcun altro ha incontrato un progetto di sincronizzazione su larga scala di questo tipo? Esiste qualcosa progettato per gestire enormi strutture di file come questo per la sincronizzazione?

— MightyE
fonte

Hai provato a suddividere il lavoro su più istanze di rsync in esecuzione contemporaneamente? Non ho una buona immagine della struttura della directory ma potresti dividerla per nome della directory o nome del file.

— Frizione

Ci avevamo pensato, ma con una struttura così piatta, è difficile trovare buone linee di divisione su cui dividere il lavoro. È complicato dal fatto che le cartelle sono per la maggior parte molto simili (c'è una convenzione di denominazione che fa iniziare la maggior parte delle cartelle con lo stesso set iniziale di 6 caratteri).

— Possente

Hai mai trovato una buona soluzione, Dave? Sto prendendo in considerazione lsyncd per una directory con 65535 sotto-directory, ognuna delle quali potrebbe avere 65 ^ 16 file.

— Mike Diehn,

1

@MikeDiehn Non ho mai trovato uno strumento di cui ero totalmente felice qui. Abbiamo ottenuto quello strumento proprietario RepliWeb per correggere il bug in cui vedevano i file come eliminazioni che non lo erano, era una struttura interna traboccata. Ho lasciato quel lavoro anni fa, presumo che lo stiano ancora usando. Per i tuoi scopi, se le tue directory sono ragionevolmente distribuite, potresti scegliere qualcosa come la soluzione di Ryan. Non noterà le eliminazioni ai massimi livelli, ma 65535 sottoconti mi suggeriscono che probabilmente non li hai.

— Potente

9

Se ci si può fidare dei timestamp dell'ultima modifica del filesystem, è possibile velocizzare le cose combinando Rsync con l'utilità 'find' di UNIX / Linux. 'find' può assemblare un elenco di tutti i file che mostrano i tempi dell'ultima modifica nel giorno passato, e quindi reindirizzare SOLO quell'elenco abbreviato di file / directory a Rsync. Questo è molto più veloce di avere Rsync a confrontare i metadati di ogni singolo file sul mittente con il server remoto.

In breve, il comando seguente eseguirà Rsync SOLO sull'elenco di file e directory che sono stati modificati nelle ultime 24 ore: (Rsync NON si preoccuperà di controllare altri file / directory).

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

Nel caso in cui non si abbia familiarità con il comando 'trova', ricerca attraverso una sottostruttura di directory specifica, alla ricerca di file e / o directory che soddisfano tutti i criteri specificati. Ad esempio, questo comando:

find . -name '\.svn' -type d -ctime -0 -print

inizierà nella directory corrente (".") e ricercherà attraverso tutte le sottodirectory, cercando:

tutte le directory ("-type d"),
chiamato ".svn" ("-name '.svn'"),
con metadati modificati nelle ultime 24 ore ("-ctime -0").

Stampa il nome completo del percorso ("-print") di tutto ciò che corrisponde a tali criteri sull'output standard. Le opzioni '-name', '-type' e '-ctime' sono chiamate "test" e l'opzione "-print" è chiamata "azione". La pagina man di 'find' ha un elenco completo di test e azioni.

Se vuoi essere davvero intelligente, puoi usare il test '-cnewer' del comando 'trova', invece di '-ctime' per rendere questo processo più tollerante agli errori e flessibile. '-cnewer' verifica se a ciascun file / directory dell'albero sono stati modificati i metadati più recentemente rispetto a un file di riferimento. Utilizzare 'tocco' per creare il file di riferimento della corsa SUCCESSIVA all'inizio di ogni corsa, subito prima di 'trova ... | Il comando rsync ... 'viene eseguito. Ecco l'implementazione di base:

#!/bin/sh
curr_ref_file=`ls /var/run/last_rsync_run.*`
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

Questo script riconosce automaticamente quando è stata eseguita l'ultima volta e trasferisce solo i file modificati dall'ultima esecuzione. Sebbene ciò sia più complicato, ti protegge da situazioni in cui potresti aver perso l'esecuzione del lavoro per più di 24 ore, a causa di tempi di inattività o altri errori.

— Ryan B. Lynch
fonte

Questa è una soluzione estremamente intelligente! Sto pensando che vuoi dire alla touch $next_ref_filefine? Ci lascia però senza la possibilità di far fronte ai percorsi eliminati (anche questi rapporti di archiviazione statici alla fine diventano abbastanza vecchi da essere archiviati ed eliminati). Tuttavia, potrebbe non essere un punto fermo.

— Possente

Sto scoprendo che anche solo find . -ctime 0è abbastanza lento su questa struttura di directory ( sto ancora aspettando che completi per riportare il suo tempo). Questo in realtà mi scoraggia un po 'perché sembra che questa potrebbe essere un'operazione di livello piuttosto basso che probabilmente pone le basi per il più veloce che possiamo aspettarci che questo lavoro venga completato. È possibile che l'I / O del disco sia il fattore limitante qui.

— Possente

Per quanto riguarda quello scriptlet, sì, ho fatto un errore. Intendevo eseguire "touch" su "next_ref_file" (NON "curr_ref_file") subito prima di eseguire "find ... | rsync ... 'comando. (Risolverò la mia risposta.)

— Ryan B. Lynch,

3

Per quanto riguarda il lento comando 'trova': che tipo di filesystem stai usando? Se stai usando Ext3, potresti prendere in considerazione due modifiche FS: 1) Esegui 'tune2fs -O dir_index <DEVICE_NODE>' per abilitare la funzione 'dir_index' di Ext3, per accelerare l'accesso alle directory con un numero elevato di file. 2) Esegui 'mount -o remount, noatime, nodiratime' per disattivare gli aggiornamenti del tempo di accesso, che accelera la lettura, in generale. 'dumpe2fs -h <DEVICE_NODE> | grep dir_index 'ti dice se' dir_index 'è già abilitato (su alcune distro, è l'impostazione predefinita), e' mount | grep <DEVICE_NODE> 'ti informa sugli aggiornamenti del tempo di accesso.

— Ryan B. Lynch,

Purtroppo è NTFS - Windows 2003 Server che utilizza Cygwin per il comando find. Ricorderò quelle opzioni di ottimizzazione (eccellente consiglio) per ext3 nel caso in cui ci imbattessimo in qualcosa di simile su uno dei nostri cluster Debian.

— Potente

7

Prova all'unisono , è stato appositamente progettato per risolvere questo problema mantenendo gli elenchi di modifiche (creazione dell'elenco dei file), localmente su ciascun server, accelerando i tempi di calcolo del delta e la quantità ridotta che viene inviata attraverso il cavo in seguito.

— Dave Cheney
fonte

Sto provando l'Unison. È in esecuzione da circa 2 ore nella fase "In cerca di modifiche" e, in base ai file su cui sta attualmente lavorando, sembra che sia circa a metà strada (quindi forse 4 ore in totale prima dell'inizio del trasferimento). Sembra che sarà meglio di rsync, ma comunque al di fuori della nostra finestra operativa desiderata.

— Possente

2

La prima volta che si crea un indice su entrambi i lati, i tempi di ricostruzione sono simili a rsync in quanto deve eseguire l'hashing di ciascun file. Una volta fatto ciò, all'unisono usa l'ultima volta modificata della directory per identificare quando un file è cambiato e deve solo scansionare quel file per le modifiche.

— Dave Cheney,

Purtroppo sono stato vittima di un amministratore delle operazioni troppo zelante che ha forzato la mia sessione prima che il catalogo fosse realizzato (limitiamo il numero di accessi simultanei ai server di produzione). Ho perso i progressi compiuti nella costruzione del catalogo iniziale, quindi devo ricominciare da capo. Ti farò sapere come va.

— Possente

Ci vogliono circa 2 ore ora che il catalogo iniziale è stato creato per cercare le modifiche. Sono piuttosto sorpreso di quanta RAM Unison stia usando per questo. Per la nostra raccolta di file, il server di origine utilizza 635M e il client remoto utilizza 366M. Sincronizzare più macchine in un cluster sarebbe un footprint piuttosto pesante, in particolare per il server di origine!

— Potente

1

Sei in grado di strutturare i tuoi dati in modo da identificare facilmente i dati che sono stati modificati di recente? Cioè, memorizzandolo nel formato anno / mese / giorno / ...?

— Dave Cheney,

3

http://oss.linbit.com/csync2/ è progettato per questo genere di cose, ci proverei.

— Justin
fonte

2

Se stai usando l'opzione -z su rsync, prova a correre senza di essa. Per qualche ragione ho visto questo accelerare anche l'enumerazione iniziale dei file.

— Chris Thorpe
fonte

Abbiamo provato con e senza la bandiera -z. Sembrava non avere un impatto sulla durata dell'esecuzione dell '"elenco dei file di costruzione".

— Possente

2

Togliendo -z dal comando rsync che non è una compressione, la "lista dei file ricevuti" è andata molto più veloce e abbiamo dovuto trasferire circa 500 GB. Prima ci volle un giorno con l'opzione -z.

— ryand32
fonte