Site Resilience Configurations

 

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

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

최근 몇 년 사이에 더욱 많은 기업에서 메시징을 성공의 토대로 인식하고 있습니다. 대부분의 조직에서 메시징 시스템은 비즈니스 연속 계획에 포함되어야 하며 사이트 복구 능력을 조직의 메시징 서비스 배포에 디자인해야 합니다. 기본적으로 여러 사이트 복구 솔루션에는 보조 데이터 센터의 백업 하드웨어 배포가 포함됩니다. 이로 인해 다음과 같은 의문점이 생길 수 있습니다.

  • 기본 데이터 센터에 오류가 발생할 경우 필요한 서비스 수준은 무엇입니까?

  • 사용자에게 자신의 데이터가 필요합니까 아니면 메시징 서비스만 필요합니까?

  • 어느 정도나 빠르게 데이터가 필요합니까?

  • 지원해야 하는 사용자 수는 몇 명입니까?

  • 사용자가 자신의 데이터에 어떻게 액세스합니까?

  • 대기 데이터 센터 활성화 SLA(서비스 수준 계약)란 무엇입니까?

  • 서비스를 기본 데이터 센터로 다시 이동하는 방법은 무엇입니까?

  • 리소스가 사이트 복구 솔루션 전용입니까?

이러한 질문에 대답함으로써 사이트 복구 능력 메시징 솔루션의 기본 틀을 갖출 수 있습니다. 사이트 오류 복구의 핵심 요구 사항은 메시징 서비스를 호스팅하는 백업 데이터 센터로 필요한 메시징 데이터를 가져오는 솔루션을 만드는 것입니다.

이 항목에서는 Microsoft Exchange Server 2007의 RTM(Release To Manufacturing) 버전 및 Exchange 2007 SP1(서비스 팩 1)에 대한 다양한 사이트 복구 구성에 대해 자세히 설명합니다. 사이트 복구 솔루션을 계획하려면 다음 용어를 잘 알고 있어야 합니다.

  • 확장 클러스터   지리적으로 분산된 클러스터라고도 하며, 클러스터의 노드가 두 개 이상의 데이터 센터에 있는 클러스터 구성입니다.

  • 데이터베이스 이식성   해당 호스트 데이터베이스를 이동하는 경우 다른 서버에서 사서함을 변경할 수 있는 관리 작업입니다.

  • 확장된 Active Directory 사이트   두 개 이상의 데이터 센터의 컴퓨터가 있는 Active Directory 디렉터리 서비스 사이트(예: 여러 실제 위치를 포괄하는 Active Directory 사이트)입니다.

  • Active Directory 사이트 구성원   컴퓨터의 기본 IP 주소를 바탕으로 한 특정 Active Directory 사이트의 구성원입니다. IP 주소를 변경하거나 해당 IP 주소가 포함된 Active Directory 사이트를 변경하면 컴퓨터의 Active Directory 사이트 구성원이 변경됩니다.

  • 프로덕션 데이터 센터   서비스의 활성 서버를 호스팅하는 데이터 센터로, 인프라를 연결합니다.

  • 핫 백업 데이터 센터   서비스의 소유권을 바로 가져와서 배달을 계속할 수 있는 백업 데이터 센터입니다. 이 위치에서 서비스를 실행하기 위한 특별한 구성이 필요하지 않습니다.

  • 웜 백업 데이터 센터   프로덕션 데이터 센터에 대한 서비스의 소유권을 가져올 수 있는 서버가 있는 백업 데이터 센터입니다. 이 데이터 센터의 서비스를 활성화하려면 수동으로 작업해야 합니다.

  • 콜드 백업 데이터 센터   서비스의 소유권을 가질 수 있는 용량 및 잠재적 인프라를 가진 백업 데이터 센터입니다. 서비스가 데이터 센터에서 작동하려면 몇 가지 작업을 수행해야 합니다.

  • 전용   기본 데이터 센터의 사용자만 지원하도록 지정된 서버입니다.

  • 비전용   기본 데이터 센터의 사용자와 다른 위치의 사용자를 지원하는 서버입니다.

프로덕션, 전용 등의 용어는 사이트 복구 배포를 설명할 때 함께 사용될 수 있습니다. 예를 들어, 대규모로 구성된 전용 백업 데이터 센터에서 백업한 프로덕션 데이터 센터를 프로덕션:웜(전용)이라고 합니다.

