VMware NSX-T: что такое и как работает

Развертывание физических сетей ЦОД сопряжено с некоторыми проблемами: нужно подготовить и настроить маршрутизаторы, коммутаторы, сеть, брандмауэры, балансировщики нагрузки, списки управления доступом и прочее. Все это занимает немало времени.

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

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

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

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

Именно здесь возникает потребность в VMware NSX — платформе виртуализации и обеспечения безопасности сетевых сервисов. Она решает задачи маршрутизации, коммутации, балансировки нагрузки, построения виртуальных сетей любой топологии, их быстрого развертывания и управления. Решение позволяет управлять несколькими гипервизорами, и не только ESXi, — есть распределенная маршрутизация и файрволл на ESXi и KVM.

Точно так же, как VMware ESXi позволяет виртуализировать компьютерную инфраструктуру, NSX позволяет виртуализировать сеть.

Подробнее об VMware ESXi читайте по ссылке

Схема NSX

Некоторое время назад VMware NSX существовал в двух версиях продукта: VMware NSX-V и VMware NSX-T.

VMware NSX-T (NSX-Transformers) — это часть VMware NSX, решение для различных платформ виртуализации. Разработано для различных платформ виртуализации и сред с несколькими гипервизорами. У NSX-T независимая консоль управления, не требующая vCenter.

VMware NSX-T — это современная версия VMware NSX Data Center.

Основные отличия NSX-T от NSX-V

В целом, NSX-V и NSX-T — это один продукт с разных сторон. VMware NSX-V изначально разработано для локальных сред, а VMware NSX-T — для облачных. Даже разворачиваются они почти идентично:

  • NSX Manager разворачивается как виртуальная машина на хосте гипервизора.
  • Разворачиваются контроллеры NSX, создается кластер контроллеров NSX.
  • Устанавливаются модули ядра на хостах ESXi, чтобы включить распределенный брандмауэр, распределенную маршрутизацию.
  • Устанавливается NSX Edge как виртуальная машины на гипервизоре (или физическом сервере).
  • И так далее.

Общие возможности NSX-v и NSX-T — это, например, программная виртуализация сети, распределенная маршрутизация, распределенный брандмауэр, автоматизация, управляемая API, подробный мониторинг и статистика.

Продукты почти идентичны, но один продукт — современный, а другой — устаревший, поэтому несколько существенных отличий все же есть. Основное в том, что NSX-V, или NSX-vSphere, как следует из названия, разработана под виртуальную среду VMware. В качестве гипервизора поддерживает только VMware ESXi, требует обязательного развертывания vCenter, использует в качестве коммутатора vSphere Distributed Switch.

NSX-T — решение более гибкое. Поддерживает несколько гипервизоров, в том числе KVM, а также OpenStack, Kubernetes, Docker, AWS. Для использования контейнеров дополнительно разворачивается плагин NSX Container plugin (NCP). Он обеспечивает интеграцию между NSX-T и контейнерными оркестраторами, например, Kubernetes, а также интеграцию между NSX-T и OpenShift и Pivotal Cloud Foundry.

При этом VMware NSX-T можно развернуть вообще без vCenter Server.

Несколько других отличий:

  • Отличаются API-интерфейсы.
  • NSX-V использует протокол VXLAN, а NSX-T — GENEVE.
  • NSX-V поддерживает режим одноадресной рассылки, многоадресной рассылки и гибридный режим. NSX-T поддерживает одноадресный режим с двумя вариантами: иерархическая двухуровневая репликация (как для NSX-V) и головная репликация (не оптимизированная).
  • Поскольку VMware отключила NSX-T от vCenter Server, то у NSX-T теперь N-VDS вместо VDS. В NSX-V это решение не поддерживается.
  • NSX-V для vSphere использует DLR (распределенный логический маршрутизатор, logical router) и централизованную маршрутизацию. NSX-T использует двухуровневую модель распределенной маршрутизации.
  • При настройке NSX-V необходимо составить план IP-адресации внутри сегментов NSX, в то время как NSX-T этого не требует.
  • Все сегменты сети между уровнями 0 и 1 получают IP-адреса автоматически, протоколы динамической маршрутизации не используются — применяются статические маршруты.

