다음을 통해 공유

대기 연속 복제: 대기 클러스터링으로 사이트 복구

  • 아티클

 

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

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

이 항목에서는 Contoso, Ltd. 조직에서 사이트 복구 시나리오에 SCR(대기 연속 복제)을 사용하는 방법을 설명합니다. 이 시나리오에서는 기본 데이터 센터에 오류가 발생하여 Contoso, Ltd.는 보조 데이터 센터를 활성화할 것을 결정합니다. 보조 데이터 센터가 활성화된 후 제어가 전환된 상태에서 기본 데이터 센터는 다시 구성되고 결국 기본 데이터 센터로 복원됩니다. Contoso, Ltd.에는 Active Directory SITEA라는 기본 데이터 센터와 Active Directory SITEB라는 백업용 보조 데이터 센터가 있습니다. SITEA는 Oregon 주의 Portland에 있으며 SITEB는 California 주의 San Jose에 있습니다.

SITEA에는 다음과 같은 인프라 구성 요소가 포함되어 있습니다.

  • 안전한 Active Directory통합형 DNS(Domain Name System) 서비스가 제공되는 디렉터리 서버 DC1

  • 클라이언트 액세스 서버 CAS1

  • 허브 전송 서버 HUB1

  • NODEA 및 NODEB가 포함되어 있는 2개 노드 SCC(단일 복사본 클러스터)인 EXCLUS1에서 실행되고 있는 클러스터된 사서함 서버인 EXCMS1 다음 사항에 유의하십시오.

    • 장애 조치(failover) 클러스터의 노드는 Windows Server 2008 운영 체제를 실행하고 있으며 장애 조치(failover) 클러스터는 노드 및 디스크 과반수 쿼럼을 사용할 수 있도록 구성됩니다.

    • 클러스터된 사서함 서버의 네트워크 이름 리소스에 대한 DNS TTL(Time to Live) 값은 5분으로 구성됩니다. 이 값은 다음 명령을 실행한 다음 구성하고 클러스터된 사서함 서버를 중지한 후 다시 시작합니다.

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300

      참고

      HostRecordTTL 속성은 Windows Server 2008이 실행되는 장애 조치(failover) 클러스터에서만 사용할 수 있으며 Windows Server 2003 운영 체제에서 실행되는 장애 조치 클러스터(failover)에서는 이 명령을 사용할 수 없습니다.

SITEB에는 다음과 같은 인프라 구성 요소가 포함되어 있습니다.

  • 안전한 Active Directory 통합형 DNS 서비스가 제공되는 디렉터리 서버 DC2

  • 클라이언트 액세스 서버 CAS2

  • 허브 전송 서버 HUB2

  • 대기 장애 조치(failover) 클러스터로 사용할 단일 노드 클러스터 DRCLUS1 다음 사항에 유의하십시오.

    • 이 클러스터의 노드인 NODEC은 대기 장애 조치(failover) 클러스터의 유일한 노드로 Windows Server 2008을 실행됩니다. 대기 장애 조치(failover) 클러스터는 노드 과반수 쿼럼을 사용할 수 있도록 구성됩니다.

      참고

      Windows Server 2003을 실행하는 장애 조치(failover) 클러스터의 경우에는 단일 노드 대기 장애 조치(failover) 클러스터가 로컬 쿼럼으로 구성됩니다.

    • 수동 사서함 서버 역할은 EXCLUS1과 같은 설치 경로를 사용해 NODEC에 설치됩니다. 이는 SCR 대상 활성화 프로세스의 일환으로 Setup /RecoverCMS를 사용해 서버 복구를 수행하는 데 필요합니다. 서버 복구 프로세스를 사용하려면 SCR 원본 컴퓨터와 SCR 대상 컴퓨터에서 Exchange Server의 설치 경로가 같아야 합니다. Exchange Server를 SCR 원본 컴퓨터의 %프로그램 파일%\Microsoft\Exchange Server에 설치하면 SCR 원본 서버에 대해 SCR 대상 컴퓨터로 사용할 모든 컴퓨터에서도 해당 서버를 %프로그램 파일%\Microsoft\Exchange Server에 설치해야 합니다. 이러한 설치 경로가 같지 않으면 레지스트리의 설치 경로가 Active Directory의 사서함 서버 개체의 msExchInstallPath 특성 값과 맞지 않아 서버 복구 프로세스가 실패합니다.

    • Active Directory 사용자 및 컴퓨터 스냅인을 사용하여 DRCLUS1의 컴퓨터 계정이 EXCMS1 컴퓨터 개체에 대한 모든 권한을 갖도록 구성합니다. 이렇게 하면 SITEA의 장애로 인해 SITEB를 활성화하는 경우에 EXCMS1의 컴퓨터 계정을 DRCLUS1에서 다시 설정할 수 있습니다.

      참고

      이 단계는 Windows Server 2008이 실행되는 장애 조치(failover) 클러스터에서만 사용됩니다. 클러스터 서비스가 로컬 시스템의 보안 컨텍스트에서 실행되기 때문입니다. 따라서 동일한 클러스터 서비스 계정이 두 장애 조치(failover) 클러스터에 사용되는 경우 Windows Server 2003이 실행되는 장애 조치 클러스터에서는 이 단계가 필요 없습니다.

