Поймай меня, если сможешь [часть 3]: инструменты миграции в Huawei Cloud Stack —сети, серверы и данные

Привет, постоянные и не очень читатели!

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

Рано или поздно (скорее поздно) аудит закончится, миграционные волны согласуют, а руководство одобрит проект и бюджет. И тогда придётся переходить к самому опасному и сложному этапу — великой и ужасной миграции.

У Huawei Cloud Stack для этого под капотом есть целый стек инструментов: HCCCMS (нет, кнопку не заело) для миграции серверов и виртуальных машин, IMS для работы с образами, DRS (Data Replication Service) для переноса баз данных, CDM (Cloud Data Migration) и DataArts для миграции данных, а также великое множество сетевых и облачных сервисов из публичного облака Huawei Cloud.

Если что-то интересующее вас в материал не попало, то задавайте вопросы в комментариях. Я или хабравчане, которые уже работали с Huawei Cloud Stack, дадим ответ. А в крайнем случае всегда можно изучить официальную документацию — у Huawei она более чем подробная.

1. Инструменты и утилиты для миграции в Huawei Cloud Stack

Если сильно упростить, то классическая миграция проходит сразу по нескольким направлениям (не всегда последовательным):

1. Развёртывание целевой платформы;

2. Подготовка сетевой инфраструктуры, маршрутизация, групповые политики безопасности;

3. Перенос физических серверов;

4. Перенос виртуальных машин (опционально — читай 1.1);

5. Перенос данных (неструктурированные данные и архивы);

6. Перенос БД (логическая структура, связи, зависимости и транзакционная целостность);

И для каждого в HCS есть свои инструменты и подходы. Ту же виртуалку можно перенести целиком (как образ диска), а можно развернуть новую и уже на ней восстановить данные из резервной копии исходной ВМ. Базу данных можно реплицировать транзакционно практически без простоя, а архив — просто скопировать (пакетами). Выбор зависит от требований бизнеса, компетенций и бюджета, поэтому я обрисую в общих чертах.

Из общего: сначала нужно развернуть целевую платформу HCS, провести базовую настройку сетей и облака, интегрировать его с существующей инфраструктурой, а лишь потом начать подготовку сервисов миграции.

Для целевой платформы используйте HCC Turnkey — мастер автоматизированного развёртывания самого HCS-кластера. Он же поможет поднять все критичные сервисы: ManageOne, ECS, EVS, VPC, OBS (если используется), Backup & DR-сервисы, IAM и базовые сервисы управления. Многое опционально — есть и упрощённое развёртывание. Про это я подробно рассказывал в первой части.

Но самое важное и сложное — стабильная сетевая инфраструктура. С неё и начнём.

1.1 Подготовка сетевой инфраструктуры HCS

Архиважно правильно спроектировать и настроить виртуальную сетевую среду, если вы, конечно, не хотите простоев после миграции.

Перенос топологии сети в Huawei Cloud Stack обычно начинают с воссоздания логической структуры сетевой инфраструктуры через сервис VPC (Virtual Private Cloud). Он позволяет создавать изолированные (логически) виртуальные сети для ECS (Elastic Cloud Server), BMS (Bare Metal Server) и других облачных ресурсов, что повышает безопасность и упрощает развёртывание.

Первым делом нужно воссоздать сегментацию, а для этого нужны отдельные VPC для каждого сегмента (или изоляция на уровне подсети внутри одной VPC). Например, отдельные VPC для разработки, тестирования и прода.

Следующий этап — планирование IP-адресного пространства. Желательно максимально сохранить IP-адресацию и полностью воспроизвести CIDR-блоки подсетей. Лишние изменения в приложениях, настройках безопасности и интеграциях часто приводят к ошибкам. Не должно быть пересечений или наложений IP-адресов подсетей друг на друга, а внутри каждой подсети первые четыре и последний IP-адрес зарезервированы и недоступны.

У сервиса VPC в HCS есть стандартные квоты:

• Максимальное количество VPC на аккаунт/проект: 5;

