вторник, 12 июня 2012 г.

Полностью виртуальная инфраструктура в Hyper-V.


Введение.

В этой небольшой статье хотелось бы рассказать про свой опыт использования виртуализации инфраструктуры на базе Hyper-V из состава Windows Server 2008 R2. Статья будет также применима и к Windows Server 2008 (R1). А если конкретно, то хотелось бы рассказать про проблему полной виртуализации инфраструктуры. Под полной виртуальной инфраструктурой я подразумеваю среду, где Hyper-V развернут в конфигурации Failover Cluster и все серверы, включая контроллеры доменов, виртуализируется.

Чтобы было более понятно, рассмотрим следующую инфраструктуру. Есть группа хостов с Windows Server 2008 R2. Вы из этих хостов собрали кластер и хотите перенести всю вашу серверную инфраструктуру из физического состояния в виртуальное. Но встает дилемма. Среди физических серверов, которые вы хотите перенести в среду виртуализации, есть контроллеры доменов. Тут вы вспоминаете, что кластер зависит от службы каталогов и получается, что вам нельзя создавать взаимозависимость: кластер виртуализации от службы каталогов и наоборот.

Вообще данная проблема не нова. Но я ни разу не встречал описание решения данной проблемы, поэтому все-таки надумал поделиться своим опытом (пока это не сделал кто-нибудь другой:)). Возможно данное решение уже где-то описано и просто-напросто я не правильно или невнимательно искал.

Решение.


Failover-кластеру без службы каталогов очень плохо. Хотя бы по той причине, что служба каталогов используется для аутентификации узлов в кластере.

Вернемся к нашей инфраструктуре. Мы все-таки развернули кластер Hyper-V, перенесли все серверы, в том числе и контроллеры доменов, в виртуальную среду. Физические серверы либо задействовали в качестве узлов кластера, либо полностью вывели из эксплуатации. Виртуальные машины разместили на Cluster Shared Volume (CSV), дабы задействовать замечательную функцию Live Migration. Получилось следующее:



В один прекрасный момент выключается электричество, а вместе с ним через некоторое время выключаются ваши физические хосты и виртуальные машины.

Включают электричество, хосты Hyper-V начинают грузиться, а вот виртуальные машины не стартуют. Это происходит по следующей причине. Виртуальные машины являются ресурсами кластера, служба ClusterSvc должна, в соответствии с зависимостью ресурсов, поочередно их поднять (перевести в online-режим). Но служба кластеров сама зависит от службы каталогов, контроллеры доменов которой являются ресурсами кластера. Получается замкнутый круг.

Есть традиционные способы решения данной проблемы:

Использовать хотя бы один физический сервер для контроллеров доменов. Согласитесь, что при текущей производительности серверов, не совсем целесообразно потратить на контроллер доменов 5-10 тыс. долларов (с последующей утилизацией раз в 3-5 лет). Для инфраструктур, характеризующих себя как централизованные и средние по размерам, хотелось бы максимально утилизировать вычислительные ресурсы, абстрагироваться от аппаратного обеспечения, и все это сделать с минимальными затратами. Децентрализованные инфраструктуры могут такой проблемы не ощущать.

Использовать хост Hyper-V как контроллер доменов. То есть, развертываем роль ADDS на одном из узлов Hyper-V. Это уже лучше, чем первый случай, но все же есть некоторые проблемы:

  • Проблема безопасности и проблема делегирования полномочий. Если развернуть RWDC на Hyper-V хосте, то трудно будет ограничить администратора среды виртуализации от возможности воздействовать на службу каталогов. Сразу скажу, что здесь можно долго спорить на эту тему, поскольку можно сказать, что если есть физический доступ к хосту, то без проблем можно получить доступ к виртуальным машинам. И это верно. Поэтому оставлю тему безопасности за рамками данной статьи. Возьмем за веру, что проблема с безопасностью все же есть в этом случае. Также можно установить RODC и это решит некоторые проблемы с безопасностью, но возникают другие проблемы.  Update: чуть позже накопал, что RODC не поддерживается на узлах кластера http://support.microsoft.com/kb/281662/en-us

  • Проблемы с решением и локализацией проблем. Если вы совмещаете несколько ролей, то не всегда можно быстро определить причину возникновения проблемы в такой системе, а значит и время решения проблемы увеличивается.

  • Проблема с лицензированием. Конечно, с лицензированием проблем здесь нет, но вот у вас проблемы появятся. Если хост Hyper-V выполняет какую-либо роль кроме виртуализации, то вы лишаетесь возможности в полной мере покрыть хостовой лицензией запущенные экземпляры виртуальных машин. Например, в случае с Standard-лицензией вообще лишаетесь возможности использовать хостовую лицензию для лицензирования одной запущенной виртуальной машины, а в случае с Enterprise - одной. То есть с Enterprise-лицензией можете лицензировать запуск не 4х виртуальных машин, а только трех. В оригинале это звучит так: 
