Trasferisci 15 TB di file di piccole dimensioni

79

Sto archiviando i dati da un server a un altro. Inizialmente ho iniziato un rsynclavoro. Ci sono volute 2 settimane per costruire l'elenco dei file solo per 5 TB di dati e un'altra settimana per trasferire 1 TB di dati.

Quindi ho dovuto terminare il lavoro perché abbiamo bisogno di un po 'di tempo morto sul nuovo server.

È stato concordato che lo avremo tarato poiché probabilmente non dovremo accedervi nuovamente. Stavo pensando di dividerlo in blocchi da 500 GB. Dopo di tarche poi avrei copiato tutto ssh. Stavo usando tare pigzma è ancora troppo lento.

C'è un modo migliore per farlo? Penso che entrambi i server siano su Redhat. Il vecchio server è Ext4 e il nuovo è XFS.

Le dimensioni dei file vanno da pochi KB a pochi MB e ci sono 24 milioni di jpeg in 5 TB. Quindi sto indovinando circa 60-80 milioni per 15 TB.

modifica: dopo aver giocato con rsync, nc, tar, mbuffer e pigz per un paio di giorni. Il collo di bottiglia sarà l'IO del disco. Poiché i dati vengono distribuiti su 500 dischi SAS e circa 250 milioni di jpeg. Tuttavia, ora ho imparato tutti questi simpatici strumenti che posso usare in futuro.

— lbanz
fonte

1

possibile duplicato di linux in linux, trasferimento da 10 TB?

— D34DM347,

2

Un'opzione consiste nel creare i file tar compressi su un'unità esterna e spostarli nel nuovo sistema. Il disco aggiuntivo accelererà la creazione dei file tar (non scriverà su dischi esistenti nel sistema, possibilmente durante il tentativo di leggere da 15 TB da essi) e non legherà il nuovo server.

— Brian,

4

C'è un modo migliore per farlo? - Sì, la replica DFS di Windows Server 2012 R2 lo preparerebbe in circa 10 ore . E sincronizzava le modifiche e riprendeva da dove si era interrotto dopo il riavvio.

— TessellatingHeckler,

27

@TessellatingHeckler: quindi suggerisci che OP migra da Redhat a Windows prima dell'archiviazione?

— Thomas Weller,

12

@ThomasWeller Hanno chiesto "c'è un modo migliore?", E c'è. Non raccomando di usare il modo migliore. Sono liberi di usare i comandi in una pipe che non possono recuperare dall'interruzione, non verificano il contenuto del file, non possono segnalare lo stato della copia, non possono usare blocchi precedentemente copiati per evitare la copia di parti di file, non ha implicazioni supporta la copia a bassa priorità, non può essere messo in pausa, non fa menzione della copia di ACL e ha bisogno di qualcuno che rimanga connesso per eseguirlo. Chiunque lo seguisse, comunque, potrebbe essere interessato - o spinto a dire "x lo fa su Linux".

— TessellatingHeckler,

64

Ho ottenuto ottimi risultati usando tar, pigz(gzip parallelo) e nc.

Macchina di origine:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Macchina di destinazione:

Estrarre:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

Per conservare l'archivio:

nc source_machine_ip 9876 > smallstuff.tar.gz

Se vuoi vedere la velocità di trasferimento esegui il pipe pvdopo pigz -d!

— h0tw1r3
fonte

3

Cordiali saluti, è possibile sostituire pigzcon gzipo rimuovere del tutto, ma la velocità sarà molto più lento.

— h0tw1r3,

10

Come può essere accettato se OP ha già provato tare pigz? Non capisco ...

— Thomas Weller,

5

@ThomasWeller dove hai capito che ci ha provato pigz? Dalla domanda sembra che abbia provato solo rsyncfinora, e stava considerando di utilizzare tarper dividere e raggruppare i dati. Soprattutto se non ha usato l' opzione -z/ --compresssu rsync, pigzteoricamente potrebbe aiutare in modo significativo.

— Doktor J,

1

@ThomasWeller sì, in effetti ho già provato tar e pigz ma non nc. Stavo usando SSH, quindi ha aggiunto molto più sovraccarico.

— lbanz,

2

@lbanz significa semplicemente che tarnon sta producendo dati abbastanza velocemente da pigzusare molta CPU per la compressione. La lettura di molti piccoli file comporta molti più syscall, molte più ricerche su disco e un sovraccarico del kernel molto maggiore rispetto alla lettura dello stesso numero di byte di file più grandi e sembra che tu stia semplicemente colmando il collo di bottiglia a un livello fondamentale.

— Hobbs,

21

Attaccherei alla soluzione rsync. Modern (3.0.0+) rsync utilizza un elenco di file incrementale, quindi non è necessario creare un elenco completo prima del trasferimento. Quindi il riavvio non richiederà di ripetere l'intero trasferimento in caso di problemi. Dividere il trasferimento per directory di primo o secondo livello lo ottimizzerà ulteriormente. (Userei rsync -a -Pe aggiungerei --compressse la tua rete è più lenta delle tue unità.)

— Volpe
fonte

Sto usando rsync 2.6.8 sul vecchio server. Poiché è una di quelle scatole in cui non è consentito installare / aggiornare nulla come indicato dal fornitore o annulla la garanzia. Potrei aggiornarlo e vedere se è più veloce.

— lbanz,

18

Trova (o crea) un binario rsync collegato staticamente ed eseguilo da casa tua. Spero che ciò non rovini la garanzia.