• Максимальное количество подсетей в рамках одного региона: 100.

Если в исходной инфраструктуре критически важные системы используют статические IP-адреса — их лучше сохранить. Да, HCS позволяет изменить частный IP-адрес у остановленной ВМ, но после таких правок нужна ручная настройка внутри гостевой ОС сервера. Поэтому для крупных проектов имеет смысл подготовить таблицу соответствия старых и новых адресов.

При создании подсетей HCS автоматически разворачивает DHCP-сервер. Но также нужно продумать перенос настроек DNS-инфраструктуры. Если вы работаете с Active Directory, то нужно либо развернуть контроллеры домена в облаке, либо настроить гибридное подключение к существующим DNS-серверам и AD на старой площадке.

Отдельно проверяют все внешние подключения.

В локальных (on-prem) инфраструктурах этим занимаются аппаратные маршрутизаторы, межсетевые экраны, балансировщики нагрузки и VPN-шлюзы. А после миграции разумеется, этот функционал должны взять на себя виртуальные аналоги.

Маршрутизация трафика в HCS работает на базе таблиц маршрутизации. Каждая VPC автоматически создает таблицу маршрутов по умолчанию, которая управляет трафиком между подсетями. Для сложных сценариев (например, перенос статических маршрутов из локальной инфраструктуры) нужно создать и настроить одну или несколько пользовательских таблиц маршрутизации. При этом пользовательская таблица маршрутизации управляет только исходящим трафиком из подсетей, с которыми она ассоциирована (входящий обрабатывает таблица по умолчанию). Учтите это при переносе сложных маршрутизаций — момент важный.

Квоты:

• Максимальное количество таблиц маршрутизации, которое можно связать с одной VPC: 5 (включая таблицу по умолчанию);

• Все таблицы маршрутизации в пределах одной VPC могут содержать не более 1000 маршрутов (исключая системные), а каждая пользовательская таблица маршрутизации может содержать до 200 маршрутов.

• За один API-запрос можно добавить до 5 маршрутов. Это важно учитывать при автоматизации развёртывания, чтобы избежать ошибок при массовом добавлении маршрутов.

Теперь к правилам сетевой безопасности. Для этого в HCS есть Security Groups (Группы безопасности) — это логические группы, к которым можно применять правила, разрешающие или запрещающие трафик/доступ к ВМ на уровне портов.

Это главный инструмент, через который можно реализовать модель минимально необходимых привилегий (про это и другие фичи кибербеза читайте в другой моей статье на Хабре: «Защита серверов и данных: Zero Trust и 20 фич для вашей кибербезопасности»).

При переносе действующих политик безопасности в HCS тоже есть свои правила и квоты:

• Одну виртуалку можно добавить в 5 Security Groups, и правила из всех этих групп будут применены вместе.

• У одной Security Group может быть до 50 правил безопасности. Но максимальное количество правил с определенными параметрами (например, с указанием диапазона портов или другой Security Group в качестве источника) ограничено 120 для входящих и исходящих правил отдельно.

• На один проект/аккаунт максимум 100 Security Groups.

• По умолчанию Security Group блокирует весь входящий трафик извне, разрешая только исходящий. Это частая причина проблем с доступностью работающего сервиса — не забывайте создать правило, разрешающее входящий трафик.

• Security Groups работают только в пределах одного VPC. Если хотите разрешить трафик между экземплярами в разных VPC, то нужно настроить связность через VPC Peering, VPN или выделенные каналы.

При переносе действующих политик безопасности нужно учесть:

• Список разрешенных IP-адресов и сетей;

• Перечень открытых портов и протоколов, необходимых для работы приложений;

• Правила взаимодействия между приложениями;

• Ограничения для административного доступа (например, RDP для Windows-серверов, SSH для Linux-серверов, доступ к СУБД только для приложений).

Хорошая практика — описать схемы сетей и сравнить их. Плюс используйте тестовые виртуалки, чтобы проверить работу сети: пингуется узлы, проверяйте маршрутизацию, разрешение доменных имён, работу приложений, взаимодействие между сегментами сети. Если всё сложно, то можно временно сохранить оба окружения в связке (гибридный режим), чтобы постепенно переводить трафик.

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

