Категорії
News 2021

VMware NSX-T Data Center 3.1.1 Release Notes

В середине осени к «тройке» NSX было выпущено первое серьезное обновление, по изменениям в котором освежить свою память можно здесь. А совсем недавно – 27 января 2021 года – Vmware выпустило к нему первый патч – 3.1.1.

Безусловно, обойти его своим вниманием мы не могли, поэтому ниже обнародуем краткую сводку по содержанию NSX-T Data Center 3.1.1, расскажем, где взять его новый билд и какие ошибки со времени выпуска 3.1 были исправлены. Тем более, что, к тому же, в NSX-T Data Center 3.1.1 добавилось кое-что интересное. Но, обо всем по порядку.

Актуальная сборка

Последний, датированный 27.01.2021 г. билд 17483185, можно скачать отсюда.

Изменения в NSX-T Data Center 3.1.1

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

L3

  • OSPFv2 поддержка на Т0-шлюзах. Теперь NSX-T Data Center 3.1.1 поддерживает OSPFv2 как динамический протокол маршрутизации между Т0-шлюзами и физическими роутерами. Включается только на внешних интерфейсах и все они могут находиться в одной области OSPF, даже по нескольким Edge-нодам, что существенно упрощает миграцию с текущего разворота виртуальных сетей под vSphere с OSPF в NSX-T Data Center.

Миграция NSX Data Center под vSphere в NSX-T Data Center

  • Поддержка функции «Universal Objects Migration» для одиночного сайта. Сайт, развернутый в режиме основного, можно смигрировать с NSX Data Center под vSphere в NSX-T Data Center, и при этом как локальные, так и универсальные объекты будут перемещены в локальные объекты на локальном NSX-T. Функция не поддерживает кросс-vCenter-среды и вторичные менеджеры NSX;
  • Миграция среды NSX-V инструментами vRealize Automation. Продолжилась работа над реализацией идеи использовать vRA в процессе миграции старого поколения виртуальных сетей. Этот релиз предложил дополнительные топологии и случаи применения для тех, кто уже начал переход на NSX-T1.0;
  • Модульная миграция для хостов и распределенного файервола. В координаторе миграции NSX-T добавлен новый режим, занимающийся переносом исключительно конфигурации распределенного файервола и хостов, оставляя на усмотрение администратора логическую топологию (L3, службы). Теперь он позволяет разворачивать шлюзы Т0/Т1 и соответствующие сервисы при in-place-миграции, в результате чего достигается куда большая гибкость в смысле топологии. Функция доступна как через UI, так и с API;
  • Модульная миграция распределенного файервола в UI NSX-T. На самом деле, эта функция была предъявлена еще в 3.1.0, однако сейчас ее несколько доработали. Она позволяет переносить настройки файерволлинга, членство и статус из среды NSX Data Center для vSphere в среду NSX-Т Data Center. Среди ее позитивных качеств существенное упрощение поэтапной миграции с vMotion;
  • Полностью валидирован сценарий для увеличения и уменьшения использования vMotion, миграции распределенного файервола и L2-расширения с мостом.

