Категорії
News 2020

NSX-T Data Center 3.1 Release Notes

30 октября стала доступной для скачивания новая версия NSX-T – 3.1.0. Этот релиз ПО для организации виртуальных сетей предложил действительно объемный и важный пул изменений, быть в курсе которого, без сомнений, будет интересно всем, кто работает с этим продуктом.

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

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

Все образа для закачки нового NSX-T Data Center 3.1 доступны здесь: билд 17107167. С разбивкой по уровню лицензии, а также с отдельными пакетными обновлениями vRealize Log Insight 8.2.0 и Identity Manager 3.3.3.

Что нового в NSX-T Data Center 3.1?

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

  • Масштабируемые облачные сети. Расширены возможности многоадресной пересылки, улучшена федерация;
  • Новое поколение SDN. Упрощен переход с NSX-V на NSX-T;
  • Внутренняя безопасность. Усовершенствованы процессы жизненного цикла и мониторинга на базе FQDN, внедрен распределенный IPS;
  • Lifecycle и мониторинг. Поддержка vSphere Lifecycle Manager (vLCM), улучшенный мониторинг, поиск и фильтрация, упрощение процедур установки;
  • Изменения в терминологии. В пользовательском интерфейсе и документации введена замена некоторых терминов, употребляемых в процессах широкого спектра действий по удалению инстансов не инклюзивных языков в продуктах VMware. В журналах логов, API и CLI по-прежнему используются старые термины.

Пройдемся по каждому пункту детально.

Федерация

  • Поддержка резервного кластера Global Manager (Standby GM). Теперь Global Manager может иметь активный кластер и резервный – в другой локации. Требования к организации: задержка между резервным и активным кластерами не должна превышать 150 мс;
  • Благодаря обновлению Federation и внедрению понятия Standby GM, федерация может считаться готовой к продакшену.

Сети L2

  • Доступно изменение отображаемого имени для TCP/IP-стека. Ключи сетевого стека прежние («vxlan» и «hyperbus»), однако в пользовательском интерфейсе они отображаются как «nsx-overlay» и «nsx-hyperbus». Отображаемые имена поменялись не только в списке сетевых стеков, но и в списке VMKNIC. Это нововведение работает с vCenter 6.7 и старше;
  • Улучшены мониторинг и устранение неисправностей моста L2. В интерфейсе командной строки, пользовательском и документации произведена унификация терминологии. Добавлены новые CLI-команды для получения сводки и детализированной информации о профилях L2 Bridge и его параметрах. Сообщения журналов логов помогают легче идентифицировать профиль моста, а также вовлеченных логических свитчей, разбираться в причинах изменения их состояния;
  • Поддержка TEP в разных подсетях для полномасштабного использования разных физических каналов связи. Снято ограничение на инициализацию IP-адреса TEP для всех коммутаторов хоста как расположенных в одной подсети. Полезно в ситуации, когда в транспортном узле предусмотрено несколько подключенных к различных транспортным зонам свитчей;
  • Обнаружение IP-адресов в NS Group. Профили обнаружения IP-адресов теперь применимы и к группам NS, благодаря чему упростилось использование Firewall Admin.

Сети L3

Улучшены API-политики. Добавлена возможность настраивать через API-политики пиры BFD на шлюзах и таймер пересылки по каждому VRF, а также с их же помощью получать информацию о входах прокси ARP шлюза.

Многоадресная пересылка

  • Поддержка многоадресной репликации на шлюзе первого тира;
  • Поддержка IGMPv2 на всех нисходящих и восходящих каналах с уровня 1;
  • Поддержка PIM-SM на всех восходящих каналах (поддерживается максимальная конфигурация) между каждым тир-0 и всеми TOR (защита от падения TOR);
  • Возможность запуска Multicast в A/S и Unicast ECMP в A/A из Tier-1 в Tier-0 и из Tier-0 в TOR;
Важно! Unicast ECMP не поддерживается на пути из ESXi-хоста в Т1, когда хост прикреплен к Т1, в котором уже включена многоадресная пересылка.
  • Поддержка программирования и обучения статического RP при помощи BS & Support для множественных статических RP;
  • Поддержка распределенного файервола для многоадресного трафика;
  • Улучшен troubleshooting. Добавлена возможность настройки локальных групп IGMP на восходящих каналах с целью выполнения Edge функций получателя. Момент важен для сортировки проблем многоадресной пересылки, так как работает с многоадресным трафиком определенной группы в Edge.

