Готовимся к облачной миграции на NSX-T: чек-лист и лайфхаки

2c32450d2b7f5779fc967087f6851bf3.jpg

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

Мигрировать придется всем

 С января 2022 заканчивается выпуск обновлений NSX-V — Software defined network — аппаратно-программного комплекса, который позволяет создавать логические сети. Другими словами, это платформа виртуализации и обеспечения безопасности сетевых сервисов, решающая задачи маршрутизации, коммутации, балансировки нагрузки и файрвола. Развитие этой версии продукта прекращается в январе, но техподдержка будет работать до 2023 года — после этого времени продукт официально умрет.

Сейчас продукты обновляются ежемесячно, а вендор представил VMware NSX-T Data Center — новое видение продукта. Он полностью изменился, начиная с его идеологии. Чтобы помочь пользователям переходить на новую версию вендор решения VMWare выпустил специальную утилиту для миграции: VMware NSX® Migration for VMware Cloud DirectorTM tool.

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

 NSX-V vs. NSX-T: рассказываем про отличия

NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур. Решение NSX-V было разработано специально для виртуальной среды VMware vSphere и использует виртуальные коммутаторы vSphere Distributed Switch (vDS). Оба продукта можно использовать под одной лицензией.

 NSX-T использует протокол GENEVE для передачи фреймов по виртуальным сетям. Архитектура NSX-T значительно отличается от предшествующего решения NSX-V.

Сравнение версий NSXСравнение версий NSX

 Преимущества NSX-T:

  • Экономичное горизонтальное масштабирование сети.

  • Лучшая в своем классе система безопасности, встроенная в инфраструктуру.

  • Полный стек сетевых служб для современных распределенных приложений.

  • Автоматизация сети и системы безопасности.

Как тестировали переезд на NSX-T

Тестируемая инфраструктура, содержала в себе следующие компоненты:

  • VMware ESXi, 7.0.1 — последний апдейт аппаратного гипервизора. За счет консолидации нескольких серверов на меньшем числе физических устройств VMware ESXi, 7.0.1 помогает высвободить пространство, снизить энергопотребление и оптимизировать ИТ-администрирование, а также значительно повысить производительность.

  • vSphere Client version 7.0.2 — платформа для виртуализации и масштабирования ЦОД, версия 6.7.

  •   NSX-V Manager 6.4.10 и VMware NSX-T Version 3.1.0 — АПК для создания логических сетей. Последний апдейт NSX-T — версия 3.1.

  • VMware Cloud Director version: 10.2.2 — это облачная платформа, которая позволяет поставщикам облачных услуг преобразовывать физические центры обработки данных в высокоэластичные виртуальные ЦОДы (VDC). Созданный на основе базовых вычислительных и сетевых платформ, которые виртуализируют физическую инфраструктуру, VMware Cloud Director имеет глубокую интеграцию с центром обработки данных NSX.

Мы протестировали работу этой утилиты: подготовили тестовую среду и провели пробную миграцию. Она состояла из следующих этапов:

  1. Оценки.

  2. Анализа инфраструктуры клиента и приведение ее в соответствии с требованиями к миграции на NSX-T.

  3. Описания инфраструктуры клиента для миграции в YAML- файле.

  4. Pre-check, topology, bridging.

  5. Services.

  6. Movevapp.

  7. Cleanup.

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

 Давайте подробнее рассмотрим каждый из этапов.

Оценка

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

