Windows Management Instrumentation

Говоря о Windows 2000, принято оперировать понятиями TCO и простоты администрирования, хотя далеко не все догадываются, что именно дает повод для таких характеристик. Дело в том, что к подобным вопросам у нас сложилось весьма своеобразное отношение. Нередко администратор только инициализирует сервер и рабочие станции, а после занимается чем угодно — компьютеры починяет, бухгалтерские программы латает, — но только не своими прямыми обязанностями. При этом у руководителей создается впечатление, что TCO представляет собой если и не ноль, то бесконечно малую величину, а об утечке конфиденциальных данных, простое рабочих станций, эффективности использования ресурсов задумываться не принято.

Следует сказать, что в определенных ситуациях (когда под сетью понимают три-четыре кое-как соединенных между собой ПК, а вокруг достаточно много минимально квалифицированной, но предельно дешевой рабочей силы) такой подход себя оправдывает. Чего не скажешь о действительно современных корпоративных информационных системах, характеризуемых распределенной структурой, гетерогенностью, разнообразием решаемых задач и сложностью программного обеспечения. Прибавьте к этому разрозненность инструментария, дороговизну большинства систем централизованного управления, необходимость глубокого изучения многочисленных технологий, и вы поймете, насколько непрост труд "настоящего" администратора и что TCO — вовсе не миф.

Чтобы решить описанные проблемы и максимально упростить администрирование Windows-сетей, компания Microsoft разработала немало технологий, утилит и прочих средств, как реализованных непосредственно в ОС семейства Windows, так и распространяемых в многочисленных Resource Kit и ZAK. Одна из последних новинок — WMI (Windows Management Instrumentation), гибкая и масштабируемая инфраструктура для управления вычислительными комплексами, сетями и приложениями, встроенная в Windows 2000 и доступная для других платформ в виде отдельных компонентов.

WMI является реализацией универсального стандарта удаленного администрирования WBEM (Web-Based Enterprise Management) и объектной модели информации CIM (Common Information Model), предложенных международной организацией по продвижению технологий удаленного управления DMTF (более подробно о деятельности DMTF и ее инициативах в области администрирования можно узнать на ее официальном Web-узле: www.dmtf.org). Данный стандарт позволяет выработать единый подход к управлению разноплановыми объектами информационных систем (серверы, рабочие станции, периферия, серверные и настольные приложения и пр.). До этого управление каждой категорией таких объектов осуществлялось по различным, несовместимым между собой протоколам (например, для управления настольными системами и периферийными устройствами широко применялся протокол DMI (Desktop Management Interface), а сетевыми и межсетевыми устройствами и приложениями — протокол SNMP). К слову, стандарт WBEM реализован не только Microsoft, но и другими производителями операционных систем. Так, компания Sun Microsystems перенесла его на платформу своей ОС Solaris (www.sun.com/solaris/wbem/).

В WMI включены как стандартные управленческие объекты CIM, так и дополнительные объекты, предоставляющие доступ к специфическим массивам информации на платформе Windows (например, Active Directory). Благодаря этому практически всеми аспектами Windows 2000 можно управлять через единый объектный интерфейс, базирующийся на общепризнанных стандартах и легко дополняемый и расширяемый сообразно с потребностями конкретной организации или в связи с дальнейшим развитием технологий. Более того, любая программа или сценарий, которые обращаются к управленческим данным WMI, могут выполнять свои задачи единообразно как на локальной машине, так и удаленно.

Особенности WMI

WMI обладает многими важными чертами, которые должны по достоинству оценить системные администраторы и IT-менеджеры.

Прежде всего — универсальный API для написания сценариев. Все объекты WMI определены в рамках единого подхода, основанного на объектной модели CIM. Приложениям-потребителям достаточно использовать единственный WMI API для доступа к управленческой информации из разнообразных источников. Таким образом, отпадает необходимость в реализации множества различных стандартов и протоколов, поддерживаемых разными типами управляемых объектов.

Другая существенная особенность — удаленное администрирование. COM-объекты, определенные в рамках WMI, доступны как на локальной машине, так и при дистанционных обращениях через сеть (благодаря стандартным для платформы Windows технологиям DCOM, RPC, COM+). Для управления удаленными объектами не требуется никакого дополнительного программного обеспечения.

Не менее важна присущая WMI открытость. Приложения и сценарии способны устанавливать, какая именно информация доступна о той или иной системе, обрабатывая список присутствующих в ней классов из иерархии WMI. Анализируя взаимоотношения между связанными объектами, можно сделать вывод о том, каким образом управленческое влияние на одну сущность затронет другие, имеющиеся в корпоративной информационной системе.

Кроме того, WMI представляет всю управленческую информацию о конкретной системе в виде реляционной базы данных, что дает возможность строить и выполнять стандартные SQL-запросы, фильтрующие данные по некоторым указанным пользователем критериям.

