Nsx t что это

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

Рассказываем об архитектуре, функционале и применении платформы виртуализации сетевых сервисов VMware NSX-T.

Эта инструкция — часть курса «Начинаем работу с VMware».

Смотреть весь курс

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

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

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

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

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

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

Точно так же, как 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-V	NSX-T
Тесная интеграция с vSphere	да	нет
Работа без vCenter	нет	нет
Поддержка нескольких экземпляров vCenter с помощью NSX Manager	нет	да
Обеспечивает виртуальную сеть для следующих платформ виртуализации	VMware vSphere	VMware vSphere, KVM, Docker, Kubernetes, OpenStack
Развертывание NSX Edge	ESXi VM	Виртуальная машина ESXi или физический сервер
Протоколы оверлейной инкапсуляции	VXLAN	GENEVE
Используемые виртуальные коммутаторы (N-VDS)	Распределенный коммутатор vSphere (VDS)	OpenVSwitch (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).

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

• 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 и собирать статистику на уровне пакетов.

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

• 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 рекомендуется, если все участники кластера расположены в одной подсети.

Логическая архитектура 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.

Гипервизор VMware ESXi: функции и отличия от ESX

Объясните, пож, что значит 10к, 30, 60к? Извините за незнание. Это деньги, но чьи и сколько в переводе на рубли?

иван иванов Искусственный Интеллект (136798) Нам разные придурки много чего навязывают! Нужно учиться адекватно реагировать на эти навязывания!

кто пользуется буквой к обозначая тысячу рублей — тот неисправимый болван. Так ему и передайте. Хотя чушь собачья как правило заразительна.

Школа, пятый класс. Что такое кг и км? Правильно, килограмм и километр. Что такое килограмм? 1000 грамм. Что такое километр? 1000 метров. К = кило = тысяча.

ТравкинаИскусственный Интеллект (112087) 4 года назад

Я бабулька 50 лет. Что такое км, мм, 1 ст. л. знаю, а вот ваши примамбасы не всегда понимаю.
сама скажи, когда и кто придумал это К? а вот и не знаешь) Конечно, в википедию лезешь.

Иван СигаевИскусственный Интеллект (148268) 4 года назад

К- = киби => *1024
к- = кило => *1000

тот случай когда «размер» имеет значение

Логический свитчинг в NSX-T

Настало время наконец приступить к понимаю основ и принципов работы виртуальных сетей в NSX-T. В предыдущих частях мы описывали что такое NSX, для чего он нужен и подготовили инфраструктуру к установке этого продукта. В этой статье мы познакомимся с архитектурой его работы на уровне L2 сетевой модели. Разберемся наконец некоторые из ранее упоминавшийся терминов и проследим за пакетами VM, как они путешествуют в пределах одного L2 домена. В этом выпуске:

