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

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

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

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

  • 데이터베이스 복사본 수 제공

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

목차

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

데이터베이스 복사본 수

디자인 단계

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

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

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

  • 모든 데이터베이스 복사본 활성화 디자인 이 모델에서는 활성화되는 호스트된 데이터베이스 복사본의 100퍼센트를 처리하도록 서버를 디자인합니다.

  • 오류 특화 시나리오 디자인 이 모델에서는 최악의 오류 상황에서 활성 사서함 로드를 처리하도록 서버를 디자인합니다.

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

맨 위로 이동

데이터베이스 복사본 수

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

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

맨 위로 이동

디자인 단계

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

  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% 늘어나야 합니다.

다른 프로세서 구성의 메가사이클 계산

다음 섹션 "사서함 서버 용량 계획의 예"에서는 프로세서 코어당 3,333메가사이클을 제공하는 기준 프로세서 구성(2 x 4코어 Intel Xeon x5470 3.33GHz 프로세서)을 사용합니다. 그러나 이 프로세서 구성은 사용자가 배포하는 프로세서 구성과 다를 가능성이 큽니다. 다음 단계를 통해서 메가사이클 조정을 수행하여 서버 디자인에서 지원할 수 있는 메가사이클을 확인할 수 있습니다.

  1. 웹 브라우저를 열고 표준 성능 평가 기관(Standard Performance Evaluation Corporation)으로 이동합니다.

  2. results를 클릭하고 CPU2006를 강조 표시한 다음 Search CUP2006 Results를 선택합니다.

  3. Available Configurations 드롭다운 상자에서 SPECint2006 Rates를 선택합니다. Search Form Request에서, Simple 옵션을 선택한 다음 Go를 클릭합니다. Simple Request에서 검색 조건을 입력합니다(예: Processor Matches x5550).

  4. 배포할 계획인 서버 및 프로세서를 찾아 Execute Simple Fetch를 클릭하고 결과 값을 확인합니다.

예를 들어, Intel x5550 2.67GHz(2,670MHz) 프로세서가 장착된 Dell PowerEdge M710 8코어 서버를 배포하는 경우를 가정합니다. 이 구성의 SPECint_rate2006 결과 값은 240이고 코어당 값은 30입니다(수식에서 새 플랫폼 코어당 값으로 표시됨).

기준 시스템(HP DL380 G5 x5470 3.33GHz, 8개 코어(3,333 MHz))의 SPECint_rate2006 결과 값은 150이며 코어당 값은 18.75입니다(수식에서 기준 코어당 값으로 표시됨).

M710 플랫폼 예의 메가사이클을 확인하려면 다음 수식을 사용합니다.

((새 플랫폼 코어당 값) × (기준 플랫폼의 코어당 Hz)) ÷ (기준 코어당 값) = 조정된 코어당 메가사이클

30 × 3,333 ÷ 18.75 = 코어당 5,333메가사이클 또는 서버당 42,662메가사이클

