Категорії
VMware: Troubleshooting

Возможные проблемы при установке, обновлении и использовании VMware NSX-T Data Center 3.1

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

Общие проблемы в VMware NSX-T Data Center 3.1

  • Issue: Ошибка вида:

Storage not accessible for service deployment

после добавления сторонних ВМ в недавно добавленные хранилища данных. Даже в случае настроенного доступа к хранилищу со всех нод кластера. Статус ошибки действует до получаса.

Resolve: Повторить попытку через 30 минут. Альтернативное решение: выполнить вызов API для апдейта записи кэша хранилища данных:

https://<nsx-manager>/api/v1/fabric/compute-collections/<CC Ext ID>/storage-resources?uniform_cluster_access=true&source=realtime

где <nsx-manager> – IP-адрес NSX Manager, где служба разворота сфейлилась, а <CC Ext ID> – идентификатор в NSX для кластера.

  • Issue: Нет связи между сетями VLAN, подключенными к одному и тому же сегменту одинаковой edge-нодой.

Resolve: Использовать два разных edge-узла в подключении двух сетей VLAN к одному и тому же сегменту.

  • Issue: Не получается установить NSX Tools на ВМ с RedHat и CentOS (версии 7.4 и новее) при включенном ускоренном сетевом управлении в Microsoft Azure. Интерфейс Ethernet не получает IP-адрес.

Resolve: До установки NSX Tools, после загрузки машины с указанными ОС в Microsoft Azure проинсталлировать самые свежие драйвера Linux Integration Services.

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

Resolve: Проделать следующее:

    1. Добавить объект в список исключений в упрощенном интерфейсе;
    2. Убедиться, что он отражается в списке исключений распределенного файервола в расширенном интерфейсе;
    3. Удалить объект из списка исключений распределенного интерфейса в расширенном интерфейсе;
    4. Вернуться к упрощенному интерфейсу и второму объекту из списка исключений и применить его;
    5. Убедиться, что новый объект появился в расширенном интерфейсе.
  • Issue: Попытка отключить VMware Identity Manager с подключенным внешним LB не срабатывает. Если запустить интеграцию Identity Manager на NSX с внешним LB, а затем отключить интеграцию, отключив и внешний LB, через минуту первоначальная конфигурация появится снова и перезапишет локальные изменения.

Resolve: Когда отключаете интеграцию, не снимайте флажок с внешней LB. В этом случае конфигурация будет сохранена и синхронизирована с другими нодами.

  • Issue: Очистка VIP не очищает интеграцию vIDM на всех нодах. При настройке vIDM в кластере с VIP, отключение виртуального адреса не приводит к удалению интеграции во всем кластере.

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

  • Issue: Операции кластера в плоскости управления фейлятся в некоторых сценариях. Например, при попытке присоединить Manager N2 к Manager N1 путем введения команды «join» на Manager N2. Невозможно сформировать кластер плоскости управления, который сможет повлиять на доступность.

Resolve: Выполнить следующие шаги:

    1. Для возвращения Manager N1 в кластер применить CLI-команду «deactivate» на Manager N1. Это удалит все другие Manager из кластера, заставив Manager N1 стать единственным его членом;
    2. Убедиться, что не конфигурируемый сервер Corfu поднят и работает на Manager N1 командой:

systemctl start corfu-nonconfig-server

    1. Присоединить другие новые Manager в кластер «join»-командами на каждом.
  • Issue: Сбой восстановления в мульти-нодовом кластере. Требует повторный разворот.

Resolve: Развернуть новый одно-нодовый кластер и снова запустить восстановление.

  • Issue: NSX-policy-manager перестает отвечать и перезагружается. Вызовы API к нему сбоят и служба недоступна.

Resolve: Вызывать API не более чем с 2000 объектов.

  • Issue: При создании в Global Manager сегмента с BridgeProfile-конфигурацией, конфигурация моста Layer2 не применяется к отдельным NSX-сайтам. Консолидированный статус сегмента – «ERROR». Такое случается при сбое в процессе создания конечной точки моста на данном NSX-сайте.

