Дизайн VMware NSX-T Data Center 3.1 – Aleksandr Mykhalchenko`s Blog

Технология NSX продвигается VMware как нативный способ организации сетей для виртуальных сред. Это еще один пример гибкой программно-определенной конструкции (совсем недавно мы обсуждали задачу создания виртуального хранилища данных vSAN), но конкретно ее функционал лежит в обеспечении безопасной связи между компонентами с целью построения родной для облачных приложений среды, автоматизации рабочих процессов.

Сегодня мы будем учиться работать конкретно с NSX-T Data Center 3.1 как с фундаментом любой серьезной виртуальной среды. Узнаем, как грамотно разработать дизайн сетей и какие существуют требования и ограничения в этой области. Но, сперва, конечно же, приведем немного теоретических сведений об этой технологии, чтобы, понимать, о чем идет речь и усвоить некоторую специфическую в этом случае терминологию.

Оговоримся, материал предназначен для читателей, знакомых с понятиями виртуальной среды, построением VMware vSphere (освежить знания можно, к примеру, здесь) и принципами классических физических сетей.

О виртуальных сетях VMware NSX

Начиная обстоятельный разговор об NSX, стоит, в первую очередь, отметить два его ключевых понятия: NSX-T Data Center и Virtual Cloud Network. В отношении последнего, пожалуй, все слышали знаменитый лозунг VMware: «Any infrastructure, any cloud, any application, any platform, any device». Действительно, NSX без разницы, какую инфраструктуру или платформу обслуживать, с какими приложениями и устройствами работать, и создавалась эта технология, и это не секрет, в том числе для обслуживания облаков.

NSX-T Data Center, в свою очередь, это инструментарий для экстраполяции всего, что создавалось в частном ЦОДе, на облачное пространство. Эта платформа позволяет виртуализировать сети и сделать их безопасными, являясь комплексным решением, поддерживающим, в том числе, такие современные приложения и технологии, как Internet of Things (IoT) и контейнеры.

Для лучшего понимания возможностей и составляющих, изучим следующую схему и немного поговорим о ее компонентах:

NSX Advanced Load Balancer – служба для балансировки нагрузок мульти-облачных приложений, помогающая в автомасштабировании, безопасности, организации сети контейнеров, брандмауэра веб-приложений.

NSX Distributed IDS/IPS – усовершенствованный механизм обнаружения латеральных угроз в east-west-сетевом трафике по всем мульти-облачным средам.

NSX Service Mesh – сервис обнаружения и безопасной связи микросервисов в гетерогенной инфраструктуре.

NSX Intelligence – решение распределенной аналитики, разработанное для обеспечения прозрачности и динамического применения политик безопасности для сред NSX-T Data Center.

VMware HCX обеспечивает мобильность и гибкость приложений и сетей.

vRealize Automation и пулу Cloud-решений в будущем обязательно будут посвящены свои масштабные циклы статей.

О глобальной цели применения NSX-T Data Center сказано выше, теперь же сконцентрируемся на его возможностях. Функции этого решения для удобства можно сгруппировать таким образом:

Платформа:

- базирующееся на политиках конфигурирование,
- мульти-гипервизорная поддержка,
- поддержка Bare-metal Server,
- поддержка виртуальных машин и контейнеров,
- работа с инстансами Microsoft Azure и Amazon AWS,
- автономия от vCenter Server,
- использование пользовательского интерфейса HTML 5 на уровне управления,
- NSX Edge ноды, основанные на Data Plane Development Kit (DPDK) – форм-фактор bare-metal или ВМ,
- федерация и мультисайтовость;

Сеть:

- перекрывающие или порожденные VLAN логические свитчи,
- L2 мосты и QoS,
- распределенная маршрутизация,
- статическая маршрутизация и мультипасовая равностоимостная маршрутизация (ECMP),
- поддержка Border Gateway Protocol (BGP),
- обнаружение дублирования IP,
- двунаправленная пересылка (BFD) для быстрой конвергенции,
- VRF Lite и EVPN,
- ограничение скорости,
- многоадресная L3;

Безопасность и службы:

- файервол шлюза,
- распределенный файервол,
- сетевой самоанализ,
- защита конечной точки,
- распределенное обнаружение вторжений,
- анализ URL,
- NSX Intelligence,
- NAT и NAT64,
- DNS,
- DHCP-сервер и ретранслятор,
- Load balancer (балансировщик нагрузок),
- L2 VPN и IPSec VPN;

Автоматизация:

- API-поддержка REST/JSON,
- поддержка OpenStack и партнерской экосистемы,
- группирование безопасности на основе тегов,
- поддержка инвентаря;

Управление и администрирование:

- визард «Getting Started»,
- панели управления,
- контроль доступа, основанный на принципе ролей,
- координация обновлений,
- бэкапирование и восстановление,
- vRealize Log Insight;

Troubleshooting.

Автоматизации мы пока коснемся лишь слегка, а примеры самых животрепещущих проблем с установкой, обновлением и администрированием NSX-T Data Center 3.1 были рассмотрены в статье «Возможные проблемы при установке, обновлении и использовании VMware NSX-T Data Center 3.1».

Компоненты архитектуры NSX-Т Data Center 3.1

В плане архитектуры выделяют три глобальных уровня NSX-T Data Center:

управление,
контроль,
уровень данных:

Это разделение помогает масштабировать виртуальные сети, не затрагивая рабочие процессы.

Первые два элемента объединены в общий уровень воздействия, и они взаимодействуют с Cloud Service Manager, NSX Container Plug-in и vCenter Server. Уровень управления разработан с использованием кластеризации для облегчения процессов обработки платформой крупномасштабных параллельных запросов API. NSX Manager предоставляет REST API и веб-клиент пользовательского интерфейса для всех конфигураций юзеров. Уровень контроля отвечает за вычисление и распределение работ виртуальной сети, а также за безопасность среды NSX-T Data Center. В ней определены центральный (CCP) и локальный (LCP) уровень управления. Это разделение упрощает функционирование виртуальных сетей и масштабирование для различных конечных точек. Каждая управляющая нода в NSX-T Data Center – это специальный Аppliance с конвергентными функциями (управления, контроля и политики).

Уровень данных – это конкретные группы ESXi или KVM (Kernel-based Virtual Machine)-хостов, а также NSX Edge-нод. Такие группы называются транспортными. Именно им вменяется ответственность за распределенную пересылку сетевого трафика.

Важно! Транспортные ноды опираются на виртуальные распределенные свитчи, управляемые именно NSX (N-VDS), а не просто на распределенные виртуальные коммутаторы. Это сделано с целью отделения уровня данных от vCenter Server и нормализации сетевого подключения. ESXi-хосты под управлением vCenter Server аналогичным образом могут быть настроены на использование vSphere Distributed Switch (VDS) в процессе подготовки транспортных нод.

Ноды VMware NSX-T Edge – это служебные Appliance, предназначенные для запуска централизованных не распределяемых между гипервизорами сетевых сервисов (файервол шлюза, NAT, DHCP, VPN и распределение нагрузок). Их можно организовывать как в форм-факторе bare metal, так и как ВМ. Предусмотрена группировка нод NSX-T Edge в один или несколько кластеров, называемых пулом емкости.

Отдельно стоит выделить уровень потребления, который, хоть и не является частью NSX-T Data Center, но отвечает за интеграцию с любым CMP через REST API и интеграцию с уровнем менеджмента облаков VMware (с продуктом vRealize Automation). Уровнем потребления можно управлять напрямую через UI NSX, также интеграция доступна через OpenStack (Red Hat, VMware Integrated OpenStack и др.), Kubernetes и Pivotal Cloud Foundry.

Все операции с виртуальными сетями (создание, чтение, обновление и удаление – т. н. CRUD) выполняются на уровне управления.

NSX Manager Appliance и NSX Management Cluster

Инстансы управления и контроля объединены в автономную виртуальную машину NSX Manager Appliance со своим выделенным IP-адресом, и доступ к его управляющим процессам получается либо напрямую, либо через load balancer. Ее функционирование происходит и на уровне управления, и на уровне контроля. Также важным ее аспектом является конфигурация политик. Поэтому нет необходимости в организации различных инстансов для всех перечисленных блоков ответственности. Несмотря на то, что декларирована подобная комплексность, под каждую глобальную функцию отведены отдельные ресурсы (CPU, память и т.п.).

Три ноды NSX Manager могут быть объединены в NSX Management Cluster для улучшения доступности и масштабируемости. Всю информацию NSX Manager хранит в базе данных, которая сквозным и моментальным образом синхронизируется по всему кластеру. Благодаря этому что чтение, что операции настройки способны выполняться на любом устройстве путем задействования UI или API. Все ноды в составе кластера должны иметь одинаковую конфигурацию.

В таком кластере одна из нод непременно назначается мастером. Если на его VIP (виртуальный IP-адрес) – адрес кластера – направляется пользовательский запрос, мастер-нода должна дать ответ. В случае, когда это не происходит, среди двух оставшихся NSX Manager происходят выборы нового мастера, и после этого уже он должен ответить. И т. д.

Требования к сетевым настройкам NSX Management Cluster

Чтобы грамотно задать сетевые настройки управляющего кластера NSX, необходимо учесть ряд требований. Причем они будут коренным образом отличаться для NSX Management Cluster с VIP и NSX Management Cluster с Load Balancer. В первом случае:

Все Manager-ноды должны принадлежать одной и той же подсети;
Одна из нод назначается мастером;
VIP кластера привязан к мастер-ноде и назначается для трафика всех Manager-нод;
Отсутствует балансировка нагрузки трафика среди всех Manager-нод при использовании VIP;
Единственный VIP применяется для клиентского доступа API и GUI;
Направляемый к любой транспортной ноде трафик использует IP-адрес управляющей ноды.

Что же касается Load Balancer, API и GUI в этом случае доступны на всех Manager-нодах, все они являются активными и могут располагаться в различных подсетях, а трафик к VIP балансирует нагрузки ко множеству управляющих нод.

Требования к сетям гипервизоров сводятся к совместимости сетевых карт с версией ESXi, на которой запущен NSX-T Data Center. Сводки по конкретным картам можно посмотреть в VCG.

Уровень управления в NSX (МР)

NSX Manager получает директивы от принятой политики (подробно о ней поговорим в соответствующем подразделе ниже) и приводит в соответствие с ней конфигурацию. Также в его задачи входит публикация конфигурации в CCP, инсталляция и подготовка компонентов уровня данных, получение статистической информации от них.

Точкой входа в NSX Manager считается обратный прокси с системой аутентификации и авторизации, а за выполнение в нем самых разнообразных функций, вроде логической маршрутизации и коммутации, файерволлинга и др., отвечает Proton – основной компонент управляющей ноды. Он, как и политика, сохраняет данные в CorfuDB. Менеджер политик NSX и Proton являются внутренними веб-приложениями и общаются между собой они через HTTP. А CorfuDB представляет собой постоянное хранилище объектов в памяти, записывающее каждую транзакцию в общий соответствующий журнал:

Политики NSX

Понятие политик в NSX введено со следующими целями:

Обеспечить централизованное расположение конфигураций сети и безопасности для всей среды (для всех рабочих нагрузок – ВМ, контейнеров, серверов без ОС; в публичных облаках; для множества гипервизоров и менеджеров вычислений);
Позволить пользователям задавать желаемую конфигурацию в UI NSX;
Дать возможность юзерам указывать конечное идеальное состояние системы, не волнуясь о текущем ее статусе или лежащей в основе реализации.

Политика NSX разворачивается как часть NSX Manager Аppliance и NSX Manager является единственной поддерживаемой точкой ее применения. Между ролями управления и политикой существует однозначное соответствие. Определяется она один раз и применяется повсеместно, а ее назначение можно назвать инфраструктурно-независимым. Доступен постоянный мониторинг по политике с отличной графической визуализацией, кроме того пользователь будет получать сообщения обо всех фактах сбоев и нарушений ее работы.

В веб-клиенте NSX доступны два режима для конфигурации ресурсов:

Policy,
Manager.

Переключаться между ними можно кнопкой:

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

Уровень контроля (ССР и LCP)

NSX Controller работает с логической коммутацией, маршрутизацией и файерволлингом и следит за тем, чтобы реализация состояния системы была перманентной. Также он занимается настройкой уровня данных. В NSX-T Data Center уровень контроля разделен на центральный контрольный уровень (ССР) и локальный контрольный уровень (LCP). ССР существует как часть нод NSX Manager, а LCP – на транспортных нодах хоста или на Edge-транспортных нодах:

ССР конкретно работает с вычислением гипотетических временных рамок выполнения задач из уровня управления, доносит информацию о топологии от элементов уровня данных, используя LCP. Именно ССР знакомится с конфигурацией NSX Manager первой, и уж затем передает ее на LCP. LCP же мониторит статус локальных соединений, вычисляет гипотетические временные рамки состояния, базируясь на обновлениях информации от уровня данных и ССР, а также передает stateless-конфигурации в механизмы пересылки.

Общаются уровень управления, ССР и уровень данных между собой по протоколу NSX-RPC. Он позволяет использовать одну программу для запросов сервисов из другой программы на другом компьютере без вникания в сетевые подробности.

В распределении нагрузок уровня контроля используется механизм сегментирования. Каждая нода из управляющего кластера назначается контроллеру для L2 и L3-конфигурации, а также для дистрибуции правил распределенного файервола. По факту любой контроллер получает обновление конфигурации от уровня управления и уровня данных, однако учитывает только релевантную информацию для тех нод, к которым он прикреплен.

Одной из важных функций NSX Controller является поддержка таблиц MAC-адресов. Заполняется база данных фильтрации сегмента/логического свитча (подробнее о них см. ниже в соответствующем разделе) точно так же, как это делается в классике физических сетевых устройств, также создается центральный репозиторий полезных для поведения системы таблиц. Эти таблицы бывают двух видов:

таблица TEP с глобальными MAC-адресами,
глобальная таблица ARP, ассоциирующая MAC-адреса с IP-адресами.

Уровень данных (DP)

Уровень данных включает множество конечных точек:

ESXi/KVM-хостов,
NSX Edge.

Он состоит из разнообразных рабочих процессов, например, из виртуальных машин, контейнеров и приложений, бегающих на bare-metal-серверах. Компоненты уровня данных называются транспортными нодами и включают:

Транспортные ноды гипервизора (работает как уровень пересылки для трафика ВМ, поддерживает ESXi/KVM),
Bare-metal-транспортные ноды (включая рабочие процессы Linux и Windows на bare-metal-серверах, контейнеры на аналогичных серверах без гипервизора),
Кластер NSX Edge (предоставляют stateful-сервисы и шлюзование).

В задачи DP входит трансфер своего трафика с использованием горизонтально масштабируемой модели распределенной пересылки, а также применение логической коммутации, распределенной и централизованной маршрутизации, фильтрации файерволом. Пересылка пакетов DP происходит в соответствии с назначенными уровнем управления конфигурациями, причем, о готовой топологии он сообщает на МР. Уровень данных поддерживает статус и справляется с аварийным переключением между множеством соединений или магистралями, выполняет stateless-пересылку на основе правил, декларированных уровнем контроля, а также работает с пакетного уровня статистикой.

В пересылке пакетов ESXi использует N-VDS или VDS v7, в зависимости от версии гипервизора, а KVM – Open vSwitch. Между транспортными узлами и NSX Manager связь обеспечивается каналом Appliance Proxy Hub (APH). Он представляет собой специфическую службу на уровне управления (nsx-appl-proxy) и безопасно соединяется с транспортной нодой по описанному выше NSX-RPC через порт 1234. А для связи между DP и ССР использует порт 1235.

Логическая коммутация в NSX-Т

После того, как мы узнали о фундаменте виртуальной сети – о дифференциации ее уровней, и, следовательно, получили понимание, как все это работает в целом, логичным будет перейти к разговору о конкретике дизайна NSX-Т. Его, бесспорно, следует начинать с перечисления компонентов и объяснения используемых технологий, так как это является базой решения, и без этих знаний ни о каком успешном проектировании виртуальных сетей и их последующем развороте говорить не приходится.

С целью обеспечения связи между внутренними службами NSX-Т и разными ВМ среды продукт создает виртуальные сети L2 – сегменты.

Виртуальный коммутатор N-VDS

N-VDS является главным компонентом логической коммутации и задействован он на уровне данных. Его задача состоит в пересылке трафика между компонентами или между внутренними составляющими и физической сетью. Во втором случае в N-VDS следует организовать один/несколько pNIC на транспортной ноде.

У каждого N-VDS должен быть свой собственный физический интерфейс, однако допускается его сосуществование с другим N-VDS или vSwitch другого типа. И его использование обязательно не только для оверлейных сетей, но и для сетей с поддержкой VLAN.

На гипервизорах ESXi N-VDS внедряются решением VMware vSphere Distributed Switch (VDS), а на KVM – Open vSwitch (OVS).

В процессе создания транспортной ноды доступен выбор между двумя типами N-VDS:

стандартным,
Enhanced (The Enhanced Data Path).

Второй (расширенный путь к данным в графическом интерфейсе пользователя) представляет собой виртуальный свитч, оптимизированный для виртуализации функций сети с рабочими нагрузками, для которых важны скорость передачи пакетов и четкие требования к задержке. Оптимизация состоит в определении пути движения данных с разными моделями размещения ресурсов на хосте. О N-VDS Enhanced можно сказать следующее:

Создается исключительно на гипервизоре ESXi;
Подключается к указанному типу транспортной зоны, из-за чего не может напрямую связываться со стандартным типом виртуального коммутатора через общий оверлейный сегмент;
Очень специфично применяется в NVF.

Важно! На одном гипервизоре оба типа виртуальных свитчей могут жить совместно, даже если они не разделяют общие аплинки или транспортные зоны. Однако, в большинстве облачных и enterprise-решений подобное не рекомендуется.

Сегменты и транспортные зоны

Виртуальные домены L2 называются сегментами, и базируются они либо на VLAN, либо на Overlay.

Сегмент на VLAN – это broadcast-домен L2, реализованный по аналогии с традиционным VLAN в физической инфраструктуре. При оverlay-механике связь между двумя ВМ на разных хостах, подключенных к одному сегменту с такой поддержкой, трафик L2 передается по туннелю, организованному между хостами. Этот туннель создается NSX и поддерживается без нужды в спецификации конфигурации для конкретного сегмента физической инфраструктуры, что дает виртуальной сети статус автономной от физической.

Транспортная зона (TZ) – это объект NSX, и состоит она из сегментов. Разумеется, учитывая деление на подвиды сегментов, и транспортная зона бывает VLAN либо Overlay. К TZ подключаются транспортные ноды, в результате чего они получают доступ к соответствующему сегменту:

Для транспортных зон и транспортных узлов справедливы следующие утверждения:

N-VDS может подключаться к нескольким транспортным зонам VLAN, но только в том случае, если идентификаторы таких VLAN не конфликтуют между собой. Иначе выбирается только один сегмент для реализации подключения;
N-VDS может подключаться одновременно к нескольким VLAN и только одной overlay-TZ;
На одном хосте допускается наличие нескольких N-VDS, но каждый из них должен подключаться к различным наборам TZ;
Каждой TZ реализовывается подключение к единственному N-VDS на конкретной транспортной ноде.
Edge-нода может быть связана только с одной overlay-TZ и с несколькими VLAN-TZ.

Uplink

Восходящие каналы (Uplink) N-VDS – это логические конструкции, сопоставимые с одним или несколькими pNIC. Они объединяются в группу агрегации каналов (LAG). Между Uplink и pNIC существует принципиальная разница:

где р1, р2 и р3 – это pNIC на гипервизоре, u1 (определен как объединяющий р1 и р2 LAG) и u2 (напрямую сопоставлен с р3) – восходящие каналы в N-VDS.

Политика тиминга

Политика тиминга определяет способ использования N-VDS аплинков для уменьшения избыточности и балансировки нагрузок трафика. Эта конфигурация политики характеризуется двумя опциями:

Failover Order – активный uplink дополняется списком резервных, и в случае выхода из строя первого, следующий из доступных резервных замещает его немедленно;
Load Balanced Source/Load Balance Source Mac Address – трафик распределяется через указанный список активных восходящих каналов. Первая опция здесь обеспечивает однозначное сопоставление виртуального интерфейса и аплинка хоста. То есть трафик, посланный через определенный интерфейс будет идти только через этот uplink, и идущий откуда-либо на этот интерфейс трафик аналогично пройдет именно по этому восходящему каналу. «Load Balance Source Mac Address» помогает в процессе получения трафика с разных Mac-адресов виртуальными интерфейсами – два фрейма, к примеру, направленные одним и тем же виртуальным интерфейсом, прикрепляются к различным аплинкам хоста.

В транспортных нодах гипервизоров ESXi эта идея реализована максимально удобно. Доступно определение более конкретных политик тиминга (именных), и они способны замещать политику по умолчанию для поддерживаемого VLAN сегмента. Что касается оверлей-сегментов, для них работает исключительно дефолтная политика тиминга.

Если же говорить о KVM, их транспортные ноды могут иметь лишь одну группу LAG и работать только с опцией «Failover Order». Балансировка для них недоступна, как и настройка именных политик тиминга. Если же нужно, чтобы активными стали сразу несколько uplink на N-VDS, придется напрямую конфигурировать LAG.

Профиль Uplink

Профиль аплинка представляет собой шаблон подключения N-VDS к физической сети. В нем указываются:

формат аплинков N-VDS,
MTU (см. пояснение ниже) аплинков,
профиль Network I/O Control,
транспортная VLAN для оверлей-трафика.

К таким восходящим каналам применяется дефолтная политика тиминга.

Профиль Uplink должен задаваться в момент, когда N-VDS прикрепляется к сети (наравне со списком соответствующих локальных интерфейсов). Выглядеть он может, например, вот так:

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

Network I/O Control

vSphere Network I/O Control v3 в NSX-T реализован при помощи Network I/O Control (NIOC). Эта функция управляет конкуренцией трафика на восходящих каналах ESXi и работает для различных видов трафика с:

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

Предопределенные типы инфраструктурного трафика в ESXi:

Management – для управления хостом,
Fault Tolerance (FT) – для синхронизации и восстановления,
NFS – передача файлов в сетевой файловой системе,
vSAN – для виртуального хранилища данных,
vMotion – для миграции вычислительных ресурсов,
vSphere replication – для репликации,
vSphere Data Protection Backup – для резервного копирования данных,
ВМ – для рабочих нагрузок виртуальных машин,
iSCSI – для размещения Internet Small Computer System Interface-стораджа.

Параметры NIOC назначаются в качестве части профиля Uplink при создании транспортной ноды ESXi. Он дополнительно детализирует трафик ВМ на уровне ее vNIC и задается путем редактирования свойств vNIC.

Создание изолированных L2-сетей

Отделение логической коммутации от физической сетевой инфраструктуры является одним из главных преимуществ работы с NSX-T. Создаваемые логические сети L2 обладают той же гибкостью и маневренностью, что и ВМ, и базируются они на оверлей сегментах/логических коммутаторах.

Оверлейная модель NSX-T предлагает прямое соединение между транспортными нодами, независимо от того, как организована связь в реальности между соответствующими стойками (к примеру, L2 или L3). Сегменты при этом могут создаваться динамически, без необходимости переконфигурировать физическую сетевую инфраструктуру.

Для наглядности, сравним пример работы логических свитчей и физической коммутации. Логическая структура:

И физическая:

Потоковый трафик

Поведение сегмента NSX-T напоминает LAN в плане способности к передачи потокового трафика ко всем подсоединенным к сегменту устройствам. NSX-T не различает разные типы фреймов, реплицированных к нескольким пунктам назначения. Broadcast, неопознанная одноадресная пересылка или многоадресный трафик будут сформированы в поток аналогичным образом по всему сегменту. Оверлей-модель формирует поток из репликации фрейма на сегменте при помощи разных компонентов NSX-T.

Для потоковой передачи NSX-T предлагает два общих метода, определяемых для каждого сегмента:

Head-End-режим репликации (транспортная нода посылает копию к каждой другой транспортной ноде, подсоединенной к этому сегменту),
Двухуровневый иерархический режим (транспортные ноды группируются, исходя из подсети IP-адреса их TEP).

Важно! При Head-End репликации транспортная нода полностью перекладывает задачу на исходный гипервизор – это необходимо учитывать при выделении пропускной способности соответствующему восходящему каналу.

Важно! Двухуровневый иерархический потоковый режим рекомендован VMware как best practice, так как обычно показывает себя лучше, по сравнению с использованием пропускной способности физического аплинка.

Одноадресный трафик

Когда фрейм отправляется на неизвестный MAC-адрес, он рассылается в потоковом режиме по сети. Но, свитчи способны применять таблицу MAC-адресов или же базу данных фильтрации (FDB), связывающую маки с портами, чтобы предотвратить такую рассылку. Это обеспечивает однозначность пересылки. N-VDS поддерживает подобную технику для каждого подсоединенного к нему сегмента/логического коммутатора. Происходит либо ассоциация MAC-адреса с vNIC локально подключенной ВМ, либо удаленного TEP, если MAC-адрес находится на удаленной транспортной ноде, доступной через идентифицированный TEP туннель.

Таблицы MAC-адресов заполняются контроллером NSX-T, либо же благодаря способности к самообучению уровня данных. Второй вариант обладает массой преимуществ, так как заполнение в этом случае происходит мгновенно и независимо от того, доступен или нет уровень контроля.

Оверлей инкапсуляция

В оверлей-модели NSX-T использует Generic Network Virtualization Encapsulation (Geneve). Это проект IETF Internet Draft, построенный на концепциях VXLAN для обеспечения повышенной гибкости в процессе расширения уровня данных. Geneve позволяет любому вендору добавлять свои собственные метаданные в хедер туннеля по простой Type-Length-Value (TLV) модели.

Следует заметить, что, к примеру, при идентификации ресурса TEP фрейма NSX-T полагается на хедер туннеля, и благодаря Geneve он способен определить одиночный TLV со следующими полями:

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

TLV может изменяться или увеличиваться VMware, независимо от других вендоров. Аналогично и другие поставщики решений могут вставлять свои собственные TLV. Так как оверлей-туннели устанавливаются исключительно между NSX-T транспортными нодами, нет нужды в использовании стороннего аппаратного обеспечения или ПО в процессе декапсуляции или просмотра оверлейных пакетов.

Соединение мостом Overlay и VLAN при помощи Edge Bridge

Иногда в производственных схемах у клиентов возникают рабочие нагрузки, которые не подлежат виртуализации по причине использования конкретного приложения или лицензирования. Например, у некоторых приложений встроен неизменяемый IP-адрес, либо же используется устаревшее ПО, тем не менее требующее подключения по L2. Обычно, эти нагрузки поддерживаются VLAN и взаимодействуют с оверлейными ВМ по L3 через шлюзы Т0/Т1 NSX-T Edge. Но, некоторые сценарии имплементации требуют подключения L2 между машинами и физическими устройствами, и тогда без службы NSX-T Bridge не обойтись.

Соединение NSX-T-мостом может понадобиться в случаях:

миграции типа виртуальный-виртуальный или физический-виртуальный,
интеграции физических не виртуализируемых устройств с подключением L2 к среде (например, сервер БД в случае не валидного и неподдерживаемого L3-подключения, нужды во встроенном служебном приложении вроде балансировщика нагрузки или физического файервола).

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

В целом же, NSX-T Edge Bridge обладает следующими преимуществами и возможностями:

Производительность на базе Data Plane Development Kit (DPDK) – низкая задержка, высокая пропускная способность и масштабируемость трафика переадресации;
Расширяемость оверлейного сегмента/логического коммутатора до VLAN;

Важно! NSX-T поддерживает Virtual Guest Tagging (VGT), благодаря чему оверлейный сегмент может передавать трафик, помеченный как VLAN. Edge Bridge не предоставляет соединение мостом для такого типа трафика.

НА – Edge Bridge работает как активная/резервная служба. Edge Bridge активируется на пути данных, которые поддерживаются уникальным предопределенным резервным мостом на другом Edge. NSX-T Edge разворачивается пулом как Edge Cluster. В нем пользователь может создать профиль моста для обозначения двух Edge как потенциальных хостов для пары уменьшенной избыточности мостов. Профиль указывает, какой Edge будет основным, а какой – резервным;
Файервол Edge Bridge – к трафику, проходящему через сегмент по мосту, применяются правила файервола. Они определяются для каждого сегмента и активного инстанса моста, в целом, независимо от того, на каком Edge был запущен этот мост;
Безусловная интеграция со шлюзами NSX-T.

Важно! На распределенную природу маршрутизации NSX-T внедрение Edge Bridge влияния на оказывает. Запросы ARP от физических рабочих процессов на IP-адресацию роутера NSX (дефолтного шлюза) обрабатываются локальным распределенным роутером на Edge с активным мостом.

Логическая маршрутизация

Логическая маршрутизация на платформе NSX-T позволяет соединить виртуальные и физические развернутые в разных логических сетях L2 рабочие нагрузки. Решение создает сетевые элементы (сегменты – broadcast-домены L2 и шлюзы – маршрутизаторы) как логические конструкции ПО, встраивает их в уровень гипервизора, при этом полностью абстрагируясь от физического оборудования. Важно отметить, что возможно создание множества шлюзов в одном автоматизированном и гибком развороте.

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

В дата-центре трафик подразделяется на East-West (E-W) и North-South (N-S), основываясь на назначении и происхождении потока. N-S-трафик – это процесс общения виртуальных и физических нагрузок в дата-центре с внешними устройствами (WAN, Internet и т.п.). Трафик между рабочими нагрузками внутри дата-центра – это E-W-трафик. На практике, более 70% трафика приходится на E-W.

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

Настройка шлюзов через NSX-T Manager инициализирует локальный распределенный шлюз на каждом гипервизоре, благодаря чему трафик виртуальных машин с одного гипервизора более не должен его покидать с целью E-W-маршрутизации.

NSX-T поддерживает статическую маршрутизацию и протокол динамической маршрутизации BGP на Т0 для рабочих нагрузок IPv4/IPv6, а также создает динамический сеанс iBGP между своими SR-компонентами. Т1 статические маршруты поддерживает, однако с протоколами динамической маршрутизации не работает.

Статическая маршрутизация

В северном направлении статические маршруты могут настраиваться на Т1 шлюзах с IP-адресом следующего прыжка как IP Routerlink шлюза Т0 (100.64.0.0/16-диапазон или определенный пользователем диапазон для интерфейса Routerlink) – в деталях эти понятия обсудим ниже. Статические маршруты южного направления настраиваются на Т1 со следующим прыжком как доступное через служебный интерфейс устройство L3.

Шлюзы Т0 конфигурируются со статическими маршрутами по отношению к внешним подсетям с IP следующего прыжка физического роутера. В южном направлении статические маршруты на Т0 настраиваются по аналогии с Т1.

Для обеспечения балансировки нагрузки, устранения неисправностей и увеличения пропускной способности со статическими маршрутами поддерживается ECMP. К примеру, если у нас есть шлюз Т0 с двумя внешними интерфейсами, использующими Edge-ноду, а EN1 и EN2 подключены к двум физическим маршрутизаторам, доступна настройка двух равностоимостных статических маршрутов по дефолту для ECMP. Всего же ECMP может поддерживаться до восьми таких путей. Соответствующий алгоритм хэширования для ECMP является двухгранным и основанным на ресурсах, а также IP назначения трафика. Описанная схема может выглядеть так:

Для ускорения обнаружения сбоев следующего прыжка на статическом маршруте можно включить BFD. Он поддерживает жизнеспособность TX/RX-таймера в диапазоне от 300 до 10 000 мс. По умолчанию, значение установлено на 1 000 мс с тремя попытками.

Динамическая маршрутизация

В WAN и большинстве современных дата-центров BGP считается основным протоколом. Типичная leaf-spine-топология обладает работающим между свитчами leaf и свитчами spine eBGP. Шлюзы Т0 поддерживают eBGP и iBGP на внешних интерфейсах с помощью физических роутеров. В каждом окружении BGP для более быстрого переключения при отказах можно включить BFD. Таймеры BFD зависят от типа Edge-ноды. Edge bare-metal поддерживает не меньше 300 мс TX/RX BFD, тогда как форм-фактор Edge ВМ поддерживает минимум 1 000 мс TX/RX BFD.

Функции BGP:

Двух- или четырехбайтовые номера AS в форматах asplain, asdot и asdot+;
eBGP-поддержка множества прыжков с целью установки пиринга eBGP на интерфейсах-петлях;
iBGP;
eBGP multi-hop BFD;
Поддержка ECMP в окружении BGP с такими же или разными номерами AS;
Разрешение AS в BGP;
Поддержка агрегации маршрутов BGP с гибким объявлением сводного маршрута только для BGP пира, либо же сводного маршрута – совместно с конкретными маршрутами. Более конкретная маршрутизация прописывается в таблице маршрутизации с целью определения сводного маршрута;
Перераспределение маршрутов BGP для назначения внутренних маршрутов шлюзов Т0 и Т1;
Фильтрация входящих/исходящих маршрутов с BGP-пиром при использовании карт маршрутов или списков префиксов;
Вариативный выбор пути BGP с помощью назначения таких параметров, как «Weight», «Local preference», «AS Path Prepend» или «MED»;
Поддержка Standard, Extended и Large типов BGP;
Включение «no-advertise», «no-export», «no-export-subconfed» и других общеизвестных имен сообщества BGP в обновления путей BGP к BGP-пиру;
Возможность назначения на карте маршрутов BGP-сообществ для облегчения их сопоставления на восходящем роутере;
Full и Helper-режимы плавного перезапуска в BGP.

Одноуровневая маршрутизация

Шлюз NSX-T предлагает оптимизированную распределенную маршрутизацию и централизованную маршрутизацию, а также службы NAT, Load balancer, DHCP server и другие.

Если мы говорим об одноуровневой топологии маршрутизации, шлюз Т0 подключается к сегментам южного направления при E-W-маршрутизации и одновременно – к физической инфраструктуре для обеспечения подключения N-S. Этот шлюз состоит из двух компонентов:

распределенной маршрутизации (DR),
сервисной маршрутизации (SR).

Distributed Router (DR)

DR представляет собой маршрутизатор с логическими интерфейсами (LIF), подключенными к нескольким посетям. Он работает как kernel-модуль и распределен между гипервизорами по всем транспортным нодам, включая Edge. Традиционный функционал уровня данных по маршрутизации и ARP-поиску представлен логическими интерфейсами, подсоединенными к различным сегментам. У каждого LIF есть свой vMAC-адрес и IP-адрес, соответствующие дефолтному IP-шлюзу для логического сегмента L2. IP-адрес является уникальным для каждого LIF и остается постоянным, независимо от местонахождения сегмента/логического свитча. Ассоциированный с каждым LIF vMAC остается статичным для каждого гипервизора, позволяя дефолтному шлюзу и MAC быть одинаковыми и при vMotion:

Services Router (SR)

E-W-маршрутизация полностью распределена в гипервизоре, причем каждый гипервизор в транспортной зоне работает со своим DR. Однако ряд служб в NSX-T не распределяется, исходя из своей природы или местоположения, а именно:

подключение к физической инфраструктуре,
NAT,
DHCP-сервер,
Load Balancer,
VPN,
файервол шлюза,
соединение мостом,
Service Interface,
прокси-сервер метаданных для OpenStack.

Компонент служб (SR) создается при включении не распределяемой шлюзом службы. Для работы таких служб в НА и горизонтально масштабируемых структурах требуется централизованный пул ресурсов. Устройства, на которых хостятся такие сервисы, называются Edge-нодами. Edge-нода – это Аppliance, обеспечивающий подключение к физической инфраструктуре.

Сравним топологию логической и физической инфраструктуры с DR и SR компонентами:

Интерфейсы шлюзов Т0 при одноуровневой маршрутизации

Внешний интерфейс. Подключается к физической инфраструктуре/маршрутизатору. Поддерживается статическая маршрутизация и BGP;
Сервисный интерфейс. Соединяет сегменты VLAN для обеспечения подключения к физическим и виртуальным рабочим нагрузкам из VLAN, а также к оверлей-сегментам Т1 автономного балансировщика нагрузок. Шлюз в этом случае должен иметь компонент SR;
Intra-Tier Transit Link. Внутреннее соединение между DR и SR. Транзитный оверлей-сегмент автоматически подключается к DR и SR, и каждый конец при этом получает IP-адрес, назначенный в 169.254.0.0/25-подсети по умолчанию. Диапазон адресов можно поменять, если он где-то еще используется в сети;
Linked Segments. Интерфейс, подключающийся к оверлей-сегменту.

Двухуровневая маршрутизация

В дополнение к оптимизированной распределенной и центральной маршрутизации NSX-T поддерживает многоуровневую модель маршрутизации с логическим распределением функций маршрутизатора между провайдером и тенантом. Концепция мультитенантности является встроенной, и в ней высший уровень соответствует Т0 шлюзу, а нижний – Т1. Подобная архитектура позволяет администратору провайдера контролировать и настраивать Т0 маршрутизацию и сервисы, а администраторы тенантов, в свою очередь, могут делать то же самое на уровне Т1.

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

В северном направлении шлюз Т0 подключается к одному или нескольким физическим маршрутизаторам/свитчам L3 и таким образом обслуживает физическую инфраструктуру. В южном направлении Т0 подключается к одному или нескольким шлюзам Т1, либо же напрямую к одному/нескольким сегментам. Каждый Т1 в северном направлении соединяется с Т0, а в южном – с одним или несколькими сегментами. В результате полностью нивелируется зависимость от физической инфраструктуры, уходит надобность в ее изменении, если к дата-центру подключается новый клиент. В такой ситуации шлюз Т0 просто назначает для него новые маршруты, спецификация которых получается из клиентского шлюза Т1.

В отличие от Т0, Т1 дела с физической инфраструктурой не имеет вовсе. Он подключается напрямую только к Т0 в северном направлении, а соединение SR с Т1 инициируется исключительно при использовании централизованных сервисов, наподобие NAT, балансировщика нагрузок и т.п. В Edge-кластер шлюз Т1 помещается только в том случае, когда такие сервисы необходимы. Что же касается непосредственно процедуры подключения, она выполняется по единственному клику мыши, либо же вызовом API. Причем настройка вообще не зависит от компонентов DR и SR шлюза.

Типы интерфейсов на шлюзах Т0 и Т1 при двухуровневой маршрутизации

Выше мы обсуждали внешний и служебный интерфейсы. Вдобавок при двухуровневой маршрутизации имеет смысл поговорить об интерфейсе RouterLink:

RouterLink Interface/Linked Port – интерфейс, соединяющий Т0 и Т1 шлюзы. Каждая такая связь осуществляется в /31 подсети с зарезервированным 100.64.0.0/16 адресом (RFC6598). Создается она автоматически при первом подключении Т0 к Т1;
Внешний интерфейс – подключение к физической инфраструктуре/роутеру. В нем поддерживаются статическая маршрутизация и BGP, и существует он исключительно на шлюзе Т0 (аналог восходящих каналов, про которые рассказывалось выше);
Служебный интерфейс – соединение с VLAN-сегментами для обеспечения связи с базирующимися на VLAN физическими или виртуальными рабочими нагрузками. Он может также подключаться к оверлейным сегментам для независимого балансировщика нагрузок, и поддерживается, как Т0, так и Т1-шлюзами, настроенными с активным/резервным НА-режимом.

Важно! В случае служебного интерфейса Т0 и Т1 обязательно должны иметь SR-компонент.

Типы маршрутизации на Т0 и Т1 шлюзах

Между Т0 и Т1 нет динамической маршрутизации – вместо нее реализовано автоподключение следующих типов:

Шлюз Т0:

- Connected – подключение маршрутов на Т0, включая внешние (192.168.240.0/24) и служебные (192.168.20.0/24) интерфейсы подсети, а также сегментов подсети (172.16.20.0/24);
- Static – настроенные пользователем статические маршруты на Т0;
- NAT IP – NAT IP-адреса, полученные Т0 согласно настроенным на этом шлюзе правилам NAT;
- BGP – маршруты, полученные из BGP-окружения;
- IPSec Local IP – локальный IP-адрес конечной точки IPSec для установления VPN-сессий;
- DNS Forwarder IP – IP-адрес получателя при клиентских DNS-запросах, используемый и в качестве исходного айпишника для пересылки этих запросов на вышестоящий DNS-сервер.

Шлюз Т1:

- Connected – подключение маршрутов на Т1, включая служебные (192.168.10.0/24) интерфейсы подсети, а также сегментов подсети (172.16.10.0/24);
- Static – настроенные пользователем статические маршруты на Т1;
- NAT IP – NAT IP-адреса, полученные Т1 согласно настроенным на этом шлюзе правилам NAT;
- LB VIP – IP-адреса виртуального сервера балансировщика нагрузок;
- LB SNAT – IP-адреса из диапазона IP-адресов, используемых балансировщиком нагрузок для Source NAT;
- IPSec Local IP – локальный IP-адрес конечной точки IPSec для установления VPN-сессий;
- DNS Forwarder IP – IP-адрес получателя при клиентских DNS-запросах, используемый и в качестве исходного айпишника для пересылки этих запросов на вышестоящий DNS-сервер.

Объявление типов маршрутизации на логическом маршрутизаторе Т1 и Т0 может происходить по такой схеме:

Полностью распределенная двухуровневая маршрутизация

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

Если же смотреть с точки зрения транспортных нод, распределенный компонент DR для Т0 и Т1 шлюзов создается на двух гипервизорах:

Маршрутизация IPv6

NSX-T Data Center поддерживает дуал-стек для интерфейсов на шлюзах Т0 и Т1. Для IPv6-рабочих нагрузок пользователи могут применять распределенные сервисы вроде распределенной маршрутизации или распределенного файервола для E-W-трафика в одноуровневой или в мульти-уровневой топологии. Равно как и централизованные сервисы, вроде файервола шлюза для N-S-трафика.

Типы одноадресных IPv6-адресов, поддерживаемых NSX-T Data Center:

Global Unicast – уникальный глобально IPv6-адрес и возможность маршрутизации через интернет;
Link-Local – конкретный IPv6-адрес для связи, используемый как следующий прыжок в IPv6-протоколах маршрутизации;
Unique Local – уникальные конкретные IPv6-адреса для сайтов, используемые в связи между сайтами, однако не маршрутизируемые в интернете (RFC4193).

В компонентах NSX-T Data Center поддерживаются следующие одноадресные и мульти-адресные типы:

Компонент	Unicast IP	Multicast IP
DR	Global, Link-Local, Unique Local	Адрес всех нод (FF02::1), адрес всех роутеров (FF02::2), запрошенный для нод мульти-адресный адрес (FF02::1:FF:0/104)
SR	Global, Link-Local, Unique Local	Адрес всех нод (FF02::1), адрес всех роутеров (FF02::2), запрошенный для нод мульти-адресный адрес (FF02::1:FF:0/104)
Router Link (внутренняя транзитная связь)	Global, Link-Local, Unique Local	Адрес всех нод (FF02::1), адрес всех роутеров (FF02::2)
SR-DR Link (внутренняя транзитная связь)	Link-Local	Адрес всех нод (FF02::1), адрес всех роутеров (FF02::2)

Шлюз Т0 поддерживает следующие функции маршрутизации IPv6:

Статические маршруты с IPv6 Next-hop;
MP-eBGP с IPv4- и IPv6-семействами адресов;
Мульти-прыжковый eBGP;
IBGP;
Поддержка ECMP со статическими маршрутами, eBGP и iBGP;
Воздействие на входящие и исходящие маршруты с Weight, Local Pref, AS Path prepend и MED;
Перераспределение маршрутов IPv6;
Агрегация маршрутов IPv6;
Карта маршрутов и список префиксов IPv6.

Шлюз Т1 поддерживает статические маршруты с IPv6 Next-hop.

НА-сервисы

SR-службы работают в SR-компоненте Т0 или Т1 на Edge-ноде Edge-кластера, предоставляя централизованный сервис по доступу к физической инфраструктуре, в двух режимах:

Active/Active – НА-режим, при котором stateless-службы (пересылка L3 и др.) базируются на IP, поэтому для них не важно, которая из Edge-нод получает и ретранслирует трафик. Все SR в такой конфигурации работают с активной пересылкой. Доступно исключительно на шлюзе Т0;
Active/Standby – НА-режим, при котором только один SR работает как активный сервис пересылки. Необходим в случае включения stateful-служб и поддерживается как Т1, так и Т0 SR. Сервисы (NAT, к примеру) всегда в режиме синхронизации между активными и резервными SR на Edge-нодах.

Preemptive и non-preemptive-режимы оба доступны для Т0 и Т1. Дефолтным режимом для шлюзов, настроенных в Active/Standby НА является non-preemptive. В preemptive же пользователю необходимо выбрать предпочитаемого члена (Edge-нода), и тогда SR будет позволена активная роль на Edge-ноде, как только произойдет восстановление после отказа.

Active/Standby SR для шлюза Т1 будут иметь одинаковые IP-адреса в северном направлении. Только активный SR станет отвечать на ARP-запросы, в то время как резервные интерфейсы SR будут демонстрироваться отключенными для автоматического сброса пакетов. На шлюзе Т0 Active/Standby SR будут иметь разные IP-адреса в северном направлении и для них разрешены eBGP-сессии в обоих подключениях. И активный, и резервный SR получат обновления маршрутизации от физических роутеров, после чего предоставят для них маршруты. Однако резервный SR трижды добавляет свою локальную AS в обновления BGP, так что трафик от физических роутеров предпочтет активный Т0 SR.

IP-адреса южного направления на активных и резервных Т0 SR одинаковы, поэтому операционный статус резервного SR в этом направлении показывается в интерфейсе как отключенный. Поэтому Т0 DR не посылает никакого трафика на резервный SR.

Размещение активного и резервного SR в разрезе подключения к TOR или инфраструктуре северного направления – важный момент в дизайне виртуальной сети, так как отказ любого компонента сети не должен привести к падению и активной, и резервной службы. Разнообразие подключений к TOR для bare-metal Еdge-нод и соображения насчет доступности назначенных хостов, на которых содержатся виртуальные машины Еdge-нод, – аналогично важны.

Еdge-нода

Еdge-ноды – это не способные распространяться на гипервизоры сервисные Аppliance с пулами емкости, предназначенные для работы сети и служб безопасности. Они функционируют на компоненте SR шлюзов Т0 и Т1 и обеспечивают:

подключение к физической инфраструктуре;
NAT;
DHCP-сервер;
файервол шлюза;
балансировку нагрузки;
соединение мостом L2;
служебный интерфейс;
VPN.

При настройке любой из перечисленных служб или определении внешнего интерфейса на шлюзе Т0 на Edge-ноде создается SR. Edge-нода – это тоже транспортный узел, поэтому по аналогии с вычислительными нодами, он способен подключаться к 1+ транспортной зоне. Обычно, Edge-нода подключается к одной оверлейной транспортной зоне и, в зависимости от топологии, к одной или нескольким VLAN-транспортным зонам для N-S-соединения.

Edge-нода может обладать 1+ N-VDS в целях обеспечения связи. Каждый N-VDS использует профиль восходящего канала (pNIC или LAG), который может быть одинаковым, либо же уникальным, в каждом N-VDS. Политика тиминга, назначенная в таком профиле, определяет, как N-VDS балансирует трафик по всем своим аплинкам.

Типы Edge-нод

Edge-ноды представлены всего двумя форм-факторами:

виртуальные машины,
bare metal.

Оба используют DPDK для ускорения обработки пакетов и роста производительности. В зависимости от требований к функциональности и специфики своего разворота, они делятся на следующие типы:

Тип	Память	vCPU	Диск	Область применения
Small	4 ГБ	2	200 ГБ	PoC, LB недоступна
Medium	8 ГБ	4	200 ГБ	Производственные схемы с централизованными службами NAT, файерволом шлюза. Балансировка нагрузки может использоваться в PoC
Large	32 ГБ	8	200 ГБ	Производственные схемы с централизованными службами NAT, файерволом шлюза, балансировщик нагрузки и т.п.
Bare-metal Edge	32 ГБ	8	200 ГБ	Производственные схемы с централизованными службами NAT, файерволом шлюза, балансировщик нагрузки и т.п. Обычно разворачивается там, где нужна высокая производительность при небольших размерах пакета и желательна сверхбыстрая конвергенция N-S

Bare-metal Edge-нода

Edge-нода bare-metal-типа работает на физическом сервере и инсталлируется ISO-файлом либо загрузкой PXE. Она предоставляет сверхбыструю конвергенцию, более скоростное переключение при отказе и лучшую пропускную способность для небольшого размера пакетов. О конкретике требований к железу и рекомендациях по ее установке поговорим в статье «VMware NSX-T Data Center 3.1: Разворот с нуля». Стоит заметить, что, если желательна избыточность, для НА-уровня управления можно использовать два сетевых адаптера.

После установки, для управления будет доступен выделенный интерфейс (1G – как вариант). Также поддерживается внутриполосное управление, при котором управляющий трафик может использовать тот же интерфейс, что и оверлей, либо же внешний трафик (N-S). Bare-metal Edge-нода поддерживает до 16 физических сетевых адаптеров для оверлейного и внешнего трафика к TOR-свитчам. Для каждого из них на сервере создается внутренний интерфейс по именованной «fp-ethX» гибкой схеме. Эти интерфейсы назначаются для DPDK Fast Path и также весьма гибко управляют оверлейным или внешним подключением.

Выбор конфигурации уровня управления с Bare-metal Edge-нодой

В управлении Bare-metal Edge-нодой существует четыре главные опции:

«Out of Band»-управление с единственным pNIC. Например, нода с тремя физическими NIC и привязанным к управлению pNIC (можно 1 Гбит/с). Последний используется для отсылки/получения управляющего трафика. В этой топологии избыточность для управляющего трафика не предусмотрена, но, даже если Р1 упадет и трафик управления вместе с ним, Edge-нода продолжит работу, так как на трафике уровня данных это не отразится:

«In Band»-управление – уровень данных (fast-path) NIC, несущий трафик управления. Не обязательно иметь привязанный физический интерфейс, чтобы нести управляющий трафик – он может применять один из интерфейсов быстрых путей DPDK. Эта конфигурация доступна через CLI на Edge-ноде, где при настройке внутриполосного управления пользователю необходимо указать VLAN для управляющего трафика и MAC-адрес для интерфейса DPDK Fast Path:

Избыточность в этом случае можно настроить через LAG, однако стоит помнить, что только один член LAG способен быть активным в каждый момент времени;

Единственный N-VDS с двумя pNIC. В первом варианте этой опции, относящемся к «Out of Band»–конфигурации, взята Bare-metal Edge-нода с четырьмя физическими NIC, причем для трафика управления выделяются два адаптера (Р1 и Р2), и настроены они в режиме active/standby. N-VDS здесь несет и оверлейный, и внешний трафик, причем первый из различных оверлей-сегментов/логических свитчей прикрепляется к TEP IP1 или TEP IP2 и получает балансировку нагрузки по обоим аплинкам. Внешний трафик от VLAN-сегментов, используемых для подключения шлюза Т0 к северному направлению, также сбалансирован по восходящим каналам, благодаря политике тиминга, закрепляющей сегмент VLAN за определенным аплинком. В этой топологии обеспечивается избыточность для управления, оверлея и внешнего трафика в случае падения pNIC на Edge-ноде:

Во втором варианте мы имеем дело с «In Band»-управлением:

Единственный N-VDS с шестью pNIC. Управляющий трафик имеет два соответствующих pNIC, настроенных в Active/Standby. Два pNIC (Р3 и Р4) отобраны для оверлейного трафика, и два (Р5 и Р6) – для внешнего. N-VDS здесь используется для переноса, оверлея и внешнего трафика, но при этом задействованы разные каналы. Для балансировки нагрузки настраивается мульти-ТЕР, также в наличии две разные политики тиминга (трафик из одного внешнего сегмента VLAN направляется только на Uplink3 (сопоставлен с Р5), а из другого – на Uplink4 (что соответствует Р6). В результате BGP-трафик с Т0 на каждый из сегментов путешествует по разным TOR (Left или Right). При этом избыточность для управления, оверлея и внешнего трафика предусмотрена. Кроме того, обеспечивается высокая пропускная способность в очень простой реализации, дизайн детерминирован, так как для различных типов трафика выделены свои физические NIC:

ВМ Edge-нода

Инсталлируется Edge-нода в форм-факторе виртуальной машины OVA, OVF или ISO-файлом. NSX-T поддерживает такие ВМ исключительно на ESXi-хостах. Они обладают четырьмя внутренними интерфейсами: eth0 (управление), fp-eth0, fp-eth1 и fp-eth2 (DPDK Fast Path). Эти интерфейсы выделены для внешнего подключения к TOR-свитчам и для оверлейного туннелинга. При этом в назначении интерфейсов Fast Path допускается полная гибкость: можно назначать каждый для своего типа трафика, а можно – оба для одинакового и т. д.

Для каждого N-VDS в этом случае существует политика по умолчанию, определяющая, как он балансирует трафик по своим аплинкам. Она предопределяется и для сегментов VLAN использованием «named teaming policy». Чтобы реализовать нужное подключение (например, обеспечить инжиниринг трафика, его явную доступность и др.) может потребоваться создать более чем один N-VDS на каждой Edge-ноде. Но, у каждого такого инстанса N-VDS будет своя уникальная политика тиминга, что позволяет сделать дизайн гибким.

Выбор конфигурации с ВМ Edge-нодой

Как и в случае с bare-metal Edge-нодой, доступны несколько вариантов дизайнов Edge-ноды с виртуальными машинами. Например:

Множество N-VDS под каждую конфигурацию ВМ Edge-ноды (чаще всего в продакшене, кстати, встречается именно три N-VDS):

Конфигурация на единственном N-VDS (и для внешнего и для оверлейного трафика):

Служебные интерфейсы на шлюзах Т0 и Т1, базирующиеся на VLAN:

В первом случае не обойтись без теггирования и, конечно же, стоит хотя бы пару слов сказать о требованиях к тегам VLAN в этой связи. Рассмотренные выше схемы применяемы только при использовании одной VLAN и не позволяют добавлять сервисные интерфейсы для подключения поддерживаемых VLAN рабочих нагрузок, в которых разрешается одна или несколько VLAN на VDS DVPG (VDS-распределенная виртуальная группа портов), в случае, когда DVPG настроены для переноса множества VLAN. Именно в подобных ситуациях необходимо теггирование VLAN для Edge ВМ. И такие теги могут применяться и к внешнему, и к оверлейному трафику, что на уровне N-VDS, что на уровне VSS/VDS.

Для N-VDS профиль аплинка, где назначается транспортная VLAN, привязывается исключительно к оверлейному трафику, а для сегмента VLAN, соединяющего шлюз Т0 с внешними устройствами, применяется тег VLAN, соответствующий именно внешнему трафику.

Что касается VSS или VDS, конфигурирование теггирования VLAN может пойти тремя путями:

EST (теггирование внешнего свитча),
VST (теггирование виртуального свитча),
VGT (виртуальное гостевое теггирование).

Подробнее о теггировании можно почитать здесь и здесь.

Кластер Edge

Edge-кластер представляет собой группу транспортных Edge-нод. Кластеризация обеспечивает горизонтальное масштабирование (с помощью ECMP), резервирование и высокую пропускную способность функционалу шлюза в логических сетях. Гетерогенность Edge-нод упростила миграцию с узла на узел без операционной перенастройки логических маршрутизаторов на bare metal Edge-нодах.

Шлюзы Т0 и Т1 для Edge-нод и кластеров назначаются весьма гибко, благодаря чему их можно размещать оба на одном и том же, или же на различных Edge-кластерах:

В зависимости от перечня хостящихся на Edge-ноде служб, а также специфики их использования, такой кластер может быть выделен, в том числе, и чисто для их запуска.

Максимально в кластер можно сгруппировать до 10 Edge-нод, а Т0-шлюз в этом случае может поддерживать только восемь равностоимостных путей. Ноды в кластере с целью обнаружения отказов и в туннеле, и в управляющей сети выполняют Bidirectional Forwarding Detection (BFD). Этот протокол позволяет быстро обнаружить сбои в пересылке, улучшая конвергенцию. Edge-ВМ поддерживают BFD с минимальным таймером в 1 секунду и тремя попытками, обеспечивая трехсекундный тайминг обнаружения отказа. Bare-metal Edge поддерживают BFD с минимальным TX/RX-таймером в 300 мс с тремя попытками, в результате чего отказ обнаруживается за 900 мс.

Failure Domain в Edge-кластере

Failure Domain – это логическое группирование Edge-нод внутри одного кластера. Эта функция может включаться на уровне кластера через API. Ранее в подразделе о active/standby НА обсуждалось, как NSX автоматически выбирает ноду для запуска активной или резервной Т1 SR. Failure Domain дополняет алгоритм автозамещения и гарантирует доступность сервиса в случае отказа стойки. Важно помнить, что активный и резервный экземпляры Т1 SR всегда должны работать на разных доменах отказа. Однако, если выбор был сделан в пользу preemptive-режима, все активные Т1 SR можно поместить в один failure domain в принудительном порядке.

Вот простейшая схема организации failure domain в кластере с четырьмя Edge-нодами:

Мульти-ТЕР поддержка на Edge-ноде

Начиная с версии 2.4, NSX-T Edge-ноды поддерживают множественные оверлейные туннели (мульти-ТЕР). Эта конфигурация позволяет балансировать оверлейный трафик для соответствующих сегментов/логических свитчей, и работает она как на ВМ, так и на bare metal.

Рассмотрим, как они могут использоваться на примере двух ТЕР, сконфигурированных на bare metal Edge. Каждый оверлейный сегмент/логический свитч привязан к определенному IP-адресу конечной точки туннеля – TEP IP1 или TEP IP2. Любой ТЕР при этом использует собственный восходящий канал (TEP IP1 – Uplink1, сопоставленный с pNIC P1, а TEP IP2 – Uplink2, сопоставленный, соответственно, с pNIC P2):

Для поддержки мульти-ТЕР следует соблюсти следующие требования:

Конфигурация ТЕР должна производиться на одном и только одном N-VDS;
Все ТЕР должны иметь одинаковую транспортную VLAN для оверлей-трафика;
Все IP ТЕР должны быть в одной и той же подсети и использовать общий дефолтный шлюз.

Другие сетевые сервисы

В обсуждении опорных для дизайна NSX-T Data Center компонентов не раз упоминались преобразование сетевого адреса, службы DHCP, прокси-служба метаданных и файервол шлюза. Службы эти очень важны и поистине незаменимы в ряде разворотов, поэтому завершая разговор об архитектуре решения скажем и о них пару слов.

Преобразование сетевого адреса

В NSX-T пользователи могут включить NAT в качестве сетевой службы. Это централизованный сервис, доступный и на Т0, и на Т1 шлюзах. Типы NAT:

SNAT (Source NAT) – транслирует IP ресурсов исходящих пакетов в известный публичный IP-адрес для облегчения взаимодействия приложения с внешним миром без использования его приватного адреса. Одновременно отслеживается ответ;
DNAT (Destination NAT) – дает доступ к внутреннему частному IP-адресу из внешнего мира путем преобразования IP-адреса назначения, когда инициируется входящая связь. Аналогично заботится об ответе;

Важно! И к SNAT, и к DNAT пользователи могут применять правила, базирующиеся на пяти критериях соответствия.

Reflexive NAT. Правила Reflexive NAT – это двунаправленные stateless-ACL. Они не занимаются отслеживанием связи, но полезны в случаях, когда stateful-NAT не может применяться по причине асимметричности путей (например, если необходимо включить NAT на active/active ECMP маршрутизаторах). Применяется исключительно на Т0 шлюзах.

Важно! В отношении первых двух типов (типов stateful-NAT), ситуация с применением правил к Т0 показана для PAS/PKS разворотов, ведь в этом случае E-W-маршрутизация между различными тенантами остается полностью распределенной. Что же касается Т1, подобное рекомендовано использовать для ECMP-топологий лишь с высокой пропускной способностью.

Каждый раз, когда включается NAT, сервисный компонент или SR должен создаваться на Edge-кластере. В настройках NAT следует указать такой кластер. Если этого не сделать, платформа выполнит автопомещение служебного компонента в Edge-ноду кластера по алгоритму взвешенного циклического перебора.

Службы DHCP

NSX-T предоставляет функционал и ретрансляции DHCP, и DHCP-сервера. Ретранслятор включается на уровне шлюза и работает как переключатель между управляемой средой (не NSX) и DHCP-серверами. DHCP-сервер, в свою очередь, обслуживает соответствующие запросы от виртуальных машин, соединенных с управляемыми NSX сегментами, и обладает всеми качествами stateful-службы. Обязательна ее привязка к Edge-кластеру или указанной паре Edge-нод, по аналогии с NAT.

Прокси-служба метаданных

Благодаря прокси-серверу метаданных инстансы ВМ могут получать специфические метаданные из сервера OpenStack Nova API. Функция работает только с OpenStack, и она так же является службой на NSX Edge-ноде. Настройка сервиса метаданных включает НА, если она произошла на двух и более нодах Edge-кластера.

Файервол шлюза

Служба файервола может включаться на шлюзах Т0 и Т1 для N-S-файерволлинга. При этом stateful-файервол доступен для обоих типов шлюзов, а вот stateless – исключительно для Т0, и обычно он применяется в active/active-режиме. По аналогии с другими централизованными службами, файерволлинг работает тоже только в Edge-кластере или же в наборе Edge-нод. Подробнее о нем поговорим ниже в разделе «Безопасность в NSX-T».

О дизайне топологии NSX-T

После того, как мы разобрались в первом приближении с архитектурой NSX-T, изучили возможности и специфику отдельных его компонентов и процессов, стоит рассмотреть use cases строящихся на этих принципах топологий. Ведь мало построить дизайн топологии, опираясь на ожидания от функционала виртуальной сети, – нужно еще и отсеять неподдерживаемые платформой варианты, и понимать, каковы при этом будут критерии отбора.

Поддерживаемые NSX-T топологии

Рассмотрим три варианта (весьма распространенные на практике, кстати) фундаментально отличающихся друг от друга топологий, работающих с подключением трафика N-S через несколько Edge-нод:

Одноуровневая с прямым подключением шлюза Т0 к сегментам и заданной маршрутизацией E-W между подсетями. Шлюз Т0 разрешает множество активных путей для N-S L3-пересылки с использованием ECMP:

Многоуровневая с предоставлением шлюзом Т0 множества активных путей для L3-пересылки с использованием ECMP, а шлюзы Т1 здесь применяются как первый прыжок для подключенных к ним сегментов. В этой топологии маршрутизация полностью распределенная:

Многоуровневая со шлюзом Т0 в Active/Standby НА-режиме для предоставления ряда централизованных или stateful-сервисов, вроде NAT, VPN и др.:

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

NAT, балансировщик нагрузки на Т1-шлюзе, Т0 поддерживает множество активных путей L3-пересылки с использованием ECMP:

Все централизованные сервисы реализованы не только на Т1, но и на Т0:

Помимо этих случаев интересными могут быть и такие:

Соединенные между собой по внешнему интерфейсу шлюзы Т0. «Tenant-1 Tier-0 Gateway» настроен под stateful-файервол, а «Tenant-2 Tier-0 Gateway» – под stateful-NAT. Оба – в Active/Standby НА-режиме. Верхний уровень шлюза Т0 («Aggregate Tier-0 Gateway») предоставляет ECMP для N-S-трафика. Для обмена маршрутами между двумя шлюзами Т0 поддерживаются статическая маршрутизация и BGP.

Важно! Для оптимальной пересылки трафика рекомендуется полная зацикленность сети.

В этом случае обеспечивается высокая пропускная способность N-S с централизованными stateful-службами, работающими на разных Т0, а также полное разделение таблиц маршрутизации на уровне тенанта шлюза Т0, что позволяет использовать ECMP в северном направлении только для доступных на Т0 служб. На Т1 доступен VPN:

Соединенные между собой по внешнему интерфейсу шлюзы Т0. «Corporate Tier-0 Gateway» на первом Edge-кластере предоставляет связь с корпоративными ресурсами (подсеть 172.16.0.0/16), полученную через пару физических маршрутизаторов. На Т0 включен stateful-файервол, чтобы регулировать доступ пользователей. «WAN Tier-0 Gateway» на втором Edge-кластере предоставляет WAN-связь через соответствующие роутеры и аналогично сконфигурирован под stateful-NAT. «Aggregate Tier-0 gateway» на третьем Edge-кластере получает специфические маршруты для корпоративной подсети (172.16.0.0/16) из «Corporate Tier-0 Gateway» и маршрут по умолчанию от «WAN Tier-0 Gateway». «Aggregate Tier-0 Gateway» предоставляет ECMP и для корпоративного, и для WAN трафика, исходящего от любых подключенных к нему сегментов, или же от подключенных к южному направлению Т1. Здесь аналогично рекомендована полная зацикленность сети для оптимальной пересылки трафика:

Не поддерживаемые NSX-T топологии

Ряд топологий по причине конфликта с базовыми принципами NSX-T не поддерживаются. Приведем их примеры:

Шлюз Т1 напрямую подключен к физическому роутеру:

Шлюз Т1 тенанта напрямую подключен к шлюзу Т1 другого тенанта:

Важно! Если необходимо настроить общение между двумя тенантами, необходимо маршрутизировать между ними обмен данными на шлюзе Т0.

Шлюз Т1 соединен с двумя разными вышестоящими Т0-шлюзами:

Безопасность в NSX-T

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

Примеры использования безопасности NSX-T

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

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

Интересно, что возможности NSX в этом плане не ограничиваются гомогенными средами vSphere, так как этот продукт гетерогенен по своей природе, что в отношении платформ, что в разрезе инфраструктуры.

Микросегментация в NSX-T поддерживает архитектуру с нулевым доверием, устанавливая периметр безопасности вокруг каждой рабочей нагрузки контейнера или каждой ВМ с динамически определяемыми политиками. Таким образом она борется не только с внешними угрозами (N-S), но и с внутренними (E-W).

Конечно, zero-trust-модель при традиционном подходе к организации сетевой безопасности может быть чересчур дорогостоящей, сложной и обременительной для руководства. К тому же недостаток ее прозрачности иногда служит причиной торможения реализации такой архитектуры, а также оставляет лазейки, многие из которых, к сожалению, выявляются исключительно после того, как ими воспользовались. Еще одним недостатком традиционных методов считается их неспособность продвинуться в детализации дальше VLAN или подсети. Но, NSX-T в этой связи разработал собственные уникальные механизмы, нивелирующие все эти минусы.

Архитектура и компоненты Distributed Firewall (DFW)

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

DFW на уровне управления

Как уже было отмечено выше в разделе про архитектуру NSX-T, в целом, уровень управления реализуется через NSX-T Manager, представляющий собой разворот кластера из трех управляющих нод. Доступ к нему организован посредством GUI или REST API. Когда настраивается правило политики файерволлинга, служба уровня управления приводит в соответствие с ним свою конфигурацию и локально сохраняет существующую копию. После этого она отправляет опубликованные пользователем политики на уровень контроля, который, в свою очередь, пересылает их дальше – на уровень данных.

Стандартная конфигурация DFW-политик состоит из одной или нескольких секций с наборами правил, использующих объекты, вроде «Group», «Segment», и приложения уровня шлюза (ALG). Для мониторинга и траблшутинга NSX-T Manager взаимодействует с агентом уровня управления на базе хоста (MPA) для получения статуса DFW совместно с конкретным правилом и потоком статистики. Кроме того, он также собирает инвентарь из всех размещенных виртуализированных рабочих нагрузок на транспортных нодах динамическим образом и постоянно обновляет эту информацию.

DFW на уровне контроля

Ранее мы уже обсуждали состав уровня контроля NSX-T (CCP и LCP), а также упоминали, что CCP разворачивается на кластере NSX-T Manager, тогда как LCP включает в себя модуль пользовательского пространства на всех транспортных нодах. Этот модуль взаимодействует с CCP для обмена настройками и информацией о статусе.

С точки зрения политик DFW, уровень контроля получает правила этих политик от уровня управления. Если политика состоит из объектов (включая сегменты или группы), он переводит их в IP-адреса, используя таблицу сопоставления объектов с IP. Эта таблица поддерживается уровнем управления и обновляется с помощью механизма обнаружения IP. Когда политика преобразовывается в набор правил на основе IP-адресов, CCP транслирует их в LCP на всех транспортных нодах.

CCP применяет иерархическую систему для распределения нагрузок своей коммуникации с LCP. Ответственность за оповещение транспортных нод распределяется по всем управляющим кластерам, опираясь в этом процессе на внутренние механизмы хэширования. К примеру, если у нас всего 30 транспортных нод и управляются они тремя менеджерами, каждый менеджер будет ответственен лишь за свой десяток.

DFW на уровне данных

Транспортные ноды NSX-T составляют распределенный уровень данных, для которых принудительное выполнение DFW задается на уровне ядра гипервизора. В любой момент времени каждый транспортный узел подключается только к одному менеджеру CCP, опираясь на принципы мастерства для него. Транспортная нода, как только LCP получает конфигурацию политики от CCP, переводит политику файервола и правила на фильтры уровня данных (в ядре) по каждому виртуальному NIC. С полем «Applied To» в правиле или секции (определение области применения) LCP убеждается в том, что только релевантные нормы DFW запрограммированы на соответствующих виртуальных NIC. Это гораздо оптимальней, чем применение каждого правила везде.

Дополнительные функции безопасности

Помимо DFW и микросегментации в NSX-T доступен ряд дополнительных функций для совершенствования уровня безопасности дата-центра:

SpoofGuard – обеспечение защиты от спуфинга с привязкой MAC+IP+VLAN. Реализуется на уровне логического порта;
Безопасность сегмента – внедрение безопасности L2 и L3 для защиты целостности сегмента путем фильтрации вредоносных атак (к примеру, от отказа служб при использовании широковещательных/многоадресных штормов), а также от несанкционированного трафика при входе в сегмент от ВМ. Реализуется через прикрепление профиля безопасности сегмента к сегменту с принудительным применением. Профиль безопасности сегмента обладает параметрами для разрешения/блокировки юнита протокола данных (BPDU), серверного/клиентского трафика DHCP, не IP-трафика. Этот механизм позволяет ограничивать скорость многоадресного и broadcast-трафика, как переданного, так и полученного.

Балансировка нагрузки в NSX-T

Балансировщик нагрузки в NSX-T – это виртуальная служба или сервер с собственным VIP-адресом и UDP/TCP-портом. Он является внешним приложением, отделенным от физической реализации: полученный им трафик может распределяться по другим подсоединенным по сети устройствам, результирующая работы которых эквивалентна обработке данных самим виртуальным сервером. Преимуществ у данной возможности масса, в том числе касающихся обеспечения НА:

а также горизонтального масштабирования приложений:

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

И сейчас нам предстоит обстоятельный разговор об архитектуре Load Balancer и режимах его развертывания.

Архитектура балансировщика нагрузки (LB)

Логическое представление архитектуры LB хорошо демонстрирует следующая схема:

Опишем ее компоненты:

LB. Работает на уровне шлюза Т1 и к одному шлюзу может подключаться только один балансировщик нагрузки;
Virtual Server. На LB пользователь может определить один или несколько виртуальных серверов (точное количество зависит от форм-фактора опции, и подробнее мы о нем поговорим в статье «Настройка и администрирование VMware NSX-T Data Center 3.1»). VS характеризуется VIP и номером порта TCP/UDP (например, IP: 20.20.20.20 TCP port 80). Каждый виртуальный сервер может иметь базовые или расширенные опции LB, вроде пересылки определенных клиентских запросов, перенаправления их на внешние сайты или их блокировки;
Pool. Конструкция, группирующая серверы, которые хостят одинаковые приложения. Группировка настраивается с применением IP-адресов серверов или «Group» для большей гибкости. Расширенные правила балансировщика нагрузки позволяют VS перенаправлять трафик в несколько пулов;
Monitor. Монитор определяет, как LB проверяет доступность приложения. Диапазон тестов ширится от базовых запросов ICMP до проверок на соответствие шаблонам в сложных запросах HTTPS. Здоровье каждого члена пула после этого приводится в соответствие путем простой проверки (ответ сервера), или же более сложными способами, например, проверкой на наличие в ответе веб-страницы определенной строки. Мониторы определяются пулами: каждому пулу сопоставляется лишь один монитор, однако один монитор может использоваться различными пулами.

Режимы разворота LB

LB весьма гибок и может инсталлироваться как в традиционной in-line, так и в one-arm-топологии.

В первом режиме – простейшем – клиенты и сервера пулов располагаются по разные стороны LB:

В этом случае нет необходимости в выполнении какого бы то ни было LB SNAT. Преимущество модели состоит в том, что члены пула напрямую идентифицируют клиентов по исходному и передаваемому без изменений IP. LB при этом создается на SR Т1 шлюза как централизованная служба. Однако минус разворота в том, что на Т1 теперь будет централизованный компонент, и трафик E-W для сегментов за разными Т1 будет прикреплен к Edge-ноде в порядке доступа к SR. Причем такое будет применяться даже к тому трафику, которому не суждено пройти через LB.

One-arm-режим разворота говорит о том, что и клиентский трафик (трафик к VIP LB), и серверный (от LB к серверу) используют один и тот же интерфейс. При этом LBSNAT применяется для уверенности, что обратный путь трафика от сервера к клиентам в действительности пройдет через LB. В этом режиме доступны два сценария действий, когда оба клиента – серверы одной подсети:

или же они принадлежат к разным:

И там, и там решение использует источник NAT для того, чтобы убедиться в направлении трафика к LB на пути от сервера к клиентам. В результате сервер не знает о настоящих IP-адресах клиентов.

Кстати, в первом случае получаем ту же проблему в итоге, что и в in-line-режиме: централизованная служба требует SR Т1, что вызывает трафик E-W для сегментов позади различных Т1, прикрепляя их к Edge-ноде. При принадлежности клиентских серверов к разным подсетям шлюз Т1 не запускает службу LB – вместо этого она разворачивается как автономный шлюз Т1 с единственным сервисным интерфейсом. Шлюз при этом является устройством, которое создает инстанс LB, и благодаря этому несколько сегментов, расположенных ниже главного шлюза Т1, способны обладать своими собственными выделенными LB.

Преимущества последней модели в гораздо более эффективном горизонтальном масштабировании, а также в гибкости назначения ресурсов LB за счет потенциального создания нескольких дополнительных SR Т1 на ряде Edge-нод. Однако E-W-трафик для сегментов позади разных шлюзов Т1 все еще может быть распределен.

Но, если one-arm LB присоединить к физическим VLAN-сегментам, служба будет работать даже для приложений во VLAN:

При этом интерфейс Т1 также используется и служебным интерфейсом, однако в этот раз подсоединенным к VLAN-сегменту вместо оверлейного.

НА балансировщика нагрузки

Модель НА LB наследует дизайн Edge. В классической схеме НА Edge, если вторая Edge-нода выходит из строя, резервный SR на первой Edge-ноде вместе со связанным с ним балансировщиком нагрузки становится активным в тот же миг. Кроме того, между Edge существует второй messaging-протокол – управляемая опция (не периодическая) и действительная для каждого приложения. Благодаря этому, если отказывает LB SR Т1 на первой Edge-ноде, аварийно переключится только то, что затронуто падением, не касаясь прочих сервисов.

Служба активного LB всегда синхронизирует с резервным аналогом свой статус, а также следующие состояния:

потока L4,
сохранения IP-адреса источника,
монитора.

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

Комбинация LB с другими SR-службами (NAT и файервол)

Начиная с версии 2.4 NSX-T, балансировщик нагрузки можно вставить в сервисную цепочку наряду с NAT и централизованным файерволом, в порядке очередности NAT – файервол – LB:

Федерация

Функция федерации в NSX-T Data Center позволяет поддерживать согласованность между несколькими дата-центрами и добиться простоты реализации сценариев аварийного восстановления. Доступна она исключительно собственникам Enterprise+-лицензий. Предваряя разговор о ней, стоит огласить ряд специфических терминов, плотно вошедших в жизнь сетевого виртуализатора, начиная с версии 3.0 продукта.

Local Manager (LM) – система, отвечающая за сетевые службы и службы безопасности для локации.

Global Manager (GM) – система, объединяющая несколько LM.

Location – объект сети или безопасности, посланный в конкретную единственную локацию.

Global – объект сети или безопасности, посланный во все локации.

Region – объект безопасности, посланный в одну или множество локаций, которые являются частью одного и того же региона (например, EMEA).

Важно! Регионы не применяются к сетевым объектам.

Локальный Т0/Т1/сегмент – Т0/Т1/сегмент со спаном одного LM.

Растянутый Т0/Т1/сегмент – Т0/Т1/сегмент со спаном более чем одного LM.

Primary или secondary Т0/Т1 – Т0 или Т1 с N-S, работающим в одной локации.

All_Primaries Т0/Т1 – Т0 или Т1 с N-S, работающим во всех локациях.

О ТЕР и RTEP мы рассказывали выше, но напомним, вкратце:

ТЕР – IP транспортной ноды (Edge или гипервизор) для Geneve-инкапсуляции в локации;

RTEP – IP транспортной ноды (Edge или гипервизор) для Geneve-инкапсуляции по всем локациям.

Преимущества использования федерации состоят в следующем:

Операционная простота для NSX-T Data Center и NSX Cloud;
Унификация конфигурации политик и применения;
Упрощенный DR.

Первая ВМ GM разворачивается по аналогии с первыми ВМ LM – через «NSX-T Manager OVA». А уже вторые и все последующие – либо через тот же OVA, либо из пользовательского интерфейса. При этом все функции NSX Manager (Manager VIP, синхронизация между NSX Manager и членами кластера и т. п.) доступны и работают одинаково. Но, служба GM функционирует исключительно на ВМ GM.

Важно! Федерация NSX-T Data Center относится к числу полностью организуемых решений с помощью:

Сторонней организации (Tanzu Kubernetes Grid Integrated Edition, vRealize Automation, vRealize Orchestration, VMware Integrated OpenStack или OpenStack, vCloud Director);
Пользовательской организации (NSX API, Terraform, Ansible);
Плагином GM под конкретное решение организации (индивидуально).

На множестве локаций режим Active/Standby НА при этом выглядит так:

Сеть и безопасность централизовано конфигурируют маршрутизатор и Primary на первой локации. И если она падает, в случае, когда GM Active потерян, активирует GM Standby, затем производится аварийное переключение T0/T1 DR, а SRM восстанавливает вычисления на второй локации (не связанной с NSX):

Последовательность политики безопасности при этом хорошо иллюстрируется диаграммой:

И ее конфигурирование опирается на следующие тезисы:

GM-группы могут быть глобальными, локальными или региональными;
Группы способны быть динамическими на основе тега любой динамической информации;
Правила файервола могут миксовать группы или спаны.

Безопасность федерации в NSX-T предлагается для ВМ/контейнеров, соединенных с сегментами NSX-T (VLAN/оверлей), и используется любым динамическим членством (имя, теги и др.), созданным GM и LM.

Сетевая топология Т0/Т1 GM, поддерживаемая в NSX-T Data Center 3.1 позволяет спанам быть Local или Stretched, и при этом Т1-спаны равны либо являются подмножеством спанов Т0 (как вариант Т1 DR-спан равен присоединенному Т0-спану). В этой топологии доступны службы GW-NAT, GW-FW, IPv6 и DHCP/DNS. В отношении сегментов топологии, для их реализации необходимо подключение Т0 или Т1, а также спан (равный спану Т0/Т1).

Важно! DHCP на растянутом сегменте поддерживает исключительно статические привязки DHCP.

Для поддержки федерации среда должна выполнить следующие требования:

Между локациями задержка не превышает 150 мс;
И на всех LM, и на GM следует проинсталлировать NSX-T Data Center 3.1;
Необходимые порты должны быть открыты для организации коммуникации между GM и LM.

Если не используется NAT, подключение следует осуществить между: GM и LM, LM и удаленным LM, Edge-нодой RTEP и удаленной Edge-нодой RTEP. Никаких требований при этом к пропускной способности WAN, а также MTU WAN не существует (разве что, желательно отсутствие перегрузок трафика для уровня управления и уровня данных, и рекомендовано 1 700+ MTU, чтобы избежать фрагментации трафика edge-ноды RTEP).

Важно! GM поддерживает только режим «Policy». Режим «Manager» в федерации не поддерживается.

Превалирующее большинство конфигураций кластера LM обладает теми же максимумами, что и кластер NSX Manager (о них подробно поговорим в статье «VMware NSX-T Data Center 3.1: Разворот с нуля»).

Общие рекомендации по проектированию NSX-T

Все необходимые базовые знания о дизайне NSX-T мы постарались озвучить. Настало время перейти к ряду практических общих рекомендаций по проектированию виртуальных сетей.

Концептуально, задача проектирования сетей NSX-T сводится к следующим опорным моментам:

Обеспечить подключение компонентов уровня управления и контроля (NSX-T Manager);
Спроектировать NSX-T Edge и соответствующие кластера;
Организовать вычислительные домены и ресурсы виртуальных сетей.

Физическая инфраструктура дата-центра

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

Итак, главные требования к физической сети включают в себя:

IP-соединение. Оно существует между всеми компонентами NSX-T и вычислительными хостами. Включая управляющие интерфейсы на хостах, равно как и на Edge-нодах (bare metal/ВМ);
Поддержка Jumbo Frame. Минимальный требуемый MTU составляет 1 600, однако рекомендовано значение 1 700 и уверенность, что в будущем среда будет готова к расширению хедера Geneve;

Важно! Если речь идет о реализации N-VDS, значение MTU должно быть не меньшим 9 000, без учета накладных расходов.

MTU виртуальной машины. Типичное развертывание гостевой ВМ определяет MTU на уровне 1 500 байт. Рекомендуется заложить значение в 8 800, что покроет и вероятное расширение заголовка в случае увеличения пропускной способности машины.

Важно! От увеличения размера MTU выигрывают такие процессы, как репликация, резервное копирование, а также чисто внутренние приложения, но, в этом деле следует соблюдать осторожность, так как все, что выбивается за рамки трафика TCP (UDP, RTP, ICMP и пр.), а также трафик, которому следует путешествовать через брандмауэр или служебные приложения, DMZ, Internet могут работать не так, как надо.

Как только эти требования удовлетворены, можно разворачивать NSX на:

Любом типе физической топологии – core/aggregation/access, leaf-spine и т.п.;
На любом свитче от любого вендора физических коммутаторов, включая устаревшие модели;
С любой нижестоящей технологией. Подключение по IP может быть достигнуто путем сквозного соединения сети L2, а также во всей полностью маршрутизированной сети.

Чтобы работа NSX-T в итоге была удовлетворительной, а дизайн – оптимальным, стоит учесть еще несколько фундаментальных стандартов:

Доступность устройства (хоста, уровня стойки, TOR, например);
Пропускную способность направлений хост – TOR и в аплинках TOR;
Согласованность операционного домена и домена отказа (к примеру, локализация пиринга Edge-ноды в северном направлении сети, разделения хостов доменов вычислений и пр.).

Для примера рассмотрим маршрутизированную leaf-spine-архитектуру. Эта модель, считай, является обобщающей для многих других сетевых топологий и конфигурационных структур, поэтому ее концепция применима также и к L2 или к не leaf-spine-топологиям:

Здесь структура L3 очень выгодна, так как легко настраиваема с обычными маршрутизаторами, сокращая спан L2 доменов до единственной стойки. Насчет L2 также сложно высказаться против, так как для него на свитче TOR не будет L2/L3-границ. Несколько вычислительных стоек настроены под размещение вычислительных гипервизоров (ESXi, KVM) для приложений виртуальных машин. Обычно, вычислительные стойки отличаются такой же структурой и таким же подключением, как и «cookie-cutter»-разворот. Что же касается вычислительных кластеров, их расположение – горизонтальное между стойками с целью защиты от падений стоек и потери связи.

Под инфраструктуру спроектировано несколько стоек, и на них содержатся:

Управляющие элементы (например, vCenter, NSX-T Manager, OpenStack, vRNI и т.д.);
Bare-metal Edge или ВМ Edge-ноды;
Элементы кластеризации (распределены между стойками, для обеспечения устойчивости к сбоям).

Разные задействованные в NSX-T компоненты посылают в сеть различные виды трафика, и обычно эти виды классифицируются при помощи использования отличающихся VLAN. Гипервизор, к примеру, посылает управляющий, трафик хранилища и vMotion, и все они будут использовать три разных тега VLAN. Так как именно эта физическая инфраструктура ограничивает L3 на TOR-свитче, спан всех VLAN лимитирован до единственной стойки. Управляющий VLAN на одной стойке не является тем же широковещательным доменом, что и управляющий VLAN на другой стойке, так как ему не хватает подключения L2. Для упрощения настройки одинаковый идентификатор VLAN, обычно, назначается единообразно по всем стойкам для каждой категории трафика. VLAN и IP подсетей для упомянутых видов трафика, к примеру, могут выглядеть так:

SVI Interface	VLAN ID	IP Subnet
Управление	101	10.101.Rack_ID.0/24
vMotion	102	10.102.Rack_ID.0/24
Хранилище	103	10.103.Rack_ID.0/24
Оверлей	104	10.104.Rack_ID.0/24

При небольших развертываниях NSX-T эти элементы могут комбинироваться в меньшем количестве стоек.

Проектирование вычислительного кластера (ESXi/KVM)

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

Вычислительные гипервизоры размещают виртуальные машины приложений в дата-центре. В типичном корпоративном дизайне они переносят, минимум, два вида трафика на разных VLAN – управляющий и оверлейный. Так как задействован оверлейный трафик, аплинки подчиняются вышеуказанным требованиям к MTU. Кроме того, в зависимости от типа гипервизора, вычислительные хосты могут переносить дополнительный трафик, вроде трафика стораджа (VSAN, NFS и iSCSI), vMotion, НА и др. ESXi-гипервизоры определяют специфические VMkernel-интерфейсы для такого инфраструктурного трафика, как правило, подключенные к отдельным VLAN. Аналогично, кстати, и для гипервизоров KVM. Больше узнать о требованиях к таким гипервизорам и их возможностях можно в соответствующей документации вендоров.

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

Обобщенная организация трафика и возможности N-VDS

Благодаря гибкости профилей аплинков и типов тиминга (обсуждалось выше в разделе архитектуры), NSX-T предоставляет выбор в процессе управления инфраструктурой и гостевым ВМ-трафиком (оверлейным или VLAN). Обычно, управляющий трафик преследует одну из двух масштабных целей для обеспечения доступности:

Оптимизацию всех доступных сетевых адаптеров. В этом случае все типы трафика расшариваются между доступными pNIC. Предполагается, что при этом можно избежать «горячего» трафика во время пиков/всплесков, а вероятность конкуренции снижается из-за количества каналов и предложенной скорости. Такой тип управления трафиком неплох для каналов со скоростью 25 Гбит/с и выше. При менее скоростных pNIC, может понадобиться включить некоторые инструменты управления трафиком, например, NIOC. Кстати, примером такой стратегии может служить трафик vSAN. Тип тиминга при этом выбирается как «Load Balanced Source Teaming»;
Детерминированный трафик на каждом pNIC. Происходит назначение определенного типа трафика определенному pNIC, благодаря чему данному типу трафика обеспечивается выделенная пропускная полоса. Вдобавок, это позволяет детерминировать отказы, как если бы один или более каналов находились в резервном режиме. Опираясь на количество pNIC, можно спроектировать такую схему управляющего трафика, при которой удается избежать конкуренции между двумя потоками с высокой пропускной способностью (VSAN vs vMotion, к примеру), а также высоко-интерактивного трафика вроде транзакций или интернета. Тип тиминга, предлагаемый NSX при этом, называется «Failover Order». В этом режиме может участвовать 1+ pNIC. В случае с единственным pNIC, его отказ не берется на себя ни одним из резервных pNIC.

Физические адаптеры вычислительного гипервизора

Архитектура NSX-T поддерживает несколько физических сетевых адаптеров, а также несколько N-VDS для каждого гипервизора. NSX-T не имеет ограничений на сосуществование с другими коммутаторами VMware (например, VSS, VDS), но физические сетевые карты могут принадлежать только одному виртуальному свитчу. Поскольку оверлейный трафик должен использовать N-VDS, вычислительному гипервизору следует выделить как минимум один pNIC для N-VDS. Кроме того, нет требований помещать какой-либо не оверлейный трафик, включая управляющий, vMotion и трафик хранилища на N-VDS. Управляющий трафик может быть на любом типе виртуального коммутатора, поэтому способен оставаться на VSS/VDS на ESXi или Linux Bridge на KVM.

Минимально, в типичном корпоративном проекте у вычислительного гипервизора два pNIC (подробно рассмотрим его ниже). Если каждый pNIC предназначен для разных виртуальных свитчей, о резервировании говорить не приходится. Такой дизайн для вычислительных гипервизоров с двумя pNIC требует, чтобы оба восходящих канала были назначены N-VDS. В этом случае не гостевой трафик (управляющий, к примеру) будет передаваться по этим восходящим каналам вместе с оверлейным. Если гипервизор использует дополнительные интерфейсы для трафика инфраструктуры (включая vMotion или VSAN), эти интерфейсы и соответствующие им VLAN также должны использовать N-VDS и его аплинки.

Некоторые корпоративные развороты работают с вычислительными нодами с четырьмя pNIC. Такой дизайн позволяет гибко выделить две pNIC для некоторого трафика, вроде оверлейного, к примеру, и две pNIC для другого трафика (управляющего, vMotion и трафика хранилища). На подробностях этого частного случая аналогично остановимся ниже.

Вычислительные ESXi-гипервизоры с двумя pNIC

Выше говорилось, что для обеспечения резервирования pNIC, оба pNIC должны быть на N-VDS. При установке NSX на гипервизор ESXi обычно отталкиваются от существующего виртуального коммутатора. После создания N-VDS интерфейсы управления и обе pNIC должны быть перенесены на этот NVDS. Обратите внимание, что возможности управления трафиком N-VDS не всегда могут соответствовать исходному виртуальному свитчу, так как он может быть неприменим к отличному от ESXi гипервизору.

Обрисуем, вкратце, исходные данные для этого случая:

Весь трафик хоста (оверлейный, управляющий, трафик хранилища, vMotion) использует NIC сообща;
Для каждого вида трафика выделены IP-подсети и VLAN.

Режим тиминга предлагает выбор в отношении доступности и распределения нагрузки трафика. Для N-VDS существуют два типа режима совместной работы на гипервизоре ESXi: порядок переключения при отказе и источник балансировщика нагрузки. Можно использовать оба типа объединения вместе. Комбинация политик тиминга требует, чтобы для оверлейного трафика использовался «default teaming mode», в то время как «named teaming policy» – для других потоков. Это идеальная ситуация, так как проект берет лучшее от обеих политик.

Альтернативный метод распределения трафика – использование LAG, для чего потребуются подключить хосты ESXi к отдельным ToR, для образования единой логической связи. Для этого может понадобиться агрегирование каналов в ToR по принципу мульти-шасси, и сам факт применения будет зависеть от поставщика решения. Этот режим не является рекомендованным, поскольку нуждается во множестве реализаций от разных поставщиков, координации поддержки, отличается ограниченностью функций и может пострадать от сложности траблшутинга. Однако иногда такой вариант является единственным способом использовать описываемую комбинацию, и тогда имеет смысл идти на осознанный риск. В подобных развертываниях можно использовать режим совместной работы на основе LAG исключительно для вычислений рабочих нагрузок. Другими словами, если вычислительный узел поддерживает Еdge-ВМ (для трафика N-S и требует пиринга сверх LAG), то настоятельно рекомендуется отделить Еdge и работать с ней только совместно с выделенными Еdge-хостами, либо же с Еdge и управляющими.

В принципе, все, что будет говориться ниже для двух pNIC, можно использовать как базовые принципы построения схем с большим количеством карт.

Режим тиминга «Failover Order»

Предположим, у нас есть один хост-коммутатор с двумя pNIC. Он управляет всем трафиком. Физические «Р1» и «Р2» прикреплены к различным свитчам верхушки стойки. Опция тиминга active/standby «Failover Order» назначает «Uplink1» активным, в то время как «Uplink2» является резервным. Коммутаторы верхушки стойки сконфигурированы с redundancy-протоколом на первом прыжке (например, HSRP, VRRP) и предоставляют активный дефолтный шлюз для всех VLAN на «ToRLeft». ВМ подключены к логическим коммутаторам, определенным на N-VDS, со шлюзом по умолчанию, установленным на логическом интерфейсе распределенного инстанса логического маршрутизатора Т1:

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

Если же по-прежнему использовать обе pNIC в active/active-режиме, детерминированность трафика сохранится. Для этого следует создать разные тиминг-профили, например, Profile1 – «active/standby with Uplink1/Uplink2» и Profile2 – «active/standby with Uplink2/Uplink1», на каждом логическом свитче VLAN и оверлее:

Для ограничения использования межлинков, ToR-свитчи настроены с redundancy-протоколом первого прыжка (FHRP), благодаря чему активный дефолтный шлюз для трафика хранилища и vMotion – в «ТoR-Left», а управляющий и оверлейный трафик существуют на «ToR-Right». Виртуальные машины, прикрепленные к сегментам/логическим свитчам определены на N-VDS со шлюзом по умолчанию, установленным на логический интерфейс распределенного инстанса Т1 роутера.

Именно этот вариант при выборе режима «Failover Order» и проектировании на двух pNIC считается best practice.

Режим тиминга «Load Balance Source»

Рассмотрим схему с двумя pNIC и одним N-VDS, обеспечивающим redundancy. По аналогии с «Failover Order», хост-свитч управляет всем трафиком, а физические «Р1» и «Р2» прикреплены к разным свитчам верхушки стойки. С политикой «Load Balance Source» потенциально обе восходящие линии связи используются на основе значения хеш-функции, сгенерированного из исходного MAC. Коммутаторы ToR настроены с FHRP, предоставляя активный дефолтный шлюз для трафика хранилища и vMotion на «ToR-Left», а управляющий и оверлейный трафик, тем временем, вынесены на «ToR-Right». ВМ подключены к определенным сегментам/логическим свитчам на N-VDS со шлюзом по умолчанию, установленным на логический инстанс логического интерфейса распределенного Т1 маршрутизатора:

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

От этой политики выигрывают как инфраструктура, так и трафик гостевых виртуальных машин, позволяя использовать все доступные аплинки на хосте.

Вычислительные ESXi-гипервизоры с четырьмя pNIC

4 pNIC на каждом вычислительном хосте обеспечивают большую гибкость при построении топологии со множеством комбинаций VSS/VDS и N-VDS или нескольких N-VDS на хосте, и доступны следующие варианты использования:

Поддержка существующей операционной модели с VSS или VDS и разрешение оверлейного трафика на N-VDS. Речь о конкретном VDS для определенных типов хранилищ, который может потребовать выделенную пропускную способность и независимый операционный контроль;
Построение топологии с выделенным N-VDS, которая допускает только VLAN и оверлей на отдельном N-VDS. Этот тип дизайна помогает микросегментировать только рабочую нагрузку существующей VLAN и строить оверлей параллельно;

Важно! Микросегментация на VLAN может использоваться вместе с оверлеем на том же N-VDS.

Разрешение топологии на основе соответствия, например, PCI, HIPPA и др., часто требующие отдельные и выделенные компоненты инфраструктуры (например, pNIC, операционные элементы управления и т. д.);
Помощь в создании модели клауд-провайдера, в которой внутренняя или внешняя инфраструктура требует своего нахождения на отдельных N-VDS;
Осуществление конкретного варианта использования NFV (виртуализации сетевых функций), где два pNIC выделены для обычного N-VDS под оверлей, и два других pNIC – для N-VDS в «enhanced mode».

В первом варианте (сосуществование VSS / VDS и N-VDS) типичные корпоративные схемы развертывают вычислительные гипервизоры со следующими параметрами:

Две pNIC для всего трафика, кроме оверлея (например, для управления, хранения, vMotion);
Две другие pNIC выделены для оверлейного трафика;
Каждый тип трафика хоста имеет выделенные IP-подсети и VLAN.

Тут VLAN управления, vMotion и хранилища настроены на выделенной VDS-группе портов. VDS сконфигурирован с помощью pNIC «P1» и «P2». И каждая группа портов настроена с разными pNIC в active/standby режиме для использования обеих pNIC. Однако выбор тиминг-режима на VDS оставлен на усмотрение пользователя или существующей реализации. N-VDS настроен с pNIC «P3» и «P4». Чтобы обеспечить использование обоих pNIC, N-VDS конфигурируется в тиминг-режиме балансировки нагрузки (см. выше). Для ограничения использования интерлинков, ToR-коммутаторы настроены с FHRP, обеспечивая активный шлюз по умолчанию для хранения и vMotion трафик на «ToR-Left», а управляющий и оверлейный трафик – на «ToR-Right». Когда все pNIC подключены, только некоторый оверлейный трафик будет пересекать канал между коммутаторами:

Второй use-case (каждый N-VDS создан для обслуживания определенных топологий или для обеспечения разделения трафика на основе корпоративных требований) подразумевает, что инфраструктурный трафик передается по N-VDS-1, что требует миграции VMkernel на N-VDS. В этом случае, по правде говоря, возможно множество комбинаций, но мы перечислим лишь самые интересные из них:

Первые две pNIC используются исключительно для трафика инфраструктуры, а оставшиеся две – для оверлейного трафика. Это позволяет выделить пропускную способность для оверлея гостевого трафика. Можно выбрать соответствующий режим тиминга, как описано выше для двух pNIC;
Первые две pNIC предназначены для «VLAN only»-микросегментации, а вторые – для оверлейного трафика;
Строится множество оверлеев для разделения трафика, хотя TEP IP обоих оверлеев должен находиться в той же VLAN/подсети, однако в разных транспортных зонах;
Создается регулярный домен – либо только VLAN, либо оверлей;
Строится DMZ-тип изоляции.

Вычислительные KVM-гипервизоры с двумя pNIC

Рассмотрим очень родственную схему рассмотренной выше для ESXi с режимом тиминга «Failover Order». Один коммутатор хоста используется с конструкцией из двух pNIC и управляет всем трафиком (оверлейным, управляющим, хранилища и т.д.). Физические карты «P1» и «P2» прикреплены к разным коммутаторам верхушки стойки. Выбрана опция тиминга «Failover Order» active/standby, и «Uplink1» активен, пока «Uplink2» находится в резерве. Эта тиминг-политика обеспечивает детерминированный и простой дизайн для управления трафиком:

Свитчи верхушки стойки настроены с redundancy-протоколом первого прыжка (например, HSRP, VRRP), обеспечивая активный дефолтный шлюз для всех VLAN на «ToR-Left». ВМ подключены к определенным на N-VDS сегментам/логическим свитчам, со шлюзом по умолчанию, установленным на логический интерфейс инстанса распределенного логического маршрутизатора T1.

Важно! Подготовка хоста NSX-T для KVM автоматически создает N-VDS и его «Port NSX-T» (с IP-адрес TEP), а также «Bridge nsx-managed» (для подключения виртуальных машин). Другие порты, такие как «Port Mgt» и «Port Storage» необходимо создать вне подготовки NSX-T:

Проектирование Edge-нод и сервисов

Подробно Edge-ноды и их работу мы рассматривали выше в одноименных соответствующих разделах архитектуры. Напомним, что форм-факторы bare-metal и ВМ одинаковы по своему функционалу, однако к физической инфраструктуре они подключаются совершенно по-разному. Для обеих разновидностей действительны общие требования к трем различным типам IP-сетей:

Управление – доступ к Edge-ноде и управление ею;
Overlay (TEP) – Создание туннелей с одноранговыми транспортными узлами;
Внешний (N-S) – пиринг с физической сетевой инфраструктурой для обеспечения связи между виртуальными компонентами NSX-T и внешней сетью.

В проектировании Edge-нод не обойтись без дизайна бриджинга, также приходится учитывать актуальные соображения насчет работающих здесь служб и ресурсов. Теоретические возможности этого процесса во всей его полноте рассматривались выше, когда изучалась архитектура виртуальных сетей. Сейчас же немножко поговорим о дизайне соединения мостами.

Edge Bridge работает в обоих форм-факторах. В случае bare-metal с ним все просто: мостовой трафик передается по восходящим каналам N-VDS, выбранным указанной в «Bridge Profile» транспортной зоной VLAN. На физической инфраструктуре при этом никаких специальных настроек не требуется. С виртуальными машинами Edge-нод все гораздо сложнее, ведь в конечном итоге получим трафик с нескольких разных MAC-адресов на VLAN vNIC Edge Bridge. Это означает, что аплинк vNIC должен подключаться к DVPG порт-группе, давая разрешение на имитацию передачи, а также на смешанный режим или Mac-learning. Стоит заметить, что эти разрешения идут вразрез с VSS, однако поддерживаются VDS. Следовательно, его и только его необходимо использовать, разворачивая ВМ-Edge-ноду.

О теггировании аналогично достаточно говорилось ранее, и в отношении Edge Bridge осталось лишь заметить, что он станет посылать трафик с 802.1Q-тегом на свой аплинк VLAN. Логично, что этот vNIC виртуальной машины Edge нуждается в прикреплении к порт-группе, настроенной для Virtual Guest Tagging (VGT). То есть DVPG показывается, как VLAN Trunk в UI vCenter.

Простейший пример применения моста в Edge-ВМ (будет показано 3 vNIC вместо 4) назначает vNIC1 на управляющий трафик, vNIC2 – в качестве аплинка N-VDS1 (N-VDS используется для оверлейного трафика), vNIC3 – аплинк N-VDS2 и привязан к транспортной зоне VLAN, куда посылается bridged-трафик. При этом «Bridge VLAN» DVPG настроен с включенным тегированием, имитацией передачи и mac-learning, благодаря чему мост может посылать трафик, полученный с разных mac-адресов. Для одинаковых pNIC используется Active/standby политика тиминга как оверлей DVPG:

Что же касается служб, при разработке дизайна виртуальной сети следует обрести четкое понимание по следующим важным аспектам:

Уровень предоставления услуги (на борту, на пропускном канале, вне и т. д.);
Масштабируемость;
Контроль конфигурации;
Мультитенантность (выделить Т1 для каждого тенанта или же службу – как тенант);
Контроль над службами (поведение в случае сбоя, доступность автоматизации контроля только для Т0 или же только для Т1).

Кроме того, стоит заметить, что службы могут предоставляться как в shared-режиме, так и в привязанном. Первый вариант является наиболее простым и общим методом разворота, и в нем, обычно, ECMP работает на Т0, а все остальные stateful-службы – на Т1. В этом случае легко локализировать сервисы в автоматическом режиме, рассматривать потенциальное их расширение и задействовать все механизмы обеспечения бесперебойной работы даже в случае глобальных сбоев. Привязанный режим означает, что на Edge-ноде будет включаться либо ECMP, либо stateful-службы, и он чрезвычайно удобен при будущем масштабировании, а также в процессе разворота нуждающихся в производительности служб кластера. Еще этот режим отлично себя показывает при мульти-уровневости Т0, или же в случае модели мульти-тенантности Т0.

Узнать об остальных нюансах организации служб и безопасности в виртуальных сетях, научиться проектировать частные случаи NSX-T, более глубоко понять архитектуру и возможности этого продукта помогут авторизированные курсы VMware по дизайну. А конкретный механизм разворота NSX-T Data Center 3.1, рекомендации по обновлению до этой версии и советы по ее администрированию мы обязательно опишем в продолжении цикла статей, посвященного виртуальным сетям VMware.