다음을 통해 공유

  • 아티클

Service Manager 성능

 

게시 날짜: 2016년 7월

적용 대상: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

System Center 2012 – Service Manager 서버 역할과 기능의 성능은 다양한 요인에 따라 달라집니다. 일반적으로 Service Manager에서는 세 가지 부분에서 성능의 차이가 두드러지게 나타납니다.

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

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

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

커넥터 성능

커넥터를 처음 동기화할 경우 시간이 오래 걸릴 수 있습니다. 예를 들어 System Center Configuration Manager와의 대규모 초기 동기화에는 8 - 12시간이 걸립니다. 이렇게 커넥터를 처음으로 동기화하는 동안에는 모든 Service Manager 서버 역할과 프로세스의 성능이 저하될 수 있습니다. 이러한 성능 저하 문제는 Microsoft SQL Server 데이터베이스인 Service Manager 데이터베이스에 데이터를 순차적으로 삽입하는 방식 때문에 발생합니다. 커넥터의 초기 동기화 프로세스 속도를 높일 수는 없지만 Service Manager를 프로덕션 환경에 배포하기 전에 동기화 프로세스가 완료되도록 초기 동기화를 계획할 수 있습니다.

초기 동기화가 완료되면 Service Manager는 실질적으로 성능에 영향을 미치지 않는 차이점을 계속 동기화합니다.

워크플로 성능

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

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

  • 대개 워크플로는 시작 후 1분 안에 완료됩니다. 그러나 Service Manager 서버 역할의 작업량이 많으면 워크플로가 정상적으로 빠르게 완료되지 않습니다.

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

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

거의 모든 워크플로 프로세스가 1분 내에 처리되도록 새 ManagmentHostKeepAlive 관리 팩이 워크플로 처리 응답성을 향상시키므로 System Center 2012 – Service Manager의 워크플로 성능이 System Center Service Manager 2010보다 개선되었습니다.

그룹, 쿼리 및 사용자 역할이 성능에 미치는 영향

그룹과 사용자 역할은 초기에 계획해야 합니다. 되도록 그룹을 적게 만들고 가능한 가장 작은 범위로 그룹을 만들어야 합니다. 그런 다음 그룹을 만들기 전에 AD DS(Active Directory 도메인 서비스), System Center Configuration Manager 및 System Center Operations Manager의 데이터로 데이터베이스를 초기에 채워야 합니다.

보통 관리자가 사용자에게 지정된 그룹에 대한 액세스 권한만 부여하기 위해 그룹을 만듭니다. 인사 담당자가 사용하는 컴퓨터에 영향을 주는 인시던트와 같이 특정한 인시던트의 하위 집합을 만들어야 하는 시나리오를 예로 들어 보겠습니다. 이 시나리오에서는 특정 담당자만 중요 서버 그룹을 보거나 수정하도록 허용해야 합니다. 이런 유형의 액세스를 사용하려면 모든 사용자에게 공통적으로 적용되는 그룹과 중요 컴퓨터에 대한 그룹을 만든 후 보안 역할에 모든 사용자 그룹과 중요 서버 그룹 모두에 대한 액세스 권한을 부여합니다. 모든 사용자가 포함된 그룹을 만들면 Service Manager에서 그룹이 변경되었는지 여부를 자주 확인하기 때문에 성능에 영향이 있을 수밖에 없습니다. 기본적으로 30분마다 그룹 변경 내용을 확인하는데 규모가 큰 그룹의 경우 변경 내용을 확인하는 것만으로도 시스템에 가중되는 부하가 크기 때문에 응답 시간이 크게 저하될 수 있습니다.

해결 방법 1: 레지스트리 키를 수정하는 방법으로 Service Manager에서 그룹 변경 내용을 확인하는 간격을 직접 지정할 수 있습니다. 예를 들어 그룹 확인 주기를 30초에서 10분으로 변경하면 성능이 크게 향상됩니다. 그러나, 큐 및 서비스 수준 목표는 동일한 그룹 계산 폴링 간격을 사용하는 그룹의 특별한 종류입니다. 따라서 폴링 간격의 값을 늘리면 큐와 서비스 수준 목표 계산 시간이 더 길어지게 됩니다.

System_CAPS_ICON_caution.jpg 주의


레지스트리를 잘못 편집하면 시스템이 심각하게 손상될 수 있습니다. 레지스트리를 변경하기 전에 컴퓨터의 중요한 데이터를 모두 백업해야 합니다.