Платформа Edge и ее сервисы

  • Связь между ТЕР внутри одного хоста. IP Edge TEP может находиться в той же самой подсети, что и локальный гипервизор ТЕР;
  • Поддержка повторного разворачивания ноды Edge. Несуществующую ноду Edge, виртуальную машину или физический сервер можно заменить новыми без необходимости удалить старые;
  • Ограничение NAT-подключений на каждый шлюз. Можно настроить максимальное количество NAT-сеансов для определенного шлюза.

Файервол

  • Усовершенствован брандмауэр на FQDN. Можно определить FQDN, применяемые в распределенном файерволе. Доступно либо добавление индивидуальных FQDN, либо импортирование набора FQDN из CSV-файлов.
  • Функции брандмауэра:
    • Экспорт и импорт. Новая версия NSX предлагает экспортировать и импортировать правила политик файервола в виде файлов CSV;
    • Расширенный поиск и фильтрация. Усовершенствованы параметры поисковой индексации и фильтрации для правил брандмауэра на основе диапазонов IP-адресов.

Распределенная система обнаружения/предотвращения вторжений (D-IDPS)

  • Настраиваемая система блокировки угроз. В NSX-T1.0 теперь можно блокировать угрозы на основе настроенных для проверки сигнатур;
  • Расширенная панель управления. Предоставляется подробная информация об обнаруженных и заблокированных угрозах;
  • Профиль IDS/IPS. Улучшение процесса создания профиля IDS/IPS расширением списка параметров до типов атак, их целей и оценок CVSS, чтобы обнаружение стало более таргетированным.

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

  • Сохранение активности на стороне HTTP-сервера. Можно поддерживать однозначный маппинг между подключением на стороне сервера и подключением на стороне клиента. Соединение бэк-енд поддерживается, пока фронт-енд-связь не будет прервана;
  • Соответствие cookie безопасности HTTP. Поддерживаются опции «httponly» и «secure» для файлов cookie HTTP;
  • Новая команда для диагностики в CLI. Единственная команда для фиксации различных относящихся к Load Balancer исходящих проблем.

VPN

TCP MSS Clamping для L2 VPN. Функция TCP MSS Clamping позволяет сеансу L2 VPN пропускать трафик при несоответствии MTU.

Автоматизация, OpenStack и API

  • Расширена поддержка NSX-T Terraform Provider федерации. Полезно для создания сложных логических конфигураций с сетью, безопасностью (включая сегмент, шлюзы, межсетевой экран и пр.) и службами в модели «инфраструктура как код». Больше почитать об этом можно здесь;
  • Преобразование в NSX-T Policy Neutron Plugin для OpenStack-среды, использующей Management API. Специальный плагин позволяет перемещать OpenStack со средой NSX-T из Management API в Policy API. Удобно в процессе переноса среды на NSX-T 2.5 и старше на последнюю версию плагина NSX-T Neutron, чтобы иметь доступ к новейшим возможностям платформы;
  • Изменение порядка NAT и FWLL на роутере OpenStack Neutron. Можно выбирать порядок работы NAT и FWLL, например, следующим образом: сначала NAT – потом файервол, либо файервол – затем NAT. Годится для уровней маршрутизатора OpenStack Neutron, сопоставимого с Т1 в NSX-T;
  • Усовершенствована политика API в NSX. Можно фильтровать и извлекать все объекты в поддереве иерархии NSX Policy API. Заметим, ранее фильтрация выполнялась из корневого каталога дерева при помощи «policy/api/v1/infra?filter=Type-». Теперь же все конфигурации нулевого уровня доступны прямо по «/policy/api/v1/infra/tier-0s?filter=Type-», без спецификации всех связанных с Т0 объектов из корневого каталога.

