고가용성 및 사이트 복구

Exchange 2010의 경우 수동 데이터베이스 복사본의 검사점 깊이가 매우 낮으며 이러한 검사점 깊이는 빠른 장애 조치(failover)를 위해 필요합니다. 또한 수동 복사본은 5MB의 검사점 깊이를 확보하기 위해 적극적인 데이터 미리 읽기를 수행합니다. 낮은 검사점 깊이를 사용하고 이러한 적극적 미리 읽기 작업을 수행한 결과, Exchange 2010에서는 수동 데이터베이스 복사본의 IOPS가 활성 복사본의 IOPS와 같았습니다.

Exchange 2013에서는 시스템이 수동 복사본에 대해 높은 검사점 깊이(100MB)를 사용하면서 빠른 장애 조치(failover)를 제공할 수 있습니다. 수동 복사본의 검사점 깊이가 100MB이므로 이전처럼 적극적이지 않도록 하향 조정되었습니다. Exchange 2013에서는 검사점 깊이가 늘어나고 적극적 미리 읽기가 하향 조정된 결과 수동 복사본의 IOPS가 활성 복사본 IOPS의 약 50%에 지나지 않습니다.

수동 복사본의 검사점 깊이가 높아짐으로써 다른 사항도 변경되었습니다. Exchange 2010의 장애 조치(failover)에서는 데이터베이스가 수동 복사본에서 활성 복사본으로 변환될 때 데이터베이스 캐시가 플러시됩니다. Exchange 2013에서는 ESE 로깅이 다시 작성되었으므로 수동 복사본에서 활성 복사본으로의 변환을 통해 캐시가 유지됩니다. ESE는 캐시를 플러시할 필요가 없기 때문에 장애 조치(failover) 속도가 빠릅니다.

또 다른 한 가지 변경 사항은 BDM(백그라운드 데이터베이스 유지 관리)입니다. 이제 BDM의 제한이 복사본당 5MB/초에서 1MB/초로 낮아졌습니다.

이러한 모든 변경 사항의 결과로 Exchange 2013의 IOPS는 Exchange 2010에 비해 50% 낮습니다.

관리되는 가용성은 기본 제공 활성 모니터링과 Exchange 2013의 고가용성 플랫폼이 통합된 것입니다. 시스템에서는 관리되는 가용성을 통해 서비스 상태를 기준으로 데이터베이스의 장애 조치(failover) 시기를 결정할 수 있습니다. 관리되는 가용성은 Exchange 2013의 클라이언트 액세스 및 사서함 서버 역할에 배포되는 내부 인프라입니다. 관리되는 가용성에는 지속적으로 작업을 수행하는 세 가지 주요 비동기 구성 요소가 포함되어 있습니다. 첫 번째 구성 요소는 프로브 엔진으로, 서버에서 데이터를 측정하고 데이터를 수집합니다. 이러한 측정의 결과는 모니터라는 두 번째 구성 요소로 전달됩니다. 모니터에는 수집되는 데이터에서 정상으로 간주되는 상태에 따라 시스템에서 사용하는 모든 비즈니스 논리가 포함되어 있습니다. 패턴 인식 엔진과 마찬가지로, 모니터는 수집된 모든 측정 결과에서 다양한 패턴을 찾은 다음 정상 상태인 항목과 그렇지 않은 항목을 결정합니다. 마지막으로 복구 작업을 담당하는 응답자 엔진이 있습니다. 무언가 비정상적인 상태인 경우 첫 번째로 수행하는 작업은 그 구성 요소의 복구를 시도하는 것입니다. 이 과정은 여러 단계의 복구 작업으로 이루어질 수 있습니다. 예를 들어, 첫 번째로 응용 프로그램 풀을 다시 시작해 보고, 두 번째로 서비스를 다시 시작해 보고, 세 번째로 서버를 다시 시작해 본 후에는 더 이상 트래픽을 받아들이지 않도록 서버를 오프라인으로 전환하는 시도를 해 볼 수 있습니다. 복구 작업에 실패하면 문제가 이벤트 로그 알림을 통해 담당자에게 에스컬레이션됩니다.

