System Center - 성능 Service Manager

  • 아티클

중요

이 버전의 Service Manager 지원이 종료되었습니다. Service Manager 2022로 업그레이드하는 것이 좋습니다.

System Center의 성능 - Service Manager 서버 역할 및 기능은 다양한 요인의 영향을 받습니다. 일반적으로 Service Manager 긍정 및 부정 성능이 가장 두드러지는 세 가지 영역이 있습니다.

  • Service Manager 콘솔 응답성. 콘솔에서 작업을 실행한 후 완료되기까지 걸리는 시간입니다.

  • 커넥터의 데이터 삽입 시간. 커넥터가 동기화되면 Service Manager 데이터를 가져오는 데 걸리는 시간입니다.

  • 워크플로 완료 시간. 워크플로에서 작업을 자동으로 적용하는 데 걸리는 시간입니다.

커넥터 성능

커넥터 초기 동기화에는 상당한 시간이 걸릴 수 있습니다. 예를 들어 Configuration Manager 대규모 초기 동기화의 경우 8~12시간입니다. 커넥터가 처음에 동기화되면 이 시간 동안 모든 Service Manager 서버 역할 및 프로세스에 대한 성능이 저하되는 것으로 예상할 수 있습니다. 이는 데이터가 Microsoft SQL Server 데이터베이스인 Service Manager 데이터베이스에 순차적으로 삽입되는 방식 때문에 발생합니다. 커넥터의 초기 동기화 프로세스를 서두르는 것은 아니지만 초기 동기화를 계획하고 Service Manager 프로덕션에 투입되기 전에 동기화 프로세스가 잘 완료되었는지 확인할 수 있습니다.

초기 동기화가 완료되면 Service Manager 성능에 측정 가능한 영향을 주지 않는 차이점을 계속 동기화합니다.

워크플로 성능

워크플로는 수행되는 자동 프로세스입니다. 여기에는 전자 메일 알림, 변경 요청 활성화의 다음 단계, 템플릿 자동 적용이 포함됩니다.

워크플로 성능 고려 사항은 다음과 같습니다.

  • 대개 워크플로는 시작 후 1분 안에 완료됩니다. Service Manager 서버 역할이 워크로드가 많은 경우 워크플로가 정상적으로 빨리 완료되지 않습니다.

  • 또한 새 알림 구독과 같은 워크플로를 새로 만들면 시스템에 부하가 가중됩니다. 새로 만드는 워크플로 수가 증가하면 각 워크플로를 실행하는 데 걸리는 시간도 길어집니다.

예를 들어 각각 워크플로를 많이 생성하는 다수의 새 인시던트를 만드는 경우와 같이 시스템에 작업 부하가 지나치게 가중되면 성능에 악영향을 미칠 수 있습니다.

성능에 대한 그룹, 큐 및 사용자 역할 영향

