전환 및 장애 조치
적용 대상: Exchange Server 2013 SP1
전환 및 장애 조치(failover)는 Microsoft Exchange Server 2013에서 두 가지 형태의 중단입니다.
전환은 cmdlet 또는 Exchange 2013의 관리되는 가용성 시스템에 의해 명시적으로 시작된 데이터베이스 또는 서버의 예약된 중단입니다. 전환은 일반적으로 유지 관리 작업 수행을 준비하기 위해 수행됩니다. 전환에는 활성 사서함 데이터베이스 복사본을 DAG(데이터베이스 가용성 그룹)의 다른 서버로 이동하는 작업이 포함됩니다. 전환 중에 정상 대상을 찾을 수 없는 경우 관리자가 오류를 수신하고 사서함 데이터베이스가 유지되거나 탑재됩니다.
장애 조치(failover)는 서비스나 데이터 또는 이 두 가지 모두 사용할 수 없게 되는 예기치 않은 이벤트를 말합니다. 장애 조치(failover)는 시스템이 수동 사서함 데이터베이스 복사본을 활성화한 다음 해당 복사본을 활성 사서함 데이터베이스 복사본으로 만들어 오류로부터 자동으로 복구하는 작업입니다. 장애 조치(failover) 중에 정상 대상을 찾을 수 없는 경우 사서함 데이터베이스가 분리됩니다.
Exchange 2013은 전환 및 장애 조치(failover)를 모두 처리하도록 설계되었습니다.
고가용성 및 사이트 복원력과 관련된 관리 작업을 찾고 있나요? 고가용성 및 사이트 복원력 관리를 참조하세요.
전환
Exchange 2013에는 세 가지 유형의 전환이 있습니다.
- 데이터베이스 전환
- 서버 전환
- 데이터 센터 전환
데이터베이스 전환
데이터베이스 전환은 개별 활성 데이터베이스가 다른 데이터베이스 복사본(수동 복사본)으로 전환되는 프로세스이며, 해당 데이터베이스 복사본은 새 활성 데이터베이스 복사본이 됩니다. 데이터베이스 전환은 데이터 센터 내부와 전체에서 발생할 수 있습니다. 데이터베이스 전환은 EAC(Exchange 관리 센터) 또는 셸을 사용하여 수행할 수 있습니다. 사용되는 인터페이스에 관계없이 전환 프로세스는 다음과 같습니다.
관리자가 데이터베이스 전환을 시작하여 현재 활성 사서함 데이터베이스 복사본을 다른 서버로 이동합니다.
작업에 사용되는 클라이언트가 DAG 구성원의 Microsoft Exchange 복제 서비스에 대한 RPC 호출을 수행합니다.
DAG 구성원에 PAM(Primary Active Manager) 역할이 없는 경우 DAG 구성원은 PAM 역할을 보유하는 서버에서 해당 작업을 참조하도록 합니다.
작업은 PAM 역할을 보유하는 서버에서 Microsoft Exchange 복제 서비스에 대한 RPC 호출을 수행합니다.
PAM이 DAG의 클러스터 데이터베이스에 저장된 데이터베이스 위치 정보를 읽고 업데이트합니다.
PAM이 수동 모드가 새 활성 사서함 데이터베이스 복사본으로 활성화된 DAG 구성원의 Microsoft Exchange 복제 서비스에 연결합니다.
대상 서버에 있는 Microsoft Exchange 복제 서비스가 다른 모든 DAG 구성원의 Microsoft Exchange 복제 서비스를 쿼리하여 데이터베이스 복사본에 대해 가장 적합한 로그 원본을 결정합니다.
현재 서버에서 데이터베이스가 분리되며 대상 서버의 Microsoft Exchange 복제 서비스를 통해 남은 로그가 대상 서버로 복사됩니다.
대상 서버의 Microsoft Exchange 복제 서비스가 데이터베이스 탑재를 요청합니다.
대상 서버의 Microsoft Exchange 정보 저장소가 로그 파일을 재생하고 데이터베이스를 탑재합니다.
오류 코드가 대상 서버의 Microsoft Exchange 복제 서비스로 반환됩니다.
PAM이 DAG의 클러스터 데이터베이스에 데이터베이스 복사본 상태 정보를 업데이트합니다.
오류 코드가 대상 서버의 Microsoft Exchange 복제 서비스에 의해 PAM의 Microsoft Exchange 복제 서비스로 반환됩니다.
PAM의 Microsoft Exchange 복제 서비스가 작업을 호출한 관리 인터페이스로 오류를 반환합니다.
원격 PowerShell이 작업 결과를 호출 중인 관리 인터페이스로 반환합니다.
데이터베이스 전환을 수행하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본 활성화를 참조하십시오.
서버 전환
서버 전환은 DAG 구성원에 있는 모든 활성 데이터베이스를 하나 이상의 다른 DAG 구성원에서 활성화하는 프로세스입니다. 데이터베이스 전환과 마찬가지로 서버 전환은 데이터 센터 내부와 전체에서 발생할 수 있으며 EAC와 셸을 모두 사용하여 시작할 수 있습니다. 사용되는 인터페이스에 관계없이 서버 전환 프로세스는 다음과 같습니다.
관리자가 서버 전환을 시작하여 현재 활성 사서함 데이터베이스 복사본을 하나 이상의 다른 서버로 이동합니다.
현재 서버의 활성 데이터베이스 각각에 대해 이 항목 이전에 설명한 데이터베이스 전환 단계(2-4단계)와 동일한 작업이 수행됩니다.
PAM이 DAG의 클러스터 데이터베이스에 저장된 데이터베이스 위치 정보를 읽고 업데이트합니다.
PAM이 수동 복사본이 활성화된 각 DAG 구성원의 Microsoft Exchange 복제 서비스에 연결합니다.
대상 서버에 있는 Microsoft Exchange 복제 서비스가 다른 모든 DAG 구성원의 Microsoft Exchange 복제 서비스를 쿼리하여 데이터베이스 복사본에 대해 가장 적합한 로그 원본을 결정합니다.
현재 서버에서 데이터베이스가 분리되며 각 대상 서버의 Microsoft Exchange 복제 서비스를 통해 남은 로그가 대상 서버로 복사됩니다.
각 대상 서버의 Microsoft Exchange 복제 서비스가 데이터베이스 탑재를 요청합니다.
각 대상 서버의 Microsoft Exchange 정보 저장소가 로그 파일을 재생하고 데이터베이스를 탑재합니다.
오류 코드가 대상 서버의 Microsoft Exchange 복제 서비스로 반환됩니다.
PAM이 DAG의 클러스터 데이터베이스에 데이터베이스 복사본 상태 정보를 업데이트합니다.
오류 코드가 대상 서버의 Microsoft Exchange 복제 서비스에 의해 PAM의 Microsoft Exchange 복제 서비스로 반환됩니다.
PAM의 Microsoft Exchange 복제 서비스가 작업을 호출한 관리 인터페이스로 오류를 반환합니다.
원격 PowerShell이 작업 결과를 호출 중인 관리 인터페이스로 반환합니다.
서버 전환을 수행하는 방법에 대한 자세한 단계는 서버 전환 수행을 참조하십시오.
데이터 센터 전환
사이트 복구 구성에서 사이트 수준 장애에 대해 진행되는 자동 복구는 DAG 내에서 발생하여 메시징 시스템이 작동 상태를 유지하도록 합니다. 이 구성에서는 DAG 구성원을 2개의 위치에 배포하고 DAG 미러링 모니터 서버를 세 번째 위치에 배포해야 하므로 적어도 3개의 위치가 필요합니다.
3개의 위치가 없거나 3개의 위치가 있지만 데이터 센터 수준 복구 작업을 제어하려는 경우에도 사이트 수준 오류가 발생하는 경우 수동 복구를 위해 DAG를 구성할 수 있습니다. 이러한 경우 데이터 센터 전환이라는 프로세스를 수행합니다. 다른 재해 복구 시나리오의 경우와 마찬가지로, 데이터 센터 전환을 사전에 계획하고 준비해 두면 복구 프로세스를 단순화하고 중지 기간을 단축할 수 있습니다.
서버 역할 통합을 포함하여 Exchange 2013의 다양한 아키텍처 변경으로 인해 Exchange 2013에서 데이터 센터 전환을 수행하는 것이 Exchange 2010보다 쉽습니다. 데이터 센터 전환 수행에 대한 자세한 단계는 데이터 센터 전환를 참조하세요.
장애 조치(failover)
장애 조치(failover)는 데이터베이스, 서버 또는 데이터 센터 수준에서 발생할 수 있는 자동 활성화 프로세스입니다. 개별 데이터베이스(예: 격리된 저장소 손실) 또는 전체 서버(예: 마더보드 오류 또는 전력 손실) 또는 전체 사이트(예: 사이트의 모든 DAG 구성원 손실)에 영향을 미치는 오류에 대한 응답으로 발생합니다.
DAG 및 사서함 데이터베이스 복사본은 데이터 및 데이터에 대한 액세스 권한이 제공되는 서비스의 전체 중복 및 신속한 복구가 제공됩니다. 다음 표에서는 다양한 오류에 대한 예상 복구 작업을 나열합니다. 관리자가 복구를 시작해야 하는 오류도 있고 시스템에서 자동 처리되는 오류도 있습니다.
설명 | 자동 활성화 | 자동 복구 작업 | 복구 중 상태: 액티브 | 복구 중 상태: 패시브 | 복구 작업 | 설명 |
---|---|---|---|---|---|---|
ESE(Extensible Storage Engine) 데이터베이스 소프트 오류: 데이터베이스를 저장하는 드라이브가 일부 읽기에서 오류를 반환하고 있습니다(예: -1018 오류). | 가능한 짧은 중단 가능한 자동 장애 조치(failover) |
잘못된 페이지의 자동 패치 | 수동 전환, 자동 장애 조치(failover) 또는 온라인 복구 | 실패 | RAID 다시 작성, 데이터베이스 및 데이터베이스 복사본 복구, 복원 및 복구 실행 후 페이지 패치 또는 복사본에서 페이지 패치 | 다른 데이터베이스 소프트 오류 코드가 있을 수 있습니다. NTFS 파일 시스템 블록 오류는 포함되지 않습니다. 장애 조치(failover) 또는 전환이 수행되면 호스트 서버가 업데이트됩니다. |
ESE "semi-soft" 데이터베이스 오류: 데이터베이스를 저장하는 드라이브가 일부 쓰기에서 오류를 반환하고 있습니다. | 자동 장애 조치(failover) 중 짧은 중단 | 가능한 드라이브 교체 후 자동 볼륨/디스크 다시 작성 | 복구할 수 없는 경우 분리됩니다. | 실패 | RAID를 다시 작성하면 문제가 해결될 수 있습니다. 복사 및 복구, 복원 및 복구 실행 또는 가능한 교체 후 볼륨/디스크 다시 작성 |
ESE semi-soft 쓰기 오류는 일부 쓰기에 성공했음을 의미합니다. NTFS 블록 오류는 포함되지 않습니다. |
ESE "semi-soft" 로그 오류: 로그 데이터를 저장하는 드라이브가 일부 읽기 또는 쓰기에서 복구되지 않는 오류를 반환하고 있습니다. | 자동 장애 조치(failover) 중 짧은 중단 | 가능한 드라이브 교체 후 자동 볼륨/디스크 다시 작성 | 복구할 수 없는 경우 분리됩니다. | 실패 | RAID를 다시 작성하면 문제가 해결될 수 있습니다. 복사 및 복구, 복원 및 복구 실행 또는 가능한 교체 후 볼륨/디스크 다시 작성 |
ESE semi-soft 읽기/쓰기 오류는 일부 읽기/쓰기에 성공했음을 의미합니다. 데이터베이스가 실패하면 로그 데이터 복구 프로세스가 시작하기 전에 자동화된 복구가 발생합니다. |
ESE 소프트웨어 오류 또는 리소스 소모: ESE가 인스턴스를 종료하는 경우 오류가 발생합니다(예: 이벤트 ID 1022, 검사점 깊이가 너무 깊음). | 자동 장애 조치(failover) 중 짧은 중단 | 없음 | 복구할 수 없는 경우 분리됩니다. | 실패 | 기본 리소스 문제를 해결합니다. | 이 오류는 다른 경우 표시되는 오류일 수 있습니다. |
NTFS 차단 오류: 데이터베이스 또는 로그를 저장하는 드라이브에 NTFS 제어 구조에 대한 읽기 또는 쓰기 오류가 발생합니다. | 자동 장애 조치(failover) 중 짧은 중단 | 가능한 드라이브 교체 후 볼륨을 다시 빌드합니다. | 복구할 수 없는 경우 분리됩니다. | 실패 | RAID를 다시 작성하면 문제가 해결될 수 있습니다. NTFS 유틸리티에서 NTFS 문제를 해결할 수 있습니다. Exchange 복구가 필요할 수 있습니다. | 이 이벤트는 RAID가 사용되지 않을 때 발생할 가능성이 높습니다. 이 이벤트가 활성 로그 볼륨에 영향을 주면 일부 최근 로그 파일이 손실됩니다. NTFS 또는 기본 소프트웨어나 하드웨어 스택에 의해 자동으로 수정된 오류는 포함되지 않습니다. |
데이터베이스 또는 로그 드라이브 오류: 데이터베이스 또는 로그를 저장하는 드라이브가 실패하여 액세스할 수 없습니다. | 자동 장애 조치(failover) 중 짧은 중단 | 드라이브 다시 포맷 또는 교체 후 전체 볼륨 다시 작성 | 복구할 수 없는 경우 분리됩니다. | 실패 | 드라이브 교체 후 가능한 RAID 다시 작성 드라이브 교체 후 전체 볼륨 다시 작성 볼륨 다시 작성 완료 |
해당 없음 |
데이터베이스 또는 로그 볼륨 오류: NTFS 또는 하위 수준 볼륨 문제로 인해 볼륨이 실패합니다. | 자동 장애 조치(failover) 중 짧은 중단 | 드라이브 다시 포맷 또는 교체 | 복구할 수 없는 경우 분리됩니다. | 실패 | 드라이브 교체 후 가능한 RAID 다시 작성 드라이브 교체 후 전체 볼륨 다시 작성 볼륨 다시 작성 완료 |
해당 없음. |
데이터베이스 또는 로그 볼륨의 공간 부족: 데이터베이스 또는 로그 파일이 포함된 NTFS 파일 시스템 공간이 부족합니다. | 다른 복사가 비슷한 상태에 있지 않으면 자동 장애 조치(failover) | 없음 | 분리. | 실패 | 전체 백업 또는 증분 백업 실행, 수동으로 로그 삭제, 데이터베이스 복사본 다시 시작 또는 실패한 데이터베이스 복사본 복구 | 해당 없음. |
관리자가 잘못된 데이터베이스를 분리합니다. | 자동 장애 조치(failover)가 관리자에 의해 차단되면 짧은 중단이 됩니다. 자동 장애 조치(failover)가 금지되면 데이터베이스를 탑재할 때까지 중단됩니다. |
없음 | 분리. | 해당 없음 | 관리자가 오류를 수정합니다. | 해당 없음. |
관리자가 잘못된 데이터베이스 복사본을 일시 중단합니다. | 구성 및 영향을 받는 복사본에 따라 자동 복구가 금지될 수 있습니다. | 없음 | 해당 없음. | 일시 중단됨 | 관리자가 오류를 수정합니다. | 해당 없음. |
관리자가 저장소, NTFS 또는 볼륨 유지 관리를 위해 데이터베이스를 분리합니다. | 자동 장애 조치(failover)가 관리자에 의해 차단되면 짧은 중단이 됩니다. 자동 장애 조치(failover)가 관리자가 작업을 완료할 때까지 중단됩니다. |
없음 | 분리. | 해당 없음 | 관리자가 작업을 완료합니다. | 해당 없음. |
관리자가 저장소, NTFS 또는 볼륨 유지 관리를 위해 데이터베이스 복사를 일시 중단합니다. | 구성 및 영향을 받는 복사본에 따라 자동 복구가 금지될 수 있습니다. | 없음 | 해당 없음. | 일시 중단됨 | 관리자가 작업을 완료합니다. | 해당 없음. |
관리자가 오프라인 데이터베이스 유지 관리를 위해 데이터베이스를 분리합니다. | 복구할 때까지 중단됨 | 없음 | 분리. | 일시 중단됨 | 관리자가 작업을 완료합니다. | 활성 및 수동 데이터베이스 복사본이 갈라집니다. 관리자가 복사를 일시 중단해야 합니다. |
SAN(저장 영역 네트워크), 디스크 또는 저장소 컨트롤러 오류입니다. | 자동 장애 조치(failover) 중 짧은 중단 | 없음 | 분리. | 모두 | 하드웨어 복구 | 수동 데이터베이스 복사본이 시스템에 오류가 발생한 당시의 상태가 됩니다. |
서버 하드웨어 유지 관리입니다. | 자동 장애 조치(failover) 중 짧은 중단(관리자가 차단하지 않는 경우) | 없음 | 분리. | 모두 | 작업 완료 | 수동 데이터베이스 복사본이 시스템이 종료된 당시의 상태가 됩니다. |
서버 소프트웨어 유지 관리입니다. | 자동 장애 조치(failover) 중 짧은 중단(관리자가 차단하지 않는 경우) | 없음 | 분리. | 모두 | 작업 완료 | 수동 데이터베이스 복사본이 시스템이 종료된 당시의 상태가 됩니다. |
관리자가 Microsoft Exchange Information Store 서비스를 중지하거나 일시 중지합니다. | 자동 장애 조치(failover) 중 짧은 중단 | 없음 | 분리. | 모두 | Microsoft Exchange Information Store 서비스를 다시 시작합니다. | 해당 없음 |
Microsoft Exchange Information Store 서비스가 실패합니다. 운영 체제가 계속 실행 중입니다. | 자동 장애 조치(failover) 중 짧은 중단 | Service Control Manager가 Microsoft Exchange Information Store 서비스를 다시 시작합니다. | 분리. | 모두 | Microsoft Exchange Information Store 서비스를 수동으로 또는 자동으로 다시 시작합니다. | 수동 데이터베이스 복사본은 Microsoft Exchange Information Store 서비스가 실패했을 때 존재하던 상태가 됩니다. |
부분 Microsoft Exchange Information Store 서비스 오류; Exchange 저장소의 일부에서 작동이 중지되지만 실패한 것으로 식별되지는 않습니다. | 자동 장애 조치(failover) 중 가능한 짧은 중단 | 없음 | 탑재되고 부분적으로 작동함 | 모두(부분만 작동 가능) | 서버, 운영 체제 또는 Microsoft Exchange Information Store 서비스를 다시 시작합니다. | 해당 없음 |
서버 오류: 다음 이유 중 하나로 인해 서버에 오류가 발생했습니다.
|
자동 장애 조치(failover) 중 짧은 중단 | 컴퓨터 다시 시작 | 분리. | 모두 | 전원 복원, 운영 체제 설정 변경, 하드웨어 설정 변경, 하드웨어 교체, 운영 체제 다시 시작, 운영 체제 수리, 하드웨어 수리 또는 통신 문제 복구 | 해당 없음. |
DAG에 쿼럼 오류가 발생했습니다. | 복구할 때까지 중단됨 | 없음 | 분리. | 모두 | 오류가 발생한 쿼럼 복구, 새 쿼럼 할당 또는 쿼럼 오류를 일으키는 네트워크 복원 | 수동 데이터베이스 복사본이 시스템에 오류가 발생한 당시의 상태가 됩니다. |
MAPI 네트워크 통신 오류: MAPI 네트워크에서 더 이상 서버를 사용할 수 없습니다. | 자동 장애 조치(failover) 중 짧은 중단, 무손실이어야 함 | 없음 통신은 계속 시도됩니다. | 분리. | 모두 | 하드웨어 또는 소프트웨어 문제를 해결하여 통신 문제를 해결합니다. | 해당 없음 |
복제 네트워크 통신 실패: 서버는 실패한 복제 네트워크를 통해 하트비트, 로그 복사본 또는 시드를 받을 수 없습니다. | 작업이 다른 네트워크로 전환되는 동안 가능한 짧은 복사 또는 시드 중단 | 없음 통신은 계속 시도됩니다. | 없음 | 모두 | 하드웨어 또는 소프트웨어 문제를 해결하여 통신 문제를 해결합니다. | 복구가 오류로 인해 영향을 받습니다. |
여러 네트워크 통신 실패: 서버는 여러 네트워크를 통해 하트비트, 로그 복사본 또는 시드를 받을 수 없습니다. | 자동 장애 조치(failover) 중 짧은 중단, 무손실이어야 함 | 없음 통신은 계속 시도됩니다. | 분리. | 모두 | 하드웨어 또는 소프트웨어 문제를 해결하여 통신 문제를 해결합니다. | 최소 하나의 네트워크가 여전히 작동합니다. |
하나 이상의 네트워크의 부분 오류: 네트워크의 오류 비율이 높습니다. | 검색된 오류 없음, 작업 없음 | 없음 | 탑재되었지만 가능한 성능 문제 있음 | 모두 | 하드웨어 또는 소프트웨어 문제를 해결하여 통신 문제를 해결합니다. | 네트워크의 오류 비율이 정상보다 높습니다. |
검색되지 않은 운영 체제 중단: 운영 체제는 응답을 중지하지만 모니터링 또는 클러스터링으로 검색되지 않습니다. | 없음 | 없음 | 모든. | 모두 | 응답하지 않는 리소스를 다시 시작하거나 종료합니다. | 중단이 검색되지 않아 수행한 작업이 없습니다. 일부 기능이 작동할 수 있습니다. |
운영 체제 드라이브에 오류가 발생했습니다. | 자동 장애 조치(failover) 중 짧은 중단 | 없음 | 분리. | 모두 | 드라이브 교체 및 서버 다시 작성 또는 RAID를 사용하여 볼륨 다시 작성 | 해당 없음. |
운영 체제 드라이브 공간이 부족합니다. | 자동 장애 조치(failover) 중 짧은 중단 | 없음 | 분리. | 모두 | 수동으로 볼륨 공간 확보 | 해당 없음 |
Exchange 이진 파일이 포함된 드라이브에는 볼륨 또는 드라이브 오류가 발생합니다. | 자동 장애 조치(failover) 중 짧은 중단 | 없음 | 분리. | 모두 | 드라이브 교체 및 응용 프로그램 다시 설치 또는 RAID를 사용하여 볼륨 다시 작성 | 해당 없음 |
Exchange 이진 파일을 포함하는 드라이브의 공간이 부족합니다. | 자동 장애 조치(failover) 중 짧은 중단 | 없음 | 분리. | 모두 | 수동으로 볼륨 공간 확보 | 해당 없음. |
잘못된 새 로그 검색됨: 로그 시퀀스가 기존 파일에 의해 중단되었습니다. | 자동 장애 조치(failover) 중 짧은 중단. 다른 복사본에 동일한 문제가 없다고 가정 | 없음 | 분리. | 실패 | 소스 확인 후 손상된 로그 제거 | 손상된 로그는 복제하면 안 됩니다. |
연속된 복제에서 잘못된 로그가 검색되었습니다. 복사 또는 재생 중 부적절한 로그가 검색됩니다. | 해당 없음. | 로그 삭제 | 해당 없음. | 실패 | 잘못된 로그 무시, 영향을 받는 로그 스트림 이동 | 해당 없음. |
데이터베이스 장애 조치(failover)
활성 상태인 데이터베이스 복사본이 더 이상 활성 상태를 유지할 수 없는 경우 데이터베이스 장애 조치(failover)가 발생합니다. 다음 항목은 데이터베이스 장애 조치(failover)의 일부입니다.
Microsoft Exchange 정보 저장소 서비스에 의해 데이터베이스 오류가 검색됩니다.
Microsoft Exchange 정보 저장소 서비스가 오류 이벤트를 Crimson 채널 이벤트 로그에 기록합니다.
오류가 있는 데이터베이스에 포함된 서버의 활성 관리자가 오류 이벤트를 검색합니다.
활성 관리자가 데이터베이스의 복사본을 보유한 다른 서버의 데이터베이스 복사 상태를 요청합니다.
다른 서버가 요청된 데이터베이스 복사본 상태를 요청한 활성 관리자에게 반환합니다.
최상의 복사본 선택 알고리즘을 사용하여 PAM이 DAG의 다른 서버로 활성 데이터베이스 이동을 시작합니다.
PAM이 선택한 서버를 참조하도록 클러스터 데이터베이스에 데이터베이스 탑재 위치를 업데이트합니다.
PAM이 데이터베이스 마스터가 되도록 선택한 서버의 활성 관리자에게 요청을 보냅니다.
선택한 서버의 활성 관리자는 Microsoft Exchange 복제 서비스가 이전 서버의 마지막 로그를 복사하고 데이터베이스에 대해 탑재 가능한 플래그를 설정하도록 요청합니다.
Microsoft Exchange 복제 서비스가 이전에 데이터베이스의 활성 복사본을 소유했던 서버의 로그를 복사합니다.
활성 관리자가 클러스터 데이터베이스에서 최대 로그 생성 번호를 읽습니다.
Microsoft Exchange 정보 저장소 서비스가 새 활성 데이터베이스 복사본을 탑재합니다.
서버 장애 조치(failover)
서버 장애 조치(failover)는 DAG 구성원이 MAPI 네트워크에 더 이상 서비스를 제공할 수 없거나 DAG 구성원의 클러스터 서비스가 나머지 DAG 구성원에 더 이상 연결할 수 없는 경우 발생합니다. 다음 항목은 서버 장애 조치(failover)의 일부입니다.
PAM의 클러스터 서비스가 다음 상황 중 하나에 대한 알림을 PAM에 보냅니다.
- 노드 다운: 서버에 연결할 수 있지만 DAG 작업에 참여할 수 없습니다.
- MAPI 네트워크 다운: MAPI 네트워크를 통해 서버에 연결할 수 없으므로 DAG 작업에 참여할 수 없습니다.
서버가 연결 가능한 경우 PAM은 영향 받는 서버의 활성 관리자에 연결하여 모든 데이터베이스를 즉시 분리하라고 요청합니다.
영향을 받는 각 데이터베이스 복사본의 경우
- PAM은 DAG의 모든 서버에게 데이터베이스 복사 상태를 요청합니다.
- PAM은 연결 가능하고 활성 상태인 모든 DAG 구성원으로부터 응답을 받습니다.
- PAM이 응답자 각각의 최신 로그 생성 번호를 쿼리하여 응답하는 모든 서버에서 가장 적합한 로그 원본을 결정합니다.
- 각 서버가 로그 생성 번호로 응답합니다.
PAM이 클러스터 데이터베이스에서 현재 검색 인덱스 카탈로그 상태를 검색합니다.
각 데이터베이스 복사본의 로그 생성 번호와 카탈로그 상태를 기반으로 PAM이 활성화하기 가장 적합한 복사본을 선택합니다.
PAM이 클러스터 데이터베이스에 데이터베이스의 탑재된 위치를 업데이트합니다.
PAM이 하나 이상의 다른 서버의 활성 관리자와 통신함으로써 데이터베이스 장애 조치(failover)를 시작합니다.
선택한 서버의 활성 관리자는 Microsoft Exchange 복제 서비스가 이전 서버의 마지막 로그를 복사하고 탑재 가능한 플래그를 설정하도록 요청합니다.
데이터베이스가 탑재 가능한 경우 서버의 활성 관리자가 데이터베이스를 탑재합니다.
활성 관리자의 최상의 복사본 선택 프로세스에 대한 자세한 내용은 Active Manager를 참조하십시오.
데이터 센터 장애 조치(failover)
Exchange 2013에서는 Exchange 2010 사이트 복구 구성의 문제를 해결하도록 다양한 부분이 변경되었습니다. 네임스페이스 단순화, 서버 역할 통합, 클라이언트 액세스 서버 및 DAG 복구의 분리(Exchange 2013에서는 네임스페이스를 DAG와 함께 이동할 필요가 없음), 부하 분산 변경 등을 통해 Exchange 2013은 단일 전역 네임스페이스 사용과 같은 새로운 사이트 복구 옵션이 제공됩니다. 또한 메시징 서비스 구성 요소를 배포할 위치가 두 개 이상 있는 경우 Exchange 2013에서는 Exchange 2010에서 수동 개입이 필요한 오류에 대응하여 자동 장애 조치(failover)를 위해 메시징 서비스를 구성할 수도 있습니다.
Exchange 2013에서는 사이트 복원력이 운영적으로 간소화되었습니다. Exchange는 여러 IP 주소, 부하 분산을 통해 네임스페이스에 기본 제공되는 내결함성을 적용합니다(필요한 경우 서버를 서비스 내/외부로 가져오는 기능). Exchange 2013에서 수행한 가장 중요한 변경 사항 중 하나는 이름 확인 요청에 대한 응답으로 DNS 서버에서 반환된 여러 IP 주소를 캐시하는 클라이언트의 기능을 사용하는 것이었습니다. 클라이언트가 여러 IP 주소를 캐시할 수 있다고 가정하면(거의 모든 HTTP 클라이언트가 수행하는, Exchange 2013의 거의 모든 클라이언트 액세스 프로토콜은 HTTP 기반이므로(Outlook, Outlook Anywhere, EAS, EWS, OWA, EAC, RPS 등), 지원되는 모든 HTTP 클라이언트는 여러 IP 주소를 사용할 수 있으므로 클라이언트 쪽에서 장애 조치(failover)를 제공합니다. 이름 확인 중에 클라이언트에 여러 IP 주소를 전달하도록 DNS를 구성할 수 있습니다. 클라이언트는 mail.contoso.com 요청하고 IP 주소 2개 또는 IP 주소 4개를 다시 가져옵니다. 그러나 클라이언트가 다시 가져오는 많은 IP 주소는 클라이언트에서 안정적으로 사용됩니다. 이 최적의 사용률을 사용하면 IP 주소 중 하나가 실패할 경우 클라이언트에 연결을 시도할 하나 이상의 다른 주소가 있기 때문에 클라이언트가 훨씬 더 잘 해제됩니다. 클라이언트가 하나를 시도하고 실패하면 약 20초 동안 기다린 다음 목록에서 다음을 시도합니다. 따라서 기본 CAS 배열에 대한 연결이 끊어지고 두 번째 CAS 배열에 대해 두 번째로 게시된 IP 주소가 있는 경우 클라이언트에 대한 복구가 자동으로 수행됩니다(약 21초).
최신 HTTP 클라이언트(10년 이하의 운영 체제 및 웹 브라우저)는 이 중복성을 자동으로 사용합니다. HTTP 스택은 FQDN에 대해 여러 IP 주소를 허용할 수 있으며, 첫 번째 IP가 하드 실패하는 경우(예: 연결할 수 없음) 목록에서 다음 IP를 시도합니다. 일시적 오류(세션이 설정된 후 연결이 끊어지는 경우, 예를 들어 디바이스가 패킷을 삭제하고 서비스를 중단해야 하는 서비스의 일시적인 오류로 인해 연결이 끊어지는 경우) 사용자는 브라우저를 새로 고쳐야 할 수 있습니다.
적절한 구성을 사용하면 클라이언트 수준에서 장애 조치(failover)가 발생할 수 있으며 클라이언트는 클라이언트 액세스 서버를 운영하는 두 번째 데이터 센터로 자동으로 리디렉션되고, 클라이언트 액세스 서버를 운영하는 클라이언트 액세스 서버는 중단의 영향을 받지 않는 사용자의 사서함 서버로 다시 통신을 프록시합니다(전환하지 않기 때문에). 서비스를 복구하는 대신 서비스가 자체 복구되며 핵심 문제(예: 실패한 부하 분산 장치 교체)를 해결하는 데 집중할 수 있습니다.
데이터 센터 간에 네임스페이스를 장애 조치(failover)할 수 있으므로 데이터 센터 장애 조치(failover)를 달성하는 데 필요한 것은 데이터 센터에서 사서함 역할의 장애 조치(failover)를 위한 메커니즘입니다. DAG에 대한 자동 장애 조치(failover)를 수행하려면 DAG가 두 데이터 센터 간에 균등하게 분할되는 솔루션을 설계한 다음 DAG 멤버를 포함하는 데이터 센터 간의 네트워크 상태에 관계없이 두 데이터 센터의 DAG 멤버가 중재할 수 있도록 감시 서버를 세 번째 위치에 배치합니다. 여기서 요점은 DAG 구성원이 포함된 위치에 영향을 주는 네트워크 오류로부터 세 번째 위치가 격리되는 것입니다.
데이터 센터가 두 개뿐이고 자동 장애 조치(failover)를 구성하려는 경우 Microsoft Azure를 세 번째 위치로 활용할 수 있습니다. Azure 가상 네트워크를 만들고 다중 지점 VPN을 사용하여 두 데이터 센터에 연결해야 합니다. 그러면 감시 서버를 Microsoft Azure 가상 머신에 배치할 수 있습니다. 자세한 내용은 DaG 미러링 모니터 서버로 Microsoft Azure VM 사용을 참조하세요.