관리되는 가용성은 두 가지 서비스의 형태로 구현됩니다.

• Exchange Health Manager 서비스(MSExchangeHMHost.exe)   작업자 프로세스를 관리하는 데 사용되는 컨트롤러 프로세스입니다. 필요에 따라 작업자 프로세스를 작성, 실행, 시작 및 중지하는 데 사용됩니다. 또한 작업자 프로세스를 이중화하여 작업자 프로세스가 중단될 경우 이를 복구하는 데도 사용됩니다.
  
• Exchange Health Manager 작업자 프로세스(MSExchangeHMWorker.exe)   런타임 작업 수행을 담당하는 작업자 프로세스입니다.
  

관리되는 가용성의 기능은 영구 저장소를 사용하여 수행됩니다.

• XML 구성 파일은 작업 프로세스를 시작하는 동안 작업 항목 정의를 초기화하는 데 사용됩니다.
  
• 레지스트리는 책갈피 같은 런타임 데이터를 저장하는 데 사용됩니다.
  
• Crimson 채널 이벤트 로그 인프라는 작업 항목 결과를 저장하는 데 사용됩니다.
  

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

Exchange 2013에서 개선된 저장소 기능은 주로 JBOD(여러 디스크 모음) 구성을 위한 것이지만 지원되는 모든 저장소 구성에서 이 기능을 사용할 수 있습니다. 이러한 기능 중 하나는 여러 데이터베이스를 동일한 볼륨에서 호스트하는 기능입니다. 이 기능은 Exchange의 대용량 디스크 최적화와 관련이 있습니다. 이러한 최적화를 통해 대용량 디스크를 용량, IOPS 및 다시 시드 시간 측면에서 훨씬 더 효율적으로 사용할 수 있으며, JBOD 저장소 구성에서 실행하는 데 관련된 다음과 같은 여러 가지 과제를 처리할 수 있습니다.

• 데이터베이스 크기는 관리가 용이해야 합니다.
  
• 다시 시드 작업은 빠르고 안정적이어야 합니다.
  
• 스토리지 용량은 증가하고 있지만 IOPS는 그렇지 않습니다.
  
• 수동 데이터베이스 복사본을 호스트하는 디스크는 IOPS 활용도가 떨어집니다.
  
• 지연된 복사본에는 비대칭적 저장소가 필요합니다.
  
• 디스크 공간이 작을 때 복구 유연성이 제한적입니다.
  

저장소 용량은 계속해서 증가하는 추세이며 조만간 8TB 드라이브가 상용화될 것으로 예상됩니다. Exchange 권장 사항인 최대 2TB의 데이터베이스 크기로 8TB 드라이브를 사용할 경우에는 5TB 이상의 디스크 공간이 낭비됩니다. 데이터베이스 크기를 증가시키면 간단히 이 문제를 해결할 수 있지만 다시 시드 시간이 길어 경우에 따라서는 다시 시드 시간을 작업으로 관리할 수 없는 등 관리 효율성이 떨어지는 단점이 있고, 네트워크를 통해 해당 양의 데이터를 복사하기 때문에 안정성 면에서도 불리합니다.

또한 Exchange 2010 모델에서 수동 복사본을 저장하는 디스크는 IOPS 면에서 활용도가 낮습니다. 지연된 수동 복사본의 경우 IOPS 면에서 디스크의 활용도가 낮을 뿐 아니라, 활성 및 지연되지 않은 수동 복사본을 저장하는 데 사용되는 디스크와 비교할 때 크기 면에서 비대칭적입니다.

Exchange 2013은 Microsoft는 Exchange의 오랜 관행을 지속하면서 JBOD 구성에서 대용량 디스크(8TB)를 보다 효율적으로 사용할 수 있도록 최적화되었습니다. Exchange 2013에서는 디스크당 여러 데이터베이스가 지원되므로 동일한 크기의 디스크에 지연된 복사본을 포함하여 여러 데이터베이스 복사본을 저장할 수 있습니다. 이 기능의 목적은 기존의 여러 볼륨에 사용자를 분산할 수 있도록 하여 일반 작업 중에 각 DAG 구성원이 동일한 볼륨에서 활성 복사본, 수동 복사본 및 선택적인 지연된 복사본을 호스트하는 대칭적 디자인을 제공하는 것입니다.

