다음을 통해 공유

데이터 센터 전환

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2012-02-14

Microsoft Exchange Server 2010 SP1(서비스 팩 1)의 기본 사이트 복구 기능과 적절한 계획을 결합하면 두 번째 데이터 센터를 빠르게 활성화하여 실패한 데이터 센터의 클라이언트에 서비스를 제공할 수 있습니다. 데이터 센터나 사이트의 오류는 서버 또는 데이터베이스 장애 조치(failover)를 일으킬 수 있는 오류 유형과 다른 방식으로 관리합니다. 고가용성 구성에서는 시스템이 자동 복구를 시작하며 보통은 오류가 발생해도 메시징 시스템이 완전하게 작동하는 상태로 복구됩니다. 반면 데이터 센터 오류는 재해 복구 이벤트로 간주되며 클라이언트 서비스를 복원하여 중지 상태를 해결하려면 수동으로 복구를 수행해야 합니다. 이때 수행하는 프로세스를 데이터 센터 전환이라고 합니다. 다른 재해 복구 시나리오의 경우와 마찬가지로, 데이터 센터 전환을 사전에 계획하고 준비해 두면 복구 프로세스를 단순화하고 중지 기간을 단축할 수 있습니다.

두 번째 데이터 센터를 활성화하기로 처음 결정한 후에 기본적으로 네 단계를 완료하여 데이터 센터 전환을 수행할 수 있습니다.

  1. 부분적으로 실행 중인 데이터 센터 종료   이 단계에서는 아직 실행 중인 서비스가 있는 경우 기본 데이터 센터에서 사서함 및 통합 메시징 서비스를 종료합니다. 사서함 서버 역할의 경우는 액티브/패시브 고가용성 모델을 사용하므로 특히 이 과정이 중요합니다. 부분적으로 실패한 데이터 센터의 서비스를 중지하지 않으면 기본 데이터 센터로 다시 전환할 때 부분적으로 실패한 데이터 센터의 문제로 인해 서비스에 부정적인 영향을 받을 수 있습니다.

    중요

    기본 데이터 센터의 오류로 인해 네트워크 또는 Active Directory 인프라 안정성이 손상된 경우에는 이러한 의존 관계가 정상적인 서비스로 복원될 때까지 모든 메시징 서비스를 꺼 두는 것이 좋습니다.

  2. 보조 데이터 센터의 선행 조건 검사 및 확인   보조 데이터 센터의 상태와 인프라 의존 관계를 검사하는 일은 대체로 기본 데이터 센터 서비스와 독립적으로 수행할 수 있으므로 이 단계는 1단계와 병행할 수 있습니다. 이 단계를 수행하는 방법은 조직마다 다를 수 있습니다. 예를 들어 인프라 모니터링 응용 프로그램에서 수집하여 필터링한 상태 정보를 검토하여 이 단계를 완료할 수도 있고, 조직 인프라에 맞게 제작된 도구를 사용할 수도 있습니다. 보조 데이터 센터의 인프라 상태가 정상적이고 안정적이지 못한 상황에서 활성화하면 좋지 않은 결과가 나올 가능성이 크므로 이 단계가 매우 중요합니다.

  3. 사서함 서버 활성화   이 단계에서 보조 데이터 센터를 활성화하는 프로세스를 시작합니다. Microsoft Exchange 서비스가 데이터베이스 중지 및 복구를 처리할 수 있으므로 이 단계는 4단계와 동시에 수행할 수 있습니다. 사서함 서버를 활성화하는 과정에서 보조 데이터 센터에서 서버를 활성화한 후에 기본 데이터 센터에서 실패한 서버를 사용할 수 없는 상태로 표시해야 합니다. 사서함 서버에 대한 활성화 프로세스는 DAG가 DAC(데이터베이스 활성화 조정) 모드에 있는지 여부에 따라 달라집니다. 데이터베이스 활성화 조정 모드에 대한 자세한 내용은 데이터 센터 활성화 조정 모드 이해를 참조하십시오.

    DAG가 DAC 모드에 있는 경우 Exchange 사이트 복구 cmdlet을 사용하여 부분적으로 실패한 데이터 센터를 종료하고(필요한 경우) 사서함 서버를 활성화할 수 있습니다. 예를 들어 DAC 모드에서 이 단계는 Stop-DatabaseAvailabilityGroup cmdlet을 사용하여 수행합니다. 경우에 따라서는 각 데이터 센터별로 두 번에 걸쳐 서버를 사용할 수 없는 것으로 표시해야 합니다. 다음으로는 Restore-DatabaseAvailabilityGroup cmdlet을 실행하여 DAG(데이터베이스 가용성 그룹) 구성원을 아직 작동하는 것으로 제한하여 쿼럼을 다시 설정하는 방법으로 보조 데이터 센터의 나머지 DAG 구성원을 복원합니다. DAG가 DAC 모드에 없는 경우 Windows 장애 조치(Failover) 클러스터 도구를 사용하여 사서함 서버를 활성화해야 합니다. 두 프로세스 중 하나가 완료된 후 이전에 보조 데이터 센터에서 수동 상태였던 데이터베이스 복사본은 활성 상태가 되고 탑재될 수 있습니다. 이 때 사서함 서버 복구가 완료됩니다.

  4. 다른 서버 역할 활성화   URL 매핑 정보와 DNS 변경 방법을 사용하여 필요한 DNS(Domain Name System) 업데이트를 모두 수행하는 과정입니다. 매핑 정보는 수행해야 할 DNS 변경을 설명합니다. 업데이트를 완료하는 데 필요한 시간은 사용된 방법과 DNS 레코드의 TTL(Time to Live) 설정, 배포 인프라의 TTL 적용 여부 등에 따라 달라집니다.

3단계와 4단계를 완료한 후에 사용자가 메시징 서비스를 시작하여 액세스해야 합니다. 3단계와 4단계에 대한 자세한 내용은 이 항목의 뒷부분에서 설명합니다.

고가용성 및 사이트 복구와 관련된 관리 작업에 대한 자세한 내용은 고가용성 및 사이트 복구 관리를 참조하십시오.

목차

부분적으로 실패한 데이터 센터 종료

사서함 서버 활성화

다른 서버 역할 활성화

기본 데이터 센터로 서비스 복원

사이트 복구 다시 설정

부분적으로 실패한 데이터 센터 종료

실패한 데이터 센터에서 아직 실행 중인 DAG 구성원이 있는 경우에는 종료해야 합니다.

DAG가 DAC 모드에 있는 경우 기본 데이터 센터에서 남아 있는 DAG 구성원을 종료하기 위한 특정 작업은 다음과 같습니다.

  1. 기본 데이터 센터에서 기본 데이터 센터의 DAG 구성원을 중지됨으로 표시해야 합니다. 중지됨은 데이터베이스 탑재를 방지하는 Active Manager 상태이며 실패한 데이터 센터에 있는 각 서버의 Active Manager는 Stop-DatabaseAvailabilityGroup cmdlet을 사용하여 중지됨 상태로 만들어야 합니다. 이 cmdlet의 ActiveDirectorySite 매개 변수를 사용하면 한 명령으로 기본 데이터 센터에 있는 모든 서버를 중지됨으로 표시할 수 있습니다. 오류에 따라서는 이 단계를 수행하지 못할 수도 있습니다. 데이터 센터 상태에 따라 가능한 경우에는 이 단계를 수행해야 합니다. 기본 데이터 센터에서 모든 서버에 대해 Stop-DatabaseAvailabilityGroup cmdlet을 실행해야 합니다. 사서함 서버를 사용할 수 없지만 기본 데이터 센터에서 Active Directory가 작동하고 있는 경우에는 기본 데이터 센터에서 이 상태에 있는 모든 서버에 대해 Stop-DatabaseAvailabilityGroup 명령(ConfigurationOnly 매개 변수 적용)을 실행하거나 사서함 서버를 꺼 두어야 합니다. 실패한 데이터 센터의 사서함 서버를 끄거나 서버에 대해 Stop-DatabaseAvailabilityGroup 명령을 성공적으로 실행하는 과정을 완수하지 못한 경우에는 두 데이터 센터 사이가 손발이 맞지 않는 증상이 나타날 수 있습니다. 이 요구 사항에 따라 전원 관리 장치를 통해 개별적으로 컴퓨터 전원을 꺼야 할 수도 있습니다.

  2. 이제 중지된 기본 데이터 센터가 표시되도록 보조 데이터 센터를 업데이트해야 합니다. 이 과정을 수행하려면 같은 Stop-DatabaseAvailabilityGroup 명령을 실행하며 ConfigurationOnly 매개 변수(같은 ActiveDirectorySite 매개 변수 사용)를 사용하고 실패한 기본 데이터 센터에 Active Directory 사이트 이름을 지정합니다. 이 단계의 목적은 서비스 복원에 사용할 수 있는 사서함 서버를 보조 데이터 센터의 서버에 알리는 것입니다.

DAG가 DAC 모드에 없는 경우 기본 데이터 센터에서 남아 있는 DAG 구성원을 종료하기 위한 특정 작업은 다음과 같습니다.

  1. 각 구성원에서 다음 명령을 실행하여 기본 데이터 센터의 DAG 구성원을 DAG의 기본 클러스터에서 강제로 제거해야 합니다.

    net stop clussvc
cluster <DAGName> node <DAGMemberName> /forcecleanup

  2. 보조 데이터 센터의 DAG 구성원은 이제 다시 시작된 다음 보조 데이터 센터에서의 제거 프로세스를 완료하는 데 사용됩니다. 각 구성원에서 다음 명령을 실행하여 보조 데이터 센터의 각 DAG 구성원에서 클러스터 서비스를 중지합니다.

    net stop clussvc

  3. 보조 데이터 센터의 DAG 구성원에서 다음 명령을 실행하여 클러스터 서비스의 쿼럼을 강제로 시작합니다.

    net start clussvc /forcequorum

  4. 장애 조치 클러스터 관리 도구를 열고 DAG의 기본 클러스터에 연결합니다. 클러스터를 확장한 다음 노드를 확장합니다. 기본 데이터 센터의 각 노드를 마우스 오른쪽 단추로 클릭하고 기타 작업을 선택한 다음 제거를 선택합니다. 기본 데이터 센터에서 DAG 구성원 제거가 완료되면 장애 조치 클러스터 관리 도구를 닫습니다.

실패한 데이터 센터에서 통합 메시징 서버를 사용 중인 경우에는 실패한 데이터 센터로 통화가 라우트되는 일을 방지하려면 통합 메시징을 사용하지 않도록 설정해야 합니다. Disable-UMServer cmdlet(예: Disable-UMServer UM01)을 사용하면 통합 메시징 서버를 사용하지 않도록 설정할 수 있습니다. 또는 VoIP(Voice over IP) 게이트웨이를 사용하는 경우에는 VoIP 게이트웨이에서 통합 메시징 서버 항목을 제거하거나, VoIP 게이트웨이가 DNS를 사용하여 통화를 라우트하도록 구성되어 있으면 실패한 서버의 DNS 레코드가 통합 메시징 서버의 IP 주소를 가리키도록 변경할 수 있습니다.

부분적으로 실패한 데이터 센터 종료

사서함 서버 활성화

데이터 센터 전환 도중 사서함 서버를 활성화하는 데 필요한 단계는 또한 DAG가 DAC 모드에 있는지 여부에 따라 달라집니다. 보조 데이터 센터에서 DAG 구성원을 활성화하기 전에 보조 데이터 센터에 있는 인프라 서비스에서 메시징 서비스 활성화가 준비되었는지 확인하는 것이 좋습니다.

DAG가 DAC 모드에 있는 경우 보조 데이터 센터에서 사서함 서버 활성화를 완료하는 단계는 다음과 같습니다.

  1. 보조 데이터 센터에 있는 각 DAG 구성원에서 클러스터 서비스를 중지해야 합니다. Stop-Service cmdlet을 사용하여 서비스를 중지하거나(예: Stop-Service ClusSvc) 관리자 권한 명령 프롬프트에서 net stop clussvc를 사용할 수 있습니다.

  2. 그런 다음 Restore-DatabaseAvailabilityGroup cmdlet을 사용하여 대기 데이터 센터의 사서함 서버를 활성화합니다. 서비스 복원에 사용할 서버를 식별하고 대체 미러링 모니터 서버를 사용할 수 있도록 DAG를 구성하기 위해 대기 데이터 센터의 Active Directory 사이트가 Restore-DatabaseAvailabilityGroup cmdlet으로 전달됩니다. 이전에 대체 미러링 모니터 서버를 구성하지 않은 경우 Restore-DatabaseAvailabilityGroup cmdlet의 AlternateWitnessServer 및 AlternateWitnessDirectory 매개 변수를 사용하여 구성할 수 있습니다. 이 명령이 성공하면 쿼럼 조건이 대기 데이터 센터에 있는 서버로 축소됩니다. 데이터 센터에 있는 서버의 수가 짝수인 경우 DAG는 DAG 개체의 설정을 통해 식별된 대체 미러링 모니터 서버를 사용하도록 전환됩니다.

  3. 이제 데이터베이스를 활성화할 수 있습니다. 조직에서 사용하는 구성에 따라 이 과정이 자동으로 수행되지 않을 수도 있습니다. 대기 데이터 센터에 있는 서버에 활성화 차단 설정이 있는 경우 시스템은 기본 데이터 센터에서 어느 데이터베이스의 대기 데이터 센터로도 자동으로 장애 조치(failover)를 수행하지 않습니다. 대기 데이터 센터에 있는 데이터베이스 복사본에 적용되는 장애 조치(failover) 제한이 전혀 없으면 시스템에서 보조 데이터 센터에 있는 복사본이 정상 상태라고 가정하고 복사본을 활성화합니다. 명시적인 수동 작업이 필요한 활성화 차단 설정을 사용하여 데이터베이스를 구성한 경우에는 두 가지 작업 중 하나를 선택할 수 있습니다.

    1. 활성화를 차단하는 설정을 취소합니다. 그러면 시스템은 사용 가능한 복사본을 활성화하는 기본 동작으로 돌아갑니다.

    2. 설정은 변경하지 않고 Move-ActiveMailboxDatabase cmdlet을 사용하여 보조 데이터 센터에서 데이터베이스 활성화를 완료합니다. 활성화 차단이 설정되어 있을 경우 Move-ActiveMailboxDatabase cmdlet을 사용하여 이 단계를 완료하려면 이동 대상을 명시적으로 식별해야 합니다.

  4. 마지막 단계는 작업에서 모든 오류 및 경고 메시지를 검토하는 것입니다. 표시된 경고에 모두 따르고 올바르게 수정해야 합니다. 이러한 명령의 작업 디자인 모델은 기본적인 디자인 목적을 달성할 수 없는 경우에만 실패하도록 되어 있습니다. 예를 들어 Restore-DatabaseAvailabilityGroup cmdlet은 쿼럼이 중지되지 않고 보조 데이터 센터에서 서버를 다시 시작하여 서비스하도록 DAG 쿼럼을 축소할 수 없는 경우에 실패합니다. 하지만 각 작업의 출력 역시 관리자의 추가 작업이 필요한 문제를 식별하는 일에 사용됩니다. 가능한 한 모든 작업 출력을 저장해 두었다가 추가 작업 여부를 검토하는 것이 좋습니다.

DAG가 DAC 모드에 없는 경우 보조 데이터 센터에서 사서함 서버 활성화를 완료하는 단계는 다음과 같습니다.

  1. 보조 데이터 센터에 있는 DAG 구성원 수에 기초하여 쿼럼을 수정해야 합니다.

    1. DAG 구성원 수가 홀수인 경우 다음 명령을 실행하여 DAG 쿼럼 모델을 노드 및 파일 공유 과반수에서 노드 과반수 쿼럼으로 변경합니다.

      cluster <DAGName> /quorum /nodemajority

    2. DAG 구성원 수가 짝수인 경우 Exchange 관리 셸에서 다음 명령을 실행하여 미러링 모니터 서버 및 디렉터리를 다시 구성합니다.

      Set-DatabaseAvailabilityGroup <DAGName> -WitnessServer <ServerName>

  2. 다음 명령을 실행하여 보조 데이터 센터의 나머지 DAG 구성원에서 클러스터 서비스를 시작합니다.

    net start clussvc

  3. 각 DAG 구성원에 대해 다음 명령을 실행하여 DAG에서 사서함 데이터베이스를 활성화하기 위한 서버 전환을 수행합니다.

    Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>

  4. 다음 명령을 실행하여 보조 사이트의 각 DAG 구성원에서 사서함 데이터베이스를 탑재합니다.

    Get-MailboxDatabase <DAGMemberinSecondSite> | Mount-Database

  5. 공용 폴더 데이터베이스는 연속 복제를 사용하는 대신 고가용성을 위해 공용 폴더 복제에 의존하기 때문에, 데이터 센터 전환 후 공용 폴더 데이터베이스에 다시 연결하는 Outlook 클라이언트의 동작은 사이트 복원력과 관련된 공용 폴더 아키텍처와 해당 공용 폴더 데이터베이스의 상태 및 업데이트 여부에 따라 달라집니다. Outlook 클라이언트의 공용 폴더 연결을 재설정하려면 간단하게 사서함 데이터베이스에 대한 기본 공용 폴더를 변경하여 두 번째 사이트의 공용 폴더 데이터베이스를 가리키도록 하면 됩니다. 사서함 데이터베이스에 대한 기본 공용 폴더 데이터베이스를 변경하는 방법에 대한 자세한 단계는 사서함 데이터베이스의 기본 공용 폴더 데이터베이스 변경을 참조하십시오.

부분적으로 실패한 데이터 센터 종료

다른 서버 역할 활성화

비사서함 서버 역할을 활성화하는 데 필요한 단계는 서버와 구성에 따라 결정됩니다. 각 서버 역할의 활성화 프로세스에 대한 자세한 내용은 다음 섹션에서 설명합니다.

클라이언트 액세스 서버 활성화

클라이언트는 서비스 끝점(예: Outlook Web App, 자동 검색, Exchange ActiveSync, Outlook Anywhere, POP3, IMAP4 및 RPC 클라이언트 액세스 배열)에 연결하여 Exchange 서비스 및 데이터에 액세스합니다. 따라서 클라이언트 액세스 서버를 활성화하려면 이러한 서비스 끝점에 대한 DNS 레코드의 매핑을 기본 데이터 센터의 IP 주소에서 새 서비스 끝점으로 구성된 보조 데이터 센터의 IP 주소로 변경해야 합니다. DNS 구성에 따라 수정해야 하는 DNS 레코드가 동일한 DNS 영역에 있거나 없을 수 있습니다.

그러면 클라이언트는 두 가지 방법 중 하나를 통해 새 서비스 끝점에 자동으로 연결합니다.

  • 클라이언트는 계속 연결을 시도하며 원래 DNS 항목에 대해 TTL이 만료되고 그 항목이 클라이언트의 DNS 캐시에서 만료된 후에 자동으로 연결되어야 합니다. 사용자가 명령 프롬프트에서 ipconfig /flushdns 명령을 실행하여 수동으로 DNS 캐시를 지울 수도 있습니다.

  • 시작하거나 다시 시작하는 클라이언트는 시작 중에 DNS 조회를 수행하여 클라이언트 액세스 서버나 보조 데이터 센터의 배열에 해당하는 서비스 끝점의 새 IP 주소를 가져옵니다.

보조 데이터 센터가 기본 데이터 센터와 같이 작동하도록 서비스를 정의 및 구성하기 위해 적절한 구성 변경을 모두 완료했으며 설정된 DNS 구성이 올바른 경우에는 더 이상 변경을 수행하지 않아도 클라이언트 액세스 서버를 활성화할 수 있습니다.

허브 전송 서버 활성화

클라이언트와 허브 전송 서버에 메시지를 제출하는 다른 서버는 일반적으로 DNS를 사용하여 서버를 식별합니다. 허브 전송 서버를 활성화하는 과정에서 보조 데이터 센터에 있는 허브 전송 서버의 IP 주소를 가리키도록 DNS 레코드를 변경해야 합니다. 그러면 클라이언트와 보내는 서버가 다음 두 가지 방법 중 하나를 통해 보조 데이터 센터의 허브 전송 서버에 자동으로 연결합니다.

  • 클라이언트는 계속 연결을 시도하며 원래 DNS 항목에 대해 TTL이 만료되고 그 항목이 클라이언트의 DNS 캐시에서 만료된 후에 자동으로 연결되어야 합니다. 사용자가 명령 프롬프트에서 ipconfig /flushdns 명령을 실행하여 수동으로 DNS 캐시를 지울 수도 있습니다.

  • 시작하거나 다시 시작하는 클라이언트는 시작 중에 DNS 조회를 수행하여 보조 데이터 센터의 허브 전송 서버에 해당하는 SMTP 끝점의 새 IP 주소를 가져옵니다.

보조 데이터 센터가 기본 데이터 센터와 같이 작동하도록 서비스를 정의 및 구성하기 위해 적절한 구성 변경을 모두 완료했으며 설정된 DNS 구성이 올바른 경우에는 더 이상 변경을 수행하지 않아도 허브 전송 서버를 활성화할 수 있습니다.

통합 메시징 서버 활성화

UM(통합 메시징) 서버는 조직의 PBX 시스템 및 전화선에 연결됩니다. PBX 시스템과 통합 메시징 서버 사이의 논리적인 연결은 IP 게이트웨이를 통해 제공됩니다. IP 게이트웨이는 고가용성 기능을 포함하며 오류가 검색될 경우 여러 통합 메시징 서버 사이를 전환할 수 있습니다.

사이트 복구 솔루션 전용으로 배정되어 사용할 수 없는 상태에 있었던 보조 데이터 센터에 통합 메시징 서버가 있는 경우에는 Enable-UMServer cmdlet을 통해 사용하도록 설정할 수 있습니다(예: Enable-UMServer UM04).

IP 게이트웨이가 DNS 서버를 통해 통합 메시징 서버에 연결되어 있는 경우 통합 메시징 서버를 활성화하는 과정에서 보조 데이터 센터에 있는 통합 메시징 서버에 구성되는 새 IP 주소를 가리키도록 DNS 레코드를 변경해야 합니다. TTL 및 DNS 캐시 항목이 만료되면 클라이언트 및 IP 게이트웨이를 Microsoft Exchange 통합 메시징 서비스에 연결할 수 없습니다. 보조 데이터 센터가 기본 데이터 센터와 같이 작동하도록 서비스를 정의 및 구성하기 위해 적절한 구성 변경을 모두 완료했으며 설정된 DNS 구성이 올바른 경우에는 더 이상 변경을 수행하지 않아도 통합 메시징 서버를 활성화할 수 있습니다.

사용 중인 IP 게이트웨이가 DNS 이름을 사용한 통합 메시징 서버 확인을 지원하지 않는 경우에는 추가 구성 단계를 수행하여 IP 게이트웨이가 보조 데이터 센터의 통합 메시징 서버의 IP 주소를 가리키도록 수동으로 설정해야 합니다.

Edge 전송 서버 활성화

Edge 전송 서버를 활성화하는 단계는 구성에 따라 다릅니다. 두 데이터 센터에 있는 Edge 전송 서버는 액티브/패시브 또는 액티브/액티브로 구성할 수 있습니다. 액티브/패시브 구성에서 보조 데이터 센터에 있는 Edge 전송 서버는 보조 데이터 센터가 활성화될 때까지 유휴 상태입니다. 액티브/액티브 구성에서는 두 데이터 센터 모두의 Edge 전송 서버가 항상 메일을 배달합니다.

액티브/액티브 구성에서는 보조 데이터 센터의 Edge 전송 서버가 이미 실행 중이므로 활성화 단계가 필요 없습니다. 액티브/패시브 구성에서는 전환 과정을 통해 각 SMTP 도메인의 DNS MX 리소스 레코드를 기본 데이터 센터에서 대기 데이터 센터로 업데이트해야 합니다. 액티브/액티브 구성의 데이터 센터 전환 솔루션이 더 간단하기는 하지만 데이터 센터 전환이 일어난 후에 주의 깊게 부하를 모니터링하며 기본 데이터 센터의 Edge 전송 서버를 사용할 수 없게 되어 늘어난 부하를 보조 데이터 센터의 Edge 전송 서버가 충분히 지원할 수 있는지 확인해야 한다는 단점이 있습니다.

액티브/액티브 구성을 사용하는 경우라도 데이터 센터를 전환하는 동안 Edge 전송 서버의 MX 리소스 레코드를 업데이트하는 것이 좋을 수 있습니다. 실패한 데이터 센터의 MX 리소스 레코드가 계속 실패한 데이터 센터를 가리킬 경우에는 데이터 센터가 복구를 시작할 때 Edge 전송 서버로 연결을 시도할 수도 있습니다. Edge 전송 서비스가 불안정한 상태에 있으면(예: 데이터 센터에 있는 종속 서비스 복원) 이 문제가 발생할 수 있습니다.

DNS 레코드를 조직에서 제어하는 경우 Edge 전송 서버를 활성화하는 작업을 통해 서버에서 호스트하는 각 SMTP 도메인의 MX 리소스 레코드를 업데이트해야 합니다.

참고

조직에서 사용하는 MX 리소스 레코드가 조직에서 제어하는 DNS 서버에서 호스트되지 않는 경우에는 MX 레코드에 CNAME 레코드를 참조하고 조직에서 제어하며 업데이트가 가능한 CNAME을 사용할 수도 있습니다.

DNS 업데이트를 통해서는 들어오는 트래픽을 사용할 수 있게 되며 나가는 트래픽은 Edge 전송 서버를 작동하는 사이트의 사서함 데이터베이스를 활성화하여 처리합니다.

  • 업데이트된 이름 확인 정보로 들어오는 SMTP 연결을 시작하면 SMTP 클라이언트가 보조 데이터 센터의 Edge 전송 서버에 연결됩니다. 트래픽은 Edge 전송 서버에서 적절하게 라우트되며 더 이상 변경이 필요 없습니다.

  • 나가는 SMTP 연결을 시작하면 로컬에서 사용할 수 있는 Edge 전송 서버로 연결을 시도하며 받는 서버의 상태에 따라 메시지가 큐에 들어가거나 즉시 송신됩니다.

부분적으로 실패한 데이터 센터 종료

기본 데이터 센터로 서비스 복원

일반적으로 데이터 센터 오류는 일시적이거나 영구적입니다. 기본 데이터 서버가 영구적으로 실패하는 등의 영구적인 오류가 발생한 경우에는 기본 데이터 센터가 활성화될 것을 기대할 수가 없습니다. 하지만 일시적인 오류(예: 오래 지속되는 정전이나 심각하지만 복구 가능한 손상)의 경우에는 기본 데이터 서버가 완전히 서비스를 복원할 것을 기대할 수 있습니다.

이전에 실패한 데이터 센터로 서비스를 복원하는 프로세스를 switchback이라고 합니다. 데이터 센터 switchback을 수행하는 단계는 데이터 센터 전환을 수행하는 단계와 비슷합니다. 가장 큰 차이는 데이터 센터 switchback이 예정에 따라 진행되며 중지 시간이 더 짧은 경우가 많다는 것입니다.

Exchange의 인프라 의존 관계가 다시 활성화되고, 안정적으로 작동하며, 유효성 검사를 마친 후에 switchback을 수행해야 합니다. 이러한 의존 관계가 사용할 수 없거나 정상 상태가 아닌 경우에는 switchback 프로세스로 인한 중지 시간이 길어질 수 있으며 프로세스 전체가 실패할 수도 있습니다.

사서함 서버 역할 Switchback

사서함 서버 역할은 기본 데이터 센터로 가장 먼저 switchback되는 역할입니다. 다음 단계에서는 사서함 서버 역할 switchback 프로세스에 대해 자세히 설명합니다.

  1. 기본 데이터 센터의 사서함 서버가 데이터 센터 전환 프로세스 중에 중지됨 상태에 들어갔습니다. 기본 데이터 센터, Exchange 의존 관계, WAN(광역 네트워크) 등의 환경이 준비된 후에 처음으로 수행할 단계는 복원된 기본 데이터 센터의 사서함 서버를 시작된 상태로 놓고 DAG에 통합하는 것입니다. 이 작업을 수행하는 방법은 DAG가 DAC 모드에 있는지 여부에 따라 달라집니다.

    1. DAG가 DAC 모드에 있는 경우 Start-DatabaseAvailabilityGroup cmdlet을 사용하여 DAG 구성원을 기본 사이트에서 다시 통합할 수 있습니다. 그런 다음 DAG에서 적절한 쿼럼 모델을 사용하고 있는지 확인하기 위해 매개 변수를 지정하지 않고 DAG에 대해 Set-DatabaseAvailabilityGroup cmdlet을 실행합니다.

    2. DAG가 DAC 모드에 없는 경우 Add-DatabaseAvailabilityGroupServer cmdlet을 사용하여 DAG 구성원을 다시 통합할 수 있습니다.

  2. 기본 데이터 센터에 있는 사서함 서버를 DAG에 통합한 후에 데이터베이스 복사본을 동기화하는 데 시간이 좀 필요합니다. 오류의 성격, 중지 시간의 길이, 중지 시간 중에 관리자가 수행한 작업 등에 따라 데이터베이스 복사본을 다시 시드해야 할 수도 있습니다. 예를 들어 중지 시간 중에 보조 데이터 센터에 남은 활성 복사본에서 로그 파일 자르기를 수행할 수 있도록 실패한 기본 데이터 센터에서 데이터베이스 복사본을 제거한 경우에는 다시 시드하는 과정이 필요합니다. 지금부터는 각 데이터베이스 작업을 개별적으로 진행할 수 있습니다. 기본 데이터 센터의 복제된 데이터베이스 복사본이 정상 상태인 경우에는 다음 단계로 진행할 수 있습니다.

    참고

    이 프로세스에서 모든 데이터베이스를 통시에 이동할 필요는 없습니다. 조직에 있는 대부분의 데이터베이스를 한꺼번에 이동하는 것이 좋지만 기본 데이터 센터의 데이터베이스 복사본과 관련된 문제가 있는 경우에는 보조 데이터 센터에 일부 데이터베이스가 조금 더 오래 남을 수도 있습니다.

  3. 대부분의 데이터베이스가 기본 데이터 센터에서 정상 상태를 찾고 나면 switchback 중지 일정을 계획할 수 있습니다. 예정된 시간이 되면 다음 단계를 수행해야 합니다.

    1. 데이터 센터 전환 프로세스 중에 DAG는 대체 미러링 모니터 서버를 사용하도록 구성되었습니다. DAG는 기본 데이터 센터에 있는 미러링 모니터 서버를 사용하도록 다시 구성해야 합니다. 기본 데이터 센터가 중지되기 전에 사용한 것과 같은 미러링 모니터 서버 및 감시 디렉터리를 사용하는 경우에는 Set-DatabaseAvailabilityGroup -Identity DAGName 명령을 실행할 수 있습니다. 원래 미러링 모니터 서버 및 디렉터리와 다른 미러링 모니터 서버 또는 미러링 모니터 디렉터리를 사용하려는 경우 Set-DatabaseAvailabilityGroup 명령을 실행하여 적절한 값으로 미러링 모니터 서버 및 미러링 모니터 디렉터리 매개 변수를 구성합니다.

    2. 기본 데이터 센터에서 다시 활성화할 데이터베이스는 보조 데이터 센터에서 분리해야 합니다. Dismount-Database cmdlet을 사용하여 데이터베이스를 분리할 수 있습니다.

    3. 데이터베이스를 분리한 후에는 보조 데이터 센터에서 기본 데이터 센터로 클라이언트 액세스 서버 URL을 이동해야 합니다. 이 작업에서는 URL의 DNS 레코드가 클라이언트 서버나 기본 데이터 센터에 있는 배열을 가리키도록 변경합니다. 그러면 시스템은 이동하는 각 데이터베이스에 대해 데이터베이스 장애 복구(failback)를 실행한 것처럼 작동합니다.

      중요

      클라이언트 액세스 서버 URL이 이동하고 DNS TTL 및 캐시 항목이 만료될 때까지는 다음 단계를 진행하지 마십시오. 클라이언트 액세스 서버 URL을 기본 데이터 센터로 이동하기 전에 기본 데이터 센터에서 데이터베이스를 활성화하면 구성이 잘못될 수 있습니다(예: 탑재된 데이터베이스의 Active Directory 사이트에 클라이언트 액세스 서버가 없는 경우).

    4. 기본 데이터 센터에 있는 각 데이터베이스가 정상 상태이므로 데이터베이스 전환을 수행하여 기본 데이터 센터에서 활성화할 수 있습니다. 이 작업을 수행하려면 활성화할 각 데이터베이스에 대해 Move-ActiveMailboxDatabase cmdlet을 사용합니다.

    5. 각 데이터베이스를 기본 데이터 센터로 이동하고 나면 Mount-Database cmdlet을 사용하여 탑재할 수 있습니다.

