Перенос рабочих нагрузок в Решение Azure VMware

В этой статье приводятся рекомендации, которые помогут лицам, принимающим решения, определить стратегию миграции для Решение Azure VMware, включая этапы планирования, реализации и вывода из эксплуатации.

Схема, на которой показан процесс microsoft Cloud Adoption Framework для внедрения Решение Azure VMware.

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

Рекомендация: Определите стратегию миграции, подход оценки рабочей нагрузки, последовательность миграции и требования к проверке перед переносом рабочих нагрузок в Решение Azure VMware.

1. Планирование миграции

Прежде чем создавать что-либо, создайте четкое представление о том, что вы переносите, в каком порядке и почему. Используйте методологию плана Cloud Adoption Framework для оценки вашего имущества. Решение Azure VMware лучше всего подходит для сценария rehost, когда требуются минимальные изменения и не требуется модернизация в ближайшей перспективе. Это подходящее решение не для любого приложения, и именно на этапе планирования вы решаете, подходит ли оно.

1.1 Обнаружение и инвентаризация

Миграция Azure сканирует локальную среду vSphere и создает инвентаризацию виртуальных машин, их использования ресурсов и их зависимостей. Эти данные сообщают о размерах (сколько узлов и какой тип узла) и планировании волн (какие рабочие нагрузки перемещаются вместе). Миграция Azure не выполняет перемещение в Решение Azure VMware. Он предоставляет доказательства размера и последовательности проекта.

Стратегия миграции 1.2

Решение Azure VMware в первую очередь поддерживает подход повторного размещения. Приложения, которым требуется рефакторинг или переработка архитектуры, возможно, лучше размещать на Azure-нативных вычислительных службах. Запишите эти решения, чтобы план отражал преднамеренный выбор, а не значения по умолчанию. См. статью "Выбор стратегии миграции в облако".

Оценка рабочей нагрузки 1.3

Не каждая рабочая нагрузка в равной степени подходит для Решение Azure VMware. Прежде чем распределять рабочие нагрузки по волнам миграции, оцените их технические требования, эксплуатационные зависимости и их соответствие платформе. Структурированная оценка помогает выявлять риски раньше, проверять пригодность и гарантировать, что планы миграции отражают бизнес-приоритеты, а не предположения.

Требования 1.3.1

Прежде чем назначать рабочую нагрузку волне миграции, оцените технические, операционные и бизнес-требования, которые влияют на успех миграции в Решение Azure VMware. Эта оценка помогает определить пригодность платформы, определить потенциальные проблемы миграции и предоставить сведения, необходимые для определения размера, последовательности и готовности решений. При оценке каждой рабочей нагрузки сосредоточьтесь на:

  • Требования к производительности: Необходимо понимать требования к ЦП, памяти, IOPS хранилища и пропускной способности сети. Сопоставьте эти требования со SKU узлов Решение Azure VMware и политиками хранения vSAN, включая конфигурацию RAID и параметры допустимого числа отказов (FTT).

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

  • Требования к совместимости: Убедитесь, что гостевые операционные системы и стороннее программное обеспечение поддерживаются в Решение Azure VMware. Большинство рабочих нагрузок, выполняемых в локальной среде vSphere, работают в Решение Azure VMware без изменений, однако это следует проверять, а не принимать на веру, и обязательно протестировать свой подход к откату для проблемных миграций.

  • Требования к сети: Задокументируйте сегменты сети, IP-адреса, конфигурации DNS и правила брандмауэра для каждой рабочей нагрузки. Определите рабочие нагрузки с учетом задержки и убедитесь, что сетевая архитектура оптимизирована для поддержки своих требований.

Обработка рабочей нагрузки 1.3.2