Resolve: Создать сегмент на сайте NSX и настроить его с помощью профиля моста.

  • Issue: При ненастроенном сервере DHCP, получение статистики/статуса на шлюзе Tier0/Tier1 или сегменте показывает ошибку.

Resolve: нет. Настроить DHCP.

  • Issue: Пользователь LDAP не может войти в NSX, если запись юзера в Active Directory не содержит атрибут UPN (userPrincipalName), а лишь атрибут samAccountName.

Resolve: нет.

  • Issue: Конфигурация IDFW/IDS не апдейтится, когда кластер IDFW/IDS удаляется из vCenter. В результате количество кластеров с поддержкой IDFW/IDS подсчитывается неточно.

Resolve: нет.

  • Issue: Сертификаты с LDAP на CDP (CRL Distribution Point) не могут применяться как tomcat/cluster-сертификаты.

Resolve: Решение можно посмотреть здесь.

  • Issue: Миграция хоста в окне техобслуживания из NSX для vSphere в NSX-T Data Center для vCenter 6.5/6.7 фейлится из-за ошибки vMotion. Сообщение вида:

Pre-migrate stage failed during host migration [Reason: [Vmotion] Can not proceed with migration: Max attempt done to vmotion vm b’3-vm_Client_VM_Ubuntu_1404-shared-1410′]

Resolve: Попробовать смигрировать хост еще раз.

  • Issue: Обновления TNP после бэкапа не восстанавливаются.

Resolve: Сделать бэкап после любых обновлений TNP.

  • Issue: Поиск в политике выдает ошибку:

Unable to resolve with start search resync policy

Обычно в проблеме рассинхронизации поиска при предоставлении нодам NSX Manager новых IP.

Resolve: Убедиться, что записи DNS PTR (сопоставления IP и имен хостов на DNS-сервере) корректны для всех NSX Manager.

  • Issue: Переключение между миграциями NVDS в CVDS не поддерживается Stateless ESX с vmk. Мигратор коммутатора NVDS в CVDS нельзя использовать при миграции Stateless ESX-хостов, если на свитче NVDS есть ВМ.

Resolve: Перенести машины из NVDS, либо удалить этот хост из NSX и после этого выполнить миграцию.

  • Issue: Этап Edge миграции фейлится с ошибкой:

Failed to fetch error list

Причина сбоя остается тайной.

Resolve: Откатить миграцию и повторить попытку.

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

Resolve: Увеличить время, ассоциированное с этой опцией. Копий станет значительно меньше.

  • Issue: Аутентификация LDAP не работает так, как надо, при настройке с внешним load balancer (конфигурация сохранения циклического соединения).

Resolve: нет.

  • Issue: Если выбирается Type как «TIER0_EVPN_TEP_IP» в перераспределении маршрутизации Tier-0 VRF LR, это значение типа не перераспределяется в BGP, так как оно в наличии в родительском Tier-0 LR. В результате путь данных нарушается.

Resolve: Выбрать «TIER0_EVPN_TEP_IP» в перераспределении маршрутизации родительского Tier-0 LR, вместо VRF Tier-0 LR, затем удалить опцию, чтобы выбрать ее из VRF Tier-0 LR.

  • Issue: Если не указать свойство «inter_sr_ibgp» в вызове PATCH API, другие поля в сущности BgpRoutingConfig не будут апдейтиться. Ошибка вида:

BGP inter SR routing requires global BGP and ECMP flags enabled

Resolve: Указать свойство «inter_sr_ibgp» в вызове PATCH API.

  • Issue: Узел UA перестал принимать любые новые вызовы API с ошибкой:

Some appliance components are not functioning properly

Около 200 подключений могут застрять в статусе «CLOSE_WAIT» – они не закрыты, поэтому любой вызов API будет отклоняться.

