Какой самый быстрый способ скопировать 400 ГБ файлов из тома хранилища эластичных блоков ec2 в s3?

Есть несколько ключевых факторов, которые определяют пропускную способность от EC2 до S3:

• Размер файла - файлы меньшего размера требуют большего количества запросов, больших накладных расходов и более медленной передачи. Прирост размера файла (при исходном из EC2) незначителен для файлов размером более 256 КБ. (Принимая во внимание, что передача из удаленного местоположения с более высокой задержкой, как правило, продолжает демонстрировать заметные улучшения до тех пор, пока не будет между 1 МБ и 2 МБ).
• Количество параллельных потоков - у одного потока загрузки обычно довольно мало - часто ниже 5 МБ / с. Пропускная способность увеличивается с увеличением количества параллельных потоков и имеет тенденцию достигать пика между 64 и 128 потоками. Следует отметить, что более крупные экземпляры могут обрабатывать большее количество параллельных потоков.
• Размер экземпляра - согласно спецификации экземпляра, более крупные экземпляры имеют больше выделенных ресурсов, включая большее (и менее изменчивое) выделение полосы пропускания сети (и операций ввода-вывода в целом, включая чтение с эфемерных дисков / дисков EBS, подключенных к сети. Типичные числовые значения для каждой категории:
  • Очень высокий: теоретический: 10 Гбит / с = 1250 МБ / с; Реалистично: 8,8 Гбит / с = 1100 МБ / с
  • Высокий: теоретический: 1 Гбит / с = 125 МБ / с; Реалистично: 750 Мбит / с = 95 МБ / с
  • Умеренный: Теоретический: 250 Мбит / с; Реалистично: 80 Мбит / с = 10 МБ / с
  • Низкий: теоретический: 100 Мбит / с; Реалистично: 10-15 Мбит / с = 1-2 МБ / с

В случаях передачи больших объемов данных может оказаться экономически целесообразным использовать экземпляр вычислительного кластера, так как эффективный выигрыш в пропускной способности (> 10x) превышает разницу в стоимости (2-3x).

Хотя приведенные выше идеи довольно логичны (хотя ограничение на поток может и не быть), довольно легко найти тесты, подтверждающие их. Один особенно подробный можно найти Вот.

Использование от 64 до 128 параллельных (одновременных) загрузок объектов размером 1 МБ должно насыщать восходящий канал 1 Гбит / с, который имеет m1.xlarge, и даже должен насыщать восходящий канал 10 Гбит / с экземпляра кластерных вычислений (cc1.4xlarge).

Хотя изменить размер экземпляра довольно просто, двумя другими факторами может быть сложнее управлять.

• Размер файла обычно фиксирован - мы не можем объединить файлы вместе на EC2 и разделить их на S3 (так что мы мало что можем сделать с небольшими файлами). Однако большие файлы мы можем разделить на стороне EC2 и повторно собрать на стороне S3 (используя загрузку нескольких частей S3). Как правило, это выгодно для файлов размером более 100 МБ.
• С параллельными потоками работать немного сложнее. Самый простой подход сводится к написанию оболочки для некоторого существующего сценария загрузки, который будет запускать несколько его копий одновременно. Лучшие подходы используют API напрямую для достижения чего-то подобного. Имея в виду, что ключ кроется в параллельных запросах, нетрудно найти несколько потенциальных скриптов, например:
  • s3cmd-модификация - форк ранней версии s3cmd, которая добавляла эту функциональность, но не обновлялась несколько лет.
  • s3-параллельно-положить - достаточно свежий скрипт Python, который работает хорошо

Итак, после долгих испытаний s3-параллельно-положить сделал трюк потрясающе. Очевидно, решение, если вам нужно загрузить много файлов на S3. Благодаря cyberx86 за комментарии.

Настройте значения конфигурации AWS CLI S3 в соответствии с http://docs.aws.amazon.com/cli/latest/topic/s3-config.html.

Ниже приведено увеличение скорости синхронизации S3 как минимум в 8 раз!

Пример:

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

Я написал оптимизированное консольное приложение на C # (CopyFasterToS3) сделать это. Я использовал в EBS vol, в моем случае у него было 5 папок с более чем 2 миллионами файлов в размере 20 ГБ. Скрипт выполнен менее чем за 30 минут.

В Эта статья Я показал, как использовать рекурсивную функцию с параллельным. Вы можете перевести его на другой язык.

Удачи!

А также есть: s3funnel, который кажется очень старым (2008 г.) и некоторыми открытыми ошибками, но все еще перечислен на самом Amazon: amzn-lnk

Попробуйте вместо этого s4cmd, он действительно быстрее, чем s3cmd. Его адрес: https://github.com/bloomreach/s4cmd

Попробуйте использовать s3-cli вместо s3cmd. Я использовал его вместо s3cmd для загрузки файлов в свою корзину s3, и это ускорило развертывание почти на 17 минут (с 21 до 4 минут)!

Вот ссылка: https://github.com/andrewrk/node-s3-cli

Еще один хороший вариант - пик /s5cmd:

При загрузке s5cmd в 32 раза быстрее, чем s3cmd, и в 12 раз быстрее, чем aws-cli. Для загрузок s5cmd может загружать канал 40 Гбит / с (~ 4,3 ГБ / с), тогда как s3cmd и aws-cli могут достигать только 85 МБ / с и 375 МБ / с соответственно.