데이터베이스 가용성 그룹 이해

 

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

마지막으로 수정된 항목: 2015-03-09

DAG(데이터베이스 사용 가능 그룹)는 Microsoft Exchange Server 2010에서 기본 제공되는 고가용성 및 사이트 복구 프레임워크의 기본 구성 요소입니다. DAG는 데이터베이스 집합을 호스트하는 최대 16개의 사서함 서버 그룹이며 개별 서버 또는 데이터베이스에 영향을 준 오류로부터 데이터베이스 수준의 자동 복구를 수행합니다.

DAG는 사서함 데이터베이스 복제, 데이터베이스 및 서버 전환, 장애 조치와 Active Manager라는 내부 Exchange 2010 구성 요소를 위한 경계입니다. DAG의 모든 서버에서 실행되는 Active Manager는 전환과 장애 조치를 관리합니다. Active Manager에 대한 자세한 내용은 Active Manager 이해를 참조하십시오.

DAG의 서버는 DAG의 다른 서버로부터 사서함 데이터베이스의 복사본을 호스트할 수 있습니다. 서버를 DAG에 추가하면 DAG의 다른 서버와 함께, 사서함 데이터베이스에 영향을 준 오류(예: 디스크 오류 또는 서버 오류)로부터 자동 복구를 수행합니다.

목차

데이터베이스 가용성 그룹 수명 주기

고가용성을 위해 데이터베이스 가용성 그룹 사용

사이트 복구를 위해 데이터베이스 가용성 그룹 사용

데이터베이스 가용성 그룹 사용 시의 클라이언트 환경

데이터베이스 가용성 그룹 수명 주기

DAG는 Exchange 2010가 설치된 후 모든 사서함 서버 및 데이터베이스에 대한 서비스 및 데이터 가용성을 배포할 수 있는 기능인 증분 배포라고 알려진 Exchange의 기능을 사용합니다. Exchange 2010을 배포한 후 DAG를 만들고 사서함 서버를 DAG에 추가한 다음 DAG 구성원 사이에 사서함 데이터베이스를 복제할 수 있습니다.

DAG는 New-DatabaseAvailabilityGroup cmdlet을 사용하여 만들어집니다. DAG는 초기에 Active Directory에서 빈 개체로 만들어집니다. 이 디렉터리 개체는 서버 구성원 정보와 같이 DAG 관련 정보를 저장하는 데 사용됩니다. DAG에 첫 번째 서버를 추가하는 경우 해당 DAG에 대한 장애 조치(failover) 클러스터가 자동으로 만들어집니다. 이 장애 조치(failover)는 DAG에서 단독으로 사용되며 해당 클러스터는 DAG에 전용으로 사용되어야 합니다. 기타 다른 목적을 위해 클러스터를 사용하는 것은 지원되지 않습니다.

장애 조치 클러스터 작성 외에 서버에서 네트워크 또는 서버 오류를 모니터링하는 인프라가 시작됩니다. 그러면 장애 조치(failover) 클러스터 하트비트 메커니즘 및 클러스터 데이터베이스를 사용하여 데이터베이스 탑재 상태, 복제 상태, 마지막으로 탑재된 위치 등 신속하게 변경할 수 있는 DAG 관련 정보를 추적하고 관리합니다.

DAG가 만들어질 때 DAG에는 고유한 이름이 지정되고, 하나 이상의 고정 IP 주소가 할당되거나 DHCP(Dynamic Host Configuration Protocol)를 사용하도록 구성됩니다. DatabaseAvailabilityGroupIPAddresses 매개 변수를 사용하여 단일 IP 주소 또는 쉼표로 구분된 IP 주소 목록을 지정할 수 있습니다.

이 예에서는 3개의 서버가 있는 DAG를 보여 줍니다. 두 개의 서버(EX1 및 EX2)는 동일한 서브넷(10.0.0.0)에 있고 세 번째 서버(EX3)는 다른 서브넷(192.168.0.0)에 있습니다.

New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

DAG1의 클러스터는 EX1이 DAG에 추가될 때 만들어집니다. 클러스터를 만드는 동안 Add-DatabaseAvailabilityGroupServer cmdlet은 DAG에 구성된 IP 주소를 검색하고 EX1에서 발견된 서브넷과 일치하지 않는 IP 주소를 무시합니다. 이 예제에서 DAG1의 클러스터는 IP 주소 10.0.0.5를 사용하여 만들어지고 192.168.0.5는 무시됩니다.

