Как перенести базу данных на 5 ТБ с AWS на выделенный сервер и сэкономить 1,3 млн рублей в год

Облако дешевле железа до тех пор, пока вы не посчитаете его на горизонте года при круглосуточной нагрузке. О том, как происходит перенос с AWS на Bare Metal и где возникает экономия — наша статья.

Этот расчётный кейс мы смоделировали для того, чтобы показать, чем физический выделенный сервер, который сдаётся в аренду целиком, без виртуализации и разделения оборудования между несколькими пользователями, дешевле облака AWS. За основу мы взяли опыт и экономические просчёты наших клиентов. О том, что такое Bare Metal, можно прочитать в другой нашей статье «Bare Metal для "чайника": что такое выделенный сервер и зачем он нужен».

Production-база аналитической платформы занимает 5 ТБ и работает в AWS круглосуточно. Нагрузка стабильная, PostgreSQL обслуживает собственная команда. Сейчас администраторы уже отвечают за обновления и эксплуатацию, поэтому после переезда круг их обязанностей изменится меньше, чем при миграции из управляемой СУБД.

В AWS база развёрнута на Amazon EC2, где PostgreSQL обслуживает собственная команда. Amazon RDS в расчёт не включаем: это управляемый сервис, в стоимость которого входят дополнительные функции обслуживания СУБД, включая автоматизацию части обновлений и восстановления. В нашем кейсе сравниваем два варианта самостоятельного администрирования PostgreSQL — на виртуальной машине EC2 и на физическом выделенном сервере Bare Metal.

AWS нет России, поэтому сервер находится во Франкфурте, в eu-central-1. Речь идёт об исторической инфраструктуре, так как в марте 2022 года Amazon прекратила регистрировать новых клиентов AWS из России и Белоруссии. Проект полностью переносит такой контур в Россию.

Исходная машина — r7i.8xlarge с 32 vCPU и 256 ГиБ памяти (около 275 ГБ). К ней подключён сетевой диск gp3 на 6,5 ТиБ (около 7,15 ТБ). Ровно 5 ТБ базе выделять нельзя, поскольку свободное пространство потребуется для роста базы, временных файлов и перестроения индексов.

Для gp3 задаём 40 000 IOPS и 1250 МиБ/с (около 1311 МБ/с). Сам диск поддерживает до 80 000 IOPS и 2000 МиБ/с (около 2097 МБ/с), но у r7i.8xlarge предел ниже — его задаёт EBS-канал виртуальной машины.

Стоимость мы просчитали по публичным тарифам AWS. В цену gp3 входят 3000 IOPS и 125 МиБ/с (около 131 МБ/с), а ресурсы поверх этого уровня оплачиваются отдельно. Для перевода в рубли использовали курс 83,8 руб. за доллар.

Налоги, платная поддержка и комиссии за оплату мы не учитывали. В расчёте используется тариф On-Demand, при котором сервер оплачивается по часам без долгосрочных обязательств. В итоге облако за год обходится в 33 279,96 долл. или 2 788 860 руб.

Снапшот из таблицы с расчетами убрали осознанно — после переезда внешняя резервная копия всё равно понадобится, а прибавлять бэкап только к AWS было бы нечестно. Его считаем отдельно по политике хранения на обеих площадках.

Bare Metal — физический сервер, который арендатор получает целиком, без виртуализации и соседей. В данном кейсе больше всего подойдет тариф standart-256-8S-V2 из линейки Bare Metal «Стандарт».

Восемь SSD вместе дают около 14,304 ТБ ёмкости. Диски по умолчанию соберутся в программный RAID 10, но половина пространства уйдет для дубликации папок и файлов. Файловая система и служебные разделы заберут ещё немного места, но база на 5 ТБ поместится с запасом в 2 ТБ.

Пока приложение и PostgreSQL находятся во Франкфурте, они будут взаимодействовать внутри сети AWS. Если перенести в Москву одну базу, а приложение оставить за рубежом, то каждый SQL-запрос за информацией будет проходить через интернет. Даже дополнительные 30–40 мс дадут задержку, потому что одна операция пользователя может обращаться к базе несколько раз.

