사서함 서버 프로세서 용량 계획

  • 아티클

마지막으로 수정된 항목: 2010-02-04

사서함 서버 용량 계획은 Microsoft Exchange Server 2010에 제공되는 사서함 복구로 인해 사서함 이전 버전의 Microsoft Exchange와 비교해서 크게 달라졌습니다. Exchange 2010은 사서함 복구 개념에 입각하여 재설계되어, 이제 서버 수준이 아닌 개별 사서함 데이터베이스 수준에서 자동 장애 조치(failover) 보호를 제공하도록 아키텍처가 변경되었습니다. 사서함 서버 역할 용량 계획 프로세스에 영향을 주는 주요 변경 사항은 두 가지입니다.

  • 동일한 서버의 활성 및 수동 데이터베이스 복사본 호스트
  • 데이터베이스 복사본 수 제공

이 항목의 정보는 이들 변경 사항을 보다 잘 이해하기 위해, 그리고 사서함 복구를 위해 구성할 때 사서함 서버의 크기 조정을 위한 디자인 참고 자료로 사용할 수 있습니다.

목차

동일한 서버의 활성 및 수동 데이터베이스 복사본 호스트

데이터베이스 복사본 수

디자인 단계

동일한 서버의 활성 및 수동 데이터베이스 복사본 호스트

Exchange 2010에서는 서버가 사서함 복구를 위해 구성되어 있으면 동일한 서버에서 활성 및 수동 데이터베이스 복사본을 모두 호스트할 수 있습니다. 각 서버의 프로세서는 (활성 상태의 탑재된 데이터베이스에서 호스트되는) 활성 사서함과 (수동 데이터베이스에서 호스트되는) 수동 사서함 모두로부터의 작업을 서비스합니다. 수동 사서함 및 데이터베이스에 대한 프로세서 요구 사항은 Exchange 2010 사서함 용량 계획을 수행할 때 반드시 고려되어야 합니다. 수동 데이터베이스 복사본은 CPU 리소스를 사용하여 복제된 로그를 확인하거나, 복제된 로그를 데이터베이스에 재생하거나, 데이터베이스 복사본과 연관된 콘텐츠 인덱싱을 유지 관리합니다. 일반적으로 (수동 데이터베이스 복사본에서 호스트되는) 각 수동 사서함은 (활성 데이터베이스 복사본에서 호스트되는) 활성 사서함을 호스트하는 데 필요한 CPU 사용률의 15%에 해당합니다.

Exchange 2010 사서함 용량 계획의 핵심 측면은 사서함 복구를 위해 구성될 때 서버 단위로 활성화되도록 할 데이터베이스 복사본 수를 결정하는 것입니다. 선택할 수 있는 디자인 범위는 다양하지만 고가용성 요소 이해에서 설명한 모델을 사용하는 것이 좋습니다.

자세한 내용은 다음 항목을 참조하십시오.

맨 위로 이동

데이터베이스 복사본 수

Exchange 2010 사서함 복구를 사용하면 다수의 데이터베이스 복사본(데이터베이스당 최대 16개)을 구성할 수 있습니다. 데이터베이스 복사본이 추가되면 활성 복사본을 호스트하는 서버가 수행해야 할 CPU 작업이 증가합니다. 활성 복사본이 있는 서버에서 추가로 수행하는 이러한 작업은 각 수동 복사본이 활성 복사본으로부터 인덱싱할 콘텐츠를 검색하므로 주로 로그 복제 및 콘텐츠 인덱싱입니다.

활성 데이터베이스 복사본을 호스트하는 서버의 사서함당 CPU 요구 사항은 데이터베이스 복사본 하나가 추가되면 10%씩 늘어나야 합니다(예: 복사본 하나 = 10%, 복사본 둘 = 20%). 이러한 요소는 활성 데이터베이스 복사본을 호스트하는 서버의 CPU 요구 사항에만 적용되며, 수동 데이터베이스 복사본을 호스트하는 데 사용되는 CPU에는 적용되지 않습니다. 자세한 내용은 Understanding Processor Configurations and Exchange Performance를 참조하십시오.

