Microsoft Operations Manager 2005: управляем сетью::Журнал СА 10.2006
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Архив номеров
Контакты
   

  Опросы
  Статьи

Рынок труда  

Системные администраторы по-прежнему востребованы и незаменимы

Системные администраторы, практически, есть везде. Порой их не видно и не слышно,

 Читать далее...

Учебные центры  

Карьерные мечты нужно воплощать! А мы поможем

Школа Bell Integrator открывает свои двери для всех, кто хочет освоить перспективную

 Читать далее...

Гость номера  

Дмитрий Галов: «Нельзя сказать, что люди становятся доверчивее, скорее эволюционирует ландшафт киберугроз»

Использование мобильных устройств растет. А вместе с ними быстро растет количество мобильных

 Читать далее...

Прошу слова  

Твердая рука в бархатной перчатке: принципы soft skills

Лауреат Нобелевской премии, специалист по рынку труда, профессор Лондонской школы экономики Кристофер

 Читать далее...

Как хорошо вы это знаете  

Портал Инкоманд. Для чего он? Для кого? Какие проблемы решает?

Компания «ЕМДЕВ» – создатель интернет-портала, предлагает всем желающим протестировать себя на

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 10024
Комментарии: 0
Потоковая обработка данных

 Читать далее...

19.03.2018г.
Просмотров: 8234
Комментарии: 0
Релевантный поиск с использованием Elasticsearch и Solr

 Читать далее...

19.03.2018г.
Просмотров: 8334
Комментарии: 0
Конкурентное программирование на SCALA

 Читать далее...

19.03.2018г.
Просмотров: 5291
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 5967
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

Друзья сайта  

 Microsoft Operations Manager 2005: управляем сетью

Архив номеров / 2006 / Выпуск №10 (47) / Microsoft Operations Manager 2005: управляем сетью

Рубрика: Сети /  Сети

Андрей Бирюков

Microsoft Operations Manager 2005: управляем сетью

Мониторинг и управление серверами и приложениями, особенно в большой сети, – задача нетривиальная, и зачастую требует довольно больших затрат времени и ресурсов. Эффективное средство, которое позволит вам решить часть этих проблем, – Microsoft Operations Manager.

Приступая к работе

Решение проблем, связанных с эксплуатацией оборудования и программного обеспечения, – неотъемлемая часть работы системного администратора. Так называемый troubleshooting, как правило, занимает намного больше времени, чем, к примеру, работы по внедрению программных продуктов или начальная настройка сетевого оборудования. В связи с этим возникает необходимость в постоянном мониторинге событий, происходящих в сети. Конечно, если у вас один или два сервера, то всю необходимую информацию можно получать из журнала событий (Event Viewer), счетчиков производительности (Performance Counter), а также WSH-сценариев. Но если у вас десятки серверов, на которых установлены различные программные продукты (службы Active Directory, базы данных, система резервного копирования, корпоративный антивирус и так далее), то без промышленного решения не обойтись. Для сети на основе Windows таким решением является Microsoft Operations Manager 2005. Однако, общаясь со многими системными администраторами, мне приходилось сталкиваться с тем, что некоторые из них, внедрив этот, прямо скажем, недешевый продукт, не используют большинство имеющихся возможностей. Другие коллеги говорили, что хотели бы внедрить у себя подобное средство, но опасаются, что продукт слишком сложен в эксплуатации и поддержке. Так ли это на самом деле? В этой статье вы узнаете об архитектуре MOM, а также разберем вместе типичные примеры использования различных компонент и функций.

Рисунок 1. Административная консоль МОМ

Рисунок 1. Административная консоль МОМ

Архитектура системы

«MOM 2005 предоставляет открытые и масштабируемые средства для управления информационными системами предприятий, комплексного управления событиями, активного контроля и оповещения, создания отчетов и анализа тенденций, а также специальные базы знаний, содержащие сведения о функционировании систем и приложений, для повышения уровня управляемости корпоративных систем». Такое определение своему продукту дает Microsoft. Несмотря на официальный стиль, такое определение дает общее представление об архитектуре и функциональности продукта. Итак, рассмотрим более подробно схему взаимодействия МОМ с управляемыми продуктами (см. рис. 2).

Рисунок 2. Схема взаимодействия МОМ и управляемых серверов

Рисунок 2. Схема взаимодействия МОМ и управляемых серверов

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

