Часть 3

В двух предыдущих частях статьи я рассказывал об управлении сервером Exchange 2000 при помощи консоли Microsoft Management Console (MMC), его взаимодействии с Active Directory (AD) и о том, как осуществляется контроль функционирования, сбор и распространение информации о состоянии системы. Все описанные возможности основаны на использовании набора интерфейсов программирования. Раньше эти интерфейсы не сопровождались соответствующей документацией, и администраторам приходилось работать только со стандартными средствами управления ОС. Сейчас политика Microsoft изменилась, и Exchange 2000 поставляется с набором документированных интерфейсов. Если кому-то не по душе стандартные консоли управления из пакета Exchange 2000, теперь можно создавать собственные программы для управления серверами. Для небольших сетей это не очень важно, но у крупных компаний появилась возможность гибкой интеграции серверов Exchange в свою систему администрирования.

В заключительной статье цикла я представлю два ключевых интерфейса: инструментарии управления Windows (WMI) и Collaboration Data Objects for Exchange Management (CDOEXM).

Предварительное знакомство с новыми интерфейсами

Программа администрирования сервера Exchange 5.5 поддерживает минимальный набор интерфейсов, используемый для импорта и экспорта информации базы данных каталога. Библиотеки Directory API (DAPI) и Messaging API (MAPI) позволяют получить доступ к объектам каталога сервера Exchange из программ, а при помощи набора Microsoft Exchange Development Kit (EDK) разработчики могут создавать коннекторы к факс-серверам и почтовым системам других типов, например Lotus Notes. Это очень мощные и эффективные, но сложные в освоении интерфейсы.

Интерфейсы к Exchange 2000 могут использоваться и языками программирования (например, Visual Basic, VB), и языками сценариев (например, VBScript). Они предоставляют доступ к данным при помощи браузеров. В состав новых интерфейсов входят не только основанные на COM объекты управления, работающие с моделью WMI, но и набор объектов CDO для управления Exchange (CDOEXM), который значительно облегчает программирование задач администрирования.

Базой архитектуры управления Exchange 2000 служат интерфейсы Active Directory Service Interfaces (ADSI), OLE DB и WMI. Exchange 2000 может получить доступ к объектам AD (таким, как пользователи, контакты, группы и др.) при помощи интерфейса ADSI. OLE DB обеспечивает доступ к хранилищу. WMI предоставляет набор интерфейсов к приложениям и аппаратным базовым компонентам системы.

В названии CDOEXM не случайно содержится ссылка на Collaboration Data Objects (CDO). До появления Exchange 2000 технология CDO служила для упрощения процесса программной обработки таких объектов, как почтовые ящики и сообщения. В Exchange 2000 программисты манипулируют сложными объектами управления (например, почтовыми ящиками и их свойствами) при помощи CDOEXM. В конечном счете программисты получили возможность создавать бесплатные или коммерческие продукты для управления Exchange 2000 либо интегрировать Exchange в имеющиеся средства управления.

Использовать ли эти возможности, зависит от ситуации. С одной стороны, в Exchange 2000 система управления сложнее, чем в Exchange 5.5. С другой - новая архитектура управления может быть достаточно простой, при желании можно задействовать только стандартные средства. Для управления сервером с небольшим числом почтовых ящиков вряд ли потребуется обращаться к помощи WMI и CDOEXM. Главное, что есть возможность гибкого управления серверами.

Стандарты совместимости

Независимые компании могут поставлять свои изделия с логотипом Windows 2000 только в том случае, если они удовлетворяют стандартам Microsoft. Это значит, что программы должны устанавливаться при помощи службы Windows Installer, для администрирования должна использоваться MMC, а для вывода данных управления - WMI.

Поскольку Exchange 2000 разработан Microsoft, он, естественно, отвечает этим условиям. Соответствие Exchan-ge 2000 первым двум требованиям рассматривалось в двух предыдущих статьях: он устанавливается при помощи новой процедуры Windows Installer, основанной на COM, а для администрирования используются программы-оснастки MMC.

Третье условие тоже выполняется, так как Exchange 2000 передает данные управления при помощи WMI и предоставляет программируемый интерфейс (т. е. CDOEXM). Вдобавок, Exchange 2000 содержит обновленные версии программ, позволяющих контролировать состояние сервера, и переработанную версию Message Trac-king Center.

