데이터 센터 전환

  • 아티클

사이트 복구 구성에서 사이트 수준 장애에 대해 진행되는 자동 복구는 DAG 내에서 발생하여 메시징 시스템이 작동 상태를 유지하도록 합니다. 이 구성에서는 DAG 구성원을 2개의 위치에 배포하고 DAG 미러링 모니터 서버를 세 번째 위치에 배포해야 하므로 적어도 3개의 위치가 필요합니다.

3개의 위치가 없거나 3개의 위치가 있지만 데이터 센터 수준 복구 작업을 제어하려는 경우에도 사이트 수준 오류가 발생할 경우 수동 복구를 위해 DAG를 구성할 수 있습니다. 이러한 경우 데이터 센터 전환이라는 프로세스를 수행합니다. 다른 재해 복구 시나리오의 경우와 마찬가지로, 데이터 센터 전환을 사전에 계획하고 준비해 두면 복구 프로세스를 단순화하고 중지 기간을 단축할 수 있습니다.

There are four basic steps that you complete to perform a datacenter switchover, after making the initial decision to activate the second datacenter:

  1. 부분적으로 실행되는 데이터 센터 종료: 이 단계에서는 서비스가 계속 실행 중인 경우 기본 데이터 센터에서 Exchange 서비스를 종료합니다. This is particularly important for the Mailbox server role because it uses an active/passive high availability model. If services in a partially failed datacenter aren't stopped, it's possible for problems from the partially failed datacenter to negatively affect the services during a switchover back to the primary datacenter.

    중요

    If network or Active Directory infrastructure reliability has been compromised as a result of the primary datacenter failure, we recommend that all messaging services be off until these dependencies are restored to healthy service.

  2. 두 번째 데이터 센터의 필수 구성 요소 유효성 검사 및 확인: 두 번째 데이터 센터의 인프라 상태에 대한 유효성 검사는 첫 번째 데이터 센터와 크게 독립적이므로 이 단계를 1단계와 병렬로 수행할 수 있습니다. Each organization typically requires its own method for performing this step. For example, you may decide to complete this step by reviewing health information collected and filtered by an infrastructure monitoring application, or by using a tool that's unique to your organization's infrastructure. 인프라가 비정상이고 불안정할 때 두 번째 데이터 센터를 활성화하지 않으려는 중요한 단계입니다.

  3. 사서함 서버 활성화: 이 단계에서는 두 번째 데이터 센터를 활성화하는 프로세스를 시작합니다. Microsoft Exchange 서비스에서 데이터베이스 중단을 처리하고 복구할 수 있으므로 이 단계는 4단계와 병렬로 수행할 수 있습니다. 사서함 서버를 활성화하려면 주 데이터 센터에서 실패한 서버를 사용할 수 없음으로 표시한 다음 두 번째 데이터 센터에서 서버를 활성화하는 프로세스가 포함됩니다. 사서함 서버의 활성화 프로세스는 DAG가 DAC(데이터베이스 정품 인증 조정) 모드인지 여부에 따라 달라집니다. 자세한 내용은 데이터 센터 활성화 조정 모드 를 참조하세요.

    If the DAG is in DAC mode, you can use the Exchange site resilience cmdlets to terminate a partially failed datacenter (if necessary) and activate the Mailbox servers. For example, in DAC mode, this step is performed by using the Stop-DatabaseAvailabilityGroup cmdlet. In some cases, the servers must be marked as unavailable twice (once in each datacenter). Next, the Restore-DatabaseAvailabilityGroup cmdlet is run to restore the remaining members of the database availability group (DAG) in the second datacenter by reducing the DAG members to those that are still operational, thereby reestablishing quorum. If the DAG isn't in DAC mode, you must use the Windows Failover Cluster tools to activate the Mailbox servers. After either process is complete, the database copies that were previously passive in the second datacenter can become active and be mounted. At this point, Mailbox server recovery is complete.

  4. 클라이언트 액세스 서비스 활성화: URL 매핑 정보 및 DNS(도메인 이름 시스템) 변경 방법론을 사용하여 필요한 모든 DNS 업데이트를 수행합니다. The mapping information describes what DNS changes to perform. The amount of time required to complete the update depends on the methodology used and the Time to Live (TTL) settings on the DNS record (and whether the deployment's infrastructure honors the TTL).

Users should start to have access to messaging services sometime after steps 3 and 4 are completed. Steps 3 and 4 are described in greater detail later in this topic.

Terminating a Partially Failed Datacenter

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

Exchange DAG가 DAC 모드인 경우 단일 명령을 사용하여 실패한 데이터 센터에서 서버를 사용하지 않도록 설정할 수 있습니다. 이렇게 하면 DAG에 쿼럼이 없는 경우에도 다른 데이터 센터에 데이터베이스를 탑재할 수 있습니다(사용 가능한 DAG 멤버의 절반 이상).

When the DAG is in DAC mode, the specific actions to terminate any surviving DAG members in the primary datacenter are as follows:

  1. The DAG members in the primary datacenter must be marked as stopped in the primary datacenter. 중지됨 은 데이터베이스가 탑재되지 않도록 하는 Active Manager 상태이며, 실패한 데이터 센터의 각 서버에서 Active Manager는 Stop-DatabaseAvailabilityGroup cmdlet을 사용하여 이 상태로 전환됩니다. 이 cmdlet의 ActiveDirectorySite 매개 변수를 사용하여 기본 데이터 센터의 모든 서버를 단일 명령으로 중지됨으로 표시할 수 있습니다. This step may not be possible depending on the failure. This step should be taken if the state of the datacenter permits it. The Stop-DatabaseAvailabilityGroup cmdlet should be run against all servers in the primary datacenter. 사서함 서버를 사용할 수 없지만 Active Directory가 기본 데이터 센터에서 작동하는 경우 ConfigurationOnly 매개 변수를 사용하여 Stop-DatabaseAvailabilityGroup 명령을 주 데이터 센터의 이 상태의 모든 서버에 대해 실행해야 합니다. 그렇지 않으면 사서함 서버를 해제해야 합니다. Failure to either turn off the Mailbox servers in the failed datacenter or to successfully perform the Stop-DatabaseAvailabilityGroup command against the servers will create the potential for split-brain syndrome to occur across the two datacenters. You may need to individually turn off computers through power management devices to satisfy this requirement.

  2. The second datacenter must now be updated to represent which primary datacenter servers are stopped. 이 작업은 동일한 ActiveDirectorySite 매개 변수를 사용하여 ConfigurationOnly 매개 변수와 동일한 Stop-DatabaseAvailabilityGroup 명령을 실행하고 실패한 기본 데이터 센터에서 Active Directory 사이트의 이름을 지정하여 수행됩니다. The purpose of this step is to inform the servers in the second datacenter about which mailbox servers are available to use when restoring service.

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

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

    net stop clussvc

    cluster <DAGName> node <DAGMemberName> /forcecleanup

  2. 이제 두 번째 데이터 센터의 DAG 멤버를 다시 시작한 다음 두 번째 데이터 센터에서 제거 프로세스를 완료하는 데 사용해야 합니다. 각 멤버에서 다음 명령을 실행하여 두 번째 데이터 센터의 각 DAG 멤버에서 클러스터 서비스를 중지합니다.

    net stop clussvc

  3. On a DAG member in the second datacenter, force a quorum start of the Cluster service by running the following command:

    net start clussvc /forcequorum

  4. Open the Failover Cluster Management tool and connect to the DAG's underlying cluster. Expand the cluster, and then expand Nodes. Right-click each node in the primary datacenter, select More Actions, and then select Evict. When you're done evicting the DAG members in the primary datacenter, close the Failover Cluster Management tool.

실패한 데이터 센터에서 통합 메시징 서비스를 사용 중인 경우 실패한 데이터 센터에 대한 호출 라우팅을 방지하기 위해 사용하지 않도록 설정해야 합니다. Disable-UMService cmdlet(예Disable-UMService EX1: )을 사용하여 통합 메시징 서비스를 사용하지 않도록 설정할 수 있습니다. 또는 VoIP(Voice over IP) 게이트웨이를 사용하는 경우 VoIP 게이트웨이에서 서버 항목을 제거하거나 VoIP 게이트웨이가 DNS를 사용하여 호출을 라우팅하도록 구성된 경우 두 번째 데이터 센터에서 서버의 IP 주소를 가리키도록 실패한 서버에 대한 DNS 레코드를 변경할 수도 있습니다.

참고

Exchange 2019에서는 통합 메시징을 사용할 수 없습니다.

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

데이터 센터 전환 도중 사서함 서버를 활성화하는 데 필요한 단계는 또한 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) 제한이 전혀 없으면 시스템에서 보조 데이터 센터에 있는 복사본이 정상 상태라고 가정하고 복사본을 활성화합니다. 명시적인 수동 작업이 필요한 활성화 차단 설정을 사용하여 데이터베이스를 구성한 경우에는 두 가지 작업 중 하나를 선택할 수 있습니다.

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

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

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

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

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

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

    cluster <DAGName> /quorum /nodemajority

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

    Set-DatabaseAvailabilityGroup <DAGName> -WitnessServer <ServerName>

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

    net start clussvc

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

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

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

    Get-MailboxDatabase <DAGMemberinSecondSite> | Mount-Database

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

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

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

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

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

  • 시작하거나 다시 시작하는 클라이언트는 시작 시 DNS 조회를 수행하고 두 번째 데이터 센터에서 클라이언트 액세스 서비스를 실행하는 Exchange 서버 또는 클라이언트 액세스 서비스 배열인 서비스 엔드포인트에 대한 새 IP 주소를 가져옵니다.