양쪽 Active Directory 사이트의 모든 서버는 Active Directory 통합형 DNS 서버를 사용하도록 구성됩니다. 두 Active Directory 사이트의 Active Directory 복제 간격은 15분으로 구성됩니다.

트랜잭션 로그 파일이 EXCMS1의 3개 저장소 그룹에서 NODEC의 SCR 대상으로 복제되도록 SCR이 구성됩니다. 이 작업은 다음 명령을 사용하여 구성합니다.

Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC

참고

EXCMS1의 모든 저장소 그룹이 SCR에 사용되도록 한 번에 설정하려면 다음 명령을 실행합니다. Get-StorageGroup -Server EXCMS1 | Enable-StorageGroupCopy -StandbyMachine NODEC

각 저장소 그룹의 SCR 상태는 Exchange 관리 셸에서 Test-ReplicationHealth 및 Get-StorageGroupCopyStatus cmdlet를 사용하여 확인합니다. 예를 들면,

Get-StorageGroupCopyStatus EXCMS1\SG1 -StandbyMachine NODEC

클러스터된 사서함 서버의 이동 작업이 예상대로 수행되어 백업 및 로그 자르기 상태로 확인되었습니다.

기본 사이트 오류 및 백업 사이트 활성화

갑자기 아무런 경고 없이 Portland에 거대한 지진이 발생합니다. 많이 다친 사람은 없지만 전력, 수도 및 천연 가스 등의 주요 공공 시설의 연결을 끊어야 하는 SITEA에는 많은 피해가 발생했습니다. SITEA를 Contoso, Ltd.에서 다시 사용할 수 있게 하려면 수 개월이 걸리므로 SITEB를 수동으로 활성화하여 SITEA에서 제공한 서비스와 모든 메시징 데이터를 사용하도록 결정합니다.

