Мониторинг своими руками

При работе над статьей я столкнулся с большим количеством терминов, описывающих нужные нам технологии. Их обилие порой вводит в заблуждение: CIM, CIMOM, WBEM, WMI, WINRM/WINRS, WSMAN, POWERSHELL REMOTING. Давайте, прежде всего, разберем, что такое CIM. В 1999 году организация по стандартизации Distributed management Task Force (DMTF) разработала и опубликовала набор предложений по удаленному обмену управляющей информацией для систем, сетей и оборудования. Основная идея модели заключается в том, что управляемые сущности описаны при помощи объектов, имеют свойства с данными и методы, которые можно вызвать удаленно и изменить состояние объекта. Следующим этапом развития этой технологии является инициатива Web-Based enterprise management (WBEM). В ней DMTF предложила набор механизмов, который бы позволил обращаться к данным CIM по протоколу HTTP, используемому в качестве транспортного. Для выполнения операций с CIM был разработан протокол CIM-XML. Эта технология была частично реализована в операционных системах Microsoft. Однако в качестве протокола транспортного уровня специалисты Microsoft предпочли использовать DCOM, что сделало эту реализацию несовместимой со стандартом. В итоге появилась технология Windows Management Instrumentation (WMI). По сути, это реализация инициатив CIM/WBEM с точки зрения Microsoft. Но прогресс не стоит на месте, и сравнительно недавно DMTF предложила очередную идею обеспечения удаленного управления системами на базе CIM через HTTP. На этот раз в качестве рабочей лошадки был выбран SOAP, а инициатива была названа WS-Management (WSMAN). Специалисты Microsoft решили не отступать от общепринятого стандарта и реализовали этот механизм в своих системах, назвав его WinRM. В итоге в Windows появилась возможность унифицированного доступа к CIM на различных платформах. В спецификации структура стека протоколов выглядит так, как показано на рисунке 1.

Рисунок 1. Структура стека WS-Management

Однако разработчики Microsoft на этом не остановились. Для обеспечения и упрощения удаленной работы в своем новом инструменте командной строки Powershell они разработали протокол Powershell Remoting Protocol. Структура его функционирования представлена на рисунке 2. Здесь MS-WSMV — это Web Services Management Protocol Extensions for Windows Vista, реализация протокола WS-Management для операционной системы Windows Vista. А MS-PSRP — собственно Powershell Remoting Protocol. Как мы видим, он работает на основе стандарта WS-Management.

Рисунок 2. Структура стека Powershell Remoting

