이전 버전의 Exchange Server 고가용성 및 사이트 복원력 변경

아티클
04/04/2023

Exchange Server 2013 이상에서는 DAG 및 사서함 데이터베이스 복사본(단일 항목 복구, 보존 정책 및 지연된 데이터베이스 복사본과 같은 다른 기능과 함께)을 사용하여 고가용성, 사이트 복원력 및 Exchange 네이티브 데이터 보호를 제공합니다. 고가용성 플랫폼, Exchange Information Store 및 ESE(Extensible Storage Engine)는 모두 Exchange 2010 이후 개선되어 가용성과 복잡한 관리를 제공하고 비용을 절감할 수 있습니다. 향상된 기능은 다음과 같습니다.

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

IOPS 감소

Exchange 2010에서는 수동 데이터베이스 복사본의 검사점 깊이가 낮으므로 빠른 장애 조치(failover)에 필요합니다. 또한 수동 복사는 데이터의 적극적인 사전 읽기를 수행하여 5MB(메가바이트) 검사점 깊이를 유지합니다. 낮은 검사점 깊이를 사용하고 이러한 적극적인 사전 읽기 작업을 수행한 결과로 수동 데이터베이스 복사본에 대한 IOPS는 Exchange 2010의 활성 복사본에 대한 IOPS와 같습니다.

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

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

그 밖의 변경 사항 중 하나는 BDM(백그라운드 데이터베이스 유지 관리) 프로세스에 대한 것입니다. 이제 BDM에서는 복사본 하나에 대해 초당 약 1~2MB를 처리합니다.

이러한 변경으로 인해 Exchange는 이제 Exchange 2010을 통해 IOPS를 크게 줄입니다.

관리되는 가용성

관리되는 가용성은 기본 제공, 활성 모니터링 및 Exchange 고가용성 플랫폼의 통합입니다. 관리 가용성을 사용하면 시스템에서 서비스 상태에 따라 데이터베이스를 장애 조치(failover)할 시기를 결정할 수 있습니다. 관리되는 가용성은 사서함 서버의 클라이언트 액세스(프런트 엔드) 서비스 및 백 엔드 서비스에 배포되는 내부 인프라입니다. 관리되는 가용성에는 지속적으로 작업을 수행하는 세 가지 주요 비동기 구성 요소가 포함됩니다.

첫 번째 구성 요소는 서버에서 측정을 수행하고 데이터를 수집하는 프로브 엔진입니다. 이러한 측정 결과는 두 번째 구성 요소인 모니터로 흐릅니다.
모니터에는 수집된 데이터에서 정상으로 간주되는 항목에 따라 시스템에서 사용하는 모든 비즈니스 논리가 포함됩니다. 패턴 인식 엔진과 마찬가지로 모니터는 수집된 모든 측정값에서 다양한 패턴을 찾은 다음, 정상으로 간주되는지 여부를 결정합니다.
마지막으로 복구 작업을 담당하는 응답자 엔진이 있습니다.

비정상 상태인 경우 첫 번째 작업은 해당 구성 요소를 복구하는 것입니다. 여기에는 다단계 복구 작업이 포함될 수 있습니다. 예를 들어:

응용 프로그램 풀을 다시 시작합니다.
서비스를 다시 시작합니다.
서버를 다시 시작합니다.
더 이상 트래픽을 허용하지 않도록 서버를 오프라인으로 전환합니다.

복구 작업이 실패하면 시스템은 이벤트 로그 알림을 통해 인간에게 문제를 에스컬레이션합니다.

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

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

관리되는 가용성은 영구 스토리지를 사용하여 해당 기능을 수행합니다.

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

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

관리되는 저장소

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

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

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

자세한 내용은 Managed Store를 참조하세요.

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

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

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

스토리지 용량 증가 추세는 계속됩니다. 예를 들어 8테라바이트 드라이브의 최대 데이터베이스 크기(2테라바이트)에 대한 Exchange 모범 사례 지침은 5테라바이트 이상의 디스크 공간을 낭비한다는 것을 의미합니다.

해결 방법은 데이터베이스를 더 크게 늘리는 것이지만, 이는 긴 재시드 시간(운영적으로 관리되지 않는 재시드 시간 포함)을 도입하고 네트워크를 통해 해당 양의 데이터를 복사하는 안정성이 손상될 수 있기 때문에 관리 효율성이 저하됩니다.

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

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

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

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

볼륨당 여러 데이터베이스.

다이어그램의 구성은 대칭 디자인을 제공합니다. 4개의 서버 모두 서버당 단일 디스크에 호스트되는 동일한 4개의 데이터베이스를 갖습니다. 키는 가지고 있는 각 데이터베이스의 복사본 수가 디스크당 데이터베이스 복사본 수와 같아야 한다는 것입니다.