그런 다음 EX2가 추가되며 Add-DatabaseAvailabilityGroupServer cmdlet은 DAG에 대해 구성된 IP 주소를 다시 검색합니다. EX2가 EX1과 동일한 서브넷에 있으므로 클러스터의 IP 주소는 변경되지 않습니다.

그런 다음 EX3이 추가되며 Add-DatabaseAvailabilityGroupServer cmdlet은 DAG에 대해 구성된 IP 주소를 다시 검색합니다. 192.168.0.5와 일치하는 서브넷이 EX3에 있으므로 192.168.0.5 주소는 클러스터 그룹에서 IP 주소 리소스로 추가됩니다. 또한 각 IP 주소 리소스의 네트워크 이름 리소스에 대한 OR 종속성이 자동으로 구성됩니다. 클러스터 그룹이 EX3으로 이동할 때 192.168.0.5 주소가 클러스터에 사용됩니다.

네트워크 이름 리소스가 온라인 상태가 되면 Windows 장애 조치 클러스터링은 DNS(Domain Name System)의 클러스터에 대한 IP 주소를 등록합니다. 또한 CNO(클러스터 이름 개체)가 Active Directory에 만들어집니다. 클러스터의 이름, IP 주소 및 CNO는 DAG 보안 및 내부 통신용으로 시스템에서 내부적으로만 사용됩니다. 어떤 이유로든 관리자와 최종 사용자는 DAG 이름 또는 IP 주소에 연결할 필요가 없습니다.

이름 및 하나 이상의 IP 주소 외에도 DAG 또한 미러링 모니터 서버 및 감시 디렉터리를 사용하도록 구성됩니다. 미러링 모니터 서버 및 미러링 모니터 디렉터리는 시스템에 의해 자동으로 지정되거나 관리자가 수동으로 지정합니다.

기본적으로 DAG는 기본 제공 연속 복제 기능을 사용하여 DAG의 서버 간에 사서함 데이터베이스를 복제하도록 설계되었습니다. Exchange 2010에서 타사 복제 API를 지원하는 타사 데이터 복제를 사용하는 경우 New-DatabaseAvailabilityGroup cmdlet과 함께 ThirdPartyReplication 매개 변수를 사용하여 타사 복제 모드에서 DAG를 만들어야 합니다. 이 모드를 사용하도록 설정한 후에는 사용하지 않게 설정할 수 없습니다.

DAG가 만들어진 후 사서함 서버를 DAG에 추가할 수 있습니다. 첫 번째 서버가 DAG에 추가될 때 DAG에 사용할 클러스터가 형성됩니다. DAG는 Windows 장애 조치 클러스터링 기술, 즉 클러스터 하트비트, 클러스터 네트워크 및 클러스터 데이터베이스(데이터베이스 상태 변경처럼 활성에서 수동으로 또는 그 반대로, 탑재에서 분리로 또는 그 반대로 변경될 수 있는 데이터를 저장하기 위한)를 제한적으로 사용합니다. 각 후속 서버는 DAG에 추가될 때 기본 클러스터에 가입되며 클러스터의 쿼럼 모델이 시스템에서 자동으로 조정되고 서버는 Active Directory의 DAG 개체에 추가됩니다.

사서함 서버가 DAG에 추가된 후 DAG 내의 데이터베이스 복제에 네트워크 암호화 또는 네트워크 압축을 사용할지 여부와 같은 다양한 DAG 속성을 구성할 수 있습니다. 또한 DAG 네트워크를 구성하고 추가 DAG 네트워크를 만들 수 있습니다.

구성원을 DAG에 추가하고 DAG를 구성한 후 각 서버의 활성 사서함 데이터베이스는 다른 DAG 구성원에 복제될 수 있습니다. 사서함 데이터베이스 복사본을 만든 후 다양한 기본 제공 모니터링 도구를 사용하여 복사본의 상태를 모니터링할 수 있습니다. 또한 데이터베이스 및 서버 전환을 수행할 수 있습니다.

