하드웨어 성능
게시 날짜: 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 에서 가장 두드러지게 나타나는 하드웨어 병목 현상은 다음과 같습니다.
가장 일반적인 병목 현상은 Microsoft SQL Server를 실행하는 컴퓨터의 메모리와 I/O입니다. 리소스가 충분하다면 추가 메모리와 고속 I/O 하위 시스템에 투자하여 SQL Server I/O를 향상시키는 것이 성능을 개선하는 가장 좋은 방법입니다.
관리 서버에 연결하는 콘솔 수가 많을 것으로 예상되는 경우에는 관리 서버에 추가 CPU와 메모리를 투자하거나 보조 Service Manager 관리 서버를 설치하는 방법으로 성능을 향상시켜 사용량이 가장 많을 때에도 원활하게 부하를 처리할 수 있습니다.
이 문서에서 설명하는 각 역할별 최소 권장 하드웨어를 참조합니다.
가상 컴퓨터의 역할
대부분의 조직에서는 가상 컴퓨터를 사용하여 Windows Server 응용 프로그램을 호스트합니다. Service Manager 서버 역할에는 예외가 없습니다. 가상 컴퓨터의 사용 범위는 가상화된 모든 서버 역할에서 가상 컴퓨터와 물리적 컴퓨터의 몇 가지 다른 조합까지 포괄할 수 있습니다.
본질적으로 조직의 요구 사항은 모두 다르기 때문에 가상 컴퓨터와 물리적 컴퓨터의 권장 비율을 구체적으로 제시하지는 않습니다. 그러나 각 소프트웨어 역할에 대한 최소 하드웨어 요구 사항은 물리적 컴퓨터에 적용됩니다. 소프트웨어 역할을 가상화하려면 각 가상 컴퓨터에 대해 추가적인 하드웨어 리소스를 준비해야 합니다.
데이터베이스 서버는 가상 컴퓨터에 설치할 경우 성능이 저하되기 쉬우므로 다음 계획 지침을 철저히 따라야 합니다.
Running SQL Server 2008 in a Hyper-V Environment(Hyper-V 환경에서 SQL Server 2008 실행) (SQL2008inHyperV2008.docx)
SQL Server를 호스트하려는 가상 컴퓨터에서 동적 디스크를 사용해서는 안됩니다. 고정 크기의 가상 하드 드라이브나 통과 드라이브를 사용합니다.
Hyper-V에서는 게스트당 가상 CPU가 4개까지만 허용되므로 콘솔 수가 많은 경우 Service Manager 서버 성능이 제한될 수 있습니다.
Service Manager 기준 테스트 결과
Service Manager 는 물리적 컴퓨터의 최소 권장 하드웨어를 사용하는 다양한 배포 시나리오를 통해 성능과 확장성에 대한 기준 테스트를 거쳤습니다. 구체적으로 설명하면 미리 데이터가 채워진 데이터베이스와 반복적으로 인시던트 및 변경 요청을 만들고 업데이트하는 Service Manager 콘솔이 테스트에 사용되었습니다.
데이터베이스는 두 가지 테스트를 위한 정보로 미리 채워졌습니다.
테스트 1은 20,000대의 컴퓨터, 20,000명의 사용자, 필요한 모든 구성 항목으로 구성되며, 구성 항목은 해당 데이터베이스에서 총 약 250만 개 행을 사용하는 약 250,000개였습니다. 테스트 1은 40개의 활성 Service Manager 콘솔도 포함했습니다.
테스트 2는 50,000대의 컴퓨터, 50,000명의 사용자, 관련 구성 항목으로 구성되며, 구성 항목은 해당 데이터베이스에서 총 600만 개 행을 사용하는 약 700,000개였습니다. 테스트 2는 80개의 활성 Service Manager 콘솔도 포함했습니다.
테스트 결과는 다음과 같았습니다.
50,000대의 컴퓨터 구성에서 응답 시간 목표를 달성하기 위해서는 SQL Server 메모리를 8GB(기가바이트)에서 32GB로 늘려야 했습니다.
테스트를 진행하는 동안 20,000대의 컴퓨터 구성에서는 시간당 200개의 인시던트와 50개의 변경 요청이, 50,000대의 컴퓨터 구성에서는 시간당 500개의 인시던트와 125개의 변경 요청이 각각 생성되었고, 각 인시던트 및 변경 요청마다 3 - 4개의 알림 구독과 템플릿이 처리되었습니다.
일반적으로 이러한 기준 테스트에서 알림 구독 처리 및 템플릿 응용 프로그램과 같은 워크플로는 각 작업 항목이 생성된 후 1분 안에 실행되었습니다.
조직에서 지원할 컴퓨터와 콘솔의 수가 20,000대 미만이고 워크플로가 많지 않다면 일부 Service Manager 역할을 가상 컴퓨터에서 호스트하더라도 Service Manager 성능 문제는 발생하지 않습니다.
그러나 Service Manager 데이터베이스에 지원 컴퓨터를 더 추가할 예정이라면 Service Manager 데이터베이스 서버의 RAM 용량을 이 문서에 나와 있는 최소 요구 사항보다 훨씬 더 확장하도록 계획해야 합니다. 예를 들어 20,000대의 컴퓨터가 포함된 기준 테스트에서는 Service Manager 데이터베이스 서버에 8GB의 RAM이 설치되어 있었습니다. 이 환경의 경우 지원할 컴퓨터가 10,000대 늘어날 때마다 8GB의 RAM을 추가해야 합니다. 예를 들어 컴퓨터 수를 50,000대로 늘리려면 RAM을 32GB로 추가해야 합니다. 32GB의 RAM이 설치된 SQL 서버를 실행하는 컴퓨터로 50,000대의 컴퓨터 구성을 테스트하는 동안 컴퓨터를 추가하기 전의 구성에 대한 테스트와 비교해도 차이가 전혀 없을 정도로 성능이 향상되었습니다.
이러한 기준 테스트에서는 네트워크 대기 시간도 테스트되었습니다. 네트워크 대기 시간은 Service Manager 콘솔 과 Service Manager 관리 서버 사이에서 발생했습니다.
참고
Service Manager 데이터베이스 서버와 Service Manager 관리 서버는 대기 시간이 짧은 LAN을 통해 연결되어야 합니다. Service Manager 데이터베이스 서버와 Service Manager 관리 서버 간에 대기 시간이 길어지면 Service Manager 성능이 크게 저하될 수 있습니다.
테스트 결과는 다음과 같았습니다.
네트워크 대기 시간이 100msec(밀리초) 미만인 경우 전반적으로 Service Manager 콘솔 응답 시간이 양호한 것으로 나타났습니다.
네트워크 대기 시간이 150 - 200msec 사이인 경우에는 일부 시나리오에서 최대 40%까지 응답 성능이 저하되었지만 운영 가능한 수준인 것으로 확인되었습니다. 대기 시간이 150에서 200밀리초 사이이면 조직의 주요 시나리오를 평가해 RDC(원격 데스크톱 연결)를 이용하는 편이 더 나은지 확인해야 합니다.
참고
Service Manager 콘솔 에서 서비스 맵을 확장하는 속도는 대기 시간에 관계없이 느리게 나타났습니다.네트워크 대기 시간이 200msec를 초과하면 전반적으로 Service Manager 콘솔 응답 시간이 불량한 것으로 나타났습니다. 따라서 대기 시간이 200msec를 초과하면 RDC(원격 데스크톱 연결)나 기타 비슷한 원격 액세스 솔루션을 운영 작업에 사용해야 합니다. 단, 비정기적인 관리 작업의 경우 자주 수행하지 않기 때문에 원격 액세스를 사용할 필요가 없습니다.