На платформах UNIX/Linux ситуация выглядит несколько иначе. Для них существует несколько реализаций WBEM на HTTP/CIM-XML, что делает невозможным доступ к CIM из систем Windows при помощи стандартных утилит. В своих тестах я опробовал несколько подобных реализаций — OpenPegasus (http://www.openpegasus.org/) и SBLIM (http://sourceforge.net/apps/mediawiki/sblim/index.php? title=Main_Page). Оба проекта предоставляют возможность доступа к CIM по HTTP или HTTPS. Аутентификация реализуется либо своими средствами, либо при помощи PAM. Можно подключать внешние классы. Однако при работе с OpenPegasus у меня возникли некоторые проблемы с настройкой, но об этом немного позже. С другой стороны, исходный код OpenPegasus является основой для агентов SCCM, использующихся для мониторинга систем Linux.

Реализация WS-Management для этой платформы тоже существует. В своих экспериментах я использовал Openwsman (http://www.openwsman.org).

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

Следующий шаг в развитии этих технологий — инициативы Systems Management Architecture for Server Hardware (SMASH) и Desktop and mobile Architecture for System Hardware (DASH). Эти технологии предназначены для удаленного управления аппаратным обеспечением. Их реализация встроена в аппаратное обеспечение. Таким образом, если ваше оборудование поддерживает эти технологии, возможны такие операции, как включение и выключение питания компьютера удаленно из командной строки без участия операционной системы. Поддержка этих технологий реализована в продуктах Intel (Intel AMT), HP (SMASH CLP в HP iLO2), AMD (AMD DAS 1.0).

Теперь рассмотрим методы, при помощи которых мы можем добраться до данных на различных платформах.

WMI, Windows и PowerShell

На эту тему написано уже очень много. Примеры сценариев можно найти в Интернете, в различных журналах и книгах. Поэтому особо углубляться не будем. Напомню только, что основной командой для работы с wmi является get-wmiobject. Можно использовать псевдоним gwmi. Например, классическое получение списка служб выполняется командой:

gwmi win32_Service | Format-Table
   -AutoSize

Для того чтобы получить список служб с удаленной системы, можно задействовать соответствующий параметр:

gwmi win32_Service -ComputerName
   localhost | Format-Table -AutoSize

Все это успешно работает в рамках домена, если у вас есть соответствующие права на клиентских компьютерах.

WBEM, Linux и PowerShell

В данном случае все обстоит несколько сложнее. Мы не можем воспользоваться стандартными возможностями PowerShell по причинам, описанным выше. Однако запросить данные мы все же можем. В принципе можно не только запрашивать данные, но и делать все те вещи, которые поддерживает используемый вами сервер WBEM. В нашем случае в качестве примера применяется SBLIM SFCB. Памятуя о том, что в качестве протокола для запросов используется специальный протокол CIM-XML, в качестве транспорта HTTP напишем простой сценарий, который будет запрашивать определенный набор данных у сервера WBEM.

Принцип работы сценария достаточно прост. Он прочитывает подготовленный запрос в формате xml из файла, подготавливает пакет HTTP с нужными заголовками, оправляет готовый запрос на сервер и получает результат. Затем этот результат можно анализировать, зная схему XML-ответа. Все это выглядит так, как показано в листинге 1. Сам запрос представлен в листинге 2, а ответ — в листинге 3.

Теперь перейдем к WS-Management.

WS-MAN и Windows

В Windows мы можем использовать несколько средств работы с WS-Man. Это, прежде всего, PowerShell, а также утилита winrm. Утилита поддерживает следующие операции: GET, PUT, ENUMERATION, INVOKE. С ее помощью можно:

перечислять экземпляры классов wmi:

-Winrm enumerate wmicimv2/
   Win32_Service

получать данные конкретного экземпляра:

-Winrm get wmicimv2/Win32_Service?
   Name=lanmanserver

обращаться к удаленным системам:

-Winrm get wmicimv2/Win32_Service?
   Name=lanmanserver -r: remoteHost

вызывать функции классов wmi на удаленных системах:

-winrm invoke reboot wmicimv2/
   Win32_OperatingSystem
-r: remoteHost

запускать службы на удаленных системах

-winrm invoke startservice wmicimv2/
   Win32_Service? name=w32 time
-r: remoteHost

Следующая возможность — использование команд PowerShell. Их список можно получить с помощью команды

Get-Command *wsman* -CommandType
   Cmdlet

В инфраструктуре Windows для того, чтобы проверить, возможен ли доступ к удаленной системе при помощи wsman, используется команда

Test-WSMan: Test-WSMan -ComputerName
   someserver

Более подробно обо всех командах WS-Man можно узнать (см. экран), запросив справку командой:

help about_WS-Management_Cmdlets

Экран. Список команд WS-Management

WS-MAN и Linux

Теперь перейдем к самому интересному разделу — к возможностям получения информации о настройках при помощи WS-Man из систем Linux. Прежде всего рассмотрим архитектуру решения, которое необходимо настроить для этой задачи. Состоит она из трех компонентов.

openwsman (http://www.openwsman.org/). Серверное программное обеспечение, реализующее коммуникацию с клиентом посредством протокола WS-Management.
SBLIM SFCB (http://sourceforge.net/apps/mediawiki/sblim/index.php? title=Sfcb). Серверное программное обеспечение, реализующее CIM.
SBLIM SFCC (http://sourceforge.net/apps/mediawiki/sblim/index.php? title=Sfcc). Клиент для SBLIM SFCB.

В конечном итоге архитектура выглядит так, как показано на рисунке 3. Проще говоря, при обращении по протоколу WS-Management сервер openwsman обрабатывает полученный запрос, при помощи клиента SFCC обращается к серверу SFCB за данными CIM. Затем эти данные преобразуются к нужному виду и отправляются в ответ. С другой стороны, в этой архитектуре мы имеем возможность обратиться к серверу SFCB самостоятельно, но уже по протоколу WBEM/CLI-XML и получить те же данные.

Рисунок 3. Архитектура решения WS-Man для Linux

При настройке я использовал последний доступный дистрибутив CentOS и RPM-пакеты SFCB и Openwsman. Последний уже имеет в своем составе sfcc, поэтому отдельно устанавливать его не нужно. Настройка сервера openwsman и SFCB проста: листинг 4 содержит параметры openwsman, а листинг 5 — параметры sfcb. Обратите внимание на выделенную запись в листинге 4. Она сообщает openwsman, что он должен использовать sfcc/sfcb для получения данных CIM. Кроме того, вместе с пакетами устанавливаются сценарии генерации ключей для соединений HTTPS. Без сгенерированных и установленных ключей эти серверы не запускаются. Однако и тут не все гладко. Сценарий для sfcb отказался работать в каталоге, в который он установлен по умолчанию. Нормально он отработал только в корневом каталоге и там же создал нужные файлы сертификатов и ключа. Затем эти файлы необходимо перенести в каталог с файлом конфигурации, поскольку путь к ним прописан именно здесь. Кроме того, нужно сгенерировать файлы паролей для аутентификации basic и digest. Для генерации файлов паролей используются утилиты htpasswd и htdigest соответственно.

Итак, нужное программное обеспечение на системе Linux настроено, соответствующие порты открыты, приступаем к тестам. И вот здесь снова начинаются проблемы. Самая первая — мне не удалось применить аутентификацию digest. При использовании аутентификации basic и http имеем следующее: проверяем наличие WS-Man (листинг 6), получаем данные — листинг 7. Похоже, работает. Однако попытка проверить соединение из PowerShell при помощи

Test-WSMan -ComputerName
   192.168.1.35 Authentication
   Basic -Credential (Get-Credential)

приводит к ошибке аутентификации. То же самое происходит со всеми попытками получить данные. Как же так? Здесь я поломал голову. На этот раз проблема уже на стороне Windows, а именно в реализации команд PowerShell в части аутентификации basic. Эта проблема существует уже давно и подробно описана (http://blog.whatsupduck.net/2009/09/not-using-PowerShell-v2 to-view-wsman.html). Вкратце, она заключается в том, что внутренняя реализация запроса вставляет перед именем пользователя символ ‘\’. К сожалению, эта ошибка до сих пор не исправлена.

Но, несмотря на это, получить данные можно. Для этого задействуем метод, основанный на использовании COM-объекта WSMan.Automation. В этом случае мы вручную создаем объекты подключения и настроек подключения с нужными флагами. Затем устанавливаем соединение и запрашиваем данные. В этом случае аутентификация проходит нормально, и данные возвращаются корректно. Исходный код сценария представлен в листинге 8.

В конечном итоге можно отметить, что Microsoft в некотором смысле идет навстречу ИТ-сообществу, реализуя стандарты, позволяющие организовать мониторинг и управление различными платформами. Справедливости ради надо сказать, что многие крупные производители программного и аппаратного обеспечения стали активно использовать стандарты DMTF в своих продуктах. Это предоставляет широкие возможности для консолидации управления большим количеством программных и аппаратных ресурсов в единой точке. Однако в этом направлении еще предстоит большая работа.

Андрей Вернигора (eosfor@gmail.com) — системный администратор, ведет блог http://eosfor.blogspot.com. Имеет сертификаты MCSA, MCDBA, MCSE, MCT

Листинг 1. Сценарий для запроса данных с WBEM-сервера без аутентификации

cls

$server = '192.168.1.35' #адрес сервера
$port = ‘5988’ # порт сервера

[string]$data = Get-Content -Path c:\tools\query5.xml

[system.Net.ServicePointManager]::Expect100Continue = $false; #отключаем ненужный заголовок

[System.Text.ASCIIEncoding] $ASCIIEncoding = new-object System.Text.ASCIIEncoding
[system.byte[]] $bytes = $ASCIIEncoding.GetBytes($data)

[System.Net.WebClient]$client = New-Object System.Net.WebClient
$client.Headers.Add("Content-Type","application/xml; charset=utf-8")
$client.Headers.Add("CIMProtocolVersion", "1.0")
$client.Headers.Add("CIMOperation", "MethodCall")
$client.Headers.Add("CIMMethod", "EnumerateInstances")
$client.Headers.Add("CIMObject", "root%2Fcimv2")
[System.Byte[]]$b = $client.UploadData("http://$server`:$port/cimom",’POST’,$bytes)

[System.Text.ASCIIEncoding] $ASCIIEncoding = new-object System.Text.ASCIIEncoding
[xml]$MyString = $ASCIIEncoding.GetString($b);

Листинг 2. Запрос EnumerateInstances класса CIM_OperatingSystem

Листинг 3. Разобранный ответ сервера на запрос EnumerateInstances класса CIM_OperatingSystem

PctTotalCPUTime 1
DefaultPageSize 4096
CodeSet ANSI_X3.4-1968
LanguageEdition en-US
TransitioningToState 12
TimeOfLastStateChange
EnabledDefault 2
RequestedState 2
OtherEnabledState NULL
EnabledState 2
PrimaryStatus
OperatingStatus
DetailedStatus
CommunicationStatus
HealthState 5
Status NULL
InstallDate
InstanceID
Caption Operating System
Description A class derived from OperatingSystem to represents the running Linux OS.
ElementName CentOS release 5.5 (Final)
CSCreationClassName Linux_ComputerSystem
CSName localhost.localdomain
CreationClassName Linux_OperatingSystem
Name localhost.localdomain
OSType 36
OtherTypeDescription NULL
Version CentOS release 5.5 (Final)
LastBootUpTime 20101230204002.000000+120
LocalDateTime 20110103225947.000000+120
CurrentTimeZone 120
NumberOfLicensedUsers 0
NumberOfUsers 3
NumberOfProcesses 144
MaxNumberOfProcesses 16384
TotalSwapSpaceSize 2096472
TotalVirtualMemorySize 3131580
FreeVirtualMemory 2504468
FreePhysicalMemory 428692
TotalVisibleMemorySize 1035108
SizeStoredInPagingFiles 2096472
FreeSpaceInPagingFiles 2075776
MaxProcessMemorySize 4294967295
Distributed FALSE
MaxProcessesPerUser 16384

Листинг 4. Файл конфигурации openwsman.conf

[server]
port = 5985
ipv4 = yes
ipv6 = yes
ssl_cert_file = /etc/openwsman/servercert.pem
ssl_key_file = /etc/openwsman/serverkey.pem
digest_password_file = /etc/openwsman/digest.passwd
basic_password_file = /etc/openwsman/simple_auth.passwd
min_threads = 4
max_threads = 0
max_connections_per_thread=20
[cim]
default_cim_namespace = root/cimv2
cim_client_frontend = SfcbLocal
vendor_namespaces = OpenWBEM=http://schema.openwbem.org/wbem/wscim/1/cim-schema/
   2,Linux=http://sblim.sf.net/wbem/wscim/1/cim-schema/2,OMC=http://schema.omc-project.org/
   wbem/wscim/1/cim-schema/2,PG=http://schema.openpegasus.org/wbem/wscim/1/cim-schema/2

Листинг 5. Файл конфигурации sfcb.cfg

enableHttp: true
httpPort: 5988
httpUserSFCB: true
httpProcs: 8
httpLocalOnly: false
useChunking: true
doBasicAuth: false
basicAuthLib: sfcBasicPAMAuthentication
provProcs: 32
maxMsgLen: 10000000
registrationDir: /var/lib/sfcb/registration
providerDirs: /usr/lib/sfcb /usr/lib /usr/lib/cmpi
enableInterOp: true
providerSampleInterval: 30
providerTimeoutInterval: 60
providerAutoGroup: true
validateMethodParamTypes: false
providerDefaultUserSFCB: true
enableHttps: true
httpsPort: 5989
httpsProcs: 8
sslKeyFilePath: /etc/sfcb/file.pem
sslCertificateFilePath: /etc/sfcb/server.pem
sslClientCertificate: ignore
sslClientTrustStore: /etc/sfcb/client.pem
certificateAuthLib: sfcCertificateAuthentication

Листинг 6. Проверка наличия WS-Man при помощи winrm

winrm id -r:192.168.1.35 -auth:basic -username:user -password:p@ssw0rd
IdentifyResponse
    ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
    ProductVendor = Openwsman Project
    ProductVersion = 2.2

Листинг 7. Результат WS-MAN-запроса к Linux-системе при помощи winrm

winrm enumerate http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_StatisticalData
   -username:user -password:p@ssw0rd -r:192.168.1.35:5985/wsman -auth:basic
Linux_OperatingSystemStatisticalData
    BlockQueueLength = 0
    CPUIdleTime = 396772900
    CPUSystemTime = 3676710
    CPUUserTime = 2352220
    CPUWaitTime = 913930
    Caption = Linux_OperatingSystemStatisticalData
    Description = statistical information about operating system
    ElementName = localhost.localdomain
    InstanceID = Linux:localhost.localdomain
    PagesPagedIn = 2031202
    PagesPagedOut = 5801566
    RunQueueLength = 2
    SampleInterval = 00000000000000.000000:000
    StartStatisticTime = 20101231160514.000000+120
    StatisticTime = 20110105160031.620893+120

Листинг 8. Сценарий для работы с WS-MAN при помощи COM объекта WSMan

$objWRM = New-Object -ComObject WSMan.Automation
$options = $objWRM.CreateConnectionOptions()
$options.UserName=’user’
$options.Password=’p@ssw0rd’
$flags = $objWRM.SessionFlagUseBasic() -bor $objWRM.SessionFlagCredUsernamePassword()

$winrmSession = $objWRM.createsession("http://192.168.1.35:5985/wsman",$flags,$options)
$winrmSession | Format-List

$ResourceUri = "http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_StatisticalData"
$s= $winrmSession.Enumerate($ResourceUri)
$services = &{do { ([xml]$s.ReadItem()).Linux_OperatingSystemStatisticalData } until ($s.AtEndOfStream)}
$services