Недавно мы получили проект по внедрению системы мониторинга на SCOM2012R2 в одном банке. Одним из “предвыборных обещаний” на этапе пресейла был мониторинг кластерных дисков. В банке множество виртуалок, размещённых на дисковой хранилке hp 3par, если на ЛУНах заканчивалось место, машины вставали на паузу. Одной из мер по предотвращению этого безобразия должен был стать SCOM.

Каково же было моё удивление, когда оказалось, что SCOM не только не мониторит свободное место на дисках заказчика, но даже и не видит их. Смотрите сами, списки кластерных дисков пусты:

При этом как ни странно, в нашей собственной инфраструктуре кластерные диски успешно мониторятся. Да и у других клиентов я такой проблемы не припомню.

Ну что ж, долго ли коротко ли, исследования причин проблемы привели меня в правило обнаружения кластерных дисков. Правило называется “Cluster Disks Discovery” и находится оно в пакете управления “Windows Server Cluster Disks Monitoring”, который поставляется в наборе пакетов управления для мониторинга Windows Server OS. Правило скриптовое, скрипт довольно объёмный, понимание, почему он не работает пришло не сразу. В итоге я набрёл на следующие строки:

Всё, что делает скрипт после этих строк – полнейшая бессмыслица, которая ни к чему не приводит. Происходит это потому, что скрипт не ожидает получить blnUseResource = false, но получает. То есть у нас там 2 раза что-то сравнивается друг с другом и оно никогда друг-другу не равно. Давайте разбираться, что там такое сравнивается:

strTargetComputer берётся из параметров запуска скрипта, и равно оно $Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$

Это ни что иное, как имя сущности Windows Computer, которая относится к Hyper-V кластеру. Наверняка вы замечали, что в оперативной консоли SCOM во вьюшке Windows Computers появляются все кластеры с заполненными атрибутами. Вот там и найдём наш кластер, чтобы подсмотреть значение PrincipalName.

Итак, запомним PrincipalName кластера: xxx-hyperv-farm.domain.com

strDnsName добывается из WMI на компьютере, где отрабатывает скрипт. Обратимся к WMI, чтобы подсмотреть значение переменной. Воспользуемся Powershell:

$objClusterResNetworks = Get-WMIObject -namespace “root\MSCluster” -query “Select * from MSCluster_Resource where Type =’Network Name’”
ForEach ($objClusterResNet In $objClusterResNetworks) {$objClusterResNet.PrivateProperties.DnsName}

И вот что мы получаем:

Действительно, на лицо несовпадение: xxx-hyperv-farm не равно xxx-hyperv-farm0. Кто же прав, SCOM или WMI? Проверим имя кластера в оснастке Failover Cluster Manager.

Прав WMI. Итак, SCOM оперирует неправильным именем кластера, из-за этого не обнаруживаются кластерные диски. Присмотревшись к журналу событий Operations Manger, я обнаружил ещё кучу ошибок, связанных с невозможностью открыть реестр на компьютере xxx-hyperv-farm, обратиться к WMI компьютера xxx-hyperv-farm и т.д. от самых разных пакетов управления.

 

Значит исправлять правило обнаружения кластерных дисков не имеет особого смысла, останется куча других ошибок. Надо копать глубже.

После некоторого размышления решение нашлось. xxx-hyperv-farm0 – 16 символов, из них один обрезается, остаётся 15 – как раз максимальная длина нетбиос имени. Явно где-то в глубинах SCOM значение атрибута windows computer principal name берётся из NETBIOS имени компьютера, а всё что свыше 15 символов обрезается. Значит нам нужно ни много ни мало – переименовать кластер во что-то более короткое, укладывающееся в 15 символов. После этого обнаружатся кластерные диски, да и остальные ошибки из лога должны исчезнуть.

Итак, открываем оснастку Failover Cluster Manager, и укорачиваем имя кластера:

Уберём дефис из середины:

Оснастка предупреждает о страшном, но жмём Yes

Всё, кластер имеет короткое имя.

Ждём немного, и вуаля – диски мониторятся, и даже алёрт о нехватке свободного места выскочил. Ошибки в логах тоже исчезли.