Qual è il modo più veloce per copiare 400G di file da un volume di archivio di blocchi elastici ec2 su s3?

Devo copiare 400G di file da un volume di archivio di blocchi elastici in un bucket s3 ... Questi sono circa 300k file di ~ 1 Mb

Ho provato s3cmd e s3fuse , entrambi sono molto, molto lenti .. s3cmd ha funzionato per un giorno intero, ha detto che ha finito di copiare, e quando ho controllato il secchio, non era successo nulla (suppongo che qualcosa sia andato storto, ma almeno s3cmd non si è mai lamentato di nulla)

S3Fuse funziona per un altro giorno completo e ha copiato meno del 10% dei file ...

C'è una soluzione migliore per questo?

Sto eseguendo Linux (Ubuntu 12.04) ovviamente

Esistono diversi fattori chiave che determinano il throughput da EC2 a S3:

• Dimensione del file: file più piccoli richiedono un numero maggiore di richieste e un sovraccarico maggiore e il trasferimento è più lento. Il guadagno con dimensione file (se originato da EC2) è trascurabile per file di dimensioni superiori a 256 KB. (Considerando che, il trasferimento da una posizione remota, con latenza più elevata, tende a continuare a mostrare miglioramenti apprezzabili fino a tra 1 MiB e 2 MiB).
• Numero di thread paralleli - un singolo thread di caricamento di solito ha un numero abbastanza basso in tutto - spesso inferiore a 5 MiB / s. La velocità effettiva aumenta con il numero di thread simultanei e tende a raggiungere un picco compreso tra 64 e 128 thread. Va notato che le istanze più grandi sono in grado di gestire un numero maggiore di thread simultanei.
• Dimensione dell'istanza - Secondo le specifiche dell'istanza , le istanze più grandi hanno risorse più dedicate, inclusa un'allocazione più ampia (e meno variabile) della larghezza di banda della rete (e I / O in generale - inclusa la lettura da dischi effimeri / EBS - che sono collegati in rete. i valori numerici per ciascuna categoria sono:
  • Molto alto: teorico: 10 Gbps = 1250 MB / s; Realistico: 8,8 Gbps = 1100 MB / s
  • Alto: teorico: 1 Gbps = 125 MB / s; Realistico: 750 Mbps = 95 MB / s
  • Moderato: teorico: 250 Mbps; Realistico: 80 Mbps = 10 MB / s
  • Basso: teorico: 100 Mbps; Realistico: 10-15 Mbps = 1-2 MB / s

In caso di trasferimento di grandi quantità di dati, può essere economicamente pratico utilizzare un'istanza di calcolo del cluster, poiché il guadagno effettivo nel throughput (> 10x) è maggiore della differenza di costo (2-3x).

Mentre le idee di cui sopra sono abbastanza logiche (anche se il limite per thread potrebbe non esserlo), è abbastanza facile trovare benchmark che le supportino. Uno particolarmente dettagliato può essere trovato qui .

L'uso tra 64 e 128 upload paralleli (simultanei) di oggetti da 1 MB dovrebbe saturare l'uplink da 1 Gbps di un m1.xlarge e dovrebbe persino saturare l'uplink da 10 Gbps di un'istanza di calcolo del cluster (cc1.4xlarge).

Mentre è abbastanza facile cambiare la dimensione dell'istanza, gli altri due fattori potrebbero essere più difficili da gestire.

• La dimensione del file è di solito fissa - non possiamo unire i file insieme su EC2 e separarli su S3 (quindi, non c'è molto che possiamo fare per i file di piccole dimensioni). Tuttavia, file di grandi dimensioni possono essere divisi sul lato EC2 e riassemblati sul lato S3 (utilizzando il caricamento in più parti di S3). In genere, questo è vantaggioso per file di dimensioni superiori a 100 MB.
• I thread paralleli sono un po 'più difficili da soddisfare. L'approccio più semplice si riduce alla scrittura di un wrapper per alcuni script di upload esistenti che eseguiranno più copie di esso contemporaneamente. Approcci migliori utilizzano direttamente l'API per realizzare qualcosa di simile. Tenendo presente che la chiave sono richieste parallele, non è difficile individuare diversi potenziali script, ad esempio:
  • Modifica s3cmd - un fork di una versione precedente di s3cmd che ha aggiunto questa funzionalità, ma non è stato aggiornato da diversi anni.
  • s3-parallel-put - script python abbastanza recenti che funzionano bene

Quindi, dopo un sacco di test s3-parallel-put ha fatto il trucco incredibilmente. Chiaramente la soluzione se devi caricare molti file su S3. Grazie a cyberx86 per i commenti.

Ottimizza i valori di configurazione di AWS CLI S3 come http://docs.aws.amazon.com/cli/latest/topic/s3-config.html .

Di seguito è aumentata una velocità di sincronizzazione S3 di almeno 8 volte!

Esempio:

$ more ~/.aws/config
[default]
aws_access_key_id=foo
aws_secret_access_key=bar
s3 =
   max_concurrent_requests = 100
   max_queue_size = 30000

Ho scritto un'applicazione console ottimizzata in C # ( CopyFasterToS3 ). Ho usato in EBS vol, nel mio caso aveva 5 cartelle con più di 2 milioni di file per un importo di 20Gb. Lo script è stato eseguito in meno di 30 minuti.

In questo articolo ho mostrato come utilizzare una funzione ricorsiva con parallelo. Puoi trascriverlo in un'altra lingua.

In bocca al lupo!

C'è anche: s3funnel , che sembra molto vecchio (2008) e alcuni bug aperti, ma è ancora elencato dalla stessa Amazon: amzn-lnk

Prova invece s4cmd, è molto più veloce di s3cmd. Il suo indirizzo: https://github.com/bloomreach/s4cmd

Prova a usare s3-cli invece di s3cmd. L'ho usato invece di s3cmd per caricare i file sul mio bucket S3 e ha reso la mia distribuzione più veloce di quasi 17 minuti (da 21 a 4 minuti)!

Ecco il link: https://github.com/andrewrk/node-s3-cli