아래 예에서는 볼륨당 여러 데이터베이스를 사용하는 구성을 보여 줍니다.

볼륨당 여러 데이터베이스를 사용하는 구성

위의 구성은 대칭적 디자인을 제공합니다. 네 개의 서버가 모두 동일한 네 개의 데이터베이스를 사용하며 이러한 데이터베이스는 모두 각 서버의 단일 디스크에서 호스트됩니다. 중요한 점은 각 데이터베이스의 복사본 수가 디스크당 데이터베이스 복사본 수와 같아야 한다는 것입니다. 위의 예에서는 각 데이터베이스의 복사본이 네 개 있습니다. 하나는 활성 복사본이고, 두 개는 수동 복사본이며, 마지막 하나는 지연된 복사본입니다. 각 데이터베이스의 복사본이 네 개이므로 올바른 구성은 볼륨당 네 개의 복사본을 포함하는 구성입니다. 또한 활성화 기본 설정은 DAG와 각 서버 간에 균형을 이루도록 구성됩니다. 예를 들어, 활성 복사본의 활성화 기본 설정 값은 1이 되고, 첫 번째 수동 복사본과 두 번째 수동 복사본의 활성화 기본 설정 값은 각각 2와 3이 되며, 지연된 복사본의 활성화 기본 설정 값은 4가 됩니다.

기존 볼륨에 사용자를 보다 효율적으로 분산할 수 있다는 점 외에, 디스크당 여러 데이터베이스를 사용할 때의 또 다른 이점은 디스크 오류와 같이 다시 시드를 필요로 하는 오류가 발생할 경우 보호 데이터를 복원하는 데 소요되는 시간이 줄어든다는 점입니다.

데이터베이스 크기가 클수록 데이터베이스를 다시 시드하는 데 오래 걸립니다. 예를 들어, 2TB 데이터베이스를 다시 시드하는 데는 23시간이 소요되는 반면 8TB 데이터베이스를 다시 시드하는 데는 93시간(약 4일)이나 소요될 수 있습니다. 두 시드는 모두 초당 약 20MB로 발생합니다. 이는 일반적으로 초대형 데이터베이스를 작업상 합리적인 시간 내에 시드할 수 없음을 의미합니다.

디스크당 단일 데이터베이스 복사본 시나리오의 경우에는 항상 단일 원본에서 디스크를 시드하므로 시드 작업이 사실상 원본의 제한을 받습니다. 볼륨을 여러 개의 데이터베이스 복사본으로 나누고 수동 데이터베이스의 활성 복사본을 별도의 DAG 구성원에 저장된 특정 볼륨에 두면 디스크를 다시 시드할 때 시스템이 더 이상 원본의 제한을 받지 않게 됩니다. 오류가 있는 디스크를 교체할 경우에는 디스크가 여러 원본에서 다시 시드될 수 있습니다. 따라서 시스템이 훨씬 더 짧은 시간으로 이러한 데이터베이스의 보호 데이터를 다시 시드하고 복원할 수 있습니다.

볼륨당 여러 데이터베이스를 사용할 경우 다음과 같은 모범 사례를 따르는 것이 좋습니다.

• 실제 디스크당 논리 디스크 파티션 하나를 사용해야 합니다. 디스크에 파티션을 여러 개 만들지 마십시오. 각 데이터베이스 복사본과 해당 트랜잭션 로그, 콘텐츠 인덱스 등의 수반되는 파일은 단일 파티션의 고유 디렉터리에서 호스트되어야 합니다.
  
• 볼륨당 구성된 데이터베이스 복사본 수는 각 데이터베이스의 복사본 수와 같아야 합니다. 예를 들어, 데이터베이스 복사본이 네 개인 경우 볼륨당 네 개의 데이터베이스 복사본을 사용해야 합니다.
  
