вторник, 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 - Updated

При использовании 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 пуле?



UPDATE 12/1/2017:
После нескольких исследований и вопросов к производителю был получен следующей ответ:

Т.е. даже не смотря на то, что в VMM явной резервации нет - механизм взаимодействия VMM и NC исключает вероятность возникновения подобной ситуации.

пятница, 28 июля 2017 г.

Fetching ResourceType: Gateways, Status: Uninitialized

При Выводе Debug-NetworkControllerConfigurationState вы видите сообщение следующего формата:



Судя по всему, такое поведение является штатным при использовании настройки



Если изменяешь настройку на "0", то запись при выводе команды Debug-NetworkControllerConfigurationState уходит.

Troubleshooting работы Microsoft SDN 2016

Обращайте внимание на детали в документации.

Ниже сделан скриншот с полностью работоспособного узла, работающего с SDN. В чём подвох, ведь соединения два? А должно быть три!

Третье соединение появляется после того, как на узле оказывается ВМ, использующая функционал Microsoft SDN.


См. документацию по устранению проблем Microsoft SDN 2016 тут.

Troubleshooting работы узлов вирутализации и SLB при использовании Microsoft SDN 2016

Столкнулись с ситуацией когда SLB HostAgent на узле виртуализации не мог подключиться к SLB.




Проблема выяснилась достаточно быстро: в нашей сети отсутствовал маршрут к SLB Manager VIP (это IP из сети, анонсируемой по BGP). После исправления на сетевом уровне (сдеали статику) - всё заработало.

Когда SLB HostAgent корректно получает необходимые параметры в журналах появляются сообщения, приведённые ниже.




После исправления маршрутизации появился доступ в интернет на виртуальных машинах.

среда, 26 июля 2017 г.

Штатное удаление Window Server 2016 SDN в SCVMM 2016

Штатно убрать из VMM Network Service и другие элементы SDN можно при выполнении следующей последовательности, т.к. для сервиса существуют зависимости:

  • Отключение всех тестовых ВМ в клиентской сети с поддержкой HNV;
  • "Отвязывание" интерфейсов ВМ от клиентской сети с поддержкой HNV;
  • Удаление ассоциации NC и SLB;
  • Отвязывание Network Sites в Uplink Profile;
  • Удаление виртуальных сетей и их пулов;
  • Удаление IP-pool логических сетей (предварительно освободить адреса, если остались занятые);
  • Удаление логических сетей и сайтов; Может возникнуть проблема с удалением Private VIP сети, т.к. к ней привязан SLB Manager VIP);
  • Удаление кластера из VMM (может не понадобиться, если всё работает "ок" - предварительно попробуйте удалить Network Service);
  • Удалить Network Service;
  • Удаление сервиса в "VMs and services";
В этом случае "трогать" логический коммутатор не потребуется.

Диагностика Network Controller и его компонентов

NC и другие компоненты SDN работают, обмениваясь информацией между собой на основе различных ID для обеспечения уникальной  индентификации объектов конфигурации.

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

Для уточнения данных воспользуйтесь тем, что введите ссылку ResourcePath в браузер. В ответ вы получите JSON файл, который будет содержать понятную человеку детализацию.




P.S. забыл, если после команды вывода конкретной строки, вставить  "| ConvertTo-Json -Depth 10", к примеру:


Get-NetworkControllerGatewayPool -ConnectionUri $URI -Credential $cred | ConvertTo-Json -Depth 10

,то вы увидите содержимое файла по ссылке в сессии PowreShell


среда, 5 июля 2017 г.

Зависание узлов Hyper-V при добавлении в Network Controller

В момент добавления узлов виртуализации в Network Controller (происходит при создании Network Service в VMM) столкнулись с тем, что узлы отдельные узлы зависали и приходилось их перезагружать "по питанию". 
Процедура создания Network Service добавляет все узлы хост-группы последовательно, но из "рандомного" массива. Поэтому, следующий сбой был слабопредсказуем и закономерность сразу не прослеживалась для всех узлов.

После упорного траблшутинга выяснилось, что после пересоздания коммутатора  и vNIC для HCI* кластера не выполнена настройка привязки интерфейсов vNIC для SMB трафика к физическим интерфейсам, с помощью команд:

Set-VMNetworkAdapterTeamMapping -VMNetworkAdapterName 'SMB-Storage-1' –ManagementOS –PhysicalNetAdapterName 'SLOT 6 Port 1'

Set-VMNetworkAdapterTeamMapping -VMNetworkAdapterName 'SMB-Storage-2' –ManagementOS –PhysicalNetAdapterName 'SLOT 6 Port 2'

Диагностировать это событие можно по сообщениям в журналах "сбойного" узла.




После исправления конфигурации NC успешно установился на HCI кластер.

*Hyper-Converged Infrastructure 

среда, 28 июня 2017 г.

Get-StorageJob показывает задание в статусе "Suspeneded"

При работе с Storage Spaces Direct столкнулись с ситуацией, что Storage Job ушли в состояние "Suspended" и никакие действия не приводили к их реанимации. В том числе, с перемещением дисков и пула на один физический узел.
Проблема возникла для конкретного виртуалного диска.

Выглядело этот следующим образом:

Проблемный виртуальный диск находился в статусе "Health Status" - Warning и "Operational Status" - Degraded.
Всё физическое оборудование работало корректно.
Ни оптимизация хранилища, ни Repair-VirtualDisk проблему не решали (Repair вообще зависал в статусе "Starting").
 
 
 При этом, SCVMM не в состоянии обновить данные Storage Provider, ошибки следующего формата (см. ниже).

Также, невозможен перевод узлов в режим "обслуживания" (Maintenance). 
 
В ветке WMI ROOT\MICROSOFT\WINDOWS\STORAGE\Providers_v2\ в классе SPACES_StorageJob (или аналогичном классе MSFT) находились те самые подвисшие задачи, с прикольным сроком начала.
 
 
Пробовали разные варианты,  в итоге помогло полное удаление виртуального диска и создание его заново.

Storage Spaces Direct: проблемы возникающие при пересборке S2D

На днях повторно поднимал Storage Spaces Direct кластер для настройки Fault Domains, однако, выполнение CMDLet Enable-S2D желаемого результата не принесло.
Предыдущий кластер S2D был "снесён" штатно.
На узлах наблюдалась странная картина - очень интересно, что один из узлов, отсутствовал в перечне (вывод с 9-го сервера).

 

Судя по всему, система продолжала считать, что кластер жив... Статус всех дисков при использовании CMDLet Get-PhysicalDisk параметре "CanPool" был равен "FALSE".

Также, выявилась забавная история: вывод состава дисков 1-го и 2-го серверов кардинально различался, хотя на 2-м сервере в системе они присутствовали все.




В диспетчере кластеров картина была ещё более загадочной :)



Детальный анализ выявил "остаточные" тома на дисках 1-го сервера.


Мы удалили оставшиеся тома.



После этого ситуация изменилась....
 

Однако, у нас оставалась проблема, заключающаяся в том, что на 1-м сервере не было NVME дисков для включения в пул для кэш. Причина была аналогичная - эти диски имели созданные тома.



После этого, система заработала "штатно", enclosures определились корректно, и кластер S2D удалось собрать.


\