Поделиться через

System Center — производительность Service Manager

  • Статья

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

  • Скорость реагирования консоли Service Manager. Время, которое проходит от момента, когда будет предпринят какой-либо вид действия в консоли, до момента выполнения этого действия.

  • Время вставки данных для соединителей. Это то, сколько времени требуется для service Manager для импорта данных при синхронизации соединителя.

  • Время завершения рабочего процесса. Время, которое затрачивается рабочими потоками на автоматическое применение какого-либо вида действия.

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

Начальная синхронизация соединителя может занять значительное время; Например, от 8 до 12 часов для большой начальной синхронизации с Configuration Manager. Как соединитель изначально синхронизируется, производительность может страдать от всех ролей и процессов сервера Service Manager в это время. Это происходит из-за того, как данные вставляются последовательно в базу данных Service Manager, которая является базой данных Microsoft SQL Server. Хотя вы не можете ускорить начальный процесс синхронизации соединителя, вы можете спланировать начальную синхронизацию и убедиться, что процесс синхронизации выполняется хорошо, прежде чем Service Manager будет помещен в рабочую среду.

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

Производительность рабочего процесса

Рабочие процессы — это процессы, выполняемые автоматически. К ним относится отправка уведомлений по электронной почте, переход на следующий этап активации запроса на изменение и автоматическое применение шаблона.

Ниже перечислены факторы, влияющие на производительность рабочих процессов.

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

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

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

Влияние группы, очереди и роли пользователя на производительность

Следует как можно раньше планировать группы и пользовательские роли. Группы необходимо создавать, исходя из соображений экономии, в том числе создавая их для минимально возможной области. Затем перед созданием групп необходимо заполнить базу данных данными из служб домен Active Directory (AD DS), Configuration Manager и System Center Operations Manager.

Часто администраторы создают группы, чтобы пользователи имели доступ только к указанным группам. Например, в некоем сценарии может потребоваться создать подмножество инцидентов, например инцидентов, влияющих на компьютеры сотрудников отдела кадров. В этом сценарии можно разрешить возможность просмотра или изменения группы конфиденциальных серверов только определенным сотрудникам. Затем, чтобы разрешить такой тип доступа, потребуется создать группу для всех пользователей и группу для конфиденциальных компьютеров, а затем обеспечить доступ роли безопасности к группе всех пользователей и к группе конфиденциальных серверов. Неизбежно создание группы, содержащей всех пользователей, приводит к влиянию на производительность, так как Service Manager часто проверяет наличие изменений в группе. Такие проверки выполняются по умолчанию каждые 30 секунд. Для большой группы проверка изменений создает тяжелую нагрузку на систему, и она может значительно замедлить время отклика.

Решение 1. Вы можете вручную указать, как часто Service Manager проверяет изменения группы, изменив раздел реестра. Например, если задать частоту проверок не каждые 30 секунд, а каждые 10 минут, можно существенно повысить производительность. Тем не менее очереди и цели уровня обслуживания — это специальные типы групп, которые используют один интервал опроса вычисления группы. Таким образом, увеличение значения интервала опроса приводит к увеличению времени для вычислений на уровне очереди и уровня обслуживания.

Внимание

Неверное редактирование реестра может привести к серьезным повреждениям системы. Перед внесением изменений в реестр рекомендуется создать резервную копию всех важных данных.

Вручную укажите интервал проверки изменения группы

  1. Запустите regedit и перейдите к HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Создайте новое значение DWORD с именем GroupCalcPollingIntervalMilliseconds.

  3. Укажите значение интервала в миллисекундах. Результат умножается на 6. Например, чтобы задать интервал в 10 минут, введите 600000.

  4. Перезапустите службу управления System Center.

Решение 2. Вы можете использовать скрипт Windows PowerShell для добавления объектов типа, например "Пользователи", в роль пользователя. По сути, аналитик, вошедший в систему в этой роли, может получить доступ ко всем объектам, имеющим тип, равным "User". Если вы используете этот метод, удалите необходимость в большой группе ("Все пользователи") и дорогой проверке того, что Service Manager выполняет определение членства в этой группе. На сервере управления Service Manager можно запустить следующий скрипт Windows PowerShell, чтобы добавить тип пользователя в роль RoleName. Вы должны изменить этот пример скрипта для вашей среды.