* Если запущено максимально разрешенное количество экземпляров, экземпляр в физической операционной среде может использоваться только для запуска программного обеспечения виртуализации устройств, обеспечения служб виртуализации устройств или для запуска программного обеспечения для управления операционными средами и их обслуживания на лицензированном сервере.

А теперь, как я решал данную проблему.


Если есть взаимозависимость кластера от службы каталогов и службы каталогов от кластера, то нужно эту зависимость убрать. Вы просто не делаете виртуальные машины (с контроллерами доменов) ресурсами кластера. А если сделали это раньше, то удаляете соответствующие ресурсы из кластера и, при необходимости, переносите файлы виртуальных машин на локальные диски сервера.

Тем самым вы решаете проблему взаимозависимости. Теперь контроллеры доменов живут в виртуальных машинах и эти виртуальные машины не являются ресурсами кластера. При отключении электричества все прекрасно стартует.

Правда в этом случае мы привязываем контроллер домена к конкретному хосту и он (контроллер домена) не может быть перемещен на другой хост с помощью Quick Migration или Live Migration (хотя может быть перемещен другими способами). Но это не беда. Высокая доступность контроллеров доменов достигается совершенно другим способом – избыточностью. На необходимое количество контроллеров доменов могут повлиять многие факторы, здесь мы их обсуждать не будем.

Некоторые рекомендации (и даже требования):

  1. Создавайте виртуальные машины с контроллерами доменов на дисках, не являющихся кластерными ресурсами. Это могут быть как локальные диски (DAS), так и диски с СХД.
  2. Режим запуска виртуальных машин: Always Automatically Turn On The Virtual Machine или Automatically Turn On The Virtual Machine If It Was Running When The Physical Server Was Stopped
  3. Для службы кластеров (ClusterSvc) необходимо произвести настройки восстановления. Те, что на вкладке «Восстановление» свойств службы ClusterSvc оснастки Services.msc. Для всех сбоев необходимо указать перезапуск службы. Не могу сказать какие конкретно значения для «Перезапуск служб через:» вам подойдут, необходимо подбирать их индивидуально. Я использовал 3 минуты.
  4. Сократите интервал отображения меню восстановления. Настроить можно с помощью апплета «Система» панели управления.

На самом деле я слукавил, когда чуть выше сказал, что все прекрасно стартует. Не совсем. Может возникнуть дополнительная проблема.

Проблема №2.


Дело в том, что есть еще одна взаимозависимость: служба каталогов от DNS и DNS от службы каталогов.



Возникает она по следующей причине. Контроллер домена, при старте, пытается произвести репликацию своих контекстов именования (это при условии, что контроллер в лесу не один): пока не произведет репликацию, не будет выполнять свои функции. Служба DNS, желая при старте работать с самыми актуальными данными, откладывает загрузку интегрированных в AD зон, до момента, когда служба каталогов реплицирует данные и оповестит об этом службу DNS. Репликация AD, как известно, зависит от DNS: контроллер домена пытается получить IP-адреса своих партнеров по репликации с помощью DNS. А DNS в это время не работает, поскольку ждет AD. AD ждет DNS, DNS ждет AD. В свою очередь от DNS также зависит кластер и аутентификация. Через какое-то время служба каталогов все-таки даст добро службе DNS и та загрузит зоны. Этот timeout зависит от количества разделов, которые обслуживает контроллер доменов и примерно составляет 20 минут для 5 разделов (для контроллеров с 2008 R2 я наблюдал намного меньшую задержку – 5 минут).

20 минут для кого-то могут быть вполне допустимы, а для кого-то нет. Попробуем решить эту проблему.