Сбор данных

Появление новых интерфейсов управления данными в Exchange 2000 вовсе не означает, что следует отказаться от использования программ независимых разработчиков, как в случае с Exchange 5.5. Напротив, можно обновить эти программы версиями, использующими WMI и CDOEXM. Сервер Exchange всегда привлекал внимание независимых разработчиков, создающих специализированные приложения, такие, как AppManager (фирма NetIQ) или PATROL (фирма BMC Software). Как правило, такие приложения собирают данные из нескольких источников (включая счетчики Performance Monitor и журнал Sys-tem), помещают их в хранилища, такие, как Microsoft SQL, и используют собственный инструментарий для анализа данных.

Экран 1. Сообщение с результатами дефрагментации.

Журналы событий служат прекрасным источником информации для таких программ управления и контроля. Например, на Экране 1 показано сообщение о событии с ID 1221, где приведены результаты дефрагментации хранилища почтовых ящиков. Эта информация помогает контролировать размеры почтовых ящиков (см. врезку «Потеря сообщений»). Кроме данных, пригодных для анализа состояния системы, журналы событий хранят информацию о критических ошибках, например таких, как известная ошибка базы данных - 1018. Эта ошибка является сигналом бедствия для любого администратора Exchange. Она указывает на проблемы взаимодействия дисковой подсистемы и хранящейся на ней базы данных.

Системный мониторинг - важнейший элемент процесса управления Exchange 2000, а CDOEXM обеспечивает легкий доступ к информации управления, которая может служить основой для других категорий программ-анализаторов. Можно анализировать производительность сервера на основе данных, полученных в процессе его работы. Для крупных организаций особенно важен анализ данных реестра и AD. Разобраться в содержании реестра достаточно сложно, смысл многих параметров понятен лишь узкому кругу специалистов Microsoft. Некоторые программные пакеты при установке тоже могут записывать данные в реестр компьютера с Exchange 2000. Два сервера могут выглядеть совершенно одинаково с точки зрения установленных на них программ, но тщательное сравнение конфигурационных данных выявляет их различия. При работе с такими продуктами, как Ecora Application Server (поддерживающим также сервер Exchange 5.5), становится очевидна целесообразность полного документирования всех настроек на сервере. Хотя CDOEXM упрощает задачу документирования настроек сервера, некоторые параметры реестра так и остаются в неизвестности.

WMI - это версия архитектуры Web-Based Enterprise Management (WBEM), реализованная Microsoft в соответствии с требованиями организации Distributed Management Task Force (DMTF), которая принимает и унифицирует стандарты управления и контроля для различных платформ. Информацию о WBEM и DMTF можно получить по адресу: http://www.dmtf.org. WBEM обеспечивает единый метод доступа к контролируемой информации (например, к состоянию системы, использованию памяти, списку установленных и выполняющихся приложений, подключенным клиентам) с серверов различных типов.

Назначение WMI - сформировать такую инфраструктуру управления, которая позволит отказаться от использования специфичных агентов управления для каждого приложения. Это позволит осуществлять наблюдение за системой, а также отдельными приложениями при помощи утилит управления, получающих данные от провайдеров WMI. Приложения регистрируются в качестве провайдеров WMI во время установки на сервер и используют вызовы WMI для передачи информации управления. Провайдеры предоставляют постоянную схему доступа и API, к которым приложения получают доступ при помощи стандартных запросов, методов и событий. Приложения (например, MMC или браузер) используют WMI API, основанные на COM, для доступа к хранилищу информации управления Common Info-rmation Model (CIM). Далее CIM указывает приложениям, где хранятся соответствующие данные. CIM является схемой, определяющей управляемые объекты, в том числе объекты приложений (например, объекты сервера Exchange) и аппаратные устройства (например, диски). WMI расширяет модель WBEM при помощи следующих элементов.

  • Набор расширений, названных схемой Win32, которые WMI добавляет в CIM. Схема Win32 описывает объекты, актуальные для приложений Windows (например, службы).
  • Служба Windows 2000 (т. е. служба WMI - winmgmt.exe), которая управляет хранилищем CIM. Служба отвечает на запросы приложений на чтение данных из хранилища или от провайдера WMI.
  • API, построенного на COM (т. е. WMI API) и компонентах, позволяющих приложениям создавать код для доступа к хранилищу CIM и службе WMI.