Управление

  • Поддержка vSphere Lifecycle Manager (vLCM). Начиная с vSphere 7.0U1, для NSX-T Data Center доступна поддержка в кластере, управляемом единственным образом vLCM. В частности:
    • Можно добавлять и удалять хосты из кластера, управляемого одним vLCM, и ESXi;
    • И NSX-T Data Center, и ESXi апгрейдятся одной задачей vLCM (доступно только для последней версии NSX-T);
    • Доступна проверка соответствия, создание отчета о пре-чеке, исправление кластера единственным образом vLCM;
  • Упрощен процесс установки хоста/кластера кнопкой «Getting Started» в UI. Автоматически предлагается сетевая конфигурация на основе настроек основного хоста в соответствующем мастере-установщике с богатым интерфейсом, рекомендованная NSX-T. После выбора кластера, можно установить NSX на него по одному щелчку мыши. Любые изменения сети перед инсталляцией NSX динамически обновляются, чтобы пользователь мог к ним обращаться сразу, как только в том возникнет необходимость;
  • Усовершенствование в «in-place»-апгрейдах. Увеличен максимальный порог количества виртуальных сетевых адаптеров, поддерживаемых хостом, убраны предыдущие ограничения, и сокращено время простоя при перемещении данных в процессе «in-place»-апгрейдов;
  • Уменьшен размер VIB. Отпечатки VIB уменьшены для всех инсталляций NSX-хостов, благодаря чему можно устанавливать ESX и сторонние VIB вместе с NSX на гипервизоры;
  • Улучшена установка NSX-T на физический сервер. Для упрощения сквозной инсталляции NSX-T Data Center на физических серверах теперь все операции выполняются через NSX Manager. Больше не требуется запускать скрипты Ansible для настройки сетевого подключения;
  • Поддержка ERSPAN на выделенном сетевом стеке с ENS. В стеке vmk теперь можно настроить ERSPAN и поддерживать его при помощи улучшенного сетевого свитча ENS, благодаря чему растет производительность и пропускная способность зеркалирования портов ERSPAN;
  • Singleton Manager с vSphere HА. NSX поддерживает разворот одного NSX Manager в продакшене совместно с vSphere HA для восстановления отказавшего NSX Manager.
Важно! Время восстановления для одного NSX Manager при помощи функции восстановления или восстановления из бэкапа с vSphere HA может увеличиться, по сравнению с обеспечиваемой кластером NSX Manager доступностью.
  • Согласованность журналов логов во всех компонентах NSX. Единый формат и сквозная документация различных компонентов NSX дают возможность легко анализировать журналы с целью автоматизации процессов, вследствие чего растет эффективность использования логов для мониторинга и устранения сбоев;
  • Поддержка Rich Common Filters. Расширены общие фильтры для операций захвата пакетов, зеркалирования портов, измерения задержки и IPFIX с целью увеличить эффективность работы пользователей;
  • Улучшен интерфейс командной строки. А именно:
    • Команды «get» CLI теперь сопровождаются отметками времени для облегчения отладки;
    • Добавлены команды «GET/SET/RESET VIP» (Virtual IP) для кластера управления NSX;
    • Запуск команд пингования напрямую на локальных машинах через центральный интерфейс позволяет избежать лишних действий в процессе логирования;
    • Доступен просмотр списка ядра любого компонента NSX;
    • Оператор «*» теперь может использоваться в CLI;
    • Добавлены команды отладки L2Bridge;
  • Распределенный Load Balancer Traceflow. Traceflow теперь поддерживает распределенный Load Balancer для траблшутинга сбоев связи от точек служб до конечных точек, развернутых в vSphere с Tanzu.

Мониторинг

  • Ивенты и предупреждения:
    • Панель емкости (максимальная емкость, порог максимальной и минимальной емкости);
    • Состояние Edge (запасной переход на другую Edge-ноду, блокировка потока Datapath, создание файла ядра NSXT Edge, случай падения логического свитча, сбои процессов Edge, высокая задержка связи с хранилищем, ошибка хранилища);
    • ISD/IPS (NSX-IDPS Engine Up/Down, использование NSX-IDPS Engine CPU превышает 75/85/95%, достигнуто максимальное количество ивентов, использование памяти NSX-IDPS превышает 75/85/95%);
    • IDFW (подключение к AD-серверу, ошибки в процессе синхронизации дельты);
    • Federation (от GM к GM Split Brain);
    • Связь (падение канала управления транспортным узлом, канал управления транспортной нодой не работает слишком долго, падение канала управления Manager Node, канал управления Manager Node не работает слишком долго, падение канала Management для транспортного узла, канал Management для транспортного узла не работает слишком долго, сбой Manager FQDN Lookup и сбой Manager FQDN Reverse Lookup);
  • Использование ERSPAN для быстрого доступа к ENS (поддержка мирроринга портов);
  • Усовершенствован плагин системного хелс-чека;
  • Трассировка и анализ живого трафика. Внедрен специальный инструмент, поддерживающий двунаправленный поток трассировки между локальными ЦОД и ЦОД VMC;
  • Статистика задержек и измерения для узлов UA. Речь о задержках между нодами NSX Manager и кластером NSX Manager, а также между разными кластерами NSX Manager на различных сайтах;
  • Service Insertion в характеристике производительности для мониторинга сети.

