사서함 서버 저장소 디자인

 

적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

마지막으로 수정된 항목: 2009-04-03

충분한 용량을 확보하는 것은 매우 중요합니다. 데이터베이스 디스크에 공간이 부족하면 데이터베이스는 오프라인 상태가 됩니다. 또한 트랜잭션 로그 디스크에 공간이 부족하면 해당 저장소 그룹의 모든 데이터베이스가 오프라인 상태가 됩니다. 추가 공간을 제공하는 작업은 신속하게 실행하기 어려운 경우가 대부분이며 오프라인 압축을 통해 공간을 확보하는 작업은 시간이 오래 걸릴 수 있습니다. 대부분의 경우 디스크 공간이 부족해지면 일정 기간 동안 하나 이상의 데이터베이스를 사용할 수 없게 되며 이 기간은 보통 RTO(Recovery Time Objective)를 초과합니다.

이 항목에서는 다음 정보를 제공합니다.

• Exchange 2007용 사서함 저장소 계산기

• 데이터베이스 LUN 용량

• 로그 LUN 용량

• 트랜잭션 I/O

• Exchange 2007 기본 IOPS 예측

• 비트랜잭션 I/O

• LUN 및 실제 디스크

• 저장소 디자인에 대한 연속 복제의 영향

Exchange 2007용 사서함 저장소 계산기

Exchange Server 2007 Mailbox Server Role Storage Requirements Calculator(저장소 계산기)를 사용하면 입력 요소 집합에 기초하여 저장소 요구 사항(I/O 성능 및 용량)과 선택적 LUN(논리 단위 번호)을 확인할 수 있습니다. Exchange 2007 사서함 서버를 위한 최적의 저장소 솔루션을 디자인하기 전에 설명해야 하는 여러 입력 요소가 있습니다. 이 항목 전체에서 이러한 입력 요소에 대해 설명합니다.

저장소 계산기에서는 조직과 관련된 값을 입력할 수 있으며 I/O 요구 사항, 용량 요구 사항 및 최적 LUN 레이아웃에 대한 권장 사항을 제공합니다.

자세한 사용 방법을 비롯하여 저장소 계산기에 대한 자세한 내용은 Exchange 팀 블로그에서 Exchange 2007 Mailbox Server Role Storage Requirements Calculator(여기서 계산기를 다운로드할 수도 있음)를 참조하십시오.

데이터베이스 LUN 용량

데이터베이스 LUN(논리 단위 번호)의 크기를 지정하는 방법을 결정할 때 사용할 수 있는 여러 가지 데이터 지점이 있습니다. 또한 기타 다양한 요소도 고려해야 합니다. 모든 요소를 고려 및 계산하고 나면 데이터베이스 LUN에 대해 추가 오버헤드 요소를 20% 정도 포함하는 것이 좋습니다. 이 값은 사서함 크기 및 공백을 계산할 때 표시되지 않을 수도 있는 데이터베이스에 있는 기타 데이터를 포함하기 위한 것입니다. 예를 들어, 데이터베이스 내의 테이블, 보기, 내부 인덱스 같은 데이터 구조가 전체 데이터베이스 크기에 추가됩니다. 예를 들어, 다음 하위 섹션을 읽은 후에 필요한 데이터베이스 LUN 크기를 120GB로 결정한다면 해당 저장소 그룹의 데이터베이스 LUN에 대해 20%의 안전 오버헤드를 나타내는 크기를 추가하여 144GB를 제공하는 것이 좋습니다.

사서함 할당량

가장 먼저 파악해야 하는 메트릭은 사서함 크기입니다. 최종 사용자가 사서함에 저장하도록 허용되는 데이터의 양을 알면 해당 서버에 포함할 수 있는 사용자 수를 결정할 수 있습니다. 최종 사서함 크기 및 할당량이 변경되지만, 필요한 용량을 결정할 때는 먼저 목표로 하는 크기를 생각해 두어야 합니다. 예를 들어, 사서함 할당량이 250MB인 5,000명의 사용자가 서버에 있는 경우에는 디스크 공간이 최소한 1.25TB 필요합니다. 사서함 할당량에 대해 구체적인 제한을 설정하지 않으면 필요한 용량을 예측하기가 어려워집니다.

데이터베이스 공백

실제 디스크의 데이터베이스 크기는 단순히 사용자 수에 사용자 할당량을 곱한 값이 아닙니다. 대부분의 사용자가 사서함 할당량에 근접하는 용량을 사용하지 않는 경우 데이터베이스가 사용하는 공간이 줄어들기 때문에 공백으로 인해 용량에 문제가 발생하지 않습니다. 즉, 데이터베이스 자체에 항상 사용할 수 있는 빈 페이지 또는 공백이 분포되어 있습니다. 온라인 유지 관리를 수행하는 동안 데이터베이스에서 제거하도록 표시된 항목이 제거되어 이러한 페이지의 공간을 확보하게 됩니다. 공백의 비율은 지속적으로 변경되며 온라인 유지 관리 직후에 비율이 가장 높고 온라인 유지 관리 직전에 비율이 가장 낮습니다.

데이터베이스의 공백 크기는 데이터베이스의 사서함을 통해 사용자가 주고받는 메일 크기에 의해 대략적으로 예측될 수 있습니다. 예를 들어, 사용자가 매일 평균적으로 10MB의 메일을 주고받는 데이터베이스에 100개의 2GB 사서함(총 200GB)이 있는 경우 공백은 약 1GB(100개의 사서함 × 사서함당 10MB)입니다.

온라인 유지 관리를 통해 전체 과정을 완료할 수 없는 경우에는 공백이 이 예상치를 초과할 수 있습니다. 그러므로 온라인 유지 관리 작업이 매일 밤 실행되도록 충분한 시간을 할당하여 1주일 이내에 전체 과정이 완료되도록 해야 합니다.

데이터베이스 쓰레기 수거통

각 데이터베이스에는 일시적으로 삭제된 항목이 저장되는 쓰레기 수거통이 있습니다. 기본적으로 Microsoft Exchange Server 2007에서는 이러한 항목이 14일 동안 저장됩니다. 여기에는 지운 편지함 폴더에서 제거된 항목도 포함됩니다. 기본적으로 Exchange Server 2003과 비교할 때 Exchange 2007에서는 삭제된 항목이 이전보다 두 배 더 오래 저장되기 때문에 데이터베이스 쓰레기 수거통이 사용하는 오버헤드가 증가되었습니다. 쓰레기 수거통의 실제 크기는 각 항목의 크기와 조직의 특정 보존 설정에 따라 다릅니다.

보존 기간이 지나고 나면 이러한 항목은 온라인 유지 관리 주기 동안 데이터베이스에서 제거됩니다. 그러면 쓰레기 수거통 크기가 데이터베이스 크기의 비율로 2주분의 받는/보내는 메일에 해당하는 크기가 되는 안정적인 상태에 도달하게 됩니다. 정확한 비율은 삭제되는 메일 양과 개별 사서함 크기에 따라 달라집니다.

쓰레기 수거통으로 인해 사서함 크기와 해당 사서함의 메시지 배달 속도에 따라 달라지는 오버헤드 비율이 데이터베이스에 추가됩니다. 예를 들어, 주당 52MB의 일정한 속도로 메시지를 배달하는 250MB의 매우 높음 프로필 사서함의 경우 쓰레기 수거통에 약 104MB의 항목이 저장되어 41%의 오버헤드가 추가됩니다. 반면 쓰레기 수거통에 역시 104MB의 항목이 저장되는 1GB 크기의 사서함의 경우 추가되는 오버헤드는 10%입니다.

실제 사서함 크기

시간이 지남에 따라 사용자 사서함은 사서함 할당량에 도달하기 때문에 들어오는 메일의 양에 해당하는 메일을 삭제하여 사서함 할당량 이하의 크기를 유지해야 합니다. 이 과정에서 쓰레기 수거통은 2주분의 받는/보내는 메일에 해당하는 최대 크기로 증가하게 됩니다. 대부분의 사용자가 사서함 할당량에 도달하는 만큼의 용량을 사용하지 않은 경우에는 받는/보내는 메일이 일부만 삭제되어 쓰레기 수거통과 사서함의 크기가 각각 따로 증가됩니다. 예를 들어, 매주 52MB의 메일(메시지의 평균 크기는 50KB)을 받는 250MB 크기의 매우 높음 메시지 프로필 사서함의 경우 쓰레기 수거통에서 104MB(41%)가 사용되고 공백이 7.3MB이므로 전체 사서함 크기는 360MB가 됩니다. 다른 예로 매주 52MB의 메일을 받는 2GB 크기의 매우 높음 메시지 프로필 사서함의 경우 쓰레기 수거통에서 104MB(5%)가 사용되고 공백이 7.3MB이므로 전체 사서함 크기는 2.11GB가 됩니다. 2GB 사서함이 저장소 그룹에 50개 있으면 총 크기는 105.6GB입니다.

