Федерация в NSX-T Data Center 3.1.x – Aleksandr Mykhalchenko`s Blog

Федерация – пример еще одной из любимых «фишек» VMware, разработке которой и пропаганде уделяется чрезвычайно много внимания. Эта технология вошла в жизнь сетевого виртуализатора вместе с NSX-T Data Center 3.0 (07.04.2020 г.), и, в частности, на VMworld-2020 ей было уделено весьма много внимания. Если в двух словах описать ее функционал, получается, что благодаря этой технологии появилась возможность управлять NSX-T Data Center по всему множеству локаций и актуальна она, естественно, лишь для очень крупных развертываний со своей спецификой:

Тем не менее, тема эта, наверняка, для очень многих будет чрезвычайно интересной и полезной, и немного вводящих в ее курс теоретических знаний и базовых навыков по развертыванию приводилось в наших статьях из цикла по виртуализации сети «Дизайн VMware NSX-T Data Center 3.1» и «VMware NSX-T Data Center 3.1: Разворот с нуля». Однако, раскрыта она в этих материалах далеко не полностью, и мы в них обещали, что обязательно выделим время для персонального, посвященного Федерации, разговора. Что ж, обещания свои надо выполнять… Более того, в сегодняшней статье мы постараемся собрать воедино всю информацию, касающуюся NSX-T Federation, чтобы-де перед вами вдруг встанет задача имплементации и работы с ней, вам не пришлось по крупицам выискивать все необходимое в глобальных трудах.

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

Что нужно знать о Федерации?

В больших корпоративных разворотах c Enterprise Plus-уровнем лицензии NSX-T технология Федерации позволяет управлять множеством сред NSX-T Data Center из единой прозрачной и очень емкой панели. С ее помощью можно создавать шлюзы и сегменты, распространяющие свое влияние на более чем одну локацию, настраивать и применять правила файерволлинга, действующие по всем локациям. Специально под концепцию мультисайтовости Федерации был разработан ряд аутентичных терминов и понятий (о них мы уже писали в «Дизайне VMware NSX-T Data Center 3.1», но, как и обещали, сегодня снова все напомним), описывающий архитектуру и работу этой технологии:

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

Global Manager (GM) – система, объединяющая несколько LM. Представляет собой автономную ВМ, развернутую в одной локации.

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

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

Локальный Т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, работающим во всех локациях.

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

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

Функционал и преимущества

Федерация в NSX-T поддерживает следующие функции сетевой виртуализации:

Т0/Т1 (А/А или A/S);
Группы безопасности (создание групп любого, определенного разновидностью региона, типа – глобального, локального или регионального; динамических групп, опирающихся на динамические критерии, вроде тегов). На такие группы распространяются политики DFW на основе соответствия по полям источника правила и его назначения;

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

Распределенный файервол (DFW);
Файервол шлюза;
NAT. В режиме А/А можно настроить только stateless-NAT (тип действия «Reflexive»). В случае A/S – любые правила NAT (и stateful, и stateless). Поясним: stateless-правила распространяются на все локации из спана, пока рассматривают одну или более указанных локаций, а stateful, аналогично распространяемые на все локации спана шлюза либо же на конкретную указанную, но реализуются они исключительно в primary-локации;
DNS;
DHCP и SLAAC (DHCP Relay поддерживается на сегментах и шлюзах; сервер DHCPv4 поддерживается на шлюзах со статическими привязками DHCP, настроенными на сегментах; адреса IPv6 могут назначаться с помощью SLAAC с DNS через RA (DAD обнаруживает дубликаты только в рамках одной локации));
Бэкапирование и восстановление (в т. ч. с FQDN или IP);
vMotion между локациями;

Важно! Холодная миграция между локациями не поддерживается.

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

Важно! L2-мосты не поддерживаются.

Доступна поддержка объектов, созданных GM в LM, в частности, подключение Т1-шлюза LM к Т0-шлюзу GM, использование групп GM в правиле DFW LM. Однако нельзя подключать сегмент LM к Т0/Т1-шлюзу GM и балансировщик нагрузки к Т1-шлюзу GM.

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

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

Особенности GM и LM и их функции

Форм-фактор GM и LM, по факту, – это виртуальные машины. Ноды GM не включают уровень общего контроля. LM разворачиваются кластером в каждой локации для НА и масштабируемости:

Глобально, GM получает конфигурацию от пользователя и отсылает ее к соответствующим LM:

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

Кроме того, он создает объекты, собственником которых, впрочем, и является, такого типа:

Т0/Т1,
сегменты,
профили сегментов,

и другие, обычные для NSX.

Локально, кластер LM получает от GM конфигурацию на данной локации и LM каждой локации изучает информацию с уровня контроля на предмет того, предназначена ли для нее эта конфигурация. Характерно, что эта функция отдана полностью под LM, так как GM складирует исключительно конфигурацию, и информация от уровня контроля в нем не апдейтится. Однако из пользовательского интерфейса GM можно просматривать инвентари всех локаций путем опроса соответствующих LM. Стоит упомянуть еще и то, что LM каждой локации инициируют процесс синхронизации для обмена конфигурацией уровня контроля данной топологии и хранит у себя информацию о ее реализации:

Выборочно, LM может отменять созданные GM указанные глобальные объекты, однако любые объекты авторства GM в LM видны, но представлены только в формате «read only». Сам LM тоже может создавать сетевые объекты и назначаться их собственником (Т0/Т1, сегменты, профиля сегментов и др., настраиваемые там же), причем изменять или удалять их может лишь он. Кстати, созданные LM объекты GM не видны.

Помимо этого, LM управляет инфраструктурными объектами типа транспортных нод, Edge-нод, транспортных зон и т.п. Вся работа по подготовке инфраструктуры, на самом деле, ложится на его плечи.

Область применения

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

Обеспечить высокую доступность приложений (функции НА);
Сократить время отклика приложений;
Предусмотреть максимально экономичное хостинговое решение, основанное на критичности приложения;
Сохранить конфигурацию на протяжении всевозможных слияний, поглощений и фрагментации в будущем.

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

Особенности сетевой топологии при использовании Федерации

Планируя среду NSX-T Federation, следует предусмотреть следующее:

Спан шлюза Т1 должен быть равен спану Т0-шлюза, к которому он прикреплен, либо быть его подмножеством;
Сегмент должен иметь тот же самый спан, что и Т0 или Т1-шлюз, к которому он прикреплен;

Важно! Изолированные сегменты в Федерации не участвуют.

Edge-ноды кластера, выбранные на GM для Т0/Т1, должны быть настроены с дефолтной оверлейной транспортной зоной.

Организация Т0 в Федерации

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

Нерастянутый Т0-шлюз. соответствуют созданию Т0-шлюза напрямую на LM, однако он может управляться из GM:

Растянутый А/А с главной и вторичными локациями. В этом случае все Edge-ноды являются активными одновременно, в результате чего Т0 не может запускать stateful-службы, а весь трафик входит в Edge-ноды и покидает их в главной локации:

Важно! Чтобы уменьшить кросс-локационный трафик одну и ту же локацию нужно настраивать как главную и для шлюза Т0, и для связанного с ним Т1.

Важно! Если в среде на физической сети используются stateful-службы (внешний файервол и т. п.), следует убедиться, что обратный трафик входит через главную локацию. Например, можно добавить AS-путь к BGP-пирам во вторичной локации. Если stateful-служб нет, но выбирается ассиметричная маршрутизация, следует отключить Unicast Reverse Path Forwarding (uRPF) на всех внешних Т0-интерфейсах.

Растянутый А/А со всеми главными локациями. Все Edge-ноды активны одновременно, в результате чего Т0 не может запускать stateful-службы, а весь трафик входит на Edge-ноды и покидает их в той же локации, что и рабочие нагрузки:

Важно! Этот вариант топологии позволяет трафику выходить локально из каждого местоположения. Чтобы stateful-службы (файервол и др.) были в этом случае разрешены, следует проследить, чтобы обратный трафик поступал сюда же. Для этого, к примеру, можно настроить специфический для локации IP NAT.

Растянутый A/S с главной и вторичными локациями. Только одна Edge-нода активна в один момент времени, поэтому stateful-службы разрешены. Весь трафик входит через активную Edge-ноду и выходит тоже через нее в главной локации:

Вот список поддерживаемых служб в последнем случае: NAT, файервол шлюза, DNS, DHCP.

Обязательно следует проследить, чтобы настройки локального AS, ECMP, Multipath Relax и бережного рестарта были одинаковы по всем локациям. Удобно, что, когда мы меняем их из веб-интерфейса GM, новые параметры автоматически применяются по всем локациям. Если же пользуетесь АPI, так как делаете все вручную, обязательно повторите процедуру для каждой.

Важно! При создании Т0 из GM нужно сконфигурировать внешний интерфейс в каждой локации, на которую растянут этот Т0. Все эти интерфейсы следует подключить к созданному из GM сегменту, выбрав настройку «Connectivity» как «None» и «Traffic type» – как «VLAN». Настроенные на этих внешних интерфейсах Edge-ноды используются во внутренней связи локации, даже если в трафике северного направления нет нужды.

Организация Т1 в Федерации

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

Если же на Т1 предусмотрены службы или хочется использовать пользовательский спан (отличный от Т0), одна из локаций выбирается как главная и остальные будут, соответственно, вторичными, а режим НА для Т1 при этом – только A/S. В результате весь трафик через этот шлюз будет проходить через активную Edge-ноду в главной локации:

Edge-ноды в растянутой сети и RTEP

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

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

TEP и RTEP могут использовать один и тот же рNIC в Edge-ноде, либо же разные – это не принципиально. Ниже, в разделе про разворот, мы обязательно поучимся все это настраивать.

Сегменты в Федерации

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

Порты сегментов создаются и перенастраиваются из LM – из GM их можно только просматривать.

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

Безопасность в Федерации

В числе компонентов безопасности NSX-T Federation:

Правила. Правила файервола базируются на объектах и тегах (не на IP-адресации);
Политика. Политика файервола может включать одно и более персональное правило файервола;
Глобальные группы. Группы, созданные GM;
Локальные группы. Группы, созданные LM;
Теги. Объектам можно назначать теги, благодаря чему они могут обнаруживаться определенной локацией, либо же определять их глобально, добавляя в глобальную группу;
Регион. Комплект локаций, каждая из которых добавлена в GM. Можно создавать пользовательские.

Важно! GM может организовать файервол во всех категориях, кроме «Emergency». В ней создают свои секции только LM.

Правила DFW, назначаемые в GM, могут обладать глобальным, региональным или локальным спаном:

Они синхронизируются со всеми LM и появляются в LM с иконкой «GM»:

Созданные в GM правила редактируются только в GM – не в LM, ни при каких обстоятельствах.

Глобальные группы бывают двух типов:

участники, принадлежащие NSX,
обнаруженные участники.

Создавать, удалять и обновлять глобальные группы может только GM. В LM они доступны только для чтения.

Важно! Глобальные группы не могут использоваться вложенными членами в политиках на основе LM.

Важно! Группы, созданные из GM, не могут включать AD–группы пользователей или группы на основе ID.

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

По интересующему объекту в Федерации можно задавать теги, независимо от того, является ли он глобальным или локальным.

Поддерживаемые рабочие процессы DFW хорошо иллюстрирует схема:

Здесь, к примеру, под GM есть три LM, и в результате созданы четыре региона (Global, Location1, Location2, Location3) автоматически, плюс пользователем добавочно организован регион «Region1», включающий LM из Location и Location3. Под такую конструкцию создается пять групп безопасности:

«Group1» – для региона Global,

«Group2» – для региона Location1,

«Group3» – для региона Location2,

«Group4» – для региона Location3,

«Group5» – для региона Region1.

Вообще же, в Федерации можно создавать группы в GM с глобальным, локальным или региональным диапазоном, в том числе и динамические, базирующиеся на динамических критериях, вроде тегов (за назначение отвечает настройка «Applied To»). Охват применения политик DFW – аналогичен. При этом важно помнить, что группы источника и назначения правил DFW должны соответствовать диапазону политики. В тех локациях, которые выходят за диапазон политики, система будет создавать группы автоматически.

Резюмируем информацию из примера и общих тезисов. Если спан политики охватывает Global, в ее правилах все группы разрешены в качестве источников и назначений правил DFW (из нашего примера, источником может быть, в частности, «Group2», а назначением «Group3», или если источник – «Group4», назначением может быть «Any» и т.д.). Если спан политики охватывает Location1 (автосозданный LM регион в первой локации), и ее источник, и ее назначение должны тоже принадлежать группам из Location1. Если речь о созданном пользователем регионе (у нас в примере – диапазон Location2 + Location3), источник и назначение должны принадлежать ему же (см. выше Region1).

Важно! Если группа содержит сегменты, спан политики DFW должен быть не меньшим, чем спан сегмента.

Правила шлюза файервола могут применяться ко всем локациям в спане шлюза, либо ко всем интерфейсам конкретной локации, либо же специфическим интерфейсам одной и более локаций (настройка «Applied To»).

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

В процессе настройки правила можно выбрать локацию и назначить для нее «Apply rule to all Entities», либо же выбрать локацию и указанные интерфейсы из нее (повторить во всех локациях и для всех интерфейсов, где хотим, чтобы правила применялись). Также можно глобально в качестве объекта применения выбрать сам шлюз, и тогда правило применится ко всем прикрепленным к этому шлюзу интерфейсам во всех локациях, на которые этот шлюз распространяется.

Требования и совместимость

Для поддержки Федерации на GM и всех LM должен быть проинсталлирован NSX-T Data Center 3.0 (многие функции доступны только с 3.0.1) или новее. Матрица совместимости с гипервизорами и vCenter Server выглядит на данный момент так:

Сетевые требования

Следует открыть порты для связи между GM и LM. Если применяется подключение без NAT, помимо этого, организуется подключение LM к удаленным LM, а также налаживается связь между RTEP Edge-ноды и удаленным RTEP Edge-ноды. При этом никаких NAT на RTEP применяться не должно.

Задержка между локациями в среде Федерации не должна превышать 150 мс. Также важно, чтобы не было никаких перегрузок на пути трафика от GM к LM и на уровне данных.

Помимо этого, требуется не меньше 1700 байт MTU во избежание фрагментации трафика RTEP Edge-ноды.

Конфигурационные лимиты

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

Подготовка к развороту Федерации

В плане подготовки к развороту Федерации, после разработки нужной топологии и очерчивания желаемого функционала, нам нужно:

Убедиться, что система отвечает требованиям по совместимости и прочим рекомендациям (см. выше). В т. ч., есть ли связь IPv6 и IPv4 с vCenter Server, и хватает ли таких серверов для назначения их в процессе менеджерами вычислений;

Важно! Один vCenter Server можно регистрировать только на одном NSX Manager.

Подготовить хосты под NSX и vCenter Server;
Продумать схему аутентификации, ролей и прав (см. раздел «Подготовка…» статьи «VMware NSX-T Data Center1: Разворот с нуля»);
Если имеем рабочую среду, в которой внедряется Федерация, предварительно нужно настроить и сохранить все бэкапы;
Проверить лицензии на валидность и сообразность решению (см. ниже подраздел «Лицензирование»);
Скачать нужную версию NSX-T (установка первичного Appliance осуществляется из одного «.ova»-файла, просто, в процессе выбирается, как именно назначить наш разворот) отсюда:

Лицензирование

Как уже говорилось выше, имплементация Федерации доступна исключительно в Enterprise+ уровне лицензий. Развернутый GM контролирует правильность лицензии LM на стадии адаптации LM.

Процедура создания NSX-T Federation

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

Инсталляция GM Appliance;
Разворот GM;
Назначение одному GM режима «Active»;
Разворот второго инстанса GM и перевод его в режим «Standby»;
Добавление LM и ее настройка. Разворот стольких LM, сколько необходимо нашей топологии;
Подготовка локации для Федерации, с установкой связи и взаимной аутентификации между GM и LM (прикрепление LM к GM, выбор имени для первой локации и создание соответствующего локационного объекта). Если нужен кросс-локационный трафик, выбираем Edge-кластер или разворачиваем его с нуля;
Опциональная настройка RTEP для всех членов кластера для возможности растягивать сети между сайтами.

Окончательно мы должны прийти к полной адаптации LM к GM и включить все доступные функции Федерации. Последние два пункта повторяем для каждого сайта, который хотим видеть в этой адаптации.

Разворот GM Appliance

Процедура полностью идентична тому, что мы делали для Appliance классического NSX-T Manager, за тем исключением, что в «Customize template» в пункте «Rolename» выбираем не «NSX Manager», а «NSX Global Manager»:

Освежить в памяти процесс можно в статье «VMware NSX-T Data Center 3.1: Разворот с нуля».

Важно! Сколько бы GM и LM мы не разворачивали, их версии NSX-T Data Center должны быть одинаковы.

Важно! При развороте выбираем «Medium» или «Large»-размер конфигурации. «Small» в Федерации не применим.

Создание кластера GM и его настройка

Следующим шагом будет создание кластера GM и его начальная настройка:

Заходим в UI NSX Manager Appliance, введя в адресной строке браузера его IP-адрес и данные учетной записи администратора. Первый вход попросит нас согласиться с EULA и присоединиться к CEIP;
Запускаем клиент NSX-T, где, в первую очередь, добавляем менеджер вычислений (процедура аналогична тому, что мы делали для NSX-T Manager – см. в упомянутой выше статье);
Добавляем два таких же Appliance и формируем из всех троих кластер, после чего настраиваем для него VIP (заходим на вкладку «System», в левой панели выбираем «Appliances» и в поле «Virtual IP» кликаем на «Set Virtual IP», вводим его – должен быть из той же подсети, что и другие ноды управления. Подробно описано в статье «Администрирование и настройка VMware NSX-T Data Center 3.1»;
В другой локации разворачиваем аналогичный кластер Standby;
Назначаем роль первого кластера, как «Active» – см. соответствующий раздел статьи «VMware NSX-T Data Center1: Разворот с нуля» и подключаем его ко второму, который будет «Standby».

Добавление локации

После того, как нужные кластера GM развернулись и для них настроили VIP, можно приступать к добавлению локации к GM. Для этого:

На той же вкладке «System» в левой панели ищем «Location Manager», заходим туда и нажимаем на кнопку внизу рабочей области справа «Add On-Prem Location»:

В появившемся окне «Add New Location» заполняем все поля, жмем «Check Compatibility» и сохраняем настройку кнопкой «Save»:

Повторяем процедуру столько раз, сколько LM предусматривает наша топология. Установка связи с Active и Standby GM произойдет автоматически, как и со всеми соседними LM. Убедиться в последнем можно здесь:

Подготовка локации для Федерации

Процедура подготовки локации для NSX-T Federation включает в себя импорт конфигурации LM в GM и обустройство сетевой топологии, в соответствии с принятым дизайном (подробную инструкцию приведем ниже в разделе по администрированию). Опционально, если необходимо растянуть сеть между сайтами со всеми вытекающими, настраивается RTEP. В результате виртуальная сеть включит диапазон множества локаций по всем подключенным L3-сетям.

Настройка Edge-нод для растянутых сетей и RTEP

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

У каждой локации, участвующей в растянутой сети, есть минимум один кластер Edge;
Все RTEP-сети в среде Федерации подключены по IP друг к другу;
Внешние файерволы разрешают кросс-локационные туннели и BGP-сеансы между Edge (настраивать следует как здесь);
Задано верное MTU для RTEP на каждом LM (выставляем максимум, какой только может выдержать физическая сеть).

Также следует определить, которые из L3-сетей и VLAN будут использоваться в RTEP-сетях.

Для настройки растянутой сети заходим в «System» – «Location Manager», выбираем локацию, где все это необходимо настроить, и кликаем на «Networking». Находим в списке подходящий Edge-кластер и нажимаем «Configure» по нему. Откроется окно «Configure Edge Nodes for Stretched Networking», где можно выбрать одну или же сразу все ноды из кластера, а также в выпадающем меню уточняется свитч хоста, политика тиминга (если хоть одна настроена), вводится VLAN для RTEP (значение от 1 до 4094), IP-пул для всех нод (если каждой ноде хочется задать свой IP, потом заходим в редактирование RTEP – см. ниже) и MTU. Вся настройка сохраняется кнопкой «Save».

Если в будущем понадобится изменить настройки RTEP, заходим в «System» – «Fabric» – «Nodes» – «Edge Transport Nodes», где выбирается нужная нода и вкладка «Tunnels» справа от нее:

В случае, когда RTEP уже был задан, он будет в списке, и можно нажать на «Edit», чтобы отредактировать его конфигурацию в таком окне:

RTEP можно настроить из каждого LM. Для этого заходим на него, а затем на вкладке «System» выбираем «Get Started» – «Configure Remote Tunnel Endpoint».

Настройка и администрирование Федерации

Важно! Все настройки в Федерации выполняются в режиме «Policy». Режим «Manager» недоступен:

Знакомство с веб-интерфейсами GM и LM

Вкладки UI GM полностью совпадают с тем, что мы рассматривали в процессе изучения NSX Manager в статье «Администрирование и настройка VMware NSX-T Data Center 3.1». Но, в левой панели после разворота GM и LM появились разделы «Global Manager Appliances» и «Location Manager». Они содержат соответствующие списки компонентов с подробной о них информацией и возможностями редактирования настроек, создания и удаления новых объектов и управления ими – в реализации задач предыдущих разделов этой статьи мы активно ими пользовались.

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

Если зайти в локальный менеджер, мы будем видеть любой глобальный объект, применимый к этой локации. Отличить такие глобальные объекты можно легко, так как они помечены иконкой «GM»:

Логично, что в представлении UI GM никаких значков около объектов мы не найдем, так как они и так все созданы именно здесь, и показываются только они.

Обновление статуса объектов, получаемое GM из LM, не является автоматическим – для этого предусмотрено специальная кликабельная ссылка по каждому объекту «Check Status», нажав на которую получим подтверждение успешности обновления:

Освежить информацию можно соответствующей иконкой рядом со словом «Success», как показано на скриншоте выше.

Также очень полезным является раздел левой панели «System Overview» на вкладке «System», где получаем графическое представление о среде Федерации, видим состояние всех компонентов архитектуры федерации и связи между ними, а также данные о том, когда делался последний бэкап и настраивался ли он вообще, о версии клиента, о том, сколько Appliance развернуты в той или иной локации GM и данные по их связи, статус синхронизации и настроен ли RTEP, а также все то же самое – но относительно связанных с этим GM LM. Пример того, как все это может выглядеть:

Данные по сетевой организации можно получить в аналогичном типе представления на вкладке «Networking» и т.д. Ниже «Network Overview», когда создадим первые сетевые объекты, появится раздел «Network Topology»:

в котором можно увидеть организованную сетевую топологию:

Бэкапирование

В левой панели UI GM в разделе «Lifecycle Management» есть опция «Backup & Restore»:

Учтите, что ее настройка потребует ввод отпечатка, который следует подготовить заранее.

В рабочей панели этой зоны можно настроить расписание бэкапирования, нажав на кнопку «Edit» в соответствующем блоке вверху нее:

В появившемся окне:

можно включить или выключить функцию, задать частоту ее активации (еженедельно, в интервале), выбрать дни недели и время снятия бэкапа. По желанию, можно включить ползунок во второй секции «Detect NSX configuration change», и тогда, как только что-то поменяется, стартует бэкап. Это делать не рекомендуется, так как количество сохраненных бэкапов в этом случае превышает все мыслимые пределы.

Импорт конфигураций из LM

Импортировать конфигурацию из LM в GM можно в любое время (но, не ранее, чем была добавлена локация), правда, лишь однажды. Функция импорта поддерживает следующую информацию: Т0/Т1 шлюзы, политики файервола, службы, профили безопасности, контекстные профили, группы, NAT, DHCP, DNS профили шлюзов.

Важно! В LM нельзя использовать следующие настройки: VPN, IDS, WAF, VHC, вставку служб, Guest Introspection, Identity Firewall, перенаправление политик, мост L2, прокси метаданных, T0 VRF, многоадресную рассылку, EVPN, временный файервол, балансировщик нагрузки. Операция их импорта будет заблокирована.

Перед импортом нужно сделать бэкап LM (см. выше) и удалить настройки неподдерживаемых функций из LM Appliance.

Функция активируется очень просто – из списка локаций в разделе «Location Manager» левой панели (кстати, система сама вам о необходимости импорта корректно намекнет, высветив соответствующее предупреждение по строке той или иной локации). Справа будет две опции «No, thanks» и «Import». Естественно, выбираем вторую:

Если во всплывшем окне нажать на «Proceed To Import», можно будет задать настройки импорта и увидеть счетчик объектов, чью конфигурацию система решила импортировать из LM в GM:

выбрав суффикс или префикс.

Операция повторяется для всех добавленных локаций.

Отмена конфигураций GM на LM

Как уже упоминалось выше, при создании объекта в GM такая же конфигурация будет распространена и на все соответствующие локации. В некоторых практических ситуациях это сильно мешает. Чтобы отменить эту конфигурацию, нужно напротив нее нажать на значок трех вертикальных точек, после чего выбрать «Edit». Теперь в колонке статуса по отмененной конфигурации и в GM, и в LM будет стоять красный значок.

Отмену конфигурации можно удалить, если снова нажать на три вертикальные точки по ней и выбрать «Revert» – тогда она восстановится из GM.

Важно! Если конфигурацию по LM отменить, а затем удалить ее из GM, она все равно будет висеть неактивной в LM. Однако, если попытаться к ней вернуться, она удалится и отсюда.

Список отмененных конфигураций можно посмотреть, введя API-запрос к GM вида:

GET https://<global-mgr>/global-manager/api/v1/global-infra/overridden-resources

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

Профили сегментов (в «Networking» – «Segments» – «Segment Profiles») – обнаружения IP и MAC, безопасности сегментов, SpoofGuard;
Профили сетей (в «Networking» – «Networking Settings») – IPv6 DAD, IPv6 ND, QoS шлюзов, BFD;

Контекстные профили (в «Inventory» – «Context Profiles»);
Профили безопасности (в «Security» – «Security Profiles») – таймера сеанса файервола, Edge Gateway Flood Protection, Firewall Flood Protection, безопасности DNS, пороговых значений памяти и CPU (последнее – только через API. Например, заменить – это с PUT/PATCH в https://<local-manager>/policy/api/v1/global-infra/settings/firewall/cpu-mem-thresholds-profiles/<id>?action=override, а вернуться – с DELETE в https://<local-manager>/policy/api/v1/global-infra/settings/firewall/cpu-mem-thresholds-profiles/<id>)
Профили траблшуттинга (в «Plan & Troubleshoot») – Firewall IPFIX, Switch IPFIX, IPFIX Firewall Collector, IPFIX Switch Collector, мирроринга диапазона удаленных L3-портов, мирроринга диапазона логических портов, QoS.

Удаление локации

Удаление локации означает удаление всех объектов, созданных GM, которые обладают глобальным диапазоном и не специфичны для этой локации (в т. ч. секций групп, файерволов и т. д.).

Важно! Процедура удаления локации может нарушить работу сети и ее целостность.

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

Сама процедура элементарна и делается, по традиции, из UI. Заходим в «System» – «Location Manager», выбираем нужную локацию и кликаем на выпадающее меню «Actions», где останавливаемся на пункте «Remove». Вылетит предупреждение, его нужно подтвердить.

Конфигурирование сети в Федерации

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

Для начала заметим, что обзор всех подключенных шлюзов и сегментов, а также сетевых служб и компонентов управления доступен на вкладке «Network Overview» UI:

Как видим, пока у нас там все весьма скромно, но скоро это исправится.

О настройке RTEP мы уже рассказали в подразделе «Настройка Edge-нод для растянутых сетей и RTEP» главы «Процедура создания NSX-T Federation», теперь настал черед шлюзов и сегментов.

Добавление и настройка шлюза Т0 из GM

Перед созданием шлюза Т0, накрывающего более одной локации, следует убедиться, что каждая такая локация обладает настроенными Edge-нодами с RTEP для растянутой сети (см. выше).

Для того, чтобы добавить шлюз в GM, нам нужно в UI пройти на вкладку «Networking», в левой панели выбрать раздел «Tier-0 Gateways» и далее почти все точно так же, как мы делали в статье «Администрирование и настройка VMware NSX-T Data Center 3.1» – нажав на «Add Tier-0 Gateway», переходим в окно настроек, где заполняем все необходимые поля привычным методом:

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

Обратите внимание на секцию «Location» (добавляем новые локации кнопкой «Add Location»). В нашем примере мы остановились на A/S модели (в пункте «Fail Over» из выпадающего меню предпочли «Preemptive» – соображения насчет модели НА и ее режимов приводились в предыдущих наших статьях цикла по NSX), поэтому выбрали соответствующий Edge-кластер и его ведущую ноду как «Primary». Это в первой локации кластера Федерации. По второй локации в качестве вторичного Appliance остановились на второй Edge-ноде из того же кластера:

Когда заданы все настройки, обновив статус новосозданного шлюза Т0 мы видим, что он развернулся для каждого LM и помечен значком «GM» возле имени:

Теперь нам нужно настроить интерфейсы аплинков на Т0 для каждой ВМ Edge – это важно для N-S-трафика и BGP-пиринга к TOR. Снова заходим в карточку нашего шлюза Т0 и выставляем все, примерно, вот так:

Назначив подсети в полях «Internal Transit Subnet» (для коммуникации между компонентами шлюза), «T0-T1 Transit Subnets» (для связи этого Т0 со всеми связанными с ним Т1) и «Intersite Transit Subnet» (для кросс-локационной коммуникации между компонентами шлюза).

Однако до того, как начнем добавлять интерфейсы аплинков, нам нужно настроить используемые в них сегменты – см. ниже. Когда же они будут готовы, раскрываем секцию «Interfaces», жмем на «SET» и кликаем на «Add Interface». В экране настроек задаем:

имя интерфейса,
локацию,
тип (для A/S доступны External, Service и Loopback, а для А/А – только External и Loopback),
IP-адрес в CIDR-формате,
сегмент (важно, чтобы в его настройках «Connectivity» было выставлено на «None», а в качестве «Traffic Type» выбран VLAN),
Edge-ноду, если тип выше не «Service»,

Если «Loopback», опционально можно задать значение MTU. А если «External» в URPF-режиме – выбирается «Strict» или «None».

Также по желанию назначаются теги и ND-профиль:

Важно! Секцию PIM пропускаем, так как мульти-адресная рассылка Федерацией не поддерживается.

После успешного создания интерфейса, если кликнуть на вертикальные три точки по нему в списке, можно выбрать «Download ARP table», чтобы загрузить таблицу ARP:

Повторяем процедуру назначения интерфейсов для каждого интерфейса аплинка Edge Appliance для выбора верной локации для сегмента и VLAN ID этого VLAN-сегмента:

Продолжим настраивать наш Т0. Теперь раскрываем секцию «Routing», чтобы добавить список IP-префиксов, статические маршруты и карты маршрутизации.

Важно! Добавленные на шлюзе Т0 статические маршруты направляются во все сконфигурированные на нем локации. Однако, обычно, включаются они только на первичных локациях, чтобы они получили статус предпочитаемых на вторичных локациях. Если по каким-то причинам это не устраивает, выбираем «Enabled on Secondary», и тогда они также включатся на вторичных локациях.

В выборе следующего прыжка можно выставить «Scope» (интерфейс/шлюз/сегмент/локация). Для настройки каждого следующего прыжка по каждой локации можно использовать возможности этого параметра.

Далее раскрываем секцию «BGP», большинство настроек которого на Т0 из GM применяются ко всем локациям, и вводим туда стандартные назначения – все по аналогии с рекомендациями из наших предыдущих статей по теме NSX-T:

И настраиваем BGP-окружение, добавив его членов кнопкой слева вверху:

После того, как появится самый первый BGP Neighbor, установятся отношения BGP, и можно добавлять все остальные:

Также можно настроить перераспределение маршрутов, если нажать на «Route Redistribution». Здесь по каждой локации нажимаем «Set»:

и выбираем 1+ источник:

Подсети Т0 (Static Routes/NAT IP/IPSec Local IP/DNS Forwarder IP/EVPN TEP IP/Connected Interfaces & Segments). В «Connected Interfaces & Segments» можно выбрать что-то из Service Interface Subnet/External Interface Subnet/Loopback Interface Subnet/Connected Segment или сразу несколько;
Объявленные Т1 подсети (после создания Т1): DNS Forwarder IP/Static Routes/LB VIP/NAT IP/LB SNAT IP/IPSec Local Endpoint/Connected Interfaces & Segments. В «Connected Interfaces & Segments» можно выбрать «Service Interface Subnet» или «Connected Segment», либо оба.

Например, вот так:

Полученный список перераспределения можно применить к карте маршрутизации с добавлением расширенных свойств BGP:

Наше подключение N-S-направления готово и настроена маршрутизация.

Добавление сегмента из GM

Так как нас интересует более сложная и интересная ситуация с растягиванием сегментов на множество локаций, будем рассматривать создание именно оверлейного сегмента из GM. Предварительно нам нужно убедиться, что каждая локация обладает дефолтной сконфигурированной транспортной зоной. Проверить ее наличие, в случае чего, можно на вкладке «System» в разделе «Fabric» левой панели на его вкладке «Transport Zones». Важно, чтобы эта TZ была настроена именно как дефолтная – следует ее выбрать, и в «Actions» назначить пункт «Set as Default Transport Zone».

Сама же процедура создания глобального сегмента выглядит так:

На вкладке «Networking» выбираем «Segments» и нажимаем «Add Segment». Вводим его имя, выбираем тип подключения (в выпадающем списке ищем нужный шлюз Т0/Т1 или пока оставляем «None», если инициация сегмента произошла до момента добавления шлюзов), тип трафика («Overlay»/«VLAN», проставится автоматически, у нас – «Overlay») и локации (можно заполнить теми же локациями, что сконфигурированы на прикрепленном шлюзе, либо назначить дефолтную TZ, чтобы сегмент распространялся на каждую локацию):

Важно! Создание сегментов на прикрепленных к шлюзу VLAN не поддерживается.

Вводим IP-адрес подсети шлюза (сегмент может содержать как IPv4-подсеть, так и IPv6-подсеть, или обе);

Важно! Подсети одного сегмента не должны перекрывать подсети других сегментов в сети. Они всегда ассоциируются с VNI, независимо от того, настроен ли он на одну подсеть, их пару или вообще без подсетей.

Раздел «DHCP Config» пропускаем, так как на сегменте из GM поддерживаются только статические привязки;
Для оверлейного типа TZ, если хочется поддерживать мост для L2 или гостевое теггирование VLAN, следует указать список ID VLAN или их диапазон;
Опционально можно выбрать политику тиминга для сегмента в соответствующем выпадающем меню (если она ранее была добавлена при конфигурировании VLAN-TZ). Если ничего не выбрано, будет использоваться политика тиминга по умолчанию.

После сохранения этой настройки (по результату может выскочить сообщение, которое нужно подтвердить) мы готовы приступать к выбору профилей сегмента, для чего нажимаем на «Segment Profiles». И, напоследок, чтобы привязать статический IP-адрес к MAC-адресу ВМ на сегменте, раскрываем раздел «DHCP Static Bindings» и нажимаем на «Set», после чего заполняем требуемые поля.

Должно получиться что-то наподобие такого:

с такой информацией по каждому:

Как обычно, по завершению работы с первым сегментом, проверяем, апдейтят ли динамически BGP нашу TOR с новосозданным сегментом. И повторяем процедуру для всех необходимых сетевой топологии сегментов:

Теперь эти сегменты видны в vCenter по каждой локации и могут использоваться в подключении ВМ:

Подключаем все ВМ к ним и проверяем связь окончательно.

Добавление и настройка шлюза Т1 из GM

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

Процедура добавления Т1-шлюза аналогична тому, что мы делали в обычном NSX-T Manager (см. «Администрирование и настройка VMware NSX-T Data Center 3.1»). Настройки в нашем случае могут выглядеть, например, вот так:

Отметьте, что в «Locations» можно включить ползунок на «Enable Edge Clusters for Services or Custom Span» – по дефолту он выключен. Если оставить все, как есть, Т1 будет иметь тот же спан, что и Т0, и специально включать службы на нем не придется, но, при этом, получим только распределение маршрутизации. Если же включить эту опцию, выбирается подмножество локаций, кластер, вносится информация о режиме (Primary/Secondary) и можно включить сервисы по желанию на Т1. Локации выбираются из выпадающего списка (наш Т1 привязан к Т0, так что они подтянутся автоматически), и под каждую назначенную выбирается Edge-кластер с конкретным режимом failover (Preemptive/Non-preemptive) и выбором параметра «Enable StandBy Relocation».

Важно! Если Т1 покрывает более одной локации, Edge-кластеры нужно настраивать с RTEP на каждой своей ноде.

Важно! В Primary-режиме можно настраивать только одну локацию. Через нее будет идти весь N-S-трафик из этого Т1.

Выбор размера из меню «Edge Pool Allocation Size» пропускаем. И, опционально, можно назначить «Route Advertisement» (All Static Routes/All NAT IP’s/All DNS Forwarder Routes/All LB VIP Routes/All Connected Segments and Service Ports/All LB SNAT IP Routes/All IPSec Local Endpoints), а также заполнить «Set Route Advertisement Rules», нажав на «Set» (это для настройки SLAAC и DAD для IPv6-адресации). Если это сделано, нажимаем на «Additional Settings» и для IPv6 выбираем или создаем с нуля ND Profile и DAD Profile, выбираем «Ingress QoS Profile» и «Egress QoS Profile» для ограничений трафика, и тогда в поле «Router Links» покажутся связанные адреса. Также опционально можно кликнуть на «Service Interfaces» – «Set» для настройки связи с сегментом (полезно для некоторых топологий, например, для сегментов на VLAN или при one-arm балансировке нагрузки). Чтобы добавить новый интерфейс, нажимаем на «Add Interface» и вводим его имя и IP-адрес в CIDR-формате.

Важно! Если настраивается мульти-адресная пересылка на этом шлюзе, нельзя настраивать Т1-адреса как статические RP-адреса в профиле PIM.

Далее выбираем сегмент, вводим значение MTU (от 64 до 9000), и в «URPF Mode» выбираем «Strict»/«None», еще можно добавить теги, а в поле «ND Profile» выбрать или создать новый профиль. Также, по желанию, можно установить статический маршрут в «Static Routes», кликнув на «Set», а затем – на «Add Static Route», введя его имя и сетевой адрес, назначить следующие прыжки в «Set Next Hops».

Если Т1 настраивался с Edge-кластером для служб, после его начальной конфигурации можно приступить к их настройке. О соответствующих процедурах весьма доходчиво и полно написано в статье «Администрирование и настройка VMware NSX-T Data Center 3.1».

Настройка безопасности в Федерации

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

Просмотр объектов безопасности, редактирование, создание новых, удаление и управление ими доступно из UI. Например, если нужно создать новую группу, сделать это можно на вкладке «Inventory» в разделе левой панели «Groups»:

Если она относится к классу глобальных, предварительно выбираем в верхнем меню регионов тот, который относится к Global.

Просмотр, создание, удаление, редактирование и управление регионами аналогично доступно из UI на той же вкладке, только в левой панели для этого выбираем «Regions».

То же самое и по остальным типам объектов безопасности.

Создание региона из GM

В UI заходим на вкладку «Inventory» и в левой панели – в раздел «Regions», после чего нажимаем на кнопку «Add Region» и в окне настроек задаем имя региона, выбираем локации, которые хотим в него включить, после чего сохраняем настройку кнопкой «Save»:

Создание групп из GM

Заходим на вкладку «Inventory» – «Groups» и кликаем на «Add Group», после чего вводим имя новой группы, принимаем дефолтный выбор региона или назначаем свой. Учтите, что для группы, однажды созданной с обозначенным регионом, впоследствии поменять этот регион не получится. Однако, если есть необходимость, можно изменить охват самого региона, добавляя или удаляя в нем локации.

Далее опционально, если найдены подходящие члены, можно нажать на «Set Members», где по каждому критерию членства указывается до пяти правил, комбинируемых логическим оператором «AND». Доступные критерии членства могут применяться к:

порту сегмента (указываем тег, диапазон или и то, и другое),
сегменту (указываем тег, диапазон или и то, и другое),
виртуальной машине (указываем имя, тег, имя ОС компьютера),
набору IP (указываем тег, диапазон или и то, и другое).

Когда критерии назначены, можно выбрать членов группы в «Members» из таких общих классов: «Groups Segments», «Segment Ports», «VIFs», «Virtual Machines», «Physical Servers» или «Cloud Native Service Instances».

Также, по желанию, можно добавить IP и MAC адреса как членов группы, если кликнуть на «IP/MAC Addresses». Кстати, доступен их импорт из «.txt» или «.csv»-файла (нужно в «Action» выбрать «Import»).

Наконец, можно назначить новой группе тег, например, вот так:

и задать, при необходимости, информативное описание, после чего весь процесс завершается по кнопке «Apply».

Создание политик DFW и правил из GM

Когда образованы пользовательские регионы, можно приступать к созданию политик безопасности и правил DFW, которые к ним будут применяться. Делается это из вкладки «Security» – «Distributed Firewall». Выбираем нужную предопределенную категорию и нажимаем «Add Policy» (общую информацию по категориям и их назначению можно посмотреть в «Администрирование и настройка VMware NSX-T Data Center 3.1»).

Важно! GM не поддерживает категории «Ethernet», «Emergency» и «Default Policy».

В открывшемся окне задаем имя для новой секции политики и нажимаем на значок «карандашика» возле «Applied To» для установки ее диапазона. В диалоговом окне «Set Applied To» выбираем регион в «Region», чтобы назначить для каких LM будет использоваться эта политика, а в «Select Applied To» – к чему именно она будет применяться. По дефолту значение по последнему проставлено как «DFW», в результате чего она станет работать для всех рабочих процессов на LM. Также можно выбрать определенную группу.

Далее нужно нажать значок «шестеренки», чтобы задать следующие параметры:

TCP Strict,
Stateful,
Locked.

После этого можно кликать на «Publish».

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

Теперь выбираем именно ее и нажимаем на «Add Rule», вводим имя правила, а значения по колонкам «Source» и «Destination» проставятся сами, опираясь на диапазон политики DFW. Но, эти значения можно отредактировать, конкретизировав, если нажать на значок «карандашика» в соответствующей колонке. В колонке «Services» также нажимаем на аналогичный значок и выбираем службы (если ничего не назначено, по умолчанию будет «Any»), в колонке «Profiles» заходим в редактирование и выбираем нужный контекстный профиль либо добавляем новый, нажав на «Add New Context Profile», а по колонке «Applied To» будет по умолчанию значение «DFW», чтобы правило применилось ко всем рабочим нагрузкам. Но, можно выбрать и определенную группу.

Важно! Нельзя использовать типы групп с IP или MAC адресами, а также AD пользовательскую группу.

В колонке «Action» выбираем, как обычно, Allow/Drop/Reject, и нажимаем подсвеченную кнопку, чтобы включить или отключить правило. Затем нажимаем по правилу значок «шестеренки», чтобы назначить настройки по следующим опциям:

Logging (по дефолту выключено, но можно включить, чтобы логи сохранялись в «/var/log/dfwpktlogs.log»);
Direction (соответствует направлению трафика с точки зрения объекта назначения – «IN», «OUT» или «In/Out»);
IP Protocol;
Log Label.

После всего публикуем правило кнопкой «Publish». Опять-таки можно сразу создать целый комплект правил, а затем опубликовать их все вместе.

Чтобы проверить статус каждой политики, можно по ней нажать на «Check Status». Там будет «Success» или «Failed», и если кликнуть на них, то откроется окно с конкретизацией статуса.

Создание политик и правил шлюза из GM

В UI заходим на «Security» – «Gateway Firewall» и определяемся с нужной категорией («Pre Rules», «Local Gateway» и «Default»). С первой и последней работать не получится – только с «Local Gateway». Делается это из вкладки «All Shared Rules», где следует кликнуть на название этой категории, или напрямую зайти на вкладку «Gateway Specific Rules».

Здесь выбирается шлюз (Т0/Т1) из выпадающего списка по пункту «Gateway», в результате чего его спан станет дефолтным для этой политики файервола шлюза и его правил.

Важно! Диапазон политики можно уменьшать, но не увеличивать.

После этого нажимаем на «Add Policy» (для правила – потом – «Add Rule») и далее процедуры полностью аналогичны тому, что мы делали для политик DFW и правил из GM, вплоть до проверки статуса (см. выше).

Восстановление GM и сети для LM

Если в среде Федерации вдруг потерялся активный GM, всегда можно переключиться на GM в статусе Standby. С этой целью просто заходим на Standby GM и выбираем «Make Active» из выпадающего меню «Actions».

Если вместе с первоначально активным GM потерялся и LM, перемещаем растянутые Т0 и Т1 шлюзы на вторичный сайт. Для этого в GM существует опция авто-обнаружения «Network Recovery». Чтобы ею воспользоваться, заходим на «System» – «Location Manager», где появится специальный баннер, оповещающий о проблеме. На нем нужно нажать «Network Recovery», чтобы стартовала процедура «Location Disaster Recovery». В ее визарде проходим следующие шаги:

По каждому Т0-шлюзу, на котором упавшая локация обозначена как главная, выбираем новую главную локацию и сохраняем настройку «Apply Configuration». «Next»;
Здесь нужно восстановить Т1, однако только в том случае, когда их спан отличается от спана Т0. Если же они совпадают, или спан Т1 меньший, для Т1 восстановится все автоматически. Но, при желании, именно здесь можно поменять выбор локации в качестве главной, а фиксируется все назначение кнопкой «Accept». «Next»;
В «Single Location Entities» будет список Т0 и Т1, которые нельзя перенести на новую главную локацию, так как они существуют исключительно на той, которая упала. «Next».

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

Далее восстанавливаем вычислительные ВМ, используя, например, VMware SRM или же другой предпочитаемый метод.

Важно! Если еще до завершения процесса смены статуса GM второй локации на активный, первый поднимется, статус первого GM будет показываться как «NONE». В конце концов его можно будет просто назначить как «Standby».

Обновление NSX-T Federation с версии 3.0 на 3.1

Апгрейд Федерации с первой ее версии – 3.0, – на 3.1, вдруг, вы уже являетесь активными пользователями решения и хочется попробовать на вкус его новейшие функции, ничем не отличается от банального обновления NSX-T Data Center, которому мы посвятили отдельную статью из цикла по виртуализации сетей «Обновление VMware NSX-T Data Center до версии 3.1». Поддерживаемый путь апгрейда (с какой версии можно обновлять на какую) там приведен для 3.1.0, как и замечания, касающиеся конкретно Федерации. Для актуального на момент написания этого материала матрица пути апгрейда выглядит так:

Важно! Если уже начали процесс обновления Федерации, завершить его, приведя все Appliance GM и LM к одной версии, критически важно. Пока у нас только один шажок с редакции до редакции, а в дальнейшем, помните, что вначале грейдятся старейшие версии компонентов до более свежих, рабочих на данный момент, и только потом все вместе – до новейшего варианта.

Важно! LM обновляем в первую очередь, GM – последним.

Для справки, полный план обновления среды Федерации приведен в «Обновление VMware NSX-T Data Center до версии 3.1».

Что ж, вот и завершился наш экскурс в NSX-T Federation, в котором мы постарались максимально доходчиво объяснить, что же это, на самом деле, такое, как все это работает и как с ним управляться. Безусловно, найдутся еще аспекты, нами не затронутые, однако это уже – повод для обращения за частными консультациями или же посещения авторизованных курсов VMware по NSX-T, где уже почти год теме Федерации уделяется один персональный модуль.