DAG 만들기, DAG 구성원 자격 관리, DAG 속성 구성, 사서함 데이터베이스 복사본 만들기 및 모니터링, 전환 수행 등에 대한 자세한 내용은 고가용성 및 사이트 복구 관리를 참조하십시오.

데이터베이스 가용성 그룹 쿼럼 모델

모든 DAG 아래에는 Windows 장애 조치 클러스터가 있습니다. 장애 조치 클러스터는 쿼럼 개념을 사용합니다. 쿼럼은 한 번에 클러스터 구성원(모든 구성원 또는 대다수의 구성원을 의미할 수 있음) 중 하나의 하위 집합만 작동하도록 보장하기 위해 응답자의 합의를 사용합니다. 쿼럼은 Exchange 2010에서 새로운 개념이 아닙니다. Exchange의 이전 버전에서 고가용성 사서함 서버는 장애 조치 클러스터링 및 쿼럼 개념도 사용합니다. 쿼럼은 구성원과 리소스의 공유 보기를 나타내며, 모든 클러스터 구성원 간에 공유되는 클러스터 내의 구성을 나타내는 실제 데이터를 설명하는 데도 사용됩니다. 따라서 모든 DAG에는 쿼럼을 갖기 위한 기본 장애 조치 클러스터가 필요합니다. 클러스터가 쿼럼을 손실하면 모든 DAG 작업이 종료되고 DAG에 호스트된 모든 탑재된 데이터베이스가 분리됩니다. 이 경우 쿼럼 문제를 해결하고 DAG 작업을 복원하기 위해 관리자 작업이 필요합니다.

쿼럼은 일관성을 유지하고 연결 분리기로 동작하여 파티션을 방지하고 클러스터 응답을 확인하는 것이 중요합니다.

• 일관성 확인   Windows 장애 조치 클러스터의 기본 요구 사항은 각 구성원이 다른 구성원과 일관되지 않은 클러스터의 보기를 항상 가지고 있어야 한다는 것입니다. 클러스터 하이브는 클러스터와 관련 있는 모든 구성 정보를 위한 가장 확실한 리포지토리 역할을 합니다. 클러스터 하이브를 DAG 구성원에 로컬로 로드할 수 없는 경우, 다른 구성원과 일관된 클러스터의 보기를 가지고 있어야 하는 요구 사항을 구성원이 충족하는지 보장할 수 없기 때문에 클러스터 서비스가 시작되지 않습니다.

• 연결 분리기로 작용   쿼럼 감시 리소스가 짝수의 구성원이 있는 DAG에 사용되어 스플릿 브레인 현상 시나리오가 발생하는 것을 방지하고 DAG에서 하나의 구성원 컬렉션만 공식적으로 간주되는지 확인합니다. 미러링 모니터 서버가 쿼럼이 필요하면 미러링 모니터 서버와 통신할 수 있는 DAG의 구성원이 SMB(Server Message Block) 잠금을 미러링 모니터 서버의 witness.log 파일에 적용할 수 있습니다. 미러링 모니터 서버를 잠그는 DAG 구성원(잠금 노드)은 쿼럼 용도의 추가 응답을 유지합니다. 잠금 노드와 연관된 DAG 구성원이 대다수이며 쿼럼을 유지 관리합니다. 잠금 노드와 연결할 수 없는 DAG 구성원은 소수이므로 쿼럼이 손실됩니다.

• 응답 확인   응답을 확인하려면 클러스터가 실행될 때마다 쿼럼 모델은 배포된 시스템의 충분한 구성원이 작동 가능한지와 통신 여부를 확인하고 클러스터의 현재 상태 중 최소 하나 이상을 복제할 수 있는지 확인해야 합니다. 구성원을 통신하게 하거나 특정 복제본이 보장받는지 여부를 판단하는 데 추가 시간이 필요하지 않습니다.

