Trasferisci 10 TB di file dagli USA al datacenter britannico

96

Sto migrando il mio server dagli Stati Uniti al Regno Unito da un data center a un altro. Il mio host ha detto che avrei dovuto essere in grado di raggiungere 11 megabyte al secondo.

Il sistema operativo è Windows Server 2008 ad entrambe le estremità.

La mia dimensione media del file è di circa 100 MB e i dati sono suddivisi su cinque unità da 2 TB.

Quale sarebbe il modo consigliato per trasferire questi file?

FTP
SMB
Rsync / Robocopy
Altro?

Non sono troppo preoccupato per la sicurezza in quanto si tratta comunque di file pubblici, ma voglio solo una soluzione in grado di spingere l'intera velocità di trasferimento di 11 MB / s per ridurre al minimo il tempo totale di trasferimento.

file-transfer large-data

— Paul Hinett
fonte

19

11 MB / so 11 Mb / s?

— mercoledì

14

trasferire i dati su una punch card binaria e usare un piccione viaggiatore :)

— enterzero

9

Dovresti fornire dettagli. Quanti piccioni viaggiatori pensi che ci vorrebbe? Mostra il tuo lavoro.

— Evik James,

18

@Evik europeo o africano?

— mercoledì

8

A parte questo, Wolfram Alpha è il modo più conveniente per fare il calcolo, "10 TB a 11 MB / s". wolframalpha.com/input/?i=10+TB+at+11MB%2Fs

— pufferfish

173

Spedisci invece dischi rigidi attraverso l'oceano.

A 11 Mbps con pieno utilizzo, stai aspettando solo 90 giorni per trasferire 10 TB.

11 Mbps = 1.375 MBps = 116.015 GB / giorno .

10240 GB / 116.015 GB / giorno = ~ 88.3 giorni .

— Shane Madden
fonte

42

+1 per Sneakernet . Inoltre, hai dimenticato l'overhead TCP / IP. È più simile a ~ 100 giorni in circostanze ideali.

— Chris S,

43

Un uomo saggio una volta disse "Non sottovalutare mai la larghezza di banda di una station wagon piena di nastri che sfrecciano lungo l'autostrada". Questa equazione è molto vera e non sostanzialmente modificata cambiando il station wagon per una barca. ( bpfh.net/sysadmin/never-underestimate-bandwidth.html )

— Rob Moir,

5

È meglio spedire nastri o dischi Blueray, piuttosto che unità. Se si utilizza un'unità, assicurarsi che gli originali siano tenuti al sicuro e disponibili per ogni evenienza. Vorrei scegliere le unità da solo (a meno che non avessi unità Ultrium 4) perché 10 TB = 410 dischi blueray a strato singolo!

— Allen

9

Ho appena realizzato che ho digitato 11 Mbps, tuttavia è quello che volevo dire in realtà era 11 MB / s. Suppongo che questo faccia una differenza abbastanza grande, i miei calcoli hanno circa 11-14 giorni circa ... è corretto?

— Paul Hinett,

18

credo ancora che l'invio di un supervisore con il backup di 10 TB mentre il disco ufficiale funziona ancora, una volta terminata l'installazione, è possibile pranzare un rsync per aggiornare il nuovo server per qualsiasi modifica. Avresti la tua macchina in funzione per circa un giorno.

— Loïc Faure-Lacroix,

26

Direi rsync, a 11 MB / s guarderai 10-14 giorni e anche se ti interrompi, rsync inizierà facilmente dove si è interrotto l'ultima volta.

A 11 Mbps spedirei i dischi rigidi come suggerito sopra :)

— Lucas Kauffman
fonte

1

La tua stima differisce in modo molto significativo da ciò che altri hanno pubblicato (e non so chi sia corretto). Puoi fornire la tua metodologia per arrivare a quelle cifre?

— John Gardeniers,

9

La differenza deriva dall'OP che indica erroneamente 11 Mbps quando in realtà intendeva 11 MBps, che è 8 volte più veloce. A proposito, riavviare un rsync da 10 TB in caso di interruzione richiederà probabilmente un po 'di tempo, no? Ore o più?

— Frank Farmer,

@FrankFarmer: non mi preoccuperei del riavvio di rsync; Conservo una copia off-site di ~ 20 TB su una linea wireless da 30 Mbps e il riavvio avviene nell'intervallo di secondi. la copia iniziale ha richiesto un paio di settimane, ma l'aggiornamento notturno è di solito un paio d'ore.

— Javier,

