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

Меня зовут Дмитрий Штегельман. Я системный инженер в VK Cloud. Мы продолжаем серию статей о правильной и безопасной миграции компонентов виртуальной инфраструктуры между облаками. В первом материале серии мы разобрались с переносом между платформами виртуальных машин, а в этой статье разберем пример миграции базы данных (БД) PostgreSQL и объектного хранилища S3 с AWS в VK Cloud.

Подготовка к миграции: обязательные шаги и рекомендации

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

Упрощенно первичная подготовка к миграции БД и S3-хранилищ состоит из нескольких этапов:

• Аудит инфраструктуры. Это важно, чтобы в целом оценить возможность миграции. Здесь надо изучить, как плотно интегрированы хранилища в ИТ-ландшафт, как их остановка на время миграции отразится на работе других сервисов, что нужно обязательно переносить на другую площадку вместе с БД и прочие факторы. 

• Аудит сети. Он нужен, чтобы на этапе подготовки понимать, какую скорость обмена данными может обеспечить сеть и сколько каналов передачи данных можно задействовать.

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

• Создание резервных копий. Наличие бэкапа — страховка на случай ошибки в процессе миграции.

• Подготовка плана миграции. Разработка максимально детализированного чек-листа и порядка действий — от старта до завершения миграции — поможет выполнить перенос безопасно и предсказуемо.

Фактически в результате такого первичного анализа на руках можно иметь отчет, из которого будет понятно:

• что именно мигрируем (особенно если миграция БД затрагивает и другие компоненты);

• какие для этого нужны ресурсы инфраструктуры и команды;

• на какой период надо будет остановить БД и/или хранилище S3.

Выбор инструмента

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

• PgAdmin — официальный клиент для PostgreSQL, который подходит для решения разных задач, включая написание SQL-запросов, разработку процедур и администрирование баз данных PostgreSQL. 

• DBeaver — универсальный инструмент с открытым исходным кодом, который может управлять различными СУБД. Позволяет визуализировать работу с базами данных на различных платформах, в том числе переносить данные между разными базами данных или между таблицами внутри БД. 

PgAdmin — удобное и простое ПО. Но инструмент медленный, а его функции ограниченны. Поэтому для осуществления данной миграции мы будем использовать DBeaver — он быстрее, нагляднее и функциональнее. Но это не значит, что другой инструмент не подойдет, — например, можно подключаться к серверам баз данных и через терминал PSQL.

С инструментом для миграции объектных S3-хранилищ все несколько проще: обычно используют либо автоматический перенос данных через панель управления хранилища, либо утилиту командной строки Rclone. Но вариант с Rclone в большинстве сценариев предпочтителен, поскольку он универсальнее, больше подходит, когда данных много и они постоянно меняются. Таким образом, при переносе S3-хранилища в примере мы будем работать с Rclone.

Миграция PostgreSQL: БД в облаке AWS

В рамках статьи мы будем рассматривать миграцию платформенной PostgreSQL из облака AWS. 

Сама база развернута как платформенный сервис PostgreSQL. 

Через интерфейс AWS мы можем зайти и посмотреть движок БД, строку подключения, порт и другие параметры. 

Подключимся к базе данных, которую мы запланировали мигрировать из облака AWS, при помощи консоли DBeaver.

Примечание: Алгоритм создания подключения к различным СУБД и базам данных при помощи DBeaver можно найти на официальном сайте.

Важно! На период миграции БД должна быть отключена от любых сервисов и доступ пользователей к ней должен быть ограничен — чтобы никто не мог вносить изменения в данные.

Миграция PostgreSQL: алгоритм переезда

Первое, что нужно, — создать БД, в которую будут выгружаться данные из AWS.

Создание инстанса в облаке VK Cloud

Для этого заходим в Личный кабинет VK Cloud. Переходим в раздел «Базы данных» и подраздел «Инстансы баз данных». 

Далее нажимаем «Добавить», чтобы создать новую базу данных.

Выбираем тип базы данных (PostgreSQL) и конфигурацию (single, master-replica или кластер). Нажимаем «Следующий шаг».

Задаем параметры инстанса: название, категорию и тип виртуальной машины (ВМ), зону доступности, параметры диска (на выбор доступны диски SSD и High-IOPS SSD) и автомасштабирования. 