짝수의 구성원이 있는 DAG가 장애 조치 클러스터의 노드 및 파일 공유 과반수 쿼럼 모드를 사용하며, 연결 분리기로 동작하는 외부 미러링 모니터 서버를 사용합니다. 이 쿼럼 모드에서 각 DAG 구성원은 응답권을 가집니다. 또한 하나의 DAG 구성원에게 가중치가 있는 응답(예: 하나의 응답권이 아니라 두 개의 응답권을 가짐)을 제공하기 위해 미러링 모니터 서버가 사용됩니다. 클러스터 쿼럼 데이터는 기본적으로 DAG의 각 구성원 시스템 디스크에 저장되며 이러한 디스크에서 일관성을 유지합니다. 그러나 쿼럼 데이터의 복사본은 미러링 모니터 서버에 저장되지 않습니다. 미러링 모니터 서버의 파일은 데이터의 최신 복사본을 가진 구성원을 추적하는 데 사용되지만 미러링 모니터 서버에는 클러스터 쿼럼 데이터의 복사본이 없습니다. 이 모드에서 대다수의 응답자(DAG 구성원 + 미러링 모니터 서버)가 작동 가능해야 하며 쿼럼을 유지 관리하도록 서로 통신할 수 있어야 합니다. 대다수의 응답자가 서로 통신할 수 없는 경우 DAG의 기본 클러스터가 쿼럼을 손실하고 다시 작동하게 하려면 DAG에 관리자 작업이 필요합니다.

홀수의 구성원이 있는 DAG는 장애 조치 클러스터의 노드 과반수 쿼럼 모드를 사용합니다. 이 모드에서 각 구성원은 하나의 응답권을 가지며 각 구성원의 로컬 시스템 디스크는 클러스터 쿼럼 데이터를 저장하는 데 사용됩니다. DAG 구성이 변경되면 해당 변경 내용은 다른 디스크에 반영됩니다. 변경 내용은 구성원 반(내림)에 1을 더해 디스크에 작성된 경우 커밋되고 지속적인 상태가 된 것으로 간주됩니다. 예를 들어, 5명의 구성원이 있는 DAG에서 변경 내용은 두 구성원에 한 명의 구성원이 더해지거나 아니면 총 3명의 구성원으로 이루어져야 합니다.

쿼럼을 사용하려면 응답자의 과반수가 서로 통신할 수 있어야 합니다. DAG에 4명의 구성원이 있다고 가정해 보겠습니다. 이 DAG에는 짝수의 구성원이 있기 때문에 외부 미러링 모니터 서버는 클러스터 구성원 중 하나에 균형을 깨는 다섯 번째 응답권을 제공하는 데 사용됩니다. 응답자의 과반수(따라서 쿼럼)를 유지 관리하려면 최소 3명의 응답자가 서로 통신할 수 있어야 합니다. 언제든지 최대 두 명의 응답자는 서비스 및 데이터 액세스를 방해하지 않고 오프라인이 될 수 있습니다. 3명 이상의 응답자가 오프라인인 경우 DAG는 쿼럼을 손실하며 문제가 해결될 때까지 서비스와 데이터 액세스는 중단됩니다.

맨 위로 이동

고가용성을 위해 데이터베이스 가용성 그룹 사용

DAG가 사서함 데이터베이스에 대해 고가용성을 제공하는 방법을 설명하기 위해 5개의 구성원이 있는 DAG를 사용하는 다음 예제를 가정해 보겠습니다. 이 DAG가 다음 그림에 나와 있습니다.

5명의 구성원이 있는 DAG

앞의 그림에서 녹색 데이터베이스는 활성 사서함 데이터베이스 복사본이고 파랑 데이터베이스는 수동 사서함 데이터베이스 복사본입니다. 이 예제에서 데이터베이스 복사본은 각 서버에서 미러링되지 않으며 여러 서버에 퍼져 있습니다. 이렇게 하면 DAG에 있는 두 개의 서버가 동일한 데이터베이스 복사본 집합을 갖지 않아 정기적인 유지 관리로 인해 다른 구성 요소가 사용할 수 없게 된 동안 발생하는 오류를 비롯한 다양한 오류에 대한 향상된 복구 능력이 DAG에 제공됩니다.

여러 데이터베이스 및 서버 오류에 대한 복구를 보여주는 앞의 DAG 예제를 사용한 다음 시나리오를 가정해 봅니다.

처음에는 모든 데이터베이스 및 서버가 정상적입니다. EX2에 일부 운영 체제 업데이트를 설치해야 합니다. 다른 사서함 서버에서 DB4 복사본을 활성화하는 서버 전환을 수행합니다. 서버 전환은 현재 서버에 대한 예약된 중단을 준비하기 위해 현재 서버의 모든 활성 사서함 데이터베이스 복사본을 DAG에 있는 하나 이상의 다른 사서함 서버로 이동합니다. Exchange 관리 셸에서 다음 명령을 실행하여 서버 전환을 신속하게 수행할 수 있습니다.

