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

적용 대상: Exchange Server 2013 SP1

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

  • Exchange 2010을 통해 IOPS 감소: 이렇게 하면 용량 및 IOPS 측면에서 더 큰 디스크를 최대한 효율적으로 활용할 수 있습니다.

  • 관리되는 가용성: 관리되는 가용성을 통해 내부 모니터링 및 복구 지향 기능이 긴밀하게 통합되어 오류를 방지하거나, 서비스를 능동적으로 복원하거나, 서버 장애 조치(failover)를 자동으로 시작하거나, 관리자에게 조치를 취하도록 경고할 수 있습니다. 핵심은 서비스를 지속적으로 사용 가능한 상태로 유지할 수 있도록 서버 및 구성 요소의 작동 시간뿐만 아니라 최종 사용자 환경을 모니터링하고 관리하는 데 있습니다.

  • 관리 저장소: 관리 저장소는 Exchange 2013에서 새로 다시 작성된 정보 저장소 프로세스의 이름입니다. 새 관리 저장소는 C# 로 작성되었으며 복원력 향상을 통해 고가용성을 제공하기 위해 Microsoft Exchange 복제 서비스(MSExchangeRepl.exe)와 긴밀하게 통합됩니다.

  • 디스크당 여러 데이터베이스 지원: Exchange 2013에는 동일한 디스크에서 여러 데이터베이스(활성 및 수동 복사본 혼합)를 지원할 수 있는 향상된 기능이 포함되어 있으므로 용량 및 IOPS 측면에서 더 큰 디스크를 최대한 효율적으로 활용할 수 있습니다.

  • AutoReseed: 자동 다시 크기 조정 기능을 사용하면 디스크 오류 후 데이터베이스 중복성을 신속하게 복원할 수 있습니다. 디스크 오류가 발생하면 해당 디스크에 저장된 데이터베이스 복사본이 활성 데이터베이스 복사본에서 동일한 서버의 예비용 디스크로 복사됩니다. 여러 데이터베이스 복사본이 실패한 디스크에 저장된 경우 해당 복사본을 모두 자동으로 예비용 디스크에 다시 시드할 수 있습니다. 이렇게 하면 활성 데이터베이스가 여러 서버에 있을 가능성이 높아지고 데이터가 병렬로 복사되므로 다시 시드 속도가 더 빨라집니다.

  • 스토리지 오류로부터 자동 복구: 이 기능은 시스템이 복원력 또는 중복성에 영향을 주는 오류로부터 복구할 수 있도록 Exchange 2010에 도입된 혁신을 계속합니다. Exchange 2010 버그 검사 동작 외에도 Exchange 2013에는 긴 I/O 시간에 대한 추가 복구 동작, MSExchangeRepl.exe 의한 과도한 메모리 사용, 시스템이 스레드를 예약할 수 없는 상태가 심각한 경우 등이 포함됩니다.

  • 지연된 복사 기능 향상: 이제 지연된 복사본은 자동 로그 재생을 사용하여 어느 정도 자신을 돌볼 수 있습니다. 지연된 복사본은 페이지 패치 및 디스크 공간 부족 시나리오와 같은 다양한 상황에서 로그 파일을 자동으로 재생합니다. 시스템이 지연된 복사본에 대한 페이지 패치가 필요하다고 감지하면 페이지 패치를 수행하기 위해 자동으로 로그가 지연된 복사본으로 재생됩니다. 지연된 복사본은 낮은 디스크 공간 임계값에 도달한 경우와 지연된 복사본이 특정 기간 동안 유일하게 사용할 수 있는 복사본으로 감지된 경우에도 이 자동 재생 기능을 호출합니다. 또한 지연된 복사본은 Safety Net을 사용하여 복구 또는 정품 인증을 훨씬 쉽게 수행할 수 있습니다.

  • 단일 복사 경고 개선 사항: Exchange 2010에 도입된 단일 복사 경고는 더 이상 별도의 예약된 스크립트가 아닙니다. 이 기능은 이제 시스템 내의 관리되는 가용성 구성 요소에 통합되었으며 Exchange 내의 기본 기능입니다.

  • DAG 네트워크 자동 구성: DAG 네트워크는 구성 설정에 따라 시스템에서 자동으로 구성할 수 있습니다. 수동 구성 옵션 외에도 DAG가 자동으로 MAPI 네트워크와 복제 네트워크를 구분하고 DAG 네트워크를 구성할 수 있습니다.

