고가용성 및 사이트 복구

아티클
04/04/2023

적용 대상: Exchange Server 2013

사서함 서버 및 데이터베이스를 고가용성과 사이트 복구를 위해 구성하여 Exchange Server 2013 사서함 데이터베이스 및 포함된 데이터를 보호할 수 있습니다. Exchange 2013은 높은 수준의 서비스 및 데이터 가용성과 대용량 사서함 지원을 제공하면서 가용성이 뛰어난 복구 가능 메시징 솔루션을 배포할 때 수반되는 비용과 복잡성을 최소화합니다.

Exchange 2013에서는 규모나 업종에 관계없이 모든 고객이 Exchange 2010에 포함된 기본 복제 기능 및 고가용성 아키텍처를 기반으로 하여 조직의 메시징 연속성 서비스를 경제적으로 배포할 수 있습니다. Exchange 2010 및 Exchange 2007에서 달라진 변경 내용 목록은 이전 버전에 비해 달라진 고가용성 및 사이트 복구 기능를 참조하세요.

주요 용어

고가용성 또는 사이트 복구 기능을 이해하려면 다음의 주요 용어를 알고 있어야 합니다.

Active Manager: DAG(데이터베이스 가용성 그룹) 내에서 장애 조치(failover)를 통해 오류 모니터링 및 수정 작업을 담당하는 Microsoft Exchange 복제 서비스 내에서 실행되는 내부 Exchange 구성 요소입니다.
AutoDatabaseMountDial: 탑재 중인 복사본에서 누락된 로그 파일 수에 따라 수동 데이터베이스 복사본이 새 활성 복사본으로 자동으로 탑재되는지 여부를 결정하는 사서함 서버의 속성 설정입니다.
연속 복제 - 블록 모드: 블록 모드에서는 각 업데이트가 활성 데이터베이스 복사본의 활성 로그 버퍼에 기록되므로 블록 모드의 각 수동 사서함 복사본에 대한 로그 버퍼로도 제공됩니다. 로그 버퍼가 꽉 차면 각 데이터베이스 복사본이 다음 로그 파일을 작성 및 검사하며 생성 시퀀스에 만듭니다.
연속 복제 - 파일 모드: 파일 모드에서 닫힌 트랜잭션 로그 파일은 활성 데이터베이스 복사본에서 하나 이상의 수동 데이터베이스 복사본으로 푸시됩니다.
데이터베이스 가용성 그룹: 복제된 데이터베이스 집합을 호스팅하는 최대 16개의 Exchange 2013 사서함 서버 그룹입니다.
데이터베이스 이동성: Exchange 2013 사서함 데이터베이스를 다른 Exchange 2013 사서함 서버에 복제하고 탑재할 수 있는 기능입니다.
데이터 센터: 일반적으로 Active Directory 사이트를 참조합니다. 그러나 물리적 사이트를 참조할 수도 있습니다. 이 설명서의 문맥에서 데이터 센터는 Active Directory 사이트와 같은 의미입니다.
데이터 센터 활성화 조정 모드: DAG 설정의 속성으로, 사용하도록 설정하면 Microsoft Exchange 복제 서비스가 시작 시 데이터베이스를 탑재할 수 있는 권한을 획득하도록 합니다.
재해 복구: 오류에서 수동으로 복구하는 데 사용되는 모든 프로세스입니다. 단일 항목에 영향을 주는 오류 또는 전체 물리적 위치에 영향을 주는 오류일 수 있습니다.
Exchange 타사 복제 API: 지속적인 복제 대신 DAG에 타사 동기 복제를 사용할 수 있도록 하는 Exchange 제공 API입니다.
고가용성: 서비스 또는 데이터에 영향을 주는 오류(예: 네트워크, 스토리지 또는 서버 오류)에서 서비스 가용성, 데이터 가용성 및 자동 복구를 제공하는 솔루션입니다.
증분 배포: Exchange 2013이 설치된 후 고가용성 및 사이트 복원력을 배포하는 기능입니다.
지연된 사서함 데이터베이스 복사본: 로그 재생 지연 시간이 0보다 큰 수동 사서함 데이터베이스 복사본입니다.
사서함 데이터베이스 복사본: 활성 또는 수동 사서함 데이터베이스(.edb 파일 및 로그)입니다.
사서함 복원력: Exchange 2013의 통합 고가용성 및 사이트 복원력 솔루션의 이름입니다.
관리되는 가용성: 모든 서버 역할 및 모든 프로토콜에서 모니터링 및 고가용성을 통합하는 프로브, 모니터 및 응답자로 구성된 내부 프로세스 집합입니다.
*over ("star over"로 발음): 전환 및 장애 조치(failover) 의 경우 짧 습니다. 전환은 하나 이상의 데이터베이스 복사본에 대한 수동 활성화입니다. 장애 조치는 오류 후 하나 이상의 데이터베이스 복사본에 대한 자동 활성화입니다.
안전망: 이전의 전송 쓰레기통으로 알려진 이 기능은 X 일 동안 모든 메시지의 복사본을 저장하는 전송 서비스의 기능입니다. 기본 설정은 2일입니다.
섀도 중복성: 전송 중인 전체 시간 동안 메시지에 대한 중복성을 제공하는 전송 서버 기능입니다.
사이트 복원력: 메시지 인프라를 여러 Active Directory 사이트로 확장하여 사이트 중 하나에 영향을 주는 오류가 발생할 경우 메시징 시스템에 대한 운영 연속성을 제공하는 구성입니다.