Move-ActiveMailboxDatabase -Server EX2

이 예에서는 EX2(DB4)에 활성 사서함 데이터베이스가 하나만 있으므로 하나의 활성 사서함 데이터베이스 복사본만 이동합니다. 앞의 명령에서 ActivateOnServer 매개 변수를 생략하여 가능한 최선의 새 활성 복사본을 시스템에서 선택하도록 했으며 다음 그림과 같이 시스템은 EX5의 복사본을 선택했습니다.

유지 관리를 위한 오프라인 상태의 서버가 있는 DAG

EX2에서 유지 관리를 수행하는 동안 EX3은 치명적인 하드웨어 오류를 경험하고 오프라인 상태가 됩니다. 오프라인으로 이동하기 전에 EX3은 DB2의 활성 복사본을 호스트했습니다. 오류에서 복구하기 위해 시스템은 EX1에서 호스트되는 DB2의 복사본을 30초 내에 자동으로 활성화합니다. 이 작업이 다음 그림에 나와 있습니다.

유지 관리를 위한 오프라인 상태의 서버 및 오류가 발생한 서버가 있는 DAG

EX2에 대한 예약된 유지 관리가 완료된 후 서버를 온라인 상태로 만듭니다. EX2가 사용할 수 있게 되자마자 DAG의 다른 구성원에 알림이 보내지고 EX2에서 호스트되는 DB1, DB4 및 DB5의 복사본은 각 데이터베이스의 활성 복사본과 자동으로 동기화됩니다. 이 작업이 다음 그림에 나와 있습니다.

데이터베이스 복사본을 동기화하는 복원된 서버가 있는 DAG

EX3의 실패한 하드웨어 구성 요소가 새 구성 요소로 대체된 후 EX3은 온라인 상태가 됩니다. EX3을 사용할 수 있게 된 후 DAG의 다른 구성원에 알림이 보내지고 EX3에서 호스트되는 DB2, DB3 및 DB4의 복사본은 각 데이터베이스의 활성 복사본과 자동으로 다시 동기화됩니다. 이 작업이 다음 그림에 나와 있습니다.

데이터베이스 복사본을 동기화하는 복구된 서버가 있는 DAG

맨 위로 이동

사이트 복구를 위해 데이터베이스 가용성 그룹 사용

데이터 센터 내에서 고가용성을 제공하는 것 외에도 하나 또는 여러 데이터 센터에 사이트 복구를 제공하는 구성에서는 DAG를 하나 이상의 다른 데이터 센터로 확장할 수 있습니다. 앞의 예제 그림에서 DAG는 단일 데이터 센터 및 단일 Active Directory 사이트에 있습니다. 증분 배포는 사서함 서버 및 필요한 지원 리소스(하나 이상의 Active Directory 서버 및 하나 이상의 허브 전송 및 클라이언트 액세스 서버)를 배포함으로써 이 DAG를 보조 데이터 센터(및 보조 Active Directory 사이트)로 확장하는 데 사용할 수 있습니다. 그러면 다음 그림에 표시된 것처럼 사서함 서버가 DAG에 추가됩니다.

두 개의 Active Directory 사이트에 걸쳐 있는 DAG

이 예에서 Redmond 데이터 센터에 있는 각 활성 데이터베이스의 수동 복사본은 Dublin 데이터 센터의 EX6에서 구성됩니다. 그러나 사이트 복구를 제공하는 DAG 구성에는 여러 가지 다른 예가 있습니다. 예를 들면 다음과 같습니다.

• 수동 데이터베이스 복사본만을 호스트하지 않고, EX6은 모든 활성 복사본을 호스트하거나 활성과 수동 복사본을 혼합하여 호스트할 수 있습니다.

• 추가 오류에 대한 보호를 제공하는 경우 EX6 외에, 여러 DAG 구성원이 Dublin 데이터 센터에 배포될 수 있습니다. Redmond 데이터 센터가 실패하면 Dublin 데이터 센터가 더 많은 사용자 채우기를 지원할 수 있도록 이 구성도 추가 용량을 제공합니다.

