사서함 데이터베이스 및 로그 용량 요소 이해

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

마지막으로 수정된 항목: 2015-03-09

이 항목에서는 Microsoft Exchange Server 2010의 사서함 서버 저장소 디자인의 일부로 사서함 데이터베이스 및 로그 용량을 계획할 때 고려해야 하는 요소를 설명합니다.

사서함 데이터베이스 용량

Exchange Server 2010 사서함 데이터베이스의 용량 계획에 영향을 미치는 요소는 많습니다. 이 섹션에서는 다음 내용에 대해 설명합니다.

• 사서함 저장소 할당량

• 데이터베이스 공백

• 사서함 데이터베이스 복구 가능한 항목

• 실제 사서함 크기

• 콘텐츠 인덱싱

• 오프라인 데이터베이스 유지 관리

• 복구 데이터베이스

• 데이터베이스 크기

• 데이터베이스 증가 오버헤드

사서함 저장소 할당량

첫 번째로 이해해야 할 메트릭은 조직의 사서함 저장소 할당량, 즉 저장소 크기 제한입니다. 최종 사용자가 사서함에 저장하도록 허용되는 데이터의 양을 알면 해당 서버에 포함할 수 있는 사용자 사서함의 수를 결정할 수 있습니다. 사서함 저장소 할당량은 조직 요구 사항이 변화함에 따라 바뀔 수 있지만 사서함 저장소 할당량 목표를 정하는 것은 필요한 사서함 데이터베이스 용량을 결정하기 위한 첫 번째 단계입니다.

예를 들어 5,000개의 250MB 사용자 사서함이 포함된 서버가 있는 경우 복구 가능한 항목을 위한 공간 요구 사항을 제외하고 최소 1.25TB의 디스크 공간이 필요합니다. 사서함 저장소 할당량에 대한 제한이 설정되지 않으면 데이터베이스 용량을 계산하기가 어렵습니다. Exchange 2010에 대한 사서함 저장소 할당량에는 기본 사서함과 개인 보관 파일 사서함(사용되는 경우)을 위한 공간이 모두 포함되어야 합니다. 자세한 내용은 사서함 서버 관리 및 개인 보관 파일 관리 항목을 참조하십시오.

데이터베이스 공백

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

데이터베이스 공백의 크기는 데이터베이스의 사서함을 통해 사용자가 주고받는 메일 크기에 의해 대략적으로 예측할 수 있습니다. 예를 들어, 사용자가 매일 평균적으로 10MB의 메일을 주고받는 데이터베이스에 100개의 2GB 사서함(총 200GB)이 있는 경우 공백은 약 1GB(100개의 사서함 × 사서함당 10MB)입니다. 백그라운드 데이터베이스 유지 관리 작업이 전체 단계를 완료하지 못할 경우 공백의 크기는 이 예상치를 초과할 수 있습니다.

맨 위로 이동

사서함 데이터베이스 복구 가능한 항목

각 데이터베이스에는 일시적으로 삭제된 항목이 저장되는 휴지통이 있습니다. 기본적으로 Exchange 2010에서 일시 삭제된 항목은 14일 동안, 일정 항목은 120일 동안 저장됩니다.

또한 Exchange 2010에는 삭제된 항목 보존 기간이 지나기 전에는 데이터의 삭제를 방지하는 기능도 포함되어 있습니다. 이 기능을 단일 항목 복구라고 합니다. 단일 항목 복구는 기본적으로 사용하지 않도록 설정됩니다. 그러나 단일 항목 복구를 사용하도록 설정하면 삭제된 항목 보존 기간 14일 동안 사서함 크기가 1.2% 커집니다. 일정 버전 로깅 데이터의 경우 사서함 크기가 3% 커집니다. 일정 버전 로깅 데이터는 기본적으로 사용하도록 설정됩니다.

삭제된 항목 보존 기간 14일에 단일 항목 복구 및 일정 버전 로깅을 사용하도록 설정한 경우의 휴지통 공간 요구 사항을 확인하기 위한 공식은 다음과 같습니다.

휴지통 크기 = (매일 받는/보내는 메일 x 평균 메시지 크기 x 삭제된 항목 보존 기간) + (사서함 할당량 x 0.012) + (사서함 할당량 x 0.03)