Exchange 2010에 비해 IOPS 감소

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에서는 복사본 하나에 대해 초당 약 1~2MB를 처리합니다.

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

관리되는 가용성

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

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

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

  • Exchange Health Manager 작업자 프로세스(MSExchangeHMWorker.exe): 런타임 작업을 수행하는 작업자 프로세스입니다.

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

  • XML 구성 파일은 작업 프로세스를 시작하는 동안 작업 항목 정의를 초기화하는 데 사용됩니다.

  • 레지스트리는 책갈피 같은 런타임 데이터를 저장하는 데 사용됩니다.

  • Crimson 채널 이벤트 로그 인프라는 작업 항목 결과를 저장하는 데 사용됩니다.

고가용성에 대한 자세한 내용은 관리되는 가용성 항목을 참조하세요.

관리되는 저장소

Exchange Server 4.0부터 2010년 Exchange Server Exchange Server 모든 이전 버전은 사서함 서버 역할에서 Store.exe(Information Store 프로세스)의 단일 인스턴스 실행을 지원했습니다. 이 단일 저장소 인스턴스는 서버의 모든 데이터베이스(활성, 수동, 지연 및 복구)를 호스트합니다. 이전 Exchange 아키텍처에서는 사서함 서버에서 호스트되는 다른 데이터베이스 간에 격리가 거의 없습니다. 단일 사서함 데이터베이스의 문제는 다른 모든 데이터베이스에 부정적인 영향을 줄 수 있으며 사서함 손상으로 인한 충돌은 해당 서버에서 데이터베이스가 호스트되는 모든 사용자의 서비스에 영향을 줄 수 있습니다.

이전 버전의 Exchange에서 단일 Store 인스턴스의 또 다른 과제는 ESE(확장 가능 스토리지 엔진)가 8-12 프로세서 코어로 잘 확장되지만 그 이상으로 프로세서 간 통신 및 캐시 동기화 문제로 인해 음수 크기가 발생한다는 것입니다. 16개 이상의 코어 시스템을 사용할 수 있는 오늘날의 훨씬 더 큰 서버를 감안할 때, 이는 ESE에 대한 8-12 코어의 선호도를 관리하고 다른 코어를 비 스토어 프로세스(예: Assistants, Search Foundation, Managed Availability 등)에 사용하는 관리 과제를 부과합니다. 또한 이전 아키텍처는 Store 프로세스에 대한 강화를 제한했습니다.

Store.exe 프로세스는 Exchange Server 자체적으로 발전함에 따라 수년에 걸쳐 상당히 발전해 왔지만, 단일 프로세스로서 궁극적으로 확장성이 제한되며 단일 실패 지점을 나타냅니다. 이러한 제한으로 인해 Store.exe Exchange 2013에서 사라지고 관리되는 저장소로 대체됩니다.

자세한 내용은 관리 저장소를 참조하세요.

볼륨당 여러 개의 데이터베이스

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가 됩니다.

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

데이터베이스 크기가 클수록 데이터베이스를 다시 시드하는 데 오래 걸립니다. 예를 들어 2테라바이트 데이터베이스는 다시 크기 조정하는 데 23시간이 걸릴 수 있지만 8테라바이트 데이터베이스는 93시간(거의 4일)이 걸릴 수 있습니다. 두 시드는 모두 초당 약 20MB로 발생합니다. 이는 일반적으로 초대형 데이터베이스를 작업상 합리적인 시간 내에 시드할 수 없음을 의미합니다.

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

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

  • 실제 디스크당 논리 디스크 파티션 하나를 사용해야 합니다. 디스크에 파티션을 여러 개 만들지 마세요. 각 데이터베이스 복사본과 해당 트랜잭션 로그, 콘텐츠 인덱스 등의 수반되는 파일은 단일 파티션의 고유 디렉터리에서 호스트되어야 합니다.

  • 볼륨당 구성된 데이터베이스 복사본 수는 각 데이터베이스의 복사본 수와 같아야 합니다. 예를 들어, 데이터베이스 복사본이 네 개인 경우 볼륨당 네 개의 데이터베이스 복사본을 사용해야 합니다.

  • 데이터베이스 복사본은 동일한 환경을 가져야 합니다. 예를 들면, 데이터베이스 복사본은 모두 각 서버에서 동일한 디스크를 공유해야 합니다.

  • 특정 디스크의 각 데이터베이스 복사본이 고유한 활성화 기본 설정 값을 갖도록 DAG에서 활성화 기본 설정의 균형을 조정해야 합니다.

