none
OpsMgr - Distributed Application & новый "класс" объектов RRS feed

  • Общие обсуждения

  • Всем Привет!

    Opsmgr 2012 SP1.

    В процессе разработки моделей сервисов Distributed Application столкнулись с одной проблемой.

    Для моделирования ИТ-сервиса в DA добавляется объект сервера (windows computer).

    Проблема - объект сервера наследует все мониторы всех Management Pack - Win. Server, SQL, IIS, SharePoint.

    Это приводит к тому, что "отказ" монитора IIS делает всю модель сервера недоступной. (IIS остановился - объект сервера стал красным, недоступным)

    Для нашей модели DA необходимо ограничиться только мониторами Windows Server Operating System Management Pack (процессор, память диск), но увы, объект сервера наследует все Management Pack.

    Возможно ли создать свой "класс" и на его основе объекты серверов только с несколькими необходимыми мониторами?


    MCITP:EA,EMA; MCSE, MCSA:Messaging



    27 декабря 2013 г. 10:56

Все ответы

  • Общий совет: никогда не добавляйте в сервисные модели компьютеры, группы компьютеров и другие верхнеуровневые объекты. Добавляйте только те компоненты, от которых напрямую зависит работоспособность данной информационной системы (сервиса). Т.е. конкретные базы данных, приложения и т.д.

    Подход типа "этот бизнес-сервис зависит от работоспособности вот этого сервера", скажем мягко, некорректен. Компьютер это сложная система, и не все его компоненты обеспечивают работоспособность данного сервиса. Сегодня это IIS, завтра ещё что-нибудь, совершенно не относящееся к работе конкретного бизнес-приложения. 

    Буквально отвечая на вопрос: когда вы создаете Distributed Application, вы реально создаете в SCOM набор новых классов "с несколькими необходимыми мониторами". У этих классов своя модель здоровья, которую можно поменять на вкладке авторинга и т.д. Даже выдумывать ничего не нужно, всё уже под рукой. Так что проблема не в технологии, а в семантике.




    • Изменено PeTrProduct 10 января 2014 г. 12:36
    9 января 2014 г. 9:10
  • Общий совет: никогда не добавляйте в сервисные модели компьютеры, группы компьютеров и другие верхнеуровневые объекты. Добавляйте только те компоненты, от которых напрямую зависит работоспособность данной информационной системы (сервиса). Т.е. конкретные базы данных, приложения и т.д.

    Подход типа "этот бизнес-сервис зависит от работоспособности вот этого сервера", скажем мягко, некорректен. Компьютер это сложная система, и не все его компоненты обеспечивают работоспособность данного сервиса. Сегодня это IIS, завтра ещё что-нибудь, совершенно не относящееся к работе конкретного бизнес-приложения. 

    Буквально отвечая на вопрос: когда вы создаете Distributed Application, вы реально создаете в SCOM набор новых классов "с несколькими необходимыми мониторами". У этих классов своя модель здоровья, которую можно поменять на вкладке авторинга и т.д. Даже выдумывать ничего не нужно, всё уже под рукой. Так что проблема не в технологии, а в семантике.




    Полностью согласен, об этом и пишу, но вопрос был в другом :).

    Тут проблема в техниологии, по умолчанию в DA нельзя просто добавить объект процессора, памяти. Сетевой адаптер можно добавить, Диск тоже можно, Базу-Данных можно добавить.

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

    Можно использовать такой способ http://michelkamp.wordpress.com/2013/05/25/extending-hp-network-devices-with-cpu-and-memory-counters/


    MCITP:EA,EMA; MCSE, MCSA:Messaging



    15 января 2014 г. 3:03
  • Всё бы вам усложнить. Как я писал:

    >> У этих классов своя модель здоровья, которую можно поменять на вкладке авторинга 

    Буквально это значит, что если нужно добавить зависимость класса DA от определенного монитора вложенного объекта, то достаточно добавить/настроить соответствующий dependency monitor, который связывает модели здоровья этих двух классов. 

    • http://technet.microsoft.com/en-us/library/hh457606.aspx
    • http://technet.microsoft.com/ru-ru/library/ff629433.aspx
    18 января 2014 г. 7:31