예를 들어 사서함 크기가 2GB인 경우 삭제된 항목 보존 기간 14일에 대해 단일 항목 복구를 사용하려면 추가로 25MB의 공간이 필요하며, 일정 로깅 기능을 사용하려면 61 MB가 추가로 필요합니다.

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

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

• 복구 가능한 항목 이해

• 복구 가능한 항목 관리

• 일정 복구 이해

• 일정 복구 관리

실제 사서함 크기

시간이 지남에 따라 사용자 사서함은 사서함 저장소 할당량에 도달하기 때문에 들어오는 메일의 양에 해당하는 메일을 삭제하여 사서함 저장소 할당량 이하의 크기를 유지해야 합니다. 이 요구 사항은 휴지통의 크기가 매일 보내고 받는 전자 메일의 크기에 삭제된 항목 보존 기간의 일 수를 곱한 값과 같은 최대 크기로 증가되어야 함을 의미합니다. 대다수 사용자가 저장소 할당량에 이르지 않은 경우에는 일부 받는/보내는 메일만 삭제됩니다. 따라서 휴지통과 사서함 크기가 증가하는 비율에 차이가 발생합니다.

개인 보관 파일 기능을 사용하지 않고 2GB 사서함을 이용하여 데이터베이스 크기를 확인하려면 Exchange 2010 사서함 서버 역할 디자인 예 항목의 "사서함 용량 요구 사항"을 참조하십시오.

계획된 실제 사서함 크기를 결정한 후 해당 값을 사용하여 데이터베이스당 최대 사용자 수를 결정할 수 있습니다. 계획된 사서함 크기를 권장되는 데이터베이스 크기로 나눕니다. 데이터베이스가 완전히 채워졌다고 가정하면 이 값을 통해 계획된 사용자 수를 처리하는 데 필요한 데이터베이스의 수를 판단할 수 있습니다. 비트랜잭션 I/O(입출력) 또는 하드웨어 제한으로 인해 단일 서버에 배치된 사용자 수를 수정해야 합니다. 관리자에 따라서는 추가 데이터베이스를 사용하여 데이터베이스 크기를 더 줄이는 편을 선호하기도 합니다. 이러한 방법은 서버당 더 많은 데이터베이스를 유지 관리하는 복잡함이 따르지만 백업 및 복원 소요 시간을 줄이는 데 도움이 됩니다.

콘텐츠 인덱싱

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

맨 위로 이동

오프라인 데이터베이스 유지 관리

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

복구 데이터베이스

재해 복구 계획의 일부분으로 복구 데이터베이스를 사용할 계획이라면 동시에 해당 서버에서 복원하려는 모든 데이터베이스를 처리하는 데 충분한 용량을 사용할 수 있어야 합니다. 자세한 내용은 복구 데이터베이스를 참조하십시오.

데이터베이스 크기

데이터베이스 크기에 따라 최종적으로 각 데이터베이스 내에 배포하는 사서함의 수, 그리고 배포하는 데이터베이스의 수가 결정됩니다. 배포하는 데이터베이스 크기는 여러 요소에 따라 달라집니다.

• 백업/복원 SLA(서비스 수준 계약)   데이터베이스 크기에 따라 적절한 시간 내에 얼마나 신속하게 데이터를 백업 및 복원하는지가 결정됩니다.

• 고가용성 아키텍처   여러 데이터베이스 복사본을 둘 계획인 경우 복구 작업 측면에서 이러한 복사본들이 첫 번째 방어선이므로 데이터베이스를 2TB 크기로 디자인할 수 있습니다.

• 저장소 아키텍처   JBOD 저장소(데이터베이스와 해당 트랜잭션 로그가 하나의 디스크에 들어감)에 배포할 계획인 경우 사용하는 디스크의 크기에 따라 최대 데이터베이스 크기가 결정됩니다. 예를 들어 1TB 디스크(포맷 용량 약 917GB)에 트랜잭션 로그와 콘텐츠 인덱스를 위한 공간도 포함해야 하며, 사용 가능한 공간을 모두 소진하지 않도록 해야 합니다.

데이터베이스 증가 오버헤드

모든 요소를 고려 및 계산하고 나면 데이터베이스 LUN(논리 단위 번호)에 대해 추가 오버헤드 요소를 20% 정도 포함하는 것이 좋습니다. 이 값은 사서함 크기 및 공백을 계산할 때 표시되지 않을 수도 있는 데이터베이스에 있는 기타 데이터를 포함하기 위한 것입니다.