• 데이터베이스 복사본은 동일한 환경을 가져야 합니다. 예를 들면, 데이터베이스 복사본은 모두 각 서버에서 동일한 디스크를 공유해야 합니다.
  
• 특정 디스크의 각 데이터베이스 복사본이 고유한 활성화 기본 설정 값을 갖도록 DAG에서 활성화 기본 설정의 균형을 조정해야 합니다.
  

자동 다시 시드는 일반적으로 데이터베이스 복사본을 다시 시드할 필요가 있는 디스크 오류, 데이터베이스 손상 또는 그 밖의 문제가 발생할 경우 이에 대처하기 위해 관리자가 주도하는 작업을 대체하는 기능입니다. 자동 다시 시드는 디스크 오류가 발생한 후 시스템에 프로비전된 예비용 디스크를 사용하여 데이터베이스 중복성을 자동으로 복원하기 위한 것입니다.

자동 다시 시드 구성에서는 표준화된 저장소 표시 구조가 사용되며 관리자가 시작 지점을 선택합니다. 자동 다시 시드 기능은 드라이브에 오류가 발생할 경우 가능한 한 즉시 중복성을 복원합니다. 이 과정에서 일련의 볼륨(예비 볼륨 포함) 및 데이터베이스가 탑재 지점을 사용하여 미리 매핑됩니다. 디스크 오류로 인해 운영 체제에서 디스크를 더 이상 사용할 수 없거나 디스크에 쓸 수 없게 될 경우 시스템에 의해 예비 볼륨이 할당되며 영향을 받는 데이터베이스 복사본은 자동으로 다시 시드됩니다. 자동 다시 시드에는 다음 프로세스가 사용됩니다.

1. Microsoft Exchange Replication Service는 FailedAndSuspended 상태인 복사본을 정기적으로 검색합니다.
   
2. 이 상태인 복사본을 찾으면 단일 복사본 상태인지 여부, 여유분을 사용할 수 있는지 여부, 특정 주체가 시스템의 자동 다시 시드를 방지할 수 있는지 여부 등 몇 가지 선행 조건 검사를 수행합니다.
   
3. 선행 조건 검사를 통과하면 Microsoft Exchange Replication Service에서는 예비 볼륨을 할당하고 다시 매핑합니다.
   
4. 그런 다음 시드 작업이 수행됩니다.
   
5. 시드가 완료된 후 Microsoft Exchange Replication Service는 새로 시드된 복사본의 상태가 정상인지 확인합니다.
   

오류가 디스크에서 발생했다면 운영자나 관리자가 이때 직접 개입하여 해당 디스크를 제거하고 교체한 다음 새 디스크를 포맷 및 초기화하고 예비 디스크로 구성해야 합니다.

자동 다시 시드는 DAG의 세 가지 속성을 사용하여 구성됩니다. 이 중 두 속성은 사용 중인 두 개의 탑재 지점을 나타냅니다. Exchange 2013에서는 Windows Server가 볼륨당 여러 탑재 지점을 허용한다는 점을 활용합니다. AutoDagVolumesRootFolderPath 속성은 사용 가능한 모든 볼륨이 포함된 탑재 지점을 나타냅니다. 여기에는 데이터베이스를 호스트하는 볼륨과 예비 볼륨이 포함됩니다. AutoDagDatabasesRootFolderPath 속성은 데이터베이스가 포함된 탑재 지점을 나타냅니다. 세 번째 DAG 속성인 AutoDagDatabaseCopiesPerVolume은 볼륨당 데이터베이스 복사본 수를 구성하는 데 사용됩니다.

아래 예에서는 자동 다시 시드 구성을 보여 줍니다.

AutoReseed 구성 예

이 예에서는 세 개의 볼륨이 있으며, 그 중 두 볼륨에는 데이터베이스(VOL1 및 VOL2)가 있고 한 볼륨에는 포맷된 빈 예비 볼륨(VOL3)이 있습니다.

자동 다시 시드를 구성하려면

