대기 연속 복제를 위한 계획

아티클
09/30/2014

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

마지막으로 수정된 항목: 2008-09-11

SCR(대기 연속 복제)의 배포가 LCR(로컬 연속 복제)과 비슷하다고는 하나 고려해야 하는 중요한 차이점이 있습니다. 즉, SCR에 대해 충족해야 하는 일반 요구 사항이 있습니다.

대기 연속 복제를 위한 일반 요구 사항

SCR을 저장소 그룹에 사용하도록 설정하기 전에 SCR 원본 및 대상에 대해 다음과 같은 요구 사항을 파악하는 것이 좋습니다.

하나의 원본에는 여러 대상이 있을 수 있습니다. 예를 들어, 하나의 원본이 동일한 데이터 센터에 있는 하나의 대상과 별도의 데이터 센터에 있는 두 번째 대상을 가질 수 있습니다. 각 원본이 가질 수 있는 대상의 수에는 제한이 없지만 원본당 대상을 4개까지만 사용하는 것이 좋습니다. 5개 이상의 대상을 구성할 경우에는 원본 서버에 미치는 추가적인 영향에 대해서 확인하고 계획해야 합니다.
각 대상에는 원본 서버가 여러 개 있을 수 있습니다. 원본과 대상 시스템 둘 다에서 Exchange 2007 SP1이 실행되어야 합니다. Exchange 2007 SP1에서 지원되는 운영 체제(예: Windows Server 2008 또는 Windows Server 2003)라면 어떠한 운영 체제라도 상관이 없지만 모든 SCR 대상 컴퓨터에서는 SCR 원본 컴퓨터와 동일한 운영 체제를 실행하고 있어야 합니다. SCR 원본 및 대상에 대해 서로 다른 운영 체제를 사용할 수 없습니다. 예를 들어, SCR 원본이 Windows Server 2003이고 SCR 대상이 Windows Server 2008이거나 이와 반대인 경우는 지원되지 않습니다.
SCR 대상 컴퓨터에는 Exchange 2007 SP1 사서함 서버 역할이 설치되어 있어야 합니다. SCR 대상 컴퓨터가 클러스터 노드인 경우 해당 노드는 수동 노드, 즉 수동 클러스터된 사서함 역할이 설치되어 있는 노드여야 하며, 클러스터에는 클러스터된 사서함 서버가 포함되어서는 안 됩니다.
대기 클러스터를 사용하고, SCR 대상 활성화 프로세스의 일부로 클러스터된 사서함 서버 복구 기능(Setup /RecoverCMS)을 사용하는 경우에 SCR을 사용하면 Exchange Server 설치 경로를 좀 더 신중하게 계획해야 합니다. 서버 복구 프로세스를 사용하려면 SCR 원본 컴퓨터와 SCR 대상 컴퓨터에서 Exchange Server의 설치 경로가 동일해야 합니다. Exchange Server를 SCR 원본 컴퓨터의 %프로그램 파일%\Microsoft\Exchange Server에 설치하면 SCR 원본 서버에 대해 SCR 대상 컴퓨터로 사용할 모든 컴퓨터에서도 해당 서버를 %프로그램 파일%\Microsoft\Exchange Server에 설치해야 합니다. 이러한 설치 경로가 일치하지 않으면 레지스트리의 설치 경로가 Active Directory 디렉터리 서비스에 있는 사서함 서버 개체의 msExchInstallPath 특성 값과 일치하지 않으므로 Setup /RecoverCMS가 실패하게 됩니다.
활성화 프로세스에 클러스터된 사서함 서버 복구가 포함되어 있는 경우에는 활성화 프로세스의 일부로 Setup /RecoverCMS를 사용하기 전에 클러스터된 사서함 서버에서 모든 저장소 그룹에 대해 SCR을 사용하지 않도록 설정해야 합니다. SCR이 모든 저장소 그룹에 대해 사용되지 않도록 설정되지 않으면 Setup /RecoverCMS가 실패합니다.
SCR 원본과 모든 대상의 저장소 그룹 및 데이터베이스 경로는 다른 저장소 그룹 또는 데이터베이스 경로와 충돌해서는 안 됩니다. SCR 원본에서 사용하는 저장소 그룹 및 데이터베이스 경로는 해당 원본에 대한 모든 SCR 대상의 저장소 그룹 및 데이터베이스 복사본에 사용되므로, SCR을 사용할 때 저장소 그룹 및 데이터베이스 경로를 보다 신중하게 계획해야 합니다.
SCR 원본 컴퓨터와 SCR 대상 컴퓨터는 동일한 Active Directory 도메인에 있어야 하지만 Active Directory 사이트는 같거나 달라도 됩니다.
각 대상 컴퓨터에서 지원하는 최대 SCR 대상(복제된 저장소 그룹) 수는 Exchange 2007 Enterprise Edition을 사용할 경우에는 50개, Exchange 2007 Standard Edition을 사용할 경우에는 5개입니다.