다음은 2GB 사서함을 사용하여 데이터베이스 크기를 나타내는 공식입니다.

사서함 크기 = 사서함 할당량 + 공백 + (매주 들어오는 메일 × 2)

사서함 크기 = 2,048MB + (7.3MB) + (52MB × 2)

2,159MB = 2,048MB + 7.3MB + 104MB(할당량보다 5% 큰 값)

계획된 실제 사서함 크기를 결정한 후 해당 값을 사용하여 데이터베이스당 최대 사용자 수를 결정할 수 있습니다. 계획된 사서함 크기를 가져와서 최대 권장 데이터베이스 크기로 나눕니다. 이렇게 하면 완전히 채워진 데이터베이스의 경우 계획된 사용자 수를 처리하는 데 필요한 데이터베이스 수를 결정하는 데 도움을 줍니다. 비트랜잭션 I/O(입출력) 또는 하드웨어 제한으로 인해 단일 서버에 배치된 사용자 수를 수정해야 합니다. 일부 관리자는 추가 데이터베이스를 사용하여 데이터베이스 크기를 추가로 축소하기를 원하게 됩니다. 이러한 접근 방법은 서버당 여러 데이터베이스 관리 시 매우 복잡한 창을 백업 및 복원하는 데 도움이 됩니다.

콘텐츠 인덱싱

콘텐츠 인덱싱을 통해 인덱스, 즉 사용자가 사서함을 직접 검색하는 것이 아니라 메일 항목을 빠르고 쉽게 검색할 수 있도록 하는 카탈로그가 만들어집니다. Exchange 2007은 전체 데이터베이스 크기의 약 5%인 인덱스를 만들어 데이터베이스와 동일한 LUN에 배치합니다. 그러므로 콘텐츠 인덱싱용으로 데이터베이스 LUN 크기에 5%의 용량을 추가해야 합니다.

유지 관리

오프라인으로 복구 또는 압축해야 하는 데이터베이스의 경우에는 대상 데이터베이스의 크기에 10%를 더한 용량이 필요합니다. 단일 데이터베이스, 저장소 그룹 또는 백업 세트에 대해 충분한 공간을 할당한 경우에도 이와 같은 작업을 수행하려면 추가 공간을 사용할 수 있어야 합니다.

복구 저장소 그룹

재해 복구 계획의 일부분으로 복구 저장소 그룹을 사용할 계획이라면 동시에 해당 서버에서 복원하려는 모든 데이터베이스를 처리하는 데 충분한 용량을 사용할 수 있어야 합니다.

디스크로 백업

대부분의 관리자는 디스크 대상에 대한 스트리밍 온라인 백업을 수행합니다. 백업 및 복원 디자인에 디스크로 백업 작업이 포함되는 경우에는 백업을 포함할 만큼 충분한 용량을 서버에서 사용할 수 있어야 합니다. 사용하는 백업 유형에 따라 이 용량은 데이터베이스 및 로그 크기처럼 작을 수도 있고 마지막 전체 백업 이후로 생성된 데이터베이스 및 모든 로그처럼 클 수도 있습니다.

로그 LUN 용량

트랜잭션 로그 파일은 데이터베이스 엔진에서 수행한 모든 트랜잭션의 레코드입니다. 모든 트랜잭션은 로그에 먼저 기록된 다음 데이터베이스에 지연 기록됩니다. 이전 버전의 Exchange와는 달리 Exchange 2007에서는 트랜잭션 로그 파일의 크기가 5MB에서 1MB로 작아졌습니다. 이 변경 내용은 연속 복제 기능을 지원하고 기본 저장소에 오류가 발생하는 경우 손실되는 데이터의 양을 최소화하기 위한 것입니다.

다음 표를 사용하여 평균 메시지 크기가 50KB인 Exchange 2007 사서함 서버에서 생성되는 트랜잭션 로그 수를 예측할 수 있습니다.

각 사서함 프로필에 대한 생성되는 트랜잭션 로그 수

사서함 프로필	메시지 프로필	생성되는 로그 수 / 사서함
낮음	5개 보냄/20개 받음	6
평균	10개 보냄/40개 받음	12
높음	20개 보냄/80개 받음	24
매우 높음	30개 보냄/120개 받음	36
가장 높음	40개 보냄/160개 받음	48

메시지 크기가 로그 생성 속도에 끼치는 영향과 관련하여 다음과 같은 지침이 마련되었습니다.

• 평균 메시지 크기가 100KB로 두 배가 될 경우 사서함당 생성되는 로그 수는 1.9배 증가합니다. 이 숫자는 첨부 파일 및 메시지 테이블(메시지 본문 및 첨부 파일)을 포함하는 데이터베이스의 백분율을 나타냅니다.

• 그 후에 메시지 크기가 100KB를 초과하여 두 배가 될 경우 사서함당 로그 생성 속도도 두 배가 됩니다.

예를 들면,

• 사서함 프로필이 높음이고 평균 메시지 크기가 100KB일 경우 사서함당 생성되는 로그 수는 24 x 1.9 = 46입니다.

• 사서함 프로필이 높음이고 평균 메시지 크기가 200KB일 경우 사서함당 생성되는 로그 수는 24 x 3.8 = 91입니다.

백업 및 복원 요소

야간에 전체 백업을 수행하는 대부분의 엔터프라이즈에서는 3일분의 로그 파일에 해당하는 용량을 트랜잭션 로그 LUN의 저장소 그룹에 할당합니다. 이 작업은 로그 드라이브가 꽉 차서 발생하는 백업 오류로 인해 저장소 그룹이 분리되는 현상을 방지하기 위한 것입니다.

로그 LUN 크기 조정은 백업 및 복원 디자인의 영향을 다소 받습니다. 예를 들어, 2주 전 시점으로 돌아가 해당 시점 이후로 생성된 모든 로그를 재생하도록 하는 디자인을 사용하는 경우에는 2주분의 로그 파일에 해당하는 공간이 필요합니다. 백업 디자인에 주별 전체 백업 및 매일 차등 백업이 포함되어 있으면 복원 중에 백업 및 재생을 모두 허용할 수 있도록 로그 LUN이 한 주 전체의 로그 파일 공간에 해당하는 용량보다 커야 합니다.

사서함 이동 작업

대규모 사서함 배포의 경우에는 사서함 이동 작업이 기본적인 용량 요소가 됩니다. 대부분의 대기업에서는 일정 비율의 사용자를 야간 또는 주 단위로 다른 데이터베이스, 서버 또는 사이트로 이동시킵니다. 사용자의 조직에서 이와 같은 작업을 수행하는 경우에는 사용자 마이그레이션을 수행할 수 있도록 로그 LUN에 추가 용량을 제공해야 합니다. 원본 서버에서는 크기가 작은 레코드 삭제 작업을 기록하지만 대상 서버에서는 먼저 전송된 모든 데이터를 트랜잭션 로그에 기록해야 합니다. 하루 동안 10GB의 로그 파일을 생성하고 3일 동안의 버퍼로 30GB를 유지한다면 2GB 사서함 50개(100GB)를 이동하는 경우 대상 로그 LUN이 꽉 차 가동이 중지됩니다. 이러한 경우에는 사서함 이동 작업을 수행할 수 있도록 로그 LUN에 대해 추가 공간을 할당해야 할 수도 있습니다.

로그 증가율

대부분의 배포에서는 예기치 않은 로그 생성 순간에 필요한 용량을 제공할 수 있도록 로그 LUN을 만들 때 다른 모든 요소를 고려한 후 20%의 오버헤드 요소를 로그 크기에 추가하는 것이 좋습니다.

사서함 용량 계획 예

다음 예에서는 CCR(클러스터 연속 복제) 환경의 단일 클러스터된 사서함 서버에서 4,000개의 1GB 매우 높음 메시지 프로필 사서함이 있는 환경에 적합한 크기 조정에 대해 설명합니다. 이러한 사서함에서는 주당 평균 50MB의 메일(평균 메시지 크기는 50KB)을 받습니다. 다음 표에서는 실제 사서함 크기를 결정하는 값을 예를 들어, 제공합니다.

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

사서함 크기	쓰레기 수거통 크기(2주)	공백	디스크 전체 크기
1GB	104MB(2 x 52MB)	7.3MB	1.11GB(+ 11%)