1. 세 개의 볼륨을 모두 단일 탑재 지점에 탑재합니다. 이 예에서는 C:\ExchVols의 탑재 지점이 사용됩니다. 이 위치는 Exchange 데이터베이스의 저장소를 가져오는 데 사용되는 디렉터리를 나타냅니다.
   
2. 사서함 데이터베이스의 루트 디렉터리는 또 다른 탑재 지점으로 탑재됩니다. 이 예에서는 C:\ExchDBs의 탑재 지점이 사용됩니다. 다음으로, 부모 디렉터리가 만들어지고 그 아래에 두 개의 하위 디렉터리(데이터베이스 파일용 하나와 로그 파일용 디렉터리 하나)가 만들어지는 방식으로 디렉터리 구조가 만들어집니다.
   
3. 데이터베이스가 만들어집니다. 위의 예에서는 볼륨당 단일 데이터베이스를 사용한 단순한 디자인을 보여 줍니다. 따라서 VOL1에는 총 3개의 디렉터리, 즉 부모 디렉터리와 두 개의 하위 디렉터리(MDB1의 데이터베이스 파일용과 로그용 각각 하나)가 있습니다. 예 이미지에 나타나 있지는 않지만 VOL2에도 부모 디렉터리와 그 아래에 MDB2의 데이터베이스 파일용 디렉터리 하나 및 로그 파일용 디렉터리 하나 등 총 3개의 디렉터리가 있습니다.
   

이 구성에서 MDB1 또는 MDB2에 오류가 발생할 경우 자동으로 해당 오류 데이터베이스의 복사본이 VOL3에 다시 시드됩니다.

자동 다시 시드 구성에 대한 자세한 내용은 데이터베이스 사용 가능 그룹에 대한 AutoReseed 구성 항목을 참조하십시오.

Exchange 2010에서 도입된 혁신적인 기능의 연속선상에 있는 저장소 오류 시 자동 복구 기능은 시스템이 복구 또는 중복성에 영향을 주는 오류로부터 복구될 수 있도록 합니다. Exchange 2010의 버그 확인 동작 외에도 Exchange 2013에는 I/O 시간이 길거나, Microsoft Exchange Replication Service(MSExchangeRepl.exe)의 메모리 소비량이 과도하거나, 스레드를 예약할 수 없는 심각한 경우를 위한 복구 동작이 추가로 포함되었습니다.

JBOD 환경에서도 저장소 배열 컨트롤러에 고장이나 중단 같은 문제가 발생할 수 있습니다. Exchange 2010에는 향상된 복구를 제공하는 중단 I/O 검색 및 복구 기능이 포함되어 있습니다. 다음 표에는 이러한 기능이 나열되어 있습니다.

Exchange 2013에서는 다른 심각한 상태에 대한 동작이 새로 포함되어 서버 및 저장소 복구 기능이 향상되었습니다. 다음 표에서는 이러한 상태와 동작을 설명합니다.

지연된 복사본의 향상된 기능에는 보안 네트워크와의 통합과 특정 시나리오에서의 로그 파일 자동 재생이 있습니다. 보안 네트워크는 전송 휴지통이라고 하는 Exchange 2010의 기능을 대신하는 전송 기능입니다. 보안 네트워크는 사서함 서버의 전송 서비스와 연결된 배달 큐라는 점에서 전송 휴지통과 비슷합니다. 이 큐는 사서함 서버의 활성 사서함 데이터베이스에 배달된 메시지의 복사본을 저장합니다. 사서함 서버의 각 활성 사서함 데이터베이스마다 배달된 메시지의 복사본을 저장하는 고유한 큐가 있습니다. 보안 네트워크에 해당 복사본이 저장되는 기간을 지정할 수 있으며 이 기간이 지나면 해당 메시지 복사본은 만료되어 자동으로 삭제됩니다.