그룹 변경 내용 확인 간격을 수동으로 지정하려면

  1. regedit를 실행하고 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2012\Common\으로 이동합니다.

  2. GroupCalcPollingIntervalMilliseconds라는 새 DWORD 값을 만듭니다.

  3. 시간 간격을 밀리초 단위로 지정합니다. 결과에 6이 곱해집니다. 예를 들어 10분 간격으로 설정하려면 600000을 입력합니다.

  4. System Center 관리 서비스를 다시 시작합니다.

    참고


    System Center 2012 R2 Service Manager의 경우, System Center 관리 서비스가 Microsoft Monitoring Agent로 이름이 변경되었습니다.

해결 방법 2: Windows PowerShell 스크립트를 사용하여 "사용자"와 같은 특정 유형의 개체를 사용자 역할에 추가할 수 있습니다. 기본적으로 이 역할로 로그온한 분석가는 "사용자"와 동일한 유형의 모든 개체에 액세스할 수 있습니다. 이 방법을 사용하면 크기가 매우 큰 그룹("모든 사용자")을 만들고 Service Manager에서 이 그룹의 멤버 자격을 확인하기 위해 리소스를 소모할 필요가 없습니다.Service Manager 관리 서버에서 다음 Windows PowerShell 스크립트를 실행하면 "user" 유형을 "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."  
}

성능 보기

보기를 만들 때는 가능한 한 시스템의 "일반" 클래스를 사용하도록 합니다. Incident Management와 같은 대부분의 개체 클래스에는 "일반" 유형과 "고급" 유형의 두 가지 개체 유형이 있습니다. 일반 개체 유형에는 항목과 관련된 작은 데이터 하위 집합에 대한 간단한 참조만 포함되지만, 고급 유형에는 항목과 관련된 데이터에 대한 복잡한 참조가 많이 포함됩니다. 즉, 일반 유형은 간단한 프로젝션인 반면 고급 유형은 복잡한 프로젝션이라고 할 수 있습니다. 고급 개체 유형은 대부분 일반적으로 보기에 표시하지 않는 폼의 여러 필드를 채우는 데 사용됩니다. 고급 개체 유형을 기반으로 한 보기를 만들고 해당 보기를 열 때마다 Service Manager는 데이터베이스를 쿼리하여 많은 양의 데이터를 읽습니다. 그러나 검색된 데이터 중에 실제로 표시되거나 사용되는 양은 얼마 되지 않습니다.

따라서 고급 개체 유형을 사용하여 정의한 보기에서 성능 문제가 발생한 경우 일반 유형으로 전환하십시오. 또는 보기를 만드는 데 필요한 데이터만 포함된 프로젝션 유형을 직접 만들 수도 있습니다. 자세한 내용은 SCSM 엔지니어링 팀 블로그의 관련 속성 기준을 사용하는 보기 만들기(프로젝션 유형) : 소프트웨어 보기 예 블로그 게시물(영문) 블로그 항목을 참조하세요.

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개의 활성 콘솔이 있다고 가정하면 관리 서버당 4개 이상의 CPU 코어를 사용해야 합니다.

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개 이상 설치해야 성능 문제를 방지할 수 있습니다.

셀프 서비스 포털 성능

셀프 서비스 포털은 인시던트 및 서비스 요청 관리에 쉽게 액세스할 수 있도록 설계된 구성 요소로, 수천 명의 사용자를 동시에 처리하지는 못합니다.

셀프 서비스 포털의 성능 테스트는 보통 "월요일 오전" 시나리오에 중점을 두고 수행되었습니다. 특히 월요일 오전에 수천 명의 사용자가 5 - 10분 내에 로그인하여 적당한 시간(4 - 5초 미만) 내에 인시던트를 제기할 수 있도록 테스트되었습니다. 이 문서에서는 이러한 목표를 달성할 수 있는 최소 권장 하드웨어를 설명합니다.

서비스 수준 목표 성능

Service Manager에서 지원한다고 정해진 서비스 수준 목표 개수는 없습니다. 예를 들어 조직의 인시던트가 거의 없는 경우 객관적으로 지원 가능한 개수보다 더 많은 서비스 수준 목표를 지원할 수 있습니다. 그러나 인시던트 수가 많은 경우 서비스 수준 목표를 줄이거나 경우에 따라 추가 하드웨어 및 소프트웨어를 수평 확장해야 합니다. 일반적으로 50,000대 컴퓨터 Service Manager 구성의 경우 서비스 수준을 5개 이하로 만드는 것이 좋습니다. 가능한 경우 서비스 수준 목표를 더 만들 수도 있습니다. 그러나 조직마다 상황이 크게 다르므로 Microsoft는 준수하도록 권장하는 구체적인 서비스 수준 목표 개수를 제시하지 않습니다. 서비스 수준 목표 개수로 인해 배포 구성의 성능이 떨어지는 경우 이 가이드의 배포 시나리오의 구성 섹션에 설명된 대로 다음 확장 규모 배포 시나리오를 사용하여 수평 확장하는 것이 좋습니다.