이 환경에서 각 사용자는 1.11GB의 디스크 공간을 사용합니다. CCR 환경에서 최대 권장 데이터베이스 크기가 200GB이기 때문에 서버는 데이터베이스당 180개 이하의 사서함을 호스팅해야 합니다. 4,000개의 사서함을 지원하려면 23개의 데이터베이스가 있어야 하며 또한 이 환경에서는 23개의 저장소 그룹이 있어야 합니다. CCR 환경에서는 저장소 그룹당 하나의 데이터베이스가 필요하기 때문에 각 데이터베이스가 해당 저장소 그룹에 위치합니다. 결과적으로 저장소 그룹당 최종 사서함의 수는 174개 입니다. 다음 표에서와 같이 사서함 수와 사서함의 실제 크기에 기초하여 데이터베이스 크기는 193GB입니다.

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

데이터베이스당 사서함	전체 데이터베이스 수	데이터베이스 크기 요구 사항
174	23	193GB

공간 할당 문제로 인해 사서함 서버가 중단된 상태를 유지하지 않게 하려면 백업 세트 도중 생성된 모든 로그를 포함하도록 트랜잭션 로그의 크기도 조정해야 합니다. 많은 조직이 백업이 실패하는 경우 일일 로그 생성 속도의 세 배에 해당하는 전체 백업 전략 계획을 매일 사용합니다. 매주 전체 백업을 하고 차등 또는 증분 백업을 사용하는 경우 복구 작업을 처리하기 위해 최소 한 주의 로그 용량이 필요합니다. 매우 높음 메시지 프로필 사서함이 평균적으로 매일 42개의 트랜잭션 로그를 생성한다고 한다면 4,000개의 사서함이 있는 서버는 매일 168,000개의 트랜잭션 로그를 생성할 것입니다. 이는 각 저장소 그룹이 7,304개의 로그를 생성한다는 것을 의미합니다. 사서함 중 10%는 특정 요일(토요일)마다 이동되고 백업 영역에는 매주 전체 백업 및 일일 증분 백업이 포함됩니다. 또한 서버에서는 로그 자르기 없이 3일이 허용될 수 있습니다. 다음 표에서와 같이 이 서버에는 각 저장소 그룹에 대한 38.8GB의 공간이 필요합니다.

로그 용량 요구 사항

저장소 그룹당 로그	로그 파일 크기	일별 로그 크기	사서함 이동 크기	증분 복원 크기	로그 크기 요구 사항
7,304	1MB	7.13GB	17GB (17 × 1GB)	21.4GB (3 × 7.13GB)	38.8GB (17.4 + 21.4)

트랜잭션 로그 LUN은 사서함 이동 작업에 의해 생성된 두 로그를 모두 처리할 만큼의 크기와 한 주 전체의 로그를 복구할 만큼의 공간을 보유해야 합니다.

트랜잭션 I/O

트랜잭션 I/O는 서버를 사용하는 사용자에 의해 생성되는 디스크 I/O입니다. 예를 들어, 항목 받기, 보내기, 삭제 등의 작업 과정에서 디스크 I/O가 생성됩니다. 캐시된 Exchange 모드를 사용하지 않는 Microsoft Outlook 사용자의 경우 디스크 대기 시간이 불량하면 직접적으로 영향을 받으며, 이는 저장소 디자인 과정에서 가장 주요한 문제입니다. 저장소의 경우 트랜잭션 I/O 요구 사항이 낮아졌으며 연속 복제를 사용하는 경우에는 고가의 파이버 채널 저장소를 사용하지 않아도 고가용성을 달성할 수 있습니다. 그러나 가능한 경우에는 파이버 채널 저장소를 사용하는 것이 좋습니다.

IOPS 이해

이전 버전의 Exchange Server에서 저장소 크기를 조정하는 데 필요한 주요 메트릭 중 하나는 각 사용자가 사용하는 IOPS(초당 데이터베이스 I/O)의 양입니다. 사용자 IOPS를 측정하려면 저장소 그룹에 대해 데이터베이스 LUN에서 I/O(읽기 및 쓰기) 양을 측정한 다음 해당 값을 저장소 그룹에 있는 사용자 수로 나눕니다. 예를 들어, 데이터베이스 LUN에서 1,000명의 사용자가 1,000개의 I/O를 생성하는 경우 사용자당 IOPS는 1.0입니다.

기본 IOPS 측정

이전 버전의 Exchange Server를 사용 중인 경우 기본 IOPS를 측정했다면 Exchange 2007에서는 해당 기본 IOPS가 다음과 같은 방식으로 영향을 받을 수 있습니다.

• 서버의 사용자 수는 사용자당 전체 데이터베이스 캐시에 영향을 줍니다.

• RAM의 양은 데이터베이스 캐시가 커질 수 있는 최대 크기에 영향을 줍니다. 데이터베이스 캐시가 커지면 캐시 읽기 적중 횟수가 많아지므로 데이터베이스 읽기 I/O가 줄어듭니다.

여기서 요점은 특정 서버에 대한 IOPS를 파악하는 것만으로는 전체 엔터프라이즈를 계획할 수 없다는 것입니다. RAM의 양, 사용자 수 및 저장소 그룹의 수는 각 서버마다 다르기 때문입니다. 실제 IOPS 수치가 나오면 항상 계산된 값에 20%의 I/O 오버헤드 요소를 적용하여 예약 공간을 추가해야 합니다. 이전보다 작업이 많아졌다고 해서 사용자 환경 전체의 성능이 저하되어서는 안 되기 때문입니다.

데이터베이스 캐시

64비트 버전의 Exchange 2007을 실행 중인 64비트 Windows Server 운영 체제에서는 가상 주소 공간이 크게 증가하며 Exchange에서는 해당 데이터베이스 캐시를 늘리고 데이터베이스 읽기 I/O를 줄이고 서버당 데이터베이스를 최대 50개까지 사용할 수 있습니다.

데이터베이스 읽기 작업 감소는 서버에서 사용할 수 있는 데이터베이스 캐시의 양과 사용자 메시지 프로필에 따라 달라집니다. 메모리 및 저장소 그룹에 대한 지침은 프로세서 구성 계획을 참조하십시오. 해당 항목의 지침을 따르면 Exchange 2003에 비해 트랜잭션 I/O를 최대 70%까지 줄일 수 있습니다. 사용자당 데이터베이스 캐시 양은 실제 I/O를 줄이는 데 있어서 핵심적인 요소입니다.

다음 표에서는 Exchange 2003의 기본 크기인 900MB와 Exchange 2007의 사용자당 데이터베이스 캐시 크기인 5MB를 비교할 때 사용자당 실제 데이터베이스 캐시가 증가했음을 보여줍니다. 이와 같은 추가 데이터베이스 캐시로 인해 캐시의 읽기 횟수가 많아지므로 디스크 수준의 데이터베이스 읽기 작업이 줄어듭니다.

사서함 수를 기준으로 한 데이터베이스 캐시 크기

사서함 수	사서함당 Exchange 2003 데이터베이스 캐시(MB)	사서함당 Exchange 2007 데이터베이스 캐시(MB)	Exchange 2003과 비교한 데이터베이스 캐시 증가량
4,000	0.225	5	23배
2,000	0.45	5	11배
1,000	0.9	5	6배
500	1.8	5	3배

Exchange 2007 기본 IOPS 예측

Exchange 2007 데이터베이스 IOPS를 예측하는 데 사용할 수 있는 두 주요 요소는 각 사용자가 매일 주고받는 사용자당 데이터베이스 캐시 크기와 메시지 수입니다. 다음 공식은 캐시된 Exchange 모드에서 Office Outlook 2007을 사용하는 표준 근로자를 기준으로 +/- 20% 내의 정확도로 테스트되었습니다. 다른 클라이언트 유형과 사용 시나리오에서는 부정확한 결과가 산출될 수 있습니다. 예상치는 2MB 및 5MB 사이 사용자 데이터베이스 캐시 크기에 대해서만 유효합니다. 공식은 매일 150개 이상의 메시지를 주고받는 사용자의 경우 유효하지 않습니다. 공식에 적절한 평균 메시지 크기는 50KB이었지만 IOPS의 경우 메시지 크기가 기본 요소는 아닙니다.

다음 표에서는 기본 Exchange 2007 IOPS 요구 사항을 예측하는 데 사용할 수 있는 사용자당 IOPS의 예상 값을 제공합니다.

사용자 프로필과 메시지 작업에 기반한 데이터베이스 캐시 및 예측된 사용자당 IOPS

사용자 유형(사용 프로필)	하루에 약 50KB의 메시지 크기를 보내기/받기	사용자당 데이터베이스 캐시	사용자당 예측된 IOPS
낮음	5개 보냄/20개 받음	2MB	0.11
평균	10개 보냄/40개 받음	3.5MB	0.18
높음	20개 보냄/80개 받음	5MB	0.32
매우 높음	30개 보냄/120개 받음	5MB	0.48
가장 높음	40개 보냄/160개 받음	5MB	0.64