В связи с этим вместе с PostgreSQL лучше сразу перенести все серверы приложений, фоновые обработчики и другие компоненты, работающие с данными. Саму базу можно перенести без длительной остановки. Разберем все пошагово.

Сначала выясняем, из чего складываются 5 ТБ. Помимо основных таблиц, место могут занимать индексы, отдельные табличные пространства и накопившиеся журналы WAL. Проверяем расширения PostgreSQL, кодировки и локали, роли пользователей, фоновые задания и библиотеки, которые загружаются вместе с сервером.

Отдельно нужно измерить объём журнала предзаписи за сутки и в часы с нагрузкой. Если база создаёт около 300 ГБ WAL в день, то сервер в Москве должен получать и применять изменения быстрее, чем они появляются во Франкфурте.

Для передачи изменений создаём пользователя с правами репликации и репликационный слот, не позволяющий исходному PostgreSQL удалить журналы, которые новый сервер ещё не получил. Для него нужно заранее задать ограничение и настроить уведомления о свободном месте.

Как мы говорили ранее, восемь SSD в standart-256-8S-V2 объединяются в RAID 10. Такая схема сохраняет работоспособность массива при отказе одного из накопителей и позволяет заменить неисправный диск без восстановления всей базы с нуля.

Для защиты от случайного удаления данных и других логических ошибок к конфигурации добавляют внешние резервные копии. Их стоимость зависит от глубины хранения и частоты создания бэкапов, поэтому её лучше рассчитывать по принятой в компании политике.

Затем нужно установить основную версию PostgreSQL и все расширения и системные библиотеки. Параметры памяти, число фоновых процессов и настройки дисковой записи нужно адаптировать под физический сервер.

Производительность RAID-массива можно проверить с помощью fio, а PostgreSQL — через pgbench и копии реальных запросов. В показателях обратите внимание на время выполнения отчётов, задержку записи WAL и поведение базы.

На этом же этапе проверяем KVM-консоль в личном кабинете RUVDS — она даёт аварийный доступ к экрану и клавиатуре сервера, независимо от SSH. Если после изменения сетевых настроек или обновления ядра машина перестанет отвечать по сети, процесс загрузки можно увидеть в консоли. Там же есть возможность исправить конфигурацию и восстановить подключение удалённо.

Между AWS и RUVDS нужно поднять защищённый туннель или включить TLS для соединения PostgreSQL. В межсетевых экранах лучше оставить только доступ с адресов исходного и целевого серверов, а правила репликации отдельно прописать в pg_hba.conf.

Перед копированием проверяем маршрут с помощью iperf3, смотрим на потери пакетов и подбираем MTU. Сетевой интерфейс на 1 Гбит/с задаёт верхний предел, тогда как реальная скорость зависит от маршрута между Франкфуртом и Москвой.

Если тест показывает устойчивые 600–700 Мбит/с, расчёт срока миграции лучше строить именно по этому значению.

Штатный pg_basebackup умеет копировать работающий кластер через протокол репликации. PostgreSQL продолжает обслуживать приложение, а утилита переносит содержимое каталога данных и необходимые журналы WAL.

Скорость можно ограничить параметром --max-rate, чтобы миграция не заняла весь сетевой канал и не увеличила задержки рабочей базы. После копирования резервную копию проверяют через pg_verifybackup, если эту возможность поддерживает используемая версия PostgreSQL.

Для базы на несколько терабайт можно использовать pgBackRest. Он поддерживает параллельную передачу, сжатие и проверку файлов, поэтому часто оказывается удобнее при нестабильном канале. Конкретный инструмент лучше выбрать во время пробной миграции на копии данных.

После восстановления базовой копии московский сервер запускается в режиме standby и начинает применять WAL, поступающие из AWS. На исходной стороне состояние репликации видно в pg_stat_replication.

Администратор следит за разницей LSN — позицией в журнале транзакций, до которой дошёл каждый сервер. Дополнительно проверяется replay lag, то есть время, на которое реплика отстаёт от рабочей базы. Сначала разница может быть большой, поскольку новый сервер обрабатывает WAL, накопившиеся во время копирования. Перед переключением она должна приблизиться к нулю.