AutoReseed

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

자세한 내용은 AutoReseed을 참조하세요. 자세한 AutoReseed 구성 단계는 데이터베이스 가용성 그룹에 대 한 자동 다시 시드를 구성 합니다.을 참조하세요.

저장소 오류 시 자동 복구

Exchange 2010에서 도입된 혁신적인 기능의 연속선상에 있는 저장소 오류 시 자동 복구 기능은 시스템이 복구 또는 중복성에 영향을 주는 오류로부터 복구될 수 있도록 합니다. Exchange 2010 버그 검사 동작 외에도 Exchange 2013에는 긴 I/O 시간에 대한 추가 복구 동작, microsoft Exchange 복제 서비스(MSExchangeRepl.exe)의 과도한 메모리 사용 및 스레드를 예약할 수 없는 심각한 경우가 포함됩니다.

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

이름 수표 작업 임계값
ESE 데이터베이스의 중단된 I/O 감지 처리되지 않은 I/O에 대한 ESE 검사 크림슨 채널에 오류 항목을 생성하여 서버 다시 시작 240초
오류 항목 채널 하트비트 오류 항목을 Crimson 채널에 쓰고 Crimson 채널에서 읽을 수 있는지 확인 Replication Service가 크림슨 채널을 하트비트하고 오류 시 서버 다시 시작 30초
시스템 디스크 하트비트 서버의 시스템 디스크 상태 확인 버퍼링되지 않은 I/O를 주기적으로 시스템 디스크에 전송하고 하트비트 시간이 초과되면 서버 다시 시작 120초

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

이름 수표 작업 임계값
시스템 상태 불량 관리되지 않는 스레드를 포함한 어떤 스레드도 예약할 수 없음 서버 다시 시작 302초
긴 I/O 시간 I/O 작업 대기 시간 측정 서버 다시 시작 41초
Replication Service 메모리 사용 MSExchangeRepl.exe의 작업 집합 측정
  1. 크림슨 채널에 서비스 종료 요청과 함께 이벤트 4395 기록
  2. MSExchangeRepl.exe의 종료 시작
  3. 서비스 종료에 실패할 경우 서버 다시 시작
4GB
시스템 이벤트 129(버스 재설정) 시스템 이벤트 로그에서 이벤트 129 확인 서버 다시 시작 이벤트가 발생할 경우
클러스터 데이터베이스 중단 글로벌 업데이트 관리자 업데이트가 차단됨 서버 다시 시작 이벤트가 발생할 경우

지연된 복사본 기능 향상

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

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

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

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

  • 디스크 공간 부족 임계값에 도달할 경우

  • 지연된 복사본에 물리적인 손상 부분이 있어 페이지를 패치해야 하는 경우

  • 정상 상태의 사용 가능한 복사본(활성 또는 수동만 포함하며 지연된 데이터베이스 복사본은 계산에서 제외)이 24시간 이상 동안 3개 미만인 경우

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

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

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

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

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

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

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

이러한 레지스트리 설정을 구성한 후에 Microsoft Exchange DAG Management Service를 다시 시작하여 변경 내용을 적용합니다.

한 가지 예로, 지정된 데이터베이스에 4개의 복사본(3개의 고가용성 복사본과 1개의 지연된 복사본)이 있고 기본 설정이 ReplayLagManagerNumAvailableCopies 에 사용되는 환경을 고려해봅니다. 지연되지 않은 복사본이 어떤 이유(예: 일시 중단 등)로 인해 작동되지 않으면 지연된 복사본이 24시간 후에 자동으로 로그 파일을 재생합니다.

단일 복사본 경고 기능 향상

서버가 안정적으로 작동 중인지, 사서함 데이터베이스 복사본이 정상적인 상태인지 확인하는 것은 일상적인 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 스크립트는 관리되는 가용성 DataProtection 상태 집합의 일부인 통합된 기본 기능으로 대체되었습니다.

