Exchange 2010 사서함 서버 역할 디자인 예

 

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

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

이 항목에서는 사서함 서버 역할과 관련 아키텍처에 적절한 메모리, 용량, I/O 및 CPU 성능 요구 사항을 결정하는 방법의 예를 보여줍니다.

입력 요소 집합을 지정하여 Exchange Server 2010 사서함 서버 역할 요구 사항 계산기를 사용하면 사서함 서버 역할에 적절한 요구 사항을 결정할 수 있습니다. 계산기로 이 예에서 설명한 요구 사항을 결정할 수 있습니다. 계산기에 대한 자세한 내용과 다운로드 방법은 Exchange Server 팀 블로그 문서 Exchange 2010 사서함 서버 역할 요구 사항 계산기(영문)를 참조하십시오.

참고

각 블로그의 콘텐츠와 해당 URL은 사전 통지 없이 변경될 수 있습니다. 각 블로그의 콘텐츠는 어떠한 보증 없이 "있는 그대로" 제공되며 어떠한 권한도 제공하지 않습니다. 포함된 스크립트 샘플 또는 코드는 Microsoft 사용 약관에 지정되어 있는 약관에 따라 사용됩니다.

사서함 서버 역할 저장소 디자인에 대한 자세한 내용은 사서함 서버 저장소 디자인을 참조하십시오.

이 예에서 사용된 시나리오는 JBOD(여러 디스크 모음) 저장소를 사용하는 세 개의 데이터베이스 복사본 솔루션입니다. 이 예에서는 다음 아키텍처 요구 사항을 고려합니다.

• 단일 DAG(데이터베이스 가용성 그룹)에 참가하는 6개의 사서함 서버

• Exchange 사서함 서버는 허브 전송 및 클라이언트 액세스 서버 역할도 호스팅함

• 세 개의 고가용성 사서함 데이터베이스 복사본, 지연된 데이터베이스 복사본 없음

• 7.2K(7,200RPM) 1TB SATA 스핀들 사용

• JBOD 저장소 구성(1 LUN(논리 단위 번호)/데이터베이스 LUN 아키텍처)

• 백업 아키텍처의 경우 단일 항목 복구 및 사서함 복구를 통해 제공되는 고유 데이터 보호 기능 사용

• 유지 관리 및 복구 작업을 위한 복원 LUN이 배포됨

• 각 LUN에 여유 공간 최소 20%

• 솔루션이 이중 서버 오류 이벤트를 견딜 수 있음

• 유일하게 설치된 서버 역할은 사서함 서버 역할

목차

사서함 용량 요구 사항

데이터베이스 복사본 요구 사항

사서함 메모리 요구 사항

사서함 I/O 요구 사항

사서함 CPU 요구 사항

사서함 용량 요구 사항

다음 예에서는 데이터베이스별로 세 개씩의 복사본이 있는 DAG에 참가하는 6개의 사서함 서버에 2GB의 100개 메시지/일 프로필 사서함 24,000개가 있는 환경에서 적절한 크기 조정을 보여줍니다. 이러한 사서함에서는 매주 5일 동안 하루 평균 37MB를 받으며 평균 메시지 크기는 75KB입니다. 단일 항목을 복구할 수 있는 기간은 삭제된 항목이 보존되는 14일 동안입니다. 다음 계산을 사용하여 사서함 크기를 결정합니다.

사서함 크기 = 사서함 제한 + 공백 + 휴지통

공백 = 100개의 메시지/일 x 75/1024MB = 7.32MB

휴지통 = (100개의 메시지/일 x 75/1024MB * 14일) + (2048MB x 0.012) + (2048MB x 0.03) = 188.6MB

디스크에서 실제 사서함 크기를 결정하기 위한 값의 예

사서함 할당량	휴지통 크기(2주)	공백	디스크 전체 크기
2GB	188.7MB	7.3MB	2.19GB(+12%)

이 환경에서는 JBOD 저장소를 사용하므로 배포할 수 있는 최대 데이터베이스 크기는 디스크의 크기에 따라 결정됩니다. JBOD 시나리오의 최대 데이터베이스 크기를 결정하려면 1TB 디스크의 포맷 용량은 931GB, 여유 공간 비율 요구 사항은 20%, 콘텐츠 인덱스 비율은 10%인 다음 수식을 사용하십시오.

최대 데이터베이스 크기 = [포맷 디스크 용량 x (1 – 여유 공간 비율 요구 사항)] / (1 + 콘텐츠 인덱스 비율)

= [931GB x (1 - 0.2)] / (1+ 0.10)

= 744.8GB / 1.1

= 677 GB

이 환경에서 각 사용자의 사서함은 2.25GB의 디스크 공간을 사용합니다. 24,000개의 사서함을 데이터베이스 크기 677 GB로 지원하려면 데이터베이스는 102개가 있어야 합니다. 이 조건에 의하면 데이터베이스당 최종 사서함 수가 235개가 됩니다.