Оценка рабочей нагрузки определяет потребности рабочей нагрузки. Обработка рабочей нагрузки определяет, какие действия следует предпринять. Лица, принимающие решения, должны оценить, следует ли размещать каждое приложение в Решение Azure VMware, должно ли оно оставаться в локальной инфраструктуре или целесообразнее ли перенести отдельные компоненты приложения на нативные службы Azure. Для каждой рабочей нагрузки определите:

  • Следует ли размещать там рабочую нагрузку. Рабочие нагрузки, которые уже хорошо работают в среде vSphere, — естественные кандидаты, особенно если их модернизация не планируется в ближайшее время. Если рабочая нагрузка планируется к выводу из эксплуатации или замене на SaaS-решение, оцените, даст ли её перенос дополнительную ценность или её следует оставить как есть до конца срока службы.

  • Должен ли каждый уровень быть там. Рабочая нагрузка часто имеет несколько уровней, таких как веб-интерфейс и база данных. Виртуальные машины приложения можно запускать на Решение Azure VMware и подключать их к службам данных Azure, таким как База данных SQL Azure. Эта конфигурация обеспечивает преимущества управляемой базы данных вместе с рабочими нагрузками VMware и снижает затраты на узел и лицензию VMware.

Готовность к миграции 1.4

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

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

  • Состояние репликации HCX

  • Маршрутизируемость сегмента NSX

  • Работоспособность узла ESXi

  • Доступность служб идентификации и аутентификации из целевого сегмента

  • Работоспособность вспомогательных служб, таких как резервное копирование и мониторинг

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

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

1.5 Последовательность миграции Решение Azure VMware

Последовательность миграции определяет, какие рабочие нагрузки будут перемещены в Решение Azure VMware первыми, вторыми и так далее. Хорошее планирование волн снижает риск и избегает ненужных нарушений.

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

  • Сопоставьте существующие правила: Задокументируйте все правила привязки или антипривязки из локальной среды и спланируйте, как их воспроизвести. Политики размещения Решение Azure VMware обеспечивают аффинность виртуальных машин к узлам, что важно для лицензионных ограничений, например для SQL Server, а также для строгих требований к производительности.

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

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

1.6 Средства миграции

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

Подход к миграции 1.6.1

VMotion перемещает запущенную рабочую нагрузку без простоя, а в поколении 2 она обычно выполняет быстрее, чем массовые методы. Миграция с репликацией и массовая миграция сегодня могут выполняться медленнее в среде Generation 2, поэтому закладывайте более длительные временные окна и планируйте волны миграции с учетом этого. Рекомендации по проектированию частного облака Решение Azure VMware поколения 2.

1.6.2 Управление сетевыми расширениями

Некоторые команды рассматривают расширение сети как постоянный дизайн. Это не так. Оставляйте расширения открытыми только на время миграции. Расширение сети HCX растягивает локальную сеть в Решение Azure VMware на уровне 2, что позволяет рабочим нагрузкам сохранять существующие адреса во время перемещения. Эта конструкция позволяет избежать перенастройки приложений заранее, и она ведет к компромиссам, которые должен управлять создатель решений.

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

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

Установка твердой политики. Расширяйте сеть, только если рабочая нагрузка не может изменить свой адрес, и удаляйте все расширения после переноса рабочих нагрузок. Сначала оцените локальную сеть, чтобы узнать, какие сегменты требуют расширения и как долго. Эта оценка лежит в основе как плана волн, так и графика расширения. Mobility Optimized Networking может уменьшить тромбонирование в некоторых случаях, поэтому перед включением проверьте поддерживаемые конфигурации. См. раздел "Настройка расширения сети HCX".

