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 удалось собрать.

\

 

 

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

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

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

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

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

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

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

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

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

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