Установка и настройка NSX-T

Основные этапы установки NSX в среде vSphere: развертывание виртуальных машин NSX Manager, преобразование хостов ESXi в транспортные узлы хостов и развертывание виртуальных машин NSX Edge.

Шаг 1. Развертывание NSX Managers

NSX Manager — это приложение, которое используется для администрирования среды NSX. В производственной среде для обеспечения отказоустойчивости следует развернуть кластер из трех узлов NSX Manager, каждый из которых работает на отдельном хосте ESXi.

Информация

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

Развертывание первого NSX Manager

Первый узел менеджера развертывается с помощью мастера развертывания шаблона OVF в vCenter.

В vCenter щелкните правой кнопкой мыши на кластер и выберите «Развернуть шаблон OVF».
Следуйте инструкциям и предоставьте следующую информацию

Option	Comment
Location of the ova file	Место, куда вы загрузили файл ova.
Virtual machine name	DEV-NSX-MGR-01
Location for the VM	Hardware Lab Cluster
Compute resource	SystemPool
Deployment configuration	Выберите размер, который вы определили на этапе подготовки.
Storage	Lab-vSAN
Virtual disk format	Thin Provision
Network 1	Lab-Management (порт группа управления)
IP allocation	Static Manual
IP protocol	IPv4
Hostname	dev-nsx-mgr-01
Rolename	NSX Manager
NSX Site Name	Site-1
Default IPv4 Gateway	172.16.80.1
Management Network IPv4 Address	172.16.80.101
Management Network Netmask	255.255.255.0
DNS Server list	172.16.80.251
NTP Server list	172.16.80.251

Дождитесь завершения развертывания. На панели «Недавние задачи» в нижней части окна клиента vSphere будет указано, когда задача будет завершена.
Включите виртуальную машину NSX Manager.
Войдите в DEV-NSX-MGR-01 по адресу https://172.16.80.101.
Перейдите в System > Licenses и нажмите Add, чтобы добавить лицензию NSX.
Перейдите в System > Fabric > Compute Managers и нажмите Add, чтобы добавить vCenter в качестве Compute Managers.

Развертывание 2 и 3 NSX Managers

В NSX Manager откройте System > Appliances.
Нажмите Add NSX Appliance.
Следуйте подсказкам и установите поочерёдно дополнительные узлы NSX Manager.

Настройка виртуального IP-адреса для кластера

Чтобы обеспечить отказоустойчивость и высокую доступность узлов NSX Manager, назначьте виртуальный IP-адрес (VIP) кластеру NSX.

Узлы кластера NSX Manager становятся частью группы HTTPS для обслуживания запросов API и пользовательского интерфейса. Лидерный узел кластера принимает на себя владение установленным VIP-адресом кластера для обслуживания любого запроса API и пользовательского интерфейса. Любой запрос API и пользовательского интерфейса, поступающий от клиентов, направляется на ведущий узел.

Информация

При назначении виртуального IP-адреса все виртуальные машины NSX Manager в кластере должны быть настроены в одной подсети. Но если для настройки VIP кластера используется внешний балансировщик нагрузки, то NSX Manager и VIP могут принадлежать к разным подсетям.

Если узел-лидер, которому принадлежит VIP, становится недоступным, NSX выбирает нового лидера. Новый лидер владеет VIP. Он отправляет пакет ARP, объявляющий о сопоставлении нового VIP-адреса с MAC-адресом. После выбора нового ведущего узла ему отправляются новые запросы API и пользовательского интерфейса.

Переключение VIP на новый ведущий узел кластера может занять несколько минут, прежде чем он станет работоспособным. Если VIP переключится на новый ведущий узел из-за того, что предыдущий ведущий узел стал недоступен, повторно аутентифицируйте учетные данные NSX Manager, чтобы запросы API направлялись на новый ведущий узел.

Важно!

VIP не предназначен для использования в качестве балансировщика нагрузки, и вы не сможете использовать его, если включите интеграцию внешнего балансировщика нагрузки vIDM в разделе «Система» > «Пользователи» > «Конфигурация». Не настраивайте VIP, если вы хотите использовать внешний балансировщик нагрузки от vIDM.

Войдите в систему NSX Manager с правами администратора по адресу https://<nsx-manager-ip-address> или https://<nsx-manager-fqdn>
Откройте System > Appliances.
В поле Virtual IP нажмите SET VIRTUAL IP.
Введите адрес IPv4 и/или IPv6, который будет использоваться в качестве VIP для кластера.