Способы:

  1. Использовать в качестве DNS сервера сервер с другой площадки. Скорее всего, в этом случае у вас не должно возникнуть и первой проблемы. 
  2. Установить дополнительный физический сервер с ролью DNS. Этот сервер будет обслуживать вторичную зону для _msdcs корневого домена и доменную зону локального домена (главная задача разрешить DSAGUID партнера по репликации в FQDN и FQDN в IP-адрес) Этот способ конечно не подходит. Мы вернулись опять к проблеме с физическим сервером. В этом случае проще сразу развернуть физический контроллер доменов.
  3. Установить роль DNS на хосте Hyper-V? Можно, но получаем те же проблемы, что и обсуждались чуть выше.
  4. Отключить начальную репликацию. Это делается установкой значения Repl Perform Initial Synchronizations в 0 для ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Можно, но не рекомендуется. Не рекомендуется хотя бы по той причине, что таким образом происходит попытка решить проблему с существованием в лесу (или домене) нескольких FSMO. Лучше такой способ не использовать.
  5. Использовать не интегрированные в AD зоны (полностью или частично). Знаете да, какие преимущества дает хранение зон в AD? Если вам эти преимущества не нужны, то можете использовать и этот способ.
  6. Сделать так, чтобы имя партнера по репликации разрешалось без участия DNS-сервера. Как это можно сделать? Способов много. Дополнительно стоит сказать, что, начиная с Windows Server 2003 SP1, появилась функция name resolution fallback, на тот случай если не удастся разрешить DSAGUID контроллера домена. Цепочка следующая: GUID -> FQDN -> NETBIOS-имя. То есть, если не удается разрешить CNAME GUID, то происходит попытка разрешить FQDN, если и это не удается сделать, то происходит попытка получить IP по NETBIOS-имени. Поэтому проблему можно решить:
  • Использованием HOSTS-файла. В хост файл можно внести запись о партнере по репликации. Можно добавить как GUID._msdcs.<имя_корневого_домена>, так и FQDN:
<IP-адрес партнера по репликации> <DSA GUID>._mcdcs.<имя корневого домена>
<IP-адрес партнера по репликации> <FQDN партнера по репликации

  • Использованием файла LMHOST. Внести в файл соответствующую запись NETBIOS.
  • Использованием WINS-сервера. Наверное, наиболее предпочтительный способ. 
  • Использованием NETBIOS-широковещания для разрешения имени. Если контроллеры доменов в одном широковещательном домене и Netbios-over-TCPIP не отключен (включен по умолчанию), то с проблемой №2 вы вообще не должны столкнуться.

Внося записи в файлы HOSTS и LMHOSTS, необходимо отдавать себе отчет в том, что такие изменения в скором времени вами забудутся, и, при возникновении проблем с разрешением имен, вы потратите дополнительное время на поиск причины. Поэтому тщательнейшим образом документируйте вносимые изменения. То же самое касается локального изменения реестра: лучше делать изменения централизовано, например, с использованием групповых политик, а иначе концов не сыщете.


Надеюсь, что представленные в этой статье рекомендации, помогут вам.


Полезные ссылки:

Как установить Hyper-V кластер: http://lmgtfy.com/?q=how+to+install+hyper-v+cluster

О первоначальной репликации: http://support.microsoft.com/kb/305476/en-us

О проблеме загрузки DNS-зон: http://support.microsoft.com/kb/2001093/en-us

LMHOSTS: http://support.microsoft.com/kb/101927/en-us

суббота, 2 июня 2012 г.

Windows Events мониторы в Operations Manager 2007 R2

Введение.


Собственно, речь в данной статье пойдет об Unit-мониторах (Unit Monitors), а если точнее, то о Windows Events мониторах.

Мне кажется Windows Event мониторы в SCOM 2007 R2 достаточно интересны и к тому же этот функционал мало где описан. SCOM 2007 R2 дает возможность создать 5 типов мониторов (Рисунок 1), плюс по некоторым типам есть разнообразные настройки, принцип функционирования которых не всегда очевиден.

Рисунок 1.

  

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

Статья была написана для SCOM 2007 R2, но возможно будет актуальна и для SCOM 2012. В процессе написания статьи были выявлены некоторые странности в поведении SCOM, а возможно это ошибки, которые сохранились даже после установки накопительного обновления 4 (CU4).