사이트 복구를 위해 여러 데이터베이스 가용성 그룹 사용

이전 예에서 하나의 데이터 센터 또는 두 데이터 센터에 대해 사이트 복구를 제공하면 단일 DAG는 여러 데이터 센터에 확장됩니다. 단일 DAG를 사용하여 DAG를 확장하는 각 데이터 센터에 활성 사용자 채우기가 있는 환경에 사이트 복구를 제공하는 경우 WAN(광역 네트워크) 연결에 단일 실패 지점이 있습니다. 쿼럼을 사용하려면 응답자의 과반수가 활성화되고 서로 통신할 수 있어야 하기 때문입니다.

이전 예에서는 응답자의 과반수가 Redmond 데이터 센터에 있습니다. Dublin 데이터 센터가 활성 사서함 데이터베이스를 호스트하고 이 데이터 센터에 로컬 사용자 채우기가 있는 경우, WAN 중단으로 인해 Dublin 사용자의 메시징 서비스가 중단됩니다. WAN 연결이 중단되면 Redmond 데이터 센터의 DAG 구성원만이 쿼럼을 유지하고 계속 메시징 서비스를 제공합니다.

활성 사용자 채우기가 있는 여러 데이터 센터에 사이트 복구를 제공해야 하는 경우 WAN을 단일 실패 지점으로 삭제하려면, 별도의 데이터 센터에 과반수의 응답자를 가지고 있는 DAG를 여러 개 배포해야 합니다. WAN 중단이 발생하면 연결이 복원될 때까지 복제가 차단됩니다. 각 DAG가 계속 로컬 사용자 채우기를 제공하기 때문에 사용자는 메시징 서비스를 제공받게 됩니다.

맨 위로 이동

데이터베이스 가용성 그룹 사용 시의 클라이언트 환경

DAG를 사용하여 고가용성 및 사이트 복구 모두를 제공할 수 있습니다. DAG를 사용할 경우 클라이언트 환경은 사서함 데이터에 액세스하기 위해 클라이언트에서 사용하는 프로토콜 및 클라이언트의 유형과 버전에 따라 다릅니다. 예를 들어 사이트 간 데이터베이스 장애 조치가 발생하면 POP3 또는 IMAP4 클라이언트에서 사용한 동작 및 재연결 논리는 Microsoft Outlook 2010 클라이언트에서 사용하는 재연결 논리 및 동작과 다릅니다.

다음 섹션에서는 여러 시나리오의 클라이언트 동작 및 논리를 설명합니다. 설명된 동작은 다음을 가정합니다.

• 환경은 각 Active Directory 사이트에 단일 클라이언트 액세스 서버 배열을 포함하며 각 사이트에는 클라이언트 액세스 서버를 최소한 2개 이상 포함됩니다.

• 적절한 하드웨어 기반 또는 소프트웨어 기반 부하 분산 장치가 설치되며 클라이언트 액세스 서버 배열 앞에 구성됩니다.

• 필요한 DNS 레코드를 포함한 적절한 네임스페이스, 인증서 계획 및 구성이 완료됩니다.

Microsoft Outlook 동작 및 논리

일반적으로, Outlook의 모든 버전은 단일 데이터 센터 및 단일 Active Directory 사이트 내에서 발생하는 데이터베이스 장애 조치와 동일하게 동작합니다. Exchange의 이전 버전과 달리 Exchange 2010에서 Outlook은 더 이상 사서함 서버의 Exchange 저장소에 직접 연결되지 않습니다. 대신, Outlook(및 기타 MAPI 클라이언트)은 클라이언트 액세스 서버 역할의 주소록 서비스 및 RPC 클라이언트 액세스에 연결되며 사용자의 Outlook은 클라이언트 액세스 서버 배열에 연결되도록 구성되고 클라이언트가 개별 클라이언트 액세스 서버에 연결됩니다. 사서함 서버와의 Outlook 연결의 추상화에서는 다음 이점이 제공됩니다.