Следующий элемент системы – база МОМ, в которой хранятся все настройки и сообщения о событиях. В связи с этим необходимо позаботиться о безопасности базы, разграничив соответствующим образом доступ к ней. В зависимости от аппаратных возможностей сервера, на котором разворачивается Microsoft Operations Manager, базу данных можно установить как на том же узле, так и другом, в случае, если нагрузка на сервер управления слишком велика. Что касается редакции SQL-серверa, которую можно использовать для базы данных, то лучше по возможности избежать применения MSDE. Дело в том, что ввиду ограничений, которые разработчики наложили на версию MSDE, например, общий объем файлов базы должен быть не более 2 Гб, нормальное функционирование МОМ в больших сетях может оказаться под угрозой. К сожалению, мне не довелось разворачивать МОМ вместе с Microsoft SQL 2005, но по заверениям Microsoft, ее также можно использовать в качестве базы данных.

Описав систему управления МОМ, теперь перейду к элементам, которыми управляет система. Узлы могут управляться как с помощью специальных агентов, так и без них. Для развертывания агентов необходимо установить на управляемую машину агент МОМ (узел вида Agent managed), то есть сервис, который будет локально собирать данные о состоянии машины и отправлять их на сервер управления. Устанавливать агентов можно как удаленно с сервера управления, так и локально, запустив дистрибутив на управляемом сервере. Для соединения с сервером управления по умолчанию используется порт 1270 и протокол TCP. Узлы без агентов (agentless managed) не содержат каких-либо сервисов и приложений МОМ. При этом агент установлен на самом сервере управления, который удаленно собирает информацию с управляемого узла. При этом используются средства Windows для сбора сведений о состоянии управляемой системы. Недостатком agentless-узлов является отсутствие ряда возможностей для более эффективного сбора статистики и реагирования на инциденты, по сравнению с agent-managed.

Еще один элемент системы управления Microsoft Operations Manager – Management Packs – контейнеры, содержащие наборы правил, позволяющих осуществлять сбор информации. Этот элемент МОМ представляет особый интерес, так как именно с помощью Management Packs можно собирать разнообразную информацию о системе. На основе этих сведений можно создавать правила, позволяющие реагировать на различные события системы.

Пакеты управления бывают как платные, так и бесплатные. Бесплатные пакеты можно найти на сайтах производителей программных продуктов. Management Packs для продуктов Microsoft можно скачать бесплатно [1]. К тому же хочу заметить, что Management Pack можно сделать самому, подробнее этот вопрос я рассмотрю далее. На этом теоретическая часть закончена, и приступим к более интересной практической части, то есть реализации функциональных возможностей МОМ на практике.

Разворачиваем систему

Прежде всего необходимо определить, какие сведения надо собирать. Предположим, что в сети имеется четыре сервера. Первый является основным контроллером домена, на нем также запущены службы DHCP, DNS, IIS и система резервного копирования. Второй – резервный контроллер домена, на котором также установлен почтовый сервер Exchange. Третий сервер в предполагаемой топологии – это сервер баз данных, на котором установлены Microsoft SQL 2000 и сервер терминалов. И наконец, четвертый файловый сервер, на нем находятся папки общего доступа, хранятся профили пользователей и файлы резервных копий. Расположение описанных приложений на конкретных серверах большого значения не имеет, даже если все они установлены на одном сервере, МОМ это не помешает.

Процесс установки самого сервера управления MOM 2005 подробно расписан в файле помощи. Отмечу лишь, что после установки MOM 2005 необходимо также установить Service Pack1.

После установки, открыв Administrative Console, вы увидите окно (см. рис. 1).

Консоль является основным средством администрирования Microsoft Operations Manager. В разделе Administration, открыв подраздел Computers, в группе Management Servers видны те серверы, которыми может управлять МОМ. Сюда входят как узлы с установленными агентами, так и agentless-узлы. Однако сразу после установки в этом разделе будет только один узел – сам сервер управления МОМ.

Теперь нужно развернуть агенты на тех узлах, которыми необходимо управлять. Конечно, можно обойтись без установки агентов, но тогда нельзя будет продемонстрировать часть функциональных возможностей продукта. Для развертывания можно воспользоваться MSI-пакетом, который входит в состав дистрибутива МОМ, или удаленной установкой из консоли управления Administration console. После запуска открывается окно для установки соединения с сервером управления (см. рис. 3).

Рисунок 3. Соединение с сервером управления

Рисунок 3. Соединение с сервером управления

Здесь необходимо указать группу, в которой должен находиться данный узел, сервер управления, а также порт, по которому должен осуществляться доступ. Обратите внимание на номер порта, который используется для установки соединения. Если при установке сервера управления был указан другой порт, то его надо указать и при установке агента. Также следует проследить, чтобы этот порт был открыт на межсетевом экране, в случае, если управляемый сервер находится в DMZ. В разделе Agent Control Level можно выбрать уровень доступа, который будет разрешен управляющему серверу к данному агенту. По умолчанию предлагается опция None, то есть сервер управления не будет иметь права на изменение конфигурации, деинсталляцию или обновление агента. Такой вариант является наиболее приемлемым в ситуации, когда управляемый узел и сервер МОМ разделены межсетевым экраном. Опция Full позволяет серверу управления осуществлять изменение конфигурации и деинсталляцию агентов. В разделе Advanced можно также добавить адрес альтернативного сервера МОМ. Это позволяет увеличить надежность системы в целом.

На следующем шаге установки необходимо указать тип аутентификации. В общем случае лучше использовать доменную учетную запись с правами, достаточными для управления сервисами на данном узле. Далее аналогичные действия необходимо проделать на остальных серверах, на которые требуется поставить агента управления МОМ. После установки агента управляемые узлы должны появиться в разделе Agent Managed Computers административной консоли МОМ. При обсуждении вопроса установки агентов на различные узлы нельзя обойти еще одну интересную возможность Microsoft Operations Manager – это средство Computer Discovery Rule, позволяющее задавать правила при поиске машин, на которые не был установлен агент, машин, входящих в домен, серверных или клиентских операционных систем, а также имен машин, содержащих определенный набор символов.

Итак, после того, как агенты управления установлены, можно приступить к установке пакетов management Packs, позволяющих осуществлять сбор информации по событиям конкретного вида. Если в состав вашего дистрибутива МОМ не входят нужные пакеты или они уже слишком устарели, то можно воспользоваться источником [1] или же поискать на сайте производителя конкретного программного обеспечения. Так какие пакеты management Pack нам нужны для того, чтобы эффективно управлять нашими четырьмя серверами? Прежде всего, учитывая, что сегодня практически каждая сеть на основе Windows использует AD, нужно установить пакет для Active Directory. С помощью Management Pack можно получать уведомления об использовании учетных записей, попытках несанкционированного доступа, изменения привилегий и так далее. Следующий необходимый пакет – Base Operating System – позволяет собирать сведения о производительности серверов, использовании ресурсов, загрузке процессора. Далее DHCP Service и, следовательно, Management Pack для сбора статистической информации по событиям, связанным с DHCP. В случае, если в вашей сети используется Distributed File System, можно воспользоваться соответствующим пакетом для DFS. Также необходим пакет для DNS. Так как мы договорились, что в нашей сети используется почтовый сервер Exchange, то необходимо установить пакеты управления для него. Тут следует оговориться, что для Lotus Domino также существуют пакеты управления для МОМ, но они платные в отличие от пакетов для продуктов Microsoft, которые можно скачать бесплатно. Далее будет весьма полезен пакет Group Policy, который позволит собирать все сведения о результатах применения групповых политик на клиентских машинах и серверах. Если в вашей сети используются веб- или FTP-службы на базе IIS, то соответствующий пакет управления также будет полезен. Management Pack для таких продуктов Microsoft, как ISA, SQL Server, SMS, Office и MOM (собственно, сбор статистики по самому МОМу тоже необходим), нужно установить в том случае, если эти продукты используются в вашей сети. Возвращаясь к нашим четырем серверам, отмечу, что необходимо установить пакет для Terminal Services, Print Service, WINS (несмотря на все рекомендации Microsoft, данная служба до сих пор активно используется во многих сетях).

Теперь, определившись с пакетами, которые необходимо развернуть, можно приступать к самому процессу установки. Для этого в административной консоли выберите раздел management Packs, далее в меню Action, опция Import/Export Management Pack. В окне запустившегося мастера, выбираем Import (Export может потребоваться при миграции настроек на другой сервер управления). Далее указываем путь к файлам пакета, внизу предлагается выбрать, что экспортировать. В случае, если у вас служба Reports не используется, импортируйте только Management Pack. Далее можно выбрать тип импорта, если пакет устанавливается впервые, то делать резервное копирование предыдущей версии не нужно. Затем происходит собственно импорт пакета. В случае удачного завершения установленный Management Pack сразу же начинает наблюдение за соответствующими компонентами системы. С помощью данного алгоритма необходимо установить все выбранные пакеты управления МОМ.

Для того чтобы увидеть результат работы пакетов, достаточно зайти в Operator Console. Здесь есть раздел Alerts и раздел Service Level Exceptions. В них находятся сообщения обо всех событиях, которые фиксирует МОМ. Также есть разделы, каждый из которых соответствует определенному Management Pack, в которые аналогично собираются события (Events) и исключения (Exceptions), но уже относящиеся только к данному разделу. Например, на рис. 4 можно наблюдать несколько сообщений разного уровня важности, критические ошибки (Critical Error), ошибки (Error), предупреждения (Warning) и информационные сообщения (Information).

Рисунок 4. Консоль оператора

Рисунок 4. Консоль оператора

Следует заметить, что это не просто сообщения, аналогичные тем, что операционная система создает в журнале событий Event Log. Здесь сообщения предусматривают некоторую реакцию оператора, в частности, обратите внимание на поле Resolution State. Новые сообщения всегда появляются в состоянии New, однако дальнейшее состояние каждого сообщения должен определять уже оператор. Состояние может подразделяться на четыре уровня:

  • Уровень 1 – проблема отправлена внутренней технической поддержке.
  • Уровень 2 – проблема отправлена специалисту по данному продукту.
  • Уровень 3 – проблема направлена во внешнюю поддержку (например, службе технической поддержки компании-поставщика).
  • Уровень 4 – проблема отправлена производителю.

И также есть состояние Resolved (решено). При этом рекомендую не ставить сообщениям состояние Resolved, не выяснив полностью причину возникновения проблемы. В противном случае вы можете просто забыть о её наличии, а ведь при следующем проявлении этой проблемы последствия могут быть более значительны. Вот простой пример, на рис. 4 приведено сообщение, в котором говорится о том, что DHCP-сервер по какой-то причине не выдает адреса. Можно предположить, что область DHCP не активирована, в связи с чем он не может выдавать IP-адреса. Теперь обратите внимание на поля «Time of First Event» и «Time of Last Event». Эти поля содержат сведения о первом и последнем сообщениях и о данной проблеме. Согласитесь, так намного удобнее, чем самому искать сведения об ошибке в журнале событий Event Log. Зная, когда проблема впервые появилась, намного проще ее решать. В моем случае, приведенном на рис. 4, администратор при создании нового пула адресов на DHCP-сервере, забыл его активировать, что и привело к появлению данных сообщений об ошибке.

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

Из прочих полезных функций Microsoft Operation Manager упомяну наличие в консоли оператора раздела Events, содержащего сведения о событиях, но, в отличие от Alerts, здесь фиксируются все события, которые получает МОМ. Эти события уже не требуют реакции от оператора и носят информативный характер, но при этом на основании сообщений раздела Events создаются уведомления Alerts.

Жизнь по правилам

Еще одно полезное свойство МОМ – это возможность создания собственных правил (Rule). На их основании можно создавать уведомление (Alert), которое будет отправляться в случае возникновения сообщений, интересующих администратора. Для того чтобы создать правило, необходимо сначала создать группу Rule Group. Для этого требуется в разделе «Management Packs» выбрать «Rule Group» и далее в меню «Action» выбрать «New Rule Group». Далее создаваемой группе необходимо дать имя и активировать ее, включив опцию «Enabled». Теперь вам доступны три вида правил: Event Rules, Alert Rules и Performance Rules. Каждая из этих групп предполагает наличие правил для решения определенных задач:

  • Event Rules – эта группа реагирует на появление определенных событий в журнале Event Log.
  • Alert Rules – правила, реагирующие на определенные Alerts.
  • Performance Rules – правила, реагирующие на определенные пороговые значения производительности различных компонентов системы.

Для лучшего понимания я создам по одному правилу каждого вида. Для Event Rules поставим задачу создать правило, по которому оператор должен получать Alert при каждой неудачной попытке FTP-соединения. Alert Rules – будем следить за сообщениями недоступности сервиса, в случае их появления запускать сценарий, который будет осуществлять перезапуск сервисов. Для Performance Rules необходимо следить за тем, чтобы нагрузка на процессор любого из серверов не превышала 80%, в противном случае также запускать сценарий.

Итак, для создания первого правила заходим в «Event Rules», далее «Action –> Create Event Rule». Выбираем в появившемся меню «Alert on or Respond to Event». Выбор обусловлен тем, что необходимо создать правило, реагирующее на появление определенного события. В следующем окне выбираем опцию «IIS Application Log – FTP», тип событий – «failure audit» (интересуют только неудачные попытки соединения). Следующий этап – расписание (лучше всего постоянный мониторинг), затем выбираем Computer и Domain (области действия). Потом Response, здесь можно задать действие, которое необходимо совершить в случае выполнения заданных критериев, например запуск какого-либо сценария. На этом пункте остановлюсь особо. Так как само по себе получение уведомлений о попытках несанкционированного доступа не слишком информативно (их может быть десятки за день), то имеет смысл использовать сценарий, либо специально настроенное приложение, которое будет адекватно реагировать на подобные попытки. Например, в случае пяти неудачных попыток подключения по FTP, для IP-адреса, с которого осуществлялись попытки, на час будет заблокирован доступ по порту 21. Вопросы практической реализации данного механизма уже обсуждались в предыдущих моих статьях [3]. И, наконец, собственно Alert, который будет создаваться. Здесь необходимо указать степень критичности создаваемого уведомления, затем состояние, в котором Alert появляется, а также описание и источник проблемы (рекомендую использовать значения по умолчанию). В результате выполненных действий после каждой неудачной попытки установления FTP-соединения будет появляться соответствующий Alert MOM, а также, при соответствующей настройке, будут выполняться действия по предотвращению несанкционированного доступа к FTP-ресурсу.

Для создания Alert Rule необходимо зайти в соответствующий раздел, выбрать «Create Alert Rule», в появившемся окне выбираете «Alert Criteria – of severity –> Service Unavaliable», далее «Define Response – Launch a script», выбираем из списка или указываем новый, в данном случае указываем свой сценарий, который будет перезапускать нужные сервисы, место запуска – Agent Computer, далее остается только дать правилу имя.

И наконец, для создания третьего правила, которое должно следить за нагрузкой на процессор, нужно проделать аналогичные действия, Create Performance Rule. Затем указывается, каким образом производится сбор сведений по производительности, в данном случае выбираете «Sample Performance», в следующем окне нужно выбрать «Performance Measure – Processor Time…» данный счетчик сообщает об использовании ресурсов процессора, далее в разделе Response выбираете готовый сценарий Microsoft Windows Base OS CPU Overload Script. По умолчанию в критериях указано значение 95%, но так как предполагалось использовать значение 80%, то соответственно его необходимо заменить.

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

Резервное копирование

Такая мощная система, как МОМ, нуждается в регулярном резервном копировании. Приведу те компоненты, которые необходимо копировать. Прежде всего это база SQL, в которой хранятся все настройки МОМ. Если вы используете только Microsoft Operations Manager, то вам достаточно регулярно делать резервную копию базы Оnepoint, однако если вы также используете отчеты (Reporting), то тогда необходимо делать и копию баз SystemCenterReporting и ReportServer. Выполнять это копирование можно штатными средствами Microsoft SQL Server. Также нужно обязательно иметь в наличии все Management Packs. Для этого воспользуйтесь экспортом пакетов из MOM, аналогично уже описанному выше импорту. Для восстановления данных необходимо сначала восстановить базы данных, а затем импортировать Management Pack в МОМ. Также не забывайте следить за выходом новых версий Management Pack [1, 2].

В завершение

Система Microsoft Operations Manager содержит в себе множество функций и средств администрирования, рассказать о которых в одной статье невозможно. Обучению этому продукту посвящены множество курсов во многих учебных центрах, также большое количество информации можно найти на сайте Microsoft. В этой статье я лишь попытался описать основные возможности продукта и рассмотреть на примерах варианты его использования. Но в заключение – несколько слов относительно особенностей использования МОМ. Отмечу, что хотя МОМ и позволяет автоматизировать выполнение определенных задач, но он требует постоянной работы со стороны системных администраторов. Нужно составить список тех ресурсов, которые необходимо отслеживать с помощью МОМ. Далее, в соответствии с этим списком необходимо создать правила. Однако этого мало. Надо также регулярно следить за теми уведомлениями, которые сообщает система, и реагировать на них. Если вы один раз, установив агентов и пакеты управления и настроив нужные правила, затем забыли про сервер МОМ, то польза от применения будет невелика. Продукт применяется для так называемой проактивной защиты от сбоев, то есть он предупреждает администратора о возможности возникновения проблемы еще до того, как она проявилась (например, закончилось место на диске или IP-адреса в DHCP-пуле). Учитывая это, необходимо ежедневно проверять уведомления системы.

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

Кстати, сейчас доступна для скачивания бета-версия MOM 2007, которую можно бесплатно получить по адресу [2].

  1. http://www.microsoft.com/downloads/Browse.aspx?displaylang=en&productID=9CD2C70F-F1DE-4C4D-8ECB-1432951CE0C6 – раздел, посвященный пакетам обновления Management Packs.
  2. http://www.microsoft.com/mom – страница посвященная МОМ.
  3. Бирюков А. Пишем систему динамической защиты ресурсов сети. //Системный администратор, №6, 2006 г. – С. 56-60.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru