понедельник, 25 сентября 2017 г.

сообщение "UnInitialized" для virtualGateways при выводе Debug-NetworkControllerConfigurationState

Привет всем.

При тестировании SDN столкнулись с тем, что вывод команды Debug-NetworkControllerConfigurationState для раздела virtualGateways был заполнен сообщениями о шлюзах, которые были в статусе "UnInitialized". Однако, проблем с работой сервисов NC не наблюдалось.


Коротко расскажу как понять к чему это относится и является ли это проблемой.
Мы выполняем команду



"Debug-NetworkController -RestURI $URI -Credential $cred -OutputDirectory c:\Temp  -IncludeTraces:$false"

Переменные $URI, $Cred, конечно, должны содержать значения для Вашей инфраструктуры.  

В папке, которую мы указали в переменной "OutputDirectory" мы ищём файл virtualGateways.json


И в нём производим поиск ID виртуального шлюза, обратите внимание, что в секции "ConfigurationState" указано значение "UnInitialized".



Этот раздел содержит ссылку на виртуальную сеть, которая выделена красной чертой. Далее ищем файл virtualNetworks.json и находим там виртуальную сеть.


Теперь мы знаем какую сеть искать и с чем работать.

В процессе экспериментов с виртуальной сетью выяснилось, что ситуация возникает при создании NAT через функционал Azure Pack. Как мы видим на картинке ниже, при включении NAT автоматически устанавливается галочка в поле "Enable Gateway".




При этом VPN ещё не создан, что и приводит к такой ситуации.

После создания VPN сообщение уйдёт.

Нюанс заключается в том, что если удалить VPN, виртуальный шлюз остаётся в состоянии "Success" и считает себя инициализированным до того момента, пока Вы не отключите NAT. При повторном включении NAT ситуация повторится.





Замечу, что при включении NAT через VMM такой проблемы не происходит, т.к. при включении через VMM инициализируются только NAT, а не NAT и шлюз, как при включении через WAP. 



Предполагаем, что это поведение by-design, но и задам вопрос разработчикам, чтобы быть уверенным.

вторник, 19 сентября 2017 г.

Troubleshooting NAT Issues SDNv2

Привет, всем.

Рассмотрим сценарий сбоя, который привел к необходимости разобрать RaS GW Role Network Controller и обнулить её конфигурации.

При этом, если кто-либо попробует создать NAT соединение из WAP - задача не будет выполнена. В SCVMM будет присутствовать следующая ошибка

Не торопитесь разбирать SLB или удалять логическую GRE сеть. Возвращаем на место роль RSGW и NAT начинает работать как должно.

Дополнительные проблемы возникают у сетей, где был настроен GRE, IPsec, NAT функционал. Для этого этот функционал необходимо выключить и включить заново.

среда, 13 сентября 2017 г.

После успешнго добавления в Network Service роли Load Balancing агент SLBHostAgent остаётся в статусе "Disabled"

Столкнулись с багом при конфигурировании Load Balancer Role.
Функционал не заработал.

Агенты SLBHostAgent на Hyper-V серверах остались в состоянии "Disabled".

В журнале "Microsoft-Windows-SoftwareLoadBalancer-HostPlugin/Debug" на узлах виртуализации присутствовала ошибка:

"
“2017-09-13 09:21:20: 3648: HostPluginEvent                          :2: ConfigReader::GetSlbmEndpoints(141), SLBM Endpoints not present in config file (C:\Windows\System32\SlbHpConfig.xml)”

"

Данная проблемы вызывается тем, что конфигурационный файл не был доставлен при конфигурации роли.

Для того, чтобы исправить ситуацию, необходимо:
  • взять исходник файла в папке "с:\Program Files\Microsoft System Center 2016\Virtual Machine Manager\bin\Configuration Providers\NetworkControllerPlugin";
  • модифицировать его для каждого сервера Hyper-V, как показано на скриншоте;

  • поместить файл на каждый Hyper-V узел;
  • запустить агенты SLBHostAgent;
  • скопировать исходный шаблон файла в папку "с:\Program Files\Microsoft System Center 2016\Virtual Machine Manager\bin\";






Узлы кластера не получают PAhostVnic адреса из HNV IP-Pool или отсутствует Compartment 3

Столкнулись с проблемой, когда узлы виртуализации Hyper-V не получают адреса для PA адаптеров. Чтобы быть ещё более точным, ситуация выглядит следующим образом: в "Compartment 3" отсутствуют сетевые адаптеры с VLAN, предназначенным для HNV Provider Network (PA network).



На хостах присутствуют PAHostNics - это видно в реестре.


Однако бывают и другие симптомы, к примеру: когда вы переустанавливаете Network Controller "с нуля", но на хосте не появляется "Compartment 3". В trace logs можно обнаружить следующие сообщения.

При выполнении CMDlet Debug-NetworkControllerConfigurationState вы получаете сообщения о том, что NC не смог сконфигурировать политику на хосте.
Других сообщений вы не сможете обнаружить, сообщения trace журналов будут аналогичные.

Проблема вызывается наличием в "Trusted Root Certification Authorities" на узле виртуализации сертификата Network Controller, в случае, если NC Network Service был развёрнут в режиме "с доменным сертификатом для NC". 

После его удаления и перезапуска NCHostAgent все заработает.


Слоны и карри - наше всё!