보안 네트워크는 DAG 환경의 섀도 중복성에서 일부 책임을 승계합니다. DAG 환경에서 섀도 중복성 기능은 배달된 메시지의 또 다른 복사본을 섀도 큐에 보관할 필요 없이 배달된 메시지가 DAG의 다른 사서함 서버에 있는 사서함 데이터베이스의 수동 복사본에 복제될 때까지 기다립니다. 배달된 메시지의 복사본은 이미 보안 네트워크에 저장되어 있으므로 필요한 경우 섀도 중복성 기능을 통해 메시지를 보안 네트워크에서 다시 배달할 수 있습니다.

보안 네트워크를 사용하면 지연된 데이터베이스 복사본을 활성화하기가 훨씬 쉬워집니다. 예를 들어, 재생 지연 시간이 2일인 지연된 복사본의 경우 2일의 기간에 대해 보안 네트워크도 구성하게 됩니다. 지연된 복사본을 사용해야 하는 상황이 발생할 경우 해당 복사본으로의 복제를 일시 중단하고 이를 두 번 복사하여 데이터베이스의 지연된 특성을 보존하고 필요한 경우 추가 복사본을 만들 수 있습니다. 그런 다음 복사본을 선택하고 필요한 범위의 로그 파일을 제외한 모든 로그 파일을 버립니다. 복사본을 탑재하면 최근 2일 동안의 메일을 다시 배달하라는 요청이 보안 네트워크에 자동으로 트리거됩니다. 보안 네트워크를 사용하면 손상이 시작된 지점을 찾을 필요가 없습니다. 손실 장애 조치(failover)에서 일반적으로 손실되는 데이터를 제외한 최근 2일 동안의 메일을 받습니다.

지연된 복사본은 이제 다음과 같은 특정 시나리오에서 자동 로그 재생을 호출하여 로그 파일을 재생함으로써 자동으로 복구될 수 있습니다.

• 디스크 공간 부족 임계값에 도달할 경우
  
• 지연된 복사본에 물리적인 손상 부분이 있어 페이지를 패치해야 하는 경우
  
• 정상 상태의 사용 가능한 복사본(활성 또는 수동)이 24시간 이상 동안 3개 미만인 경우
  

Exchange 2010에서는 지연된 복사본에 페이지 패치를 사용할 수 없었습니다. Exchange 2013에서는 이 자동 재생 기능을 통해 지연된 복사본에 페이지 패치를 사용할 수 있습니다. 시스템이 지연된 복사본에 대한 페이지 패치가 필요하다고 감지하면 페이지 패치를 수행하기 위해 자동으로 로그가 지연된 복사본으로 재생됩니다. 지연된 복사본은 낮은 디스크 공간 임계값에 도달한 경우와 지연된 복사본이 특정 기간 동안 유일하게 사용할 수 있는 복사본으로 감지된 경우에도 이 자동 재생 기능을 호출합니다.

지연된 복사본 재생 동작은 기본적으로 사용하지 않도록 설정되어 있으며 다음 명령을 실행하면 이를 사용하도록 설정할 수 있습니다.

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

재생 동작을 사용하도록 설정한 후 복사본 수가 3개 미만이면 재생이 발생합니다. 다음 레지스트리 값을 수정하면 기본값 3을 변경할 수 있습니다.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

디스크 공간 부족 임계값에 도달할 경우 재생을 사용하도록 설정하려면 다음 레지스트리 항목을 추가로 구성해야 합니다.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagPlayDownPercentDiskFreeSpace

서버가 안정적으로 작동 중인지, 사서함 데이터베이스 복사본이 정상적인 상태인지 확인하는 것은 일상적인 Exchange 2013 메시징 작업의 기본 목표입니다. 하드웨어, Windows 운영 체제 및 Exchange 서비스도 활발히 모니터링해야 합니다. 그러나 Exchange 2013 사서함 복구 환경에서 실행할 때는 DAG와 사서함 데이터베이스 복사본의 상태를 모니터링하는 것이 중요합니다. 특히 데이터 중복성 위험 관리 작업을 수행하고 복제된 데이터베이스가 단일 복사본으로만 존재하는 기간을 모니터링하는 것은 매우 중요합니다. 이는 RAID(Redundant Array of Independent Disks)를 사용하지 않는 대신 JOBD 구성을 배포하는 환경에서 특히 중요합니다. RAID 환경에서는 단일 디스크 오류가 활성 사서함 데이터베이스 복사본에 영향을 주지 않습니다. 그러나 JBOD 환경에서는 단일 디스크 오류로 인해 데이터베이스 장애 조치(failover)가 트리거됩니다.

