Планирование производительности Service Manager оборудования

Статья
03/18/2024

Важно!

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

Важная часть System Center — Service Manager производительность зависит от конфигурации оборудования и топологии развертывания, которая планируется удовлетворить потребности вашей организации. В следующих разделах приведены общие рекомендации, которые следует учитывать при планировании достаточной производительности оборудования.

Производительность оборудования

Ниже приведены аппаратные узкие места, которые наиболее заметны в Service Manager с значительной нагрузкой и объемом данных в базе данных Service Manager.

Самое распространенное ограничение связано с памятью и операциями ввода-вывода на компьютере, работающем под управлением Microsoft SQL Server. Если у вас есть ресурсы, инвестиции в больший объем памяти и более быструю подсистему ввода-вывода для улучшения SQL Server ввода-вывода позволят повысить производительность.
Если предполагается, что к серверу управления подключается множество консолей, можно повысить производительность для обработки пиковой нагрузки, инвестируя в дополнительные ЦП и память для сервера управления или установив дополнительный сервер управления Service Manager.

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

Роль виртуальных машин

Во многих организациях для размещения приложений Windows Server используются виртуальные машины. Service Manager роли сервера, такие как сервер управления и сервер хранилища данных, не являются исключениями. Виртуальные машины можно использовать как для всех ролей сервера, так и для любых других комбинаций виртуальных и физических компьютеров.

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

Серверы баз данных уязвимы к низкой производительности на виртуальных машинах, если не соблюдаются следующие рекомендации по планированию:

Выполнение SQL Server в среде Hyper-V.
На виртуальных машинах, предназначенных для размещения SQL Server, нельзя использовать динамические диски. Используйте жесткие диски с фиксированным размером или транзитные диски.
Hyper-V допускает только четыре виртуальных ЦП на одного гостя, что может ограничить Service Manager сервер, если у вас много консолей.

Service Manager базовых результатов тестирования

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

База данных предварительно заполнялась сведениями для двух тестов.

Тест 1 включал 20 000 компьютеров, 20 000 пользователей и все необходимые элементы конфигурации, что составило около 250 000 элементов конфигурации примерно в 2,5 млн. строк в базе данных. Тест 1 также включал 40 активных Service Manager консолей.
Тест 2 включал 50 000 компьютеров, 50 000 пользователей и все необходимые элементы конфигурации, что составило около 700 000 элементов конфигурации примерно в 6 млн. строк в базе данных. Тест 2 также включал 80 активных Service Manager консолей.

Тесты продемонстрировали следующие результаты.

Чтобы удовлетворить требования к времени отклика для конфигурации из 50 000 компьютеров, пришлось увеличить память SQL Server с 8 до 32 ГБ.
Во время тестирования каждый час создавалось 200 инцидентов и 50 запросов на изменение для конфигурации из 20 000 компьютеров, а для конфигурации из 50 000 компьютеров — 500 инцидентов и 125 запросов на изменение; для каждого инцидента и запроса на изменение обрабатывалось от трех до четырех подписок на уведомления и шаблонов.
Обычно в базовом тестировании такие рабочие процессы, как обработка подписки на уведомления и приложения шаблона, выполнялись в пределах одной минуты для каждого созданного рабочего элемента.

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

Однако если вы планируете добавить дополнительные поддерживаемые компьютеры в базу данных Service Manager, следует запланировать увеличение объема ОЗУ для сервера базы данных Service Manager за пределы минимальных требований, перечисленных в этом документе. Например, в базовом тесте было установлено 8 ГБ ОЗУ на сервере базы данных Service Manager, который содержал записи для 20 000 компьютеров. Позднее при каждом увеличении планируемого числа поддерживаемых компьютеров на 10 000 следует добавлять по 8 ГБ ОЗУ. Например, для 50 000 компьютеров необходимо запланировать 32 ГБ ОЗУ. При тестировании конфигурации из 50 000 компьютеров с 32 ГБ ОЗУ на компьютере под управлением SQL Server производительность была улучшена так, что эффект понижения производительности по сравнению с состоянием тестируемой конфигурации до добавления дополнительных компьютеров отсутствовал.

В базовых тестах проверялась также задержка в сети. Задержка сети между консолью Service Manager и сервером управления Service Manager.

Примечание

Сервер базы данных Service Manager и серверы управления Service Manager должны находиться в локальной сети с низкой задержкой. Задержка сети между сервером базы данных Service Manager и сервером управления Service Manager может привести к значительному ухудшению Service Manager Производительности.

Тесты также продемонстрировали следующие результаты.

Если задержка сети была менее 100 миллисекунд (msec), общее время отклика Service Manager консоли было найдено хорошим.
Если задержка в сети составляла от 150 мс до 200 мс, производительность была отмечена как пригодная для использования, с снижением времени отклика до 40 процентов в некоторых сценариях. С задержкой от 150 мс до 200 мс следует запланировать оценку ключевых сценариев для вашей организации и определить, является ли подключение к удаленному рабочему столу (RDC) лучшим вариантом.

Примечание

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

Дальнейшие действия

Чтобы ознакомиться с общими рекомендациями, которые следует учитывать при планировании производительности Service Manager программного обеспечения, ознакомьтесь с Service Manager производительности.