개요

• Planning Mailbox Servers for High Availability
• Exchange Server 2013을 위한 고가용성 계획

 

고가용성 및 사이트 복구

적용 대상: Exchange Server 2013
마지막으로 수정된 항목: 2014-07-01

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

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

목차

• 주요 용어
• 데이터베이스 가용성 그룹
• 사서함 데이터베이스 복사본
• Active Manager
• 사이트 복구
• 타사 복제 API
• 고가용성 및 사이트 복구 설명서

출처: <http://technet.microsoft.com/ko-kr/library/dd638137(v=exchg.150).aspx>

 

이전 버전에 비해 달라진 고가용성 및 사이트 복구 기능

적용 대상: Exchange Server 2013 SP1, Exchange Server 2013
마지막으로 수정된 항목: 2014-07-24

Exchange 2013에서는 DAG 및 사서함 데이터베이스 복사본과 함께 단일 항목 복구, 보존 정책, 지연된 데이터베이스 복사본 등의 다른 기능을 사용하여 고가용성, 사이트 복구 및 Exchange 고유 데이터 보호가 제공됩니다. 고가용성 플랫폼인 Exchange 정보 저장소와 ESE(Extensible Storage Engine)는 모두 탁월한 가용성 및 관리 용이성을 제공하고 비용을 절감하도록 향상되었습니다. 향상된 기능은 다음과 같습니다.

• Exchange 2010에 비해 IOPS 감소   더 큰 디스크를 용량 및 IOPS 면에서 가능한 한 효율적으로 사용할 수 있습니다.
• 관리되는 가용성   관리되는 가용성을 통해 내부 모니터링 및 복구 지향 기능이 긴밀하게 통합되어 오류를 방지하거나, 서비스를 능동적으로 복원하거나, 서버 장애 조치(failover)를 자동으로 시작하거나, 관리자에게 조치를 취하도록 경고할 수 있습니다. 핵심은 서비스를 지속적으로 사용 가능한 상태로 유지할 수 있도록 서버 및 구성 요소의 작동 시간뿐만 아니라 최종 사용자 환경을 모니터링하고 관리하는 데 있습니다.
• 관리되는 저장소   관리되는 저장소는 Exchange 2013에서 새롭게 다시 작성된 정보 저장소 프로세스의 이름입니다. 새로운 관리되는 저장소는 C#으로 작성되었으며 Microsoft Exchange Replication Service(MSExchangeRepl.exe)와 밀접하게 통합되어 개선된 복원력을 통해 더 높은 가용성이 제공됩니다.
• 디스크당 여러 데이터베이스 지원 Exchange 2013에는 동일한 디스크에서 여러 데이터베이스(활성 및 수동 복사본의 혼합)를 지원할 수 있는 개선 사항이 포함되어 용량과 IOPS 면에서 더 큰 디스크를 최대한 효율적으로 활용할 수 있습니다.
• AutoReseed   자동 다시 시드 기능을 사용하여 디스크 오류 후 데이터베이스 중복성을 신속하게 복원할 수 있습니다. 디스크 오류가 발생하면 해당 디스크에 저장된 데이터베이스 복사본이 활성 데이터베이스 복사본에서 동일한 서버의 예비용 디스크로 복사됩니다. 여러 데이터베이스 복사본이 실패한 디스크에 저장된 경우 해당 복사본을 모두 자동으로 예비용 디스크에 다시 시드할 수 있습니다. 이렇게 하면 활성 데이터베이스가 여러 서버에 있을 가능성이 높아지고 데이터가 병렬로 복사되므로 다시 시드 속도가 더 빨라집니다.
• 저장소 오류에서 자동 복구   이 기능은 Exchange 2010에서 도입된 혁신적인 기능을 뒤이어 시스템에서 복원력 또는 중복성에 영향을 주는 오류를 복구할 수 있도록 지원됩니다. Exchange 2010 버그 검사 동작 외에도 Exchange 2013에는 긴 I/O 시간, MSExchangeRepl.exe의 과도한 메모리 사용 및 시스템이 스레드를 예약할 수 없는 잘못된 상태에 있는 심각한 경우를 위한 추가 복구 동작이 포함되어 있습니다.
• 지연된 복사본 기능 향상   지연된 복사본은 자동 로그 재생을 사용하여 일정 한도에서 자체적으로 처리될 수 있습니다. 지연된 복사본은 페이지 패치, 낮은 디스크 공간 시나리오 같은 다양한 상황에서 로그 파일의 재생 속도를 자동으로 늦춥니다. 시스템이 지연된 복사본에 대한 페이지 패치가 필요하다고 감지하면 페이지 패치를 수행하기 위해 자동으로 로그가 지연된 복사본으로 재생됩니다. 지연된 복사본은 낮은 디스크 공간 임계값에 도달한 경우와 지연된 복사본이 특정 기간 동안 유일하게 사용할 수 있는 복사본으로 감지된 경우에도 이 자동 재생 기능을 호출합니다. 또한 지연된 복사본은 보안 네트워크를 이용하여 복구나 활성화를 훨씬 더 쉽게 만들 수 있습니다.
• 단일 복사본 경고 기능 향상 Exchange 2010에 도입된 단일 복사본 경고는 더 이상 별도의 예약된 스크립트가 아닙니다. 이 기능은 이제 시스템 내의 관리되는 가용성 구성 요소에 통합되었으며 Exchange 내의 기본 기능입니다.
• DAG 네트워크 자동 구성   시스템에서 구성 설정을 기반으로 DAG 네트워크를 자동으로 구성할 수 있습니다. 수동 구성 옵션 외에도 DAG가 자동으로 MAPI 네트워크와 복제 네트워크를 구분하고 DAG 네트워크를 구성할 수 있습니다.

출처: <http://technet.microsoft.com/ko-KR/library/dn789066(v=exchg.150).aspx>

 

데이터베이스 가용성 그룹

적용 대상: Exchange Server 2013
마지막으로 수정된 항목: 2014-06-18

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

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

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

목차

• 데이터베이스 사용 가능 그룹 수명 주기
• 고가용성을 위해 데이터베이스 사용 가능 그룹 사용
• 사이트 복구를 위해 데이터베이스 사용 가능 그룹 사용

출처: <http://technet.microsoft.com/ko-KR/library/dd979799(v=exchg.150).aspx>

 

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

적용 대상: Exchange Server 2013
마지막으로 수정된 항목: 2013-04-05

Microsoft Exchange Server 2013은 Exchange에서 관리되는 데이터베이스 수준 장애 조치인 데이터 이동성이라는 개념을 활용합니다. 데이터베이스 이동성은 서버에서 데이터베이스를 분리하고, 단일 데이터베이스의 복사본을 최대 16개까지 지원하며, 데이터베이스에 데이터베이스 복사본을 추가합니다.

주요 특징

사서함 데이터베이스 복사본의 주요 특징은 다음과 같습니다.

• DAG(데이터베이스 사용 가능 그룹)로 그룹화한 여러 사서함 서버에 Exchange 2013 사서함 데이터베이스 복사본을 16개까지 만들 수 있습니다. 이때 DAG는 연속 복제의 경계가 되고, Exchange 2013 사서함 데이터베이스는 DAG 내의 다른 Exchange 2013 사서함 서버에만 복제할 수 있습니다. DAG 외부로 데이터베이스를 복제하거나 Exchange 2013 사서함 데이터베이스를 Exchange 2010 이하 버전을 실행 중인 서버로 복제할 수는 없습니다. DAG에 대한 자세한 내용은 데이터베이스 가용성 그룹를 참조하십시오.
• DAG의 모든 사서함 서버는 동일한 Active Directory 도메인에 속해 있어야 합니다.
• 사서함 데이터베이스 복사본은 재생 지연 시간 및 자르기 지연 시간의 개념을 지원합니다. 단, 이러한 기능을 사용하려면 적절한 계획을 수립해야 합니다.
• 모든 데이터베이스 복사본은 Exchange 인식 VSS(볼륨 섀도 복사본 서비스) 기반 백업 응용 프로그램을 사용하여 백업할 수 있습니다.
• 데이터베이스 복사본은 데이터베이스의 활성 복사본을 호스트하지 않는 사서함 서버에만 만들 수 있습니다. 같은 서버에 같은 데이터베이스의 복사본을 2개 이상 만들 수 없습니다.
• 특정 데이터베이스의 모든 복사본은 복사본이 포함된 각 서버에서 동일한 경로를 사용합니다. 각 사서함 서버에서 데이터베이스 복사본의 데이터베이스 및 로그 파일 경로는 다른 데이터베이스 경로와 서로 충돌하지 않아야 합니다.
• 데이터베이스 복사본은 같은 네트워크 서브넷 또는 다른 네트워크 서브넷의 같거나 다른 Active Directory 사이트에 만들 수 있습니다.
• 왕복 네트워크 대기 시간이 500밀리초를 초과하는 사서함 서버 간에는 데이터베이스 복사본이 지원되지 않습니다.

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