Примечание: Данные параметры надо рассчитать заранее. Для этого необходимо иметь собранные метрики по нагрузке на все ресурсные группы (CPU, память, диски, сеть) вашей базы данных за длительный период. Это даст понимание пиковых нагрузок, прироста базы данных, одновременного количества пользователей, отчетных периодов и других показателей. 

Платформа VK Cloud позволяет автоматически увеличивать размер дисков при заполнении данными, а также дает возможность создавать кластеры с синхронными и асинхронными репликациями, которые можно использовать для распределения нагрузки. Но ответственность за «здоровье» системы всегда лежит на инженере.

Здесь же указываем параметры сети, настройки резервного копирования. Нажимаем «Следующий шаг».

Далее указываем тип создания (выбираем «Новая база данных»), задаем имя базы данных, имя пользователя и пароль (данная учетная запись будет владельцем конкретной базы данных, но не сможет управлять СУБД). Нажимаем «Создать базу данных».

В зависимости от размера виртуальной машины создание может занять до 15–20 минут.

После того как инстанс с базой данных будет готов, он отобразится и станет доступным в личном кабинете VK Cloud в разделе «Инстансы баз данных».

После этого можем переходить к следующему этапу.

Создание резервной копии PostgreSQL

Поскольку база в AWS отключена от любых пользователей и находится в статичном положении, мы можем через DBeaver сделать бэкап. 

Подготавливаем отдельную виртуальную машину в облаке VK Cloud с диском необходимого размера, на который мы сможем положить созданную резервную копию. Следом ставим на нее DBeaver, даем доступ в интернет, настраиваем необходимые правила облачного файрвола.

Переходим в DBeaver, где уже есть предварительно созданный и подключенный инстанс PostgreSQL из AWS с названием moodle.

Заходим в настройки БД, выбираем пункт «Инструменты» и подпункт «Резервная копия».

Далее выбираем объекты для выгрузки. В нашем случае это public со всеми таблицами.

Нажимаем «Далее».

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

После конфигурирования нажимаем «Старт». 

Ждем создания резервной копии и сообщения, что задача создания дампа завершена успешно.

Подготовка БД в VK Cloud

После создания резервной копии БД из AWS переходим в Личный кабинет VK Cloud и открываем ранее подготовленный инстанс, где можем посмотреть всю информацию о нем. 

Переходим в подраздел «Список баз данных», нажимаем «Создать базу данных».

Даем название moodle, нажимаем кнопку «Создать базу данных».

Она отобразится в списке баз данных.

В следующем подразделе «Параметры баз данных» при необходимости можно указать дополнительные внутренние параметры. Примечательно, что всё, что обычно настраивается с помощью конфигурационных файлов, в VK Cloud можно настроить несколькими кликами.

В нашем примере оставим параметры без изменений.

Также для инстанса через соответствующий подраздел можно добавить пользователя и назначить базу, с которой он сможет работать.

Помимо этого, через настройки также можно в несколько кликов подключить расширения PostgreSQL для разных задач: Prometheus для серверных метрик, сервис для оптимизации, популярные Hints для планера PostgreSQL, pooler и другие.

После подготовки БД можно переходить к следующему этапу.

Развертывание бэкапа БД в VK Cloud

Переходим в DBeaver.

В поле слева открываем рабочее пространство VK DEMO DB root, находим базу данных moodle. 

Вызываем ее контекстное меню. Выбираем пункт «Инструменты» и подпункт «Восстановить».

В появившемся окне выбираем настройки и файл резерва, то есть ранее созданную резервную копию БД из AWS. После этого нажимаем «Старт».

Ждем окончания восстановления БД уже на целевой облачной платформе.

После восстановления PostgreSQL в облаке VK Cloud миграцию можно считать завершенной. Остается только поменять в конфиге путь к базе данных — переключить его на БД в VK Cloud. После этого PostgreSQL станет доступной для работы. Profit.

Миграция S3: объектное хранилище в облаке AWS

Для демонстрации алгоритма миграции S3-хранилищ из AWS в VK Cloud, мы предварительно создали бакет с названием demo-vkcloud, в который для наглядности добавили объекты разного размера — от 1 до 100 МБайт и более.

Миграция S3-хранилища: алгоритм переезда

Приступим к пошаговому описанию алгоритма миграции.