Resolve: Перезапустить службу proton или перезапустить унифицированную ноду appliance.

  • Issue: При переконфигурировании правила «ANY» на «ANY SNAT», указанные для адресов исходной сети/сети назначения/транслируемой сети свойства показываются как пустая строка, что приводит к сбою реализации на уровне управления и периферии.

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

  • Issue: Политикой разрешено не более 500 сеансов VPN. NSX поддерживает 512 сессий VPN на каждый edge в  крупных форм-факторах, так как Policy задает автоподключение политик безопасности – в количестве до 500 VPN-сеансов. Если попробовать настроить 501-ю сессию на Tier0 выдаст с ледующую ошибку:

{‘httpStatus’: ‘BAD_REQUEST’, ‘error_code’: 500230, ‘module_name’: ‘Policy’, ‘error_message’: ‘GatewayPolicy path=[/infra/domains/default/gateway-policies/VPN_SYSTEM_GATEWAY_POLICY] has more than 1,000 allowed rules per Gateway path=[/infra/tier-0s/inc_1_tier_0_1].’}

Resolve: Использовать уровень управления API для создания дополнительных VPN-сеансов.

  • Issue: Для свитча не обновляется «nsxaHealthStatus», когда имя коммутатора содержит одинарные кавычки. Как итог – статус конфигурации NSX показывается как частично успешный.

Resolve: Изменить имя свитча, удалив одинарные кавычки.

  • Issue: В логах политики наблюдается «NsxTRestException», когда из API создается SegmentPort.

Resolve: Заполнить поле ID в «PortAttachmentDto» или выставить там ноль в API-вводе.

  • Issue: Подключение vIDM к NSX завершается ошибкой, если не поставить флажки на «lb_enable» и «vidm_enable». Сообщение:

An error occurred attempting to update the vidm properties

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

Resolve: Включение этих флажков не является опциональным – они обязательны.

  • Issue: DFW-правило остается примененным, даже после силового удаления менеджера nsgroup. Трафик остается заблокированным.

Resolve: Не удалять группу nsgroup принудительно, если она все еще используется в правиле DFW. Просто пока надо ее оставить пустой, либо же следует избавиться от правила DFW.

  • Issue: При резервном копировании/восстановлении Appliance с использованием интеграции vIDM, конфигурирование vIDM ломается. Обычно, в процессе обновления/восстановления среды, когда пытаешься восстановить Appliance, где поднята интеграция vIDM, конфигурация последней портится и нуждается в перенастройке.

Resolve: После восстановления вручную перенастроить vIDM.

  • Issue: Миграция с NVDS на CVDS не поддерживается, если VMK с закрепленным pnic подключен к логическому свитчу, поддерживаемому NVDS.

Resolve: нет.

  • Issue: Инвентарь не видит SRIOV vNIC на ВМ. В диалоговом окне «Add new SPAN» они не отобажаются.

Resolve: нет.

  • Issue: В пользовательском интерфейсе статус реализации профиля BFD отображается как «uninitialized».

Resolve: нет. Можно игнорировать, ни на что не влияет.

  • Issue: Статус реализации успешного созданного Global T0 на содержащемся на борту сайте некорректно показывает ошибку для транспортных узлов edge сайта:

logical router port configuration realization error

Явление временное и пропадающее после завершения подключения T0-T1, если использовать политику API.

Resolve: На уровне управления или уровне управления API удалить порт логического маршрутизатора, созданный на T0 для соединения с T1, или же завершить подключение по T1.

  • Issue: В общем консолидированном статусе значится «IN_PROGRESS», в то время как индивидуальный консолидированный статус каждой точки применения демонстрирует «SUCCESS».

Resolve: нет. По завершению синхронизации статус будет соответствовать.

  • Issue: В NSX с большим количеством Stateless-хостов (TransportNodes) рабочие процессы ВМ могут временно терять связь при апгрейде нод уровня управления до версии 3.0.0 и выше.