사서함 데이터베이스 복사본은 언제든지 만들 수 있으며, 유연하고 세분화된 방식으로 사서함 서버 간에 배포할 수 있습니다.

Exchange 관리 센터에서 사서함 데이터베이스 복사본 추가 마법사를 사용하거나 Exchange 관리 셸에서 Add-MailboxDatabaseCopy cmdlet을 사용하여 사서함 데이터베이스 복사본을 만들 수 있습니다.

사서함 데이터베이스 복사본을 만들 때에는 다음 매개 변수를 지정해야 합니다.

• Identity   이 매개 변수는 복사되는 데이터베이스의 이름을 지정합니다. 데이터베이스 이름은 Exchange 조직 내에서 고유해야 합니다.
• MaliboxServer   이 매개 변수는 데이터베이스 복사본을 호스트할 사서함 서버의 이름을 지정합니다. 이 서버는 동일한 DAG의 구성원이어야 하고 데이터베이스 복사본을 호스트하고 있지 않아야 합니다.

필요에 따라 다음을 지정할 수도 있습니다.

• ActivationPreference 이 매개 변수는 Active Manager의 최상의 복사본 선택 프로세스의 일부로 사용되는 활성화 기본 설정 수를 지정합니다. 또한 RedistributeActiveDatabases.ps1 스크립트를 사용할 때 DAG 전체에 활성 사서함 데이터베이스를 재배포하는 데 사용됩니다. 활성화 기본 설정의 값이 1보다 크거나 같은 숫자이며, 1이 기본 설정 순서에서 맨 위입니다. 위치 수는 사서함 데이터베이스 복사본의 수보다 클 수 없습니다.
• ReplayLagTime   이 매개 변수는 Microsoft Exchange 복제 서비스가 데이터베이스 복사본에 복사된 로그 파일을 재생하기 전에 대기해야 하는 시간을 지정합니다. 이 매개 변수에 대한 형식은 (일.시:분:초)입니다. 이 값의 기본 설정은 0초입니다. 이 값에 대한 최대 허용 설정은 14일이며, 최소 허용 설정은 0초입니다. 재생 지연 시간 값을 0으로 설정하면 로그 재생 지연이 해제됩니다.
• TruncationLagTime   이 매개 변수는 Microsoft Exchange 복제 서비스가 데이터베이스 복사본으로 재생된 로그 파일을 자르기 전에 대기해야 하는 시간을 지정합니다. 해당 기간은 로그가 데이터베이스의 복사본으로 재생된 후에 시작됩니다. 이 매개 변수에 대한 형식은 (일.시:분:초)입니다. 이 값의 기본 설정은 0초입니다. 이 값에 대한 최대 허용 설정은 14일이며, 최소 허용 설정은 0초입니다. 자르기 지연 시간 값을 0으로 설정하면 로그 자르기 지연이 해제됩니다.
• SeedingPostponed    이 매개 변수는 해당 작업이 지정된 사서함 서버의 데이터베이스 복사본을 자동으로 시드하지 않도록 지정합니다. 데이터베이스의 기존 수동 복사본을 사용하여 새 사서함 데이터베이스 복사본을 시드하려고 하는 경우(예를 들어, 특정 데이터베이스의 두 번째 복사본을 원격 위치에 추가) 일반적으로 이 옵션이 사용됩니다. 이 매개 변수를 사용하는 경우, Update-MailboxDatabaseCopy cmdlet을 사용하여 데이터베이스 복사본을 수동으로 시드해야 합니다.

사서함 데이터베이스 복사본을 만들고 사용하고 관리하는 방법에 대한 자세한 내용은 사서함 데이터베이스 복사본 관리를 참조하십시오.

출처: <http://technet.microsoft.com/ko-KR/library/dd979802(v=exchg.150).aspx>

 

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

적용 대상: Exchange Server 2013
마지막으로 수정된 항목: 2014-03-07

DAG(데이터베이스 사용 가능 그룹)가 생성되고 구성된 후 사서함 서버 구성원으로 채워지면 EAC(Exchange 관리 센터) 또는 Exchange 관리 셸을 사용하여 사서함 데이터베이스 복사본을 유연하고 세밀한 방식으로 추가할 수 있습니다.

데이터베이스 복사본 관리

데이터베이스의 복사본이 여러 개 만들어진 후에는 EAC 또는 셸을 사용하여 각 복사본의 상태를 모니터링하고 데이터베이스 복사본과 관련된 다른 관리 작업을 수행할 수 있습니다. 이러한 관리 작업에는 데이터베이스 복사본 일시 중단 또는 다시 시작, 데이터베이스 복사본 시드, 데이터베이스 복사본 모니터링, 데이터베이스 복사본 설정 구성, 데이터베이스 복사본 제거 등이 있습니다.

데이터베이스 복사본 일시 중단 및 다시 시작

계획한 유지 관리 수행 같은 다양한 이유로, 데이터베이스 복사본에 대한 연속 복제 작업을 일시 중단하고 다시 시작해야 할 경우가 있습니다. 또한 시드 등의 일부 관리 작업에서는 먼저 데이터베이스 복사를 일시 중단해야 합니다. 데이터베이스의 경로 또는 그 로그 파일을 변경할 경우 모든 복제 작업을 일시 중단하는 것이 좋습니다. EAC를 사용하거나 셸에서 Suspend-MailboxDatabaseCopy 및 Resume-MailboxDatabaseCopy cmdlet을 실행하여 데이터베이스 복사본 작업을 일시 중단하고 다시 시작할 수 있습니다. 데이터베이스 복사본의 연속 복제 작업을 일시 중단하거나 다시 시작하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본 일시 중지 또는 다시 시작을 참조하십시오.

데이터베이스 복사본 시드

업데이트라고도 하는 시드는 빈 데이터베이스 또는 프로덕션 데이터베이스의 복사본인 데이터베이스가 활성 데이터베이스와 동일한 DAG에 있는 다른 사서함 서버의 대상 복사 위치에 추가되는 과정을 말합니다. 이는 해당 서버에서 유지 관리되는 복사본에 대한 기준 데이터베이스가 됩니다.

상황에 따라 시드를 자동으로 진행하거나 사용자가 수동으로 시작할 수 있습니다. 데이터베이스 복사본이 추가되면, 이 복사본은 대상 서버와 저장소가 적절히 구성되어 있는 경우 자동으로 시드됩니다. 복사본을 만드는 동안 자동 시드를 수행하지 않고 데이터베이스 복사본을 수동으로 복사하려면 Add-MailboxDatabaseCopy cmdlet을 실행할 때 SeedingPostponed 매개 변수를 사용합니다.

최초의 시드가 발생한 후 데이터베이스 복사본을 다시 시드해야 하는 일은 거의 없습니다. 그러나 다시 시드해야 할 상황이거나, 시스템에서 자동으로 복사본을 시드하게 하는 대신 데이터베이스 복사본을 수동으로 시드하려면 EAC에서 사서함 데이터베이스 복사본 업데이트 마법사를 사용하거나 셸에서Update-MailboxDatabaseCopy cmdlet을 사용하여 이 작업을 수행할 수 있습니다. 데이터베이스 복사본을 시드하기 전에 먼저 사서함 데이터베이스 복사본을 일시 중단해야 합니다. 데이터베이스 복사본을 시드하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본 업데이트을 참조하십시오.

수동 시드 작업이 완료된 후에는 시드된 사서함 데이터베이스 복사본에 대한 복제가 자동으로 다시 시작됩니다. 복제가 자동으로 다시 시작되지 않게 하려면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 ManualResume 매개 변수를 사용합니다.

시드 대상 선택