• 데이터베이스 장애 조치가 발생하면 Outlook은 클라이언트 액세스 서버 배열에서 동일한 서버와 연결된 채로 있게 됩니다. 이러한 경우 클라이언트 액세스 서버에서 실행되는 Active Manager 클라이언트는 어느 DAG 구성원이 DAG의 Active Manager에서 활성 데이터베이스 복사본을 호스트하는지 알게 됩니다. 그런 다음 클라이언트 액세스 서버는 사서함 서버에 연결되며 Outlook에 Exchange 서버에 연결되어 있음이 표시됩니다.

• 클라이언트 액세스 서버 배열의 클라이언트 액세스 서버 중 하나가 예약되거나 예약되지 않은 중단 때문에 사용할 수 없게 되면, 해당 배열의 나머지 클라이언트 서버에서는 클라이언트 부하가 처리됩니다. Outlook은 개별 클라이언트 액세스 서버가 아닌 클라이언트 액세스 서버 배열에 연결되도록 구성되기 때문에, 클라이언트 액세스 서버 배열 구성원은 개별적으로 오류가 발생하거나 사용자의 Outlook 프로필에 영향을 주지 않고 수동으로 오프라인 상태가 될 수 있습니다. 자동으로 발생하거나(예를 들어 배열 앞에 부하 분산 장치 솔루션에서 수행하는 모니터링을 기반으로 하는 자동 배열 재구성) 이를 수동으로 수행할 수 있습니다.

또한 Outlook의 모든 버전은 두 개의 데이터 센터 및 두 개의 Active Directory 사이트 사이에서 발생하는 데이터 센터 전환과 동일하게 동작합니다. 데이터 센터 전환은 클라이언트 액세스 네임스페이스(예를 들어, Microsoft Office Outlook Web App, SMTP, POP3, IMAP4, 자동 검색, Exchange 웹 서비스 또는 RPC 클라이언트 액세스)에서 사용한 IP 주소를 기본 데이터 센터의 IP 주소에서 보조 데이터 센터의 IP 주소로 변경하는 것과 관련됩니다. 따라서 사용자의 Outlook 프로필에서 사용된 네임스페이스는 변경되지 않으며 자동 검색은 계속 클라이언트를 동일한 클라이언트 액세스 서버 배열 네임스페이스로 지정합니다.

사이트 간 데이터베이스 장애 조치 후의 Outlook의 동작은 단일 Active Directory 사이트에서의 데이터베이스 장애 조치 후 또는 데이터 센터 전환 후의 동작과 다릅니다.

Outlook 버전의 동작 예제

다음 예에서는 사이트 간 데이터베이스 장애 조치가 발생한 후 Outlook 2010, Office Outlook 2007 및 Office Outlook 2003의 동작을 설명합니다. 각 예에서 사용된 토폴로지는 두 개의 Active Directory 사이트, 즉 Redmond 및 Portland로 확장된 4개의 구성원이 있는 DAG입니다. 사용자의 사서함은 DB1에서 호스트되며, 각 서버에 복제됩니다. 각 예에서 DB1의 활성 복사본은 MBX2에서 MBX3까지 장애 조치합니다.

사이트 간 데이터베이스 장애 조치 후 Outlook 동작을 보여주는 토폴로지 예제

각 클라이언트에서 CAS1은 홈 서버로 구성되어 Redmond를 Outlook 프로필 사이트로 만듭니다. 클라이언트가 Redmond에 있기 때문에 DB1의 RPCClientAccessServer 속성은 CAS1로 구성되어 Redmond를 선호하는 데이터베이스 사이트로 만듭니다. DB1이 MBX2에서 실패하고 MBX3에서 활성화되었기 때문에, Portland는 탑재된 데이터베이스 사이트가 됩니다.

Outlook 2010 및 Outlook 2007의 예제

Redmond 사이트에서 클라이언트 액세스 서버를 사용할 수 있으면 Outlook 2010 및 Outlook 2007이 Redmond 사이트의 RPC 클라이언트 액세스 배열에 계속 연결할 수 있습니다. 클라이언트가 사용하는 클라이언트 액세스 서버는 MAPI RPC를 사용하여 Portland 사이트에 있는 사용자의 사서함 서버와 통신합니다.

Redmond 사이트에서 사용할 수 있는 클라이언트 액세스 서버가 없으면 서비스 및 데이터에 대한 액세스를 복원하기 위해 Redmond에서 Portland로 데이터 센터 전환을 수행해야 합니다. 데이터 센터 전환을 수행하기 위한 자세한 단계는 서버 전환 수행을 참조하세요.