SITEB의 활성화는 디렉터리 서비스의 유효성 확인 및 DNS 확인을 통해 시작됩니다. SITEB에도 Active Directory 통합형 DNS를 호스팅하는 디렉터리 서비스가 이미 있으므로 이러한 서비스는 정상적인 현재 상태로 SITEA의 중단에 크게 영향을 받지 않은 상태입니다. 디렉터리 서비스와 DNS를 모두 확인한 후에는 SCR 대상을 활성화하여 클러스터된 사서함 서버를 복구하는 작업을 시작합니다. 이 작업은 다음 단계를 차례로 수행하여 완료합니다.

  1. Exchange 관리 셸을 NODEC에서 열고 다음 명령을 실행하여 탑재할 SCR 대상을 준비합니다.

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Force

    중요

    SCR 원본을 사용할 수 없는 경우에는 SCR Force 매개 변수를 항상 지정해야 합니다.

    참고

    1단계에서와 같이 Restore-StorageGroupCopy 명령을 각각 세 번 실행하는 대신, 다음과 같이 Microsoft Exchange Server 2007 SP1(서비스 팩 1)에 포함된 새 스크립트인 GetSCRSources.ps1을 사용하여 한 번의 Restore-StorageGroupCopy 작업에 대한 스크립트 결과에 파이프라인을 수행할 수도 있습니다. GetSCRSources | Restore-StorageGroupCopy -StandbyMachine $env:ComputerName -Force

  2. DNS 관리 스냅인을 사용해 기존의 EXCMS1 DNS 레코드를 DNS에서 제거합니다.

    참고

    이 단계는 Windows Server 2008이 실행되는 장애 조치(failover) 클러스터에서만 사용됩니다. 클러스터 서비스가 로컬 시스템의 보안 컨텍스트에서 실행되기 때문입니다. 따라서 동일한 클러스터 서비스 계정이 두 장애 조치(failover) 클러스터에 사용되는 경우 Windows Server 2003이 실행되는 장애 조치 클러스터에서는 이 단계가 필요 없습니다.

  3. /RecoverCMS 프로세스를 준비하기 위해 SCR이 모든 저장소 그룹에 대해 사용되지 않도록 설정됩니다. SCR이 모든 저장소 그룹에 대해 사용되지 않도록 설정되지 않으면 Setup /RecoverCMS가 실패합니다. 다음 명령을 사용하여 SCR을 사용하지 않도록 설정할 수 있습니다.

    Disable-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Confirm:$False

  4. 클러스터된 사서함 서버(EXCMS1)는 설치 프로그램에 /RecoverCMS 옵션을 사용하여 복구됩니다. 다음 명령을 사용해 복구를 수행하면 NODEC에 복구가 시작됩니다.

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    참고:

    • 위 명령의 CMSIPAddress 값은 EXCMS1이 사이트 외부에서 복구될 것이므로 EXCMS1의 원래 IP 주소와 다른 IP 주소입니다. 즉, 원래는 SITEA에서 호스팅되었지만 복구 작업은 현재 SITEB에서 진행되고 있기 때문입니다.

    • DNS 복제가 일어나고 복구 서버(NODEC)의 DNS 캐시가 플러시되고 나면 Setup /RecoverCMS가 종료됩니다. 설치 프로그램이 실패하면 PDC(Primary Domain Controller)와 NODEC 모두에서 NSLookup을 사용해 올바른 IP 주소가 NODEC으로 확인되는지 검사한 다음 설치 프로그램을 다시 실행합니다.

    • Windows Server 2003이 실행되는 장애 조치(failover) 클러스터의 경우 Setup /RecoverCMS 프로세스 도중 EXCMS1의 컴퓨터 개체가 다시 설정됩니다. 이렇게 다시 설정된 내용이 로컬 Active Directory 사이트에 복제되어야 설치 프로그램이 종료됩니다. PDC가 로컬 Active Directory 사이트에 없으면 PDC와 로컬 Active Directory 사이트 사이에서 작동하는 Active Directory 사이트 링크가 있어야 합니다.

    • 설치 복구 프로세스가 완료되면 EXCMS1이 SITEB에 복구되어 DRCLUS1이라고 하는 단일 노드 SCC의 NODEC에서 호스팅할 수 있습니다.

    • 클러스터된 사서함 서버 복구 작업의 결과로 EXCMS1의 DNS TTL이 기본값인 20분으로 되돌려졌습니다. 따라서 다음 명령을 실행하여 5분으로 다시 설정한 다음 클러스터된 사서함 서버를 중지하고 다시 시작합니다.

      Cluster.exe res EXCMS1 /priv HostRecordTTL=300

  5. 그 다음 세 개의 저장소 그룹에 있는 데이터베이스를 Mount-Database 작업을 사용하여 탑재합니다.

  6. CAS2 및 HUB2가 이미 SITEB에 있으므로, 클라이언트 액세스나 허브 전송 등 다른 서버 역할의 복구 작업은 이 시나리오에서 필요하지 않습니다.

    참고

    클라이언트 액세스 서버 복구 작업의 일환으로 SITEB의 클라이언트 액세스 서버를 나타내도록 외부 URL을 다시 구성해야 합니다.

    참고

    이 예제 시나리오에는 Edge 전송 서버 복구가 포함되지 않습니다. Edge 전송 서버가 SITEA에 있었는데 사이트 장애 발생 시 손실된 경우, 새로운 Edge 전송 서버가 SITEB에서 온라인 상태로 되어야 하며 Contoso SMTP(Simple Mail Transfer Protocol) 도메인의 MX(Mail Exchanger) DNS 레코드가 새 Edge 전송 서버를 나타내도록 업데이트되어야 합니다.

  7. Contoso 조직에 추가 Active Directory 사이트가 있으면 메시지는 기본 Active Directory 사이트에 대기됩니다. EXCMS1의 사이트 구성원 정보가 다른 모든 Active Directory 사이트에 복제되고 나면 기본 사이트로 보내려던 메시지를 보관하고 있던 SMTP 큐를 수동으로 다시 시도할 수 있습니다 (수동으로 다시 시도하지 않을 경우 전송 엔진에 의해 12시간 후에 자동으로 다시 큐가 시도됩니다). 이 작업을 통해 메시지가 다시 분류됩니다. 메시지가 모두 재분류된 후 SITEB의 EXCMS1으로 배달됩니다.

