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

vladimir NSX

Для того что бы заставить виртуальные сети работать, нам нужно подготовить нашу инфраструктуру к 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
  • VLAN

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, то нам нужно настроить дополнительные настройки – NIOC Profile (о нем упоминали выше) и LLDP Profile. А также мы определяем дополнительные настройки в графе 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.