Перенос файлов от одного облачного провайдера S3 к другому должен был обойтись нам примерно в 133 000 рублей. Вместо этого, мы заплатили за него около 29 000 рублей. Как можно в 5 раз удешевить этот процесс – рассказываем в статье.
Введение
Перенос данных между облачными хранилищами типа S3 – это задача, с которой регулярно сталкиваются многие компании.
Причины для такого переноса могут быть разнообразными:
Экономия на хранении данных. Один из основных факторов – это экономия финансов. Разные облачные провайдеры предлагают разные тарифы и условия хранения данных. В некоторых случаях переход к другому провайдеру может существенно снизить расходы на инфраструктуру.
Улучшение производительности. Некоторые облачные хранилища могут обеспечивать более высокую скорость загрузки или скачивания данных, что особенно важно для приложений и сервисов, требующих быстрого доступа к данным.
Географическое расположение. Зачастую, для компании важно, чтобы их данные хранились в определенном регионе.
Улучшение доступности и надежности. Одной из причин переноса, могут быть проблемы с текущим провайдеров, в частности – надежность предоставляемого им сервиса.
В нашем случае, решающими были фактор стоимости, фактор производительности и расположения. Мы перенесли сервера в облако Яндекс и вместе с серверами организовали и перенос S3-облака, чтобы всю инфраструктуру собрать вместе.
Но процесс оказался гораздо запутаннее, чем мы ожидали, и скрывал в себе много подводных камней. Нам потребовалось несколько дней и несколько тысяч рублей, потраченных зря, чтобы выработать эффективный и недорогой алгоритм переноса.
В данном руководстве мы расскажем, как мы осуществляли перенос и с какими трудностями столкнулись в процессе.
Проблемы процесса
Высокая стоимость и сложность расчета. В формировании стоимости переноса данных участвуют, как минимум, следующие показатели:
стоимость исходящего трафика у провайдера А.
стоимость GET-запросов у провайдера А.
стоимость хранения данных у провайдера А.
стоимость входящего трафика у провайдера Б.
стоимость PUT-запросов у провайдера Б.
стоимость хранения данных у провайдера Б.
Скорость передачи. Конечно же, мы хотим максимально ускорить процесс переноса данных, как минимум для того, чтобы как можно меньшее время платить обоим провайдерам за хранение.
Ограниченный бюджет. Тут следует учесть, что процедура переноса естественным образом приведет к очень быстрому “сгоранию” баланса у провайдера-источника (на которого вы, скорее всего, уже не хотите тратить лишние деньги), поэтому нужно учесть этот фактор при планировании переезда. Мы рассчитали траты не очень качественно, это привело к тому, что пришлось экстренно пополнять баланс в последний день и потерять некоторую сумму. Мы могли бы этого не делать, если бы просто начали на несколько дней раньше.
В ответ на эти проблемы рождаются решения:
Правильный подбор классов хранилищ для минимизации расходов (горячее/холодное/ледяное).
Развертка виртуальной машины в локальной сети рядом с хранилищем-источником, для обнуления стоимости исходящего трафика.
Правильная настройка rclone для получения максимальной скорости передачи данных.
Настройка классов хранилищ
Хранилище бывает “горячего” либо “холодного” класса (в некоторых случаях - еще и “ледяного”). Чем более “горячее” хранилище - тем дешевле трафик и запросы, но дороже хранение данных. Чем “холоднее” - тем дешевле хранить данные, но дороже их помещать в хранилище или читать из него.
Во время процедуры переноса данных идеально, чтобы хранилища с обоих сторон были “горячими”. Это позволит в несколько раз уменьшить стоимость запросов и трафика.
В нашем случае, ситуация усложнялась тем, что класс целевого хранилища в конце-концов нам нужен “ледяной”, потому что данных у нас хранится много, но обращаемся к ним редко. К счастью, целевое хранилище у нас – Yandex Object Storage, в котором есть такой инструмент как Lifecycle Policies (Жизненный цикл). С помощью него, мы настроили следующую схему работы:
Класс хранилища по умолчанию - горячий. Это означает, что новые файлы относятся к этому классу, и добавление данных тарифицируется по самой низкой цене (входящий трафик и PUT-запросы).
Для каждого бакета настроен Жизненный Цикл, по которому файлы перемещаются из горячего в ледяное хранилище через 1 полные сутки. Тут обнаружился небольшой подвох в настройках Yandex Object Storage: в интерфейсе невозможно настроить перенос из горячего в ледяное хранилище одной операцией, можно только “охладить” на одну ступень, то есть из горячего в холодное или из холодного в ледяное. Но через API за 10 минут можно создать правило, которое позволяет перенести сразу из горячего в ледяное.
Со стороны хранилища-источника, в нашем случае, класс был холодным. Мы посчитали и пришли к выводу, что миграция на горячий класс не принесет ощутимой выгоды.
Виртуальная машина
В основном, провайдеры облачных услуг взимают плату за исходящий трафик и за запросы к облаку. Однако, некоторые из них, включая Яндекс и Selectel, не берут плату за исходящий трафик между своими виртуальными машинами и облачным хранилищем. Стоимость виртуальной машины на 1-2 дня аренды в разы ниже стоимости исходящего трафика. Плата за входящий трафик у текущих провайдеров не берётся, по этому мы заплатим только за запросы к облаку и виртуальную машину.
На схеме мы видим двух провайдеров. От первого мы переносим файлы ко второму. Для этого мы запускаем процесс переноса на виртуальной машине и такие запросы не будут тратить бюджет.
К примеру для быстрого переноса 5 ТБ, нам понадобится 9 600 рублей на исходящий трафик. При этом виртуальная машина, для переноса нам обойдётся примерно в ~200 рублей в сутки. По итогу мы сэкономим около 9000 рублей только на трафике. При большем объеме данных экономия может быть намного ощутимее.
Выбор характеристик виртуальной машины зависит от объема данных, которые вы планируете перенести, и от скорости, с которой вы хотите это сделать. Очень важно взять нужное количество процессорных ядер, объем оперативной памяти и пропускную способность сети, иначе переезд может затянуться.
Перенос данных мы будем совершать через Rclone – крайне эффективный инструмент для копирования данных, который может быть настроен под ваши характеристики виртуальной машины. Его можно настроить как на минимальную нагрузку, так и на максимальную для вашей машины, что позволяет выжимать всю скорость сетевого канала.
Какие характеристики нам важны:
Оперативная память. Rclone использует оперативную память для хранения частей файлов во время передачи. Количество используемой памяти зависит от размера блока данных, который Rclone передает за один раз (известный как “размер блока”). Больший размер блока может увеличить скорость передачи данных, но также потребует больше оперативной памяти. Значительно увеличивают использование оперативной памяти флаги
--fast-listи--buffer-size, fast list - ускоряет передачу данных, за счёт полного кеширования списка файлов в оперативной памяти, а buffer-size увеличивает размер блоков данных. Имейте ввиду--fast-listможет потребовать очень много оперативной памяти, при пересылке примерно 10 млн файлов, он потребовал 12 гб оперативной памяти, при условии что без флага, потребовалось всего 1 гб памяти. Но без fast-list не получится максимально разогнать скорость заливки.Процессор. Rclone использует процессор для управления процессом передачи данных и для выполнения таких задач, как шифрование и дешифрование данных. Более мощный процессор может ускорить эти процессы, особенно при работе с большими объемами данных. В Rclone есть такая вещь, как workers и если увеличить их кол-во через флаг
--cache-workers, то нагрузка на процессор увеличится, как и скорость передачи данных.Сеть. Скорость передачи данных также зависит от пропускной способности сети виртуальной машины. Рекомендуется как минимум гигабитный канал, чтобы максимально разогнать скорость. В идеальном случае, канал может быть вообще не ограничен на уровне провайдера.
Мы использовали виртуальную машину с 4 VCPU и 8 GB оперативной памяти, передавали 40 файлов за раз и использовали 30 воркеров для передачи. Без fast-list мы получили скорость передачи в среднем 80Mbit/s, а при fast-list скорость передачи была более 300Mbit/s. Но при этом пришлось ждать около 7 часов, пока list выгрузится и так же пришлось докидывать swap для его работы.
Настраиваем Rclone
Практически у каждого провайдера s3 облака можно найти пример настройки rclone. Так что советуем посмотреть в документации облака наличие инструкции настройки. Мы в качестве примера настроим rclone для Яндекс облака.
Установим rclone, в нашем примере ставить будем на ubuntu:
apt update && apt upgrade
apt install rclone -y Для запуска настройки rclone нужна команда:
rclone configПосле ввода увидим меню:
e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit configВыбираем New remote, нажатием n:
e/n/d/r/c/s/q> nВводим имя конфига:
Enter name for new remote.
name> yandex Далее нам нужно выбрать вид хранилища:
Storage> 5 Выбираем провайдера:
provider> 1Ручной ввод данных:
env_auth> 1 В следующих двух пунктах нужно ввести access_key_id и secret_access_key, их можно получить у провайдера, создав сервисный аккаунт для работы с облаком.
Выбираем регион:
region> ru-central1и последнее что нам нужно, это ввести endpoint:
endpoint> storage.yandexcloud.net Остальные настройки можно оставить по умолчанию.
Отлично, мы настроили подключение к одному из бакетов, теперь повторите процедуру для второго облака и можно приступать к переносу.
Какие флаги rclone нам будут нужны:
--fast-list: загружает все файлы в виде списка в оперативную память, повышает кол-во памяти которую использует rclone, но при этом сильно ускоряет передачу файлов и уменьшает кол-во запросов. Так как без этого флага, каждый файл который будем переносить, будет запрашиваться отдельно.--create-empty-src-dirs: если в вашем хранилище из которого вы переносите файлы, есть пустые директории и они вам нужны и в новом облаке, то используйте этот флаг, что бы rclone их создал.--progress: флаг который будет показывать процесс переноса.-v: для более подробной информации в выводе консоли, чем больше v тем подробнее информация (vилиvvилиvvv).--transfers=30: кол-во файлов которые будут отправляться за раз. Советую следить за тем, какую скорость показывает rclone в консоль и регулировать кол-во файлов через команду. Имейте ввиду, без--fast-listслишком много файлов параллельно передать не получится.--cache-workers=16: кол-во процессов-воркеров которые кешируют и отправляют файлы. Каждый воркер отдельный процесс, по этому нужно регулировать их кол-во в зависимости от мощности вашего процессора.--update: если вы по какой либо причине остановили процесс переноса и хотите восстановить его, то обязательно используете данный флаг, что бы rclone пропускал файлы уже загруженные в облако и не дёргал их дополнительно, например, для сверки чексуммы.
Пример полной команды:
rclone copy source:/source_bucket yandex:/bucket \
--fast-list \
--create-empty-src-dirs \
--transfers=30 \
--cache-workers=16 \
--update \
-P \
-vТаким образом мы переносим все данные из облака source и бакета в нем source_bucket все данные в облако yandexи бакет в нем bucket. Используем fast list так как оперативной памяти хватает, если упремся то перезапускаем без него. Создаем пустые директории, следим за процессом с выводом предупреждений, передаем сразу 30 файлов для использования всей скорости канала, при этом включены у нас 16 воркеров с пропуском файлов которые в Яндексе уже присутствуют. Для нас именно такие настройки, сделали загрузку максимально быстрой и позволили забить канал в 1 гигабит.
Заключение
Мы мигрировали 50 млн файлов общим весом 5ТБ.
Без применения описанных выше методов, при настройке самым прямым образом, переезд рассчитывался бы следующим образом:
Исходящий трафик из облака А: 9 600 руб.
GET-запросы к облаку А: 4 950 руб.
PUT-запросы к облаку Б: 118 000 руб.
Итого: 132 550 руб.
С применением описанных подходов:
Исходящий трафик из облака А: 0 руб.
GET-запросы к облаку А: 4 950 руб.
PUT-запросы к облаку Б: 24 000 руб.
Виртуальная машина в локальной сети провайдера А: ~600 руб.
Итого: 29 550 руб.
Таким образом, описанные в материале методы могут позволить сократить расходы на миграцию данных в 5 раз. В нашем случае – это было примерно 100 000 рублей, но при другом объеме данных, речь может идти о сотнях тысяч или даже миллионах.
Когда мы приступали к этой задаче, нам не посчастливилось найти материал, который рассказал бы нам про все эти нюансы и позволил сэкономить время и деньги. Вместо этого мы слили несколько тысяч рублей прежде чем поняли, как этого избежать, затянули процесс на несколько дней, уперлись в кончающийся баланс и слили еще несколько тысяч. Надеемся, что эта статья позволит кому-то избежать повторения наших ошибок.