이제 올바른 EXCMS1 IP 주소를 가진 다른 서버 및 클라이언트에서 DNS 서버를 사용하는 한, 모든 클라이언트에서는 자신의 원래 액세스 방법(예: Microsoft Outlook Web Access, Exchange ActiveSync 및 Microsoft Office Outlook)을 사용하여 사서함에 액세스할 수 있어야 합니다.

기본 사이트 다시 구성

보조 사이트인 SITEB가 현재 기본 데이터 센터 역할을 하고 있으므로, 원래의 기본 데이터 센터인 SITEA가 다시 사용할 수 있도록 활성화된 다음 호스팅한 서비스가 현재 SITEB에서 호스팅되는 서비스와 충돌하지 않도록 SITEA를 다시 구성해야 합니다. SITEA는 관리자 제어 방식으로 다음 단계를 사용하여 온라인 상태가 됩니다.

  1. 먼저 DC1을 온라인 상태로 만들어 디렉터리 서비스와 DNS 이름 확인 서비스를 온라인 상태로 만듭니다.

  2. DC1을 온라인 상태로 만든 다음 CAS1과 HUB1을 온라인 상태로 만듭니다.

    HUB1이 온라인 상태로 된 후에는 관리자가 큐의 메시지가 제대로 배달되는지 확인해야 합니다. 메시지가 큐에 정체되어 있으면 다음 명령을 사용하여 다시 전송합니다.

    Retry-queue [queue name] -Resubmit $True

  3. EXCLUS1 클러스터를 호스팅하는 노드를 온라인 상태로 만듭니다. 이 시나리오에서는 NODEA가 먼저 온라인 상태로 된 다음 NODEB가 온라인 상태로 됩니다.

  4. 두 노드가 모두 온라인 상태로 될 때 클러스터된 사서함 서버는 오프라인 상태로 남아 있습니다. 여기에는 클러스터된 사서함 서버(특히, 네트워크 이름 리소스)를 포함한 모든 리소스가 해당됩니다. 이러한 리소스는 EXCMS1이 이미 온라인 상태에서 동일한 네트워크 이름을 사용하고 있으므로 온라인 상태가 될 수 없습니다. EXCMS1을 NODEA 또는 NODEB에서 온라인 상태로 만들면 네트워크에서 이름 충돌이 발생됩니다.

  5. 클러스터된 사서함 서버를 비롯한 리소스 그룹이 존재하는 노드에서 관리자는 클러스터된 사서함 서버와 리소스를 장애 조치(failover) 클러스터에서 지워야 합니다. 이를 위해 관리자는 먼저 클러스터된 사서함 서버가 포함된 클러스터 그룹에서 비 Exchange 리소스를 제거한 다음 NODEA에서 다음 명령을 실행합니다.

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

    다음 사항에 유의하십시오.

    • 클러스터된 사서함 서버와 리소스를 EXCLUS1에서 지운 후에는, 클러스터 관리자 또는 장애 조치(failover) 클러스터 관리 스냅인을 사용하여 클러스터된 사서함 서버 리소스가 모두 제거되었는지 확인하는 것이 좋습니다.

    • 이제 EXCLUS1은 수동 사서함 서버 역할이 각각 설치되어 있는 두 개의 수동 노드 NODEA와 NODEB로 구성된 장애 조치(failover) 클러스터로서, 클러스터된 사서함 서버는 존재하지 않습니다.

  6. 클러스터 노드가 Windows Server 2008을 실행하고 있으므로 Setup /ClearLocalCMS를 실행하면 VCO(가상 컴퓨터 개체)가 사용되지 않도록 설정됩니다. VCO를 다시 사용하도록 설정하려면 시작을 클릭하고 모든 프로그램, 관리 도구를 차례로 가리킨 다음 Active Directory 사용자 및 컴퓨터를 클릭합니다. 도메인을 확장하고 컴퓨터를 확장한 다음 EXCMS1 VCO를 마우스 오른쪽 단추로 클릭하고 계정 사용을 클릭합니다.

  7. SITEB에서 SITEA로의 제어 전환을 위해, NODEA를 SITEB의 EXCMS1에서 호스팅된 저장소 그룹의 SCR 대상으로 만듭니다. 이 작업을 수행하려면 NODEC에서 다음 명령을 실행합니다.

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEA

    참고

    원래 장애 조치(failover) 클러스터에서 사용된 저장소가 SITEA 장애로 인한 영향을 받지 않고 또한 세 저장소 그룹의 원래 데이터베이스와 트랜잭션 로그가 NODEA에 그대로 유지된다면 NODEA의 각 저장소 그룹에 대한 전체 다시 시드를 수행할 필요 없이 연속 복제에 이를 사용할 수 있습니다. 기존 파일을 사용할 수 없거나 원래의 클러스터된 사서함 서버가 순환 로깅을 사용하도록 구성된 경우에는 Update-StorageGroupCopy cmdlet를 실행하여 각 저장소 그룹에 대해 전체 다시 시드를 수행해야 합니다.