Здесь могут быть сложности, связанные с тем, что в текущих версиях утилиты, Cloud Director и NSX-T не поддерживаются следующие опции:

  • Миграция строго в рамках одного vCenter Server

  • Не поддерживаются общие (shared) или cross-VDC сети

  • Не поддерживаются сети routed vApp и independent disks

  • Не поддерживается SSL VPN (Plus), L2 VPN, route-based IPSec

  • Мигрируемая VM не должна иметь снепшотов или примонтированных образов

    На выходе получаем одно из трех возможных состояний миграции:

    1. Can be migrated — этот процесс не требует каких-либо дополнительных настроек. Организация может быть мигрирована.

    2. Can be migrated with additional preparation work. Данный этап требует внесения дополнительных настроек, о которых можно узнать как из самого файла с детализацией по столбцам, так и выполнив precheck по организации посредством утилиты (подробнее расскажем об этом в четвертом этапе).

    3. Automated migration not supported with the current version. В этом состоянии миграция организации посредством утилиты невозможна. Необходимо понять в чем причина можно выполнив PreCheck по организации.

Анализ инфраструктуры клиента и приведение ее в соответствии с требованиями к миграции на NSX-T

Проверяем количество сетей у клиента. Количество edge node в NSX-T должно быть равно количеству сетей клиента, так как каждая сеть подключается к своей edge node для организации bridge

Описание инфраструктуры клиента для миграции в YAML-файле

Для миграции клиента необходимо описать ряд параметров, при этом важно обратить внимание на следующие:

ImportedNeworkTransportZone: TZ-VLAN-HOST — тут создана отдельная TZ которая применена только к хостам. Ее нет на edge node. Сделано для того, что бы трафик VLAN не шел через edge node, а напрямую через свитч на хосты.

DummyExternalNetwork: V-to-T-dummy — сеть-заглушка созданная заранее. Используется во время переключения внешней сети.

ExternalNetwork: T0–01-AA-CL01-Internet — интернет, подаваемый через NSX-T.

EdgeClusterName: # List of dedicated NSX-T Edge Clusters to be used for bridging- CLtmp-bridge_1_uplink — edge cluster, через который будут настроены bridges.

 Подробную структуру YAML-файла с описанием всех конфигураций не приводим — в каждом случае она будет у всех своя, а примеры можно найти на сайте VMWare.

 Pre-check, topology, bridging

 На этом этапе проводится проверка и создание инфраструктуры клиента с NSX-T для последующей миграции. В организации клиента создается копия oVDC c суффиксом v2t под управлением NSX-T. Создаются все объекты мигрируемого VDC.

 Сети уже создаются в NSX-T, но на этом этапе не подключаются никуда. Этот этап никак не влияет на мигрируемые VDC.

На этом этапе создается связность между сетями в старом oVDC и сетями в новом VDC. Так же не влияет на работу старого VDC.

 Services

Доступен с версии NSX-T 2.4, улучшения в каждом релизе.

Это основной этап, который несет за собой сетевую недоступность. На данном этапе идет переключение шлюзов с NSX-V на NSX-T и подключение сегментов созданных в NSX-T к T1, а T1 к T0. После данного этапа весь трафик наружу будет идти через BGP NSX-T. Соответственно наружу будет анонсится белая сеть клиента, которая раньше была на edge NSX-V. Также в этот момент переносятся все правила FW, NAT и так далее на T1.

 Важно заметить, что если у клиента есть LB, он будет перенесен на AVI. Соответственно AVI SE Group контроллеры и NSX-T cloud должны быть заранее заведены в облако. Так же небольшой лайфхак: можно в AVI заранее создать какой-то сервис, чтобы развернулись SE, а потом его удалить. В этом случае при миграции LB клиента облако не будет ждать пока развернутся SE.

 Movevapp

На данном этапе все виртуальные машины клиента переезжают в новый кластер, в новые ресурс пулы.

 Cleanup

Если все переехало нормально, клиент проверил все сервисы и подтвердил работоспособность, то выполняется cleanup. В данном случае команда удалит старую инфраструктуру на NSX-V и переименует новую на NSX-T, убрав суффикс v2t из названий.

Резюме

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

В ближайшее время будем пробовать мигрировать что-то приближенное к реальным условиям и тестировать новейшие апдейты. Не переключайтесь, в следующей нашей статье мы поделимся опытом продуктивной миграции.

© Habrahabr.ru