Краткая таблица различий функционала решений.

NSX-VNSX-T
Тесная интеграция с vSphereданет
Работа без vCenterнетнет
Поддержка нескольких экземпляров vCenter с помощью NSX Managerнетда
Обеспечивает виртуальную сеть для следующих платформ виртуализацииVMware vSphereVMware vSphere, KVM, Docker, Kubernetes, OpenStack
Развертывание NSX EdgeESXi VMВиртуальная машина ESXi или физический сервер
Протоколы оверлейной инкапсуляцииVXLANGENEVE
Используемые виртуальные коммутаторы (N-VDS)Распределенный коммутатор vSphere (VDS)Откройте vSwitch (OVS) или VDS
Режимы репликации логического переключателяОдноадресная, многоадресная, гибриднаяОдноадресная передача (двухуровневая или головная)
Подавление ARPда да
Двухуровневая распределенная маршрутизациянетда
Настройка схемы IP-адресации для сегментов сетиРуководство пользователяАвтоматический (между уровнями 0 и 1)
Интеграция для проверки трафикаданет
Распределенный брандмауэр на уровне ядрадада

С января 2022 года выпуск обновлений NSX-V заканчивается. Техподдержка будет работать до 2023 года, а после продукт официально закончит существование.

Облако на базе VMware

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

Архитектура NSX-T Data Center

Архитектуру NSX-T можно разделить на три части:

  • архитектура управления,
  • физическую,
  • логическую.

Начнем с первой.

Архитектура управления NSX-T

NSX-T управляется с помощью:

  • Management Plane,
  • Control Plane,
  • Data Plane.

Management Plane

Это единая точка входа для запросов пользователей и управления NSX-T. Работает так:

  • Пользователь через REST API или пользовательский интерфейс взаимодействует с NSX-T.
  • Management Plane (MP) обрабатывает API-запросы, передает запросы в Control Plane.
  • Management Plane в БД хранит пользовательскую конфигурацию, заданную пользователем.
  • Окончательный вариант конфигурации системы передается с помощью NSX-T Manager в Control Plane, чтобы стать действующей конфигурацией в Data Plane.

MP обеспечивает повсеместное подключение, безопасность и видимость, посредством управления объектами и сбора информации о них. Поддерживает несколько вычислительных доменов – до 16 vCenters, контейнерных оркестраторов TAS/TKGI, OpenShift и облаков AWS или Azure.

Management Plane в NSX-T реализован за счет NSX-T Manager. Отказоустойчивость обеспечивает NSX Manager Cluster.

Control Plane

Control Plane (CP) получает от Management Plane конфигурацию и запросы, которые в структурированном виде передает для исполнения на Data Plane. Control Plane разделен на Central Control Plane (CCP) и Local Control Plane (LCP).

Control Plane

Такое разделению позволяет платформе расширяться и масштабироваться:

  • CCP реализован на NSX Manager в виде кластера виртуальных машин, называемых узлами CCP, а LCP расположен на гипервизорах и Edge-
  • LCP получает от CCP конфигурацию для гипервизора и передает команду Data Plane о том, что делать.
  • Это означает, что любой сбой в управлении не влияет на существующие операции в Data Plane, потому что CCP логически отделен от трафика Data Plane.
  • У каждого NSX Manager в Management Cluster есть CCP Conroller. Контроллеры работают совместно и разделяют управление транспортными нодами и типы конфигурации этих нод. При отключении одного из NSX Manager другие участники кластера распределят управление транспортными нодами.
Схема управления транспортными нодами

Data Plane

Расположен на транспортных нодах — хостах, на которых запущены локальные демоны Control Plane и механизмы пересылки, реализующие Data Plane NSX-T. Работа Data Plane включает в себя следующие задачи:

  • обрабатывать сетевые пакеты: фреймы, заголовки, данные в них, инструкции, которые передает Local Control Plane;
  • пересылать/преобразовывать пакеты на основе таблиц, заполненных Control Plane;
  • сообщать информацию о топологии в CP и собирать статистику на уровне пакетов.
Data Plane