Параллельно сверяем роли, расширения и табличные пространства, проверяем контрольные суммы и агрегаты по критичным таблицам. Приложение можно временно подключить к реплике в режиме чтения и прогнать основные пользовательские сценарии, отчёты и фоновые задания.

Перед рабочей миграцией стоит провести полноценную репетицию. Команда фиксирует последовательность команд, ответственных сотрудников и допустимое время каждого шага. Если приложение подключается к базе по DNS-имени, TTL записи заранее уменьшают, чтобы клиенты быстрее увидели новый адрес.

Репетиция также показывает, сколько времени потребуется пулам соединений и фоновым процессам для переподключения. Иногда сама база переключается за минуту, а приложение ещё десять минут продолжает обращаться по старому адресу из-за закешированной DNS-записи или сохранённых соединений.

В согласованное окно приложение переводим в режим обслуживания и останавливаем новые операции записи. Затем ждём, пока московская реплика применит последний WAL, и ещё раз проверяем отсутствие отставания.

После этого standby повышается до роли primary, то есть становится основным сервером PostgreSQL. В приложении меняем адрес подключения, перезапускаем пулы соединений и постепенно возвращаем рабочий трафик. Сначала можно включить небольшую часть запросов и проверить ошибки, задержки и загрузку сервера.

При отрепетированном сценарии окно недоступности записи укладывается в 10–30 минут. Копирование самих 5 ТБ займёт гораздо больше времени, однако весь этот период исходная база продолжит работать.

Старый сервер во Франкфурте разумно на некоторое время оставить включённым в режиме только для чтения — до начала записи в Москве переключение на него остаётся простым. После появления новых транзакций данные на двух площадках начинают расходиться, поэтому для возврата потребуется обратная репликация.

При идеальных условиях 5 ТБ проходят через 1 Гбит/с примерно за 11 часов, при устойчивых 700 Мбит/с — за 16 часов. С учётом шифрования, рабочей нагрузки и накопившихся WAL на начальную копию разумно отвести сутки. Подготовка и репетиция займут ещё несколько дней.

В конфигурацию RUVDS входит канал до 1 Гбит/с и 10 ТБ трафика в сутки, поэтому базовая копия уместится в дневной пакет. Обычный вывод 5 ТБ из AWS в интернет обойдётся примерно в 440–450 долл. после бесплатных 100 ГБ, или в 37–38 тыс. рублей по принятому курсу.

При полном уходе с площадки можно заранее запросить у поддержки бесплатный вывод данных. После одобрения AWS компенсирует расходы и даёт подходящим клиентам 90 дней на завершение переноса.

Сведём ежемесячные расходы в одну таблицу. В расчёте по-прежнему участвуют один сервер EC2 и один физический сервер RUVDS, а курс доллара зафиксирован на уровне 83,8675 руб. В базовом сценарии компания сэкономит около 104,5 тыс. руб. ежемесячно, или 1,25 млн руб. за год.

Разовые расходы на миграцию окупятся за счёт ежемесячной разницы. Если подготовка инфраструктуры, перенос данных и работа администраторов обойдутся в 300 тыс. руб., затраты вернутся примерно за три месяца. При бюджете миграции в 500 тыс. руб. срок увеличится примерно до пяти месяцев. Даже с учётом этих расходов экономия за первый год составит около 955 тыс. и 755 тыс. руб. соответственно.

Финансовый смысл переезда уменьшается у проектов, которые запускают сервер лишь на несколько часов в день или регулярно меняют объём ресурсов — облачная модель позволяет отключать временные машины и оплачивать их только во время работы, тогда как физический сервер арендуется на весь выбранный период.

Для того, чтобы проверить стоит ли вам переезжать, Bare Metal в RUVDS можно взять на один день, получить root-доступ и прогнать копию нагрузки в московском ЦОД. Среди тарифов доступны:

В нашем кейсе после такого теста остаётся standart-256-8S-V2 — его RAID 10 вмещает базу на 5 ТБ, а разница с инфраструктурой AWS достигает около 1,3 млн рублей в год. Финальная сумма появится после добавления бэкапа и нужного компании уровня доступности, но её уже можно успешно защитить перед финансовым директором.