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

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

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

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

1. Самое распространенное ограничение связано с памятью и операциями ввода-вывода на компьютере, работающем под управлением Microsoft SQL Server. Если у вас есть ресурсы, инвестируйте в увеличение памяти и повышение скорости подсистемы ввода-вывода, чтобы улучшить производительность ввода-вывода SQL Server.
2. Если вы ожидаете, что у вас есть множество консолей, подключающихся к серверу управления, можно повысить производительность, чтобы справиться с пиковой нагрузкой, вложив дополнительные ЦП и память для сервера управления или установив дополнительный сервер управления 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 миллисекунд (мс), общее время отклика консоли Service Manager считалось хорошим.

• При задержке в сети от 150 мс до 200 мс производительность была отмечена как приемлемая, при этом в некоторых сценариях зафиксировано до 40% снижение времени отклика. При задержке от 150 msec до 200 msec необходимо спланировать оценку ключевых сценариев для вашей организации и определить, является ли подключение к удаленному рабочему столу (RDC) лучшим вариантом.

  Примечание.

  Разворачивание схем обслуживания в консоли Service Manager происходило медленно при любом уровне задержки.

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

Следующие шаги

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