사이트 복구 능력을 지원하는 기능

사이트 복구 솔루션의 기본 구성 요소로 사용할 수 있는 다음과 같은 여러 가지 Exchange 2007 기능이 있습니다.

  • 확장 클러스터: 데이터를 복제하거나 백업 데이터 센터의 활성화를 간단하게 하는 데 사용할 수 있습니다.

  • 데이터베이스 이식성: 복제된 데이터를 활성화하는 데 사용할 수 있습니다.

  • 확장된 Active Directory 사이트: 확장된 클러스터를 지원하거나 백업 데이터 센터를 사용하도록 설정하는 데 사용할 수 있습니다.

  • 컴퓨터의 Active Directory 사이트 구성원 변경: 백업 데이터 센터 활성화의 일부로 수행할 수 있습니다.

  • 외부 저장소와 함께 정규 테이프 백업 사용: 백업 데이터 센터에서 사서함 데이터를 복구하는 데 사용할 수 있습니다.

또한 타사 제품은 백업 데이터 센터로 데이터를 전송하는 데 사용할 수 있는 데이터 복제를 제공합니다. 이러한 제품은 독립 실행형 서버, 복구 클러스터 또는 확장된 SCC(단일 복사본 클러스터)와 함께 사용할 수 있습니다. 이러한 구성에서 기본 서버나 클러스터의 데이터가 보조 데이터 센터의 보조 서버나 클러스터 구성에 복제됩니다. 사이트 오류가 발생하는 경우 보조 데이터 센터의 클러스터나 서버가 수동으로 활성화됩니다.

Exchange 2007 SP1에는 특히 사이트 복구 시나리오를 위해 설계된 SCR(대기 연속 복제)이라는 새 기능이 추가되었습니다. 이름이 암시하듯이 SCR은 대기 복구 서버를 사용하는 시나리오를 위해 설계되었습니다. Exchange 2007 RTM의 기존 연속 복제 기능을 확장하는 SCR을 사용하면, Exchange 2007 SP1을 실행하는 사서함 서버에 대한 새 데이터 가용성 시나리오가 가능합니다. SCR은 LCR(로컬 연속 복제) 및 CCR(클러스터 연속 복제)에서 사용하는 동일한 로그 전달 및 재생 기술을 사용하여 추가된 배포 옵션과 구성을 제공합니다.

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

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

사이트 복구를 수행할 솔루션

조직에서는 여러 가지 사이트 복구 솔루션을 고려할 수 있습니다. 이 항목의 나머지 부분에서 다음 사이트 복구 솔루션에 대한 정보를 제공합니다.

  • 프로덕션:콜드(전용)

  • 프로덕션:웜(전용)

  • 프로덕션:웜(비전용) – 두 개의 Active Directory 사이트 포함

  • 프로덕션:프로덕션(비전용) - 단일 Active Directory 사이트 포함

이 항목에서 설명하는 솔루션은 프로덕션 데이터 센터에서 오류가 발생하면 전체 메시징 인프라가 손실된다고 가정합니다. 백업 데이터 센터는 인터넷에 연결되어 있어야 하고 Exchange를 호스팅하는 데 필요한 모든 서비스가 있어야 합니다. 또한 활성화 프로세스를 스크립팅하고 정기적으로 테스트해야 합니다.

프로덕션:콜드(전용)

가장 기본적인 메시징 사이트 복구 솔루션은 조직에 하드웨어 및 설비에 대한 계약이 있지만 활성 백업 데이터 센터가 없는 경우입니다. 모든 사서함 데이터는 정기적으로 백업되고 사이트 밖으로 이동됩니다. Active Directory 데이터는 같은 방식으로 처리됩니다. 사이트 복구 솔루션을 활성화하려면 하드웨어를 확보하고 배포해야 합니다. 전체 중지 시간을 줄이기 위해 조직은 중요한 하드웨어 부분에 대해 하드웨어 공급업체와 신속한 배달 계약을 합니다.

이러한 솔루션의 변형으로는 공급업체가 유지 관리하는 풀에서 하드웨어를 사용할 수 있는 재해 복구 공급업체와의 관계를 설정하는 것입니다. 이러한 유형의 관계를 사용하면 공급업체의 위치에서 백업 데이터를 유지 관리할 수 있으므로 복구 시간을 줄일 수 있습니다. 공급업체 위치에 있는 전용 저장소는 사서함 및 Active Directory 데이터의 복제 대상일 수 있습니다.