이 시나리오에서는 SCC가 예제에 사용됩니다. 그런데 복구 시나리오에서 CCR(클러스터 연속 복제) 환경의 클러스터된 사서함 서버를 대신 사용할 경우에는 제어 전환을 위해 수동 노드도 준비해야 하는데, 이를 위해 데이터베이스와 로그 파일이 포함된 수동 노드를 준비하는 추가 단계를 수행하는 것이 좋습니다. 이러한 단계는 CCR 환경이 SITEA로 옮겨진 이후 수동 저장소 그룹을 시드하지 않아도 되는 최적화를 위해 수행됩니다. 이 작업은 다음 두 가지 방법 중 하나를 사용하여 수행합니다.

  • 세 개의 SCR 대상 모두에 대해 연속 복제를 일시 중단한 다음 NODEA의 저장소 그룹 파일과 데이터베이스를 NODEB의 적절한 위치로 복사합니다.

  • NODEB를 EXCMS1의 SCR 대상으로 사용하도록 설정합니다.

원래의 기본 사이트로 제어 전환

SITEA가 사용 가능한 것으로 승인된 다음에는 SITEB의 데이터 및 서비스에 대한 제어를 SITEA로 전환하는 단계를 수행합니다. 제어 전환 수행 단계는 다음과 같이 SITEB 활성화 수행 단계의 역순입니다.

  1. 먼저 EXCMS1의 모든 데이터베이스를 분리합니다. NODEA에서의 트랜잭션 로그 파일 생성을 중단하고 SCR 대상의 활성화를 준비하려면 이 작업을 수행합니다. 데이터베이스는 Exchange 관리 콘솔을 사용하거나 Exchange 관리 셸의 Dismount-Database cmdlet를 사용하여 분리합니다.

  2. NODEA에서 관리자는 탑재할 저장소 그룹을 모두 준비합니다. 이 작업에서는 다음 명령을 실행합니다.

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEA

    다음 사항에 유의하십시오.

    • SCR 원본 서버를 사용할 수 있으므로 위의 세 명령에서는 Force 매개 변수를 사용하지 않습니다. 따라서 이 명령을 실행하면 SCR 원본의 모든 로그 파일이 자동으로 복사됩니다.

    • 각 작업이 완료되면 관리자는 각 저장소 그룹의 모든 로그 파일이 NODEA에 복사되고 SCR을 사용하지 않도록 설정되었는지 확인해야 합니다.

    • NODEB도 SCR 대상으로 구성되었다면 작업을 계속하기 전에 이 노드도 SCR을 사용하지 않도록 설정하고 복원해야 합니다. 이 시나리오에서는 Restore-StorageGroupCopy를 NODEB에서 먼저 실행하고 NODEA에서 실행한 다음, NODEA에서 Setup /RecoverCMS를 실행합니다.

  3. DRCLUS1의 클러스터된 사서함 서버인 EXCMS1을 중지하여야 합니다. 이 작업은 Exchange 관리 콘솔에서 클러스터된 사서함 서버 관리 마법사를 사용하거나 Exchange 관리 셸의 Stop-ClusteredMailboxServer cmdlet를 사용하여 NODEC에서 수행해야 합니다.

  4. DNS 관리 스냅인을 사용하여 DNS에서 EXCMS1의 레코드를 제거해야 합니다.

    참고

    EXCMS1의 레코드는 장애 조치(failover) 클러스터에 Windows Server 2008이 실행되는 경우에만 제거해야 하며, Windows Server 2003이 실행되는 경우에는 이 단계를 수행할 필요가 없습니다.

  5. 클러스터된 사서함 서버(EXCMS1)는 설치 프로그램에 /RecoverCMS 옵션을 사용하여 복구됩니다. 다음 명령을 사용해 복구를 수행하면 NODEA에 복구가 시작됩니다.

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    다음 사항에 유의하십시오.

    • 위 명령의 CMSIPAddress 값은 EXCMS1이 원래의 위치로 다시 복구될 것이므로 원래의 EXCMS1 IP 주소입니다.

    • 설치 복구 프로세스가 완료되면 EXCMS1이 SITEA에 복구되어 EXCLUS1이라고 하는 2개 노드 SCC의 NODEA에서 호스팅할 수 있습니다.

    참고

    이 시나리오에서는 SCC가 예제에 사용됩니다. 그런데 복구 시나리오에서 CCR 환경의 클러스터된 사서함 서버를 대신 사용할 경우에는 추가 단계를 수행해야 합니다. 이 경우, /RecoverCMS 작업으로 NODEA에서 NODEB로의 연속 복제가 일시 중단되므로 관리자는 저장소 그룹에 대해 Resume-StorageGroupCopy를 실행하여 다시 복제를 설정하여 작업을 재생해야 합니다. 그런 다음 복제 작업이 다시 시작되는지도 확인해야 합니다. 위에서 설명했듯이 NODEB의 준비가 실패하면 저장소 그룹의 수동 복사본을 다시 시드해야 합니다.

    • 클러스터된 사서함 서버 복구 작업의 결과로 EXCMS1의 DNS TTL이 기본값인 20분으로 되돌려졌습니다. 따라서 다음 명령을 실행하여 5분으로 다시 설정한 다음 클러스터된 사서함 서버를 중지하고 다시 시작합니다.

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300

  6. 세 개의 저장소 그룹에 있는 데이터베이스를 Mount-Database cmdlet를 사용하여 탑재합니다.

  7. CAS1 및 HUB1이 이미 SITEA에 있으므로, 클라이언트 액세스나 허브 전송 등의 다른 서버 역할의 복구 작업은 이 시나리오에서 필요하지 않습니다.

    참고

    클라이언트 액세스 서버 복구 작업의 일환으로 SITEA의 클라이언트 액세스 서버를 나타내도록 외부 URL을 다시 구성해야 합니다.

    참고

    이 예제 시나리오에는 Edge 전송 서버 복구가 포함되지 않습니다. Edge 전송 서버를 사용 중인 경우, Contoso SMTP(Simple Mail Transfer Protocol) 도메인의 MX(Mail Exchanger) DNS 레코드가 올바른 Edge 전송 서버를 나타내도록 업데이트되어야 합니다.

  8. Contoso 조직에 추가 Active Directory 사이트가 있으면 메시지는 기본 Active Directory 사이트에서 대기됩니다. EXCMS1의 사이트 구성원 정보가 다른 모든 Active Directory 사이트에 복제되고 나면 기본 사이트로 보내려던 메시지를 보관하고 있던 SMTP 큐를 수동으로 다시 시도할 수 있습니다 (수동으로 다시 시도하지 않을 경우 전송 엔진에 의해 12시간 후에 자동으로 다시 큐가 시도됩니다). 이 작업을 통해 메시지가 다시 분류됩니다. 메시지가 모두 재분류된 후 SITEA의 EXCMS1으로 배달됩니다.

  9. 이제 올바른 EXCMS1 IP 주소를 가진 다른 서버 및 클라이언트에서 DNS 서버를 사용하는 한, 모든 클라이언트에서는 자신의 원래 액세스 방법(예: Outlook Web Access, Exchange ActiveSync 및 Outlook)을 사용하여 사서함에 액세스할 수 있어야 합니다. 또한 DNS 변경 사항이 SITEB에 복제되고 EXCMS1의 사이트 구성원이 복제된 다음에는 허브 전송 서버가 메시지를 올바른 Active Directory 사이트에 라우팅합니다. 관리자가 HUB1 또는 HUB2의 큐에 있는 메시지를 수동으로 다시 전송할 수도 있습니다. 이 작업에서는 다음 명령을 실행합니다.

    Retry-queue [queue name] -Resubmit $True