데이터베이스 가용성 그룹

DAG는 Exchange 2013에서 기본 제공되는 고가용성 및 사이트 복구의 기본 구성 요소입니다. DAG는 데이터베이스 집합을 호스트하는 최대 16개의 사서함 서버를 포함하는 그룹으로, 개별 데이터베이스, 네트워크 또는 서버에 영향을 주는 오류가 발생할 경우 데이터베이스 수준에서 자동으로 복구할 수 있도록 합니다. DAG의 서버는 DAG의 다른 서버로부터 사서함 데이터베이스의 복사본을 호스트할 수 있습니다. 서버를 DAG에 추가하면 DAG의 다른 서버와 함께, 사서함 데이터베이스에 영향을 준 오류(예: 디스크 오류 또는 서버 오류)로부터 자동 복구를 수행합니다. DAG에 대한 자세한 내용은 DAG(데이터베이스 가용성 그룹)를 참조하세요.

사서함 데이터베이스 복사본

Exchange 2010에서 처음 도입된 고가용성 및 사이트 복구 기능이 Exchange 2013에서는 데이터베이스 복사본을 만들고 유지 관리하는 데도 사용됩니다. Exchange 2013에서는 데이터베이스 이동성의 개념, 즉 Exchange에서 관리되는 데이터베이스 수준의 장애 조치(failover) 기능도 활용합니다.

데이터베이스 이동성은 서버에서 데이터베이스의 연결을 끊고 단일 데이터베이스의 최대 16개 복사본에 대한 지원을 추가합니다. 또한 데이터베이스의 복사본을 만들기 위한 기본 환경을 제공합니다.

데이터베이스 복사본을 활성 사서함 데이터베이스로 설정하는 것을 전환이라고 합니다. 데이터베이스 또는 데이터베이스 액세스에 영향을 주는 오류가 발생하여 새 데이터베이스가 활성 복사본이 되는 프로세스를 장애 조치(failover)라고 합니다. 또한 이 프로세스는 실패한 서버에서 이전에 온라인 상태였던 데이터베이스를 하나 이상의 서버에서 온라인 상태로 만드는 서버 오류라고도 합니다. 전환 또는 장애 조치(failover)가 발생할 경우 다른 Exchange 2013 서버는 전환을 거의 즉시 인식하고 클라이언트 및 메시징 트래픽을 새 활성 데이터베이스로 리디렉션합니다.

예를 들어 기본 스토리지 오류로 인해 DAG의 활성 데이터베이스가 실패하는 경우 Active Manager는 DAG의 다른 사서함 서버에서 데이터베이스 복사본으로 장애 조치(failover)하여 자동으로 복구됩니다. Exchange 2013에서 관리되는 가용성은 애플리케이션 작업자 풀 재활용, 서비스 및 서버 다시 시작, 데이터베이스 장애 조치(failover) 시작 등 데이터베이스에 대한 프로토콜 액세스 손실로부터 복구하기 위한 새로운 동작을 추가합니다.

사서함 데이터베이스 복사본에 대한 자세한 내용은 사서함 데이터베이스 복사본를 참조하십시오.

Active Manager

Exchange 2013은 Exchange 2010에서 도입된 Active Manager 구성 요소를 활용하여 데이터베이스, 데이터베이스 복사본 상태, 현재 상태, 연속 복제 및 기타 사서함 서버 고가용성 기능을 관리합니다. Active Manager에 대한 자세한 내용은 Active Manager를 참조하십시오.