Outlook 2003의 예제

Outlook 2003이 CAS1로 연결을 시도하면 응답으로 ecWrongServer 메시지도 수신합니다. Outlook 2010 및 Outlook 2007과 달리, Outlook 2003은 자동 검색 기능을 포함하지 않으며 다른 기타 수단을 사용하여 사용자의 프로필을 업데이트해야 합니다. MAPI 프로필 리디렉션은 Outlook 2003에서 사용되는 메커니즘입니다. MAPI 프로필을 리디렉션하려면 원래 원본 서버가 온라인이어야 합니다. CAS1을 사용할 수 없고 해당 배열의 다른 모든 클라이언트 액세스 서버도 사용할 수 없는 경우(또는 배열에 CAS1만 포함된 경우), Outlook 2003은 MAPI 리디렉션을 수행하거나 수동 중단 없이 사용자의 사서함 데이터베이스를 연결할 수 없습니다.

공용 폴더 사용 시 Outlook 동작 및 논리

공용 폴더 데이터베이스를 DAG의 구성원인 사서함 서버에서 호스트할 수 있더라도, 공용 폴더 데이터베이스는 연속 복제를 사용하지 않으며 고가용성을 위해 공용 폴더 복제에 의존합니다. 사서함 데이터베이스 장애 조치 후 Outlook 클라이언트를 공용 폴더 데이터베이스에 다시 연결하는 동작은 해당 오류의 특성뿐만 아니라 공용 폴더 복제 구성 설정 및 공용 폴더 데이터베이스의 최신 상태에 따라 다릅니다. 연속 복제를 공용 폴더 데이터베이스에 사용할 수 없기 때문에 공용 폴더 데이터베이스의 고가용성은 다중 공용 폴더 데이터베이스 배포 및 서로 복제하도록 구성하여 이루어집니다. 각 폴더에 둘 이상의 복제본을 구성하는 것이 좋습니다.

비 Outlook 클라이언트 동작 및 논리

일반적으로, Outlook 및 MAPI가 아닌 클라이언트와 프로토콜의 동작은 사용된 응용 프로그램 및 오류 시나리오마다 다릅니다. 일반적으로, Outlook과 마찬가지로 일반 Exchange 응용 프로그램 및 클라이언트(예를 들어, Outlook Web App, Microsoft Exchange ActiveSync, POP3, IMAP4 및 Exchange 웹 서비스)는 단일 데이터 센터와 단일 Active Directory 사이트 내에서 발생하는 데이터베이스 장애 조치와 동일하게 동작합니다. 이와 마찬가지로, 데이터 센터 전환 후 모든 클라이언트와 프로토콜(SMTP 및 Windows PowerShell 포함)은 Outlook과 동일하게 동작합니다.

사이트 간 데이터베이스 장애 조치가 발생하면 클라이언트와 프로토콜은 다르게 동작합니다. 다음 표는 클라이언트의 동작을 나열합니다.

일반 Exchange 클라이언트의 사이트 간 데이터베이스 장애 조치 동작

클라이언트 또는 프로토콜	동작
Outlook Web App	수동 리디렉션. 이 시나리오에서 클라이언트 네임스페이스는 http://mailred.contoso.com에서 http://mailpdx.contoso.com으로 변경됩니다. 사용자가 로그온 자격 증명을 입력한 후 사용자는 잘못된 URL이 사용되었으며 올바른 URL은 https://mailpdx.contoso.com/owa임을 설명하는 수동 리디렉션 페이지를 통해 Portland 사이트의 CAS2로 리디렉션됩니다.
Exchange ActiveSync	프록시 또는 리디렉션. 이 시나리오에서 클라이언트 동작은 클라이언트 장치의 Exchange ActiveSync 프로토콜의 버전 및 구현에 의해 결정됩니다.
POP3 및 IMAP4	프록시. 이 시나리오는 항상 클라이언트 액세스 서버를 클라이언트 액세스 서버 프록싱에 연관시킵니다.
Exchange 웹 서비스	자동 검색을 사용하여 새 연결 끝점을 확인합니다.

맨 위로 이동

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