Мониторинг Active Directory

Цель лекции: Осветить процесс мониторинга Active Directory.

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

Отдельного инструмента или пакета программ, предназначенного для мониторинга Active Directory, не существует, поэтому мониторинг службы каталога является комбинацией задач, имеющих общую цель [ 4 ] , [ 13 ] - измерение текущей характеристики некоторого ключевого индикатора (занимаемый объем диска, степень использования процессора, период работоспособного состояния службы и т. д.) по сравнению с известным состоянием (отправная точка)^{1Существуют наборы инструментов, которые могут соединить мониторинг этих ключевых индикаторов в один легко управляемый интерфейс, и для больших организаций наличие таких средств очень существенно, но они дороги, сложны и требуют много ресурсов.}.

Причины проведения мониторинга, реализуемые преимущества и сопутствующие затраты

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

Мониторинг дает возможность поддерживать соглашение об уровне сервиса (Service-Level Agreement, SLA) с пользователем сети. В контексте Active Directory соглашение SLA между ИТ-отделом и сообществом пользователей может содержать такие параметры, как максимально приемлемый уровень времени простоя системы, время входа в систему и время получения ответа на справочный запрос.

Еще одна причина для проведения мониторинга Active Directory состоит в том, что необходимо отслеживать следующие изменения инфраструктуры^{2Возможно, эта информация не поможет предотвратить возникновение сегодняшней ошибки, но она позволит получить ценные данные, с которыми можно строить планы по дальнейшему развитию инфраструктуры компании.} [ 13 ] :

• увеличение размера базы данных Active Directory;
• функционирование серверов глобального каталога (GC) в интерактивном режиме;
• время репликации между географически разнесенными контроллерами доменов.

Преимущества, которые можно получать от проведения мониторинга Active Directory, включают следующие компоненты [ 13 ] :

• способность поддерживать SLA-соглашение с пользователями, избегая простоя службы;
• достижение высокой производительности службы путем устранения "узких мест" в работе, которые иначе нельзя обнаружить;
• снижение административных затрат с помощью профилактических мер в обслуживании системы;
• повышенная компетентность при масштабировании и планировании будущих изменений инфраструктуры в результате глубокого знания компонентов службы, их функциональных возможностей и текущего уровня использования;
• увеличение доброжелательности в отношении ИТ-отдела в результате удовлетворения клиентов.

При всех указанных преимуществах мониторинг Active Directory связан с затратами, которые необходимы для его эффективной реализации [ 13 ]

• Для проектирования, развертывания и управления системой мониторинга нужны соответствующие людские ресурсы (человеко-часы), требующие оплаты.
• На приобретение необходимых средств управления, на обучение и на аппаратные средства, которые предназначены для реализации мониторинга, требуются определенные фонды.
• Часть пропускной способности сети будет задействована для мониторинга Active Directory на всех контроллерах домена предприятия.
• Для выполнения приложений-агентов на целевых серверах и на компьютере, являющемся центральным пультом мониторинга, используются память и ресурсы процессора.

Стоит отметить, что стоимость мониторинга быстро повышается при внедрении глобального мониторинга предприятия типа комплекса Microsoft Operations Manager (MOM 2005 или его современный аналог - MSCOM 2007). Инструментальные средства MOM хотя и расширяют возможности мониторинга, но достаточно дороги, требуют обучения оператора и расходуют большее количество системных ресурсов в отличие от мониторинговых решений Windows Server 2003, которые являются проверенными, интегрированными и поддерживаемыми продуктами, но с базовыми возможностями мониторинга.

Уровень мониторинга будет зависеть от результатов анализа преимуществ и затрат. В любом случае, стоимость ресурсов, которые будут потрачены на систему мониторинга, не должна превышать ожидаемую от мониторинга экономию. По этой причине большие организации находят более рентабельным вкладывать капитал в комплексные решения по управлению предприятием. Для менее крупных организаций более оправдано использовать инструментальные средства мониторинга, встроенные в систему Windows Server 2003.

Процесс мониторинга Active Directory

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

Ниже приводится схема процесса мониторинга службы Active Directory высокого уровня [ 13 ] .

1. Определить, какой из индикаторов функционирования службы необходимо отслеживать.
2. Выполнить мониторинг индикаторов функционирования службы, чтобы установить и задокументировать базовый (нормальный) уровень.
3. Определить пороги для этих индикаторов функционирования, то есть указать, при каком уровне индикатора необходимо принимать меры, предотвращающие расстройство функционирования службы.
4. Спроектировать необходимую аварийную систему, предназначенную для обработки событий при достижении порогового уровня. Аварийная система должна включать в себя следующие компоненты:
   • уведомления оператора;
   • автоматические действия, если они возможны;
   • действия, инициируемые оператором.
5. Спроектировать систему создания отчета, фиксирующую историю состояния Active Directory.
6. Реализовать решение, которое будет измерять выбранные ключевые индикаторы в соответствии с расписанием, отражающим изменения данных индикаторов и их воздействие на состояние Active Directory.