Убедитесь, что VIP входит в ту же подсеть, что и другие узлы управления. При развертывании NSX Manager в среде с двойным стеком (IPv4 и IPv6) используйте действительный адрес полного доменного имени и один и тот же адрес полного доменного имени для адресов IPv4 и IPv6.

Нажмите Save.
Чтобы проверить состояние кластера и лидера API группы HTTPS, введите команду get cluster status verbose в командной строке NSX Manager или через SSH.

dev-nsx-mgr-01> get cluster status verbose
Mon Mar 18 2024 UTC 12:20:19.844
Cluster Id: 3b22f69e-5b7a-433c-acbd-322f6c1d960d
Overall Status: STABLE

Group Type: HTTPS
Group Status: STABLE

Members:
    UUID                                       FQDN                                       IP               STATUS
    a3b52542-733e-3f0b-101f-9a85727e601d       dev-nsx-mgr-01.stormdev.lan                172.16.80.101    UP
    c1c7ef3b-1c0e-41cf-a559-1b2497284b61       dev-nsx-mgr-02.stormdev.lan                172.16.80.102    UP
    9ba0d9b9-a692-460b-b7fe-4e460cc7753b       dev-nsx-mgr-03.stormdev.lan                172.16.80.103    UP

Leaders:
    SERVICE                                    LEADER                                     LEASE VERSION
    api                                        a3b52542-733e-3f0b-101f-9a85727e601d       24108

Убедитесь, что VIP работает правильно.

В браузере войдите в NSX Manager, используя виртуальный IP-адрес, назначенный кластеру по адресу https://<VIP-адрес>.

Шаг 2. Настройка VDS

Вы можете использовать существующий VDS (Virtual Distributed Switch) или настроить новый. Если вы используете существующий VDS, вам необходимо установить его MTU равным 1600 или выше.

Информация

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

Измените значение MTU для VDS

В vCenter в разделе Networking щелкните правой кнопкой мыши VDS и выберите Settings > Edit Settings.
В поле MTU (байты) введите 1600 или более.

Uplink Profile

Чтобы хост был частью NSX, на нем должны быть установлены модули NSX.
После установки хост называется транспортным узлом.

Uplink Profiles - определяют как N-VDS/VDS будут подключены к физическим сетевым интерфейсам хоста или интерфейсам Edge. При добавлении транспортной ноды к NSX и соответственно к TZ, Uplink Profile назначается для каждого виртуального коммутатора NSX. Настраивается в System > Fabric > Profiles > Uplink Profiles.

Имя профиля
Teaming Policy – определяет сколько аплинков active, а сколько standby, как они будут называться, а так же алгоритм балансировки. Почти то же самое что и настройка teaming policy на виртуальном коммутаторе в vSphere. Учтите, что количество активных аплинков напрямую влияет на количество создаваемых на виртуальном коммутаторе TEP интерфейсов. Считается один к одному, то есть два активных аплинка равно два TEP интерфейса.
Указываем VLAN для Overlay трафика. Это трафик между TEP интерфейсами. Для него резервируют отдельный VLAN и адресацию. Ну и MTU. Эта настройка задает MTU для N-VDS/VDS на который назначается профиль. Если не трогать это поле, то MTU будет по умолчанию 1600. Как мы говорили выше это значение необходимо для Overlay трафика и вообще полноценного функционирования NSX-T.

Хочу обратить внимание на настройку Transport VLAN в профилях по умолчанию везде указан 0 VLAN, а значит трафик Overlay c хоста не будет тегирован при применении этого профиля. Это сгодится для профиля Edge (потому что они в большинстве случаев представлены в качестве VM), но для физической транспортной ноды не пойдёт, потому как для транспорта Geneve выделяют конкретный VLAN. Поэтому рекомендуется создавать свои собственные Uplink Profiles и указывать в них нужный нам VLAN.

Создаём профиль для транспортных нод:

Важно!

When you’re using a DVS for your NSX-T overlay transport zone, you have to think about where your edges will be connected to the overlay network. If the edge is attached to a distributed port group created on the same DVS in the same VLAN, it doesn’t work. So when you’re using and N-VDS or VDS for NSX-T and you’re placing an Edge on the same switch you have to put the Edge overlay in a different subnet. The Geneve traffic that originates from the Edge is not allowed to pass a switch that’s hosting a tunnel endpoint for ESXi (VMK10).

https://knowledge.broadcom.com/external/article/317168/nsxt-edge-tep-networking-options.html

