Каждому агенту для нормальной работы (а точнее – для того, чтобы он вообще заработал) необходимо иметь конфигурацию. Конфигурация – очень важная часть OpsMgr, так как именно она предписывает агенту что именно он должен наблюдать и как он должен это делать.
Конфигурация агента содержит информацию обо всех объектах, которыми он управляет (наблюдает за ними), об их взаимосвязях (relationships) и взаимосвязях с объектами, которыми данный агент не управляет (например, о группах, в которые входит данный объект, или родительских объектах).~~~
Формированием конфигурации для агентов занимается RMS, а если точнее, то работающая на нем служба Configuration. RMS поддерживает общую конфигурацию для менеджмент группы и управляет обновлением конфигурации конкретных агентов.
В общем случае процесс формирования конфигурации состоит из следующих операций:
- На агенте запускается процесс обнаружения (discovery), который находит экземпляр объекта
- Результат (данные об обнаруженых объектах и их взаимосвязях) передается на RMS
- RMS принимает результат и на его основе пересчитывает часть конфигурации, за которую отвечает только он (членство в группах, взаимосвязи с объектами, которыми управляет RMS и т.п.)
- RMS формирует новую конфигурацию для менеджмент группы и обновляет конфигурацию агентов, передавая агенту полный файл его конфигурации, а не только то, что изменилось
Как вы понимаете, любая из этих операций требует вычислительных ресурсов на том компьютере, на котором она выполняется. Поэтому неверное планирование при создании менеджмент паков (или неверное их использование и настройка) может приводить к заметному снижению производительности всей менеджмент группы (как менеджмент серверов, так и серверов, на которых установлены агенты и выполняются обнаружения(discovery)).
Как вы уже поняли – главный объект, который нас интересует в данном контексте – обнаружения (discoveries). Что же можно сделать, чтобы минимизировать негативное влияние на производительность? И чего не нужно делать, чтобы (опять же) не понизить производительность серверов?
Периодичость запуска
Слишком часто запускающийся модуль обнаружения может использовать относительно значительное количество ресурсов той машины, на кторой он запускается. В подавляющем большинстве случаев объекты, которые призван обнаружить discovery-модуль, не изменяются настолько часто, поэтому смысла в частом запуске обнаружения нет никакого. Особенно это верно для модулей, использующих большие сценарии.
Отключение ненужных обнаружений
В мененджмент паках от вендоров (Microsoft, DELL, IBM и т.п.) достаточно часто встречаются ресурсоемкие модули обнаружения (большие сценарии, например), которые нацелены на общие высокоуровневые классы. Например, на Windows Computer. Это ни в коем случае не ошибка дизайна, модуль должен искать свои объекты там, где теоретически они могут быть. Но администратор конкретной инфраструктуры может точно сказать, где определенных объектов в инфраструктуре его предприятия точно быть не может. Например, на контроллерах домена вашего предприятия нет и никогда не будет ни SQL Server, ни ConfigManager серверов. Поэтому для своей инфраструктуры вы можете благополучно отключить обнаружения SQL и ConfigMgr для группы Domain Controllers. После этого на контроллерах домена перестанут регулярно запускаться несколько ресурсоемких модулей и ресурсы сервера не будут расходоваться на обработку ненужных задач.
Определение часто изменяющихся свойств
При написании менеджмент пака (а конкретно – модулей обнаружения) не выбирайте в качестве аттрибутов класса часто изменяемые аттрибуты. То есть, например, если у вас есть класс “Файл”, то приемлимыми аттрибутами могут быть “имя” и “расширение”, но не “размер”.
Когда модуль обнаружения находит “свой” объект, он формирует его описание. То есть “экземпляр класса “файл” с аттрибутами “имя”=”MyFile” и “расширение”=”.doc”. Затем модуль сравнивает эти данные с данными предыдущего цикла обнаружения (данные, собраные во время предыдущего запуска модуля обнаружения, хранятся в кэше агента) и только если данные в чем-то изменились они отправляются на RMS. Если ничего не менялось – агент ничего не отправляет (не путайте “ничего не отправляет” и “отправляет пустой discovery-пакет”!). Соответственно, если одно из свойств часто изменяется (как, например, размер файла) – данные будут часто отправляться на RMS, вызывая частые обновления конфигурации. По этой же причине крайне не рекомендуется использовать incremental discovery в общем случае, а только тогда, когда без него совсем нельзя обойтись.