Resolve: нет.

  • Issue: Порт сегмента может создаваться до успешного формирования транспортной ноды физического сервера Windows, что приводит к отображению его статуса как отказавшего. К сожалению, UI не отображает состояние прогресса создания транспортного узла, поэтому непонятно, когда приступать к назначению порта сегмента для физических серверов Windows. А если это сделать до того, произойдет логический фейл.

Resolve: Устанавливая физический сервер Windows выбрать вариант «continue later» на третьем шаге мастера-помощника. Когда уже будет понятно, что транспортный узел создался успешно, перейти к назначению порта сегмента из действий управления сегментом.

  • Issue: Миграция NVDS в CVDS через vSphere Update Manager не полностью поддерживается параллельным режимом оной. Могут быть выявлены проблемы в процессе миграции, вызванной апгрейдом ESX. Свитч автоматически не смигрируется с NVDS в CVDS и система останется в несовместимом состоянии.

Resolve: Задать максимальное количество обновляемых хостов, равное 4, в параллельном режиме Update Manager. Если же Update Manager уже запустился без указанного лимита доступны два варианта решения проблемы:

    1. Запустить миграцию вручную для каждого хоста;
    2. Удалить существующие транспортные узлы со свитчами NVDS и воссоздать их с использованием коммутаторов CVDS, переместив вначале рабочие нагрузки с первого, а затем вернув их обратно на TN уже с CVDS.
  • Issue: В процессе создания политик безопасности, в которых содержится до тысячи правил в каждой, происходит сбой API.

Resolve: нет.

  • Issue: IPv6 дублирует статус обнаружения IP (DAD) машины, представляя трехсекундную задержку на порте заднего уровня T0/T1 SR (и для T1 SR восходящего порта), когда IP переносится с одного SR на другой при отказе. Подключение N-S отличается потерей трафика v6 до 6 сек. при сбое T0 A/A.

Resolve: Избегать ассиметричных потоков трафика и полагаться на таймеры BGP 1/3 для обнаружения отказов HA на восходящем T0.

  • Issue: При использовании API на уровне управления для настройки режима пересылки L3 политика перезапишет изменение уровня управления с режимом по умолчанию IPV4_ONLY и прервет связь по IPv6. Конфигурация режима пересылки L3 была представлена в «Policy» релиза NSX-T 3.0.0. Проблема влияет на обновление NSX-T 3.0.1/3.0.2 до 3.1.0. Апгрейдов NSX-T 2.5.x до 3.1.0 и NSX-T 3.0.0 до 3.1.0 не касается.

Resolve: Решение представлено в соответствующем КБ.

  • Issue: Восстановление хоста в vLCM-кластере с Service VM Deployment, базирующемся на хосте, фейлится после 95% прогресса. Зависает на 95%, затем 70-минутный тайм-аут и, наконец, сбой.

Resolve: Соответствующий КБ.

  • Issue: Выдается аварийный сигнал о достижении максимальной емкости при превышении количества портов логического свитча всей системы 25К.

Resolve: нет. На самом деле, в Env-масштабе PKS ограничение для порта контейнера составляет 60К. Поэтому сообщение о достижении 25К – норма.

  • Issue: При удалении физического сервера из NSX соединение с ним теряется, а само удаление завершается неуспешно. Подключенный интерфейс порта сегмента на физическом сервере сконфигурирован как «Using existing IP», поэтому при удалении физического сервера из NSX без первоначального удаления порта сегмента происходит потеря связи с физическим сервером и деинсталляция NSX фейлится.

Resolve: Удалять порт сегмента первым – до деинсталляции физического сервера.

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

Resolve: нет.

  • Issue: Статистика Load balancer API не возвращает параметры. Параметры API не установлены.

Resolve: Уменьшить количество настроенных балансировщиков нагрузки.

  • Issue: При добавлении Windows Bare Metal Server 2016/2019 на этапе «Applying NSX Switch Configuration» показывается ошибка «host disconnected». Однако, установка, похоже, прогрессирует и в итоге все получается правильно.

