вторник, 31 октября 2017 г.

Странное поведение VMM JOB при добавлении Network Controller на хост группы

Замечено, что, если у нас есть набор хост-групп в VMM, в которые вложены хосты виртуализации, и на которые мы распространяем Network Service, то если у нас 12 узлов виртуализации Hyper-V,  они в процессе выполнения VMM JOB для NC будут добавлены 2-ды 








Но, при этом в инвентаризации NC, если посмотреть вывод Get-NetworkControllerServer, их будет 12  какой-то баг, при отработке вложенности. В остальном, по нашему мнению, работает штатно.

понедельник, 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 все заработает.


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









понедельник, 28 августа 2017 г.

После повторного добавления хоста в VMM, узел не подключается к Network Controller, error 20611

Привет.

Разберём следующий сценарий:
Нам необходимо по каким-либо причинам вывести хост виртуализации из под управления VMM, а затем добавить его обратно. Ситуация осложняется тем, что узел использует SDNv2 на базе Windows Server 2016 и System Center VMM 2016.

Симптом:
После повторного добавления узла в VMM и кластер не устанавливаются подключения к Network Controller по порту TCP 6640. 

Как исправить:
Рекомендую обратить внимание на закладку "Status" в свойствах узла виртуализации.


Нажмите кнопку "Repair ALL"  и нажмите "ОК".


Если вы не удаляли сертификат, выданный SCVMM, то он останется прежним при добавлении узла. После этого все соединения по портам 6640 восстановятся.



P.S. Сервисы  Network Controller зависят от VMM. Если в VMM сервис находиться в сбойном состоянии - он работать не будет.

Настройка и нюансы балансировки с помощью SLB

При использовании SDNv2 существует возможность создать балансировщик сетевой нагрузки и предоставить его в использование гостевым виртуальным машинам, допустим: тенанта в Azure Pack.

К сожалению, это невозможно сделать в графике, by-design (пока что).

Для начала, мы создаём такой балансировщик, с помощью Powershell.
Исходя из снимка экрана, Вы видите VIP адрес, ссылающийся на 2 DIP адреса ВМ внутри тенанта. Я выбрал свободный адрес из Public VIP пула, как это указано в статье.
Далее,  я беру обе ВМ, настраиваю IIS, перезапускаю его, предварительно модифицировав LANDING PAGE на обоих серверах.


И вуаля, всё работает.



Однако, не бывает простых решений. Давайте внимательно посмотрим на IP-pool Public VIP в VMM.


Public VIP pool ничего не знает по этот IP адрес. Предполагаю, что VMM может выдать его любому тенанту случайным образом. И я подозреваю, что в данном сценарии могут быть риски дублирующихся IP адресов, т.к. пул Public VIP, ничего не знает про адрес.

Пока это требует исследования.

Я планирую вернуться к этому вопросу в ближайшее время.
Однако, как решить проблему с SLB и фиксацией IP адреса в Public VIP пуле?


Приведённое ниже решение не является официальным и Вы делаете его на свой страх и риск.

Могу предложить выход из ситуации:

На днях я протестировал создание внешнего балансировщика на IP адресе прибитом к отдельному NAT, в отдельной виртуальной сети Azure Pack + SCVMM - это работает. Однако, при таком сценарии на NAT перестают работать правила и отвечает только порт, указанный в балансировщике. Имейте это в виду при работе с Azure Pack.

P.S. внутренняя балансировка изолирована от внешней. На сколько я понял, на текущий момент, невозможно балансировать внешний трафик внутренним балансировщиком - это разомкнутые контуры. По крайней мере, у меня не получилось привести внешний трафик из Public VIP диапазона на Private VIP балансировщика - на мой взгляд это схема не рабочая by-design.