Exchange 2010 테스트된 솔루션: Cisco Unified Compute System 블레이드 서버 및 EMC CLARiiON Storage에서 Hyper-V를 실행 중인 세 사이트의 32400개의 사서함
마지막으로 수정된 항목: 2016-12-14
Rob Simpson, 프로그램 관리자, Microsoft Exchange; Boris Voronin, 선임 솔루션 엔지니어, Exchange 솔루션 엔지니어링, EMC; Mike Mankovsky, Microsoft 솔루션 설계자, Cisco
날짜
2011년 6월
Exchange 2010 테스트 솔루션
Microsoft와 참여 서버, 저장소 및 네트워크 파트너는 Exchange 2010 테스트 솔루션에서 Microsoft Exchange Server 2010을 배포하려는 고객이 접하는 일반적인 고객 시나리오와 주요 디자인 관련 결정 사항을 검토했습니다. 이러한 일련의 백서를 통해 일부 서버, 저장소 및 네트워크 파트너가 제공한 하드웨어에 배포된 Exchange 2010 솔루션 중 디자인이 뛰어나고 비용 효율적인 몇 가지 예를 제공합니다.
이 문서는 Microsoft 다운로드 센터에서 다운로드할 수 있습니다.
적용 대상
Microsoft Exchange Server 2010 SP1(서비스 팩 1)
Windows Server 2008 R2
Windows Server 2008 R2 Hyper-V
목차
소개
솔루션 요약
고객 요구 사항
사서함 프로필 요구 사항
지리적 위치 요구 사항
서버와 데이터 보호 요구 사항
디자인 가정
서버 구성 가정
저장소 구성 가정
솔루션 디자인
고가용성 전략 결정
사서함 저장소 용량 요구 사항 예측
사서함 I/O 요구 사항 예측
저장소 유형 결정
DAS 또는 SAN 저장소 솔루션 선호 여부 결정
저장소 솔루션 선택
사서함 메모리 요구 사항 예측
필요한 데이터베이스 캐시 계산
사서함 CPU 요구 사항 예측
사서함 요구 사항 요약
서버 모델 결정
서버 모델의 CPU 용량 계산
필요한 실제 사서함 서버 수 결정
일반적인 작동 조건 및 오류 시나리오에서 사서함 서버별 활성 사서함 수 결정
별도의 물리적 서버에 클라이언트 액세스 및 허브 전송 서버 역할 배포 여부 결정
필요한 실제 클라이언트 액세스 및 허브 전송 조합 서버 수 결정
필요한 총 실제 서버 수 결정
서버 가상화 사용 여부 결정
실제 서버 수를 줄이는 데 가상화 사용 가능 여부 결정
Hyper-V 루트 서버의 CPU 용량 계산
가상화 오버헤드에 사용할 수 있는 메가사이클 수 조정
VM의 CPU 용량 확인
기본 사서함 서버 VM의 CPU 용량 확인
보조 사서함 서버 VM의 CPU 용량 확인
기본 사서함 서버 VM당 필요한 메모리 결정
보조 사서함 서버 VM당 필요한 메모리 확인
클라이언트 액세스 및 허브 전송 조합 서버당 필요한 메모리 결정
Hyper-V 루트 서버당 필요한 메모리 확인
데이터베이스 가용성 그룹 디자인
데이터베이스 복사본 레이아웃 디자인
데이터 센터 활성화 조정 모드
파일 공유 감시 배치 확인
네임스페이스 계획
클라이언트 액세스 서버 배열 및 로드 균형 조정 전략 결정
하드웨어 부하 분산 모델 결정
저장소 디자인 결정
솔루션 개요
논리 솔루션 다이어그램
물리적 솔루션 다이어그램
Hyper-V 루트 서버 구성 요약
클라이언트 액세스 및 허브 전송 서버 구성
사서함 서버 구성
데이터베이스 레이아웃
저장소 하드웨어 요약
저장소 구성
솔루션 유효성 검사 방법론
저장소 디자인 유효성 검사 방법론
서버 디자인 유효성 검사
기능 유효성 검사 테스트
데이터베이스 전환 유효성 검사
서버 전환 유효성 검사
서버 장애 조치 유효성 검사
데이터 센터 전환 유효성 검사
기본 데이터 센터 서비스 복원 유효성 검사
테스트 시설
솔루션 유효성 검사 결과
기능 유효성 검사 결과
저장소 디자인 유효성 검사 결과
서버 디자인 유효성 검사 결과
결론
추가 정보
소개
이 설명서에서는 Cisco 통합 컴퓨팅 시스템 블레이드 서버와 EMC CLARiiON 저장소 솔루션에 32,400개의 사서함을 배포한 고객 환경에서 Windows Server 2008 R2 Hyper-V 기술을 실행 중인 Exchange Server 2010 솔루션을 디자인하고 테스트하고 유효성을 검사하는 방법에 대한 예를 제공합니다. 규모가 더 큰 Exchange 2010 환경을 디자인하는 경우 주요 문제점 중 하나는 사용 가능한 현재 서버와 저장소 옵션을 검사하고 솔루션의 예상 수명에 대한 최상의 가치를 제공하는 적합한 하드웨어를 선택하는 것입니다. 이 설명서의 단계별 방법에 따라 이러한 주요 문제를 해결하는 데 도움이 되는 중요한 디자인 결정 요소를 안내하고 고객의 핵심 비즈니스 요구 사항이 충족되었는지 확인할 것입니다. 이 고객에 대한 최적의 솔루션을 결정하면 해당 솔루션은 일반 작동, 유지 관리 및 오류 시나리오에 대해 시뮬레이트된 프로덕션 작업을 수행할 수 있는지 확인하기 위해 표준 유효성 검사 프로세스를 거치게 됩니다.
Exchange 2010 테스트 솔루션
솔루션 요약
다음 표에는 이 솔루션의 주요 Exchange 및 하드웨어 구성 요소가 요약되어 있습니다.
Exchange 구성 요소
| Exchange 구성 요소 | 값 또는 설명 |
|---|---|
대상 사서함 수 |
32400 |
대상 평균 사서함 크기 |
2GB(600MB 초기 크기로 씬 프로비저닝됨) |
대상 평균 메시지 프로필 |
하루에 100개 메시지 |
데이터베이스 복사본 수 |
3 |
VSS(볼륨 섀도 복사본 서비스) 백업 |
없음 |
사이트 복구 |
예 |
사이트 수 |
3 |
DAG(데이터베이스 가용성 그룹) 모델 |
활성/활성 배포(여러 DAG) |
가상화 |
Hyper-V |
Exchange 서버 수 |
4대의 VM(가상 컴퓨터) |
실제 서버 수 |
2 |
하드웨어 구성 요소
| 하드웨어 구성 요소 | 값 또는 설명 |
|---|---|
서버 파트너 |
Cisco |
서버 모델 |
M200 |
서버 유형 |
블레이드 |
프로세서 |
Intel Xeon X5570 |
저장소 파트너 |
EMC |
저장소 모델 |
CX4-480 |
저장소 유형 |
SAN(저장 영역 네트워크) |
디스크 유형 |
450GB 15,000 SAS 3.5" |
부하 분산 파트너 |
Cisco |
하드웨어 부하 분산 모델 |
Ace |
Exchange 2010 테스트 솔루션
고객 요구 사항
Exchange 솔루션 디자인의 가장 중요한 첫 번째 단계 중 하나는 올바른 디자인 결정을 내리는 데 중요한 비즈니스 및 기술 요구 사항을 정확하게 요약하는 것입니다. 다음 섹션에서는 이 솔루션에 대한 고객 요구 사항에 대해 간략하게 설명합니다.
Exchange 2010 테스트 솔루션
사서함 프로필 요구 사항
사서함 프로필 요구 사항은 디자인의 다른 모두 구성 요소에 영향을 줄 수 있으므로 이러한 요구 사항을 가능한 한 정확하게 결정해야 합니다. Exchange를 처음 사용하는 경우 몇 가지를 추측해야 할 수 있습니다. 기존 Exchange 환경이 있는 경우 Microsoft Exchange Server Profile Analyzer 도구를 사용하면 이러한 대부분의 정보를 얻는 데 도움을 받을 수 있습니다. 다음 표에는 이 솔루션에 대한 사서함 프로필 요구 사항이 요약되어 있습니다.
사서함 수 요구 사항
| 사서함 수 요구 사항 | 값 |
|---|---|
사서함 수(리소스 사서함을 포함한 총 사서함 수) |
30000 |
예상 사서함 수 증가(%)(솔루션의 수명 동안 예상 사서함 수 증가) |
8% |
예상 사서함 동시성 %(임의 시점의 최대 활성 사서함 수) |
100% |
대상 사서함 수(성장 x 예상 동시성을 포함한 사서함 수) |
32400 |
사서함 크기 요구 사항
| 사서함 크기 요구 사항 | 값 |
|---|---|
평균 사서함 크기(MB) |
600 MB |
평균 사서함 보관 크기(MB) |
해당 없음 |
예상 사서함 크기(MB) 증가(%)(솔루션의 수명 동안 예상 사서함 크기 증가) |
230% |
대상 평균 사서함 크기(MB) |
2,048MB |
사서함 프로필 요구 사항
| 사서함 프로필 요구 사항 | 값 |
|---|---|
대상 메시지 프로필(하루에 사용자당 주고받는 평균 총 메시지 수) |
하루에 100개 메시지 |
대상 평균 메시지 크기(KB) |
75 |
% - MAPI 캐시된 모드 |
100 |
% - MAPI 온라인 모드 |
0 |
% - 외부에서 Outlook 사용 캐시된 모드 |
0 |
% - Microsoft Office Outlook Web App(Exchange 2007 및 이전 버전의 Outlook Web Access) |
0 |
% - Exchange Activesync |
0 |
Exchange 2010 테스트 솔루션
지리적 위치 요구 사항
고가용성 및 사이트 복구에 대한 디자인을 결정할 때 사서함 사용자와 데이터 센터의 배포를 이해하는 것이 중요합니다.
다음 표에서는 Exchange 시스템을 사용하게 될 사람들의 지리적 분포를 간략히 보여줍니다.
사람들의 지리적 분포
| 사서함 사용자 사이트 요구 사항 | 값 |
|---|---|
사서함 사용자가 포함된 주요 사이트의 수 |
3 |
사이트 1의 사서함 사용자 수 |
10800 |
사이트 2의 사서함 사용자 수 |
10800 |
사이트 3의 사서함 사용자 수 |
10800 |
다음 표에서는 Exchange 전자 메일 인프라를 잠재적으로 지원할 수 있는 데이터 센터의 지리적 분포를 간략히 보여줍니다.
데이터 센터의 지리적 분포
| 데이터 센터 사이트 요구 사항 | 값 |
|---|---|
총 데이터 센터 수 |
3 |
데이터 센터 1 주변의 활성 사서함 수 |
10800 |
데이터 센터 2 주변의 활성 사서함 수 |
10800 |
데이터 센터 3 주변의 활성 사서함 수 |
10800 |
Exchange가 둘 이상의 데이터 센터에 상주하기 위한 요구 사항 |
예 |
Exchange 2010 테스트 솔루션
서버와 데이터 보호 요구 사항
환경에 대한 서버와 데이터 보호 요구 사항을 정의하는 것도 중요합니다. 이러한 요구 사항은 고가용성 및 사이트 복구에 대한 디자인 결정을 지원하기 때문입니다.
다음 표에는 서버 보호 요구 사항이 나와 있습니다.
서버 보호 요구 사항
| 서버 보호 요구 사항 | 값 |
|---|---|
사이트 내 동시 서버 또는 VM 실패 수 |
1 |
사이트 오류 발생 중 동시 서버 또는 VM 실패 수 |
0 |
다음 표에는 데이터 보호 요구 사항이 나와 있습니다.
데이터 보호 요구 사항
| 데이터 보호 요구 사항 | 값 또는 설명 |
|---|---|
Exchange 데이터베이스의 백업을 Exchange 환경 외부에 유지 관리하기 위한 요구 사항(예: 타사 백업 솔루션) |
아니요 |
Exchange 데이터베이스의 복사본을 Exchange 환경 내에 유지 관리하기 위한 요구 사항(예: Exchange 고유 데이터 보호) |
예 |
기본 데이터 센터에서 사서함 데이터의 여러 복사본을 유지 관리하기 위한 요구 사항 |
예 |
보조 데이터 센터에서 사서함 데이터의 여러 복사본을 유지 관리하기 위한 요구 사항 |
아니요 |
Exchange 데이터베이스의 지연된 복사본을 유지 관리하기 위한 요구 사항 |
아니요 |
복사 기간 지연(일) |
해당 없음 |
대상 데이터베이스 복사본 수 |
3 |
지운 편지함 폴더 보존 창(일) |
14 |
Exchange 2010 테스트 솔루션
디자인 가정
이 섹션에서는 일반적으로 고객 요구 사항의 일부로 수집되지는 않지만 디자인 및 디자인 유효성 검사 방법에 모두 중요한 정보에 대해 설명합니다.
Exchange 2010 테스트 솔루션
서버 구성 가정
다음 표에서는 일반적인 작동 조건 및 사이트 서버 오류나 서버 유지 관리 조건에 대한 최대 CPU 사용률 대상에 대해 설명합니다.
서버 사용률 대상
| 대상 서버 CPU 사용률 디자인 가정 | 값 |
|---|---|
사서함 서버에 대한 일반 운영 |
<70% |
클라이언트 액세스 서버에 대한 일반 운영 |
<70% |
허브 전송 서버에 대한 일반 운영 |
<70% |
여러 서버 역할(클라이언트 액세스, 허브 전송 및 사서함 서버)에 대한 일반 운영 |
<70% |
여러 서버 역할(클라이언트 액세스 및 허브 전송 서버)에 대한 일반 운영 |
<70% |
사서함 서버에 대한 노드 오류 |
<80% |
클라이언트 액세스 서버에 대한 노드 오류 |
<80% |
허브 전송 서버에 대한 노드 오류 |
<80% |
여러 서버 역할(클라이언트 액세스, 허브 전송 및 사서함 서버)에 대한 노드 오류 |
<80% |
여러 서버 역할(클라이언트 액세스 및 허브 전송 서버)에 대한 노드 오류 |
<80% |
사서함 서버에 대한 사이트 오류 |
<80% |
클라이언트 액세스 서버에 대한 사이트 오류 |
<80% |
허브 전송 서버에 대한 사이트 오류 |
<80% |
여러 서버 역할(클라이언트 액세스, 허브 전송 및 사서함 서버)에 대한 사이트 오류 |
<80% |
여러 서버 역할(클라이언트 액세스 및 허브 전송 서버)에 대한 사이트 오류 |
<80% |
Exchange 2010 테스트 솔루션
저장소 구성 가정
다음 표에는 저장소 구성을 디자인할 때 가정한 몇 가지 데이터 구성 및 입출력(I/O) 정보가 요약되어 있습니다.
데이터 구성 가정
| 데이터 구성 가정 | 값 또는 설명 |
|---|---|
데이터 오버헤드 요소 |
20% |
주당 사서함 이동 |
1% |
전용 유지 관리 또는 복원 LUN(논리 단위 번호) |
아니요 |
LUN 여유 공간 |
20% |
로그 전달 압축 사용 |
예 |
로그 전달 암호화 사용 |
예 |
I/O 구성 가정
| I/O 구성 가정 | 값 또는 설명 |
|---|---|
I/O 오버헤드 요소 |
20% |
추가 I/O 요구 사항 |
없음 |
Exchange 2010 테스트 솔루션
솔루션 디자인
다음 섹션에서는 이 솔루션을 디자인하는 데 사용된 단계별 방법을 제공합니다. 이 방법은 고객 요구 사항과 디자인 가정을 이용하며 Exchange 2010 환경을 디자인할 때 지정해야 하는 주요 디자인 결정 요소를 안내합니다.
Exchange 2010 테스트 솔루션
고가용성 전략 결정
Exchange 2010 환경을 디자인할 때 고가용성 전략에 대한 여러 가지 디자인 결정 요소가 다른 디자인 구성 요소에 영향을 줍니다. 고가용성 전략을 디자인 절차의 첫 단계로 결정하는 것이 좋습니다. 이 단계를 시작하기 전에 다음 정보를 반드시 검토하십시오.
1단계: 사이트 복구 필요 여부 결정
데이터 센터가 두 개 이상 있는 경우 Exchange 인프라를 한 데이터 센터에 배포할 것인지 아니면 둘 이상의 데이터 센터에 분산할 것인지를 결정해야 합니다. 조직의 복구 SLA(서비스 수준 계약)는 기본 데이터 센터 오류를 처리하는 데 필요한 서비스 수준을 정의해야 합니다. 이 정보는 이 결정에 대한 기준을 형성해야 합니다.
*디자인 결정 요소*
이 솔루션에는 세 개의 실제 데이터 센터 위치가 있습니다. SLA에는 데이터 센터 복구가 전자 메일을 비롯한 모든 중요 업무용 서비스에 필요하다고 기술되어 있습니다. Exchange 2010 디자인은 메시징 서비스와 데이터에 대한 사이트 복구를 포함하는 다중 사이트 배포를 기반으로 합니다.
2단계: 사서함 사용자 위치와 데이터 센터 위치 사이의 관계 확인
이 단계에서는 모든 사서함 사용자가 주로 한 사이트에 있는지 아니면 여러 사이트에 분산되어 있는지, 그리고 그러한 사이트가 데이터 센터와 연관되어 있는지를 살펴봅니다. 사서함 사용자가 여러 사이트에 분산되어 있고 데이터 센터가 그러한 사이트와 연관되어 있는 경우 사서함 사용자 및 사이트와 연관된 데이터 센터 간 선호도를 유지 관리하기 위한 요구 사항이 있는지 확인해야 합니다.
*디자인 결정 요소*
이 예에서 세 데이터 센터는 각각 지사에 함께 있습니다. 일반 작동 조건 중에 사용자 위치와 해당 사서함의 기본 활성 복사본 위치 간 선호도를 유지 관리하려고 합니다.
3단계: 데이터베이스 배포 모델 결정
고객이 두 개 이상의 실제 위치에 Exchange 인프라를 배포하기로 결정했기 때문에 고객은 조직의 요구에 가장 적합한 데이터베이스 배포 모델을 결정해야 합니다. 데이터베이스 배포 모델에는 다음 세 가지가 있습니다.
활성/수동 배포 활성 사서함 데이터베이스 복사본은 기본 데이터 센터에 배포되고 수동 데이터베이스 복사본만 보조 데이터 센터에 배포됩니다. 보조 데이터 센터는 대기 데이터 센터 역할을 하며, 일반적인 작동 조건에서는 활성 사서함이 데이터 센터에서 호스트되지 않습니다. 가동 중단이 발생하여 기본 데이터 센터에 영향이 미치는 경우 보조 데이터 센터로의 수동 전환이 수행되고, 기본 데이터 센터가 온라인 상태로 돌아올 때까지 활성 데이터베이스가 여기서 호스트됩니다.
활성/수동 배포
활성/활성 배포(단일 DAG) 활성 사서함 데이터베이스는 기본 및 보조 데이터 센터에 배포됩니다. 해당 수동 복사본은 대체 데이터 센터에 있습니다. 모든 사서함 서버는 단일 DAG의 구성원입니다. 이 모델에서 두 데이터 센터 간의 WAN(Wide Area Network) 연결은 잠재적으로 단일 오류 지점입니다. WAN 연결이 끊기면 쿼럼 손실로 인해 한 데이터 센터에 있는 사서함 서버가 오류 상태가 됩니다.
활성/활성 배포(단일 DAG)
활성/활성 배포(여러 DAG) 이 모델은 여러 DAG를 활용하여 단일 오류 지점으로 WAN 연결을 제거합니다. 한 DAG는 기본 데이터 센터에 활성 데이터베이스 복사본이 있고 보조 데이터 센터에 해당 수동 데이터베이스 복사본이 있습니다. 다른 DAG는 보조 데이터 센터에 활성 데이터베이스 복사본이 있고 기본 데이터 센터에 해당 수동 데이터베이스 복사본이 있습니다. WAN 연결이 끊기는 경우 각 사이트에 있는 활성 복사본은 로컬 사서함 사용자에게 데이터베이스 가용성을 계속 제공합니다.
활성/활성 배포(여러 DAG)
*디자인 결정 요소*
이 예에서는 활성 사서함 데이터베이스가 세 개의 데이터 센터 위치 각각에 배포되므로 데이터베이스 배포 모델이 여러 DAG와 함께 활성/활성 상태가 됩니다. 활성/활성 데이터베이스 배포 모델을 배포할 때 몇 가지 디자인 추가 고려 사항이 있으며, 이러한 사항은 이후 단계에서 설명합니다.
4단계: 백업 및 데이터베이스 복구 전략 결정
Exchange 2010에는 몇 가지 새로운 기능과 중요한 변경 사항이 있는데, 이를 올바르게 배포 및 구성하면 기본 데이터 보호가 제공되어 기존 방식의 데이터 백업이 불필요해집니다. 백업은 일반적으로 재해 복구, 실수로 삭제한 항목 복구, 장기 데이터 저장 및 지정 시간 데이터베이스 복구에 사용됩니다. Exchange 2010은 기존 백업 없이도 이러한 시나리오를 모두 해결할 수 있습니다.
재해 복구 하드웨어 또는 소프트웨어 오류가 발생한 경우 DAG에 있는 여러 데이터베이스 복사본을 사용하여 데이터 손실 없이 빠르게 장애 조치(failover)를 수행하는 방법으로 고가용성을 확보할 수 있습니다. DAG를 여러 사이트로 확장하여 데이터 센터 오류를 복구할 수 있습니다.
실수로 삭제한 항목 복구 Exchange 2010의 새로운 복구할 수 있는 항목 폴더와 폴더에 적용할 수 있는 보존 정책을 사용하면 삭제 및 수정된 데이터를 지정 기간 동안 모두 보관할 수 있으므로 해당 항목을 더 쉽고 빠르게 복구할 수 있습니다. 자세한 내용은 메시징 정책 및 규정 준수, 복구 가능한 항목 이해 및 보존 태그 및 보존 정책 이해을 참조하십시오.
장기 데이터 저장소 백업이 보존 목적으로 사용되기도 합니다. 일반적으로 규정 준수 요구 사항에 따라 장기적으로 지정 시간의 데이터 스냅숏을 보관하는 데에는 테이프가 사용됩니다. 보관, 여러 사서함 검색 및 메시지 보존 등 Exchange 2010의 새로운 기능은 최종 사용자가 액세스할 수 있는 방식으로 데이터를 효과적으로 장기 보존하는 방법을 제공합니다. 자세한 내용은 개인 보관 파일 이해, 여러 사서함 검색 이해 및 보존 태그 및 보존 정책 이해을 참조하십시오.
지정 시간 데이터베이스 스냅숏 조직에 사서함 데이터의 과거 지정 시간 복사본이 필요한 경우 Exchange에서는 DAG 환경에 지연된 복사본을 만드는 기능을 제공합니다. 이 기능은 DAG의 여러 데이터베이스에서 복제되는 논리적인 손상이 생겨 이전 시간으로 돌아가야 하는 경우에 유용합니다. 관리자가 사서함 또는 사용자 데이터를 실수로 삭제한 경우에도 이 기능이 유용할 수 있습니다.
Exchange 2010의 기본 제공 기능을 사용하여 기존 백업을 대체하기 전에 기술적인 이유와 몇 가지 문제를 고려해야 합니다. 이러한 결정을 내리기 전에 백업, 복원 및 재해 복구 이해를 참조하십시오.
*디자인 결정 요소*
이 예에서 현재 Exchange 구현과 함께 기존 백업 솔루션의 주요 용도는 실수로 삭제한 메일 항목을 복구하는 것입니다. 단일 항목 복구에 대한 요청의 80%는 15일 미만의 메시지에 대한 것입니다. 따라서 지운 편지함 보존 기간은 14일이 될 것입니다. 기존의 VSS 백업은 단일 항목을 복원하는 데 필요하지 않으며 복구 시간 목표를 충족하지 않기 때문에 Exchange 고유 데이터 보호 및 지운 편지함 폴더 보존 기능이 데이터베이스 복구 전략으로 사용됩니다.
5단계: 필요한 데이터베이스 복사본 수 결정
데이터베이스 복구 전략을 정의할 때 다음으로 중요한 것은 배포할 데이터베이스 복사본 수를 결정하는 것입니다. RAID(Redundant Array of Independent Disk)나 기존의 VSS 기반 백업과 같은 기존 형태의 데이터베이스 보호를 제거하기 전에 가능하면 사서함 데이터베이스 복사본을 세 개 이상 배포하는 것이 좋습니다.
이러한 결정을 내리기 전에 사서함 데이터베이스 복사본 이해를 참조하십시오.
*디자인 결정 요소*
이 예에서는 기존의 VSS 백업 솔루션이 배포되고 있지 않기 때문에 복구 시간 목표 및 복구 지점 목표 요구 사항을 충족하는지 확인하기 위해 최소 세 개의 데이터베이스 복사본이 배포됩니다. 두 개의 복사본은 기본 데이터 센터에 배치하고 세 번째 복사본은 사이트 복구를 제공할 수 있도록 다른 데이터 센터에 배치합니다.
6단계: 데이터베이스 복사본 유형 결정
두 가지 유형의 데이터베이스 복사본이 있습니다.
고가용성 데이터베이스 복사본 이 데이터베이스 복사본은 재생 지연 시간 0으로 구성됩니다. 이름이 암시하듯이 고가용성 데이터베이스 복사본은 시스템에 의해 최신 상태로 유지되고 자동으로 시스템에서 활성화할 수 있으며 사서함 서비스 및 데이터에 대한 고가용성을 제공하는 데 사용됩니다.
지연된 데이터베이스 복사본 이 데이터베이스 복사본은 일정 시간 동안 트랜잭션 로그 재생을 지연하도록 구성됩니다. 지연된 데이터베이스 복사본은 지정 시간 보호를 제공하도록 디자인되었으며, 저장소 논리적 손상, 관리 오류(예: 연결이 끊어진 사서함 삭제 또는 제거) 및 자동화 오류(예: 연결이 끊어진 사서함 일괄 제거)로부터 복구하는 데 사용할 수 있습니다.
*디자인 결정 요소*
이 예에서는 세 개의 사서함 데이터베이스 복사본 모두 고가용성 데이터베이스 복사본으로 배포됩니다. SLA에서는 데이터의 지연된 복사본을 요구하지 않습니다. 이전에 논리적 손상이 발생하지 않았고 메시징 데이터를 조정하는 다른 응용 프로그램이 사용되고 있지 않으므로 지연된 복사본이 필요하지 않습니다. 지연된 복사본을 사용할 유일한 다른 이유는 단일 지운 편지함 복구 기능을 제공하는 것이지만 지운 편지함 폴더 보존 기능을 사용하여 이 요구 사항을 충족하는 것이 훨씬 쉽고 비용 효율적입니다.
7단계: 사서함 서버 복구 전략 결정
Exchange 2010은 사서함 복구에 대해 다시 설계되었습니다. 자동 장애 조치 보호는 이제 서버 수준 대신 사서함 데이터베이스 수준에서 제공됩니다. 활성 및 수동 데이터베이스 복사본을 DAG 내의 사서함 서버에 전략적으로 배포할 수 있습니다. 서버별로 활성화할 데이터베이스 복사본 수를 결정하는 것이 Exchange 2010 용량 계획의 중요한 부분입니다. 배포할 수 있는 다른 데이터베이스 배포 모델이 있지만 일반적으로 다음 중 하나가 권장됩니다.
활성화된 모든 복사본에 대한 디자인 이 모델에서는 사서함 서버 역할이 서버의 모든 데이터베이스 복사본 활성화를 수용할 수 있도록 크기가 조정됩니다. 예를 들어 사서함 서버 하나는 4개의 데이터베이스 복사본을 호스트할 수 있습니다. 일반적인 작동 조건에서는 서버에 두 개의 활성 데이터베이스 복사본과 두 개의 수동 데이터베이스 복사본이 있을 수 있습니다. 오류 또는 유지 관리 이벤트 동안 4개의 데이터베이스 복사본이 모두 사서함 서버에서 활성화됩니다. 이 솔루션은 일반적으로 쌍으로 배포됩니다. 예를 들면 4개의 서버를 배포하는 경우 첫 번째 쌍은 서버 MBX1과 MBX2이고, 두 번째 쌍은 서버 MBX3과 MBX4입니다. 또한, 이 모델에 대해 디자인할 때 일반적인 작동 조건에서 각 사서함 서버의 크기를 사용 가능한 리소스의 40%로 지정합니다. 3개의 데이터베이스 복사본과 6개의 서버로 구성된 사이트 복구 배포에서, 보조 데이터 센터에 세 번째 서버가 있는 3개의 서버 집합에 이 모델을 배포할 수 있습니다. 이 모델은 활성/수동 사이트 복구 모델을 사용하여 솔루션에 3개의 서버로 된 구성 요소를 제공합니다.
이 모델은 다음 시나리오에서 사용할 수 있습니다.
오류 도메인(예: 랙, 블레이드 엔클로저 및 저장소 배열)에 기본 데이터 센터에서 데이터베이스 복사본을 쉽게 격리해야 하는 활성/수동 다중 사이트 구성
예상되는 성장에 따라 확장의 논리 단위를 쉽게 추가할 수 있는 활성/수동 다중 사이트 구성
DAG에서 두 사서함 서버의 동시 손실을 감당할 필요가 없는 구성
이 모델은 단일 사이트 배포의 경우 쌍으로, 여러 사이트 배포의 경우 세 세트로 서버를 배포해야 합니다. 다음 표에서는 이 모델에 대한 샘플 데이터베이스 레이아웃을 보여줍니다.
활성화한 모든 복사본에 대한 디자인
앞의 표에서 다음이 적용됩니다.
C1 = 일반 작업 중에 활성 복사본(활성화 기본 설정값 1)
C2 = 일반 작업 중에 수동 복사본(활성화 기본 설정값 2)
C3 = 사이트 오류 이벤트 중에 수동 복사본(활성화 기본 설정값 3)
오류 특화 시나리오 디자인 이 모델에서는 사서함 서버 역할이 서버에서 데이터베이스 복사본 하위 집합의 활성화를 수용할 수 있게 디자인됩니다. 하위 집합의 데이터베이스 복사본 수는 디자인할 특정 오류 시나리오에 따라 다릅니다. 이 디자인의 주요 목표는 활성 데이터베이스 부하를 DAG의 나머지 사서함 서버에 고르게 분산하는 것입니다.
이 모델은 다음 시나리오에서 사용해야 합니다.
데이터베이스 복사본이 3개 이상 있는 모든 단일 사이트 구성
DAG에서 두 사서함 서버 동시 손실을 감당해야 하는 구성
이 모델에 대한 DAG 디자인에는 3 - 16개의 사서함 서버가 필요합니다. 다음 표에서는 이 모델에 대한 샘플 데이터베이스 레이아웃을 보여줍니다.
오류 특화 시나리오 디자인
앞의 표에서 다음이 적용됩니다.
C1 = 일반 작업 중에 활성 복사본(활성화 기본 설정값 1)
C2 = 일반 작업 중에 수동 복사본(활성화 기본 설정값 2)
C3 = 일반 작업 중에 수동 복사본(활성화 기본 설정값 3)
*디자인 결정 요소*
이전 단계에서 여러 DAG가 있는 활성/활성 데이터베이스 배포 모델을 배포하기로 했습니다. 이 모델의 각 DAG에는 기본 데이터 센터에 두 개의 고가용성 데이터베이스 복사본만 있는 활성/수동 구성이 있기 때문에, 활성화된 모든 복사본에 대해 디자인되는 사서함 서버 복구 전략이 가장 적합합니다.
8단계: 데이터베이스 가용성 그룹 수 결정
DAG는 Exchange 2010에 기본 제공되는 고가용성 및 사이트 복구 프레임워크의 기본 구성 요소입니다. DAG는 복제된 데이터베이스 집합을 호스트하고 개별 서버나 데이터베이스에 영향을 주는 오류로부터 데이터베이스 수준의 자동 복구를 제공하는 최대 16개의 사서함 서버 그룹입니다.
DAG는 사서함 데이터베이스 복제, 데이터베이스와 서버 전환 및 장애 조치의 경계이자 Active Manager라는 내부 구성 요소의 경계입니다. Active Manager는 전환 및 장애 조치를 관리하는 Exchange 2010 구성 요소입니다. Active Manager는 DAG의 모든 서버에서 실행됩니다.
계획 관점에서 보면 배포되는 DAG 수를 최소화해야 합니다. 다음과 같은 경우 둘 이상의 DAG를 고려해야 합니다.
16개가 넘는 사서함 서버를 배포합니다.
여러 사이트(활성/활성 사이트 구성)에 활성 사서함 사용자가 있습니다.
별도 DAG 수준의 관리 경계가 필요합니다.
별도의 도메인에 사서함 서버가 있습니다. DAG는 도메인 경계입니다.
*디자인 결정 요소*
이전 단계에서 활성/활성 데이터베이스 배포 모델을 배포하기로 했습니다. 각 사이트에 활성 사서함 사용자가 있는 단일 DAG를 배포할 수 있습니다. 하지만 한 사이트에 있는 DAG 구성원과 다른 사이트에 있는 DAG 구성원의 연결이 일시적으로 끊기는 경우 해당 사이트에 있는 클러스터가 쿼럼 손실로 인해 제대로 작동하지 않게 됩니다. 이런 이유로 세 개의 DAG가 배포됩니다. 각 DAG에는 기본 및 보조 데이터베이스 복사본을 호스트할 기본 데이터 센터의 사서함 서버가 포함됩니다. 또한 각 DAG에는 세 번째 데이터베이스 복사본을 호스트할 대체 데이터 센터 중 하나에 있는 서버가 포함됩니다. 따라서 각 데이터 센터에서 한 DAG의 기본 및 보조 복사본과 다른 DAG의 세 번째 복사본을 호스트하는 세 개의 활성/수동 DAG 디자인이 됩니다.
9단계: DAG당 사서함 서버 수 결정
이 단계에서는 DAG 디자인을 지원하는 데 필요한 최소 사서함 서버 수를 결정해야 합니다. 이 수는 작업을 지원하는 데 필요한 서버 수와 다를 수 있으므로 서버 수에 대한 최종 결정은 다음 단계에서 합니다.
*디자인 결정 요소*
이전 단계에서는 세 개의 활성/수동 DAG를 배포하고, 활성화할 모든 복사본에 대해 서버 복구 전략을 디자인하기로 결정했습니다. 각 DAG를 세 개 서버 단위로 배포해야 합니다(기본 사이트에 두 개, 대체 사이트에 한 개). 세 개의 DAG가 배포되므로 DAG 디자인을 지원하는 데 필요한 최소 서버 수는 9개입니다. 이 솔루션에는 작업을 지원하는 데 필요한 서버 수에 따라 9, 18 또는 27개의 서버가 사용됩니다. 다음 표에서는 가능한 구성을 간략히 보여줍니다.
DAG당 사서함 서버 수
| DAG1 기본 데이터 센터 | DAG1 보조 데이터 센터 | DAG2 기본 데이터 센터 | DAG2 보조 데이터 센터 | DAG3 기본 데이터 센터 | DAG3 보조 데이터 센터 | 총 사서함 서버 개수 |
|---|---|---|---|---|---|---|
2 |
1 |
2 |
1 |
2 |
1 |
9 |
4 |
2 |
4 |
2 |
4 |
2 |
18 |
6 |
3 |
6 |
3 |
6 |
3 |
27 |
참고
세 개 노드로 구성된 DAG 모델의 경우 기본 데이터 센터에서 두 개 노드를 손실하면 클러스터가 쿼럼 및 자동 활성화를 손실하게 됩니다. 보조 데이터 센터의 세 번째 복사본이 추가 데이터 가용성을 제공하지만 보조 데이터 센터의 서비스 복구는 수동 작업입니다.
Exchange 2010 테스트 솔루션
사서함 저장소 용량 요구 사항 예측
여러 요소가 사서함 서버 역할에 대한 저장소 용량 요구 사항에 영향을 줍니다. 자세한 내용은 사서함 데이터베이스 및 로그 용량 요소 이해를 검토하는 것이 좋습니다.
다음 단계는 사서함 용량 요구 사항을 계산하는 방법을 간략하게 설명합니다. 이러한 요구 사항은 어떤 저장소 솔루션 옵션이 용량 요구 사항을 충족하는지를 결정하는 데 사용됩니다. 이후 섹션에서는 선택한 저장소 플랫폼에서 저장소 레이아웃을 적절히 디자인하는 데 필요한 추가 계산을 다룹니다.
Microsoft는 이러한 대부분의 작업을 수행할 사서함 서버 역할 요구 사항 계산기를 만들었습니다. 계산기를 다운로드하려면 E2010 사서함 서버 역할 요구 사항 계산기를 참조하십시오. 계산기 사용에 대한 자세한 내용은 Exchange 2010 사서함 서버 역할 요구 사항 계산기를 참조하십시오.
1단계: 디스크의 사서함 크기 계산
총 저장소 요구 사항을 확인하기 전에 디스크의 사서함 크기를 알고 있어야 합니다. 할당량이 1GB인 전체 사서함에는 1GB가 넘는 디스크 공간이 필요합니다. 보내기/받기 금지 제한, 사용자가 일별로 주고받는 메시지 수, 지운 편지함 폴더 보존 창(사용하도록 설정된 일정 버전 로깅 및 단일 항목 복구가 있거나 없음) 및 사서함당 평균 데이터베이스 일별 변동을 고려해야 하기 때문입니다. 사서함 서버 역할 요구 사항 계산기는 이러한 계산을 대신 수행합니다. 다음 정보를 사용하여 수동으로 계산할 수도 있습니다.
다음 계산은 이 솔루션에서 사서함 제한이 2GB인 사서함에 대한 디스크의 사서함 크기를 결정할 때 사용합니다.
공백 = 하루 100개 메시지 x 75 ÷ 1024MB = 7.3MB
휴지통 = (하루 100개 메시지 x 75 ÷ 1024MB × 14일) + (2048MB x 0.012) + (2048MB x 0.058) = 246MB
디스크의 사서함 크기 = 사서함 제한 + 공백 + 휴지통
= 2048 + 7.3 + 246
= 2,301 MB
2단계: 데이터베이스 저장소 용량 요구 사항 계산
이 단계에서는 모든 사서함 데이터베이스에 필요한 높은 수준의 저장소 용량이 결정됩니다. 계산된 용량에는 데이터베이스 크기, 카탈로그 인덱스 크기 및 20%의 사용 가능한 공간이 포함됩니다.
모든 데이터베이스에 필요한 저장소 용량을 결정하려면 다음 수식을 사용합니다.
데이터베이스 크기 = (사서함 수 × 디스크의 사서함 크기 × 데이터베이스 오버헤드 성장 요소) + (20% 데이터 오버헤드)
= (32400 × 2301 × 1) + (14910480)
= 89,462,880 MB
= 87,366 GB
데이터베이스 인덱스 크기 = 데이터베이스 크기의 10%
= 87366 × 0.10
= 8,737 GB
총 데이터베이스 용량 = (데이터베이스 크기) + (인덱스 크기) ÷ 0.80(20%의 사용 가능한 볼륨 공간 추가)
= (87366 + 8737) ÷ 0.8
= 120,128 GB
3단계: 트랜잭션 로그 저장소 용량 요구 사항 계산
공간 할당 문제로 인해 사서함 서버가 중단된 상태를 유지하지 않게 하려면 백업 세트 도중 생성된 모든 로그를 포함하도록 트랜잭션 로그의 크기도 조정해야 합니다. 이 아키텍처에서 사서함 복구 및 단일 복구 기능을 백업 아키텍처로 활용한다는 점을 고려하면 오류가 발생한 복사본이 3일 동안 복구되지 않을 경우 매일 3개의 로그 생성 속도에 대해 로그 용량을 할당해야 합니다. (복사에 실패하면 로그가 잘리지 않습니다.) 서버가 3일 이내에 다시 온라인 상태가 되지 않으면 복사본을 일시적으로 제거하여 자르기가 수행되도록 할 수 있습니다.
모든 트랜잭션 로그에 필요한 저장소 용량을 결정하려면 다음 수식을 사용합니다.
로그 파일 크기 = (로그 파일 크기 × 일별 사서함당 로그 수 × 실패한 인프라를 교체하는 데 필요한 일 수 × 사서함 사용자 수) + (1% 사서함 이동 오버헤드)
= (1MB × 20 × 4 × 32400) + (32400 × 0.01 × 2048MB)
= 3,255,552 MB
= 3,179 GB
총 로그 용량 = 로그 파일 크기 ÷ 0.80(20%의 사용 가능한 볼륨 공간 추가)
= (3179) ÷ 0.80
= 3974
4단계: 총 저장소 용량 요구 사항 결정
다음 표에는 이 솔루션에 대한 높은 수준의 저장소 용량 요구 사항이 요약되어 있습니다. 이후 단계에서는 이 정보를 사용하여 배포할 저장소 솔루션을 결정합니다. 그런 다음 이후 단계의 특정 저장소 요구 사항을 자세히 살펴봅니다.
저장소 용량 요구 사항 요약
| 디스크 공간 요구 사항 | 값 |
|---|---|
디스크의 평균 사서함 크기(MB) |
2301 |
필요한 데이터베이스 용량(GB) |
120128 |
필요한 로그 용량(GB) |
3974 |
필요한 총 용량(GB) |
124102 |
세 개의 데이터베이스 복사본에 필요한 총 용량(GB) |
372306 |
세 개의 데이터베이스 복사본에 필요한 총 용량(TB) |
364 |
각 사이트에 필요한 총 용량(TB) |
122 |
Exchange 2010 테스트 솔루션
사서함 I/O 요구 사항 예측
Exchange 환경을 디자인할 때 데이터베이스 및 로그 성능 요소를 이해해야 합니다. 데이터베이스와 로그 성능 요소 이해를 검토하는 것이 좋습니다.
1단계: 총 사서함 I/O 요구 사항 계산
각 사서함 사용자가 사용하는 IOPS(초당 데이터베이스 I/O)의 크기를 이해해야 하는데, 그 이유는 IOPS가 저장소 크기를 적절히 지정하는 데 필요한 주요 트랜잭션 I/O 메트릭 중 하나이기 때문입니다. 저장소 하위 시스템은 임의 I/O보다 훨씬 더 효율적으로 순차 I/O를 처리할 수 있기 때문에 단순 순차 I/O 작업이 사서함 서버당 IOPS 계산에서 고려되지 않습니다. 이러한 작업에는 백그라운드 데이터베이스 유지 관리, 로그 트랜잭션 I/O 및 로그 복제 I/O가 포함됩니다. 이 단계에서는 다음을 사용하여 모든 사서함 사용자를 지원하는 데 필요한 총 IOPS를 계산합니다.
사서함 사용자별 예상 IOPS = 0.10
필요한 총 IOPS = 사서함 사용자별 IOPS × 사서함 수 × I/O 오버헤드 요소
= 0.10 × 32400 × 1.2
= 3888
참고
다른 메시지 프로필에 대한 IOPS 프로필을 확인하려면 데이터베이스와 로그 성능 요소 이해의 표, "메시지 활동 기반의 사서함당 데이터베이스 캐시 및 예상 IOPS"를 참조하십시오.
2단계: 사이트별 총 사서함 I/O 요구 사항 계산
이것은 다중 사이트 배포이므로 각 사이트에 대한 저장소 크기를 적절히 지정하기 위해 사이트별 IOPS 요구 사항을 고려해야 합니다. 이전 단계에서, 각 사이트가 기본 DAG의 기본 및 보조 데이터베이스 복사본과 대체 DAG의 제3의 데이터베이스 복사본을 호스트하는 것으로 결정했습니다. 이 모델에서 최악의 시나리오는 기본 DAG의 10,800개 사서함과 대체 DAG의 10,800개 사서함이 해당 사이트에 있는 저장소에서 활성화된 상태에서 단일 사이트 오류가 발생하는 경우입니다. 다음 계산을 사용합니다.
사이트별로 필요한 총 IOPS = 사서함 사용자별 IOPS × 사서함 수 × I/O 오버헤드 요소
= 0.10 × 21600 × 1.2
= 2592
Exchange 2010 테스트 솔루션
저장소 유형 결정
Exchange 2010에는 조직이 다양한 저장소 옵션으로 Exchange를 실행할 수 있도록 성능, 안정성 및 고가용성의 향상된 기능이 포함되어 있습니다.
사용 가능한 저장소 옵션을 검토할 때 Exchange에 대한 성공적인 저장소 솔루션을 얻으려면 성능, 용량, 관리 효율성 및 비용 요구 사항의 균형을 맞추는 것이 반드시 필요합니다.
Exchange 2010 저장소 솔루션 선택에 대한 자세한 내용은 사서함 서버 저장소 디자인을 참조하십시오.
Exchange 2010 테스트 솔루션
DAS 또는 SAN 저장소 솔루션 선호 여부 결정
Exchange 2010에 사용할 수 있는 저장소 옵션은 매우 다양합니다. DAS(직접 연결 저장소) 솔루션을 배포할 것인지(로컬 디스크 사용 포함) 아니면 SAN 솔루션을 배포할 것인지를 결정하여 선택 목록을 줄일 수 있습니다. 선택하는 이유가 여러 가지가 있으므로 선호하는 저장소 공급업체와 함께 자신의 비즈니스 및 TCO(총 소유 비용) 요구 사항에 맞는 솔루션을 결정해야 합니다.
*디자인 결정 요소*
이 예에서는 SAN 인프라가 배포되며 SAN은 환경의 모든 데이터를 저장하는 데 사용됩니다. SAN 저장소 솔루션을 계속 사용할 것이므로 Exchange 2010을 배포하는 옵션에 대해 알아보겠습니다.
Exchange 2010 테스트 솔루션
저장소 솔루션 선택
다음 단계를 사용하여 저장소 솔루션을 선택합니다.
1단계: 기본 저장소 공급업체 식별
이 예에서는 EMC 저장소가 여러 해 동안 사용되었으므로 Exchange 2010 배포에 EMC 저장소 솔루션을 사용합니다. EMC Corporation은 CLARiiON 및 Symmetric 같은 고성능의 저장소 배열을 제공합니다.
2단계: 기본 공급업체에서 사용 가능한 옵션 검토
EMC CLARiiON 제품군은 엔터프라이즈 플래시 드라이브, 파이버 채널 및 SATA(Serial ATA)와 같은 여러 계층의 저장소를 제공하는데, 이 경우 단일 관리 인터페이스로 여러 계층을 관리할 수 있으므로 비용이 절감됩니다.
CLARiiON Virtual Provisioning은 간소화된 저장소 관리 및 향상된 용량 사용률을 비롯하여 기존의 씬 프로비저닝을 뛰어넘는 이점을 제공합니다. 호스트에 대용량을 제공한 다음 필요에 따라 공유 풀에서 공간을 사용할 수 있습니다.
CLARiiON CX4 시리즈는 네 개의 모델에 유연한 수준의 용량, 기능 및 성능을 제공합니다. 각 모델의 기능이 다음 표에 설명되어 있습니다.
CLARiiON CX4 시리즈 기능
| Feature | CX4 모델 120 | CX4 모델 240 | CX4 모델 480 | CX4 모델 960 |
|---|---|---|---|---|
최대 디스크 수 |
120 |
240 |
480 |
960 |
저장소 프로세서 수 |
2 |
2 |
2 |
2 |
저장소 프로세서별 실제 메모리 |
3 GB |
4 GB |
8 GB |
16 GB |
최대 쓰기 캐시 |
600 MB |
1.264 GB |
4.5 GB |
10.764 GB |
시스템별 최대 Initiator 수 |
256 |
512 |
512 |
1024 |
고가용성 호스트 수 |
128 |
256 |
256 |
512 |
최소 폼 요소 크기 |
6U |
6U |
6U |
9U |
최대 표준 LUN 수 |
1024 |
1024 |
4096 |
4096 |
SnapView 스냅숏 |
예 |
예 |
예 |
예 |
SnapView 복제 |
예 |
예 |
예 |
예 |
SAN 복사본 |
예 |
예 |
예 |
예 |
MirrorView/S |
예 |
예 |
예 |
예 |
MirrorView/A |
예 |
예 |
예 |
예 |
RecoverPoint/S |
예 |
예 |
예 |
예 |
RecoverPoint/A |
예 |
예 |
예 |
예 |
3단계: 디스크 유형 선택
이 예에서는 초기 Exchange 사용자 요구 사항을 충족할 수 있도록 I/O 성능 및 용량을 제공하는 450GB 파이버 채널 15,000rpm 디스크를 선택합니다.
참고
테스트를 수행한 이후 600GB 10,000rpm 디스크의 가격이 하락했으므로 이 배포에 적합합니다.
4단계: 배열 선택
이 예에서 솔루션은 122TB의 사용 가능한 저장소와 2,592 IOPS를 제공해야 합니다. 이전 표에 있는 옵션은 모두 IOPS 요구 사항을 처리하므로 결정은 용량 요구 사항을 기준으로 합니다. CLARiiON CX4 모델 240은 약 100TB의 사용 가능한 용량에만 RAID-5 구성의 450GB의 디스크를 제공합니다. EMC CLARiiON CX4 모델 480은 Exchange 2010 요구 사항을 모두 지원하는 데 필요한 용량과 I/O 성능을 제공하므로 이 모델을 선택했습니다.
Exchange 2010 테스트 솔루션
사서함 메모리 요구 사항 예측
정상적인 Exchange 환경을 디자인할 때 중요한 단계는 메모리 크기를 올바르게 조정하는 것입니다. 메모리 구성 및 Exchange 성능 이해 및 사서함 데이터베이스 캐시 이해를 검토하는 것이 좋습니다.
Exchange 2010 테스트 솔루션
필요한 데이터베이스 캐시 계산
ESE(Extensible Storage Engine)는 데이터베이스 캐시를 사용하여 I/O 작업을 줄입니다. 일반적으로, 사용할 수 있는 데이터베이스 캐시가 많을수록 Exchange 2010 사서함 서버에서 I/O가 덜 생성됩니다. 하지만 데이터베이스 캐시를 추가하면 IOPS의 대폭 감소가 멈추는 시점이 있습니다. 따라서 필요한 최적의 데이터베이스 캐시 양을 결정하지 않고 Exchange 서버에 많은 양의 실제 메모리를 추가하면 비용은 많이 들고 성능 혜택은 최소화될 수 있습니다.
이전 단계에서 완료한 IOPS 예상치는 사서함당 최소 데이터베이스 캐시 양을 가정합니다. 이러한 최소 양은 사서함 데이터베이스 캐시 이해의 표, "메시지 활동 및 사서함 데이터베이스 캐시 기반의 사서함당 예상 IOPS"에 요약되어 있습니다.
다음 표에서는 여러 메시지 프로필에 대한 사용자별 데이터베이스 캐시를 간략히 보여줍니다.
사용자당 데이터베이스 캐시
| 하루에 사서함당 주고받는 메시지 수(평균 메시지 크기 약 75KB) | 사용자당 데이터베이스 캐시(MB) |
|---|---|
50 |
3 MB |
100 |
6 MB |
150 |
9 MB |
200 |
12 MB |
이 단계에서는 전체 환경에 대한 높은 수준의 메모리 요구 사항을 결정합니다. 이후 단계에서는 이 결과를 사용하여 각 사서함 서버에 필요한 실제 메모리 양을 결정합니다. 다음 계산을 사용합니다.
데이터베이스 캐시 = 프로필 특정 데이터베이스 캐시 × 사서함 사용자 수
= 6MB × 32400
= 194,400 MB
= 190 GB
Exchange 2010 테스트 솔루션
사서함 CPU 요구 사항 예측
Exchange 2010에 제공된 새 사서함 데이터베이스 복구 모델로 인해 사서함 서버 용량 계획이 이전 버전의 Exchange에서 크게 변경되었습니다. 자세한 내용은 사서함 서버 프로세서 용량 계획을 참조하십시오.
다음 단계에서 활성 및 수동 데이터베이스 복사본에 대한 높은 수준의 메가사이클 요구 사항을 계산합니다. 이러한 요구 사항은 작업을 지원하는 데 필요한 사서함 서버 수를 결정하는 데 사용됩니다. 필요한 사서함 서버 수는 또한 사서함 서버 복구 모델 및 데이터베이스 복사본 레이아웃에 따라 다릅니다.
메가사이클 요구 사항을 사용하여 Exchange 사서함 서버에서 지원할 수 있는 사서함 사용자 수를 결정하는 것은 정확하지 않습니다. 여러 가지 요인에 의해 테스트 및 프로덕션 환경에 예기치 않은 메가사이클 결과가 나타날 수 있습니다. 메가사이클은 Exchange 사서함 서버가 지원할 수 있는 사서함 사용자 수를 근사치로 계산할 때만 사용해야 합니다. 디자인 프로세스의 용량을 계획할 때는 적극적인 것보다 보수적인 것이 항상 더 낫습니다.
다음 계산은 아래 표에 요약된 대로 게시된 예상 메가사이클 수를 기준으로 합니다.
예상 메가사이클 수
| 하루에 사서함당 주고받는 메시지 수 | 활성 사서함 데이터베이스에 대한 사서함당 메가사이클 수 | 원격 수동 사서함 데이터베이스에 대한 사서함당 메가사이클 수 | 로컬 수동 사서함에 대한 사서함당 메가사이클 수 |
|---|---|---|---|
50 |
1 |
0.1 |
0.15 |
100 |
2 |
0.2 |
0.3 |
150 |
3 |
0.3 |
0.45 |
200 |
4 |
0.4 |
0.6 |
1단계: 활성 사서함 CPU 요구 사항 계산
이 단계에서는 다음을 사용하여 활성 데이터베이스 복사본을 지원하는 데 필요한 메가사이클 수를 계산합니다.
필요한 활성 사서함 메가사이클 수 = 프로필 특정 메가사이클 수 × 사서함 사용자 수
= 2 × 32400
= 64800
2단계: 활성 사서함 원격 데이터베이스 복사본 CPU 요구 사항 계산
각 데이터베이스 복사본이 세 개 있는 디자인에서, 원격 서버에서 데이터베이스 복사본을 유지 관리하는 데 필요한 로그 전달과 관련된 프로세서 오버헤드가 있습니다. 이 오버헤드는 일반적으로 처리 중인 각 원격 복사본에 대한 활성 사서함 메가사이클 수의 10%입니다. 다음을 사용하여 요구 사항을 계산합니다.
필요한 원격 복사본 메가사이클 수 = 프로필 특정 메가사이클 수 × 사서함 사용자 수 × 원격 복사본 수
= 0.1 × 32400 × 2
= 6480
3단계: 로컬 수동 사서함 CPU 요구 사항 계산
각 데이터베이스의 복사본이 세 개 있는 디자인에서 각 데이터베이스의 로컬 수동 복사본 유지 관리와 관련된 프로세서 오버헤드가 있습니다. 이 단계에서는 로컬 수동 데이터베이스 복사본을 지원하는 데 필요한 높은 수준의 메가사이클 수를 계산합니다. 이러한 수는 서버 복구 전략 및 데이터베이스 복사본 레이아웃과 일치하도록 이후 단계에서 구체화됩니다. 다음을 사용하여 요구 사항을 계산합니다.
필요한 로컬 수동 사서함 메가사이클 수 = 프로필 특정 메가사이클 수 × 사서함 사용자 수 × 수동 복사본 수
= 0.3 × 32400 × 2
= 19440
4단계: 총 CPU 요구 사항 계산
다음을 사용하여 총 요구 사항을 계산합니다.
필요한 총 메가사이클 수 = 활성 사서함 + 원격 수동 + 로컬 수동
= 64800 + 6480 + 19440
= 90720
사서함당 평균 메가사이클 수 = 90720 ÷ 32400 = 2.8
Exchange 2010 테스트 솔루션
사서함 요구 사항 요약
다음 표에는 이 환경에 필요한 대략적인 메가사이클 수와 데이터베이스 캐시가 요약되어 있습니다. 이 정보는 이후 단계에서 솔루션에서 배포할 서버를 결정하는 데 사용됩니다.
사서함 요구 사항 요약
| 사서함 CPU 요구 사항 | 값 |
|---|---|
전체 환경에 필요한 총 메가사이클 수 |
97200 |
전체 환경에 필요한 총 데이터베이스 캐시 |
190 GB |
Exchange 2010 테스트 솔루션
서버 모델 결정
다음 단계를 사용하여 서버 모델을 결정할 수 있습니다.
1단계: 기본 설정된 서버 공급업체 식별
이 솔루션의 기본 설정 서버 플랫폼은 TCO를 줄이고 유연성을 높이도록 디자인된 시스템에 컴퓨팅, 네트워킹, 저장소 액세스 및 가상화를 통합하는 데이터 센터 플랫폼인 Cisco 통합 컴퓨팅 시스템입니다. 이 시스템은 대기 시간이 짧은 10GB 이더넷 네트워크 패브릭을 엔터프라이즈급의 x86 아키텍처 서버에 통합합니다. 아키텍처, 기술, 파트너 관계 및 서비스에 대한 시스템 접근 방법을 사용하는 Cisco 통합 컴퓨팅 시스템은 데이터 센터 리소스를 간소화하고, 서비스 배달을 확장하고, 설정, 관리, 전원, 냉각 및 케이블을 필요로 하는 장치 수를 줄여줍니다.
2단계: 기본 공급업체에서 사용 가능한 옵션 검토
Cisco 통합 컴퓨팅 시스템은 네 개의 기본 시스템 구성 요소로 구성된 블레이드 서버 시스템입니다. 이러한 시스템 구성 요소는 패브릭 상호 연결, 섀시, 패브릭 Extender(I/O 모듈) 및 블레이드 서버입니다.
다음 블레이드 서버 모델은 이 솔루션에 대한 잠재적인 옵션입니다.
옵션 1: B200 블레이드 서버
Cisco 통합 컴퓨팅 시스템 B200 블레이드 서버는 절반 너비의 두 개 소켓으로 구성된 블레이드 서버입니다. 이 시스템은 두 개의 Intel Xeon 5500 또는 5600 시리즈 프로세서, 최대 96GB의 DDR3 메모리, 두 개의 선택적인 핫 스왑 가능한 작은 폼 요소 SAS 디스크 드라이브, I/O 처리량의 최대 20Gbps용 단일 메자닌 커넥터를 사용합니다. 이 서버는 프로덕션 수준의 가상화 및 기타 일반 데이터 센터 작업을 위해 간소화, 성능 및 밀도의 균형을 유지합니다.
옵션 2: B250 Blade Server
Cisco 통합 컴퓨팅 시스템 B250 확장 메모리 블레이드 서버는 Cisco 확장 메모리 기술을 갖춘, 전체 너비의 두 개 소켓으로 구성된 블레이드 서버입니다. 이 시스템은 두 개의 Intel Xeon 5500 또는 5600 시리즈 프로세서, 최대 384GB의 DDR3 메모리, 두 개의 선택적인 작은 폼 요소 SAS 디스크 드라이브, I/O 처리량의 최대 40Gbps용 단일 메자닌 커넥터를 사용합니다. 이 서버는 가상화와 대형 데이터 집합 작업에 맞게 성능과 용량을 높입니다.
옵션 3: B440 Blade Server
Cisco 통합 컴퓨팅 시스템 B440 블레이드 서버는 큰 데이터 집합 및 트랜잭션 집약적인 데이터베이스 등의 엔터프라이즈 응용 프로그램, ERP(전사적 자원 관리) 프로그램 및 DSS(Decision-Support System)를 작동하도록 디자인되었습니다. Intel Xeon 7500 시리즈 프로세서의 확장 가능한 성능 및 안정성 기능으로 구동되는 Cisco 통합 컴퓨팅 시스템 B440을 사용하면 작업 가상화 범위를 넓히고, 간소화된 통합 인프라 내에서 성능 집약적인 독립 실행형 응용 프로그램을 통합할 수 있습니다. Cisco 통합 컴퓨팅 시스템 B440은 총 I/O 처리량이 최대 40Gbps인 256GB의 주 메모리와 최대 32개 처리 코어를 지원합니다.
3단계: 서버 모델 선택
Intel Xeon X5570 프로세서가 장착된 Cisco 통합 컴퓨팅 시스템 B200을 선택했는데, 그 이유는 이 블레이드 서버가 이 배포를 위한 처리 능력, 메모리 용량 및 폼 요소 간의 최적화된 균형을 제공하기 때문입니다. 확장성과 비용을 포함하여 모든 관련 요소를 기반으로, Exchange 2010 배포에 2-소켓 서버 플랫폼이 자주 선택됩니다. Cisco 통합 컴퓨팅 시스템 B250은 더 높은 메모리 구성과 I/O 처리량을 지원하지만 이 솔루션에는 이러한 기능이 필요하지 않습니다.
참고
테스트를 수행한 이후 600GB 10,000rpm 디스크의 가격이 하락했으므로 이 배포에 적합합니다.
Exchange 2010 테스트 솔루션
서버 모델의 CPU 용량 계산
이전 단계에서는 활성 사서함 사용자 수를 지원하는 데 필요한 메가사이클을 계산했습니다. 다음 단계에서는 서버 모델과 프로세서가 지원할 수 있는 메가사이클 수를 결정하여 각 서버에서 지원할 수 있는 활성 사서함 수를 결정합니다.
1단계: 서버 및 프로세서에 대한 벤치마크 값 결정
메가사이클 요구 사항은 기본 서버와 프로세서 모델을 기준으로 하기 때문에 기본 서버에 대해 서버에 사용할 수 있는 메가사이클 수를 조정해야 합니다. 이를 위해 SPEC(표준 성능 평가 기관)에서 유지 관리하는 독립적인 성능 벤치마크가 사용됩니다. SPEC는 최신 고성능 컴퓨터에 적용할 수 있는 표준화된 관련 벤치마크 세트를 설정, 유지 관리 및 인증하기 위해 구성된 비영리 기업입니다.
서버 및 프로세서에 대한 벤치마크 값을 얻는 과정을 단순화하려면 Exchange 프로세서 쿼리 도구를 사용하는 것이 좋습니다. 이 도구는 계획한 프로세서의 SPECint 2006 속도 값을 확인하는 수동 단계를 자동화합니다. 이 도구를 실행하려면 컴퓨터가 인터넷에 연결되어 있어야 합니다. 이 도구는 계획한 프로세서 모델을 입력으로 사용한 다음 표준 성능 평가 기관(Standard Performance Evaluation Corporation) 웹 사이트에 쿼리를 실행하여 해당 특정 프로세서 모델에 대한 모든 테스트 결과 데이터를 반환합니다. 또한 각 사서함 서버에서 사용할 프로세서 수를 기반으로 평균 SPECint 2006 속도 값을 계산합니다. 다음 계산을 사용합니다.
프로세서 = 인텔 X X5570 2.93GHz
SPECint_rate2006 값 = 256
프로세서 코어 당 SPECint_rate2006 값 = 256 ÷ 8
= 32
2단계: 조정된 메가사이클 수 계산
이전 단계에서는 사서함당 메가사이클 예상치를 기반으로 전체 환경에 필요한 메가사이클 수를 계산했습니다. 이러한 예상치는 SPECint_rate2006 값이 150(8코어 서버), 즉 코어당 18.75인 기준 시스템(HP DL380 G5 x5470 3.33GHz, 8개 코어)에서 측정한 것입니다.
이 단계에서는 필요한 메가사이클을 용량 계획에 사용할 수 있도록, 선택한 서버와 프로세서에 사용할 수 있는 메가사이클 수를 기준 프로세서와 비교하여 조정해야 합니다.
Cisco B200-M1 Intel X5570 2.93GHz 플랫폼의 메가사이클 수를 결정하려면 다음 수식을 사용합니다.
조정된 코어별 메가사이클 수 = (새 플랫폼 코어당 값) × (기준 플랫폼의 코어당 Hz) ÷ (기준 코어당 값)
= (32 × 3330) ÷ 18.75
= 5683
조정된 서버별 메가사이클 수 = 조정된 코어별 메가사이클 수 × 코어 수
= 5683 × 8
= 45466
3단계: 사서함 서버별로 사용할 수 있는 메가사이클 수 계산
조정된 서버별 메가사이클 수를 알고 있으므로 대상 최대 프로세서 사용률을 조정해야 합니다. 이전 단계에서 최고 작업 시간 중에 또는 오류 시나리오에서 프로세서 사용률이 80%를 초과하지 않도록 했습니다. 다음 계산을 사용합니다.
조정된 사용 가능한 메가사이클 수 = 서버별 사용 가능한 메가사이클 수 × 대상의 최대 프로세서 사용률
= 45466 × 0.80
= 36372
각 서버의 사용 가능한 용량은 36,372메가사이클입니다.
Exchange 2010 테스트 솔루션
필요한 실제 사서함 서버 수 결정
다음 단계를 사용하여 필요한 실제 사서함 서버 수를 결정할 수 있습니다.
1단계: 단일 사서함 서버에서 지원하는 최대 활성 사서함 수 결정
단일 사서함 서버에서 지원하는 활성 사서함 수를 결정하려면 다음 계산을 사용합니다.
활성 사서함 수 = 서버별로 사용 가능한 메가사이클 수 + 사서함당 메가사이클 수
= 36372 ÷ 2.8
= 12990
2단계: 각 DAG에 필요한 작업을 지원하기 위해 사이트별로 필요한 최소 사서함 서버 수 결정
각 DAG에는 10,800개의 활성 사서함이 있습니다. DAG에 있는 모든 사서함을 지원하는 데 필요한 최소 사서함 수를 결정하려면 다음 계산을 사용합니다.
필요한 서버 수 = DAG별 총 사서함 수 ÷ 서버별 활성 사서함 수
= 10800 ÷ 12990
= 0.83
각 DAG에서 10,800개 사서함의 작업을 지원하는 데 최소 한 개의 사서함 서버가 필요합니다.
3단계: 각 DAG의 사서함 복구 전략을 지원하는 데 필요한 서버 수 결정
이전 단계에서, 활성/수동 DAG에서 활성 상태인 모든 복사본에 대해 디자인하기로 결정했습니다. 이 모델에서는 사서함 서버 역할을 각 DAG의 세 그룹에 배포합니다.
사서함 서버 및 DAG 수
| DAG1 기본 데이터 센터 | DAG1 보조 데이터 센터 | DAG2 기본 데이터 센터 | DAG2 보조 데이터 센터 | DAG3 기본 데이터 센터 | DAG3 보조 데이터 센터 | 총 사서함 서버 개수 |
|---|---|---|---|---|---|---|
2 |
1 |
2 |
1 |
2 |
1 |
9 |
4 |
2 |
4 |
2 |
4 |
2 |
18 |
6 |
3 |
6 |
3 |
6 |
3 |
27 |
DAG 디자인을 기준으로 할 때 각 DAG에 최소 세 개의 물리적 사서함 서버 또는 세 DAG 모두에 대해 총 9개의 물리적 사서함 서버가 필요합니다.
Exchange 2010 테스트 솔루션
일반적인 작동 조건 및 오류 시나리오에서 사서함 서버별 활성 사서함 수 결정
다음 단계를 사용하여 일반적인 작동 조건 및 오류 시나리오에서 사서함 서버별 활성 사서함 수를 결정할 수 있습니다.
1단계: 정상적인 작동 조건에서 사서함 서버별 활성 사서함 수 결정
정상적인 작동 조건에서 각 사서함 서버가 호스트하는 활성 사서함 수를 결정하려면 다음 계산을 사용합니다.
서버별 사서함 수 = DAG의 총 사서함 수 ÷ 기본 데이터 센터의 사서함 서버 수
= 10800 ÷ 2
= 5400
2단계: 기본 데이터 센터에서 사서함 서버 오류 발생 시 사서함 서버별 활성 사서함 수 결정
기본 데이터 센터에서 한 사서함 서버에 오류가 발생하는 경우 오류가 발생한 서버의 5,400개 활성 사서함은 나머지 서버에서 활성화됩니다. 이 시나리오에서 나머지 사서함 서버는 10,800개의 활성 사서함을 갖게 됩니다.
3단계: 기본 데이터 센터에서 두 사서함 서버에 오류 발생 시 사서함 서버별 활성 사서함 수 결정
기본 데이터 센터가 오프라인 상태가 되면 기본 데이터 센터에 있는 10,800개의 활성 사서함은 보조 데이터 센터에서 활성화됩니다. 이 시나리오에서 보조 데이터 센터의 단일 서버는 10,800개의 활성 사서함을 갖게 됩니다.
Exchange 2010 테스트 솔루션
별도의 물리적 서버에 클라이언트 액세스 및 허브 전송 서버 역할 배포 여부 결정
서버 수가 더 적은 환경에 배포할 클라이언트 액세스 서버 역할 및 허브 전송 서버 역할 수를 결정할 때, 두 역할을 동일한 물리적 컴퓨터에 배포하도록 고려할 수 있습니다. 이렇게 하면 관리할 실제 컴퓨터 수, 업데이트 및 유지 관리할 서버 운영 체제 수, 구입해야 할 Windows 및 Exchange 라이선스 수 등을 줄일 수 있습니다. 클라이언트 액세스 및 허브 전송 서버 역할을 결합하면 디자인 프로세스를 간단하게 할 수 있습니다. 역할을 격리하여 배포할 때 네 개의 사서함 서버 논리 프로세서마다 한 개의 허브 전송 서버 논리 프로세서를 배포하고 네 개의 사서함 논리 프로세서마다 세 개의 클라이언트 액세스 서버 논리 프로세서를 배포하는 것이 좋습니다. 이렇게 하면 여러 실제 서버에 오류 또는 유지 관리 시나리오에서 충분한 클라이언트 액세스 및 허브 전송 서버를 제공해야 할 때 특히 혼란을 줄 수 있습니다. 클라이언트 액세스 및 허브 전송 서버와 사서함 서버를 같은 실제 서버나 같은 VM에 배포할 경우, 사이트의 사서함 서버마다 클라이언트 액세스와 허브 전송 서버 조합 하나를 배포할 수 있습니다.
*디자인 결정 요소*
이 솔루션에서는 같은 물리적 컴퓨터에 허브 전송 및 클라이언트 액세스 서버 역할을 함께 배치하기로 했습니다. 이렇게 하면 관리할 운영 체제 수를 줄일 수 있을 뿐만 아니라 서버 복구 계획도 쉬워집니다.
Exchange 2010 테스트 솔루션
필요한 실제 클라이언트 액세스 및 허브 전송 조합 서버 수 결정
이전 단계에서 사이트마다 세 개의 사서함 서버가 필요하다는 것을 확인했습니다(해당 사이트의 활성 사서함을 호스트하는 DAG에 두 개의 사서함 서버와, 해당 DAG의 기본 데이터 센터에 오류가 발생하는 경우 사이트 복구를 지원하는 대체 DAG에 한 개의 사서함 서버).
다음 표와 같이, 사서함 서버마다 클라이언트 액세스와 허브 전송 서버 조합 하나를 배포하는 것이 좋습니다.
필요한 실제 클라이언트 액세스 및 허브 전송 조합 서버 수
| 서버 역할 구성 | 권장되는 프로세서 코어 비율 |
|---|---|
사서함: 클라이언트 액세스 및 허브 전송 조합 서버 역할 |
1:1 |
같은 사이트에 DAG를 둘 이상 두기로 한 경우 필요한 클라이언트 액세스 및 허브 전송 조합 서버 수를 결정하려면 최악의 오류 시나리오를 검토해야 합니다. 이 솔루션에서 최악의 오류 시나리오는 기본 DAG에서 두 개 사서함 서버 중 하나가 손실되고, 다른 사이트의 활성 사서함이 현재 같은 사이트에서 호스트되는 동시 사이트 오류가 발생하는 경우입니다. 이 경우 두 사서함 서버에서 실행 중인 사이트에 21,600개의 활성 사서함이 있으므로 아래 그림처럼 각 사이트에 최소 두 개의 클라이언트 액세스 및 허브 전송 조합 서버가 필요합니다.
클라이언트 액세스 및 허브 전송 서버
Exchange 2010 테스트 솔루션
필요한 총 실제 서버 수 결정
지금까지 세 개의 데이터 센터에 있는 32,400개 활성 사서함에 대해 클라이언트 액세스, 허브 전송 및 사서함 서버 역할을 지원하는 데 아래 그림과 같이 15개의 실제 서버가 필요하다는 것을 확인했습니다.
필요한 실제 서버 수
Exchange 2010 테스트 솔루션
서버 가상화 사용 여부 결정
Exchange 서버 가상화를 고려할 때 중요한 여러 가지 요소가 있습니다. 가상화에 대해 지원되는 구성에 대해서는 Exchange 2010 시스템 요구 사항을 참조하십시오.
다음과 같은 이유로 Exchange에 가상화를 사용하는 것을 고려해 보십시오.
서버의 사용률이 낮아서 사용률을 높이려는 경우 가상화를 사용하면 더 적은 수의 서버를 구입할 수 있습니다.
클라이언트 액세스, 허브 전송 및 사서함 서버 역할을 같은 실제 서버에 배포할 때 NLB(네트워크 부하 분산)를 사용할 수 있습니다.
조직에서 모든 서버 인프라에 가상화를 사용 중인 경우 회사 표준 정책에 맞추기 위해 Exchange에 가상화를 사용할 수 있습니다.
이 환경에서 가상화 사용 여부를 결정하려면 예상 프로세서 사용률을 고려하고 서버의 사용률이 낮을 가능성이 있는지 확인합니다.
1단계: 일반적인 작동 조건에서 사서함 서버의 예상 CPU 사용률 확인
단일 사서함 서버에 있는 5,400개 활성 사서함의 CPU 사용률을 확인하려면 다음 계산을 사용합니다.
% 프로세서(일반적인 작동에서 최대 사용) = 필요한 메가사이클 수 ÷ 사용할 수 있는 메가사이클 수
= (5400 × 2.8) ÷ 45466
= 33.2%
2단계: 최악의 오류 조건에서 사서함 서버의 예상 CPU 사용률 계산
단일 사서함 서버에 있는 10,800개 활성 사서함의 CPU 사용률을 확인하려면 다음 계산을 사용합니다.
% 프로세서(오류 조건에서 최대 사용) = 필요한 메가사이클 수 ÷ 사용할 수 있는 메가사이클 수
= (10800 × 2.8) ÷ 45466
= 66.5%
*디자인 결정 요소*
최악의 오류 시나리오 대상에 대한 서버 사용률이 80% 미만으로 예상되므로 가상화를 사용하여 서버 수를 줄일 수 있습니다. 이 내용은 다음 단계에서 자세히 다룹니다.
Exchange 2010 테스트 솔루션
실제 서버 수를 줄이는 데 가상화 사용 가능 여부 결정
다음 단계에서는 이 솔루션에 필요한 실제 서버 수를 줄이는 데 가상화를 사용할 수 있는지 여부를 결정합니다. Microsoft Hyper-V가 가상화 플랫폼으로 사용됩니다.
1단계: 기존 실제 서버 카운트에 가상화 추가
테스트할 때 Microsoft Hyper-V는 VM당 최대 네 개의 가상 프로세서를 지원합니다. 실제 디자인에서 기본 DAG에 대한 사서함 서버 역할이 총 16개 논리 프로세서가 장착된 두 개의 실제 서버에 배포되었습니다. 가상화를 추가함에 따라 이제 기본 DAG에 대한 사서함 서버 역할이 네 개의 VM에 배포됩니다. 각 VM에는 네 개의 가상 프로세서가 있으므로 총 16개의 가상 프로세서가 있습니다.
실제 디자인에서는 대체 DAG에 대한 사서함 서버 역할이 8개의 논리 프로세서가 있는 단일 실제 서버에 배포되었습니다. 가상화를 추가함에 따라 이제 대체 DAG에 대한 사서함 서버 역할이 두 개의 VM에 배포됩니다. 각 VM에는 네 개의 가상 프로세서가 있으므로 총 8개의 가상 프로세서가 있습니다.
실제 디자인에서는 클라이언트 액세스 및 허브 전송 조합 서버가 총 16개 논리 프로세서가 장착된 두 개의 실제 서버에 배포되었습니다. 가상화를 추가함에 따라 이제 클라이언트 액세스 및 허브 전송 조합 서버가 네 개의 VM에 배포됩니다. 각 VM에는 네 개의 가상 프로세서가 있으므로 총 16개의 가상 프로세서가 있습니다.
8개의 논리 프로세서에 Hyper-V 루트 서버를 사용할 때 한 개의 사서함 서버 VM과 한 개의 클라이언트 액세스 및 허브 전송 조합 서버 VM을 각 Hyper-V 루트 서버에 배포하는 것이 좋습니다.
이제 이 솔루션에서는 아래 그림과 같이 각 사이트에 있는 5개의 실제 서버에서 10개의 VM이 실행되고 있습니다.
가상 컴퓨터
2단계: 실제 서버 수 줄이기
이전 단계의 계산을 기준으로 할 때 최악의 작업에 대한 메가사이클 요구 사항을 네 개의 실제 서버에서 처리할 수 있음을 예측할 수 있습니다. 이 단계에서는 실제 서버 수를 다섯 개에서 네 개로 줄이고 대체 DAG에 있는 사서함 서버를 나머지 네 개의 실제 서버에 재배포합니다. 실제 서버 네 개에서 균형을 유지하려면 두 개의 사서함 서버 VM(네 개의 가상 프로세서 포함)을 네 개의 사서함 서버 VM(두 개의 가상 프로세서 포함)으로 변경해야 합니다.
그 결과 아래 그림과 같이 각 사이트에 있는 네 개의 실제 서버에서 12개의 VM이 실행됩니다.
가상 컴퓨터
가상 컴퓨터
3단계: 각 VM에 할당되는 가상 프로세서의 수 결정
이 단계에서는 각 VM에 필요한 가상 프로세서 수를 예측합니다. 다음 단계에서는 계산을 수행하여 가정을 확인합니다.
기본 DAG의 네 개 사서함 서버 VM은 각각 일반적인 작동 조건에서 DAG에 있는 10,800개 활성 사서함의 25%, 즉 2,700개의 사서함을 지원합니다. 서버 오류가 발생하는 경우 남아 있는 사서함 서버 VM이 5,400개의 활성 사서함을 지원해야 합니다.
사이트 오류 발생 시 기본 DAG의 네 개 사서함 서버 VM은 각각 DAG에 있는 10,800개 활성 사서함의 25%, 즉 2,700개의 사서함을 지원합니다. 이 시나리오에서는 데이터베이스의 세 번째 및 최종 복사본에서 사서함이 실행됩니다. 서버 또는 VM 오류가 발생하는 경우 남아 있는 VM이 5,400개의 활성 사서함을 지원할 필요가 없습니다. 최대 사서함 수는 항상 2,700입니다.
대체 DAG에 있는 VM의 가상 프로세서 수는 기본 DAG에 있는 VM의 가상 프로세서 수의 절반이 됩니다. 이 솔루션에서는 네 개의 가상 프로세서를 기본 DAG에 있는 VM에 할당하고 두 개의 가상 프로세서를 대체 DAG에 있는 VM에 할당합니다.
논리 프로서세와 가상 프로세서 비율을 1:1로 유지하면 각 클라이언트 액세스 및 허브 전송 조합 서버에 대해 두 개의 가상 프로세서가 남습니다. 사서함 서버 코어와 클라이언트 액세스 및 허브 전송 조합 서버 코어의 비율을 1:1로 유지하고자 하므로 네 개의 가상 프로세서를 각 클라이언트 액세스 및 허브 전송 조합 서버에 할당합니다. 그 결과 가상 프로세서 수가 루트 서버의 실제 프로세서 수를 초과하는 시나리오가 됩니다. 이것을 초과 구독이라고 합니다. 대부분의 경우 초과 구독을 사용하지 않는 것이 좋습니다. 하지만 이 솔루션에서 대체 DAG의 사서함 서버 VM은 사이트 오류가 발생하는 경우에만 사용됩니다. 이런 경우는 발생 가능성이 낮으므로 약간의 초과 구독은 문제가 되지 않습니다.
다음 표에는 제안된 가상 프로세서 할당이 나와 있습니다.
가상 프로세서 할당
| 가상 컴퓨터 | 가상 프로세서 수 |
|---|---|
클라이언트 액세스 및 허브 전송 조합 |
3 |
사서함(기본 DAG) |
4 |
사서함(대체 DAG) |
2 |
전체 |
9 |
Exchange 2010 테스트 솔루션
Hyper-V 루트 서버의 CPU 용량 계산
이전 단계에서는 활성 사서함 사용자 수를 지원하는 데 필요한 메가사이클을 계산했습니다. 다음 단계에서는 서버 모델과 프로세서에서 지원할 수 있는 사용 가능한 메가사이클 수를 결정하므로 각 사서함 서버에서 지원할 수 있는 활성 사서함 수를 결정할 수 있습니다.
Exchange 2010 테스트 솔루션
가상화 오버헤드에 사용할 수 있는 메가사이클 수 조정
루트 서버에 VM을 배포할 때 하이퍼바이저 및 가상화 스택을 지원하는 데 필요한 메가사이클 수를 고려해야 합니다. 이 오버헤드는 서버 및 작업마다 다릅니다. 아래 계산처럼, 보수적으로 볼 때 사용 가능한 메가사이클의 약 10%가 사용됩니다.
조정된 사용 가능한 메가사이클 수 = 사용 가능한 메가사이클 수 × 0.90
= 45466 × 0.90
= 40919
각 서버의 사용 가능한 VM 용량은 40,919메가사이클입니다.
논리 프로세서당 사용 가능한 용량은 5,115메가사이클입니다.
Exchange 2010 테스트 솔루션
VM의 CPU 용량 확인
이전 단계에서, 다음 표와 같이 세 가지 VM 유형에 대해 가상 프로세서를 할당하기로 결정했습니다.
가상 프로세서 할당
| 가상 컴퓨터 | 가상 프로세서 수 |
|---|---|
클라이언트 액세스 및 허브 전송 조합 |
3 |
사서함(기본 DAG) |
4 |
사서함(대체 DAG) |
2 |
전체 |
9 |
1단계: 가상 프로세서별 사용 가능한 메가사이클 수 결정
8개의 논리 프로세서가 장착된 루트 서버에서 9개의 가상 프로세서를 실행 중이므로 가상 프로세서의 메가사이클 용량이 논리 프로세서의 메가사이클 용량과 다릅니다. 이 단계에서는 가상 프로세서별 사용 가능한 메가사이클 수를 계산합니다.
가상 프로세서별 메가사이클 수 = 논리 프로세서별 메가사이클 수 × (논리 프로세서 수 ÷ 가상 프로세서 수)
= 5115 × (8 ÷ 9)
= 4547
2단계: VM당 사용 가능한 메가사이클 수 결정
이 단계에서 VM당 사용 가능한 메가사이클 수를 결정할 때 다음 표를 참조하십시오.
VM당 사용 가능한 메가사이클 수
| 가상 컴퓨터 | 가상 프로세서 수 | 가상 프로세서당 메가사이클 수 | 사용 가능한 메가사이클 수 |
|---|---|---|---|
클라이언트 액세스 및 허브 전송 조합 |
3 |
4547 |
13641 |
사서함(기본 DAG) |
4 |
4547 |
18188 |
사서함(대체 DAG) |
2 |
4547 |
9094 |
3단계: VM당 대상의 사용 가능한 메가사이클 수 결정
디자인 가정에서 프로세서 사용률이 80%를 초과하지 않는다고 했으므로 다음 표와 같이 80%의 대상을 반영하도록 사용 가능한 메가사이클 수를 조정합니다.
VM당 대상의 사용 가능한 메가사이클 수
| 가상 컴퓨터 | 사용 가능한 메가사이클 수 | 최대 프로세서 사용률 | 대상의 사용 가능한 메가사이클 수 |
|---|---|---|---|
클라이언트 액세스 및 허브 전송 조합 |
13641 |
80% |
10913 |
사서함(기본 DAG) |
18188 |
80% |
14550 |
사서함(대체 DAG) |
9094 |
80% |
7275 |
Exchange 2010 테스트 솔루션
기본 사서함 서버 VM의 CPU 용량 확인
기본 사서함 서버 VM의 CPU 용량을 확인하려면 다음 단계를 사용합니다.
1단계: 최악의 작업 중에 메가사이클 요구 사항 결정
기본 사서함 서버의 최악의 작업은 5,400개의 사서함이 기본 사서함 서버에서 활성 상태이고 두 번째와 세 번째 원격 복사본이 유지 관리되고 있는 유지 관리 시나리오 또는 서버 오류가 발생했을 때입니다(예: 수동 복사본을 업데이트 중인 복구 이벤트를 따르지만 활성 사서함을 대상 서버로 다시 이동하지 않은 경우). 이 단계에서는 다음 계산을 사용하여 기본 사서함 서버 VM에 대한 메가사이클 요구 사항을 결정합니다.
필요한 사서함 메가사이클 수 = (사서함 사용자 수 × 프로필 특정 메가사이클 수) + 원격 데이터베이스 복사본 수 × (사서함 사용자 수 × 프로필 특정 메가사이클 수 × 10%)
= (5400 × 2) + 2 × (5400 × 2 × 0.1)
= 10800 + 2160
= 12960
2단계: 기본 사서함 서버 VM이 최악의 시나리오 작업을 지원할 수 있는지 확인
이 단계에서는 사용 가능한 메가사이클 수가 필요한 메가사이클 수보다 큰지 확인합니다. 12,960메가사이클이 필요하지만 14,550메가사이클이 있으므로 기본 사서함 서버 VM의 용량은 5,400개의 활성 사서함을 지원하기에 충분합니다.
Exchange 2010 테스트 솔루션
보조 사서함 서버 VM의 CPU 용량 확인
보조 사서함 서버 VM의 CPU 용량을 확인하려면 다음 단계를 사용합니다.
1단계: 최악의 작업 중에 메가사이클 요구 사항 결정
보조 사서함 서버의 최악의 작업은 2,700개의 사서함이 보조 사서함 서버에서 활성 상태이고 두 번째와 세 번째 원격 복사본이 유지 관리되고 있는 사이트 오류 시나리오가 발생했을 때입니다(예: 원래의 기본 및 보조 복사본을 업데이트 중인 원래의 사이트가 다시 온라인 상태가 되지만 활성 사서함을 대상 서버로 다시 이동하지 않은 경우). 이 단계에서는 다음 계산을 사용하여 보조 사서함 서버 VM에 대한 메가사이클 요구 사항을 결정합니다.
필요한 사서함 메가사이클 수 = (사서함 사용자 수 × 프로필 특정 메가사이클 수) + 원격 데이터베이스 복사본 수 × (사서함 사용자 수 × 프로필 특정 메가사이클 수 × 10%)
= (2700 × 2) + 2 × (2700 × 2 × 0.1)
= 5400 + 1080
= 6480
2단계: 기본 사서함 서버 VM이 최악의 시나리오 작업을 지원할 수 있는지 확인
이 단계에서는 사용 가능한 메가사이클 수가 필요한 메가사이클 수보다 큰지 확인합니다. 6,480메가사이클이 필요하지만 7,275메가사이클이 있으므로 보조 사서함 서버 VM의 용량은 2,700개의 활성 사서함을 지원하기에 충분합니다.
Exchange 2010 테스트 솔루션
기본 사서함 서버 VM당 필요한 메모리 결정
다음 단계를 사용하여 기본 사서함 서버 VM에 필요한 메모리를 결정할 수 있습니다.
1단계: 최악의 오류 시나리오에 대한 서버당 데이터베이스 캐시 요구 사항 결정
이전 단계에서, 모든 사서함에 대한 데이터베이스 캐시 요구 사항은 190GB이고 활성 사서함당 필요한 평균 캐시는 6MB라고 결정했습니다.
최악의 시나리오에 대해 디자인하려면 나머지 사서함 서버 VM에서 5,400개의 활성 사서함을 기반으로 필요한 데이터베이스 캐시를 계산합니다.
데이터베이스 캐시에 필요한 메모리 = 활성 사서함 수 × 사서함당 평균 캐시
= 5400 × 6MB
= 32,400 MB
= 31.6 GB
2단계: 최악의 오류 시나리오에 대해 사서함 서버 VM별 총 메모리 요구 사항 확인
이 단계에서는 다음 표를 참조하여 권장 메모리 구성을 확인합니다.
메모리 요구 사항
| 서버의 실제 메모리(RAM) | 데이터베이스 캐시 크기(사서함 서버 역할만 해당) |
|---|---|
24 GB |
17.6 GB |
32 GB |
24.4 GB |
48 GB |
39.2 GB |
사서함 서버 역할에 대해 31.6GB의 데이터베이스 캐시를 지원하는 데 필요한 권장 메모리 구성은 48GB입니다.
Exchange 2010 테스트 솔루션
보조 사서함 서버 VM당 필요한 메모리 확인
다음 단계를 사용하여 보조 사서함 서버 VM당 필요한 메모리를 확인할 수 있습니다.
1단계: 최악의 오류 시나리오에 대한 서버당 데이터베이스 캐시 요구 사항 결정
이전 단계에서 모든 사서함에 대한 데이터베이스 캐시 요구 사항이 190GB이고 활성 사서함당 필요한 평균 캐시는 6MB였음을 확인했습니다.
최악의 시나리오에 대해 디자인하려면 보조 사서함 서버 VM에 있는 2,700개의 활성 사서함을 기준으로 하여 필요한 데이터베이스 캐시를 계산합니다.
데이터베이스 캐시에 필요한 메모리 = 활성 사서함 수 × 사서함당 평균 캐시
= 2700 × 6MB
= 16,200 MB
= 15.8 GB
2단계: 최악의 오류 시나리오에 대해 사서함 서버 VM별 총 메모리 요구 사항 확인
이 단계에서는 다음 표를 참조하여 권장 메모리 구성을 확인합니다.
메모리 요구 사항
| 서버의 실제 메모리(RAM) | 데이터베이스 캐시 크기(사서함 서버 역할만 해당) | 데이터베이스 캐시 크기(사서함 및 허브 전송 서버 역할 등의 여러 서버 역할) |
|---|---|---|
24 GB |
17.6 GB |
14 GB |
32 GB |
24.4 GB |
20 GB |
48 GB |
39.2 GB |
32 GB |
사서함 서버 역할에 대해 15.8GB의 데이터베이스 캐시를 지원하기 위한 권장 메모리 구성은 24GB입니다.
Exchange 2010 테스트 솔루션
클라이언트 액세스 및 허브 전송 조합 서버당 필요한 메모리 결정
클라이언트 액세스 및 허브 전송 조합 서버 VM에 대한 메모리 구성을 결정하려면 다음 표를 참조하십시오.
설치된 서버 역할에 따른 Exchange 2010 서버의 메모리 구성
| Exchange 2010 서버 역할 | 최소 지원 | 권장되는 최대 구성 |
|---|---|---|
클라이언트 액세스 및 허브 전송 조합 서버 역할(클라이언트 액세스 및 허브 전송 서버 역할이 동일한 실제 서버에서 실행됨) |
4 GB |
코어당 2GB(최소 8GB) |
클라이언트 액세스 및 허브 전송 조합 서버 VM에 세 개의 가상 프로세서가 있으므로 각 클라이언트 액세스 및 허브 전송 조합 서버 VM에 6GB의 메모리가 할당됩니다.
Exchange 2010 테스트 솔루션
Hyper-V 루트 서버당 필요한 메모리 확인
Hyper-V 루트 서버당 필요한 메모리를 확인하려면 다음 계산을 사용합니다.
루트 서버 메모리 = 루트 운영 체제 메모리 + 클라이언트 액세스 및 허브 전송 조합 서버 VM 메모리 + 기본 사서함 서버 VM 메모리 + 보조 사서함 서버 VM 메모리
= 4GB + 6GB + 48GB + 24GB
= 82 GB
루트 서버에 대한 실제 메모리 요구 사항은 82GB입니다. 권장 메모리 구성에 맞추기 위해 서버가 96GB로 채워집니다.
Exchange 2010 테스트 솔루션
데이터베이스 가용성 그룹 디자인
이전 단계에서 솔루션에 세 개의 DAG를 포함하고 각 DAG가 세 개의 실제 위치 중 두 개에 걸쳐 있도록 결정했습니다. 작업 및 DAG 요구 사항을 지원하는 데 필요한 사서함 서버 수를 결정했으므로 DAG 디자인을 계속 진행할 수 있습니다.
DAG 디자인
Exchange 2010 테스트 솔루션
데이터베이스 복사본 레이아웃 디자인
다음 단계를 사용하여 데이터베이스 복사본 레이아웃을 디자인합니다.
1단계: DAG에서 고유한 Exchange 데이터베이스 수 결정
배포할 최적의 Exchange 데이터베이스 수를 결정하려면 Exchange 2010 사서함 서버 역할 요구 사항 계산기를 사용합니다. 입력 탭에 해당 정보를 입력하고 데이터베이스/DAG 수 자동 계산에 대해 예를 선택합니다. 사서함 크기 제한 필드에 완전히 프로비저닝된 사서함 할당량 2,048MB를 사용합니다.
DAG의 Exchange 데이터베이스
역할 요구 사항 탭에 권장 데이터베이스 수가 나타납니다. 이 솔루션의 경우 계산기에서는 각 DAG에 최소 24개의 고유한 데이터베이스를 두도록 권장합니다.
*디자인 결정 요소*
계산기의 권장 사항에 따라 DAG당 24개의 데이터베이스가 표시됩니다.
2단계: 일반적인 작동 조건에서 데이터베이스 레이아웃 결정
DAG마다 24개의 고유한 데이터베이스가 있고 DAG에 8개의 서버가 있으므로 주 사이트에서 네 개의 각 서버는 일반적인 작동 조건에서 6개의 활성 데이터베이스 복사본을 호스트합니다.
다음 표와 같이, 활성 데이터베이스 복사본을 네 개의 서버에 추가하여 시작합니다.
일반적인 작동 조건에서 데이터베이스 레이아웃
| 데이터베이스 | MBX1 | MBX2 | MBX3 | MBX4 |
|---|---|---|---|---|
DB1-6 |
A1 |
|||
DB7-12 |
A1 |
|||
DB13-18 |
A1 |
|||
DB19-24 |
A1 |
앞의 표에서 다음이 적용됩니다.
- A1 = 활성 데이터베이스 복사본
이전 단계에서 사서함 서버 복구 전략은 운영 효율성을 위해 디자인되었습니다. 사서함 서버가 쌍으로 배포됩니다.
DAG에 네 개의 사서함 서버가 있으므로 서버 1과 2가 한 쌍이 되고 서버 3과 4가 한 쌍이 됩니다. 이 단계에서는 다음 표와 같이 수동 데이터베이스 복사본(P1)을 대체 서버에 쌍으로 추가합니다.
수동 복사본을 사용하는 일반적인 작동 조건에서 데이터베이스 레이아웃
| 데이터베이스 | MBX1 | MBX2 | MBX3 | MBX4 |
|---|---|---|---|---|
DB1-6 |
A1 |
P1 |
||
DB7-12 |
P1 |
A1 |
||
DB13-18 |
A1 |
P1 |
||
DB19-24 |
P1 |
A1 |
앞의 표에서 다음이 적용됩니다.
A1 = 활성 데이터베이스 복사본
P1 = 수동 데이터베이스 복사본
3단계: 사이트 내 서버 오류 발생 시 또는 유지 관리 조건에서 데이터베이스 레이아웃 결정
서버 오류 발생 시 또는 유지 관리 이벤트 중에는 P1 복사본이 대체 서버에서 활성화됩니다. 다음 표는 유지 관리를 위해 MBX2 및 MBX4를 끈 경우 이를 보여줍니다.
사이트 내 서버 오류 발생 시 또는 유지 관리 조건에서 데이터베이스 복사본 레이아웃
앞의 표에서 다음이 적용됩니다.
A1 = 활성 데이터베이스 복사본
P1 = 수동 데이터베이스 복사본
4단계: 사이트 복구를 지원하기 위해 보조 데이터 센터에 데이터베이스 복사본 추가
이 단계에서는 다음 표와 같이 세 번째 데이터베이스 복사본을 보조 데이터 센터의 DAG 구성원에 추가하여 사이트 복구를 제공합니다.
사이트 복구를 지원하기 위해 보조 데이터 센터에 추가된 데이터베이스 복사본
| 데이터베이스 | SiteA MBX1 | SiteA MBX2 | SiteA MBX3 | SiteA MBX4 | SiteB MBX5 | SiteB MBX6 | SiteB MBX7 | SiteB MBX8 |
|---|---|---|---|---|---|---|---|---|
DB1-6 |
A1 |
P1 |
P2 |
|||||
DB7-12 |
P1 |
A1 |
P2 |
|||||
DB13-18 |
A1 |
P1 |
P2 |
|||||
DB19-24 |
P1 |
A1 |
P2 |
앞의 표에서 다음이 적용됩니다.
A1 = 활성 데이터베이스 복사본
P1 = 로컬 수동 데이터베이스 복사본
P2 = 원격 수동 데이터베이스 복사본
5단계: 사이트 오류 조건에서 데이터베이스 레이아웃 결정
기본 데이터 센터에 오류 발생 시 다음 표와 같이 P2 복사본이 보조 사이트에서 활성화됩니다. 기본 사이트가 온라인 상태로 돌아올 때까지 단일 데이터베이스 복사본만 있게 됩니다.
사이트 오류 조건에서 데이터베이스 레이아웃
앞의 표에서 다음이 적용됩니다.
A1 = 활성 데이터베이스 복사본
P1 = 수동 데이터베이스 복사본
P2 = 수동 데이터베이스 복사본
Exchange 2010 테스트 솔루션
데이터 센터 활성화 조정 모드
DAC(데이터 센터 활성화 조정) 모드는 DAG에 영향을 주는 심각한 오류(예: 데이터 센터 중 하나의 완전 실패)가 발생하는 경우 DAG의 활성화 동작을 제어하는 데 사용됩니다. DAC 모드가 사용하도록 설정되지 않고 DAG의 여러 서버에 영향을 주는 오류가 발생하는 경우, 오류가 발생된 후 대부분의 DAG 구성원이 복원되면 DAG가 다시 시작되고 데이터베이스를 탑재하려고 시도합니다. 다중 데이터 센터 구성에서 이 동작은 스플릿 브레인(split-brain) 현상(모든 네트워크가 실패하는 경우 발생하는 상태)을 일으킬 수 있고 DAG 구성원은 서로 하트비트 신호를 받을 수 없습니다. 데이터 센터 간에 네트워크 연결 문제가 생겨도 스플릿 브레인 현상이 발생할 수 있습니다. 스플릿 브레인 현상은 항상 DAG 구성원의 과반수(DAG 구성원 수가 짝수인 경우 DAG 미러링 모니터 서버)를 사용 가능한 상태로 유지하고, DAG가 작동하도록 상호 작용하게 함으로써 방지할 수 있습니다. 자세한 내용은 데이터 센터 활성화 조정 모드 이해를 참조하십시오.
*디자인 결정 요소*
DAC 모드가 환경의 세 DAG에 대해 모두 활성화되어 스플릿 브레인 현상이 발생하지 않습니다.
Exchange 2010 테스트 솔루션
파일 공유 감시 배치 확인
Exchange 2010에서 DAG는 Windows 장애 조치(failover) 클러스터링의 최소 구성 요소 집합을 사용합니다. 그러한 구성 요소 중 하나가 클러스터 상태를 결정하고 구성원을 결정할 때 중재 수단을 제공하는 쿼럼 리소스입니다. 각 DAG 구성원이 DAG의 기본 클러스터 구성 방식에 대해 일관된 관점을 갖는 것이 중요합니다. 쿼럼은 클러스터와 관련 있는 모든 구성 정보를 위한 가장 확실한 리포지토리 역할을 합니다. 또한 쿼럼은 스플릿 브레인 현상을 피하기 위한 타이브레이크로도 사용됩니다. 스플릿 브레인 현상은 DAG 구성원이 서로 통신할 수는 없지만 사용 가능하고 실행되고 있는 경우에 발생하는 상황입니다. 스플릿 브레인 현상은 항상 DAG 구성원의 과반수(DAG 구성원 수가 짝수인 경우 DAG 미러링 모니터 서버)를 사용 가능한 상태로 유지하고, DAG가 작동하도록 상호 작용하게 함으로써 방지할 수 있습니다.
미러링 모니터 서버는 DAG 구성원이 짝수인 경우 쿼럼을 구성하고 유지하는 데 사용되는 DAG 외부의 서버로, 파일 공유 감시를 호스트합니다. 구성원이 홀수인 DAG는 미러링 모니터 서버를 사용하지 않습니다. DAG 작성 시 파일 공유 감시는 DAG의 첫 번째 구성원과 같은 사이트에 있는 허브 전송 서버(사서함 서버 역할이 설치되지 않음)에 기본적으로 추가됩니다. 허브 전송 서버가 사서함 서버 역할을 실행 중인 VM과 같은 루트 서버에 있는 VM에서 실행 중이면 파일 공유 감시 위치를 가용성이 높은 다른 서버로 이동하는 것이 좋습니다. 파일 공유 감시를 도메인 컨트롤러로 이동할 수 있지만 보안에 영향을 줄 수 있으므로 이 작업을 마지막 수단으로만 사용합니다.
DAG가 여러 사이트로 확장되는 솔루션에서 보조 사이트에 대해 대체 파일 공유 감시를 정의하는 것이 좋습니다. 이렇게 하면 클러스터가 DAC 모드가 활성화된 사이트 오류 이벤트 중에 쿼럼을 유지 관리할 수 있습니다.
*디자인 결정 요소*
DAG를 세 개 배포하고 모든 DAG에 여러 사이트의 구성원을 포함하도록 했으므로 세 개의 기본 감시 디렉터리와 세 개의 대체 감시 디렉터리를 정의해야 합니다. 이러한 디렉터리는 각 사이트 내의 파일 서버에 위치합니다.
Exchange 2010 테스트 솔루션
네임스페이스 계획
Exchange 2010 조직을 계획할 때 가장 중요한 결정 사항 중 하나는 조직의 외부 네임스페이스 정렬 방법을 결정하는 것입니다. 네임스페이스는 DNS(Domain Name System)에 일반적으로 도메인 이름으로 표시되는 논리 구조입니다. 네임스페이스를 정의할 때는 사서함이 들어 있는 클라이언트와 서버의 여러 위치를 고려해야 합니다. 클라이언트의 실제 위치 외에도 Exchange 2010에 연결하는 방식을 평가해야 합니다. 이러한 질문에 대답함으로써 필요한 네임스페이스 수가 결정됩니다. 네임스페이스는 일반적으로 DNS 구성에 맞추어집니다. 인터넷 연결 클라이언트 액세스 서버가 하나 이상 있는 지역의 Active Directory 사이트마다 하나의 고유한 네임스페이스가 있는 것이 좋습니다. 이러한 네임스페이스는 일반적으로 mail.contoso.com 또는 mail.europe.contoso.com과 같은 A 레코드로 DNS에 표시됩니다.
자세한 내용은 클라이언트 액세스 서버 네임스페이스 이해를 참조하십시오.
외부 네임스페이스를 정렬하는 여러 가지 방법이 있지만 일반적으로 다음 네임스페이스 모델 중 하나를 요구 사항에 맞출 수 있습니다.
통합된 데이터 센터 모델 이 모델은 단일 실제 사이트로 구성됩니다. 모든 서버가 사이트 내에 있으며 mail.contoso.com과 같은 단일 네임스페이스가 있습니다.
단일 네임스페이스와 프록시 사이트 이 모델은 여러 개의 실제 사이트로 구성됩니다. 하나의 사이트에만 인터넷 연결 클라이언트 액세스 서버가 포함되어 있습니다. 다른 사이트는 인터넷에 노출되지 않습니다. 이 모델에서는 사이트에 대해 하나의 네임스페이스(예: mail.contoso.com)만 있습니다.
단일 네임스페이스와 여러 사이트 이 모델은 여러 개의 실제 사이트로 구성됩니다. 각 사이트에는 하나의 인터넷 연결 클라이언트 액세스 서버가 있을 수 있습니다. 또는, 여러 인터넷 연결 클라이언트 액세스 서버를 포함하는 단일 사이트만 있을 수 있습니다. 이 모델에서는 사이트에 대해 하나의 네임스페이스(예: mail.contoso.com)만 있습니다.
국가별 네임스페이스 이 모델은 여러 개의 실제 사이트와 여러 개의 네임스페이스로 구성됩니다. 예를 들면, 뉴욕에 있는 사이트의 네임스페이스는 mail.usa.contoso.com이 되고 토론토에 있는 사이트의 네임스페이스는 mail.canada.contoso.com이 되며 런던에 있는 사이트의 네임스페이스는 mail.europe.contoso.com이 됩니다.
다중 포리스트 이 모델은 여러 개의 네임스페이스가 있는 다중 포리스트로 구성됩니다. 이 모델을 사용하는 조직은 두 개의 파트너 회사로 구성될 수 있습니다(예: Contoso와 Fabrikam). 네임스페이스에는 mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.fabrikam.com 및 mail.europe.fabrikam.com이 포함될 수 있습니다.
*디자인 결정 요소*
이 시나리오에서는 여러 사이트에 활성 사서함이 있는 조직에 국가별 네임스페이스 모델이 가장 적합하므로 이 모델을 선택했습니다.
이 모델의 장점은 더 높은 비율의 사용자가 사서함 서버와 동일한 Active Directory 사이트에 있는 클라이언트 액세스 서버에 연결할 수 있으므로 프록싱이 감소한다는 것입니다. 이를 통해 최종 사용자 환경 및 성능이 향상됩니다. 인터넷 연결 클라이언트 액세스 서버가 없는 사이트에 사서함이 있는 사용자는 여전히 프록시 처리됩니다.
이 솔루션에는 또한 다음과 같은 구성 요구 사항이 있습니다.
여러 개의 DNS 레코드를 관리해야 합니다.
여러 개의 인증서를 가져오고, 구성하고, 관리해야 합니다.
인터넷 연결 사이트마다 Microsoft Forefront Threat Management Gateway 컴퓨터 또는 다른 역방향 프록시나 방화벽 솔루션이 필요하기 때문에 보안 관리가 더 복잡합니다.
사용자는 자신의 국가별 네임스페이스에 연결해야 합니다. 이를 위해 지원 부서에 문의하거나 교육을 받아야 할 수 있습니다.
Exchange 2010 테스트 솔루션
클라이언트 액세스 서버 배열 및 로드 균형 조정 전략 결정
Exchange 2010에서는 활성 사서함 데이터베이스 복사본을 다른 사서함 서버로 이동할 때(예: 사서함 데이터베이스 오류 발생 시 및 유지 관리 이벤트 중) 사서함 사용자 환경이 개선되도록 RPC 클라이언트 액세스 서비스 및 Exchange 주소록 서비스를 클라이언트 액세스 서버 역할에 도입했습니다. Microsoft Outlook 및 기타 MAPI 클라이언트에서 사서함 액세스에 대한 연결 끝점이 사서함 서버 역할에서 클라이언트 액세스 서버 역할로 이동되었습니다. 따라서 내결함성을 달성하려면 내부 및 외부 Outlook 연결 모두의 부하를 사이트 내의 클라이언트 액세스 서버 전체에 걸쳐 분산해야 합니다. 특정 클라이언트 액세스 서버가 아닌 클라이언트 액세스 서버 그룹과 MAPI 끝점을 연결하려면 클라이언트 액세스 서버 배열을 정의할 수 있습니다. Active Directory 사이트당 하나의 배열만 구성할 수 있고 배열을 두 개 이상의 Active Directory 사이트로 확장할 수 없습니다. 자세한 내용은 RPC 클라이언트 액세스 이해 및 Understanding Load Balancing in Exchange 항목을 참조하십시오.
*디자인 결정 요소*
각 사이트에서 클라이언트 액세스 서버 역할을 실행 중인 네 개의 서버에 세 개 사이트를 배포하는 것이므로 클라이언트 액세스 서버 배열은 총 세 개가 됩니다. 하드웨어 부하 분산 솔루션은 각 사이트에서 클라이언트 액세스 서버 배열 전반에 부하를 분산하는 데 사용됩니다.
Exchange 2010 테스트 솔루션
하드웨어 부하 분산 모델 결정
하드웨어 부하 분산 모델을 결정하려면 다음 단계를 사용합니다.
1단계: 기본 하드웨어 부하 분산 공급업체 식별
Cisco ACE(Application Control Engine) 제품군이 이 솔루션의 서버, 네트워크 및 저장소 연결 구성 요소에 대해 선택한 Cisco 통합 컴퓨팅 시스템과 작동하기 때문에 이 예에서 기본 공급업체는 Cisco입니다.
Cisco ACE 제품군은 Exchange 2010 응용 프로그램 환경에서 혜택을 볼 수 있는, 가용성 및 확장성이 뛰어난 데이터 센터 솔루션을 제공합니다. Cisco ACE 제품은 다음과 같은 장점과 함께 상호 운용성을 제공합니다.
성능, 확장성, 처리량 및 응용 프로그램 가용성
표준 기반 디자인
장치 분할을 사용한 가상 아키텍처
역할 기반 관리 및 중앙 집중식 관리
상세 패킷 검사, ACL(액세스 제어 목록), 유니캐스트 패스 반전 전달 및 NAT(Network Address Translation)/PAT(Port Address Translation)를 통한 보안 서비스
2단계: 기본 공급업체에서 사용 가능한 옵션 검토
Cisco ACE 제품군에는 두 가지 하드웨어 부하 분산 모델이 포함되어 있는데, 이들은 가용성 및 확장성이 뛰어난 데이터 센터 솔루션에 대한 요구를 충족하므로 Exchange 2010 응용 프로그램 환경에 적합합니다. 이러한 모델은 Cisco ACE 4710 어플라이언스와 Cisco Catalyst 6500/Cisco 7600 라우팅 플랫폼에 통합된 서비스 모듈입니다.
Cisco ACE 4710 어플라이언스는 소프트웨어 라이선스를 통해 업그레이드가 가능하고, 장기 투자 보호 및 확장성을 제공하는 1RU(One-Rack-Unit) 폼 요소에 최대 4Gbps 처리량을 제공합니다. 기본적으로 4710은 Cavium Nitrox Octeon 가속 카드가 장착된 1U 랙 섀시로, Cisco EtherChannel을 사용하여 함께 번들로 제공하고 스위치에 연결할 수 있는 4GB 이더넷 포트를 제공합니다. 기본적으로 Cisco ACE 4710은 한 개의 관리자 장치와 5개의 사용자 장치, 1Gbps 대역폭, 초당 1,000 SSL(Secure Sockets Layer) 트랜잭션 및 100Mbps의 압축 기능으로 가상화를 지원합니다. 새 장비 없이도 다음 소프트웨어 라이선스 업그레이드를 통해 이 솔루션을 확장할 수 있습니다.
처리량 1Gbps의 기본 처리량을 2Gbps 또는 4Gbps로 늘릴 수 있습니다.
가상 장치 가상 장치 수를 5개에서 20개로 늘릴 수 있습니다.
SSL 초당 트랜잭션 수 SSL 초당 트랜잭션 수를 1,000에서 5,000 또는 7,500으로 늘릴 수 있습니다.
압축 압축을 처리량의 500Mbps 또는 1Gbps나 2Gbps로 늘릴 수 있습니다.
역할 기반 액세스 제어 중앙 집중식 역할 기반 관리가 Application Network Manager GUI 또는 CLI(명령줄 인터페이스)를 통해 제공됩니다.
고가용성 어플라이언스 내 및 컨텍스트 간 중복 구성을 지원합니다.
ACE 4710 어플라이언스처럼 소프트웨어 라이선스를 통해 업그레이드할 수 있는 Cisco Catalyst 6500 시리즈 스위치 또는 Cisco 7600 시리즈 라우터용 Cisco ACE 모듈은 한 개 슬롯 모듈 폼 요소에서 최대 16Gbps의 처리량을 제공합니다. 최대 4개의 Cisco ACE 모듈을 단일 Cisco Catalyst 6500 시리즈 스위치 또는 Cisco 7600 시리즈 라우터에 설치할 수 있습니다. 각 모듈은 스위치나 라우터에서 사용 가능한 광범위한 연결 옵션을 이용하여 여러 독립적인 사업부의 업무 프로세스를 지원할 수 있습니다. 시스템 관리자는 응용 프로그램 요구 사항을 확인하고 해당 네트워크 서비스를 가상 컨텍스트로 지정할 수 있습니다. 각 컨텍스트에는 정책, 인터페이스, 리소스 및 관리자의 고유한 세트가 포함되어 있습니다.
처리량 부하 분산 서비스는 초당 345,000개의 계층 4 연결 및 최대 16Gbps의 처리 용량을 제공합니다.
가상 장치 가상 장치 수를 5개에서 250개로 늘릴 수 있습니다.
SSL 초당 트랜잭션 수 SSL 초당 트랜잭션 수를 ACE20 모듈의 라이선스를 통해 15,000개 SSL 세션으로, ACE30 모듈의 라이선스를 통해 30,000개 SSL 세션으로 늘릴 수 있습니다.
압축 ACE30 모듈에서 압축을 6Gbps로 늘릴 수 있습니다.
역할 기반 액세스 제어 중앙 집중식 역할 기반 관리가 Application Network Manager GUI 또는 CLI를 통해 제공됩니다.
고가용성 어플라이언스 내, 섀시 간 및 컨텍스트 간 중복 구성을 지원합니다.
3단계: 하드웨어 부하 분산 모델 선택
최대 응용 프로그램 가용성, 포괄적인 응용 프로그램 보안, 가상화된 아키텍처 및 투자 가치와 보호를 제공하므로 Cisco ACE 4710 어플라이언스를 선택했습니다.
최대 응용 프로그램 가용성 Cisco ACE 4710은 응용 프로그램이나 장치 오류의 영향을 최소화하는 확장성이 뛰어난 계층 4 부하 분산과 계층 7 콘텐츠 전환을 통해 가용성을 높임으로써 최종 사용자에게 비즈니스 연속성 및 서비스를 보장합니다.
포괄적인 응용 프로그램 보안 Cisco ACE 4710은 상세 패킷 검사, 네트워크와 프로토콜 보안 및 확장성이 뛰어난 액세스 제어 기능 등과 함께 응용 프로그램 위협과 DoS(서비스 거부) 공격에 대한 보호 기능을 제공함으로써 서버 방어의 최전선 역할을 합니다.
가상화된 아키텍처 가상화된 아키텍처는 Cisco ACE의 기본 디자인 요소이며, 시장의 다른 솔루션에 비해 고유한 판매 방법입니다. IT 관리자는 단일 Cisco ACE 4710 어플라이언스에서 최대 20개의 가상 장치를 구성할 수 있습니다. 이에 따른 이점은 응용 프로그램 배포가 늘어나도 관리할 장치 수가 감소하고, 전원 및 냉각 비용이 크게 줄며, 새 응용 프로그램의 서비스에 걸리는 시간이 단축된다는 것입니다.
Exchange 2010 테스트 솔루션
저장소 디자인 결정
잘 디자인된 저장소 솔루션은 성공적인 Exchange 2010 사서함 서버 역할 배포에 중요합니다. 자세한 내용은 사서함 서버 저장소 디자인를 참조하십시오.
1단계: 저장소 요구 사항 요약
다음 표에는 이전 디자인 단계에서 계산했거나 결정한 저장소 요구 사항이 요약되어 있습니다.
디스크 공간 요구 사항 요약
| 디스크 공간 요구 사항 | 값 |
|---|---|
2GB 사서함(MB)에 대한 디스크의 사서함 크기 |
2301 |
필요한 총 데이터베이스 용량(GB) |
120128 |
필요한 총 로그 용량(GB) |
3974 |
필요한 총 용량(GB) |
124102 |
세 개의 데이터베이스 복사본에 필요한 총 용량(GB) |
372306 |
세 개의 데이터베이스 복사본에 필요한 총 용량(TB) |
364 |
사이트당 필요한 총 용량(TB) |
122 |
2단계: 가상 또는 씬 프로비저닝 사용 여부 확인
많은 고객이 Exchange 2010으로 이동하면서 사서함 할당량을 크게 늘리고 싶어 합니다. 하지만 사서함 크기를 수백 MB에서 수백 GB로 늘리려면 시간이 걸릴 수 있습니다. 이 경우 일부 조직은 추가 저장소 구매에 대해 알아보고 나중에 디스크 저장소 가격이 저렴해지는 시기로 구매를 연기하여 혜택을 볼 수 있습니다.
많은 저장소 공급업체가 몇 가지 유형의 씬 프로비저닝 솔루션을 제공하므로 실제로 사용할 수 있는 것보다 더 많은 저장소 용량을 Exchange 서버에 제공한 다음, 중단 또는 가동 중지 시간 없이 늘어나는 요구를 충족할 수 있도록 실제 저장소를 동적으로 추가할 수 있습니다. 이렇게 하면 초기에 할당하는 저장소 용량을 줄임으로써 TCO를 낮추고, 성장을 지원하는 데 필요한 단계를 줄임으로써 관리를 단순화할 수 있습니다.
씬 프로비저닝의 EMC 통합 저장소 구현은 해당 가상 프로비저닝 기능에 의해 제공되는데, 이러한 기능은 핫 스페어링, 사전 스페어링, 중단 없는 씬 풀 확장을 지원하며, 가동 중지 시간 없이 씬(thin) LUN과 기존의 씨크(thick) LUN 간 마이그레이션도 지원합니다. 이러한 유연성에서 EMC 통합 저장소 가상 프로비저닝과 일반적인 씬 프로비저닝 구현이 구분됩니다.
*디자인 결정 요소*
현재 Exchange 구현에는 200MB의 정의된 사서함 할당량이 있습니다. Exchange 2010으로 이동한 후 사서함 크기가 처음 12-18개월에 약 300% 늘어납니다. 계획은 평균 600MB의 사서함 크기를 수용할 수 있는 충분한 저장소를 구입하는 것입니다. Exchange 2010 전체 구현 기간 동안 예상 평균 사서함 크기는 약 2GB입니다. 2GB의 사서함 할당량을 구매하려면 비용이 너무 많이 들기 때문에 씬 프로비저닝을 구현하게 됩니다. 따라서 600MB의 초기 사서함 할당량을 배포할 수 있습니다. 예상 수요를 충족하기 위해 다음 예산 주기에서 기본 실제 저장소를 확장합니다.
3단계: 동일한 LUN에 로그와 데이터베이스 공존 여부 결정
Exchange 2010 배포용 EMC 통합 저장소에서 씬 프로비저닝을 이용할 때 로그 파일과 데이터베이스 파일을 구분하는 것이 좋습니다. 사서함 크기는 늘어나지만 메시지 프로필(하루 동안 주고받는 메시지)은 늘어나지 않을 것이라고 예상되는 경우 데이터베이스 LUN을 점진적으로 늘리고 로그 LUN은 늘리지 않아야 합니다. 로그를 씬 프로비저닝된 LUN에 두는 것이 도움이 되지 않을 수 있습니다.
데이터베이스 LUN과 로그 LUN을 구분하면 각각을 다른 유형의 디스크에 둘 수 있거나 다른 수준의 RAID를 사용할 수 있습니다.
*디자인 결정 요소*
EMC 모범 사례에 따라 데이터베이스와 로그가 다른 LUN에 구분됩니다. 메시지 프로필이 다음 3년 동안 거의 변동이 없을 것으로 예상되므로 로그를 씬 프로비저닝된 LUN에 두어도 도움이 되지 않습니다.
4단계: LUN당 데이터베이스 수 결정
VSS 기반 백업 및 복원이 LUN 수준에서 작동하므로 LUN당 데이터베이스 수는 일반적으로 백업 전략에 의해 결정됩니다. 이전 단계에서 VSS 기반 백업을 데이터베이스 복구 전략에 포함하지 않기로 했습니다. LUN당 데이터베이스 수에 대한 결정은 다른 요소를 기준으로 합니다. 일반적으로 LUN당 단일 데이터베이스를 배포해야 합니다. LUN당 데이터베이스 수가 두 개 이상일 경우 다음과 같은 결과가 나타날 수 있습니다.
오버로드된 데이터베이스가 정상적인 데이터베이스에 영향을 줌
한 데이터베이스의 시드 작업이 정상적인 데이터베이스에 영향을 줌
수동 데이터베이스 I/O가 활성 데이터베이스에 영향을 줌
*디자인 결정 요소*
LUN당 두 개 이상의 데이터베이스 배포에 대한 요구 사항이 없기 때문에 저장소 디자인은 LUN 모델별 단일 데이터베이스를 기준으로 합니다.
5단계: 기본 데이터 센터의 사서함 서버에 대한 서버당 LUN 수 결정
이전 단계에서 각각의 기본 사서함 서버가 6개의 활성 데이터베이스와 6개의 수동 데이터베이스를 지원하는 것을 확인했습니다. 아래 표에 요약된 대로 각각의 기본 데이터 센터 사서함 서버에 대해 총 24개의 LUN이 필요합니다.
사서함 서버당 필요한 LUN 수
| LUN 유형 | 서버당 LUN 수 |
|---|---|
활성 데이터베이스 LUN 수 |
6 |
활성 로그 LUN 수 |
6 |
수동 데이터베이스 LUN 수 |
6 |
수동 로그 LUN 수 |
6 |
총 LUN 수 |
24 |
6단계: 보조 데이터 센터의 사서함 서버에 대한 서버당 LUN 수 결정
이전 단계에서 각각의 보조 사서함 서버가 6개의 수동 데이터베이스를 지원하는 것을 확인했습니다. 아래 표에 요약된 대로 각각의 보조 데이터 센터 사서함 서버에 대해 총 12개의 LUN이 필요합니다.
사서함 서버당 필요한 LUN 수
| LUN 유형 | 서버당 LUN 수 |
|---|---|
수동 데이터베이스 LUN 수 |
6 |
수동 로그 LUN 수 |
6 |
총 LUN 수 |
12 |
7단계: 저장소 구성 요소 정의
저장소 디자인의 나머지 단계를 간단하게 하기 위해 구성 요소 방법을 사용합니다. 이 솔루션에서 각 데이터베이스는 450개의 활성 사서함을 지원합니다. 각 사서함 서버는 6개의 데이터베이스 LUN과 6개의 로그 LUN에서 6개의 데이터베이스 또는 2,700개의 활성 사서함을 지원합니다. 2,700개 단위의 사서함을 지원하는 12개의 LUN 구성 요소가 사용됩니다.
8단계: 구성 요소의 IOPS 요구 사항 결정
이 단계에서는 구성 요소에서 2,700개 활성 사서함 사용자를 지원하는 데 필요한 트랜잭션 IOPS를 계산합니다. 다음 단계에서는 IOPS 요구 사항을 사용하여 처음에 프로비저닝된 사서함 할당량과 완전히 프로비저닝된 사서함 할당량을 기준으로 하여 구성 요소에 배포할 최소 및 최대 스핀들 수를 결정합니다. 다음 계산을 사용합니다.
구성 요소에 필요한 총 트랜잭션 IOPS = 사서함 사용자당 IOPS × 사서함 수 × I/O 오버헤드 요소
= 0.10 × 2700 × 20%
= 324 IOPS
9단계: 디스크의 초기 사서함 크기 결정
이전 단계에서 2,048MB 사서함 할당량 제한에 대해 디스크의 사서함 크기를 2,301MB로 계산했습니다. 씬 프로비저닝이 사용되므로 디스크의 초기 사서함 크기를 계산합니다. 이 값은 이후 단계에서 초기 용량 요구 사항을 결정할 때 사용됩니다.
다음 계산은 600MB 사서함 할당량을 기준으로 하여 이 솔루션에서 디스크의 초기 사서함 크기를 결정하는 데 사용됩니다.
공백 = 하루 100개 메시지 x 75 ÷ 1024MB = 7.3MB
휴지통 = (하루 100개 메시지 x 75 ÷ 1024MB × 14일) + (600MB x 0.012) + (600MB x 0.058) = 144.2MB
디스크의 사서함 크기 = 사서함 제한 + 공백 + 휴지통
= 600MB + 7.3MB + 144.2MB
= 752 MB
10단계: 구성 요소의 초기 데이터베이스 용량 요구 사항 결정
초기 사서함 할당량이 600MB인 2,700개 사서함에 필요한 초기 저장소 용량을 결정하려면 다음 계산을 사용합니다.
데이터베이스 파일 용량 = (사서함 수 × 디스크의 사서함 크기 × 데이터베이스 오버헤드 성장 요소) + (20% 데이터 오버헤드)
= (2700 × 752 × 1) + (406080)
= 2,436,480 MB
= 2,379 GB
데이터베이스 카탈로그 용량 = 데이터베이스 파일 용량의 10%
= 238 GB
총 데이터베이스 용량 = (데이터베이스 파일 크기) + (인덱스 크기) ÷ 0.80(20%의 사용 가능한 볼륨 공간 제공)
= (2379 + 238) ÷ 0.8
= 3,271 GB
구성 요소의 6개 데이터베이스에 3,271GB의 초기 저장소 용량이 필요합니다.
11단계: 구성 요소의 완전히 프로비저닝된 데이터베이스 용량 요구 사항 결정
사서함 할당량이 2,048MB인 2,700개 사서함에 필요한 완전히 프로비저닝된 저장소 용량을 결정하려면 다음 계산을 사용합니다.
데이터베이스 파일 용량 = (사서함 수 × 디스크의 사서함 크기 × 데이터베이스 오버헤드 성장 요소) + (20% 데이터 오버헤드)
= (2700 × 2301 × 1) + (1242540)
= 7,455,240 MB
= 7,281 GB
데이터베이스 카탈로그 용량 = 데이터베이스 파일 용량의 10%
= 728 GB
총 데이터베이스 용량 = (데이터베이스 파일 크기) + (인덱스 크기) ÷ 0.80(20%의 사용 가능한 볼륨 공간 제공)
= (7281 + 728) ÷ 0.8
= 10,011GB
구성 요소의 6개 데이터베이스에 10,011GB의 완전히 프로비저닝된 저장소 용량이 필요합니다.
12단계: 구성 요소의 로그 용량 요구 사항 결정
구성 요소의 2,700개 사서함에 필요한 로그 저장소 용량을 결정하려면 다음 계산을 사용합니다.
필요한 구성 요소 로그 용량 = 사서함 사용자 수 × 일별 사서함당 로그 수 × 로그 크기 × (실패한 인프라를 교체하는 데 필요한 일 수) + (사서함 이동 비율 오버헤드)
= (2700 × 20 × 1024 × 4) + (2700 × 0.01 × 2048)
= 216,054MB
= 211 GB
총 로그 용량 = 로그 용량 ÷ 0.80(20%의 사용 가능한 볼륨 공간 제공)
= 211 ÷ 0.80
= 264
구성 요소의 6개 로그 세트에 264GB의 저장소 용량이 필요합니다.
참고
로그 볼륨이 씬 프로비저닝되지 않았기 때문에 계산된 저장소 용량은 완전히 프로비저닝된 환경의 로그 용량 요구 사항을 나타냅니다.
13단계: 구성 요소의 IOPS 요구 사항을 지원하는 데 필요한 스핀들 수 결정
이 단계에서는 IOPS 요구 사항을 지원하는 데 필요한 스핀들 수를 결정합니다. 다음 단계에서 용량 요구 사항을 충족하는 스핀들 수를 결정합니다.
이전 단계에서 2,700개 사서함 구성 요소를 지원하는 데 324개의 IOPS가 필요함을 확인했습니다. 이 단계에서는 다음 계산을 사용하여 IOPS 요구 사항을 충족하는 데 필요한 디스크 수를 계산합니다.
디스크 수 = (사용자 IOPS × 읽기 비율) + 쓰기 벌점 × (사용자 IOPS × 쓰기 비율) ÷ 선택한 디스크 유형의 IOPS 기능
= (324 × 0.6) + 4 × (324 × 0.4) ÷ 155
= 4.6
RAID-5 구성에 5개 디스크를 사용하여 IOPS 요구 사항을 충족할 수 있습니다.
참고
이러한 계산은 EMC 솔루션에만 사용할 수 있습니다. 선택한 저장소 솔루션의 스핀들 요구 사항에 대한 지침은 저장소 공급업체에 문의해야 합니다.
14단계: 구성 요소의 초기 데이터베이스 용량 요구 사항을 지원하는 데 필요한 스핀들 수 결정
이전 단계에서 초기에 프로비저닝된 600MB의 사서함에 대한 2,700개의 사서함 구성 요소에 3,271GB의 저장소 용량이 필요하다는 것을 확인했습니다. CX4 모델 480의 RAID-5 구성에서 450GB 스핀들별로 사용 가능한 용량은 약 402GB입니다. 필요한 디스크 수를 결정하려면 다음 계산을 사용합니다.
디스크 수 = (필요한 총 용량) ÷ (RAID-5의 스핀들당 사용 가능한 용량)
= 3271GB ÷ 402GB
= 8.1
초기 데이터베이스 용량 요구 사항은 9개 디스크로 충족됩니다.
씬 프로비저닝을 사용하여 EMC 통합 저장소에 저장소를 배포하는 최상의 방법은 5개 디스크의 배수로 RAID-5 씬 풀을 구성하는 것입니다. 2,700개 사서함의 한 개 구성 요소에 대해 10개 디스크를 할당하면 이후 증가에 적절한 공간이 생깁니다.
15단계: 구성 요소의 완전히 프로비저닝된 데이터베이스 용량 요구 사항을 지원하는 데 필요한 스핀들 수 결정
이전 단계에서 초기에 프로비저닝된 2,048MB의 사서함에 대한 2,700개의 사서함 구성 요소에 10,011GB의 저장소 용량이 필요하다는 것을 확인했습니다. CX4 모델 480의 RAID-5 구성에서 450GB 스핀들별로 사용 가능한 용량은 약 402GB입니다. 필요한 디스크 수를 결정하려면 다음 계산을 사용합니다.
디스크 수 = (필요한 총 용량) ÷ (RAID-5의 스핀들당 사용 가능한 용량)
= 10011GB ÷ 402GB
= 24.9
완전하게 프로비저닝된 데이터베이스 용량 요구 사항은 25개 디스크로 충족됩니다.
16단계: 구성 요소의 로그 용량 요구 사항을 지원하는 데 필요한 스핀들 수 결정
이전 단계에서 2,700개 사서함 구성 요소에 264GB의 로그 저장소 용량이 필요하다는 것을 확인했습니다. CX4-480의 RAID-1/0 구성에 450GB 드라이브 두 개를 사용하면 402GB의 사용 가능한 저장소 용량이 제공됩니다. 제안한 두 개의 디스크 구성이 2,700개 사서함 구성 요소의 로그 용량 요구 사항을 충족합니다.
17단계: 씬 풀 전략 결정
구성 요소의 IOPS 및 용량 요구 사항을 지원하는 데 필요한 스핀들 수가 결정되었으므로 가상 또는 씬 프로비저닝을 사용할 때 해당 구성 요소의 배열에서 LUN을 프로비저닝하는 최상의 방법을 결정해야 합니다.
Exchange에 사용할 씬 풀을 디자인할 때 사용할 수 있는 기본 모델이 세 개 있습니다.
단일 저장소 풀 모든 Exchange 데이터베이스와 로그에 대해 한 개의 큰 저장소 풀을 사용하는 것이 가장 간단한 방법이며 최상의 공간 사용률을 제공합니다. 하지만 같은 데이터베이스의 복사본 여러 개가 같은 실제 배열에 있는 경우에는 단일 씬 풀을 사용하지 않는 것이 좋습니다.
서버당 한 개의 저장소 풀 각 Exchange 사서함 서버당 하나의 저장소 풀을 사용하면 배열에 LUN을 배치할 때 좀 더 세부적으로 조정할 수 있습니다. 제대로 디자인하는 경우, 데이터베이스 복사본이 분리되어 스핀들 세트가 구분되며 시드/다시 시드, 백업 및 온라인 유지 관리(백그라운드 데이터베이스 유지 관리)와 같은 작업 중에 나타날 수 있는 디스크 경합 문제를 최소화할 수 있습니다. 하지만 이 모델에서는 보유한 사서함 서버 수에 따라 씬 모델이 여러 개 생길 수 있으며 이로 인해 관리가 더욱 어려워질 수 있습니다.
데이터베이스 복사본당 한 개의 저장소 풀 데이터베이스 복사본당 저장소 풀 하나를 사용하면 각 복사본이 배열의 다른 스핀들 세트에 격리됩니다. 대부분의 조직이 2-4개의 데이터베이스 복사본을 배포하므로 씬 풀 수가 관리 가능한 수로 유지됩니다. 이 모델에서는 여러 사서함 서버의 같은 씬 풀에 데이터베이스 LUN이 있습니다. 하나의 사서함 서버에서 시드/다시 시드, 백업 및 온라인 유지 관리(백그라운드 데이터베이스 유지 관리) 등의 작업이 다른 사서함 서버의 성능에 영향을 주는 경우가 있습니다.
*디자인 결정 요소*
서버 모델마다 한 개의 저장소 풀의 장점이 관심을 끌지만 이 경우 각 사이트에 8개의 씬 풀이 있거나 총 24개의 씬 풀이 있게 됩니다. 이러한 상황을 간단하게 유지하기 위해 데이터베이스 복사본 모델마다 1개의 저장소 풀이 사용됩니다. 따라서 각 사이트에 세 개의 씬 풀이 필요하며 각 데이터베이스 복사본이 고유한 스핀들 세트에 있게 됩니다. 또한 증분을 수용할 수 있도록 저장소를 추가해야 하는 경우 데이터베이스 복사본 스핀들 격리가 유지 관리됩니다.
18단계: 씬 풀당 초기 스핀들 수 결정
첫 번째 씬 풀에는 사이트에 네 개의 기본 데이터 센터 사서함 서버 각각에 2,700개의 사서함 구성 요소가 있습니다. 이전 단계에서 구성 요소의 IOPS 및 용량 요구 사항을 지원하는 데 10개의 스핀들이 필요하다는 것을 확인했습니다. 10,800개의 활성 사서함을 지원하는 첫 번째 씬 풀에는 40개의 스핀들이 필요합니다.
두 번째 씬 풀에도 사이트에서 네 개의 기본 데이터 센터 사서함 서버 각각에 2,700개의 사서함 구성 요소가 있습니다. 10,800개의 활성 사서함을 지원하는 두 번째 씬 풀에는 40개의 스핀들이 필요합니다.
세 번째 씬 풀에도 사이트에 있는 네 개의 각 보조 데이터 센터 사서함 서버의 2,700개 사서함 구성 요소가 있습니다(사이트 복구 데이터베이스 복사본을 지원하는 대체 DAG의 서버). 10,800개의 수동 사서함을 지원하는 세 번째 씬 풀에는 40개의 스핀들이 필요합니다.
초기 데이터베이스 용량 요구 사항을 지원하는 데 사이트별로 총 120개의 스핀들이 필요합니다.
19단계: 씬 풀당 완전하게 프로비저닝된 스핀들 수 결정
첫 번째 씬 풀에는 사이트에 네 개의 기본 데이터 센터 사서함 서버 각각에 2,700개의 사서함 구성 요소가 있습니다. 이전 단계에서 구성 요소의 IOPS 및 완전히 프로비저닝된 용량 요구 사항을 지원하는 데 25개의 스핀들이 필요하다는 것을 확인했습니다. 10,800개의 활성 사서함을 지원하는 첫 번째 씬 풀에는 100개의 스핀들이 필요합니다.
두 번째 씬 풀에도 사이트에서 네 개의 기본 데이터 센터 사서함 서버 각각에 2,700개의 사서함 구성 요소가 있습니다. 10,800개의 활성 사서함을 지원하는 두 번째 씬 풀에는 100개의 스핀들이 필요합니다.
세 번째 씬 풀에도 사이트에 있는 네 개의 각 보조 데이터 센터 사서함 서버의 2,700개 사서함 구성 요소가 있습니다(사이트 복구 데이터베이스 복사본을 지원하는 대체 DAG의 서버). 10,800개의 수동 사서함을 지원하는 세 번째 씬 풀에는 100개의 스핀들이 필요합니다.
완전히 프로비저닝된 데이터베이스 용량 요구 사항을 지원하는 데 사이트별로 총 300개의 스핀들이 필요합니다.
20단계: 모든 로그 LUN을 지원하는 데 필요한 스핀들 수 결정
이전 단계에서 2,700개의 각 사서함 구성 요소에는 로그 LUN 요구 사항을 지원하는 데 두 개의 스핀들이 필요하다는 것을 확인했습니다.
기본 데이터 센터 사서함 서버에 활성 사서함 데이터베이스를 지원하는 구성 요소가 네 개 있습니다. 10,800개의 활성 사서함을 지원하는 로그 LUN에는 8개의 스핀들이 필요합니다.
기본 데이터 센터 사서함 서버에 수동 사서함 데이터베이스를 지원하는 구성 요소가 네 개 있습니다. 10,800개의 수동 사서함을 지원하는 로그 LUN에는 8개의 스핀들이 필요합니다.
보조 데이터 센터 사서함 서버에 수동 사서함 데이터베이스를 지원하는 구성 요소가 네 개 있습니다. 10,800개의 수동 사서함을 지원하는 로그 LUN에는 8개의 스핀들이 필요합니다.
단일 사이트에서 로그 LUN 요구 사항을 지원하려면 24개의 스핀들이 필요합니다.
21단계: 저장소 배열에서 초기에 필요한 스핀들 수를 지원할 수 있는지 확인
이 단계에서는 다음 계산을 사용하여 선택한 저장소 배열에서 필요한 총 스핀들 수를 지원할 수 있는지 확인합니다.
사이트별로 필요한 총 스핀들 수 = 데이터베이스 LUN에 필요한 스핀들 수 + 로그 LUN에 필요한 스핀들 수
= 120 + 24
= 144
10개의 디스크 배열 엔클로저가 있는 CX4-480은 150개의 스핀들을 포함하며 요구 사항을 충족합니다.
22단계: 완전하게 프로비저닝된 환경을 지원하는 데 필요한 스핀들 수 결정
이 단계에서는 다음 계산을 사용하여 완전하게 프로비저닝된 환경을 지원하는 데 필요한 총 스핀들 수를 계산합니다.
사이트별로 필요한 총 스핀들 수 = 데이터베이스 LUN에 필요한 스핀들 수 + 로그 LUN에 필요한 스핀들 수
= 300 + 24
= 324
22개의 디스크 배열 엔클로저가 있는 CX4-480에는 330개의 스핀들이 있으며 요구 사항을 충족합니다.
Exchange 2010 테스트 솔루션
솔루션 개요
이전 섹션에서는 Exchange 2010 솔루션을 고려할 때 디자인 결정에 대한 정보를 제공했습니다. 다음 섹션에서는 솔루션의 개요를 제공합니다.
Exchange 2010 테스트 솔루션
논리 솔루션 다이어그램
이 솔루션은 다중 사이트 토폴로지에 배포된 총 36개의 Exchange 2010 서버로 구성됩니다. 36개 서버 중 12개는 클라이언트 액세스 서버 역할과 허브 전송 서버 역할을 모두 실행합니다. 나머지 24개 서버는 사서함 서버 역할을 실행합니다. 각 사이트에 클라이언트 액세스와 허브 전송 조합 서버가 네 개 있는 클라이언트 액세스 서버 배열이 있습니다. DAG가 세 개 있고, 각각에 8개의 사서함 서버가 있습니다. 각 사이트에 있는 파일 서버는 각 DAG에 대한 기본 및 대체 파일 공유 미러링 모니터 서버를 호스트합니다.
논리 솔루션 다이어그램
Exchange 2010 테스트 솔루션
물리적 솔루션 다이어그램
세 사이트에는 각각 중복 Cisco Fabric Interconnect 6120 및 Cisco MDS 9134 스위치를 통해 EMC CLARiiON CX4 모델 480 저장소 배열에 연결된 Cisco B200 블레이드 서버 네 개가 있습니다. 중복 Cisco Nexus 5010 이더넷 스위치는 기본 네트워크 인프라를 제공합니다. 중복 Cisco ACE 4710 부하 분산 장치를 통해 각 사이트에 있는 클라이언트 액세스 서버 배열에 클라이언트 트래픽의 부하가 분산됩니다.
물리적 솔루션 다이어그램
Exchange 2010 테스트 솔루션
Hyper-V 루트 서버 구성 요약
다음 표에는 이 솔루션에 사용된 실제 서버 하드웨어가 요약되어 있습니다.
Cisco 통합 컴퓨팅 시스템 요약
| 항목 | 설명 |
|---|---|
블레이드 서버 |
4 × B200 M1 |
프로세서 |
2 × Intel Zeon x5570(2.93GHz) |
메모리 |
96GB RAM(12 × 8GB DIMM) |
수렴된 네트워크 어댑터 |
M71KR-Q(2 × 10GB 이더넷 및 2 × 4Gbps 파이버 채널) |
내부 블레이드 저장소 |
2 × 146GB SAS 10,000 RPM 디스크(RAID-1) |
섀시 |
5108(6RU) |
패브릭 Extender |
2 × 2104XP |
패브릭 상호 연결 |
2 × 6120XP |
패브릭 상호 연결 확장 모듈 |
2 × 8포트 4Gbps 파이버 채널 |
다음 표에는 이 솔루션에 사용된 저장소 및 네트워크 하드웨어가 요약되어 있습니다.
LAN 및 SAN 스위치
| 항목 | 설명 |
|---|---|
10GB 이더넷(GbE) 스위치 |
2 × Nexus 5010(8개의 고정된 1GbE/10GbE 포트, 12개의 고정된 10GbE 포트, 데이터 센터 브리징) |
파이버 채널 스위치 |
2 × MDS 9134(32개의 고정된 4Gbps 포트) |
다음 표에는 이 솔루션에 사용된 소프트웨어에 대한 정보가 나와 있습니다.
솔루션에 대한 소프트웨어 요약
| 항목 | 설명 |
|---|---|
하이퍼바이저 호스트 서버 |
Windows Server 2008 R2 Hyper-V Enterprise |
Exchange Server VM |
Windows Server 2008 R2 Enterprise |
Exchange Server 2010 사서함 서버 역할 |
Enterprise Edition RU2 |
Exchange Server 2010 허브 전송 및 클라이언트 액세스 서버 역할 |
Standard Edition RU2 |
여러 경로 I/O 분산 |
EMC PowerPath |
Exchange 2010 테스트 솔루션
클라이언트 액세스 및 허브 전송 서버 구성
다음 표에는 이 솔루션에 사용된 클라이언트 액세스 및 허브 전송 조합 서버 구성이 요약되어 있습니다.
클라이언트 액세스 및 허브 전송 서버 구성
| 구성 요소 | 값 또는 설명 |
|---|---|
실제 또는 가상 |
Hyper-V VM |
가상 프로세서 수 |
3 |
메모리 |
8 GB |
저장소 |
루트 서버 운영 체제 볼륨의 가상 하드 디스크 |
운영 체제 |
Windows Server 2008 R2 |
Exchange 버전 |
Exchange Server 2010 Standard Edition |
Exchange 업데이트 수준 |
Exchange 2010 업데이트 롤업 2 |
타사 소프트웨어 |
없음 |
Exchange 2010 테스트 솔루션
사서함 서버 구성
다음 표에는 이 솔루션에 사용된 기본 사서함 서버(DAG에 대한 기본 사이트에서 기본 및 보조 데이터베이스 복사본 호스팅) 구성이 요약되어 있습니다.
기본 사서함 서버 구성
| 구성 요소 | 값 또는 설명 |
|---|---|
실제 또는 가상 |
Hyper-V VM |
가상 프로세서 수 |
4 |
메모리 |
53 GB |
저장소 |
루트 서버 운영 체제 볼륨의 가상 하드 디스크 |
운영 체제 |
Windows Server 2008 R2 |
Exchange 버전 |
Exchange Server 2010 Enterprise Edition |
Exchange 업데이트 수준 |
Exchange 2010 업데이트 롤업 2 |
타사 소프트웨어 |
없음 |
다음 표에는 이 솔루션에 사용된 보조 사서함 서버(DAG에 대한 보조 사이트에서 제3의 데이터베이스 복사본 호스팅) 구성이 요약되어 있습니다.
보조 사서함 서버 구성
| 구성 요소 | 값 또는 설명 |
|---|---|
실제 또는 가상 |
Hyper-V VM |
가상 프로세서 수 |
2 |
메모리 |
24 GB |
저장소 |
루트 서버 운영 체제 볼륨의 가상 하드 디스크 |
운영 체제 |
Windows Server 2008 R2 |
Exchange 버전 |
Exchange Server 2010 Enterprise Edition |
Exchange 업데이트 수준 |
Exchange 2010 업데이트 롤업 2 |
타사 소프트웨어 |
없음 |
Exchange 2010 테스트 솔루션
데이터베이스 레이아웃
다음 다이어그램은 일반적인 작동 조건에서 이 솔루션에 사용된 데이터베이스 복사본 레이아웃을 요약한 것입니다.
데이터베이스 복사본 레이아웃: 1
데이터베이스 복사본 레이아웃: 2
데이터베이스 복사본 레이아웃: 3
Exchange 2010 테스트 솔루션
저장소 하드웨어 요약
다음 표에는 이 솔루션에 사용된 저장소 하드웨어에 대한 정보가 나와 있습니다.
EMC 통합 저장소 NS-480(통합된 CLARiiON CX4-480)
| 항목 | 설명 |
|---|---|
저장소 |
3 CLARiiON CX4-480(사이트당 1개) |
저장소 연결(파이버 채널, SAS, SATA, iSCSI) |
파이버 채널 |
저장소 캐시 |
32GB(저장소 포트당 600MB 읽기 캐시 및 10,160MB 쓰기 캐시) |
저장소 컨트롤러 수 |
저장소 프레임당 2개 |
사용 가능하거나 사용한 저장소 포트 수 |
저장소 프레임당 8개(저장소 포트당 4개) 사용 가능, 4개 사용(저장소 포트당 2개) |
호스트할 최대 저장소 연결 대역폭 |
8 × 4Gbps |
솔루션에서 테스트한 총 디스크 수 |
432개(3개 사이트에서 데이터베이스용 360개, 로그용 72개) |
저장소에서 호스트할 수 있는 최대 스핀들 수 |
단일 저장소 배열에 480개 |
Exchange 2010 테스트 솔루션
저장소 구성
솔루션에 사용된 각 CX4 모델 480 저장소 배열이 아래 표와 같이 구성되었습니다.
저장소 구성
| 구성 요소 | 값 또는 설명 |
|---|---|
총 저장소 엔클로저 수 |
3 |
사이트당 총 저장소 엔클로저 수 |
1 |
엔클로저당 총 디스크 수 |
150 |
엔클로저당 총 저장소 풀 수 |
3 |
저장소 풀당 총 디스크 수(초기) |
40 |
데이터베이스 LUN당 총 디스크 수(초기) |
10 |
로그 LUN당 총 디스크 수 |
2 |
엔클로저당 사용된 총 디스크 수 |
144 |
데이터베이스에 대한 LUN 크기(초기) |
4,020GB |
로그에 대한 LUN 크기 |
402 GB |
데이터베이스에 대한 RAID 수준 |
5 |
로그에 대한 RAID 수준 |
1/0 |
다음 표에서는 세 개의 CX4 모델 480 저장소 시스템 간에 사용 가능한 저장소를 디자인하고 할당하는 방법을 보여줍니다.
CX4 모델 480 저장소 시스템 간 저장소 구성
| 데이터 센터 | DAG | 데이터베이스 | Array1 | Array2 | Array3 |
|---|---|---|---|---|---|
1 |
1 |
DB1-24 |
C1, C2 |
C3 |
|
2 |
2 |
DB25-48 |
C3 |
C1, C2 |
|
3 |
3 |
DB49-72 |
C3 |
C1, C2 |
Exchange 2010 테스트 솔루션
솔루션 유효성 검사 방법론
프로덕션 환경에 Exchange 솔루션을 배포하기 전에 해당 솔루션이 제대로 디자인되고 크기가 조정되고 구성되었는지 확인합니다. 이 유효성 검사에는 시스템이 원하는 대로 작동하는지 확인하는 기능 테스트와 시스템에서 원하는 사용자의 부하를 처리할 수 있는지 확인하는 성능 테스트를 포함해야 합니다. 이 섹션에서는 이 솔루션에 대한 서버와 저장소 디자인의 유효성을 검사하는 데 사용된 방법 및 테스트 방법론을 설명합니다. 특히 다음 테스트가 자세하게 정의됩니다.
성능 테스트
저장소 성능 유효성 검사(Jetstress)
서버 성능 유효성 검사(Loadgen)
기능 테스트
데이터베이스 전환 유효성 검사
서버 전환 유효성 검사
서버 장애 조치 유효성 검사
데이터 센터 전환 유효성 검사
Exchange 2010 테스트 솔루션
저장소 디자인 유효성 검사 방법론
Exchange 사서함 서버 역할에 연결된 저장소 하위 시스템의 성능 및 안정성 수준은 전반적인 Exchange 배포 상태에 큰 영향을 미칩니다. 또한 저장소 성능이 저하되면 트랜잭션 대기 시간이 길어지고, 주로 Exchange 시스템에 액세스할 때 저하된 클라이언트 환경에 반영됩니다. 가능한 최상의 클라이언트 환경을 보장하려면 이 섹션에서 설명한 방법을 통해 저장소 크기 조정 및 구성의 유효성을 확인합니다.
도구 집합
Exchange 저장소 크기 조정 및 구성의 유효성을 확인하려면 Microsoft Exchange Server Jetstress 도구를 사용하는 것이 좋습니다. Jetstress 도구는 Jet라고도 하는 ESE와 직접 상호 작용하여 데이터베이스 수준에서 Exchange I/O 작업을 시뮬레이트하도록 디자인되었습니다. ESE는 Exchange에서 사서함 서버 역할에 대한 메시징 데이터를 저장할 때 사용하는 데이터베이스 기술입니다. Exchange에 요구되는 성능 제한 내에서 저장소 하위 시스템에 적용할 수 있는 최대 I/O 처리량을 테스트하도록 Jetstress를 구성할 수 있습니다. 또는 원하는 사용자 수 및 사용자별 IOPS의 대상 프로필을 허용하여 해당 저장소 하위 시스템이 대상 프로필로 적절한 성능 수준을 유지할 능력이 있는지 확인할 수 있습니다. 테스트 기간은 조정이 가능합니다. 적절한 성능을 확인할 때는 최소 시간 동안 실행할 수 있고, 저장소 하위 시스템의 안정성을 추가로 확인할 때는 장시간 실행할 수 있습니다.
Jetstress 도구는 다음 위치의 Microsoft 다운로드 센터에서 구할 수 있습니다.
Jetstress 설치 관리자에 포함된 설명서에 서버 하드웨어에서 Jetstress 유효성 검사 테스트를 구성하고 실행하는 방법이 설명되어 있습니다.
저장소 유효성 검사 방식
저장소 구성에는 두 가지 주요 유형이 있습니다.
DAS 또는 내부 디스크 시나리오
SAN 시나리오
DAS 또는 내부 디스크 시나리오에는 디스크 하위 시스템에 액세스하는 서버가 하나뿐이므로 저장소 하위 시스템의 성능에 대해 별도로 유효성 검사를 수행할 수 있습니다.
SAN 시나리오에서는 솔루션에 사용된 저장소를 여러 서버에서 공유할 수 있고 서버를 저장소에 연결하는 인프라가 공유된 의존 관계일 수도 있습니다. 이렇게 하려면 추가 테스트가 필요합니다. 성능과 기능의 유효성을 검사하려면 공유된 인프라의 다른 서버에 대한 영향을 충분히 시뮬레이트해야 하기 때문입니다.
저장소 유효성 검사에 대한 테스트 사례
다음의 저장소 유효성 검사 테스트 사례가 솔루션에 대해 실행되었으므로 저장소 유효 검사에 대한 시작 지점으로 이를 고려해야 합니다. 특정 배포에 추가 테스트를 충족할 수 있는 다른 유효성 검사 요구 사항이 있을 수 있으므로 이 목록은 완전하지 않습니다.
최악의 데이터베이스 전환 시나리오의 유효성 검사 이 테스트 사례에서는 I/O 수준이 최악의 전환 시나리오(가장 적은 수의 서버에 가장 많은 수의 활성 복사본이 있음)의 저장소 하위 시스템에서 처리됩니다. 저장소 하위 시스템이 DAS인지 SAN인지에 따라 저장소 하위 시스템에서 종단 간 솔루션 부하를 유지할 수 있는지 확인하기 위해 이 테스트를 여러 호스트에서 실행해야 할 수 있습니다.
저장소 오류 및 복구 시나리오에서 저장소 성능의 유효성 검사(예: 실패한 디스크 교체 및 다시 빌드) 이 테스트 사례에서는 오류 및 다시 빌드 시나리오 중에 저장소 하위 시스템의 성능을 평가하여 최적의 Exchange 클라이언트 환경에 맞게 필요한 성능 수준이 유지 관리되는지 확인합니다. DAS와 SAN 배포에 같은 경고가 적용됩니다. 여러 호스트가 공유 저장소 하위 시스템에 의존하는 경우 테스트에 이러한 호스트의 부하를 포함하여 오류 및 다시 빌드에 대한 전체 효과를 시뮬레이트해야 합니다.
결과 분석
Jetstress 도구는 각 테스트를 완료한 후 보고서 파일을 생성합니다. 보고서를 쉽게 분석하려면 Jetstress 2010 Test Summary Reports의 지침을 사용합니다.
특히, 보고서의 테스트 결과 표에 있는 데이터를 검사할 때 아래 표에 있는 지침을 사용해야 합니다.
Jetstress 결과 분석
| 성능 카운터 인스턴스 | 성능 테스트 지침 |
|---|---|
I/O 데이터베이스 읽기 평균 대기 시간(밀리초) |
평균값은 20밀리초(0.020초)보다 작아야 하고 최대값은 50밀리초보다 작아야 합니다. |
I/O 로그 쓰기 평균 대기 시간(밀리초) |
로그 디스크 쓰기는 순차적이므로 평균 쓰기 대기 시간은 10밀리초보다 작아야 하며, 최대값은 50밀리초보다 작아야 합니다. |
% Processor Time |
평균은 80%보다 작아야 하고 최대값은 90%보다 작아야 합니다. |
용도를 변경한 전환 페이지 수/초(Windows Server 2003, Windows Server 2008, Windows Server 2008 R2) |
평균은 100보다 작아야 합니다. |
보고서 파일에는 Exchange 시스템에서 수행한 여러 가지 I/O 범주가 표시됩니다.
트랜잭션 I/O 성능 이 표는 데이터베이스에 대해 사용자 작업을 나타내는 I/O를 보고합니다(예: Outlook 생성 I/O). 이 데이터는 테스트 중에 측정한 총 I/O에서 백그라운드 유지 관리 I/O와 로그 복제 I/O를 뺀 값으로 생성됩니다. 이 데이터는 Jetstress 성능 테스트 통과 또는 실패 여부를 확인하는 데 필요한 I/O 대기 시간 측정과 함께 생성된 실제 데이터베이스 IOPS를 제공합니다.
백그라운드 데이터베이스 유지 관리 I/O 성능 이 표는 진행 중인 ESE 데이터베이스 백그라운드 유지 관리로 인해 생성된 I/O를 보고합니다.
로그 복제 I/O 성능 이 표는 시뮬레이트된 로그 복제에서 생성된 I/O를 보고합니다.
총 I/O 성능 이 표는 Jetstress 테스트 중에 생성된 총 I/O를 보고합니다.
Exchange 2010 테스트 솔루션
서버 디자인 유효성 검사
저장소 하위 시스템의 성능 및 안정성에 대한 유효성을 검사한 후에 메시징 시스템에서 기능, 성능 및 확장성에 대해 모든 구성 요소의 유효성을 검사합니다. 즉, 스택에서 위로 이동하여 Exchange 제품과의 클라이언트 소프트웨어 상호 작용에 대한 유효성과 Exchange와 상호 작용하는 서버 측 제품의 유효성을 검사합니다. 종단 간 클라이언트 환경이 허용되는지, 전체 솔루션이 원하는 사용자 부하를 견딜 수 있는지 확인하려면 서버 디자인 유효성 검사에 대해 이 섹션에서 설명한 방법을 적용할 수 있습니다.
도구 집합
종단 간 솔루션 성능 및 확장성의 유효성을 검사하려면 Microsoft Exchange Server Load Generator 도구(Loadgen)를 사용하는 것이 좋습니다. Loadgen은 Exchange 배포에 대해 시뮬레이트된 클라이언트 작업을 생성하도록 디자인되었습니다. 이 작업은 Exchange 시스템의 성능을 평가하는 데 사용할 수 있고, 시스템에 부하가 걸린 상태에서 전반적인 솔루션의 여러 가지 구성 변경을 시도하여 그 영향을 평가하는 데에도 사용할 수 있습니다. Loadgen은 Microsoft Office Outlook 2007(온라인 및 캐시됨), Office Outlook 2003(온라인 및 캐시됨), POP3, IMAP4, SMTP, ActiveSync 및 Outlook Web App(Exchange 2007 및 이전 버전에서 Outlook Web Access라고도 함) 클라이언트 작업을 시뮬레이트할 수 있습니다. LoadGen은 단일 프로토콜 작업을 생성하는 데 사용할 수 있으며, 이런 클라이언트 프로토콜을 결합하여 다중 프로토콜 작업을 생성할 수 있습니다.
Loadgen 도구는 다음 위치의 Microsoft 다운로드 센터에서 구할 수 있습니다.
Loadgen 설치 관리자에 포함된 설명서에 Exchange 배포에 대해 Loadgen 테스트를 구성하고 실행하는 방법이 설명되어 있습니다.
서버 유효성 검사 방식
서버 디자인의 유효성을 검사할 때 작업이 가장 많을 것으로 예상되는 상황에서 최악의 시나리오를 테스트합니다. Microsoft IT 및 기타 고객의 데이터 집합 수를 기준으로 할 때 최고 부하는 일반적으로 근무일 나머지 시간 평균 작업의 2배입니다. 이것을 최고 작업 대 평균 작업 비율이라고 합니다.
성능 모니터
프로덕션 사서함 서버의 시간별 Exchange 작업 수행 시간을 나타내는 여러 가지 카운터를 표시하는 이 성능 모니터 스냅숏에서 하루 전체에 대한 평균을 계산할 때 초당 RPC 작업에 대한 평균값은 약 2,386입니다. 10시부터 11시까지 최대 사용 시간 동안 이 카운터의 평균은 약 4,971이며, 최고 작업 대 평균 작업 비율은 2.08입니다.
Exchange 솔루션이 최대 평균 처리 중에 생성된 작업을 지속할 수 있는지 확인하려면 시뮬레이트한 전체 근무일에 작업을 분배하지 않고 최대 평균 수준에서 작업 양을 생성하도록 Loadgen 설정을 수정합니다. Loadgen 작업 기반 시뮬레이션 모듈(Outlook 시뮬레이션 모듈과 유사)은 시뮬레이트한 날에 평균 사용자에 대해 각 작업이 발생할 횟수를 정의한 작업 프로필을 사용합니다.
시뮬레이트한 날에 실행해야 하는 총 작업 수는 구성된 작업 프로필에서 작업 수의 합계에 사용자 수를 곱하여 계산됩니다. 그런 다음 Loadgen은 시뮬레이트한 해당 날에 실행할 총 작업 수를 시뮬레이트한 기간으로 나누어 구성된 사용자 세트에 대해 작업을 실행해야 하는 비율을 결정합니다. 예를 들어 Loadgen이 시뮬레이트한 날에 1,000,000개의 작업을 실행해야 하며 시뮬레이트한 기간이 8시간(28,800초)이면 Loadgen이 초당 1,000,000 ÷ 28,800 = 34.72 작업을 실행하여 필요한 작업 정의를 충족해야 합니다. 부하 양을 원하는 최고 평균으로 늘리려면 기본 시뮬레이트한 기간(8시간)을 최고 작업 대 평균 작업 비율(2)로 나누고 이 값을 새로 시뮬레이트한 기간으로 사용합니다.
작업 속도 예인 초당 1,000,000 ÷ 14,400 = 69.44 작업을 다시 사용합니다. 이렇게 하면 시뮬레이트한 기간을 절반까지 줄일 수 있고 이로 인해 서버에 실행한 실제 작업은 두 배가 되어 최고 평균 작업 목표를 달성할 수 있습니다. Loadgen 구성에서는 테스트 실행 기간을 조정하지 않습니다. 이 실행 기간은 테스트 기간을 지정하는 것으로, Exchange 서버에 대해 작업이 실행되는 속도에 영향을 주지 않습니다.
서버 디자인 유효성 검사에 대한 테스트 사례
솔루션에 대해 다음 서버 디자인 유효성 검사 테스트 사례가 실행되었으므로 이를 서버 디자인 유효 검사에 대한 시작 지점으로 고려해야 합니다. 특정 배포에 추가 테스트를 충족할 수 있는 다른 유효성 검사 요구 사항이 있을 수 있으므로 이 목록은 완전하지 않습니다.
일반적인 작동 조건 이 테스트 사례에서 솔루션의 기본 디자인은 해당하는 일반 작동 상태에서 모든 구성 요소에 유효합니다(오류는 시뮬레이트하지 않음). 솔루션에 대해 원하는 작업이 생성되고 다음에 오는 메트릭을 기준으로 전반적인 솔루션 성능에 대해 유효성 검사가 수행됩니다.
단일 서버 오류 또는 단일 서버 유지 관리(사이트 내) 이 테스트 사례에서는 단일 서버를 분해하여 서버의 예상 오류 또는 서버에 대해 계획한 유지 관리 작업을 시뮬레이트합니다. 사용할 수 없는 서버에서 정상적으로 처리한 작업이 이제 솔루션 토폴로지에 있는 다른 서버에 의해 처리되며 전반적인 솔루션 성능에 대해 유효성 검사가 수행됩니다.
테스트 실행 및 데이터 수집
Exchange 성능 데이터는 테스트가 실행될 때 그리고 테스트가 실행되는 사이에 변형됩니다. 평균적으로 여러 번 실행하여 이러한 변형을 완화하는 것이 좋습니다. Exchange 테스트 솔루션의 경우 8시간 동안 최소 세 개의 별도 테스트를 완료했습니다. 테스트의 전체 8시간 동안 성능 데이터를 수집했습니다. 3-4시간의 안정적인 기간에서 성능 요약 데이터를 가져왔습니다(테스트의 처음 두 시간과 마지막 한 시간 제외). 각 Exchange 서버 역할에서 각 테스트 실행에 대해 서버 간 평균을 냈고, 이는 각 데이터 요소에 대해 단일 평균값을 제공합니다. 그런 다음 각 실행의 값으로 평균을 내어 모든 테스트 실행에서 같은 서버 역할을 가진 모든 서버에 단일 데이터 요소를 제공합니다.
예상된 부하의 유효성 검사
성능 카운터를 확인하거나 성능 유효성 검사 분석을 시작하기 전에 실행하려고 했던 작업이 실제로 실행한 작업과 일치하는지 확인합니다. 시뮬레이트된 작업이 예상 작업과 일치했는지 확인하는 방법에는 여러 가지가 있지만 가장 쉽고 일관된 방법은 메시지 배달 속도를 확인하는 것입니다.
예상 최대 부하 메시지 배달 속도 계산
모든 메시지 프로필은 하루에 보낸 평균 메시지 수와 하루에 받은 평균 메시지 수의 합계로 구성됩니다. 메시지 배달 속도를 계산하려면 다음 표에서 일별로 받은 평균 메시지 수를 선택합니다.
최대 부하 메시지 배달 속도
| 메시지 프로필 | 하루에 보낸 메시지 수 | 하루에 받은 메시지 수 |
|---|---|---|
50 |
10 |
40 |
100 |
20 |
80 |
150 |
30 |
120 |
200 |
40 |
160 |
다음 예에서는 각 사서함 서버에 하루에 150개의 메시지 프로필이 있는 5,000개의 활성 사서함이 있다고 가정합니다(하루에 30개의 메시지를 보내고 120개의 메시지를 받음).
5,000개의 활성 사서함에 대한 최대 부하 메시지 배달 속도
| 설명 | 계산 | 값 |
|---|---|---|
메시지 프로필 |
하루에 받은 메시지 수 |
120 |
사서함 서버당 활성 사서함 수 |
해당 없음 |
5000 |
사서함 서버당 하루에 받은 총 메시지 수 |
5000 × 120 |
600000 |
사서함 서버별로 초당 받은 총 메시지 수 |
600000 ÷ 28800 |
20.83 |
최대 부하에 대해 조정된 총 메시지 수 |
20.83 × 2 |
41.67 |
최대 부하 중 일일 메시지 수 150개의 메시지 프로필이 있는 5,000개의 활성 사서함을 실행 중인 각 사서함 서버에 배달되는 초당 예상 메시지 수는 41.67개입니다.
실제 메시지 배달 속도 측정
각 사서함 서버에서 다음 카운터를 사용하여 실제 메시지 배달 속도를 측정할 수 있습니다. MSExchangeIS Mailbox(_Total)\Messages Delivered/sec. 측정한 메시지 배달 속도가 초당 1-2개 이내의 메시지인 경우 원하는 부하 프로필이 성공적으로 실행되었음을 확신할 수 있습니다.
서버 유효성 검사: 성능 및 상태 조건
이 섹션에서는 Exchange 환경이 적절하게 크기가 조정되었고 장기간의 최고 작업 중에 정상적인 상태에서 실행할 수 있는지를 판단하는 데 사용된 성능 모니터 카운터 및 임계값을 설명합니다. Exchange 성능 관련 카운터에 대한 자세한 내용은 성능 및 확장성 카운터 및 임계값을 참조하십시오.
Hyper-V 루트 서버
Hyper-V 루트 서버의 성능과 상태 조건 및 VM 내에서 실행 중인 응용 프로그램의 유효성을 검사하려면 Hyper-V 아키텍처 및 성능 모니터링에 영향을 주는 방식에 대한 기본적인 개념을 알고 있어야 합니다.
Hyper-V의 세 가지 주요 구성 요소는 가상화 스택, 하이퍼바이저 및 장치입니다. 가상화 스택은 에뮬레이트된 장치를 처리하고, VM을 관리하고, I/O를 처리합니다. 하이퍼바이저는 가상 프로세서를 예약하고, 인터럽트를 관리하고, 타이머를 처리하고, 다른 칩 수준의 기능을 제어합니다. 하이퍼바이저는 장치 또는 I/O를 처리하지 않습니다(예: 하이퍼바이저 드라이버가 없음). 장치는 루트 서버의 일부이거나, 통합 서비스의 일부로 게스트 서버에 설치됩니다. 루트 서버는 시스템 전체 보기 기능을 가지고 있고 VM을 제어하므로 WMI(Windows Management Instrumentation) 및 성능 카운터를 통해 모니터링 정보를 제공합니다.
프로세서
루트 서버에서(또는 게스트 VM 내에서) 실제 프로세서 사용률의 유효성을 검사할 때 표준 Processor\% Processor Time 카운터는 별로 유용하지 않습니다.
대신 Hyper-V Hypervisor Logical Processor\% Total Run Time 카운터를 검사할 수 있습니다. 이 카운터는 게스트 및 하이퍼바이저 런타임에 소요된 프로세서 시간 비율을 표시하므로 루트 서버에서 실행 중인 하이퍼바이저 및 모든 VM에 대한 총 프로세서 사용률을 측정하는 데 사용해야 합니다. 이 카운터는 80% 또는 디자인한 최대 사용률 대상을 초과하지 않아야 합니다.
| 카운터 | 대상 |
|---|---|
Hyper-V Hypervisor Logical Processor\% Total Run Time |
<80% |
게스트 VM을 처리하는 데 소요된 프로세서 시간 비율을 계산하려는 경우 Hyper-V Hypervisor Logical Processor\% Guest Run Time 카운터를 검사할 수 있습니다. 하이퍼바이저에 소요된 프로세서 시간 비율을 계산하려는 경우 Hyper-V Hypervisor Logical Processor\% Hypervisor Run Time 카운터를 검사할 수 있습니다. 이 카운터는 5% 미만이어야 합니다. Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time 카운터는 가상화 스택에 소요된 프로세서 시간의 비율을 표시합니다. 이 카운터 또한 5% 미만이어야 합니다. 이 두 카운터는 가상화를 지원하는 데 사용 중인 사용 가능한 실제 프로세서 시간 비율을 확인하는 데 사용할 수 있습니다.
| 카운터 | 대상 |
|---|---|
Hyper-V Hypervisor Logical Processor\% Guest Run Time |
<80% |
Hyper-V Hypervisor Logical Processor\% Hypervisor Run Time |
<5% |
Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time |
<5% |
메모리
Hyper-V 루트 서버에 VM에 할당된 메모리를 지원할 만큼 충분한 메모리가 있는지 확인해야 합니다. Hyper-V는 루트 운영 체제에 대해 자동으로 512MB를 예약합니다(이 크기는 Hyper-V 릴리스마다 다를 수 있음). 메모리가 부족할 경우 Hyper-V는 마지막 VM이 시작되지 않게 합니다. 일반적으로 Hyper-V 루트 서버의 메모리 유효성 검사에 대해서는 걱정하지 않아도 됩니다. Exchange 역할을 지원할 충분한 메모리를 VM에 할당했는지만 확인하면 됩니다.
응용 프로그램 상태
모든 VM이 올바른 상태에 있는지 확인하는 간단한 방법은 Hyper-V Virtual Machine Health Summary 카운터를 살펴보는 것입니다.
| 카운터 | 대상 |
|---|---|
Hyper-V Virtual Machine Health Summary\Health OK |
1 |
Hyper-V Virtual Machine Health Summary\Health Critical |
0 |
사서함 서버
사서함 서버 크기가 올바르게 지정되었는지 확인할 때에는 프로세서, 메모리, 저장소 및 Exchange 응용 프로그램 상태에 집중하십시오. 이 섹션에서는 이러한 각 구성 요소의 유효성 검사 방식에 대해 설명합니다.
프로세서
디자인 프로세스 중에 서버나 프로세서 플랫폼에 대해 조정된 메가사이클 용량을 계산했습니다. 그런 다음 사용 가능한 메가사이클 용량의 80%를 초과하지 않은 채 서버에서 지원할 수 있는 최대 활성 사서함 수를 결정했습니다. 또한 일반 작업 조건 및 여러 서버 유지 관리 또는 오류 시나리오에서 계획한 CPU 사용률을 결정했습니다.
확인 과정에서 최악의 시나리오 작업이 사용 가능한 메가사이클 수의 80%를 초과하지 않았는지 확인합니다. 실제 CPU 사용률이 일반 작업 조건 및 여러 서버 유지 관리 또는 오류 시나리오에서 예상한 CPU 사용률에 근접한지도 확인해야 합니다.
실제 Exchange 배포에서는 Processor(_Total)\% Processor Time 카운터를 사용하고 이 카운터가 평균 80% 미만인지 확인합니다.
| 카운터 | 대상 |
|---|---|
Processor(_Total)\% Processor Time |
<80% |
가상 Exchange 배포에서는 Processor(_Total)\% Processor Time 카운터가 VM 내에서 측정됩니다. 이 경우 카운터는 실제 CPU 사용률을 측정하지 않습니다. 하이퍼바이저에서 제공한 가상 CPU 사용률을 측정합니다. 따라서 이 카운터는 실제 프로세서의 정확한 읽기를 제공하지 않으므로 디자인 유효성 검사 목적으로 사용해서는 안 됩니다. 자세한 내용은 Hyper-V: 클록 배치... 어떤 성능 카운터를 신뢰할 수 있습니까?를 참조하십시오.
Microsoft Hyper-V에서 실행 중인 Exchange 배포 유효성을 검사하려면 Hyper-V Hypervisor Virtual Processor\% Guest Run Time 카운터를 사용합니다. 이 카운터는 게스트 운영 체제에서 사용하는 실제 CPU 양에 대한 정확한 값을 제공합니다. 이 카운터는 평균 80% 미만이어야 합니다.
| 카운터 | 대상 |
|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
메모리
디자인 프로세스 중에 각 사서함 서버에서 최대 활성 데이터베이스 수를 지원하는 데 필요한 데이터베이스 캐시 크기를 계산했습니다. 그런 다음 데이터베이스 캐시와 시스템 메모리 요구 사항을 지원하기 위한 최적의 실제 메모리 구성을 결정했습니다.
Exchange 사서함 서버에 대상 작업을 지원할 충분한 메모리가 있는지에 대한 유효성 검사는 간단한 작업이 아닙니다. Exchange의 메모리 관리자는 사용 가능한 실제 메모리를 거의 모두 사용하도록 디자인되었기 때문에 사용 가능한 메모리 카운터를 사용하여 남아 있는 실제 메모리를 보는 것은 도움이 되지 않습니다. 정보 저장소(store.exe)는 데이터베이스 캐시에 대해 실제 메모리의 많은 부분을 예약합니다. 데이터베이스 캐시는 데이터베이스 페이지를 메모리에 저장하는 데 사용됩니다. 메모리에서 페이지에 액세스하는 경우 디스크에서 정보를 검색하여 읽기 I/O를 줄이지 않아도 됩니다. 데이터베이스 캐시는 쓰기 I/O를 최적화하는 데에도 사용됩니다.
데이터베이스 페이지를 수정하면(더티 페이지라고 함) 해당 페이지가 일정 기간 동안 캐시에 남아 있습니다. 캐시에 남아 있는 기간이 길수록 그러한 변경 사항을 디스크에 쓰기 전에 페이지를 여러 번 수정할 수 있는 기회가 많아집니다. 더티 페이지를 캐시에 보관하면 동일한 작업에서 여러 페이지가 디스크에 기록됩니다(쓰기 병합이라고 함). Exchange는 시스템에서 사용 가능한 메모리를 가능한 한 많이 사용합니다. 따라서 Exchange 사서함 서버에는 사용 가능한 메모리가 많지 않습니다.
Exchange 사서함 서버의 메모리 구성이 부족한지를 파악하기가 어려울 수 있습니다. 대부분의 경우 사서함 서버 기능이 작동하지만 I/O 프로필이 예상보다 훨씬 높을 수 있습니다. I/O가 높을수록 디스크 읽기 및 쓰기 지연이 높아질 수 있으며 이로 인해 응용 프로그램 상태 및 클라이언트 사용자 환경에 영향을 줄 수 있습니다. 결과 섹션에 메모리 카운터에 대한 참조가 없습니다. 잠재적인 메모리 문제는 저장소 유효성 검사 및 응용 프로그램 상태 결과 섹션에서 확인할 수 있고, 이 섹션에서 메모리 관련 문제를 쉽게 탐색할 수 있습니다.
저장소
Exchange 사서함 서버에 성능 문제가 있다면 그러한 문제는 저장소 관련 문제일 수 있습니다. 저장소 문제는 앞에서 설명했듯이 대상 I/O 요구 사항을 지원할 충분한 디스크가 없거나, 저장소 연결 인프라가 오버로드되었거나 제대로 디자인되지 않았거나, 메모리 부족과 같은 대상 I/O 프로필을 변경하는 요소로 인해 발생할 수 있습니다.
저장소 유효성 검사의 첫 단계는 데이터베이스 지연이 대상 임계값보다 낮은지 확인하는 것입니다. 이전 릴리스에서는 논리 디스크 카운터가 디스크 읽기 및 쓰기 대기 시간을 결정했습니다. Exchange 2010에서는 모니터링하는 Exchange 사서함 서버에 활성 및 수동 사서함 데이터베이스 복사본 조합이 있을 수 있습니다. 활성 및 수동 데이터베이스 복사본의 I/O 특성은 다릅니다. I/O의 크기가 수동 복사본에서 훨씬 크기 때문에 일반적으로 수동 복사본에서 대기 시간이 훨씬 높습니다. 수동 데이터베이스에 대한 대기 시간 목표는 200밀리초인데, 이는 활성 데이터베이스 복사본의 목표보다 10배 높습니다. 수동 데이터베이스의 높은 대시 시간은 클라이언트 환경에 영향을 주지 않으므로 이것은 문제가 되지 않습니다. 하지만 기존의 논리 디스크 카운터를 사용하여 대기 시간을 측정하려는 경우에는 개별 볼륨을 검토하고 활성 및 수동 데이터베이스가 포함된 볼륨을 분리해야 합니다. 대신 Exchange 2010의 새 MSExchange Database 카운터를 사용하는 것이 좋습니다.
Exchange 2010 사서함 서버에서 대기 시간의 유효성을 검사할 경우 활성 데이터베이스에는 다음 표에 있는 카운터를 사용하는 것이 좋습니다.
| 카운터 | 대상 |
|---|---|
MSExchange Database\I/O Database Reads (Attached) Average Latency |
<20밀리초 |
MSExchange Database\I/O Database Writes (Attached) Average Latency |
<20밀리초 |
MSExchange Database\IO Log Writes Average Latency |
<1밀리초 |
수동 데이터베이스에는 다음 표에 있는 카운터를 사용하는 것이 좋습니다.
| 카운터 | 대상 |
|---|---|
MSExchange Database\I/O Database Reads (Recovery) Average Latency |
<200밀리초 |
MSExchange Database\I/O Database Writes (Recovery) Average Latency |
<200밀리초 |
MSExchange Database\IO Log Read Average Latency |
<200밀리초 |
참고
성능 모니터에서 이러한 카운터를 보려면 고급 데이터베이스 카운터를 사용해야 합니다. 자세한 내용은 확장된 ESE 성능 카운터 사용 설정 방법을 참조하십시오.
Microsoft Hyper-V에서 실행 중인 Exchange 배포에 대한 디스크 대기 시간의 유효성을 검사할 때 I/O Database Average Latency 카운터(여러 번 실행 기반 카운터)가 정확하지 않을 수도 있습니다. VM 내에서 시간 개념이 실제 서버에서와 다르기 때문입니다. 다음 예에서는 시뮬레이트된 같은 작업에 대해 I/O 데이터베이스 읽기(첨부) 평균 대기 시간이 VM에서 22.8이고, 실제 서버에서 17.3임을 보여줍니다. 시간 기반 카운터 값이 대상 임계값을 초과하면 서버가 올바르게 실행되고 있는 것입니다. 사서함 서버 역할이 VM 내에 배포된 경우 서버 상태에 관계없이 모든 상태 조건을 검토하여 결정합니다.
가상 및 실제 사서함 서버에 대한 디스크 대기 시간 카운터의 값
| 카운터 | 가상 사서함 서버 | 실제 사서함 서버 |
|---|---|---|
MSExchange Database/ |
||
I/O Database Reads (Attached) / Average Latency |
22.792 |
17.250 |
I/O Database Reads (Attached) / sec |
17.693 |
18.131 |
I/O Database Reads (Recovery) / Average Latency |
34.215 |
27.758 |
I/O Database Writes (Recovery) / sec |
10.829 |
8.483 |
I/O Database Writes (Attached) / Average Latency |
0.944 |
0.411 |
I/O Database Writes (Attached) / sec |
10.184 |
10.963 |
MSExchangeIS |
||
RPC Averaged Latency |
1.966 |
1.695 |
RPC Operations/sec |
334.371 |
341.139 |
RPC Packets / sec |
180.656 |
183.360 |
MSExchangeIS Mailbox |
||
Messages Delivered / sec |
2.062 |
2.065 |
Messages Sent / sec |
0.511 |
0.514 |
디스크 대기 시간 외에 Database\Database Page Fault Stalls/sec 카운터를 검토합니다. 데이터베이스 캐시에서 할당에 사용할 수 있는 페이지가 없기 때문에 이 카운터는 서비스할 수 없는 페이지 오류의 비율을 나타냅니다. 이 카운터는 정상적인 서버에서 0이어야 합니다.
| 카운터 | 대상 |
|---|---|
Database\Database Page Fault Stalls/sec |
<1 |
또한, Database\Log Record Stalls/sec 카운터를 검토합니다. 이 카운터는 로그 버퍼가 꽉 찼기 때문에 초당 로그 버퍼에 추가할 수 없는 로그 레코드 수를 나타냅니다. 이 카운터는 평균적으로 10보다 작아야 합니다.
| 카운터 | 대상 |
|---|---|
Database\Log Record Stalls/sec |
<10 |
Exchange 응용 프로그램 상태
프로세서, 메모리 및 디스크에 명백한 문제가 없어도 표준 응용 프로그램 상태 카운터를 모니터링하여 Exchange 사서함 서버 상태가 정상인지 확인해야 합니다.
MSExchangeIS\RPC Averaged Latency 카운터는 데이터베이스 대기 시간이 높은 다른 카운터가 실제로 Exchange 상태와 클라이언트 환경에 영향을 미치는지 여부를 가장 잘 나타냅니다. 주로 RPC 평균 대기 시간이 높은 것은 RPC 요청 수가 많기 때문입니다. 이 요청 수는 항상 70보다 작아야 합니다.
| 카운터 | 대상 |
|---|---|
MSExchangeIS\RPC Averaged Latency |
평균 <10밀리초 |
MSExchangeIS\RPC Requests |
항상 <70 |
그런 다음 전송 계층이 정상인지 확인합니다. 전송 문제 또는 전송 계층에 영향을 주는 전송 다운스트림 문제는 MSExchangeIS Mailbox(_Total)\Messages Queued for Submission 카운터로 감지될 수 있습니다. 이 카운터는 항상 50보다 작아야 합니다. 이 카운터가 임시로 늘어날 수는 있지만 시간이 지남에 따라 카운터 값이 커지지 않아야 하며, 15분 넘게 지속되어서도 안 됩니다.
| 카운터 | 대상 |
|---|---|
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
항상 <50 |
그런 다음 데이터베이스 복사본의 유지 관리 상태가 정상인지 확인합니다. 로그 전달 또는 로그 재생 문제는 MSExchange Replication(*)\CopyQueueLength 및 MSExchange Replication(*)\ReplayQueueLength 카운터를 사용하여 식별할 수 있습니다. 복사 큐 길이는 수동 복사본 로그 파일 폴더에 복사 대기 중인 트랜잭션 로그 파일 수를 나타내며, 항상 1보다 작아야 합니다. 재생 큐 길이는 수동 복사본으로 재생 대기 중인 트랜잭션 로그 파일 수를 나타내며, 5보다 작아야 합니다. 값이 클수록 클라이언트 환경에 영향을 미치지 않지만 전달, 장애 조치(failover) 또는 활성화를 수행할 때 저장소 탑재 시간이 오래 걸립니다.
| 카운터 | 대상 |
|---|---|
MSExchange Replication(*)\CopyQueueLength |
<1 |
MSExchange Replication(*)\ReplayQueueLength |
<5 |
클라이언트 액세스 서버
클라이언트 액세스 서버 상태가 정상인지 확인하려면 프로세서, 메모리 및 응용 프로그램 상태를 검토합니다. 중요한 카운터의 확장 목록은 클라이언트 액세스 서버 카운터를 참조하십시오.
프로세서
실제 Exchange 배포에는 Processor(_Total)\% Processor Time 카운터를 사용합니다. 이 카운터는 평균 80% 미만이어야 합니다.
| 카운터 | 대상 |
|---|---|
Processor(_Total)\% Processor Time |
<80% |
Microsoft Hyper-V에서 실행 중인 Exchange 배포 유효성을 검사하려면 Hyper-V Hypervisor Virtual Processor\% Guest Run Time 카운터를 사용합니다. 이 카운터는 게스트 운영 체제에서 사용하는 실제 CPU 양에 대한 정확한 값을 제공합니다. 이 카운터는 평균 80% 미만이어야 합니다.
| 카운터 | 대상 |
|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
응용 프로그램 상태
MAPI 클라이언트 환경을 허용할 수 있는지 확인하려면 MSExchange RpcClientAccess\RPC Averaged Latency 카운터를 사용합니다. 이 카운터는 250밀리초 이하여야 합니다. 대기 시간이 높은 것은 RPC 요청 수가 많기 때문입니다. MSExchange RpcClientAccess\RPC Requests 카운터는 평균적으로 40 미만이어야 합니다.
| 카운터 | 대상 |
|---|---|
MSExchange RpcClientAccess\RPC Averaged Latency |
<250밀리초 |
MSExchange RpcClientAccess\RPC Requests |
<40 |
전송 서버
전송 서버가 정상인지 확인하려면 프로세서, 디스크 및 응용 프로그램 상태를 검토합니다. 중요한 카운터의 확장 목록은 전송 서버 카운터를 참조하십시오.
프로세서
실제 Exchange 배포에는 Processor(_Total)\% Processor Time 카운터를 사용합니다. 이 카운터는 평균 80% 미만이어야 합니다.
| 카운터 | 대상 |
|---|---|
Processor(_Total)\% Processor Time |
<80% |
Microsoft Hyper-V에서 실행 중인 Exchange 배포 유효성을 검사하려면 Hyper-V Hypervisor Virtual Processor\% Guest Run Time 카운터를 사용합니다. 이 카운터는 게스트 운영 체제에서 사용하는 실제 CPU 양에 대한 정확한 값을 제공합니다. 이 카운터는 평균 80% 미만이어야 합니다.
| 카운터 | 대상 |
|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
디스크
디스크 성능을 사용할 수 있는지 확인하려면 Logical Disk(*)\Avg를 사용합니다. 전송 로그 및 데이터베이스가 포함된 볼륨에 대한 Disk sec/Read 및 Write 카운터입니다. 이 두 카운터 모두 20밀리초 미만이어야 합니다.
| 카운터 | 대상 |
|---|---|
Logical Disk(*)\Avg. Disk sec/Read |
<20밀리초 |
Logical Disk(*)\Avg. Disk sec/Write |
<20밀리초 |
응용 프로그램 상태
허브 전송 서버 크기가 적절한지 그리고 올바른 상태에서 실행 중인지 확인하려면 다음 표에 요약된 MSExchangeTransport Queues 카운터를 검토합니다. 이 모든 큐에는 다양한 시간의 메시지가 포함됩니다. 큐 길이가 유지되지 않는지, 시간이 지나면서 늘어나지 않는지 확인해야 합니다. 큐 길이가 커지면 허브 전송 서버가 오버로드되었음을 나타냅니다. 그렇지 않으면 네트워크 문제가 있거나 사서함 서버가 오버로드되어 새 메시지를 받을 수 없기 때문일 수 있습니다. 확인할 Exchange 환경의 다른 구성 요소를 점검해야 합니다.
| 카운터 | 대상 |
|---|---|
MSExchangeTransport Queues(_total)\Aggregate Delivery |
<3000 |
MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length |
<250 |
MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length |
<250 |
MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length |
<100 |
MSExchangeTransport Queues(_total)\Submission Queue Length |
<100 |
Exchange 2010 테스트 솔루션
기능 유효성 검사 테스트
기능 유효성 검사 테스트에 다음 섹션에 있는 정보를 사용할 수 있습니다.
Exchange 2010 테스트 솔루션
데이터베이스 전환 유효성 검사
데이터베이스 전환은 개별 활성 데이터베이스가 다른 데이터베이스 복사본(수동 복사본)으로 전환되는 프로세스이며, 해당 데이터베이스 복사본은 새 활성 데이터베이스 복사본이 됩니다. 데이터베이스 전환은 데이터 센터 내부와 전체에서 발생할 수 있습니다. 데이터베이스 전환은 EMC(Exchange 관리 콘솔) 또는 Exchange 관리 셸을 사용하여 수행할 수 있습니다.
데이터베이스의 수동 복사본을 다른 서버에서 활성화할 수 있는지 확인하려면 다음 명령을 실행합니다.
Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>
성공 조건: 활성 사서함 데이터베이스가 지정된 대상 서버에 탑재되어 있습니다. 이 결과는 다음 명령을 실행하여 확인할 수 있습니다.
Get-MailboxDatabaseCopyStatus <DatabaseName>
Exchange 2010 테스트 솔루션
서버 전환 유효성 검사
서버 전환은 DAG 구성원에 있는 모든 활성 데이터베이스를 하나 이상의 다른 DAG 구성원에서 활성화하는 프로세스입니다. 데이터베이스 전환과 마찬가지로 서버 전환은 데이터 센터 내부와 전체에서 발생할 수 있으며 EMC와 셸을 모두 사용하여 시작할 수 있습니다.
서버에 있는 데이터베이스의 모든 수동 복사본을, 수동 복사본을 호스트하는 다른 서버에서 활성화할 수 있는지 확인하려면 다음 명령을 실행합니다.
Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>성공 조건: 활성 사서함 데이터베이스가 지정된 대상 서버에 탑재되어 있습니다. 이 결과는 다음 명령을 실행하여 확인할 수 있습니다.
Get-MailboxDatabaseCopyStatus <DatabaseName>각 활성 데이터베이스의 복사본 하나가 데이터베이스의 수동 복사본을 호스트하는 다른 사서함 서버에서 활성화되는지 확인하려면 다음 작업을 수행하여 서버를 종료합니다.
현재 활성 서버 전원을 끕니다.
성공 조건: 활성 사서함 데이터베이스가 DAG의 다른 사서함 서버에 탑재되어 있습니다. 이 결과는 다음 명령을 실행하여 확인할 수 있습니다.
Get-MailboxDatabaseCopyStatus <DatabaseName>
Exchange 2010 테스트 솔루션
서버 장애 조치 유효성 검사
서버 장애 조치(failover)는 DAG 구성원이 MAPI 네트워크에 더 이상 서비스를 제공할 수 없거나 DAG 구성원의 클러스터 서비스가 나머지 DAG 구성원에 더 이상 연결할 수 없는 경우 발생합니다.
각 활성 데이터베이스의 복사본 하나가 데이터베이스의 수동 복사본을 호스트하는 다른 사서함 서버에서 활성화되는지 확인하려면 다음 작업을 수행하여 서버를 종료합니다.
서버 전원이 꺼질 때까지 서버에 있는 전원 단추를 길게 누릅니다.
서버에서 전원 케이블을 뽑으면 서버 전원이 꺼집니다.
성공 조건: 활성 사서함 데이터베이스가 DAG의 다른 사서함 서버에 탑재되어 있습니다. 이 결과는 다음 명령을 실행하여 확인할 수 있습니다.
Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus
Exchange 2010 테스트 솔루션
데이터 센터 전환 유효성 검사
데이터 센터나 사이트의 오류는 서버 또는 데이터베이스 장애 조치(failover)를 일으킬 수 있는 오류 유형과 다른 방식으로 관리합니다. 고가용성 구성에서는 시스템이 자동 복구를 시작하며 보통은 오류가 발생해도 메시징 시스템이 완전하게 작동하는 상태로 복구됩니다. 반면 데이터 센터 오류는 재해 복구 이벤트로 간주되며 클라이언트 서비스를 복원하여 중지 상태를 해결하려면 수동으로 복구를 수행해야 합니다. 이때 수행하는 프로세스를 데이터 센터 전환이라고 합니다. 다른 재해 복구 시나리오의 경우와 마찬가지로, 데이터 센터 전환을 사전에 계획하고 준비해 두면 복구 프로세스를 단순화하고 중지 기간을 단축할 수 있습니다.
데이터 센터 전환 수행 세부 단계를 비롯하여 자세한 내용은 데이터 센터 전환을 참조하십시오.
보조 데이터 센터를 활성화하기로 처음 결정한 후에 기본적으로 네 단계를 완료하여 데이터 센터 전환을 수행할 수 있습니다.
부분적으로 실행 중인(실패한) 데이터 센터를 종료합니다.
유효성을 검사하고 보조 데이터 센터에 대한 필수 구성 요소를 확인합니다.
사서함 서버를 활성화합니다.
클라이언트 액세스 서버를 활성화합니다.
다음 섹션에서는 데이터 센터 전환의 유효성을 검사하는 데 사용하는 단계를 설명합니다.
부분적으로 실패한 데이터 센터 종료(DAG가 DAC 모드에 있다고 가정)
DAG가 DAC 모드에 있는 경우 기본 데이터 센터에서 남아 있는 DAG 구성원을 종료하기 위한 특정 작업은 실패한 데이터 센터의 상태에 따라 다릅니다. 다음 중 하나를 수행합니다.
실패한 데이터 센터의 사서함 서버에 여전히 액세스할 수 있는 경우(일반적으로 해당되지 않음) 각 사서함 서버에서 다음 명령을 실행합니다.
Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>실패한 데이터 센터의 사서함 서버를 사용할 수 없지만 Active Directory가 기본 데이터 센터에서 작동 중이면 도메인 컨트롤러에서 다음 명령을 실행합니다.
Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
참고
실패한 데이터 센터의 사서함 서버를 끄지 못하거나 서버에 대해 Stop-DatabaseAvailabilityGroup 명령을 성공적으로 수행하지 못한 경우에는 두 데이터 센터 사이에 스플릿 브레인 현상이 나타날 수 있습니다. 이 요구 사항에 따라 전원 관리 장치를 통해 개별적으로 컴퓨터 전원을 꺼야 할 수도 있습니다.
성공 조건: 실패한 사이트의 모든 사서함 서버가 중지된 상태에 있습니다. 실패한 데이터 센터의 서버에서 다음 명령을 실행하여 이 상태를 확인할 수 있습니다.
Get-DatabaseAvailabilityGroup | Format-List
보조 데이터 센터에 대한 필수 구성 요소의 유효성 검사 및 확인
중지된 기본 데이터 센터가 표시되도록 보조 데이터 센터를 업데이트해야 합니다. 보조 데이터 센터의 서버에서 다음 명령을 실행합니다.
Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
이 단계의 목적은 서비스 복원에 사용할 수 있는 사서함 서버를 보조 데이터 센터의 서버에 알리는 것입니다.
성공 조건: 실패한 데이터 센터의 모든 사서함 서버가 중지된 상태에 있습니다. 이를 확인하려면 보조 데이터 센터의 서버에서 다음 명령을 실행합니다.
Get-DatabaseAvailabilityGroup | Format-List
사서함 서버 활성화(DAG가 DAC 모드에 있다고 가정)
보조 데이터 센터에서 DAG 구성원을 활성화하기 전에 보조 데이터 센터에 있는 인프라 서비스에서 메시징 서비스 활성화가 준비되었는지 확인하는 것이 좋습니다.
DAG가 DAC 모드에 있는 경우 보조 데이터 센터에서 사서함 서버 활성화를 완료하는 단계는 다음과 같습니다.
보조 데이터 센터의 각 DAG 구성원에서 클러스터 서비스를 중지합니다. Stop-Service cmdlet을 사용하여 서비스를 중지하거나(예: Stop-Service ClusSvc) 관리자 권한 명령 프롬프트에서 net stop clussvc를 사용할 수 있습니다.
보조 데이터 센터에서 사서함 서버를 활성화하려면 다음 명령을 실행합니다.
Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>이 명령이 성공하면 쿼럼 조건이 보조 데이터 센터에 있는 서버로 축소됩니다. 데이터 센터에 있는 서버의 수가 짝수인 경우 DAG는 DAG 개체의 설정을 통해 식별된 대체 미러링 모니터 서버를 사용하도록 전환됩니다.
데이터베이스를 활성화하려면 다음 명령 중 하나를 실행합니다.
Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>또는
Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>이벤트 로그를 확인하고 모든 오류 및 경고 메시지를 검토하여 보조 사이트 상태가 정상인지 확인합니다. 데이터베이스를 탑재하기 전에 표시된 문제를 추적하여 수정해야 합니다.
데이터베이스를 탑재하려면 다음 명령을 실행합니다.
Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database
성공 조건: 활성 사서함 데이터베이스가 보조 사이트의 사서함 서버에 탑재되어 있습니다. 확인하려면 다음 명령을 실행합니다.
Get-MailboxDatabaseCopyStatus <DatabaseName>
클라이언트 액세스 서버 활성화
클라이언트는 서비스 끝점에 연결하여 Exchange 서비스 및 데이터에 액세스합니다. 따라서 인터넷에 연결된 클라이언트 액세스 서버를 활성화하면서 새 서비스 끝점에 대해 구성할 새 IP 주소를 가리키도록 DNS 레코드를 변경해야 합니다. 그러면 클라이언트는 두 가지 방법 중 하나를 통해 새 서비스 끝점에 자동으로 연결합니다.
클라이언트는 계속 연결을 시도하며 원래 DNS 항목에 대해 TTL(Time to Live)이 만료되고 그 항목이 클라이언트의 DNS 캐시에서 만료된 후에 자동으로 연결되어야 합니다. 사용자가 명령 프롬프트에서 ipconfig /flushdns 명령을 실행하여 수동으로 DNS 캐시를 지울 수도 있습니다. Outlook Web App를 사용하는 경우 웹 브라우저를 닫고 다시 시작하여 브라우저에서 사용한 DNS 캐시를 지워야 할 수 있습니다. Exchange 2010 SP1에서 이 브라우저 캐시 문제는 Outlook Web App 가상 디렉터리 owa에서 FailbackURL 매개 변수를 구성하여 줄일 수 있습니다.
시작하거나 다시 시작하는 클라이언트는 시작 중에 DNS 조회를 수행하여 클라이언트 액세스 서버나 보조 데이터 센터의 배열에 해당하는 서비스 끝점의 새 IP 주소를 가져옵니다.
Loadgen에서 시나리오의 유효성을 검사하려면 다음 작업을 수행합니다.
클라이언트 액세스 서버 배열에 대한 DNS 항목이 보조 사이트에 있는 하드웨어 부하 분산의 가상 IP 주소를 가리키도록 변경합니다.
모든 Loadgen 서버에서 ipconfig /flushdns 명령을 실행합니다.
Loadgen 테스트를 다시 시작합니다.
보조 사이트에 있는 클라이언트 액세스 서버가 부하를 처리하고 있는지 확인합니다.
Outlook 2007 클라이언트에서 시나리오의 유효성을 검사하려면 다음을 수행합니다.
클라이언트 액세스 서버 배열에 대한 DNS 항목이 보조 사이트에 있는 하드웨어 부하 분산의 가상 IP 주소를 가리키도록 변경합니다.
클라이언트에서 ipconfig /flushdns 명령을 실행하거나 TTL이 만료될 때까지 기다립니다.
Outlook 클라이언트가 다시 연결될 때까지 기다립니다.
Exchange 2010 테스트 솔루션
기본 데이터 센터 서비스 복원 유효성 검사
이전에 실패한 데이터 센터의 서비스를 복원하는 프로세스를 *장애 복구(failback)*라고 합니다. 데이터 센터 장애 복구(failback)를 수행하는 단계는 데이터 센터 전환을 수행하는 단계와 비슷합니다. 가장 큰 차이는 데이터 센터 장애 복구(failback)가 예정에 따라 진행되며 중지 시간이 더 짧은 경우가 많다는 것입니다.
Exchange의 인프라 의존 관계가 다시 활성화되고, 안정적으로 작동하며, 유효성 검사를 마친 후에 장애 복구(failback)를 수행해야 합니다. 이러한 의존 관계가 사용할 수 없거나 정상 상태가 아닌 경우에는 장애 복구(failback)로 인한 중지 시간이 길어질 수 있으며 프로세스 전체가 실패할 수도 있습니다.
사서함 서버 역할은 기본 데이터 센터로 가장 먼저 장애 복구(failback)되는 역할입니다. 다음 단계에서는 사서함 서버 역할 장애 복구(failback) 프로세스에 대해 자세히 설명합니다(DAG가 DAC 모드에 있다고 가정).
DAG 구성원을 기본 사이트에서 다시 통합하려면 다음 명령을 실행합니다.
Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>기본 데이터 센터에서 데이터베이스 복사본의 상태를 확인하려면 다음 명령을 실행합니다.
Get-MailboxDatabaseCopyStatus
기본 데이터 센터에 있는 사서함 서버를 DAG에 통합한 후에 데이터베이스 복사본을 동기화하는 데 시간이 좀 필요합니다. 오류의 성격, 중지 시간의 길이, 중지 시간 중에 관리자가 수행한 작업 등에 따라 데이터베이스 복사본을 다시 시도해야 할 수도 있습니다. 예를 들어 중지 시간 중에 보조 데이터 센터에 남은 활성 복사본에서 로그 파일 자르기를 수행할 수 있도록 실패한 기본 데이터 센터에서 데이터베이스 복사본을 제거한 경우에는 다시 시드하는 과정이 필요합니다. 이 시점에서는 각 데이터베이스를 개별적으로 동기화할 수 있습니다. 기본 데이터 센터의 복제된 데이터베이스 복사본이 정상 상태인 경우에는 다음 단계로 진행할 수 있습니다.
데이터 센터 전환 프로세스 중에 DAG는 대체 미러링 모니터 서버를 사용하도록 구성되었습니다. 기본 데이터 센터에서 미러링 모니터 서버를 사용하도록 DAG를 다시 구성하려면 다음 명령을 실행합니다.
Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>기본 데이터 센터에서 다시 활성화할 데이터베이스는 이제 보조 데이터 센터에서 분리해야 합니다. 다음 명령을 실행합니다.
Get-MailboxDatabase | Dismount-Database데이터베이스를 분리한 후에는 보조 데이터 센터에서 기본 데이터 센터로 클라이언트 액세스 서버 URL을 이동해야 합니다. 이를 위해 URL의 DNS 레코드가 클라이언트 액세스 서버나 기본 데이터 센터에 있는 배열을 가리키도록 변경합니다.
중요
클라이언트 액세스 서버 URL이 이동하고 DNS TTL 및 캐시 항목이 만료될 때까지는 다음 단계를 진행하지 마십시오. 클라이언트 액세스 서버 URL을 기본 데이터 센터로 이동하기 전에 기본 데이터 센터에서 데이터베이스를 활성화하면 구성이 잘못될 수 있습니다(예: 탑재된 데이터베이스의 Active Directory 사이트에 클라이언트 액세스 서버가 없는 경우).
데이터베이스를 활성화하려면 다음 명령 중 하나를 실행합니다.
Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>또는
Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>데이터베이스를 탑재하려면 다음 명령을 실행합니다.
Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database
성공 조건: 활성 사서함 데이터베이스가 보조 사이트의 사서함 서버에 탑재되어 있습니다. 확인하려면 다음 명령을 실행합니다.
Get-MailboxDatabaseCopyStatus <DatabaseName>
Exchange 2010 테스트 솔루션
테스트 시설
테스트는 워싱턴 레드몬드에 있는 Microsoft 본사 캠퍼스의 최신 엔터프라이즈 솔루션 유효성 검사실인 Microsoft Enterprise Engineering Center에서 수행했습니다.
1억 2천 5백만 달러가 넘는 하드웨어 및 업계 선두 OEM(주문자 상표 부착 방식)과의 파트너 관계를 갖춘 EEC에서는 실제로 모든 프로덕션 환경을 복제할 수 있습니다. EEC는 고객, 파트너 및 Microsoft 제품 엔지니어 간의 광범위한 공동 작업을 가능하게 하는 환경을 제공합니다. 이를 통해 Microsoft 종단 간 솔루션이 고객의 기대를 충족하도록 할 수 있습니다.
Exchange 2010 테스트 솔루션
솔루션 유효성 검사 결과
다음 섹션에는 기능 및 성능 유효성 검사 테스트 결과가 요약되어 있습니다.
Exchange 2010 테스트 솔루션
기능 유효성 검사 결과
다음 표에는 기능 유효성 검사 테스트 결과가 요약되어 있습니다.
기능 유효성 검사 결과
| 테스트 사례 | 결과 | Comments |
|---|---|---|
데이터베이스 전환 |
성공 |
오류 없이 완료됨 |
서버 전환 |
성공 |
오류 없이 완료됨 |
서버 오류 |
성공 |
오류 없이 완료됨 |
사이트 오류 |
성공 |
오류 없이 완료됨 |
Exchange 2010 테스트 솔루션
저장소 디자인 유효성 검사 결과
단일 저장소 프레임에서 사이트별 전체 디스크에 대해 테스트한 결과, CX4-480이 .15 IOPS의 150개 메시지 사용자 프로필과 추가 20% 공간으로 구성된 8개 Exchange VM 전체에서 8,000개가 넘는 Exchange 2010 트랜잭션 IOPS를 처리하는 것으로 나타납니다. 성능은 이 구성에 필요한 대상 기준 5,832 IOPS를 초과했으며 최대 부하를 위한 추가 공간을 제공했습니다. Exchange 2010 성능에 대한 Microsoft 모범 사례에 따라 디스크 대기 시간은 모두 허용되는 매개 변수 내에 있었습니다.
저장소 디자인 유효성 검사 결과
| 데이터베이스 I/O | 대상 값 | 일반적인 작동 조건에서 4개 사서함 서버(사서함 서버당 2, 700명의 사용자) | 전환 조건에서 4개 사서함 서버(사서함 서버당 5,400명의 사용자) | 전체 |
|---|---|---|---|---|
달성한 트랜잭션 IOPS(I/O 데이터베이스 읽기/초 + I/O 데이터베이스 쓰기/초) |
1944 / 3888 |
3576 IOPS |
4488 IOPS |
8064 IOPS |
I/O 데이터베이스 읽기/초 |
해당 없음 |
2193 |
2729 |
4922 |
I/O 데이터베이스 쓰기/초 |
해당 없음 |
1439 |
1703 |
3142 |
I/O 데이터베이스 읽기 평균 대기 시간(밀리초) |
<20밀리초 |
14 |
18 |
16 |
I/O 데이터베이스 쓰기 평균 대기 시간(밀리초) |
데이터베이스 쓰기가 비동기적이므로 클라이언트 대기 시간에 대한 표시기가 적절하지 않음 |
14 |
18 |
16 |
I/O 로그 쓰기/초 |
해당 없음 |
1238 |
1560 |
2798 |
I/O 로그 읽기 평균 대기 시간(밀리초) |
<10밀리초 |
2 |
2 |
2 |
Exchange 2010 테스트 솔루션
서버 디자인 유효성 검사 결과
다음 섹션에는 테스트 사례에 대한 서버 디자인 유효성 검사 결과가 요약되어 있습니다.
Loadgen 유효성 검사: 테스트 시나리오
| 테스트 | 설명 |
|---|---|
정상 작동 |
각 사서함 서버에서 2,700명의 사용자를 처리하는 한 사이트에서 10,800명 사용자에 대한 100%의 동시 부하가 시뮬레이트되었습니다. |
단일 서버 오류나 단일 서버 유지 관리(사이트 내) |
사이트별 단일 Hyper-V 호스트 서버 오류가 시뮬레이트되었습니다. VM 하나로 5,400명의 사용자를 처리하는 단일 Hyper-V 호스트에 대해 100%의 동시 부하가 실행되었습니다. 3개의 클라이언트 액세스 및 허브 전송 조합 서버에서만 부하를 처리했습니다. |
사이트 오류 |
사이트 오류가 시뮬레이트되었거나 대기 사서함 서버 VM의 보조 이미지가 활성화되었습니다. 단일 사이트에서 21,600명의 사용자에 대해 100%의 동시 부하가 실행되었습니다. |
테스트 사례: 일반적인 작동 조건
이 테스트 사례는 일반적인 작동 조건에서 최대 부하 작업을 나타냅니다. 일반적인 작동 조건이란 모든 활성 및 수동 데이터베이스가 실행하려고 계획했던 서버에 있음을 의미합니다. 이 테스트 사례는 최악의 작업을 나타내지 않기 때문에 주요 성능 유효성 검사 테스트가 아닙니다. 이 테스트 사례는 서버 오류 또는 유지 관리 이벤트 외부에서 이러한 환경이 실행되는 방식을 잘 나타냅니다. 이 테스트의 목적은 최대 부하가 있는 일반적인 작동 조건에서 전체 Exchange 환경의 유효성을 검사하는 것입니다. 모든 Exchange VM이 일반적인 조건에서 작동했습니다. Loadgen은 최대 부하를 시뮬레이트하도록 구성되었습니다. 최대 부하 모드에서 실행된 150개 메시지 작업 프로필은 초당 주고받은 메시지의 두 배를 생성하도록 예상되었습니다.
예상된 부하의 유효성 검사
메시지 배달 속도는 테스트한 작업이 대상 작업과 일치했는지 확인합니다. 메시지 배달 속도가 대상보다 약간 빠르기 때문에 원하는 프로필보다 부하가 약간 높습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
사서함당 메시지 배달 속도 |
15.0 |
15.2 |
기본 사서함 서버의 유효성 검사
다음 표에는 기본 사서함 서버 VM의 유효성 검사 결과가 나와 있습니다.
프로세서
예상한 대로 프로세서 사용률이 70% 미만입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
69 |
저장소
저장소 결과는 양호합니다. 모든 대기 시간이 대상 값보다 작습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchange Database\I/O Database Reads (Attached) Average Latency |
<20밀리초 |
19 |
MSExchange Database\I/O Database Writes (Attached) Average Latency |
<20밀리초 <읽기 평균 |
18 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20밀리초 |
5 |
Database\Log Record Stalls/sec |
0 |
0 |
응용 프로그램 상태
Exchange가 정상이며 응용 프로그램 상태를 확인하는 데 사용된 카운터가 모두 대상 값보다 작습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
3.0 |
MSExchangeIS\RPC Averaged Latency |
<10밀리초 |
2.0 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
2.0 |
보조 사서함 서버의 유효성 검사
다음 표에는 보조 사서함 서버 VM의 유효성 검사 결과가 나와 있습니다.
프로세서
예상한 대로 프로세서 사용률이 70% 미만입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
26 |
저장소
저장소 결과는 양호합니다. 모든 대기 시간이 대상 값보다 작습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchange Database\I/O Database Reads (Recovery) Average Latency |
<100밀리초 |
0 |
MSExchange Database\I/O Database Writes (Recovery) Average Latency |
<100밀리초 <읽기 평균 |
16 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20밀리초 |
3 |
Database\Log Record Stalls/sec |
0 |
0 |
응용 프로그램 상태
보조 사서함 서버는 세 번째 수동 데이터베이스 복사본만 유지 관리하므로 표준 Exchange 응용 프로그램 상태 표시기를 이 시나리오에 적용할 수 없습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
해당 없음 |
MSExchangeIS\RPC Averaged Latency |
<10밀리초 |
해당 없음 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
해당 없음 |
클라이언트 액세스 및 허브 전송 서버 유효성 검사
다음 표에는 클라이언트 액세스 및 허브 전송 서버 VM의 유효성 검사 결과가 나와 있습니다.
프로세서
예상한 대로 프로세서 사용률은 낮습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
48 |
저장소
저장소 결과는 양호해 보입니다. 매우 낮은 대기 시간은 메시지 전송에 영향을 주지 않습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Logical/Physical Disk(*)\Avg. Disk sec/Read |
<20밀리초 |
0.001 |
Logical/Physical Disk(*)\Avg. Disk sec/Write |
<20밀리초 |
0.005 |
응용 프로그램 상태
RPC Averaged Latency 값이 낮으면 클라이언트 액세스 서버가 정상적이므로 클라이언트 환경에 영향을 주지 않습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchange RpcClientAccess\RPC Averaged Latency |
<250밀리초 |
8 |
MSExchange RpcClientAccess\RPC Requests |
<40 |
3 |
Transport Queues 카운터가 모두 대상보다 낮아 양호하므로, 허브 전송 서버가 정상이며 필요한 메시지를 처리하고 전달할 수 있습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues) |
<3000 |
2.5 |
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length |
<250 |
0 |
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length |
<250 |
2.3 |
\MSExchangeTransport Queues(_total)\Submission Queue Length |
<100 |
0 |
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length |
<100 |
0.3 |
루트 서버 상태 유효성 검사
다음 표에는 Hyper-V 루트 서버의 유효성 검사 결과가 나와 있습니다.
프로세서
예상대로 프로세서 사용률이 매우 낮으며 대상 임계값보다 낮습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time |
<75% |
66 |
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time |
<5% |
2 |
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time |
<80% |
68 |
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time |
<5% |
3 |
응용 프로그램 상태
Virtual Machine Health Summary 카운터는 모든 VM의 상태가 정상임을 나타냅니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Virtual Machine Health Summary\Health Critical |
0 |
0 |
테스트 사례: 단일 서버 오류나 단일 서버 유지 관리(사이트 내)
이 테스트의 목적은 최대 부하가 있는 실제 Hyper-V 루트 서버 오류 또는 유지 관리 작업 조건에서 전체 Exchange 환경의 유효성을 검사하는 것입니다. 사이트 내 Hyper-V 루트 서버 중 하나에서 실행 중인 VM을 모두 종료하여 호스트 유지 관리 조건을 시뮬레이트합니다. 이렇게 하면 데이터베이스 이미지(복사본)가 다른 사서함 서버 VM으로 이동되어, 사서함 서버 VM당 5,400명의 사용자 작동 조건이 만들어집니다. 클라이언트 액세스 및 허브 전송 조합 서버의 절반만 클라이언트 액세스 및 메일 전달을 처리했습니다.
예상된 부하의 유효성 검사
실제 메시지 배달 속도는 대상과 같습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
서버당 메시지 배달 속도 |
30 |
30 |
기본 사서함 서버의 유효성 검사
다음 표에는 기본 사서함 서버 VM의 유효성 검사 결과가 나와 있습니다.
프로세서
프로세서 사용률은 대상보다 조금 높습니다. 이 테스트 사례는 최대 부하의 오류 또는 유지 관리 시나리오를 나타내므로 발생 가능성이 낮습니다. 프로세서 사용률을 장시간 이렇게 높게 유지하고자 하지는 않을 것입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
83 |
저장소
저장소 결과를 허용 가능한 것으로 보입니다. 평균 읽기 대기 시간이 대상보다 조금 높습니다. 평균 데이터베이스 쓰기 대기 시간이 기본보다 높습니다. 이것은 최대 부하에서 최악의 오류 시나리오에 대한 것으로, 발생 가능성이 낮습니다. 대기 시간이 높다고 해서 응용 프로그램 상태 카운터가 대상보다 커지지는 않으므로 사용자 환경은 여전히 허용 가능한 상태가 됩니다. 대기 시간을 장시간 이렇게 높게 유지하고자 하지는 않을 것입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchange Database\I/O Database Reads (Attached) Average Latency |
<20밀리초 |
20.5 |
MSExchange Database\I/O Database Writes (Attached) Average Latency |
<20밀리초 |
23 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20밀리초 |
8 |
Database\Log Record Stalls/sec |
0 |
0 |
응용 프로그램 상태
이 카운터는 Exchange 상태가 정상임을 보여줍니다. 최대 부하에서는 일부 메시지 큐가 발생하기 시작합니다. 이를 장시간 유지하고자 하지는 않을 것입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
9.0 |
MSExchangeIS\RPC Averaged Latency |
<10밀리초 |
2.0 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
77 |
보조 사서함 서버의 유효성 검사
다음 표에는 보조 사서함 서버 VM의 유효성 검사 결과가 나와 있습니다.
프로세서
예상한 대로 프로세서 사용률이 70% 미만입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
21 |
저장소
저장소 결과는 양호합니다. 모든 대기 시간이 대상 값보다 작습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchange Database\I/O Database Reads (Recovery) Average Latency |
<100밀리초 |
0 |
MSExchange Database\I/O Database Writes (Recovery) Average Latency |
<100밀리초 <읽기 평균 |
21 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20밀리초 |
3 |
Database\Log Record Stalls/sec |
0 |
0 |
응용 프로그램 상태
보조 사서함 서버는 세 번째 수동 데이터베이스 복사본만 유지 관리하므로 표준 Exchange 응용 프로그램 상태 표시기를 이 시나리오에 적용할 수 없습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
해당 없음 |
MSExchangeIS\RPC Averaged Latency |
<10밀리초 |
해당 없음 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
해당 없음 |
클라이언트 액세스 및 허브 전송 서버 유효성 검사
다음 표에는 클라이언트 액세스 및 허브 전송 서버 VM의 유효성 검사 결과가 나와 있습니다.
프로세서
예상한 대로 프로세서 사용률이 80% 미만입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
74 |
저장소
저장소 결과는 양호해 보입니다. 매우 낮은 대기 시간은 메시지 전송에 영향을 주지 않습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Logical/Physical Disk(*)\Avg. Disk sec/Read |
<20밀리초 |
0.001 |
Logical/Physical Disk(*)\Avg. Disk sec/Write |
<20밀리초 |
0.008 |
응용 프로그램 상태
RPC Averaged Latency 값이 낮으면 클라이언트 액세스 서버가 정상적이므로 클라이언트 환경에 영향을 주지 않습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchange RpcClientAccess\RPC Averaged Latency |
<250밀리초 |
18 |
MSExchange RpcClientAccess\RPC Requests |
<40 |
14 |
Transport Queues 카운터가 모두 대상보다 낮아 양호하므로, 허브 전송 서버가 정상이며 필요한 메시지를 처리하고 전달할 수 있습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues) |
<3000 |
49 |
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length |
<250 |
0 |
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length |
<250 |
43 |
\MSExchangeTransport Queues(_total)\Submission Queue Length |
<100 |
53 |
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length |
<100 |
4 |
루트 서버 상태 유효성 검사
다음 표에는 Hyper-V 루트 서버의 유효성 검사 결과가 나와 있습니다.
프로세서
프로세서 사용률이 대상 임계값에 가까운데, 이는 최대 부하에 있는 오류 또는 유지 관리 시나리오에서 예상되는 상황입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time |
<75% |
77 |
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time |
<5% |
2 |
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time |
<80% |
79 |
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time |
<5% |
3 |
응용 프로그램 상태
Virtual Machine Health Summary 카운터는 모든 VM의 상태가 정상임을 나타냅니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Virtual Machine Health Summary\Health Critical |
0 |
0 |
테스트 사례: 사이트 오류 및 전환
이 테스트 사례는 기본 사이트의 활성 데이터베이스를 보조 사이트의 수동 데이터베이스로 전환하여 사이트 오류를 시뮬레이트한 것으로, 한 사이트에 21,600개의 사서함이 활성화됩니다. 나머지 사이트에 있는 네 개의 기본 사서함 서버 VM에서 2,700개 활성 사서함의 일반 작업을 각각 실행 중입니다. 나머지 사이트에 있는 네 개의 보조 사서함 서버 VM에서 이제 2,700개 활성 사서함을 각각 실행 중입니다. 각 Hyper-V 루트 서버는 5,400개의 활성 사서함을 호스트합니다.
예상된 부하의 유효성 검사
메시지 배달 속도가 대상보다 약간 빠르기 때문에 원하는 프로필보다 부하가 약간 높습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
서버당 메시지 배달 속도 |
15 |
15.1 |
기본 사서함 서버의 유효성 검사
다음 표에는 기본 사서함 서버 VM의 유효성 검사 결과가 나와 있습니다.
프로세서
기본 사서함 서버 VM이 일반 작업을 실행 중이며 예상한 대로 프로세서 사용률 대상보다 낮습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
63 |
저장소
저장소 결과는 양호합니다. 모든 대기 시간이 대상 값보다 작습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchange Database\I/O Database Reads (Attached) Average Latency |
<20밀리초 |
12 |
MSExchange Database\I/O Database Writes (Attached) Average Latency |
<20밀리초 |
13 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20밀리초 |
4 |
Database\Log Record Stalls/sec |
0 |
0 |
응용 프로그램 상태
Exchange가 정상이며 응용 프로그램 상태를 확인하는 데 사용된 카운터가 모두 대상 값보다 작습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
3.0 |
MSExchangeIS\RPC Averaged Latency |
<10밀리초 |
2.0 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
3 |
보조 사서함 서버의 유효성 검사
다음 표에는 보조 사서함 서버 VM의 유효성 검사 결과가 나와 있습니다.
프로세서
프로세서 사용률은 80%의 대상보다 높습니다. 이 사용률은 기본 설정보다 높지만 다른 Exchange 상태 카운터에 영향을 주지는 않는 것 같습니다. 이 테스트는 사이트 오류 발생 가능성이 낮을 때의 최대 부하를 나타내므로 문제가 되지 않습니다. 프로세서 사용률을 오랫동안 이 수준으로 유지하고자 하지는 않을 것입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
84 |
저장소
저장소 결과는 양호합니다. 모든 대기 시간이 대상 값보다 작습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchange Database\I/O Database Reads (Attached) Average Latency |
<20밀리초 |
17 |
MSExchange Database\I/O Database Writes (Attached) Average Latency |
<20밀리초 <읽기 평균 |
12 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20밀리초 |
3 |
Database\Log Record Stalls/sec |
0 |
0 |
응용 프로그램 상태
이 카운터는 Exchange가 정상임을 나타냅니다. 작은 양의 큐가 있습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
3 |
MSExchangeIS\RPC Averaged Latency |
<10밀리초 |
2 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
106 |
클라이언트 액세스 및 허브 전송 서버 유효성 검사
다음 표에는 클라이언트 액세스 및 허브 전송 서버 VM의 유효성 검사 결과가 나와 있습니다.
프로세서
예상한 대로 프로세서 사용률이 80% 미만입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
63 |
저장소
저장소 결과는 양호해 보입니다. 매우 낮은 대기 시간은 메시지 전송에 영향을 주지 않습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Logical/Physical Disk(*)\Avg. Disk sec/Read |
<20밀리초 |
0.002 |
Logical/Physical Disk(*)\Avg. Disk sec/Write |
<20밀리초 |
0.003 |
응용 프로그램 상태
RPC Averaged Latency 값이 낮으면 클라이언트 액세스 서버가 정상적이므로 클라이언트 환경에 영향을 주지 않습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
MSExchange RpcClientAccess\RPC Averaged Latency |
<250밀리초 |
9 |
MSExchange RpcClientAccess\RPC Requests |
<40 |
7 |
Transport Queues 카운터가 모두 대상보다 낮아 양호하므로, 허브 전송 서버가 정상이며 필요한 메시지를 처리하고 전달할 수 있습니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues) |
<3000 |
5 |
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length |
<250 |
0 |
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length |
<250 |
4 |
\MSExchangeTransport Queues(_total)\Submission Queue Length |
<100 |
0 |
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length |
<100 |
1 |
루트 서버 상태 유효성 검사
다음 표에는 Hyper-V 루트 서버의 유효성 검사 결과가 나와 있습니다.
프로세서
프로세서 사용률은 80%의 대상보다 높습니다. 이 테스트는 사이트 오류 발생 가능성이 낮을 때의 최대 부하를 나타내므로 문제가 되지 않습니다. 프로세서 사용률을 오랫동안 이 수준으로 유지하고자 하지는 않을 것입니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time |
<75% |
85 |
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time |
<5% |
2 |
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time |
<80% |
87 |
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time |
<5% |
3 |
응용 프로그램 상태
Virtual Machine Health Summary 카운터는 모든 VM의 상태가 정상임을 나타냅니다.
| 카운터 | 대상 | 테스트 결과 |
|---|---|---|
Hyper-V Virtual Machine Health Summary\Health Critical |
0 |
0 |
Exchange 2010 테스트 솔루션
결론
이 백서는 Cisco 및 EMC 하드웨어에 배포된 여러 사이트에 32,400개의 사서함이 있는 고객 환경에 대해 Exchange 2010 솔루션을 디자인 및 테스트하고 유효성을 검사하는 방법의 예를 제공합니다. 이 설명서의 단계별 방법론은 주요 문제를 해결하는 데 도움이 되는 중요한 디자인 결정 요소를 안내하고 핵심 비즈니스 요구 사항이 충족되었는지 확인합니다.
Exchange 2010 테스트 솔루션
추가 정보
Exchange 2010 전체 설명서를 보려면 Exchange Server 2010을 참조하십시오.
Cisco 및 EMC 관련 정보에 대해서는 다음 리소스를 참조하십시오.
EMC CLARiiON CX4-480: EMC CLARiiON Virtual Provisioning
EMC CLARiiON CX4-480: 제품 개요
Cisco 통합 컴퓨팅 및 서버: UCS 개요
Cisco 통합 컴퓨팅 및 서버: B-시리즈 블레이드 서버
Cisco 통합 컴퓨팅 및 서버: UCS 관리자
이 문서는 "있는 그대로" 제공됩니다. URL 및 기타 인터넷 웹 사이트 참조를 포함한 이 문서의 내용 및 견해는 예고 없이 변경될 수 있습니다. 내용 사용으로 인한 위험을 감안하십시오.
이 문서는 Microsoft 제품에 대한 어떠한 법적 권한이나 지적 재산권도 제공하지 않습니다. 내부 참조용으로 이 문서를 복사하고 사용할 수 있습니다.
Exchange 2010 테스트 솔루션