다이어그램의 구성에는 각 데이터베이스의 복사본 4개(활성 복사본 1개, 수동 복사본 2개, 지연된 복사본 1개)가 있습니다. 각 데이터베이스의 복사본은 4개이므로 적절한 구성은 볼륨당 4개의 복사본이 있는 복사본입니다.

또한 DAG 및 각 서버 간에 균형을 맞추도록 활성화 기본 설정이 구성됩니다. 예시:

활성 복사본의 활성화 기본 설정 값은 1입니다.
첫 번째 수동 복사본의 활성화 기본 설정 값은 2입니다.
두 번째 수동 복사본의 활성화 기본 설정 값은 3입니다.
지연된 복사본의 활성화 기본 설정 값은 4입니다.

기존 볼륨에서 사용자를 더 잘 배포하는 것 외에도 디스크당 여러 데이터베이스를 사용할 경우의 또 다른 이점은 다시 시딩해야 하는 오류(예: 디스크 오류)에 대한 데이터 보호를 복원하는 데 걸리는 시간이 줄어든다는 것입니다.

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

디스크당 단일 데이터베이스 복사본 시나리오의 경우에는 항상 단일 원본에서 디스크를 시드하므로 시드 작업이 사실상 원본의 제한을 받습니다.

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

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

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

AutoReseed

자동 다시 크기 조정(AutoReseed라고도 함)은 디스크 오류, 데이터베이스 손상 이벤트 또는 데이터베이스 복사본을 다시 설정해야 하는 기타 문제에 대한 응답으로 일반적으로 관리자 기반 작업을 대체합니다. AutoReseed는 디스크 오류가 발생한 후 시스템에 프로비전된 예비용 디스크를 사용하여 데이터베이스 중복성을 자동으로 복원하기 위한 것입니다.

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

저장소 오류 시 자동 복구

스토리지 오류에서 자동 복구를 사용하면 시스템이 복원력 또는 중복성에 영향을 주는 오류로부터 복구할 수 있습니다. Exchange 2010에 도입된 버그 검사 동작 외에도 Exchange에는 이제 긴 I/O 시간, Microsoft Exchange 복제 서비스(MSExchangeRepl.exe)의 과도한 메모리 사용 및 스레드를 예약할 수 없는 심각한 경우에 대한 추가 복구 동작이 포함됩니다.

JBOD 환경에서도 저장소 배열 컨트롤러에 고장이나 중단 같은 문제가 발생할 수 있습니다. 다음 표에서는 향상된 복원력을 제공하는 중단된 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 확인	서버 다시 시작	이벤트가 발생할 경우
클러스터 데이터베이스 중단	글로벌 업데이트 관리자 업데이트가 차단됨	서버 다시 시작	이벤트가 발생할 경우

지연된 복사본 기능 향상

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

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

Safety Net을 사용하면 지연된 데이터베이스 복사본을 활성화하는 것이 더 쉬워집니다. 예를 들어 2일 재생 지연이 있는 지연된 복사본을 고려합니다. 이 경우 2일 동안 Safety Net을 구성합니다. 지연된 복사본을 사용해야 하는 상황이 발생하면 다음을 수행할 수 있습니다.

복제를 일시 중단합니다.
데이터베이스의 지연된 특성을 유지하고 필요한 경우 추가 복사본을 만들려면 두 번 복사합니다.
복사본을 가져와서 필요한 범위에 있는 로그 파일을 제외한 모든 로그 파일을 삭제합니다.
지난 2일간의 메일을 다시 배달하기 위해 Safety Net에 자동 요청을 트리거하는 복사본을 탑재합니다.