Запуск скрипта Windows PowerShell для добавления объектов в роль пользователя

  • При необходимости измените следующий сценарий, а затем запустите его:
#  
# Insert a "type" scope in a role  
# Syntax:  
#   AddTypeToRoleScope -server "put_server_name_here" -RoleName "put display name of the role here" -TypeToAdd "put display name of the type to add to scope here"  
#  
# Note:  This is a simple demonstration script without error checking.   
#   

# set script parameter defaults  
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")  

$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")  

$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server   

# Get Type object  
#   Note:  If you need to get a list of all available classes related to (for example) "User",   use this command:  
#               $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}  
#  
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}  

# Get role object, and insert the type GUID into scope  
$role = $m.Security.GetUserRoles()  | ?{ $_.DisplayName -eq $RoleName}  
$role.Scope.Objects.Add($type.Id)     
$role.Update()  

#   
# Get the value from the database again and validate it is there  
if ( $role.scope.objects.Contains($type.Id) ) {  
    write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)  
} else {  
    write-host "There was an error trying to insert the scope into the role."  
}

Просмотр производительности

При создании представлений планируйте использование "типичных" классов в системе всякий раз, когда это возможно. Большинство классов объектов, например, "Управление инцидентами" имеет два типа: "типичный" и "расширенный". Стандартный тип объекта содержит простые ссылки на небольшое подмножество данных, относящихся к элементу. Расширенный тип содержит много сложных ссылок на данные, относящиеся к элементу. Стандартные типы — это простые проекции, расширенные типы — это сложные проекции. Большинство расширенных типов объектов используются для заполнения различных полей в формах, которые обычно не нужно отображать в представлении. При создании представления на основе расширенного типа объекта и при открытии представления Service Manager запрашивает базу данных и большой объем данных считывается. Однако очень мало извлеченных данных отображается или используется.

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

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

Производительность базы данных Service Manager напрямую влияет на различные факторы, включая количество одновременных консолей Service Manager, которые считывают или записывают данные, интервал проверки изменения группы и данные, вставляемые соединителями. В этом документе даются дополнительные сведения. Далее приведено несколько основных моментов.

  • У вас должно быть не менее 8 гигабайт (ГБ) ОЗУ для сервера управления, в котором размещена база данных Service Manager, чтобы иметь допустимое время отклика в типичных сценариях.

  • На компьютере с базой данных Service Manager должно быть не менее 8 ядер ЦП.

  • Можно улучшить производительность, по возможности размещая файлы журналов и файлы данных на разных физических дисках. Вы можете добиться дополнительных преимуществ, переместив tempdb на другой физический RAID-диск, отличный от базы данных Service Manager. По возможности используйте дисковую систему RAID 1+0 для размещения базы данных Service Manager.

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

Дополнительные сведения об оценке размера базы данных см. в вспомогательном средстве service Manager, включенном в набор документации по заданию Service Manager (SM_job_aids.zip), чтобы оценить размер базы данных и создать базу данных с размером, который ближе к окончательному размеру. Это поможет повысить производительность, уменьшая количество операций автоматического увеличения базы данных.

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

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

Производительность сервера управления Service Manager в основном зависит от количества активных параллельных консолей Service Manager. Так как все роли Service Manager взаимодействуют с сервером управления, рекомендуется добавить дополнительные серверы управления, если планируется иметь большое количество одновременных консолей. Для сервера управления требуется 8 ГБ ОЗУ. У вас должно быть не менее 4 ядер ЦП на сервере управления, если у вас есть 10–12 активных консолей на ядро ЦП.

Производительность консоли Service Manager

Производительность консоли Service Manager в первую очередь зависит от количества форм, открытых аналитиками и объема данных, полученных представлениями. У вас должно быть 4 ГБ ОЗУ на компьютере, на котором установлена консоль Service Manager. Если у вас есть представления, которые извлекают большой объем данных, потребуется дополнительная ОЗУ. Для компьютера, на котором установлена консоль Service Manager, должен быть по крайней мере 4-ядра ЦП. Так как консоль Service Manager является конечным пользователем приложением, рекомендуется перезапустить его, если вы видите чрезмерное потребление ресурсов. Консоль Service Manager агрессивно кэширует сведения в памяти, что может способствовать общему использованию памяти.

Производительность базы данных хранилища данных Service Manager