사이트 복구

Exchange 2013에서도 사서함 서버 역할 고가용성 및 사이트 복구에 DAG와 Windows 장애 조치(failover) 클러스터링을 계속 사용하지만 Exchange 2013의 사이트 복구 기능에는 차이점이 있습니다. Exchange 2013의 사이트 복구 기능은 단순화되었으므로 훨씬 더 우수합니다. Exchange 2013에서 구현된 기본 아키텍처 변경 사항은 사이트 복구 구성의 복구 측면에 상당한 영향을 줍니다.

Exchange 2010에서는 사서함(DAG)과 클라이언트 액세스(클라이언트 액세스 서버 배열) 복구가 서로 결합되어 있었습니다. 클라이언트 액세스 서버 전체, 배열의 VIP 또는 DAG의 중요 부분이 손실된 경우에는 데이터 센터 전환을 수행해야 했습니다. 데이터 센터 전환은 잘 문서화되어 있고 일반적으로 이해하기 쉽지만 수행하는 데 시간이 걸리며 사용자의 개입이 있어야만 프로세스를 시작할 수 있습니다.

Exchange 2013에서 어떤 이유로든 클라이언트 액세스 서버 배열이 손실되는 경우(예: 부하 분산 장치 실패) 데이터 센터 전환 작업을 수행할 필요가 없습니다. 적절한 구성을 사용하면 장애 조치(failover)가 클라이언트 수준에서 발생하고 클라이언트는 클라이언트 액세스 서버를 운영하는 두 번째 데이터 센터로 자동으로 리디렉션되고, 클라이언트 액세스 서버를 운영하는 클라이언트 액세스 서버는 중단의 영향을 받지 않는 사용자의 사서함 서버로 통신을 다시 프록시합니다( 전환하지 않기 때문에). 서비스를 복구하는 대신 서비스가 자체 복구되며 핵심 문제(예: 실패한 부하 분산 장치 교체)를 해결하는 데 집중할 수 있습니다.

또한 네임스페이스 단순화, 서버 역할 통합, Active Directory 사이트 서버 역할 요구 사항의 분리, 클라이언트 액세스 서버 배열과 DAG 복구의 분리, 부하 분산 변경과 함께 Exchange 2013에서는 클라이언트 액세스 서버 및 DAG 복구를 사이트 간에 분리하고 자동화할 수 있으므로 3개의 위치가 있는 경우 데이터 센터 장애 조치(failover) 시나리오가 제공됩니다.

Exchange 2010에서는 두 데이터 센터에 DAG를 배포하고, 세 번째 데이터 센터에서 미러링 모니터 서버를 호스트하고, 두 데이터 센터 중 하나의 사서함 서버 역할에 대해 장애 조치(failover)를 사용할 수 있었습니다. 그러나 사서함 서버 역할이 아닌 서버 역할에 대해서는 여전히 수동으로 네임스페이스를 변경해야 했으므로 솔루션 자체를 위한 장애 조치(failover)는 아니었습니다.

Exchange 2013에서는 DAG와 함께 네임스페이스를 이동하지 않아도 됩니다. Exchange는 다중 IP 주소, 부하 분산(필요한 경우 서비스 실행 상태 및 서비스 중지 상태로 서버를 사용하는 기능)을 통해 네임스페이스에 기본 제공되는 내결함성을 활용합니다. 최신 HTTP 클라이언트는 자동으로 이 중복성 기능과 함께 작동합니다. HTTP 스택은 FQDN(정규화된 도메인 이름)에 대해 다중 IP 주소를 허용할 수 있으며, 시도한 첫 IP 주소가 실패할 경우(연결할 수 없는 경우) 목록에 있는 다음 IP 주소를 시도합니다. 장치가 패킷을 누락하고 있어 서비스 중지 상태로 사용되어야 하는 등의 일시적인 서비스 문제로 인해 세션 설정 이후에 연결이 손실된 경우에는 사용자가 브라우저를 새로 고치면 됩니다.

즉, 네임스페이스는 Exchange 2010에서와 같이 더 이상 단일 실패 지점이 아닙니다. Exchange 2010에서 메시징 시스템에서 가장 큰 단일 실패 지점은 사용자에게 어디로 가야 했는지 알려주기 때문에 사용자에게 제공하는 FQDN일 수 있습니다. Exchange 2010 패러다임에서 DNS를 변경한 다음 DNS 대기 시간을 처리해야 하기 때문에 FQDN이 어디로 가는지 변경하는 것은 쉽지 않습니다. 또한 일반적으로 처리해야 하는 약 30분 이상의 브라우저에 이름 캐시가 있습니다.