Safety Net을 사용하면 부패 지점이 도입된 위치를 헌팅할 필요가 없습니다. 손실된 장애 조치(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 메시징 작업의 주요 목표입니다. 하드웨어, Windows 운영 체제 및 Exchange 서비스도 활발히 모니터링해야 합니다.

그러나 Exchange 사서함 복원력 환경에서는 DAG 및 사서함 데이터베이스 복사본의 상태와 상태를 모니터링하는 것이 중요합니다. 특히 데이터 중복성 위험 관리 작업을 수행하고 복제된 데이터베이스가 단일 복사본으로만 존재하는 기간을 모니터링하는 것은 매우 중요합니다. 이는 RAID(독립 디스크 중복 배열)를 사용하지 않고 JBOD 구성을 배포하는 환경에서 매우 중요합니다. RAID 환경에서는 단일 디스크 오류가 활성 사서함 데이터베이스 복사본에 영향을 주지 않습니다. 그러나 JBOD 환경에서는 단일 디스크 오류로 인해 데이터베이스 장애 조치(failover)가 트리거됩니다.

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

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

활성 복사본을 수동 복사본에 복제하지 못했습니다.
로그 복사 또는 재생에서 복사본이 뒤에 있는 정상 상태 외에도 FailedAndSuspended 및 Failed 상태를 포함하는 모든 수동 복사본의 실패입니다. 지연된 복사본은 로그를 지연 기간으로 재생한 후 10분 이내에 지연된 복사본으로 간주되지 않습니다.
시스템에서 활성 복사본의 최신 로그 생성을 정확히 알지 못합니다.

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

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

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

동일한 서버의 여러 데이터베이스가 단일 복사 조건에 들어갈 때 발생하는 경고 노이즈를 줄이기 위해 네이티브 기능이 향상되었습니다. Exchange 2010에서는 단일 복사본 경고가 데이터베이스 수준에서 생성되었습니다. 결과적으로 여러 데이터베이스 및 여러 데이터베이스 복사본에 영향을 주는 서버 전체 문제로 인해 경고가 발생할 수 있습니다. 여러 오류는 서버 전체(예: 컨트롤러 또는 메모리 문제)이므로 각 서버 인시던트에 대해 경고 폭풍이 발생할 가능성이 있었습니다.

이제 경고는 서버별로 생성됩니다. 중단이 전체 서버에 영향을 미치고 여러 데이터베이스 복사본에 대한 데이터 중복성이 위험해지면 서버별 단일 경고가 생성됩니다.

DAG 네트워크 자동 구성

DAG 네트워크는 복제 트래픽 또는 MAPI 트래픽용으로 사용되는 하나 이상의 서브넷 모음입니다. 각 DAG는 최대 한 개의 MAPI 네트워크와 0개 이상의 복제 네트워크를 포함합니다.

Exchange 2010에서는 클러스터 서비스에서 열거한 서브넷을 기반으로 시스템에서 초기 DAG 네트워크(예: DAGNetwork01 및 DAGNetwork02)를 만들었습니다. 여러 네트워크가 있고 지정된 네트워크(예: MAPI 네트워크)에 대한 인터페이스가 동일한 서브넷에 있는 경우 추가 구성이 거의 필요하지 않았습니다. 그러나 지정된 네트워크에 대한 인터페이스가 여러 서브넷에 있는 경우 DAG 네트워크 축소라는 작업을 수행해야 했습니다.

Exchange 2013 이상에서는 DAG 네트워크를 더 이상 축소할 필요가 없습니다. Exchange는 여전히 동일한 검색 메커니즘을 사용하여 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에서 기본 제공 관리되는 가용성 모니터링 구성 요소의 일부인 몇 가지 새로운 상태 검사가 포함되어 있습니다. Active Manager에서 수행하는 네 가지 추가 검사가 있습니다(수행되는 순서로 나열됨).

모든 정상: 모든 모니터링 구성 요소가 정상 상태인 영향을 받는 데이터베이스의 복사본을 호스팅하는 서버를 확인합니다.
정상 정상까지: 정상 상태의 우선 순위가 정상인 모든 모니터링 구성 요소가 있는 영향을 받는 데이터베이스의 복사본을 호스팅하는 서버를 확인합니다.
All Better than Source: 영향을 받는 복사본을 호스트하는 현재 서버보다 더 나은 상태의 모니터링 구성 요소가 있는 영향을 받는 데이터베이스의 복사본을 호스팅하는 서버를 확인합니다.
원본과 동일: 영향을 받는 복사본을 호스팅하는 현재 서버와 동일한 상태의 모니터링 구성 요소가 있는 영향을 받는 데이터베이스의 복사본을 호스팅하는 서버를 확인합니다.

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

DAG Management Service

Exchange 2013 CU2 이상에는 MICROSOFT Exchange DAG 관리 서비스(MSExchangeDAGMgmt)가 포함됩니다. 이 서비스에는 이전에 MSExchangeRepl(Microsoft Exchange Replication Service) 내에 있던 내부 DAG 모니터링 기능이 포함되어 있습니다.

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

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

Windows Server 2012 R2 이상을 사용하면 관리 액세스 지점 없이 장애 조치(failover) 클러스터를 만들 수 있습니다. 관리 액세스 포인트가 없는 Windows 장애 조치(failover) 클러스터의 특징은 다음과 같습니다.

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

Windows Server 2012 R2 이상에서 Exchange에서 실행되는 Exchange 2013 SP1 이상을 사용하면 클러스터 관리 액세스 지점 없이 DAG를 만들 수 있습니다. 자세한 내용은 DAG 만들기 및 데이터베이스 가용성 그룹 만들기를 참조하세요.

다음을 통해 공유