Недавно мы получили проект по внедрению системы мониторинга на SCOM2012R2 в одном банке. Одним из “предвыборных обещаний” на этапе пресейла был мониторинг кластерных дисков. В банке множество виртуалок, размещённых на дисковой хранилке hp 3par, если на ЛУНах заканчивалось место, машины вставали на паузу. Одной из мер по предотвращению этого безобразия должен был стать SCOM.
Каково же было моё удивление, когда оказалось, что SCOM не только не мониторит свободное место на дисках заказчика, но даже и не видит их. Смотрите сами, списки кластерных дисков пусты:
При этом как ни странно, в нашей собственной инфраструктуре кластерные диски успешно мониторятся. Да и у других клиентов я такой проблемы не припомню.
Ну что ж, долго ли коротко ли, исследования причин проблемы привели меня в правило обнаружения кластерных дисков. Правило называется “Cluster Disks Discovery” и находится оно в пакете управления “Windows Server Cluster Disks Monitoring”, который поставляется в наборе пакетов управления для мониторинга Windows Server OS. Правило скриптовое, скрипт довольно объёмный, понимание, почему он не работает пришло не сразу. В итоге я набрёл на следующие строки:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
For Each objClusterResNet In objClusterResNetworks strDnsName = objClusterResNet.PrivateProperties.DnsName If InStr(strTargetComputer, ".") > 0 Then If LCase(Left(strTargetComputer, InStr(strTargetComputer, ".") - 1)) = LCase(strDnsName) Then blnUseResource = True else blnUseResource = false End If Else If LCase(strTargetComputer) = LCase(strDnsName) Then blnUseResource = True else blnUseResource = false End If End If If blnUseResource = true Then |
Всё, что делает скрипт после этих строк – полнейшая бессмыслица, которая ни к чему не приводит. Происходит это потому, что скрипт не ожидает получить 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 и т.д. от самых разных пакетов управления.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
Log Name: Operations Manager Source: Health Service Modules Date: 23.06.2014 13:39:58 Event ID: 31901 Task Category: None Level: Error Keywords: Classic User: N/A Computer: xxx-HyperV01.MSK.domain.com Description: The Registry Probe could not connect to the registry of the computer 'xxx-HYPERV-FARM.domain.com'. Error: 0x80070035 One or more workflows were affected by this. Workflow name: Microsoft.Windows.FileServer.DFSR.2003.DFSRServerDiscovery2003 Instance name: xxx-HYPERV-FARM.domain.com |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
Log Name: Operations Manager Source: Health Service Modules Date: 23.06.2014 8:30:40 Event ID: 10401 Task Category: None Level: Warning Keywords: Classic User: N/A Computer: xxx-HyperV01.domain.com Description: Module was unable to connect to namespace '\\xxx-HYPERV-FARM.domain.com\root\cimv2' This has happened 1 times since this instance was loaded. HRESULT: 0x800706ba Details: The RPC server is unavailable. One or more workflows were affected by this. Workflow name: Microsoft.Windows.Server.6.2.Computer.Discovery Instance name: xxx-HYPERV-FARM.domain.com |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
Log Name: Operations Manager Source: Health Service Modules Date: 23.06.2014 7:40:32 Event ID: 31901 Task Category: None Level: Error Keywords: Classic User: N/A Computer: xxx-HyperV01.domain.com Description: The Registry Probe could not connect to the registry of the computer 'xxx-HYPERV-FARM.domain.com'. Error: 0x80070035 One or more workflows were affected by this. Workflow name: Microsoft.SQLServer.2005.SeedDiscovery Instance name: xxx-HYPERV-FARM.domain.com |
Значит исправлять правило обнаружения кластерных дисков не имеет особого смысла, останется куча других ошибок. Надо копать глубже.
После некоторого размышления решение нашлось. xxx-hyperv-farm0 – 16 символов, из них один обрезается, остаётся 15 – как раз максимальная длина нетбиос имени. Явно где-то в глубинах SCOM значение атрибута windows computer principal name берётся из NETBIOS имени компьютера, а всё что свыше 15 символов обрезается. Значит нам нужно ни много ни мало – переименовать кластер во что-то более короткое, укладывающееся в 15 символов. После этого обнаружатся кластерные диски, да и остальные ошибки из лога должны исчезнуть.
Итак, открываем оснастку Failover Cluster Manager, и укорачиваем имя кластера:
Уберём дефис из середины:
Оснастка предупреждает о страшном, но жмём Yes
Всё, кластер имеет короткое имя.
Ждём немного, и вуаля – диски мониторятся, и даже алёрт о нехватке свободного места выскочил. Ошибки в логах тоже исчезли.
Оставить комментарий или два