Ну и, наконец, мощная система публикации событий. Каждая программа, поддерживающая WMI, может получать оповещения практически о любых изменениях, происходящих с управляемыми объектами в информационной системе. Это достигается за счет организации виртуальных событий, которые генерируются в ответ на те или иные изменения и затем публикуются для всех заинтересованных процессов и приложений. Причем эти события могут порождаться как самими управляемыми объектами и их программными интерфейсами, а после ретранслироваться WMI API, так и непосредственно на уровне WMI API. Предусмотрена также возможность избирательного оповещения программ и сценариев о событиях определенного типа; в этом случае они как бы "подписываются" на эту информацию. С помощью WMI API системный администратор может также задавать собственные события и затем отслеживать их в своих управленческих приложениях.

Архитектура WMI

WMI имеет трехуровневое строение (см. схему). На нижнем уровне архитектуры находятся провайдеры WMI, специфичные для каждого отдельного объекта корпоративной информационной системы (например, драйвера аппаратного устройства, операционной системы, службы, программного комплекса и т. д.). Провайдеры выступают посредниками между управляемыми объектами и менеджером CIM (см. далее). Их задача заключается в извлечении соответствующей информации об объекте через доступные программные интерфейсы (разумеется, в каждом конкретном случае набор таких интерфейсов специфичен). Полученные данные "проецируются" на соответствующие классы WMI API, которые уже могут применяться конечными потребителями WMI. В дальнейшем, при создании новых управляемых компонентов и доработке ранее созданных, использование провайдеров WMI значительно упростит разработчикам задачу предоставления конечным пользователям гибкого контроля за своими продуктами.

На среднем уровне WMI находится менеджер CIM, имеющий собственное хранилище информации и выступающий в роли брокера объектных вызовов. Менеджер CIM и его хранилище информации представлены в операционной системе службой WinMgmt (реализованной в виде отдельного приложения WinMgmt.exe). Провайдеры WMI взаимодействуют с менеджером CIM через набор специальных COM-интерфейсов.

Менеджер CIM отслеживает, какие именно классы WMI доступны в системе (их определения находятся в хранилище менеджера CIM) и какие провайдеры WMI ответственны за работу с ними. Когда потребитель WMI посылает запрос на получение некоторой информации, менеджер CIM анализирует его, перенаправляет соответствующему провайдеру, а затем возвращает полученные от него данные. Потребителю WMI достаточно только запросить интересующую его информацию, не вдаваясь в подробности относительно ее источника.

Наконец, на самом высоком уровне находятся потребители WMI. Ими могут быть пакеты вроде Microsoft Systems Management Server или продукты сторонних разработчиков, а также обычные сценарии. Как уже отмечалось, этим приложениям необходимо лишь знать о классах WMI, представляющих тот или иной управляемый объект, а детали обработки их запросов скрыты на нижних уровнях архитектуры WMI. Таким образом, вызывая функции единого интерфейса WMI API, программы могут получить огромные массивы разнообразной управленческой информации о компьютерах, устройствах, операционных системах, драйверах и приложениях, функционирующих в пределах корпоративной информационной среды. Кроме того, у пользователей WMI есть возможность работать с информацией, доступной через другие протоколы сетевого управления — SNMP, DMI и пр.

Потребители WMI могут взаимодействовать со службой WinMgmt через множество разнообразных интерфейсов. Например, Web-приложения используют технологии ASP или XML для доступа к менеджеру CIM, а полновесные приложения Win32 работают с ним через OLE DB.

Представленное выше описание архитектуры WMI является лишь общей схемой, где опущены технологические детали ее реализации. Читателям, которым будет интересно заглянуть внутрь WMI и подробнее изучить "анатомию" этой технологии, стоит познакомиться с многочисленными материалами на MSDN (например, msdn.microsoft.com/msdnmag/issues/
0500/wmiover/wmiover.asp
).

Еще раз о провайдерах WMI

Вместе с Windows 2000 поставляется целый ряд предустановленных провайдеров WMI. Они значительно скрасят будни системных администраторов, позволяя легко создавать программы и сценарии для управления корпоративными информационными системами. Остановимся вкратце на каждом из них:

  • провайдер Win32 — предоставляет информацию об операционной системе, компьютере, периферийных устройствах, файловой системе и средствах защиты;
  • провайдер WDM — предоставляет низкоуровневую информацию о драйверах устройств (ввода/вывода, хранения информации, сетевых интерфейсов и пр.), соответствующих стандарту WDM (Windows Driver Manager);
  • провайдер журнала событий — позволяет считывать информацию из системного журнала событий Windows NT/2000, конфигурировать его параметры, а также автоматизировать процесс резервного копирования файлов журнала. События WMI могут генерироваться в ответ на занесение тех или иных записей в системный журнал;
  • провайдер системного реестра — позволяет создавать, удалять и редактировать ключи системного реестра. События WMI могут генерироваться в ответ на изменение тех или иных ключей;
  • провайдер учета производительности — открывает доступ к низкоуровневым счетчикам активности системы, информация от которых используется для вычисления интегральных показателей производительности, отображаемых в системном мониторе Windows NT;
  • провайдер службы каталога — выступает в виде шлюза для доступа ко всем видам информации, хранимой в Active Directory;
  • провайдер службы установки/удаления ПО — позволяет полностью контролировать работу Windows Installer и осуществлять инсталляцию необходимого программного обеспечения посредством WMI;
  • провайдер SNMP — выступает в качестве шлюза при взаимодействии с системами и устройствами, для управления которыми используется протокол SNMP;
  • провайдер представлений — позволяет строить новые агрегированные классы на основе ранее определенных классов WMI.

