예약된 중단 및 예약되지 않은 중단

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

마지막으로 수정된 항목: 2007-10-29

예약된 중단과 예약되지 않은 중단은 CCR(클러스터 연속 복제) 환경의 두 가지 중단 유형입니다. 예약된 중단은 관리자가 오류를 복구하거나 유지 관리 작업을 수행하기 위해 명시적으로 시작합니다. 예약되지 않은 중단은 서비스나 데이터 또는 이 두 가지 모두 사용할 수 없게 되는 예기치 않은 이벤트를 말합니다. CCR은 예약된 중단과 예약되지 않은 중단 모두를 처리하도록 만들어졌습니다.

예약된 중단

CCR을 사용하면 CMS(클러스터된 사서함 서버)를 장기간 중단하지 않고도 특정 노드의 장기간 시스템 중단을 예약할 수 있습니다. CCR의 예약된 중단 기능은 활성 노드에 있는 모든 로그 데이터를 수동 노드에 복사하도록 만들어졌습니다. 따라서 복제가 비동기적으로 발생해도 예약된 중단 시에 항상 데이터 손실이 없습니다. 오류가 발생하고 이로 인한 장애 조치가 수행되면 수동 노드는 온라인 상태가 되는 시점에서 극히 최근의 로그 데이터는 사용할 수 없는 경우가 있습니다.

CCR 환경에서는 한 번에 하나의 노드만 오프라인 상태로 만들 수 있습니다. 두 개 이상의 노드를 오프라인 상태로 만들면 서비스가 중단됩니다. 어떤 특정 시간에 파일 공유 감시 기능을 갖는 MNS(과반수 노드 집합) 쿼럼에 대한 파일 공유를 호스팅하는 컴퓨터 또는 장애 조치(failover) 클러스터의 수동 노드는 하드웨어 및 소프트웨어 유지 관리, 업데이트 및 복구를 위하여 오프라인 상태로 만들 수 있습니다. 먼저 활성 노드인지 또는 리소스를 호스팅하는지를 확인하기 전에는 절대 노드를 오프라인 상태로 만들지 않도록 해야 합니다. 클러스터 관리자를 사용하여 리소스를 호스팅하는지 확인할 수 있습니다. Exchange 관리 셸의 Get-ClusteredMailboxServerStatus cmdlet를 실행하면 노드 상태를 확인할 수 있습니다. CMS 상태를 보는 방법에 대한 자세한 내용은 클러스터된 사서함 서버의 상태를 보는 방법을 참조하십시오.

관리 작업

예약된 중단은 관리자가 오류를 복구하거나 유지 관리 작업을 수행하기 위해 명시적으로 시작합니다. 예약된 중단을 통해 시스템에서 CMS를 활성 노드에서 수동 노드로 이동할 수 있어 수동 노드를 새로운 활성 노드로 만들 수 있고, 복제된 데이터베이스와 저장소 그룹을 탑재할 수 있습니다. 탑재 후 데이터베이스는 이후 복제에 대한 모든 후속 업데이트의 원본이 됩니다. 두 복사본은 데이터베이스 변경 내용을 생성하거나 데이터베이스 변경 내용을 받아 적용하는 복제 역할을 전환합니다.

CCR에서는 비동기 복제를 사용하기 때문에 클러스터의 한 노드에서 다른 노드로 활성 CMS를 변환하려면 클러스터와 복제 지원 간의 조정이 필요합니다. CCR에서는 이러한 조정을 구현합니다. 관리자는 Exchange 명령 셸의 Move-ClusteredMailboxServer cmdlet를 사용하여 예약된 중단을 시작합니다.

Move-ClusteredMailboxServer cmdlet에서는 수동 노드에 유효하고 정상적인 복사본이 있는지 확인합니다. 또한 복사본이 비교적 최신 버전인지 확인합니다. 복사본이 비교적 최신 버전이 아니면 복제가 완료되는 동안 중단이 연장될 수 있습니다. 이러한 확인이 이루어지면 전환이 시작됩니다. 이동하는 동안 오류가 없으면 선택한 노드에서 CMS가 실행 중인 경우 작업이 완료되고 모든 데이터베이스가 탑재됩니다. 이 과정이 진행되는 동안 오류가 발생하여 이 전환이 이루어지지 않거나 모든 데이터베이스가 자동으로 탑재되는지 여부에 영향을 줄 수 있습니다. 이러한 상황이 발생하면 예약되지 않은 중단 작업이 발생합니다.

부분적으로 오류가 발생한 서버를 복구하는 데 예약된 중단이 사용되는 경우도 있습니다. 손상된 데이터베이스나 로그 파일이 있는 서버를 예로 들 수 있습니다. 이 경우에는 복제 시스템에 로그를 보내는 논리에 의해 Move-ClusteredMailboxServer cmdlet가 차단됩니다. 관리자가 이 시나리오를 관리하는 방법은 간단합니다. 관리자는 문제가 되는 데이터베이스를 분리하고 분리된 데이터베이스에 연결된 로그를 복사하는 옵션과 함께 Move-ClusteredMailboxServer 명령을 실행하지만 일부 로그를 복사할 수 없는 경우 이동하는 데 실패하지 않습니다. 결과적으로 Move-ClusteredMailboxServer cmdlet를 사용하면 손상된 저장소 그룹의 복구까지도 쉽게 수행됩니다.