시드 작업을 수행할 때 사서함 데이터베이스 복사본이나 사서함 데이터베이스 복사본의 콘텐츠 인덱스 카탈로그 중 하나, 또는 데이터베이스 복사본과 콘텐츠 인덱스 카탈로그 복사본 둘 다를 시드하도록 선택할 수 있습니다. 사서함 데이터베이스 복사본 업데이트 마법사 및 Update-MailboxDatabaseCopy cmdlet의 기본 동작은 사서함 데이터베이스 복사본과 콘텐츠 인덱스 카탈로그 복사본 모두를 시드하는 것입니다. 콘텐츠 인덱스 카탈로그는 제외하고 사서함 데이터베이스 복사본만 시드하려면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 DatabaseOnly 매개 변수를 사용합니다. 콘텐츠 인덱스 카탈로그 복사본만 시드하려면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 CatalogOnly 매개 변수를 사용합니다.

시드 원본 선택

정상 상태인 데이터베이스 복사본을 이 데이터베이스의 추가 복사본에 대한 시드 원본으로 사용할 수 있습니다. 이것은 DAG가 여러 물리적 위치에 확장되어 있는 경우에 특히 유용합니다. 예를 들어 두 구성원(MBX1과 MBX2)은 Oregon 주의 Portland에 있고 두 구성원(MBX3과 MBX4)은 New York 주의 New York에 있는 네 구성원 DAG 배포를 가정해 보겠습니다. DB1이라는 사서함 데이터베이스가 MBX1에서 활성 상태이고 DB1의 수동 복사본이 MBX2 및 MBX3에 있습니다. DB1의 복사본을 MBX4에 추가할 때는 MBX3의 복사본을 시드 원본으로 사용할 수 있습니다. 이렇게 하면 Portland와 New York 간의 WAN 링크를 통한 시드를 피할 수 있습니다.

새 데이터베이스 복사본을 추가할 때 특정 복사본을 시드 원본으로 사용하려면 다음과 같은 작업을 수행합니다.

• Add-MailboxDatabaseCopy cmdlet을 실행할 때 SeedingPostponed 매개 변수를 사용하여 데이터베이스 복사본을 추가할 수 있습니다.SeedingPostponed 매개 변수를 사용하지 않으면 데이터베이스 복사본은 해당 데이터베이스의 활성 복사본을 원본으로 사용하여 명시적으로 시드됩니다.
• EAC에서 사서함 데이터베이스 복사본 업데이트 마법사의 일부로 사용할 원본 서버를 지정하거나, Update-MailboxDatabaseCopy cmdlet을 사용하여 원하는 시드 원본 서버를 지정할 때 SourceServer 매개 변수를 사용할 수 있습니다. 앞의 예에서는 MBX3을 원본 서버로 지정합니다.SourceServer 매개 변수를 사용하지 않으면 데이터베이스 복사본은 데이터베이스의 활성 복사본에서 명시적으로 시드됩니다.

시드 및 네트워크

사서함 데이터베이스 복사본 시드를 위한 특정 원본 서버를 선택할 수 있을 뿐만 아니라, 셸을 사용하여 사용하고자 하는 DAG 네트워크를 지정할 수도 있고 시드 작업 중에 DAG 네트워크의 압축 및 암호화 설정을 다시 정의할 수도 있습니다.

시드에 사용할 네트워크를 지정하려면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 Network 매개 변수를 사용하고 원하는 DAG 네트워크를 지정합니다. Network 매개 변수를 사용하지 않으면 시스템은 시드 작업에 사용할 네트워크를 선택할 때 다음과 같은 기본 방식을 사용합니다.

• 원본 서버와 대상 서버가 같은 서브넷에 있고 이 서브넷을 포함하는 복제 네트워크가 구성되어 있는 경우 복제 네트워크가 사용됩니다.
• 원본 서버와 대상 서버가 서로 다른 서브넷에 있는 경우 이들 서브넷을 포함하는 복제 네트워크가 구성되어 있더라도 클라이언트 (MAPI) 네트워크가 시드에 사용됩니다.
• 원본 서버와 대상 서버가 서로 다른 데이터 센터에 있는 경우 클라이언트 (MAPI) 네트워크가 시드에 사용됩니다.

DAG 수준에서, 암호화 및 압축을 위해 DAG 네트워크가 구성됩니다. 기본 설정은 다른 서브넷의 통신에만 암호화와 압축을 사용하는 것입니다. 원본 및 대상이 서로 다른 서브넷에 있고 DAG가 NetworkCompression 및 NetworkEncryption에 대한 기본값을 사용하여 구성되어 있다면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 NetworkCompressionOverride 및 NetworkEncryptionOverride 매개 변수를 각각 사용하여 이 값을 다시 정의할 수 있습니다.

시드 프로세스

Add-MailboxDatabaseCopy 또는 Update-MailboxDatabaseCopy cmdlet을 사용하여 시드 프로세스를 시작할 경우 다음 작업이 수행됩니다.

1. 지정된 데이터베이스 및 서버를 확인하기 위해, 그리고 원본 및 대상 서버가 Active Directory을 실행 중인지, 둘 다 같은 DAG의 구성원인지, 지정된 데이터베이스가 복구 데이터베이스가 아닌지를 확인하기 위해 Exchange 2013에서 데이터베이스 속성을 읽습니다. 또한 데이터베이스 파일 경로도 읽습니다.
2. 대상 서버의 Microsoft Exchange 복제 서비스에서 다시 시드 확인을 위한 준비 작업이 수행됩니다.
3. 대상 서버의 Microsoft Exchange 복제 서비스가 1단계에서 Active Directory 확인을 위해 읽은 파일 디렉터리에 데이터베이스와 트랜잭션 로그가 있는지 확인합니다.
4. Microsoft Exchange 복제 서비스가 대상 서버로부터 cmdlet을 실행한 관리 인터페이스로 상태 정보를 반환합니다.
5. 모든 사전 검사를 통과하면 작업을 계속할지 확인하는 메시지가 표시됩니다. 작업을 계속하기로 선택하면 프로세스가 계속됩니다. 사전 검사 중 오류가 발생할 경우 오류가 보고되고 작업이 실패합니다.
6. 시드 작업이 대상 서버의 Microsoft Exchange 복제 서비스에서 시작됩니다.
7. Microsoft Exchange 복제 서비스가 활성 데이터베이스 복사본의 데이터베이스 복제를 일시 중단합니다.
8. 데이터베이스에 대한 상태 정보가 시드 상태를 반영하도록 Microsoft Exchange 복제 서비스에 의해 업데이트됩니다.
9. 대상 서버에 대상 데이터베이스 및 로그 파일을 위한 디렉터리가 없으면 새로 만들어집니다.
10. 데이터베이스 시드 요청이 TCP를 사용하여 대상 서버의 Microsoft Exchange 복제 서비스에서 원본 서버의 Microsoft Exchange 복제 서비스로 전달됩니다. 이 요청 및 데이터베이스 시드를 위한 이후 통신은 복제 네트워크로 구성된 DAG 네트워크에서 일어납니다.
11. 원본 서버의 Microsoft Exchange 복제 서비스가 Microsoft Exchange 정보 저장소 인터페이스를 통해 ESE(Extensible Storage Engine) 스트리밍 백업을 시작합니다.
12. Microsoft Exchange 정보 저장소 서비스가 데이터베이스 데이터를 Microsoft Exchange 복제 서비스로 스트리밍합니다.
13. 데이터베이스 데이터가 원본 서버의 Microsoft Exchange 복제 서비스에서 대상 서버의 Microsoft Exchange 복제 서비스로 이동합니다.
14. 대상 서버의 Microsoft Exchange 복제 서비스는 temp-seeding이라는 주 데이터베이스 디렉터리에 있는 임시 디렉터리에 데이터베이스 복사본을 씁니다.
15. 데이터베이스의 끝에 도달하면 원본 서버의 스트리밍 백업 작업이 끝납니다.
16. 대상 서버에서의 쓰기 작업이 완료되고 데이터베이스가 temp-seeding 디렉터리에서 최종 위치로 이동합니다. temp-seeding 디렉터리가 삭제됩니다.
17. 대상 서버에서, Microsoft Exchange 복제 서비스가 Microsoft Exchange 검색 서비스로 요청을 프록시 처리하여 데이터베이스 복사본의 콘텐츠 인덱스 카탈로그가 있는 경우 이를 탑재합니다. 데이터베이스 복사본의 이전 인스턴스의 오래된 기존 카탈로그 파일이 있는 경우 탑재 작업이 실패하고, 이로 인해 원본 서버로부터 카탈로그를 복제해야 합니다. 마찬가지로, 대상 서버에 있는 데이터베이스 복사본의 새 인스턴스에 카탈로그가 없는 경우 카탈로그의 복제본이 필요합니다. Microsoft Exchange 복제 서비스는 원본에서 새 카탈로그가 복사되는 동안 데이터베이스 복사본에 대한 인덱싱을 일시 중단하도록 Microsoft Exchange 검색 서비스에 지시합니다.
18. 대상 서버의 Microsoft Exchange 복제 서비스가 원본 서버의 Microsoft Exchange 복제 서비스로 카탈로그 시드 요청을 보냅니다.
19. 원본 서버에서, Microsoft Exchange 복제 서비스가 Microsoft Exchange 검색 서비스에 디렉터리 정보를 요청하고 해당 인덱싱의 일시 중단을 요청합니다.
20. 원본 서버의 Microsoft Exchange 검색 서비스가 검색 카탈로그 디렉터리 정보를 Microsoft Exchange 복제 서비스에 반환합니다.
21. 원본 서버의 Microsoft Exchange 복제 서비스가 디렉터리에서 카탈로그 파일을 읽습니다.
22. 원본 서버의 Microsoft Exchange 복제 서비스가 복제 네트워크 내 연결을 사용하여 대상 서버의 Microsoft Exchange 복제 서비스로 카탈로그 데이터를 이동합니다. 읽기가 완료되면 Microsoft Exchange 복제 서비스는 원본 데이터베이스의 인덱싱을 다시 시작하기 위해 Microsoft Exchange 검색 서비스에 요청을 보냅니다.
23. 디렉터리의 대상 서버에 기존 카탈로그 파일이 있는 경우 대상 서버의 Microsoft Exchange 복제 서비스가 이를 삭제합니다.
24. 대상 서버의 Microsoft Exchange 복제 서비스가 카탈로그 데이터 전송이 완전히 끝날 때까지 CiSeed.Temp라는 임시 디렉터리에 카탈로그 데이터를 씁니다.
25. Microsoft Exchange 복제 서비스가 완전한 카탈로그 데이터를 최종 위치로 이동합니다.
26. 대상 서버의 Microsoft Exchange 복제 서비스가 대상 데이터베이스의 검색 인덱싱을 다시 시작합니다.
27. 대상 서버의 Microsoft Exchange 복제 서비스가 완료 상태를 반환합니다.
28. 이 작업의 최종 결과가 cmdlet을 호출한 관리 인터페이스로 전달됩니다.