Resolve: Дождаться завершения инсталляции.

  • Issue: Внутренняя ошибка (500) сервера при выполнении API.

Resolve: Ошибка из-за недействительности сеанса. Повторно запустить API-сессию создания, чтобы инициировать новую сессию.

  • Issue: При переходе активной edge-ноды в состояние неактивной при течении потока трафика S-N, трафик теряется. Поток S-N работает на многоадресной активной ноде. Предпочтительная маршрутизация в данном случае на TOR к ресурсу должна происходить только через активную ноду edge. Поднятие другой edge может занять многоадресность активной ноды (это касается edge нижнего ранга), и в результате S-N трафик испытает потери до 4 минут по времени. Такого не происходит с новыми потоками, или если текущий поток остановился и перезапустился снова.

Resolve: Трафик S-N восстановится автоматически через 3,5-4 минуты. Чтобы он восстановился быстрее, нужно отключить многоадресную рассылку и включить ее через конфигурацию.

  • Issue: Фильтрация по «Namespaces», «Compute Collection», «L2VPN Service» может не выдавать данных для нескольких комбинаций фильтров типов ресурсов. Это случается даже если ресурсы полностью совместимы по критериям соответствия. Известно для комбинаций:
    • Для Namespaces – фильтрация по Cluster Name/Pods Name,
    • Для страницы Network Topology – по службе L2VPN, примененной к удаленному ip-фильтру,
    • Для Compute Collection – фильтр ComputeManager.

Resolve: Применять только один фильтр за раз для этих типов ресурсов.

  • Issue: В ряде случаев посланный NSX-T edge пакет PMTU игнорируется в месте назначения. PMTU не обнаруживает, что ведет к фрагментации и повторной сборке, а затем и к отбрасыванию пакетов. Производительность падает, либо трафик отключается вовсе.

Resolve: нет.

  • Issue: Сеансы анализа трафика (LTA) не освобождаются при параллельном запуске запроса LTA. На уровне управления (МР) хост будет постоянно сообщать о результате LTA, поэтому МР всегда будет казаться, что LTA демонстрирует утечку и будет отражать это в логах nsxapi.log. Пакеты от хоста с неочищенным сеансом LTA будут заполнены заголовком «LTA INT Geneve».

Resolve: Перезагрузить ESXi-хост, где существуют LTA-сессии.

  • Issue: IDS с включенными настройками прокси не получает доступ к GitHub, используемому в загрузке подписей. Новый апдейт сигнатур не загружается.

Resolve: Использовать функцию автономной загрузки для загрузки и выгрузки подписей при отсутствии сетевого подключения.

  • Issue: Если физический сервер Windows 2016/2019 не закончен, порты сегмента отказывают при попытке создать порт сегмента.

Resolve: Подождать изменения статуса конфигурации транспортного узла на «Success», и только потом создавать порт сегмента.

  • Issue: Политика выдает ошибку при настройке в привязке профиля моста нескольких диапазонов VLAN. Сообщение вида:

INVALID VLAN IDs

Resolve: Создать несколько конечных точек моста с диапазонами VLAN в сегменте вместо одной со всеми ними вкупе.

  • Issue: Клиент REST API вызывает «/fabric/nodes» каждые две минуты, однако прерывает соединение до того момента, когда возвращается ответ API. Ошибки фиксируются в системном журнале вида:

java.io.IOException: Broken pipe

Resolve: нет. Функционально не воздействует.

  • Issue: В Bare Metal Edge трафик, проходя сквозь шлюз VRF, может не достичь точки назначения. Захват пакетов на партнере по каналу означает, что они получены без контрольной суммы, однако со смещением фрагментации в IP-заголовке. И такой пересекающий шлюз трафик отбрасывается по причине повреждения пакетов.

Resolve: Чтобы нормально пользоваться функционалом VRF Lite, следует использовать edge ВМ.