Exchange 2013의 변경 사항 중 하나는 클라이언트가 둘 이상의 위치를 가질 수 있도록 하는 것입니다. 클라이언트가 둘 이상의 위치를 사용할 수 있다고 가정하면(Exchange 2013의 거의 모든 클라이언트 액세스 프로토콜은 HTTP 기반이며(예: Outlook, Outlook Anywhere, EAS, EWS, OWA 및 EAC 포함) 지원되는 모든 HTTP 클라이언트는 여러 IP 주소를 사용할 수 있으므로 클라이언트 쪽에서 장애 조치(failover)를 제공합니다. 이름 확인 중에 클라이언트에 여러 IP 주소를 전달하도록 DNS를 구성할 수 있습니다. 클라이언트는 mail.contoso.com 요청하고 IP 주소 2개 또는 IP 주소 4개를 다시 가져옵니다. 그러나 클라이언트가 다시 가져오는 많은 IP 주소는 클라이언트에서 안정적으로 사용됩니다. 이렇게 하면 IP 주소 중 하나가 실패하면 클라이언트에 연결을 시도할 하나 이상의 다른 IP 주소가 있기 때문에 클라이언트가 훨씬 더 좋아집니다. 클라이언트가 하나를 시도하고 실패하면 약 20초 동안 기다린 다음 목록에서 다음을 시도합니다. 따라서 클라이언트 액세스 서버 배열에 대한 VIP가 손실되면 클라이언트에 대한 복구가 자동으로 약 21초 후에 발생합니다.

이점은 다음과 같습니다.

Exchange 2010에서 기본 데이터 센터에서 부하 분산 장치를 분실하고 해당 사이트에 다른 부하 분산 장치가 없는 경우 데이터 센터 전환을 수행해야 했습니다. Exchange 2013에서 기본 사이트에서 부하 분산 장치를 분실한 경우 단순히 해제(또는 VIP 끄기)하고 복구하거나 교체합니다. 보조 데이터 센터에서 VIP를 아직 사용하지 않는 클라이언트는 네임스페이스를 변경하지 않고 DNS를 변경하지 않고 보조 VIP로 자동으로 장애 조치합니다. 이는 더 이상 전환을 수행할 필요가 없다는 것을 의미할 뿐만 아니라 일반적으로 데이터 센터 전환 복구와 연결된 모든 시간이 소비되지 않는다는 것을 의미합니다. Exchange 2010에서는 DNS 대기 시간을 처리해야 했습니다(따라서 TTL(Time to Live)를 5분으로 설정하고 장애 복구 URL을 도입하는 것이 좋습니다. Exchange 2013에서는 VIP(데이터 센터) 간에 네임스페이스의 빠른 장애 조치(failover)(20초)를 받기 때문에 이 작업을 수행할 필요가 없습니다.
데이터 센터 간 네임스페이스에 대한 장애 조치(failover)를 수행할 수 있기 때문에 데이터 센터 장애 조치(failover)에 필요한 것은 데이터 센터 간 사서함 서버 역할의 장애 조치(failover)를 위한 메커니즘뿐입니다. DAG에 대한 자동 장애 조치(failover)를 수행하려면 DAG가 두 데이터 센터 간에 균등하게 분할되고, DAG 구성원을 포함하는 데이터 센터 간의 네트워크 상태에 상관없이 두 데이터 센터의 DAG 구성원이 미러링 모니터 서버를 중재할 수 있도록 세 번째 위치에 이를 배치하는 솔루션을 구성합니다. 두 개의 데이터 센터만 있고 세 번째 물리적 위치를 사용할 수 없는 경우 Microsoft Azure 가상 머신에 미러링 모니터 서버를 배치할 수 있습니다. 자세한 내용은 Microsoft Azure VM을 DAG 감시 서버로 사용을 참조하세요.
이 시나리오에서 관리자의 노력은 단순히 문제를 해결하는 데 사용되며 서비스를 복원하는 데 소비되지 않습니다. 실패한 항목을 수정하기만 하면 됩니다. 서비스가 실행되고 데이터 무결성이 유지되는 동안 손상된 장치를 고칠 때 느끼는 긴급성과 스트레스 수준은 서비스를 복원하기 위해 노력할 때 느끼는 긴급성과 스트레스와는 다릅니다. 최종 사용자에게는 더 낫고 관리자에게는 스트레스가 적습니다.

다시 전환(장애 복구(failback)와 혼동되는 경우도 있음)을 수행할 필요 없이 장애 조치(failover)가 수행되도록 할 수 있습니다. 기본 데이터 센터에서 클라이언트 액세스 서버가 손실되고 이로 인해 클라이언트 서비스가 20초 동안 중단되더라도 장애 복구(failback)에 신경 쓸 필요가 없습니다. 이 시점에서 주요 관심사는 장애가 있는 부하 분산 장치를 교체하는 것과 같이 근본 문제를 해결하는 것입니다. 기본 데이터 센터가 다시 온라인 상태가 되어 작동하게 되면 일부 클라이언트는 해당 데이터 센터를 사용하기 시작하지만 다른 클라이언트는 여전히 두 번째 데이터 센터를 통해 작동하고 있을 수 있습니다.

Exchange 2013에서는 관리자가 일시적인 오류를 처리할 수 있는 기능도 제공됩니다. 예를 들면, 초기 TCP 연결에는 성공했지만 이후 아무 작업도 수행되지 않는 경우가 일시적인 오류에 해당합니다. 일시적인 오류는 교체 장치에서 서비스를 제공하도록 전환한 결과로 인해 발생할 수 있으므로 추가 관리 작업을 수행해야 합니다. 이 복구 프로세스가 진행되는 동안 장치의 전원을 켜고 일부 요청을 받을 수도 있지만 필요한 구성 단계가 수행되기 전까지는 장치에서 실제로 클라이언트에 서비스를 제공할 수 없습니다. 이 경우 관리자는 DNS에서 교체되는 장치의 VIP를 제거하여 네임스페이스 전환을 수행할 수 있습니다. 그러면 해당 서비스 기간 동안 클라이언트가 이 장치에 연결하지 않게 됩니다. 교체 프로세스가 완료된 후 관리자는 VIP를 다시 DNS에 추가할 수 있으며 그러면 클라이언트가 해당 장치를 사용하기 시작합니다.

사이트 복원력 계획 및 배포에 대한 자세한 내용은 고가용성 및 사이트 복원력 계획 및 고가용성 및 사이트 복원력 배포를 참조하세요.

타사 복제 API

Exchange 2013에는 조직에서 기본 제공되는 연속 복제 기능 대신 타사 동기식 복제 솔루션을 사용할 수 있게 하는 타사 복제 API가 포함되어 있습니다. Microsoft는 해당 솔루션이 API를 사용한 결과로 사용할 수 없는 모든 기본 연속 복제 기능을 대체하는 데 필요한 기능을 제공한다면 이 API를 사용하는 타사 솔루션을 지원합니다. API가 DAG 내에서 사용되어 사서함 데이터베이스 복사본을 관리하고 활성화하는 경우에만 솔루션이 지원됩니다. 이러한 경계 외부에서의 API 사용은 지원되지 않습니다. 또한 솔루션은 관련 Windows 하드웨어 지원 요구 사항을 충족해야 합니다. 단, 지원을 위해 테스트 유효성 검사는 필요하지 않습니다.

기본 타사 복제 API를 사용하는 솔루션을 배포하는 경우 솔루션 공급업체가 해당 솔루션에 대한 주 지원 공급자가 됩니다. Microsoft는 복제된 솔루션 및 복제되지 않은 솔루션 모두에 대한 Exchange 데이터를 지원합니다. 데이터 복제를 사용하는 솔루션은 데이터 복제에 대한 Microsoft 지원 정책을 준수해야 합니다. 또한 Windows 장애 조치(failover) 클러스터 리소스 모델을 사용하는 솔루션은 Microsoft 기술 자료 문서 943984, Windows Server 2008 또는 Windows Server 2008 R2 장애 조치(failover) 클러스터에 대한 Microsoft 지원 정책 또는 Windows Server 2012 장애 조치(failover) 클러스터에 대한 Microsoft 지원 정책에서 설명한 Windows 클러스터 지원 가능성 요구 사항을 준수해야 합니다.

타사 복제 API 기반 솔루션을 사용하는 배포의 경우 Microsoft의 백업 및 복원 지원 정책은 고유의 연속 복제 배포의 경우와 동일합니다.

타사 API에 대한 정보가 필요한 파트너는 Microsoft 담당자에게 문의하십시오.