понедельник, 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.


пятница, 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 удалось собрать.


\
 
 

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

Проблема интеграции WAP, SMA, SPF и VMM

Привет, пытаюсь возобновить ведение блога после длительного перерыва - много работы в текущем проекте по построению облака на технологиях Microsoft.

Коротко о маленьком нюансе при интеграции WAP, SMA, SPF и VMM.

SMA можно эффективно использовать при создании автоматизаций в облаке Microsoft.
К примеру, мы хотим запускать какую-либо автоматизацию по триггеру события, скажем на запуск виртуальной машины.

Для того, чтобы SMA был в состоянии запускать что-либо по триггеру, необходимо добавить учётную запись веб-сервиса VMM в группу smaAdminGroup.

Пример поиска проблемы привожу ниже (нажмите на картинку, чтобы увеличить).

При анализе журналов IIS на SMA NLB кластере мне удалось увидеть сообщение (выделенное синим). Оно говорит о том, что есть проблемы с доступом учётной записи  к SMA.

После добавления учётной записи в соответствующую группу, мы видим изменение в урналах IIS. Нюанс: наличие УЗ в данной группе не даёт права УЗ на доступ к самому серверу, а он нужен, посему УЗ веб-сервиса VMM добавлена и в локальные администраторы сервиса SMA.


(нажмите на картинку, чтобы увеличить).
 При нормальном запуске автоматизаций в журнале Microsoft-ServiceManagementAutomation появляются следующие сообщения