Qual é o caminho mais rápido para copiar 400G de arquivos de um volume de armazenamento de bloco el2 ec2 para s3?

Question

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

Eu tentei s3cmd e s3fuse , ambos são muito, muito lentos .. s3cmd correu para um dia completo, disse que terminou de copiar, e quando eu verifiquei o balde, nada tinha acontecido (suponho que algo deu errado, mas em menos s3cmd nunca reclamou de nada)

S3Fuse está trabalhando para outro dia completo e copiou menos de 10% dos arquivos ...

Existe uma solução melhor para isso?

Estou executando o Linux (Ubuntu 12.04), é claro

    

Answer 1

Existem vários fatores-chave que determinam a taxa de transferência do EC2 para o 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 originado 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 apreciáveis até entre 1 MiB e 2 MiB).
• Número de encadeamentos paralelos - um único encadeamento de upload geralmente tem um valor bastante baixo - geralmente abaixo de 5 MiB / s. A taxa de transferência aumenta com o número de encadeamentos simultâneos e tende a pico entre 64 e 128 encadeamentos. Deve-se notar que instâncias maiores são capazes de lidar com um número maior de threads simultâneas.
• Tamanho da instância - de acordo com as especificações da instância , as instâncias maiores têm mais recursos dedicados, incluindo recursos maiores ( e menos variável) alocação de largura de banda de rede (e E / S em geral - incluindo leitura de discos efêmeros / EBS - que são conectados à rede. Valores de números típicos para cada categoria são:
  • Muito alto: Teórico: 10Gbps = 1250MB / s; Realista: 8.8Gbps = 1100MB / s
  • Alta: Teórica: 1 Gbps = 125 MB / s; Realista: 750Mbps = 95MB / s
  • Moderado: Teórico: 250Mbps; Realista: 80Mbps = 10MB / s
  • Baixo: Teórico: 100Mbps; Realista: 10-15Mbps = 1-2MB / s

Em 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) é maior que a diferença no custo (2-3x). p>

Embora as idéias acima sejam razoavelmente lógicas (embora o limite por thread talvez não seja), é muito fácil encontrar os benchmarks para fazer backup deles. Um deles, 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 tem e deve saturar o uplink de 10 Gbps de uma instância de computação de cluster (cc1.4xlarge).

Embora seja muito 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 separá-los no S3 (portanto, não há muito que possamos fazer sobre arquivos pequenos). Arquivos grandes, no entanto, podemos nos separar no lado do EC2 e remontar no lado do S3 (usando o upload de várias partes do S3). Normalmente, isso é vantajoso para arquivos maiores que 100 MB.
• Os encadeamentos paralelos são um pouco mais difíceis 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 são solicitações paralelas, não é difícil localizar vários scripts em potencial, por exemplo:
  • s3cmd-modification - um fork de uma versão inicial do s3cmd que adicionou essa funcionalidade, mas não foi atualizada em vários anos .
  • s3-parallel-put - script Python razoavelmente recente que funciona bem

Answer 2

Então, depois de muitos testes s3-parallel-put , o truque foi incrível. Claramente a solução se você precisar enviar muitos arquivos para o S3. Graças a cyberx86 para os comentários.

    

Answer 3

Ajuste os valores de configuração do AWS CLI S3 de acordo com o link .

O abaixo aumentou a velocidade de sincronização 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

    

Answer 4

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

Em este artigo Eu mostrei como usar uma função recursiva com paralelo. Você pode transcrever para outro idioma.

Boa sorte!

    

Answer 5

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

    

Answer 6

Experimente o s4cmd, é realmente mais rápido que o s3cmd. Seu endereço: link

    

Answer 7

Tente usar s3-cli em vez de s3cmd. Eu usei em vez de s3cmd para fazer upload de arquivos para o meu s3 bucket e isso tornou minha implantação mais rápida quase 17 minutos (de 21 a 4 minutos)!

Este é o link: link