Edge 전송 서버와 허브 전송 서버는 다음을 배달하는 서버 역할을 합니다.
· 조직으로 들어오고 나가는 메일
· 사서함 서버로 들어오고 나가는 메일
· 통합 메시징 서버에서 제출한 음성 메시지
Exchange 조직에서 메일 흐름 및 배달을 효율적으로 수행하려면 Edge 전송 및 허브 전송 서버에 올바로 디자인된 저장 솔루션이 있어야 합니다.
이 항목에서는 Edge 전송 및 허브 전송 서버의 용량 및 I/O(입출력) 요구 사항을 확인하는 데 도움을 주는 정보 및 예제를 제공합니다.
Edge 전송 서버는 각 조직의 용량 및 트랜잭션의 I/O 요구 사항에 맞게 디자인되어야 합니다. 큐 증가를 올바로 유지 관리하고 최대한 빠르게 메일을 라우팅하여 SLA(서비스 수준 계약)가 불리하게 영향을 받지 않게 하는 것이 중요합니다. Edge 전송 서버의 전체 용량에 영향을 주는 여러 가지 요소는 다음과 같습니다.
· 메시지 추적 로그
· 프로토콜 로그
· 메일 데이터베이스
· 연결 로그
· 에이전트 로그
최소 4GB 이상의 여유 공간 및 데이터베이스를 위한 여유 공간이 메시지 큐 데이터베이스가 있는 드라이브에 있어야 합니다. 그렇지 않으면 전송 시스템이 역 압력, Microsoft Exchange Server 2007 전송 서비스의 시스템 리소스 모니터링 기능을 활성화합니다. 역 압력의 기본값은 PercentageDatabaseDiskSpaceUsedHighThreshold 매개 변수에서 제어되며 필요한 경우 이를 수정할 수 있습니다. 역 압력 및 역 압력 구성 옵션 에 대한 자세한 내용은 백 프레셔의 이해를 참조하십시오.
메시지 추적 로그를 사용하도록 설정하면 추가 용량이 필요합니다. 전송 서버에서 수신한 메시지의 수에 따라 메시지 추적 용량 요구 사항이 달라집니다. 조직에서 Microsoft Exchange Server 2003 을 현재 사용하면 현재 로그 생성 속도를 결정하고 데이터를 보관할 날짜 수에 대한 구체적인 제한(예: 10일)을 설정할 수 있습니다. Microsoft 에서는 220MB의 메시지 추적 로그를 매 영업일(주말에는 적음)에 생성하고 1주간의 로그에 대해 충분한 용량인 약 1.3GB를 확인합니다. 프로토콜, 연결 및 에이전트 로그 크기는 작업에 따라 달라집니다. Microsoft 에서 프로덕션 전송 서버는 참조 지점으로 다음을 생성합니다.
· Edge 전송 서버에서 매일 5 - 15GB의 프로토콜 로그. 프로토콜 로그 할당량에 충분한 용량인 15GB가 보장됩니다.
· Edge 전송 서버에서 매일 100MB의 연결 로그. 주간 로그에 충분한 용량인 약 600MB가 보장됩니다.
· Edge 전송 서버에서 매일 250MB의 에이전트 로그. 주간 로그에 충분한 용량인 1.5GB가 보장됩니다.
순환 로깅을 사용하면 일반 로그 작성이 제한되므로 트랜잭션 로그는 많은 디스크 용량을 필요로 하지 않습니다. 따라서 운영 체제가 포함된 LUN(논리 단위 번호)에 트랜잭션 로그를 배치할 수 있습니다. Microsoft 에서는 이 LUN에 두 개의 디스크 미러를 사용합니다.
데이터베이스(mail.que)는 항목을 무한정으로 저장하지 않으며 큐가 최대 상태이고 서버가 종료된 경우에 예약된 용량은 평균 메시지 크기에 최대 큐를 곱한 용량이여야 합니다. 평균 메시지 크기가 50KB인 500,000개의 항목 큐는 데이터베이스에서 약 25GB의 데이터를 차지합니다.
받는 메일에 바이러스 백신 스캔을 실행하는 Edge 전송 서버는 바이러스 백신 격리를 위한 충분한 공간을 필요로 합니다. 디스크 I/O 리소스 요구 사항은 바이러스에 감염된 받는 메일의 비율에 따라 다르며 일반적으로 작습니다. 감염된 메시지 및 첨부 파일의 용량 및 격리에 머무르는 시간은 격리에서 필요로 하는 공간의 크기에 영향을 줍니다. 1GB의 디스크 공간은 좋은 시작점이 될 수 있지만 실제 필요한 용량은 각 조직에 따라 다릅니다.
대부분의 Edge 전송 서버 배포의 경우 다른 요소를 모두 고려한 후에 20%의 오버헤드 요소를 데이터베이스 크기에 추가하는 것이 좋습니다. 이 값은 데이터베이스 내의 내부 구조를 고려하며 메일 흐름의 급격한 상승 또는 변경으로 인해 데이터베이스 크기가 커진 경우 충분한 공간을 보장합니다.
Edge 전송 서버의 용량 예제
이 예제에서 트랜잭션 로그는 운영 체제 파티션(C:)에 저장되며 이 파티션은 배터리로 지원된 캐싱 RAID(Redundant Array of Independent Disk) 컨트롤러에서 호스팅됩니다. 용량 요구 사항은 여러 메가바이트 범위로 작습니다.
다음은 Edge 전송 서버의 용량을 결정하는 두 단계 프로세스입니다. 첫 번째는 데이터베이스 크기를 계산한 다음 트랜잭션 로그 크기를 결정합니다.
1단계: 데이터베이스 크기
Edge 전송 서버가 24시간 간격으로 평균적으로 초당 5개의 메시지(50KB의 평균 크기)를 받으며 최대 큐의 항목이 500,000개인 것으로 간주합니다. 다른 요소를 모두 추가한 후에 20%의 추가 오버헤드를 포함시키면 다음 표와 같이 디스크에서 총 크기는 58GB입니다.
데이터베이스 크기
|
최대 큐 |
큐 용량 |
프로토콜 로그 |
메시지 추적 로그 |
바이러스 백신 격리 |
연결 로그 |
에이전트 로그 |
여유 공간 |
디스크 전체 크기 |
|
500,000 |
약 25GB(500,000 × 50KB) |
15GB |
1.3GB |
1GB |
600MB |
1.5GB |
4GB |
58GB (48GB + 20%) |
2단계: 트랜잭션 로그 크기
트랜잭션 로그 크기를 결정하려면 트랜잭션 I/O, 기타 디스크 I/O 및 메시지당 데이터베이스 IOPS(초당 I/O)를 고려해야 합니다.
트랜잭션 I/O
서버에 사용 가능한 메모리가 충분하면 받는 메일이 RAM 및 트랜잭션 로그에 저장되어 디스크 영향이 최소화됩니다. 메모리 리소스가 낮아지면 첫 번째 128KB의 메시지만 메모리 및 트랜잭션 로그에 저장됩니다. 나머지 메시지는 데이터베이스에 저장됩니다. 콘텐츠를 변환하는 동안 데이터는 임시 디렉터리(%TEMP%)에 스트리밍됩니다. 따라서 데이터베이스와 동일한 LUN에 임시 디렉터리를 배치하는 것이 중요합니다. 또한 저장소 컨트롤러 캐시를 50% 읽기 및 50% 쓰기로 설정하는 것이 중요합니다. 큐가 크게 커지지 않는 경우에는 읽기 작업을 수행하는 디스크 I/O가 거의 없습니다. 큐가 있는 경우에는 메시지가 데이터베이스 캐시에 있지 않을 수 있으므로 더 많은 디스크 I/O를 필요로 합니다.
기타 디스크 I/O
시스템에는 트랜잭션 I/O와 더불어 기타 디스크 I/O도 있을 수 있습니다. 예를 들면,
· 메시지 추적 로그를 사용하려면 디스크 I/O에 2-5%의 추가 오버헤드가 필요합니다.
· 프로토콜 및 연결 로그를 사용하면 받는 메일의 양에 따라 디스크 I/O에 소규모 오버헤드가 포함됩니다.
· 기본 에이전트 로그를 사용하면 사용자 지정 에이전트가 사용 중인 경우 디스크 리소스가 더 많이 필요하더라도 디스크 I/O에 소규모 오버헤드가 포함됩니다.
· 스팸 방지 및 바이러스 백신 작업이 메모리에서 발생하면 더 많은 CPU 리소스가 필요합니다.
테스트 중에는 프로덕션에서 사용할 모든 서비스가 실행되는 상태에서 Edge 전송 서버를 테스트해야 합니다.
메시지당 데이터베이스 IOPS
Microsoft 에서는 내부 테스트 중에 60KB의 평균 메시지 크기를 사용했습니다. 여러 조직이 초당 20개의 메시지와 같이 특정 메시지 속도를 가정하여 전송 서버의 크기를 설정합니다. 이 메시지 속도에는 140개(20 × (4.5 + 2.5))의 데이터베이스 I/O 및 220개의 (20 × 11) 로그 I/O가 필요합니다.
큐가 형성될 때는 더 많은 읽기가 필요합니다. RAID-1/0의 경우 모든 실제 디스크가 다음 표와 같이 읽기 요청에 응답하기 때문에 더욱 그러합니다.
메시지당 데이터베이스 IOPS
|
Edge 전송 데이터베이스 I/O(안정적인 상태) |
대략적인 Edge I/O |
|
메시지당 총 IOPS(약 60KB) |
18 |
|
메시지당 로그 쓰기 I/O(순차) |
11 |
|
메시지당 데이터베이스 쓰기 I/O(임의) |
4.5 |
|
메시지당 데이터베이스 읽기 I/O(임의) |
2.5 |
|
|
|
이전 표에서 숫자는 프로덕션 환경에서 편차가 최대 +/- 30%인 여러 서버의 평균을 나타냅니다. 저널링 및 전송 규칙과 같은 추가 기능에는 메시지당 예상 I/O에 영향을 주며 이러한 기능은 이 항목에 제공된 예제 프로덕션 수에 영향을 줍니다. |
크기 설정 지침을 Edge 전송 서버의 하드웨어 디자인에 적용
Edge 전송 서버에 필요한 용량 및 트랜잭션 I/O 요구 사항이 준비되면 제안된 하드웨어 디자인에 적용할 수 있습니다. 프로세서 및 메모리 구성에 대해서는 프로세서 및 메모리 구성 계획 및 메모리 구성 계획을 참조하십시오. Edge 전송 서버를 디자인할 때에는 시스템에 충분한 RAM을 확보하여(각 메시지에는 8 또는 9KB의 메모리가 필요함) 대기 중인 메시지 본문이 디스크에 임시로 캐시되지 않도록 하는 것이 중요합니다.
Edge 전송 서버에는 ESE(Extensible Storage Engine) 데이터베이스가 사용됩니다. 최적의 성능 및 복구를 위해 대규모 큐가 있을 환경의 실제 자체 디스크에서 로그와 데이터베이스 파일을 분리하는 것이 중요합니다. 디스크 I/O 요구 사항이 낮은 소규모 배포의 경우에는 트랜잭션 로그 및 데이터베이스를 모두 동일한 LUN에 배치할 수 있습니다. 사서함 서버와 같이 Edge 전송 서버에는 20밀리초 미만인 I/O 응답 시간이 필요합니다.
배터리로 지원된 캐싱 RAID 컨트롤러를 사용하고 데이터베이스 유지 관리를 밤에 실행하는 것이 중요합니다. 또한 선택된 디스크 유형이 용량과 성능 간의 적절한 균형을 제공하는지 확인합니다.
Edge 전송 서버의 하드웨어 디자인 크기 설정 예제
이 예제에서는 초당 예상 메시지를 기반으로 저장소를 디자인하는 방법을 보여줍니다. 이 예제에서 Edge 전송 서버는 초당 20개의 메시지를 처리하며 데이터베이스 LUN에 140 IOPS, 로그 LUN에 220 IOPS를 필요로 합니다. 평일보다 더 많이 처리하려면 디스크 I/O 매개 변수에 20% 증가율을 항상 추가합니다. 디스크 레이아웃은 RAID10입니다. 하드웨어 크기 설정 결과에 대해서는 다음 표를 참조하십시오.
하드웨어 크기 조정
|
디스크(1) 및 (2), RAID1 레이아웃 |
디스크(3), (4), (5) 및 (6), RAID10 레이아웃 |
|
운영 체제 및 트랜잭션 로그 220 + 20% = 264 IOPS |
데이터베이스, 프로토콜과 메시지 추적 로그 및 바이러스 백신 격리140 + 20% = 168 IOPS |
이 예제에는 주간 데이터에 약 70GB의 데이터베이스 LUN 용량 요구 사항이 포함되어 있습니다. 2주간의 데이터가 필요하면 용량 요구 사항을 140GB로 2배 늘려야 합니다. 146GB의 실제 디스크를 사용하면 RAID10 구성에서 292GB의 LUN이 허용됩니다.
또한 허브 전송 서버는 조직의 용량 및 트랜잭션의 I/O 요구 사항에 맞게 디자인되어야 합니다. Edge 전송 서버와 마찬가지로 최소 4GB의 여유 공간 및 데이터베이스를 위한 여유 공간이 메시지 큐 데이터베이스가 있는 드라이브에 있어야 합니다. 그렇지 않으면 전송 시스템이 역 압력을 활성화합니다 허브 전송 서버에서 PercentageDatabaseDiskSpaceUsedHighThreshold 매개 변수의 기본값을 수정할 수 있습니다.
전송 서버에서 수신한 메시지의 수에 따라 메시지 추적 로그 용량이 달라집니다. 조직에서 Exchange 2003 을 현재 사용하면 현재 로그 생성 속도를 결정하고 데이터를 보관할 날짜 수에 대한 구체적인 제한(예: 10일)을 설정할 수 있습니다. Microsoft 에서는 700MB의 메시지 추적 로그를 매 영업일(주말에는 적음)에 허브 전송 서버에 생성하고 1주간의 로그에 충분한 용량인 4.5GB를 확인합니다.
프로토콜 로그 크기는 작업에 따라 달라집니다. Microsoft 에서는 하루에 2.7GB의 프로토콜 로그를 허브 전송 서버에 생성하고 1주간의 로그에 충분한 용량인 16GB를 확인합니다.
순환 로깅을 사용하면 일반 로그 작성이 제한되므로 트랜잭션 로그는 많은 디스크 용량을 필요로 하지 않습니다. 따라서 운영 체제 LUN에 트랜잭션 로그를 배치할 수 있습니다. Microsoft 에서는 이 LUN에 두 개의 디스크 미러를 사용합니다.
데이터베이스(mail.que)는 항목을 무한정으로 저장하지 않으며 큐가 최대 상태이고 서버가 종료된 경우에 예약된 용량은 평균 메시지 크기에 최대 큐를 곱한 용량이여야 합니다. 평균 메시지 크기가 50KB인 500,000개의 항목 큐는 데이터베이스에서 약 25GB의 데이터를 차지합니다.
대부분의 허브 전송 서버 배포의 경우 다른 요소를 모두 고려한 후에 20%의 추가 오버헤드를 데이터베이스 크기에 추가하는 것이 좋습니다.
전송 쓰레기 수거통
다음을 포함하는 사이트에서는 허브 전송 서버에 필요한 특수 고려 사항이 필요합니다.
· Exchange Server 2007 RTM(Release To Manufacturing) 버전 또는 Microsoft Exchange Server 2007 SP1(서비스 팩1) 중 하나를 사용하는 CCR(클러스터 연속 복제) 환경에서 배포된 클러스터된 사서함 서버
· LCR(로컬 연속 복제)에 사용된 하나 이상의 저장소 그룹이 있는 Exchange 2007 SP1을 실행하는 사서함 서버
이전 환경 중 하나를 배포할 때에는 사이트에 있는 모든 저장소 그룹에 대해 메일을 충분히 오래 저장하는 데 용량이 충분하도록 허브 전송 서버를 디자인해야 활성 노드가 갑자기 중지된 경우 메시지를 복구할 수 있습니다. 이러한 기능을 전송 쓰레기 수거통라고 합니다.
전송 쓰레기 수거통의 I/O 오버헤드는 큐를 증가시키는 것과 유사합니다. 메시지가 전송 쓰레기 수거통에 머무르는 기간을 제어하는 데 사용할 수 있는 두 개의 매개 변수는 MaxDumpsterSizePerStorageGroup 및 MaxDumpsterTime입니다. MaxDumpsterSizePerStorageGroup의 기본값은 18MB입니다. 전송 쓰레기 수거통의 크기를 환경에 맞추려면 가장 큰 허용 가능한 메시지 크기를 가져와서 해당 크기를 50% 증가시킵니다. 예를 들어, 메시지 할당량이 10MB이면 MaxDumpsterSizePerStorageGroup을 15MB로 설정할 수 있습니다. CCR 환경 또는 Exchange 2007 SP1을 실행하는 LCR 환경에서 클러스터된 사서함 서버와 동일한 Active Directory 디렉터리 서비스 사이트에 두 개 이상의 허브 전송 서버가 있으면 해당 클러스터된 사서함 서버에서 저장소 그룹의 집계 저장소가 모든 허브 전송 서버 간에 확산됩니다. 예를 들어, 15MB 전송 쓰레기 수거통이 있는 4개의 허브 전송 서버가 있으면 해당 저장소 그룹에 60MB 전송 쓰레기 수거통이 있습니다.
메시지 크기 제한이 없는 조직의 경우에는 MaxDumpsterSizePerStorageGroup을 조직 내에 전송된 평균 메시지 크기의 1.5배 값으로 설정하는 것이 좋습니다. 또한 최대 메시지 크기가 설정되지 않은 경우에는 CCR 환경에서 예약되지 않은 장애 조치(failover) 후에 또는 Exchange 2007 SP1을 실행하는 LCR 환경에서 수동 복사본의 활성화 후에 해당 메시지를 다시 가져올 수 없습니다.
MaxDumpsterTime을 기본값인 7일로 설정하는 것이 좋습니다.
전송 쓰레기 수거통에서 사용되는 용량은 최대 전송 쓰레기 수거통 크기에 저장소 그룹의 수를 곱한 수여야 합니다. 최대 전송 쓰레기 수거통 크기가 15MB이고 허브 전송 서버가 LCR(Exchange 2007 SP1) 또는 CCR(Exchange 2007 RTM) 환경에 있는 100개의 저장소 그룹을 서비스하면 1.5GB를 전송 쓰레기 수거통에 할당해야 합니다.
전송 쓰레기 수거통 크기 설정 예제
이 예제에서는 트랜잭션 로그가 운영 체제 파티션(C:)이 포함된 디스크에 있으며 이 파티션은 배터리로 지원된 캐싱 RAID 컨트롤러에서 호스팅됩니다. 용량 요구 사항은 메가바이트 범위로 작습니다. 크기 설정 결과에 대해서는 다음 표를 참조하십시오.
다음은 전송 쓰레기 수거통 기능에 필요한 용량을 결정하는 두 단계 프로세스입니다. 첫 번째는 데이터베이스 크기를 계산한 다음 트랜잭션 로그 크기를 결정합니다.
1단계: 데이터베이스 크기
허브 전송 서버가 24시간 간격으로 평균적으로 초당 5개의 메시지를 받으며 최대 큐의 항목이 500,000개인 것으로 간주합니다.
전송 쓰레기 수거통 크기 결정
|
최대 큐 |
큐 용량 |
프로토콜 로그 |
메시지 추적 로그 |
전송 쓰레기 수거통 |
디스크 전체 크기 |
|
500,000 |
25GB(500,000 × 50KB) |
15GB |
4.5GB |
1.5GB |
55GB(46GB + 20%) |
2단계: 트랜잭션 로그 크기
트랜잭션 로그 크기를 결정하려면 트랜잭션 I/O, 기타 디스크 I/O 및 메시지당 데이터베이스 IOPS를 고려해야 합니다.
트랜잭션 I/O
Edge 전송 서버에 이전에 나열된 트랜잭션 I/O에 대한 동일한 지침이 허브 전송 서버에 적용됩니다. 이전에 설명한 바와 같이 50% 읽기, 50% 쓰기로 저장소 컨트롤러의 캐시 설정을 구성하는 것이 매우 중요합니다.
전송 쓰레기 수거통 I/O
전송 쓰레기 수거통을 사용하도록 설정하면 디스크 I/O이 증가합니다. 데이터베이스 쓰기가 증가하지만 데이터베이스 읽기도 발생하며 Microsoft 프로덕션 서버의 데이터베이스 읽기 평균은 메시지당 약 3회의 읽기입니다.
기타 디스크 I/O
Edge 전송 서버에 이전에 나열된 기타 디스크 I/O에 대한 동일한 지침이 허브 전송 서버에 적용됩니다. 테스트 중에는 프로덕션 환경에서 사용할 모든 서비스가 실행되는 상태에서 허브 전송 서버를 테스트하는 것이 특히 중요합니다.
메시지당 데이터베이스 IOPS
Microsoft 의 내부 테스트에서 40KB의 평균 메시지 크기를 사용하고 전송 쓰레기 수거통을 사용하도록 설정하면 허브 전송 서버에 더 많은 디스크 리소스가 필요합니다. 여러 엔터프라이즈가 초당 20개의 메시지와 같이 특정 메시지 속도를 가정하여 전송 서버의 크기를 설정합니다. 전송 쓰레기 수거통을 사용하도록 설정한 상태에서 초당 20개를 받는 메시지 속도를 서비스하려면 200개의 데이터베이스 I/O(20 × (7 + 3)) 및 140개의 로그 I/O(20 × 7)가 필요합니다. 전송 쓰레기 수거통을 사용하지 않도록 설정한 상태에서 초당 20개를 받는 메시지 속도를 서비스하려면 40개의 데이터베이스 I/O(20 × 2) 및 40개의 로그 I/O(20 × 2)가 필요합니다.
큐가 형성될 때는 더 많은 읽기가 필요합니다. RAID10의 경우 모든 실제 디스크가 읽기 요청에 응답하기 때문에 더욱 그러합니다. 자세한 내용은 다음 표를 참조하십시오.
트랜잭션 로그 크기 설정
|
허브 전송 서버 데이터베이스 I/O(안정적인 상태) |
전송 쓰레기 수거통 사용 |
전송 쓰레기 수거통 사용 안 함 |
|
메시지당 총 IOPS(약 40KB) |
17 |
4 |
|
메시지당 로그 쓰기 I/O(순차) |
7 |
2 |
|
메시지당 데이터베이스 쓰기 I/O(임의) |
7 |
2 |
|
메시지당 데이터베이스 읽기 I/O(임의) |
3 |
0 |
|
|
|
이전 표에서 숫자는 프로덕션 환경에서 편차가 최대 +/- 30%인 여러 서버의 평균을 나타냅니다. 저널링 및 전송 규칙과 같은 추가 기능에는 메시지당 예상 I/O에 영향을 주며 이러한 기능은 이 예제에 있는 값에 영향을 줍니다. |
크기 설정 지침을 허브 전송 서버의 하드웨어 디자인에 적용
허브 전송 서버에 필요한 용량 및 트랜잭션 I/O 요구 사항이 준비되면 제안된 하드웨어 디자인에 적용할 수 있습니다. 허브 전송 서버의 프로세서 및 메모리 구성에 대해서는 프로세서 및 메모리 구성 계획 및 메모리 구성 계획을 참조하십시오. 허브 전송 서버를 디자인할 때에는 시스템에 충분한 RAM을 확보하여(각 메시지에는 8 또는 9KB의 메모리가 필요함) 대기 중인 메시지 본문이 디스크에 임시로 캐시되지 않도록 하는 것이 중요합니다.
허브 전송 서버에는 ESE 데이터베이스가 사용됩니다. 대규모 큐가 있을 환경에서 또는 전송 쓰레기 수거통을 사용할 때 최적의 성능을 위해 실제 자체 디스크에서 로그와 데이터베이스 파일을 분리하는 것이 중요합니다. 디스크 I/O 요구 사항이 낮은 소규모 배포의 경우에는 동일한 LUN에 트랜잭션 로그 및 데이터베이스를 모두 배치할 수 있습니다. Edge 전송 서버와 같이 허브 전송 서버에는 20밀리초 미만인 I/O 응답 시간이 필요합니다.
허브 전송 서버에 대한 하드웨어 디자인 크기 설정 예제
초당 예상 메시지를 기반으로 저장소를 디자인하는 것이 중요합니다. 이 예제에서 허브 전송 서버는 전송 쓰레기 수거통을 사용하지 않도록 설정한 상태에서 초당 20개의 메시지를 처리하며 데이터베이스 LUN에 40 IOPS, 로그 LUN에 40 IOPS를 필요로 합니다. 평일보다 더 많이 처리하려면 디스크 I/O 매개 변수에 20% 증가율을 항상 추가합니다. 디스크 레이아웃은 RAID1입니다. 이 예제에는 주간 데이터에 약 55GB의 데이터베이스 LUN 용량 요구 사항이 포함되어 있습니다. 2주간의 데이터가 필요하면 용량 요구 사항을 110GB로 2배 늘려야 합니다. 140GB의 실제 디스크를 사용하면 RAID1 구성에 140GB의 데이터베이스 LUN을, RAID1 구성에 140GB의 로그 LUN을 제공합니다. 결과에 대해서는 다음 표를 참조하십시오.
전송 쓰레기 수거통을 사용하지 않도록 설정한 상태에서 20개의 메시지를 처리하는 허브 전송 서버의 하드웨어 크기 설정
|
디스크(1) 및 (2), RAID1 레이아웃 |
디스크(3) 및 (4), RAID1 레이아웃 |
|
운영 체제 및 트랜잭션 로그 40 + 20% = 48 IOPS |
데이터베이스, 프로토콜, 메시지 추적 로그 및 바이러스 백신 격리 40 + 20% = 48 IOPS |
이 예제에서 허브 전송 서버는 전송 쓰레기 수거통을 사용하도록 설정한 상태에서 초당 20개의 메시지를 처리합니다. 이 구성에는 데이터베이스 LUN에 200 IOPS, 로그 LUN에 140 IOPS와 20% 추가 증가율이 필요합니다. 디스크 레이아웃은 RAID10입니다. 이 예제에는 2주간의 데이터가 필요한 경우 주간 데이터를 위한 약 55GB의 데이터베이스 LUN 용량 요구 사항이 포함되어 있습니다. 140GB의 실제 디스크를 사용하면 RAID10 구성에서 280GB의 데이터베이스 LUN 및 RAID1 구성에서 140GB의 로그 LUN을 제공합니다.
전송 쓰레기 수거통을 사용하도록 설정한 상태에서 초당 20개의 메시지를 처리하는 허브 전송 서버의 하드웨어 크기 설정
|
디스크(1) 및 (2), RAID1 레이아웃 |
디스크(3), (4), (5) 및 (6), RAID10 레이아웃 |
|
운영 체제 및 트랜잭션 로그 140 + 20% = 168 IOPS |
데이터베이스, 프로토콜, 메시지 추적 로그 및 바이러스 백신 격리 200 + 20% = 240 IOPS |
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가 더 추가됩니다.
Exchange Server 2003의 저장소 최적화에는 필수 폴더의 항목 수 및 사용 중인 클라이언트의 유형과 모드가 일부 사용자의 디스크 성능에 영향을 줄 수 있는 방식에 대한 설명이 나와 있습니다. 사서함 크기가 커질수록 이 요소는 더욱 중요해집니다.
Exchange 2003 과 비교할 때 서버 I/O를 70%까지 줄일 수 있는 방법 중 하나는 캐시된 Exchange 모드로 Outlook 2007 을 사용하는 것입니다. 초기 사서함 동기화에는 비용이 많이 들지만 시간이 지나면서 사서함 크기가 커지면 디스크 하위 시스템의 작업이 Exchange 서버에서 Outlook 클라이언트로 이동하게 됩니다. 즉, 사용자의 받은 편지함에 항목 수가 많거나 사용자가 사서함을 검색하고 있어도 서버의 성능에는 거의 영향이 없습니다. 또한 적절한 성능에 대한 개별 사용자의 임계값에 따라, 캐시된 Exchange 모드를 사용하며 대규모 사서함을 보유한 사용자의 경우 사서함 크기가 작은 사용자에 비해 속도가 빠른 컴퓨터가 필요할 수 있습니다. 다음 표에서는 사서함 크기를 기반으로 하여 캐시된 Exchange 모드로 Outlook 2007 을 실행 중인 클라이언트 컴퓨터에 대한 권장 사항을 제공합니다.
Outlook 2007 캐시된 Exchange 모드 클라이언트에 대한 메모리 및 디스크 권장 사항
|
사서함 크기 |
메모리 크기 |
하드 디스크 속도 |
|
1GB |
1GB |
5,400RPM |
|
2GB |
1–2GB |
7,200RPM |
2GB보다 큰 사서함의 경우에는 사서함 크기를 줄이거나 온라인 모드를 사용하는 것이 좋습니다.
|
|
|
클라이언트가 캐시된 Exchange 모드로 Outlook 2007 을 사용하는 중이면 Outlook 2007 용 성능 업데이트를 Microsoft 기술 자료 문서 933493, Outlook 2007용 업데이트에 대한 설명: 2007년 4월 13일(Description of the update for Outlook 2007: April 13, 2007)에서 다운로드하여 설치하는 것이 좋습니다. |
온라인 모드에서 Outlook Web Access 및 Outlook 은 모두 서버의 데이터 복사본에 대해 인덱스를 저장하고 검색을 수행합니다. 중간 정도 크기인 사서함의 경우에는 이렇게 하면 적절한 크기의 캐시된 Exchange 모드 클라이언트의 사서함당 IOPS의 크기가 약 두 배가 됩니다. 그리고 큰 사서함의 사서함당 IOPS는 더욱 커집니다. 보기를 새로운 방식으로 처음 정렬하면 인덱스가 만들어져 데이터베이스 LUN에 대해 많은 읽기 I/O가 생성됩니다. 이 작업이 수행된 이후로는 활성 인덱스에 대해 저렴하게 정렬 작업을 수행할 수 있습니다.
문제가 될 수 있는 시나리오는 사용자가 Exchange 에서 저장할 수 있는 인덱스 수를 초과하여 저장한 경우(Exchange 2007 의 경우 11개 인덱스)입니다. 이 경우 사용자가 새로운 방식으로 보기를 정렬하도록 선택하여 12번째 인덱스를 만들면 디스크 I/O가 추가로 생성됩니다. 해당 인덱스는 저장되지 않으므로 이 디스크 I/O 비용은 정렬을 수행할 때마다 발생합니다. 이 시나리오에서는 많은 I/O가 생성될 수 있기 때문에 받은 편지함 및 보낸 편지함 폴더 등의 주요 폴더에 5,000개가 넘는 항목을 저장하지 않는 것이 좋습니다. 보다 상위 수준의 폴더를 만들거나 받은 편지함 및 보낸 편지함 폴더 아래에 하위 폴더를 만들면 한 폴더에 포함된 항목 수가 5,000개를 넘지 않는 한 이러한 인덱스 작성 작업과 관련된 비용이 크게 줄어듭니다. 항목 개수가 사서함 서버 성능에 영향을 주는 방식에 대한 자세한 내용은 권장되는 사서함 크기 제한(Recommended Mailbox Size Limits)을 참조하십시오.
|
|
|
각 블로그의 콘텐츠 및 URL은 예고 없이 변경될 수 있습니다. |
트랜잭션 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을 참조하십시오.
|
|
|
각 블로그의 콘텐츠 및 URL은 예고 없이 변경될 수 있습니다. |
백업 및 복원
관리자가 사용할 수 있는 다양한 백업 및 복원 방법이 있습니다. 백업 및 복원과 관련된 주요 메트릭은 처리량, 즉 프로덕션 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에서 볼륨 섀도 복사본 서비스 사용에 대한 모범 사례(Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003)를 참조하십시오. Exchange 2007 의 새로운 기능을 통해 LCR 또는 CCR 환경에서 실행하는 저장소 그룹의 수동 복사본을 VSS 백업할 수 있습니다. 이러한 환경에서 수동 복사본으로부터 VSS 스냇숏을 가져오면 백업에 대한 체크섬 무결성 단계와 테이프 또는 디스크에 대한 후속 복사 작업 중 일어나는 활성 LUN에서의 디스크 부하를 없앨 수 있습니다. 또한 온라인 유지 보수, MRM 및 기타 작업을 실행하기 위한 활성 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 다중 사이트 데이터 복제 배포 지침을 참조하십시오.