Exchange 2000 использует WMI для контроля различных параметров сервера, включая количество свободного пространства на диске. На Рисунке 1 показана архитектура WMI. Ее центром является WMI API, который взаимодействует с менеджером объектов CIM и хранилищем CIM для получения доступа к зарегистрированным WMI-провайдерам сервера.

Рисунок 1. Архитектура WMI.

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

WMI-провайдеры

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

  • провайдер службы каталога обеспечивает доступ к AD;
  • провайдер журнала событий обеспечивает доступ к данным журналов событий;
  • провайдер монитора производительности обеспечивает доступ к данным управляемых объектов, связанных с производительностью;
  • провайдер реестра обеспечивает доступ к элементам реестра;
  • провайдер безопасности обеспечивает доступ к установкам безопасности файлов, папок и общих файлов;
  • провайдер Win32 обеспечивает доступ к базе служб Windows 2000;
  • провайдер Windows Driver Model (WDM) обеспечивает доступ к информации об аппаратуре.

Эти провайдеры работают с данными, принадлежащими конкретным приложениям. Кроме перечисленных, Windows 2000 содержит провайдер предоставления (View), консолидирующий информацию от многих провайдеров в единую точку доступа к управляющим данным. В Windows 2000 доступ к данным WMI разрешен только администраторам. Если обычный пользователь пытается обратиться к данным, то в журнал приложений (Application) записывается событие следующего вида:

Event ID 1000 Source Perflib
Description:
Access to performance data was denied
 to TRedmond as attempted from
F:WINNTSystem32WBEMWinMgmt.exe 

(«Доступ к данным о производительности был запрещен пользователю Tredmond при попытке обращения из F:WINNTSystem32WBEMWinMgmt.exe».)

На Рисунке 1 изображены провайдеры WMI, в том числе провайдеры журнала событий (Event Log) и реестра (Registry), а также три провайдера Exchange 2000.

  • ExchangeQueue. Этот провайдер используется Exchange 2000 для сбора информации о протоколе (например, SMTP), управляющем очередью, для подсчета сообщений в очереди, вывода даты и времени следующего соединения по расписанию, вывода размера данных очереди в байтах.
  • ExchangeRoutingTable. Этот провайдер используется для занесения в таблицу маршрутизации данных о состоянии локального сервера Exchange и коннекторов, установленных на локальном сервере. В свою очередь, из таблицы маршрутизации может быть получена информация о состоянии других серверов и коннекторов компании.
  • ExchangeCluster. Этот провайдер используется Exchange 2000 только при работе с кластерами и позволяет отслеживать состав кластерных групп, ресурсы и текущее состояние.

В состав этих трех провайдеров включены пять новых классов WMI.

  • ExchangeLink. Этот класс предоставляет информацию о состоянии и свойствах связи. Свойства включают такие данные, как число повторных передач, общий размер сообщений, ожидающих отправки, и текущее состояние связи (т. е. функционирует или недоступен). Эта информация используется механизмом вычисления маршрутов SMTP для коррекции таблицы маршрутизации в зависимости от текущего состояния каналов связи.
  • ExchangeQueue. Этот класс предоставляет подробную информацию об очередях передачи сообщений. Например, о протоколе, использующем очередь (т. е. X.400 или SMTP) и об имени канала связи, через который будут отправляться сообщения из очереди. Программа (например, консоль ESM), использующая этот класс, может пересчитать все сообщения в очереди.
  • ExchangeConnectorState. Этот класс предоставляет информацию о состоянии коннектора. Прежде всего, нужно знать, функционирует ли коннектор вообще. В Таблице 1 перечислена и другая информация, доступная этому классу, в частности хранящееся в AD имя DN для коннектора. Программы, подобные ESM, используют DN для получения из конфигурационного контейнера сервера Exchange информации о свойствах коннектора.
  • ExchangeServerState. Этот класс предоставляет информацию о состоянии подсистем сервера: например, о дисковой памяти, состоянии системы и служб. ESM весьма интенсивно использует этот класс для наблюдения за состоянием серверов.
  • ExchangeClusterResource. Этот класс предоставляет информацию (только при работе Exchange в кластере) о состоянии конкретного кластерного ресурса и имени виртуального (EVS) сервера Exchange, использующего данный ресурс.

