고가용성 및 사이트 복구 배포

  • 아티클

 

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

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

이전 버전의 Exchange에서 가용성이 뛰어난 사서함 서버를 만들려면 Microsoft Exchange 장애 조치(failover) 클러스터의 구성원으로 구성된 서버에 Windows를 설치합니다. 가용성이 뛰어난 사서함 서버를 필요로 하는 경우 Exchange 설치 프로그램을 실행하기 전에 클러스터를 구현하고 구성해야 합니다. Exchange 설치 프로그램(및 Exchange 저장소, Exchange System Attendant 등의 다른 Microsoft Exchange 구성 요소)은 클러스터 인식 프로그램이므로, 독립 실행형 서버에서 실행될 때와 다르게 작동합니다. Exchange를 독립 실행형 Windows 서버에 이미 설치했으면 먼저 Exchange를 제거하고, 클러스터를 구현한 후, 클러스터 인식 버전의 설치 프로그램을 사용하여 Exchange를 다시 설치해야만 해당 서버에 고가용성을 구성할 수 있습니다.

Microsoft Exchange Server 2010에서는 증분 배포로 알려진 개념을 사용하여 고가용성과 사이트 복구를 실현합니다. 이전 버전과는 달리 Exchange 2010에서는 고가용성을 위한 클러스터 리소스 모델을 더 이상 사용할 수 없습니다. 이러한 아키텍처의 변화로 이제 설치 프로그램의 클러스터 인식 버전이 없고, 설치하는 동안 사용자가 고가용성을 구성하지 않습니다. 대신에 모든 Exchange 2010 서버를 독립 실행형 서버로 간단히 설치한 후 필요에 따라 사서함 서버와 사서함 데이터베이스를 추가로 구성하여 가용성 및 사이트 복구 기능을 향상시킬 수 있습니다.

배포 프로세스 개요

각 조직에서 사용하는 실제 단계는 약간씩 다를 수 있지만 고가용 또는 사이트 복구 구성의 Exchange 2010을 배포하는 전체 프로세스는 일반적으로 동일합니다. DAG(데이터베이스 가용성 그룹)를 구성 및 배포하고 사서함 데이터베이스 복사본을 만들기 위해 필요한 계획 및 디자인 작업을 수행한 후 다음과 같이 합니다.

  1. DAG를 만듭니다. 자세한 단계는 데이터베이스 사용 가능 그룹 만들기를 참조하십시오.

  2. 필요한 경우 CNO(클러스터 이름 개체)를 사전 준비합니다. Windows Server 2012를 실행 중인 사서함 서버를 사용하여 DAG를 배포할 경우 CNO 사전 준비가 필요합니다. 사전 준비는 컴퓨터 계정 만들기가 제한되거나 컴퓨터 계정이 기본 컴퓨터 컨테이너가 아닌 컨테이너에서 만들어지는 환경에서도 필요합니다. 자세한 단계는 데이터베이스 가용성 그룹에 대한 클러스터 이름 개체 미리 준비를 참조하십시오.

  3. 둘 이상의 사서함 서버를 DAG에 추가합니다. 자세한 단계는 데이터베이스 사용 가능 그룹 구성원 관리를 참조하십시오.

  4. 필요에 맞게 DAG 속성을 구성합니다.

    1. 필요에 따라 DAG 암호화 및 압축, 복제 포트, DAG IP 주소 및 기타 DAG 속성을 구성합니다. 자세한 단계는 데이터베이스 가용성 그룹 속성 구성을 참조하십시오.

    2. DAG가 여러 Active Directory 사이트에 배포된 사서함 서버를 셋 이상 포함하는 경우 DAC(데이터 센터 활성화 조정) 모드를 사용해야 합니다. 자세한 내용은 데이터 센터 활성화 조정 모드 이해를 참조하십시오.

    3. DAG 네트워크를 만드는 방법에 대한 자세한 단계는 데이터베이스 가용성 그룹 네트워크 만들기를 참조하십시오. DAG 네트워크를 관리하려면 데이터베이스 가용성 그룹 네트워크 속성 구성을 참조하십시오.

  5. 사서함 서버의 사서함 데이터베이스 복사본을 DAG에 추가합니다. 자세한 단계는 사서함 데이터베이스 복사본 추가를 참조하십시오.

배포 예: 두 데이터 센터의 네 구성원 DAG