Exchange 2010에서는 CheckDatabaseRedundancy.ps1 스크립트를 도입했습니다. 이름에서 알 수 있듯이, 이 스크립트의 용도는 정상적인 최신 복사본이 두 개 이상 구성되어 있는지 확인하여 복제된 사서함 데이터베이스의 중복성을 모니터링하고, 복제된 데이터베이스의 정상적인 복사본이 하나만 있을 경우 이벤트 로그를 생성하여 관리자에게 경고하는 것입니다. 이런 경우, 중복성을 확인할 때 활성 및 수동 복사본 모두가 합산됩니다.

복사본이 하나만 존재하게 되는 경우의 예는 다음과 같습니다.

• 활성 복사본을 수동 복사본에 복제하지 못했습니다.
  
• 모든 수동 복사본에 오류가 있습니다. 여기에는 FailedAndSuspended 및 Failed 상태뿐 아니라 정상 상태지만 복사본의 로그 복사 또는 재생이 늦은 경우도 포함됩니다. 지연된 복사본의 로그 재생이 지연 기간에 대해 10분 이내 범위에서 이루어지는 경우에는 지연된 복사본이 늦은 것으로 간주되지 않습니다.
  
• 시스템에서 활성 복사본의 최신 로그 생성을 정확히 알지 못합니다.
  

관리자는 최우선적으로 정상 상태의 데이터베이스 복사본이 하나만 존재하는 시기를 알아야 하므로 CheckDatabaseRedundancy.ps1 스크립트는 관리되는 가용성의 일부인 통합된 기본 기능으로 대체되었습니다.

이 기본 기능도 이벤트 로그 알림을 통해 관리자에게 경고를 보내며, Exchange 2013 경고를 Exchange 2010과 구별하기 위해 Exchange 2013에서는 다음 이벤트 ID를 사용합니다.

• 이벤트 4138(빨간색 경고)
  
• 이벤트 4139(녹색 경고)
  

Exchange 2013에서는 동일한 서버의 여러 데이터베이스가 단일 복사본 상태가 될 때 발생할 수 있는 경고 노이즈의 수준을 낮추도록 기본 기능이 향상되었습니다. Exchange 2010에서는 단일 복사본 경고가 데이터베이스 수준에서 생성되었습니다. 따라서 여러 데이터베이스와 여러 데이터베이스 복사본에 영향을 주는 서버 차원의 문제가 발생할 경우에는 경고 폭풍이 발생할 수 있었습니다. 컨트롤러 또는 메모리 문제 등 몇몇 오류는 서버 쪽에서 발생하므로 그러한 경고 폭풍이 서버 인시던트마다 발생할 가능성이 높았습니다. Exchange 2013에서는 이제 경고가 서버 단위로 생성됩니다. 서버 중단으로 인해 전체 서버가 영향을 받고 여러 데이터베이스 복사본에 대한 데이터 중복성에 위험이 생길 경우 이제는 서버별로 단일 경고가 생성됩니다.

DAG 네트워크는 복제 트래픽 또는 MAPI 트래픽용으로 사용되는 하나 이상의 서브넷 모음입니다. 각 DAG는 최대 한 개의 MAPI 네트워크와 0개 이상의 복제 네트워크를 포함합니다. Exchange 2010에서 시스템이 만드는 초기 DAG 네트워크(예: DAGNetwork01 및 DAGNetwork02)는 클러스터 서비스에서 열거한 서브넷을 기반으로 했습니다. 여러 네트워크가 사용되며 특정 네트워크(예: MAPI 네트워크)의 여러 인터페이스가 동일한 서브넷에 있는 환경에서는 관리자가 수행해야 하는 추가 구성이 매우 드물었습니다. 그러나 특정 네트워크의 인터페이스가 여러 서브넷에 있는 환경에서는 관리자가 DAG 네트워크 축소라는 작업을 수행해야 했습니다.