Пространство имен WMI в папке ootcimv2applicationsexchange определяет пять классов. Программы управления взаимодействуют с данными Exchange 2000 прежде всего через классы, а не провайдеры. Каждый класс курирует отдельную часть Exchange 2000 и использует тот же самый набор стандартных API, что и Exchange. Например, провайдер Ex-changeRoutingTable функционирует поверх Routing API и создает классы ExchangeServerState и ExchangeCon-nectorState. Routing API позволяет Ex-change 2000 контролировать передачу сообщений, основанную на новом механизме маршрутизации SMTP. Провайдер ExchangeQueue функционирует поверх Queue API, взаимодействует как с MTA, так и с механизмом маршрутизации SMTP, и создает классы ExchangeLink и ExchangeQueue. Сообщение помещается в очередь после того, как обработчик SMTP выбрал наилучший маршрут для передачи. Queue API предоставляет для Exchan-ge 2000 интерфейс к таким очередям. Провайдер ExchangeCluster функционирует поверх Cluster API и создает класс ExchangeClusterResource. Разумеется, этот интерфейс доступен только при установке Exchange 2000 в кластер.

В Таблице 1 приведены свойства класса ExchangeConnectorState в качестве примера данных для классов WMI для Exchange 2000. Название каждого свойства отражает назначение связанных с ним данных. Эта информация используется консолью ESM при отображении статуса всех известных системе коннекторов.

Windows Scripting Host (WSH) и другие подобные средства используют классы для автоматизации операций. Например, следующий фрагмент кода возвращает из коллекции, известной локальной системе, список всех компьютеров с установленными на них серверами Exchange и номерами версий Exchange.

Const ComputerName = «LocalHost»
Const WMINameSpace = «root/cimv2/
	applications/exchange»
Const WMIInstance = «Exchange
	ServerState»
Set ExchangeList = GetObject
(«winmgts:{impersonationLevel=
impersonate}!//» & - Computer
Name & «/» & - WMINameSpace)
.InstancesOf (WMIInstance)
For each ExchangeServer in
ExchangeList Wscript.Echo 
«Name: « & ExchangeServer.Name
Wscript.Echo «Version: « &
ExchangeServer.Version
Next

Набор разработки программ SDK для Exchange 2000 содержит полное описание провайдеров, классов и примеры их использования.

Объединяй и побеждай: CDOEXM

CDOEXM входит в семейство интерфейсов (ADSI, OLE DB, ADO и CDO), используемых для получения программного доступа к структуре данных Exchange 2000.

  • ADSI. Этот интерфейс используется для управления объектами AD, включая учетные записи пользователей и группы.
  • CDO. Этот интерфейс используется для управления составными объектами серверов Exchange, такими, как сообщения и вложения в них.
  • OLE DB. Этот интерфейс используется для программирования хранилища сервера Exchange при помощи таких языков, как C++.
  • ADO. Этот интерфейс используется для программирования хранилища сервера Exchange при помощи таких языков, как VBScript.
  • CDOEXM. Этот интерфейс используется для управления такими объектами сервера Exchange, как почтовые ящики и общие папки.

Один-единственный интерфейс не может использоваться для управления всеми объектами сервера Exchange. Поэтому все интерфейсы работают совместно, хотя многие задачи можно решить при помощи нескольких основных интерфейсов. Например, если требуется создать учетную запись пользователя и соответствующий ему почтовый ящик, то используется ADSI для создания нового объекта и CDOEXM для создания почтового ящика. При выполнении подобных задач основными строительными блоками приложений являются объект CDO.Person и ADSI-объекты - ADS-User, ADSContact, ADSGroup.

CDOEXM обеспечивает программный доступ к почтовым ящикам, общим папкам (включая самый верхний уровень), серверам и группам хранения SG. Это позволяет создавать собственные средства управления, если не устраивают стандартные программы Microsoft. Например, CDOEXM содержит объект Exchan-geServer, свойства которого обеспечивают доступ к информационным параметрам выбранного сервера. В Таблице 2 приведены свойства объекта ExchangeServer.