Identity Firewall

  • Поддержка NSX Policy API настроек Identity Firewall. Установки AD для использования в правилах Identity Firewall теперь могут настраиваться и через NSX Policy API (https://<nsx-mgr>/policy/api/v1/infra/firewall-identity-stores), что идентично существующему NSX Manager API (https://<nsx-mgr>/api/v1/directory/domains).

Расширенная интеграция Load Balancer

  • Поддержка Policy API Avi-конфигурации. Уникальные типы объектов предоставляются конечным точкам через «https://<nsx-mgr>/policy/api/v1/infra/alb-<objecttype>»;
  • Вставка служб. Завершен очередной этап внедрения функции поддержки Transparent LB в NSX-T расширенного балансировщика нагрузок. Avi пересылает трафик балансировщика нагрузок на сервера с клиентскими IP в качестве источника IP. Эта функция использует вставку службы для перенаправления обратного трафика в механизм службы для обеспечения прозрачной балансировки нагрузки без необходимости в каких-то изменениях на стороне сервера.

Платформа Edge и службы

  • Ретранслятор DHCPv4 на сервисном интерфейсе. Т0 и Т1-шлюзы поддерживают ретранслятор DHCPv4 на сервисных интерфейсах, включая сторонний DHCP-сервер при его расположении в физической сети.

ААА и безопасность платформы

  • Гостевые пользовательские и локальные пользовательские аккаунты. Клиенты NSX интегрируют их существующие корпоративные хранилища идентификации во встроенные пользовательские для нормальной деятельности NSX-T. Для обеспечения разных сценариев применения и упрощения работы представлены два гостевых локальных пользователя в дополнение к существующим администраторскому и аудиторскому. С этой функцией администратор NSX получает расширенные привилегии для управления жизненным циклом пользователей (ротация паролей и т. п.), включая настройку и назначение соответствующих RBAC-разрешений. При этом возможности локальных пользователей доступны как на LM, так и на GM, однако не охватывают Edge-ноды через API и UI. Гостевые пользователи выключены по дефолту и нуждаются в активации в виде исключения для этого доступа, причем могут быть отключены в любое время;
  • Совместимое с FIPS обновление Bouncy Castle. Теперь NSX-T1.1 содержит проапдейченную версию FIPS, совместимую с Bouncy Castle 1.0.2.1. Модуль Bouncy Castle представляет собой сборник криптографических библиотек на Java, функций и API, и весьма активно используется в NSX-T Manager. Новая его версия решает критические баги в безопасности и упрощает совместимость операций безопасности NSX-T.

NSX Cloud

  • NSX Marketplace Appliance в Azure. Появилась опция для полноценного разворота уровней управления и контроля NSX в публичных облаках Azure. Компоненты этих уровней и NSX Cloud Public Cloud Gateway (PCG) содержатся в пакетах VHD и доступны в Azure Marketplace. Кроме того, для разворотов с нуля можно использовать terraform-скрипт «по одному щелчку»;
Важно! Эту функцию в AWS VMware обещает добавить в следующих релизах.
  • НА NSX Cloud Service Manager. Для разворотов уровня управления/контроля в публичном облаке для CSM доступна НА. Так как PCG, в любом случае, разворачивается в режиме active-standby, НА для него всегда справедливо;
  • Усовершенствование NSX-Cloud для инфраструктуры виртуальных десктопов Horizon Cloud. При использовании NSX Cloud для защиты VDI Horizon в Azure можно инсталлировать агент NSX как часть установки Horizon-агента в VDI. Функция адресована, в том числе гибридным схемам, в которых VDI, PCG и др. комбинируются и с разными поддерживаемыми версиями ОС. В результате любая версия PCG может сотрудничать с любой версией агента на ВМ.

Новое в работе

  • Upgrade Readiness Tool для миграции из NVDS в VDS из UI NSX-T Data Center. В процессе миграции транспортных нод с NVDS в VDS можно использовать Upgrade Readiness Tool в визарде «Getting Started» прямо в UI менеджера.

Контейнерная сеть и безопасность

На кластерах vSphere с Tanzu NSX-T 3.1.1 поддерживает на каждый vCenter, максимально, 50 кластеров ESXi, включенных с vLCM. Соответствующие изменения внесены в таблицы лимитов конфигураций.

Сертификация

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

Новое в лицензировании

VDS теперь подлежат лицензированию во всех редакциях vSphere для пользователей NSX-T Data Center. Можно применять эквивалентное кол-во лицензий на CPU для использования VDS.

Исправленные проблемы и ошибки

  • В UI статус реализации профиля BFD отображен как «uninitialized» (смысловой нагрузки не несет, можно игнорировать);
  • Состояние реализации для успешно внедренного Global T0 на встроенном сайте некорректно показывает ошибку «logical router port configuration realization error» для транспортных нод Edge сайта;
  • При добавлении глобальной службы как встроенной в LM не демонстрируется никакой ошибки (вроде, все хорошо, но реализация не осуществляется);
  • Общий консолидированный статус показывает «IN_PROGRESS», в то время как индивидуальный консолидированный статус по каждой точке применения – «SUCCESS»;
  • Повторяемый лог ObjectNotFoundException и обратная трассировка исключения в процессе сбора данных по трассировке или результату ее действий в режиме реального времени;
  • В Федерации, если дочерняя группа используется двумя разными группами и вторая родительская группа обладает более высоким спаном, спан дочерней группы может быть большим, чем спан первой группы из-за специфики создания объектов. Спан первой группы может расшириться, однако обратно к своему оригинальному состоянию возвращен быть не может. Теперь уменьшать спаны домена в GM нельзя вообще;
  • Порт сегмента может быть создан до того, как успешно создалась транспортная нода физического сервера Windows, и в результате он уходит в статус ошибки;
  • Миграция NVDS в CVDS с помощью vSphere Update Manager в параллельном режиме полностью не поддерживается;
  • IPv6 обнаружение дубликатов IP (DAD) вводит трехсекундную задержку на Т0/Т1 SR позади порта (и для Т1 SR порта аплинков), когда IP перемещается с одного SR на другой в процессе восстановления после падения. В итоге N-S-связь демонстрирует шестисекундные падения трафика при аварийном переключении с Т0 А/А;
  • Не получается назначить GM как standby из пользовательского интерфейса после незапланированного переключения, когда такой GM сначала потерялся, а затем вернулся обратно в онлайн;
  • Когда используется API уровня управления для настройки режима L3-пересылки, Policy перезаписывает изменения уровня с дефолтным режимом «IPV4_ONLY» и прерывает связь по IPv6;
  • При обновлении до NSX-T1 в разделе апгрейда хостов кнопка «Stage» на месте и активна для всех кластеров/хостов группы;
  • Канал асинхронного репликатора иногда остается в упавшем состоянии при перезапуске ноды;
  • Статус синхронизации репозитория показывает сбой в UI NSX Manager, однако можно запускать все инсталляции и операции, связанные с апгрейдом;
  • Рабочий процесс обновления LM прерывается, если LM был добавлен в GM с использованием его VIP, а позднее публикуется его FQDN;
  • Действие правила DFW jumpto не поддерживается правилами L7 APPID или FQDN-контекстными профилями (после vMotion);
  • Апгрейд Edge, развернутый на bare metal-сервере с более чем одним диском, может не состояться (сбой посередине апдейта при перезагрузке);
  • При выводе физического сервера из NSX связь с ним теряется, и деинсталляция NSX дает сбой (в случае прикрепленного интерфейса порта сегмента на физическом сервере, настроенного как «Using existing IP»);
  • При добавлении bare metal-сервера Windows 2016/2019 показывается ошибка «host disconnected» на этапе «Applying NSX Switch Configuration»;
  • При подключении рабочих нагрузок к Т0 сегментам и отсылке IGMP-выхода для группы G запись удаляется из снупинг-таблицы IGMP на Т0 SR;
  • GM может работать медленно в процессе удаления большого количества ресурсов по сайтам. Периодически появляются сообщения об ошибке, что конкретный источник не может быть создан или удален, так как это затрагивает диапазон многих источников, участвующих в очищении сайта;
  • LTA-сеансы не освобождаются при параллельном возникновении запросов LTA. Хост постоянно сообщает об этом на уровень управления (МР), поэтому MP получает нехватку сеансов LTA и фиксирует соответствующий лог в «nsxapi.log». Пакеты, посланные с хоста с неочищенным сеансом LTA, дополняют заголовок Geneve;
  • IDS с включенными прокси-настройками не может получить доступ к GitHub, используемому в загрузке сигнатур;
  • Если физический сервер Windows 2016/2019 не завершен, порт сегмента сбоит при попытке создать порт сегмента;
  • На bare metal Edge трафик, идущий через VRF-шлюз, может не достигать пункта назначения;
  • Связь GM с LM падает (рабочие процессы, связанные с входом/вводом отпечатка) после замены сертификата LM;
  • Если DHCP-сервер не настроен, получение статистики/статуса DHCP на Т0/Т1-шлюзах или сегментах показывает ошибку, указывающую на неуспешную реализацию (функционально не имеет значения);
  • Поиск в политике сбоит с ошибкой «Unable to resolve with start search resync policy» (не синхронизированность при предоставлении нод NSX Manager с новыми IP);
  • Миграция свитчей с NVDS в CVDS не поддерживает stateless ESX с vmks;
  • Если профиль транспортной ноды применяется на кластере до миграции, создается один дополнительный профиль транспортной ноды в изолированном состоянии;
  • Статус GM показывается как успешный, а затем снова падает в «IN_PROGRESS»;
  • При изменении роли сайта на растянутый T1-LR любой трафик с этого логического роутера плотно сжимается на 6-8 минут;
  • Если тип выбран как «TIER0_EVPN_TEP_IP» в распределении маршрутов T0 VRF LR, этот тип не распределяется в BGP как существующий в родительском Т0 LR, и в итоге путь данных обрывается;
  • Правила файервола не применяются для кросс-сайтового vMotion, если найденные порты сегментов используются в глобальных группах;
  • При задании «ANY» в правиле «ANY SNAT» указанные для свойств сетевого источника/сети назначения/транслированной сети адреса содержат пустые строки («»), что приводит к ошибке реализации на уровне управления.

Дополнение релиза от 4 марта 2021 года

Новая редакция Release Notes NSX-T Data Center 3.1.1 от 04.03.2021 г. дополнилась подразделом о Федерации. Там всего два новшества:

  • Увеличение масштабируемости хоста с 256 до 650. Соответствующие изменения внесены в таблицы конфигурационных лимитов;
  • Добавлена оркестровка через PowerCLI в дополнение к Terraform. Для интересующихся, полезные примеры можно найти здесь.

No related posts.