Exchange 2013에서는 DAG 네트워크 축소가 더 이상 필요하지 않습니다. Exchange 2013에서도 동일한 검색 메커니즘을 사용하여 MAPI 네트워크와 복제 네트워크를 구별하지만 이제 DAG 네트워크 축소는 적절하게 자동으로 수행됩니다.

또한 DAG 네트워크는 기본적으로 시스템에서 자동으로 관리됩니다. EAC(Exchange 관리 센터)를 사용하여 DAG 네트워크 속성을 보려면 EAC에서 DAG의 속성을 수정하거나 Set-DatabaseAvailabilityGroup cmdlet을 사용하여 ManualDagNetworkConfiguration 매개 변수를 True로 설정하는 방법으로 DAG를 수동 네트워크 제어가 가능하도록 구성해야 합니다.

BCS(최상의 복사본 선택)는 활성화할 수 있는 복사본과 해당 복사본의 상태가 목록으로 나열될 경우 개별 데이터베이스의 복사본 중 활성화할 최상의 복사본을 찾기 위한 내부 알고리즘 프로세스입니다. Active Manager는 기존 활성 데이터베이스 복사본이 실패하거나 관리자가 대상 없는 전환을 수행할 때 사용이 가능하고 차단되지 않은 최적의 복사본을 새 활성 데이터베이스 복사본으로 선택합니다. Exchange 2010에서는 BCS 프로세스가 각 데이터베이스 복사본의 여러 가지 요소를 평가하여 활성화하기에 최적의 복사본을 확인했습니다. 이러한 요소는 다음과 같습니다.

• 복사 큐 길이
  
• 재생 큐 길이
  
• 데이터베이스 상태
  
• 콘텐츠 인덱스 상태
  

Exchange 2013에서 Active Manager는 동일한 BCS 검사 및 단계를 수행하여 복제 상태를 확인하지만 내림차순 상태 제약 조건도 사용한다는 차이점이 있습니다. 이러한 변경의 결과로 BCS를 이제는 BCSS(최상의 복사 및 서버 선택)라고 합니다.

Exchange 2013의 경우 기본 제공 관리되는 가용성 모니터링 구성 요소의 일부인 몇 가지 새로운 상태 검사 기능이 BCSS에 포함되어 있습니다. Active Manager가 새로 수행하는 추가 확인은 네 가지이며 수행되는 순서대로 아래에 나열되어 있습니다.

1. 모두 정상   영향을 받은 데이터베이스의 모든 모니터링 구성 요소가 정상 상태인 복사본을 호스트하는 서버가 있는지 확인합니다.
   
2. 보통 정상   영향을 받은 데이터베이스의 보통 우선 순위의 모든 모니터링 구성 요소가 정상 상태인 복사본을 호스트하는 서버가 있는지 확인합니다.
   
3. 모두 원본보다 양호   영향을 받은 데이터베이스의 복사본을 호스트하는 현재 서버보다 모니터링 구성 요소의 상태가 양호한 복사본을 호스트하는 서버가 있는지 확인합니다.
   
4. 원본과 동일   영향을 받은 데이터베이스의 복사본을 호스트하는 현재 서버와 모니터링 구성 요소의 상태가 동일한 복사본을 호스트하는 서버가 있는지 확인합니다.
   

BCSS는 예를 들면, 장애 조치(failover) 응답자를 통해 관리되는 가용성 모니터링 구성 요소가 트리거하는 장애 조치(failover)의 결과로 호출되며, 대상 서버의 구성 요소 상태가 장애 조치(failover)가 발생한 서버보다 양호해야 한다는 필수 제약 조건이 추가로 적용됩니다. 예를 들어, Microsoft Office Outlook Web App가 장애 조치(failover) 응답기를 통해 장애 조치(failover)를 트리거하면 BCSS는 영향을 받은 데이터베이스를 호스트하는 서버 중에서 Outlook Web App가 정상 상태인 서버를 선택해야 합니다.