이 예에서는 Contoso, Ltd.라는 조직이 두 물리적 위치에 확장될 네 구성원 DAG를 구성 및 배포하는 방법을 자세히 설명합니다. Active Directory SITEA라는 기본 데이터 센터와 Active Directory SITEB라는 보조 데이터 센터가 있습니다. SITEA는 Redmond, Washington에 있고 SITEB는 Dublin, Ireland에 있습니다.

기본 인프라

각 위치에는 Exchange 2010을 기반으로 메시징 인프라를 운영하는 데 필요한 다음과 같은 인프라 요소가 포함되어 있습니다.

  • 디렉터리 서비스(Active Directory 또는 AD DS(Active Directory))

  • DNS(Domain Name System) 이름 확인

  • 하나 이상의 Exchange 2010 클라이언트 액세스 서버

  • 하나 이상의 Exchange 2010 허브 전송 서버

  • 하나 이상의 Exchange 2010 사서함 서버

참고

클라이언트 액세스, 허브 전송 및 사서함 서버 역할은 한 컴퓨터에 공존할 수 있습니다. 이 예에서 서버 역할은 별도의 컴퓨터에 설치되어 있습니다.

다음 그림에서는 Contoso 구성을 보여 줍니다.

두 사이트 간에 확장된 데이터베이스 사용 가능 그룹

두 사이트에 걸쳐 있는 데이터베이스 사용 가능 그룹

사서함 서버를 제외하고, Contoso 환경의 모든 서버는 Windows Server 2008 R2 Standard 운영 체제를 실행하고 있습니다. DAG와 함께 계획했던 사서함 서버는 Windows Server 2008 R2 Enterprise를 실행하고 있습니다.

이 인프라 구성 요소 외에도, 각 위치에는 Edge 전송 서버와 통합 메시징 서비스 등의 다른 메시징 요소가 포함되어 있습니다.

네트워크 구성

이전 그림에서 설명한 대로 솔루션은 여러 서브넷과 여러 네트워크의 사용을 포함합니다. DAG의 각 사서함 서버는 개별 서브넷에 두 개의 네트워크 어댑터를 갖습니다. 각 사서함 서버에서 네트워크 어댑터 하나는 MAPI 네트워크(192.168.x.x)에 사용되고 하나는 복제 네트워크(10.0.x.x)에 사용됩니다. MAPI 네트워크만 Active Directory, DNS 서비스, 다른 Exchange 서버와 클라이언트에 대한 연결을 제공합니다. 각 구성원의 복제 네트워크에 사용되는 어댑터는 DAG의 다른 구성원의 복제 네트워크 어댑터에만 연결을 제공합니다.

각 노드의 각 네트워크 어댑터에 대한 설정은 다음 표에 자세히 나와 있습니다.

이름 IPv4 주소 서브넷 마스크 기본 게이트웨이

MBX1A(MAPI)

192.168.1.4

255.255.255.0

192.168.1.1

MBX2A(MAPI)

192.168.1.5

255.255.255.0

192.168.1.1

MBX1B(MAPI)

192.168.2.4

255.255.255.0

192.168.2.1

MBX2B(MAPI)

192.168.2.5

255.255.255.0

192.168.2.1

MBX1A(복제)

10.0.1.4

255.255.0.0

없음

MBX2A(복제)

10.0.1.5

255.255.0.0

없음

MBX1B(복제)

10.0.2.4

255.255.0.0

없음

MBX2B(복제)

10.0.2.5

255.255.0.0

없음

이 표에 나와 있는 대로, 복제 네트워크에 사용되는 어댑터는 기본 게이트웨이를 사용하지 않습니다. 각 복제 네트워크 어댑터 간에 네트워크 연결을 제공하기 위해 Contoso에서는 Netsh.exe 도구를 사용하여 구성하는 영구적인 정적 루트를 사용합니다. Netsh.exe는 명령 프롬프트에서 Windows 기반 컴퓨터를 구성 및 모니터링하는 데 사용할 수 있는 도구입니다. Netsh.exe 도구를 사용하면 상황에 맞는 명령을 입력하여 적절한 도우미를 호출한 후 그 도우미가 명령을 실행하도록 할 수 있습니다. 도우미는 동적 링크 라이브러리 파일(.dll)로서 하나 이상의 서비스, 유틸리티 또는 프로토콜에 대한 구성, 모니터링 및 지원을 제공하는 방법으로 Netsh.exe 도구의 기능을 확장합니다.

MBX1A와 MBX2A의 복제 네트워크 어댑터에 대한 라우팅을 구성하기 위해 각 서버에서 다음 명령을 실행했습니다.

netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254

MBX1B와 MBX2B의 복제 네트워크 어댑터에 대한 라우팅을 구성하기 위해 각 서버에서 다음 명령을 실행했습니다.

netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254

다음 추가 네트워크 설정도 구성했습니다.

  • 각 DAG 구성원의 MAPI 네트워크 어댑터에 대해서는 DNS에 이 연결의 주소를 등록 확인란이 선택되고, 각 복제 네트워크 어댑터에서는 이 확인란의 선택이 취소됩니다.

  • 각 DAG 구성원의 MAPI 네트워크 어댑터에 대해서는 적어도 하나의 DNS 서버 주소가 구성되고, 복제 네트워크 어댑터에 대해서는 아무것도 구성되지 않습니다. 중복을 위해, Contoso는 MAPI 네트워크 어댑터에 여러 DNS 서버 주소를 사용하고 있습니다.

  • Contoso는 IPv6을 사용하지 않으며, 서버에서 이 프로토콜을 사용하지 않도록 설정했습니다.

  • Contoso는 Windows 방화벽을 사용하지 않으며, 서버에서 이 기능을 해제했습니다.

네트워크 어댑터를 구성한 후 Contoso는 DAG를 만들고 DAG에 사서함 서버를 추가할 준비를 완료했습니다.

데이터베이스 가용성 그룹 만들기 및 구성

관리자는 여러 작업을 수행하는 Windows PowerShell 명령줄 인터페이스 스크립트를 사용하기로 결정했습니다.

다음은 스크립트에 사용된 명령입니다.

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer HUB-A -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8

이 명령으로 DAG1이라는 DAG를 만들고, Hub-A를 미러링 모니터 서버로 구성하고, 특정 미러링 모니터 디렉터리(C:\DAGWitness\DAG1.contoso.com)를 구성하고, DAG에 두 개의 IP 주소(MAPI 네트워크의 각 서브넷에 하나씩)를 구성합니다.

Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer HUB-B

이 명령은 DAG1이 Hub-B의 대체 미러링 모니터 서버와 Hub-B의 대체 미러링 모니터 디렉터리(Hub-A에 구성된 동일한 경로 사용)를 사용하도록 구성합니다.

참고

동일한 경로를 필수적으로 사용해야 하는 것은 아닙니다. Contoso는 구성을 표준화하기 위해 동일한 경로를 사용하도록 선택했습니다.

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1B
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2B

이 명령은 각 사서함 서버를 한 번에 하나씩 DAG에 추가합니다. 또한 각 사서함 서버에 Windows 장애 조치(failover) 클러스터링 구성 요소도 설치하고(아직 설치하지 않은 경우), 장애 조치(failover) 클러스터를 만들고, 새로 만든 클러스터에 각 사서함 서버를 가입시킵니다.

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

이 명령은 DAG에 대해 DAC 모드를 사용하도록 설정합니다.

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

DAG를 만들고 DAG에 사서함 서버를 추가한 후 Contoso는 사서함 데이터베이스와 사서함 데이터베이스 복사본을 만들 준비를 합니다. 오류를 견디기 위한 조건을 충족하기 위해, Contoso는 지연되지 않은 데이터 베이스 복사본 세 개와 지연된 데이터베이스 복사본 하나로 각 사서함 데이터베이스를 구성할 계획을 세웁니다. 지연된 복사본은 3일의 구성된 로그 재생 지연을 갖게 됩니다.

이 구성으로 각 데이터베이스에 대한 총 4개(활성 1개, 지연되지 않은 수동 2개, 지연된 수동 1개)의 복사본이 제공됩니다. Contoso는 서버당 네 개의 활성 데이터베이스를 갖는 계획을 세웁니다. 서버당 활성 데이터베이스 4개와 각 데이터베이스의 수동 복사본 3개를 비롯하여, Contoso 솔루션은 총 16개의 데이터베이스 복사본을 포함합니다.

다음 그림에 나와 있는 대로, Contoso는 데이터베이스 레이아웃에 균형 잡힌 접근 방식을 취하고 있습니다.

Contoso, Ltd의 데이터베이스 복사본 레이아웃

Contoso, Ltd의 데이터베이스 복사본 레이아웃

각 사서함 서버는 한 개의 활성 사서함 데이터베이스 복사본, 두 개의 지연되지 않은 수동 데이터베이스 복사본 및 한 개의 지연된 수동 데이터베이스 복사본을 호스트합니다. 각 활성 사서함 데이터베이스의 지연된 복사본은 다른 사이트의 사서함 서버에서 호스트됩니다.

이 구성을 만들기 위해 관리자는 여러 명령을 실행합니다.

MBX1A에 대해 다음 명령을 실행합니다.

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX1B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -SuspendComment "Seed from MBX2B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX1B -SourceServer MBX2B
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -ActivationOnly

MBX2A에 대해 다음 명령을 실행합니다.

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX2B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -SuspendComment "Seed from MBX1B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX2B -SourceServer MBX1B
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -ActivationOnly

MBX1B에 대해 다음 명령을 실행합니다.

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -SuspendComment "Seed from MBX2A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1A -SourceServer MBX2A
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -ActivationOnly

MBX2B에 대해 다음 명령을 실행합니다.

Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -SuspendComment "Seed from MBX1A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2A -SourceServer MBX1A
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -ActivationOnly

Add-MailboxDatabaseCopy cmdlet에 대한 위 예에서 ActivationPreference 매개 변수는 지정되지 않았습니다. 추가된 각 복사본을 사용하여 활성화 기본 설정 번호가 자동으로 증가합니다. 원본 데이터베이스는 항상 우선 설정 번호 1을 갖고, Add-MailboxDatabaseCopy cmdlet을 사용하여 추가된 첫 복사본에 우선 설정 번호 2가 자동으로 할당되며, 제거되는 복사본이 없다는 가정 하에 그 다음 추가된 복사본에 우선 설정 번호 3이 할당됩니다. 따라서, 위 예에서는 활성 복사본과 같은 데이터 센터의 수동 복사본이 활성화 우선 설정 번호 2를 갖고, 원격 데이터 센터의 지연되지 않은 수동 복사본이 활성화 우선 설정 번호 3을 가지며, 원격 데이터 센터의 지연된 수동 복사본이 활성화 우선 설정 번호 4를 갖습니다.

다른 위치의 WAN에 걸쳐 있는 각 활성 데이터베이스의 복사본은 두 개지만 WAN을 통한 시드는 한 번만 수행되었습니다. 이는 Contoso가 Exchange 2010의 기능을 활용하여 데이터베이스의 수동 복사본을 시드의 원본으로 사용하고 있기 때문입니다. Add-MailboxDatabaseCopy cmdlet에 SeedingPostponed 매개 변수를 함께 사용하면 만들어지는 새 데이터베이스 복사본이 자동으로 시드되는 일이 방지됩니다. 그러면 관리자는 시드되지 않은 복사본을 일시 중단하고, Update-MailboxDatabaseCopy cmdlet에 SourceServer 매개 변수를 사용하여 데이터베이스의 로컬 복사본을 시드 작업의 원본으로 지정할 수 있습니다. 따라서, 각 위치로 추가되는 보조 데이터베이스 복사본의 시드는 WAN을 통하지 않고 로컬로 수행됩니다.

참고

위 예에서 지연되지 않은 데이터베이스 복사본은 WAN을 통해 시드되고, 이 복사본은 지연되지 않은 복사본과 같은 데이터 센터에 있는 데이터베이스의 지연된 복사본을 시드하는 데 사용됩니다.

Contoso는 거의 발생하지는 않지만 치명적인 데이터베이스 논리적 손상에 대한 보호를 제공하기 위해 각 사서함 데이터베이스의 수동 복사본 중 하나를 지연된 데이터베이스 복사본으로 구성했습니다. 그 결과로, 관리자는 Suspend-MailboxDatabaseCopy cmdlet에 ActivationOnly 매개 변수를 사용하여 지연된 복사본이 활성화에 대해 차단되도록 구성하고 있습니다. 이렇게 하면 데이터베이스 또는 서버 장애 조치(failover)가 수행되는 경우 지연된 데이터베이스 복사본이 활성화되지 않습니다.