2. Подготовка к миграции

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

  1. Целевая среда платформы: Убедитесь, что все необходимые централизованные службы сети, идентификации, безопасности и мониторинга готовы к интеграции с рабочими нагрузками Azure VMware. Примените базовые показатели управления и безопасности с помощью Политика Azure к иерархии групп управления, которые помогут вам достичь требований соответствия требованиям. Поколение 2 развертывается в вашей виртуальной сети, поэтому базовый набор политик, предписывающий строгие правила для групп безопасности сети или таблиц маршрутизации, может блокировать развертывание. Удалите эти определенные политики из виртуальной сети частного облака перед развертыванием, а затем повторно примените их. Запланируйте это исключение в базовый план, чтобы управление не застопоряло развертывание.

  2. Зоны размещения рабочих нагрузок: Разместите зоны размещения рабочих нагрузок (подписки) в соответствующей группе управления — внешней или внутренней («Corp»).

  3. Диапазоны IP-адресов: Зарезервируйте минимальный блок адресов /22 для частного облака. Для Generation 2 также зарезервируйте два дополнительных блока /24 для управления HCX и аплинка. Убедитесь, что ни один из этих диапазонов не перекрывает локальное, Azure или другое облачное адресное пространство. Вы не можете легко исправить это условие после развертывания. См. рекомендации по проектированию поколения 2.

  4. Запрос квоты: Запросить квоту рано, так как выделение может занять до пяти рабочих дней. Запрашивайте достаточно ресурсов для роста и аварийного восстановления, например с резервированием по схеме N+1, то есть с одним дополнительным узлом сверх того, что требуется рабочей нагрузке. Подтвердите лицензию Portable VMware Cloud Foundation, требующую новых развертываний. См. Запрос квоты хоста.

  5. Развертывание частного облака Решение Azure VMware: Разверните частное облако поколения 2 в виртуальной сети Azure. См. статью "Создание частного облака поколения 2".

  6. Конфигурация сети и идентификационных данных: Настройте пиринг сети частного облака с вашим центральным узлом и подключение к локальной инфраструктуре. Подключите vCenter Server к внешнему источнику удостоверений, чтобы администраторы входили в систему с помощью управляемых учетных записей вместо общих встроенных учетных данных.

  7. Мониторинг и управление: Перенаправьте журналы в решение по управлению журналами и настройте оповещения о работоспособности служб. Подключите гостевые виртуальные машины через Azure Arc, чтобы управлять ими с помощью тех же инструментов Azure, которые вы используете в других средах.

  8. Установка HCX: Установите HCX и проверьте подключение типа "сеть — сеть" перед началом первой волны.

3. Выполнение миграции

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

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

  1. Каждая виртуальная машина в рамках этой волны работает в Решение Azure VMware и больше не зависит от сетевого расширения для производственного трафика.

  2. Каждое приложение доступно пользователям и зависимым системам.

  3. Каждая виртуальная машина отображается в средствах мониторинга без предупреждений или ошибок.

  4. Откат больше не нужен, и вы можете формально завершить его.

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

  6. Рабочие нагрузки соответствуют вашим требованиям к безопасности и соответствию требованиям.

  7. Рабочая нагрузка успешно подключена к решениям резервного копирования и аварийного восстановления.

4. Оценка миграции и вывод из эксплуатации

Миграция не заканчивается, когда рабочие нагрузки запускаются в Решение Azure VMware. Убедитесь, что рабочие нагрузки корректно функционируют в новой среде, что временные меры, принятые для миграции, устранены, и что исходная инфраструктура официально выведена из эксплуатации. Сохранение локальной инфраструктуры без изменений может привести к необнаруженным и недокументированным зависимостям. Дисциплинированный процесс оценки и вывода из эксплуатации гарантирует, что организация реализует ожидаемые преимущества миграции без ненужных операционных затрат или рисков.

4.1 Готовность к эксплуатации после переключения в продуктивную среду

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

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

Проверка подключения 4.2

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

Если вы создали дополнительный экземпляр Решение Azure VMware для аварийного восстановления, убедитесь, что он доступен как из основного экземпляра, так и от любых клиентов или вспомогательных служб, которые должны подключиться к нему, если он активирован.

4.3 Разложение сетевого расширения

Когда все рабочие нагрузки в расширенном сегменте будут перемещены, удалите расширение сети второго уровня (Layer 2) HCX и убедитесь, что собственный шлюз Решение Azure VMware правильно маршрутизирует трафик. Не оставляйте расширение на месте дольше, чем это необходимо для миграции.

4.4 Вывод из эксплуатации исходной среды

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

Дальнейшие действия

Проектирование рабочей нагрузки:

  • Last updated on