1.2 Перенос физических серверов в HCS

Для переноса аппаратных серверов (фраза не совсем корректна, я осознанно упрощаю) нужна этакая оцифровка физической (Physical) инфраструктуры в виртуальную (Virtual). Отсюда и название — P2V, а перенос виртуальных машин называют V2V (Virtual to Virtual). Метод зависит от того, что именно вы переносите: сам сервер, данные, сервис или всё сразу. Простой файловый архив перенести легко, а вот продакшн-систему с лицензиями, привязанными к железу, уже намного сложнее.

Основной инструмент для P2V-миграции в современных версиях Huawei Cloud Stack (8.x и выше) — инструмент HCCCMS (Huawei Cloud Computing Cloud Migration Station), встроенный в Service OM (Operation Manager, про него я писал в первой части).

Это ключевая подсистема, которая работает на уровне виртуализации и выполняет следующие основные функции:

• Единое управление вычислительными, сетевыми и хранилищными ресурсами;

• Жизненный цикл виртуальных машин (создание, удаление, миграция и т.д.);

• Мониторинг производительности и доступности физических и виртуальных ресурсов;

• Обработка аварийных сигналов и управление событиями;

• Предоставление северного (northbound) RESTful API для вышестоящих систем, таких как ManageOne и Service OM.

В ранних версиях HCS для этого была отдельная утилита Rainbow Convertor (hConvertor), автоматизировавшая конвертацию и перенос ОС на целевую платформу — что-то вроде аналога VMware vCenter Converter. Сейчас её функции интегрированы в HCCCMS. Rainbow Convertor работал на базе FusionSphere и выполнял миграцию на уровне файлов или блоков.

Есть и классическая альтернатива — через резервное копирование с восстановлением бэкапа в целевой виртуальной машине и импортом образа в HCS. Вы можете снять образ физического сервера сторонними решениями, вроде Acronis, Veeam, Symantec Backup, Commvault и т.д.

Но для критических сервисов, вроде ERP, CRM, SAP и т.д., такой P2V — не лучший вариант. Лучше сделать ребилд — развернуть новую ECS (Elastic Cloud Server), установить ОС, установить приложение и перенести данные через DRS/CDM/репликацию с последующим переключением.

1.3 Перенос виртуальных машин в HCS

HCCCMS — основной инструмент и для V2V-миграции в современных версиях Huawei Cloud Stack, который позволяет мигрировать как с агентами, так и безагентным способом (в зависимости от сценария), может переносить виртуальные машины между разными версиями HCS, а также служебные ВМ, тома и связанные с ВМ хранилища.

Для некоторых V2V-сценариев (например, VMware) CMS подключается напрямую к API гипервизора-источника, не требуя установки агента внутри гостевой ОС. Но есть и вариант с установкой агента Rainbow в исходную ВМ. Тогда репликация идёт на уровне блоков или файлов.

Миграция через HCCCMS (через интерфейс Service OM) выглядит так: в ManageOne регистрируют исходную платформу (среду-источник) — vCenter, кластер Hyper-V, XenServer и т.п. Далее указываете учётные данные с правами на чтение/управление ВМ, задаёте целевой проект (облако Huawei Cloud Stack) и политики миграции. Вам нужно будет отобрать ВМ с помощью фильтров или руками из списка (можно импортировать CSV-файл с перечнем виртуалок и их параметрами). По учётным данным гостевой ОС Rainbow может автоматически (или руками) установить агент миграции на все выбранные виртуалки. Потом идёт полное копирование дисков, а в конце — инкрементальная синхронизация. По каждой отдельной ВМ можно отслеживать прогресс: скорость, расчётное время и т.д.

Важно, что HCCCMS умеет проводить предварительные проверки (сетевую доступность, совместимость гостевой ОС, права доступа) и делать сводки по запланированным/завершённым миграциям. Саи инструмент входит в штатную поставку Huawei Cloud Stack — его не нужно отдельно лицензировать и развёртывать.