Общие сведения о мониторах.


Для чего нужен монитор? Монитор настраивается на выполнение определенных проверок компонентов объекта управления, и затем эти проверки отражаются на состоянии монитора, а, в конечном счете, и на состоянии объекта управления. Например, монитор отслеживает появление какого-либо события в журнале событий Windows и, при появлении такого события, переходит в состояние Warning. В нормальное (Health) состояние монитор может быть переведен наступлением другого события, например, ручным сбросом состояния. По такому принципу работают Unit-мониторы. Есть еще Rollup-мониторы, но в этой статье они не обсуждаются.

Сразу опишу события, которые позволяют сбросить состояние монитора в Health. Таких событий три и они одинаковы для всех типов мониторов обсуждаемых в данной статье:

  • Manual – ручной сброс состояния монитора;
  • Timer Reset – сброс по прошествии заданного времени;
  • Windows Event Reset – сброс при возникновении определенного события Windows.
То есть, если у нас монитор находится в состоянии Warning или Critical и возникает одно из перечисленных событий, то состояние монитора переводится в Health. Да, хотелось бы отметить, что Window Event Unit-мониторы, доступные для создания через Operations Console, имеют всего два состояния Success и Failure, но в пакете управления (management pack) Microsoft.Windows.Library доступны также мониторы с тремя состояниями (Health, Warning, Critical). Для того чтобы ими воспользоваться, вам придется использовать другие средства создания мониторов, например, Authoring Console.

В начале статьи можно было увидеть картинку с типами мониторов, которые доступны через Operations Console. Продублирую эту информацию:
  • Simple Event Detection;
  • Repeated Event Detection;
  • Missing Event Detection;
  • Correlated Event Detection;
  • Correlated Missing Event Detection.
А теперь подробнее по каждому монитору.

Simple Event Detection.

Это простой монитор, который реагирует на указанное вами событие в журнале событий Windows (Windows Event Log). Вроде ничего сложного и криминального в работе этого монитора нет.

Рабочий поток (workflow) монитора выглядит примерно так:

Рисунок 2.



Модуль Microsoft.Windows.BaseEventProvider отслеживает события на определенном компьютере в определенном журнале (задается на шаге Event Log Name в визарде), далее данные типа Microsoft.Windows.EventData передаются модулю System.ExpressionFilter, конфигурацию которого вы задаете в мастере создания монитора на шаге Event Expression Unhealthy Event . Фильтр событий задается через типом ExpressionType. Если System.ExpressionFilter получает данные, которые подходят под критерии фильтрации, то на выходе возвращается событие и состояние монитора изменяется на Failure.

Simple Event Monitor со сбросом по событию (Windows Event Reset) имеет дополнительный рабочий поток, такой же что и был изображен ранее, но настроен он на состояние Success.

Repeated Event Detection.

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

У данного монитора есть три режима учета событий (Counting Mode): Trigger on timer, Trigger on count и Trigger on count, sliding.

Что делает Trigger on timer? Он просто отслеживает появление указанных событий в определенный интервал времени и в конце этого интервала отражает состояние монитора.

Trigger on count. Монитор меняет свое состояние на Failure, если в определенном интервале времени было обнаружено заданное число событий.

Trigger on count, sliding. Поведение тоже самое, что и у Trigger on count, но при появлении очередного события интервал времени начинается заново.

Теперь рассмотрим интервалы времени (или отслеживания):
  • Based on items occurence within a time interval. Этот интервал времени начинается свой отсчет при первом появлении события.
  • Based on fixed weekly schedule. Указывается интервал времени на основе дней недели.
  • Based on fixed simple recurring schedule. Указываются фиксированные, рекурсивные промежутки времени.

Теперь по каждой комбинации отдельно.

Trigger on timer и Based on items occurence within a time interval. Этот монитор отслеживает события (количество не важно), при этом отсчет времени начинается при первом появлении события. Состояние монитора отражается только по истечении интервала. На выходе мы получаем последнее событие, а также счетчик событий в этом интервале.
Например (рисунок 3), мы сконфигурировали интервал в 1 минуту на отслеживание события А. В 01:15 генерируется интересующее нас событие. В этот момент начинается отсчет интервала в 1 минуту. По истечении интервала (02:15) происходит изменение состояния монитора в Failure (Warning или Critical). В эту минуту могут генерироваться дополнительные интересующие нас события, тогда монитор будет увеличивать счетчик событий, но интервал увеличиваться не будет. Выводом монитора будут данные о последнем событии и число событий в интервале.

