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

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

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

  • Главная System Center, Без рубрики, Новое OpsMgr, SCOM, мониторинг
    • System Center Operations Manager 2007 – Пакеты управления

      В прошлых статьях я не раз упоминал пакеты управления (management pack, МП). Пришло время поговорить о них поподробнее, т.к. пакеты управления – один из ключевых элементов OpsMgr. МП – кирпичики, из которых складывается система. Без пакетов управления OpsMgr – голая программная оболочка. Именно из пакетов управления OpsMgr узнает, что и как ему надо выполнять, что и где отображать в интерфейсе и т.д. Фактически пакет управления – это модуль описания, содержащий правила построения системы и ссылки на библиотеки сборок.

    • Главная System Center, Без рубрики, Новое OpsMgr, SCOM, мониторинг
      • System Center Operations Manager 2007 – Health Model

        Данная статья продолжает цикл статей о OpsMgr 2007 R2, и в этот раз речь пойдет о модели здоровья. Кроме описанного ранее моделирования служб, OpsMgr использует еще одну модель – модель «здоровья» (Health Model). Каждый объект в системе OpsMgr имеет показатель «здоровья». Здоровье объекта определяется шестью состояниями: здоров (healthy ), предупреждение (warning ), критический (critical ), не проверяется (unmonitored ), в режиме обслуживания (Maintenance mode ) и «недоступен» ().

        Мониторы (monitors)

        Для воздействия на состояние объекта в рамках OpsMgr существуют мониторы (monitors), которые делятся на несколько видов: юнит-мониторы, Aggregate rollup-мониторы и Dependency rollup-мониторы.

        Модель здоровья строится по принципу «дерева», при этом нижележащие мониторы передают своё состояние по определенным правилам вышележащим.

        При инициализации любого объекта в системе ему присваивается статус Health, если данный объект имеет хотя бы один активный монитор, или Unmonitored, если для объекта не настроено ни одного монитора (их нет вообще или они отключены). После этого, по результатам проверки состояния объекта, выставляется состояние предупреждение (warning) или критический (critical). В случае если агент, который занимается обслуживание данного объекта, не доступен, объект помечается как «недоступный», при этом отображается последнее известное состояние объекта.

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

        Монитор может иметь как все три состояния (Health-Warning-Critical), так и какую-то пару состояний (Health-Warning или Health-Critical). Это определяется на этапе создания монитора.

        Unit-monitor

        Unit-монитор – это процесс, производящий некие действия, результаты которых оцениваются, и по этой оценке выставляется уровень здоровья данного монитора – Health, Warning или Critical. Unit-монитор обычно состоит из трех частей:

        1. Планировщик, который запускает монитор по определенному расписанию. Этого шага может не быть, если наблюдаемый объект поддерживает подписку на события (н-р журнал Windows или WMI Events)
        2. Процесс, получающий данные о проверяемом объекте
        3. Условие, которое по данным определяет состояние объекта

        Примером Unit-монитора могут служить:

        – выполнение WMI-запроса, и проверка состояния службы Windows

        – появление события с определенным ID и источником в журнале Windows

        – результат выполнения скрипта (vbs или powershell)

        – наличие строки в текстовом файле

        Т.к. unit-монитор обычно запускается по расписанию, перерасчет состояния происходит через промежутки времени, заданные в расписании. Если монитор настроен на запуск раз в 15 минут, и срабатывает условие, которое переводит его в состояние Critical, то обратно он вернутся только через 15 минут, даже если в реальности условие перехода наступило через 2 минуты. Исключением может служить, например, монитор, работающий с событиями в журнале Windows – он реагирует сразу, как только событие имело место.

        Пакеты управления содержат массу готовых и настроенных unit-мониторов, но администратор может добавлять их из шаблонов, идущих в комплекте с OpsMgr, тем самым влияя на модель здоровья. В OpsMgr существует огромное количество шаблонов unit-мониторов, они будут рассмотрены позже. Чаще всего используются мониторы, реагирующие на события в журнале Windows, и мониторы на базе скриптов. Кроме этого администраторы могут создавать свои unit-мониторы любой сложности с помощью Authoring Console.

        Aggregate rollup monitor

        В отличие от unit-мониторов, aggregate-мониторы не выполняют никаких действий, а лишь собирают состояния других мониторов, расположенных ниже в дереве здоровья, для выставления общей оценки объекта по какому-либо критерию. У любого объекта есть как минимум 4 aggregate-монитора: Availability, Configuration, Performance и Security. Например, для класса Windows Server 2003 Operating System определен еще один дополнительный aggregate-монитор Core Windows Services Rollup, определяющий общее состояние служб:

        Dependency rollup monitor

        Dependency-монитор также не выполняет никаких действий, а лишь передает сведения о здоровье другого объекта, от которого зависит проверяемый объект. Dependency-мониторы крайне тесно связаны с понятием «отношения», рассмотренным ранее. Думаю лучше пояснить работу Dependency-монитора на примере. Когда я описывал отношения, одним из примеров было отношение между лесом AD и сайтом. С точки зрения «здоровья» логично, что если что-то не так с сайтом, то это также должно отобразиться и на всем лесе. Dependency-монитор как раз и передает состояние здоровья сайта в схему здоровья леса:

        Для dependency-монитора мы можем выбрать в качестве ссылки те мониторы, которые нацелены на объект класса, с которым у исходного объекта есть отношения. На рисунке представлены возможные варианты настройки dependency-монитора для леса AD:

        Политики сбора здоровья (Health Rollup Policy)

        Для Dependency rollup и Aggregate rollup можно определить «политики сбора здоровья» – правила, по которым будет передаваться состояние ниже лежащих объектов в дереве.

        Для Aggregate rollup monitor можно лишь задать одно из двух значений: по худшему состоянию (worst state) или по лучшему (best state). Рисунок, который поясняет работу этой политики, размещен прямо в консоли:

        В качестве примера использования правила сбора по лучшему состоянию можно привести кластер – кластер считается «живым», пока хотя бы одна нода находится в рабочем состоянии.

        Для Dependency rollup monitor настроек гораздо больше. Кроме сбора по худшему или лучшему состоянию, доступен также сбор худшего значение от определенного процента объектов:

        Тут может возникнуть вопрос – откуда в Dependency-мониторе может взяться несколько объектов, если мы делаем ссылку на один монитор? Ответ достаточно прост: как уже говорилось выше, Dependency-мониторы строятся на базе отношений. И каждый объект может иметь отношения как с одним, так и с несколькими объектам. Например, возвращаясь к примеру с лесом и сайтом, мы имеем следующую ситуацию: у нас определены Containment-отношения между классами AD Forest и AD Site. Исходя из этого, мы можем для класса AD Forest создать Dependency-монитор, который ссылается на монитор Availability класса AD Site. Но в системе в одном лесе может быть несколько сайтов, поэтому при оценке здоровья будет использоваться состояние всех сайтов в данном лесе.

        Кроме правила определения состояния «лучший-худший», Dependency-монитор позволяет настроить реакцию на случаи, когда монитор, на который идеи ссылка, не доступен (unmonitored), и когда зависимый объект находится в состоянии обслуживания (Maintenance mode). Для каждого из состояний можно игнорировать этот монитор (Ignore), переводить монитор в состояние Warning или переводить монитор в состояние Critical.

        Health Explorer

        Главным инструментом для работы с моделью здоровья служит Health Explorer. В этой консоли сведены все мониторы для объекта. Health Explorer можно вызвать для любого объекта в системе. На рисунке представлен скриншот Health Explorer, вызванный для объекта класса AD Forest:

        Корневой элемент в дереве – Entity Health, это и есть общее состояние объекта. Все остальные элементы строятся по шаблону «Имя_правила – имя_объекта (класс_объекта)». Например, элемент «Logical Disk Availability – C: (Windows Server 2003 Logical Disk)» следует понимать как монитор «Logical Disk Availability», который проверяет здоровье объекта с именем «C:», принадлежащий к классу Windows Server 2003 Logical Disk.

        Кроме этого, из Health Explorer можно посмотреть свойства любого монитора. Пример свойств Dependency-монитора AD Forest Availability Health Rollup Monitor:

        Как видно, данный монитор устанавливает зависимость от монитора Availability класса AD Site, а также имеет политику сбора, согласно которой монитор переходит в худшее состояние из 40% лучших сайтов J.

        В отличие от основной консоли, обновление информации не происходит автоматически: Health Explorer отображает состояние объектов на момент его открытия. Для обновления информации можно воспользоваться соответствующей кнопкой на панели.

        Сброс состояния (Reset Health)

        В идеальных условиях, переход между состояниями монитора (здесь и далее речь идет о unit-мониторах) должен происходить после выполнения неких проверочных действий. Но мир ИТ далек от идеалов, и всегда находится момент, когда необходимо отойти от идеалов, и сделать всё через «запасный выход». Такая же ситуация может сложиться и с монитором, ведь легко можно представить, когда у нас есть критерий перехода монитора в состояние Critical, но нет правила, по которому мы могли бы вычислить, что с объектом уже всё в порядке. Часто такое поведение встречает, когда «здоровье» вычисляет по событиям в журнале операционной системы: мы имеет событие, которое говорит о том, что с сервером что-то случилось, а вот события, говорящее о том, что работоспособность восстановлена – нет.

        Для выхода из таких ситуаций монитор может быть создан с ручным сбросом (Manual Reset) и со сбросом по времени (Time Reset). Монитор с ручным сбросом может переходить в состояние Critical или Warning, но никогда автоматически не вернется в состояние Health. Для сброса состояния таких мониторов необходимо открыть Health Explorer, выбрать нужный монитор и нажать кнопку Reset Health. После некоторого времени, состояние монитора будет сброшено в Health. Также состояние можно сбрасывать с помощью скриптов на Powershell (готовых командлетов для этого нет) или с помощью сторонних программ (например GreenMachine).

        Мониторы со сбросом по времени работают следующим образом. В свойствах монитора указывается, через какое время состояние объекта будет сброшено в Health. Когда монитор переходит в состояние Critical (или Warning), запускается отчет. По достижении указанного промежутка времени, монитор сбрасывается в Health. Например, вот так будет меняться состояние монитора, настроенного на событие в журнале безопасности и сброс в Healh через 2 минуты:

        Обратите внимание, что в последнем случае сброс произошел через 4 минуты. Это связано с тем, что при появлении события, отчет зачинается заново.

        Быстро определить, каким образом происходит возврат монитора в Health можно в свойствах монитора: на вкладке Health в столбце «Monitor Condition» обычно описан тип возврата.

        Кроме сброса состояния, существует также возможность вычислить состояние на данный момент (recalculate state). При этом предпринимается попытка запустить монитор, и получить текущие данные о состоянии объекта. Но в реальной жизни это используется редко, т.к. далеко не все мониторы поддерживают пересчет состояния, и определить, поддерживает ли монитор пересчет состояния или нет, стандартными средствами нельзя.

        «Залипание» состояния

        Как было описано выше, rollup-мониторы целиком и полностью зависят от состояния unit-мониторов. Поэтому они меняют своё состояние в зависимости от нижележащих unit-мониторов. Но иногда можно наблюдать вот такую картину:

        Как видно, все unit-мониторы находятся в состоянии Health, а вот rollup-монитор в Critical. Reset Health здесь не поможет, и одно из средств – установить объект-хозяин в Maintenance Mode на минимальное время (5 минут). При выходе из Maintenance Mode происходит сброс всех мониторов объекта в Health.

        Заключение

        В данной статье мы кратко рассмотрели модель здоровья в OpsMgr. На поведение мониторов влияет несколько других компонентов OpsMgr, такие как упомянутый Maintenance Mode, а также overrides. Также при создании собственных мониторов важным является понимание нацеливания мониторов (targeting). Обо всем этом вы можете прочитать в сопроводительной документации к продукту, или позже в моих статьях.

        В следующей статье речь пойдет о пакетах управления (management packs) и компонентах, входящих в них.

        Антон Гриценко ака FreemanRU

        OpsMgr.ru

      • Главная System Center, Без рубрики, Новое OpsMgr, SCOM, мониторинг
        • System Center Operations Manager 2007 R2 — Service Modeling

          В предыдущей части мы рассмотрели компоненты, из которых состоит система, построенная на OpsMgr 2007 R2. Теперь речь пойдет о том, как же работает OpsMgr «изнутри».

          OpsMgr реализует концепцию управления на основе моделей (model-based management). Любую систему можно разложить на службы (services), в свою очередь, любую службу можно представить в виде некой модели. Использование моделирования позволяет легко описать любую службу или процесс, при этом абстрагировавшись от реального аппаратного и программного обеспечения. Для примера моделирования и его крайней полезности в деле мониторинга, можно привести массу примеров. Например, возьмем терминальные службы: их разворачивают в компаниях с числом серверов от одного до нескольких тысяч. В рамках классического объектного мониторинга в каждом случае пришлось бы строить систему «по месту» – вносить в систему мониторинга каждый сервер, каждый сервис на этом сервере, строить некие правила проверки и так далее. При использовании моделирования мы можем создать некую абстракцию, создать для неё правила проверки и признаки, по которым мы можем отличить терминальные службы от прочих – и тогда всё равно, сколько серверов и компонентов в нашей системе, все они будут проверяться по единой модели и единым правилам.

        • Главная System Center, Без рубрики, Новое OpsMgr, SCOM, мониторинг
          • System Center Operations Manager – Компоненты OpsMgr R2

            В предыдущей статье я вкратце описал класс систем мониторинга, к которым относится System Center Operations Manager. Данная статья будет первой технической статьей, и в ней я опишу компоненты, составляющие систему, построенную на OpsMgr.

            SCOM vs OpsMgr

            И то, с чего я хотел бы начать свой рассказ о самом продукте, покажется немного странным, однако прояснить этот момент я считаю необходимым. Речь идет о названии продукта, а точнее о его сокращении. Все продукты линейки System Center сокращаются одинаково – по первым буквам слов в названии. Например, System Center Configuration Manger – это SCCM, ну и т.д. Но так было не всегда. Когда выходила очередная версия Microsoft Operations Manager, она была включена в состав линейки продуктов System Center и получила название System Center Operations Manager 2007. И тут оказалось, что сокращение SCOM крайне напоминает слово scam. Разработчикам и маркетологам не очень понравилось такое совпадение, и решено было сделать официальным сокращением аббревиатуру «OpsMgr». Впоследствии оказалось, что ИТ-сообщество не усмотрело в SCOM ничего такого обидного, и активно пользовалась именно этим сокращением. После не большого промежутка времени маркетинг Microsoft сдался, и официальным сокращением стало SCOM. Однако среди специалистов и разработчиков продукта до сих пор «идеологически верным» является сокращение OpsMgr, поэтому и я, дабы не нарушать идеологии, пользуюсь именно этим сокращением в своих статьях. Данных факт до сих пор вносит некоторую неразбериху при поиске информации о продукте, поэтому в тегах к статье вы можете увидеть оба сокращения.

            Еще одно отступление, которое хотелось бы сделать – это локализация. В русском ИТ-сообществе использование локализованных версий продуктов фактически является «дурным тоном». В основном это связанно с тем, что качество перевода оставляет желать лучшего. Кроме этого, поиск решения возникающих проблем проще производить на английском языке. Но есть продукты, которые зависят от языковой среды, в которой они работают. И при локализации этих продуктов могут возникнуть ошибки не только в переводе, но и собственно в функционировании продукта. К таким вот продуктам относится и OpsMgr. Справедливости ради надо отметить, что на данный момент, с выходом OpsMgr 2007 R2 и CU2 к нему, эта проблема во многом «сошла на нет», но если вы не хотите в какой-то определенный момент выступать в роли тестировщика, мой совет – никогда не устанавливайте в качестве каких-либо компонентов в системе мониторинга локализованные продукты. Это касается всех компонентов – ОС, SQL Server и самого OpsMgr. Этим вы обезопасите себя хотя бы от ошибок при локализации. В связи с этим в статье я буду давать собственный перевод терминов и названий, приводя оригинальное название на английском языке.

            System Center Operations Manager 2007 R2

            На данный момент крайней версией продукта является System Center Operations Manager 2007 R2, которая имеет следующие возможности:

            • Поддержка большого числа устройств в качестве точек мониторинга: Windows-компьютеры с агентом, Windows-компьютеры без агента, *NIX-компьютеры с агентом, SNMP-устройства (это не только сетевые устройства, но и вообще любые системы, способные выступать в роли SNMP-агента: серверное оборудование, операционные системы и т.д.).
            • Обнаружение установленных систем и компонентов на точках мониторинга
            • Выполнение действий по проверке состояния обнаруженных систем и компонентов: Monitors (мониторы) и Rules (Правила)
            • Выполнение диагностических и корректирующих воздействий
            • Сбор данных с точек мониторинга – Collection Rules. Обычно это данные о производительности.
            • Раздельное хранение краткосрочных и долгосрочных (отчетных) данных. Срок хранения программно не ограничен ничем, и зависит только от возможностей вашего аппаратного обеспечения.
            • Ролевая система доступа
            • Возможность отправлять уведомления по нескольким каналам: SMTP, SMS, IM и с использованием внешних приложений
            • Масштабируемость системы: от 30 до десятков тысяч точек мониторинга
            • Мониторинг соблюдения показателей SLA
            • Возможность передачи событий во внешние системы, в том числе с синхронизацией состояния
            • Сбор событий из журнала безопасности (Audit Collection Service – ACS)
            • Разработки дополнительных модулей
            • Поддержка базы знаний

            Компоненты OpsMgr

            Административной единицей в системе мониторинга на основе System Center Operations Manager 2007 R2 является группа управления, состоящая из следующих компонентов:

            • Операционная база данных (Operation DB);
            • Корневой сервер управления (Root Management Server – RMS);
            • Отчетная база данных (DataWarehouse DB) и интерфейса отчетности;
            • Один или несколько дополнительных серверов управления (Management Server – MS);
            • Один или несколько серверов-шлюзов (Gateway Server);
            • Консоли мониторинга;
            • Веб-консоли мониторинга (Web-Console);
            • Базы данных (ACS DB) и коллекторов событий (ACS Collector) из журналов безопасности (Security Event Log) Windows;
            • Агенты, устанавливаемых на серверах и рабочих станциях (Windows или *NIX);

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

            Группа управления

            Группа управления – это исключительно административное деление, чем-то напоминающее домен в Active Directory. Сравнение может и грубое, но для понимания назначения группы я считаю его оптимальным. При проектировании системы мониторинга необходимо стремиться всегда иметь одну группу управления. Добавление группы мониторинга может понадобиться в случаях, когда:

            • Количество компьютеров, которые необходимо мониторить, превышает 5000. Жестких ограничений нет, но крайне рекомендуется не превышать это число по соображениям производительности.
            • Необходимо использовать тестовое окружение.
            • Есть четкое административное разделение компьютеров на группы, и эти группы требуют абсолютно разных настроек мониторинга. В принципе, это можно реализовать и в одной группе, но иногда удобнее сделать разные группы. Например, у вас есть 150 серверов, которые необходимо мониторить полностью по всем аспектам, и есть еще 100, на которых необходимо лишь снимать базовые показатели производительности. Чтобы не делать множество переопределений в одной группе мониторинга, проще разделить эти сервера на разные группы управления.
            • Необходимо выделить ACS в отдельную группу. Это может понадобиться с точки зрения безопасности, т.к. администраторы группы мониторинга имеет доступ ко всем данным в группе, в том числе и к данным ACS.
            • Необходимо разделить компьютеры по географическому принципу или из-за особенностей сетевой топологии. Данный момент будет подробно рассмотрен при описании сетевого взаимодействия различных компонентов OpsMgr.

            В случае если в организации развернуто несколько групп, их можно подключить друг к другу. В этом случае одна из группы будет ведущей (Top-Tier), остальные группы будут подключенными (Mid-Tier). Это делается для того, чтобы можно было просматривать данные из нескольких групп в одной консоли. Консоль должна быть подключена к ведущей группе. При этом из ведомой группы передаются только события и состояние объектов, и ничего больше. Веб-консоль также не поддерживается – она будет отображать только данные своей группы.

            Точки мониторинга

            Как уже было сказано выше, в качестве точки мониторинга могут выступать Windows-компьютеры с агентами и без агентов, *NIX-компьютера с агентами и агенты SNMP.

            Windows-агенты

            Максимальную информацию, естественно, предоставляет точка мониторинга с агентом (agent-management state). Агент мониторинга может предоставлять как всю информацию о компонентах и системах расположенных на самом компьютере, где он установлен, так и о других системам. Классическим примером является кластер – агенты расположены на нодах кластера, но кроме самих нод, агенты передают информацию обо всех виртуальных серверах, участвующих в кластере. Agent-management компьютер всегда подключен к какому-либо серверу управления (RMS или MS). Переключение между серверами управления может производиться как в автоматическом режиме (при потере связи с текущим MS), так и в ручном – из консоли управление OpsMgr. При количестве агентов более 100 рекомендуется строить систему таким образом, чтобы агенты не были подключены к RMS. Агент может работать в двух режимах – управляемом (Manageable) и не управляемом (unmanageable). Отличаются эти два режима способом установки агента. В случаях, когда агент был установлен из консоли OpsMgr, агент считает управляемым. Во всех остальных случаях (установка «руками», с помощью SCCM или иным способом) агент считается не управляемым. Функционально отличие состоит в том, что управляемый агент можно переключить с одного управляемого сервера на другой, удалить и обновить из консоли OpsMgr. Обновление – это один из самых важных аспектов, т.к. при установке обновлений на OpsMgr управляемые агенты обновляться автоматически, а вот на все не управляемые необходимо будет устанавливать обновления вручную.

            Безагентный мониторинг Windows

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

            Мониторинг Unix и Linux

            В версии OpsMgr R2 была добавлена возможность устанавливать агенты на компьютеры под управлением Unix и Linux, ранее известная под именем SCXplat – Cross Platform Extension. На данный момент поддерживают следующие версии ОС:

            • AIX 5.3 (Power), 6.1 (Power)
            • HP-UX 11iv2 (PA-RISC и IA64), and 11iv3 (PA-RISC и IA64)
            • Red Hat Enterprise Server 4 (x64 и x86) и 5 (x64 и x86)
            • Solaris 8 (SPARC), 9 (SPARC) и 10 (SPARC и x86 версии старше 120012-14)
            • SUSE Linux Enterprise Server 9 (x86) , 10 SP1 (x86 and x64) и 11 (x86 и x64)\

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

            Кроме этого, OpsMgr может выступать в роли syslog-сервера, и обрабатывать поступающие сообщения.

            Мониторинг устройств SNMP

            OpsMgr позволяет взаимодействовать с агентами SNMP по средствам Get-запросов. Кроме этого, OpsMgr может выступать в роли получателя trap-ов для агентов, зарегистрированных в системе. Такие устройства в терминах OpsMgr называются Network Devices. К сожалению, «из коробки» OpsMgr имеет лишь базовую функциональность: единственное, что проверяется по умолчанию, это доступность устройства путем отправки Get-запроса на устройство. До недавнего времени было всего два решения: писать все нужные дополнения самому, либо приобретать коммерческие решения. Цена последних была заоблачной, и зачастую в несколько раз превосходило стоимость внедрения самого OpsMgr. Не так давно ситуация изменилась, и был выпущен пакет xSNMP, который позволяет мониторить основные характеристики SNMP-устройств, при этом распространяется бесплатно. Список поддерживаемых производителей и устройств впечатляет:

            • APC
            • APC/NetBotz
            • Brocade
            • Check Point SPlat
            • Cisco
            • Data Domain
            • Dell PowerEdge
            • HP ProCurve
            • HP Proliant
            • IBM AIX
            • Juniper Networks
            • NetApp
            • NetScreen Firewalls
            • NetSNMP (Unix/Linux)
            • NetScreen Firewalls
            • SonicWALL Firewalls
            • Sun Server Hardware

            Что нельзя мониторить?

            Список того, что можно мониторить, может показаться не большим. Но на самом деле ответ на вопрос «Что можно мониторить с помощью OpsMgr» прост – всё. Абсолютно всё, что доступно по сети, можно так или иначе мониторить с помощью OpsMgr. Всё зависит только от вашей фантазии и желания. Например, можно проверять наличие кофе в кофеварке.

            Сервера управления

            В системе OpsMgr есть два вида серверов управления – корневой сервер управления (RMS) и рядовой сервер управления (MS). RMS – это первый сервер, устанавливаемый в системе. В системе может быть только один RMS. RMS отличается от рядового сервера следующим:

            • На RMS располагается служба SDK и Config, которая отвечает за подключение консолей управления, любых коннекторов и внешних систем
            • На RMS располагается служба Config, которая отвечает за распространение настроек группы на другие компоненты системы
            • RMS выполняет ряд workflow, отвечающих за функционирование некоторых аспектов системы, таких как оповещения, назначение компьютеров в рамках AD Integration (будет рассмотрено отдельно), grooming базы данных и других.

            Набор служб на RMS и MS одинаковый: System Center Data Access (OMSDK), System Center Management (HealthService) и System Center Management Configuration (OMCFG). Но на рядовом MS службы OMSDK и OMCFG отключены (Disabled), и включаются только если роль сервера повышается до RMS. Как видно из списка – RMS является ключевым компонентом системы, и требует обеспечения отказоустойчивости. Достигнуть отказоустойчивости можно двумя способами:

            • расположить RMS на кластере
            • использовать дополнительный рядовой сервер, и при выходе из строя RMS поднять рядовой сервер до RMS.

            Выбор зависит от требований к отказоустойчивости и бюджета организации. В случае кластера, вам необходимо будет иметь два сервера с установленной ОС Windows Server Enterprise Edition, при этом один сервер будет простаивать. Время восстановления составит несколько секунд. В случае же использования второго сервера MS, достаточно установить Windows Server Standard Edition, при этом второй сервер может обслуживать агентов, что позволяет распределить нагрузку на сервера. При этом время восстановления может занять до получаса. Восстановление представляет собой повышение второго сервера до RMS.

            Сервер-шлюз (gateway server)

            Вся коммуникация между агентами и серверами управления происходит только после взаимной аутентификации. Для аутентификации в обычных условиях используется Kerberos. Причем Kerberos используется не только для аутентификации, но и для шифрования трафика между агентом и серверами управления. Такой подход вводит некоторые ограничения, а именно: сервера и агенты должны располагаться в пределах доменов AD, отношения между которыми поддерживают Kerberos. Таких отношений всего два: parent-child trusts и full forest trusts. Т.е. если агенты и сервера находятся в разных лесах AD, то между этими лесами должны быть настроены full forest trusts. Доверие между доменами в разных лесах не подходит. Но что же делать, если агенты и сервера управления расположены в разных лесах, и доверие между ними установить нельзя? Или агенты вовсе расположены в рабочей группе, и ни о каком Kerberos речи идти не может? В этом случае поддерживается аутентификация при помощи сертификатов. Для этого необходимо установить сертификат на каждый компьютер с агентом и на сервера управления. Отличная возможность! Пока дело не доходит до реального внедрения. Установить сертификаты на 30-50 серверов (а это не редкость, например в случае использования DMZ) в ручном режиме, а потом еще и сопровождать всё это – не самое приятное занятие. Ведь надо следить за отозванными сертификатами, за истечением срока действия и т.д. И далеко не всегда есть доступ от таких компьютеров до сервера сертификатов. Для упрощения системы в таких ситуациях служит роль «шлюз» – Gateway Server. Как и следует из названия, шлюз становится посредником между агентами в одном домене и серверами управления в другом. При этом шлюз располагается в том же домене, что и агенты, поэтому аутентификация происходит с помощью Kerberos. В свою очередь, аутентификация между шлюзом и серверами управления происходит при помощи сертификатов:


            Однако шлюз нельзя использовать для упрощения подключения агентов из рабочих групп. Для таких агентов нужно использовать только сертификаты.

            Базы данных OpsMgr и система отчетности

            Для работы OpsMgr необходим MSSQL Server. Он выполняет роль хранилища всех данных – от конфигурационных до отчетных. Кроме этого, одна из ролей MSSQL – Reporting Services, используется для системы отчетности OpsMgr. Для работы OpsMgr необходим MSSQL Server 2005 или старше, либо MSSQL Server 2008 SP1 и старше. Заметьте, что MSSQL Server 2008 без SP1, а также MSSQL Server 2008 R2 не поддерживаются. MSSQL Express также не поддерживается.

            Добавлено 28.09.2010. С этого момента добавлена поддержка MSSQL 2008 R2 Standard и Enterprise, но с некоторыми ограничениями. Подробно решение описано в Базе Знаний.

            Для каждой группы OpsMgr необходимо от одной до нескольких баз данных:

            • Одна база данных OperationDB. Это основная база данных, в которой содержатся все данные о конфигурации группы и текущие данные мониторинга. Данная БД обязательна для каждой группы, и в системе с высокой доступностью – основной кандидат на кластеризацию;
            • Одна отчетная база данных. Содержит в себе данные долгосрочного хранения. Используется для построения отчетов. Замечу, что несколько групп могут использовать одну базу данных отчетности (и, соответственно, один сервер отчетности)
            • Одна или несколько баз данных ACS. Несколько баз данных может потребоваться в том случае, когда у вас используется несколько коллекторов ACS, т.к. один коллектор может использовать только одну, выделенную ему, базу данных.

            Отчетность и ACS будут рассмотрены отдельно, т.к. это достаточно объемные темы.

            Консоль OpsMgr

            Основным инструментом администратора является консоль OpsMgr. Она может быть установлена на любой компьютер, работающих под управление ОС Windows XP SP2 и старше. Консоль позволяет просматривать данные мониторинга, состояние объектов, выполнять задачи, просматривать отчеты, производить настройки системы, производить базовую разработку (Authoring). Общий вид консоли представлен ниже:

            Веб-консоль (Web-console)

            Веб-консоль является альтернативой основной консоли OpsMgr, и может применяться в случаях, когда достаточно просмотра сообщений и состояния объектов. Веб-консоль построена на базе IIS и AJAX, и требует наличие на клиенте только браузера. На сегодняшний день поддерживает только Internet Explorer 6 и выше. FireFox, Chrome и прочие альтернативные браузеры просто не работают с веб-консолью. При проектировании рекомендуется располагать веб-консоль вместе с ролью RMS. От основной консоли веб-консоль отличается отсутствием возможности производить настройки группы, производить разработку и просматривать отчеты (система отчетности имеет собственный веб-интерфейс). Вид веб-консоли представлен ниже:

            Audit Collection Service (ACS)

            ACS – это отдельный компонент в OpsMgr, который служит для сбора событий безопасности из одноименного журнала ОС Windows. ACS позволяет производить анализ событий безопасности, и интересна в первую очередь представителям службы безопасности. В частности, она позволяет ответить на такие вопросы, как кто и когда выполнял вход на рабочие станции, какие учетные записи были заблокированы, какие пользователи добавлялись в группы и т.д. ACS состоит из 3 компонентов:

            1. Collector ACS – служба на одном из серверов OpsMgr, отвечающая за прием событий и передачи их в базу данных.
            2. Forwarder ACS – служба на любом компьютере под управлением ОС Windows, на котором есть агент OpsMgr. Форвардер передает все события безопасности из локального журнала на коллектор.
            3. База данных ACS – отдельная база данных, в которую попадают все события от коллектора.

            Каждому коллектору соответствует только одна база данных ACS. Одна база данных не может обслуживать несколько коллекторов. ACS работает следующим образом:

            1. В момент запуска на удаленном компьютере с агентом, служба ACS Fowarder собирает все события безопасности с момента последнего запуска. Если это первый запуск – собираются все записи из журнала безопасности. Записи отправляются на Collector, который указывается при настройки ACS Fowarder.
            2. Collector ACS принимает данные о событиях безопасности, производит фильтрацию (фильтр позволяет настроить какие записи попадут в базу данных, а какие будут исключены), затем согласно схеме обрабатывает данные событий безопасности и записывает обработанные данные в базу данных.

            ACS это также довольно обширная тема, поэтому ей будет посвящена отдельная статья.

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

            Антон Гриценко ака FreemanRU

            opsmgr.ru

          • Главная System Center, Без рубрики, Новое OpsMgr, SCOM, мониторинг
            • Мониторинг в корпоративной среде

              Предисловие

              Эта статья является первой в цикле статей об Microsoft Operations Manager 2007 R2. Сколько в итоге получится таких статей, я не знаю. Всё будет зависеть от наличия свободного времени, интереса читателей и еще кучи факторов. В первой статье я вкратце опишу, что понимается под словом «мониторинг» когда речь заходит о средних и крупных ИТ-системах. Если же у вас уже есть понимаю, что вам необходима система мониторинга уровня OpsMgr – можете смело пропустить эту статью, не думаю что вы найдете здесь для себя что-то новое.

              Понятие мониторинга

              Мониторинг. Очень часто доводится слышать этот термин в сфере ИТ. Но самое интересное, что каждый понимает под этим словом что-то своё. Для кого-то это – проверить, жив ли сервер пингами, а для кого-то – понять, почему вдруг пользователи начали жаловаться на «тормоза» в корпоративном приложении. И все по-своему правы. И на каждом уровне развития ИТ-инфраструктуры используется свои методы и средства для наблюдения и оценки работы ИТ-инфраструктуры.

              Когда у вас 1-2 сервера вы вряд ли задумывается о мониторинге. Обычно сервера находятся «под боком», вы можете хоть каждый час проверять сами их состояние, и при возникновении проблем вы узнаете сразу. При этом каждый аспект работы этих серверов изучен, и вы знаете как реагировать на ту или иную проблему. При росте инфраструктуры, когда у вас уже 5-10 серверов, следить за всеми серверами «руками» не так удобно. Обычно на этом этапе начинается внедрение скриптов, различных автоматических «пинговалок» и «проверялок» вроде GoldenEye. Но вот когда число серверов переваливает за 20-30, и бизнес-приложения начинаются «размазываться» по нескольким серверам, такие средства оказываются не совсем к месту. Часто приходилось видеть ситуации, когда по данным скриптовых проверок и проверок состояний различных служб всё отлично (всё пингуется, все службы запущены), а пользователи всё равно жалуются – почта «не ходит», 1С тормозит, сайт не открывается. И тогда администратор начинает «разбор полетов». И вот тогда обычно возникает вопрос – «а что происходит там, внутри приложения? Какие ресурсы и компоненты задействованы?». Именно в этот момент происходит понимание, что необходимо в первую очередь мониторить бизнес-приложения в целом, а уже потом сервера и службы, которые их обслуживают. Все крупные вендоры, такие как Microsoft, IBM, CA, HP, предлагают свои продукты исходя именно из этого подхода. И именно поэтому вместо monitoring употребляется слово operations management, т.е. управление операциями (а продукты от HP и Microsoft используют это обозначение в своих продуктах).

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

              • Осуществлять проверку максимального числа компонентов бизнес-приложения на самом глубоком уровне.
              • Иметь средства аналитики для быстрого обнаружения проблемных мест в работе бизнес-приложения, в том числе агрегации и корреляции событий.
              • Уметь выполнять проактивный мониторинг, т.е. обнаруживать потенциальную проблему до начала её влияния на бизнес. Замечу, что для администратора эта возможность является одной из ключевых, т.к. не только позволяет избежать простой бизнеса, но и повышает его оценку в глазах руководителя.
              • Иметь возможность долгосрочного хранения информации об ИТ-инфраструктуре
              • Иметь возможность реагировать на процессы, вплоть до действий по восстановлению компонентов системы. Согласитесь, полезно, когда кто-то делает за тебя всю работу J
              • Должна реализовывать в базовом функционале основные принципы ITIL, т.к. эти рекомендации давно стали де-факто стандартном в ИТ индустрии
              • Иметь возможность ведения базы знаний

              Этот список явно дает понять, что разного рода «проверялки» уровня GoldenEye не могут выполнять ни одной из этих задач, а если могут, то с очень большими оговорками. Некоторые коллеги могут возразить, что все эти задачи можно реализовать и самому, при помощи скриптов и различных утилит. Да, можно. Но такой подход можно охарактеризовать как «а после нас – хоть потоп». Он имеет право на жизнь в статичной инфраструктуре, где ничего не меняется годами (да, есть и такое, один знакомый недавно хвастался, что у него uptime сервера составляет что-то около 500 дней), или где применяются крайне специфичные системы. Но таких предприятий крайне мало. Что же касается «обычных» компаний, то в них ИТ-инфраструктура, а в особенности бизнес-приложения, редко переживают год. Представьте ситуацию – вы, как администратор, разработали отличную систему мониторинга, написали два десятка скриптов по косточкам разбирающие все ваши бизнес-приложения, даже «прикрутили» ко всему этому интерфейс. Получили за это премию и уважение руководства. А через год уволились. Приходит новый админ, и что? Документации нет, как это работает, знает только один человек, и тот уехал в Израиль\Австралию\Бирюлево и его координат нет. Да, но она работает, вроде бы всё отлично? Но через 3 месяца происходит внедрение новой версии корпоративного приложения, и построенная система мониторинга просто перестает работать. Обычно в этом случае про старую систему забывают, и начинают строить новую J Коммерческие системы мониторинга позволяют стандартизовать подход к проверке систем, что дает массу преимуществ, таких как наличия документации к системе, поддержки вендора, наличия специалистов по данной системе на рынке труда.

              Итак, вы пришли к пониманию, что вам необходима коммерческая система мониторинга. Какую выбрать? Для меня ответ на этот вопрос на самом деле крайне прост – выбирайте систему того вендора, который максимально представлен в вашей инфраструктуре. Если у вас в сети большинство бизнес-приложений базируются на HPUX – выбирайте продукт от HP. Если у вас ядром системы являются решения от Oracle – выбирайте и мониторинг от Oracle. Если у вас бизнес-приложения завязаны на продукты Microsoft – выбирайте систему мониторинга от Microsoft. Ибо на сегодняшний день никто лучше не знает о продукте, чем вендор его создавший (с некоторыми оговорками и исключениями, конечно).

              Хуже дело обстоит, когда сеть гетерогенная, и в ней перемещались не только несколько вендоров, но и несколько платформ – часть бизнес-приложений построено на платформе Windows, часть на Unix. В этом случае выбор системы не очевиден, и ответа на вопрос «что выбрать» однозначно дать не возможно. Очень может быть, что систем мониторинга будет не одна, а несколько. В этом случае необходимо обратить внимание на то, сколько ваших компонентов в данных момент, и насколько глубоко, поддерживает та или иная система мониторинга, как она развивается и поддерживается другими вендорами, насколько просто её интегрировать с другими системами, в том числе системами ServiceDesk.

              Почему именно OpsMgr?

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

              • Рынок Windows-based приложений на сегодняшний день огромен. И, как я уже говорил выше, никто не знает о своих системах лучше, чем создавший их вендор. Поэтому вполне логично, что система мониторинга от Microsoft является одним из основных кандидатом при выборе.
              • OpsMgr способен получать данные от практически всех распространенных систем и приложений, существующих на рынке. Существуют решения для мониторинга VMware, Oracle Database, SAP, сетевых устройств Cisco, Linux-систем, Unix-систем, аппаратных платформ HP, Dell, Intel ,EMC и т.д. Список этот огромен, и многие из этих решений созданы для OpsMgr самими вендорами, что означает глубину управлением системы и поддержку со стороны вендора. За достаточно короткое время, OpsMgr стал де-факто основной системой мониторинга на рынке бизнес-приложений.
              • Легкая интеграция с любыми внешними системами, в том числе двухсторонняя. Частое требование к системе мониторинга – передача событий в систему ServiceDesk\HelpDesk. OpsMgr «из коробки» имеет поддержку такой коммуникации, причем он способен не просто передать событие во внешнюю систему, но и поддерживать эту связь на протяжении всей жизни события и синхронизировать состояния события между системами.
              • Относительная простота разработки компонентов системы. С одной стороны, создать достаточно мощную систему мониторинга собственного приложения или бизнес-сервиса можно прямо из консоли OpsMgr, не прибегая ни к каким сторонним средствам разработки. С другой, вы можете использовать любые средства разработки в случаях, когда вам потребуется мониторинг какого-либо крайне специфичного бизнес-приложения.
              • OpsMgr позволяет выполнять мониторинг с точки зрения бизнес-пользователя. Он способен отслеживать соблюдение уровней SLA, строить карты распределенных бизнес-приложений и производить оценку влияния того или иного сбоя на это приложения согласно карте.

              Этот список далеко не полный, и я очень надеюсь, что вы сами сможете его дополнить после изучения System Center Operations Manager.

              Антон Гриценко ака FreemanRU

              opsmgr.ru