데이터베이스 복사본 구성

데이터베이스 복사본이 만들어진 후, 필요한 경우 그 구성 설정을 보거나 수정할 수 있습니다. EAC에서 데이터베이스 복사본의 속성 페이지를 확인하면 일부 구성 정보를 볼 수 있습니다. 또한 셸에서 Get-MailboxDatabase 및 Set-MailboxDatabaseCopy cmdlet을 사용하여 재생 지연 시간, 자르기 지연 시간 및 활성화 기본 설정 순서 등의 데이터베이스 복사본 설정을 보거나 구성할 수 있습니다. 데이터베이스 복사본 설정을 보거나 구성하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본 속성 구성을 참조하십시오.

재생 지연 및 자르기 지연 옵션 사용

사서함 데이터베이스 복사본은 재생 지연 시간 및 자르기 지연 시간 또는 모두를 분 단위로 구성하여 사용하도록 지원합니다. 재생 지연 시간을 설정하면 데이터베이스 복사본을 특정 시점으로 되돌릴 수 있습니다. 자르기 지연 시간을 설정하면 수동 데이터베이스 복사본의 로그를 사용하여 활성 데이터베이스 복사본의 로그 파일 손실로부터 복구할 수 있습니다. 이러한 기능 모두는 임시 작성 로그 파일을 만들기 때문에 해당 기능을 사용하면 저장소 디자인에 영향을 미칩니다.

재생 지연 시간

재생 지연 시간은 데이터베이스 복사본에 대한 로그 재생을 지연하기 위해 분 단위로 시간을 지정하는 사서함 데이터베이스 복사본의 속성입니다. 재생 지연 타이머는 로그 파일이 수동 복사본에 복제되고 검사를 통과했을 때 시작됩니다. 데이터베이스 복사본에서 로그 재생을 지연하면 데이터베이스를 과거의 특정 시점으로 복구할 수 있습니다. 재생 지연 시간이 0보다 길게 구성된 사서함 데이터베이스 복사본은 지연된 데이터베이스 복사본 또는 간단히 지연된 복사본이라고 합니다.

Exchange 2013의 데이터베이스 복사본과 소송 보존 기능을 사용하는 전략은 일반적으로 데이터 손실을 초래할 수 있는 오류로부터 데이터를 보호합니다. 그러나 이러한 기능은 드물기는 하지만 논리적 손상으로 데이터가 손실되는 경우에는 데이터를 보호할 수 없습니다. 지연된 복사본은 논리적 손상으로부터 데이터 손실을 막기 위해 설계되었으며, 논리적 손상에는 일반적으로 두 가지 유형이 있습니다.

• 데이터베이스 논리적 손상   데이터베이스 페이지 체크섬은 일치하지만, 페이지의 데이터가 논리적으로 잘못되었습니다. 이러한 손상은 ESE가 데이터베이스 페이지 쓰기를 시도할 경우에 발생하며, 운영 체제에서 성공 메시지가 반환되더라도 이 데이터를 디스크에 쓰지 않았거나 잘못된 위치에 쓴 것입니다. 이를 손실 플러시라고 합니다. 데이터 손실로부터 손실 플러시를 방지하기 위해, ESE는 데이터베이스에 페이지 패치 기능(단일 페이지 복원)과 함께 손실 플러시 감지 메커니즘을 포함합니다.
• 저장소 논리적 손상   사용자가 예상하지 못한 방식으로 데이터가 추가되고, 삭제되고, 조작됩니다. 이러한 문제는 대부분 타사 응용 프로그램에 의해 발생합니다. 일반적으로 사용자가 이것을 손상으로 본다는 점에서 손상일 뿐이며, Exchange 저장소는 논리적 손상에서 생성된 트랜잭션을 일련의 유효한 MAPI 작업으로 간주합니다. Exchange 2013의 소송 보존 기능은 사용자나 응용 프로그램이 콘텐츠를 영구적으로 삭제하는 것을 방지하기 때문에 저장소 논리적 변조로부터의 보호를 제공합니다. 하지만 사용자 사서함이 너무 심하게 손상되어 데이터베이스를 손상 전 특정 시점으로 복원한 다음 사용자 사서함을 내보내고 손상되지 않은 데이터를 검색하는 것이 더 쉬운 시나리오가 있을 수 있습니다.

데이터베이스 복사본, 보존 정책, ESE 단일 페이지 복원을 조합하여 함께 사용하는 것은 드물게 발생하지만 매우 치명적인 저장소 논리적 손상인 경우로 제한합니다. 데이터베이스 복사본에 재생 지연(지연된 복사본)을 사용할지 여부는 어떤 타사 응용 프로그램을 사용하는지와 조직에 어떤 저장소 논리적 손상이 발생했었는지에 따라 결정합니다.

지연된 복사본을 사용하기로 선택하면 다음 의미를 알아야 합니다.

• 재생 지연 시간은 관리자가 구성하는 값이며 기본적으로 사용하지 않도록 설정되어 있습니다.
• 재생 지연 시간 설정은 기본적으로 0일이며, 최대 설정은 14일입니다.
• 지연된 복사본은 항상 사용 가능한 복사본으로 간주되지 않습니다. 대신, 저장소 논리적 손상으로부터 데이터를 보호하기 위해 재해 복구용으로 설계되었습니다.
• 재생 지연 시간을 크게 설정할수록 데이터베이스 복구 프로세스가 길어집니다. 복구하는 동안 재생해야 할 로그 파일의 수, 하드웨어가 로그 파일을 재생하는 속도에 따라 데이터베이스를 복구하는 데 수시간 또는 수일이 소요될 수도 있습니다.
• 지연된 복사본이 전반적인 재해 복구 전략에 반드시 필요한지 여부를 결정합니다. 재해 복구 전략에 지연된 복사본 사용이 필수적이면 지연된 복사본 여러 개를 사용하고, 만약 지연된 복사본이 하나뿐인 경우에는 RAID(Redundant Array of Independent Disks)를 사용하여 이 복사본을 보호하는 것이 좋습니다. 디스크가 손실되거나 손상이 발생하더라도 지연된 시점이 보존됩니다.
• 지연된 복사본은 ESE 단일 페이지 복원 기능에 패치되지 않습니다. 지연된 복사본에 데이터베이스 손상(예: a -1018 오류)이 발생하면 복사본의 지연된 부분이 손실되므로 다시 시드해야 합니다.

