Планирование производительности оборудования 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 миллисекунд (msec), было найдено общее время отклика консоли Service Manager.

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

  Примечание.

  Развертывание карт служб в консоли Service Manager было медленным с любой задержкой.

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

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

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