SCR 대상 컴퓨터의 제한 사항

수동 노드나 독립 실행형 사서함 서버를 SCR 대상으로 구성할 경우에는 다음과 같은 기능상의 제약이 있습니다.

SCR 대상으로 지정되는 독립 실행형 사서함 서버에서는 저장소 그룹에 LCR을 사용하도록 설정할 수 없습니다. Microsoft Exchange 복제 서비스는 LCR과 다른 원본의 복제를 모두 관리할 수 있도록 설계되거나 수정되어 있지 않습니다.
SCR 대상으로 지정되는 수동 노드는 클러스터된 사서함 서버가 없는 장애 조치(failover) 클러스터의 구성원이어야 합니다. 이를 대기 클러스터라고 합니다. 대기 클러스터에 대한 자세한 내용은 고가용성을 참조하십시오.

SCR 및 공용 폴더 데이터베이스

SCR과 공용 폴더 복제는 Exchange에서 기본 제공되는 매우 다른 두 가지 복제 형태입니다. 연속 복제와 공용 폴더 복제 간의 상호 운용성 제한으로 인해, Exchange 조직에 있는 두 개 이상의 사서함 서버에 공용 폴더 데이터베이스가 있을 경우 공용 폴더 복제가 사용되도록 설정되어 있지만 공용 폴더 데이터베이스를 SCR 환경에서 호스팅해서는 안 됩니다.

참고

데이터베이스 이식성은 사서함 데이터베이스에만 사용할 수 있으므로 공용 폴더 데이터베이스의 SCR 대상 복사본 활성화는 서버 또는 클러스터된 사서함 서버 복구 작업의 일부분으로만 수행할 수 있습니다(예: Setup /m:recoverServer 또는 Setup /recoverCMS).

Exchange 조직에서 공용 폴더 데이터베이스와 SCR을 사용하는 경우 다음과 같이 구성하는 것이 좋습니다.