Рисунок 3.

Trigger on timer и Based on fixed weekly schedule. Этот монитор аналогичен Based on items occurence within a time interval, но интервал начинается не при первом появлении события, а в фиксированное время. В качестве времени может быть указан интервал в часах, в днях недели, а также и то и другое. Изменение состояния монитора происходит также в конце интервала, на выходе данные о последнем событии и число этих событий.
Что самое интересное, монитор данного вида изменяет свое состояние на Failure в конце интервала вне зависимости от того были ли желаемые события или нет. Это происходит, потому что модуль System.ConsolidatorCondition, с использованием фиксированных интервалов и отражающий состояние в конце этого интервала, всегда возвращает данные типа System.ConsolidatorData. Если события возникали, то счетчик событий будет больше 0, если нет то 0. Но чем это грозит? Да тем, что монитор изменит свое состояние на всех целевых объектах и состояние этих объектов также, скорее всего, изменится. Скажем если у вас 500 управляемых объектов Windows, и вы нацелили монитор на класс Windows Computer, то все 500 объектов поменяют свое состояние и, возможно, вся консоль будет засыпана Предупреждениями (Alert). Видимо Microsoft забыла вставить дополнительный модуль System.ExpressionFilter с фильтром Count > 0. Позже будет показано, как это нужно было сделать. Такое поведение было замечено на 2007 R2 без CU4 и с CU4.
Trigger on timer и Based on fixed simple recurring schedule. Тоже самое, что и Based on items occurence within a time interval, но интервал начинается фиксировано и циклически, а не при первом появлении заданного события. Есть возможность выровнять интервал по определенной границе. Например, мы настроили монитора на интервал в 1 минуту и выравнивание по 00:00 (рисунок 4).

Рисунок 4.

С этим монитором наблюдаются те же самые проблемы, что и с монитором Based on fixed weekly schedule. Монитор данного вида изменяет свое состояние на Failure в конце интервала вне зависимости от того были ли желаемые события или нет.
Trigger on count и Based on items occurence within a time interval. Это уже другой тип подсчета событий – количественный за определенный промежуток времени. Работает следующим образом. Первое событие начинает отсчет заданного интервала времени, и если в этом интервале времени происходит заданное количество событий, то состояние монитора переходит в Failure. Срабатывание монитора происходит сразу после обнаружения заданного числа событий. На выходе имеем последнее сгенерированное событие (например, третье, если счетчик срабатывания равен трем) и данные об этом последнем событии. Например (Рисунок 5), мы сконфигурировали интервал в 1 минуту и 3 срабатывания события А. В 01:15 сработало первое событие А, начался интервал в 1 минуту, в этом интервале сгенерировалось всего два события, состояние монитора сохранилось на Success. В 02:40 появилось новое событие, которое не принадлежит предыдущему интервалу, поэтому начался новый интервал в 1 минуту. В этом интервале сработало 4 события, но монитор изменил свое состояние уже после третьего события, четвертое событие не учитывается.

Рисунок 5.

Trigger on count и Based on fixed weekly schedule. Также считает количество событий, но в определенном заданном фиксированном интервале времени. Как и с Trigger on timer можно указать дни недели и промежутки времени. Но в отличие от Trigger on timer переводит свое состояние в Failure сразу после фиксирования заданного числа событий, а не в конце интервала. То есть принцип срабатывания такой же что и с Trigger on count и Based on items occurence within a time interval.

Trigger on count и Based on fixed simple recurring schedule. Срабатывание аналогично Trigger on count Based on items occurence within a time interval, но интервал времени не начинается с появлением первого события. Это фиксированные рекурсивные интервалы времени. Их можно также выровнять по определенной временной границе.
Trigger on count, sliding. Для этого монитора есть только один возможный параметр интервала - Based on items occurence within a time interval. Это и верно, поскольку он использует динамические интервалы, то другие два типа фиксированных интервалов абсолютно бессмысленны. Работает он достаточно просто. Берется последнее событие и от него отсчитывается заданный интервал. Если в этот интервал попадает определенное количество событий, то монитор переходит в состояние Failure. На выходе мы получаем данные последнего события в интервале и количество событий во всем интервале.
Например (рисунок 6), мы сконфигурировали монитор, интервал 1 минута, повторяющихся событий А – 3. При возникновении последнего события отсчитывается минутный интервал и высчитывается количество событий. В нашем случае три. Состояние монитора изменяется на Failure.
Рисунок 6.
Реализация.

Примерная реализация Repeated Event мониторов следующая:

Рисунок 7.
Первая часть аналогична Simple Event Detection, но далее, после модуля System.ExpressionFilter, данные передаются модулю System.ConsolidatorCondition, который производит консолидацию событий. Конфигурация System.ConsolidatorCondition передается через свойство Consolidator типа ConsolidatorType. На выходе получаем данные типа System.ConsolidatorData. Стоит заметить, что System.ConsolidatorCondition может работать с данными любого типа (на входе принимает данные типа System.BaseData). Консолидация может происходить просто по данным на входе (после фильтрации модулем System.ExpressionFilter), либо по дополнительной фильтрации в самом модуле System.ConsolidatorCondition. Например, дополнительную фильтрацию для Repeated Event Detection мониторов можно задать кнопкой Edit на странице Repeated Event Configuration (Рисунок 8).

Рисунок 8.

Missing Event Detection.


Этот тип мониторов достаточно простой. Он изменяет свое состояние на Critical, если в заданный интервал времени не было ни одного указанного события.

Монитор можно настроить на два типа фиксированных интервалов: Based on fixed weekly schedule и Based on fixed simple recurring schedule. Предназначение интервалов аналогично интервалам монитора Repeated Event Detection.

Реализация.

Принцип реализации (Рисунок 9):

Рисунок 9.

Модуль Microsoft.Windows.BaseEventProvider отслеживает события в указанном журнале, далее данные типа Microsoft.Windows.EventData передаются модулю System.ExpressionFilter . После модуля Systep.ExpressionFilter, данные передаются в композитный монитор System.MissingConsolidatorCondition, который состоит из нативных (native) модулей System.Consolidator и System.ExpressionFilter. Поскольку данный тип мониторов работает только с фиксированными интервалами отслеживания, то в конце указанного интервала всегда генерируются данные типа System.ConsolidatorData. Если событие происходило, то Count будет больше нуля, если не было – Count равен нулю. Нас как раз интересует отсутствие событий в этом интервале, поэтому для System.ExpressionFilter настроен фильтр «Count Equal 0». Получается, что в конце интервала System.ConsolidatorCondition отдает данные типа System.ConsolidatorData модулю System.Expression, тот, если событий не происходило (Count = 0), отдает данные дальше на выход и происходит изменение состояние монитора на Failure, или же блокирует данные, тогда изменение состояния монитора не происходит.

Помните ошибку в работе монитора Repeated Event Detection? Как раз Microsoft видимо забыл вставить модуль System.ExpressionFilter с фильтром Count > 0.

Correlated Event Detection.


Это, наверное, один из самых непонятных типов мониторов. Correlated Mission Event Detection тоже непонятный, но он основан на Correlated-мониторе, поэтому если рассмотрим его, поймем и Mission.
В чем смысл корреляции в данном случае? Найти связь между двумя типами событий, соотнести эти события по заданным признакам в определенный интервал времени. К примеру, у нас есть приложение, которое почувствовав себя плохо, сначала генерирует событие уровня Warning, а далее известно, что если приложению уж совсем поплохело, то должно генерироваться какое-то количество дополнительных событий уровня Error. Нам необходимо отслеживать такое поведение. В этом нам как раз таки и поможет монитор Correlated Event Detection.

А теперь о различных конфигурациях мониторов данного типа. Существует пять типов корреляции. Первый.

The First Occurrence of A with the configured occurrence of B in chronological order. Работает он следующим образом. При возникновении первого события A начинается отсчет времени. Если в этот промежуток времени срабатывает заданное количество событий B, то события считаются связанными и происходит изменение состояния монитора (с небольшой задержкой). При этом интервал времени не продляется и не начинается заново, если в заданный промежуток времени попадают дополнительные события А.
На выходе получаем результат из двух событий в структуре типа System.CorrelatorData: первое событие А (Item0Context), Item0Count (всегда равно 1), последнее событие B (Item1Context) и количество событий B.

