При этом отслеживаются как состояние самого ИБП (входное напряжение, частота переменного тока, уровень загрузки и т.д.) и его батареи (напряжение и ток батареи, ее температура и т.д.), так и состояние дополнительных модулей ИБП (например, значение температуры, полученное с внешнего термодатчика платы Environment Monitoring Card).

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

Информация предоставляется оператору с использованием всех возможностей Microsoft System Center Operations Manager 2007 – модель здоровья, диаграммы, уведомления в почту, графики и др.

В отличие от прочих пакетов управления, представленных на рынке, пакет от Metrex Engineering работает полностью за счёт функционала Microsoft System Center Operations Manager 2007. Благодаря этому, установка и настройка пакета управления мало чем отличается от внедрения стандартных пакетов управления от Microsoft. Пакет управления не требует для своей работы ни отдельной базы данных, ни выделенных серверов.

В большинстве случаев, от конечного пользователя пакета управления Metrex APC Monitoring Management Pack вообще не требуется никаких дополнительных действий связанных с настройкой пакета. Все пороги по умолчанию исходят из рекомендаций производителя и учитывают неидеальность российских условий.

Поддерживаемые типы ИБП.

Metrex APC Monitoring Management Pack работает за счёт стандартной для ИБП производства APC технологии SNMP (в том числе и SNMP-trap’ы). Это позволяет отслеживать состояние различных ИБП производителя, поддерживающих мониторинг через SNMP. При этом наличие в ИБП разъема Ethernet остается рекомендуемым, но не обязательным требованием для мониторинга.

Системные требования.

Microsoft System Center Operations Manager 2007 R2

• коммутаторов
• маршрутизаторов
• брандмауэров
• беспроводных точек доступа

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

Благодаря отслеживанию IPSLA-мониторов пакет управления Metrex Cisco позволяет мониторить состояние и качество каналов между маршрутизаторами Cisco, а значит, между удалёнными офисами.

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

Информация предоставляется оператору с использованием всех возможностей Microsoft System Center Operations Manager 2007 – графики, модель здоровья, диаграммы, уведомления в почту и др.

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

В отличие от прочих пакетов управления, представленных на рынке, пакет от Metrex Engineering работает полностью за счёт функционала Microsoft System Center Operations Manager 2007. Благодаря этому, установка и настройка пакета управления мало чем отличается от внедрения стандартных пакетов управления от Microsoft. Пакет управления не требует для своей работы ни отдельной базы данных, ни выделенных серверов.

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

Поддерживаемые типы сетевых устройств.

Metrex Cisco Management Pack работает за счёт стандартных для устройств Cisco технологий SNMP и Syslog. Это позволяет отслеживать состояние любых моделей сетевых устройств Cisco укладывающихся в рамки: коммутатор, маршрутизатор, брендмауэр, беспроводная точка доступа. В редких случаях, для того, чтобы получать информацию в полном объёме, требуется прошить в сетевое устройство более актуальную версию IOS.

Системные требования.

Microsoft System Center Operations Manager 2007 R2

Гарантии

Пакет управления Metrex Cisco

• успешно прошёл бета-тестирование в нескольких реальных клиентских сетях
• был проверен командой разработчиков Microsoft System Center Operations Manager 2007 на предмет соответствия их требованиям
• был внедрён в нескольких крупных компаниях

Помимо стандартных требований – компоненты “SNMP Service” и “SNMP WMI provider”, Powershell v1.0, он требует установить hotfix под номером  942589. Эта заплатка устраняет проблемы с перенаправлением файловой системы в Windows x64.

Для начала,  я думаю, стоит объяснить, что такое – “перенаправление файловой системы”. Эта штука нужна  для обеспечения нормальной работы 32-битных приложений в 64-битной среде

Корень проблемы кроется в том, что большинство приложений  использует в своей работе системные компоненты и библиотеки windows, но вот корректно взаимодействовать многие 32-битные приложения могут только с 32-битными же библиотеками и компонентами. Поэтому, для обеспечения совместимести, во все операционные системы Windows x64 включены в том числе и сборки всех важных системных компонент (IIS, Powershell, SNMP и других) под 32 бита.

Работает перенаправление предельно просто. Когда 32-битное приложение пытается обратиться к файлу, находящемуся в папке C:\WINDOWS\System32, операционная система перехватывает запрос и перенаправляет его в специальную песочницу – папку C:\WINDOWS\SysWOW64.

Именно в папке  SysWOW64 и находятся специальные сборки, необходимые для обеспечения совместимости. Чего там только нет. Про IIS, Powershell и SNMP я уже упоминал, а ещё там есть msixec, mmc.exe, net.exe, cmd.exe. Там даже mspaint есть.

Однако, как быть, если 32-битному приложению нужно работать именно с 64-битными компонентами? Ведь некоторые компоненты не имеют 32-битных аналогов, к примеру, powershell командлеты для работы с System Center Operations Manager 2007 существуют только в x64 версии. Для таких случаев в 64-битных ОС есть специальный путь c:\windows\sysnative. Он позволяет 32-битному приложению обойти перенаправление файловой системы и попасть не в SysWOW64, а в System32.

Так вот, к сожалению, из-за бага в Windows 2003 x64,  который обещали поправить в SP3, путь c:\windows\sysnative не работает. Для устранения этого бага и нужно ставить hotfix 942589.

Так уж случилось, что модули лицензирования в наших пакетах управления изначально проектировались для работы в среде x86. В среде x64 они, впрочем, успешно работают, но активно используют путь sysnative для запуска 64-битной версии Powershell.

Поэтому, для тех, кто пока ещё не перевёл свои серверы на Windows 2008, но предпочитает 64-битные системы у меня есть две новости, плохая и хорошая.

Новость первая, плохая.

• Придётся устанавливать хотфикс, да ещё и перезагружать сервер после установки.

Новость вторая, хорошая.

• Наш модуль лицензирования работает только на сервере SCOM с ролью RMS. Поэтому устанавливать hotfix придётся только на него. А серверы SCOM с ролями MS, Gateway и Agent, используемые нашими пакетами управления как прокси, опрашивающие устройства по SNMP, в хотфиксе не нуждаются.

]]> http://blog.vpn.ru/ru/?feed=rss2&p=397 0 http://blog.vpn.ru/ru/?p=421 http://blog.vpn.ru/ru/?p=421#comments Thu, 22 Oct 2009 12:30:31 +0000 Maksim http://blog.vpn.ru/ru/?p=421 Нам часто задают одни и те же вопросы по электронной почте и по телефону. В этом посте я постараюсь разом ответить на большую часть этих вопросов.

1 у.е. равен одному доллару США в рублях по курсу ММВБ на день покупки.

Стоимость годового контракта на поддержку пакетов управления – 15% суммарной стоимости пакетов управления. В поддержку входят консультации по электронной почте и обновление до новых мажорных версий.

Минимальная сумма единовременной покупки – 5000 у.е.

Кроме того, продолжает действовать скидка при большой единовременной покупке

• 20% при покупке на сумму от 100 тыс.у.е.

Пакеты управления лицензируются на количество устройств. То есть,  если вы, к примеру, хотите мониторить 30 коммутаторов, 4 брандмауэра и 10 маршрутизаторов, и 20 ИБП то цена рассчитывается так:

30*70+4*175+10*210+20*105 =  7000 у.е.

Стоимость поддержки – 7000 * 15% = 1050 у.е.

Итого: 8050 у.е.

Как и во всех нормальных серверах, в сетевых устройствах Cisco есть центральный процессор, оперативная и постоянная память, и даже операционная система с процессами, которые эти самые процессор и память используют для своих нужд.

Ресурсы центрального процессора циски расходуются на два типа задач – обработку прерываний и работу процессов.

Прерывания происходят всякий раз, когда пакет выходит с консольного или AUX порта. Высокая загрузка процессора, связанная с обработкой прерываний, обычно означает, что через устройство проходит большой трафик. В нормальных условиях при полном использовании пропускной способности циски, эта загрузка не превышает 30-40%. Однако, если допустить бесконтрольный рост сети, то рано или поздно, через устройства начнёт идти такой объём трафика, что загрузка процессоров по прерываниям превысит допустимые нормы.

Процессы, помимо простого перенаправления пакетов с порта на порт в зависимости от таблицы маршрутизации/коммутации, занимаются и более интеллектуальными задачами (OSPF, SNMP, NBAR, STP и т.д.). Ошибки, допущенные при конфигурировании цисок могут привести к чрезмерной загрузке процессора, связанной с обработкой процессов. Не стоит, к примеру, настраивать на маршрутизаторе 200 туннелей и включать на каждом NBAR, или задавать интервал опроса циски средствами мониторинга меньше, чем 5 минут.

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

• Troubleshooting High CPU Utilization Due to Interrupts
• Troubleshooting High CPU Utilization due to Processes
• Troubleshooting High CPU Utilization on Cisco Routers
• Catalyst 3750 Series Switches High CPU Utilization Troubleshooting
• High CPU Utilization on Cisco IOS Software-Based Catalyst 4500 Switches

К чему может привести чрезмерная нагрузка центрального процессора циски опытному сетевому администратору объяснять не нужно, он хотя бы раз в жизни с таким сталкивался. А приводит это к звонкам разъярённых пользователей, у которых тормозят или просто перестают работать сетевые диски, почта, интернет,  терминальные сервисы, сетевые шахматы и прочие жизненно необходимые для работы вещи.

Именно по причине высокой важности контроля загруженности центрального процессора, мониторить эту загруженность умеют почти все средства мониторинга цисок. Не исключение и Metrex Cisco Management Pack для SCOM 2007.

Он позволяет:

1. отслеживать загруженность центрального процессора, усреднённую по 5-минутному, 1-минутному и 5-секундному интервалам,

Чем больше период усреднения, тем глаже график.

2. отслеживать загрузку процессора, связанную с прерываниями,

Обработка прерываний отъедает солидный кусок процессорных ресурсов, но пока всё в пределах нормы.

3. автоматически обнаруживать самые ресурсоёмкие процессы и  выводить графики о том, как они расходуют ресурсы центрального процесса.

Типичный набор для коммутатора уровня ядра.

Тишь да гладь.

Здесь важно оговориться, почему мы решили отслеживать только самые жадные процессы, а не вообще все. Дело в том, что в зависимости от сложности выполняемых задач, в циске бывает одновременно запущено 150-300 процессов. По каждому процессу в идеале нужно выводить три графика – усредняемый по 5 минутам, 1 минуте и 5 секундам. Итого – 450 – 900 графиков по каждому устройству. Помимо того, что от такого потока информации распухнет база данных SCOM, перспектива работы с 900 графиками приведёт в уныние любого оператора мониторинга.

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

Похоже, что с трафиком перебор.

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

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

Однако, после внедрения нашего менеджмент пака в сетях, не подконтрольных нашим сетевым аминистраторам, стали происходить совсем уж загадочные события. Как вам, к примеру, такой набор графиков?

Нагрузка, связанная с прерываниями, почти нулевая.

Ни один процесс не шелохнётся.

Судя по ним, центральный процессор коммутатора постоянно загружен на 20-25% не понятно чем. Все процессы по нулям, и прерывания тоже. Чем же он занят?

А вот это – уведомление с него же:

На прерывания ушёл 1%, на процессы - 0%, а суммарно - 79%.

Бессмыслица какая-то, не правда ли? Причём творились эти странности только на некоторых коммутаторах, а вот со всех маршрутизаторов поступали вполне адекватные данные.

Однако, выяснить, в чём причина этой неразберихи не составило большого труда. Во первых, оказалось, что информация о процессах, полученная через CLI серьёзно отличается от информации, полученной по SNMP.

Данные из CLI.

Как видите, тут не нули, а вполне осмысленные значения. А во-вторых, выяснилось, что нули по SNMP возвращают исключительно коммутаторы с относительно старым IOS (2008 года и старше). А после прошивки свежего IOS ситуация волшебным образом меняется, по SNMP начинают приходить реальные значения.

Однако, как же отследить, что IOS устройства врёт и его нужно обновить на новый? Для этого мы добавили в наш менеджмент пак ещё один монитор. Принцип его работы предельно прост, он 10 раз собирает статистику по процессам, и если из этих 10 опросов ни один не вернул ни одного значения, отличного от нуля, то монитор рапортует, что IOS нуждается в перепрошивке. Дело в том, что в реальных условиях не может быть такого, чтобы использование процессора всеми процессами постоянно было нулевым. К примеру,  значение 5-секундной загрузки для процесса SNMP Engine, практически всегда отлично от нуля.

Вот как выглядит статистика по версиям IOS у одного из наших клиентов.

4 из 6 коммутаторов нуждаются в заливке свежего IOS

А вот маршрутизаторы в перепрошивке не нуждаются, даже если IOS датирован 2005-м годом.

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

]]> http://blog.vpn.ru/ru/?feed=rss2&p=348 0 http://blog.vpn.ru/ru/?p=303 http://blog.vpn.ru/ru/?p=303#comments Tue, 11 Aug 2009 09:52:53 +0000 Maksim http://blog.vpn.ru/ru/?p=303 31-го июля произошло знаменательное событие – вышел Visio Add-in for SCOM 2007 R2. Эта надстройка позволяет делать схемы Visio интерактивными. То есть объекты на такой схеме могут менять свой внешний вид в зависимости от текущего здоровья.

У любой IT-службы со временем накапливается пачка визийных схем: сетевые схемы, схемы хождения почты, схемы серверных помещений и серверных стоек и тд. и т.п. Такие схемы в основном используются для того, чтобы понять, какие объекты IT-инфраструктуры вообще имеются в компании и как они взаимосвязаны. Благодаря свежевышедшему Add-in’у стало возможным по этим схемам отслеживать ещё и здоровье всех объектов.

Работает это следующим образом – на рабочую станцию оператора мониторинга ставится консоль SCOM, Visio 2007 Pro и Add-in. После установки Add-in’а в Visio появляется новый пункт меню – “Operations Manager”. Далее нужно создать визийную схему или открыть готовую и из нового пункта меню сопоставить с объектами этой схемы объекты Operations Manager’a. Разумеется, предварительно нужно внедрить Operations Manager.

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

1. Установка.

На самом деле, подобный add-in уже давно существовал для версии SCOM 2007 (не R2). Однако, чтобы заставить Visio 2007 работать со SCOM’ом, требовалось странное – наличие на рабочей станции оператора полноценной среды разработчика Visual Studio 2005 Pro (далеко не бесплатной, между прочим). Для новой версии Add-in’а предварительные требования следующие:

• Operations Manager 2007 R2 Operations console
• Microsoft Office Visio 2007 Professional
• The Microsoft .NET Framework 3.5 SP1
• Visual Studio Tools for Office system Runtime 3.0
• 2007 Microsoft Office System Update: Redistributable Primary Interop Assemblies

После установки перечисленного выше софта и патчей, можно скачать и установить Add-in. Установка всего этого добра на мою рабочую Windows 7 не вызвала у меня никаких затруднений, думаю, и у вас всё получится.

2. Создание соединения с сервером SCOM.

Для начала нужно заполучить схему, с которой будем работать или нарисовать таковую самому. Дружественный отдел IT-диспетчеров прислал мне одну из своих схем, на ней отображена связь московского офиса одного из наших клиентов с офисом в Краснодаре.

Схема сети

Открываем схему в Visio. Заходим в меню “Operations Manager”. Выбираем – “Configure Data Source”.

Настройка соединения схемы Visio с серером SCOM

Указываем имя RMS сервера, url его web-консоли (у меня даже сработал автопоиск url), выбираем, как часто обновлять схему.

3. Сопоставление объектов.

Переходим к самой интересной части. Будем сопоставлять цискам и каналам на визийной схеме циски и каналы из SCOM’а, и да пребудет с нами Сила.

В Visio открываем меню “Operations Manager” и выбираем пункт “Add Data Links”. Далее мы должны, используя выпадающий список и фильтр, выбрать класс, объекты которого мы хотим добавить на схему. Наш выбор – рутеры.

Выбираем класс

После этого надо определиться, какие именно рутеры нам нужны. Наш выбор – два московских и один краснодарский. Кое-какие данные на скриншоте пришлось вымарать. Не обессудьте, отдел информационной безопасности не дремлет.

Выбираем, какие именно рутеры нам нужны.

Нажимаем кнопочку Add и вуаля, прямо в Visio появляются объекты из SCOM.

Объекты из SCOM в панели Visio

Полдела сделано, осталось только прилинковать их к объектам на схеме. Сделать это можно несколькими способами, например, подхватить объект SCOM из новой панельки и перетащить его на объект на схеме Visio (drag’n drop рулит). В результате, на схеме появится знакомый нам по SCOM кружок.

Зелёный кружок с галочкой означает, что объект в порядке.

Если же кружки на схеме вас не устраивают и вы предпочитает раскрашивать объекты в цвет их здоровья, то нужно зайти в меню Data, выбрать пункт Display Data on Shapes и в появившемся меню произвести соответствующую настройку.

Окрашиваем объекты в цвет их здоровья.

Итак, с цисками покончили, переходим к каналам. У нас на схеме есть 4 линка: KRDR_PU-J_1, KRDR_PU-J_2 – публичные, KRDR_MU-J_1 – mpls, KRDR_U-J_2 – интегральный.

Получаем их из SCOM’а.

Выбираем класс "jitter"

Выбираем объекты - джиттеры, в названии которых есть буквы krdr

Далее, линкуем появившиеся в панели Visio джиттеры к линкам на схеме.

4. Подводим итоги.

В результате у меня получилась вот такая схемка:

Итоговая схема.

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

Что ещё можно делать с этой схемой? Можно ткнуть правой кнопкой по объекту и вызвать Health Explorer или Alert view.

Верхних двух пунктов раньше не было.

Health Explorer и Alert View откроются в окне браузера. Для этого на вашем сервере SCOM конечно должна быть установлена web-консоль.

Health explorer.

Теперь можно развернуть Visio на весь экран (кнопка F5) и получится вполне взрослый Monitoring Dashboard. Ставите вокруг себя пяток мониторов с такими dashboard’ами и можно считать, что мониторинг удался.

Для мониторинга всего остального нужно скачивать и устанавливать пакеты управления (management packs). Microsoft выпускает и выкладывает для бесплатного использования MP для всей линейки производимого ею программного обеспечения, однако потенциально функционал SCOM гораздо шире. Его SDK позволяет мониторить любое устройство, которое поддерживает протокол SNMP, и в которое можно воткнуть витую пару.

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

Что вообще можно мониторить в источниках бесперебойного питания? Да на самом деле много чего. Температуру, входное напряжение, суммарную мощность подключенных устройств можно выводить на графики. А в случае неожиданного пропадания электричества в серверной, перегрева, превышения допустимой мощности подключенных устройств, значительных перепадов входного напряжения было бы неплохо получать уведомления на почту, а лучше – на телефон по SMS.

На данный момент, на рынке представлено всего три пакета управления источниками бесперебойного питания. Их производят компании Jalasoft, Quest Software и Метрекс Инжениринг. Оговорюсь сразу, что эти пакеты управления умеют работать только с источниками бесперебойного питания, производимыми компанией APC. Дело в том, что эта компания разработала свой собственный SNMP стандарт для ИБП, не совместимый с общепринятым. Таким образом, перед разработчиком пакета управления сразу встаёт нелёгкий выбор, какие ИБП поддерживать – APC или все остальные. Учитывая, что компания APC – лидер в производстве ИБП, вывод очевиден.

В этом посте я сделаю обзор всех трёх решений: Jalasoft Xian Network Manager Io SP2 for OpsMgr 2007 (далее – Xian), Quest Software Management Xtensions – Operations Manager 2007 Edition (далее – QMX) и Metrex UPS MP (его название я не буду сокращать из-за патриотических чувств).

1. Особенности установки.

Xian и QMX устроены почти одинаково, они состоят из  фреймворка  (отдельной большой программы) и, собственно, пакетов управления. Фреймворк берёт на себя львиную долю работы, он опрашивает устройства по SNMP, затем, полученные данные через коннектор передаются в SCOM, а пакеты управления в SCOM’е просто отображают поступающую информацию в виде графиков и диаграмм, генерируют алёрты и так далее.

Для своей работы оба продукта используют собственные базы данных. Xian – MS SQL, а Quest – MS SQL или MS Access. Если у вас уже есть SCOM, то проблем с базой данных возникнуть не должно, MS SQL у вас куплен по-любому. Однако, если вы сэкономили при покупке MS SQL и купили его со скидкой в комплекте со SCOM’ом, то использовать Xian не получится. По лицензионному соглашению, использовать такой MS SQL можно только для размещения баз данных самого SCOM и больше ни для чего.

Основная беда Xian и QMX в том, что для сбора данных они не используют функционал SCOM, а фактически, дублируют его. Это значит, что если у вас простая сеть с одним сайтом, в котором один SCOM RMS, то вам повезло, вы сможете установить все компоненты Xian или QMX на этот сервер и радоваться жизни. Но если в вашей компании много офисов, в некоторых из которых стоят SCOM-шлюзы, если вам нужно отказоустойчивое решение, если вы хотите мониторить много устройств, то всё что вы делали при внедрении SCOM вам придётся повторить, выстраивая аналогичную структуру  шлюзов, кластеров и прочего-прочего из Xian или QMX. Затем нужно будет открывать на сетевом оборудовании нужные порты, чтобы все компоненты могли между собой общаться. Затем придётся бэкапить программную часть, базы данных, и вообще всячески холить и лелеять это хозяйство.

Типовая структура SCOM в компании среднего-большого размера

Metrex UPS MP является обычным пакетом управления, состоящим из одного файла с расширением MP. Его инсталляция ничем не отличается от импорта стандартного пакета управления. Консоль оператора SCOM -> Administration -> Management Packs -> import – вот и вся инсталляция.

Зачем же Quest Software и Jalasoft так усложнили схему работы пакетов управления, зачем танцы с бубном вокруг этих фреймворков? – спросите вы. На самом деле, в такой схеме есть три неоспоримых преимущества (два для разработчиков и одно для пользователей):

1. Такие пакеты управления гораздо проще защитить от взлома. Даже не так. Их можно защитить от взлома. Стандартный пакет управления при желании легко декодируется в исходный код на xml, после чего любой мало-мальски грамотный программист сможет сделать с ним что угодно. С фреймворком такой номер не пройдёт.

2. Фреймворк – универсальная штука. Если вы прошли через муки установки и настройки фреймворка, чтобы мониторить, допустим, циски, то заставить его мониторить ещё и ИБП – дело нескольких щелчков мыши. Таким образом, компании-разработчики подсаживают пользователей на свои продукты.

3. Фреймворки теоретически менее требовательны к железу. Ни для кого не секрет, что узкоспециализированное решение почти всегда работает лучше, чем универсальное. Функционал SCOM по работе с SNMP довольно узок. Многие вещи в пакете управления приходится реализовывать на скриптах vbs или js, а скрипты в плане скорости работы и оптимального использования ресурсов рекордов не ставят. На практике, разница в скорости работы будет заметна, если вы захотите мониторить 300 цисок или 1000 ИБП с одного сервера. При меньших количествах, заметного выигрыша в производительности от использования фреймворков нет.

2. Конфигурирование.

2.1 Добавление ИБП.

Так как Metrex UPS MP – стандартный пакет управления, не содержащий никаких дополнительных программ, то вся конфигурационная часть ложится на SCOM. Чтобы добавить ИБП в список мониторящихся устройств, вы должны воспользоваться стандартным визардом SCOM по поиску и добавлению сетевых устройств.

Добавляем ИБП прямо в SCOM.

Можно не морочить голову и добавлять сетевые устройства целыми сетевыми сегментами. Если вы купили у нас пакеты мониторинга для ИБП, цисок, принтеров (этот пока в разработке) , то пакеты сами разберутся, что есть что и будут мониторить именно то, что им положено.

В пакете управления Xian сетевые устройства добавляются через собственный симпатичный интерфейс. Единственный недостаток – вы должны чётко знать, что именно вы добавляете. Если сетевики выдали вам диапазон адресов и сказали – отмониторь-ка наши железяки, то придётся стребовать с них разъяснения, что из этого коммутатор, что маршрутизатор, а что брендмауэр. Зачем? А потому что так устроен интерфейс Xian. Но в нашем случае, мы добавляем исключительно один класс устройств - ИБП компании APC, так что проблем возникнуть не должно.

Запускаем визард.

Выбираем тип устройства.

Можно добавлять как одно устройство, так и целый диапазон.

Добавленное устройство появляется в интерфейсе Xian.

После того, как вы добавили ИБП во фреймворк Xian, он автоматически появляется в SCOM’е.

Несмотря на то, что компания PowerQuest уже давно на рынке, занимается исключительно написанием программного обеспечения и имеет годовой оборот сравнимый с годовым бюджетом Ленинградской области, с интерфейсом пакету управления QMX конкретно не повезло. Он воистину суров, не причёсан  и способен вызвать нервный смех даже у самого бывалого и видавшего виды админа. При изменении размера окна кнопки так и норовят исчезнуть, всплывающие подказки практически не читаемы, а некоторые подписи под полями ввода напоминают строчки из неведомого скриптового языка.

Артемию Лебедеву наш горячий комсомольский привет.

Добавить ИБП, впрочем, на удивление не сложно. Нужно пометить один из существующих по умолчанию ИБП, нажать кнопку Clone столько раз, сколько ИБП вы планируете мониторить, и затем, в настройках каждого появившегося объекта прописать IP адрес, Trap Community String, Read Community String и Write Community String. Однако, если вы думаете, что после нажатия кнопки Save, ИБП появятся в SCOM’е, вас ждёт разочарование. Для того, чтобы запустить мониторинг устройства, нужно найти его в дереве слева, ткнуть по нему правой кнопкой и выбрать “Start”.

Запускаем мониторинг.

Зато, как вы сами можете убедиться на скриншоте выше, есть несколько способов проверить, отвечает ли устройство и верно ли вы сконфигурировали его настройки. Самый интересный пункт - test connection, он проверяет, отвечает ли устройство на SNMP запрос.

Проверка прошла успешно.

Если всё прошло удачно, то вы увидите, что ИБП появились в SCOM’е. Если же вы видите что все ИБП помечены красным и висят алёрты о невозможности соединиться с ними, значит вы забыли их всех прощёлкать и нажать start.

2.2 Конфигурирование правил и мониторов.

Для начала, давайте определимся, что такое правила и мониторы в понимании SCOM. Если в MOM 2005 правила отвечали за всё на свете, то в SCOM 2007 всё поменялось. Теперь правила используются в основном для отображения значений на графиках, а мониторы собирают значения ключевых параметров, сравнивают их с пороговыми числами и в случае необходимости генерируют алёрты.

В пакете управления Metrex UPS MP содержится 13 правил, рисующих графики и 21 монитор, генерирующий алёрты. По умолчанию один из мониторов отключен. Это монитор, который пингует UPS и если тот не отвечает на 40% запросов, то генерируется алёрт о том, что устройство не доступно.

Монитор, закрашенный серым, по умолчанию выключен.

Монитор выключен в связи с тем, что некоторые заказчики экономят на APC Environmet картах и администраторы вынуждены подключать ИБП не в локальную сеть, а к серверам по usb-порту. В таких случаях у ИБП нет собственного ip адреса, и пинговать попросту нечего. Поэтому, по умолчанию, для определения доступности ИБП используется монитор, посылающий ИБП SNMP-запросы. Однако, если вы по каким-то причинам захотите включить пингующий монитор для всех ИБП или для каких-то определённых, то можете сделать это через переопределение (override).

Включаем бесполезный монитор.

Если вы вдруг решите, что часть графиков вам не нужна, или некоторые алёрты для вас бесполезны – не проблема, выключайте их через переопределения. Как и в любом стандартном пакете управления, в этом уже заданы все пороговые значения, которые можно переопределять. К примеру, для температуры окружающей среды warning-порог – 28 градусов цельсия, а critical – 40. Это значит, что если у вас в серверной температура имеет обыкновение скакать вокруг отметки 28 (что конечно маловероятно), то вы будете завалены оповещениями о том, что алёрт то открыт, то закрыт. В таких случаях нужно переопеределять пороги на те, которые актуальны для вас.

Переводим порог на летнее время.

Пороги в пакете управления Metrex UPS MP взяты не с потолка, а выбраны метедом проб и ошибок, опираясь на российские реалии. Вероятность того, что вам придётся переопределять что-либо не высока. Скорее всего, вполне подойдут значения по умолчанию.

Конфигурирование правил и мониторов в пакете управления Xian осуществляется через интерфейс фреймворка. Интерфейс, бесспорно удобный и красивый, хотя и немного запутанный.

Xian свёл все настройки в некий набор правил, в которых можно для каждого параметра выбрать, отображать ли его на графике, а также выставить пороговые значения и интервал опроса.

Задаём пороговое значение.

Настраиваем алёрт и решаем, отображать ли значение на графике.

Задаём интервал опроса

Все возможные правила, есть из чего выбрать.

Настраивать правила по отдельности для каждого ИБП было бы глупо, поэтому есть возможность создать одну или несколько политик (политика – это набор правил с заданными настройками) и применить их к ИБП по своему усмотрению. По умолчанию уже есть рекомендуемая к использованию политика, которой вполне можно пользоваться.

Политика по умолчанию

Оптимальный порядок действий мне представляется таким: сначала нужно произвести грубую конфигурацию создав политики и применив их к ИБП, а затем в свойствах каждого ИБП при желании можно более тонко настроить правила.

После того, как вы сконфигурируете правила во фреймворке Xian (правила в понимании Xian), произойдёт реконфигурация пакета управления импортированного в SCOM и появятся графики, мониторы и алёрты.

… продолжение следует.

Однако, если у вас в фирме МФУ только от компании Xerox – считайте, что вам повезло. Xerox сделала management pack для мониторинга своих МФУ с помощью SCOM 2007 и даже любезно выложила его для бесплатного скачивания. Этот MP носит гордое имя Xerox CentreWare for Microsoft SCOM по аналогии с отдельным продуктом для мониторинга МФУ Xerox.

Давайте разберёмся, достаточно ли функционала этого MP для нормального мониторинга, а также, можно ли его использовать для мониторинга МФУ не только Xerox, но и других производителей.

1. Установка.

MP состоит из одного XML файла, но, несмотря на это, программисты Xerox запаковали его в инсталлер. Запускать инсталлер нужно строго на рутовом сервере SCOM, он проверят, действительно ли SCOM есть на том сервере, где его запустили, затем распаковывает и импортирует XML в репозитарий. Вероятно, установщик был сделан для нашего удобства, но на практике, на одном из моих серверов он упорно не находит SCOM и отказывается продолжать установку.

Если вам не повезёт, то вы увидите это.

Будем считать, что вы успешно установили MP, и перейдём к обзору его интерфейса и возможностей.

2. Интерфейс и функционал.

Так как MP состоит из одного XML файла, то у него нет собственного интерфейса по добавлению принтеров. MP анализирует сетевые устройства, добавленные в SCOM, разбирается, принтер это или нет, и мониторит то, что считает принтерами.

Интерфейс MP настолько по-спартански прост и суров, что я приведу его на скриншотах целиком.

Корневая, она же единственная, папка.

Список неприятностей, происходящих с принтерами.

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

Принтер-хулиган.

Графики количества отпечатанных листов.

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

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

Общий список сетевых устройств.

К сожалению, как и ожидалось, MP работает только с МФУ, произведёнными компанией Xerox. На скриншоте видно, что принтеры HP 10.100.19.10 и 10.100.19.100 не мониторятся.

3. Баги.

Ошибки при установке MP сразу навеяли тревожные предчувствия, которые позже подтвердились. После установки MP в логи Operations Manger на сервере SCOM стали регулярно сыпаться ошибки.

Последствия установки MP.

Достаточно ли функционала, предоставляемого MP от Xerox для мониторинга принтеров? Если бы можно было мониторить принтеры любых производителей, то ответ был бы положительный.

На самом деле, достаточно одного alert view и возможности посылать уведомления по почте и SMS. Графики общего количества отпечатанных листов в общем-то нафиг никому не нужны.

Для полного счастья, пожалуй, хотелось бы иметь общий список принтеров (state view), а от мусорных алёртов напротив хотелось бы избавиться. Кроме того, неплохо было бы убратьошибки в логах.

Во второй части этой статьи я вскрою MP, и объясню, как он работает. В третьей части я доработаю его насколько это возможно и выложу улучшенную версию для скачивания. Следите за обновлениями блога.

Системные администраторы  должны прийти раньше всех и:

• зайти в серверную и убедиться, что ни на одном сервере не горит красная лампочка, все сервера включены, температура в серверной не больше 20 градусов,
• войти через ssh или rdp на каждый сервер, просмотреть системные сообщения, проверить остаток свободного места на дисках, проверить, хватает ли оперативной памяти, процессорных мощностей и так далее,
• убедиться, что, критичные службы и приложения продолжают работать: послать пару тестовых писем, скачать файлик с интернета, проверить работоспособность бизнес-приложений,
• убедиться, что ночные задания резервного копирования прошли успешно,
• просмотреть журналы событий  контроллеров домена на предмет подбора паролей,
• просмотреть лог  маршрутизатора,
• убедиться что батарея источника бесперебойного питания в порядке, что ожидаемого времени автономной работы хватает, чтобы корректно погасить серверы в случае неожиданного отключения электроэнергии владельцами здания,
• убедиться, что на критичных для бизнеса рабочих станциях генерального директора, главного бухгалтера, и финансового директора нет никаких проблем.

Зачем нужен такой утренний обход? Дело в том, что если пустить всё на самотёк, то рано или поздно одна из намечающихся проблем, оставшись незамеченной,  перерастёт в катастрофу. Например, в один прекрасный момент может оказаться, что на одном из серверов «рухнула» ОС из-за нехватки места на системном диске (такое бывает), а резервные копии  давно уже не делались из-за того, что истекла лицензия на систему резервного копирования, и восстанавливать сервер можно только из копии годовалой давности, которая давно не актуальна.

Системным администраторам, как и всем творческим личностям, претит рутинная работа. Поэтому, скорее всего, в вашей компании такой обход совершается в лучшем случае раз в неделю, а то и вообще не совершается.

Как можно проконтролировать, что ваши системщики совершают всю эту работу? Теоретически, можно заставить их вести журналы и отмечать каждый шаг. На практике, заставить их делать это практически невозможно.

Как составить такой список ежеутренних шагов? Доверять такое штатным системным администраторам – всё равно, что поручить узнику Гуантанума составить набор пыток, которые будут к нему применять на допросе. В идеале, для составления списка шагов придётся приглашать специалистов со стороны.

Как руководству узнать, в каком состоянии находится ваша IT-инфраструктура? Приглашать по мере необходимости к себе начальника IT-службы и спрашивать у него. И хорошо, если он действительно в курсе.

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

В этом случае придётся нанимать для утренних обходов много умных и высокооплачиваемых администраторов и следить за ними.

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

 Ответом на все эти вопросы является внедрение системы мониторинга. Давайте помечтаем об идеальной системе мониторинга. Она должна постоянно делать все-то же самое, что делают админы на утреннем обходе, только лучше и не раз в день, а постоянно – каждую минуту, без перерыва на обед и сон. Она должна выдавать информацию о назревающих или уже возникших проблемах так быстро, как никогда не смогут даже сотни сертифицированных администраторов. Система мониторинга должна быть всеядна, то есть уметь собирать информацию со всего имеющегося оборудования – рабочие станции, серверы, принтеры – не важно. Она должна анализировать эту информацию и ставить в известность ответственных лиц в случае необходимости. Кроме того, она должна позволять гибко настраивать свой интерфейс, чтобы в случае необходимости сетевой отдел видел только информацию относящемуся к сетевому оборудованию, служба поддержки видела проблемы на рабочих станциях, а начальник IT службы видел консоль со сводной информацией, по которой он мог  мгновенно сориентироваться, на каком направлении в данный момент имеются проблемы. Ну и конечно обязательно нужны еженедельные или ежемесячные отчёты о состоянии It-структуры, желательно, чтобы система мониторинга умела создавать их при минимальном участии со стороны персонала.

 Что даёт внедрение системы мониторинга:

1. Администраторы узнают о проблеме до её появления и не допустят рецидива.
2. Если проблема подкралась коварно и незаметно, и всё же возникла, администраторы узнают о ней не от разгневанных пользователей, а мгновенно, это уменьшит время реакции и простой будет сведён к минимуму.
3. Начальник IT службы может одним взглядом оценить состояние всей структуры в целом, и отдельных её частей подробнее (если потребуется).
4. Высокое руководство и аудиторы могут получать милые их сердцу ежемесячные отчёты.
5. Администраторы избавлены от рутинной работы и могут сосредоточиться на решении более высокоуровневых задач.

Самое удивительное, что мы предлагаем вам почти идеальную систему мониторинга.

Сердцем нашей системы мониторинга является продукт фирмы Microsoft с длинным названием System Center Operations Manger 2007 R2, а попросту SCOM.

Почему именно SCOM? Дело в том, что SCOM является золотой серединой между дорогостоящими гигантскими решениями вроде Tivoli, и бесплатными продуктами типа Zabbix или Nagios.

SCOM дёшев, но пригоден для работы в корпоративной среде – он легко масштабируем, поддерживает отказоустойчивые сценарии внедрения, прост в управлении, быстр во внедрении и неприхотлив в обслуживании. К тому же за SCOM стоит гигантская махина – компания Microsoft, которая предоставляет техническую поддержку различными способами и постоянно работает над улучшением этого продукта.

SCOM позволяет:

• Мониторить серверы на базе ОС Microsoft Windows 2000/2003/2008.
• Мониторить рабочие станции на базе ОС Microsoft Windows 2000/XP/Vista.
• Мониторить критические для бизнеса рабочие станции особенно тчательно.
• Мониторить клиентские и серверные приложения и службы (только созданные компанией Microsoft).
• Строить отчёты.
• Гибко делегировать полномочия ответственным лицам.
• Создавать более общие сводные представления для руководителей IT подразделений, начальника IT департамента и гендиректора.
• Отправлять уведомления всеми доступными способами – e-mail, sms, прочие.

 Внимательный и требовательный читатель наверняка уже понял, почему SCOM является почти идеальной системой. Он не всеяден. Он не понимает линуксы, ИБП, принтеры, сетевое оборудование Cisco, Avaya, 3COM и D-Link. Не умеет работать с приложениями Symantec, Oracle, 1c, Гарант, Консультант и ещё много с чем.

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

Наши специалисты научились писать модули для SCOM по мере необходимости. На данный момент у нас уже готовы модули для мониторинга сетевого оборудования фирмы CISCO и источников бесперебойного питания APC. Почему именно CISCO и APC? Потому что они есть у наших клиентов.

Как у нас это получилось? Очень просто. Наша компания является единственным Royalty партнёром компании Microsoft в России по направлению SCOM. Благодаря этому у нас есть доступ в закрома закрытой документации по SCOM, а также возможность консультироваться с разработчиками этого продукта напрямую в случае необходимости. Кроме того, это даёт нам возможность закупать в Microsoft напрямую (а значит с большой скидкой) программные продукты, необходимые для внедрения SCOM:  сам SCOM, MS SQL, MS Office, Visio и даже Exchange и потом продавать их нашим клиентам по цене ниже рыночной.

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