작업을 간소화하기 위해 배포된 구성이 프로덕션 환경과 실제로 비슷하거나 최소한 프로덕션 환경의 일부와 비슷할 수 있습니다. 이러한 복구 프로세스 도중에 가능하면 잘 알고 있는 기술 및 종속성으로 작업하는 것이 좋습니다.

프로덕션:웜(전용)

프로덕션:웜(전용) 복구 모델에서는 프로덕션 데이터 센터에 전용 장비로 지정된 백업 데이터 센터가 있습니다. 전용 장비는 프로덕션 데이터 센터를 사용할 수 없을 때 사용됩니다. 앞서 설명한 것처럼 백업 데이터 센터는 자동으로 활성화되지 않습니다. 관리자가 해당 활성화를 수동으로 트리거해야 합니다. 트리거되면 활성화를 통해 메시징 서비스를 제공하기 위한 전용 백업 장비와 인프라가 다시 구성됩니다. 다음은 프로덕션:웜(전용) 구성을 나타낸 그림입니다.

프로덕션:웜(전용) 배포 예제

프로덕션:웜(전용) 배포

위의 그림에서는 Edge 전송, 허브 전송, 클라이언트 액세스 및 사서함 서버 역할을 호스팅하는 프로덕션 데이터 센터(A)를 보여줍니다. 웜 백업 데이터 센터(B)에는 각 역할 및 Active Directory에 대한 전용 백업 서버가 있습니다. 이 그림은 사서함 서버 역할을 제외한 모든 서버 역할에 간단한 중복이 사용되고 있음을 보여줍니다. 사서함 중복은 적절한 복제 솔루션을 사용한 클러스터나 대기 서버 구성에 의해 처리됩니다.

가능한 사서함 중복 솔루션은 다음과 같습니다.

  • 확장 클러스터 구성의 CCR(클러스터 연속 복제)   CCR은 로그 전달을 사용하여 사서함 데이터의 보조 복사본을 만들고 관리합니다. 그러므로 CCR 두 노드 클러스터에는 각 데이터 센터의 노드가 하나 있습니다. 이 구성에서 Windows 클러스터 서비스에 두 위치 사이에서 확장되는 서브넷이 필요합니다. 확장 클러스터를 통해 할당된 IP 주소를 다른 데이터 센터의 노드에 다시 등록함으로써 클러스터된 사서함 서버가 간단히 장애 조치할 수 있습니다.

  • 동기 파트너 복제를 사용한 SCC(단일 복사본 클러스터)   파트너 복제를 통해 시스템에서 두 개의 사서함 서버 데이터 복사본을 가질 수 있습니다. CCR에서처럼 클러스터 장애 조치가 이루어지려면 확장된 서브넷이 필요합니다.

  • 파트너 복제를 사용한 대기 클러스터   사서함 데이터는 백업 데이터 센터의 보조 클러스터에 복제되고 서버 재해 복구 프로세스가 서비스를 복원하는 데 사용됩니다. 복제는 동기적이거나 비동기적일 수 있습니다. 클러스터링이 필요하지 않으므로 확장된 서브넷 요구 사항이 없습니다.

  • 파트너 복제를 사용한 대기 서버   사서함 데이터는 백업 데이터 센터의 보조 서버에 복제되고 데이터베이스 이식성 또는 서버 재해 복구 프로세스가 서비스를 복원하는 데 사용됩니다. 복제는 동기적이거나 비동기적일 수 있습니다. 클러스터링이 필요하지 않으므로 확장된 서브넷 요구 사항이 없습니다.

  • 보조 데이터 센터에 호스팅된 보조 복사본을 사용한 LCR(로컬 연속 복제)   기본 솔루션은 아니지만 일부 조직에 충분할 수 있습니다. 이 구성에서는 iSCSI(인터넷 SCSI) 기반 저장소를 사용하여 데이터의 수동 복사본을 저장합니다. 네트워크 연결 특성상 수동 복사본이 활성 복사본과 일관된 상태여야 합니다. 이 구성에서 네트워크 지연 및 대역폭이 클라이언트 액세스를 지원할 가능성이 거의 없으므로 LCR은 빠른 로컬 활성화에 사용할 수 없습니다.