기본 데이터 센터에서 데이터베이스를 하나 이상 활성화하여 탑재하고 나면 다른 서버 역할에 대해 switchback 절차를 수행할 수 있습니다.

다른 서버 역할 Switchback

클라이언트, 다른 서버 및 IP 게이트웨이에서 클라이언트 액세스, 허브 전송, Edge 전송 및 통합 메시징 서버의 서비스 끝점을 확인할 때 사용하는 내부 및 외부 DNS 레코드는 전환 프로세스를 거치면서 보조 데이터 센터의 해당 끝점을 가리키도록 수정되었습니다. 다른 서버 역할에 대한 switchback 프로세스를 수행하는 동안 이러한 레코드가 기본 데이터 센터의 복원된 서비스 끝점을 가리키도록 수정해야 합니다.

보조 데이터 센터로 전환하는 동안 이루어지는 DNS 변경과 마찬가지로 클라이언트, 서버 및 IP 게이트웨이는 계속 연결을 시도하며 원래 DNS 항목의 TTL이 만료되고 DNS 캐시에서 그 항목이 만료된 후에 자동으로 연결되어야 합니다.

사이트 복구 다시 설정

기본 데이터 센터로 완전히 switchback된 후에 보조 데이터 센터에 있는 각 사서함 데이터베이스 복사본의 상태와 정상 여부를 확인하여 기본 데이터 센터의 사이트 복구 능력을 다시 설정할 수 있습니다. 또한 보조 데이터 센터의 데이터베이스 복사본 중에서 원래 활성화를 위해 차단된 것이 있는 경우에는 지금 그러한 설정을 다시 구성할 수 있습니다.

부분적으로 실패한 데이터 센터 종료

 © 2010 Microsoft Corporation. 모든 권리 보유.