데이터베이스 캐시 크기를 예측하려면 Exchange 서버에 설치된 전체 메모리 크기에서 2,048MB(LCR(로컬 연속 복제)을 사용하는 경우 3,072MB)를 빼고 이 값을 사용자 수로 나눕니다. 예를 들어, 3,000명의 사용자와 16GB의 RAM을 가진 서버의 경우 시스템에서 2GB를 빼고 14GB의 RAM 또는 사용자당 4.66MB(14GB ÷ 3,000 = 4.66MB)를 남겨 둡니다.

평균 사용자당 데이터베이스 캐시 크기가 4.66MB이고 매일 주고받는 평균 메시지 수가 60인 것을 알고 있다면 데이터베이스 읽기 및 쓰기를 모두 예측할 수 있습니다.

• 데이터베이스 읽기   하루당 60개의 메시지에 0.0048을 곱하면 0.288이 됩니다. 그런 다음 사서함당 데이터베이스 캐시 크기(4.66MB)에 -0.65승(5 ^ -0.65)을 곱하면 0.3622가 됩니다. 마지막으로 둘을 곱하면 사용자당 데이터베이스 읽기 값은 0.104(0.288 × 0.3622 = 0.104)가 됩니다.

• 데이터베이스 쓰기   사용자당 메시지 수(60)에 0.00152를 곱하면 사용자당 데이터베이스 쓰기 값은 0.0912가 됩니다.

사용할 공식은 다음과 같습니다.

((0.0048 × M) × (D ^ -0.65)) + (0.00152 × M) = 전체 데이터베이스 IOPS

여기서 M은 사용자당 메시지 수이고 D는 사용자당 데이터베이스 캐시입니다. 사용자당 전체 데이터베이스 IOPS는 읽기 및 쓰기를 모두 더한 값이며 이 예에서는 다음 계산을 통해 0.189 IOPS가 됩니다.

((0.0048 × 60) × (4.66 ^ -0.65)) + (0.00152 × 60) = 0.189

다음 그래프에서는 캐시된 Exchange 모드 및 권장되는 서버 메모리에서 Outlook 2007을 시뮬레이션하는 4,000개의 250MB 사서함을 가진 Exchange 2007을 실행할 경우의 데이터베이스 읽기 및 쓰기 감소를 보여줍니다.

Exchange Server 2003과 비교한 Exchange Server 2007의 IOPS 감소

온라인 모드 클라이언트의 효과

캐시된 Exchange 모드 클라이언트와 달리 모든 온라인 모드 클라이언트 작업은 데이터베이스에 대해 발생합니다. 결과적으로 읽기 I/O 작업이 데이터베이스에 대해 증가합니다. 따라서 대부분의 클라이언트가 온라인 모드에서 작동할 경우를 위한 다음과 같은 지침이 마련되었습니다.

• 250MB 온라인 모드 클라이언트는 캐시된 Exchange 모드 클라이언트와 비교했을 때 데이터베이스 읽기 작업을 1.5배 증가시킵니다. 250MB 미만인 경우 거의 영향을 주지 않습니다.

• 사서함 크기가 두 배가 되면 데이터베이스 읽기 IOPS도 두 배가 됩니다(주요 폴더 간의 동등 항목 배포가 동일하게 유지된다고 가정).

다음 그래프에서는 사서함 크기에 기초한 IOPS를 보여줍니다.

사서함 크기가 증가하면 데이터베이스 읽기 IOPS가 증가함

사서함당 5MB를 초과하여 데이터베이스 캐시를 늘려도 데이터베이스 읽기 I/O 요구 사항이 크게 감소하지 않는다는 것이 테스트를 통해서 밝혀졌습니다. 다음 그래프에서는 온라인 모드 클라이언트를 사용하는 2GB 사서함과 캐시를 5MB를 초과하여 늘릴 경우 데이터베이스 읽기 I/O 요구 사항이 감소하는 효과를 보여줍니다.

사서함당 캐시 크기가 증가하면 데이터베이스 읽기 IOPS가 감소함

이 데이터의 결과로 인해 다음과 같은 두 가지 사항을 권장할 수 있습니다.

• 해당될 경우 캐시된 모드 클라이언트를 배포합니다. 자세한 내용은 아래의 "폴더당 항목 수" 섹션을 참조하십시오.

• 데이터베이스 저장소를 디자인할 때 I/O 요구 사항이 고려되는지 확인합니다.

타사 클라이언트와 같은 추가 IOPS 요소에 대한 자세한 내용은 Exchange Server 2003의 저장소 최적화를 참조하십시오.

데이터베이스 읽기/쓰기 비율

Exchange 2003에서 데이터베이스 읽기/쓰기 비율은 보통 2:1(읽기 66%)입니다. Exchange 2007을 사용하는 경우 데이터베이스 캐시가 커지면 디스크의 데이터베이스에 대한 읽기 횟수가 감소하여 읽기가 전체 I/O의 백분율로 줄어듭니다. 권장 메모리 지침을 따르며 캐시된 Exchange 모드를 사용하는 경우 읽기/쓰기 비율은 1:1(각 50%)에 근접해야 합니다.

Outlook을 온라인 모드로 사용하거나 데스크톱 검색 엔진을 사용하는 경우에는 사서함 크기에 따라 읽기/쓰기 비율에서 읽기 쪽이 약간 커집니다. 전체 I/O 비율에서 쓰기 값이 더 크면 RAID(Redundant Array of Independent Disks)를 선택할 때 쓰기와 관련한 비용이 많이 드는 RAID5나 RAID6 등의 RAID 형식을 선택하는 경우 문제가 될 수 있습니다. 서버에 사용할 적절한 RAID 솔루션을 선택하는 방법에 대한 자세한 내용은 저장소 기술을 참조하십시오.

데이터베이스 비율 기록

Exchange 2003에서 저장소 그룹의 트랜잭션 로그에는 해당 저장소 그룹에 있는 데이터베이스 수의 약 10%에 해당하는 I/O가 필요합니다. 예를 들어, 데이터베이스 LUN에서 1,000개의 I/O를 사용하는 경우 로그 LUN에서는 약 100개의 I/O를 사용합니다. Exchange 2007에서는 데이터베이스 읽기 횟수가 감소할 뿐 아니라 로그 파일 크기가 작아지고 더 많은 저장소 그룹을 사용할 수 있으므로 로그 대 데이터베이스 쓰기 비율은 약 3:4가 됩니다. 예를 들어, 데이터베이스 LUN에서 500개의 쓰기 I/O를 사용하는 경우 로그 LUN에서는 약 375개의 쓰기 I/O를 사용합니다.

트랜잭션 로그 I/O를 측정 또는 예측한 후에는 정상적인 경우보다 사용량이 많은 시기에 대해 적절한 공간을 제공할 수 있도록 20%의 오버헤드 요소를 적용합니다. 또한 연속 복제를 사용하는 경우에는 닫힌 트랜잭션 로그를 읽은 다음 두 번째 위치로 보내야 합니다. 이 오버헤드로 인해 로그 읽기에 10%의 공간이 더 추가됩니다. 즉, 저장소 그룹의 트랜잭션 로그에서 375개의 쓰기 I/O를 사용하는 경우 연속 복제를 사용할 때는 37.5개의 읽기 I/O가 더 추가됩니다.

폴더당 항목 수

많은 항목 수와 제한된 보기가 성능에 미치는 영향 이해에는 일부 사용자의 디스크 성능에 필수 폴더의 항목 수 및 사용 중인 클라이언트의 유형과 모드가 미치는 영향에 대한 설명이 나와 있습니다.

서버 I/O를 줄일 수 있는 한 가지 방법은 캐시된 Exchange 모드로 Outlook 2007을 사용하는 것입니다. 초기 사서함 동기화에는 비용이 많이 들지만 시간이 지나면서 사서함 크기가 커지면 디스크 하위 시스템의 작업이 Exchange 서버에서 Outlook 클라이언트로 이동하게 됩니다. 즉, 사용자의 받은 편지함에 항목 수가 많거나 사용자가 사서함을 검색하고 있어도 서버의 성능에는 거의 영향이 없습니다. 또한 적절한 성능에 대한 개별 사용자의 임계값에 따라, 캐시된 Exchange 모드를 사용하며 대규모 사서함을 보유한 사용자의 경우 사서함 크기가 작은 사용자에 비해 속도가 빠른 컴퓨터가 필요할 수 있습니다. Outlook 2007을 실행하는 클라이언트 컴퓨터를 캐시된 Exchange 모드에서 배포할 때는 사서함/.OST 크기와 관련하여 다음 사항을 고려하십시오.

• 5GB 이하의 크기: 대부분의 하드웨어에서는 사용자 환경에 이 크기를 지정하는 것이 좋습니다.

• 5GB - 10GB의 크기: 대개 하드웨어에 따라 크기가 달라집니다. 따라서 하드 디스크 속도가 빠르고 RAM이 많은 경우에는 환경 성능이 훨씬 좋아집니다. 그러나 대부분의 휴대용 컴퓨터 드라이브 또는 이전 세대의 SSD(반도체 드라이브) 등과 같은 속도가 느린 하드 드라이브의 경우에는 드라이브 응답 시 일부 응용 프로그램이 일시 중지됩니다.

• 10GB 이상의 크기: 대부분의 하드웨어에서 응용 프로그램이 잠깐 동안 일시 중지됩니다.

• 매우 큰 크기(25GB 이상): 짧은 시간 동안 발생하는 일시 중지 빈도가 늘어납니다. 특히 새 전자 메일을 다운로드할 때 자주 일시 중지됩니다. 보내기/받기 그룹을 사용해 메일을 수동으로 동기화할 수도 있습니다.

캐시된 Exchange 모드 배포에서 Outlook 2007에 성능 관련 문제가 발생하는 경우에는 기술 자료 문서 940226, Outlook 2007에서 성능 문제를 해결하는 방법을 참조하십시오.

온라인 모드에서 Outlook Web Access 및 Outlook은 모두 서버의 데이터 복사본에 대해 인덱스를 저장하고 검색을 수행합니다. 중간 정도 크기인 사서함의 경우에는 이렇게 하면 적절한 크기의 캐시된 Exchange 모드 클라이언트의 사서함당 IOPS의 크기가 약 두 배가 됩니다. 그리고 큰 사서함의 사서함당 IOPS는 더욱 커집니다. 보기를 새로운 방식으로 처음 정렬하면 인덱스가 만들어져 데이터베이스 LUN에 대해 많은 읽기 I/O가 생성됩니다. 이 작업이 수행된 이후로는 활성 인덱스에 대해 저렴하게 정렬 작업을 수행할 수 있습니다.

문제가 될 수 있는 시나리오는 사용자가 Exchange에서 저장할 수 있는 인덱스 수를 초과하여 저장한 경우(Exchange 2007의 경우 11개 인덱스)입니다. 이 경우 사용자가 새로운 방식으로 보기를 정렬하도록 선택하여 12번째 인덱스를 만들면 디스크 I/O가 추가로 생성됩니다. 해당 인덱스는 저장되지 않으므로 이 디스크 I/O 비용은 정렬을 수행할 때마다 발생합니다. 이 시나리오에서는 많은 I/O가 생성될 수 있기 때문에 받은 편지함 및 보낸 편지함 폴더 등의 주요 폴더에 20,000개가 넘는 항목을 저장하지 않는 것이 좋습니다. 보다 상위 수준의 폴더를 만들거나 받은 편지함 및 보낸 편지함 폴더 아래에 하위 폴더를 만들면 한 폴더에 포함된 항목 수가 20,000개를 넘지 않는 한 이러한 인덱스 작성 작업과 관련된 비용이 크게 줄어듭니다. 사서함 서버 성능에 항목 개수가 미치는 영향에 대한 자세한 내용은 Recommended Mailbox Size Limits(영문) 및 많은 항목 수와 제한된 보기가 성능에 미치는 영향 이해를 참조하십시오.

제공되고 있는 향상된 기능에 대한 자세한 내용은 기술 자료 문서 968009, Outlook 2007 improvements in the February 2009 cumulative update(영문)를 참조하십시오.

비트랜잭션 I/O

트랜잭션 I/O는 직접적인 사용자 작업에 대한 응답으로 발생하며 보통 우선 순위가 가장 높고 저장소 디자인을 중심으로 합니다. 트랜잭션 I/O가 감소하면 비트랜잭션 I/O의 중요성이 높아집니다. 대규모 사서함, 특히 2GB 사서함의 경우 대부분의 엔터프라이즈에서는 사용자 용량을 두 배로 늘리지 않습니다. 일부 경우에는 용량을 10배로 늘리기도 합니다. 200MB의 사서함에서 2GB의 사서함으로 이동하는 경우를 예로 들 수 있습니다. 이와 같이 디스크의 데이터 양이 크게 늘어나면 저장소 디자인을 계획할 때 비트랜잭션 I/O도 고려 및 계산해야 합니다.

콘텐츠 인덱싱

Exchange 2007에서는 받은 메시지를 인덱싱하므로 디스크 I/O 오버헤드가 거의 발생하지 않습니다. Exchange 2007에서 인덱스를 검색하는 작업의 속도가 Exchange 2003보다 약 30배 빨라졌습니다.

메시징 레코드 관리

MRM(메시징 레코드 관리) MRM은 관리자 및 사용자가 사서함을 관리할 수 있도록 하는 Exchange 2007의 새로운 기능입니다. 기간 등의 특정 임계값을 충족하는 메일은 이동 또는 삭제하도록 정책을 설정할 수 있습니다. MRM은 백업 및 온라인 유지 관리와 유사한 동기 읽기 작업에서 데이터베이스에 대해 실행되는 예약된 크롤링입니다. MRM의 디스크 비용은 삭제 또는 이동 등 작업을 수행해야 하는 항목 수에 따라 달라집니다.

MRM은 백업 또는 온라인 유지 관리와 동시에 실행하지 않는 것이 좋습니다. 연속 복제를 사용하는 경우에는 VSS(볼륨 섀도 복사본 서비스) 백업을 수동 복사본으로 오프로드하여 온라인 유지 관리 및 MRM에 더 많은 작업 시간을 허용함으로써 각 작업이 상호 또는 사용자에게 영향을 주지 않도록 할 수 있습니다.

온라인 유지 관리

데이터베이스에서 영구적으로 삭제된 항목을 제거하고 데이터베이스에 대해 온라인 조각 모음을 수행하는 등의 온라인 유지 관리를 실행하는 동안에는 여러 가지 작업이 수행됩니다. 유지 관리를 실행하면 읽기가 수행되는 반면 온라인 조각 모음을 실행하면 읽기와 쓰기가 모두 수행됩니다. 유지 관리 작업을 완료하는 데 걸리는 시간은 데이터베이스의 크기에 비례하며 데이터베이스가 커질 수 있는 최대 크기를 제한하는 요소가 될 수 있습니다. 온라인 유지 관리에 대한 자세한 내용은 Store Background Processes Part I을 참조하십시오.

백업 및 복원

관리자가 사용할 수 있는 다양한 백업 및 복원 방법이 있습니다. 백업 및 복원과 관련된 주요 메트릭은 처리량, 즉 프로덕션 LUN에 대해 복사할 수 있는 초당 MB 수입니다. 처리량을 확인한 후에는 해당 수치가 SLA(서비스 수준 계약) 백업 및 복원을 충족하기에 충분한지를 결정해야 합니다. 예를 들어, 백업을 4시간 이내에 완료해야 한다면 작업 완료를 위해 하드웨어를 더 추가할 수 있습니다. 하드웨어 구성에 따라 할당 단위 크기를 변경함으로써 이점을 얻을 수도 있습니다. 이는 스트리밍 온라인 백업과 VSS 백업 중에 수행되는 Exchange Server 데이터베이스 유틸리티(Eseutil.exe) 무결성 검사 모두에 도움이 됩니다.

특정 서버에 2,000명의 사용자가 있는 경우 200MB 사서함에서 2GB 사서함으로 이동하면 데이터베이스 크기가 10배 커집니다. 대부분의 관리자는 하나의 서버에서 많은 양의 데이터를 처리하는 데 익숙하지 않습니다. 2GB 크기의 사서함이 2,000개 있다고 가정해 봅시다. 위에서 설명한 오버헤드를 추가하면 데이터의 양은 4TB가 넘습니다. 시간당 175GB(분당 48MB)의 속도로 백업을 수행할 수 있다고 해도 서버를 백업하는 데 최소한 23시간이 걸립니다. LCR 또는 CCR을 사용하지 않는 서버에 대해 사용할 수 있는 다른 방법은 다음 표에 나와 있는 것처럼 매일 데이터베이스의 1/7에 해당하는 데이터에 대해 전체 백업을 수행하고 나머지 부분에 대해서는 증분 백업을 수행하는 것입니다.

주별 백업 절차 예

백업 유형	1일	2일	3일	4일	5일	6일	7일
전체	데이터베이스 1-2	데이터베이스 3-4	데이터베이스 5-6	데이터베이스 7-8	데이터베이스 9-10	데이터베이스 11-12	데이터베이스 13-14
증분	데이터베이스 3-14	데이터베이스 1-2 데이터베이스 5-14	데이터베이스 1-4 데이터베이스 7-14	데이터베이스 1-6 데이터베이스 9-14	데이터베이스 1-8 데이터베이스 11-14	데이터베이스 1-10 데이터베이스 13-14	데이터베이스 1-12

위 표에서 볼 수 있듯이 야간에 백업되는 전체 데이터 양은 약 650GB입니다. 시간당 175GB의 속도로 백업을 수행한다고 가정하면 이 작업은 3.7시간이면 완료됩니다. 일부 솔루션의 경우에는 처리량이 보다 많거나 적을 수도 있지만 대규모 사서함의 경우에는 여러 가지 다른 방식을 사용해야 할 수도 있습니다.

LCR 및 CCR의 경우 수동 복사본은 최우선적인 방어책입니다. 활성 복사본과 수동 복사본에 모두 오류가 발생하거나 사용할 수 없는 경우 백업에서만 복구할 수 있습니다. 여러 날짜에 해당하는 증분 로그를 복구하면 복구 시간이 길어질 수 있습니다. 그러므로 CCR 또는 VSS 복제본 같은 빠른 복구 솔루션에서는 증분 백업을 거의 사용하지 않습니다. VSS 복제를 사용하는 경우에는 데이터가 빠르게 복구되며 백업 시간을 백업 SLA 내로 유지하기 위해 로그 재생 시간을 약간 추가해도 됩니다.

스트리밍 온라인 백업

스트리밍 백업을 사용하는 경우에는 스트리밍 I/O(원본 및 대상)를 분리하여 동시에 백업되는 여러 저장소 그룹이 동일한 디스크 리소스에 대해 경쟁하지 않도록 하는 것이 좋습니다. 대상이 디스크이든 테이프이든 관계없이 각 하드웨어 솔루션에 대해 고유하게 적용되는 실제 디스크 및 컨트롤러의 처리량 제한이 있습니다. 일부 저장소 그룹을 서로 격리하여 동시 백업 작업 수를 최대화하고 처리량을 격리하여 백업 창 크기를 최소화해야 할 수도 있습니다. 다음 표에서는 14개의 데이터베이스가 두 개의 동시 백업을 수행하는 예를 설명합니다.

동시 백업 절차 예

백업 번호	LUN 1	LUN 2	LUN 3	LUN 4	LUN 5	LUN 6	LUN 7
첫 번째 백업	SG(저장소 그룹) 1	SG 2	SG 3	SG 4	SG 5	SG 6	SG 7
두 번째 백업	SG 8	SG 9	SG 10	SG 11	SG 12	SG 13	SG 14

위 표에서 설명한 것과 같이 저장소 그룹 LUN을 서로 간에 분리할 경우 각 LUN에서 스트리밍 백업을 동시에 실행할 수 있습니다. 백업 작업은 두 번째 저장소 그룹이 백업 스트림을 분리하며 백업을 시작하기 전에 각 LUN의 기본 저장소 그룹에서 완료해야 합니다. 동일한 실제 디스크에서 수행되는 두 가지 스트리밍 백업 작업의 속도가 두 배가 되지는 않더라도 초당 메가바이트 속도로 단일 스트리밍 백업 작업보다는 빨라야 합니다.

VSS 백업

Exchange 2007에서는 Windows Server 2003에 포함된 VSS를 사용하여 데이터베이스 및 트랜잭션 로그 파일의 볼륨 섀도 복사본을 만듭니다. 복제 및 스냅숏 기술을 모두 포함하는 VSS에 대한 자세한 내용은 Exchange Server 2003에서 볼륨 섀도 복사본 서비스 사용에 대한 모범 사례를 참조하십시오. Exchange 2007의 새로운 기능을 통해 LCR 또는 CCR 환경에서 실행하는 저장소 그룹의 수동 복사본을 VSS 백업할 수 있습니다. 이러한 환경에서 수동 복사본으로부터 VSS 스냇숏을 가져오면 백업에 대한 체크섬 무결성 단계와 테이프 또는 디스크에 대한 후속 복사 작업 중 일어나는 활성 LUN에서의 디스크 부하를 없앨 수 있습니다. 또한 온라인 유지 보수, MRM 및 기타 작업을 실행하기 위한 활성 LUN에서의 시간을 단축합니다.

LUN 및 실제 디스크

대부분의 경우 운영 체제에서 인식하는 실제 디스크 또는 LUN은 운영 체제에 디스크를 제공하는 데 사용되는 하드웨어에서 요약됩니다. 성능 및 복구를 위해 트랜잭션 로그 파일을 항상 LUN과 실제 디스크 수준에 있는 데이터베이스 파일과 분리하는 것이 중요합니다. 동일한 실제 디스크에서 임의 및 순차 디스크 I/O를 혼합하면 성능이 크게 저하되며 복구 측면에서 볼 때 저장소 그룹의 로그 파일과 데이터베이스 파일을 분리하면 하나의 실제 디스크 집합에 오류가 발생해도 데이터베이스 파일과 로그 파일은 모두 손실되지 않습니다.

Exchange 2007에서는 한 저장소 그룹에 있는 모든 데이터베이스를 동일한 실제 LUN에 배치하는 것이 좋습니다. 또한 각 저장소 그룹에 데이터베이스를 하나만 배치하는 것이 좋습니다. Exchange 데이터베이스 I/O는 임의 입출력이므로 실제 디스크에서 동일한 작업 부하를 수행할 때는 대부분의 저장소 하위 시스템이 유용합니다. 대부분의 저장소 배열은 먼저 다양한 실제 디스크가 디스크 그룹으로 그룹화된 다음 해당 디스크 그룹의 사용 가능한 공간에서 LUN이 만들어지고 모든 실제 디스크에 동일하게 분배되도록 디자인됩니다. 저장소 그룹의 데이터베이스 LUN을 백업 중인 실제 디스크에서는 다른 저장소 그룹과 서버의 데이터베이스가 들어 있는 다른 LUN을 백업할 수도 있습니다. 마찬가지로 순차 I/O 손실이 성능에 약간의 영향을 주는 경우에도 저장소 그룹의 트랜잭션 로그 LUN을 별도의 실제 스핀들로 격리하지 않는 것이 좋습니다.

최대 50개의 저장소 그룹이 단일 서버에 구성되어 있는 경우 각 저장소 그룹에 대해 고유한 트랜잭션 로그 LUN 및 데이터베이스 LUN을 지정해야 합니다. LUN이 사용 가능한 드라이브 문자 수를 초과하면 NTFS 파일 시스템 볼륨 탑재 지점을 사용해야 합니다. 연속 복제용으로 구성된 50개의 저장소 그룹에는 200개의 LUN이 필요하며, 특히 200개의 LUN을 모두 단일 서버에 제공해야 하는 LCR의 경우 이 LUN은 일부 저장소 배열 최대값을 초과할 수 있습니다. LUN 수가 증가하면 디스크 공간 부족으로 인해 해당 저장소 그룹이 분리될 수 있으므로 모니터링이 더욱 중요합니다.

LUN 디자인

대부분의 경우 운영 체제에서 인식하는 LUN은 실제로 해당 디스크가 구성되어 있는 실제 하드웨어에서 요약됩니다. 성능 및 복구 기능을 향상시키려면 항상 LUN 및 실제 디스크 수준에서 모두 데이터베이스의 트랜잭션 로그를 분리해야 합니다. 일부 저장소 배열의 경우에는 임의의 I/O와 순차 I/O가 같은 실제 디스크에 혼합되어 있어 성능이 저하될 수 있습니다. 복구의 측면에서 볼 때 저장소 그룹의 트랜잭션 로그와 데이터베이스를 분리하면 특정 실제 디스크 집합에서 오류가 발생해도 데이터베이스와 트랜잭션 로그가 모두 손실되는 일이 없도록 할 수 있습니다.

Exchange 데이터베이스 I/O는 임의성이 있으며 이는 실제 디스크에서 동일한 작업 부하를 수행할 때 대부분의 저장소 하위 시스템에 도움이 됩니다. 대부분의 저장소 배열은 먼저 다양한 실제 디스크가 디스크 그룹으로 그룹화되도록 가상 저장소를 사용합니다. 그런 다음 해당 디스크 그룹의 사용 가능한 공간에서 LUN이 만들어져 모든 실제 디스크에 동일하게 분배됩니다. 연속 복제를 사용하지 않는 경우에는 저장소 그룹의 데이터베이스 LUN을 백업 중인 실제 디스크에서는 다른 저장소 그룹과 서버의 데이터베이스가 들어 있는 다른 LUN을 백업할 수도 있습니다. 마찬가지로 순차 I/O 손실이 성능에 약간의 영향을 주는 경우에도 저장소 그룹의 트랜잭션 로그 LUN을 별도의 실제 스핀들로 격리하지 않는 것이 좋습니다. 같은 저장소 그룹의 로그 및 데이터베이스 LUN을 별도의 실제 디스크로 분리해야 합니다. 30 IOPS 및 5%의 용량이 필요한데 2개 또는 4개의 500GB 실제 디스크를 단일 저장소 그룹의 트랜잭션 로그 LUN 전용으로 사용하는 것은 적절하지 않습니다.

Exchange 2007에서는 다양한 방식으로 LUN을 디자인할 수 있지만 LUN이 복잡해지지 않도록 다음과 같은 두 가지 디자인 방식을 사용하는 것이 좋습니다.

• 저장소 그룹당 LUN 2개

• 백업 세트당 LUN 2개

저장소 그룹당 LUN 2개

저장소 그룹당 2개의 LUN(로그와 데이터베이스에 대해 각각 하나씩)을 만드는 것이 Exchange 2003의 표준 최상의 방법이었습니다. Exchange 2007을 사용하는 경우 최대 50개의 저장소 그룹이 있으면 제공해야 하는 LUN의 수는 백업 전략에 따라 달라집니다. RTO가 낮거나 빠른 복구를 위해 VSS 복제본을 사용하는 경우에는 각 저장소 그룹을 고유한 트랜잭션 로그 LUN 및 데이터베이스 LUN에 배치하는 것이 좋습니다. 이렇게 하면 사용 가능한 드라이브 문자 수가 초과되어 볼륨 탑재 지점을 사용해야 하기 때문입니다.

이 전략을 사용하는 경우의 몇 가지 이점은 다음과 같습니다.

• 하드웨어 기반 VSS를 저장소 그룹 수준에서 사용할 수 있으므로 단일 저장소 그룹 백업 및 복원을 수행할 수 있습니다.

• 저장소 그룹 간의 성능을 유동적으로 격리할 수 있습니다.

• 안정성을 높일 수 있습니다. 단일 LUN에서 발생하는 용량, 손상 또는 바이러스 문제가 하나의 저장소 그룹에만 영향을 주기 때문입니다.

이 전략을 사용하는 경우의 몇 가지 문제점은 다음과 같습니다.

• 연속 복제를 사용하는 50개의 저장소 그룹에는 200개의 LUN이 필요하며, 특히 200개의 LUN을 모두 단일 서버에 제공해야 하는 LCR의 경우 이 LUN은 일부 저장소 배열 최대값을 초과할 수 있습니다.

• 각 저장소 그룹에 별도의 LUN을 지정하면 서버당 더 많은 LUN이 필요하므로 관리 비용이 증가합니다.

백업 세트당 LUN 2개

백업 세트는 야간에 전체 백업되는 여러 데이터베이스의 집합입니다. 데이터베이스의 1/7 분량에 대해 야간에 전체 백업을 수행하는 솔루션을 사용하면 동일한 로그 및 데이터베이스 LUN에 대해 백업할 모든 저장소 그룹을 배치하여 복잡도를 낮출 수 있습니다. 또한 이렇게 하면 서버의 LUN 수도 줄일 수 있습니다.

이 전략을 사용하는 경우의 몇 가지 이점은 다음과 같습니다.

• 관리할 LUN 수가 줄어들기 때문에 저장소 관리 작업이 간편해집니다.

• 백업 작업의 수도 줄일 수 있습니다.

이 전략을 사용하는 경우의 몇 가지 문제점은 다음과 같습니다.

• 하드웨어 기반 VSS 백업 및 복원을 수행하는 기능이 제한됩니다.

• MBR(마스터 부트 레코드) 파티션이 2TB로 제한되므로 용량 조정 범위가 제한됩니다.

볼륨 탑재 지점

다중 노드 SCC(단일 복사 클러스터) 등과 같이 사용 가능한 드라이브 문자보다 더 많은 LUN이 필요한 경우가 많습니다. 이러한 경우에는 볼륨 탑재 지점을 사용해야 합니다. 드라이브 문자는 파티션 또는 디스크를 인식하기 위한 레거시 MS-DOS 운영 체제 기능이므로 너무 많이 사용하지 않는 것이 좋습니다. 관리 작업을 쉽게 수행할 수 있도록 모든 트랜잭션 로그 및 데이터베이스 LUN을 볼륨 탑재 지점에 배치하는 것이 훨씬 간편합니다. 20개의 저장소 그룹이 있고 각 저장소 그룹이 데이터베이스에 연결되어 있는 경우 데이터베이스 17의 드라이브 문자를 기억하는 것은 어렵습니다. 다음 표에서는 볼륨 탑재 지점을 사용한 예에 대해 설명합니다.

볼륨 탑재 지점을 사용한 폴더 레이아웃의 예

트랜잭션 로그 (L:)	데이터베이스 (P:)
L:\SG1LOG	P:\SG1DB
L:\SG2LOG	P:\SG2DB
L:\SG3LOG	P:\SG3DB
L:\SG4LOG	P:\SG4DB

이 예에서 L:과 P:는 앵커 LUN이며 모든 로그와 데이터베이스 LUN이 개별적으로 포함되어 있습니다. 이러한 드라이브의 각 폴더는 개별 LUN에 대한 볼륨 탑재 지점입니다.

하드웨어 기반 VSS

하드웨어 기반 VSS를 사용할 때는 Exchange 데이터를 LUN에 배치할 때 필요한 몇 가지 권장 사항을 확인해야 합니다. 하드웨어 기반 VSS 솔루션의 경우 각 트랜잭션 로그 LUN 및 데이터베이스 LUN에는 선택한 백업 세트의 파일만 포함되어야 합니다. 다른 저장소 그룹에는 영향을 주지 않고 특정 저장소 그룹을 복원하려는 경우에는 각 저장소 그룹에 대해 별도의 트랜잭션 로그 LUN 및 데이터베이스 LUN이 필요합니다. 다른 데이터베이스 및 저장소 그룹을 오프라인으로 설정하고 단일 데이터베이스를 복원하려는 경우에는 단일 트랜잭션 로그 LUN 및 데이터베이스 LUN에 여러 저장소 그룹을 배치해도 됩니다.

소프트웨어 기반 VSS

소프트웨어 기반 VSS를 사용하는 경우, 특히 대규모 사서함 및 연속 복제를 사용하는 경우의 백업 전략은 두 가지 단계로 구성됩니다. 먼저 VSS 스냅숏을 가져온 다음 플랫 파일을 디스크 또는 테이프로 스트리밍합니다.

LUN 안정성

안정성 향상을 위해 저장소 그룹의 트랜잭션 로그 및 데이터베이스는 항상 별도의 실제 디스크에 배치해야 합니다. 또한 연속 복제를 사용하는 경우에는 활성 LUN과 수동 LUN을 완전히 분리된 저장소에 배치해야 합니다. CCR 및 LCR을 사용하면 기본 저장소에 오류가 발생하는 경우 저장소를 복구할 수 있습니다.

LUN 예

이전 용량 예에서 구성된 해당 정보를 LUN 생성에 적용하는 경우를 예로 들어 보겠습니다. 이 예에서 백업 환경은 매일 수행되는 전체 백업입니다. 콘텐츠 인덱싱을 사용하도록 설정하고 데이터베이스 LUN에 배치합니다. 193GB의 약 5%는 10GB입니다. 이 크기를 최종 LUN 크기에 추가해야 합니다. 193GB에 대한 증가율은 최종 데이터베이스 크기의 20%입니다. 193GB의 20%는 39GB입니다. 다음 표에는 결과가 나와 있습니다.

데이터베이스 LUN 크기를 결정하기 위한 값의 예

데이터베이스 크기	증가율	콘텐츠 인덱싱	데이터베이스 LUN 크기
193GB	39GB	10GB	241GB

각 저장소 그룹은 매일 7.13GB의 로그를 생성하고 최소 3일 간의 로그를 저장합니다.

로그 LUN 크기를 결정하기 위한 값의 예

로그(1일)	로그(3일)
7.13GB	21.4GB

사서함 이동

