다음을 통해 공유

클러스터 연속 복제

  • 아티클

 

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

마지막으로 수정된 항목: 2008-03-21

CCR(클러스터 연속 복제)은 Exchange 2007에 기본적으로 포함된 비동기 로그 전달 및 재생 기술을 클러스터 서비스에서 제공하는 장애 조치(failover) 및 관리 기능과 결합한 Microsoft Exchange Server 2007의 고가용성 기능입니다.

CCR은 다음과 같은 솔루션을 제공하여 Exchange 2007 사서함 서버에 고가용성을 제공하도록 만들어져 있습니다.

  • 단일 오류 지점이 없는 솔루션

  • 특별한 하드웨어 요구 사항이 없는 솔루션

  • 공유 저장소 요구 사항이 없는 솔루션

  • 하나 또는 두 개의 데이터 센터 구성에서 배포할 수 있는 솔루션

  • 전체 백업 빈도와 백업된 총 데이터 볼륨을 줄이고 처음으로 발생한 오류의 복구 시간에 대한 SLA(서비스 수준 계약)를 단축하는 솔루션

CCR은 Exchange 2007의 데이터베이스 오류 복구 기능을 사용하여 활성 데이터베이스 복사본에 대해 수행한 변경 내용이 적용된 두 번째 데이터베이스 복사본의 연속 및 비동기 업데이트를 수행할 수 있도록 합니다. CCR 환경에서 수동 노드를 설치하는 동안 각 저장소 그룹 및 해당 데이터베이스가 활성 노드에서 수동 노드로 복사됩니다. 이 작업을 시드라고 하며, 이를 통해 복제를 위한 기본적인 데이터베이스가 제공됩니다. 초기 시드가 수행되고 나면 로그 복사 및 재생이 연속적으로 수행됩니다.

CCR 환경에서는 복제 기능이 클러스터 서비스와 통합되어 고가용성 솔루션이 제공됩니다. CCR에서는 데이터 및 서비스 가용성뿐 아니라 예약된 중단 기능도 제공합니다. 업데이트를 설치해야 하거나 유지 관리 작업을 수행해야 할 때 관리자는 이전 버전의 Exchange Server에서는 Exchange 가상 서버라고 했던 클러스터된 사서함 서버를 직접 수동 노드로 이동할 수 있습니다. 이동 작업이 완료되고 나면 관리자가 필요한 유지 관리 작업을 수행할 수 있습니다.

이동 작업은 Exchange 관리 셸의 Move-ClusteredMailboxServer cmdlet를 사용하여 수행됩니다. 또한 Microsoft Exchange Server 2007 SP1(서비스 팩 1)의 Exchange 관리 콘솔에는 클러스터된 사서함 서버 관리라는 새로운 마법사가 포함되어 있으며 이 마법사를 사용하여 클러스터된 사서함 서버를 이동할 수 있습니다. 이러한 작업에서 사용되는 논리를 통해 필요한 설정이 적용되므로 이동 작업 동안 사서함 데이터가 손실되지 않습니다. 또한 이 작업은 이동 전에 검사 작업도 수행하여 수동 노드의 복제본을 빠르게 활성화할 수 있는지 확인합니다.