위의 그림에서는 클러스터된 솔루션 중 하나를 사용하는 방법을 보여줍니다. 사서함 서버가 프로덕션 데이터 센터의 Active Directory 사이트에 표시되기 때문입니다. 클러스터된 솔루션에서 클러스터에 있는 각 노드의 네트워크는 같은 서브넷에 있어야 합니다. 클러스터되지 않은 솔루션에서 단일 서브넷이 필요하지 않지만 권장됩니다. 필요한 경우 다른 서브넷을 사용할 수 있습니다.

클러스터된 솔루션이 사용된다고 가정할 경우 일반 작업 과정은 다음과 같습니다.

  1. 받는 인터넷 메일은 모두 데이터 센터 A의 Edge 전송 서버를 통해 이동합니다.

  2. Active Directory 사이트 Redmond-Prod의 사서함 서버로 보내는 모든 메일은 Redmond-Prod의 허브 전송 서버에서 처리됩니다.

  3. Active Directory 사이트 Redmond-Prod의 클러스터된 사서함 서버는 데이터 센터 A 또는 데이터 센터 B에 구성된 노드에서 호스팅됩니다. 노드 A와 노드 B는 Redmond-Prod의 일부이며 Redmond-Prod 허브 전송 서버와 클라이언트 액세스 서버에서 처리됩니다.

  4. CCR은 두 개의 노드를 지원하므로 두 번째 노드가 데이터 센터 B에 있어야 합니다. 즉, 데이터 센터 A에서 활성 노드가 실패하면 클러스터된 사서함 서버가 데이터 센터 B로 이동됩니다. 이 경우 클러스터된 사서함 서버는 여전히 데이터 센터 A의 허브 전송 서버와 클라이언트 액세스 서버에서 처리됩니다.

  5. 세 개의 서버와 두 개의 데이터 복사본이 있는 SCC는 오류 발생 시 클러스터된 사서함 서버가 데이터 센터 B로 장애 조치되지 않고 데이터 센터 A에 남아 있도록 구성할 수 있습니다. 그러나 저장소 기반 오류인 경우 데이터 센터 B에서 수동 노드를 여전히 활성화해야 합니다.

두 데이터 센터 간 네트워크 대역폭 요구 사항에는 세 가지 구동 요소가 있습니다.

  • 클러스터 서비스 대기 요구 사항   클러스터 서비스에는 클러스터 노드 간에 0.5초 이하의 왕복 시간이 필요합니다.

  • 복제를 위한 대역폭 요구 사항   CCR 복제가 데이터베이스 복사가 아닌 로그 전달을 기반으로 하므로 CCR은 타사 복제 솔루션보다 작은 대역폭을 필요로 합니다. CCR 솔루션에 필요한 대역폭은 일반적으로 환경마다 고유한 여러 가지 요소에 따라 다르며 요구 사항에는 다음에 대한 대역폭이 포함됩니다.

    • 로그 전달

    • Microsoft Exchange Replication Service가 전달할 수 있는 새 로그 파일이 있는 시점을 알게 되는 방식인 파일 시스템 알림

    • 디렉터리 서버 트래픽

    • 클라이언트가 클러스터된 사서함 서버와 동일한 실제 위치에 없는 경우의 클라이언트 트래픽

    • 클러스터 하트비트 트래픽

    • 클러스터 데이터베이스 업데이트

    • 네트워크를 사용하는 기타 모든 응용 프로그램

  • 허브 전송 및 클라이언트 액세스 서버에는 서버와 서버에서 처리하는 사서함 서버 간의 LAN 통신 필요   클라이언트 액세스 서버의 경우 온라인 사용자를 처리하기 때문에 이 요구 사항이 더욱 중요합니다. 도메인 컨트롤러에 대한 사서함 액세스는 WAN(Wide Area Network) 연결을 통해 이루어지며 액세스가 지연되면 온라인 MAPI 액세스에 영향을 줍니다.

클러스터되지 않은 솔루션이 배포되면 지연 및 대역폭 요구 사항이 줄어들 수 있습니다. 복제에 대한 네트워크 요구 사항은 유지되며 중요합니다. 그러나 데이터 센터 A의 전체 오류 없이 백업 사서함 서버를 활성화할 수 있다면 대부분의 다른 요구 사항은 없습니다.

관리자는 프로덕션 데이터 센터에 오류가 발생하면 다음 중 하나를 수행하여 메일 흐름 및 메시징 서비스를 복원할 수 있습니다.

  • 백업 데이터 센터의 사서함 서버를 Active Directory 사이트 Redmond-DR로 이동

  • 백업 데이터 센터의 허브 전송, 클라이언트 액세스 및 디렉터리 서버를 Active Directory 사이트 Redmond-Prod로 이동

