로컬 연속 복제를 위한 계획
적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
마지막으로 수정된 항목: 2008-01-04
로컬 연속 복제(LCR)를 위한 계획에는 저장소 그룹과 데이터베이스 토폴로지를 설계하고 적절한 저장소 솔루션 지원과 적절한 LCR 모니터링을 보장하는 것이 포함됩니다.
LCR에 대한 저장소 요구 사항 및 권장 사항
LCR에는 몇 가지 저장소 요구 사항과 권장 사항이 포함됩니다. LCR 저장소 솔루션을 디자인할 때 LCR에 대한 추가 I/O(입출력) 사용을 포함해야 합니다. 이는 활성 복사본에 의한 로그 업데이트와 수동 복사본의 비슷한 로그 읽기가 LCR 환경에 포함되기 때문입니다. 수동 복사본이 활성 복사본과 비슷한 용량 및 성능 기능을 갖도록 저장소를 디자인하는 것이 좋습니다. LCR을 사용할 경우 다음과 같은 최상의 방법을 따르십시오.
각 저장소 그룹마다 단일 데이터베이스 사용 LCR에 대해 저장소 그룹이 사용하도록 설정된 경우 하나의 데이터베이스만 포함할 수 있습니다. 또한 기존 저장소 그룹에 여러 개의 데이터베이스가 있는 경우, 데이터베이스를 하나만 남겨 놓고 모두 삭제하기 전까지는 해당 저장소 그룹에 대해 LCR을 사용하도록 설정할 수 없습니다. 이러한 방법으로 복구 기능이 향상되고 관리하기 용이한 Microsoft Exchange 저장소 토폴로지를 만들 수 있습니다.
볼륨 탑재 지점을 사용합니다. 데이터베이스 파일과 트랜잭션 로그 파일을 저장하는 위치를 지정하기 위해 Exchange 데이터 LUN(논리 단위 번호) 또는 디스크에 대한 드라이브 문자나 볼륨 탑재 지점을 사용할 수 있습니다. 각 Exchange Server에 대한 26자의 드라이브 문자 길이 제한을 피하기 위해 NTFS 파일 시스템 볼륨 탑재 지점 기능을 사용하는 것이 좋습니다. 볼륨 탑재 지점을 사용하여 다른 실제 디스크의 폴더로 대상 파티션을 이식하거나 탑재할 수 있습니다. 볼륨 탑재 지점을 사용해도 Exchange Server을 비롯한 프로그램의 사용 방식에는 아무런 변화가 없습니다. 볼륨 탑재 지점을 사용하면 프로덕션 트랜잭션 로그나 데이터베이스 파일에 손상이 감지되었을 때 드라이브 문자 할당과 경로를 즉시 바꿀 수 있으므로 복구 과정이 간단해집니다. 프로덕션 트랜잭션 로그나 데이터베이스 파일의 손상을 복구하는 방법에 대한 자세한 내용은 로컬 연속 복제 관리를 참조하십시오.
성능과 복구를 위해 데이터를 분할합니다. 일반적으로 여러 하드 디스크에 걸쳐 데이터를 분할하면 성능이 향상되고 복구해야 할 데이터의 양이 줄어들 수 있습니다. 오류의 유형에 따라 데이터베이스와 트랜잭션 로그 파일을 별도의 디스크에 보관하면 데이터 손실을 상당히 줄일 수 있습니다. 예를 들어, 동일한 실제 하드 디스크에 Exchange 데이터베이스와 트랜잭션 로그 파일을 보관한 경우 해당 디스크에 오류가 발생하면 마지막 백업 시 존재한 데이터만 복구할 수 있습니다. 또는 로그 파일과 데이터베이스 파일을 별개의 디스크에 보관했다고 가정해 봅니다. 이 경우 데이터베이스 파일이 포함된 디스크에 오류가 발생하면 별개의 디스크에 있는 로그 파일에서 데이터를 복구할 수 있습니다. 성능을 최적화하고 내결함성을 높이고 문제 해결을 쉽게 하려면 다음 파일이 별도의 디스크에 놓이도록 데이터를 분할해야 합니다.
Microsoft Windows 운영 체제 파일
Exchange Server 응용 프로그램 파일
활성 복사본의 Exchange 데이터베이스 파일
활성 복사본의 Exchange 트랜잭션 로그 파일
수동 복사본의 Exchange 데이터베이스 파일
수동 복사본의 Exchange 트랜잭션 로그 파일
또한 LCR 사용 가능 저장소 그룹의 수동 복사본은 LCR 사용 가능 저장소 그룹의 활성 복사본과는 격리된 디스크에 배치해야 합니다. 그리고 LCR 파일이 포함된 디스크의 성능이 프로덕션 저장소 그룹이 포함된 디스크의 성능과 동일하도록 해야 합니다. 이처럼 성능이 동일하면 장애 조치가 발생한 경우에 LCR 복사본이 로드를 지원할 수 있습니다.
충분한 디스크 공간을 확보합니다. LCR 파일이 포함된 디스크의 크기는 프로덕션 볼륨에 따라 상대적으로 조정되어야 합니다. 수동 복사본에서 사용하는 저장소는 활성 복사본에서 사용하는 저장소와 같아야 합니다. 또한 두 저장소 솔루션에 모두 기존 데이터베이스와 예상 데이터베이스 크기 증가분을 수용하기에 충분한 공간을 포함해야 합니다.
LCR에서 iSCSI 저장소를 사용하는 경우 충분한 대역폭 및 짧은 대기 시간을 확보합니다 권장되지 않지만 LAN(Local Area Network) 또는 WAN(Wide Area Network) 링크를 통해 사서함 서버에 연결된 iSCSI(인터넷 SCSI) 저장소를 사용하여 LCR을 구성하기 위해 지원됩니다. 이 구성에서 로그 전달 및 로그 재생 작업 모두 동일한 저장소 네트워크에서 발생됩니다. 이 구성을 권장하지 않는 주요 이유는 로그 전달에 의해 발생되는 네트워크 트래픽 때문입니다. LCR이 예상 수준의 보호를 제공하려면 로그 전달이 최신 상태를 유지하고 로그 전달과 연결된 네트워크 트래픽이 로그 재생 작업과 관련된 네트워크 트래픽에 간섭되지 않도록 너무 많은 대역폭을 사용하지 않아야 합니다. 복제 트래픽은 우선 순위를 지정할 수 없습니다. 또한 다음과 같은 몇 가지 저장소 요구 사항을 고려해야 합니다.
RTM(Release To Manufacturing) 버전의 Microsoft Exchange Server 2007에서 데이터베이스의 수동 복사본 저장소는 활성 복사본에 사용되는 저장소가 제공하는 IOPS(초당 I/O)보다 2-3배 빠른 IOPS를 제공해야 합니다.
Microsoft Exchange Server 2007 SP1(서비스 팩 1)에서 수동 복사본의 저장소는 활성 복사본과 동일할 수 있습니다.
참고
Microsoft Exchange Server Jetstress 도구를 사용하여 프로덕션에 들어가기 전에 저장소 솔루션을 확인합니다. 먼저 데이터베이스의 활성 복사본에 사용할 저장소를 확인한 다음 데이터베이스의 수동 복사본에 사용할 저장소를 확인합니다. Jetstress에 대한 자세한 내용은 저장소 유효성 검사의 "저장소 관련 도구"를 참조하십시오.
LCR에 대한 프로세서 및 메모리 요구 사항
모든 Microsoft Exchange Server 2007 사서함 서버 역할 서비스 및 Microsoft Exchange Replication Service가 같은 서버에서 실행되는 LCR에 대해 사용 가능하도록 설정된 사서함 서버의 경우 이와 같은 추가적인 부하를 처리하기 위해 하드웨어 리소스가 추가로 필요합니다. 대부분의 추가 리소스는 LCR 사용 가능 사서함 서버의 로그 파일 확인 및 로그 파일 재생에서 소비됩니다. 이 추가적인 처리 비용은 약 20%(프로세서 구성 계획에 나열된 프로세서 지침 범위 초과)이며 LCR 사서함 서버의 크기를 지정할 때 고려해야 합니다. 또한 Microsoft Exchange Replication Service는 제공된 메모리 리소스에 기반한 LCR 서버에서 제대로 작동합니다. 그러나 ESE(Extensible Storage Engine) 데이터베이스 캐시가 LCR에서 최적의 효율성을 유지 관리하려면 Exchange 사서함 및 다중 역할 서버에 대해 1GB의 실제 RAM을 추가로 설치하는 것이 좋습니다(메모리 구성 계획에 나열된 메모리 지침보다 높은 값).
LCR에 대한 데이터베이스 크기 권장 사항
LCR은 데이터 손실로부터 복구할 수 있는 유연성을 훨씬 더 많이 제공합니다. LCR에서 저장소 오류나 실제 데이터베이스 손상을 방어하는 첫 번째 방법은 데이터의 수동 복사본을 활성화하고 백업에서 복원하지 않는 것입니다. LCR은 빠른 데이터 복구를 제공하지만 백업 솔루션이 아닙니다. LCR로 인해 아카이브 또는 테이프 복원을 기준으로 한 RTO(Restore Time Objectives)가 짧은 것이 훨씬 덜 중요해졌습니다. 테이프 복구 대신, 수동 복사본을 활성화하여 몇 시간이 아니라 몇 분 이내에 클라이언트에서 데이터를 사용할 수 있습니다. 이런 의미에서 LCR을 빠른 복구 메커니즘으로 생각하고 Exchange Server 2003에서 VSS(볼륨 섀도 복사본 서비스)를 사용하여 만들어진 하드웨어 기반 복제와 동일한 범주에 넣을 수 있습니다.
잘못된 백업으로 인한 복구와 같은 오프라인 데이터베이스 작업을 수행하는 것은 관리자에게 일반적인 일입니다. (예: 잘못된 테이프 또는 복구 실패) 복구가 필요한 상황의 비율이 크게 줄어들지만 그래도 여전히 복구가 필요한 경우가 있게 됩니다. 데이터베이스 크기를 결정할 때 최악의 시스템 고장에 대한 오차 허용 범위를 반드시 고려하도록 합니다.
LCR에서는 저장소 그룹의 수동 복사본에서 백업할 수 있으므로 활성 복사본의 온라인 유지 관리 창을 확장할 수 있습니다. 많은 경우에 온라인 유지 관리 창을 두 배로 확장할 수 있으며, 따라서 큰 사서함 및 데이터베이스를 가질 수 있습니다.
여기서 LCR이 위험 없이 원하는 만큼 데이터베이스를 커지게 할 수 있는 것처럼 보일 수 있지만 실제로는 그렇지 않습니다. 적절한 시간 안에 완료되는 데이터베이스당 온라인 유지 관리는 여전히 데이터베이스 크기를 제한하는 요소입니다. 그러나 LCR에서는 데이터베이스를 다시 시드해야 할 가능성 또한 제한 요소입니다. LCR에서는 데이터베이스가 중복되므로 데이터베이스의 활성 복사본이 손실되거나 손상되는 경우 데이터베이스의 수동 복사본을 활성화하여 빠르게 복구를 수행할 수 있습니다.
활성화가 발생한 후에는 한 개의 데이터베이스 복사본 즉, 새로운 활성 복사본만 남습니다. 수동 복사본이 더 이상 없기 때문에 데이터베이스 복구가 위태로울 수 있습니다. 그러나 여전히 백업이 필요합니다. 복구를 다시 사용하려면 손실되거나 손상된 데이터베이스를 제거해야 하며 데이터베이스의 새로운 수동 복사본을 만들어 활성 복사본에서 다시 시드해야 합니다. 데이터베이스 크기에 따라 이러한 작업은 시간이 오래 걸릴 수 있습니다. 최악의 시나리오는 모든 활성 복사본의 손실 또는 손상으로, 이 경우 모든 수동 복사본을 다시 시드해야 합니다.
연속 복제를 사용할 때는 최대 데이터베이스 크기를 더 크게 조정할 수 있습니다. Exchange 2007에 대한 최대 데이터베이스 크기를 다음과 같이 설정하는 것이 좋습니다.
LCR 없이 사서함 서버에서 호스팅되는 데이터베이스: 100GB
LCR을 사용하는 사서함 서버에서 호스팅되는 데이터베이스: 200GB
중요
데이터베이스의 실제 최대 크기는 조직에서 사용 중인 SLA(서비스 수준 계약)에 의해 지정되어야 합니다. 조직의 SLA에 지정되어 있는 기간 내에 백업 및 복구할 수 있는 최대 크기의 데이터베이스를 결정하는 것이 데이터베이스의 최대 크기를 결정하는 방법입니다.
LCR 및 공용 폴더 데이터베이스
LCR과 공용 폴더 복제는 Exchange에 기본 제공되는 두 개의 매우 다른 복제 형식입니다. 연속 복제와 공용 폴더 복제 간의 상호 운용성 제한으로 인해 Exchange 조직의 하나 이상의 사서함 서버에 공용 폴더 데이터베이스가 있을 경우 공용 폴더 복제가 사용하도록 설정되며 LCR에 사용하도록 설정된 저장소 그룹에 공용 폴더 데이터베이스를 호스팅해서는 안 됩니다.
Exchange 조직에서 공용 폴더 데이터베이스와 LCR을 사용하는 경우 다음과 같이 구성하는 것이 좋습니다.
Exchange 조직에 사서함 서버가 하나만 있고 이 사서함 서버가 독립 실행형 서버인 경우 사서함 서버는 LCR에 사용하도록 설정된 저장소 그룹에 공용 폴더 데이터베이스를 호스팅할 수 있습니다. 이러한 구성에서는 Exchange 조직에 공용 폴더 데이터베이스가 하나만 있습니다. 따라서 공용 폴더 복제를 사용할 수 없습니다.
사서함 서버가 여러 개 있고 하나의 사서함 서버에만 공용 폴더 데이터베이스가 있는 경우 이 사서함 서버는 LCR에 사용하도록 설정된 저장소 그룹에 공용 폴더 데이터베이스를 호스팅할 수 있습니다. 이러한 구성에서는 Exchange 조직에 공용 폴더 데이터베이스가 하나만 있습니다. 따라서 공용 폴더 복제를 사용할 수 없습니다.
LCR에 사용하도록 설정된 저장소 그룹에 공용 폴더 데이터를 마이그레이션하는 경우, 공용 폴더 복제를 사용하여 공용 폴더 데이터베이스의 콘텐츠를 LCR에 사용하도록 설정된 저장소 그룹의 공용 폴더 데이터베이스로 이동할 수 있습니다. LCR 사용 가능 저장소 그룹에 공용 폴더 데이터베이스를 만들었으면 공용 폴더 데이터를 LCR 사용 가능 저장소 그룹의 공용 폴더 데이터베이스에 완전히 복제할 때까지만 추가 공용 폴더 데이터베이스가 존재해야 합니다. 복제가 완료되면 LCR 사용 가능 저장소 그룹 외부의 모든 공용 폴더 데이터베이스를 제거해야 하며 Exchange 조직에서 어떠한 다른 공용 폴더 데이터베이스도 호스팅해서는 안 됩니다.
LCR에 사용하도록 설정된 저장소 그룹 외부로 공용 폴더 데이터를 마이그레이션하는 경우, 공용 폴더 복제를 사용하여 공용 폴더 데이터베이스의 콘텐츠를 LCR에 사용하도록 설정된 저장소 그룹의 공용 폴더 데이터베이스 외부로 이동할 수 있습니다. LCR에 사용하도록 설정된 저장소 그룹 외부에 추가 공용 폴더 데이터베이스를 만들었으면 공용 폴더 데이터를 추가 공용 폴더 데이터베이스에 완전히 복제할 때까지만 LCR에 사용하도록 설정된 저장소 그룹에 공용 폴더 데이터베이스가 존재해야 합니다. 복제가 완료되면 모든 LCR 사용 가능 저장소 그룹에 있는 공용 폴더 데이터베이스를 모두 제거해야 하며 모든 후속 공용 폴더 데이터베이스를 연속 복제에 사용하도록 설정된 저장소 그룹에 호스팅해서는 안 됩니다.
Exchange 조직에 두 개 이상의 공용 폴더 데이터베이스가 있으며 LCR에 사용하도록 설정된 저장소 그룹에서 하나 이상의 공용 폴더 데이터베이스가 호스팅되어 있는 동안, LCR 활성 저장소 그룹에 오류가 발생하여 공용 폴더 데이터베이스에 있는 저장소 그룹의 수동 복사본을 활성화해야 할 경우, 공용 폴더 데이터베이스를 호스팅하는 저장소 그룹의 모든 로그를 사용할 수 있을 때에만 탑재가 가능합니다. 활성 복사본 오류로 인해 누락되거나 사용할 수 없는 로그가 있을 경우 공용 폴더 데이터베이스의 수동 복사본을 활성화할 수 없습니다. 이 경우 데이터 손실이 발생하지 않도록 활성 복사본을 온라인 상태로 만들거나, 저장소 그룹의 활성 복사본에서 공용 폴더 데이터베이스를 다시 만들고 수동 복사본이 아닌 공용 폴더 데이터베이스의 공용 폴더 복제를 사용하여 콘텐츠를 복구해야 합니다.
LCR에 대한 모니터링 권장 사항
LCR은 데이터 가용성 솔루션입니다. 이 솔루션은 사전에 모니터링되어야 합니다. Exchange 2007에서는 LCR 복사본에 대한 다양한 상태 정보를 게시합니다. 저장소 그룹에 대해 LCR을 활성화한 후 Exchange 관리 콘솔이나 Exchange 관리 셸을 사용하여 LCR 복사본의 상태와 구성 설정을 볼 수 있습니다. 상태 및 구성 정보를 보는 방법에 대한 자세한 단계는 로컬 연속 복제 복사본 상태를 보는 방법을 참조하십시오.
자동화된 사전 모니터링을 위해 MOM(Microsoft Operations Manager)과 MOM용 Exchange 2007 관리 팩을 사용하는 것이 좋습니다. LCR 모니터링에 대한 자세한 내용은 모니터링 및 작업 관리을 참조하십시오.
Exchange 2007 SP1에서는 Test-ReplicationHealth라는 새로운 cmdlet를 사용하여 LCR에 사용되는 저장소 그룹의 상태를 확인할 수 있습니다. Test-ReplicationHealth cmdlet에 대한 자세한 내용은 Test-ReplicationHealth를 참조하십시오.
백업 및 복원과 LCR
LCR은 로그 전달 및 로그 재생을 제공하며 데이터의 보조 복사본으로 빨리 수동 전환할 수 있도록 합니다. 이러한 기능은 데이터 수준 재해에 필요한 복구 시간을 줄여줍니다. 또한 LCR은 충분한 데이터 보호에 필요한 백업 수를 줄여 줍니다. LCR 사용으로 백업을 수행할 필요가 없는 것은 아니지만 매일 전체 백업을 수행할 필요성이 줄어듭니다. 또한 LCR을 사용하면 활성 저장소 그룹에서 수동 저장소 그룹으로 VSS(볼륨 섀도 복사본 서비스) 백업을 오프로드할 수 있습니다. 활성 복사본 LUN의 중요한 디스크 I/O를 유지하면서, 4가지 모든 백업 유형(전체, 복사, 증분 및 차등)을 수동 복사본 위치에서 가져와 클라이언트에 제공할 수 있습니다.
LCR은 전반적인 TCO(총 소유 비용)를 줄이는 것 외에도 이전 백업 솔루션보다 추가 이점을 제공합니다. LCR을 사용하면 Exchange 데이터베이스의 추가 복사본을 만들 수 있으므로 다음과 같은 이점이 제공됩니다.
데이터베이스 백업 빈도의 감소 LCR 복사본은 프로덕션 데이터베이스 오류를 방지하기 위한 최우선 방어책입니다. 프로덕션 저장소 그룹 및 저장소 그룹 복사본에 모두 오류가 발생하면 백업 복사본이 필요합니다. 결과적으로 이러한 경우 장기간의 SLA(서비스 수준 계약)가 좋습니다. 장기간의 SLA와 함께 주간 전체 백업 및 일일 증분 백업이 좋습니다.
빠른 재해 복구 일반적으로 데이터 손실이 거의 없거나 전혀 없이 10분 이내에 복구됩니다.
대용량 사서함 할당량 지원 데이터베이스 크기에 상관없는 빠른 복구 결과로 가능합니다.
백업 및 복원에 대한 자세한 내용 및 별도의 지침에 대해서는 재해 복구를 참조하십시오.
Exchange 백업 및 LCR
활성 저장소 그룹과 데이터베이스 및 수동 데이터베이스 복사본에서 Exchange 인식 백업이 지원됩니다.
참고
Exchange 인식 백업을 수행하는 동안 백업이 완료되면 트랜잭션 로그 파일을 잘라내는 것이 일반적입니다. LCR의 복제 기능을 사용하면 복제되지 않은 로그가 삭제되지 않습니다. 그러므로 로그 삭제 모드에서 백업을 수행해도 복제가 로그 복사보다 훨씬 느리게 진행될 경우 사실상 사용 가능한 공간을 확보하지 못할 수 있습니다.
이 구성에서 Exchange 인식 복원은 스트리밍 또는 VSS 백업 솔루션을 사용하여 수행할 수 있습니다. 스트리밍 백업은 활성 복사본에서만 수행할 수 있지만 VSS 백업은 활성 또는 수동 복사본에서 수행할 수 있습니다.
Exchange 복원 및 LCR
Exchange 인식 복원은 스트리밍 또는 VSS 백업 솔루션을 사용하여 수행할 수 있습니다. 활성 데이터베이스 및 로그 파일 위치를 복원 대상으로 지정할 수 있습니다. 기본적으로 수동 복사본 위치로 Exchange 인식 데이터베이스 백업을 복원할 수 없습니다. 수동 복사본 위치로의 복원은 파일 수준 복원을 통해 수동으로 할 수 있습니다.
LCR에 대해 구성된 저장소 그룹에서 데이터베이스를 복원하려면, 저장소 그룹에 대한 LCR을 일시 중단해야 합니다. 복원이 완료되면 LCR을 다시 시작할 수 있습니다. 복원 중인 데이터베이스에 대해서는 LCR을 일시 중단해야 합니다.
데이터베이스를 백업에서 LCR을 사용하도록 설정된 저장소 그룹으로 복원한 후에는 각각 Suspend-StorageGroupCopy 및 Resume-StorageGroupCopy를 사용하여 저장소 그룹에 대한 연속 복제를 일시 중단했다가 다시 시작해야 합니다. 이 프로세스는 올바른 로그 생성 정보를 사용하여 Microsoft Exchange 복제 서비스를 업데이트하는 데 필요합니다. 연속 복제를 일시 중단했다가 다시 시작하지 않으면 Microsoft Exchange 복제 서비스에 오래된 로그 생성 정보가 사용되어 로그 파일 복제가 중지됩니다.