그룹과 사용자 역할은 초기에 계획해야 합니다. 되도록 그룹을 적게 만들고 가능한 가장 작은 범위로 그룹을 만들어야 합니다. 그런 다음 그룹을 만들기 전에 처음에 데이터베이스를 Active Directory Domain Services(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. GroupCalcPollingIntervalMilliseconds라는 새 DWORD 값을 만듭니다.

  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 콘솔 수, 그룹 변경 검사 간격 및 커넥터에 의해 삽입되는 데이터 등 다양한 요인에 의해 직접적인 영향을 받습니다. 이 문서에는 이러한 성능 고려 사항에 대해 자세히 설명되어 있습니다. 요점을 간단히 정리하면 다음과 같습니다.

  • 일반적인 시나리오에서 허용 가능한 응답 시간을 가질 수 있도록 에서 Service Manager 데이터베이스를 호스트하는 관리 서버에 대해 최소 8GB의 RAM이 있어야 합니다.

  • Service Manager 데이터베이스를 호스트하는 컴퓨터에 CPU 코어가 8개 이상 있어야 합니다.

  • 가능한 경우 로그 파일과 데이터 파일을 각각 별도의 물리적 디스크에 따로 저장하면 데이터베이스 성능을 높일 수 있습니다. tempdb를 Service Manager 데이터베이스와 다른 물리적 RAID 드라이브로 이동하여 추가적인 이점을 얻을 수 있습니다. 이때 가능하면 RAID 1+0 디스크 시스템을 사용하여 Service Manager 데이터베이스를 호스트합니다.

  • Service Manager 데이터베이스가 더 작은 크기로 만들어지고 자동 증가로 설정된 경우 성능에 부정적인 영향을 받을 수 있습니다.

데이터베이스 크기 평가에 대한 도움말은 Service Manager 작업 지원 설명서 집합(SM_job_aids.zip)에 포함된 Service Manager 크기 조정 도우미 도구를 참조하고 최종 크기에 가까운 크기로 데이터베이스를 만듭니다. 이렇게 하면 데이터베이스가 자동 증가해야 하는 횟수를 줄여 성능을 향상할 수 있습니다.

마찬가지로 고성능 데이터베이스에 대한 다른 모든 모범 사례도 적용할 수 있습니다. 예를 들어 우수한 디스크 하위 시스템을 활용할 수 있는 경우 각 파일 그룹의 테이블 그룹을 분할하고 다른 실제 드라이브로 이동하는 이점을 얻을 수 있습니다.

Service Manager 관리 서버 성능

Service Manager 관리 서버의 성능은 주로 활성 동시 Service Manager 콘솔 수의 영향을 받습니다. 모든 Service Manager 역할은 관리 서버와 상호 작용하므로 많은 수의 동시 콘솔을 사용하려는 경우 관리 서버를 추가하는 것이 좋습니다. 또한 관리 서버에는 8GB의 RAM이 필요합니다. CPU 코어당 10~12개의 활성 콘솔이 있다고 가정하면 관리 서버당 CPU 코어가 4개 이상 있어야 합니다.

Service Manager 콘솔 성능

Service Manager 콘솔의 성능은 주로 분석가가 일반적으로 열어 놓은 양식 수와 뷰에서 검색되는 데이터의 양에 영향을 받습니다. Service Manager 콘솔이 설치된 컴퓨터에는 4GB의 RAM이 있어야 합니다. 많은 양의 데이터를 검색하는 뷰가 있는 경우 추가 RAM이 필요합니다. Service Manager 콘솔이 설치된 컴퓨터에 대해 4코어 이상의 CPU가 있어야 합니다. Service Manager 콘솔은 최종 사용자 애플리케이션이므로 과도한 리소스 사용량이 표시되면 다시 시작하는 것이 좋습니다. Service Manager 콘솔은 메모리에 정보를 적극적으로 캐시하므로 전체 메모리 사용량에 기여할 수 있습니다.

데이터 웨어하우스 데이터베이스 성능 Service Manager

데이터 웨어하우스의 성능은 데이터를 보내는 동시 Service Manager 관리 서버 수, 저장된 데이터 볼륨 또는 데이터 보존 기간, 데이터 변경 속도, ETL(추출, 변환 및 로드) 빈도 등 다양한 요인에 의해 직접적인 영향을 받습니다. 데이터 웨어하우스에 저장되는 데이터 양은 시간이 지날수록 증가하기 때문에 불필요한 데이터를 압축하는 것이 무엇보다 중요합니다. 데이터 웨어하우스 성능에 영향을 주는 또 다른 요인은 ETL 프로세스의 BatchSize 설정입니다.

로그 파일과 데이터 파일을 각각 별도의 실제 디스크에 따로 저장하면 성능을 높일 수 있습니다. 그러나 디스크당 로그 파일을 두 개 이상 저장하지 않아야 합니다. 마찬가지로 tempdb를 다른 데이터베이스와 분리하여 별도의 실제 디스크로 옮기는 방법으로도 처리량을 높일 수 있습니다. 마지막으로 데이터베이스를 서로 다른 실제 디스크에 설치하는 것도 성능을 높이는 방법입니다. 이때 가능하면 RAID 1+0 디스크 시스템을 사용하여 데이터 웨어하우스를 호스트합니다. 데이터 웨어하우스 데이터베이스가 설치된 컴퓨터의 경우에는 보통 8GB 이상의 RAM을 설치해야 합니다. Operations Manager 또는 Configuration Manager 추가 데이터 웨어하우스 데이터 원본이 있는 경우 데이터베이스의 RAM 양을 늘려야 합니다. 데이터 웨어하우스를 호스트하는 SQL Server를 실행하는 컴퓨터에서도 메모리 양을 늘리는 것이 좋고 데이터 마트 및 리포지토리 데이터베이스가 동일한 서버에 있는 경우에는 더욱 그렇습니다. 그러나 배포 토폴로지에 4,000대 이하의 컴퓨터가 있는 경우 4GB로 충분합니다. 데이터 웨어하우스 데이터베이스가 설치된 컴퓨터는 CPU 코어가 8개 이상이어야 합니다. 코어를 추가하면 ETL 및 보고서 성능을 높이는 데 도움이 됩니다.

시스템의 모든 데이터베이스를 작은 크기로 만들고 크기가 자동으로 증가하도록 설정하면 성능이 저하될 수 있습니다. 특히 증가 폭이 작을수록 성능에 미치는 영향도 큽니다. Service Manager 작업 보조 문서 집합(SM_job_aids.zip)에 포함된 Service Manager 크기 조정 도우미 도구를 참조하여 데이터베이스 크기를 평가하고 데이터베이스가 자동 증가해야 하는 횟수를 줄여 성능에 도움이 되는 최종 크기에 가까운 크기로 데이터베이스를 만듭니다.

Service Manager 파일 그룹에 대한 기본 제공 지원이 포함되어 있습니다. 별도의 하드 드라이브에 파일 그룹을 배치하여 이점을 얻을 수 있습니다. 파일 그룹 모범 사례에 대한 자세한 내용은 SQL Server 설명서를 참조하세요.

데이터 웨어하우스 서버 성능 Service Manager

데이터 웨어하우스 서버의 성능은 데이터 웨어하우스에 등록된 Service Manager 관리 서버 수, 배포 크기 및 데이터 원본 수의 영향을 받습니다. 또한 데이터 웨어하우스 서버에는 보통 8GB 이상의 RAM이 필요합니다. 그러나 둘 이상의 Service Manager 관리 서버가 데이터 웨어하우스에 데이터를 삽입하는 고급 배포 시나리오에 대한 추가 메모리가 있으면 성능이 향상됩니다. 불가피하게 성능을 다소 희생해야 할 경우 SQL Server를 실행하는 컴퓨터에 메모리를 최우선으로 할당해야 합니다. CPU 코어를 8개 이상 설치해야 성능 문제를 방지할 수 있습니다.

셀프 서비스 포털 성능

Self-Service Portal은 인시던트 및 서비스 요청 제출에 쉽게 액세스할 수 있도록 설계되었습니다. 수천 명의 사용자를 동시에 처리하도록 설계되지 않았습니다.

Self-Service Portal에 대한 성능 테스트는 일반적인 "월요일 아침" 시나리오에 중점을 두었으며, 특히 월요일 아침에 수백 명의 사용자가 5~10분 이내에 로그인하고 허용되는 응답 시간(4~5초 미만)으로 인시던트 열기를 할 수 있도록 했습니다. 이 문서에서는 이러한 목표를 달성할 수 있는 최소 권장 하드웨어를 설명합니다.

서비스 수준 목표 성능

Service Manager 지원하는 특정 서비스 수준 목표는 없습니다. 예를 들어 조직의 인시던트가 거의 없는 경우 객관적으로 지원 가능한 개수보다 더 많은 서비스 수준 목표를 지원할 수 있습니다. 그러나 인시던트 수가 많은 경우 서비스 수준 목표를 줄이거나 경우에 따라 추가 하드웨어 및 소프트웨어를 수평 확장해야 합니다. 일반적인 50,000대의 컴퓨터 Service Manager 구성에 대해 5개 이하의 서비스 수준 목표를 만드는 것이 좋습니다. 가능한 경우 서비스 수준 목표를 더 만들 수도 있습니다. 그러나 조건이 organization organization 크게 다르기 때문에 Microsoft는 사용자가 초과해서는 안 되는 서비스 수준 목표 수에 대한 구체적인 권장 사항을 제공할 수 없습니다. 서비스 수준 목표 수로 인해 배포 구성 성능이 저하되는 경우 이 가이드의 배포 시나리오 구성 문서에 설명된 대로 다음으로 큰 배포 시나리오를 사용하여 스케일 아웃하는 것이 좋습니다.

다음 단계