Exchange 조직에 단일 사서함 서버가 있고 이 사서함 서버가 독립 실행형 사서함 서버이거나 SCC의 클러스터된 사서함 서버인 경우, 해당 사서함 서버에서 공용 폴더 데이터베이스를 호스팅할 수 있으며 공용 폴더 데이터베이스가 포함된 저장소 그룹을 SCR에 사용하도록 설정할 수 있습니다. 단, LCR에 해당 저장소 그룹을 사용하도록 설정하지 않은 경우에 한합니다. 이러한 구성에서는 Exchange 조직에 공용 폴더 데이터베이스가 하나만 있습니다. 따라서 공용 폴더 복제를 사용할 수 없습니다. 이 시나리오에서는 SCR을 사용하여 공용 폴더 데이터베이스 중복성을 획득할 수 있습니다. SCR은 공용 폴더 데이터베이스의 두 개 복사본을 유지 관리합니다.
여러 개의 사서함 서버 중 하나에만 공용 폴더 데이터베이스가 포함되어 있으며 이 사서함 서버가 독립 실행형 사서함 서버이거나 SCC의 클러스터된 사서함 서버인 경우, 이 사서함 서버에서 공용 폴더 데이터베이스를 호스팅할 수 있으며 공용 폴더 데이터베이스가 포함된 저장소 그룹을 SCR에 사용하도록 설정할 수 있습니다. 단, LCR에 이 저장소 그룹을 사용하도록 설정하지 않은 경우에 한합니다. 이러한 구성에서는 Exchange 조직에 공용 폴더 데이터베이스가 하나만 있습니다. 따라서 공용 폴더 복제를 사용할 수 없습니다. 이 시나리오에서도 SCR을 사용하여 공용 폴더 데이터베이스 중복성을 획득합니다.
SCR에 사용하도록 설정된 저장소 그룹으로 공용 폴더 데이터를 마이그레이션하는 경우, 공용 폴더 복제를 사용하여 공용 폴더 데이터베이스의 콘텐츠를 독립 실행형 사서함 서버나 SCC의 클러스터된 사서함 서버에서 SCR 사용 가능 저장소 그룹으로 이동할 수 있습니다. 복제가 완료되면 SCR 사용 가능 저장소 그룹 외부의 모든 공용 폴더 데이터베이스를 제거해야 하며 Exchange 조직에서 어떠한 다른 공용 폴더 데이터베이스도 호스팅해서는 안 됩니다.
SCR에 사용하도록 설정된 저장소 그룹 외부로 공용 폴더 데이터를 마이그레이션하는 경우, 공용 폴더 복제를 사용하여 공용 폴더 데이터베이스의 콘텐츠를 해당 저장소 그룹에서 독립 실행형 사서함 서버나 SCC의 클러스터된 사서함 서버로 이동할 수 있습니다. 복제가 완료되면 모든 SCR 사용 가능 저장소 그룹 내부의 공용 폴더 데이터베이스를 모두 제거해야 하며 모든 후속 공용 폴더 데이터베이스를 SCR 사용 가능 저장소 그룹에서 호스팅해서는 안 됩니다.

Exchange 조직에 두 개 이상의 공용 폴더 데이터베이스가 있으며 SCR에 사용하도록 설정된 저장소 그룹에서 하나 이상의 공용 폴더 데이터베이스가 호스팅되어 있는 동안, SCR 원본 저장소 그룹에 오류가 발생하여 SCR 대상 공용 폴더 데이터베이스를 활성화해야 할 경우, 공용 폴더 데이터베이스를 호스팅하는 저장소 그룹의 모든 로그를 사용할 수 있을 때에만 탑재가 가능합니다. SCR 원본 오류로 인해 누락되거나 사용할 수 없는 로그가 있을 경우 공용 폴더 데이터베이스의 SCR 대상 복사본을 활성화할 수 없습니다. 이 경우 데이터 손실이 발생하지 않도록 SCR 원본을 온라인 상태로 만들거나, SCR 원본에서 공용 폴더 데이터베이스를 다시 만들고 SCR 대상 복사본이 아닌 공용 폴더 데이터베이스의 공용 폴더 복제를 사용하여 콘텐츠를 복구해야 합니다.

SCR 및 백업

SCR 대상 복사본은 백업할 수 없습니다. 반면, LCR 및 CCR은 활성 복사본 및 수동 복사본 둘 다의 백업을 지원합니다. SCR은 SCR 원본에 대한 백업만 지원합니다. SCR 원본 저장소 그룹에 대해 지원되는 백업을 수행하면 SCR 대상의 데이터베이스 헤더가 업데이트되고, 로그 파일이 잘립니다. SCR 원본 저장소 그룹에 CCR 또는 LCR을 사용하도록 설정한 경우, SCR 원본 저장소 그룹의 활성 복사본 또는 수동 복사본에 대해 백업을 수행하면 SCR 대상의 데이터베이스 헤더가 업데이트되고, 로그 파일이 잘립니다.

SCR 및 복원

SCR 원본 데이터베이스를 이전 버전의 데이터베이스와 바꿀 때는 각각 Suspend-StorageGroupCopy 및 Resume-StorageGroupCopy를 사용하여 저장소 그룹에 대해 연속 복제를 일시 중단한 후에 다시 시작해야 합니다. 이 프로세스는 올바른 로그 생성 정보를 사용하여 Microsoft Exchange 복제 서비스를 업데이트하는 데 필요합니다. 연속 복제를 일시 중단했다가 다시 시작하지 않으면 복제 서비스에 오래된 로그 생성 정보가 사용되어 로그 파일 복제가 중지됩니다.

SCR 및 로그 파일 자르기

Exchange 2007 RTM의 경우, 연속 복제 환경에서 로그 파일이 데이터베이스 복사본으로 백업 및 재생되어야 로그 파일을 삭제할 수 있는 규칙이 적용됩니다. SCR을 사용할 때는 이 규칙이 수정됩니다. 여러 데이터베이스 복사본의 개념이 도입된 SCR에서는 로그 파일이 모든 SCR 대상 컴퓨터에서 검색되는 즉시 SCR 원본에서 잘릴 수 있습니다. SCR 대상 복사본의 로그 재생 지연 시간이 길게 구성될 수 있으므로 SCR 원본에서 로그 자르기 작업은 모든 로그가 모든 SCR 대상으로 재생될 때까지 기다리지 않습니다. 그러나 저장소 그룹에 대해 하나 이상의 SCR 대상이 다운된 경우에는 SCR 원본에서 로그 자르기가 수행되지 않습니다. SCR 원본에서 로그가 잘리도록 하려면 SCR 대상 컴퓨터가 온라인 상태이며 원본에서 해당 컴퓨터에 액세스할 수 있어야 합니다.

SCR 대상에서는 백그라운드 스레드가 3분마다 실행되어 잘라야 할 로그 파일이 있는지 여부를 확인합니다. 다음 세 가지 조건을 충족하면 SCR 대상에서 로그 파일이 잘립니다.

로그 파일이 SCR 원본에서 잘렸습니다.
로그 파일 생성 시퀀스가 저장소 그룹에 대한 로그 파일 검사점 이전입니다.
로그 파일이 ReplayLagTime과 TruncationLagTime을 더한 것보다 오래되었습니다. (이러한 매개 변수에 대한 설명은 대기 연속 복제 항목의 "SCR의 cmdlet 업데이트"를 참조하십시오.)

SCR로 확장된 LCR 또는 CCR 환경에서 다음 세 가지 조건을 충족하면 LCR 또는 CCR 환경에 있는 활성 복사본 및 수동 복사본에서 로그 파일이 잘립니다.

로그 파일이 백업되었습니다.
로그 파일 생성 시퀀스가 저장소 그룹에 대한 로그 파일 검사점 이전입니다.
모든 SCR 대상에서 로그 파일을 검색했습니다.

SCR용 Windows 2003 네트워킹 최적화

Windows Server 2008에서 SCR을 사용할 때는 네트워크 최적화를 수행할 필요가 없지만, Windows Server 2003에서 SCR을 사용할 때는 특정 네트워크 링크의 속도 및 대기 시간에 대해 Windows Server TCP/IP 설정을 최적화하는 것이 좋습니다. 특히 SCR 원본 컴퓨터 및 해당 SCR 대상 컴퓨터에서 TCP(Transmission Control Protocol) 수신 창 크기와 RFC(Request for Comments) 1323 창 배율 옵션을 조정해야 할 수 있습니다. 또한 ARP(Address Resolution Protocol) 캐시 만료 설정을 구성하고 Windows 레지스트리에서 Windows Server 2003 SNP(Scalable Networking Pack)에 대해 고급 TCP/IP 옵션을 사용하지 않도록 설정하면 유용할 수 있습니다.

작업 환경에서 IPsec(IP 보안) 프로토콜을 사용하는 경우에는 이러한 권장 사항 외에도 SCR 환경 전체에서 IPsec을 일관성 있게 구성하는 것이 좋습니다. SCR 원본과 모든 해당 SCR 대상이 IPsec을 사용해야 할 수도 있고, SCR 원본이나 해당 대상이 모두 IPsec을 사용하지 않아야 할 수도 있습니다. 한 노드만 IPsec을 사용하도록 구성되어 있는 경우에 IPsec 보안 연결 프로세스를 수행하면 패킷이 지연되거나 손실될 수 있습니다.

TCP 수신 창 및 RFC 1323 배율 옵션

TCP 수신 창 크기는 연결을 통해 한 번에 받을 수 있는 최대 데이터 양(바이트 단위)입니다. 송신 컴퓨터에서는 수신 컴퓨터에서 데이터 수신을 확인하고 TCP 창을 업데이트하도록 기다릴 때까지 데이터를 이 최대 양만큼만 보낼 수 있습니다. 이 설정을 조정하면 로그 전달 중에 처리량을 높이는 데 도움이 될 수 있습니다.

TCP 처리량을 최적화하려면 송신 컴퓨터에서 송신자와 수신자 간의 파이프를 채우는 데 충분한 패킷을 전송해야 합니다. 네트워크 파이프의 용량은 파이프의 대역폭과 대기 시간(왕복 시간)을 기준으로 합니다. 대기 시간이 길수록 데이터 수신을 확인하는 사이에 데이터를 보낼 수 있는 시간이 늘어나므로 용량도 늘어납니다. TCP 창 크기를 늘리면 시스템이 더 많은 데이터를 보냄으로써 데이터 수신 확인 사이의 시간을 활용할 수 있습니다.

TCP/IP 표준에서는 수신 창의 크기를 최대 65,535(8진수)까지 지정할 수 있습니다. 이는 16비트 TCP 창 크기 필드에서 지정할 수 있는 최대값입니다. 대기 시간이 긴 고대역폭 네트워크에서 성능을 높이기 위해 Windows Server TCP/IP는 RFC 1323, 고성능을 위한 TCP 확장에 설명되어 있는 확장 가능한 창을 사용하여 65,535(8진수)보다 큰 수신 창 크기를 보급하는 기능을 지원합니다. 창 배율을 사용할 때는 대화 중인 호스트가 파일 전송 프로토콜에서 자주 사용되는 패킷과 같은 다수의 대형 패킷을 수신자 버퍼에서 보류하도록 허용하는 창 크기를 협상할 수 있습니다. RFC 1323에는 TCP가 연결 설정 시에 창 크기에 대한 배율 인수를 협상하도록 허용하여 보다 큰 수신 창 크기를 지원하는 방법이 자세히 설명되어 있습니다.

두 레지스트리 항목을 수정하여 Windows Server 2003을 실행하는 컴퓨터에서 TCP 수신 창 크기 및 RFC 1323 창 배율 옵션을 최적화할 수 있습니다. 이 두 레지스트리 항목은 TCPWindowSize와 TCP1323Opts입니다. 이러한 기능에 대한 자세한 내용은 Microsoft 기술 자료 문서 224829, Windows 2000 및 Windows Server 2003 TCP 기능 설명(영문)을 참조하십시오.

네트워크 링크 및 네트워크 대기 시간을 기준으로 하여 이러한 레지스트리 항목의 최적 설정을 결정하려면 버전 13 이상의 Exchange 2007 Mailbox Server Role Storage Requirements Calculator를 사용하는 것이 좋습니다. Calculator를 다운로드하려면 Exchange 팀 블로그에서 Exchange 2007 Mailbox Server Role Storage Requirements Calculator(영문)를 참조하십시오. Storage Calculator에는 서버에서 레지스트리 값을 입력하기 위한 단계별 지침도 포함되어 있습니다.

참고

UNRESOLVED_TOKEN_VAL(exBlog)

ARP 캐시 만료

ARP 캐시는 IP 주소를 MAC(미디어 액세스 제어) 주소로 매핑하는 메모리 내 테이블입니다. ARP 캐시의 항목은 아웃바운드 패킷을 항목에 있는 IP 주소로 보낼 때마다 참조됩니다. 기본적으로 Windows Server 2003은 시스템의 요구 사항에 맞게 ARP 캐시 크기를 자동으로 조정합니다. 보내는 데이터그램에서 2분 동안 사용되지 않는 항목은 ARP 캐시에서 제거됩니다. 그리고 현재 참조되는 항목은 10분 후에 ARP 캐시에서 제거됩니다. 수동으로 추가한 항목은 캐시에서 자동으로 제거되지 않습니다.

Microsoft의 내부 IT 부서에서 시행한 내부 테스트 결과에 따르면, 기본 ARP 캐시 만료 설정을 사용하는 경우 CCR 및 SCR 환경에서 패킷이 손실됩니다. 패킷이 손실되면 전송 서버가 손실된 데이터를 다시 전송해야 합니다. 연속 복제 환경에서는 로그 파일을 최대한 빨리 수동 노드로 복사해야 합니다. 또한 패킷 손실로 인해 데이터를 다시 전송하면 로그 전달 처리량이 떨어질 수 있습니다.

Windows 레지스트리에서 ArpCacheMinReferencedLife TCP/IP 매개 변수를 수정하여 ARP 캐시 만료를 제어할 수 있습니다. 이 매개 변수는 참조되는 항목이 삭제될 때까지 ARP 캐시 테이블에 보관되어야 하는 기간을 결정합니다. Microsoft에서는 내부적으로 ArpCacheMinReferencedLife 레지스트리 값에 대한 최적 설정은 네트워크의 라우터에서 ARP 캐시 만료에 사용하는 것과 같은 값(4시간)을 사용하는 것임을 확인했습니다.

작업 환경에서 ArpCacheMinReferencedLife의 값을 수정하기 전에 Microsoft 네트워크 모니터 또는 유사한 캡처 도구를 사용하여, 활성 노드에서 수동 노드로 로그를 복사하는 데 사용되는 네트워크 인터페이스에서 네트워크 트래픽을 수집 및 분석하는 것이 좋습니다. ArpCacheMinReferencedLife 레지스트리 값을 수정하는 방법에 대한 자세한 단계는 부록 A: TCP/IP 구성 매개 변수(영문)를 참조하십시오.

Scalable Networking Pack 고급 TCP/IP 기능

Windows Server 2003 SNP(Scalable Networking Pack)는 Windows 네트워크 스택을 가속화하기 위한 상태 저장 및 상태 비저장 오프로드를 포함하는 Windows Server 2003용 별도 업데이트입니다. 이 업데이트에는 TCP Chimney 오프로드, RSS(수신측 배율) 및 NetDMA(Network Direct Memory Access) 등이 있습니다.

TCP Chimney는 상태 저장 오프로드입니다. TCP Chimney 오프로드를 사용하면 하드웨어에서 TCP/IP 프로세스를 처리할 수 있는 네트워크 어댑터로 TCP/IP 프로세스를 오프로드할 수 있습니다.

RSS 및 NetDMA는 상태 비저장 오프로드입니다. 여러 CPU가 단일 컴퓨터에 있는 경우 Windows 네트워킹 스택은 "수신" 프로토콜 처리를 단일 CPU로 제한합니다. RSS는 네트워크 어댑터로부터 수신한 패킷이 여러 CPU에 걸쳐 균형을 이루도록 함으로써 이 문제를 해결합니다. NetDMA는 PCI(Peripheral Component Interconnect) 버스에서 DMA(직접 메모리 액세스) 엔진을 사용하도록 허용합니다. TCP/IP 스택은 복사 작업을 처리하기 위해 CPU를 인터럽트하는 대신 DMA 엔진을 사용하여 데이터를 복사할 수 있습니다. 관련 구성 요소인 TCPA는 PCI 버스에서 하드웨어 DMA 엔진을 사용하여 수신 프로세스를 도울 수 있는 또 다른 오프로드 기능입니다.

일부 환경에서 이러한 기능을 사용하면 네트워크 성능이 향상되지만, 다른 기술을 사용하는 일부 경우에는 이러한 기능을 사용할 수 없습니다. 예를 들어, 다음 기술을 사용하는 경우에는 TCP Chimney 오프로드 및 NetDMA를 사용할 수 없습니다.

Windows 방화벽
IPsec(인터넷 프로토콜 보안)
IPNAT(Internet Protocol Network Address Translation)
타사 방화벽
NDIS 5.1 중간 드라이버

또한 이러한 기능을 사용하면 네트워크 성능이 저하될 수 있는 일부 환경(예: Microsoft Exchange가 설치된 환경)에서 발생하는 알려진 문제도 있습니다. 이러한 일부 문제에 대한 자세한 내용은 Exchange 팀 블로그 게시물, Windows 2003 Scalable Networking Pack 및 Exchange에 미칠 수 있는 영향(영문)을 참조하십시오.

참고