Главная System Center, Новое System Center Operations Manager 2007 R2 — Service Modeling
  • System Center Operations Manager 2007 R2 — Service Modeling

    В предыдущей части мы рассмотрели компоненты, из которых состоит система, построенная на OpsMgr 2007 R2. Теперь речь пойдет о том, как же работает OpsMgr «изнутри».

    OpsMgr реализует концепцию управления на основе моделей (model-based management). Любую систему можно разложить на службы (services), в свою очередь, любую службу можно представить в виде некой модели. Использование моделирования позволяет легко описать любую службу или процесс, при этом абстрагировавшись от реального аппаратного и программного обеспечения. Для примера моделирования и его крайней полезности в деле мониторинга, можно привести массу примеров. Например, возьмем терминальные службы: их разворачивают в компаниях с числом серверов от одного до нескольких тысяч. В рамках классического объектного мониторинга в каждом случае пришлось бы строить систему «по месту» — вносить в систему мониторинга каждый сервер, каждый сервис на этом сервере, строить некие правила проверки и так далее. При использовании моделирования мы можем создать некую абстракцию, создать для неё правила проверки и признаки, по которым мы можем отличить терминальные службы от прочих – и тогда всё равно, сколько серверов и компонентов в нашей системе, все они будут проверяться по единой модели и единым правилам.

    OpsMgr реализуется два подхода – моделирование служб (Service Modeling), и модель состояния (Health Model). Моделирование служб давно используется компанией Microsoft, и особое развитие оно получило в программировании .NET. Для моделирования служб в ИТ принят стандарт Service Modeling Language (SML), на котором и основано моделирование в OpsMgr. SML позволяет описать все компоненты службы, а также отношения (relationships) между этими компонентами.

    Все модели и их описание попадают в OpsMgr через так называемые «пакеты управления» (Management Pack, но русский перевод не прижился, поэтому далее по тексту я везде буду употреблять сокращение МП). МП описываются при помощи XML, но могут существовать в двух видах: исходный XML, так называемые «не запечатанный МП» (unsealed MP) и бинарный файл, называемый «запечатанным МП» (sealed MP). Отличие этих МП будет рассмотрено позже.

    Классы

    Все модели служб в OpsMgr основаны на «классах». Те, кто знаком с программирование, легко примут такой подход, т.к. он используется в объектно-ориентированном программировании. Любой объект (object, entity) в системе мониторинга всегда относится к какому-либо классу. В каждом МП описаны классы, его свойства и взаимоотношение с другими классами. Взаимоотношение – обычно это либо когда объект зависит от другого объекта, либо когда объект содержит в себе другие объекты (т.е. служит контейнером).

    Каждый класс, как и в классическом программировании, имеет набор свойств. Рекомендуется, чтобы значения свойств класса были статичны, т.е. менялись как можно реже в жизни объекта класса. Например, имя базы данных – отличный кандидат на свойство класса «База данных». А вот размер базы данных лучше не делать свойством, т.к. значение этого свойства будет часто меняться. Такая рекомендация связана с тем, что на каждое изменение свойства объекта в отчетной базе данных (Data warehouse DB) создается новый экземпляр объекта (посмотреть изменение свойств затем можно через отчеты Configuration Changes в OpsMgr). Соответственно, частое обновление свойств класса приведет к росту базы данных.

    Кроме стандартных классов, в системе присутствуют абстрактные классы (abstract class) и singleton классы.

    Ни один объект в системе не может принадлежать абстрактному классу. Назначение таких классов – хранить общие для нескольких других классов свойства и отношения, строить иерархию классов. Передача свойств от класса к классу-потомку называется наследованием. Каждый класс в системе может быть (а пользовательские классы и должны) наследоваться от какого-то другого класса. Классом верхнего уровня служит класс Entity, имеющий всего несколько базовых свойств – Name, Display Name и Path.

    В качестве примера абстрактного класса можно привести класс Logical Disk. В любой операционной системе Windows имеются логические диски с одинаковым набором базовых свойств, но при этом в зависимости от версии ОС могут добавляться некоторые свойств, а также способы их обнаружения и проверки. Для упрощения был создан абстрактный класс Logical Disk, включающий в себя общие для всех ОС свойства. Затем были созданы классы дисков для каждой из операционных систем, наследованные от абстрактного класса Logical Disk: Logical Disk Windows 2003, Logical Disk Windows 2008.

    Кроме этого, абстрактный класс может выступать целью (target) для мониторов и правил. Тут важно понимать, что абстрактный класс не имеет экземпляров, поэтому в итоге монитор будет нацелен на всех потомков этого класса. Например, если мы хотим, чтобы монитор выполнялся на всех серверных Windows-операционных системах, мы можем в качестве цели выбрать класс «Windows Server Operating System». В итоге монитор будет запущен на экземплярах классов «Windows Server 2003 Operating System», «Windows Server 2008 Operating System» и т.д., так как эти классы являются потомками класса «Windows Server Operating System».

    Singleton классы отличаются от обычных тем, что могут иметь в системе только один экземпляр, который создается в момент установки МП, в котором этот класс определен (аналог static класса в программировании). Примером singleton-класса являются группы и распределенные приложения (Distributed Applications). Главная особенность singleton-класса: он всегда обрабатывается на RMS, т.е. все правила и мониторы, нацеленные на singleton-классы, будет выполняться на RMS.

    Ниже представлена иерархия класса Microsoft.Windows.Server.DC.Computer. На данном рисунке классы, помеченные серым, являются абстрактными классами, синим — обычные. Кроме этого представлен список всех свойств класса Microsoft.Windows.Server.DC.Computer, а также показано от каких классов наследуются те или иные свойства.

    Отношения

    Для построения модели службы не достаточно одних свойств. В любой модели обычно присутствует несколько объектов разных классов, поэтому обязательным компонентом модели являются отношения (relationship) между классами. OpsMgr поддерживает несколько типов отношений:

    • Hosting
    • Containment
    • Reference

    Hosting-отношения

    Hosting-отношения определяют, что один объект (hosted object) обязательно расположен на другом объекте-хозяине (host object). Т.е. hosted-объект не может существовать без host-объекта. Примером Hosting-отношений может служить логический диск. Логический диск всегда расположен на определенном объекте класса Windows-компьютер:

    Hosting-отношения – ключевой компонент в системе. На его основе строятся многие аспекты в OpsMgr: path, удаление hosted-объектов при удалении объекта-хозяина и пр. Многие из этих аспектов важны при разработке своих МП, но понимание некоторых необходимо и для администраторов, работающих с системой.

    Первое, это формирования свойства Path. Значение свойства Path является уникальным для каждого объекта в OpsMgr. Это свойство формирует автоматически на основе ключевых свойств классов, и строится как раз таки на основе hosting-отношений. Если вернуться к примеру с логическим диском, то ключевым свойством класса Windows-компьютер является его полное имя, для класса логический диск – имя диска. Т.к. для этих классов определены hosting-отношения, система автоматически строит свойство Path. Для сервера server.local и диска C: Path будет равен «server.local\C:». В качестве другого примера можно рассмотреть SQL server. Каждая база данных обязательно размещена на каком-то экземпляре SQL -сервера, в то же время каждый экземпляр SQL-сервера расположен на Windows-компьютере. Получается два hosting-отношения: между классами SQL Database <-> SQL Instance и между классами SQL Instance <-> Windows Computer. В этом случае свойство Path для сервера sql.local, экземпляра по умолчанию и базы данных master будет следующим: «sql.local\MSSQLSERVER\master»

    Второе ключевое свойство hosting-отношений, это их влияние на удаление объектов. Когда из системы удаляется какой-либо объект, удаляются все объекты, для которых удаляемый объект является хозяином. Например, если мы удалим сервер sql.local из системы, все экземпляры SQL-сервера и все базы данных, расположенные на этом сервере, также будут удалены.

    В случае если объект не имеет hosted-отношений, он называет unhosted. Отличается он тем, что все правила и мониторы, нацеленные на unhosted-объекты, выполняются на RMS. Примером unhosted-класса является группа и класс Windows Computer. Кроме этого, значения набора ключевых свойств должны уникально идентифицировать объект в системе.

    Containment-отношения

    Containment-отношения определяют, что один объект может содержаться в другом объекте. Containment-отношения служат для двух целей: для создания зависимости одного объекта от другого и для создания групп. Примером такой зависимости в OpsMgr может служит лес AD и домен AD.

    Containment-отношения отличаются от hosting меньшими ограничениями: Containment являются отношением типа «многие-ко-многим», кроме этого объект может существовать без другого объекта, даже не смотря на установленные Containment-отношения.

    Reference-отношения

    Reference-отношения служат лишь для указания, что один объект каким-то образом связан с другим объектом, при этом оба объекта функционируют не зависимо друг от друга. Примером reference-отношений служит сайт AD и сайт-линк.

    Группы

    Одним из частных случаев классов и отношений является группа (Group). На вид группа – это обычная группа, какую мы привыкли её видеть, например, в AD. Но «внутри» она являет собой singleton-класс, у которого есть отношение типа containment.

    Группы в OpsMgr могут строиться по нескольким принципам:

    • Статические объекты, указанные администратором
    • Динамический запрос
    • Исключение

    При использовании статических объектов и исключений в правило формирования сontainment -отношения просто добавляются ID объектов, которые администратор указывает в GUI в свойствах группы. Используйте статическое членство в группах как можно реже, т.к. это затрудняет последующее обслуживание системы. Также старайтесь всегда в описании (description) оставлять пометку, для чего была создана та или иная группа.

    При использовании динамических запросов правило формирования contained-отношения полностью соответствует схеме формирования таких запросов, и будет рассмотрено в отдельной статье. Если кратко – для группы указывается правило, по которым объектов попадают в эту группу. Пример такого правила: Объект принадлежит к классу Windows Computer и находится в домене domain.local. Правила могут строиться на базе любого свойства объекта.

    В системе существует 2 вида групп: созданные на базе класса Instance Group (в GUI имеют иконку ), и созданные на базе Computer Group (в GUI имеют иконку ). Создание групп на базе Computer Group доступно только разработчикам МП. Все группы, создаваемые из GUI, создаются на базе класса Instance Group.

    Группы в OpsMgr могут использоваться для следующих целей (все они будут рассмотрены позднее отдельно):

    • В ролевой системе безопасности
    • В качестве цели для оверрайдов (но группы не стоит указывать в качестве цели для правил и мониторов, т.к. разворачивание группы не производится).
    • В представлениях для фильтрации выводимых объектов

    Отдельно хотелось пояснить п.2. Указывая целью для правил и мониторов группы, можно было бы предположить, что эти правила и мониторы будут применяться на членов этой группы, но это не происходит, т.к. группа сама по себе объект в системе. Поэтому нацеливая монитор или правило на группу, надо быть точно уверенным, что вам это необходимо, и вы понимаете что делаете. Я с ходу не могу придумать ситуации, когда это может потребоваться.

    У каждой группы в системе может существовать подгруппа (sub-group). Но это лишь не более, чем способ организовать хранение групп. Группа и подгруппа существуют отдельно, и правила основной группы не наследуются в подгруппе. Например, в системе есть группа DNS Forwarders, у которой есть две подгруппы DNS Conditional Forwarders и DNS Unconditional Forwarders.

    Discovery

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

    Discovery могут производить поиск экземпляров по большому числу правил: по значение реестра, по WMI-запросу, по результатам выполнения скрипта и т.д., при этом для обнаружения одного того же объекта может использоваться как одно, так и несколько правил одновременно.

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

    Возвращаясь к примеру с логическим диском, приведу пример, как строится его Discovery. Из модели известно, что класс Windows Server 2003 Logical Disk расположен на объекте класса Windows Computer. Согласно этой схеме, discovery должно находить объект класса Windows Server 2003 Logical Disk, все его свойства, а также устанавливать отношение между Windows Server 2003 Logical Disk и Windows Computer. Поиск дисков производится с помощью WMI-запросов, а их логичнее запускать на уровне ОС. Поэтому discovery настроено на запуск обнаружения на объекте Windows Server 2003 Operation System. Discovery анализирует выполнение WMI-запроса «Select * from Win32_LogicalDisk where DriveType = 2». Каждая возвращенная строка в этом запросе считается отдельным экземпляром класса Windows Server 2003 Logical Disk, а значение столбцов – свойствами класса. Кроме этого, discovery производит сопоставление отношений между объектом Windows Computer и Windows Server 2003 Logical Disk исходя из имени компьютера:

    В случае если между классами установлены hosting-отношения, обнаружение отношений может производиться автоматически. Примером может служить обнаружение экземпляров SQL-сервера. Между классами Windows Server установлено hosting-отношение с классом DB Engine, при этом Windows Server является хозяином (host). Discovery, которое производит поиск экземпляров класса DB Engine, запускается на объектах Windows Server. При этом явного создания отношений нет, а все связи OpsMgr создает автоматически:

    Кроме обнаружения, discovery отвечают также за обновление свойств и удаление объектов. Для примера давайте представим, что вы удалили SQL-сервер с компьютера. В итоге вы тут же получите огромное количество сообщений на консоль, и «красное» состояние сервера, т.к. OpsMgr пытается делать проверки установленного SQL-сервера, и естественно получает ошибки. Обычно возникает два вопроса – когда SQL-сервер удалится из OpsMgr, и как этого избежать в дальнейшем.

    Поиск экземпляров SQL-сервера производится по ключу в реестре, и после удаление SQL с сервера, этот ключ также удаляется. Когда в следующий раз запуститься discovery, он не обнаружит соответствующего ключа, и экземпляр будет считаться удаленным, и будет удален из системы (со всеми hosted-объектами). Период запуска Discovery можно посмотреть в свойствах, н-з для DB Engine он равен 14400 секундам (или каждые 4 часа):

    Т.е. вполне можно ожидать, что максимум через 4 часа экземпляр SQL-сервера будет удален из системы мониторинга.

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

    1. С помощью оверрайда отключить discovery на конкретном экземпляре (for a specified object of a class). Мастер сам предложит нужный класс. Оверрайды будут подробно рассмотрены позже.

    1. Подождать минут 5 для применения параметров.
    2. Из Operations Manager Shell запустить командлет Remove-DisabledMonitoringObject.
    3. Убедиться, что объект удален из системы.
    4. Произвести необходимые работы по деинсталяции.
    5. Удалить созданный оверрайд для того, чтобы включить оверрайд.

    У данного способа есть один большой минус: в случае, если на сервере установлено несколько экземпляров SQL, из мониторинга будут удалены все экземпляры (они добавятся обратно при следующем запуске discovery). Но при этом он позволяет удалять любые объекты, даже те, у которых Discovery написаны не верно – до сих пор такое иногда встречается, когда discovery не может обнаружить удаление объекта.

    Заключение

    На первый взгляд, многое из изложенного может показаться лишним для первоначального обучения, и необходимым лишь для разработчиков МП. Но на самом деле, понимание внутреннего устройства OpsMgr поможет вам лучше понять поведение системы в том или ином случае, и во многом избавит вас от вопросов «А почему это работает вот так, а не иначе?».

    В следующей статье мы рассмотрим модель «здоровья», которая используется в OpsMgr.

    Антон Гриценко ака FreemanRU

    opsmgr.ru

Комментарии

  1. ДОбрый день. Спасибо за статью — очень интересно.

    Антон, а вот здесь случайно не опечатка:

    В качестве другого примера можно рассмотреть SQL server. Каждая база данных обязательно размещена на каком-то экземпляре SQL -сервера, в то же время каждый экземпляр SQL-сервера расположен на Windows-компьютере. Получается два hosting-отношения: между классами SQL Database SQL Instance и между классами SQL Instance Windows Computer.

    Разве должно быть не: «... отношения: между классами SQL Database SQL Instance и между классами SQL Database Windows Computer».

    И еще — можете пояснить — чем принципиально отличаются отношения Hosting и Containment.

    Спасибо.

  2. «Такая рекомендация связана с тем, что на каждое изменение свойства объекта в отчетной базе данных (Data warehouse DB) создается новый экземпляр объекта (посмотреть изменение свойств затем можно через отчеты Configuration Changes в OpsMgr). Соответственно, частое обновление свойств класса приведет к росту базы данных.»

    То есть если у меня не установлен репортинг, то ничего страшного мне не грозит и я могу использовать любые свойства?

  3. to Pavel:

    Нет, не опечатка. На картинке черными стрелками показаны hosting-отношения. Database раположен на SQLInstance, а не самом компьютере.

    Ответ на второй вопрос я добавил в статью.

    то Иван:

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

  4. «В теории — да, но лучше воздержаться и делать сразу всё правильно, чтобы потом не наступить на грабли.»

    ЛОЛ. А теперь идите и погуглите на тему «opsmgr config churn». И перестаньте бредить.

  5. Именно эти «грабли» я и имел ввиду. Рад что тут есть знающие люди 😉

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

    У меня встречный вопрос, а вы на практике сталкивались с таким поведением?

  6. «Именно эти «грабли» я и имел ввиду.»

    Когда писали, что это «приведет к росту базы данных» потому что «на каждое изменение свойства объекта в отчетной базе данных (Data warehouse DB) создается новый экземпляр объекта»? Объясните мне связь между config churn и ростом DW? И особенно между написанным и тем, что вы имели в виду?

    Я даже подсказку дам: config churn это ситуация когда генерация конфигурации менеджмент группы выходит в бесконечный цикл (или близкий к тому, очень частый) вследствии чего появляются серьезные проблемы с _производительностью_ RMS и, возможно, еще и проблемы с апдейтом конфигурации агентов. Объясните мне как от этого страшно растет DW? А потом взрывается, да?

    Да, сталкивался.

  7. Скажем так, это встречается крайне редко. И в каждом конкретном случае лечится по своему. При этом иногда НЕОБХОДИМО выводить в свойства изменяющиеся параметры, но скажем просто их discovery производить редко (раз в день, или даже раз в несколько дней например).

    Рост базы данных и config churn — это РАЗНЫЕ проявления изменения значения параметров. И я повторюсь, второе встречается очень редко, и может лечиться не только отказом от таких свойств, но и изменением частоты discovery. Т.е. у вас может расти база, но не быть config churn.

  8. «Т.е. у вас может расти база, но не быть config churn.»

    Можете сказать какая таблица в DW растет при этом и на какие величины она может расти?

  9. Никакая таблица не растет при частых изменениях свойств объектов. Вырастает после дисковери новых и все тут.

    Просто меняются значения свойств.

    Пытливые умы могут попробовать поэксперементировать и последить за размером

    таблицы 'ManagedEntityProperty'.

    То что не растет, мнение исключительно субъективное, зачем ей это 🙂

  10. Саш, тогда уж поэксперементируй с представлением vManagedEntityPropertyChange. Это нагляднее.

    Хотя и ManagedEntityProperty тоже подходит, если сделать where DeltaXml is not null order by [ManagedEntityRowId].

    Что касается объема, то ПРИМЕРНО (я давно не занимаюсь SQL, так что где-то мог напутать с размером данных и страницы, кроме того XML не имеет фиксированного объема) он расчитывается по формуле:

    8192 * ((4+4+2000+800+8+8+8+8)%8192) * ObjectCount * DiscoveryInterval.

    Например 300 объектов при дискавери раз в час нагенерят за сутки чуть больше 50 метров данных. Причем объем будет расти при увеличении числа измененных свойств.

  11. И что в этом такого ужасного? Ну подрастает таблица. DW достаточно большая база данных, ей эти 50 (100, 500) мегабайт в сутки — ни о чем. Даже если умножить это не период хранения все равно по сравнению с ростом тех же таблиц с данными о производительности — ни о чем.

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

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

  12. Это как сказать. Например 480 объектов это всего-то 10 коммутаторов по 48 портов. И в системе с ~50 серверами, где весь DW за ГОД будет около 30 Gb, прирост в 250 метров в час как мне кажется гораздо бОльшая проблема, и главное более вероятная проблема, чем производительность. Увеличение нагрузки на RMS никто и не заметит, а вот увеличение базы данных в разы заметят, как только кончится место.

    Для примера можно привести DNS — Serial Number является свойством класса DNSZone, его дискавери идет раз в 4 часа. Соответственно меняется SN довольно часто, особенно для обратных зон. Но даже для 100 DNS-серверов, на каждом по 10-15 зон, никаких проблем с производительностью RMS не наблюдается.

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

    В любом случае, я считаю, что _основная_ причина шторма — не верная архитектура решения, а не неправильно написанный МП.

    Что касается ACS, то если вы его не настроите нормально, то да, он будет расти нереальными темпами. Но что правильного в непонимании вопроса фильтрации событий? Но это, как говорится, отдельная история.

  13. Да таки растет 🙁

    Да не критично, но факт остается фактом.

    И зачем хранить все предыдущие значения???

    Спасибо за статью. Для будущих опытных OpsMgr администраторов самое то.

    З.Ы. Где же ты был раньше (года 2 назад).

  14. Не нужно подменять понятия и передергивать цифрами, взятыми с потолка. Система с 50 серверами, DW в 30Гб и вдруг там 250 мегабайт в ЧАС появляется. При этом у вас "300 объектов при дискавери раз в час нагенерят за сутки чуть больше 50 " а потом сразу «480 объектов... прирост в 250 метров в час» (то есть за сутки примерно 6Гб). Объектов в полтора раза больше, а рост просто взрывной. Попугать тех, кто считать не умеет?

    А потом шторм приплели. При чем тут шторм? Alert Storm это резкое увеличение потока алертов. Либо вследствии большой пробемы в инфраструктуре, либо нехорошего МП. При чем здесь это? Чтобы было что сказать?

    Одно изменение (грубо говоря — строка в таблице это порядка двух килобайт данных, найдите базу, посмотрите). Ну, сами посчитаете сколько нужно объектов с плохими дискавери, чтобы нагенерить 250 МЕГАБАЙТ в ЧАС?

  15. Иван, может не надо троллить, человек решил написать цикл статей, таким как я, поверьте, очень необходимы. Ну знаете, напишите этот цикл статей сами. Возьметесь? Вряд ли. Это не для Вас статьи.

  16. А я разве сказал, что они не необходимы? Только вот после таких статей у новичков сложится неправильное понимание продукта и того, как он функционирует, которое потом будет ОЧЕНЬ сложно «переделать». Вы хотите понять как работает или наслушаться баек?

  17. Конечно, про 250 в ЧАС я описался, в день имелось ввиду конечно... Просто я видел МП, в которых дискавери раз в 15 минут собирало интерфейсы коммутаторов, при этом одно из свойств класса коммутатора постоянно менялось. Группа управления была не большой, и рост данных для них оказался существенным, гораздо больше, чем по любым расчетам.

    А при чем тут алерт шторм? я писал о config churn, просто перевод взял самый близкий по смыслу (ИМХО конечно), а не дословный.

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

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

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

  18. нормально написано...вернее по-русски...начинающим пригодится 🙂

  19. Антон — большое спасибо за статью!

    Иван — спасибо за инфу про реконфигурацию СКОМа, познавательно

  20. Антон — большое спасибо за статью!

    Иван — спасибо за инфу про реконфигурацию РМС, познавательно!

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

  22. от нескольких часов до пары суток.

  23. [...] наследование – можете прочитать мою статью “System Center Operations Manager 2007 R2 — Service Modeling”. Напомню, что SCSM наследует объектную модель от OpsMgr, [...]

  24. [...] наследование – можете прочитать мою статью “System Center Operations Manager 2007 R2 — Service Modeling”. Напомню, что SCSM наследует объектную модель от OpsMgr, [...]

  25. [...] немного теории. Если вы читали мою статью про OpsMgr, то должны знать, что все компоненты в пакете [...]

  26. «Я с ходу не могу придумать ситуации, когда это может потребоваться»

    Я могу) Когда мы мониторим сервера из разных доменов, и для каждого домена свои хотелки по настройкам оверрайдов. К сожалению, классам нельзя задать домен. Домен задается группам.

  27. Максим, вы не внимательно читали статью ) Речь идет о Target для мониторов и правил, а не оверайдах. То, о чем говорите вы — это как раз таи переопределения настроек.

Опубликовать

Я не робот.