Ошибки в процессе инсталляции

  • Issue: Обновление службы vm не работает после корректировки url, если разворот апгрейда сфейлился с «Invaildurl».

Resolve: нет.

  • Issue: Некоторые транспортные ноды застревают в состоянии ожидания после операции восстановления. Конфигурации из восстановленной базы данных не отправляются на транспортный узел.

Resolve: Использовать следующий POST в API для повторного применения существующей конфигурации ТУ:

POST /api/v1/transport-nodes/<transportnode-id>?action=resync_host_config

Ресинхронизировать конфигурацию ТУ на хосте. Процесс аналогичен апдейту TransportNode с существующей конфигурацией, но с принудительной синхронизацией (без оптимизации бэк-енда).

  • Issue: Одноузловый NSX Manager отключается от остальной федерации NSX, если на нем заменить сертификат APH-AR.

Resolve: Разворот одно-нодового кластера не поддерживается. Использовать кластер NSX Manager с тремя узлами.

  • Issue: Удаление транспортного узла длится бесконечно, после отключения NSX Manager в процессе этой операции.

Resolve: После резервного копирования Manager, подготовить узел снова и опять запустить процесс удаления.

Проблемы с апгрейдом NSX-T до версии 3.1

  • Issue: При обновлении конфигурация vIDM не сохраняется.

Resolve: Отключить конфигурацию vIDM, обновиться, повторно войти в систему и опять включить vIDM в кластере.

  • Issue: Во время обновления появляется сообщение:

The credentials were incorrect or the account specified has been locked

Resolve: нет. Ошибка временна, система все равно автоматически восстановится.

  • Issue: При обновлении до 3.1.0 в секции апгрейда хоста кнопка «Stage» присутствует и активна для всех кластеров/групп хостов. Но, этот параметр применим исключительно к кластерам со включенным vLCM, что исключается этим сценарием, так как поддержка NSX-T vLCM включена из комбинации версий NSX-T 3.1.0 и vSphere 7.0 U1. Если выбрать опцию «Stage», появится подтверждающее сообщение, в котором если нажать «Yes», кластер покажет, что он подготовлен для обновления. Однако, если затем кликнуть на «Start», он подвергнется таким же апгрейдам, как если бы они были инициированы через обычные обновления хоста NSX.

Resolve: Игнорировать опцию «Stage» и выполнить апгрейд хоста по обычной процедуре.

  • Issue: После обновления статус репозитория отмечен как «FAILED» в пользовательском интерфейсе NSX Manager. При этом все операции установки и обновления доступны.

Resolve: Выполнить действия разрешения из UI NSX Manager.

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

Resolve: Предварительно убедиться, что в bare metal-сервере только один диск.

NSX Edge

  • Issue: API уровня управления «https://<nsx-manager>/api/v1/routing-table» и «https://<nsx-manager>/api/v1/forwarding-table» выдают ошибку, если у edge 65К+ маршрутов для RIB и 100К+ маршрутов для FIB. В этом случае обращение из уровня управления к Edge занимает более 10 сек. и по итогу получаем тайм-аут.

Resolve: Существует два пути получения RIB/FIB. Эти API поддерживают параметры фильтрации на основе сетевых префиксов или типа маршрута. Если применять эти параметры для загрузки интересующих маршрутов, все получится. CLI использовать только тогда, когда нужна вся таблица RIB/FIB и для ее выдачи не установлен тайм-аут.

  • Issue: Статус BFD, отображаемый в «get bgp neighbor summary», может неправильно отражать последнее состояние сеанса BFD. BGP и BFD могут настраивать свои сеансы независимо. При этом BGP, в том числе, показывает статус BFD, как часть «get bgp neighbor summary». Следовательно, если BGP не работает, уведомления BFD он обрабатывать не станет, а продолжит демонстрировать последнее известное состояние.

Resolve: Полагаться исключительно на сведения «get bfd-sessions» и проверять поле «State» для получения наиболее свежего статуса BFD.

  • Issue: При Edge vMotion может происходить потеря многоадресного трафика в интервале до 30 сек. (интервал pim hello по умолчанию). При vMotion Edge и включенном в TOR отслеживании IGMP, TOR нуждается в информации о новом местоположении Edge. TOR его узнает, когда получает любой контроль над многоадресной рассылкой или над трафиком данных из Edge.

Resolve: нет. Трафик восстановится после получения TOR многоадресных пакетов, а для более быстрого восстановления следует отключить, а затем включить pim на интерфейсе подключенного к TOR восходящего трафика.

NSX Cloud

  • Issue: Вызовы PCM к AWS фейлятся. При изменении роли PCG для AWS-аккаунта на CSM со старой pcg-роли на новую, CSM обновляет роль для инстанса PCG на AWS до новой. Но, PCM не в курсе, что произошел такой апдейт, и продолжает пользоваться клиентами AWS со старыми ролями. В итоге получаем сбой сканирования облачного инвентаря и прочих вызовов облака AWS.

Resolve: Не менять/удалять старую роль сразу после перехода на новую минимум 6,5 часов. Затем перезапустить PCG, после чего все клиенты AWS получат новые учетные данные.

Проблемы безопасности

  • Issue: SSL-сертификаты канала AR не проверяются периодически на свою валидность, что ведет к применению просроченного или даже отозванного сертификата имеющегося соединения.

Resolve: Перезапустить APH на управляющей ноде, чтобы вызвать переподключение.

Проблемы с федерацией

  • Issue: Рабочий процесс апгрейда Local Manager прерывается, если он был добавлен в Global Manager с использованием своего VIP, но позднее был опубликован FQDN Local Manager.

Resolve: Обновить полное доменное имя Local Manager после его публикации.

  • Issue: SRM-восстановление для вычислительных ВМ приводит к потере всех примененных к машинам и портам сегментов тегов NSX.

Resolve: нет. Переназначить вручную.

  • Issue: Параллельное подключение конфигурации не поддерживается в Global Manager в плане предотвращения больших нагрузок обработки. Несколько запусков конфигурации в GM существенно замедляют его работу.

Resolve: Администратор безопасности и пользователи должны синхронизировать окна техобслуживания, чтобы избегать одновременного запуска конфигурирования.

  • Issue: По завершению подключения и восстановления Local Manager, статус Global Manager неизменен:

IN_PROGRESS

Конфигурацию восстановленного сайта невозможно импортировать.

Resolve: Использовать API Local Manager для адаптации сайта Local Manager при необходимости.

  • Issue: Сеансы Inter-SR iBGP продолжают колебания, когда промежуточные маршрутизаторы или физические сетевые адаптеры обладают меньшим, либо же равным MTU в качестве порта inter-SR. Оказывает на связь между сайтами в топологиях федерации.

Resolve: Придерживаться pNic MTU и MTU промежуточных маршрутизаторов больших, чем глобальный MTU. Иначе из-за инкапсуляции размер пакетов превысит MTU, и они не пройдут.

  • Issue: Правила файервола не применяются в варианте использования кросс-сайтового vMotion при использовании портов сегментов в глобальных группах. Передача правил не осуществляется должным образом.

Resolve: Перенастроить правила.

  • Issue: Подключение блокируется при попытке подключиться через API с ошибкой:

Default transport zone not found at site

Resolve: Дождаться завершения синхронизации Global Manager и Local Manager.

  • Issue: При добавлении глобальной службы в качестве вложенной на Local Manager ошибка не отображается. Создание политики успешно, но реализация фейлится. Локальная служба не может работать на уровне управления, поэтому она не в состоянии участвовать в правилах распределенного файервола.

Resolve: Перенастроить службу с целью удаления глобальной службы и добавить в качестве членов локальные службы.

  • Issue:  Нельзя вложить группу из настраиваемой области, созданную на указанном сайте в группе, которая принадлежит системе, созданной в этой области. Дочерняя группа с тем же расположением не может быть выбрана.