Производительность хранилища данных непосредственно влияет на различные факторы, включая количество одновременных серверов управления Service Manager, отправляющих данные, объем данных, хранящихся или период хранения данных, скорость изменения данных, а также частоту извлечения, преобразования и загрузки (ETL). Объем данных в хранилище данных со временем возрастает. Важно архивировать ненужные данные. Другим фактором, влияющим на производительность хранилища данных, является значение параметра BatchSize для процессов извлечения, преобразования и загрузки.

Кроме того, производительность можно улучшить, по возможности размещая файлы журналов и файлы данных на разных физических дисках. Тем не менее, следует избегать размещения нескольких файлов журналов на одном диске. Аналогичным образом можно повысить пропускную способность, поместив tempdb на другой физический диск, чем другие базы данных. Наконец, можно получить преимущества от размещения трех разных баз данных на соответствующих физических дисках. По возможности следует использовать для размещения хранилища данных дисковую систему RAID 1+0. В общем, необходимо, чтобы на компьютере, на котором устанавливаются базы данных хранилища данных, было минимум 8 ГБ ОЗУ. Если у вас есть дополнительные источники данных хранилища данных из Operations Manager или Configuration Manager, следует увеличить объем ОЗУ для баз данных. Дополнительные преимущества, в том числе связанные с объемом памяти, на компьютере под управлением SQL Server, на котором размещается хранилище данных, можно получить, если разместить базы данных киоска данных и репозитория на том же сервере. Однако если в топологии развертывания имеется 4000 или меньше компьютеров, достаточно 4 ГБ. Необходимо иметь по крайней мере 8 ядер ЦП на компьютере, на котором установлена база данных хранилища данных. Дополнительные ядра способствуют улучшению производительности извлечения, преобразования и загрузки, а также создания отчетов.

Производительность может уменьшиться, если все базы данных в системе создаются с наименьшим размером, и для них задается автоматическое увеличение, особенно с малыми приращениями. См. вспомогательный инструмент sizing Service Manager, включенный в набор документации по заданиям Service Manager (SM_job_aids.zip), чтобы оценить размер базы данных и создать базу данных с размером, который ближе к окончательному размеру, что поможет повысить производительность за счет уменьшения числа операций автоматического увеличения базы данных.

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

Производительность сервера хранилища данных Service Manager

Производительность сервера хранилища данных зависит от количества серверов управления Service Manager, зарегистрированных в хранилище данных, размера развертывания и количества источников данных. Как правило, для сервера хранилища данных требуется как минимум 8 ГБ ОЗУ. Тем не менее, производительность будет повыситься за счет дополнительной памяти для расширенных сценариев развертывания, в которых несколько серверов управления Service Manager вставляют данные в хранилище данных. Если приходится искать компромиссное решение по производительности, наивысший приоритет следует отдать памяти для сервера SQL Server. Чтобы избежать проблем с производительностью, необходимо иметь по меньшей мере 8 ядер ЦП.

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

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

Тестирование производительности для портала самообслуживания было сосредоточено на типичных сценариях "понедельник утром", чтобы гарантировать, что в понедельник утром сотни пользователей могут входить в течение 5–10 минут и открывать инциденты с приемлемыми (менее 4–5 секунд) ответов. Эта цель была достигнута с тем минимумом оборудования, который рекомендуется в данном документе.

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

Не существует определенного количества целей уровня обслуживания, поддерживаемых Service Manager. Например, если в организации, как правило, возникает мало инцидентов, количество поддерживаемых целей уровня обслуживания выше нежели в противном случае. Однако чем больший объем инцидентов необходимо поддерживать, тем меньше количество целей уровня обслуживания, либо требуется дополнительное программное обеспечение и оборудование соответственно. Рекомендуется создать не более пяти целей уровня обслуживания для типичной конфигурации Service Manager на 50 000 компьютеров. Возможно, в конкретной среде удастся создать больше целей уровня обслуживания. Однако, поскольку условия значительно отличаются от организации к организации, корпорация Майкрософт не может предоставить конкретную рекомендацию по количеству целей уровня обслуживания, которые не должны превышаться. Если конфигурация развертывания страдает от низкой производительности в результате количества целей уровня обслуживания, рекомендуется масштабировать с помощью следующего сценария развертывания, как описано в статье "Конфигурации для сценариев развертывания" этого руководства.

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

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