맨 위로 이동

디자인 단계

새로운 크기 조정 요인으로 인해, 사서함 복구를 위해 구성될 때 사서함 서버의 크기를 조정하는 데 추가 단계가 필요합니다. 일반적인 단계는 다음과 같습니다.

  1. 전반적인 솔루션 아키텍처에 대한 고가용성 요구 사항을 고려합니다. 사서함 복구 또는 독립 실행형 솔루션, 사이트 복구, 필요한 데이터베이스 복사본 수, 일반 오류 사례를 처리하기 위한 서버 또는 DAG 수를 고려합니다.
  2. 사서함 복구를 사용하는 경우 디자인할 데이터베이스 활성화 모델을 선택합니다. (지정된 오류 시나리오를 위한 디자인, 또는 활성화된 모든 데이터베이스 복사본을 위한 디자인)
  3. 다음 표를 사용하면 디자인을 기반으로 CPU 및 메모리 요구 사항을 예상할 수 있습니다. 활성 사서함의 CPU 및 메모리 요구 사항, 수동 사서함의 CPU 요구 사항, 추가 데이터베이스 복사본에 대한 활성 사서함의 CPU 요구 사항을 고려합니다. 활성화 모델을 사용하여 디자인이 수용할 수 있는 최대 사서함 수를 정의합니다.

다음 표에서는 사용자 프로필을 기반으로 예상 값을 제공합니다. 예상 값은 지식 근로자의 근무일 중 가장 바쁜 두 시간(예: 오전 10시부터 정오까지)을 기반으로 합니다. 이 최대 사용 시간 동안의 사용률은 총 8 ~ 10시간인 하루 근무 시간 평균 사용률의 두 배에 달하기도 합니다. 사용자 프로필 설명은 전자 메일 사용량이 늘어나면서 프로필의 범위가 커져 제외되었습니다.

사서함당 데이터베이스 캐시, IOPS 및 CPU는 사용자 프로필과 메시지 작업을 기반으로 예상합니다.

하루에 사서함당 주고받는 메시지 수 사서함당 데이터베이스 캐시(MB) 사서함당 IOPS가 예상된 단일 데이터베이스 복사본(독립 실행형) 사서함당 IOPS가 예상된 여러 데이터베이스 복사본(사서함 복구) 활성 사서함 또는 독립 실행형 사서함의 메가사이클 수동 사서함의 메가사이클

50

3

0.06

0.05

1

0.15

100

6

0.12

0.1

2

0.3

150

9

0.18

0.15

3

0.45

200

12

0.24

0.2

4

0.6

250

15

0.3

0.25

5

0.75

300

18

0.36

0.3

6

0.9

350

21

0.42

0.35

7

1.05

400

24

0.48

0.4

8

1.2

450

27

0.54

0.45

9

1.35

500

30

0.6

0.5

10

1.5

참고

하나의 활성 복사본 이후 데이터베이스 복사본이 하나 추가될 때마다 활성 사서함의 메가사이클이 10% 늘어나야 합니다.

참고

메가사이클은 Intel Xeon x5470 3.33 GHz 프로세서(2x4 코어 배열)의 측정 값을 기반으로 예상합니다. 3.33 GHz 프로세서 코어는 성능 처리량이 3,300 메가사이클입니다. 다른 프로세서 구성은 이 측정 플랫폼과 SPEC(표준 성능 평가 기관)에서 테스트한 서버 플랫폼을 비교하여 예상할 수 있습니다. 자세한 내용은 표준 성능 평가 기관 웹 사이트에서 SPEC CPU2006 결과를 참조하십시오.

사서함 서버 용량 계획의 예

