Copia file di grandi dimensioni da un server Linux a un altro

Sto tentando di copiare un tgz da 75 gigabyte (mysql lvm snapshot) da un server Linux nel nostro data center di Los Angeles a un altro server Linux nel nostro data center di New York tramite un collegamento da 10 MB.

Sto ottenendo circa 20-30Kb / s con rsync o scp che oscilla tra le 200 e le 300 ore.

Al momento è un collegamento relativamente silenzioso in quanto il secondo data center non è ancora attivo e ho ottenuto velocità eccellenti da trasferimenti di file di piccole dimensioni.

Ho seguito inutilmente diverse guide di tuning tcp che ho trovato tramite google (forse sto leggendo le guide sbagliate, ne ho una buona?).

Ho visto la punta del tunnel tar + netcat, ma la mia comprensione è che è buono solo per MOLTI file di piccole dimensioni e non ti aggiorna quando il trasferimento del file è effettivamente finito.

Prima di ricorrere alla spedizione di un disco rigido, qualcuno ha qualche input valido?

AGGIORNAMENTO: Beh ... potrebbe essere il link dopo tutto :( Vedi i miei test qui sotto ...

Trasferimenti da New York a Los Angeles:

Ottenere un file vuoto.

[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s
[nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST .
FROM_NY_TEST                                    3%  146MB   9.4MB/s   07:52 ETA

Ottenere il tarball dell'istantanea.

[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz
-rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz

[nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz .
db_dump.08120922.tar.gz            0%   56MB 574.3KB/s 14:20:40 ET

Trasferimenti da LA a NY:

Ottenere un file vuoto.

[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s
[nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST .
FROM_LA_TEST                                    0% 6008KB 497.1KB/s 2:37:22 ETA

Ottenere il tarball dell'istantanea.

[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz
-rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz

[nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz .
db_dump_08120901.tar.gz                0%  324KB  26.8KB/s 314:11:38 ETA

Suppongo che lo farò con le persone che gestiscono le nostre strutture, il collegamento è etichettato come un collegamento MPLS / Ethernet da 10 MB. (Alzata di spalle)

Sneakernet Qualcuno?

Supponendo che questa sia una copia di una volta, non suppongo sia possibile copiare semplicemente il file su un CD (o altro supporto) e durante la notte è lì?

Questa potrebbe effettivamente essere l'opzione più veloce in quanto un trasferimento di file di quelle dimensioni, su quella connessione, potrebbe non essere copiato correttamente ... nel qual caso dovresti ricominciare tutto da capo.

rsync

La mia seconda scelta / tentativo sarebbe rsync in quanto rileva trasferimenti non riusciti, trasferimenti parziali, ecc. E può riprendere da dove era stato interrotto.

rsync --progress file1 file2 user@remotemachine:/destination/directory

Il flag --progress ti darà un feedback invece di stare lì seduto e lasciarti indovinare da solo. :-)

Vuze (bittorrent)

La terza scelta sarebbe probabilmente quella di provare a utilizzare Vuze come server torrent e quindi fare in modo che la propria posizione remota utilizzi un client bitorrent standard per scaricarlo. Conosco altri che l'hanno fatto, ma sai ... quando hanno messo tutto in funzione, ecc ... Avrei potuto passare da un giorno all'altro i dati ...

Dipende dalla tua situazione, immagino.

In bocca al lupo!

AGGIORNARE:

Sai, ho pensato un po 'di più al tuo problema. Perché il file deve essere un unico grande tarball? Tar è perfettamente in grado di dividere file di grandi dimensioni in file più piccoli (ad esempio per estendere i media), quindi perché non dividere quell'enorme tarball in pezzi più gestibili e quindi trasferire i pezzi invece?

L'ho fatto in passato, con un file tbz2 da 60 GB. Non ho più lo script ma dovrebbe essere facile riscriverlo.

Innanzitutto, dividi il file in pezzi di ~ 2 GB:

split --bytes=2000000000 your_file.tgz

Per ogni pezzo, calcola un hash MD5 (questo per verificare l'integrità) e conservalo da qualche parte, quindi inizia a copiare i pezzi e il loro md5 sul sito remoto con lo strumento che preferisci (io: netcat-tar-pipe in uno schermo sessione).

Dopo un po ', controlla con md5 se i tuoi pezzi sono a posto, quindi:

cat your_file* > your_remote_file.tgz

Se hai anche creato un MD5 del file originale, controlla anche quello. Se va bene, puoi decomprimere il tuo file, tutto dovrebbe essere a posto.

(Se trovo il tempo, riscrivo lo script)

Normalmente sono un grande sostenitore di rsync, ma quando si trasferisce un singolo file per la prima volta, non sembra avere molto senso. Se, tuttavia, trasferissi nuovamente il file con solo lievi differenze, rsync sarebbe il chiaro vincitore. Se decidi di utilizzare comunque rsync, ti consiglio vivamente di eseguire un'estremità in --daemonmodalità per eliminare il tunnel ssh che uccide le prestazioni. La pagina man descrive questa modalità abbastanza accuratamente.

La mia raccomandazione? FTP o HTTP con server e client che supportano il ripristino dei download interrotti. Entrambi i protocolli sono veloci e leggeri, evitando la penalità del tunnel SSH. Apache + wget urlava velocemente.

Anche il trucco della pipa netcat funzionerebbe bene. Tar non è necessario quando si trasferisce un singolo file di grandi dimensioni. E il motivo per cui non ti avvisa quando è finito è perché non te l'hai detto. Aggiungi un -q0flag sul lato server e si comporterà esattamente come ti aspetteresti.

server $ nc -l -p 5000> outfile.tgz

client $ nc -q0 server.example.com 5000 <infile.tgz

L'aspetto negativo dell'approccio netcat è che non ti consentirà di riprendere se il tuo trasferimento muore 74GB in ...

Dai un colpo a netcat (a volte chiamato nc). Quanto segue funziona su una directory, ma dovrebbe essere abbastanza facile da modificare per la semplice copia di un file.

Nella casella di destinazione:

netcat -l -p 2342 | tar -C /target/dir -xzf -

Nel riquadro di origine:

tar czf * | netcat target_box 2342

Puoi provare a rimuovere l'opzione 'z' in entrambi i comandi tar per un po 'più di velocità visto che il file è già compresso.

SCP e Rsync predefiniti (che utilizzano SCP) sono molto lenti per file di grandi dimensioni. Immagino che esaminerei l'utilizzo di un protocollo con un overhead inferiore. Hai provato a utilizzare un cifrario di crittografia più semplice o per niente? Prova a esaminare l' --rshopzione per rsync per modificare il metodo di trasferimento.

Perché non FTP o HTTP?

Anche se aggiunge un po 'di sovraccarico alla situazione BitTorrent è in realtà una soluzione davvero piacevole per il trasferimento di file di grandi dimensioni. BitTorrent ha molte belle funzioni come il blocco nativo di un file e il checksum di ogni blocco che può essere ritrasmesso se corrotto.

Un programma come Azureus [ora noto come Vuze] contiene tutti i pezzi necessari per creare, server e download di torrent in un'unica app. Bean in mente Azureus non è la soluzione più snella disponibile per BitTorrent e penso che richieda anche la sua GUI - ci sono molti strumenti torrent basati su riga di comando per Linux.

Bene, personalmente, 20-30Kb / s sembrano piuttosto bassi per un collegamento da 10 Mb (supponendo 10 Mb e non 10 MB).

Se fossi in te, farei una delle due cose (supponendo che l'accesso fisico non sia disponibile) -

Ad ogni modo, ti consiglio di dividere il file di grandi dimensioni in blocchi più piccoli, circa 500 MB In caso di corruzione in transito.

Quando hai i blocchi più piccoli, usa di nuovo o rsync, oppure preferisco personalmente utilizzare una sessione privata Secure FTP, quindi CRC i file al termine.

Alcune domande potrebbero essere utili nelle discussioni: quanto sono importanti i dati da trasferire? È per ripristino di emergenza, backup a caldo, archiviazione offline o cosa? Intendi eseguire il backup del database mentre è attivo o inattivo? Che dire di impostare un database sul sistema remoto e di mantenerli sincronizzati utilizzando il clustering o l'aggiornamento tramite i log delle modifiche (non sono completamente esperto delle capacità di un sistema di database MySql). Ciò potrebbe aiutare a ridurre la quantità di dati che devono essere trasferiti attraverso il collegamento.

bbcp taglierà il file per te e lo copierà con più flussi.

Risposta in ritardo per googler:

Quando si trasferiscono set di dati di grandi dimensioni, è possibile utilizzare rsync per confrontare l'origine e la destinazione, quindi scrivere un file batch su supporti rimovibili locali utilizzando il flag --only-write-batch. Quindi spedisci il supporto locale nella posizione remota, collegalo ed esegui di nuovo rsync, usando --read-batch per incorporare le modifiche nel set di dati remoto.

Se i file di origine cambiano durante il trasporto fisico o se il supporto di trasporto si riempie, puoi semplicemente continuare a ripetere il batch --only-write-batch | nave | - ciclo ciclo-batch fino a quando la destinazione non è stata raggiunta.

(Rif: sono stato uno degli autori di questa funzione in rsync - per ulteriori informazioni e casi d'uso, vedere questa discussione sull'implementazione del prototipo: https://lists.samba.org/archive/rsync/2005-March/011964 .html )