두 번째 옵션은 환경의 다른 부분에 주는 영향을 최소화하므로 권장되는 전략입니다. 예를 들면 지점의 Exchange 서버에서는 대기 중인 메일에 대한 인식하는 라우팅을 변경하지 않아도 됩니다. 올바른 서버가 작동하고 사용할 수 있는 경우 이러한 서버는 간단히 연결됩니다.

데이터 센터 B를 활성화하려면 다음과 같은 고급 단계를 수행합니다.

  1. 네트워크 인프라를 온라인 상태로 만듭니다.

  2. Active Directory 인프라를 온라인 상태로 만듭니다.

  3. 나머지 사서함 서버를 온라인 상태로 만듭니다. 이 단계에서 클러스터가 나머지 단일 서버와 함께 온라인 상태로 전환됩니다.

  4. Active Directory 사이트 Redmond-Prod는 Redmond-DR의 허브 전송, 클라이언트 액세스 및 디렉터리 서버의 IP 주소로 업데이트됩니다.

  5. 조직의 도메인에 대한 MX 레코드는 데이터 센터 B에 있는 Edge 전송 서버의 IP 주소로 업데이트됩니다.

  6. 새로 이동한 클라이언트 액세스 서버가 NLB(네트워크 부하 분산) 구성에 추가됩니다.

  7. 데이터 센터 A 메시징 서비스가 데이터 센터 B에서 복원됩니다.

데이터 센터 A를 사용할 수 있으면 다음과 같은 고급 단계를 수행하여 데이터 센터 B를 비활성화할 수 있습니다.

  1. 데이터 센터 A 개별 서버를 온라인 상태로 만듭니다. Exchange 서비스가 수동으로 중지 또는 사용하지 않도록 설정되지 않으면 이들 서버가 서비스를 제공합니다. 이전으로 마이그레이션할 때 데이터 센터 A 서버를 온라인 상태로 전환할 수 있습니다.

  2. 데이터 센터 B의 허브 전송 서버에서 해당 큐를 손실한 다음 해당 서버를 오프라인 상태로 전환할 수 있습니다.

  3. 데이터 센터 B의 클라이언트 액세스 서버를 NLB 구성 밖으로 가져갑니다. 그러면 클라이언트가 데이터 센터 A의 서버를 통해 연결됩니다.

  4. 조직의 도메인에 대한 MX 레코드는 데이터 센터 A에 있는 Edge 전송 서버의 IP 주소로 업데이트됩니다.

  5. 필수 네트워킹 인프라 업데이트를 수행합니다.

  6. 클러스터된 사서함 서버를 데이터 센터 A로 이동합니다.

  7. Active Directory 사이트 Redmond-DR을 활성화 중에 이동된 서버의 IP 주소로 업데이트합니다.

  8. 데이터 센터 A 메시징 서비스가 복원됩니다.

사이트 오류 솔루션과 마찬가지로 프로덕션 및 백업 데이터 센터 활성화를 정기적으로 스크립팅하고 테스트해야 합니다. 사서함 서버에 클러스터된 솔루션을 사용하면 백업 데이터 센터의 활성화 시간이 줄어듭니다. 다른 솔루션의 경우 메일 흐름이 다시 시작되고 클라이언트가 자신의 사서함에 액세스할 수 있을 경우 영향을 줄 수 있는 일부 DNS(Domain Name System) 및 Active Directory 복제가 필요할 수 있습니다.

프로덕션:웜(전용) 솔루션은 전용 컴퓨터에서 예상할 수 있는 수준의 서비스를 제공한다는 이점이 있습니다.

프로덕션:웜(비전용) – 두 개의 Active Directory 사이트 포함

프로덕션:웜(전용) 구성에서 백업 데이터 센터의 Edge 전송, 허브 전송 및 클라이언트 액세스 서버는 데이터 센터 A의 전용 대기 리소스로 사용됩니다. 이러한 구성은 중요한 하드웨어 투자가 완전히 사용되고 있지 않음을 나타냅니다. 대체 모델이 아래 그림에 나와 있습니다.

프로덕션:웜(비전용) 배포 예제

예제 프로덕션:웜(비전용) 배포

