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

Я должен скопировать 400 ГБ файлов из тома хранилища эластичных блоков в корзину s3 ... Это около 300 КБ файлов размером ~ 1 МБ

Я пробовал s3cmd и s3fuse , они оба очень-очень медленные. S3cmd работал целый день, сказал, что копирование закончено, и когда я проверил корзину, ничего не произошло (полагаю, что-то пошло не так, но по крайней мере s3cmd ни на что не жаловался)

S3Fuse работает еще целый день и скопировал менее 10% файлов ...

Есть ли лучшее решение для этого?

Я использую Linux (Ubuntu 12.04), конечно

Есть несколько ключевых факторов, которые определяют пропускную способность от 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 -rallel-put - довольно свежий скрипт на python, который хорошо работает

Итак, после большого количества испытаний s3-parallel-put сделали свое дело. Очевидно, решение, если вам нужно загрузить много файлов на 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