하지만 이 솔루션은 JBOD 저장소 아키텍처를 사용하므로 데이터베이스당 사서함 수가 단일 디스크에서 달성할 수 있는 임의 I/O의 양을 초과하지 않아야 합니다. 이 솔루션은 폼 요소가 큰 7.2K SATA 스핀들을 사용하므로 스핀들을 완전히 활용하면 최대 55의 무작위 IOPS(초당 I/O)를 달성할 수 있습니다. I/O 오버헤드 성장 버퍼가 20%인 것을 고려하면 스핀들은 총 44까지의 IOPS를 처리할 수 있습니다.

사용자 기반에 100개의 메시지/일 프로필이 있는 점을 감안하면 각 사서함은 0.1 IOPS를 소비하게 되므로 디스크는 이 IOPS 프로필로 최대 440개의 사서함을 지원할 수 있습니다. 용량 계산 결과 지원할 수 있는 최대 사서함 수는 235개이며 이 값이 IOPS 프로필로부터 계산한 440보다 낮으므로 이 솔루션을 단일 디스크에 배포할 수 있습니다.

실제 데이터베이스 크기를 결정하려면 다음 수식을 사용합니다.

데이터베이스 크기 = 사서함 수 x 디스크에 있는 사서함 크기 x 데이터베이스 오버헤드 성장 요소

사서함 수와 실제 사서함 크기, 데이터베이스 성장 오버헤드 요소인 20%를 고려한 데이터베이스 크기는 다음 표에서와 같이 619 GB입니다.

데이터베이스 용량 요구 사항

데이터베이스당 사서함	전체 데이터베이스 수	데이터베이스 크기 요구 사항
235	102	619GB

공간 할당 문제로 인해 사서함 서버가 중단된 상태를 유지하지 않게 하려면 백업 세트 도중 생성된 모든 로그를 포함하도록 트랜잭션 로그의 크기도 조정해야 합니다. 이 아키텍처에서 사서함 복구 및 단일 복구 기능을 백업 아키텍처로 활용한다는 점을 고려하면 오류가 발생한 복사본이 3일 동안 복구되지 않을 경우 매일 3개의 로그 생성 속도에 대해 로그 용량을 할당해야 합니다. (복사에 실패하면 로그가 잘리지 않습니다.)

100개의 메시지/일 프로필 사서함이 하루 평균 20개의 트랜잭션 로그를 생성하므로 사서함이 24,000개인 환경에서는 매일 576,000개의 트랜잭션 로그가 생성됩니다. 그러므로 각 데이터베이스는 매일 5,647개의 로그를 생성합니다. 매주 토요일에 사서함 중 1%가 이동합니다. 이 방법은 Exchange의 고유 데이터 보호 기능을 사용하므로 백업을 수행하지 않으며, 3일 동안 로그를 자르지 않고 감당할 수 있는 크기로 조정됩니다.

다음 표에서와 같이 이 서버에는 각 데이터베이스 복사본에 사용할 23GB의 공간이 필요합니다.

로그 용량 요구 사항

데이터베이스당 로그	로그 파일 크기	일별 로그 크기	사서함 이동 크기 ÷ 데이터베이스	자르기 오류 허용	로그 크기 요구 사항
5647	1MB	5.65GB	6GB (240 × 2.19GB x 1.2 / 102)	16.5GB (3 × 5.65GB)	23GB (16.5GB + 6GB)

복사본이 세 개인 사서함 복구 및 JBOD 구성인 점을 고려하면 각 데이터베이스와 관련 트랜잭션 로그는 동일한 LUN에 들어갑니다. 필요한 LUN 크기는 다음과 같습니다.

LUN 용량 = 데이터베이스 크기 ÷ (1 - 여유 공간 비율 요구 사항)

= (데이터베이스 크기 + 트랜잭션 로그 크기 + 콘텐츠 인덱스 크기) ÷ (1 - 0.2)

= (619 GB + 23GB + 61.9 GB) / 0.8

= 879 GB

필요한 LUN 크기 결정

데이터베이스 크기	트랜잭션 로그 크기	콘텐츠 인덱스 크기	데이터베이스 LUN 크기
619GB	23GB	61.9GB	879GB

맨 위로 이동

데이터베이스 복사본 요구 사항

24,000개의 사서함을 지원하기 위해 총 102개의 데이터베이스가 필요하며 각 데이터베이스에 세 개의 복사본이 있는 경우를 가정하면 DAG는 총 306개의 데이터베이스를 지원합니다. 306개의 데이터베이스가 6개의 사서함 서버에 분산되어 있으면 각 사서함에는 51개의 데이터베이스 복사본이 들어갑니다. 데이터베이스 복사본은 DAG의 서버에서 서버 수준 오류가 생길 경우 활성 데이터베이스가 가능한 한 많은 수의 나머지 서버로 장애 조치되는 방식으로 배포됩니다(데이터베이스 복사본이 대칭적으로 배포되지는 않음).