다음은 CCR의 주요 특징입니다.

  • 연속 복제는 비동기 방식입니다.   로그는 닫아야 복사할 수 있으며 사서함 서버에서 더 이상 사용되지 않습니다. 즉, 일반적으로 활성 노드에는 있는 모든 로그 파일의 복사본이 수동 노드에는 없습니다. 유일한 예외는 관리자가 활성 노드의 예약된 중단을 시작하여 업데이트를 적용하거나 기타 유지 관리 작업을 수행하는 경우입니다.

  • 일반적인 작업 시에는 연속 복제로 인해 활성 노드에 CPU 및 I/O(입/출력) 부하가 거의 발생하지 않습니다.   CCR은 수동 노드를 사용하여 로그를 복사 및 재생합니다. 수동 노드에서는 보안 파일 공유를 통해 로그에 액세스합니다.

  • 클러스터 수명 동안 수행되는 활성 노드 및 수동 노드 변경 내용은 자동으로 지정됩니다.   예를 들어, 장애 조치(failover)가 발생한 후에는 활성과 수동 지정이 반전됩니다. 즉, 복제 방향이 반대로 바뀝니다. 복제를 역방향으로 바꾸기 위한 관리 작업은 필요하지 않습니다. 시스템에서 복제 반전을 자동으로 관리합니다.

  • 장애 조치와 예약된 중단 시간은 기능 및 성능과 대칭적으로 이루어집니다.   예를 들어, 노드1에서 노드2로의 장애 조치에 걸리는 시간과 노드2에서 노드1로의 장애 조치에 걸리는 시간이 같습니다. 일반적으로 이 작업에 걸리는 시간은 2분 미만입니다. 대규모 서버의 경우 일반적으로 예약된 중단 시간은 4분 미만입니다. 장애 조치와 예약된 중단 간의 시간 차이는 예약된 중단에 대해 활성 노드에 제어된 종료를 수행하는 데 걸리는 시간과 연관되어 있습니다. 이 성능 차이는 이후 서비스 팩에서는 감소될 예정입니다.

  • 수동 노드에서 VSS(볼륨 섀도 복사본 서비스) 백업이 지원됩니다.   이로 인해 관리자가 활성 노드에서 백업을 오프로드하고 백업 창을 확장할 수 있습니다 또한 대규모 구성에서도 VSS 백업을 사용하려면 하드웨어 VSS가 지원되어야 한다는 성능 요구 사항의 제한을 받지 않습니다. 수동 노드의 작업 부하는 주로 로그 복사 및 로그 재생으로 인한 것인데 이 두 작업은 활성 노드의 클러스터된 사서함 서버처럼 실시간 제약을 받지 않습니다. 예를 들어 활성 노드는 제시간 내에 클라이언트 요청에 응답해야 합니다. 수동 노드에는 실시간 응답 제한이 없으므로 더 큰 데이터베이스 및 사서함 크기를 사용할 수 있습니다. 그렇기 때문에 보다 시간이 긴 백업 창을 사용할 수 있습니다.

  • 백업 미디어의 전체 데이터 양이 줄어듭니다.   CCR 수동 노드 복사본은 손상 및 데이터 손실에 대한 최우선적인 방어를 제공합니다. 그러므로 오류가 두 번 발생해야 백업이 사용됩니다. 첫 번째 오류의 경우 복원이 필요하지 않기 때문에 복구 작업의 SLA는 상대적으로 짧습니다. 그러나 두 번째 오류에 대한 복구 작업의 SLA는 훨씬 길어질 수 있습니다. 그러므로 매일 증분 백업 전략을 사용하여 매주 전체 백업을 수행할 수 있습니다. 이를 통해 백업 미디어에 배치해야 하는 전체 데이터 볼륨이 줄어듭니다.

  • CCR은 SCR(대기 연속 복제)과 결합할 수 있습니다.   CCR을 SCR과 결합하여 저장소 그룹을 기본 데이터 센터(고가용성을 위해 CCR 사용)에 로컬로 복제하고 보조 또는 백업 데이터 센터(사이트 복구를 위해 SCR 사용)에 원격으로 복제할 수 있습니다. 보조 데이터 센터에는 SCR 대상을 호스팅하는 장애 조치 클러스터의 수동 노드가 포함될 수 있습니다. 이러한 유형의 클러스터는 클러스터된 사서함 서버를 포함하고 있지 않지만, 복구 시나리오에서 클러스터된 사서함 서버로 대체하여 빠르게 제공할 수 있기 때문에 대기 클러스터라고 합니다. 기본 데이터 센터에 장애나 기타 손실이 발생하면 이 대기 클러스터에서 호스팅된 SCR 대상을 해당 대기 클러스터에서 즉각 활성화할 수 있습니다.

CCR 핵심 아키텍처

CCR은 다음 요소를 결합합니다.

  • Microsoft 장애 조치(failover) 클러스터에서 제공하는 장애 조치(failover) 및 가상화 기능

  • 클러스터 작동에 대한 감시로 파일 공유를 사용하는 과반수 기반의 장애 조치 클러스터 쿼럼 모델

  • Exchange 2007의 트랜잭션 로그 복제 및 재생 기능

  • 전송 쓰레기 수거통이라고 하는 허브 전송 서버의 메시지 큐 기능

Windows 장애 조치 클러스터

다음 그림과 같이 Exchange 2007 SP1에서 CCR은 Windows Server 2003 서비스 팩 2 또는 Windows Server 2008을 실행하는 단일 장애 조치 클러스터에 가입된 두 대의 컴퓨터(노드라고 함)를 사용합니다. 장애 조치 클러스터의 노드는 단일 클러스터된 사서함 서버를 호스트합니다. 클러스터된 사서함 서버를 현재 실행 중인 노드를 활성 노드라고 하며 클러스터된 사서함 서버를 실행하고 있지 않지만 클러스터의 일부이며 연속 복제의 대상인 노드를 수동 노드라고 합니다. 유지 관리되는 예약된 중단 시간 및 예약되지 않은 중단 시간의 결과로 인해, 활성 또는 수동으로 지정된 노드 상태는 장애 조치 클러스터의 수명에 걸쳐 여러 번 변경됩니다.

CCR의 기본 배포

클러스터 연속 복제 아키텍처

장애 조치(failover) 클러스터는 클러스터 서비스 및 다음과 같은 특정 유형의 클러스터 쿼럼 모델을 사용하여 만들 수 있습니다.

파일 공유 감시

앞의 두 쿼럼 모델은 세 번째 컴퓨터의 파일 공유를 감시 기능으로 사용합니다. 이러한 쿼럼 모델에서 세 번째 컴퓨터의 파일 공유는 브레인 신드롬 분할이라고도 알려진 클러스터 내의 네트워크 파티션이 발생하지 않도록 하는데 사용됩니다. 브레인 신드롬 분할은 내부 클러스터 통신을 수행하도록 지정된 모든 네트워크가 실패하는 경우에 발생하며 노드가 서로 하트비트 신호를 받지 못하게 됩니다. 두 개의 노드 대부분과 파일 공유가 항상 사용 가능하고 클러스터된 사서함 서버가 작동하도록 상호 작용함으로써 브레인 신드롬 분할을 방지할 수 있습니다. 대부분의 컴퓨터가 통신 중인 경우를 일컬어 클러스터에 쿼럼이 있다고 합니다. 파일 공유 미러링 모니터의 파일 공유는 Windows Server가 실행 중인 컴퓨터에서 호스팅될 수 있습니다. 파일 공유를 호스팅하는 Windows Server 운영 체제의 버전이 CCR 환경의 운영 체제와 일치할 필요는 없습니다. 그러나 클러스터된 사서함 서버가 있는 Active Directory 디렉터리 서비스 사이트에서 허브 전송 서버를 사용하여 파일 공유를 호스팅하는 것이 좋습니다. 이렇게 하면 메시징 관리자가 파일 공유에 대한 제어를 유지 관리할 수 있기 때문입니다.

참고

파일 공유 감시에서 사용되는 파일 공유는 DFS(분산 파일 시스템) 환경에서 호스팅할 수 없습니다.

파일 공유 미러링 모니터는 클러스터 외부의 컴퓨터에서 파일 공유를 사용하여 클러스터인 두 노드의 작업에 대한 미러링 모니터로 작동합니다. 감시 기능은 두 개의 노드에서 클러스터를 제어하고 있는 노드를 추적하는 데 사용됩니다. 기록판은 두 노드가 서로 통신할 수 없는 경우에만 필요합니다. 노드1과 노드2로 구성된 2개 노드 클러스터된 사서함 서버의 경우, 노드1은 기록판에 대한 제어권을 가질 수 있는 노드이므로 클러스터에 대한 제어권을 가질 수 있으며 클러스터된 사서함 서버를 가져올 수 있습니다. 노드2가 작동하지만 노드1과 통신할 수 없는 경우 노드2는 기록판에 대한 제어권을 가지려고 시도하며 실패합니다. 노드2가 기록판을 제어할 수 없다는 것은 클러스터된 사서함 서버를 가져올 수 없음을 의미합니다.

두 노드가 서로 상호 작용할 수 있으면 기록판이 필요 없으며 오프라인 상태일 수 있습니다. 그러나 이후에 노드 오류가 발생하면 파일 공유 미러링 모니터를 사용할 수 없는 경우 클러스터된 사서함 서버가 온라인이 될 수 없습니다.

파일 공유가 유지하는 상태는 앞에서 설명한 상태가 전부입니다. 따라서 모든 클러스터 구성 정보가 두 노드 간에 교환됩니다. 즉, 노드1을 사용할 수 있고 노드2를 사용할 수 없는 경우 파일 공유 미러링 모니터와 통신할 수 있더라도 노드1과 통신하기 전에는 노드2를 사용할 수 없습니다.

파일 공유 미러링 모니터 지원을 통해 파일 공유 미러링 모니터의 정기적인 액세스 검사가 제공됩니다. 액세스 검사가 실패하면 이벤트가 생성됩니다. 이벤트는 모니터링 시스템에서 검색되고 수집되며 보고될 수 있습니다. 따라서 두 번째 동시 오류로 인해 중단되는 문제가 발생하기 전에 운영 직원이 문제를 해결할 수 있습니다.

파일 공유는 다음과 같은 조건에서 액세스됩니다.

  • 클러스터 노드가 나타나고 클러스터 노드 하나만 사용할 수 있는 경우

  • 네트워크 연결 문제로 인해 이전의 연결할 수 있는 노드가 클러스터와 통신하지 못하는 경우

  • 클러스터 노드가 클러스터를 벗어난 경우

  • 주기적인 유효성 검사 목적의 경우. 빈도는 사용자가 구성할 수 있습니다.

이와 같은 이유로 파일 공유에서 로드는 적습니다. 따라서 단일 서버는 여러 개의 CCR 환경에 대한 파일 공유를 제공할 수 있습니다. 그러나 각 CCR 환경에는 이 서버에 대한 고유의 전용 폴더와 공유가 있어야 합니다.

파일 공유 감시에 대한 고려 사항

CCR은 두 개 노드 환경으로, 전형적인 MNS 클러스터에서 요구되었던 클러스터의 세 번째 노드(또는 그 이상의 노드) 대신 파일 공유 감시 기능이 있는 MNS 쿼럼이나 노드 및 파일 공유 과반수 쿼럼을 사용합니다. 지리적으로 분산된 CCR 환경은 두 개의 데이터 센터 배포에 해당되는데 활성 노드는 기본 데이터 센터에 배포되며 수동 노드는 보조 데이터 센터에 배포됩니다. 따라서 지리적으로 분산된 CCR 환경에는 파일 공유 배치를 위한 두 가지 옵션이 있는데, 기본 데이터 센터에 배치 또는 세 번째 데이터 센터에 배치가 이에 해당됩니다.

첫 번째 옵션은 기본 데이터 센터에 허브 전송 서버의 파일 공유를 구성하는 것입니다. 메시징 관리자가 파일 공유를 관리하고 파일 공유 중단을 모니터링할 수 있으므로 허브 전송 서버를 사용하는 것이 좋습니다. 지금까지의 경험과 고객의 피드백에 의하면 가장 흔한 유형의 네트워크 서비스 중단은 WAN(Wide Area Network) 토폴로지에서 발생합니다. 파일 공유를 기본 데이터 센터에 배치하면 두 데이터 센터 사이의 네트워크 장애로 인한 서비스 중단을 피할 수 있으므로 유용합니다. 이 구성을 사용한다는 것은 기본 데이터 센터가 중단될 경우 자동 장애 조치(failover)가 발생하지 않음을 의미합니다. 하지만 장애 조치(failover) 클러스터 내의 대부분은 기본 데이터 센터와 보조 데이터 센터 간의 네트워크 장애에 영향을 받지 않습니다.

두 번째 옵션은 세 번째 물리적 사이트내에서 관리되는 서버 역할의 파일 공유를 구성하는 것입니다. 관리되는 서버 역할은 메시징 서비스의 배달에 중요한 다른 서버와 비슷한 수준으로 지원되고 관리되는 서버입니다. 관리되는 서버 역할의 한 예는 기본 데이터 센터의 허브 전송 서버입니다. 이 세 번째 물리적 사이트는 지사 또는 세 번째 데이터 센터입니다. 이렇게 구성하려면 세 번째 사이트에는 대기 시간이 짧고 안정성이 높은 기본 데이터 센터 및 보조 데이터 센터를 위한 네트워크 인프라가 있어야 합니다.

트랜잭션 로그 복제 및 재생

트랜잭션 로그 복제와 재생은 변경된 데이터를 복사하고 수동 복사본의 데이터베이스를 업데이트하는 데 사용됩니다. 복제는 ESE(Extensible Storage Engine)에서 생성한 변경 기록을 활용합니다. 이 변경 기록은 고정 크기 1메가바이트(MB)의 로그 파일 시퀀스로 표시됩니다. 각 로그 파일이 생성될 때 복제 기능을 통해 로그 파일이 수동 노드에 복사됩니다. 복제 메커니즘은 온라인 데이터베이스에 대해 비동기적입니다. 로그가 수동 노드에 도달하면 이 로그는 손상되지 않았는지 확인되고 수동 노드에 저장된 데이터베이스의 복사본으로 재생됩니다. 재생 프로세스는 변경 로그에 설명된 변경 사항을 수동 노드의 데이터베이스에 실행하며, 이를 통해 수동 노드의 데이터베이스는 약간의 시차를 두고 프로덕션 데이터베이스와 일치하게 됩니다.

노드 간에 데이터가 복제되기 때문에 클러스터된 사서함 서버는 클러스터의 노드 중 하나에서 작동할 수 있습니다. 이 기능을 통해 한 노드에 예약된 중단 또는 오류가 발생해도 클러스터된 사서함 서버가 장기간 중단되지 않으므로 가용성이 대폭 향상됩니다. 또한 한 노드에서 저장소의 서비스 중단이 발생해도 다른 노드 및 클러스터된 사서함 서버의 가용성에는 영향을 주지 않습니다. 파일 공유가 사용 가능하고 수동 노드와 통신할 수 있는 경우 활성 노드가 중단되면 클러스터된 사서함 서버는 나머지 노드로 이동되어 계속해서 작동합니다.

CCR 환경에서 활성 노드의 트랜잭션 로그 파일 폴더는 표준 Windows 파일 공유를 사용하여 공유됩니다. 저장소 그룹의 개체 GUID(글로벌 고유 식별자)는 공유 이름에 사용되며 공유 이름 뒤에 달러 기호($)가 추가됩니다. 수동 노드의 Microsoft Exchange Replication Service는 활성 노드의 공유에 연결하고 SMB(서버 메시지 블록) 프로토콜을 사용하여 로그 파일을 복사하거나 끌어옵니다. 그런 다음 수동 노드는 로그 파일을 확인하고 수동 노드의 데이터베이스 복사본으로 재생합니다.

참고

트랜잭션 로그 파일 복제의 SMB 트래픽은 암호화되지 않습니다. 필요한 경우 IPsec(인터넷 프로토콜 보안)을 사용하여 이 트래픽을 암호화할 수 있습니다. 트랜잭션 로그 파일 복제는 SMB 프로토콜을 사용해서만 발생합니다. 수동 복사본의 다시 시드는 암호화되지 않은 통신인 ESE 백업 API(응용 프로그래밍 인터페이스)를 사용하여 수행됩니다. 필요한 경우 IPSec을 사용하여 이 데이터를 암호화할 수 있습니다.

예비 클러스터 네트워크를 통한 연속 복제

RTM 버전의 Microsoft Exchange Server 2007에서 CCR 환경의 모든 트랜잭션 로그 파일 복사 및 시드 작업은 공용 네트워크 상에서 발생합니다. 이러한 구성에는 다음과 같은 제한이 있습니다.

  • 수동 노드를 몇 시간 동안 사용할 수 없는 경우에는 전송해야 할 로그가 엄청나게 많이 쌓입니다. 이러한 로그는 수동 노드가 다시 사용할 수 있게 되었을 때 가능한 빨리 이동되어야 합니다. 그런데 공용 네트워크를 통해 로그를 복사하면 로그의 이동이 클라이언트 트래픽과 경쟁하게 됩니다. 이로 인해 클라이언트 트래픽에 영향을 미치게 되며 재동기화가 느려집니다.

  • 공용 네트워크에 장애가 발생하면 로그 데이터를 사용할 수 있더라도 장애 조치(failover)가 손실됩니다.

  • 로그 통신에 격리된 네트워크를 사용하면 암호화 및 이와 관련된 성능 패널티를 사용하지 않고 메시징 데이터에 대한 보안 기능을 제공할 수 있습니다.

  • 몇 가지 상황에서는 로그 폭풍이 일어날 수 있는데, 이 경우 시스템의 복제 부하량이 비정상적으로 많아집니다. 이로 인해 로그 데이터가 클라이언트 통신에 사용되는 네트워크와 동일한 네트워크를 통해 통신되어야 하는 경우 클라이언트 기아 상태가 발생됩니다.

이러한 문제가 모두 같은 주기로 발생되는 것은 아닙니다. 하지만 첫 번째 문제는 수동 노드가 정기적인 유지 관리 작업을 위해 오프라인 상태로 되므로 몇 달의 주기로 발생됩니다.

Exchange 2007 SP1에서는 관리자가 로그 전달을 위한 혼합 네트워크(내부 클러스터 하트비트 트래픽과 클라이언트 트래픽을 모두 지원하는 클러스터 네트워크)를 클러스터에 하나 이상 만들 수 있으므로 위 문제의 영향을 최소화합니다. 또한 Exchange 2007 SP1에서는 관리자가 시드에 사용할 특정 혼합 네트워크를 지정할 수 있습니다.

참고

로그 전달 및 시드에 사용되는 클러스터 네트워크는 혼합 네트워크로 구성되어야 합니다. 혼합 네트워크란 클러스터(하트비트)와 클러스터 액세스 트래픽 모두에 대해 구성된 클러스터 네트워크입니다. 또한 연속 복제 호스트 이름으로 구성 중인 네트워크 어댑터에서 관리자는 고급 TCP/IP 속성 대화 상자에서 DNS에 이 연결의 주소를 등록 확인란의 선택을 취소하고 각 노드에 정적 DNS 항목이나 호스트 파일 항목을 사용하여 각 노드에서 새로 만든 호스트 이름에 대한 이름 확인을 허용해야 합니다. 네트워크 어댑터에서 사용되는 DNS 서버는 공용 또는 개인 네트워크에 있을 수 있으며 그 위치와 상관 없이 양 노드에서 액세스하여 호스트 이름을 확인할 수 있어야 합니다. 또한 Windows Server 2008에서 로그 전달 또는 시드에 사용되는 네트워크 어댑터의 경우 NetBIOS를 사용하도록 설정해야 합니다.

혼합 네트워크를 통한 로그 파일 복사 지원은 Enable-ContinuousReplicationHostName이라는 새로운 cmdlet를 사용하여 구성됩니다. 마찬가지로 이 기능은 Disable-ContinuousReplicationHostName cmdlet를 사용하여 해제됩니다.

클러스터된 사서함 서버가 CCR 환경에 있는 경우, 관리자는 Enable-ContinuousReplicationHostName을 클러스터의 양쪽 노드에서 실행하고, 추가 IP 주소와 호스트 이름을 지정할 수 있습니다. 이후에 이러한 주소와 호스트 이름은 각 노드와 연결된 전용 클러스터 그룹에 만들어집니다. 이 작업이 수행된 이후, 구성이 완료되고 새 네트워크가 작동되는지 확인되면 바로 Microsoft Exchange Replication Service는 로그를 복사하는 데 새로 만든 네트워크를 사용하기 시작합니다. 새 네트워크가 여러 개 만들어지면, Microsoft Exchange Replication Service는 그 중 하나를 임의로 선택합니다. 특정 네트워크를 사용할 수 없게 되면 Microsoft Exchange Replication Service는 자동으로 다른 복제 네트워크를 사용하기 시작하고, 사용할 수 있는 네트워크가 없으면 공용 네트워크를 사용하여 5분 내에 로그를 전달합니다. (Microsoft Exchange Replication Service 네트워크 검색은 5분마다 수행됩니다. 기본 설정 복제 네트워크를 다시 사용할 수 있게 되면 Microsoft Exchange Replication Service는 기본 설정 복제 네트워크를 사용하여 로그를 전달하도록 자동으로 전환됩니다.

이러한 cmdlet에 대한 자세한 내용은 Enable-ContinuousReplicationHostName 및 Disable-ContinuousReplicationHostName을 참조하십시오.

중복 클러스터 네트워크를 통한 시드 지원은 Update-StorageGroupCopy cmdlet를 사용하여 구성됩니다. Exchange 2007 SP1에서 이 cmdlet는 DataHostNames라는 새 매개 변수를 포함하도록 업데이트되었습니다. 이 매개 변수는 시드에 사용해야 하는 클러스터 네트워크를 지정하는 데 사용됩니다. Exchange 2007 SP1의 Update-StorageGroupCopy cmdlet 변경 내용에 대한 자세한 내용은 Update-StorageGroupCopy를 참조하십시오.

연속 복제를 위해 클러스터 네트워크를 만들었으면, Get-ClusteredMailboxServerStatus cmdlet를 사용하여 연속 복제 작업에 사용할 수 있는 클러스터 네트워크에 대한 업데이트 정보를 볼 수 있습니다. 새로운 출력 자세히는 다음과 같습니다.

  • OperationalReplicationHostNames:{Host1,Host2,Host3}

  • FailedReplicationHostNames:{Host4}

  • InUseReplicationHostNames:{Host1,Host2}

Exchange 2007 SP1의 Get-ClusteredMailboxServerStatus cmdlet 변경 내용에 대한 자세한 내용은 Get-ClusteredMailboxServerStatus를 참조하십시오.

전송 쓰레기 수거통

자동 복구 중에 손실된 데이터의 대부분은 이후에 전송 쓰레기 수거통이라는 허브 전송 서버 기능을 통해 자동으로 복구됩니다. 특정 데이터베이스에 대한 전송 쓰레기 수거통은 클러스터된 사서함 서버가 있는 Active Directory 사이트의 모든 허브 전송 서버에 있을 수 있습니다. 메시지가 허브 전송 서버를 통해 CCR 환경의 클러스터된 사서함 서버로 이동될 때 복제 창이 사라질 때까지 복사본이 전송 큐(mail.que)에 보관됩니다. 전송 쓰레기 수거통은 CCR 배포의 필수 구성 요소입니다. 전송 쓰레기 수거통은 장애 조치에 의해 영향을 받는 일부 데이터를 다시 확보해야 하는 환경에서 중복 기능을 활용합니다. 특히 허브 전송 서버에서는 최근에 배달된 메일의 큐를 유지합니다. 이 큐는 메일이 유지되는 시간과 사용되는 전체 공간에 의해 제약을 받습니다. 무손실이 아닌 장애 조치가 발생한 경우, 클러스터된 사서함 서버의 CCR은 Active Directory 사이트의 모든 허브 전송 서버에게 전송 쓰레기 수거통 큐의 메일을 다시 전송하도록 자동으로 요청합니다. 정보 저장소에서는 자동으로 중복 메일을 삭제하고 손실된 메일을 다시 배달합니다.

전송 쓰레기 수거통은 CCR에 사용할 수 있고 Exchange 2007 SP1에서는 LCR(로컬 연속 복제)에도 사용할 수 있습니다. 그러나 SCR 또는 SCC(단일 복사본 클러스터)에는 전송 쓰레기 수거통을 사용할 수 없습니다. CCR의 경우, 전자 메일 메시지를 전송 쓰레기 수거통에 보관하려면 CCR 환경 또는 SP1에서 클러스터된 사서함 서버(LCR에 사용할 수 있는 사서함 데이터베이스)에 사서함이 있는 받는 사람이 전자 메일 메시지에 최소한 한 명 이상 있어야 합니다.

전송 쓰레기 수거통은 관리자에게 데이터 손실량이 제한된 클러스터된 사서함 서버가 다른 노드에서 자동으로 온라인 상태가 되도록 CCR을 구성할 수 있는 옵션을 제공함으로써 데이터 손실을 방지할 목적으로 만들어졌습니다. 이러한 상황이 발생하면 시스템에서 이 전자 메일 메시지가 아직 저장되어 있는 전송 쓰레기 수거통을 사용하여, 이 서버의 사용자에게 최근에 보낸 모든 전자 메일 메시지를 자동으로 배달합니다. 이 방법을 사용하면 대부분의 경우 데이터 손실을 방지할 수 있습니다. CCR 환경에서는 사이트의 모든 허브 전송 서버에 있는 전송 쓰레기 수거통의 재배달 요청이 자동으로 수행되며, Exchange 2007 RTM에서 재시도 간격은 7일로 하드 코드됩니다. Exchange 2007 SP1에서의 재시도 간격은 MaxDumpsterTime에 대해 설정된 값과 같습니다. LCR 환경에서는 사이트의 모든 허브 전송 서버의 재배달 요청이 Restore-StorageGroupCopy 작업의 일환으로 수행됩니다.

다음과 같은 경우에는 전송 쓰레기 수거통을 사용해도 데이터 손실을 막을 수 없습니다.

  • 온라인 모드에 있는 Microsoft Outlook 클라이언트의 임시 보관함 폴더

  • 약속, 연락처 업데이트, 속성 업데이트, 작업 및 작업 업데이트

  • 클라이언트에서 허브 전송 서버로 전송 중인 보내는 메일. 전자 메일 메시지가 보낸 사람의 사서함 서버에만 존재하는 기간이 있습니다.

클러스터 연속 복제 배포

CCR 배포는 독립 실행형 Exchange 서버의 배포와 비슷하며, SCC 배포와도 비슷합니다. SCC에 대한 자세한 내용은 단일 복사본 클러스터를 참조하십시오. 그러나 CCR을 배포하는 경우 고려해야 할 중요한 차이점이 몇 가지 있습니다. 사용자 환경에서 CCR을 설계하고 배포하기 전에 다음 항목을 검토하는 것이 좋습니다.

CCR을 배포할 준비가 되면 다음 항목 중 하나에 설명된 각 설치 단계를 수행하는 과정을 시작할 수 있습니다.

Exchange 2007 SP1의 CCR 기능 향상

Exchange 2007 SP1에서는 추가 Exchange 관리 콘솔 사용자 인터페이스 요소, 향상된 상태 및 모니터링 기능, 성능 향상 등을 비롯한 몇 가지 CCR 기능이 향상되었습니다.

Exchange 관리 콘솔의 향상된 기능

CCR을 비롯한 고가용성 기능의 관리 환경을 향상시켜 주는 몇 가지 새로운 사용자 인터페이스 요소가 Exchange 2007 SP1에 추가되었습니다. 이러한 향상된 기능에는 다음이 포함됩니다.

  • 전송 쓰레기 수거통 사용자 인터페이스   새로운 전역 설정 탭이 조직 구성 작업 영역 아래의 허브 전송 노드에 추가되었습니다. 이 탭에는 조직에 대해 다음과 같은 전송 쓰레기 수거통 설정을 구성하는 데 사용할 수 있는 전송 설정 속성 페이지가 포함됩니다.

    • 저장소 그룹당 최대 크기(MB)   각 저장소 그룹에 대해 전송 쓰레기 수거통의 최대 크기를 지정합니다.

    • 최대 보존 기간(일)   전자 메일 메시지를 전송 쓰레기 수거통에 보관해야 하는 기간을 지정합니다.

  • 연속 복제   관리자가 연속 복제를 일시 중단, 다시 시작, 업데이트 및 복원할 수 있는 추가 사용자 인터페이스 컨트롤이 Exchange 관리 콘솔에 추가되었습니다. 이러한 컨트롤은 다음과 같은 Exchange 관리 셸 cmdlet를 사용하는 것과 동일한 기능을 합니다.

    • Suspend-StorageGroupCopy

    • Resume-StorageGroupCopy

    • Update-StorageGroupCopy

    • Restore-StoreGroupCopy

    이러한 cmdlet와 해당 Exchange 관리 콘솔 작업을 통해 LCR 환경과 CCR 환경에서 모두 연속 복제를 관리할 수 있습니다.

상태 및 모니터링 기능 향상

Exchange 2007 SP1에는 Exchange 2007의 관리 효율을 향상시키도록 설계된 몇 가지 변경 사항이 도입되었습니다. 이러한 변경 내용에는 Exchange 2007 RTM의 클러스터 보고 기능을 향상시킨 것과 연속 복제 환경을 사전 모니터링하기 위한 추가 기능이 포함된 것 등이 포함됩니다. 특히 변경 내용 및 기능 향상을 통해 Get-StorageGroupCopyStatus cmdlet의 알려진 결함이 수정되고, Test-ReplicationHealth라는 새로운 cmdlet가 제공되며 전송 쓰레기 수거통의 손실 창에 대해 더욱 명확히 파악할 수 있습니다.

향상된 Get-StorageGroupCopyStatus Cmdlet

Exchange 2007 RTM에는 다음과 같이 Get-StorageGroupCopyStatus 및 연속 복제 성능 카운터의 보고 상태가 정확하지 않거나 잘못 이해되는 몇 가지 상황이 있습니다.

  • 변경되지 않는 저장소 그룹 같은 활성 상태가 아닌 저장소 그룹은 정상 상태가 아닌 경우에도 정상인 것으로 보고될 수 있습니다. 이러한 상황은 로그를 재생하기 전까지는 비정상 상태가 탐지되지 않기 때문에 발생합니다.

  • 복제 초기화 중에 복제 상태가 다시 평가되고 정확하지 않을 수 있습니다. 초기화가 완료되면 상태가 업데이트됩니다.

  • 저장소 그룹의 데이터베이스를 분리할 때 LastLogGenerated 필드의 값이 잘못될 수 있습니다.

  • 로그 스트림 도중에 하나 이상의 로그가 누락된 경우 수동 복사본이 계속해서 복구를 시도하면서 복제 상태가 실패와 정상 간에 전환되는 상황이 발생합니다. 이러한 상황이 발생하면 재생 큐와 복사 큐의 크기가 계속 증가합니다.

  • 드물지만 로그를 확인한 경우에도 재생할 수 없는 경우가 있습니다. 이러한 경우 시스템에서 복구를 시도하면서 실패와 정상 상태가 번갈아 일어납니다. 이러한 상황이 발생하면 재생 큐와 복사 큐의 크기가 계속 증가합니다.

Get-StorageGroupCopyStatus 또한 CCR 환경에 대한 새 상태 정보가 추가되어 cmdlet도 향상되었습니다.

  • Get-StorageGroupCopyStatus cmdlet는 대상 컴퓨터의 Microsoft Exchange Replication Service에 네트워크를 통해 액세스할 수 없는 경우 ServiceDown의 SummaryCopyStatus를 보고합니다.

  • Get-StorageGroupCopyStatus cmdlet는 대상 컴퓨터의 Microsoft Exchange Replication Service가 초기 시작 검사를 완료하지 않은 경우 Initializing의 SummaryCopyStatus를 보고합니다. 또한 이 상태를 부울로 나타내기 위해 새 성능 카운터를 만들었습니다.

  • Get-StorageGroupCopyStatus cmdlet는 증분 다시 시드가 완료되지 않은 경우 Synchronizing의 SummaryCopyStatus를 보고합니다.

Exchange 관리 도구의 Exchange 2007 SP1 버전을 사용할 경우에만 SummaryCopyStatus 값의 새 상태를 볼 수 있습니다. Exchange 관리 도구의 Exchange 2007 RTM 버전을 사용할 경우 모든 이전 상태에 대한 상태는 실패로 보고됩니다.

Test-ReplicationHealth Cmdlet

Exchange 2007 SP1에는 Test-ReplicationHealth라는 새 cmdlet가 도입되었습니다. 이 cmdlet는 연속 복제의 사전 모니터링과 연속 복제 파이프라인을 위한 것입니다. Test-ReplicationHealth cmdlet는 복제, 클러스터 서비스 및 저장소 그룹 복제의 모든 측면을 검사하고 상태를 재생하여 복제 시스템의 전체 개요를 제공합니다. 특히 클러스터의 노드에서 실행될 경우 Test-ReplicationHealth cmdlet는 다음 표에 설명한 테스트를 수행합니다.

Test-ReplicationHealth cmdlet가 수행하는 테스트

Test 설명

클러스터 네트워크 상태

로컬 노드에 있는 모든 클러스터 관리 네트워크가 실행 중인지 확인합니다. 이 테스트는 CCR 환경에서만 실행됩니다.

쿼럼 그룹 상태

쿼럼 리소스가 포함된 클러스터 그룹이 정상인지 확인합니다. 이 테스트는 CCR 환경에서만 실행됩니다.

파일 공유 쿼럼 상태

파일 공유 감시가 있는 과반수 노드 세트 쿼럼이 사용하는 FileSharePath의 값에 도달할 수 있는지 확인합니다. 이 테스트는 CCR 환경에서만 실행됩니다.

클러스터된 사서함 서버 그룹 상태

그룹의 모든 자원이 온라인 상태인지 확인하여 클러스터된 사서함 서버가 정상인지 확인합니다. 이 테스트는 CCR 환경에서만 실행됩니다.

노드 상태

클러스터의 노드가 일시 중지된 상태가 아닌지 확인합니다. 이 테스트는 CCR 환경에서만 실행됩니다.

DNS 등록 상태

성공적인 DNS 등록 필요가 설정된 모든 클러스터 관리 네트워크 인터페이스가 DNS 등록을 통과했는지 확인합니다. 이 테스트는 CCR 환경에서만 실행됩니다.

복제 서비스 상태

로컬 컴퓨터의 Microsoft Exchange Replication Service가 정상인지 확인합니다.

일시 중단된 저장소 그룹 복사본

연속 복제에 사용되도록 설정된 저장소 그룹에 대해 연속 복제가 일시 중단되었는지 여부를 확인합니다.

실패한 저장소 그룹 복사본

저장소 그룹 복사본이 실패 상태인지 여부를 확인합니다.

저장소 그룹 복제 큐 길이

최상의 임계값보다 큰 복제 복사본 큐 길이를 가진 저장소 그룹이 있는지 여부를 확인합니다. 현재 이러한 임계값은 다음과 같습니다.

  • 경고   큐 길이가 3–5개의 로그입니다.

  • 실패   큐 길이가 6개 이상의 로그입니다.

장애 조치(failover) 이후 분리된 데이터베이스

장애 조치(failover)가 발생한 후에 분리 또는 실패한 데이터베이스가 있는지 여부를 확인합니다. 이 테스트는 장애 조치(failover)로 인해 실패한 데이터베이스만 확인합니다.

성능 향상

Exchange 2007 SP1에서는 성능 향상을 통해 고가용성 배포의 효율성을 높였습니다. 이러한 향상된 기능에는 다음이 포함됩니다.

  • 연속 복제 환경에서 저장소 그룹의 수동 복사본을 포함하는 디스크의 I/O 감소   Exchange 2007 SP1에서 연속 복제 아키텍처의 디자인이 수정되어, 이제 데이터베이스 캐시가 일련의 로그 재생 작업 간의 수동 노드에서 유지됩니다. 일련의 로그 재생 작업 간의 데이터베이스 캐시가 유지됨으로써, Microsoft Exchange Replication Service는 ESE의 데이터베이스 캐싱 기능을 사용할 수 있게 되어, 결과적으로 수동 복사본의 LUN(논리 단위 번호)에서 발생하는 디스크 I/O 양이 감소합니다. 반면 Exchange 2007 RTM에서는 각 일련의 로그 재생 작업에 대한 새 데이터베이스 캐시가 만들어져서, 일부 경우에 수동 노드의 디스크 I/O 작업이 활성 노드의 디스크 I/O 작업보다 2-3배 많아졌습니다.

  • CCR 환경의 노드 간에 클러스터된 사서함 서버의 신속한 이동   이 향상된 기능을 통해 클러스터된 사서함 서버가 2분 내에 노드 간에 이동할 수 있습니다. 이에는 관리자가 Move-ClusteredMailboxServer cmdlet를 사용하여 수행하는 이동과 클러스터 서비스가 관리하는 장애 조치(failover)가 포함됩니다. 데이터베이스는 CCR 환경에서 신속하게 이동하기 위해, 데이터베이스 캐시를 플러시하지 않고 오프라인 상태가 됩니다. 이러한 작업을 통해, 클러스터된 사서함 서버가 다른 노드로 이동될 때 발생되는 가동 중지 시간을 줄일 수 있습니다.

CCR과 함께 대기 연속 복제 사용

SCR은 Exchange 2007 SP1에 추가된 새로운 기능입니다. SCR은 기존의 연속 복제 기능을 확장하여 Exchange 2007 사서함 서버에 새로운 데이터 가용성 시나리오를 사용할 수 있도록 합니다. SCR에서는 LCR 및 CCR과 동일한 로그 전달 및 재생 기술을 사용하여 추가 배포 옵션 및 구성을 제공합니다.

SCR을 사용하면 연속 복제를 사용하여 독립 실행형 사서함 서버(LCR 적용 또는 비적용)로부터 또는 SCC나 CCR 환경의 클러스터된 사서함 서버로부터 사서함 서버 데이터를 복제할 수 있습니다.

SCR에서 만들어 유지 관리하는 사서함 서버 데이터의 복사본을 활성화하는 프로세스는 수동 프로세스로, 다시 시작 또는 다른 간단한 방법으로 복구할 수 있는 단순한 서버 중단이 아니라 치명적인 오류가 발생할 때 사용하도록 만들어졌습니다. 데이터베이스 이식성, 서버 복구 옵션(Setup /m:RecoverServer), 또는 사서함 서버가 클러스터된 경우에는 클러스터된 사서함 서버 복구 옵션(Setup /RecoverCMS)을 사용하여 SCR 대상을 활성화할 수 있습니다. 옵션은 해당 구성 및 발생한 오류 유형을 기준으로 선택합니다.

SCR에 대한 자세한 내용은 대기 연속 복제를 참조하십시오.

자세한 내용

다음 항목에서는 CCR을 고가용성 및 사이트 복구 계획의 일부로 사용하는 시기와 방법에 대해 설명합니다.