데이터베이스에서 모든 로그 파일을 재생하고 데이터베이스 복사본을 최신 상태로 만들려는 경우 지연된 사서함 데이터베이스 복사본을 활성화하고 복구하는 프로세스가 간단합니다. 로그 파일을 특정 시점까지 재생하려면 수동으로 로그 파일을 조작하고 Eseutil(Exchange Server Database Utilities) 도구를 실행해야 하기 때문에 작업이 더 복잡해집니다.

지연된 사서함 데이터베이스 복사본을 활성화하는 방법에 대한 자세한 단계는 지연된 사서함 데이터베이스 복사본 활성화를 참조하십시오.

자르기 지연 시간

자르기 지연 시간은 로그 파일이 데이터베이스 복사본에 재생된 후 데이터베이스 복사본에 대한 로그 삭제를 지연하기 위해 분 단위로 시간을 지정하는 사서함 데이터베이스 복사본의 속성입니다. 자르기 지연 타이머는 로그 파일이 수동 복사본에 복제되고 검사를 통과한 후 데이터베이스 복사본에 재생되었을 때 시작됩니다. 데이터베이스 복사본에서 로그 파일 자르기를 지연하면 데이터베이스의 활성 복사본에 대한 로그 파일에 영향을 준 오류로부터 복구할 수 있습니다.

데이터베이스 복사본 및 로그 잘라내기

Exchange 2013의 로그 잘라내기는 Exchange 2010에서와 동일한 방식으로 작동합니다. 자르기 동작은 복사본에 대한 재생 지연 시간 및 자르기 지연 시간 설정에 의해 결정됩니다.

지연 설정이 기본값 0(사용하지 않도록 설정)보다 왼쪽에 있는 값을 갖는 경우 데이터베이스 복사본의 로그 파일을 자르려면 다음 조건을 충족해야 합니다.

• 로그 파일을 성공적으로 백업했거나, 순환 로깅을 사용하도록 설정되어 있어야 합니다.
• 로그 파일이 데이터베이스에 대한 검사점(복구에 필요한 최소 로그 파일) 아래에 있어야 합니다.
• 다른 모든 지연된 복사본에 검사를 마친 로그 파일이 있어야 합니다.
• 지연된 복사본이 아닌 다른 모든 복사본이 로그 파일을 재생했어야 합니다.

지연된 데이터베이스 복사본에 대한 자르기가 수행되려면 다음 조건을 충족해야 합니다.

• 로그 파일이 데이터베이스의 검사점 아래에 있어야 합니다.
• 로그 파일이 ReplayLagTime + TruncationLagTime보다 오래된 것이어야 합니다.
• 로그 파일이 활성 복사본에서 잘렸어야 합니다.

Exchange 2013에서는 수동 복사본이 하나 이상 일시 중단되어 있으면 활성 사서함 데이터베이스 복사본에서 로그를 자르지 않습니다. 계획된 유지 관리 작업이 오래 계속된 경우(예를 들면 며칠) 상당한 양의 로그 파일이 쌓일 수 있습니다. 트랜잭션 로그로 로그 드라이브가 꽉 차지 않게 하려면 해당 수동 데이터베이스 복사본을 일시 중단하는 대신 제거합니다. 계획된 유지 관리가 완료되면 수동 데이터베이스 복사본을 다시 추가할 수 있습니다.

Exchange 2013 SP1(서비스 팩 1)에는 느슨한 잘라내기(기본적으로 사용하지 않도록 설정됨)라는 새로운 기능이 도입되었습니다. 정상 작동 중에는 데이터베이스의 모든 복사본이 재생(수동 복사본) 또는 수신(지연된 복사본)되었음을 확인할 때까지 각 데이터베이스 복사본에서 다른 데이터베이스 복사본에 전달해야 하는 로그가 유지됩니다. 이는 기본 로그 잘라내기 동작입니다. 데이터베이스 복사본이 특정 사유로 인해 오프라인 상태로 전환되면 데이터베이스의 다른 복사본에서 사용하는 디스크에 로그 파일이 누적되기 시작합니다. 영향을 받는 데이터베이스 복사본이 연장된 기간 동안 오프라인 상태로 유지되면 이로 인해 다른 데이터베이스 복사본의 디스크 공간이 부족해질 수 있습니다.

느슨한 자르기가 사용하도록 설정된 경우에는 자르기 동작이 달라집니다. 각 데이터베이스 복사본이 자체 사용 가능한 디스크 공간을 추적한 다음 사용 가능한 공간이 부족해지면 느슨한 자르기 동작이 적용됩니다. 활성 복사본의 경우에는 가장 오래된 지연 복사본, 즉 로그 재생에서 맨 끝에 있는 수동 데이터베이스 복사본이 무시되고 남아 있는 가장 오래된 수동 복사본이 자르기에 사용됩니다. 전역 자르기는 활성 데이터베이스 복사본에서 계산됩니다. 수동 복사본은 활성 복사본에 대한 자르기 결정을 사용합니다. 자르기에서 사용되는 매개 변수의 이름이 MinCopiesToProtect이기는 하지만 Exchange에서는 자르기를 실행할 때 가장 오래된 것으로 확인된 지연 복사본만 무시합니다. 수동 복사본의 경우에는 공간이 부족해지면 아래에 설명되어 있는 구성된 매개 변수를 사용하여 로그 파일을 독립적으로 자릅니다.

오프라인 데이터베이스가 다시 온라인 상태로 전환되면 다른 정상 상태의 복사본에서 삭제된 로그 파일이 누락되고 해당 데이터베이스 복사본 상태가 FailedAndSuspended로 됩니다. 이 경우 Autoreseed가 구성되어 있으면 영향을 받는 복사본이 자동으로 다시 시드되고, Autoreseed가 구성되어 있지 않으면 데이터베이스 복사본을 관리자가 수동으로 시드해야 합니다.

필요한 정상 상태 복사본 수, 사용 가능한 디스크 공간 임계값 및 유지할 로그 수는 모두 구성 가능한 매개 변수입니다. 기본적으로 사용 가능한 디스크 공간 임계값은 204,800MB(200GB)이고 유지할 로그 수는 수동 복사본에 필요한 100,000개(100GB) 및 활성 복사본에 필요한 10,000개(10GB)입니다.

느슨한 잘라내기를 사용하도록 설정하고 느슨한 잘라내기 매개 변수를 구성하려면 각 DAG 구성원에 대한 Windows 레지스트리를 편집하면 됩니다. 구성할 수 있는 레지스트리 값은 3개이며, 모두 HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation에 저장되어 있습니다. DWORD 값 뒤의 BackupInformation 키는 기본적으로 존재하지 않으며 수동으로 만들어야 합니다. BackupInformation 아래의 DWORD 레지스트리 값은 다음 표에서 설명되어 있습니다.

LooseTruncation_MinLogsToProtect 레지스트리 값을 사용할 때의 동작은 활성 데이터베이스 복사본과 수동 데이터베이스 복사본에서 각각 다릅니다. 활성 데이터베이스 복사본에서 이 레지스트리 값은 필요한 활성 복사본 범위 및 수동 데이터베이스 복사본에 필요한 로그를 초과하여 유지되는 추가 로그의 수입니다. 수동 데이터베이스 복사본에서 이 레지스트리 값은 사용 가능한 최신 로그에서 유지되는 로그의 수입니다. 또한 이 수동 복사본의 필요한 범위를 초과하는 로그를 유지하는 데 이 수의 1/10이 사용됩니다. 이 두 제한은 지연된 데이터베이스 복사본이 공간을 너무 많이 차지하지 않도록 하기 위해 적용됩니다. 일반적으로 지연된 데이터베이스 복사본에 필요한 범위가 매우 크기 때문입니다.

