2012-11-04 16 views
5

Sto passando ai provider di hosting e ho bisogno di trasferire milioni di file caricati su un nuovo server. Tutti i file si trovano nella stessa directory. Sì. Hai letto bene. ;)Come posso spostare in modo efficiente molti file su un nuovo server?

In passato ho fatto questo:

  1. Zip tutti i file dal server di origine
  2. scp la zip al nuovo server
  3. Unzip directory
  4. Sposta posizione appropriata
    • per qualsiasi motivo le mie cerniere dal passaggio 1 portano sempre il percorso insieme a loro e richiedono me a MV.

L'ultima volta che ho fatto questo ci sono voluti circa 4-5 giorni per completare e che era circa il 60% di quello che ho adesso.

Sto sperando in un modo migliore. Che cosa suggerisci?

La struttura del file è sottoposta a hash. Qualcosa di simile a questo: AAAAAAAAAA.jpg-ZZZZZZZZZZ.txt

Ecco un idea che sta lanciando in giro:

Split le cerniere in tonnellate di mini-cerniere basato su 3 prefissi lettera. Qualcosa di simile:

AAAAAAAAAA.jpg - AAAZZZZZZZ.gif => AAA.zip 

Pro teorici:

  • potrebbe accelerare il trasferimento, consentendo a più cerniere di trasferire in una volta
  • potrebbero limitare il tempo perso per il trasferimento non è riuscito. (In attesa di 2 giorni per un trasferimento a fallire è pessimo)
  • Contro

teorici:

  • potrebbe rallentare la zip iniziale notevolmente da quando la zip deve cercare i file attraverso un jolly (AAA*) , forse compensato eseguendo molti thread zip contemporaneamente, usando tutte le CPU invece di una sola.
  • Complessità?

Abbiamo anche pensato a rsync e scp, ma ci preoccupiamo delle spese di trasferimento di ogni file manualmente. E poiché il server remoto è vuoto, non devo preoccuparmi di cosa c'è già.

Cosa ne pensi? Come lo faresti?

(Sì, mi trasferirò questi per Amazon S3 alla fine, e mi limiterò a spedirli un disco, ma nel frattempo, ho bisogno di loro fino a ieri!)

+3

E a proposito di rsync? –

+1

In questo tipo di situazione la mia preoccupazione principale sarebbe quella di non ripetere il trasferimento piuttosto che trasferire velocemente. Una volta ho dovuto trasferire 100 GB di file in luoghi diversi da quelli di mare. Ho provato con file di grandi dimensioni e il caricamento non è riuscito a causa di un errore casuale e ho dovuto fare di nuovo tutto. Quindi quello che ho fatto è stato dividere i file in blocchi da 6 GB e inviarli in parallelo (3-4) alla volta. Era molto più veloce e più affidabile. Puoi semplicemente creare uno script per farlo automaticamente per te. – specialscope

risposta

10

In realtà hanno più opzioni, il mio preferito potrebbe utilizzare rsync.

rsync [dir1] [dir2] 

Questo comando confronta effettivamente le directory e sincronizza solo le differenze tra di esse.

Con questo, sarei molto likeley di utilizzare il seguente

rsync -z -e ssh [email protected]:/var/www/ /var/www/ 

-z Zip
-e shell dei comandi

Si potrebbe anche usare SFTP, FTP tramite SSH.

O anche wget.

wget -rc ssh://[email protected]:/var/www/ 
+1

Non rsync richiederebbe uno sforzo per confrontare ogni file? La directory remota è vuota, quindi perché aggiungere questa spesa? Inoltre, sta trasferendo milioni di file più efficienti di uno (o anche di 1000) file compressi? – Ryan

+0

Non sono sicuro del confronto.E inizialmente hai suggerito la compressione, quindi l'ho appena buttato qui come opzione per te. Perché non solo una connessione FTP standard ..? O anche wget -rc ssh: //[email protected]:/var/www/ –

+0

Il confronto di Rsync si basa sull'hash dei diskblock (per i file esistenti) Per i file non esistenti non c'è nulla da confrontare (tranne che per * forse * una verifica finale dopo la copia) – wildplasser

1

Sono del mondo Linux/Unix. Vorrei usare tar per creare un numero di file tar ciascuno di una dimensione impostata. Es .:

tar -cML $MAXIMUM_FILE_SIZE_IN_KILOBYTES --file=${FILENAME}}_{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}.tar ${THE_FILES} 

Salto la ricompressione a meno che i file .txt non siano enormi. Non otterrai molto chilometraggio per ricomprimere i file .jpeg e mancherà molto tempo CPU (e reale).

Vorrei vedere come funziona il tuo traffic shaping. Quante connessioni simultanee puoi avere? Quanta larghezza di banda per connessione? Quanto totale?

Ho visto alcune cose interessanti con scp. Il test di una rete domestica, scp ha dato un throughput molto inferiore rispetto alla copia su un filesystem smbfs montato montato. Non sono del tutto chiaro perché. Anche se ciò potrebbe essere auspicabile se scp sta verificando la copia e richiede la ritrasmissione degli errori. (Esiste una probabilità molto piccola di un errore che lo attraversa in un pacchetto trasmesso su Internet. Senza una sorta di fase successiva di verifica, si tratta di un problema reale con set di dati di grandi dimensioni. Potresti voler eseguire gli hash MD5 ...)

Se questo è un server web, puoi sempre usare solo wget. Anche se sembra altamente inefficiente ...

+0

Concordato sulla compressione. La maggior parte dei nostri file sono immagini e non si comprimono. Tuttavia, la preoccupazione riguarda la spesa per il trasferimento di molti file (10 M +) anziché solo uno (o 1000). Pensi che SCP possa gestirlo meglio della compressione sul front-end? Come devo valutare le spese di I/O e le spese di connessione? – Ryan

0

Che ne dici di usare BitTorrent? Potrebbe non essere facile da configurare, ma una volta che si sta andando dovrebbe fare esattamente quello che vuoi. BitTorrent è stato sviluppato per facilitare il trasferimento di file di grandi dimensioni. Avresti bisogno di un client sul computer di origine e uno sul computer di destinazione. Creare il metafile sul computer di origine. Copialo sul computer di destinazione e caricalo nel client BitTorrent. Immettere manualmente l'IP sul computer di origine. Finché non hai alcun firewall che ti blocca, il trasferimento dovrebbe iniziare. Opzionalmente è possibile comprimere tutti i file prima senza compressione, ovvero con la compressione STORED, quindi trasferire lo zip utilizzando BitTorrent.

Problemi correlati