А так же следуем NSX Design Guide

Транспортные Зоны

После того как мы развернули NSX Manager нам нужно создать транспортные зоны (TZ). транспортная зона — это набор транспортных нод, которые могут общаться друг с другом по сети через TEP интерфейсы и образовывать между собой виртуальную L2 сеть. TZ определяет какой набор транспортных нод будет «видеть» виртуальные L2 сегменты. Если объяснить более детально, то в NSX-T есть Segments – это виртуальные L2 домены, которые по сути являются порт-группами на виртуальном коммутаторе. Так вот, если ESXi (Транспортная Нода) не состоит в транспортной зоне, в которой создан определенный сегмент NSX, то соответствующая порт-группа будет недоступна для этого хоста и соответственно виртуальные машины, подключенные к этой порт-группе (Сегменту NSX) не смогут переехать на этот хост. TZ определяет физические границы для L2 сегментов NSX. Маршрутизация между сегментами работать будет.

Транспортные зоны бывают двух типов:

Overlay TZ. Используется для внутренних коммуникаций виртуальных машин в пределах виртуальной сети. При этом пакеты VM, покидая транспортную ноду инкапсулируются Geneve заголовком (отсюда и требования в 1600 MTU), а по прибытию на другую транспортную ноду заголовок снимается и пакет доставляется по назначению.

VLAN TZ. Такая транспортная зона используется в качестве канала в физический мир и основана на обычном тегировании пакетов меткой 802.1Q. К ней добавляются «эджи» что бы иметь коннект до физических роутеров. А также для работы смигрированных vmk интерфейсов хоста на N-VDS. Если сказать коротко, то трафик в VLAN TZ не инкапсулируются Geneve и используют для сегментации VLAN-ы. VLAN сегменты могут быть подключены к логическим маршрутизаторам NSX-T для того что бы пользоваться какими-либо сервисами на них (Load Balancing, маршрутизация, NAT, VPN и так далее). Но вот распределенная маршрутизация для VLAN сегментов будет недоступна.

Как правило для простой инфраструктуры или для тестовой среды создаются две TZ – одна VLAN – для связи Edge с физическим роутером, и вторая Overlay – для внутреннего взаимодействия. Так же присутствуют заранее созданные TZ, так называемые Default Zones.

Transport Nodes Profiles

Профиль Транспортной Ноды - это сгруппированная куча настроек, которые применяются на ESXi при его добавлении в NSX. Этот профиль необходим при добавлении кластеров vSphere, для консистентной настройки ESXi хостов в кластере. Без него вы не сможете добавить ESXi хосты, сгруппированные в кластер. Чем-то похоже на Host Profiles в vSphere.

Информация

Наличие реального шлюза обязательно для маршрутизации трафика в туннелях. Без него связи между хостами не будет.

Установка NSX на транспортные ноды

Инфраструктура добавлена в NSX-T, но сам NSX на транспортных нодах не развернут и соответственно они не принимают участие в обработке трафика виртуальной сети. Для того что бы магия NSX заработала на них нужно его установить. Выбираем наш кластер в System > Fabric > Hosts > Clusters и нажимаем CONFIGURE NSX. Далее выбираем профиль транспортной ноды из предыдущего шага и жмем NEXT. Начнётся установка.

Шаг 3. Развертывание пограничных узлов NSX

Создадим новый пограничный узел. В NSX Manager переходим в System > Fabric > Nodes > Edge Transport Nodes > Add Edge Node

Указываем имя, FQDN и конфигурацию.

Задаём доступы для root-пользователя и CLI-пользователя.
Вклчюаем SSH, если требуется. (В продуктивной среде - не рекомендуется)

Указываем кластер для развёртывания. Рекомендую разносить коммутаторы между разными кластерами и хранилищами.

Заполянем конфигурацию менеджмент интерфейса, указываем порт группу, адресацию, опционально заполняем DNS и NTP.

Важно!

For uplinks used by a teaming policy, you cannot use he same uplinks in a different uplink profile for a given NSX Edge transport node. Standby uplinks are not supported and must not be configured in the failover teaming policy. If the teaming policy uses more than one uplink (active/standby list), you cannot use the same uplinks in the same or a different uplink profile for a given NSX Edge transport node.
NSX Edge VMs do not support any standby uplinks - single or multiple standby uplinks. KB VMware

Добавим новые пограничные узлы в edge-кластера.

В NSX Manager переходим в System > Fabric > Nodes > Edge Clusters > Add Edge Cluster