Первое, что нужно, — создать в облаке VK Cloud (или другой целевой платформы) виртуальную машину, на которую нужно установить Rclone (ПО для синхронизации данных между различными хранилищами) и AWS CLI (консольный интерфейс для управления S3).

Примечание: Подробную инструкцию по созданию виртуальной машины в облаке VK Cloud можно найти в документации на официальном сайте провайдера. Она здесь.

После создания ВМ подключаемся в машине через Windows PowerShell — командную оболочку, которая позволяет решать практически любые задачи администрирования, от настройки операционной системы до удаленного управления устройствами в сети.

Здесь будем выполнять настройку RСlone и AWS CLI.

В первую очередь выполняем команду конфигурирования профиля подключения AWS с помощью AWS CLI:

aws configure - - profile aws

Далее последовательно вводим AWS Access Key ID, AWS Secret Access Key и Default region name, соответствующие бакету S3 в AWS. Default output format можно не указывать — он будет назначен по умолчанию. 

Следующим шагом настраиваем подключение к ранее созданному (но пока еще пустому) бакету в облаке VK Cloud с помощью команды: 

aws configure - - profile vk

Далее также последовательно вводим AWS Access Key ID, AWS Secret Access Key и Default region name, соответствующие бакету S3 в VK Cloud.

После настройки проверяем список файлов в AWS. Для этого используем команду:

aws s3 ls - -summarize - -human-readable - -profile aws - -recursive s3://demo-vkcloud/

В ответ получаем полный перечень объектов с указанием их количества и суммарного объема.

Далее проверяем готовность и отсутствие объектов в бакете в VK Cloud. Для этого выполняем команду:

aws s3 ls - -summarize - -human-readable - -profile vk- -recursive s3://demo-vkcloud/ - -endpoint-url https://hb.vkcs.cloud

В ответ получаем вывод с количеством объектов и занятым объемом. Поскольку бакет новый, значения должны быть нулевыми. 

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

Примечание: Подробную инструкцию настройки конфигурации rclone можно найти в официальной документации по ссылке.

В рамках нашего обзора будем работать с уже предварительно настроенными конфигурациями rclone для AWS и VK Cloud.

Запускаем копирование, используя команду:

rclone copy aws:/demo-vkcloud vk:/demo-vkcloud -P - -transfers=16, 

где: copy aws:/demo-vkcloud — S3-исходник;

vk:/demo-vkcloud — целевой бакет (куда копируем);

P — ключ для отображения процесса копирования;

16 — количество потоков.

Примечание: Количество потоков можно назначать и больше. Оно ограничено лишь типом виртуальной машины, на которой запущен RСlone (количество потоков не должно быть больше количества ядер на виртуальной машине), и каналом, который соединяет инстансы S3 в разных облаках.

После выполнения команды начинается копирование.

Дожидаемся сообщения об успешном завершении копирования с указанием количества скопированных объектов и их суммарного объема.

Для проверки корректности копирования проверяем количество объектов в целевом бакете и их размер. Для этого используем команду:

rclone size vk:/demo-vkcloud

Помимо этого, также можем отобразить список объектов, используя команду:

rclone ls vk:/demo-vkcloud

Далее проверяем сами объекты в личном кабинете VK Cloud. Для этого заходим в раздел «Объектное хранилище» и выбираем подраздел «Бакеты». Находим бакет с названием demo-vkcloud. Переходим в него.

Проверяем, что все мигрируемые объекты есть и «доехали» без ошибок.

На этом миграцию объектного хранилища S3 можно считать завершенной. 

Вместо выводов

Наш опыт и описанный в статье пример показывает, что мигрировать БД и S3 можно безопасно, без риска потери данных и их утечки. Но для этого надо тщательно подготовиться, правильно выбрать стек и развернуть инфраструктуру на целевой платформе, а также четко придерживаться рекомендованной последовательности действий. Более того, в таком случае легче обходятся и потенциальные ограничения vendor-lock.

В следующей, заключительной, статье серии мы рассмотрим алгоритм миграции Kubernetes между облаками. Оставайтесь с нами!

VK Cloud предлагает российским компаниям помощь в переходе на безопасную облачную платформу отечественного провайдера. Команда инженеров поможет выбрать архитектуру ИТ‑решения и набор облачных сервисов, провести миграцию, обеспечить отказоустойчивость и доступность.