프로덕션:웜(비전용)은 관리자가 백업 데이터 센터의 활성화를 수동으로 트리거해야 합니다. 트리거되면 활성화 프로세스는 백업 데이터 센터의 일부 장비와 인프라에서 데이터 센터 A의 사용자에 대한 메시징 서비스를 실행하도록 재구성합니다.

프로덕션:웜(전용) 솔루션에서처럼 프로덕션:웜(비전용) 솔루션에는 두 개의 Active Directory 사이트가 있습니다. 그러나 프로덕션:웜(전용) 솔루션과 달리 이 두 Active Directory 사이트는 다른 데이터 센터로 확장됩니다. 백업 데이터 센터의 전용 리소스는 백업 데이터 센터의 다른 프로덕션 구성에 대한 중복 서버가 됩니다. 이렇게 하면 일반 사용에 이러한 리소스를 사용할 수 있으므로 서로 효율적으로 백업이 되는 두 개의 프로덕션 데이터 센터가 만들어집니다.

예를 들어, 그림 프로덕션:웜(비전용) 배포 예에서처럼 데이터 센터 A에 오류가 발생하면 허브 전송 서버 4, 클라이언트 액세스 서버 4 및 글로벌 카탈로그 서버 4가 Active Directory 사이트 Redmond에 추가되고 Redmond 노드 B와 함께 데이터 센터 A의 사용자에게 메시징 서비스를 제공합니다. 사이트에 오류가 발생하면 두 개의 프로덕션 환경에서는 표준 상태에 비해 용량과 중복이 줄어든 상태로 실행됩니다. 처리 중인 해당 부하를 지원할 수 있다면 이 구성을 사용할 수 있습니다. 예를 들면 인터넷 메일이 데이터 센터 B의 Edge 전송 서버를 통해 이동합니다. 확장 데이터 센터 중지를 지원하려면 비즈니스에 필요 시 추가 하드웨어를 신속하게 제공하는 공급업체 계약이 있을 수 있습니다. 그러면 추가 하드웨어를 사용하여 중복을 복원하거나 용량을 추가할 수 있습니다.

이 솔루션에 대한 Redmond 및 Dublin Active Directory 사이트 배포의 일반적인 작업은 프로덕션:웜(전용) 솔루션에 대한 배포와 동일합니다. 마찬가지로 두 위치 간 네트워크 대역폭의 구동 요소는 같습니다. 단, Redmond 서버와 Dublin 서버를 동시에 지원해야 합니다.

백업 데이터 센터의 활성화는 다음을 통해 수행됩니다.

  • 활성 노드와 클러스터된 사서함 서버를 작동 중인 데이터 센터의 Active Directory 사이트로 이동

  • 백업 데이터 센터의 허브 전송, 클라이언트 액세스 및 디렉터리 서버를 오류가 발생한 데이터 센터의 Active Directory 사이트로 이동

권장하는 활성화 솔루션은 허브 전송 및 클라이언트 액세스 서버를 오류가 발생한 데이터 센터의 Active Directory 사이트로 이동하는 것입니다. 이 솔루션을 사용하면 오류를 최소화하고 간단하게 활성화를 수행할 수 있습니다.

이 솔루션에서 다음과 같은 고급 단계를 수행하여 데이터 센터 A를 복구합니다.

  1. 네트워크 인프라를 온라인 상태로 만듭니다. 인터넷 메일을 데이터 센터 B에서 받고 있으므로 네트워크 인프라를 변경하지 않아도 됩니다.

  2. 데이터 센터 A의 Active Directory 인프라를 온라인 상태로 만듭니다(Active Directory 사이트 Redmond).

  3. 나머지 사서함 서버를 온라인 상태로 만듭니다. 이 단계에서 클러스터가 나머지 단일 서버와 함께 온라인 상태로 전환됩니다.

  4. Active Directory 사이트 Redmond는 허브 전송 서버 4, 클라이언트 액세스 서버 4 및 글로벌 카탈로그 서버 4의 IP 주소로 업데이트됩니다.

  5. 클라이언트 액세스 서버 3이 Redmond의 NLB 구성에 추가됩니다.

  6. 데이터 센터 A 메시징 서비스가 복원됩니다.