사서함 서버 용량 계획의 예

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

  • 사서함 수   12,000

  • 사서함 프로필   하루에 주고받은 150개의 메시지

  • 가용성 요구 사항   단일 사이트 내 사서함 복구, 2개 서버 동시 오류에 대한 내결함성

  • 저장소 아키텍처   3개의 데이터베이스 복사본이 있는 JBOD(Just A Bunch Of Disk)(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,664메가사이클(8×3,330MHz)입니다. 서버 플랫폼을 기반으로 필요한 메가사이클을 사용 가능한 메가사이클로 나누어 2개 노드 동시 오류 후 최고 사용 시간의 CPU 사용률을 예상합니다(예상 CPU 사용률은 22,950 ÷ 26,664 = 86%). 86%의 CPU 사용률은 거의 빈 공간 없이 완전히 사용되는 서버를 의미하지만 이는 최고 사용 시간 동안 발생하는 이중 오류 조건을 기반으로 하므로 이 값을 적용할 수 있습니다.

    독립 실행형 서버가 최고 사용 시간 동안 70%의 사용률을 넘지 않도록, 그리고 단일 노드 오류에만 견딜 수 있는 2개 노드 및 3개 노드 구성이 (노드 오류 중) 최고 사용 시간에 80%의 사용률을 넘지 않도록 디자인하는 것이 좋습니다.

가상화

새로운 가상화된 배포의 크기를 지정하는 경우 프로세서를 초과 구독하지 않는 것이 좋습니다. 따라서 호스트에서 논리적 코어와 가상 CPU를 1:1 비율로 사용하려고 합니다. 여기서 이 항목에 설명된 실제 크기 지정과 관련된 지침을 따르고 10% 하이퍼바이저 CPU 오버헤드를 고려합니다. 예를 들어, 실제 배포의 크기를 코어당 500명 사용자로 지정한 경우 가상 배포의 크기는 코어당 450명 사용자가 됩니다.

데이터 센터당 필요한 사서함 코어 수 계산

서버 역할 비율 및 Exchange 성능 이해에서 언급한 것처럼, 사서함 서버 부하를 기반으로 허브 전송 서버, 클라이언트 액세스 서버 및 글로벌 카탈로그 서버의 크기를 조정해야 합니다.

일반적으로 프로세서 코어 비율 지침은 배포한 총 사서함 코어 수를 기반으로 가정하지만, 이 경우는 해당되지 않습니다. 일반적으로 사서함 서버는 100%의 시간 동안 100%의 CPU 사용률로 실행되지 않습니다. 디자인이 잘 된 솔루션의 CPU 사용률은 이전 섹션에서 설명한 70% 및 80% 디자인 임계값을 기반으로 확장된 시간 동안 100%가 되어서는 안 됩니다.

허브 전송 서버, 클라이언트 액세스 서버 및 글로벌 카탈로그 서버 프로세서 코어의 최소 수를 계산하려면, 최악의 장애 모델 동안 활성 사서함 데이터베이스를 지원하는 데 필요한 사서함 코어 수를 정해야 합니다.

데이터 센터 내 필요한 사서함 코어를 계산하는 공식:

필요한 사서함 코어 = (활성 사서함 CPU 요구 사항) ÷ (조정된 코어당 메가사이클) × (남아 있는 서버 개수) × (DAG 개수)

고가용성 솔루션을 배포하지 않은 경우의 공식:

필요한 사서함 코어 = (활성 사서함 CPU 요구 사항) ÷ (조정된 코어당 메가사이클) × (데이터 센터 내 사서함 서버 개수)

데이터 센터당 필요한 사서함 코어 수 계산 예

앞의 예에서 해당 솔루션은 두 개의 서버 장애를 견딜 수 있으며 남아 있는 각 서버는 18,000메가사이클이 필요합니다. 따라서 다음과 같습니다.

필요한 사서함 코어 = (18,000 ÷ 3,333) × 2

= 5.4 × 2

= 총 11코어

이는 이 데이터 센터 내에서 지정된 장애 모델(또는 남아 있는 사서함 서버당 5.5코어) 동안 사용 가능한 16개 사서함 코어 중 총 11개의 코어가 사용된다는 것을 의미합니다.

이 데이터를 기반으로 할 때 허브 전송 서버, 클라이언트 액세스 서버 및 글로벌 카탈로그 서버를 위해 데이터 센터 내에서 배포해야 하는 프로세서 코어의 최소 수는 다음과 같습니다.

데이터 센터당 허브 전송 서버(바이러스 백신 포함) 프로세서 코어의 최소 수 = (데이터 센터당 필요한 사서함 코어 수) ÷ 5

= 11 ÷ 5

= 3코어

데이터 센터당 클라이언트 액세스 서버 프로세서 코어의 최소 수 = (데이터 센터당 필요한 사서함 코어의 수) × 3 ÷ 4

= 11 × 3 ÷ 4

= 33 ÷ 4

= 9코어

데이터 센터당 글로벌 카탈로그 서버(64비트) 프로세서 코어의 최소 수 = (데이터 센터당 필요한 사서함 코어 수) ÷ 8

= 11 ÷ 8

= 2코어

맨 위로 이동

 © 2010 Microsoft Corporation. 모든 권리 보유.