솔루션 유효성 검사

솔루션을 배포하고 구성한 후, 관리자는 DAG에서 프로덕션 사서함을 데이터베이스로 이동하기에 앞서 솔루션의 준비 상태를 검사하는 작업을 수행합니다. 솔루션을 테스트할 때는 오류 시뮬레이션을 포함한 몇 가지 방법을 사용해야 합니다. 솔루션의 유효성을 확인하기 위해 관리자는 다음과 같은 몇 가지 작업을 수행합니다.

DAG의 전반적인 상태를 확인하기 위해 Test-ReplicationHealth cmdlet을 실행합니다. 이 cmdlet은 복제 및 재생 상태를 검사하여 DAG의 각 사서함 서버와 데이터베이스 복사본에 대한 정보를 제공합니다.

복제 및 재생 작업을 확인하기 위해 Get-MailboxDatabaseCopyStatus cmdlet을 실행합니다. 이 cmdlet은 특정 서버의 모든 사서함 데이터베이스 복사본 또는 특정 사서함 데이터베이스 복사본에 대한 실시간 상태 정보를 제공할 수 있습니다. DAG의 복제된 데이터베이스 상태 모니터링에 대한 자세한 내용은 고가용성 및 사이트 복구 모니터링을 참조하십시오.

전환 작업을 예상한 대로 진행하기 위해 Move-ActiveMailboxDatabase cmdlet을 사용하여 일련의 데이터베이스 전환 및 서버 전환을 수행합니다. 이 작업들이 성공적으로 완료되면 관리자는 같은 cmdlet을 사용하여 활성 데이터베이스 복사본을 원래 위치로 이동합니다.

다양한 오류 시나리오에서 예상되는 동작을 확인하기 위해 오류를 시뮬레이션하거나 실제로 오류가 발생하도록 하는 여러 가지 작업을 수행합니다. 예를 들면 관리자는 다음과 같이 할 수 있습니다.

  • MBX1A에서 전원 코드를 분리하여 서버 장애 조치(failover)가 수행되도록 합니다. 그런 다음 DB1이 다른 서버(활성화 기본 설정 값에 따르면 MBX2A)에서 활성 상태가 되었는지 확인합니다.

  • MBX2A에서 MAPI 네트워크 어댑터의 네트워크 케이블을 분리하여 서버 장애 조치(failover)가 수행되도록 합니다. 그런 다음 DB2가 다른 서버(활성화 기본 설정 값에 따르면 MBX1A)에서 활성 상태가 되었는지 확인합니다.

  • DB3의 활성 복사본에 사용되는 디스크를 오프라인으로 만들어 서버 장애 조치(failover)가 수행되도록 합니다. 그런 다음 DB3이 다른 서버(활성화 기본 설정 값에 따르면 MBX2B)에서 활성 상태가 되었는지 확인합니다.

비즈니스 요구 사항에 따라 조직에서 테스트할 다른 오류 시나리오가 있을 수 있습니다. 전원 플러그를 뽑는 것 같은 단일 오류를 시뮬레이션하고 솔루션의 복구 동작을 확인한 후, 관리자는 솔루션을 원래 구성으로 되돌려야 합니다. 경우에 따라서는 여러 동시 오류에 대해 솔루션을 테스트할 수 있습니다. 궁극적으로, 솔루션 테스트 계획은 각 오류 시뮬레이션이 완료된 후 솔루션이 원래 구성으로 돌아가는지 여부를 알려줍니다.

또한, 관리자는 두 데이터 센터 간 네트워크 연결을 끊어 사이트 오류가 시뮬레이션되도록 합니다. 데이터 센터 전환 수행은 한층 더 복잡하고 조화가 필요한 프로세스지만, 배포할 솔루션이 메시징 서비스와 데이터에 대한 사이트 복구를 제공할 목적을 가진 경우 권장되는 프로세스입니다. 데이터 센터 전환에 대한 자세한 내용은 데이터 센터 전환을 참조하십시오.

작업 전환

솔루션을 배포한 후 증분 배포를 통해 더욱 확장할 수 있습니다. 이러한 점에서 솔루션 관리는 다음 작업이 수행되는 작업 프로세스로의 전환이기도 합니다.

솔루션 관리에 대한 자세한 내용은 고가용성 및 사이트 복구 관리를 참조하십시오.

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