Для работы с образами есть служба IMS (Image Management Service) — про неё я рассказал в разделе категоризации и совместимости во второй части. Через IMS можно импортировать образы ВМ из других платформ виртуализации в Huawei Cloud Stack. Подробнее можете почитать здесь.

IMS работает так:

1. Экспорт образа из VMware или Hyper-V.

2. При необходимости конвертация формата.

3. Загрузка образа в OBS.

4. Импорт в IMS.

5. Создание Private Image (преднастроенная виртуалка — эталонный шаблон).

6. Развёртывание новых ECS-инстансов.

1.4 Миграция данных в HCS

Миграция данных сложна тем, что есть требования к их целостности и времени простоя, а какого-то единого и универсального решения у Huawei нет. Тут, кстати, проявляются плюсы проприетарных СХД Huawei OceanStor Dorado; Huawei OceanStor Pacific; Huawei OceanStor V3/V5/V6, которые позволяют использовать встроенные механизмы HyperReplication, HyperCopy, Remote Replication, Active-Active и т.д.

Если в HCS развёрнут OBS (Object Storage Service), то можно использовать его как промежуточное звено (очень удобно для архивов, файлов, резервных копий) перед целевой системой.

В Huawei Cloud Stack можно использовать сервисы миграции данных семейства CDM (Cloud Data Migration), входящие в платформу управления данными DataArts Studio, но всё зависит от версии HCS, самой CDM и набора развёрнутых облачных сервисов.

DataArts Migration позволяет перенести огромные объёмы структурированных данных из разнородных источников (базы данных, хранилища данных, озёра данных, файловые серверы, различные Oracle, MySQL, SQL Server, DWS, MRS Hive/HBase, OBS и многие другие) в хранилища и аналитические системы HCS. Для этого надо создать CDM-кластер (группу виртуальных машин-исполнителей), настроить каналы с источником и приёмником, и просто запустить перенос данных.

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

1.5 Перенос баз данных в HCS

Вот тут у HCS есть замечательный (хоть и платный) инструмент DRS (Data Replication Service), который сильно упрощает миграцию БД. С ним глубокие технические знания не нужны — и настраивается всё за минуты (а не дни, недели и месяцы). Это сервис по онлайн-миграции, но тарифицируется по требованию — заплатили, перенесли, забыли.

DRS работает через репликацию — сначала полностью переносит данные, а затем переходит в режим непрерывной синхронизации изменений (инкрементальная миграция). Так что финальное переключение можно сделать без остановки сервиса.

А так, без DRS, можно проводить миграцию через встроенные механизмы самих СУБД: штатная репликация (PostgreSQL и MySQL), горячий резерв, логическая синхронизация или сторонние решения специально для переноса. Вариант выбирают после оценки RPO, RTO и допустимого простоя при переключении.

2. Сводная таблица по миграции в HCS

Разумеется, вариативность выше — есть и сторонние сервисы, и другие проприетарные инструменты, включая некоторые решения публичного облака Huawei Cloud. Я затронул базовый набор, от которого можно отталкиваться, а дальше менять что-то под свой проект.

3. Тестирование и валидация

После переключения начинается рабочий этап: обновите документацию и RunBook (рутинные операции, диагностика или устранение инцидентов в IT-системах), настройте мониторинг, наблюдаемость и резервное копирование, проверьте права доступа в ManageOne, политики безопасности, маршрутизацию и процедуры аварийного восстановления (DR). Собирайте отзывы конечных пользователей: пусть тестят критичные функции (например, вход в систему, основные бизнес-процессы). Убедитесь, что задержки доступа и UX не ухудшились — при необходимости, корректируйте систему.

Эти тесты нужно выполнять до, во время миграции и сразу после переключения. Только после всего этого миграцию можно считать успешной (и завершенной).

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

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

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

А у HCS есть всё для построения частного или гибридного облака корпоративного уровня — в наилучшем его виде.