Move-ClusteredMailboxServer cmdlet를 사용하면 관리자가 이동을 시작하는 이유를 기록할 수 있습니다. 이 이유가 이벤트 로그에 배치됩니다. 또한 이 명령을 사용하면 관리자가 CMS를 호스팅할 노드를 지정할 수 있습니다. 따라서 관리자는 CMS가 이미 올바르게 호스팅된 경우 CMS를 잘못 이동하지 않게 됩니다.

Cluster.exe 명령줄 관리 인터페이스와 클러스터 관리자 GUI(그래픽 사용자 인터페이스)에 모두 클러스터된 CMS를 이동할 수 있는 기능이 포함되어 있습니다. 이 방법을 사용하면 복제 플러시 논리가 트리거됩니다. 그러나 다음과 같은 이유 때문에 이 방법을 사용하지 않는 것이 좋습니다.

• 이 방법은 수동 복사본의 상태를 확인하지 않습니다. 따라서 이 방법을 사용하면 노드에서 필요한 작업을 수행하여 데이터베이스를 탑재 가능하게 만들지만 중단 기간이 길어질 수 있습니다.

• 또한 이 방법을 사용하면 복제가 분리된 상태이기 때문에 데이터베이스가 무한정 오프라인 상태일 수 있습니다.

예약된 중단 후 복제 작업 복원

활성 노드의 예약된 중단 후 CCR 환경을 복원하는 프로세스는 노드를 다시 시작하는 것입니다. 시스템 시작 시 복제 작업이 자동으로 시작됩니다. 다음 두 가지 경우를 고려해야 합니다.

• 예약된 중단이 완료되어 예약된 중단에 연결된 변환이 이루어지는 동안 오류가 없었으며 모든 데이터베이스가 자동으로 온라인 상태가 되었습니다. 이 경우 관리자는 두 노드의 저장소 그룹과 데이터베이스가 일치하도록 예약된 중단을 수행합니다. 따라서 노드가 즉시 복제를 계속할 수 있습니다. 로그를 재생하여 복사본을 현재 상태로 가져올 수 있으며 특별한 조치를 취할 필요가 없습니다.

• 예약된 중단이 부분적으로만 완료되거나 예약된 중단 이전에 일부 데이터베이스가 손상되었습니다. 이 경우 예약된 중단은 데이터베이스 탑재 전에 대상에서 원본의 모든 로그를 사용할 수 있는 상태였는지 확인할 수 없습니다. 일반적으로 이러한 상황은 예약된 중단 이전, 또는 예약된 중단 작업 후반부의 오류로 인해 발생합니다. 따라서 원본 데이터베이스와 대상 데이터베이스가 일치하지 않습니다. 경우에 따라 CCR이 일부 불일치 상태를 자동으로 복구할 수 있습니다. 이러한 경우 복제가 시작되고 사용 가능한 로그가 처리됩니다. 복제에서 자동으로 복구할 수 없으면 복사본이 분리된 것으로 표시되고 문제를 나타내는 이벤트가 생성됩니다. 저장소가 실행 가능한 경우 1차적인 복구 작업은 복사본을 다시 시드하는 것입니다. 이 문제를 해결하는 절차에 대한 자세한 내용은 클러스터 연속 복제 복사본을 시드하는 방법을 참조하십시오.

예약되지 않은 중단

예약되지 않은 중단은 일부 오류 종류에 대한 자동 시스템 응답으로 발생합니다. CCR은 가용성이 향상되고 대부분의 환경에서 자동 복구를 원하는 높은 수준의 신뢰가 있는 경우 오류에 대해 자동 복구에 중점을 둡니다.

예약되지 않은 중단을 사용하면 시스템에서 수동 노드의 사서함 서버를 활성화할 수 있으므로 해당 서버가 활성 상태가 되며, 복제된 데이터베이스와 저장소 그룹을 탑재할 수 있습니다. 탑재 후 데이터베이스는 이후 복제에 대한 모든 후속 업데이트의 원본이 됩니다. 두 복사본은 데이터베이스 변경 내용을 생성하거나 데이터베이스 변경 내용을 받아 적용하는 복제 역할을 전환합니다.

CCR에서는 비동기 복제를 사용하므로 예약되지 않은 중단은 일부 데이터 손실이 발생할 것임을 의미합니다. 최소한 활성 서버에 의해 작성되고 있는 로그는 복구 작업에 사용할 수 없습니다. CCR에서는 장애 조치(failover) 작업의 관리 제어를 제공하고 영향을 받는 대량의 데이터를 다시 확보할 수 있는 기능을 제공하여 이 문제를 해결합니다.

