Qual é a maneira mais rápida de copiar 400G de arquivos de um volume de armazenamento de bloco elástico ec2 para s3?

Eu tenho que copiar 400G de arquivos de um volume de armazenamento de bloco elástico para um balde s3 ... Esses são cerca de 300k arquivos de ~ 1Mb

Eu tentei s3cmd e s3fuse , os dois são muito, muito lentos. S3cmd correu por um dia inteiro, disse que terminou de copiar e, quando chequei o balde, nada havia acontecido (suponho que algo desse errado, mas pelo menos s3cmd nunca reclamou de nada)

O S3Fuse está trabalhando por mais um dia completo e copiou menos de 10% dos arquivos ...

Existe uma solução melhor para isso?

Estou executando o Linux (ubuntu 12.04) é claro

Existem vários fatores principais que determinam a taxa de transferência de EC2 para S3:

• Tamanho do arquivo - arquivos menores exigem um número maior de solicitações e mais sobrecarga e transferência mais lenta. O ganho com o tamanho do arquivo (quando originário do EC2) é insignificante para arquivos maiores que 256kB. (Considerando que a transferência de um local remoto, com maior latência, tende a continuar mostrando melhorias consideráveis ​​até 1MiB e 2MiB).
• Número de encadeamentos paralelos - um único encadeamento de upload geralmente tem uma quantidade bastante baixa - geralmente abaixo de 5MiB / s. A taxa de transferência aumenta com o número de threads simultâneos e tende a atingir um pico entre 64 e 128 threads. Deve-se observar que instâncias maiores podem lidar com um número maior de threads simultâneos.
• Tamanho da instância - de acordo com as especificações da instância , instâncias maiores têm mais recursos dedicados, incluindo uma alocação maior (e menos variável) de largura de banda da rede (e E / S em geral - incluindo leitura de discos efêmeros / EBS - que estão conectados à rede. Os valores numéricos para cada categoria são:
  • Muito alto: Teórico: 10Gbps = 1250MB / s; Realista: 8.8Gbps = 1100MB / s
  • Alto: Teórico: 1 Gbps = 125 MB / s; Realista: 750Mbps = 95MB / s
  • Moderado: Teórico: 250Mbps; Realista: 80 Mbps = 10 MB / s
  • Baixo: Teórico: 100Mbps; Realista: 10-15Mbps = 1-2MB / s

Nos casos de transferência de grandes quantidades de dados, pode ser economicamente prático usar uma instância de computação de cluster, pois o ganho efetivo na taxa de transferência (> 10x) é mais do que a diferença no custo (2-3x).

Embora as idéias acima sejam bastante lógicas (embora o limite por segmento possa não ser), é bastante fácil encontrar referências que as apoiem. Um particularmente detalhado pode ser encontrado aqui .

Usar entre 64 e 128 uploads paralelos (simultâneos) de objetos de 1 MB deve saturar o uplink de 1 Gbps que um m1.xlarge possui e deve saturar o uplink de 10 Gbps de uma instância de computação em cluster (cc1.4xlarge).

Embora seja bastante fácil alterar o tamanho da instância, os outros dois fatores podem ser mais difíceis de gerenciar.

• O tamanho do arquivo geralmente é fixo - não podemos unir arquivos no EC2 e dividi-los no S3 (portanto, não há muito o que fazer sobre arquivos pequenos). Arquivos grandes, no entanto, podemos nos separar no lado do EC2 e remontar no lado do S3 (usando o upload em várias partes do S3). Normalmente, isso é vantajoso para arquivos maiores que 100 MB.
• Threads paralelos é um pouco mais difícil de atender. A abordagem mais simples se resume a escrever um wrapper para algum script de upload existente que executará várias cópias dele de uma só vez. Melhores abordagens usam a API diretamente para realizar algo semelhante. Tendo em mente que a chave é solicitações paralelas, não é difícil localizar vários scripts em potencial, por exemplo:
  • s3cmd-modification - uma bifurcação de uma versão anterior do s3cmd que adicionou essa funcionalidade, mas não foi atualizada há vários anos.
  • s3-parallel-put - script python razoavelmente recente que funciona bem

Então, depois de muitos testes, o s3-parallel-put fez o truque de maneira impressionante. Claramente a solução se você precisar enviar muitos arquivos para o S3. Obrigado a cyberx86 pelos comentários.

Ajuste os valores de configuração do AWS CLI S3 conforme http://docs.aws.amazon.com/cli/latest/topic/s3-config.html .

A seguir, aumentamos a velocidade de sincronização do S3 em pelo menos 8x!

Exemplo:

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

Eu escrevi um aplicativo de console otimizado em C # ( CopyFasterToS3 ) para fazer isso. Eu usei no EBS vol. No meu caso, ele tinha 5 pastas com mais de 2 milhões de arquivos em uma quantidade de 20Gb. O script executado em menos de 30 minutos.

Em este artigo i mostrou como usar uma função recursiva com paralelo. Você pode transcrevê-lo para outro idioma.

Boa sorte!

Há também: s3funnel , que parece muito antigo (2008) e alguns bugs abertos, mas ainda está listado na própria Amazon: amzn-lnk

Experimente o s4cmd, é muito mais rápido que o s3cmd. Seu endereço: https://github.com/bloomreach/s4cmd

Tente usar s3-cli em vez de s3cmd. Usei-o em vez do s3cmd para fazer upload de arquivos para o meu bucket s3 e agilizou minha implantação quase 17 minutos (de 21 a 4 minutos)!

Aqui está o link: https://github.com/andrewrk/node-s3-cli