Mover arquivo grande (100 GB) para a instância EC2 do meu centro de dados de cores

2

Estou configurando uma nova instância do EC2. Como parte disso, preciso mover um arquivo grande (100 GB) para o EC2 de nosso centro de dados de cores. (Por exemplo, o site do colo tem muita largura de banda ....).

Minha instância do EC2 tem um grande volume de EBS, então tenho um lugar para colocá-lo.

Eu tentei robocopy, mas isso estava demorando. Agora estou tentando teracopy, mas isso parece que levará 12 horas. (Ele está registrando 1,8MB / s agora) (Tanto o robocopy quanto o teracopy funcionam usando compartilhamentos de arquivos do Windows.)

  • Centro de dados Colo: Muita largura de banda (30-60mbps de saída ou mais)
  • Instância do EC2: instância do m1.medium

Quais são as opções para mover isso mais rapidamente?

Obrigado!

    
por samsmith 16.09.2013 / 18:42

5 respostas

2

Resolvido.

O problema parece ser o seguinte: o robocopy e o teracopy estão passando por compartilhamento de arquivos. E ... uma vez que os servidores são win2003 de um lado e win2012 do outro, estamos presos no SMB1 que não é ideal para transferências de WAN como esta. (Se ambos os lados fossem Win2008 ou superior, o SMB2 seria negociado automaticamente, o que supostamente é ideal para transferências como essa.)

Então nós demitimos o ftp em vez disso, usando o filezilla como o servidor ftp e o filezilla ftp client. Annnnnnnnnnd ... os resultados estão em:

  • 3-4 horas de tempo de transferência estimado
  • 6,4MB / s

Isso é resultado dos resultados de robocópia / teracopia que foram

  • 12 horas
  • 1,8MB / s

Testamos as soluções robocopy / teracopy e ftp em relação às instâncias EC2 médias e xlarge e não observamos diferença alguma na taxa de transferência com base no tipo de instância do EC2. A única diferença estava no protocolo usado para mover dados. (Se houver um delta na taxa de transferência no tráfego "da nuvem", o gargalo está em algum lugar que não consigo ver).

    
por 17.09.2013 / 01:04
6

Meu primeiro passo seria tentar uma instância muito maior. m1.mediums têm desempenho de rede "moderado". link

Algo como o hi1.4xlarge daria a você uma conexão de 10 gigabits à rede da AWS. Se o teste com um não mostrar melhor desempenho, o gargalo não é AWS.

    
por 16.09.2013 / 19:10
3

Como alternativa, você pode enviar seus dados por e-mail: link

    
por 17.09.2013 / 03:19
2

Você pode testar o link da Amazon e o volume do EBS baixando algo de um grande site espelho na mesma região geográfica da sua instância. Minha instância t1.micro na UE pode obter ~ 6-9MB / s de live.debian.net . No US-West em um micro eu posso obter 2-4MB / s de mirrors.kernel.org

Tente fazer sua transferência com algo como FTP / SCP / SFTP, que pode ser um pouco mais rápido que o CIFS em um link WAN, especialmente se você tiver uma versão mais antiga do Windows nas duas extremidades.

Se houver mais alguma coisa saindo do link de colo, 1,8 MB não está tão longe da largura de banda que você citou. Você pode conseguir extrair um pouco mais do link dividindo o arquivo em partes e executando a cópia de cada parte em paralelo. ymmv dependendo do que está limitando a largura de banda.

    
por 16.09.2013 / 21:27
0

Mova-o via S3.

São quase 2 anos depois, e o desempenho e a saída de rede do EC2 ainda não são grandes. Na verdade, é mais rápido mover-se via S3, mesmo que seja um salto extra. Eu estou em Sydney.

    
por 26.07.2015 / 02:32

Tags