Например (Рисунок 10), нам нужно после события А отслеживать три события B в двухминутном интервале. В 00:25 возникает событие А, начинается двухминутный интервал, в этот интервал попадают четыре события B. Происходит связывание первого события А и третьего события B. Четвертое событие B не учитывается и в результирующие данные не попадает. Отражение состояния монитора происходит после обнаружения сконфигурированного числа (три в нашем случае) событий B, но с небольшой задержкой, 60 секунд.

Рисунок 10.

The First Occurrence of A with the configured occurrence of B, or vise versa. При появлении первого события А (или B) начинается новый интервал корреляции. Если в этот интервал попадает заданное количество событий типа B (или А), то сообщения считаются связанными и монитор меняет свое состояние. Тут главное понять, что именно с первого события начинается интервал корреляции. Сообщение, инициировавшее интервал корреляции, считается основным, в этом случае противоположное событие должно появиться в интервале сконфигурированное количество раз. Новый интервал не может начаться, пока не истечет текущий.
На выходе: событие инициировавшее интервал и последнее противоположное событие.
Рассмотрим предыдущий пример. Событие B начинает интервал, в интервал должно попасть три события А, чтобы сообщения считались связанными. Этого не происходит, поэтому состояние монитора не изменяется.
Рисунок 11.
А вот если бы первого события B не было, то событие А считалось бы инициировавшим интервал корреляции и мы бы получили срабатывание монитора (Рисунок 12).
Рисунок 12.
The Last Occurrence of A with the configured occurrence of B in chronological order. На первый взгляд может показаться, что здесь все очевидно: последнее событие А начинает новый интервал и ждет появление событий B. На самом деле поведение совсем другое. Поведение аналогично «The First Occurrence of A with the configured occurrence of B in chronological order», но происходит связывание последнего события А с последним событием B.
То есть, первое событие А начинает интервал, далее в этом интервале начинается отсчет событий B. Если обнаруживается заданное количество событий B, то происходит корреляция последнего события А с последним событием B, далее изменение состояния монитора.
Проиллюстрирую на схеме (Рисунок 13). Условия те же: три события B, двухминутный интервал.
Рисунок 13.

На выходе последнее событие A и третье событие B.
The Last Occurrence of A with the configured occurrence of B, or vise versa. Поведение этого монитора аналогично «The First Occurrence of A with the configured occurrence of B, or vise versa», за тем исключением, что происходит соотнесение последнего события А и последнего события B. Соотнесение событий аналогично «The Last Occurrence of A with the configured occurrence of B in chronological order».

The First Occurrence of A with the configured occurrence of B happens, enable interval restart. Тут все достаточно просто. Каждое событие А начинает новый интервал. Если в этот интервал попадает заданное количество событий B, то происходит связывание последнего А с последним B. Если в уже начавшемся интервале появляется событие А, то интервал сбрасывается и начинается новый отсчет событий B.
Рисунок 14.

Реализация.

Принцип реализации (Рисунок 15):

Здесь есть два модуля Microsoft.Windows.BaseEventProvider, один для события А, другой для B. Есть два фильтра System.ExpressionFilter, также для события А и B. Далее отфильтрованные события попадают в композитный модуль System.CorrelatorAutoCondition, который и проделывает все работы по корреляции событий (инициация интервала, подсчет событий) и возвращению данных типа System.CorrelatorData, наличие которых вызывает изменение состояния монитора на Failure. Модуль System.CorrelatorAutoCondition состоит из нативных модулей System.Correlator и System.ExpressionFilter. Модуль System.Correlator всегда возвращает данные по закрытию интервала, поэтому здесь модуль System.ExpressionFilter введен специально, чтобы отфильтровывать некорректные данные (пустые или если число событий в промежутке меньше, чем задано). На уровне модуля System.Correlator (также как и с System.Consolidator) можно задать дополнительный фильтр для корреляции событий (в Operations Console это кнопка Configure advanced options).

Mission Correlated Event Detection.