Нет ничего удивительного в том, что ExchangeServer является центральным объектом CDOEXM. Он служит отправной точкой для многих других операций с Exchange-сервером. Например, при помощи объекта Ex-changeServer.StorageGroups можно получить список групп SG, передать его объекту StorageGroups и изменить такие установки, как режим обновления журналов транзакций (circular logging) или путь, используемый SG для доступа к ним. Следует очень тщательно тестировать код, использующий эти интерфейсы, так как ошибки могут привести к потере работоспособности сервера.

В одной статье невозможно рассмотреть все аспекты совместного использования CDOEXM, WMI, ADO, CDO и других компонентов для создания программ управления и контроля. Я рекомендую собрать максимум информации и примеров программ, затем написать и отладить программы на тестовом сервере и только потом перенести их на рабочий сервер.

Задача контроля и управления сервером Exchange значительно упростилась после выпуска документированных интерфейсов. Но не следует думать, что можно будет сразу создавать программы, использующие провайдеры Exchange 2000 WMI и CDOEXM. Придется уделить время изучению стандартных средств управления. Для большинства из нас новые возможности программирования Exchange интересны, но необязательны. В конце концов, не все же пишут программы для Exchange. Большинство только наблюдает и с радостью использует готовые разработки. И тем не менее нужно знать о существовании таких интерфейсов, разбираться в них хотя бы для того, чтобы убедиться, что купленные программы независимых производителей поддерживают эти интерфейсы.

(Окончание.)

Тони Редмонд - редактор Windows 2000 Magazine, старший технический редактор выпусков Exchange Administrator, вице-президент в Compaq Global Services. Связаться с ним можно по адресу: exchguru@win2000mag.com.


Потеря сообщений

Сервер Exchange 2000 записывает информацию в файлы журналов и, в частности, в журнал Application, особенно если уровень регистрации событий выше минимального. Размер файла журнала Application по умолчанию равен 512 Кбайт, а этого явно недостаточно для контроля передачи сообщений системы Exchange среднего размера. Если не увеличить размер файла журнала, он станет слишком быстро переполняться и записи о важных событиях будут пропадать. Чтобы этого избежать, рекомендуется увеличить размер файла до 4 Мбайт (для серверов с числом почтовых ящиков 500) или более (для серверов с числом почтовых ящиков более 500). Размер журнала событий можно изменить в диалоговом окне Properties.

назад


Таблица 1. Свойства класса ExchangeConnectorState.
СвойствоУказывает на
DNDN имя коннектора
NameИмя коннектора, используемое для вывода в программах управления. Может отличаться от имени DN, отражает назначение коннектора.
GUIDУникальный глобальный идентификатор ID (GUID), используется AD для идентификации объекта "коннектор".
GroupDNDN имя группы маршрутизации, к которой принадлежит коннектор.
IsUPТекущее состояние коннектора.

назад


Таблица 2. ExchangeServer. Свойства объекта.
СвойствоУказывает на
Name*Имя сервера Exchange
ExchangeVersion*Версия сервера Exchange (включая пакет исправлений)
StorageGroups*Список URL-адресов, указывающих на активные группы хранения SG на сервере.
MessageTrackingEnabledФлаг. Указывает, включена ли на сервере система контроля передачи сообщений.
SubjectLoggingEnabledФлаг. Указывает, разрешен ли контроль и просмотр темы сообщений администратору.
DaysBeforeLogFileRemovalКоличество дней, в течение которых сервер хранит файл журнала переданных сообщений.
ServerTypeФлаг. Указывает, является Exchange сервером front-end или back-end. (0=front end, 1=back end). Сервер front-end получает запросы от клиентов и proxy-серверов и передает их для обработки на сервер back-end.
DirectoryServer*Флаг. Указывает, является ли компьютер с установленным сервером Exchange контроллером домена.
GetInterface*Указывает интерфейс к объекту.
DataSource*IDataSource интерфейс к объекту
Fields*Коллекция полей объекта
*Только чтение. Разрешено лишь чтение, поскольку некоторые свойства (например, Fields) служат только для обеспечения доступа к данным.

Поделитесь материалом с коллегами и друзьями