@FrankFarmer - rsync sembra ridimensionare molto bene. Ho ~ 2 TB su una linea ADSL1 rurale che è stata inizializzata con sneakernet, ma impiega ~ 5 minuti a sincronizzarsi ogni notte se non è cambiato nulla.

— Flexo,

6

rsync il tempo di riavvio scala con il numero di file (principalmente dal stattempo, nella mia esperienza), non con i dati totali. Non mi aspetto alcuna attesa significativa (al massimo diversi minuti). Anche se la mia esperienza con rsync supera poco meno di 5 TB.

— derobert,

15

Rsync ovviamente.

Almeno puoi continuare in qualsiasi momento dopo una pausa ed è senza dolore.

— Korjavin Ivan
fonte

7

Più di 3 mesi da copiare al 100% di utilizzo. Siamo spiacenti, ma è un modo terribile per trasferire così tanti dati.

— Chris S,

Sono d'accordo con @ChrisS, l'utilizzo rsyncsolo per copiare file di grandi dimensioni non è efficiente. Per le mie cose ho finito per usare tarsopra netcato sshper il trasferimento iniziale. È molto più veloce e inizia a trasferire immediatamente, mentre rsyncscansiona prima tutti i file che richiedono tempo. Se questo viene interrotto, è comunque possibile utilizzarlo in rsyncseguito. In effetti, lo faccio a volte dopo, tarcomunque, per garantire che tutte le autorizzazioni, i file socket, ecc. Siano corretti.

— Martin Scharrer il

1

Dopo che OP ha corretto la connessione a ~ 100 Mb, non a 11 Mb, rsync ha molto più senso. +1 per il primo a menzionarlo.

— Chris S,

12

Non sottovalutare mai la larghezza di banda di una station wagon piena di nastri

- Trad.

Nel tuo caso, dischi o nastri inviati dal corriere, ma il principio si applica ancora. Se non sei preoccupato per la latenza, sarà molto più economico della larghezza di banda della rete per trasferire 10 TB di dati in un ragionevole lasso di tempo.

— ConcernedOfTunbridgeWells
fonte

Jeff Atwood gestiva i numeri in uno dei suoi vecchi post di Coding Horror .. codinghorror.com/blog/2007/02/the-economics-of-bandwidth.html

— tardate

10

Dovresti usare rsync. Si comprime i dati e de-duplicare prima di inviarlo. Può anche riprendere trasferimenti parziali, che è molto importante per qualsiasi trasferimento di grandi dimensioni.

È probabile che non trasferisca 10 TB; se si tratta di registri e testo e simili potrebbe essere inferiore a 1 TB; forse molto al di sotto di 1 TB.

Esistono strumenti che svolgono un lavoro di compressione migliore rispetto a rsync e che probabilmente trovano più corrispondenze. Potresti usare lrzip, ecc.

Esistono tipi specifici di dati che non si comprimono bene e non contengono duplicati letterali, ad esempio video e altri media. In questi casi, FTP e rsync stanno facendo lo stesso sforzo.

— Volontà
fonte

3

RSync deduplica i dati? Penso che lo faccia solo a livello di file, il che significa che la deduplicazione è per lo più inutile in questo caso.

— Devicenull,

6

So che questo è già stato accettato, ma hai preso in considerazione l'idea di portare i tuoi dischi in un data center / provider / host dove puoi ottenere maggiore larghezza di banda? Probabilmente ti costerà un po 'di denaro, ma copiare 10240Gb su dischi di backup e l'invio costerà anche tempo e denaro (2 x denaro).

Inoltre sarai sicuro che i tuoi dischi non si rompono durante il trasporto.

— Asken
fonte

In che modo questa risposta è diversa dalla risposta accettata?

— Chris S,

2

@Chris Questa risposta suggerisce di trasportare i dischi in una pipe più grande nello stesso continente.

— Alex Jasmin,

5

11Mbps? Questa è una limitazione che hai qui. Nella tua situazione vorrei semplicemente:

Clonare i dati
Comprimilo
Noleggia server su entrambe le estremità con una larghezza di banda almeno 10 volte maggiore (negli stessi data center o alla tua estremità in un data center vicino a te).
Trasferisci i file
Applicare i dati al nuovo server.

Se davvero non hai una soluzione per aumentare la larghezza di banda ... Quindi spedire un'unità fisica sarà molto più veloce.

Dalla mia esperienza dolorosa, i dischi rigidi tendono a rompersi nella posta ... Le unità flash USB sono una soluzione migliore per frequenti trasferimenti di dati. Nel tuo caso ne richiederebbe alcuni :) Quindi invia 2 copie dei tuoi dati su più dischi rigidi.

