클러스터 연속 복제 관리
적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
마지막으로 수정된 항목: 2009-06-10
Exchange 조직의 일상적인 관리 작업 외에도 CCR(클러스터 연속 복제) 환경을 관리하기 위한 특정 작업이 있습니다. 일반적으로 CCR의 관리 작업은 다음과 같은 두 가지 범주로 그룹화됩니다.
클러스터된 사서함 서버 관련 작업
클러스터된 사서함 서버의 저장소 그룹 및 데이터베이스 관련 작업
클러스터된 사서함 서버 관련 작업
CCR 환경에서 클러스터된 사서함 서버와 연결된 관리 작업은 다음을 포함합니다.
디스크 볼륨 관리
구성 설정 보기
복제 작업 모니터링
성능 데이터 보기 및 수집
온라인으로 설정, 오프라인으로 설정 및 노드 간 클러스터된 사서함 서버 이동 등 클러스터된 사서함 서버 관리
로그 파일 복제 및 재생 관리
디스크 볼륨 관리
CCR 환경을 관리할 때 CCR 클러스터와 연결된 디스크 볼륨을 관리해야 하는 경우도 있습니다. 예를 들어, 유지 관리나 기타 이유로 인해 시스템에서 볼륨을 일시적으로 분리해야 하는 경우가 있습니다. 활성 저장소 그룹 또는 데이터베이스에서 이러한 경우가 발생하면 해당 저장소 그룹의 데이터베이스를 분리해야 합니다. 저장소 그룹 또는 데이터베이스의 수동 복사본에 대해 이러한 작업을 수행해야 할 경우에는 복제를 중단하여 해당 볼륨에 대한 모든 복제 I/O(입출력)를 중지시켜야 합니다.
디스크 볼륨을 관리하는 방법에 대한 자세한 내용은 CCR 복사본에 대한 디스크 볼륨 관리 작업을 준비하는 방법을 참조하십시오.
구성 설정 보기
서버에 CCR이 사용되도록 설정한 후에 Exchange 관리 콘솔과 Exchange 관리 셸을 사용하면 서버에 있는 저장소 그룹과 데이터베이스의 구성 설정을 볼 수 있습니다.
구성 정보에는 저장소 그룹 및 데이터베이스 파일의 위치가 포함됩니다. 또한 Exchange 관리 셸을 사용하면 클러스터된 사서함 서버와 관련된 구성을 검토할 수도 있습니다.
CCR 장애 조치 제어 구성 정보를 표시하는 방법에 대한 자세한 내용은 장애 조치 제어 구성을 보는 방법을 참조하십시오.
복제 작업 모니터링
데이터베이스의 수동 복사본은 최신 상태로 유지된 경우에만 유용합니다. CCR은 특별한 모니터링이 필요하지 않지만 로그 파일을 적절히 복제하는지 확인하기 위해 각 저장소 그룹을 정기적으로 모니터링할 것을 권장합니다. Microsoft Operations Manager 2005용 Microsoft Exchange Server 2007 관리 팩에는 CCR 환경과 관련된 몇 가지 중요한 문제에 대한 경고가 포함되어 있습니다.
Microsoft Exchange Replication Service가 수동 노드에서 실행되고 있지 않습니다. 이 경고를 생성하는 이벤트는 해당 서비스가 중지된 후에 반복해서 나타나지 않으므로 이벤트 관련 경고를 지울 경우 더 이상 사용할 수 없습니다.
수동 복사본이 실패 상태인 경우
수동 복사본이 정상 상태이지만 로그 복사 또는 재생 시 너무 느린 경우
또한 수동 노드가 실행 중인 것으로 검색되지 않으며 활성 노드를 포함하는 클러스터의 일부인 경우 트리거되는 사용자 지정 이벤트 규칙을 Microsoft Operations Manager에 추가하는 것이 좋습니다. 이 조건을 충족하면 클러스터 서비스는 이벤트를 시스템 이벤트 로그에 기록합니다. 클러스터 서비스에서 기록하는 이벤트에 포함될 이벤트 규칙에 대해 다음 조건을 사용하는 것이 좋습니다.
이벤트 원본: ClusSvc
이벤트 ID: 1135
Microsoft Operations Manager에서 이벤트 규칙을 만드는 방법에 대한 자세한 내용은 MOM을 사용한 보안 이벤트 모니터링을 참조하십시오.
Exchange 2007 관리 팩 또는 사용자 지정 이벤트 규칙에 의해 생성되는 위의 경고는 가능한 빨리 확인하고 해결해야 합니다.
Microsoft Operations Manager 2005용 Exchange 2007 관리 팩을 사용하는 대신 Exchange 관리 셸의 Get-StorageGroupCopyStatus cmdlet를 실행하는 스크립트를 주기적으로 실행할 수 있습니다. Get-StorageGroupCopyStatus cmdlet를 실행하면 활성 노드에서 생성하는 로그 수가 포함된 큐 길이를 알 수 있습니다. 성능상의 이유로 큐 길이 성능 카운터는 Microsoft Exchange Replication Service에 알려져 있는 정보만 보고합니다. 드문 경우지만 이는 활성 노드의 상태와 일치하지 않을 수 있습니다. Get-StorageGroupCopyStatus cmdlet에 대한 자세한 내용은 이 항목 뒷부분의 "저장소 그룹 복사본의 상태 보기"를 참조하십시오.
성능 데이터 보기 및 수집
성능 카운터를 사용하여 복제 진행률을 판단할 수 있습니다. CCR의 성능 카운터 사용에 대한 자세한 내용은 클러스터 연속 복제의 성능 카운터를 보는 방법을 참조하십시오.
클러스터된 사서함 서버 관리
클러스터된 사서함 서버 관리를 위한 세 가지 주요 관리 작업으로는 클러스터된 사서함 서버를 온라인 및 오프라인으로 가져오기, 클러스터의 노드 간에 클러스터된 사서함 서버 이동이 있습니다. 또한 업데이트 관리 또는 기타 유지 관리 작업의 일부로 클러스터의 노드 중 하나를 종료하거나 다시 시작할 수 있습니다.
클러스터된 사서함 서버 시작 및 중지
장애 조치 클러스터 관리 도구(Windows Server 2008), 클러스터 관리자(Windows Server 2003) 및 두 운영 체제의 Cluster.exe 명령줄 도구를 사용하여 리소스를 온라인 상태와 오프라인 상태로 만들 수 있습니다. 클러스터된 사서함 서버를 오프라인으로 만드는 것을 중지라고 하고 온라인으로 만드는 것을 시작이라고 합니다. 클러스터된 사서함 서버를 시작할 때는 Start-ClusteredMailboxServer cmdlet를 사용하는 것이 좋으며, 클러스터된 사서함 서버를 중지하는 적절한 방법은 Stop-ClusteredMailboxServer cmdlet를 사용하는 것입니다. Exchange 2007 SP1(서비스 팩 1)에서 Exchange 관리 콘솔의 클러스터된 사서함 서버 관리 마법사를 사용하여 클러스터된 사서함 서버를 시작 또는 중지할 수도 있습니다.
클러스터된 사서함 서버를 온라인으로 가져오는 방법에 대한 자세한 단계는 클러스터된 사서함 서버를 시작하는 방법을 참조하십시오. 클러스터된 사서함 서버를 오프라인으로 가져오는 방법에 대한 자세한 단계는 클러스터된 사서함 서버를 중지하는 방법을 참조하십시오.
노드 간에 클러스터된 사서함 서버 이동
노드 간에 클러스터된 사서함 서버를 수동으로 이동하는 것을 전달 또는 예약된 중단이라고 합니다. 클러스터된 사서함 서버를 이동하려면 Move-ClusteredMailboxServer cmdlet를 사용합니다. Exchange 2007 SP1에서는 Exchange 관리 콘솔의 클러스터된 사서함 서버 관리 마법사를 사용하여 클러스터된 사서함 서버를 전달할 수도 있습니다. 장애 조치 클러스터 관리 도구(Windows Server 2008), 클러스터 관리자(Windows Server 2003) 및 두 운영 체제의 Cluster.exe 명령줄 도구를 사용하여 노드 간에 클러스터된 사서함 서버를 이동할 수 있지만, Exchange 관리 도구 중 하나를 사용하여 클러스터된 사서함 서버를 활성 노드에서 수동 노드로 이동하면 전달 이유를 지정할 수 있기 때문에 이 방법이 좋습니다. 또한 다음 항목을 적용해야 합니다.
클러스터 도구를 사용하면 Exchange 관리 도구에서 수행하는 수동 복사본 상태에 대한 확인을 건너뜁니다. 따라서 이 방법을 사용하면 노드에서 필요한 작업을 수행하여 데이터베이스를 탑재 가능하게 만들지만 중단 기간이 길어질 수 있습니다.
클러스터 도구를 사용하면 복제 상태가 정상이 아니므로 데이터베이스가 무한정 오프라인 상태로 남을 수도 있으며, Exchange 관리 도구와 달리 클러스터 도구로는 리소스 그룹을 이동하기 전에 복제 상태를 확인할 수 없습니다.
참고
노드 간에 클러스터된 사서함 서버를 이동하면 잠시 서비스가 중단됩니다. 또한 클러스터된 사서함 서버의 저장소 그룹 백업이 취소됩니다.
복제 상태가 정상이 아니거나 확인 결과 수동 노드가 전달에 알맞은 상태가 아닌 경우, Exchange 관리 도구에서 전달 작업을 수행하지 않습니다. 이 상태에서도 CMS를 수동 노드로 이동해야 한다면 클러스터 관리 도구를 사용하여 작업을 수행할 수 있습니다.
노드 간에 네트워크 지연이 있는 장애 조치(failover) 클러스터의 클러스터된 사서함 서버를 이동하는 경우 수동 노드에서 이동 작업을 수행하는 것이 좋습니다.
노드 간에 클러스터된 사서함 서버를 이동하는 방법에 대한 자세한 단계는 CCR 환경에서 클러스터된 사서함 서버를 이동하는 방법을 참조하십시오.
클러스터에서 유지 관리 수행
유지 관리는 항상 클러스터의 수동 노드에서 수행되어야 합니다. 업데이트, 핫픽스 및 기타 응용 프로그램은 일반적으로 현재 클러스터된 사서함 서버를 소유하고 있는 활성 노드에 설치하면 안 됩니다. CCR 환경에서 Exchange 업데이트 롤업을 설치하는 방법에 대한 자세한 단계는 Exchange 2007 업데이트 롤업을 클러스터된 사서함 서버에 적용을 참조하십시오.
활성 노드에서 유지 관리를 수행해야 할 경우 먼저 Move-ClusteredMailboxServer cmdlet를 사용하여 클러스터된 사서함 서버를 수동 노드로 이동해야 합니다. 클러스터된 사서함 서버를 이동하면 이전 활성 노드는 수동 노드가 되고 이전 수동 노드는 활성 노드가 됩니다. 그런 후 유지 관리를 수행하고 클러스터된 사서함 서버를 반대 방향으로 이동하는 전달을 수행할 수 있습니다.
CCR 환경에서는 클러스터된 사서함 서버를 중단하지 않고도 특정 노드의 시스템 중단을 예약할 수 있습니다. CCR 환경에서는 한 번에 하나의 노드만 오프라인 상태로 만들 수 있습니다. 두 개 이상의 노드를 오프라인 상태로 만들면 서비스가 중단됩니다.
예약된 중단은 Exchange 관리 셸 Move-ClusteredMailboxServer cmdlet를 통해 시작됩니다. CCR 환경에서 클러스터된 사서함 서버를 이동하는 방법 항목에서는 예약된 중단을 수행하는 절차를 제공합니다.
CCR 환경에서 노드를 종료하거나 다시 시작하기 전에 클러스터된 사서함 서버를 현재 호스팅하고 있는 노드를 확인하는 것이 좋습니다. Get-ClusteredMailboxServerStatus cmdlet를 사용하면 이 정보를 얻을 수 있습니다.
클러스터에서 유지 관리 수행
유지 관리는 항상 클러스터의 수동 노드에서 수행되어야 합니다. 업데이트, 핫픽스 및 기타 응용 프로그램은 일반적으로 현재 클러스터된 사서함 서버를 소유하고 있는 활성 노드에 설치하면 안 됩니다. CCR 환경에서 Exchange 업데이트 롤업을 설치하는 방법에 대한 자세한 단계는 Exchange 2007 업데이트 롤업을 클러스터된 사서함 서버에 적용을 참조하십시오.
활성 노드에서 유지 관리를 수행해야 할 경우 먼저 Move-ClusteredMailboxServer cmdlet를 사용하여 클러스터된 사서함 서버를 수동 노드로 이동해야 합니다. 클러스터된 사서함 서버를 이동하면 이전 활성 노드는 수동 노드가 되고 이전 수동 노드는 활성 노드가 됩니다. 그런 후 유지 관리를 수행하고 클러스터된 사서함 서버를 반대 방향으로 이동하는 전달을 수행할 수 있습니다.
클러스터의 노드 종료
활성 노드를 비롯하여 클러스터의 모든 노드를 종료해야 할 경우 먼저 클러스터된 사서함 서버를 중지해야 합니다. Windows 종료 프로세스는 Exchange에서 인식되지 않습니다. 따라서 수동 노드만 종료하는 것이 좋습니다. 활성 노드를 종료하거나 다시 시작해야 할 경우에는 클러스터된 사서함 서버를 사용 가능한 다른 노드로 이동하는 것이 좋습니다. 다른 노드로 클러스터된 사서함 서버를 이동하는 방법에 대한 자세한 내용은 CCR 환경에서 클러스터된 사서함 서버를 이동하는 방법을 참조하십시오.
수동 노드가 이미 종료되어 클러스터된 사서함 서버를 수동 노드로 이동할 수 없는 경우 활성 노드를 종료하기 전에 해당 서버를 중지해야 합니다.
활성 노드를 다시 시작하거나 종료해야 하고 클러스터된 사서함 서버를 수동 노드로 이동할 수 없는 경우 활성 노드를 다시 시작하거나 종료하기 전에 그룹 정책을 사용하여 클러스터된 사서함 서버가 중단되었는지 확인하는 것이 좋습니다. Windows Server은 그룹 정책 스냅인을 사용하여 관리할 수 있는 정책 기반 컴퓨터 종료 스크립트 집합을 제공합니다. 그룹 정책 스냅인에는 컴퓨터를 종료할 때 실행되는 스크립트를 지정할 수 있는 확장이 포함되어 있습니다.
예를 들어, 적절한 매개 변수를 사용하여 Move-ClusteredMailboxServer cmdlet 또는 Stop-ClusteredMailboxServer cmdlet를 실행하는 종료 스크립트를 만들 수 있습니다. 또한 관리자가 활성 노드를 종료하기 전에 클러스터된 사서함 서버를 이동하거나 중지해야 하는 것을 모르고 시스템을 종료하거나 다시 시작할 가능성을 최소화할 수 있기 때문에 종료 스크립트를 사용하는 것이 좋습니다.
중요
이러한 스크립트는 로컬 시스템 계정에서 실행됩니다. 이러한 스크립트를 실행하려면 클러스터된 사서함 서버를 관리하기 위한 로컬 시스템 계정(로컬 노드의 컴퓨터 계정) 권한을 부여해야 합니다.
로그 파일 복제 및 재생 관리
CCR 환경에서 복제 관리에는 다음과 같은 주요 작업이 포함됩니다.
복제가 중단될 경우 장애 조치 처리
저장소 그룹 복사본에 대한 복제 중단 및 다시 시작
복제를 위한 하나 이상의 중복 네트워크 구성
복제가 중단될 경우 장애 조치 처리
복제를 중단하면 일시 중단 기간 동안 활성 저장소 그룹에서 복사본으로 변경 내용을 전파하는 모든 과정이 중지됩니다. 이 때 장애 조치를 수행하면 저장소 그룹 복사본에 최신 변경 내용이 적용되지 않습니다. 활성 노드에서 발생한 변경된 볼륨에 따라 최신 변경 내용이 부족하면 시스템이 수동 컴퓨터에 복사본을 탑재하지 못하도록 방지할 가능성이 커집니다. 따라서 수동 노드에서 사용 가능한 저장소 그룹을 사용하거나 원본 서버가 복구될 때까지 기다립니다. 이러한 노출을 최소화하기 위해서는 복제가 중단되는 시간을 최소화하는 것이 중요합니다.
원본 컴퓨터를 사용할 수 있을 때 수동 노드의 데이터 버전을 탑재하지 않는 경우 복제 시스템은 누락된 로그를 복사하고 새로운 활성 노드의 데이터베이스 복사본을 자동으로 탑재합니다.
복제를 다시 시작한 후 발생하는 장애 조치는 수동 복사본에 로그가 없거나 모든 로그를 가지고 있지만 재생되기 전인 경우 발생할 수 있습니다. 로그가 복사되었지만 재생되지 않으면 대기 중인 로그를 데이터베이스로 재생하는 장애 조치가 발생합니다. 따라서 이 저장소 그룹은 다른 저장소 그룹에 영향을 주지 않더라도 장애 조치 중에 복구 시간이 늘어납니다. 그러나 구성된 자동 탑재 기준을 만족할 만큼 충분한 로그를 사용할 수 있는 경우 시스템은 사용 가능한 최신 데이터를 가진 데이터베이스를 탑재합니다. 이 프로세스는 재생하는 로그 중 하나가 손상되면 재생이 수행되지 않을 수도 있는 위험이 있습니다. 이 경우 재생을 수행하면 오류가 발생하고 이후 재생 작업이 모두 차단됩니다. 이러한 상황이 발생하면 저장소 그룹 복사가 Failed라는 오류 상태로 됩니다. 이러한 오류 상태에서 해당 시점까지의 데이터베이스 버전을 사용하여 복구할 수 있습니다. 그렇지 않으면 원본 서버를 사용할 수 있고 손상되지 않은 로그가 다시 복사될 때까지 기다려야 합니다.
저장소 그룹 복사본에 대한 복제 중단 및 다시 시작
경우에 따라서는 수동 복사본 작업을 제어해야 합니다. 복제 작업을 중단 및 다시 시작해야 하는 경우도 있습니다. 복제는 저장소 그룹 수준에서 제어됩니다. 저장소 그룹에는 하나의 데이터베이스만 포함될 수 있기 때문에 복제는 한 데이터베이스에 대해서 지역화됩니다.
복제는 클러스터의 두 노드가 모두 작동 중이고, 대상 노드에서 Microsoft Exchange Replication Service가 실행 중이고, 저장소 그룹 복사본에서 복사 기능을 사용하도록 설정되어 있는 경우에 발생합니다. CCR의 소스 또는 대상 위치를 사용할 수 없는 경우 복제를 중지해야 합니다. 또한 시드, 무결성 검사 수행 또는 저장소 다시 구성과 같은 일부 CCR 관리 작업의 경우 저장소 그룹 복사본의 복제 작업을 중단해야 합니다. 대상 로그 파일 및 로그 디렉터리에 대한 모든 액세스를 중지해야 하는 경우 복제를 중단해야 합니다.
Exchange 2007의 경우 저장소 그룹 또는 데이터베이스의 위치를 변경하는 경우 모든 복제 작업을 중단해야 합니다.
데이터베이스 복사본 업데이트 중단에 대한 자세한 내용은 클러스터 연속 복제 복사본에서 복제를 중단하는 방법을 참조하십시오. 데이터베이스 복사본 업데이트 다시 시작에 대한 자세한 내용은 클러스터 연속 복제 복사본에서 복제를 다시 시작하는 방법을 참조하십시오.
CCR 트랜잭션 로그 및 데이터베이스 파일에서 무결성 검사를 수행하는 방법에 대한 자세한 내용은 Eseutil을 사용하여 클러스터 연속 복제 복사본을 확인하는 방법을 참조하십시오.
복제를 위한 하나 이상의 중복 네트워크 구성
Exchange 2007 SP1에서는 CCR 환경에서 로그 전달 및 시드 작업에 사용할 수 있는 중복 클러스터 네트워크를 구성할 수 있습니다. 중복 네트워크는 혼합 클러스터 네트워크로 구성해야 합니다. 혼합 클러스터 네트워크란 클러스터(하트비트)와 클러스터 액세스 트래픽 양쪽에 대해 구성된 클러스터 네트워크입니다.
연속 복제 호스트 이름 및 IP 주소로 혼합 클러스터 네트워크가 구성되면 Exchange 2007에서 로그 전달에 해당 네트워크를 사용합니다. 또한 구성된 해당 네트워크는 관리자가 Update-StorageGroupCopy cmdlet를 사용하여 시작한 시드에도 사용할 수 있습니다. 여러 혼합 네트워크를 지정할 수 있으며 둘 이상의 네트워크를 사용할 수 있을 경우 Exchange 2007에서는 네트워크 중 하나를 임의로 선택합니다. 현재 사용하고 있는 네트워크를 사용할 수 없게 되면 Exchange 2007에서는 사용 가능한 다른 네트워크를 자동으로 선택합니다.
혼합 네트워크를 통한 로그 전달 지원은 Enable-ContinuousReplicationHostName cmdlet를 사용하여 구성됩니다. 마찬가지로 이 기능은 Disable-ContinuousReplicationHostName cmdlet를 사용하여 해제됩니다. 클러스터된 사서함 서버가 CCR 환경에 있을 경우, 관리자는 Enable-ContinuousReplicationHostName을 클러스터의 두 노드에서 실행하고 두 개의 IP 주소와 호스트 이름을 지정할 수 있습니다. 이 작업이 수행된 이후, 구성이 완료되고 혼합 네트워크가 작동되는지 확인되면 시스템은 로그 복사를 위한 혼합 네트워크를 무작위로 선택합니다.
Update-StorageGroupCopy cmdlet를 사용하여 CCR 환경에서 시드 및 다시 시드 작업을 수행합니다. 이 cmdlet는 Microsoft Exchange 2007 SP 1(서비스 팩 1)에서 이제 DataHostNames라는 새 매개 변수도 포함하도록 확장되었습니다. 이 매개 변수는 시드 또는 다시 시드 작업에 사용할 네트워크를 지정하는 데에 사용됩니다. 값은 FQDN(정규화된 도메인 이름)이나 호스트 이름, 이 두 개의 이름으로 구성된 다중값 목록입니다. 이 이름 중 하나는 수동 노드를 식별해야 합니다.
로그 전달 및 시드 작업을 위한 중복 네트워크 구성에 대한 자세한 내용은 다음 항목을 참조하십시오.
Windows Server 2008 CCR:
Windows Server 2003 CCR:
클러스터된 사서함 서버에서 저장소 그룹 및 데이터베이스 관련 작업
CCR 환경에 있는 클러스터된 사서함 서버의 저장소 그룹 및 데이터베이스와 관련된 관리 작업은 다음과 같습니다.
저장소 그룹 파일 또는 데이터베이스의 위치 이동
저장소 그룹 복사본의 상태 보기
데이터베이스 탑재 및 분리
저장소 그룹 복사본의 무결성 확인
프로덕션 저장소 그룹 또는 저장소 그룹 복사본의 손상 복구
오류 또는 일부 유형의 데이터 손상이 발생한 후 CCR 복구
특별한 유형의 저장소 그룹인 복구 저장소 그룹을 제외하고 CCR 환경에서 모든 저장소 그룹 및 데이터베이스는 자동으로 연속 복제를 사용하도록 설정됩니다. 복제 및 재생을 일시 중지할 수 있지만 CCR 환경에서 하나 이상의 저장소 그룹에 대한 연속 복제 비활성화는 특정 데이터베이스에 액세스하지 못하도록 연속 복제가 중단될 수 있기 때문에 수행할 수 없습니다.
CCR 환경에서 새 저장소 그룹을 만드는 경우 수동 노드의 데이터베이스 복사본 시드 작업이 자동으로 수행되어야 합니다. 어떤 이유로 시드 작업이 자동으로 이루어지지 않으면 데이터베이스 복사본을 수동으로 시드해야 합니다. 데이터베이스 복사본을 시드하는 방법에 대한 자세한 단계는 클러스터 연속 복제 복사본을 시드하는 방법을 참조하십시오.
저장소 그룹 파일 또는 데이터베이스의 위치 이동
CCR 환경에서 저장소 그룹 파일의 위치나 데이터베이스의 위치를 이동해야 하는 경우가 있습니다. 파일 위치를 이동하는 데 걸린 시간은 이동되는 데이터베이스의 크기, 이동되는 트랜잭션 로그 파일의 수 및 저장소의 성능 특성에 따라 다릅니다. 이동 중에는 데이터베이스가 분리됩니다.
CCR 환경에서 저장소 그룹을 다시 배치하려면 활성 노드와 수동 노드의 파일 위치가 모두 동일해야 하므로 두 복사본을 일관된 방식으로 다시 배치해야 합니다. 저장소 그룹 또는 데이터베이스를 이동할 수 있기 때문에 데이터베이스를 분리하고 복제를 일시 중지해야 합니다. 활성 복사본의 경우 Exchange 관리 셸에서 Dismount-Database cmdlet를 사용하여 이를 수행할 수 있습니다. Microsoft Exchange Replication Service의 경우 Suspend-StorageGroupCopy cmdlet 및 Resume-StorageGroupCopy cmdlet를 사용합니다.
참고
Microsoft Exchange Replication Service는 복사본 위치 및 활성 노드의 로그 모두에서 파일을 지속적으로 모니터링합니다. 따라서 어떤 방식으로든 활성 로그를 조작하면 Suspend-StorageGroupCopy cmdlet를 통해 복제를 중단하여 해당 저장소 그룹의 활동을 일시 중지해야 합니다.
CCR 환경에서 저장소 그룹 파일 위치를 이동하는 방법에 대한 자세한 단계는 CCR 환경에서 저장소 그룹을 이동하는 방법을 참조하십시오. CCR 환경에서 데이터베이스 위치를 이동하는 방법에 대한 자세한 단계는 CCR 환경에서 데이터베이스를 이동하는 방법을 참조하십시오.
저장소 그룹 복사본의 상태 보기
RTM(Release To Manufacturing) 버전의 Microsoft Exchange 2007에서는 Exchange 관리 셸을 사용하여 CCR 상태 정보만 볼 수 있습니다. Exchange 2007 SP1에서 다음 표에 나열된 일부 상태 정보를 Exchange 관리 콘솔에서 볼 수 있습니다.
Exchange 2007에서는 저장소 그룹 복사본에 대한 다양한 상태 정보를 게시합니다. 다음 표에서는 사용 가능한 상태 정보에 대해 설명합니다. 다음 표에서 특성은 Get-StorageGroupCopyStatus cmdlet의 전체 출력에 표시되는 순서대로 나열되어 있습니다. 상태 정보 보기에 대한 자세한 단계는 Exchange 관리 셸을 사용하여 클러스터 연속 복제 복사본 상태를 표시하는 방법을 참조하십시오.
CCR 사용 가능 저장소 그룹에 사용될 수 있는 상태 정보
| 특성 | 설명 |
|---|---|
Identity |
쿼리된 저장소 그룹의 ID입니다. 이 특성은 <ServerName>\<StorageGroupName>을 제공합니다. |
StorageGroupName |
쿼리된 저장소 그룹의 이름입니다. 이 특성은 저장소 그룹 이름을 제공합니다. |
SummaryCopyStatus |
수동 복사본의 전체적인 현재 상태입니다. 가능한 값은 다음과 같습니다.
Exchange 2007 SP1은 다음 추가 상태 값을 추가합니다.
|
Failed |
복제하지 못하도록 하는 불일치를 식별한 데이터베이스 또는 로그가 확인되었습니다. 또는 활성 또는 수동 복사본에 구성 또는 액세스 문제가 있습니다. 가능한 값은 True와 False입니다. |
FailedMessage |
복제가 실패된 조건을 식별하는 텍스트 메시지입니다. 복제 문제 영역에만 한정되는 것이 아닐 수 있습니다. |
Seeding |
시드가 진행 중임을 표시합니다. 가능한 값은 True와 False입니다. |
Suspend |
수동 복사본에 대한 복제가 중단되었음을 표시합니다. 이 상태에서는 데이터베이스 작업 및 로그 복사를 수행할 수 없습니다. 가능한 값은 True와 False입니다. |
SuspendComment |
관리자가 복제 활동 중단 원인 또는 그에 대한 참고를 제공할 수 있는 선택적 설명 영역입니다. |
CopySuspend |
수동 복사본에 대한 로그 복사가 중단되었음을 표시합니다. 이 상태에서는 로그 복사 디렉터리를 변경할 수 없습니다. 가능한 값은 True와 False입니다. |
CopySuspendComment |
로그 복사 작업의 중단 원인 또는 그에 대한 참고를 제공하는 선택적 관리자 설명입니다. |
CopyQueueLength |
수동 복사본 로그 파일 폴더에 복사하려고 대기 중인 트랜잭션 로그 파일 수입니다. 손상이 없는지 검사를 거치기 전까지는 복사가 완료된 것으로 간주되지 않습니다. |
ReplayQueueLength |
수동 복사본에 재생하려고 대기 중인 트랜잭션 로그 파일의 수입니다. |
LatestAvailableLogTime |
가장 최근에 검색된 새 트랜잭션 로그 파일의 원본 저장소 그룹에 있는 타임 스탬프입니다. |
LastCopyNotificationedLogTime |
활성 저장소 그룹에서 생성하고 복사본에서 알고 있는 최신의 새 로그와 연결된 시간입니다. |
LastCopiedLogTime |
최근 트랜잭션 로그 파일 복사의 원본 저장소 그룹에 있는 타임 스탬프입니다. |
LastInspectedLogTime |
최근 트랜잭션 로그 파일 검사의 대상 저장소 그룹에 있는 타임 스탬프입니다. |
LastReplayedLogTime |
최근 트랜잭션 로그 파일 검사의 대상 저장소 그룹에 있는 타임 스탬프입니다. |
LastLogGenerated |
저장소 그룹의 활성 복사본에 생성될 것으로 알려진 마지막 로그 생성 번호입니다. |
LastLogCopied |
수동 복사본 로그 폴더에 복사된 마지막 로그 생성 번호입니다. |
LastLogNotified |
활성 저장소 그룹에서 생성되었고, 복사본으로 알려진 마지막 로그 생성 번호입니다. |
LastLogInspected |
일관성 및 손상에 대해 검사한 마지막 로그 생성 번호입니다. |
LastLogReplayed |
데이터베이스의 수동 복사본에 재생된 마지막 로그 생성 번호입니다. |
LatestFullBackupTime |
마지막 전체 백업 시간입니다. |
LastestIncrementalBackupTime |
마지막 증분 백업 시간입니다. |
SnapshotBackup |
마지막으로 수행한 전체 백업이 레거시 스트리밍 백업인지 또는 VSS(볼륨 섀도 복사본 서비스) 백업 스냅숏인지를 나타냅니다. |
SnapshotLatestFullBackup |
마지막 스냅숏 전체 백업 시간입니다. |
SnapshotLatestIncrementalBackup |
마지막 스냅숏 증분 백업 시간입니다. |
SnapshotLatestDifferentialBackup |
마지막 스냅숏 차등 백업 시간입니다. |
SnapshotLatestCopyBackup |
마지막 스냅숏 복사본 백업 시간입니다. |
OutstandingDumpsterRequests |
해결되지 않은 요청 및 해결되지 않은 요청의 시간 범위(낮음–높음)입니다. |
DumpsterStatistics |
액세스할 수 있는 모든 허브 전송 서버의 전송 쓰레기 수거통 통계입니다. 이 값은 Get-StorageGroupCopyStatus 명령에서 DumpsterStatistics 매개 변수를 사용하는 경우에만 표시됩니다. |
DumpsterStatisticsNotAvailable |
액세스할 수 없는 허브 전송 서버의 목록입니다. |
SummaryCopyStatus, CopyQueueLength, ReplayQueueLength 및 LastInspectedLogTime 값을 보면 저장소 그룹 복사본의 상태를 신속하게 평가할 수 있습니다. 이러한 특성은 저장소 그룹 복사본이 제대로 작동하는지와 저장소 그룹 복사본이 복사 및 재생 로그 모두에서 비교적 최신 상태인지 여부를 보여줍니다. 다음 조건이 발생하면 문제의 원인을 판단하고 해결해야 합니다.
복사본 상태가 정상이 아닙니다.
복사본 큐 길이가 5보다 큽니다.
재생 큐 길이가 20보다 큽니다.
마지막으로 검사한 로그 시간이 최근 시간이 아닙니다. 저장소 그룹의 비활성으로 인해 이 상황이 발생될 수 있지만 Microsoft Exchange Replication Service가 중지되었을 수도 있습니다.
두 큐 번호는 다음과 같이 시간 단위로 계산할 수 있습니다.
복사 큐 시간 = LatestAvailableLogTime – LastCopiedLogTime
재생 큐 시간 = LatestCopiedLogTime – LastInspectedLogTime
재생 큐 길이 및 복사본 큐 길이 값을 성능 카운터로 사용할 수 있습니다. 이것은 Microsoft Exchange Replication Service 성능 개체 아래의 CopyQueueLength 및 ReplayQueueLength 성능 카운터입니다.
드물지만 복제 상태를 잘못 이해할 가능성이 있는 몇몇 시나리오가 있습니다. 다음은 그러한 시나리오의 목록입니다.
활성 상태가 아닌 저장소 그룹, 즉 변경되지 않는 저장소 그룹은 정상 상태가 아닌 경우에도 정상인 것으로 보고될 수 있습니다. 이러한 상황은 로그를 재생하기 전에는 비정상 상태를 탐지할 수 없기 때문에 발생합니다.
복제 초기화 중에는 복제 상태가 평가되므로 정확하지 않을 수 있습니다. 초기화가 완료되면 상태는 업데이트됩니다.
데이터베이스를 분리할 때 LastLogGenerated 필드의 값이 잘못될 수 있습니다. 그러나 저장소 그룹 복사본을 복제하는 경우 최종 사용자 콘텐츠가 포함된 모든 로그가 복제됩니다.
로그 스트림 도중에 하나 이상의 로그가 누락된 경우 수동 복사본이 계속해서 복구를 시도합니다. 이 과정에서 복제 상태가 실패와 정상 상태 간에 전환됩니다. 재생 및 복사 큐의 크기는 계속 증가합니다.
매우 드물지만 로그를 확인한 경우에도 재생할 수 없는 경우가 있습니다. 이러한 경우 시스템에서는 복구를 시도하면서 실패와 정상 상태가 번갈아 일어납니다. 재생 및 복사 큐의 크기는 계속 증가합니다.
참고
Exchange 2007 SP1에서는 Test-ReplicationHealth라는 새 cmdlet를 사용하여 연속 복제에 사용하도록 설정할 수 있는 저장소 그룹의 상태를 확인할 수도 있습니다. Test-ReplicationHealth cmdlet에 대한 자세한 내용은 Test-ReplicationHealth를 참조하십시오.
데이터베이스 탑재 및 분리
CCR 환경에서 데이터베이스를 탑재하거나 분리해야 하는 경우도 있습니다. 이러한 예로는 구성을 다시 수행할 경우나 서버나 데이터베이스 문제를 해결하는 경우를 들 수 있습니다. 데이터베이스를 분리하면 추가 변경을 수행할 수 없습니다. 데이터베이스가 분리된 동안에는 데이터베이스나 로그 파일이 변경되지 않습니다.
CCR 환경에서 데이터베이스를 탑재하는 방법에 대한 자세한 내용은 클러스터 연속 복제 환경에 데이터베이스를 탑재하는 방법을 참조하십시오. CCR 환경에서 데이터베이스를 분리하는 방법에 대한 자세한 내용은 클러스터 연속 복제 환경에서 데이터베이스를 분리하는 방법을 참조하십시오.
저장소 그룹 복사본의 무결성 확인
CCR을 사용하는 경우 데이터베이스 및 트랜잭션 로그 파일에 대해 실제 일관성 검사를 실행하여 정기적으로 수동 복사본의 무결성을 확인하는 것이 좋습니다. 실제 일관성 검사는 트랜잭션 로그와 데이터베이스 파일의 손상을 검사합니다. Exchange Server 데이터베이스 유틸리티(Eseutil.exe)를 사용하여 검사를 수행할 수 있습니다. Eseutil을 사용하여 실제 손상이 있는지 트랜잭션 로그 및 데이터베이스 파일을 검사하는 방법에 대한 자세한 내용은 Eseutil을 사용하여 클러스터 연속 복제 복사본을 확인하는 방법을 참조하십시오.
참고
데이터베이스에 실제 일관성 검사를 실행하기 전에 저장소 그룹 복사본에 대한 복제 작업을 일시 중단해야 합니다. Exchange 관리 셸의 Suspend-StorageGroupCopy cmdlet를 사용하여 트랜잭션 로그 재생 작업을 일시 중단할 수 있습니다. 일관성 확인을 완료하면 Resume-StorageGroupCopy cmdlet를 사용하여 트랜잭션 로그 재생 작업을 다시 시작할 수 있습니다.
CCR 환경의 손상 복구
CCR을 사용하면 예약된 중단을 시작하여 프로덕션 저장소 그룹의 손상이나 오류를 복구할 수 있습니다. 로그 파일이 손상되지 않은 경우에는 복구로 인한 데이터 손실이 발생하지 않습니다. 하지만 로그 파일을 사용할 수 없는 경우에는 복사본에 반영된 손상되지 않은 마지막 변경 내용과 일치하는 특정 시점으로만 저장소 그룹을 복구할 수 있습니다. 또한 해당 시점보다 이전에 손실되거나 손상된 변경 데이터가 있을 수 없다는 제약 조건이 따릅니다.
CCR 환경에서 손상이나 오류를 복구하는 방법에 대한 자세한 단계는 다음 항목을 참조하십시오.
실패 또는 손상이 발생된 후 CCR 복구
CCR은 실패 후 자동으로 복구하는 기능을 제공합니다. 그러나 수동 복구가 필요한 경우도 있습니다. 이러한 경우는 다음과 같습니다.
데이터베이스 파일이 수동 복사본에서 손상되었습니다. 데이터베이스가 손상된 후 CCR을 복원하는 방법에 대한 자세한 단계는 데이터베이스 손상 발생 후 복원하는 방법을 참조하십시오.
수동 복사본에서 데이터베이스 또는 로그 볼륨에 오류가 발생했습니다. 볼륨 오류가 발생한 후 CCR을 복원하는 방법에 대한 자세한 단계는 볼륨 오류 후 복원하는 방법을 참조하십시오.
데이터베이스에 오류가 발생했거나 현저하게 차이가 납니다. 오류로 인해 데이터베이스에 현저한 차이가 나는 경우 CCR이 검색하여 보고합니다. 일반적으로 이러한 오류는 데이터베이스 복사본을 사용할 수 있고 실패된 데이터베이스 복사본에 허용된 자동 탑재 기준보다 많은 변경 내용이 있는 경우 발생합니다. 데이터베이스 실패 또는 차이 발생 후 CCR 복구 방법에 대한 자세한 단계는 오류 또는 차이가 발생한 후 CCR 기능을 복원하는 방법을 참조하십시오.