두 번째 데이터 센터의 서비스가 기본 데이터 센터에 있는 것처럼 작동하도록 정의하고 구성하기 위해 모든 적절한 구성 변경이 완료되었다고 가정하고, 설정된 DNS 구성이 올바르다고 가정할 경우 클라이언트 액세스 서비스를 활성화하기 위해 추가 변경이 필요하지 않습니다.

전송 서비스 활성화

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

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

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

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

Exchange 2016에서 통합 메시징 서비스 활성화

참고

Exchange 2019에서는 통합 메시징을 사용할 수 없습니다.

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

두 번째 데이터 센터에 사이트 복원력 솔루션 전용이므로 비활성화된 상태인 통합 메시징 서비스가 있는 경우 Enable-UMService cmdlet(예 Enable-UMService EX4: )을 사용하여 사용하도록 설정할 수 있습니다.

IP 게이트웨이가 DNS 서버를 통해 통합 메시징 서비스에 연결되어 있는 경우 통합 메시징 서비스를 활성화하는 과정에서 보조 데이터 센터에 있는 통합 메시징 서비스에 구성되는 새 IP 주소를 가리키도록 DNS 레코드를 변경해야 합니다. 보조 데이터 센터가 기본 데이터 센터와 같이 작동하도록 서비스를 정의하고 구성하기 위해 적절한 구성 변경을 모두 완료했으며 설정된 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이 예정에 따라 진행되며 중지 시간이 더 짧은 경우가 많다는 것입니다.

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 절차를 수행할 수 있습니다.

클라이언트 액세스 서비스 전환

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

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

Reestablishing Site Resilience

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