Планирование дизайна группы управления

Обзор

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

Простейшая реализация Operations Manager — это одна группа управления. Для каждой дополнительной группы требуется по крайней мере собственная операционная база данных и сервер управления. Каждая группа также должна поддерживаться отдельно с собственными параметрами конфигурации, пакетами управления и интеграцией с другими решениями для мониторинга и ITSM.

Реализация распределенной группы управления формирует основу 99 процентов развертываний Operations Manager. Он позволяет распространять функции и службы на нескольких серверах, чтобы обеспечить масштабируемость и избыточность некоторых этих функций. Он может включать все роли сервера Operations Manager и поддерживает мониторинг устройств через границы доверия с помощью сервера шлюза.

На следующей схеме представлен один возможный вариант топологии распределенной группы управления.

Примечание.

Прямой обмен данными между консолью управления и базами данных отсутствует. Все взаимодействие направляется на конкретный сервер управления через порт TCP 5724, а затем на серверы баз данных с помощью OLE DB в TCP 1433 или определяемом пользователем порту, указанном администратором SQL во время установки экземпляра ядра СУБД SQL Server. Однако существует прямая связь между консолью диагностики приложений (совместно размещенной с веб-консолью) и SQL Server, в котором размещаются операционные базы данных и базы данных хранилища данных.

Группа управления, развернутая в вашей среде, может интегрироваться с Microsoft Operations Management Suite (OMS) и с помощью Log Analytics, можно дополнительно сопоставить, визуализировать и действовать на производительности, событиях и оповещениях. Это обеспечивает повышенную видимость, обеспечивая возможность выполнять пользовательские поиски по всему набору данных для сопоставления данных между системами и приложениями, размещенными в локальной среде или в облаке.

Интеграция с Operations Manager распространяется на другие продукты, такие как BMC Remedy, IBM, Netcool или другие корпоративные решения для управления, используемые вашей организацией. Дополнительные сведения о планировании взаимодействия с этими решениями см. в руководстве по интеграции с другими решениями по управлению.

Компоненты группы управления

Сервер управления

В Operations Manager 2007 корневой сервер управления (RMS) был специализированным типом сервера управления в группе управления и был первым сервером управления, установленным в группе управления. RMS был центром администрирования конфигурации группы управления, администрирования и взаимодействия с агентами, а также взаимодействия с операционной базой данных и другими базами данных в группе управления. RMS также выступает в качестве целевого объекта для консоли управления и предпочтительного целевого объекта для веб-консоли. В System Center 2012 R2 — Operations Manager роль корневого сервера управления была удалена, а все серверы управления теперь одноранговые. Эта конфигурация продолжает существовать в System Center 2016 и более поздних версиях — Operations Manager.

RMS больше не является одной точкой сбоя, так как все серверы управления размещают службы, ранее размещенные только RMS. Роли распространяются на все серверы управления. Если один сервер управления становится недоступным, его функции автоматически перераспределяются. Роль эмулятора корневого сервера управления обеспечивает обратную совместимость для тех пакетов управления, целью которых являлся корневой сервер управления. Если у вас нет пакетов управления, предназначенных ранее для RMS, вам не потребуется использовать эмулятор RMS.

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

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

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

Типичный сервер управления будет обрабатывать примерно 3000 агентов. Фактическая производительность сервера зависит от объема собранных операционных данных; однако серверы управления обычно могут поддерживать 3000 агентов каждый, даже с относительно высоким объемом операционных данных.

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

Серверы управления должны иметь хорошее сетевое подключение к базе данных Operations Manager и хранилищу данных, так как они часто отправляют большие объемы данных в эти хранилища. Как правило, эти подключения SQL Server потребляют больше пропускной способности и более чувствительны к задержке сети. Поэтому все серверы управления должны находиться в той же локальной сети, что и операционная база данных и база данных хранилища данных, и никогда не развертываются в широкой сети. Между сервером управления и экземпляром SQL Server, на котором размещены базы данных Operations Manager, должно быть меньше 10 миллисекунд задержки.

Сервер шлюза

Operations Manager требует выполнения взаимной проверки подлинности между агентами и серверами управления перед обменом информацией между ними. Чтобы защитить процесс проверки подлинности, выполняется его шифрование. Если агент и сервер управления размещены в одном домене Active Directory или в доменах Active Directory, в которых установлено отношение доверия, они используют механизмы проверки подлинности Kerberos V5, предоставленные Active Directory. Если агенты и серверы управления не находятся в пределах той же границы доверия, другие механизмы должны использоваться для удовлетворения требования безопасной взаимной проверки подлинности.

Серверы шлюзов используются, когда брандмауэр отделяет агенты от серверов управления или когда агенты находятся в отдельном недоверенном домене. Сервер шлюза выступает в качестве прокси-сервера между агентами и сервером управления. Без сервера шлюза агенты по-прежнему могут выполнять проверку подлинности сертификатов с сервером управления, но сертификат X.509 должен быть выдан и установлен на каждом агенте с помощью средства MOMCertImport.exe, и каждому из них потребуется доступ к серверу управления через брандмауэр. Если агенты находятся в том же домене, что и сервер шлюза или если они находятся в доверенном домене, они могут использовать проверку подлинности Kerberos. В этом случае только сервер шлюза и подключенные серверы управления потребуют сертификатов. Это включает мониторинг виртуальных машин, работающих в инфраструктуре Microsoft Azure как услуга (IaaS), с Помощью Operations Manager (то есть гибридного облачного мониторинга), которые не присоединены к той же доверенной области, что и роли, поддерживающие группу управления Operations Manager, или вы развернули Operations Manager в Azure IaaS (виртуальная машина с SQL Server, на которой размещена операционная база данных и одна или несколько виртуальных машин, на которых размещена роль сервера управления) и отслеживаются ненадежными. локальные рабочие нагрузки.

Ниже приведен пример мониторинга ресурсов Azure IaaS для развертывания Operations Manager.

Ниже приведен пример развертывания Operations Manager, размещенного в Azure IaaS.

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

• Наличие более 2000 агентов на сервер шлюза может негативно повлиять на возможность восстановления в случае устойчивого сбоя, который предотвращает взаимодействие сервера шлюза с сервером управления. Рекомендуется использовать несколько серверов шлюза, если требуется более 2000 агентов. Альтернатива, если время восстановления сервера шлюза является проблемой, заключается в тестировании системы, чтобы убедиться, что сервер шлюза может быстро очистить очередь после устойчивого сбоя между сервером шлюза и сервером управления. Кроме того, после заполнения входящей очереди на сервере шлюза данные в очереди удаляются в соответствии со своим приоритетом, что означает, что устойчивый сбой сервера шлюза в этом сценарии может привести к потере данных.
• При наличии большого количества агентов, подключенных через серверы шлюза, рекомендуется использовать выделенный сервер управления для всех серверов шлюза. При подключении всех серверов шлюза к одному серверу управления без других агентов, подключенных к нему, может ускорить восстановление в случае устойчивого сбоя. Эффективная нагрузка на сервер управления — это общее количество агентов, сообщаемых ему напрямую или через серверы шлюза.
• Чтобы предотвратить взаимодействие сервера шлюза с сервером управления, в том числе при настройке отработки отказа между несколькими серверами управления для обеспечения высокой доступности, средство утверждения шлюза включает аргумент командной строки /ManagementServerInitiatesConnection. Это позволяет Operations Manager соответствовать политике безопасности клиента, если системы развертываются в dmZ или другой сетевой среде и обмен данными можно инициировать только из интрасети.

Сервер веб-консоли

Веб-консоль предоставляет интерфейс для группы управления, доступной через веб-браузер. Она не имеет полной функциональности консоли управления и предоставляет доступ только к представлениям "Мониторинг" и "Моя рабочая область". Веб-консоль предоставляет доступ ко всем данным мониторинга и задачам, которые могут выполняться на отслеживаемых компьютерах из консоли управления. Доступ к данным в веб-консоли имеет те же ограничения, что и доступ к содержимому в консоли управления.

Сервер отчетов

Отчеты для System Center — Operations Manager устанавливаются в службах SQL Server Reporting Services (которая поддерживается версией Operations Manager, которую вы используете), а единственная допустимая конфигурация служб Reporting Services, поддерживаемая Operations Manager Reporting, является собственным режимом.

Примечание.

Установка System Center — Operations Manager Reporting Services интегрирует безопасность экземпляра служб SQL Reporting Services с безопасностью на основе ролей Operations Manager. Не устанавливайте другие приложения Служб Reporting Services в этом же экземпляре SQL Server.

Компоненты сервера отчетов Operations Manager можно установить на том же сервере, на котором запущены службы SQL Server 2014 или 2016 Reporting Services или на другом компьютере. Для оптимальной производительности, особенно в корпоративной среде с большим объемом, параллельного создания отчетов пользователями при одновременной обработке интерактивных или запланированных отчетов необходимо увеличить масштаб, чтобы обрабатывать больше одновременных пользователей и более крупные нагрузки на выполнение отчетов. Рекомендуется, чтобы служба отчетов Operations Manager не была совместно размещена в том же SQL Server, где размещена база данных хранилища данных и установлена в выделенной системе.

Рабочая база данных

Операционная база данных — это база данных SQL Server, содержащая все операционные данные, сведения о конфигурации и правила мониторинга для группы управления. База данных Operations Manager является одним источником сбоя для группы управления, поэтому ее можно сделать высокодоступной с помощью поддерживаемых конфигураций кластеризации.

Чтобы сохранить эту базу данных в согласованном размере, параметры очистки в Operations Manager указывают продолжительность хранения данных в ней. По умолчанию эта длительность составляет семь (7) дней.

База данных хранилища данных отчетов

Хранилище данных отчетов — это база данных SQL Server, которая собирает и сохраняет операционные данные для долгосрочных отчетов. Эти данные записываются непосредственно из правил, которые собирают данные для отчета и из процессов синхронизации данных в операционной базе данных. Обслуживание хранилища данных, включая агрегирование, очистку и оптимизацию, выполняется автоматически Operations Manager.

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

Набор данных	Тип агрегирования	Период хранения (в днях)
Предупреждение	Необработанные	400
Мониторинг клиентов	Необработанные	30
Мониторинг клиентов	Ежедневно	400
События	Необработанные	100
Производительность	Необработанные	10
Производительность	Почасовая	400
Производительность	Ежедневно	400
State	Необработанные	180
State	Почасовая	400
State	Ежедневно	400

Хранилище данных может обслуживать несколько групп управления. Это позволяет одному отчету включать данные со всех компьютеров в организации.

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

Сборщик ACS

Сборщик ACS принимает и обрабатывает данные событий от серверов пересылки ACS и затем отправляет эти данные в базу данных ACS. Эта обработка включает распаковку данных, чтобы она была распределена по нескольким таблицам в базе данных ACS, минимизируя избыточность данных и применяя фильтры, чтобы ненужные события не добавлялись в базу данных ACS.

База данных ACS

База данных ACS – это центральный репозиторий для данных событий, формируемых политикой аудита в рамках развертывания служб ACS. База данных ACS может размещаться на одном компьютере со сборщиком ACS, но ради повышения производительности каждый из этих компонентов следует устанавливать на отдельном сервере. По умолчанию данные хранятся в течение 14 дней.

Средство пересылки ACS

Служба, выполняемая на серверах пересылки ACS, включается в агент Operations Manager. При установке агента Operations Manager эта служба по умолчанию устанавливается, но не включается. Эту службу можно включить для нескольких компьютеров агента одновременно с помощью задачи "Включить сбор аудита" или с помощью PowerShell. После включения этой службы данные всех событий безопасности отправляются не только в локальный журнал безопасности, но и на сборщик ACS.

Рекомендации по проектированию

При принятии решения о реализации одной или нескольких групп управления следует учитывать следующие факторы:

• Увеличена емкость. Operations Manager не имеет встроенных ограничений в отношении количества агентов, которые может поддерживать одна группа управления. В зависимости от используемого оборудования и нагрузки мониторинга (больше пакетов управления, развернутых, означает более высокую нагрузку мониторинга) в группе управления, может потребоваться несколько групп управления для обеспечения приемлемой производительности.
• Консолидированные представления. При использовании нескольких групп управления для мониторинга среды необходимо обеспечить консолидированное представление данных мониторинга и оповещения от них. Это можно сделать, развернув дополнительную группу управления (которая может или не иметь каких-либо обязанностей по мониторингу), которая имеет доступ ко всем данным во всех других группах управления. Затем эти группы управления будут подключены. Группа управления, используемая для предоставления консолидированного представления данных, называется локальной группой управления, а другие, предоставляющие данные для него, называются подключенными группами управления.
• Безопасность и администрирование. Секционирование групп управления по соображениям безопасности и администрирования аналогично делегированию административного органа по подразделениям Active Directory или доменам в разные административные группы. Ваша компания может включать несколько ИТ-групп, каждая из которых имеет собственную область ответственности. Область может быть определенной географической областью или бизнес-отделом. Например, в случае с холдинговой компанией это может быть одна из дочерних компаний. Если этот тип полного делегирования административного органа из централизованной ИТ-группы существует, может оказаться полезным реализовать структуру группы управления в каждой из областей. Затем их можно настроить как подключенные группы управления в локальную группу управления, которая находится в централизованном ИТ-центре обработки данных.
• Установленные языки. Все серверы с ролью сервера Operations Manager, установленной на них, должны быть установлены на одном языке. То есть вы не можете установить сервер управления с помощью английской версии Operations Manager 2012 R2, а затем развернуть консоль управления с помощью японской версии. Если мониторинг должен охватывать несколько языков, для каждого языка операторов потребуется дополнительная группа управления.
• Функциональные возможности рабочей и предварительной версии. В Operations Manager рекомендуется использовать рабочую реализацию, которая используется для мониторинга рабочих приложений и предварительной реализации, которая имеет минимальное взаимодействие с рабочей средой. Перед переносом в рабочую среду группа управления используется для тестирования и настройки функций пакета управления. Кроме того, некоторые компании используют промежуточную среду для серверов, на которых недавно созданные серверы помещаются на период хранения до размещения в рабочей среде. Предварительная группа управления может использоваться для мониторинга промежуточной среды, чтобы обеспечить работоспособность серверов до развертывания рабочей среды.
• Выделенные функции ACS. Если ваши требования включают необходимость сбора событий журнала безопасности Windows или событий безопасности UNIX/Linux, вы будете реализовывать службу сбора аудита (ACS). Возможно, полезно реализовать группу управления, которая поддерживает функцию ACS исключительно в том случае, если требования к безопасности вашей компании требуют, чтобы функция ACS контролировалась и администрируется административной группой, отличной от той, которая управляет остальной частью рабочей среды.
• Функции аварийного восстановления. В Operations Manager все взаимодействия с базой данных Operations Manager записываются в журналы транзакций до фиксации в базе данных. Эти журналы транзакций можно отправить на другой сервер под управлением Microsoft SQL Server и зафиксировать в копию базы данных Operations Manager. Эта функция позволяет обеспечить избыточность операционной базы данных Operations Manager между двумя серверами SQL Server в одной группе управления. При выполнении управляемой отработки отказа серверы управления в группе управления требуют изменения реестра, чтобы ссылаться на вторичный SQL Server и взаимодействовать с ним. Можно развернуть группу управления отработкой отказа, которая соответствует точной конфигурации основной группы управления (пакетов управления, переопределений, подписок уведомлений, безопасности и т. д.), а агенты настроены для отчетов обеим группам управления. Если основная группа управления в целом становится недоступной по какой-либо причине, время простоя среды мониторинга отсутствует. Это решение обеспечивает непрерывность службы группы управления и нулевой потери операционного мониторинга.

Перед развертыванием System Center Operations Manager в рабочей среде запланируйте проектирование группы управления. На этапе планирования вы узнаете о компонентах ИТ-службы (т. е. инфраструктуре и уровне приложений) и количестве систем и устройств, поддерживающих их, о том, как они интегрируются и поддерживают процессы управления инцидентами и проблемы, а также о том, как визуализировать данные для различных уровней поддержки эскалации инцидентов, инженеров, потребителей служб и управления.

Подключенные группы управления

Многие предприятия с серверами в нескольких географических расположениях требуют централизованного мониторинга этих серверов. Конфигурация подключенной группы управления, показанная на рисунке ниже, представляет собой набор рабочих процессов, предназначенных для создания иерархической инфраструктуры управления системами.

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

Подключая группы управления Operations Manager, централизованные функции мониторинга можно поддерживать одновременно.

• Мониторинг большего количества объектов управления, чем это возможно с помощью одной группы управления.
• Изоляция действий мониторинга в соответствии с логическими бизнес-подразделениями, такими как "Маркетинг" или физические расположения, такие как Рим.

При подключении групп управления не развертываются новые серверы. Вместо этого локальной группе управления предоставляется доступ к предупреждениям и сведениям об обнаружении устройств, имеющимся в подключенной группе управления. Таким образом обеспечивается возможность просматривать и взаимодействовать со всеми предупреждениями и другими данными мониторинга, поступающими из нескольких групп управления, в одной консоли управления. Помимо этого можно выполнять задачи на отслеживаемых компьютерах подключенных групп управления. Сведения о подключении групп управления см. в статье "Подключение групп управления" в Operations Manager.

Установленные языки

Группы управления Operations Manager поддерживают только один установленный язык. Если в общей ИТ-среде, которую требуется отслеживать, используется несколько установленных языков, для каждого языка потребуется создание отдельной группы управления.