데이터 센터 A를 사용할 수 있으면 다음과 같은 고급 단계를 사용하여 데이터 센터 B를 해당하는 일반 구성으로 복원할 수 있습니다.

  1. 데이터 센터 A 개별 서버를 온라인 상태로 만듭니다. Exchange 서비스가 수동으로 중지 또는 사용하지 않도록 설정되지 않으면 이들 서버가 서비스를 제공합니다. 이전으로 마이그레이션할 때 데이터 센터 A 서버를 온라인 상태로 전환할 수 있습니다.

  2. 허브 전송 서버 4에서 해당 큐를 손실한 다음 해당 서버를 오프라인 상태로 전환할 수 있습니다.

  3. 클라이언트 액세스 서버 4를 NLB 구성 밖으로 가져갑니다. 클라이언트가 데이터 센터 A의 서버에 연결할 수 있습니다.

  4. 필수 네트워킹 인프라 업데이트를 수행합니다.

  5. 클러스터된 사서함 서버를 데이터 센터 A로 이동합니다.

  6. Active Directory 사이트 Dublin을 활성화 중에 이동된 서버의 IP 주소로 업데이트합니다.

  7. 두 데이터 센터가 원래 조건으로 복원됩니다.

사이트 오류 솔루션과 마찬가지로 프로덕션 및 백업 데이터 센터 활성화를 정기적으로 스크립팅하고 테스트해야 합니다. 사서함 서버용의 클러스터링 솔루션을 사용하면 백업 데이터 센터의 활성화 시간이 줄어듭니다. 메일 흐름이 다시 시작되고 클라이언트가 자신의 사서함에 액세스할 수 있을 때 영향을 줄 수 있는 일부 DNS 및 Active Directory 복제가 다른 사서함 솔루션에 필요할 수 있습니다.

이 솔루션을 사용하여 사이트 복구에 사용된 서버를 일반 작업에 적용할 수 있습니다. 이렇게 할 경우 사이트 복구 솔루션 비용을 절감할 수도 있으나 필요할 때 전체 시스템 부하를 견딜 수 없다는 위험이 있습니다. 예를 들어, 데이터 센터 B에 있는 허브 전송 서버의 부하가 용량의 80%를 사용하게 늘어나는 경우 A의 백업 데이터 센터를 활성화하면 허브 전송 용량을 초과하게 됩니다. 이 솔루션을 사용하는 경우 관리자는 시간이 지남에 따라 시스템 사용률을 추적할 때 주의하여 솔루션이 실행 가능한 상태로 있는지 확인해야 합니다. 부하가 늘어나면 새 하드웨어를 구하여 배포해야 합니다.

프로덕션:프로덕션(비전용) – 한 개의 Active Directory 사이트 포함

백업 사이트의 자동 활성화를 지원할 수 있는 솔루션이 필요한 조직은 프로덕션:프로덕션(비전용) 솔루션을 배포해야 합니다. 이 솔루션은 다음 그림에서처럼 두 데이터 센터를 포괄하는 단일 Active Directory 사이트에 중복 서버를 배포합니다.

프로덕션:프로덕션(비전용) 배포 예

프로덕션:프로덕션(비전용) 배포

이 솔루션은 두 데이터 센터의 리소스를 단일 Active Directory 사이트에 배포합니다. 사이트의 모든 리소스는 대부분의 요청을 처리하는 데 사용될 수 있습니다. 예를 들어, 데이터 센터 A의 Edge 전송 서버가 데이터 센터 B의 허브 전송 서버를 사용하여 데이터 센터 A에 호스팅되어 있는 클러스터된 사서함 서버에 사서함이 있는 사용자에게 메시지를 전달할 수 있습니다. 마찬가지로 Active Directory 트래픽에 대한 참조 위치는 기본적으로 없습니다. 따라서 이 솔루션은 사용하지 않는 것이 좋습니다.

백업 데이터 센터를 활성화하는 방법은 여러 서버 오류를 복구하는 방법과 비슷합니다. 활성화에서 복구하려면 오류가 발생한 서버에서 서비스를 복원해야 합니다. 앞에서 설명한 비전용 솔루션에서처럼 잘못된 용량 관리로 인해 데이터 센터 오류 발생 시 부하가 서비스 용량을 초과할 수 있습니다. 관리자는 솔루션이 데이터 센터 오류 발생 이후 예상 부하를 지원할 수 있는지 확인해야 합니다. 적절히 용량을 관리하지 못하면 단일 데이터 센터에서 오류가 발생하는 경우 전체 메시징 서비스가 실패할 수 있습니다.