Рассказываем о том, как подготовиться к миграции на новую версию VMware NSX. В ближайшие несколько лет тема миграции коснется всех облачных провайдеров. Мы начали изучать этот вопрос на практике уже сейчас: реализовали несколько тестовых кейсов по миграции, набили шишек и получили бесценный опыт, которым делимся в этой статье.
Мигрировать придется всем
С января 2022 заканчивается выпуск обновлений NSX-V — Software defined network — аппаратно-программного комплекса, который позволяет создавать логические сети. Другими словами, это платформа виртуализации и обеспечения безопасности сетевых сервисов, решающая задачи маршрутизации, коммутации, балансировки нагрузки и файрвола. Развитие этой версии продукта прекращается в январе, но техподдержка будет работать до 2023 года — после этого времени продукт официально умрет.
Сейчас продукты обновляются ежемесячно, а вендор представил VMware NSX-T Data Center — новое видение продукта. Он полностью изменился, начиная с его идеологии. Чтобы помочь пользователям переходить на новую версию вендор решения VMWare выпустил специальную утилиту для миграции: VMware NSX® Migration for VMware Cloud DirectorTM tool.
У нее тоже есть разные версии с разными возможностями. К сожалению, она не позволяет автоматически взять и провести миграцию существующих клиентов — сначала нужно провести оценку возможности миграции решения клиента. Однако, утилита развивается и возможностей у нее и пользователей появляется все больше. Последняя версия, доступная на сегодня — 1.3.
NSX-V vs. NSX-T: рассказываем про отличия
NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур. Решение NSX-V было разработано специально для виртуальной среды VMware vSphere и использует виртуальные коммутаторы vSphere Distributed Switch (vDS). Оба продукта можно использовать под одной лицензией.
NSX-T использует протокол GENEVE для передачи фреймов по виртуальным сетям. Архитектура NSX-T значительно отличается от предшествующего решения NSX-V.
Начиная с версии 10.1, в vCD появилась возможность одновременно подключать кластеры с разными NSX, это стало первым рубежом, когда можно было начинать думать о какой-то миграции всерьез. Для этого нам пришлось строить совсем отдельную площадку под NSX-T и сводить всё в одну систему.
Преимущества 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.
Мы протестировали работу этой утилиты: подготовили тестовую среду и провели пробную миграцию. Она состояла из следующих этапов:
Оценки.
Анализа инфраструктуры клиента и приведение ее в соответствии с требованиями к миграции на NSX-T.
Описания инфраструктуры клиента для миграции в YAML- файле.
Pre-check, topology, bridging.
Services.
Movevapp.
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 не должна иметь снепшотов или примонтированных образов
На выходе получаем одно из трех возможных состояний миграции:
Can be migrated — этот процесс не требует каких-либо дополнительных настроек. Организация может быть мигрирована.
Can be migrated with additional preparation work. Данный этап требует внесения дополнительных настроек, о которых можно узнать как из самого файла с детализацией по столбцам, так и выполнив precheck по организации посредством утилиты (подробнее расскажем об этом в четвертом этапе).
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 выходят очень быстро, и пока хороших понятных руководств по миграции нет. Документация пишется параллельно с апгрейдом ПО, приходится идти методом проб и ошибок. Поэтому создание полных и качественных гайдов — не быстрый процесс, так как приходится проверять каждый шаг.
В ближайшее время будем пробовать мигрировать что-то приближенное к реальным условиям и тестировать новейшие апдейты. Не переключайтесь, в следующей нашей статье мы поделимся опытом продуктивной миграции.