데이터베이스 활성화 정책

사서함 데이터베이스 복사본을 만들거나 오류 발생 시 시스템에서 해당 복사본을 자동으로 활성화하지 않으려는 경우가 있을 수 있습니다.

• 하나 이상의 사서함 데이터베이스 복사본을 대체 데이터 센터 또는 대기 데이터 센터로 배포하는 경우
• 복구를 위해 지연된 데이터베이스 복사본을 구성하는 경우
• 서버의 유지 관리 또는 업그레이드를 수행하는 경우

앞에 나온 각 시나리오에서, 시스템에 의해 자동으로 활성화되지 않아야 할 데이터베이스 복사본이 있습니다. 시스템이 사서함 데이터베이스 복사본을 자동으로 활성화하지 않게 하기 위해, 활성화가 차단(일시 중단)되도록 복사본을 구성할 수 있습니다. 이렇게 하면 시스템은 로그 전달 및 재생을 통해 데이터베이스의 현재 상태를 유지하면서 시스템이 복사본을 자동으로 활성화하고 사용하는 것을 방지합니다. 활성화가 차단된 복사본은 관리자가 수동으로 활성화해야 합니다. Set-MailboxServer cmdlet을 사용하여 전체 서버에 대한 데이터베이스 활성화 정책을 구성하거나 Set-MailboxDatabaseCopy cmdlet을 사용하여 DatabaseCopyAutoActivationPolicy 매개 변수를 Blocked로 설정하여 개별 데이터베이스 복사본에 대한 데이터베이스 활성화 정책을 구성할 수 있습니다.

데이터베이스 활성화 정책 구성에 대한 자세한 내용은 사서함 데이터베이스 복사본에 대한 정품 인증 정책 구성 항목을 참조하십시오.

연속 복제에서 사서함 이동의 영향

로그 생성 속도가 높고 작업량이 매우 많은 사서함 데이터베이스에서는 수동 데이터베이스 복사본으로의 복제가 로그 생성 속도를 따라가지 못할 경우 데이터 손실의 가능성이 커집니다. 로그 생성 속도가 높아질 수 있는 한 가지 시나리오는 사서함 이동입니다. Exchange 2013에는 시스템 또는 관리자가 설정한 DataMoveReplicationConstraint 매개 변수의 값에 따라 MRS(Microsoft Exchange Mailbox Replication Service) 등의 서비스가 데이터베이스 복사본 아키텍처의 상태를 확인하기 위해 사용하는 데이터 보장 API가 포함되어 있습니다. 데이터 보장 API는 다음과 같은 용도로 사용할 수 있습니다.

• 복제 상태 확인   필수 데이터베이스 복사본 수를 사용할 수 있는지 확인합니다.
• 복제 플러시 확인   필수 데이터베이스 복사본 수에 대해 필요한 로그 파일이 재생되었는지 확인합니다.

API가 실행되면 호출 응용 프로그램에 다음과 같은 상태 정보를 반환합니다.

• Retry   일시적 오류가 있기 때문에 조건을 데이터베이스에 대해 확인하지 못함을 의미합니다.
• Satisfied   데이터베이스가 필수 조건을 충족하거나 데이터베이스가 복제되지 않았음을 의미합니다.
• NotSatisfied   데이터베이스가 필수 조건을 충족하지 않음을 의미합니다. 또한 NotSatisfied 응답이 반환된 이유에 대한 정보가 호출 응용 프로그램에 제공됩니다.

사서함 데이터베이스에 대한 DataMoveReplicationConstraint 매개 변수의 값에 따라 요청의 일부로 평가해야 하는 데이터베이스 복사본의 수가 결정됩니다. DataMoveReplicationConstraint 매개 변수에는 다음 값이 허용됩니다.

• None   사서함 데이터베이스를 만들 때 기본적으로 이 값이 설정됩니다. 이 값을 설정하면 데이터 보장 API 조건은 무시됩니다. 이 설정은 복제되지 않은 사서함 데이터베이스에만 사용해야 합니다.
• SecondCopy   사서함 데이터베이스의 두 번째 복사본을 추가할 때 기본값입니다. 이 값을 설정한 경우 최소 하나 이상의 수동 데이터베이스 복사본이 데이터 보장 API 조건을 충족해야 합니다.
• SecondDatacenter   이 값을 설정한 경우 다른 Active Directory 사이트에서 최소 하나 이상의 수동 데이터베이스 복사본이 데이터 보장 API 조건을 충족해야 합니다.
• AllDatacenters   이 값을 설정한 경우 각 Active Directory 사이트에서 최소 하나 이상의 수동 데이터베이스 복사본이 데이터 보장 API 조건을 충족해야 합니다.
• AllCopies   이 값을 설정한 경우 사서함 데이터베이스의 모든 복사본이 데이터 보장 API 조건을 충족해야 합니다.

복제 상태 확인

데이터베이스 복사본 인프라의 상태를 평가하기 위해 데이터 보장 API가 실행될 경우 몇 개의 항목이 평가됩니다.

복제 플러시 확인

데이터 보장 API는 필수 데이터베이스 복사본 수가 필요한 트랜잭션 로그를 재생했는지 확인하는 데도 사용할 수 있습니다. 이를 확인하려면 마지막 로그 재생 타임스탬프를 호출 서비스의 커밋 타임스탬프(대개의 경우 필요한 데이터가 포함된 마지막 로그 파일의 타임스탬프)에 5초를 더한(시스템 시간 시계 편차를 처리하기 위해) 값과 비교합니다. 재생 타임스탬프가 커밋 타임스탬프보다 큰 경우에는 DataMoveReplicationConstraint 매개 변수가 충족됩니다. 재생 타임스탬프가 커밋 타임스탬프보다 작은 경우에는 DataMoveReplicationConstraint 매개 변수가 충족되지 않습니다.

DAG 내의 복제 데이터베이스 간에 많은 수의 사서함을 이동하기 전에 다음에 따라 각 사서함 데이터베이스에 대한 DataMoveReplicationConstraint 매개 변수를 구성하는 것이 좋습니다.

데이터베이스 복사본 균형 조정

DAG의 고유한 특성으로 인해 데이터베이스 전환 및 장애 조치(failover)의 결과로 활성 사서함 데이터베이스 복사본은 DAG의 수명 동안 여러 번 호스트를 변경합니다. 결과적으로 DAG는 활성 사서함 데이터베이스 복사본 배포 측면에서 불균형하게 될 수 있습니다. 다음 표에서는 활성 데이터베이스 복사본이 균등하게 배포되지 않은 각 데이터베이스의 복사본 4개가 포함된 4개의 데이터베이스(각 서버에서 총 16개의 데이터베이스)가 있는 DAG의 예를 보여 줍니다.

활성 복사본이 불균형하게 배포된 DAG

위 예에서는 각 데이터베이스의 4개의 복사본이 있습니다. 따라서 활성화 기본 설정(1, 2, 3 또는 4)에 대한 4개의 가능한 값이 있습니다. 기본 설정 카운트 목록 열에서는 이러한 값 각각이 포함된 데이터베이스 수의 카운트를 보여 줍니다. 예를 들어 EX3에서는 활성화 기본 설정이 1인 13개의 데이터베이스 복사본, 활성화 기본 설정이 2인 2개의 복사본, 활성화 기본 설정이 3인 1개의 복사본이 있으며 활성화 기본 설정이 4인 복사본은 없습니다.

표시된 것처럼, 이 DAG는 각 DAG 구성원이 호스트하는 활성 데이터베이스 수, 각 DAG 구성원이 호스트하는 수동 데이터베이스 수 또는 호스트된 데이터베이스의 활성화 기본 설정 카운트를 고려하여 균형이 조정되지 않았습니다.

RedistributeActiveDatabases.ps1 스크립트를 사용하여 활성 사서함 데이터베이스 복사본을 DAG 간에 균형 조정할 수 있습니다. DAG의 각 서버에서 탑재된 데이터베이스 수가 동일하게 되도록 하기 위해 이 스크립트는 해당 복사본 간에 데이터베이스를 이동합니다. 또한 필요한 경우 이 스크립트는 사이트 간에 활성 데이터베이스를 균형 있게 조정하려고 시도합니다.

이 스크립트는 DAG 내에서 활성 데이터베이스 복사본을 균형 있게 조정하기 위한 두 가지 옵션을 제공합니다.