Resolve: нет.

  • Issue: Удаление тормозит, когда с помощью индивидуальных API работают с большим количеством объектов.

Resolve: Использовать иерархический API для массового удаления.

  • Issue: Правило брандмауэра создается очень долго, когда отдельные правила создаются последовательно. Медленный API требует больше времени для создания правил.

Resolve: Использовать иерархический API с целью создания множества правил.

  • Issue: В федерации, если дочерняя группа используется в двух различных группах, а вторая родительская группа отличается более высоким спаном, дочерняя группа может получиться большей, чем спан второй родительской группы. Спан меньшей расширить можно, но в исходное состояние он уже не возвратится. Спан домена в Global Manager не сокращается.

Resolve: Не добавлять одну и ту же дочернюю группу в две родительские с различными размерами.

  • Issue: Имена хостов не апдейтятся на странице Location Manager в UI при обновлении имен хостов через CLI. Показываются старые имена.

Resolve: нет.

  • Issue: Состояние менеджера вычислений, добавленного в активный Global Manager не реплицируется на резервный Global Manager. Функция автоматического развертывания новых узлов Global Manager недоступна в случае активации резервного Global Manager.

Resolve: Добавить vCenter в качестве менеджера вычислений в активный на данный момент Global Manager.

  • Issue: API-переключения Global Manager рапортуют об ошибке при сбоях в транзакциях, но переключение завершается.

Resolve: нет.

  • Issue: Изменение сертификатов LM может не произойти после регистрации в GM. Когда нужно использовать федерацию и PKS на одном и том же LM, задачи PKS по созданию внешних VIP и изменению сертификатов LM должны осуществиться до регистрации LM на GM. Если нарушить порядок регистрации, связь между LM и GM после изменения сертификатов будет утеряна и потребуется повторная регистрация.

Resolve: Регистрировать в правильном порядке.

  • Issue: Не получается сделать из Global Manager резервный из UI после незапланированного переключения, кода этот GM теряется, но потом, после переключения, возвращается в оперативный режим.

Resolve: Использовать API с полезной нагрузкой, включающей «connection_info» для изменения статуса GM с «NONE» на «Standby»:

PUT https://<active-GM-IP>/global-manager/api/v1/global-infra/global-managers/<ID of GM with the status NONE>

Example Request Body:

{

  “display_name”: “<Display Name of GM with status NONE>”,

  “mode”: “STANDBY”,

  “_revision” : <Revision-Number>, 

 

“connection_info”: [

                {“fqdn”: “<FQDN or IP of the GM with status NONE>”,

                 “username”: “<username>”,

                 “password”: “<password>”,

                 “thumbprint”: “<API thumbprint of the GM with status NONE>”}

  ]

}

  • Issue: Канал асинхронного репликатора иногда при перезапуске ноды остается не работающим. Статус синхронизации не работает и изменения в GM не передаются в LM.

Resolve: Перезапустить процесс асинхронного репликатора, введя команду:

service async-replicator-service restart

  • Issue: При настройке NSX Intelligence в Local Manager адаптация фейлится. Причина – в ошибке принципиальной идентификации.

Resolve: Создать временного пользователя с принципиальной идентификаций, чье имя будет аналогичным тем, что использует NSX Intelligence.

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

Resolve: Отключить Tier 1 от Tier 0 для удаления унаследованного спана. Если они не могут быть отключены, подождать несколько минут и повторить операцию.

  • Issue: Сбои по причине дублирования конфигурации корректно не передаются пользователю. Когда адаптация в прогрессе, можно увидеть ошибку:

Onboarding Failure

Resolve: Восстановить Local Manager и повторить попытку.

  • Issue: Обмен данными между Global Manager и Local Manager ломается (рабочие процессы зависят от пароля/отпечатка) после замены сертификата Local Manager. Статус и некоторые функции не обновляются.

Resolve: Заменить отпечаток Local Manager, используя вызов API на Global Manager.

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