DAG(데이터베이스 사용 가능 그룹)

적용 대상: Exchange Server 2013

Exchange Server 2013에서 Exchange DAG에 대해 알아봅니다. 이 문서에서는 DAG(데이터베이스 사용 가능 그룹) 수명 주기뿐만 아니라 고가용성 및 사이트 복구를 위한 DAG 사용 방법도 설명합니다.

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

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

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

DAG(데이터베이스 사용 가능 그룹) 수명 주기

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

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

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

만드는 동안 DAG에는 고유한 이름이 지정되고 하나 이상의 고정 IP 주소가 할당되거나 DHCP(동적 호스트 구성 프로토콜)를 사용하도록 구성되거나 클러스터 관리 액세스 지점 없이 생성됩니다. 관리 액세스 지점이 없는 DAG는 Windows Server 2012 R2 Standard 또는 Datacenter 버전에서 Exchange 2013 서비스 팩 1 이상을 실행하는 서버에서만 만들 수 있습니다. 클러스터 관리 액세스 지점이 없는 DAG에는 다음과 같은 특성이 있습니다.

• 클러스터/DAG에 IP 주소가 할당되지 않으므로 클러스터 핵심 리소스 그룹에 IP 주소 리소스가 없습니다.
• 클러스터에 네트워크 이름이 할당되지 않으므로 클러스터 핵심 리소스 그룹에 네트워크 이름 리소스가 없습니다.
• 클러스터/DAG의 이름이 DNS에 등록되지 않으며 네트워크에서 확인할 수 없습니다.
• CNO(클러스터 이름 개체)가 Active Directory에서 만들어지지 않습니다.
• 장애 조치 클러스터 관리 도구를 사용하여 클러스터를 관리할 수 없습니다. 클러스터는 Windows PowerShell을 사용하여 관리해야 하며 개별 클러스터 구성원에 대해 PowerShell cmdlet을 실행해야 합니다.

다음 예에서는 셸을 사용하여 세 개의 서버를 포함할 클러스터 관리 액세스 포인트가 포함된 DAG를 만드는 방법을 보여 줍니다. 두 개의 서버(EX1 및 EX2)는 동일한 서브넷(10.0.0.0)에 있고 세 번째 서버(EX3)는 다른 서브넷(192.168.0.0)에 있습니다.

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -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

클러스터 관리 액세스 포인트가 없는 DAG를 만드는 명령도 매우 비슷합니다.

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress])::None
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는 무시됩니다. 위의 두 번째 예에서 DatabaseAvailabilityGroupIPAddresses 매개 변수의 값은 관리 액세스 포인트가 없는 DAG에 대해 장애 조치 클러스터를 만드는 작업을 지시합니다. 따라서 클러스터는 핵심 클러스터 리소스 그룹의 IP 주소 또는 네트워크 이름 리소스를 사용하여 만들어집니다.

그런 다음 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 주소가 클러스터에 사용됩니다.

클러스터 관리 액세스 포인트가 있는 DAG의 경우 네트워크 이름 리소스가 온라인 상태가 되면 Windows 장애 조치 클러스터링은 DNS(Domain Name System)의 클러스터에 대한 IP 주소를 등록합니다. 또한 EX1을 클러스터에 추가하면 Active Directory에서 CNO(클러스터 이름 개체)가 만들어집니다. 클러스터에 대한 네트워크 이름, IP 주소 및 CNO는 DAG 기능에 사용되지 않습니다. 어떤 이유로든 관리자와 최종 사용자는 클러스터/DAG 이름 또는 IP 주소와 상호 작용하거나 해당 이름 또는 주소에 연결할 필요가 없습니다. 일부 타사 애플리케이션은 클러스터 관리 액세스 지점에 연결하여 백업 또는 모니터링과 같은 관리 작업을 수행합니다. 클러스터 관리 액세스 지점이 필요한 타사 애플리케이션을 사용하지 않고 DAG가 Windows Server 2012 R2에서 Exchange 2013 SP1 이상을 실행하는 경우 관리 액세스 지점 없이 DAG를 만드는 것이 좋습니다. 그러면 DAG 구성이 간소화되고 하나 이상의 IP 주소를 사용할 필요가 없으며 DAG의 공격 범위가 줄어듭니다.

또한 DAG는 미러링 모니터 서버 및 감시 디렉터리를 사용하도록 구성됩니다. 미러링 모니터 서버 및 감시 디렉터리는 시스템에서 자동으로 구성되거나 관리자가 수동으로 구성합니다. 위의 예에서는 DAG의 구성원이 아니며 구성원으로 지정할 계획도 없는 EX4를 DAG의 미러링 모니터 서버로 수동 구성합니다.

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

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

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

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

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

DAG(데이터베이스 사용 가능 그룹) 쿼럼 모델

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

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

• 일관성 보장: Windows 장애 조치(failover) 클러스터의 기본 요구 사항은 각 멤버가 항상 다른 멤버와 일치하는 클러스터 보기를 갖는 것입니다. 클러스터 하이브는 클러스터와 관련 있는 모든 구성 정보를 위한 가장 확실한 리포지토리 역할을 합니다. 클러스터 하이브를 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(데이터베이스 사용 가능 그룹) 사용

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

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

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

처음에는 모든 데이터베이스 및 서버가 정상적입니다. 서버를 유지 관리 모드로 전환하려면 EX2에 몇몇 운영 체제 업데이트를 설치해야 합니다. 그러면 다른 사서함 서버에서 DB4 복사본을 활성화하는 서버 전환이 수행됩니다. 서버 전환은 현재 서버에 대한 예약된 중단을 준비하기 위해 현재 서버의 모든 활성 사서함 데이터베이스 복사본을 DAG에 있는 하나 이상의 다른 사서함 서버로 이동합니다. 이 예에서는 EX2(DB4)에 활성 사서함 데이터베이스가 하나만 있으므로 하나의 활성 사서함 데이터베이스 복사본만 이동합니다.

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

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

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

사이트 복구를 위한 DAG(데이터베이스 사용 가능 그룹) 사용

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

되었습니다.

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

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

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

사이트 복구를 위한 여러 DAG(데이터베이스 사용 가능 그룹) 사용

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

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

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