— Fox,

Che ne dici unison? Come si confronta rsync?

— Gwyneth Llewelyn,

15

Configurare una VPN (se è internet), creare un'unità virtuale di qualche formato sul server remoto (renderlo ext4), montarla sul server remoto, quindi montarla sul server locale (usando un protocollo a livello di blocco come iSCSI ) e utilizzare dd o un altro strumento a livello di blocco per eseguire il trasferimento. È quindi possibile copiare i file dall'unità virtuale sull'unità reale (XFS) a proprio piacimento.

Due motivi:

Nessun sovraccarico del filesystem, che è il principale responsabile delle prestazioni
Nessuna ricerca, stai osservando la lettura / scrittura sequenziale su entrambi i lati

— Arthur Kay
fonte

3

Bypassare il filesystem è buono. Copiare a livello di blocco di un filesystem montato in lettura-scrittura è una pessima idea. Smonta o monta prima di sola lettura.

— JB.

Anche avere una copia da 15 TB fa schifo. Significa che il nuovo server ha bisogno di un minimo di 30.

— Arthur Kay,

3

Se il server utilizza LVM, si potrebbe fare un'istantanea di sola lettura del filesystem e copiarlo invece. Overhead dello spazio solo per le modifiche nel filesystem che si verificano durante la lettura dell'istantanea.

— liori,

9

Se il vecchio server viene rimosso e i file possono rimanere offline per alcuni minuti, è spesso più veloce estrarre le unità dalla vecchia scatola e collegarle al nuovo server, montarle (ora online adesso) e copiare i file ai dischi nativi dei nuovi server.

— Robin Hammond
fonte

2

Si tratta di circa 1 TB di unità da 2 TB, quindi è troppo.

— lbanz

3

Usa mbuffer e se è su una rete sicura puoi evitare il passaggio di crittografia.

— JamesRyan
fonte

3

(Molte risposte diverse possono funzionare. Eccone un'altra.)

Generare l'elenco dei file con find -type f(ciò dovrebbe concludersi tra un paio d'ore), dividerlo in piccoli blocchi e trasferire ogni blocco usando rsync --files-from=....

— pts
fonte

3

Hai considerato Sneakernet? Con ciò, intendo trasferire tutto sulla stessa unità, quindi spostare fisicamente quell'unità.

circa un mese fa, Samsung ha presentato un'unità da 16 TB (tecnicamente, è da 15,36 TB), che è anche un SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -drive-16TB

Penso che questo disco farebbe quasi per questo. Dovresti comunque copiare tutti i file, ma poiché non hai la latenza di rete e probabilmente puoi usare SATA o una tecnica altrettanto veloce, dovrebbe essere molto più veloce.

— Nzall
fonte

2

Se c'è qualche possibilità di ottenere un alto rapporto di successo durante la deduplicazione, userei qualcosa come Borgbackup o Attico.

In caso contrario, controlla la soluzione netcat + tar + pbzip2 , adatta le opzioni di compressione in base al tuo hardware - controlla qual è il collo di bottiglia (CPU? Rete? IO?). Il pbzip2 si estenderebbe perfettamente su tutte le CPU, offrendo prestazioni migliori.

— neutrinus
fonte

lzma ( xz) si decomprime più velocemente di bzip2 e funziona bene sulla maggior parte degli input. Sfortunatamente, xzl'opzione multithread non è ancora implementata.

— Peter Cordes,

Di solito lo stadio di compressione richiede più potenza della decompressione, quindi se la CPU è il fattore limitante, pbzip2 si tradurrebbe in migliori prestazioni complessive. La decompressione non dovrebbe influire sul processo, se entrambe le macchine sono simili.

— neutrina,

Sì, il mio punto era che è un peccato che non ci sia un lzma multi-thread a flusso singolo. Anche se per questo caso d'uso, di trasferire interi filesystem di dati, pigzverrebbe probabilmente. essere il compressore più lento che vorresti usare. O addirittura lz4. (È disponibile un lz4mtmulti-thread per un singolo stream. Non esegue il thread in modo molto efficiente (genera nuovi thread estremamente spesso), ma ottiene una solida velocità)

— Peter Cordes,

2

Stai usando RedHat Linux, quindi questo non si applica, ma come un'altra opzione:

Ho avuto un grande successo usando ZFS per contenere milioni di file poiché gli inode non sono un problema.

Se questa fosse un'opzione per te, puoi quindi scattare istantanee e usare zfs per inviare aggiornamenti incrementali. Ho avuto molto successo usando questo metodo per trasferire così come i dati di archivio.

ZFS è principalmente un filesystem Solaris, ma può essere trovato nell'illumos (fork open source di OpenSolaris di Sun). So che c'è stato anche un po 'di fortuna nell'usare ZFS su BSD e Linux (usando FUSE?) - ma non ho esperienza nel provarlo.

— sleepyweasel
fonte

3

Esiste da un po 'di tempo una porta nativa non FUSE di ZFS: zfsonlinux.org

— EEAA,

1

Avviare un rsyncdemone sul computer di destinazione. Ciò accelererà molto il processo di trasferimento.

— Heiko Wiesner
fonte

-1

Puoi farlo con solo tar e ssh, in questo modo:

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

Oppure, se si desidera conservare singoli file:

tar zcf - <your files> | ssh <destination host> "tar zxf -"

— Fabio Brito
fonte

1

Non verrà deduplicato, nessun modo per riprendere, la compressione con una sola CPU.

— neutrina,