• BalanceDbsByActivationPreference   이 옵션을 지정하는 경우 스크립트가 Active Directory 사이트에 상관없이 가장 선호되는 복사본(활성화 기본 설정 기준)으로 데이터베이스를 이동하려고 시도합니다.
• BalanceDbsBySiteAndActivationPreference   이 옵션을 지정하는 경우 스크립트가 각 Active Directory 사이트 내에서 활성 데이터베이스를 균형 있게 조정하려고 시도하는 동안 가장 선호되는 복사본으로 활성 데이터베이스를 이동하려고 시도합니다.

첫 번째 옵션으로 스크립트를 실행하면 다음 표에서와 같이 위의 불균형한 DAG가 균형 있게 조정됩니다.

위의 표에서와 같이 이 DAG는 이제 각 서버의 활성 및 수동 데이터베이스 수와 서버 간에 활성화 기본 설정을 고려하여 균형 있게 조정되었습니다.

다음 표에서는 RedistributeActiveDatabases.ps1 스크립트에 사용할 수 있는 매개 변수를 보여 줍니다.

RedistributeActiveDatabases.ps1 스크립트 매개 변수

RedistributeActiveDatabases.ps1 예

이 예는 기본 설정 카운트 목록을 포함하여 DAG에 대한 현재 데이터베이스 배포를 보여 줍니다.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

이 예는 입력을 요청하지 않고 활성 기본 설정을 사용하여 DAG에서 활성 사서함 데이터베이스 복사본을 다시 배포하고 균형 있게 조정합니다.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

이 예는 활성 기본 설정을 사용하여 DAG에서 활성 사서함 데이터베이스 복사본을 다시 배포하고 균형 있게 조정하며 배포 요약을 생성합니다.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

데이터베이스 복사본 모니터링

데이터베이스 복사본은 데이터베이스의 활성 복사본에 영향을 주는 오류가 발생할 경우 첫 번째 방어 수단입니다. 따라서 필요할 때 사용할 수 있으려면 데이터베이스 복사본의 상태를 모니터링하는 것이 중요합니다. EAC에서 데이터베이스 복사본의 상세 정보를 확인하면 복사 큐 길이, 재생 큐 길이, 상태 및 콘텐츠 인덱스 상태 정보를 포함한 다양한 정보를 볼 수 있습니다. 또한 셸에서 Get-MailboxDatabaseCopyStatus cmdlet을 사용하여 데이터베이스 복사본의 다양한 상태 정보를 볼 수도 있습니다.

데이터베이스 복사본 모니터링에 대한 자세한 내용은 데이터베이스 사용 가능 그룹 모니터링 항목을 참조하십시오.

데이터베이스 복사본 제거

EAC를 사용하거나 셸에서 Remove-MailboxDatabaseCopy cmdlet을 사용하여 데이터베이스 복사본을 언제든지 제거할 수 있습니다. 데이터베이스 복사본을 제거한 후에는 데이터베이스 복사본을 제거하고 있는 서버에서 모든 데이터베이스 및 트랜잭션 로그 파일을 수동으로 삭제해야 합니다. 데이터베이스 복사본을 제거하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본 제거를 참조하십시오.

데이터베이스 전환

데이터베이스의 활성 복사본을 호스트하는 사서함 서버를 사서함 데이터베이스 마스터라고 합니다. 수동 데이터베이스 복사본을 활성화하는 프로세스는 데이터베이스의 사서함 데이터베이스 마스터를 변경시키고 수동 복사본을 새로운 활성 복사본으로 전환합니다. 이 프로세스를 데이터베이스 전환이라고 합니다. 데이터베이스 전환에서는 데이터베이스의 활성 복사본이 특정 사서함 서버에서 분리되고, 해당 데이터베이스의 수동 복사본이 새 활성 사서함 데이터베이스로 다른 사서함 서버에 탑재됩니다. 전환을 수행할 때 새 사서함 데이터베이스 마스터에서 데이터베이스 탑재 다이얼 설정을 다시 정의할 수 있습니다.

EAC의 데이터베이스 복사본 탭에서 오른쪽 열을 확인하여 어떤 사서함 서버가 현재 사서함 데이터베이스 마스터인지 신속하게 알아볼 수 있습니다. EAC에서 활성화 링크를 사용하거나 셸에서 Move-ActiveMailboxDatabase cmdlet을 사용하여 전환을 수행할 수 있습니다.

수동 복사본을 활성화하기 전에 수행될 몇몇 내부 검사가 있습니다.

• 데이터베이스 복사본의 상태를 확인합니다. 데이터베이스 복사본이 실패 상태이면 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet에SkipHealthChecks 매개 변수를 사용하면 이 동작을 다시 정의하여 상태 검사를 무시할 수 있습니다. 이 매개 변수는 활성 복사본을 실패 상태인 데이터베이스 복사본으로 이동하는 데 사용됩니다.
• 활성 데이터베이스 복사본이 현재 데이터베이스의 수동 복사본에 대한 시드 원본인지 여부를 검사합니다. 활성 복사본이 현재 시드 원본으로 사용 중인 경우에는 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet의 SkipActiveCopyChecks 매개 변수를 사용하면 이 동작을 다시 정의하고 시드 원본 검사를 무시할 수 있습니다. 이 매개 변수를 사용하면 시드 원본으로 사용 중인 활성 복사본을 이동할 수 있습니다. 이 매개 변수를 사용할 경우 시드 작업이 취소되고 실패한 것으로 간주됩니다.
• 데이터베이스 복사본의 복사 큐와 재생 큐 길이를 검사하여 그 값이 구성된 기준 내에 있는지 확인합니다. 또한 데이터베이스 복사본이 시드를 위한 원본으로 현재 사용되고 있지 않은지 확인합니다. 큐 길이에 대한 값이 구성된 기준을 벗어나거나 데이터베이스가 시드를 위한 원본으로 현재 사용 중이면 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet에 SkipLagChecks 매개 변수를 사용하면 이 동작을 다시 정의하여 검사를 무시할 수 있습니다. 이 매개 변수는 구성된 기준을 벗어나는 재생 큐 및 복사 큐가 있는 복사본을 활성화하는 데 사용됩니다.
• 데이터베이스 복사본의 검색 카탈로그 상태(콘텐츠 인덱스)를 확인합니다. 검색 카탈로그가 최신 상태가 아니거나, 비정상 상태이거나, 손상된 경우 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet에 SkipClientExperienceChecks 매개 변수를 사용하면 이 동작을 다시 정의하여 검색 카탈로그 검사를 무시할 수 있습니다. 이 매개 변수는 이 검색이 카탈로그 상태 검사를 건너뛰게 하는 데 사용됩니다. 활성화할 데이터베이스 복사본의 검색 카탈로그가 비정상이거나 사용할 수 없는 상태인 경우 이 매개 변수를 사용하여 카탈로그 상태 검사를 건너뛰고 데이터베이스 복사본을 활성화하면 검색 카탈로그를 다시 크롤링하거나 시드해야 합니다.

데이터베이스 전환을 수행할 때 현재 활성화되어 있는 수동 데이터베이스 복사본을 호스트하는 서버에 구성된 탑재 다이얼 설정을 다시 정의할 수 있습니다. Move-ActiveMailboxDatabase cmdlet에 MountDialOverride 매개 변수를 사용하여 대상 서버가 자신의 탑재 다이얼 설정을 다시 정의하고MountDialOverride 매개 변수에 의해 지정된 설정을 사용하도록 지시할 수 있습니다.

데이터베이스 복사본 전환을 수행하는 방법의 자세한 단계는 사서함 데이터베이스 복사본 활성화 항목을 참조하십시오.

출처: <http://technet.microsoft.com/ko-KR/library/dd335158(v=exchg.150).aspx>

사서함 서버의 고가용성에 대해 살펴보는 것이 목적이므로, 아래의 내용은 보너스로 읽어 보자.

 

고가용성 및 사이트 복원 계획

적용 대상: Exchange Server 2013
마지막으로 수정된 항목: 2014-08-05

계획 단계에서 시스템 설계자, 관리자 및 기타 핵심 관계자는 비즈니스 요구 사항과 배포 시 아키텍처 요구 사항 외에 특히 고가용성과 사이트 복구에 대한 요구 사항을 확인해야 합니다.