네이티브 기능은 여전히 이벤트 로그 알림을 통해 관리자에게 경고하고 Exchange 2010과 Exchange 2013 경고를 구분하기 위해 Exchange 2013에서는 다음 이벤트 ID를 사용합니다.

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

  • 이벤트 4139(녹색 경고)

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

DAG 네트워크 자동 구성

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(최상의 복사 및 서버 선택)라고 합니다.

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

  1. 모두 정상: 모든 모니터링 구성 요소가 정상 상태인 영향을 받는 데이터베이스의 복사본을 호스팅하는 서버를 확인합니다.

  2. 정상 상태까지: 정상 상태의 우선 순위가 정상인 모든 모니터링 구성 요소가 있는 영향을 받는 데이터베이스의 복사본을 호스팅하는 서버를 확인합니다.

  3. 원본보다 더 나은 기능: 영향을 받는 복사본을 호스팅하는 현재 서버보다 더 나은 상태의 모니터링 구성 요소가 있는 영향을 받는 데이터베이스의 복사본을 호스팅하는 서버를 확인합니다.

  4. 원본과 동일: 영향을 받는 복사본을 호스팅하는 현재 서버와 동일한 상태의 모니터링 구성 요소가 있는 영향을 받는 데이터베이스의 복사본을 호스팅하는 서버를 확인합니다.

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

DAG Management Service

Exchange 2013의 RTM(Release To Manufacturing) 버전용 CU2(누적 업데이트 2)에는 DAG의 구성원인 사서함 서버에 대한 새로운 서비스가 포함되어 있습니다. 이 서비스를 Microsoft Exchange DAG Management Service(MSExchangeDAGMgmt)라고 합니다. 이 새로운 서비스에는 이전에 Microsoft Exchange Replication Service(MSExchangeRepl) 내부에서 실행되었던 내부 DAG 모니터링 기능이 포함되어 있습니다.

클러스터 관리 액세스 포인트가 없는 DAG

Windows Server 2008 R2 또는 Windows Server 2012를 실행하는 모든 DAG에는 MAPI 네트워크에 포함된 모든 서브넷의 IP 주소가 하나 이상 필요합니다. DAG에 할당된 IP 주소는 클러스터 관리 액세스 포인트(클러스터 네트워크 이름이라고도 함)가 포함된 DAG 클러스터로 이름 확인 및 클러스터 이름을 사용한 클러스터 연결(구체적으로는 현재 클러스터 핵심 리소스 그룹을 소유한 클러스터 구성원에 연결)을 사용하도록 설정하는 데 사용됩니다. Windows Server 2012 R2에서는 관리 액세스 포인트가 없는 장애 조치(failover) 클러스터를 만들 수 있습니다. 관리 액세스 포인트가 없는 Windows 장애 조치(failover) 클러스터의 특징은 다음과 같습니다.

  • 클러스터에 IP 주소가 할당되지 않으므로 클러스터 핵심 리소스 그룹에 IP 주소 리소스가 없습니다.

  • 클러스터에 네트워크 이름이 할당되지 않으므로 클러스터 핵심 리소스 그룹에 네트워크 이름 리소스가 없습니다.

  • 클러스터의 이름이 DNS에 등록되지 않으며 네트워크에서 확인할 수 없습니다.

  • CNO(클러스터 이름 개체)가 Active Directory에서 만들어지지 않습니다.

  • Windows 장애 조치(failover) 클러스터는 장애 조치(failover) 클러스터 관리 도구를 사용하여 관리할 수 없습니다. 클러스터는 Windows PowerShell을 사용하여 관리해야 하며 개별 클러스터 구성원에 대해 PowerShell cmdlet을 실행해야 합니다.

Windows Server 2012 R2 이상에서 실행하는 경우에는 Exchange 2013 SP1(서비스 팩 1) 이상을 설치하면 클러스터 관리 액세스 포인트가 없는 DAG를 만들 수 있습니다. Exchange 관리 센터를 사용하거나 셸을 사용하여 관리 액세스 지점 없이 DAG를 만들 수 있습니다. 자세한 내용은 DAG 만들기데이터베이스 가용성 그룹 만들기를 참조하세요.