맨 위로 이동

로그 용량

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

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

매일 생성되는 트랜잭션 로그 수 값은 선택한 메시지 프로필 및 평균 메시지 크기를 기반으로 합니다. 이 값은 매일 사서함당 생성되는 트랜잭션 로그 수를 나타냅니다. 메시지 프로필 계정당 생성되는 로그 수:

• 메시지 크기 영향

• 보낸/받은 데이터 크기

• 데이터베이스 상태 유지 관리 작업

• 레코드 관리 작업

• 메시지가 아닌 사서함에 저장된 데이터(작업, 로컬 일정 약속, 연락처)

• 강제 실행된 로그 롤오버(정기적으로 현재 트랜잭션 로그 파일을 닫는 메커니즘)

사서함 프로필당 생성되는 트랜잭션 로그 수

다음 지침을 사용하여 메시지 크기가 트랜잭션 로그의 생성 속도에 어떻게 영향을 미치는지를 파악할 수 있습니다.

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

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

예를 들어 하루 메시지 수가 100개인 경우 다음과 같습니다.

• 평균 메시지 크기가 150KB인 경우 사서함당 생성되는 로그 수는 20 x 1.9 = 38이 됩니다.

• 평균 메시지 크기가 300KB인 경우 사서함당 생성되는 로그 수는 20 x 3.8 = 76이 됩니다.

다음 섹션에서는 로그 용량 설정에 영향을 주는 요소에 대해 설명합니다.

• 백업 및 복원 요소

• 사서함 이동 작업

• 로그 증가 오버헤드 요소

• 고가용성 요소

• LUN 용량 계획

백업 및 복원 요소

로그 LUN 크기 조정은 부분적으로 백업 및 복원 디자인의 영향을 받습니다. 예를 들어, 2주 전 시점으로 돌아가 해당 시점 이후로 생성된 모든 로그를 재생하도록 하는 디자인을 사용하는 경우에는 2주분의 로그 파일에 해당하는 공간이 필요합니다. 백업 디자인에 주별 전체 백업 및 매일 차등 백업이 포함되어 있으면 복원 중에 백업 및 재생을 모두 허용할 수 있도록 로그 LUN이 한 주 전체의 로그 파일 공간에 해당하는 용량보다 커야 합니다. 야간 전체 백업을 수행하는 대부분의 엔터프라이즈는 필요한 일일 로그 생성 용량의 2 ~ 3배를 할당합니다. 이러한 방식은 로그 드라이브가 꽉 차서 발생하는 백업 오류로 인해 데이터베이스가 분리되는 현상을 방지하기 위한 것입니다.

백업 인프라로 Exchange 2010 내에서 사서함 복구 및 단일 항목 복구 기능을 사용할 계획이고, 그에 따라 순환 로깅을 사용할 계획이라면 최선의 방법에 따라 필요한 일일 로그 생성 용량의 3배를 할당해야 합니다. 이렇게 하면 복제가 일시 중단되거나 정상적인 상태에서 작동하지 않는 경우 자르기 오류로 인해 데이터베이스가 분리되는 일이 없습니다.

사서함 이동 작업

대규모 사서함 배포의 경우에는 사서함 이동 작업이 기본적인 용량 요소가 됩니다. 대부분의 대기업에서는 일정 비율의 사용자 사서함을 야간 또는 주 단위로 다른 데이터베이스, 서버 또는 사이트로 이동시킵니다. 사용자의 조직에서 이와 같은 작업을 수행하는 경우에는 사서함 이동을 수행할 수 있도록 로그 LUN에 추가 용량을 제공해야 합니다.

원본 서버에서는 크기가 작은 레코드 삭제 작업을 기록하지만 대상 서버에서는 먼저 전송된 모든 데이터를 트랜잭션 로그에 기록해야 합니다. 하루 동안 10GB의 로그 파일을 생성하고 3일 동안의 버퍼로 30GB를 유지한다면 2GB 사서함 50개(100GB)를 이동하는 경우 대상 로그 LUN이 꽉 차 가동이 중지됩니다. 이러한 경우에는 사서함 이동 작업을 수행할 수 있도록 로그 LUN에 대해 추가 공간을 할당해야 할 수도 있습니다.

로그 증가 오버헤드 요소

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

고가용성 요소

고가용성은 다음과 같은 세 가지 방식으로 로그 용량 요구 사항에 중대한 영향을 미칩니다.

• 데이터베이스 복사본 수   전체 시스템의 로그 용량은 고가용성 배포에서 선택된 데이터베이스 복사본의 수에 따라 증가합니다. 세 개의 서버에 세 개의 데이터베이스 복사본이 분산되어 있는 경우 각 서버에서 각 복사본에 대한 로그 용량을 프로비전해야 합니다.

• 로그 자르기 메커니즘   각 사서함 데이터베이스의 최대 16개 복사본을 둘 수 있는 기능과 Exchange 2010의 고가용성은 로그 자르기/삭제 메커니즘으로 지속적인 복제 순환 로깅을 사용할 수 있는 기반을 제공합니다. 이는 오래된 로그를 자르고 삭제하기 위해 전체/증분 백업을 실행하는 것과는 대조적인 방법입니다. 자세한 내용은 고가용성 및 사이트 복구 및 백업, 복원 및 재해 복구 이해의 "백업 없이 로그 자르기" 섹션을 참조하십시오.

• 데이터베이스 복사본 재생 지연   Exchange 2010의 고가용성은 수동 데이터베이스 복사본에서 로그 재생 지연 옵션을 제공합니다(각 복사본별로 구성됨). 이 기능은 지연된 데이터베이스 복사본으로 로그가 재생되는 시점을 지연시키는 데 사용됩니다. 이 지연은 원치 않는 콘텐츠가 모든 데이터베이스 복사본으로 복제되도록 하는 이벤트로부터 보호하는 데 유용할 수 있습니다. 원치 않는 콘텐츠가 포함된 로그가 데이터베이스로 재생되기 전에 재생을 일시 중단함으로써 콘텐츠가 지연된 데이터베이스 복사본으로 재생되지 않도록 할 수 있습니다.

  데이터베이스 복사본에 대해 재생 지연을 사용하도록 설정하면 로그 용량 요구 사항도 그에 따라 변합니다. 14일 지연을 구성하면 17일분의 로그에 맞추어 프로비전해야 합니다. 이 추가 로그 용량은 지연이 구성된 데이터베이스 복사본에 대해서만 필요하며, 지연이 없는 이 데이터베이스의 다른 복사본에 대해서는 일반적인(지연 없음) 로그 용량 요구 사항이 적용됩니다.

자세한 내용은 고가용성 요소 이해를 참조하십시오.

LUN 용량 계획

LUN에 대한 용량 요구 사항은 데이터 집합(데이터베이스, 트랜잭션 로그, 콘텐츠 인덱스 및 복구 공간)의 크기와 약간의 추가 여유 공간을 기반으로 합니다. 대부분의 작업 관리 프로그램에는 LUN 사용률이 80%를 초과할 경우 경고를 제공하는 용량 임계값이 있습니다.

다음 공식을 사용하여 LUN의 적절한 크기를 결정할 수 있습니다.

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

예를 들어 데이터 크기 요구 사항이 3000MB이고 여유 공간 요구 사항이 20%인 경우 이 데이터를 호스팅하는 LUN의 크기는 3750MB여야 합니다.

트랜잭션 로그 디스크 공간의 완전 소비 방지

트랜잭션 로그 디스크 공간이 모두 소비되지 않게 하려면 먼저 환경의 기준을 계산하여 일반적인 일별 로그 생성 속도를 결정해야 합니다. 그런 다음, 모니터링을 설정하고 생성되는 경고와 관련된 조치를 취해야 합니다. 특히 다음 항목을 모니터링해야 합니다.

• 트랜잭션 로그 LUN 디스크 공간. 여러 임계값과 다양한 경고 메커니즘을 설정합니다. 예를 들어, 일반적인 로그 생성 기준을 알고 있다면 기준을 20% 넘었을 때 보고하도록 임계값을 설정할 수 있습니다.

• 성공적인 백업 완료(Exchange Native Data Protection을 이용하지 않는 경우).

• 응용 프로그램 로그에서 이벤트의 잘림.

• 데이터베이스 복사본 복제 상태.

원인을 알 수 없는 트랜잭션 로그의 증가 문제 해결

원인을 알 수 없는 트랜잭션 로그의 증가 문제를 해결하려면 셸에서 Troubleshoot-DatabaseSpace.ps1 스크립트를 사용하여 데이터베이스 로그 증가 관리를 참조하십시오.

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