백업 사이트 다시 구성

SITEB에서 SITEA로의 수동 제어 전환이 완료된 다음에는 SITEB를 다시 원래의 백업 데이터 센터로 되돌릴 수 있습니다. SITEB의 장애 조치(failover) 클러스터에서 대기 클러스터된 사서함 서버를 지우고 NODEC를 EXCMS1에 있는 세 저장소 그룹의 SCR 대상으로 사용하도록 다시 설정하면 됩니다. 이 작업은 다음 단계를 차례로 수행하여 완료합니다.

  1. 제어 전환 시 SITEB의 DRCLUS1에서 실행되는 클러스터된 사서함 서버를 중지하여 SITEA의 EXCLUS1에서 호스팅될 수 있도록 합니다. EXCMS1이 다시 EXCLUS1에서 작동되면 해당 구성 정보를 DRCLUS1에서 제거해야 합니다. 구성 정보를 지울 수 있으며, 클러스터된 사서함 서버를 포함하는 클러스터 그룹에서 비 Exchange 리소스를 제거한 후에 다음 명령을 실행하면 DRCLUS1에서 EXCMS1을 완전히 제거할 수 있습니다.

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

  2. 클러스터 노드가 Windows Server 2008을 실행하고 있으므로 Setup /ClearLocalCMS를 실행하면 VCO가 사용되지 않도록 설정됩니다. VCO를 다시 사용하도록 설정하려면 시작을 클릭하고 모든 프로그램, 관리 도구를 차례로 가리킨 다음 Active Directory 사용자 및 컴퓨터를 클릭합니다. 도메인을 확장하고 컴퓨터를 확장한 다음 EXCMS1 VCO를 마우스 오른쪽 단추로 클릭하고 계정 사용을 클릭합니다.

  3. 클러스터된 사서함 서버와 리소스를 DRCLUS1에서 지운 후에는, 관리자가 클러스터 관리자 또는 장애 조치(failover) 클러스터 관리 스냅인을 사용하여 클러스터된 사서함 서버 리소스가 모두 제거되었는지 확인해야 합니다.

  4. 트랜잭션 로그 파일이 EXCMS1의 3개 저장소 그룹에서 NODEC의 SCR 대상으로 복제되도록 SCR이 구성됩니다. 이 작업은 다음 명령을 사용하여 구성합니다.

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC

    참고

    SCR에서 저장소 그룹을 EXCMS1에서 NODEC로 복제할 수 있도록 설정하기 전에 저장소 그룹 또는 데이터베이스 경로 충돌이 없는지 확인해야 합니다. 또한 이전에 사용하던 불필요한 저장소 그룹과 데이터베이스 파일이 원래 경로에서 제거되었는지도 확인해야 합니다.

  5. 그런 다음 각 저장소 그룹의 SCR 상태를 Test-ReplicationHealth 및 Get-StorageGroupCopyStatus cmdlet를 사용하여 확인합니다. 백업 및 로그 자르기 작업을 비롯하여 노드 간 클러스터된 사서함 서버의 이동 작업이 예상대로 수행되었는지 확인합니다. 모든 확인 작업이 끝나면 기본 데이터 센터와 보조 데이터 센터가 다시 Exchange 2007 메시징 시스템에서의 원래 작업 모드로 돌아갑니다.