Пользовательский интерфейс

  • Графическая визуализация VPN. Карта топологии сети помогает наглядно продемонстрировать результат настройки сессий и туннелей VPN;
  • Dark Mode. Можно переключаться между темным и светлым режимом интерфейса;
  • Экспорт и импорт файервола. (см. выше подраздел «Файервол»);
  • Улучшен поиск и фильтрация. (аналогично см. выше «Автоматизация, OpenStack и API» и «Управление»);
  • Уменьшено количество кликов при редактировании сетевых объектов.

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

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

Распределение по уровню лицензии сохранилось, и, если ранее применялись функции, которые в текущую их редакцию не вошли, они будут доступны исключительно в режиме просмотра объектов (без создания и редактирования), пока не будут приобретены соответствующие ключи. Деление на Standard/Professional/Advanced/Enterprise Plus/ROBO в редакции июня 2018 года актуально, и все старые ключи NSX для vSphere – рабочие.

В качестве нового в лицензировании NSX Data Center добавлена поддержка NSX Firewall и NSX Firewall с лицензией Advanced Threat Prevention.

Больше о лицензировании конкретно VMware NSX-T Data Center можно почитать здесь.

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

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

Помимо этого, в системе безопасности платформы предусмотрено отражение сбоев в журналах аудита, играющих жизненно важную роль в управлении рисками кибербезопасности и диагностике проблем производительности. Эти уведомления приведены в соответствие с NIST-800-53 и отраслевыми стандартами.

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

И, наконец, завершая разговор о новом в безопасности NSX-T, стоит отметить, что криптографические модули, применяемые актуальной версией, прошли проверку FIPS 140-2 (действует с NSX-T 2.5). Это было сделано с целью расширения формальной сертификации, чтобы обеспечить совместимость с vSphere 7.х.

Новое в совместимости и требованиях

В проверке совместимости VMware NSX-T 3.1.0 с другими компонентами среды, аппаратной и программной ее частью, как обычно, нам помогает VCG. В деталях все необходимые требования и ограничения обязательно будут описаны в наших будущих материалах, посвященных обновлению виртуальной сети и ее развороту с нуля.

Локализация

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

  • английский,
  • немецкий,
  • французский,
  • японский,
  • упрощенный китайский,
  • традиционный китайский,
  • корейский,
  • испанский.