Considerando la quantità di dati che hai, puoi anche inviare unità da un array RAID 5 o RAID 6 se hai lo stesso hardware / software sull'altro lato per collegare le tue unità. Ma in tal caso ricorda di contrassegnare l'ordine delle tue unità e i loro numeri di serie, quindi durante la riconfigurazione non si confondono.

— Coyote
fonte

1

scusate, l'11 Mbps era un errore di battitura, è 11MB / s ... di cui ho parlato in uno dei commenti sopra.

— Paul Hinett,

4

Mentre in questo caso devo essere d'accordo sulla risposta "spediscilo usando hard disk", qui una soluzione di copia che uso quando devo copiare grandi quantità di file per la prima volta:

Sebbene rsyncsia utile mantenere sincronizzati due archivi di dati, introduce un certo sovraccarico non necessario per il trasferimento iniziale. Ho pensato che il modo più veloce è quello su tarcui viene convogliato netcat. Sul sito del ricevitore è anche possibile utilizzare netcatin modalità di ascolto che convoglia i dati in arrivo a un'estrazione tar. Il vantaggio è che tarinizia a inviare immediatamente e lo netcatinvia come semplice flusso TCP senza sovraccarico di protocollo di livello superiore. Questo dovrebbe essere il più veloce possibile. Tuttavia, non è semplice riavviare un trasferimento interrotto nell'ultima posizione.

È anche possibile comprimere facilmente i dati per il trasferimento utilizzando le giuste taropzioni o aggiungere uno strumento di compressione nei tubi. Si noti che netcatinvia la data non crittografata. Nei casi in cui questa non è un'opzione, è sshpossibile utilizzare una connessione crittografata ( tar <options> | ssh <target> -c 'tar -x <options>').

Se tutti i dati vengono trasferiti, è rsyncpossibile garantire che tutti i file che sono stati aggiornati nel frattempo siano sincronizzati. Inoltre, IIRC tarnon crea socket che altrimenti andranno persi, ma comunque non vengono realmente utilizzati per i dati del datacenter.

— Martin Scharrer
fonte

Il rovescio della medaglia è che non tollera le interruzioni

— Joel Coel,

3

Hai considerato IPoAC ?

Un singolo piccione può essere in grado di trasportare decine di gigabyte di dati in circa un'ora, che su una base di larghezza di banda media si confronta in modo molto favorevole con gli attuali standard ADSL, anche quando si tiene conto di unità perse.

— Wim
fonte

21

I piccioni subirebbero una perdita di segnale alla distanza descritta dall'OP.

— Roy Tinker,

@RoyTinker L'IPoAC cancellato deve essere implementato usando un processo a finestre.

— JamesBarnett,

3

Ancora una volta, il primo suggerimento è di spedire le unità.

Il secondo suggerimento è di usare rsync su rsyncd, non su SSH. Ho provato molte cose ed è di solito il più veloce. Ricorda di attivare la compressione. Inoltre, osservare l' aumento o la riduzione della dimensione del buffer rsync per ottenere la velocità di trasferimento ottimale. Può anche aiutare ad aumentare le dimensioni della MTU . Questo aiuta solo se i router in rotta non frammentano i pacchetti. Ci sono modi per determinare se lo fanno.

Purtroppo non esiste un'impostazione che sia sempre la migliore. Dovrai sperimentare per scoprire cosa funziona meglio nella tua situazione.

— sjbotha
fonte

2

Hai detto che i server eseguono Windows 2008. Microsoft DFS sarebbe adatto? C'è un po 'di magia nell'estremità inferiore che cerca di ottenere quanta più larghezza di banda possibile dalla connessione e ha anche compressione e de-duplicazione (IIRC).

Intendiamoci, dischi rigidi, DVD o BluRay sarebbero più veloci ... Il mio calcolo è di 11 giorni a 11 MB / s completi ...

— TiernanO
fonte

1

Per questo puoi usare un torrent.

Crea un torrent privato da un lato e usa il client dall'altro.

Sebbene sia in atto la crittografia, è necessario verificare con i propri requisiti.

— Dragos
fonte

1

Una relazione torrent 1 a 1 non è migliore di un trasferimento di file 1 a 1. Se esiste una conduttura limitata tra i due siti, sono necessarie più seminatrici su condotte diverse, idealmente distribuite geograficamente.

— Jeremy,

@Jeremy - non è migliore o peggiore in termini di produttività. Potrebbe essere meglio in termini di affidabilità (facile pausa / ripresa), che per questa dimensione xfer potrebbe essere importante

— Joel Coel,