장애 조치가 발생할 경우 CCR에서는 항상 나머지 수동 노드의 사서함 서버를 활성화합니다. 시스템 제어는 데이터베이스가 이 활성 노드에 탑재되었는지 여부에 연결됩니다. CCR에서는 관리 제어를 제공하여 데이터베이스가 탑재되었는지 여부를 나타냅니다. 기본 위치는 Best availability입니다. 이 위치에서 시스템은 이전의 활성 프로덕션 데이터베이스와 동기화된 모든 데이터베이스를 자동으로 탑재합니다. Best availability를 사용하면 두 복사본 간에 더 다양한 불일치가 허용됩니다. Good availability는 새로운 로그를 생성하는 동안 마지막으로 생성된 로그가 복제된 경우 데이터베이스를 온라인으로 가져옵니다. Lossless를 사용하면 데이터 손실이 없을 것임을 확인할 수 없는 경우 복사본을 온라인으로 가져오지 않습니다. Lossless를 사용하면 원래 서버가 다시 작동되고 모든 로그 데이터를 사용할 수 있으며 손상되지 않은 경우에만 자동 복구가 발생합니다.

데이터베이스가 자동으로 탑재되지 않는 설정 상태에 있는 데이터베이스가 하나 이상 있을 경우 관리자는 사용 가능한 콘텐츠가 있으면 복사본을 탑재하도록 명시적으로 결정할 수 있습니다. 관리자는 복사본의 상태를 확인한 다음 두 가지 명령을 실행해야 합니다. 첫 번째 명령에서는 복제 엔진에게 이 복사본이 복제 원본(변경 원본)이 되어야 한다는 사실, 즉 복사본을 탑재해야 한다고 알립니다. 두 번째 명령에서는 데이터베이스를 탑재합니다.

CCR을 사용할 수 있는 경우 손상 또는 오류의 복구에 대한 자세한 내용은 클러스터 연속 복제 관리를 참조하십시오.

관리 제어 기능

예약되지 않은 중단 시 작업 제어를 위해 관리 제어가 제공됩니다. CCR에서는 예약되지 않은 중단 복구 작업을 제어하는 데 사용할 수 있는 사서함 서버의 특성을 제공합니다. AutoDatabaseMountDial 특성은 세 가지 값 즉, Lossless, Good availability 그리고 Best availability를 가질 수 있습니다.

• Lossless   Lossless는 손실한 로그가 없습니다. 특성을 Lossless로 설정하면 대부분의 환경에서 시스템은 데이터베이스가 탑재되기 전에 오류가 있는 노드가 다시 온라인 상태가 될 때까지 기다립니다. 그러면 오류가 있는 시스템에서 액세스 가능하고 손상되지 않은 모든 로그를 반환해야 합니다. 오류가 발생한 후 수동 노드는 활성 상태가 되고 Microsoft Exchange Information Store 서비스는 온라인 상태가 됩니다. 이 옵션을 사용하면 데이터 손실 없이 데이터베이스를 탑재할 수 있는지 확인할 수 있습니다. 확인 결과 가능하면 데이터베이스가 탑재됩니다. 그렇지 않으면 시스템에서 주기적으로 로그를 복사하려고 시도합니다. 서버에서 로그를 그대로 반환하는 경우 이러한 시도가 수행되며 데이터베이스가 탑재됩니다. 서버에서 로그를 그대로 반환하지 않는 경우 나머지 로그를 사용할 수 없으며 영향을 받는 데이터베이스는 탑재되지 않습니다.

  참고

  장애 조치가 완료된 후 언제든지 관리자는 이전의 수동 노드에서 사용할 수 있는 데이터베이스와 로그를 사용하여 탑재할지 결정하고 조정할 수 있습니다. 이 작업은 두 가지 간단한 단계를 사용하여 수행됩니다. 주로 관리자는 원래 서버가 작동하는 데 필요한 시간을 분석한 결과를 기반으로 조정을 결정합니다. 오류가 발생할 경우 두 노드 간 복제 일관성과 서버에 대한 액세스 권한을 얻는 클라이언트의 긴급성이 이 분석의 부분적인 요소입니다.

• Good availability   Good availability는 손실한 로그가 세 개입니다. Good availability를 사용하면 복제가 정상적으로 작동하고 생성되는 속도로 로그를 복제하는 경우 완전한 자동 복구가 가능합니다.

• Best availability   Best availability는 손실한 로그가 여섯 개이고 이것이 기본 설정입니다. Best availability는 Good availability와 비슷하게 작동하지만 복제가 조금 더 지연되는 경우 자동 복구가 허용됩니다. 따라서 장애 조치(failover) 후 새 활성 노드가 이전 활성 노드의 상태보다 약간 더 이전일 수 있으므로 데이터베이스 확산이 발생할 가능성이 높아지고 이를 해결하려면 전체 다시 시드가 필요합니다.

중단 관리 작업에 대한 자세한 내용은 클러스터 연속 복제의 장애 조치 및 탑재 설정을 조정하는 방법을 참조하십시오.