• Онлайн-трансляция встречи Citrix User Group + Geek Speak Local


    До встречи Citrix User Group осталась меньше недели, Количество зарегистрировавшихся на встречу превзошло все ожидания, регистрация закрыта, и, если Вы или кто-то из Ваших друзей или коллег не успел зарегистрироваться – регистрируйтесь на онлайн-трансляцию – http://firmbook.ru/Event/Index/b5pXcOG3lk_B7lbI-ZTwJg, организованную компанией “Фирмбук”
    Программа встречи практически готова, будет много интересных докладов, в том числе….

  • Главная 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

          • OpsMgr на ITBand – быть или не быть

            Logo Microsoft System Center Operations ManagerДень добрый всем посетителям данного ресурса.

            Меня зовут Антон, большая часть посетителей меня знают под ником FreemanRU. Так уж сложилось, что до этого момента я занимался только комментированием статей на ресурсе. По большей части это связано с тем, что System Center Operations Manager, продукт по которому я являюсь специалистом, не очень распространен в RU-сегменте. Такие выводы я делаю по активности на форумах и комментированию на некоторых русскоязычных сайтах по этому продукту.
            Но некоторые люди уверяют, что это не совсем так. Что продукт если и используется мало, то только потому, что слишком мало информации по OpsMgr в русском сегменте интернета. И тогда появилась идея провести небольшой опрос – а необходима ли серия статей по OpsMgr, или данный продукт слишком специфичен и вряд ли будет интересен широкой аудитории?
            Ниже приведен ряд вопросов, на которые мы хотели бы попросить вас ответить. По результатам этих ответов и по их количеству будет приниматься решение о том, увидят ли свет статьи по OpsMgr. На все вопросы лучше отвечать да\нет, поясняя своё мнение уже после ответов. Так нам легче будет обрабатывать результаты.

          • Главная Virtualization, Windows, Без рубрики, Новое Citrix, Citrix XenApp, Hyper-V, RDP, Remote Desktop
            • Вторая встреча Citrix User Group + Geek Speak Local

              CitrixUSerGroupУважаемые коллеги,

              11 октября при поддержке компаний Citrix и Microsoft в Москве пройдет вторая встреча Citrix User Group. В этот раз встреча будет более масштабной и интересной и будет объединена с Geek Speak Local.

              Geek Speak Local – это неформальная “не конференция” на которой известные аналитики, технические эксперты и блоггеры сами выбирают тему для обсуждения и отвечают на вопросы зала. Geek Speak заменяет стандартные маркетинговые презентации на живые дебаты с участием признанных ИТ-гуру.
              Специально для участия в мероприятии к нам в гости приедут такие гуру в области виртуализации, доставки приложений и Server Based Computing как Brian Madden, Harry Labana, Rick Dehlinger, Robert Morris и Fabian Kienle.

              • Первая встреча Russian Citrix User Group – Москва – 27 мая

                CitrixUserGroupsПриглашаем Вас на встречу Russian Citrix User Group в Москве.
                На первой встрече Russian Citrix User Group, за кружкой вкусного пива, Денис Гундарев, Citrix Technology Professional расскажет о своих впечатлениях от Citrix Synergy 2010 – главного ежегодного мероприятия компании Citrix и о новинках, представленных на этой конференции.

                В программе встречи – описание новинок, планы Citrix на будущее, технические детали.
                Самое главное на этой встрече – обмен опытом.
                На терминальном сервере не работает печать или 1С? Приходите, на встрече будут администраторы, у которых все работает 🙂
              • Главная Windows, Без рубрики, Новое Citrix XenApp, Load Balansing
                • Балансировка нагрузки в Citrix XenApp

                  balancing_act Одним из преимуществ использования Citrix XenApp по сравнению с базовым функционалом Терминальных Служб Windows (по новому – RDS) является расширенные возможности по балансировке нагрузки. Данный функционал реализован компонентом Load Manager.

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