Подытожим, как работают эти компоненты в связке:

  • CCP получает конфиги от Management Plane и формирует их в машинное представление.
  • Через Appliance Proxy Hub и по протоколу NSX-RPC отправляет на транспортные ноды по сети.
  • NSX-Proxy передает все это на Lосаl Control Plane.
  • LCP — это «филиал» Control Plane на транспортных нодах: записывает поступившую информацию в БД NestedDB. Это временное хранилище информации для Data Plane, после перезагрузки хоста оно пустеет.

Чтобы все это заработало, нам нужен управляемый виртуальный коммутатор.

Физическая архитектура VMware NSX-T

У NSX-T есть N-VDS (NSX Virtual Distributed Switch) — виртуальный распределенный коммутатор. Это программный компонент NSX, который создается с транспортной зоной, а затем транспортная зона применяется к транспортному узлу.

Коммутаторы N-VDS разных транспортных узлов независимы, но их можно сгруппировать.

На гипервизорах ESXi для реализации N-VDS нужен распределенный коммутатор VMware vSphere — реализуется через модуль NSX-vSwitch, который загружается в ядро гипервизора. На гипервизорах KVM реализован модулем Open-vSwitch (OVS).

Для N-VDS требуется выделенный сетевой адаптер в vSphere 6.7

Transport Nodes

Транспортные ноды, как и виртуальные коммутаторы, — это компоненты передачи данных NSX. В NSX-T это гипервизоры и Edge Nodes.

  • Hypervisor Transport Nodes — транспортные узлы гипервизоров (поддерживаются VMware ESXi и KVM). NSX-T предоставляет сетевые услуги виртуальным машинам на этих гипервизорах. Гипервизоры, соответственно, подготовлены и сконфигурированы для NSX-T.
  • Edge Nodes — это сервисные устройства, которые предназначены для запуска централизованных сетевых служб. Могут представлять из себя как железные серверы, так и виртуальные машины. Edge Nodes можно группировать в кластеры как пул мощностей, которые могут использовать службы. Они не распределяются между гипервизорами.

Функционал транспортных нод заключается в двух вещах:

  • Распределенная маршрутизация: каждому хосту — по роутеру.
  • Распределенный брандмауэр: каждой виртуальной машине — по файрволлу.

Транспортные ноды образуют транспортные зоны, которые определяют границы распространения логических сетей (в них и существует виртуальная сеть). Зоны определяют, как виртуальные машины на хосте могут взаимодействовать друг с другом, и используются для разделения сред разработки и тестирования. Участники внутри транспортной зоны могут взаимодействовать друг с другом по умолчанию, поэтому транспортная зона — это просто набор логических сегментов. Есть два типа транспортных зон: Overlay и VLAN.

Транспортные ноды — это часть физической архитектуры NSX-T, к которой относят три компонента.

  • NSX Manager,
  • Transport Node,.
  • Edge Nodes

Про транспортные ноды уже рассказали, теперь перейдем к Edge Nodes.

Edge Nodes

Это тоже транспортные ноды, как ESXi или KVM-хост, но немного другие. На Edge Nodes не исполняются виртуальные машины, это ресурс для различных сетевых сервисов. В Edge происходят все вычисления, связанные со следующими сервисами:

  • балансировщики нагрузки,
  • пограничный брандмауэр,
  • маршрутизация пограничного трафика,
  • SNAT/DNAT,
  • Reflexive NAT,
  • DHCP Server/Relay,
  • L2 VPN,
  • IPSec VPN,
  • DNS Relay.

Edge — это вычислительный «хаб», через который сетевой трафик попадает в виртуальную сеть или выходит из нее, попадая в реальный мир.

NSX Edge можно развернуть как виртуально, так и как физический сервер. Также его можно собрать в кластер по 10 штук, чтобы повысить отказоустойчивость и увеличить пропускную способность.

NSX Manager

NSX Manager — это централизованный компонент NSX, который используется для управления сетями. Это консоль управления NSX, с которой взаимодействует пользователь через веб-интерфейс, CLI или API.

Устройство NSX Manager имеет встроенные роли Policy, Manager и Controller. Они отличаются. Например, в роль NSX Controller входит обеспечение функциональности плоскости управления: логическая коммутация, маршрутизация и распределенный межсетевой экран или распространение информации о топологии, сообщаемой элементами плоскости данных. А Policy позволяет пользователям вводить нужную конфигурацию в интерфейсе NSX или указывать конечное желаемое состояние системы.

Интерфейс NSX Manager работает в двух режимах – Policy/Manager.

  • О Management Plane, который базируется на NSX Manager, мы уже говорили. MP получает конфигурацию от пользователя и определяет, что нужно делать, чтобы их достичь, передавая конфиги в Control Plane.
  • Policy Plane — центральный интерфейс, который принимает от пользователя простые запросы, но не определяет, что делать для их достижения. Этот режим более простой для администратора и содержит немного больше функций.

Фактически это две сущности одного и того же — они предоставляют конечному пользователю интерфейс для взаимодействия и «понимают», что он хочет.

С установки NSX Manager и начинается процесс развертывания NSX в инфраструктуре. Manager может быть развернут только в виде виртуальной машины, причем как на ESXi-хосте, так и на KVM.

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

У Control Plane на каждой ноде свой набор транспортных нод, которые он обслуживает: в пределах кластера CP работает распределенно. У каждого NSX Manager есть база данных, которая реплицируется между участниками кластера.

Для кластера используется виртуальный IP (VIP). Это адрес кластера, на него отвечает активная нода. Она перенаправляет запросы модулям на других нодах. При падении текущей ноды активной становиться другая, и работа продолжается. Виртуальный IP рекомендуется, если все участники кластера расположены в одной подсети.

Виртуальный IP для кластера

Логическая архитектура NSX-T

Большинство объектов в NSX-T — логические. Например, сегменты, логические свичи, Tier1 и Tier0 маршрутизаторы/логические роутеры, балансировщики нагрузки, распределенные брандмауэры и другие объекты. В этом тексте подробно останавливаться на разборе логической архитектуры мы не будем. Это тема для отдельной обширной статьи, посвященной функционалу продукта.

Что мы узнали о платформе виртуализации NSX-T

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

  • Масштабируемая сеть.
  • Разнообразные стек современных приложений, включая «контейнерные».
  • Лучшая в своем классе безопасность, использующая ИИ, который помогает заранее обнаруживать и предотвращать кибератаки.
  • Надежный интерфейс, управляемый API, который помогает упростить сетевую автоматизацию.
  • Интуитивно понятная панель управления и возможности мониторинга.

Эта реализация не ограничивается рамками VMware vSphere, говоря про NSX-V. Сама компания VMware помогает заказчикам с нуля устанавливать VMware NSX-T даже в средах VMware vSphere. Также существует документация по процессу миграции с платформы VMware NSX-V на NSX-T.

Что еще почитать по теме

Каким должен быть Feature Store, чтобы оптимизировать работу с ML-моделями

В статье рассказываем о том, что нужно бизнесу от Feature Store сегодня, и разбираем архитектуру open source-платформы Feast.
Андрей Салита 30 ноября 2022

Отличия PowerShell от CMD: что использовать в работе

Рассказали о ключевых отличиях между интерпретаторами командной строки в Windows.
Андрей Салита 30 ноября 2022
T-Rex 23 ноября 2022

Как работает СУБД Redis

Рассказываем, что такое Redis: рассматриваем его применение и преимущества, поддерживаемые типы данных.
T-Rex 23 ноября 2022

Новое в блоге

Михаил Фомин 24 июня 2022

Docker Swarm VS Kubernetes — как бизнес выбирает оркестраторы

Рассказываем, для каких задач бизнесу больше подойдет Docker Swarm, а когда следует выбрать Kubernetes.
Михаил Фомин 24 июня 2022
Ульяна Малышева 8 декабря 2022

Продуктовый дайджест: предзаказ серверов на ARM и миграция с комфортом

Рассказываем об актуальных продуктовых новостях за ноябрь.
Ульяна Малышева 8 декабря 2022

Как создать Minecraft на Python? Обзор библиотеки Ursina Engine

В статье делимся основами работы с библиотекой Ursina Engine и показываем, как с помощью нее создать мир из кубов.