Этот тип мониторов полная противоположность Correlated Event Detection. Где этот монитор можно задействовать? Например, у вас есть приложение, которое, обнаружив собственную нестабильную работу, генерирует некоторое событие. Далее у вас есть приложение (это можно также реализовать с помощью Правил (Rules)), которое реагирует на это событие и запускает ряд тестов или процедур восстановление, в процессе работы которых генерируются события об исправлении ошибок. Вам важно знать, что в определенный промежуток времени после генерации ошибки успешно отработали корректирующие процедуры. Если это не так, то вы бы хотели получить Alert.
Многие настройки монитора этого типа аналогичны настройкам Correlated Event Detection.
The First Occurrence of A with the configured occurrence of B in chronological order. Первое событие А начинает интервал. Если в этом интервале происходит заданное число событий B, то монитор сохраняет свое состояние. Если в этом интервале вообще не генерируются события B или этих событий меньше, чем мы указали, то монитор меняет состояние на Failure. Статус всегда определяется в конце интервала. В случае смены состояния на Failure, на выходе мы имеем первое событие А и последнее событие B.
The First Occurrence of A with the configured occurrence of B, or vise versa. Тоже самое, что и предыдущий тип, но интервал может инициироваться первым событием А или первым событием B. Далее идет отсчет количества событий B, если интервал начался с сообщения A, или отсчет количества событий A, если интервал начался с B. Если событий, противоположных инициировавшему интервал, нет или меньше заданного количества, то происходит изменение монитора на Failure. Определение состояния монитора происходит в конце интервала.
В случае смены состояния на Failure, на выходе мы имеем первое событие А (или B) и последнее событие B (или A).
The Last Occurrence of A with the configured occurrence of B in chronological order. Тоже самое что и «The First Occurrence of A with the configured occurrence of B in chronological order», но коррелируются последнее в интервале событие А и последнее событие B. Это происходит в конце интервала, в случае если монитор перешел в состояние Failure.

The Last Occurrence of A with the configured occurrence of B, or vise versa. Тоже самое что и «The First Occurrence of A with the configured occurrence of B, or vise versa», но коррелируются последнее в интервале событие А (или B) и последнее событие B (или А). Это происходит в конце интервала, в случае если монитор перешел в состояние Failure.
The First Occurrence of A with the configured occurrence of B happens, enable interval restart. Поведение этого монитора аналогично одноименному из Correlated Event Detection. Каждое событие А начинает новый интервал, если в новый интервал попадает нужное количество событий B, то состояние монитора не меняется. Состояние монитора определяется в конце интервала. Если событий B не было вообще или было, но меньше, чем сконфигурировано, то состояние монитора изменяется на Failure.

В случае срабатывания монитора, на выходе имеем последнее событие А и последнее событие B.
Реализация.
Рисунок 16.
Монитор реализован следующим образом. Есть два модуля Microsoft.Windows.BaseEventProvider, один для события А, другой для B. Есть два фильтра System.ExpressionFilter, также для события А и B. Далее отфильтрованные события попадают в композитный модуль System.CorrelatorAutoMissingCondition, который и проделывает все работы по корреляции событий (инициация интервала, подсчет событий) и возвращению данных типа System.CorrelatorData, наличие которых на выходе вызывает изменение состояния монитора на Failure. Модуль System.CorrelatorAutoMissingCondition состоит из нативных модулей System.Correlator и System.ExpressionFilter. Модуль System.Correlator всегда возвращает данные по завершению интервала, поэтому здесь модуль System.ExpressionFilter введен специально, чтобы отфильтровывать некорректные данные. То есть, на выходе появляются данные только в том случае, если в конце интервала событий не было или было, но меньше сконфигурированного числа. На уровне модуля System.Correlator можно задать дополнительный фильтр для корреляции событий (в Operations Console это кнопка Configure advanced options).

Заключение.


На самом деле перечисленные в этой статье типы мониторов далеко не все. В предустановленных пакетах управления (management packs) можно найти еще много интересных шаблонов мониторов (monitor types) и шаблонов модулей (module types), которые расширяют функционал работы с событиями. Но создавать мониторы на основе этих шаблонов придется не из Operations Console, а используя другие утилиты, например, Authoring Console.

Используемая литература:
Event Monitors - http://technet.microsoft.com/en-us/library/ff629447
Operations Manager Management Pack Development Kit - http://msdn.microsoft.com/en-us/library/ee533840