예를 들어, 조직이 주당 사서함의 10%를 이동하고 토요일에 모든 이동 작업을 수행하기 때문에 로그 LUN은 특정 일에 전체 로드를 처리해야 합니다. Microsoft에서 사용되는 사서함 이동 전략은 각 저장소 그룹의 전반에 걸쳐 들어오는 사용자를 동일하게 분배하는 것입니다. 예를 들어, 4,000명의 사용자를 보유한 서버는 토요일마다 약 400명의 사용자를 이동시킵니다. 다음 표에서와 같이 23개의 저장소 그룹을 가진 경우 각 저장소 그룹은 17개의 1GB 사서함을 받아야 합니다.

사서함 이동 로그 LUN 크기를 결정하기 위한 값의 예

로그(3일)	사서함 이동	로그 LUN 크기
21.4GB	17.64GB(17 1GB 사용자)	46.6GB(38.8GB + 20%)

이 레이아웃에서 하루에 17명 이상의 사용자를 저장소 그룹에 이동할 수 없습니다. 따라서 특정 일에 10% 이상을 이동해야 하는 경우 로그 LUN의 크기를 증가시켜야 합니다.

저장소 디자인에 대한 연속 복제의 영향

연속 복제는 저장소 그룹의 데이터베이스와 로그 파일을 보조 위치로 복사하는 Exchange 2007의 새로운 기능입니다. 새 트랜잭션 로그가 닫히거나 가득 차면 보조 위치로 복사되고 유효성 검사가 수행된 후 데이터베이스의 수동 복사본으로 재생됩니다. 저장소 복구 기능을 수행하려면 활성 프로덕션 LUN에서 완전히 격리된 저장소 배열에 수동 복사본을 배치하는 것이 좋습니다. 실패할 경우 프로덕션 로드는 수동 복사본에 따라 처리되므로 해당 저장소는 저장소 그룹의 활성 복사본에서 사용된 저장소 솔루션의 성능 및 용량과 일치해야 합니다.

연속 복제를 사용할 경우 각 저장소 그룹은 단일 데이터베이스만 포함할 수 있으므로 각 데이터베이스 복사본에는 4개의 LUN이 필요합니다. 각 데이터베이스 복사본은 고유한 저장소 그룹에 포함되며 이 저장소 그룹에는 활성 복사본 및 수동 복사본 각각에 대한 별도의 로그 및 데이터베이스 LUN이 필요합니다.

다음을 수행하는 것이 좋습니다.

• 저장소를 하드웨어 수준의 개별 LUN으로 분리하고 운영 체제 내에서 여러 개의 LUN 논리 파티션을 만들지 않습니다.

• 트랜잭션 로그와 데이터베이스를 분리하고 별도의 논리 디스크에 포함하여 내결함성을 높입니다.

• 저장소가 단일 오류 지점이 되지 않도록 활성 LUN과 수동 LUN을 완전히 다른 저장소 배열로 분리합니다.

• 동일한 저장소 배열에 있는 여러 클러스터된 사서함 서버에서 저장소 그룹이나 데이터베이스를 호스팅할 경우 별개의 실제 디스크를 사용하여 각 LUN이 만들어지는지 확인해야 합니다.

저장소 디자인은 저장소 컨트롤러를 서로 다른 PCI(Peripheral Component Interconnect) 버스로 분리하여 내결함성을 최대화해야 하며, 수동 복사본의 용량 및 성능이 활성 복사본에서 사용된 저장소와 일치하도록 저장소를 디자인해야 합니다. 수동 복사본 저장소는 활성 복사본 저장소에 오류가 발생할 경우 첫 번째 방어 방법이 되고 장애 조치 시 수동 복사본은 활성 복사본이 됩니다. 수동 복사본의 LUN을 완전히 다른 저장소 하드웨어에 배치하면 수동 복사본에 대해 수행된 모든 작업이 활성 복사본에 영향을 주지 않습니다.

연속 복제를 사용하면 트랜잭션 I/O가 증가합니다. 서버 크기를 결정할 때 이 요소를 고려해야 합니다. 순차적 쓰기가 사용되는 활성 트랜잭션 로그의 경우도 로그가 닫힌 후 읽어서 복제본 트랜잭션 로그 LUN 격리 폴더로 복사해야 합니다. 그런 다음 복제본 위치에서 로그가 검사되고 복제본 LUN의 최종 대상으로 이동되어야 합니다. 마지막으로 로그가 읽히고 데이터베이스로 재생됩니다. 활성 및 복제본 트랜잭션 로그 LUN은 모두 읽고 쓰지만 독립 실행형 사서함 서버에서는 거의 100% 순차 쓰기 활동이 발생합니다. 이 작업을 변경하려면 캐시 설정에서 저장소 컨트롤러를 평가해야 할 수 있습니다. 권장되는 설정값은 배터리가 지원되는 저장소 컨트롤러에서 읽기 25% 및 쓰기 75%입니다.

연속 복제 및 데이터베이스 크기

연속 복제를 사용할 때는 최대 데이터베이스 크기를 더 크게 조정할 수 있습니다. Exchange 2007에 대한 최대 데이터베이스 크기를 다음과 같이 설정하는 것이 좋습니다.

• 연속 복제 없이 사서함 서버에서 호스팅되는 데이터베이스: 100GB

• 연속 복제 및 Gigabit 이더넷을 사용하는 사서함 서버에서 호스팅되는 데이터베이스: 200GB

  참고

  대형 데이터베이스는 복구 시나리오를 수용하기 위한 증가된 대역폭을 위해 최신 저장소 기술이 필요할 수 있습니다.

  중요

  데이터베이스의 실제 최대 크기는 조직에서 사용 중인 SLA에 의해 지정되어야 합니다. 조직의 SLA에 지정되어 있는 기간 내에 백업 및 복구할 수 있는 최대 크기의 데이터베이스를 결정하는 것이 데이터베이스의 최대 크기를 결정하는 방법입니다.

LCR 저장소 옵션

LCR을 사용하여 단일 서버에서 로그를 전달할 수 있습니다. 데이터베이스 또는 로그 파일의 활성 복사본이 들어 있는 저장소에 오류가 발생하면 관리자는 데이터베이스의 수동 복사본을 수동으로 활성화할 수 있습니다. 수동 복사본용 저장소는 활성 복사본용 저장소와 완전히 분리되어야 합니다. 또한 다음 항목을 적용해야 합니다.

• 컨트롤러 카드는 서로 다른 PCI 버스에 있어야 합니다.

• 각 저장소 솔루션에는 고유한 UPS(무정전 전원 공급 장치)가 있어야 합니다.

• 각 저장소 솔루션은 별도의 전원 회로에 있어야 합니다.

CCR 저장소 옵션

CCR을 사용하여 활성/수동 장애 조치 클러스터의 수동 노드로 로그를 전달할 수 있습니다. 완전히 다른 서버에 있는 수동 복사본으로 로그를 전달하고 해당 복사본을 유지 관리하면 활성 노드에 대한 영향이 줄어들고 서버에 내결함성이 제공됩니다.

지리적으로 분산된 CCR 배포에서는 수동 복사본이 활성 노드와 다른 실제 위치의 노드에 있을 수 있으므로 사이트 복구 기능을 제공합니다. 문서 Deployment Guidelines for Exchange Server Multi-Site Data Replication의 정보가 계속 적용되지만 연속 복제를 구성하는 풀 기반 기술은 대기 시간이 길어도 사용자 환경에 영향을 미치지 않음을 의미합니다. 이 내용은 동기 복제 대기 시간이 활성 서버에 부정적 영향을 미치는 지리적으로 분산된 클러스터 솔루션과 상반됩니다. CCR의 경우 복제 프로세스가 백그라운드에서 실행될 수 있으므로 활성 복사본과 수동 복사본이 동기화되지 않은 시간이 늘어납니다. 그러나 재해가 활성 복사본에 영향을 미칠 경우 허브 전송 서버의 전송 쓰레기 수거통 기능으로 인해 수동 노드로 복제되지 않은 모든 메시지가 복구될 수 있습니다.

단일 복사본 클러스터 저장소 옵션

SCC에 사용된 하드웨어는 Windows 서버 카탈로그의 클러스터 범주에 표시되어야 합니다. 지리적으로 분산된 SCC에 사용된 하드웨어는 지원할 Windows 서버 카탈로그의 지리적으로 분산된 클러스터 범주에 표시되어야 합니다.

공유 저장소를 사용하는 클러스터된 사서함 서버의 경우 독립 실행형 서버와 동일한 기본 저장소 고려 사항이 있습니다. 동기 복제를 사용할 경우 복제 프로세스를 통해 디스크 대기 시간을 인위적으로 늘릴 수 있습니다. 저장소 배열 내에서 복제 지점을 최대화할 경우 주의해야 합니다. SCC 복제에 대한 자세한 내용은 Exchange Server 다중 사이트 데이터 복제 배포 지침을 참조하십시오.