DAG에 참가하는 사서함 서버의 효율을 극대화하기 위해, 활성 데이터베이스는 모든 사서함 서버에 고르게 배포합니다. 따라서 6개의 사서함 서버가 모두 작동하는 경우 각 서버는 17개의 활성 데이터베이스 복사본을 호스트해야 합니다.

단일 사서함 서버에 오류가 발생하면 17개의 데이터베이스가 나머지 사서함 서버에 다시 배포되어 서버당 활성 데이터베이스 복사본 수가 21개로 늘어납니다.

두 개의 사서함 서버에 오류가 발생하면 34개의 데이터베이스가 나머지 사서함 서버 사이에 다시 배포되어 서버당 활성 데이터베이스 복사본의 수는 26개가 됩니다. 사서함 서버의 메모리 및 CPU 요구 사항을 정할 때에는 이 활성 복사본 수를 사용합니다.

사서함 서버 전체에 데이터베이스 복사본을 분산하는 방법에 대한 자세한 내용은 데이터베이스 복사본 레이아웃 디자인을 참조하십시오.

맨 위로 이동

사서함 메모리 요구 사항

100메시지/일의 메시지 프로필에서 사서함당 데이터베이스 캐시를 지원하기 위해 최소한으로 요구되는 메모리를 6MB입니다. 최악의 경우 서버당 활성 사서함 데이터베이스 수는 26개이므로 각 서버에는 총 6,110개의 라이브 사서함을 호스트할 수 있습니다. 또한 서버당 데이터베이스 수는 총 51개입니다. 사서함 서버에는 최소 12GB의 데이터베이스 캐시가 필요합니다. 따라서 데이터베이스 캐시를 지원하는 데 필요한 메모리의 크기는 다음과 같습니다.

필요한 최소 데이터베이스 캐시 = MAX((라이브 사서함 수 x 필요한 메모리 / 사서함), 데이터베이스의 최소 메모리)

= MAX(6110 x 6/1024GB, 12GB)

= MAX (36GB, 12GB)

= 36GB

다중 역할 아키텍처를 배포하는 경우 이 구성을 지원하기 위해 필요한 총 물리적 메모리는 사서함 데이터베이스 캐시 이해의 표에 따라 64GB입니다.

맨 위로 이동

사서함 I/O 요구 사항

각 사서함은 하루 100개의 메시지를 보내거나 받습니다. 따라서 각 사서함의 IOPS 프로필은 0.1입니다. 각 데이터베이스에는 235개의 사서함이 있습니다. 따라서 총 데이터베이스 볼륨 I/O 크기는 다음과 같습니다.

데이터베이스 볼륨 I/O = 사서함 수 x IOPS 프로필 x (1 + I/O 오버헤드 성장 요소)

= 235 x 0.1 x 1.2

= 28.2 IOPS

이 아키텍처에서 데이터베이스 읽기 I/O 백분율은 60%입니다. 따라서 각 데이터베이스 볼륨은 16.92 IOPS의 읽기 I/O 및 11.28 IOPS의 쓰기 I/O입니다.

이 아키텍처에서 각 로그 스트림은 데이터베이스 쓰기 I/O의 50%를 생성합니다. 따라서 볼륨당 로그 쓰기 I/O는 5.64 IOPS입니다.

26개의 활성 데이터베이스 복사본 역시 로그 쓰기 I/O의 10%에 해당하는 로그 읽기 I/O를 생성합니다. 따라서 이러한 데이터베이스의 로그 읽기 I/O는 0.56 IOPS입니다.

폼 요소가 큰 각 7.2K SATA 디스크가 55개의 임의 IOPS를 생성하는 것을 고려하면 디스크에서 데이터베이스의 I/O 요구 사항을 처리하지 못할 걱정은 없습니다.

맨 위로 이동

사서함 CPU 요구 사항

이중 서버 오류 이벤트가 발생할 경우 나머지 서버는 각각 26개의 데이터베이스를 호스트하여 서버당 총 6,110개의 활성 사서함을 담당합니다. 사서함 서버 프로세서 용량 계획의 계산을 기준으로 볼 때 각 서버에는 다음과 같은 CPU 메가사이클 요구 사항이 있습니다.

CPU 메가사이클 요구 사항 결정

활성 사서함 CPU 메가사이클 요구 사항	수동 사서함 CPU 메가사이클 요구 사항	총 CPU 메가사이클 요구 사항
14,682	1,765	16,447

선택한 서버 플랫폼에서 총 26,400 메가사이클을 지원할 수 있는 점을 고려하면 서버 CPU 플랫폼은 이중 서버 오류 이벤트가 발생할 경우에도 이 환경을 지원할 수 있습니다.

맨 위로 이동

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