Категорії
News 2021

VMware NSX-T Data Center 3.1.2 Release Notes

В конце января этого года VMware пропатчила наш самый, без преувеличений, полезный, глобальный и многофункциональный продукт, отвечающий за целое направление вендора – построение сетевой виртуализации. Он был первым к версии 3.1, цикл статей о которой мы публиковали в декабре 2020-го и все, что было в нем интересного, описано в нашей новости «VMware NSX-T Data Center 3.1.1 Release Notes». К слову, цикл этот включал в себя комплекс знаний, необходимый начинающему сетевому виртуализатору для эффективного старта в этой области или освежения информации по данному вопросу, – статьи по дизайну, установке и базовой настройке, администрированию и обновлению.

Сегодня же в прицел нашего внимания попадет очередной патч к NSX-T Data Center, изданный 17 апреля 2021 года, благодаря которому самой свежей стала версия 3.1.2. О том, где ее достать, что в ней конкретно поменялось и какие ошибки, тянущиеся из предыдущих релизов, были исправлены, мы и поговорим ниже в деталях.

Актуальный билд

Скачать новую версию нашего NSX-T Data Center 3.1.2  можно отсюда:

Там, как обычно, деление по уровню лицензии, плюс можно найти такие полезные штуки, как Network Insight, vRealize Log Insight под NSX, свежий вариант Identity Manager, HCX и многое другое.

Новое в NSX-T Data Center 3.1.2

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

NSX Cloud

  • HCS на Azure с NSX Cloud Testing. Дополнительные топологии HCS были протестированы и валидированы на NSX Cloud;
  • Дополнительная поддержка ОС NSX Cloud. Теперь поддерживаются и:
    • стандартная лицензия Windows 2012, 2016/2019 и Еnterprise-уровень Windows 10,
    • Red Hat Enterprise Linux 7.0, 7.1, 7.2, 7.3, 8.1, 8.2, 8.3.

События и предупреждения

  • Load Balancer. Добавлены статусы «Load Balancer/Distributed Load Balancer Status Degraded», «Load Balancer Service Memory Usage Very High»;
  • Edge Health. Аналогично – «Edge node Pool Member Capacity In Use Very High», «Edge node Load Balancer Capacity In Use High»;
  • IPAM. «IP Block Usage Very High», «IP Pool Usage Very High»;
  • Edge NIC Out of Receive Buffer. Опираясь на отзывы клиентов степень серьезности аварийного сигнала меняется с критической на предупреждение, а пороговое значение по умолчанию меняется с 0,1% на 0,2%.

Операции

Для облегчения траблшутинга проблем путей к данным на Edge добавлена опция Rolling Packet Capture. Ее можно включить как скользящий захват пакетов на Edge через nsxcli с максимум 25 файлами и предельным размером 100 МБ на файл. Это поможет запускать захват пакетов надолго при устранении периодически возникающих проблем с каналом передачи данных.

Миграция с NVDS на VDS

  • Поддержка параллельного апгрейда кластеров. Теперь можно мигрировать NVDS-свитчи хостов на VDS при обновлении ESXi-хостов до vSphere 7.0 U2, где кластеры хостов апгрейдятся параллельно. Максимально доступно участие 4 кластеров в процессе с этой функцией;
  • Поддержка файлового сервиса VSAN и share nothing-архитектуры ВМ при миграции свитчей.

Прекращение поддержки

Анонсировано прекращение поддержки хост-коммутатора N-VDS NSX-T. Известно, что NSX-T 3.0.0 и свежее могут работать на свитчах vSphere VDS версии 7.0 и более поздних. Это обеспечивает более тесную интеграцию с нашей средой и упрощает внедрение NSX-T. Однако, стало известно, что в следующем релизе NSX-T (выпуск запланирован, примерно, весной следующего года) виртуальные свитчи N-VDS на ESXi-хостах более поддерживаться не будут. Они останутся актуальными для KVM, NSX-T Edge-нод, нативных агентов публичных облаков и рабочих нагрузок bare metal. При новых развертываниях NSX-T рекомендуется сразу применять VDS-коммутаторы версии 7.0 и выше, а также запланировать на протяжении этого года миграцию на них со старых, если это необходимо.

Решенные проблемы

  • Формат кодирования для ручной настройки распознавателя маршрутов и конфигурация целевого маршрутизатора в EVPN-разворотах. Несмотря на то, что сейчас можно настраивать и в кодировке Type-0, и в Type-1, крайне рекомендуется пользоваться только вторым;
  • Очистка VIP не очищала интеграцию vIDM на всех нодах. Если VMware Identity Manager настроен на кластере с VIP, отключение VIP не влекло за собой очистку по всему кластеру. Приходилось вручную работать с каждой нодой по отдельности, чтобы поправить конфигурацию vIDM;
  • Для созданного в GM сегмента, если в нем настроен BridgeProfile, настройка соединения мостом Layer2 не применялась к отдельным сайтам NSX. Консолидированный статус сегмента оставался «ERROR». Причина кроется в отказе создать конечную точку моста на заданном NSX-сайте;
  • Пользователь LDAP не мог зайти в NSX только, если пользовательская запись AD не содержала UPN-атрибут, а только атрибут samAccountName;
  • При обновлении конфигурация vIDM могла не сохраниться. Теперь достаточно просто выключить и включить vIDM;
  • Не получалось проапдейтить nsxaHealthStatus для свитча, если его имя содержало одинарную кавычку. А конфигурация NSX, естественно, оставалась в статусе частичного успеха. Если же не использовать имена с таким знаком, все будет в порядке;
  • Попытка подключить vIDM к NSX с использованием nsx-cli сбоила, если флажки lb_enable и vidm_enable не были указаны специально. Ошибка вида:

An error occurred attempting to update the vidm properties

vIDM можно было подключать только напрямую через REST API, из UI или по CLI с обязательным определением этих флажков. Сейчас это неактуально;

  • При vMotion Edge встречались потери многоадресного трафика до 30 сек (дефолтный pim hello интервал). Если снупинг IGMP был включен на TOR, при vMotion Edge, на TOR приходилось определять новую локацию Edge. Он получал эту информацию, когда происходил любой контроль многоадресности, либо же непосредственно пересылка данных с Edge. Если выключить/включить pim на интерфейсе аплинка, подключенном к TOR, потери значительно сократятся;
  • Восстановление могло дать сбой. В этом случае помогает банальное нажатие на кнопку «Retry» в UI;
  • Пересылка пакетов между сайтами могло сфейлиться на нодах КVM, если групповой идентификатор vtep назначенной l2-пересыльщиком системы конфликтовал с ярлыком VTEP, что назначался транспортным нодам. Прикрепленные к растянутому сегменту ВМ могли потерять кросс-локационное подключение и кросс-сайтовый трафик мог не работать для конфликтующих сегментов в KVM-разворотах. Здесь найдено решение в виде определения нового сегмента и переключения на него рабочих нагрузок;
  • Опреационный статус правил файерволлинга на ВМ в облаках мог показываться как неизвестный по некоторым правилам, если случалось аварийное переключение НА шлюзов публичных облаков;
  • Было невозможно применить функционал «import CRL» через UI GM. В качестве решения предложено использовать API:

PUT https://{{gm-ip}}/global-manager/api/v1/global-infra/crls/cr11

  • Если транспортная нода обновлялась между URT и началом миграции, она теряла дополнительный конфигурационный профиль, а сама миграция сбоила на этапе TN_Validate. Теперь рекомендуется запустить URT и вызвать задачу MigrateToCvdsTask снова, после чего использовать API для очистки:

POST https://<manager-ip>/api/v1/nvds-urt?action=cleanup

  • Если были развернуты GI-сервисы в кластере, URT ApplyTopology сбоил, так как URT не мог изменить этот сервис на транспортной ноде. Возвращался статус «APPLY_TOPOLOGY_FAILED». Следует удалить разворот GI и перезапустить URT-пречек и ApplyTopology;
  • LR не работал после переключения свитча с IP-адреса на FQDN. Ошибка вида: «Fetching LR status timed out» в UI, а репликация логов GM останавливалась. Следует снять FQDN и перезапустить ноды LR на Active и Standby сайтах;
  • Вторая попытка адаптации конфигурации для сайта падала после успешного отката в GM. Статус адаптации застревал в «In progress» и не получалось дальше ничего сделать. Единственный предложенный выход из подобной ситуации – это убрать адаптацию и перезапустить ее на сайте. Операция вызовет очищение специфической для сайта настройки адаптационных статусов в GM и поможет начать свежую адаптацию сайта;
  • После обновления с NSX-T 3.0 на NSX-T 3.1 не получалось сделать никаких изменений для VRF LR. Если TIER0_EVPN_TEP_IP был добавлен в правиле перераспределения VRF LR было невозможно провести какие-либо изменения на VRF LR. Валидационный статус ошибки того «TIER0_EVPN_TEP_IP» не поддерживался VRF LR. Чтобы избежать этого рекомендуется использовать API политики для удаления TIER0_EVPN_TEP_IP на локальном сервисе VRF, после чего поменять имя, если это необходимо;
  • Время получения статуса синхронизации LR истекало, поскольку одна нода LR попадала в TransactionAbortedException и закрывала ее пул потоков. Было невозможно переключиться и LR останавливался. Следует перезапустить все LR-ноды на Active и Standby сайтах;
  • Вход на ноду NSX-T Manager под пользователемLDAP в масштабируемой AD конфигурации мог занять много времени или попросту сфейлиться. Рекомендовано обратиться к этому КБ;
  • Апгрейд NSX Cloud с более старой версии до NSX-T 3.1.1 мог временно переместить агенты ВМ в состояние ошибки. Терялся доступ к машинам и получался простой приложений, пока PCG обновлялся. Чтобы избежать этого следует проделать следующее:
    1. Пройти на страницу апгрейда CSM (подождать, пока страница загрузится около 5 минут);
    2. Нажать на «Begin Upgrade», и после завершения синхронизации покажется список vpc/instance. «Next»;
    3. Кликнуть на «Skip NSX Tools Upgrade»;
    4. Выбрать PCG для обновления. «Next»;
    5. Перезапустить апгрейд-координатор на CSM CLI (перезапустить службу инсталляции-обновления);
    6. Пройти на страницу апгрейда CSM. Подождать пока она загрузится снова;
    7. Нажать на «Begin Upgrade». После синхронизации список vpc/instance будет продемонстрирован;
    8. Выбрать агентов, подлежащих обновлению. «Next».

В результате увидим статус обновления агентов.

  • Трафик в направлении N-S терялся, если первичный PCG уходил в режим standby в процессе апгрейда. Вторичный PCG при этом становился активным. Нужно просто подождать, пока первичный PCG снова станет активным, когда апгрейд завершится;
  • Расширенное large-сообщество BGP сбоило, если было настроено с regex. FRR-CLI падал и конфигурация не применялась, из-за чего фильтрация BGP-маршрутов не работала;
  • Если был включен сервис IDS на транспортной ноде (хосте), трафик ВМ на ней внезапно мог оборвать свой поток. При включении NSX IDS/IPS (неважно, в режиме только обнаружения или в режиме обнаружения и предотвращения) в кластере vSphere и применении IDS/IPS к рабочим нагрузкам, могла произойти блокировка из-за простого механизма IDPS. В результате весь трафик к и от рабочих нагрузок на гипервизоре сбрасывался. На трафик, неподлежащий IDS/IPS или Deep Packet Inspection Services (L7 App-ID) это не распространялось. И как только IDS/IPS отключался или же более не применялся к трафику, его поток восстанавливался. От этой проблемы помог избавиться выход ESXi 7.0.2.

No related posts.