• Архитектура L2 NSX-T
  • Сегменты
  • Тунелирование
  • Протокол Geneve
  • TEP интерфейсы
  • SpoofGuard
  • IP Discovery
  • MAC Discovery
  • Segment Security
  • QoS
  • TEP/MAC/ARP таблицы
  • Путь пакета Unicast
  • Путь пакета BUM

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

  В этом разделе опишем из чего состоит L2 в NSX-T технически. Как мы знаем из предыдущей статьи у нас есть Транспортные Зоны, которые деляться на Overlay и VLAN по типу. Тип Зон определяет на основе какой технологии (VLAN или Overlay) будет происходить разделение широковещательных L2 доменов внутри них. Если с VLAN все понятно — мы используем такие сегменты в качестве линков в физический мир (а как — это тема для следующих частей), для управления хостов, сеть которых переехала на N-VDS и просто для VM, которые должны находиться в каком-либо VLAN по тем или иным причинам. То с Overlay нам предстоит разобраться. Но давайте по порядку. Снизу изображена концептуальная архитектура L2 на NSX-T.

  

  Мы видим виртуальный свитч, который добавляется на транспортную ноду, об этом написано в прошлой статье. Физические аплинки сервера, назначенные свитчу, через которые ходят пакеты в физическую сеть. Видим Сегмент, который является по сути порт-группой на виртуальном свитче. А также порты на этом сегменте, к которым подключены виртуальные машины, контейнера и шлюз. Segment profiles, определяющие политики и некоторый функционал NSX-T на L2 уровне. Единственно тут не хватает TEP интерфейсов для полноты картины, но мы не обделим их вниманием в этой статье. Давайте приступим к погружение во все это.

  Segments

  Сегменты NSX-T. Так же называются Logical Switches. Эти два термина обозначают одно и то же, но в разных контекстах (Segment – Policy Plane/Logical Switch – Management Plane). Сегменты создаются внутри транспортной зоны и как мы помним из предыдущих статей, не могут выйти за ее пределы. Транспортная Зона диктует на каких хостах будет доступен определенный L2 сегмент.

  Сегмент это один виртуальный широковещательный домен L2 в NSX-T. По сути это одна порт-группа на виртуальном коммутаторе, обеспечивающая соединение между портами VM по L2 внутри и между Транспортных Нод (ESXi хостов). Если мы зайдем в vCenter, то сегменты NSX-T будут видны нам как порт-группы с немного измененными иконками в зависимости от того какой виртуальный свитч мы выбрали в Профиле Транспортной Ноды (подробно описано в прошлой статье).

  Сегменты бывают двух типов – VLAN и overlay.

  VLAN сегменты ничем почти не отличаются от обычных порт-групп на виртуальном коммутаторе и используют 802.1Q заголовок для разделения L2 доменов. VLAN сегменты просты и не имеют возможности пользоваться распределенной маршрутизацией NSX, но в остальном имеют похожие свойства и настройки, что и overlay сегменты. Могут быть созданы только в Транспортной Зоне VLAN типа.

  Overlay сегменты более сложны. Они являются более «виртуальными» чем VLAN-ы и могут пользоваться всеми функциями NSX, предоставляя больше гибкости и масштабируемости. Overlay сегменты работают поверх VLAN-ов, а точнее поверх одного транспортного VLAN-а, который нужен только для транспортировки пакетов в пределах overlay сегмента по физической сети. Каждому overlay сегменту присваивается идентификатор (VNI), Похожий на VLAN ID. VNI может принимать значения от 5000 до 16777216. То есть мы можем напилить в среднем около 16 миллионов Overlay сегментов, в отличие от максимума 4095 возможного с технологией VLAN. В данной статье речь пойдет преимущественно о overlay сегментах. Ну и стоит упомянуть что overlay сегменты создаются только внутри Overlay Транспортной Зоны.

  Теперь о том, как происходит обмен пакетами между членами одного overlay сегмента. Мы знаем, как это работает в обычных порт-группах с настроенным VLAN, к примеру, на VDS. Машина VM-1, расположенная на гипервизоре A отправляет пакет на машину VM-2, расположенную на гипервизоре B. Итак, гипервизор A обрабатывает пакет, вешает на него тег с VLAN ID и пускает с аплинка в физическую сеть. Коммутатор на основе VLAN ID и MAC таблицы пропихивает пакет в нужный порт к аплинку гипервизора B. Гипервизор B принимает пакет, снимает с него тэг и пропихивает в VM-2. Все. Так же это происходит в сегменте, созданном в VLAN TZ на NSX. Но как это происходит в Overlay сегменте?

  Тунелирование

  А происходит это с помощью тунелирования. Пакет VM-1 инкапсулируется протоколом Geneve и отправляется по физической сети до гипервизора с VM-2 на борту по туннелю Geneve.

  

  Туннели подымаются между TEP интерфейсами Транспортных Нод, изолируя Overlay сегмент от физической сети. В данном случае у нас изображен туннель между TEP интерфейсами гипервизоров A и B. Overlay сегменты основаны на туннелях, которые изолируют виртуальную сеть от физической. Эта изоляция достигается путем инкапсуляции пакетов VM в заголовок протокола Geneve. Инкапсулированные пакеты путешествуют между Транспортными Нодами по физической L2 или L3 сети. IP адресом источника и назначения такого пакета являются адреса TEP интерфейсов. Сам же оригинальный пакет VM скрывается за заголовком Geneve и будет распакован, и передан VM-2 по прибытию на TEP хоста B.

  Туннели подымаются между хостами при включении на хостах VM. В списке транспортных нод можно посмотреть на каких хостах туннели есть и до каких хостов они ведут.

  Это на самом деле очень важно. Потому что если до каких-то хостов туннели не подымятся, то VM между этой парой хостов не смогут обмениваться траффиком. Такое случается, когда в профилях хостов указан неправильный VLAN для транспортного трафика либо какая-то проблема в маршрутизации туннельного трафика, если TEP интерфейсы у хостов в разных подсетях. Одним словом, если какая-то машина не может достучаться до другой и машины на разных гипервизорах – смотри туннели.

  Протокол Geneve

  Теперь про то что эти туннели строит – протокол Geneve (Generic Network Virtualization Encapsulation). Это открытый протокол туннелирования, который инкапсулирует L2 фреймы поверх L3. Его можно сравнить с другими аналогами — VXLAN, NVGRE, и STT. Но по сравнению с ними он более гибок и функционален. Его функциональность достигается более многочисленными полями в служебном заголовке, которые могут быть использованы для различных нужд в будущем. Для сведения VMware NSX-V использует протокол VXLAN для тех же целей.

  Так как пакет Geneve имеет свой собственный заголовок L3 и L2, туннели между Транспортными Нодами могут простираться не только в пределах одной подсети или VLAN, но и за их пределами. То есть трафик туннелей может маршрутизироваться, а TEP интерфейсы Нод находиться в разных физических L2 доменах.

  Виртуальная машина VM-1 на хосте A отправляет пакет, предназначенный VM-2, расположенной на хосте B, машины в одном сегменте. Гипервизор А понимает по служебным таблицам (о них потом), что VM-2 находиться на гипервизоре B (с которым у него установлен туннель) берет пакет и не меняя в нем ничего инкапсулирует его в Geneve заголовок. В заголовке указывается адресом источника – IP своего TEP, а адрес назначения – IP TEP интерфейса хоста B, с которым у него есть туннель. Протокол доставки UDP, а порт назначения 6081. Пакет отправляется в путешествие по VLAN, казанному в Профиле Транспортной Ноды гипервизора A как Транспортный VLAN. Итак, пакет доставляется до хоста B, тот его рассматривает, понимает, что он прилетел к машине, расположенной на нем, декапсулирует пакет, снимая Geneve заголовок и пропихивает оригинальный пакет в порт виртуальной машины VM-2. Вуаля. Если трафик мультикастовый или броадкастовый, то инкапсулированный фрейм летит на несколько гипервизоров что бы быть доставленным всем портам в сегменте.

  

  • Использует UDP для доставки пакетов.
  • Использует порт 6081.
  • Использует 24 битный VNI.
  • Поддерживает IPv4 и IPv6.
  • В заголовке присутствует куча дополнительных полей, зарезервированных на будущие нужды NSX, собственно именно благодаря функциональному заголовку Geneve и «отжал» у VXLAN позиции в NSX-T.
  • Позволяет делать такой же offloading на физическом адаптере, как и VXLAN.
  • Классное название.

  TEP интерфейсы

  Про них было уже много рассказано сегодня. Они являются сетевым горлышком для обмена трафиком внутри Транспортной Зоны. Geneve туннели начинаются и заканчиваются этими интерфейсами.

  TEP создается на Транспортной Ноде при установки NSX. Он может быть и не один. Количество TEP интерфейсов на хосте или Edge ноде зависит от Uplink Profile, а точнее от количества Active Uplinks. Почему? Потому что если активных аплинка два, а TEP один, то инкапсулированный трафик будет задействовать только один физический аплинк, а второй будет простаивать. Не оптимальненько. Поэтому сколько активных аплинков, столько и TEP интерфейсов. Соответственно и количество подымаемых туннелей увеличится на хосте, если TEP-ов больше.

  

  В интерфейсах хоста в vCenter, TEP-ы так же видны и используют персональный tcp/ip stack – «nsx-overlay», но в консоли ESXi данный стек носит другое название – «vxlan». Имейте это ввиду, когда производите траблшутинг.

  Каждый из TEP-ов на хосте будет стремиться поднять туннель с каждым TEP-ом на каждом другом хосте в инфраструктуре NSX-T. Например, у нас три хоста и на каждом по два TEP. На каждом хосте будет 8 туннелей.

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

  vmkping –I vmk10 –s vxlan - 30.30.30.104 –d

  Запускаем подключившись к одному из хостов ESXi, между которыми лежит туннель.

  -I vmk10 – определяем исходящий интерфейс.

  -S vxlan – определяем tcp/ip stack, который работает на интерфейсе, на TEP может работать только ‘vxlan’ и указать его необходимо иначе команда не заработает. Как говорилось выше, в интерфейсе vCenter, стэк носит имя «nsx-overlay».

  30.30.30.104 – ну ты понел.

  -s 1472 – задает количество байт ICMP в пакете. Если прибавим 28 байт (заголовок ICMP/заголовок IP/Ethernet), то получим 1600. Наш необходимый MTU.

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

  Создание сегмента

  Давайте уже создадим сегмент в NSX-T. Идем в Network> Segments> add segment. Нам откроется форма ниже. Вводим имя и пробежимся по выделенным полям.

  

  1. Выбираем к какому логическому маршрутизатору будет подключен данные сегмент. Об этом в следующих статьях.
  2. Выбираем транспортную Зону в пределах которого будет развернут этот сегмент.
  3. Задаем адрес шлюза для этого сегмента. Да все верно. Если мы указали IP шлюза и подсоединили сегмент к виртуальному маршрутизатору в пункте 1, то в этом сегменте создается порт для роутера и ему назначается IP. Сегмент становиться маршрутизируемым.
  4. Тут мы можем увидеть все подключенные порты VM к этому сегменту.
  5. Тут задается VLAN ID для сегмента в случае если создаем его в VLAN Транспортной Зоне. В случае Overlay оставляем пустым. VNI для сегмента будет назначен автоматически.

  Остальные поля нам пока не нужны. Нажимаем SAVE и сегмент готов. Через секунду-две статус сегмента станет зеленым. Это значит, что Policy Plane принял к исполнению наши требования, передал это на Management Plane, а тот на CCP и на Data Plane. А затем обратно пришел рапорт об успешно принятой конфигурации и создании объекта.

  К слову о Management Plane. Если мы переключим контекст меню на manage, то сегменты предстанут перед нами как Logical Switches. Интерфейс создания тоже будет немного отличаться, но ключевые параметры останутся.

  Segment Profiles

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

  • SpoofGuard
  • IP Discovery
  • MAC Discovery
  • Segment Security
  • QoS

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

  В NSX присутствуют Default Segment Profiles.

  

  Редактировать их не получиться. Но можно посмотреть их настройки, раскрыв стрелку.

  Теперь давайте пройдемся и опишем каждый профиль.

  MAC Discovery Profiles

  Этот профиль определяет будет ли работать MAC Learning и будет ли возможность поменять MAC адрес на виртуальной машине в сегменте безнаказанно. Давайте детально.

  

  MAC Learning – функция, позволяющая выучить множественные дополнительные MAC адреса, если они вдруг появились за определенным портом в сегменте. К примеру, у нас есть один подключенный к сегменту порт виртуальной машины. У машины есть MAC адрес на виртуальном интерфейсе, NSX его знает, знает на каком он порте, и шлет фреймы, предназначенные ему в этот порт. И тут вдруг с этого самого порта начинают исходить фреймы, MAC адрес источника которых отличается от MAC адреса, который знает NSX. Так вот, если MAC Learning включен в этом профиле, то NSX будет запоминать эти «левые» маки и направлять пакеты, предназначенные им в порт, с которого они «засветились». Это очень подходит если у нас развернуты вложенные ESXi хосты, на которых работают виртуалки, общающиеся по сети.

  У MAC Learning есть параметр времени, на протяжении которого NSX будет помнить выученный «левый» MAC если тот перестал использоваться и пакеты с от него не летят. Этот параметр не конфигурируется и составляет 10 минут. Это значит, что спустя десять минут после того как «левый» мак перестал слать пакеты, NSX удалит его из MAC таблицы сегмента.

  MAC Limit задает максимальное количество маков, которое NSX может выучить. По умолчанию 4096 и увеличить это значение можно только после включения MAC Learning.

  MAC Limit Policy – Определяет что делать с пакетами, MAC адрес источника которых неизвестен NSX-у по причине преодоления лимита, настроенного в MAC Limit. Deny – дропать пакеты исходящие от неизвестных MAC адресов, а пакеты направляемые таким адресам (неизвестным) помечать как unknown unicast. И если включен Unknown Unicast Flooding такие пакеты будут разосланы всем портам в сегменте, а если не включен, то будут дропнуты. Alloy – пропускать пакеты исходящие от неизвестных маков, пакеты предназначенные им (unknown unicast) пропускать в случае если включен Unknown Unicast Flooding.

  Unknown Unicast Flooding – про это описано выше. Если включен, то пакеты с неизвестным MAC адресом назначения будут рассылаться во все порты сегмента. Если выключен – дропаться.

  MAC Change – определяет как будет реагировать NSX на смену виртуальной машиной своего MAC адреса, прописанного в vmx файле. Данная опция доступна только на ESXi хостах, на KVM работать не будет, что бы мы тут не настроили. По умолчанию эта функция отключена и это значит, что если VM сменила мак, то ее трафик будет дропнут и сеть у нее не будет работать.

  IP Discovery Profiles

  NSX нужно знать IP адреса виртуальных машин для ряда функций:

  • ARP/ND Suppression, которая позволяет минимизировать широковещательный ARP трафик между VM.
  • Distributed Firewall – распределенный брандмауэр.
  • SpoofGuard – механизм для блокировки дублирующийся IP.

  Что бы эти адреса узнать NSX использует несколько технологий, в число которых входит:

  • DHCP/DHCPv6 snooping
  • ARP/ND snooping
  • VMware Tools

  DHCP/DHCPv6 Snooping – NSX следит за трафиком DHCP и запоминает какой MAC получил какой IP. Позволяет определять IP порта, если не настроен статический адрес.

  ARP Snooping – слушается ARP трафик машин и на основе ответов происходит сопоставление MAC-IP отвечающей машины. Определяет IP порта, когда задан статический IP в виртуальной машине.

  ND Snooping – то же самое что и ARP только для IPv6.

  VMware Tools – установленные на VM тулзы рапортуют о IPv4 и IPv6 адресах, которые настроены на интерфейсах. Работает только на машинах, расположенных на ESXi естевственно.

  Сопоставленные MAC/IP, выученные на каждом порту с помощью вышеописанных служб, записывает в так называемые Address Bindings. У каждого порта в сегменте есть свои Bindings.

  Address Binding это сопоставленные IP/MAC/VLAN (если есть, у портов в Overlay TZ всегда равен нулю) и закрепленные за портом в сегменте. Посмотреть эти биндинги можно переключив интерфейс Networking в режим manager. Затем зайти в Logical switches> Ports и выбрав интересующий нас порт. Открываем Address Bindings и видим различные типы биндингов.

  

  Auto Discovered Bindings – содержит полученные IP/MAC на порту в результате работы одного из методов описанных выше.

  Manual Bindings содержит то же самое, но заданное вручную администратором.

  Ignore Bindings – список IP/MAC, который NSX известен из каких либо источников, но который игнорируется системой. В этот список можно добавить биндинги вручную. Иногда такое требуется если на маке порта засветился адрес, который по каким-либо причинам нежелателен.

  Realized Bindings – а это уже биндинги на которые ориентируются службы, перечисленные в начале. Как видим присутствующий биндинг получен с помощью ARP snooping.

  Итак, NSX-T c помощью определенных в профиле функций узнает IP/MAC порта, заносит его в Auto Discovered Bindings, затем плюсуется запись из Manual Bindings (если она есть), из этого списка удаляются записи, перечисленные в Ignore Bindings (опять же если они есть) и все что «уцелело» падает в Realized Bindings, на которые и ориентируется NSX.

  Вернемся к нашему IP Discovery профилю, который и определяет, как и с помощью каких технологий будут заполняться Auto Discovered Bindings в определенном сегменте или даже на определенном порту (как мы помним, сегмент профиля можно назначать и на порты). В данном профиле мы можем задавать с помощью каких технологий будет определяться IP порта, отключая ненужные. В профиле по умолчанию IPv6 адреса не определяются так как отключены DHCPv6 Snooping, ND Snooping, VMware IPv6 и что бы нам это исправить, нужно создать дополнительные профиля, в которых включить их.

  

  По умолчанию ARP и ND Snooping работают в режиме trust on first use (TOFU). В этом режиме если IP адрес узнан и добавлен в Realized Bindings List, то он остается там навсегда. Можно отключить этот режим соответствующим переключателем в профиле и тогда ARP/ND Snooping будет работать в trust on every use (TOEU). В этом режиме запись MAC/IP будет существовать в Realized Bindings List только определенное время (заданное в ARP ND Binding Limit Timeout в минутах), после которого будет заменяться на ново изученную. TOEU подходит для сегментов, где IP у машин меняются периодически.

  DHCP/DHCPv6 snooping и VMware Tools работают всегда в TOEU. Потому как динамические адреса имеют свойства меняться и их «приколачивание» к порту тут неуместно.

  Так же у нас есть ARP и ND Snooping Limit настройки. Они определяют лимит IPv4 и IPv6 адресов, закрепленных за портом.

  Duplicate IP Detection – эта функция проверяет, присутствует ли выученный IP адрес в Realized Binding List других портов. Другими словами, проверяет есть ли такой же IP в данном сегменте. И если есть, то свежий дублирующийся адрес не добавляется в Realized Binding List своего порта и соответственно не учитывается. Но и не удаляется. Он тусит в Auto Discovered Bindings списке своего порта до тех пор, пока адрес, который он дублирует не исчезнет из сегмента по какой-либо причине. После этого он перемещается в Realized Binding List своего порта и будет учтен.

  Но что делать если сразу несколько портов «засветили» одинаковым адресом, да к тому же еще и присутствующем в системе? NSX вызывает копов. Дело в том, что, когда NSX определяет IP в сегменте, он добавляет к его записи в Auto Discovered Bindings листе метку времени, когда этот IP «засветился». И когда адрес, который дублируют другие порты исчезает из сегмента, в Realized Binding List своего порта попадает та запись, метка времени которой старше, а более «младшая» продолжает «чилить» в Auto Discovered Bindings своего порта.

  QoS profile

  Данный профиль позволяет вешать на трафик Overlay сегмента метки, определяющие приоритетность трафика. Что бы устройства в физической сети – коммутаторы и маршрутизаторы ориентировались на эти метки и гарантированно предоставляли определенные качества сервиса (задержки и ширина полосы пропускания). QoS профиль поддерживает управление следующими типами меток:

  • Class of Service (CoS)
  • Differentiated Services Code Point (DSCP)

  Class of Service (CoS) – метка добавляется в L2 заголовок пакета и может содержать значение от 0 до 7. Это значение присваивается пакетам внутри гипервизора и может быть использовано для определения приоритетности пакетов как в буфере ESXi, то есть в пределах одного гипервизора, так и в физической сети.

  Differentiated Services Code Point (DSCP) – это метка может разбивать трафик по приоритетам от 0 до 63. DSCP метка помещается в L3 заголовок пакета и учитывается роутерами при маршрутизации трафика в физической сети. Данная метка не учитывается при продвижении пакетов внутри буферов гипервизора и нужна сугубо для приоретезации пакетов в физической сети. И так как эта метка предназначена для физических устройств, она лепится на внешний L3 заголовок сформированного Geneve пакета.

  Теперь о том, как NSX определяет какую метку какого типа лепить на какие пакеты.

  

  По DSCP. У нас есть настройка Mode, которая определяет будет ли метка DSCP, назначенная гостевой системой учтена и дублирована во внешний Geneve заголовок, на основе которого пакет будет перемещаться по физической сети и соответственно получать определенный уровень сервиса (Trusted Mode). Или же на пакет будет прилеплена метка с приоритетом, определенным в профиле (Untrusted Mode) и не важно какое значение добавляет виртуалка. Настройка Priority как раз определяет это значение. Если используется Untrusted Mode, метки будут присваиваться так же и на пакеты в VLAN сегменте, в то время как Trusted Mode подразумевает трансляцию внутренней метки пакета во внешнюю, а Geneve заголовке и соответственно использование Overlay сегмента. Естественно в случае VLAN сегмента, метки будут помещаться в оригинальный IP заголовок и физическая сеть будет ориентироваться на него при пересылке пакета, так как Geneve заголовок отсутствует.

  По CoS. Все просто, настройка Class of Service определяет значение метки в L2 заголовке.

  Для того что бы предотвратить перегрузку физических линков наших гипервизоров мы можем воспользоваться до боли похожими на Traffic Shaping из vSphere настройками скорости, пиковой скорости и размером Burst входящего и исходящего трафика.

  Segment Security Profile

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

  

  Пробежимся по этим механизмам.

  BPDU Filter – как видно из названия блокирует весь BPDU трафик, который как то попал в сегмент. На самом деле это очень важная настройка, которая может предотвратить изоляцию хоста, в случае если, какая-либо виртуальная машина отошлет с сеть BPDU пакет, и он доберется до физического коммутатора, а там настроен BPDU Guard на принимающем порту. Но это другая тема для другого поста. Лучше его включать.

  BPDU Filter Allow List – тут мы можем указать MAC адреса назначения, BPDU трафик до которых будет разрешен при включенном BPDU Filter. Имеются ввиду внешние физические маки.

  Перейдем к разделу DHCP:

  Server Block – при включении режет трафик, направленный от DHCP сервера клиенту.

  Client Block – блокирует запросы от клиента к серверу.

  Server Block/Client Block IPv6 – думаю объяснять не нужно что они делают.

  Block Non-IP Traffic – при включении этого фильтра будет блокировать весь трафик кроме IPv4, IPv6, ARP, GARP и BPDU.

  RA Guard – запретить IPv6 router advertisements.

  Rate Limits – создаем лимит для broadcast и multicast трафика в сегменте. Задается указанием количества пакетов в секунду, а не скоростью. Может предотвратить широковещательный шторм в сегменте. Рекомендуется задавать значение около 10 пакетов в секунду на все четыре поля для того что б совсем не ликвидировать широковещательный трафик.

  SpoofGuard Profile

  Последний в списке, но не по значению SpoofGuard. Он имеет лишь одну настройку – вкл/выкл, которая регламентирует соответственно включен ли механизм SpoofGuard в сегментеb или на конкретном порту, к которому добавлен этот профиль. Теперь о том, что делает этот механизм будучи включенным. Главная суть этого механизма в том, чтобы предотвратить передачу трафика VM, если IP/MAC/VLAN (если сегмент в VLAN TZ) отправителя в пакете, отправленном этой VM отличается от того что в Realized Bindings List порта. То есть, когда пакет отправляется с порта в сегменте, его IP, MAC отправителя и VLAN (если в сегменте транком подаются VLAN к портам) сверяются с содержащимися в Realized Bindings List этого порта и, если они не совпадают, то пакет дропается. А если в тоже время с порта попытается уйти нормальный кадр, с IP/MAC/VLAN источника соответствующими Realized Bindings List, то его пропустят. Проверка происходит по всем трем пунктам IP/MAC/VLAN.

  Как пакеты путешествуют по сегменту?

  В этом разделе мы разберем что еще нужно помимо того, что мы рассмотрели выше для перемещения пакетов в сегменте NSX, проследим за путешествием маленького пакета в огромном сегменте, а также посмотрим, как распространяется BUM трафик и узнаем про ARP Suppression.

  TEP/MAC/ARP таблицы

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

  • TEP Table
  • MAC Table
  • ARP Table

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

  TEP Table

  Содержит сопоставления VNI-ID сегмента к IP TEP интерфейса хоста. Выглядит это так:

  VNI сегмента	TEP IP хоста
  5700	192.168.30.2
  5701	192.168.30.2

  Запись VNI сегмента-TEP IP добавляется в таблицу при включении VM в этом сегменте. Итак, мы знаем за какими нашими локальными TEP-ами прячутся какие сегменты, супер. Но что дальше, нам то эта информация зачем? А затем что бы регулярно отправлять эту таблицу на Central Control Plane (CCP) по Management Network. А CCP в свою очередь получая со всех хостов такие таблицы, формирует из них одну и затем рассылает ее хостам. Таким образом все хосты получают информацию о том какие TEP-ы принимают участие в пересылке пакетов в определенном сегменте. Теперь на каждом хосте таблица стала такой.

  VNI сегмента	TEP IP хоста
  5700	192.168.30.2 192.168.30.3
  5701	192.168.30.2 192.168.30.3

  MAC Table

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

  VNI сегмента	VM MAC	TEP IP хоста
  5700	AA:AA:AA:AA	192.168.30.2
  5701	BB:BB:BB:BB	192.168.30.2

  Точно так же эта информация отправляется в CCP, с которого потом прилетает консолидированная таблица MAC-TEP по всем хостам.

  VNI сегмента	VM MAC	TEP IP хоста
  5700	AA:AA:AA:AA CC:CC:CC:CC	192.168.30.2 192.168.30.3
  5701	BB:BB:BB:BB DD:DD:DD:DD	192.168.30.2 192.168.30.3

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

  ARP Table

  Но виртуальная сеть на этом не останавливается. Для реализации ARP Suppression о которой мы говорили ранее NSX-у нужно знать сопоставление IP-MAC машин. Как мы помним из предыдущего раздела у нас есть Realized Bindings List, в котором и содержаться IP-MAC-VLAN маппинги. Этой информацией заполняется наша ARP таблица на хосте и отправляется на CCP, где прилетевшие таблицы со всех хостов складываются в одну, и она рассылается обратно хостам. И мы получаем:

  VNI сегмента	VM IP	VM MAC	TEP IP хоста
  5700	172.16.33.25 172.16.33.26	AA:AA:AA:AA CC:CC:CC:CC	192.168.30.2 192.168.30.3
  5701	163.15.240.21 163.15.240.22	BB:BB:BB:BB DD:DD:DD:DD	192.168.30.2 192.168.30.3

  Теперь Data Plane на Транспортных Нодах обладает всей необходимой информацией о том, кто и где, чтобы пересылать пакеты и уменьшать количество широковещательных запросов с помощью ARP Suppression. Эти таблицы рассылаются c CCP не только гипервизорам, но и «эджам». Потому как Edge Nodes так же учувствуют в пересылке трафика на L2 и на них так же есть TEP интерфейсы. Пакеты из физического мира попадают в матрицу виртуальную сеть только через Edge, соответственно ему нужно знать за каким TEP находится нужная VM.

  Путешествие пакетов между хостами

  Во время прочтения этой статьи мы знакомились с компонентами логического свитчинга в NSX-T, узнали, что для чего нужно и как это работает. Теперь настало время сложить все узнанное в единую картинку и посмотреть, как функционирует уровень L2 сетевой модели в виртуальной сети NSX. Рассмотрим, как фреймы путешествуют по виртуальной сети в случае Unicast и BUM трафика.

  Путь пакета Unicast

  В нашем примере VM-1 хочет отослать пакет VM-2.VM-1 отсылает пакет с адресом назначения IP 2 (1).

  

  Гипервизор ESXi-A принимает пакет на Data Plane, смотрит его адрес назначения и понимает, что пакет предназначен VM, которая на нем не расположена. Он проверяет присланные с CCP таблицы и видит, что IP машины, которой предназначен пакет располагается за TEP с IP 10.20.10.12. ESXi-A инкапсулирует пакет VM-1 Geneve заголовком и указывает в адресе источника IP своего TEP интерфейса (10.20.10.11), а в адресе назначения IP TEP хоста ESXi-B (10.20.10.12), добавляет в заголовок VNI ID сегмента (5000). Инкапсулированный пакет отправляется в путешествие по физической сети до TEP ESXi-B (2).

  

  Пакет доставляется физической сетью до ESXi-B. Гипервизор принимает пакет на своих аплинках и передает TEP интерфейсу (3).

  ESXi-B производит декапсуляцию пакета Geneve. Смотрит адрес назначения оригинального пакета, определяет, что он предназначен для VM-2 и пропихивает фрейм в порт, на котором числиться в Realized Binding List IP адрес назначения (4).

  

  Задача выполнена и пакет доставлен. VM-2 ответит VM-1 по такому же принципу и ее ответный пакет проделает аналогичный путь, только наоборот. Таким образом происходит пересылка Unicast пакетов внутри сегмента NSX.

  Пересылка BUM трафика

  Для начала вспомним, что такое BUM трафик. Это широковещательный трафик broadcast, unknown unicast и multicast, сокращенно BUM. Данный трафик адресован множественным получателям. Мы не будем вникать в его технические нюансы, подразумевая что читатель знаком с ними, а если нет, то бегом сюда.

  Итак, перед NSX-T стоит задача пересылки такого трафика. Из предыдущего примера мы знаем, как пересылается обычный unicast пакет между хостами. Но как быть с пакетом, который должен попасть в несколько портов сегмента? Логично, его нужно транслировать до необходимых TEP интерфейсов в сегменте за которыми расположены порты назначения. В случае broadcast это все TEP в сегменте. А после доставки на гипервизор, данный пакет будет разослан всем портам, которым он предназначен. Остается уточнить как именно наш широковещательный пакет будет рассылаться по гипервизорам. Существует два режима рассылки BUM трафика в NSX-T:

  • Head Replication
  • Hierarchical two-tier replication

  Head Replication – Транспортная Нода источник сама рассылает широковещательные пакеты до каждого TEP интерфейса в сегменте, неважно находиться ли IP TEP-ов назначения в одном L2 домене с IP TEP источником или нет. Каждому TEP-у по копии пакета. Далее получившие данный пакет хосты рассылают его копии всем портам назначения в сегменте.

  

  Hierarchical Two-Tier Replication – в данном режиме Транспортная Нода источник BUM трафика берет на себя рассылку широковещательного пакета всем TEP-ам в одном с ней L2 домене. Если есть TEP-ы, которые так же должны получить этот широковещательный пакет, но их IP адреса находиться в другом L2 домене, то есть в другой подсети, то происходит следующее. ТН источник рандомно выбирает в каждой сети один TEP (Proxy TEP), на который отправляется копия широковещательного пакета. В заголовке Geneve данного пакета ставиться специальная метка. Хост назначения получает этот пакет на своем TEP интерфейсе, проверяет заголовок, видит метку и рассылает копии этого пакета всем остальным TEP-ам в его сети, но метку с них снимает. А также пропихивает полученный кадр своим локальным получателям. Остальные хосты получают наш пакет и рассылают свои получателям.

  

  Данные режимы настраиваются на каждом сегменте.

  Подготовка инфраструктуры к NSX-T

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

  • Увеличение MTU
  • Создать IP Pool в NSX
  • Определиться с выбором виртуального коммутатора для NSX
  • Создать Транспортные Зоны в NSX
  • Создать профили для Транспортных Нод
  • И наконец добавить хосты в NSX

  MTU

  Первое что нужно сделать перед тем как непосредственно приступить к развертыванию виртуальных сетей, это увеличить MTU на всех сетевых устройствах и виртуальных коммутаторах в vSphere до 1600. Это нужно что бы физические устройства, участвующие в виртуальной сети, могли обмениваться инкапсулированным трафиком между собой. Для чего нужна инкапсуляция и как она работает рассмотрим позже. Без нее не будут работать почти что все функции NSX-T. MTU можно оставить 1500 разве что том случае, если нам NSX нужен только для распределенного брандмауэра, и мы не хотим использовать все остальное (такие случаи тоже бывают). А так для полноценной виртуальной сети MTU должен быть не ниже 1600.

  IP Adress Pools

  Пулы IP адресов. Это наборы адресов для использования в служебных целях. В основном используются для назначения IP адресов TEP интерфейсам Транспортных Нод. Когда мы добавляем ESXi к Overlay Транспортной Зоне, на хосте создается TEP интерфейс и ему соответственно нужен IP адрес, который и берется отсюда. TEP интерфейс нужен для возможности общения VM, расположенных на разных Транспортных Нодах внутри одной Транспортной Зоны. Нужно заранее определиться с пулом адресов для этого, с его размером, подсетью и прочими атрибутами. Стоит учесть, что если мы добавляем Транспортную Ноду и в Uplink Profile (о нем ниже) фигурируют два активных аплинка, то и TEP интерфейса будет два и соответственно будет потрачено два адреса из пула.

  

  N-VDS или VDS

  А теперь о более знакомом, о виртуальных коммутаторах. Для того что бы любой гипервизор обрабатывал трафик виртуальных машин ему нужна программная сущность для этого, ею на большинстве гипервизоров выступает виртуальный коммутатор. Это совокупность служб и модулей, которые проталкивают пакеты сквозь свои буферы и делают необходимые манипуляции с ними перед тем как выпустить в физический мир, а также производят сегментацию на уровне L2. У vSphere это как известно Standard vSwitch и VDS (Virtual Distributed Switch). NSX-T так же нужна подобная сущность для обработки трафика на Транспортных Нодах (Гипервизорах и Edge). Для этого в NSX-T 3.0 нам предлагается на выбор использовать N-VDS или существующий VDS v7 при добавлении Транспортной Ноды.

  N-VDS

  N-VDS — это независимый от платформы распределенный виртуальный коммутатор, оснащенный всеми нужными службами и модулями по обработке трафика VM, который устанавливается на Транспортную Ноду при ее добавлении в NSX-T. Поддерживаются все виды транспортных нод – ESXi, KVM и NSX Edge. N-VDS управляется только NSX-ом, ни хост, ни vCenter не способны внести изменения в его конфигурацию, они только могут инициировать подключение VM к сегменту, а NSX Manager получив этот запрос уже отдает распоряжение на N-VDS о коннекте порта VM. NSX Manager-у не нужен vCenter для добавления и управления N-VDS на хостах. Сегменты NSX-T, расположенные на N-VDS видны для vCenter и ESXi хостов как так называемые opaque networks. То есть мы видим в инвентаре иконки порт-групп NSX, можем подключать к ним VM, но не можем производить конфигурацию этих порт-групп. N-VDS не похож на своего собрата из «сферы» и не является консистентным на всех гипервизорах, как это происходит с VDS на vSphere. Конфигурации двух N-VDS, расположенных на разных Транспортных Нодах независимы. Если мы добавляем N-VDS на ESXi хосты у нас есть возможность настроить NIOC на нем, так же, как и на обычном VDS. Сделано это для того что бы была полноценная возможность мигрировать management сеть ESXi на N-VDS и при этом не потерять службу приоретизации трафика. В добавок к этому на N-VDS настраивается LLDP.

  VDS

  Начиная с vSphere 7.0 у «сферы» появилась новая версия Virtual Distributed Switch – v7. Она поддерживается NSX-T целиком и полностью и является альтернативой N-VDS, но только на ESXi хостах не старше 7.0 версии. То есть при добавлении ESXi хостов в NSX-T вы можете выбрать для обработки трафика существующий VDS v7 вместо добавления N-VDS. Наверное, понятно, что использовать VDS получиться только на ESXi и только не ниже 7.0 версии. VDS управляется вицентром и соответственно что бы добавить в NSX хост с VDS, вам нужно добавить туда сам vCenter. VDS не создается в NSX и соответственно должен уже существовать на ESXi хостах в момент их добавления в NSX. Использование VDS в разы упрощает инфраструктуру и масштабируемость. Стоит только вспомнить о том что физический сетевой интерфейс на хосте ESXi не может быть задействован в качестве аплинка в нескольких виртуальных коммутаторах одновременно и при использовании N-VDS нам придется решать как распределить физические линки – добавить их все в N-VDS и смигрировать management интерфейсы хоста на неуправляемый вицентром коммутатор (такое возможно), или же разделить их между N-VDS и существующим VDS/Standard vSwitch, на которых останется management, что очень не оптимально, а если сетевых линка только два? Да, дилемма. Ее вы избежите если у вас vSphere 7.0, и вы используете VDS v7. Management хоста останется на VDS, и виртуальная сеть NSX будет так же задействовать его для обработки трафика виртуальной сети, а также на нем могут продолжать «жить» виртуальные машины, которые не используют NSX и подключены к простым порт-группам.

  Если в инфраструктуре vSphere присутствуют хосты версии ниже чем 7.0, то на них можно развернуть N-VDS в то время как на хостах 7.0 будет использоваться VDS v7. Допускается использование разных типов виртуальных коммутаторов в одной транспортной зоне. Более того в пределах одного ESXi допускается сосуществование VDS/N-VDS/Standard vSwitch.

  

  Вот так выглядят сегменты NSX-T, реализованные на N-VDS/VDS коммутаторах в vSphere.

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

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

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

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

  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.

  

  Создание TZ простейшее действие, нам нужно задать адекватное имя для зоны и определиться какая она будет – VLAN или Overlay.

  Uplink Profiles

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

  

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

  По умолчания у нас после развертывания NSX Manager присутствуют профили по умолчанию с несколькими типовыми конфигурациями аплинков или LAG интерфейсов.

  

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

  NIOC Profiles

  

  Мы знаем, что у VDS на vSphere есть механизм приоритизации сетевого трафика по типам и называется он Network Input/Output Control (NIOC). Он конфигурируется на самом VDS в vCenter. Так вот у N-VDS есть такой же механизм и конфигурируется он с помощью NIOC Profiles в NSX-T Manager-е. На картинке изображен профиль NIOC по умолчанию и как видим он ничем не отличается от аналога на VDS.

  • NIOC работает только на ESXi хостах
  • Возможность добавить этот профиль есть только в случае с N-VDS, так как NIOC для VDS конфигурируется на vCenter.

  Мы можем создавать свои профиля со своей собственной конфигурацией. Это очень актуально если наши ESXi хосты ниже седьмой версии, и мы оснащаем их N-VDS-ом и мигрируем на него сеть управления, vSAN, vMotion и так далее.

  Transport Nodes Profiles

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

  

  1. Конфиги разбиты по разделам виртуальных коммутаторов, которые NSX будет использовать для работы. Как мы знаем на одной транспортной ноде виртуальных коммутаторов может быть несколько. И нажимая плюсик мы создаем конфигурацию для еще одного свича на Транспортной Ноде.
  2. Определяем виртуальный коммутатор – N-VDS или VDS. Если мы выбираем VDS, то он должен уже существовать в vSphere на наших ESXi хостах и его MTU должен быть не меньше 1600. Если наш выбор пал на N-VDS, то нам нужно настроить дополнительные настройки – NIOCProfile (о нем упоминали выше) и LLDPProfile. А также мы определяем дополнительные настройки в графе Mode (о них позже).
  3. Если выбрали VDS, нужно указать vCenter и имя свича. Как видим добавить новый у нас не получиться из NSX Manager-а. VDS уже должен существовать в vSphere и быть корректно настроенным (MTU).
  4. Определяем Транспортные Зоны, которые будут обслуживаться этим виртуальным коммутаторам. Мы можем сгруппировать несколько TZ на один коммутатор, либо распределить TZ по нескольким коммутаторам, создав новые.
  5. Определяем Uplink Profile.
  6. Определяем, как на TEP интерфейсы на этом коммутаторе будут назначаться IP адреса. В нашем примере адреса будут браться из IP Pool, о котором написано выше.
  7. Указываем из какого IP Pool будут браться адреса для TEP интерфейсов.
  8. В Teaming policy Uplink Mapping сопоставляем аплинки присутствующего в инфраструктуре VDS с теми, которые будет использовать NSX согласно Uplink Profile.

  Теперь для сравнения посмотрим Transport Node Profile с использованием N-VDS.

  

  1. Мы сами выбираем имя для N-VDS свича.
  2. Назначаем NIOC профиль.
  3. Определяем будет ли работать LLDP на свиче.
  4. И определяем какие физические интерфейсы хоста будут аплинками на свиче.

  Но это еще не все. Есть пара настроек, которые нужны в случае миграции management сети ESXi на N-VDS. Это нужно, когда у нас, например, только два сетевых адаптера на хосте и неправильно с точки зрения отказоустойчивости оставлять один адаптер для существующего в vSphere VDS (для management), а другой добавлять в N-VDS (для трафика NSX). Поэтому вся сеть хоста «перевозиться» на N-VDS.

  

  1. PNIC only Migration — переводим переключатель в позицию Yes в случае если ни один физический адаптер, который мы добавляем в N-VDS не используется существующим vmk интерфейсом хоста. Если же это не так, то оставляем в No и переходим к параметрам ниже.
  2. Network Mappings for Install — данная настройка определяет какой vmk интерфейс будет смигрирован в какой сегмент при установке NSX на хосте. Сегмент должен быть в VLAN TZ, так как трафик управления хостом не может находиться в Overlay.
  3. Network Mappings for Uninstall — определяет на какую порт-группу переедет vmk в случае удаления NSX с хоста.

  Добавление ESXi к NSX-T

  После того как мы настроили MTU, создали IP Pool, осознали, что такое Транспортные Зоны, добавили Uplink Profile и Transport Node Profile настало время добавить наконец хосты ESXi к NSX-T.

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

  Добавить vCenter мы можем, пройдя в System> Fabric> Compute Managers, и нажимая +. После этого откроется форма, как на картинке ниже.

  

  Все стандартно — FQDN, логин и пароль. Внизу мы можем определить несколько параметров доверия между vCenter и NSX Manager. Нужно это по нескольким определенным причинам, например, при развертывании тех же Kubernetes на vSphere. Жмем NEXT, подтверждаем сертификат и вот наш vСenter добавлен. После этого вы можете видеть кластера и хосты из добавленного vCenter в панели System> Fabric> Nodes> Host Transport Nodes, выбрав в Managed by свой вицентр.

  

  Итак, инфраструктура добавлена в NSX-T, но сам NSX на Транспортных Нодах не развернут и соответственно они не принимают участие в обработке трафика виртуальной сети. Для того что бы магия NSX заработала на них нужно его установить. Выбираем наш кластер, в нашем примере это temp, а в нем аж целый один хост, нажимаем CONFIGURE NSX. Далее выбираем Профиль Транспортной Ноды (в котором описано как хосты в кластере нужно конфигурировать, Какие Транспортные Зоны добавлять и к каким свичам), жмем NEXT и пошла установка. Установка займет какое-то время, поэтому можно пойти попить кофе.

  

  После завершения инсталляции наш ESXi хост полностью готов к работе с виртуальными сетями.

  

  Мы видим, что в интерфейсе стали видны версия NSX, установленная на хост, добавленные свичи и адреса TEP интерфейсов (их у нас два, потому что в Uplink Profile назначены два активных аплинка). На этом шаге мы закончили подготовку инфраструктуры к работе с NSX-T. Далее мы можем создавать Сегменты, Виртуальные роутеры и все прочее добро, которым изобилует NSX, и оно будет работать на нашей инфраструктуре vSphere.

  Об авторе

  Какой то инженер по виртуализации. В данном контексте это не особо важно. Вы же не за этим сюда пришли, верно?

  Похожие публикации:

  1. Искрит в щитке в подъезде куда обращаться
  2. Как выключить новости виндовс 10
  3. Как проверить баланс яндекс карты
  4. Как установить клавишу на ноутбуке