Главная System Center, Без рубрики, Новое System Center Operations Manager – Компоненты OpsMgr R2
  • 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

Комментарии

  1. Молодец, так держать, пищи еще!

  2. Я не знаю-насколько хватит запала у автора, но начал-как Карманов, круто и обстоятельно. За ссылку на xSNMP -отдельное спасибо, сам нашел еще вчера- из-за brocade…

  3. Статья супер, архитектура понятна. Готовлю тестовые виртуалки и жду продолжения)

  4. Прикольно, родной MP для Netapp показывает мне намного меньше(наверное, готовить не умею), чем MP для NetApp из xSNMP

  5. по поводу названия есть и другая версия 😉
    аббревиатура SCCM зарегистрированна за Society of Critical Care Medicine. И на нее это сообщество имеет патентное право. Видимо маркетинг MS решил не связываться с этим 🙂
    Кстати, по моему только OpsMgr и ConfigMgr не сокращаются официально. По моему SCDPM, SCSM, SCVVM вполне себе используются тем же маркетингом.

  6. Леш, в итоге-то SCCM и SCOM используются официально.. так что врядли.. тем более патентное право имеет такое понятие, как область применения… Т.е. если патент выдан на название в одном сегменте рынка, его можно использовать в другом не конкуретном.

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

  8. пока не появится нормальный(в стиле MS- пара кликов) импортер mibов и не додумают как snmp-объекты в консоли представлять(логическая иерархия/вложенность/группировка и т.п.), “мониторинг snmp” – это просто :)) вроде тех с кофемашиной…
    при массовом вводе в данной версии posh не поможет…не дописано 🙂
    ручное создане групп, подписок и т.п. + некая тормознутость и непродуманность некоторых окошечек интерфейса(например, фокус не там и не туда переходит)

    и есть у меня подозрение что индексов в БД не хватает, т.к. одни и те же запросы колбасятся каждый раз (например добавление explicit member в группу)

  9. Му-му, хорошо, вот будет испортер MIB-ов, и что? ЧТо дальше? Ну импортировал ты его, а толку?
    Остальное есть. Но если нужен мониторинг ТОЛКО snmp, то OpsMgr не тот продукт, который вам нужен. Для OpsMgr snmp введен лишь для того, чтобы обеспечивать логическую связь между объектами, т.е. проверять всякие сетевые устройства. в OpsMgr v.Next всё будет несколько лучше, но на сколько пока понять нельзя.

    “Ручное создание”??? а оно бывет другим??
    Что касается индексов, то у них есть как плюсы, так и минусы, один из самых больших – они увеличивают размер базы данных, причем значительно. Так что тут надо быть аккуратным.

  10. Да, Му-му, и собственно чем xSNMP не устраивает расскажите…

  11. Я тож свои 5 копеек про xSNMP!!!
    xSNMP+savision map рулят, устаивает все, жаль только нет базы знаний, ну дык-извините, mp от quest-13т.р. за устройство, а тут халява. Уважаемый Антон, я только начал постигать scom-скажите, вот я зацепил к xSNMP свои cisco и brocade, мониторится много всего -но интерфейсы не мониторятся(unmonitored пишет)-это можно изменить?

  12. Да, по умолчанию мониторы, настроенные на интерфейсы скорее всего отключены, включите их с помощью оверайдов. Ну и как всегда чтение сопроводительной документации помогает 😉

  13. А у xSNMP доки нет:)) оборотная сторона халявы

  14. Да ну? 🙂 А слово manual вот здесь: http://www.manage-x.net/download.aspx как можно перевести? 😉

  15. Извините, не приметил:(

  16. “После не большого промежутка времени маркетинг Microsoft сдался, и официальным сокращением стало SCOM.”
    И ссылка, которая “под” аббревиатурой: http://www.microsoft.com/systemcenter/OPSMGR/

    Майкрософт действительно сдался. Ни одной такой аббревиатуры по ссылке, в URL все как нужно.
    Все это конечно же доказывает, что Майкрософт сдался.

  17. Иван, а заголовок страницы: “System Center Operations Manager 2007 (SCOM)” вам не о чем не говорит? И поверьте, MS в официальной документации использует сокращение SCOM.

  18. Антон,

    Вы не могли бы привести пример такого официального документа?

  19. Иван, http://download.microsoft.com/download/6/7/7/67735352-1046-4745-a99f-6f742ecb85be/SCOM%25202007.pdf

    Коллеги, обратите внимание, что добавлена поддержка SQL Server 2008 R2, но ВНИМАТЕЛЬНО прочитайте прилагаемую статью.

  20. 🙁 Ссылка битая. Можете хотя бы название документа сказать(не имя файла)?

  21. Большое спасибо за такой материал, всё чётко и логически доходчиво описывается, с нетерпением буду ждать продолжения. Кстати где кроме официального сайта можно достать live maps а то с офф. сайта даже url а демку не высылают

  22. LiveMaps заказывать необходимо здесь: http://www.savision.com/free-version
    Вами пришлют ссылку на закачку и ключ на год.

  23. +100
    Статья действительно толковая. Как раз разворачиваю у себя МОМ 2к7 – цикл статей прям в тему.

  24. Отличная статья, спасибо. Сегодня был в учебном центре MS – там знают об Ваших статьях и даже настоятельно порекомендовали ознакомиться с ними. Может вам о книге подумать…

  25. Всё написано до меня, называется Operations Manager 2007 Unleashed )
    во вторых для книги у меня не хватает знаний….

  26. Спасибо за статью. А можно отдельную статью о развертывании gateway server и установке агентов.

  27. За 5 минут прочтения статьи узнал о СКОМе, больше, чем за неделю чтения отрывков.
    Мне не надо было глубже, но и “СКОМ – средство мониторинга” меня тоже не устраивало.

    Спасибо.