Поймай меня, если сможешь [часть 2]: как мигрировать в облако Huawei Cloud Stack (и другие)

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

Недавно на Хабре вышел лонгрид «Поймай меня, если сможешь [часть 1]: облако на Huawei Cloud Stack — что это, как используют и лицензирование», в котором я рассказал про платформу Huawei Cloud Stack (HCS) — как она устроена и почему крупные компании вообще смотрят в её сторону, лицензирование и многое другое.

Что ещё было:

Там же было немного про архитектуру и сценарии использования платформы в продакшене: пулы ресурсов, мультиоблачность, варианты отказоустойчивости, высокой доступности и аварийного восстановления, edge-инфраструктура (периферийная), различно ПО, вроде ManageOne (центр управления ЦОДом и облачными ресурсами), и прочие радости корпоративной жизни с Huawei Cloud Stack. В общем, есть что почитать.

Но платформа HCS больше, чем сумма её частей: первый лонгрид (при всех моих стараниях) всё равно получился лишь аннотацией к Сильмариллиону. Той теории достаточно для поверхностного знакомства, теперь же обсудим подготовку к миграции: аудит инфраструктуры, разберёмся с RPO и RTO, посмотрим на совместимость виртуальных машин и образов, а самое главное — обсудим стратегии миграции по методологии AWS, которые можно применить не только к HCS, но и к любому другому облаку.

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

Миграция на Huawei Cloud Stack

В целом все актуальные облачные платформы, будь то платные или опенсорс, частные, гибридные или публичные, умеют одно и то же: пулы ресурсов, виртуалки, сети, SDS, контейнеры, высокая доступность, аварийное восстановление и т.д. И, разумеется, они предоставляют ресурсы и сервисы по запросу в рамках своих границ, а потому облако — это в неком роде XaaS (Everything-as-a-Service aka всё как услуга). На даже при схожем конечном результате под капотом у разных облаков и конкретных IT-инфраструктур всё по-своему.

Это значит, что миграция между экосистемами облаков — это всегда столкновение двух океанов: разных моделей управления и подходов к автоматизации, сетевых архитектур, гипервизоров, форматов, систем хранения и различного ПО.

Где-то миграция пройдёт легко, пока админ будет попивать сок у себя на квартале. А где-то её вообще нет смысла проводить — дешевле, надёжнее и быстрее поднять сервисы с нуля, чем переносить легаси-хвосты из сомнительных или устаревших решений. Отдельное удовольствие админов и всех причастных — миграция высоконагруженных сред и сред, где простой (не антоним к сложному, а вынужденная остановка работы) даже на несколько минут обходится организациям неприлично дорого: банкам, телекому, промышленности, госам или облачным провайдерам и различным гиперскейлерам. Всё это — целевая аудитория частных/гибридных облаков в целом и Huawei Cloud Stack в частности.

Huawei, конечно, пишет в маркетинговых буклетах и документации про бесшовную миграцию, но это касается лишь редких частных случаев. Глобальная миграция всего и вся — это вопрос критичный и крайне сложный. На один лишь аудит зависимостей могут уйти месяцы, а ещё нужна подготовка, планирование, тесты, закупка решений и инструментов, найм/обучение персонала и много другое.

То, насколько сложно или гладко всё пройдет, зависит от качества предварительного аудита.

Давайте этим и займёмся.

1. Аудит и сбор данных — ваше всё

Без аудита миграцию начинать нельзя — и провести его нужно по всей строгости регламентов IT-инфраструктуре и всему контуру администрирования.

Вам предстоит весёлая работа по инвентаризации всех виртуалок и аппаратных серверов, по описанию лицензий, сервисов и их зависимостей, сетевых конфигов и конфигов хранилищ, различных проблем и рисков. Вы должны четко знать, на каких локалках и подсетях работают сервисы, какие бэкапы уже настроены, какие версии ОС и приложений используют виртуалки, насколько длинный софтовый и аппаратный легаси-хвост у вашей инфраструктуры и с каких годов он тянется. Без этого не получится определить, какие сервисы можно перенести сразу (или нельзя в принципе), а какие позже — после адаптации.

А контур администрирования — это все системы, отвечающие за управление, мониторинг, резервное копирование, безопасность, аварийное восстановление и работу инфраструктуры: Active Directory, DNS, DHCP, PKI, системы мониторинга, логирования, наблюдаемости, SIEM, CMDB, резервное копирование, сервисы автоматизации, средства управления виртуализацией, системы удалённого низкоуровневого доступа к серверам (iLO, iDRAC, IMM, IPMI), а также различные внутренние порталы, скрипты и интеграции. Вы же не хотите получить несовместимости и коллизии?

Другой момент — если раньше у вас не было требований по RPO (Recovery Point Objective, сколько данных можно потерять) и RTO (Recovery Time Objective, сколько времени допускается на восстановление) хотя бы для критичных сервисов, то самое время этим заняться, так как от них напрямую зависят сроки и методы миграции.

После этого можно разбить перенос системы на этапы — их называют миграционными волнами. Очевидно, что начинать надо не с ERP или CRM. Сначала разворачивают базовую инфраструктуру в целевой среде (сети, каналы, VPN, бэкапирование, площадку виртуализации или облако и т.д.), а уже потом переносят изолированные (или наименее зависимые) и самые простые системы, чтобы проверить сети, процессы миграции, резервное копирование: у команды будет время протестировать новую платформу, внести правки или, если надо, откатить изменения. Только после этого переходят к среднекритичным сервисам. И если всё хорошо — к критичным бизнес-системам, вроде ERP, CRM и т.п.

Шаги аудита перед миграцией в облако:

1. Проводим инвентаризацию физической инфраструктуры + контура администрирования;

2. Составляем карту зависимостей;

3. Определяем RPO/RTO (хотя бы для критичных систем);

4. Определяем этапы миграции (миграционные волны);

5. Разрабатываем план отката с тестами (он же rollback);

6. Оцениваем совместимость старого с новым (опционально — про это дальше).

И помните: для любого переключения нужно заранее подготовить и протестировать план отката на исходную платформу (это не на время тестов, а на первое время после миграции, когда уже весь прод работает в новом облаке). Даже если вы продумали и протестировали миграцию 10 раз (и тестовая среда работала без сбоев несколько недель). Когда речь о бизнес-процессах, простоях, финансовых и репутационных потерях, нужно учитывать закон подлости Мёрфи, который гласит: если что-то может пойти не так, то оно пойдёт не так. В аудит это не входит — скорее в управление рисками.

В конце аудита у вас должна получится карта зависимостей (её лучше нарисовать), требования по RPO/RTO, очередность миграционных волн. Я приведу таблицу для примера, но ваш документ должен получится ещё подробнее.

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

1.1 Категоризация и оценка совместимости виртуальных дисков и конфигураций виртуалок (если у вас нет виртуализации, переходите сразу ко 2 пункту)

Чтобы мигрировать с VMware или Hyper-V на Huawei Cloud Stack, нужно привести виртуальные диски и конфигурации виртуалок к форматам целевой платформы. Для этого в HCS есть служба управления образами IMS (Image Management Service), через которую можно импортировать внешние образы, а следом сделать из них шаблонные private image для массового развёртывания сервисов ECS (Elastic Cloud Server). Дальше эти шаблоны уже подключаются к Auto Scaling, DR-сценариям и автоматизации инфраструктуры.

Итак, VMware и ESXi использует VMDK формат файлов виртуального жесткого диска, а гипервизор Hyper-V — VHD/VHDX. Ну а поскольку HCS основан на архитектуре виртуализации OpenStack/KVM (ныне сильно модифицированной), то основными форматами в нём исторически были QCOW2 и RAW. В ранних версиях HCS образы из VMware или Hyper-V обычно приходилось сначала конвертировать руками, а уже потом импортировать в IMS/ECS.

Особенно весело было со старыми Windows Server 2008/2012. VMware использовала свои SCSI-контроллеры и драйверы паравиртуализации, а KVM/OpenStack хотел VirtIO или IDE/SATA. Если внутри гостевой ОС нужного драйвера не было, то виртуалка просто не видела системный диск после переноса. А это что? Правильно — гарантированный синий экран смерти.

Миграция на современные версии HCS стала в разы удобнее. Особенно после развития IMS, появления Rainbow (про него будет позже), HCC, автоматизированных инструментов и перехода многих инсталляций на OBS (Object Storage Service).

Сейчас Huawei Cloud Stack поддерживает гораздо больше форматов внешних образов.

Учтите, что ZVHD (а также ZVHD2) — это проприетарные форматы образов виртуальных жестких дисков от Huawei. И вдобавок они не взаимозаменяемы при импорте. ZVHD не поддерживает ленивую загрузку (lazy loading), поэтому для быстрого импорта больших файлов (до 1 ТБ) нужен ZVHD2. Если файл в формате ZVHD и больше 128 ГБ — его всё равно придётся конвертировать в ZVHD2 или RAW с bitmap.

В общем, жизнь новый HCS (8.x) облегчил, но форматы виртуальных дисков — это полбеды. Вам всё ещё нужно учитывать версии гостевых ОС, специфическое ПО (всякие антивирусы и EDR-агенты), поддержку виртуальных адаптеров (например, отсутствие драйверов VirtIO в старых Windows), формат загрузки (UEFI/BIOS), BitLocker и прочее шифрование, OEM-драйверы, привязку лицензий к железу, старые VMware Tools/Hyper-V Integration Services, разметку GPT/MBR, наличие VirtIO-драйверов и другое.

И Huawei отдельно напоминает, что образ не должен быть зашифрован; загрузочный и системный разделы должны лежать (физически или логически) на одном диске; базовая ОС должна поддерживать полную аппаратную виртуализацию; OEM-образы сторонних производителей могут не работать в принципе, гетерогенные хранилища (объединение накопителей с радикально разными характеристиками или интерфейсами) не поддерживаются.

А кто говорил, что тащить легаси добро в другое облако легко? Но раньше, с ручной конвертацией образов и импортом в IMS, было ещё сложнее. Перекрестились, свечку поставили, идём дальше.

2. Стратегии миграции в облако — у вас должна быть какая-то тактика

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

• Cold migration (холодная миграция) — сервис полностью останавливается на время переноса;

• Warm migration (горячая миграция) — данные предварительно реплицируются, а на переключение требуется короткое окно простоя;

• Live migration (живая миграция) — перенос выполняется практически незаметно для пользователей.

Эти сценарии идеально бы дополнить отраслевым стандартом 6R (а лучше 7R). Например, одну систему можно мигрировать по стратегии Rehosting (дальше расскажу) через cold migration, а другую — по той же стратегии, но уже через warm migration с репликацией и коротким окном переключения.

6R — это модель миграции IT-инфраструктур, систем и приложений в облако, которую разработала AWS (Amazon Web Services) на основе пяти принципов от Gartner (ведущая мировая исследовательская и консалтинговая компания). У AWS даже проприетарный фреймворк есть — AWS 6Rs, который помогает компании оценить портфель своего ПО и выбрать лучший путь переноса каждой отдельной системы.

Итак, что за Rehosting и 6R такие?

А мы ещё и седьмой вариант прикрутим (7R) — Relocate, он же быстрый перенос из кофейни на Патриарших в кофейню в Тбилиси платформы виртуализации целиком. Виртуалки/контейнеры в таком сценарии перемещают без изменений и переустановки. Например, массовая миграция виртуальных машин из VMware vSphere в среду Huawei Cloud Stack с использованием инструментов миграции и конвертации образов. Тот самый частный случай с, цитирую, «бесшовной миграцией».

Седьмое и другие правила отлично накладывается на таблицу, что я приводил — выше в разделе про аудит. Так что в правом столбце к плану миграции можно добавить и стратегию (например, 6R, если пронумеруете и не забудете, что есть что). Или выделить в отдельный столбец — по желанию.

Выбирайте одну из семи стратегий для каждого сервиса с учётом бизнес-требований. Их можно (и нужно) совмещать, исходя из RPO и RTO каждого — в этом и есть смысл. Например, часть виртуалок перемещают по стратегии Rehosting, бизнес-критичные приложения модернизируют через стратегии Replatforming или Refactoring, от древних систем отказываются (Retire), а отдельные сервисы оставляют как есть на локальных серверах (Retain).

Кстати, если вы ещё не занимались ТЭО и пока только читаете статьи, изучаете платформу, то после аудита, выбора стратегий, оценки и категоризации, самое время заняться этим.

Краткий подытог

Миграция в Huawei Cloud Stack не ограничивается переносом виртуальных машин. Если вы уже работаете с PaaS облачными сервисами, то часть систем можно вообще не переносить.

Например, базы данных можно перенести из собственных виртуальных машин в управляемые сервисы БД Huawei Cloud Stack, а контейнеризированные приложения — в Kubernetes-кластеры с помощью сервиса Cloud Container Engine (CCE). Это уже не просто перенос образов виртуальных машин, а миграция данных, конфигураций и приложений между сервисами разных платформ.

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

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