데이터베이스 크기 조정 및 성능
데이터베이스 크기 조정은 System Center - Orchestrator의 성능을 이해하는 열쇠입니다. Runbook 서버, Management Server 및 웹 구성 요소는 모두 Orchestrator 데이터베이스를 사용하여 작업을 처리합니다. Orchestrator 배포의 문제는 데이터베이스의 데이터 형식과 이를 관리하는 방법에 대한 불완전한 이해로 인해 발생할 수 있습니다.
Runbook Designer는 Management Server를 통해 Orchestrator 데이터베이스와 통신하므로 데이터베이스 성능이 떨어지면 해당 통신이 원활하게 이루어지지 않습니다.
Orchestrator 연산자 환경은 오케스트레이션 콘솔과 웹 서비스의 두 가지 구성 요소를 기반으로 합니다. Orchestration 콘솔 은 웹 서비스를 사용하여 Orchestrator 데이터베이스에 연결하는 Silverlight 기반 애플리케이션입니다. 웹 서비스는 데이터베이스에 연결되는 IIS 애플리케이션입니다. 따라서 웹 서비스 및 오케스트레이션 콘솔 은 모두 Orchestrator 데이터베이스의 성능에 따라 달라집니다.
또한 Orchestration 콘솔 이 웹 서비스를 사용하지만 자체 성능 특성과 사용자 인터페이스의 기능에 대해서는 고유한 논리도 포함합니다.
구성 데이터 및 로그 데이터
높은 수준에서 Orchestrator 데이터베이스에는 다음 두 종류의 데이터가 포함됩니다.
구성 데이터
Orchestrator 인프라에는 구성 데이터가 포함됩니다. 이 데이터 형식에 대한 스토리지 요구 사항은 작기 때문에 데이터베이스 증가 컨텍스트에서는 이 데이터가 중요하지 않습니다.
로그 데이터
Orchestrator는 Runbook Designer에서 보고 관리할 수 있는 다양한 유형의 로그 데이터를 만듭니다. 이 데이터에 대한 스토리지 요구 사항은 크기가 다를 수 있으며 클 수 있습니다.
다음 표에는 Orchestrator 데이터베이스에 저장할 수 있는 로그 데이터 형식이 나와 있습니다. 또한 Orchestrator는 감사 추적 및 추적을 위해 별도의 로그 파일(데이터베이스 외부)에 데이터를 저장합니다. 모든 유형의 로그 데이터에 대한 자세한 내용은 Orchestrator Logs를 참조하십시오.
| 로그 데이터의 유형 | Runbook Designer에서의 위치 | 로그 제거로 관리되는지 여부 |
|---|---|---|
| Runbook 로그 | 로그 및 로그 기록 탭 | 예 |
| 작업(플랫폼) 이벤트 | 이벤트 탭 | 아니요 |
| 감사 기록 | 감사 기록 탭 | 아니요 |
플랫폼 코드 및 도메인 코드
오케스트레이터 Runbook 작업에는 두 가지 유형의 코드가 포함됩니다.
플랫폼 코드
대부분의 활동에서 공유하는 공통 코드이며 Orchestrator 작업에서 수행하는 일반적인 작업을 실행하는 데 사용됩니다. 플랫폼 코드는 공통 게시된 데이터를 생성합니다.
도메인 코드
일반적으로 Orchestrator 플랫폼 자체와 연결되지 않은 각 활동에 대한 작업에 특정한 다양한 작업을 실행합니다. 잠재적으로 플랫폼 코드와 도메인 코드 간에 큰 차이가 있을 수 있습니다.
지정된 작업에 대해 생성된 로깅 데이터에는 단일 값 또는 여러 값이 지정된 데이터 요소가 포함될 수 있습니다. 각 작업은 단일 값 데이터에 대해 단일 레코드를 생성합니다. 도메인 코드는 여러 값 데이터의 여러 레코드를 생성할 수 있으므로, 이전 작업에서 수신한 공통 게시된 데이터에 대해 작업이 수행하는 내용을 결정합니다.
기본적으로, Orchestrator Runbook은 도메인 코드의 개별 요소 간에 데이터를 전달하도록 설계되었습니다. 또한 도메인 코드는 선택적으로 작업 관련 게시된 데이터를 생성할 수 있습니다.
모든 Runbook은 기본적으로 도메인 코드와 플랫폼 코드로 구성되는 작업을 실행하고, 워크플로를 반복하고 분기한다는 점에서 비슷합니다. Runbook이 특정 작업을 수행하는 다른 Runbook을 호출할 때 분기가 진행됩니다. Runbook이 처음 호출되면 단일 스레드로 구성됩니다. 이 스레드가 그 링크에서 분기를 요구하는 Runbook 작업을 발견할 경우 각 분기마다 하나씩 추가 스레드가 만들어집니다. 각 스레드는 분기를 만든 작업의 공통 게시된 데이터를 입력으로 사용합니다. 이 데이터는 Runbook의 이전 작업과 다시 관련되어 해당 작업이 구독하는 공통 게시된 데이터를 업데이트합니다.
도메인 코드는 분기를 통해 생성되는 다중 스레딩보다 데이터베이스 성능에 더 큰 영향을 줄 수 있습니다. 도메인 코드가 작업 관련 게시된 데이터의 상당량을 생성할 수 있기 때문입니다.
로깅 옵션
Runbook의 속성 에 있는 로깅 탭에서 로깅 항목을 선택적으로 저장할 수 있습니다. 기본 로깅 이라는 용어는 두 가지 게시된 데이터 옵션이 모두 선택되지 않음을 의미하며, 각 작업에 대해 524바이트가 생성됩니다. 로깅 옵션은 다음과 같은 두 가지 범주의 공통 게시된 데이터를 제공합니다.
일반적인 게시된 데이터
모든 작업에 공통적인 데이터 항목의 집합입니다. 목록은 Runbook 로그 옵션을 참조 하세요.
이 로깅 옵션은 각 작업에 대해 6082바이트를 생성합니다.
활동별 게시된 데이터
도메인 코드를 통해 선택적으로 생성되는 작업과 관련된 데이터 집합입니다.
이 로깅 옵션은 특정 작업으로 로깅되는 바이트 외에도 6082바이트를 생성합니다.
팁
이 옵션은 기본적으로 디버깅을 위해 선택합니다. 선택하지 않으면 로깅 증가가 제한됩니다.
로깅 옵션을 설정하면 성능이 상당한 영향을 받을 수 있고 데이터베이스도 증가할 수 있습니다. 먼저 동일한 Runbook 작업을 기본 수준의 데이터 로깅으로 실행한 후(게시된 데이터 옵션을 선택하지 않음) 공통 게시된 데이터를 선택한 상태에서 실행하는 식으로, 두 번 실행하는 경우를 생각해 보십시오. 이런 경우 도메인 코드를 완료하는 시간은 동일합니다. 그러나 플랫폼 코드는 기본 로깅만 설정한 상태에서 수행하는 것보다 12배 더 많은 공통 게시된 데이터 로깅 양을 지원해야 하므로, 플랫폼 코드 실행 시간이 더 길어집니다.
로그 제거
Runbook Designer의 로그 제거 기능에 지정된 기본 옵션은 기본 Orchestrator 배포에 가장 적합한 사용자 환경을 제공하도록 구성됩니다. 이러한 값을 변경하면 환경의 성능 특성이 변경될 수 있으며 변경 결과를 평가할 수 있도록 점진적으로 상위 워터마크를 구현해야 합니다.
로그의 자동 및 수동 제거에 대한 자세한 내용은 Runbook 로그 제거를 참조 하세요.
성능 벤치마크 만들기
로깅 증가를 테스트하는 간단한 Runbook을 만들려면 표준 작업 비교 값을 사용하여 Orchestrator 환경의 벤치마크를 만들 수 있습니다.
다음 절차에서는 값 비교 작업을 10,000번 실행하는 Runbook을 만듭니다. 값 비교는 도메인 코드가 최소인 간단한 작업입니다. 이 Runbook은 지정된 Orchestrator 런타임 환경의 전반적인 성능을 특성화하기 위해 다양한 상황에서 호출할 수 있습니다.
Orchestrator 환경을 벤치마킹하는 데 사용할 수 있는 Runbook 만들기
새 Runbook을 만듭니다.
표준 작업 팔레트에서 Compare Values 작업을 추가합니다. 작업을 두 번 클릭하여 구성합니다.
일반 탭을 선택하고 문자열(기본값)을 비교하도록 이 작업을 구성합니다.
세부 정보 탭을 선택하고 테스트 상자에 STRING 값을 입력한 다음 비어 있습니다.
[마침]을 선택하여 활동에 대한 업데이트를 저장합니다.
작업을 마우스 오른쪽 단추로 클릭하고 반복을 선택합니다.
사용 확인란을 선택하고 시도 간 지연에 대해 숫자 0(0)을 입력합니다.
종료 탭을 선택합니다.
기본 종료 조건을 변경합니다. 값 비교를 선택하고, 공통 게시된 데이터 표시 확인란을 선택하고, 루프: 시도 횟수를 선택합니다. 확인을 선택하여 이 변경 내용 저장
업데이트된 종료 조건에서 값을 선택하고 숫자 10000(1만)을 입력합니다. 확인을 선택하여 이 변경 내용 저장
마침을 선택하여 이러한 업데이트를 저장합니다.
체크 인 선택하여 변경 내용을 Orchestrator 데이터베이스에 저장합니다.
이 Runbook을 사용하여 다양한 Orchestrator 구성을 실험해 볼 수 있습니다. 예를 들어, 여러 데이터 센터에 배포된 네 가지 Runbook Server 성능을 확인하는 벤치마크 Runbook을 만들 수 있습니다.
| 데이터 센터 | 로깅 구성 | 플랫폼 코드 실행 시간(밀리초) | 작업당 밀리초 수 | 배율 |
|---|---|---|---|---|
| 위치 1 | 기본 로깅 | 819 | 82 | 1.0(참조) |
| 위치 1 | 공통 게시된 데이터 로깅 | 2012 | 201 | 2.5 |
| 위치 2 | 기본 로깅 | 1229 | 123 | 1.5 |
| 위치 2 | 공통 게시된 데이터 로깅 | 3686 | 369 | 4.5 |
| 위치 3 | 기본 로깅 | 2457 | 426 | 3.0 |
| 위치 3 | 공통 게시된 데이터 로깅 | 4422 | 442 | 5.4 |
| 위치 4 | 기본 로깅 | 1474 | 147 | 1.8 |
| 위치 4 | 공통 게시된 데이터 로깅 | 2654 | 265 | 3.2 |
공통 게시된 데이터 로깅으로 플랫폼 성능이 상당히 감소하는 것을 볼 수 있습니다. 가장 나쁜 상황은 위치 2에 공통 게시된 데이터 로깅이 나타나는 것입니다. 표면적으로 이것은 명확하고 관련된 결론처럼 보입니다.
그러나 이러한 수치가 도메인 코드가 아닌 플랫폼 코드의 오버헤드를 반영한다는 점에 유의해야 합니다. 도메인 코드 런타임은 더 길 수 있습니다. 예를 들어 Virtual Machine Manager 통합 팩의 템플릿 에서 VM 만들기 작업은 VM이 만들어질 때 몇 분 동안 실행할 수 있습니다. 이전 예제에서 확장하면 위치에 관계없이 실행하는 데 1분(1분 = 60,000밀리초)이 걸리는 Runbook 작업의 플랫폼 코드 비용을 고려합니다.
| 데이터 센터 | 로깅 구성 | 플랫폼 코드 실행 시간(밀리초) | 도메인 코드(%) | 플랫폼 코드(%) |
|---|---|---|---|---|
| 위치 1 | 기본 로깅 | 819 | 98.6% | 1.4% |
| 위치 1 | 공통 게시된 데이터 로깅 | 2012 | 96.7% | 3.3% |
| 위치 2 | 기본 로깅 | 1229 | 98.0% | 2.0% |
| 위치 2 | 공통 게시된 데이터 로깅 | 3686 | 93.9% | 6.1% |
| 위치 3 | 기본 로깅 | 2457 | 95.9% | 4.1% |
| 위치 3 | 공통 게시된 데이터 로깅 | 4422 | 92.6% | 7.4% |
| 위치 4 | 기본 로깅 | 1474 | 97.5% | 2.5% |
| 위치 4 | 공통 게시된 데이터 로깅 | 2654 | 95.6% | 4.4% |
데이터를 대입하면 더 이해하기가 쉽습니다. 위치 2에서 공통 게시된 데이터의 로깅이 설정된 시나리오에서 여전히 성능이 가장 떨어집니다. 그러나 플랫폼 코드와 로깅은 총 런타임의 6%만 차지합니다. 이 수치도 상당하지만 최상의 시나리오는 1.4%입니다. 기본적으로, 이 예에서 도메인 코드에 소요되는 시간은 플랫폼 코드 실행 시간보다 훨씬 깁니다. 이를 관점에서 볼 때 플랫폼 코드 비용을 완전히 제거할 수 있다면 Runbook 성능이 1.4%에서 7.4% 범위로 개선된 것만 볼 수 있습니다.
대부분의 실제 시나리오는 다를 수 있습니다. 작업 동작은 도메인 코드에 지시된 내용에 따라 달라질 수 있습니다. 예를 들어 템플릿 작업의 VM 복제는 서버 템플릿 A에서 VM을 복제하는 데 1분이 걸리지만 서버 템플릿 B에서 VM을 복제하는 데 5분이 걸릴 수 있습니다. 또한 Runbook Server는 서로 다른 성능 특성을 가진 서로 다른 네트워크에 상주할 수 있으며, 이는 도메인 코드 성능과 Orchestrator 데이터 로깅 성능 모두에 영향을 줄 수 있습니다.
데이터베이스 증가 확인
Orchestrator 데이터베이스의 데이터베이스 관리자는 다음 지침에 따라 데이터베이스 파일 증가 전략을 확인할 수 있습니다.
일반적으로 데이터베이스 파일의 크기는 Runbook을 호출할 때마다 증가하지 않습니다. 해당 파일에 포함된 데이터가 데이터베이스 관리자에 의해 구성된 특정 상위 워터마크에 도달할 때 즉, 파일이 보통 확장될 때 파일이 증가합니다.
Runbook 활동이 실행될 때마다 개별적으로 계산되어야 하며, 이는 반복 기능으로 인해 단일 작업이 여러 번 실행될 수 있는 경우 고려해야 합니다.
Runbook의 각 호출에 필요한 스토리지를 확인하려면 Runbook의 활동 수를 선택한 로깅 수준에 따라 데이터베이스에 추가된 바이트 수를 곱합니다. 해당 값은 다음과 같습니다.
524바이트
기본 로깅 구성
6082바이트
공통 게시된 데이터 로깅 수준
6082바이트 + 작업을 통해 로깅되는 데이터
작업 관련 게시된 데이터 로깅 수준
기본적으로, Orchestrator는 오전 2시에 각 Runbook에 대해 최근 500개 로그를 제외한 모든 로그를 제거합니다. Runbook을 호출할 때마다 필요한 스토리지를 확인하려면 각 Runbook 호출에 필요한 스토리지와 500을 곱합니다. 로그 제거 설정을 변경하는 경우 각 호출과 일별, 주별 또는 월별로 필요한 예상 호출 수를 곱합니다.
다음 표에는 로깅 수준 구성의 증가 및 성능 예상 수치가 나와 있습니다.
| 로깅 수준 | DB 증가 배율 | 성능 배율 | 프로덕션에 권장되는지 여부 |
|---|---|---|---|
| 기본값 | 1 | 1 | 예 |
| 공통 게시된 데이터 | 11.6배 | 2.5배 | 계획 시 제한적으로 사용 |
| 작업 관련 게시된 데이터 | 11.6배 넘음 | 2.5배 넘음 | 아니요 |
예제
예 1
다음 표에서는 Orchestrator 배포에 대한 데이터베이스 크기 조정 고려 사항에 대해 설명합니다.
| Runbook 이름 | 작업 수 | 로깅 수준 | 일당 호출 수 |
|---|---|---|---|
| Runbook 1 | 50 | 기본값 | 100 |
| Runbook 2 | 25 | 기본값 | 50 |
| Runbook 3 | 12 | 공통 게시된 데이터 | 24 |
| Runbook 4 | 8 | 공통 게시된 데이터 | 500 |
위에서 설명한 데이터베이스 크기 조정을 사용하면 Runbook의 스토리지 요구 사항을 예상할 수 있습니다.
| Runbook 이름 | 호출당 바이트 수 | MB의 스토리지 기본 로그 제거(500개의 호출) |
월당 호출 수 | MB의 스토리지 한 달 (기본 로그 제거 아님) |
30일 후의 DB 스토리지(%) |
|---|---|---|---|---|---|
| Runbook 1 | 26,200 | 12.5 | 3,000 | 74.5 | 9% |
| Runbook 2 | 13,100 | 6.2 | 1,500 | 18.7 | %2 |
| Runbook 3 | 72,984 | 34.8 | 720 | 50.1 | 6% |
| Runbook 4 | 48,656 | 23.2 | 15,000 | 696.0 | 83% |
| 합계: 76.7MB | 합계: 839.3MB |
이 예에서는 데이터 로깅에 대해 근거 있는 의사 결정을 내리는 것이 얼마나 중요한지 확실히 보여 줍니다. Runbook 4는 8개의 활동만 포함하지만 공통 게시된 데이터 로깅 수준에서 구성된 경우 호출 빈도가 높기 때문에 데이터베이스의 스토리지 대부분을 사용합니다. 이러한 결과에 따라 Runbook 4의 로깅 수준을 기본 로깅 구성으로 줄이는 것이 좋습니다.
예제 2
다음 표에서는 Orchestrator의 다른 배포에 대한 데이터베이스 크기 조정 고려 사항에 대해 설명합니다.
| Runbook 이름 | 작업 수 | 로깅 수준 | 일당 호출 수 |
|---|---|---|---|
| Runbook 1 | 50 | 기본값 | 100 |
| Runbook 2 | 25 | 기본값 | 50 |
| Runbook 3 | 12 | 공통 게시된 데이터 | 24 |
| Runbook 4 | 8 | 기본값 | 500 |
업데이트된 구성의 스토리지 수치를 다시 계산하면 결과가 상당히 달라집니다.
| Runbook 이름 | 호출당 바이트 수 | MB의 스토리지 기본 로그 제거(500개의 호출) |
월당 호출 수 | MB의 스토리지 한 달 (기본 로그 제거 아님) |
30일 후의 DB 스토리지(%) |
|---|---|---|---|---|---|
| Runbook 1 | 26,200 | 12.5 | 3,000 | 74.5 | 37% |
| Runbook 2 | 13,100 | 6.2 | 1,500 | 18.7 | 9% |
| Runbook 3 | 72,984 | 34.8 | 720 | 50.1 | 25% |
| Runbook 4 | 4,192 | 2.0 | 15,000 | 60.0 | 29% |
| 합계: 55.5MB | 합계: 203.3MB |
기본 로깅 구성(Runbook당 로그 항목 500개)은 거의 변경되지 않지만 30일 스토리지 요구 사항은 크게 변경되었습니다. 이 변경으로 인해 30일 동안 데이터베이스 스토리지 요구 사항이 76% 감소하므로 Runbook 4에 대해 공통 게시된 데이터 로깅을 사용하는 스토리지 비용을 신중하게 고려해야 합니다.
요약
다음 지침에 따라 데이터베이스 크기 조정 및 성능을 관리할 수 있습니다.
필요한 경우에만 공통 게시된 데이터 로깅을 사용합니다.
작업 실행 횟수가 로깅된 데이터 볼륨을 결정한다는 점에 유의하십시오. 몇 가지 작업이 여러 번 실행되는 작은 Runbook은 더 큰 Runbook이 더 적은 횟수를 실행하는 것보다 더 많은 데이터 로깅을 초래할 수 있습니다.
프로덕션 환경에서 활동별 게시된 데이터 로깅을 사용하도록 설정하지 말고 디버깅 용도로만 사용해야 합니다.
플랫폼 코드 실행과 비교하여 Runbook이 도메인 코드를 실행하는 데 드는 시간의 양을 이해하는 것이 좋습니다.
이 문서에서 개략적으로 설명하는 기술을 사용하여 플랫폼 코드 비용을 예상해 봅니다. Runbook 성능을 개선할 수 있는 지점을 고려할 때 참조 자료로 활용할 수 있습니다.
측정치의 비교를 표준화하면 더 개선할 수 있는 부분을 쉽게 파악할 수 있습니다.