Важно! Локализация NSX-T 3.1.0 тесно завязана на языковые настройки браузера.

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

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

  • Ряд версий хостов ESXi уходит в перезагрузку в процессе обновления NSX-T, если там в наличии устаревшие фильтры DV. Речь о ESXi 6.5U2/U3 и 6.7U1/U2.
  • В NSX-T не устанавливаются VIB из-за недостатка места. Ошибка вида «BootBankInstaller.pyc: ERROR» при загрузке сторонних VIB.
  • Профиль DHCP выдает сообщение «NOT SET» и кнопки «Apply» неактивны при конфигурировании шлюза DHCP на сегменте. Совет: обязательно предварительно настроить DHCP.
  • Группы с наборами IP из Manager Mode могут создаваться из Global Manager.
  • Если настроен упреждающий режим НА и включен IPSec HA, в процессе двойного сбоя наблюдается сброс пакетов поверх VPN. Речь о сбросе трафика вне VPN на сторону пиров. IPSec HA выдает все большее число ошибок.
  • Инстанс службы не создается после повторного добавления того же самого хоста в кластер, если ВМ службы уже есть на ноде. Статус разворота при этом успешен, однако защита на этом хосте выключается.
  • Регистрация vCenter как вычислительного ресурса с NSX Manager завершается ошибкой, даже если предварительно создалось расширение NSX-T «com.vmware.nsx.management.nsxt» в vCenter. Статус «Not Registered» и операции на vCenter, вроде автоматической установки Edge и других, не выполняются.
  • Несоответствие между выводом CLI и политикой вывода для таблиц маршрутизации. Имеются в виду загруженные из пользовательских интерфейсов таблицы маршрутизации с большим количеством маршрутов по сравнению с выводом CLI.
  • Карты маршрутизации и перераспределения шлюзов Tier-0, созданные в упрощенном пользовательском интерфейсе или API-политикой, замещают то, что создается в расширенном UI (или в MP API).
  • Таймер сеанса не срабатывает после обновления до NSX-T 3.0 в некоторых сценариях. При этом сеанс подключения может использовать свой системный таймер по умолчанию вместо настраиваемого.
  • В экранах пользовательского Manager-интерфейса, колонка «Alarms» не всегда показывает самый свежий счетчик сигналов тревоги. Последние созданные предупреждения не отображаются.
  • T-0 NSX Edge вычисляет неверную контрольную сумму UDP после инкапсуляции ESP при туннелированном трафике IPsec. Трафик сбрасывается.
  • При настройке источника идентификации LDAP аутентификация по LDAP Group – NSX Role Mapping не работает, если доменное имя LDAP было сконфигурировано в смешанном регистре. В доступе в NSX отказано.
  • Резервное копирование по расписанию может не случиться в некоторых случаях.
  • Правила распределенного файервола с применением контекстных профилей (layer 7) не работают, как ожидается, при использовании с подами Kubernetes. Вместо этого трафик попадает в дефолтное правило.
  • PNIC мигрируют с NVDS обратно на VDS-восходящие каналы с сопоставлением, которое отличается от исходного сопоставления в VDS. Ситуация с созданием транспортной ноды в Transport Node Profile, где есть сопоставление установки и деинсталляции PNIC, и последующим удалением этого ЦОД из транспортного узла.
  • Day2tools пытается смигрировать TN из NVDS на CVDS даже после назначения «ds-migrate disable-migrate». Миграция фейлится, и хост выпадает в режим техобслуживания.
  • SI и GI, использующие базовое развертывание хоста, не поддерживаются в процессе миграции NVDS в CVDS.
  • Load balancer не работает, когда постоянный Source-IP сконфигурирован на большом количестве виртуальных серверов. Потребляется слишком крупный объем памяти, в результате чего ее не хватает NSX Edge. Даже если устранить проблему по горячим следам, добавление дополнительных виртуальных серверов снова к ней приводит.
  • В окне «Restore Backup» для CSM нет доступных бэкапов, хотя их список присутствует на сервере.
  • Пользовательский интерфейс выдает общее сообщение об ошибке, не конкретизирующее ее. Например, об изменении виртуального IP Local Manager. Проблема оказывала прямое влияние на связь Global Manager с сайтом.
  • Удаление правил 5000 NAT иногда по времени занимает более часа. Правила NAT все еще отображаются в UI, но неактивны. Следует дождаться их очистки до создания правил NAT с аналогичным именем. Если имя выбрать другое, проблем не будет.
  • Сообщение в UI неполное, если система пытается подключиться к сайту со службой DNS на шлюзе первого типа в дополнение к службе LB. Пользовательский интерфейс отображает только текст соответствия со службой DHCP, однако аналогичное разрешение применимо и к службе DNS.
  • Проблема с Bare Metal в интерфейсе соединения ОС Linux при применении в профиле восходящего канала NSX. Ошибка вида:

Transport Node creation may fail

Эта ошибка исходит из того, что VMware не поддерживает бондинг Линукса. Однако для транспортных узлов Bare Metal Server она с легкостью использует Open vSwitch (OVS).

  • Правило «Anti-affinity» предотвращает использование ВМ службы vMotion в режиме техобслуживания. Проблема была актуальна для двух-нодовых кластеров и НА-пар с правилом анти-сродства. Автоматический переход в режим Maintenance был заблокирован.
  • Карта маршрутизации удаляется после модификации правила перераспределения на странице «Policy» или в API.
  • На странице «Context Profile» показываются неподдерживаемые сообщения об ошибках APP_ID, вида:

This context profile uses an unsupported APP_ID – [<APP_ID>]. Please delete this context profile manually after making sure it is not being used in any rule.

Проблема возникает из-за присутствия после апгрейда шести устаревших идентификаторов (AD_BKUP, SKIP, AD_NSP, SAP, SUNRPC, SVN), более не участвующих в процессе транспортировки данных.

No related posts.