다음은 프로세서 크기 조정 프로세스를 설명한 예입니다. 이 예는 다음 디자인 가정을 기반으로 합니다.

  • 사서함 수   12,000
  • 사서함 프로필   하루에 주고받은 150개의 메시지
  • 가용성 요구 사항   단일 사이트 내 사서함 복구, 2개 서버 동시 오류에 대한 내결함성
  • 저장소 아키텍처   3개의 데이터베이스 복사본이 있는 JBOD(RAID 아님), 데이터베이스당 300개의 사서함, 서버당 30개의 데이터베이스 복사본이 있는 40개의 데이터베이스(또는 DAG당 120개의 데이터베이스 복사본). 3개의 데이터베이스 복사본은 4개의 노드에 무작위로 배포되므로 어떤 두 서버도 같지 않습니다.
  • 활성화 모델   최소한의 중지로 2개 서버 동시 오류를 허용하는 지정된 오류 시나리오. 서버당 30개의 복사본 중 20개의 데이터베이스가 2개 서버 동시 오류 이벤트 이후 활성화됩니다.
  • 서버 플랫폼   2x4 코어 Intel Xeon x5470 3.33 GHz 프로세서

다음 프로세스가 적용됩니다.

  1. 서버 수 계산   2개 서버 동시 오류를 허용하려면 4개 노드 DAG가 필요하므로 DAG 내에 4개의 사서함 서버로 시작하는 디자인이 필요합니다.
  2. 활성화 모델을 기반으로 서버당 최대 활성 사서함 계산   활성 데이터베이스는 각 노드에 균등하게 배포되므로 이상적으로 각 서버는 3,000개(12,000÷4)의 활성 사서함을 호스트하게 됩니다. (이 예를 기반으로) 2개 노드 동시 오류가 발생한 후 활성 사서함 수를 계산하려면 총 사서함을 남아 있는 2개 노드로 나누어 노드당 활성 사서함 수가 6,000개(12,000÷2)가 됩니다.
    이 예에서 Set-MailboxServer cmdlet의 MaximumActiveDatabases 매개 변수는 20으로 구성됩니다.
  3. **활성 사서함 CPU 요구 사항 계산   **위 테이블을 기반으로 최대 활성 사서함 수(20×300 = 6,000개의 활성 사서함)와 활성 사서함당 메가사이클을 곱합니다(6,000×3메가사이클 = 18,000메가사이클). 각 추가 데이터베이스 복사본에 대해 이 값에 10%를 곱합니다.
    이 예에서 각 데이터베이스에는 하나의 활성 복사본과 두 개의 수동 복사본이 있으므로 18,000메가사이클에 20%가 더해집니다(18,000×1.2 = 21,600메가사이클).
  4. **수동 사서함 CPU 요구 사항 계산  **위 테이블을 기반으로 (서버가 최대 개수의 활성 사서함을 호스트하는 경우) 수동 사서함 수와 수동 사서함당 메가사이클을 곱합니다(3,000×.45메가사이클 = 1,350메가사이클).
  5. **총 CPU 요구 사항을 얻기 위해 수동 CPU 요구 사항 더하기   **이 예에서 21,600 활성 사서함 메가사이클+1,350 수동 사서함 메가사이클 = 22,950메가사이클(총 CPU 요구 사항)
  6. **하드웨어 플랫폼에 총 CPU 요구 사항 적용   **이 예에서는 2x4 코어 Intel Xeon x5470 3.33-GHz 프로세서 기반 서버를 사용합니다. 값은 26,640메가사이클(8×3,330MHz)입니다. 서버 플랫폼을 기반으로 필요한 메가사이클을 사용 가능한 메가사이클로 나누어 2개 노드 동시 오류 후 최고 사용 시간의 CPU 사용률을 예상합니다(예상 CPU 사용률은 22,950÷26,640 = 86%). 86%의 CPU 사용률은 거의 빈 공간 없이 완전히 사용되는 서버를 의미하지만 이는 최고 사용 시간 동안 발생하는 이중 오류 조건을 기반으로 하므로 이 값을 적용할 수 있습니다.
    독립 실행형 서버가 최고 사용 시간 동안 70%의 사용률을 넘지 않도록, 그리고 단일 노드 오류에만 견딜 수 있는 2개 노드 및 3개 노드 구성이 (노드 오류 중) 최고 사용 시간에 80%의 사용률을 넘지 않도록 디자인하는 것이 좋습니다.

맨 위로 이동