Указанные выше провайдеры предоставляют системным администраторам доступ к базовой функциональности компонентов информационных систем, функционирующих на платформе Win32. Кроме них, существует целый ряд других провайдеров, созданных как самой компанией Microsoft, так и сторонними разработчиками. Они, как правило, открывают доступ к управлению соответствующими серверными приложениями через интерфейс WMI.

Среди дополнительных провайдеров WMI от Microsoft хотелось бы упомянуть провайдер для ее почтовой системы MS Exchange. В числе сторонних разработчиков, поддерживающих WMI, следует назвать, прежде всего, таких гигантов, как IBM, Hewlett-Packard, Tivoli и Intel. Первые три компании создали провайдеры WMI для удаленного администрирования своих пакетов управления корпоративными информационными системами. Intel применила WMI в средствах удаленного управления материнскими платами собственного производства (модели JN440BX, MP440BX, KU440EX, WS440BX, BL440ZX). С помощью соответствующего провайдера приложения могут получать оповещения о параметрах состояния этих плат (температуре, напряжении электропитания и пр.) и реагировать на их изменения.

Для популяризации WMI компания Microsoft разработала WMI SDK, который можно бесплатно загрузить с узла MSDN. Используя этот комплект, разработчики могут создавать провайдеры WMI для своих продуктов, а администраторы получат необходимые инструменты и документацию для написания сценариев.

Использование WMI API

Прежде чем перейти к обсуждению практического использования WMI, остановимся вкратце на составных частях WMI API. В целом, они повторяют структуру всех объектных моделей.

  • свойства — содержат описательную информацию об экземплярах классов WMI;
  • методы — действия, осуществляемые с помощью экземпляров классов WMI;
  • события — это особые ситуации, о наступлении которых могут оповещаться процессы и приложения. Такими ситуациями могут быть, например, вызов системной службы, внесение изменений в реестр и пр.;
  • ассоциации — описания взаимоотношений между связанными объектами информационной среды (например, параллельный порт компьютера и подключенный к нему принтер могут рассматриваться не только как отдельные управляемые объекты, но и в рамках одной ассоциации). Это достаточно мощная особенность WMI, позволяющая просматривать и анализировать управленческую информацию о связанных объектах в едином ключе.

В соответствии с идеологией Microsoft, главный инструмент администратора — сценарий Windows Scripting Host, а синтаксис VBScript наиболее удобен для работы с разветвленной объектной моделью WMI. Следующий сценарий позволяет получить перечень ресурсов локального компьютера — запущенных системных служб и активных процессов:

set WMI = GetObject(“WinMgmts:”)
‘ описания служб локальной машины
set objs = WMI.InstancesOf(“Win32_Service”)
for each obj in objs
      if IsNull(obj.Description) then
           WScript.Echo “NAME = “ + obj.Name
      else
           WScript.Echo “DESCRIPTION = “ + obj.Description
     end if
next
‘ описания активных процессов
set objs = WMI.InstancesOf(“Win32_Process”)
for each obj in objs
      if IsNull(obj.Description) then
           WScript.Echo “NAME = “ + obj.Name
      else
           WScript.Echo “DESCRIPTION = “ + obj.Description
     end if
next

Следует отметить, что приведенный выше сценарий работает с локальной машиной (т. е. с той, с которой он запущен). Однако этот код может быть легко переделан для мониторинга удаленной машины. Для этого достаточно лишь модифицировать первую строчку программы:

set WMI = GetObject(“WinMgmts://REMOTE_HOST”)
‘ REMOTE_HOST — имя удаленной машины

Естественно, для выполнения любых дистанционных операций необходимо иметь соответствующие привилегии. При соблюдении этого условия WMI открывает перед администратором безграничные возможности. Например, с помощью следующего сценария можно перезапустить удаленный компьютер:

‘ REMOTE_HOST — имя удаленной машины
Set OpSysSet = GetObject(“winmgmts:” & _
“itc_drupal_impersonationLevel=impersonate,” & _
“(RemoteShutdown)//REMOTE_HOST).ExecQuery” & _
“(“select * from Win32_OperatingSystem ” & _
“where Primary=true”)
for each OpSys in OpSysSet
     OpSys.Reboot()
Next

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