이러한 기능 배포를 위해 충족해야 할 일반적인 요구 사항뿐 아니라, 마찬가지로 충족해야 할 하드웨어, 소프트웨어 및 네트워킹 요구 사항도 있습니다.

목차

• 일반 요구 사항
• 하드웨어 요구 사항
• 저장소 요구 사항
• 소프트웨어 요구 사항
• 네트워크 요구 사항
• 미러링 모니터 서버 요구 사항
• 사이트 복구 계획

출처: <http://technet.microsoft.com/ko-kr/library/dd638104(v=exchg.150).aspx>

 

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

적용 대상: Exchange Server 2013
마지막으로 수정된 항목: 2014-02-21

Microsoft Exchange Server 2013에서는 증분 배포로 알려진 개념을 사용하여 고가용성과 사이트 복구를 실현합니다. 두 개 이상의 Exchange 2013 사서함 서버를 독립 실행형 서버로 간단히 설치한 다음 고가용성 및 사이트 복구 기능을 제공하기 위해 필요에 따라 사서함 서버와 사서함 데이터베이스를 추가로 구성합니다.

• 배포 프로세스 개요
• 배포 예: 두 데이터 센터의 네 구성원 DAG

출처: <http://technet.microsoft.com/ko-KR/library/dd638129(v=exchg.150).aspx>

 

고가용성 및 사이트 복구 관리

적용 대상: Exchange Server 2013
마지막으로 수정된 항목: 2012-11-05

Microsoft Exchange Server 2013 고가용성 또는 사이트 복구 솔루션을 구축하고, 유효성을 검사하고, 배포하면 솔루션이 전체 솔루션 수명 주기의 배포 단계에서 운영 단계로 전환됩니다. 운영 단계는 몇 가지 작업으로 이루어지며 모든 작업은 DAG(데이터베이스 사용 가능 그룹), 사서함 데이터베이스 복사본, 사전 모니터링 수행, 전환 및 장애 조치(failover) 관리 영역 중 하나와 관련이 있습니다.

목차

• 데이터베이스 사용 가능 그룹 관리
• 사서함 데이터베이스 복사본 관리
• 사전 모니터링
• 전환 및 장애 조치(failover)

출처: <http://technet.microsoft.com/ko-KR/library/dd638215(v=exchg.150).aspx>

백업, 복원 및 재해 복구

적용 대상: Exchange Server 2013

마지막으로 수정된 항목: 2014-06-20

데이터 보호 계획의 일부로서 데이터를 보호하는 방법을 이해하고 조직의 요구에 가장 적합한 방법을 결정하는 것이 중요합니다. 데이터 보호 계획은 배포 계획 단계의 여러 가지 결정을 활용하는 복잡한 과정입니다.

일반적으로 다음 시나리오에서 백업이 사용되었습니다.

• 재해 복구   하드웨어 또는 소프트웨어 오류가 발생한 경우 DAG에 있는 여러 데이터베이스 복사본을 사용하여 데이터 손실이 거의 또는 전혀 없이 빠르게 장애 조치(failover)를 수행하는 방법으로 고가용성을 확보할 수 있습니다. 그러면 가동 중지 시간과 그에 따른 생산성 손실을 해소하여 디스크 또는 테이프에 대한 이전의 지정 시간 백업을 복원할 때 필요한 비용을 절약할 수 있습니다. DAG를 여러 사이트로 확장하여 디스크, 서버, 네트워크 및 데이터 센터 오류를 복구할 수 있습니다.
• 실수로 삭제한 항목 복구   지금까지 사용자가 삭제한 항목을 나중에 복구해야 하는 상황이 되면 복구할 데이터가 저장된 백업 미디어를 찾은 다음 원하는 항목을 찾아 사용자에게 제공해야 했습니다. Exchange 2013의 복구 가능한 항목 폴더와 폴더에 적용할 수 있는 보존 정책을 사용하면 삭제 및 수정된 데이터를 지정 기간 동안 모두 보관할 수 있으므로 해당 항목을 더 쉽고 빠르게 복구할 수 있습니다. 그러면 최종 사용자가 실수로 삭제한 항목을 직접 복구할 수 있어 Exchange 관리자와 IT 지원 센터의 부담이 줄고 단일 항목 복구와 관련된 복잡성과 관리 비용도 절감됩니다. 자세한 내용은 메시징 정책 및 규정 준수 및 데이터 손실 방지 항목을 참조하십시오.
• 장기 데이터 저장소   백업이 보존용으로 사용되기도 했으며 일반적으로 규정 준수 요구 사항에 따라 장기적으로 지정 시간의 데이터 스냅샷을 보관하는 일에는 테이프가 사용됩니다. Exchange 2013의 새로운 보관, 여러 사서함 검색 및 메시지 보존 기능은 최종 사용자가 액세스할 수 있는 방식으로 데이터를 효과적으로 장기 보존하는 방법을 제공합니다. 이를 통해 테이프에서 복원하는 비경제적 방법이 사라지고 생산성이 높아집니다. 자세한 내용은 원본 위치 보관, 원본 위치 eDiscovery및 원본 위치 유지을 참조하십시오.
• 지정 시간 데이터베이스 스냅숏   조직에 지난 지정 시간의 사서함 데이터 복사본이 필요한 경우 Exchange에서 제공되는 기능을 사용하여 DAG 환경에 지연된 데이터베이스 복사본을 만들 수 있습니다. 이 기능은 논리적으로 손상된 복제본을 DAG의 여러 데이터베이스 복사본에 저장하게 되어 이전 시점으로 돌아가야 하는 드문 경우에 유용합니다. 관리자가 사서함 또는 사용자 데이터를 실수로 삭제한 경우에도 이 기능이 유용할 수 있습니다. 지연된 복사본은 오랜 시간을 들여 백업 서버에서 Exchange 서버로 복사하는 과정이 생략되므로 지연된 복사본에서 복구하면 백업에서 복원하는 경우보다 작업 시간을 절약할 수 있습니다. 그리고 가동 중지 시간을 줄여 총 소유 비용을 대폭 절감할 수 있습니다.

이러한 각 시나리오를 효율적이면서 비용 효과적인 방식으로 충족하는 고유한 Exchange 2013 기능이 있으므로 작업 환경에서 전형적인 백업을 사용하는 경우를 줄이거나 없앨 수 있습니다.

• Exchange 고유 데이터 보호
• 지원되는 백업 기술
• Exchange 2013 VSS 기록기
• Exchange Server 복구
• 통합 연락처 저장소 복구
• 복구 데이터베이스
• 데이터베이스 이식성
• 발신음 이식성

출처: <http://technet.microsoft.com/ko-KR/library/dd876874(v=exchg.150).aspx>

관리되는 가용성

적용 대상: Exchange Server 2013 SP1, Exchange Server 2013, Exchange Online

마지막으로 수정된 항목: 2014-08-07

메시징 시스템 관리자의 기본적인 목표는 사용자에게 항상 효율적인 전자 메일 환경을 제공하는 것입니다. Microsoft Exchange Server 2013 조직의 가용성과 안정성을 보장하려면 시스템의 모든 측면을 적극적으로 모니터링하고 확인된 문제를 신속하게 해결해야 합니다. 이전 Exchange 버전에서는 중요 시스템 구성 요소를 모니터링할 때 대개 Microsoft System Center 2012 Operations Manager와 같은 외부 응용 프로그램을 사용하여 데이터를 수집한 다음 수집된 데이터 분석을 통해 확인된 문제에 대한 복구 작업을 제공했습니다. Exchange 2010 이하 버전에서는 상태 매니페스트 및 상관 관계 엔진이 관리 팩 형태로 포함되어 있었습니다. Operations Manager에서는 이러한 구성 요소를 통해 특정 구성 요소의 상태가 정상인지 여부를 확인했습니다. 또한 Operations Manager는 Exchange 2010에서 기본 제공되는 진단 cmdlet 인프라를 사용하여 다양한 시스템 측면에 대해 가상 트랜잭션을 실행했습니다.

Exchange 2013에서는 모니터링 및 복구 작업을 기본 제공하는 관리되는 가용성이라는 기능을 사용하여 최종 사용자 환경을 기본적으로 모니터링 및 보존하는 새로운 방식이 사용됩니다.

출처: <http://technet.microsoft.com/ko-KR/library/dn482056(v=exchg.150).aspx>