3

I am setting up a new EC2 instance. As part of this, I need to move a large file (100GB) up to EC2 from our colo data center. (E.g. the colo site has lots of bandwidth....).

My EC2 instance has a large EBS volume, so I have a place to put it.

I tried robocopy, but that was taking forever. Now I am trying teracopy, but this appears it will take 12 hours. (it is clocking 1.8MB/s right now) (Both robocopy and teracopy work using Windows file shares.)

  • Colo data center: Lots and lots of bandwidth (30-60mbps outbound or more)
  • EC2 instance: m1.medium instance

What are the options for moving this faster?

Thank you!

Improve this question
10
  • What size AWS instance? Bigger ones get more bandwidth. How big's the pipe on your end?
    – ceejayoz
    Commented Sep 16, 2013 at 16:46
  • @ceejayoz OP revised
    – Jonesome Reinstate Monica
    Commented Sep 16, 2013 at 17:03
  • are you doing this over a windows file share?
    – Matt
    Commented Sep 16, 2013 at 18:03
  • 3
    60mbps - megabit. You call that lots and lots of bandwidth? Seriously? Like 1990? 1gigabit would be good today. Your data center should facilitate fast copy operations.
    – TomTom
    Commented Sep 16, 2013 at 18:58
  • 1
    That is 60 megabits of actual, available, bandwidth ... not 1 megabit. Full gigabit is rarely seen all the way out of the data center to the wild, as there are other traffic generators, usually on both ends.
    – Jonesome Reinstate Monica
    Commented Sep 16, 2013 at 19:18

5 Answers 5

Reset to default
6

My first move would be trying a much larger instance. m1.mediums have "moderate" network performance. http://aws.amazon.com/ec2/instance-types/#instance-details

Something like the hi1.4xlarge would give you a 10 gigabit connection to AWS's network. If testing with one doesn't show better performance, the bottleneck isn't AWS.

Improve this answer
7
  • Thanks, I see what you refer to. Seems like I almost want a direct connection from "outside" AWS to EBS just to push data. Then connect the EBS volume to whatever instance..... (rather than having to go through an instance to EBS)
    – Jonesome Reinstate Monica
    Commented Sep 16, 2013 at 17:43
  • 2
    Yep. Make your EBS volume on a huge instance, then attach it to a more normally sized instance later. You'll pay a few bucks for the transfer but it'll be dramatically faster.
    – ceejayoz
    Commented Sep 16, 2013 at 17:44
  • Those refer to LAN network speeds which will generally be well in excess of net bandwidth. I can pull 6-10MB/s down to a t1.micro instance off the internet. See epamcloud.blogspot.co.uk/2013/03/…
    – Matt
    Commented Sep 16, 2013 at 19:02
  • OK, spun up an xlarge.... and not seeing any faster perf. This may mean the bottleneck is elsewhere (but, as I have never seen xlarge be faster, it does not help indicate where the bottleneck is).
    – Jonesome Reinstate Monica
    Commented Sep 16, 2013 at 21:26
  • Using both SMB1 (file share) and ftp, I found identical throughput to medium and xlarge instances from the cloud.
    – Jonesome Reinstate Monica
    Commented Sep 16, 2013 at 23:02
4

Alternately, you can snail-mail your data: http://aws.amazon.com/importexport/

Improve this answer
2

You can test the Amazon link and EBS volume by downloading something off a large mirror site in the same geographical region as your instance. My t1.micro instance in the EU can get ~6-9MB/s from live.debian.net. In US-West on a micro I can get 2-4MB/s from mirrors.kernel.org

Try doing your transfer with something like FTP/SCP/SFTP which might be a bit quicker than CIFS over a WAN link, especially if you have an older version of Windows at either end.

If there is anything else going out the colo link, 1.8 MB isn't that far from the bandwidth you quoted. You might be able to eek some more out of the link by splitting the file into chunks and running the copy for each chunk in parallel. ymmv depending on what is limiting the bandwidth.

Improve this answer
2

Resolved.

Issue looks to be as follows: robocopy and teracopy are going over file share. And.... since the servers are win2003 on one side and win2012 on the other, we are stuck on SMB1 which is not ideal for WAN transfers like this. (If both sides were Win2008 or higher, SMB2 would be auto negotiated, which is allegedly ideal for transfers like this.)

So we fired up ftp instead, using filezilla as the ftp server and filezilla ftp client. Annnnnnnnnnnd.... the results are in:

  • 3-4 hour estimated transfer time
  • 6.4MB/s

This is up from the robocopy / teracopy results which were

  • 12 hours
  • 1.8MB/s

We tested both the robocopy / teracopy and ftp solutions against both EC2 medium and xlarge instances and saw no difference at all in throughput based on the EC2 instance type. The only difference was in the protocol used to move data. (If there is a delta in throughput in "from the cloud" traffic, the bottleneck is somewhere I can't see.)

Improve this answer
1
  • It's possible that using CIFS/SMB was causing it to use sync writes rather than async, therefore it was waiting for a response after each filesystem block write instead of queuing up a lot at once. FTP transfers work as a stream so it doesn't employ the concept of writing filesystem blocks one by one.
    – Paccc
    Commented Sep 18, 2013 at 18:43
0

Move it via S3.

It's almost 2 years later, and EC2 network performance in and out is still not great. It is actually faster to move via S3 even though this is an extra hop. I am in Sydney.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .