Планирование структуры группы управления

Важно!

Поддержка этой версии Operations Manager завершена. Рекомендуется выполнить обновление до Operations Manager 2022.

Обзор

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

Простейшая реализация 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.

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

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

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

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

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

Серверы управления должны иметь хорошее сетевое подключение к базе данных и хранилищу данных Operations Manager, так как они часто отправляют большие объемы данных в эти хранилища. Как правило, такие подключения SQL Server потребляют больше пропускной способности и более чувствительны к задержке в сети. Таким образом, все серверы управления должны размещаться в той же локальной сети, что и рабочая база данных и база данных хранилища данных, и ни в коем случае не распределяться по глобальной сети. Задержка между сервером управления и экземпляром SQL, на котором хранится база данных 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 размещение операционных баз данных и одной или нескольких виртуальных машин с ролью сервера управления) и мониторинг недоверенных локальных рабочих нагрузок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dataset	Тип статистической обработки	Период хранения (в днях)
Предупреждение	Raw	400
Отслеживание клиентов	Raw	30
Отслеживание клиентов	Ежедневно	400
События	Raw	100
Производительность	Raw	10
Производительность	Каждый час	400
Производительность	Ежедневно	400
Область	Raw	180
Область	Каждый час	400
Область	Ежедневно	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 в одной группе управления. Если необходимо реализовать управляемую отработку отказа, на серверах управления в группе управления потребуется внести изменения в реестр для взаимодействия с сервером-получателем SQL Server. Можно развернуть группу управления отработкой отказа, которая точно соответствует конфигурации основной группы управления (пакеты управления, переопределения, подписки на уведомления, безопасность и т. д.), а агенты настроены для передачи отчетов обеим группам управления. Если основная группа управления в целом по какой-либо причине становится недоступной, простоя среды мониторинга нет. Это решение обеспечивает непрерывность обслуживания группы управления и отсутствие потерь данных мониторинга.

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

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

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

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

За счет подключения групп управления Operations Manager можно поддерживать централизованное наблюдение одновременно со следующими операциями:

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

При подключении групп управления вы не развертываете новые серверы; вместо этого вы разрешаете локальной группе управления доступ к оповещениям и сведениям об обнаружении, которые есть в подключенной группе управления. Таким образом обеспечивается возможность просматривать и взаимодействовать со всеми предупреждениями и другими данными мониторинга, поступающими из нескольких групп управления, в одной консоли управления. Помимо этого можно выполнять задачи на отслеживаемых компьютерах подключенных групп управления. Информацию о подключении групп управления см. на странице Connecting Management Groups in Operations Manager (Подключение групп управления в Operations Manager).

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

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