Active Manager 이해
적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3
마지막으로 수정된 항목: 2015-03-09
Microsoft Exchange Server 2010에는 Active Manager라는 새로운 구성 요소가 포함됩니다. 이 구성 요소는 이전 버전의 Exchange에서 클러스터 서비스와의 통합을 통해 제공된 리소스 모델 및 장애 조치(failover) 관리 기능을 대체하는 기능을 제공합니다. Exchange는 고가용성을 위해 더 이상 클러스터 리소스 모델을 사용하지 않습니다. 클러스터된 사서함 서버라는 구조를 포함하여 exres.dll에서 제공했던 모든 Exchange 클러스터 리소스는 더 이상 존재하지 않습니다. Windows 장애 조치(failover) 클러스터는 Exchange에서 사용되지만 Exchange에 대한 클러스터 그룹은 없으며 클러스터에 저장소 리소스도 없습니다. 따라서 클러스터 관리 도구를 사용하여 클러스터를 검사하면 중요 클러스터 리소스(IP 주소와 네트워크 이름, 그리고 필요한 경우 쿼럼 리소스)만 볼 수 있습니다. 클러스터 노드 및 네트워크도 존재하지만 이는 클러스터나 클러스터 도구가 아닌 Exchange에 의해 관리됩니다.
Active Manager는 모든 사서함 서버에서 역할로 실행합니다. 고가용성으로 구성되지 않은 사서함 서버에는 다음과 같은 단일 Active Manager 역할이 있습니다. 독립 실행형 Active Manager. DAG(데이터베이스 가용성 그룹)의 구성원인 서버에 다음과 같은 두 가지의 Active Manager 역할이 있습니다. PAM(Primary Active Manager)과 SAM(Standby Active Manager), 두 가지입니다. PAM은 활성 및 수동 복사본을 결정하는 DAG의 Active Manager입니다. PAM은 토폴로지 변경 알림을 가져오고 서버 오류에 대처하는 역할을 담당합니다. PAM 역할을 맡은 DAG 구성원은 항상 현재 클러스터 쿼럼 리소스(기본 클러스터 그룹)를 소유한 구성원입니다. 클러스터 쿼럼 리소스를 소유한 서버에 오류가 발생하면 PAM 역할은 클러스터 쿼럼 리소스 소유권을 취하는 남은 서버로 자동으로 이동됩니다. 또한 유지 관리 또는 업그레이드를 위해 클러스터 쿼럼 리소스를 호스팅하는 서버를 오프라인으로 전환해야 하는 경우 먼저 PAM을 DAG의 다른 서버로 옮겨야 합니다. PAM은 데이터베이스 복사본 간의 모든 활성 지정 이동을 제어합니다(항상 하나의 복사본만 활성 상태일 수 있으며, 이 복사본은 탑재 또는 분리될 수 있음). PAM은 로컬 시스템에서 SAM 역할의 기능도 수행합니다(로컬 데이터베이스 및 로컬 정보 저장소 오류 검색).
SAM은 사서함 데이터베이스의 활성 복사본을 Active Manager 클라이언트 구성 요소를 실행하는 다른 Exchange 구성 요소에 호스팅하는 서버에 대한 정보를 제공합니다(예: RPC 클라이언트 액세스 서비스 또는 허브 전송 서버). SAM은 로컬 정보 저장소 및 로컬 데이터베이스의 오류를 검색합니다. SAM은 오류에 대처하기 위해 PAM에 장애 조치(failover)를 시작하도록 요청합니다(데이터베이스가 복제되는 경우). SAM은 장애 조치(failover)의 대상을 결정하지 않고, PAM의 데이터베이스 위치 상태도 업데이트하지 않습니다. SAM은 수신하는 활성 데이터베이스 복사본에 대한 쿼리에 응답하기 위해 활성 데이터베이스 복사본 위치 상태에 액세스합니다.
참고
Exchange 2010은 클러스터된 응용 프로그램이 아니며 대신 클러스터, 그룹, 클러스터 네트워크(하트비트), 노드 관리, 클러스터 레지스트리를 위해 clusapi.dll에 구현된 클러스터 라이브러리 기능과 몇 가지 제어 코드 기능을 사용합니다. 또한 Active Manager는 클러스터 데이터베이스에 현재 사서함 데이터베이스 정보를 저장합니다(예: 활성 및 수동 데이터, 탑재된 데이터) 이 정보는 클러스터 데이터베이스에 직접 저장되지만 다른 구성 요소에 의해 직접 액세스되지는 않습니다.
Exchange 2010에서 Microsoft Exchange Replication Service는 탑재된 모든 데이터베이스의 상태를 주기적으로 모니터링합니다. 또한 ESE(Extensible Storage Engine)에서 I/O 오류 또는 장애도 모니터링합니다. 오류가 발견되면 Active Manager에 이를 알립니다. 그러면 Active Manager는 탑재해야 할 데이터베이스 복사본과 이 데이터베이스를 탑재하기 위해 필요한 요소를 결정합니다. 또한 마지막으로 탑재된 데이터베이스 복사본을 바탕으로 사서함 데이터베이스의 활성 복사본을 추적하고, 클라이언트가 연결되는 클라이언트 액세스 서버의 RPC 클라이언트 액세스 구성 요소에 이 추적 결과를 제공합니다.
Active Manager 최적 복사본 선택
복제된 사서함 데이터베이스에 영향을 미치는 오류가 발생하면, Active Manager는 활성화에 가장 적합한 실패한 데이터베이스의 복사본을 선택하여 오류에서 복구를 위해 몇몇 단계를 수행합니다. 일반 프로세스는 다음 순서로 발생합니다.
Active Manager는 오류를 검색합니다.
PAM은 BCS(최상의 복사본 선택)라는 내부 알고리즘을 실행합니다.
ACLL(Attempt Copy Last Logs)이라는 프로세스가 발생하며, 장애 조치 전에 활성 데이터베이스 복사본을 호스트한 서버에서 누락된 로그 파일을 복사하려고 시도합니다.
ACLL 프로세스가 완료되면 PAM은 탑재 요청을 RPC(원격 프로시저 호출)를 통해 Microsoft Exchange 정보 저장소에 발행합니다. 이 시점에서는 다음 중 하나가 수행됩니다.
데이터베이스가 탑재되고 클라이언트가 사용할 수 있습니다. 또는
데이터베이스가 탑재되지 않고 PAM은 다음 최상의 복사본(사용 가능한 경우)에서 3단계와 4단계를 수행합니다.
가능한 최상의 복사본을 검색하면 PAM은 별도의 조건 집합을 최대 10개 사용하여 활성화할 최상의 복사본을 결정합니다. 가능한 최상의 복사본을 찾으면 ACLL이 실행됩니다. ACLL 프로세스가 완료된 후 이전 활성 복사본에서 모든 누락된 로그 파일이 복사되면 데이터베이스는 데이터 손실 없이 탑재됩니다. 이를 무손실 장애 조치라고 합니다. ACLL 프로세스가 실패하는 경우 AutoDatabaseMountDial에 대해 구성된 값이 참조됩니다. AutoDatabaseMountDial에 대한 자세한 내용은 Set-MailboxServer를 참조하십시오. 손실된 로그의 수가 AutoDatabaseMountDial에 대해 구성된 값 내에 있으면 데이터베이스가 탑재됩니다. 손실된 로그의 수가 AutoDatabaseMountDial에 대해 구성된 값을 벗어나면 누락된 로그 파일이 복구되거나 관리자가 명시적으로 데이터베이스를 탑재하고 더 큰 데이터 손실을 수락할 때까지 데이터베이스는 탑재되지 않습니다. 데이터베이스가 자동으로 탑재되지 않으면 PAM은 다음 최상의 복사본을 선택합니다(사용 가능한 경우). 처음 선택한 데이터베이스 복사본이 자동으로 탑재되지 않는 데는 최소 3가지 이상의 이유가 있습니다.
손실된 로그 파일의 수는 AutoDatabaseMountDial에 구성된 값보다 큽니다.
탑재 시도된 서버는 활성 데이터베이스의 소프트 최대값으로 구성되며 서버에서 활성 데이터베이스 복사본의 최대 수에 도달했습니다.
데이터베이스 복사본의 활성화가 일시 중단됩니다.
최상의 복사본 선택 프로세스
Active Manager는 활성화의 잠재적인 후보자인 데이터베이스 복사본의 목록을 만들어 최상의 복사본 선택 프로세스를 시작합니다. 도달할 수 없거나 관리를 위해 활성화가 차단된 데이터베이스 복사본(Set-MailboxServer cmdlet의 DatabaseCopyAutoActivationPolicy 속성을 사용하여)은 선택 프로세스 동안 무시되며 사용되지 않습니다. 목록의 순서는 Exchange 2010의 버전에 따라 다릅니다.
Exchange 2010 RTM(Release To Manufacturing) 버전에서 Active Manager는 복사 큐 길이를 기본 키로 사용하여 결과 목록을 정렬합니다. LastLogInspected(복사의 관점에서)를 기준으로 계산되어, 잠재적인 복사본의 목록이 LastLogInspected(가장 낮은 복사본 큐 길이를 가진 복사본이 됨)의 가장 높은 값으로 정렬됩니다. 그런 다음 Active Manager는 ActivationPreference의 값을 보조 키로 사용하여 두 번째로 목록을 정렬합니다. 가장 낮은 ActivationPreference 값을 가진 복사본이 목록에서는 우선 순위가 높습니다.
Exchange 2010 SP1(서비스 팩1)에서 무손실의 자동 데이터베이스 탑재 다이얼 값으로 서버가 구성된 점을 제외하고는 동작은 RTM 버전과 동일합니다. 무손실 설정이 사용되면 Active Manager는 ActivationPreference의 값을 기본 키로 사용하여 오름차순으로 결과 목록을 정렬합니다. 이 동작은 데이터베이스 불균형이 이동 작업(전환 또는 StartDagServerMaintenance.ps1을 실행하는 경우와 같은)을 통해 최소화되도록 설계되었습니다.
다음으로, Active Manager는 상태가 Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing 또는 SeedingSource인 사서함 데이터베이스 복사본을 목록에서 찾은 다음, 10개의 조건 순서 집합을 사용하여 목록에서 각 복사본의 활성화 가능성을 평가합니다. Active Manager는 활성화 후보자가 조건의 첫 번째 집합을 충족하는지 확인합니다.
상태가 Healthy이며 콘텐츠 인덱스가 있음
복사 큐 길이가 로그 파일 10개 미만임
재생 큐 길이가 로그 파일 50개 미만임
조건의 첫 번째 집합을 충족하는 데이터베이스 복사본이 없는 경우 Active Manager는 조건의 두 번째 집합을 충족하는 데이터베이스 복사본을 찾습니다.
상태가 Crawling이며 콘텐츠 인덱스가 있음
복사 큐 길이가 로그 파일 10개 미만임
재생 큐 길이가 로그 파일 50개 미만임
조건의 두 번째 집합을 충족하는 데이터베이스 복사본이 없는 경우 Active Manager는 조건의 세 번째 집합을 충족하는 데이터베이스 복사본을 찾습니다.
상태가 Healthy이며 콘텐츠 인덱스가 있음
재생 큐 길이가 로그 파일 50개 미만임
조건의 세 번째 집합을 충족하는 데이터베이스 복사본이 없는 경우 Active Manager는 조건의 네 번째 집합을 충족하는 데이터베이스 복사본을 찾습니다.
상태가 Crawling이며 콘텐츠 인덱스가 있음
재생 큐 길이가 로그 파일 50개 미만임
조건의 네 번째 집합을 충족하는 데이터베이스 복사본이 없는 경우 Active Manager는 조건의 다섯 번째 집합을 충족하는 데이터베이스 복사본을 찾습니다.
- 재생 큐 길이가 로그 파일 50개 미만임
조건의 다섯 번째 집합을 충족하는 데이터베이스 복사본이 없는 경우 Active Manager는 조건의 여섯 번째 집합을 충족하는 데이터베이스 복사본을 찾습니다.
상태가 Healthy이며 콘텐츠 인덱스가 있음
복사 큐 길이가 로그 파일 10개 미만임
여섯 번째 조건을 충족하는 데이터베이스 복사본이 없는 경우 Active Manager는 조건의 일곱 번째 집합을 충족하는 데이터베이스 복사본을 찾습니다.
상태가 Crawling이며 콘텐츠 인덱스가 있음
복사 큐 길이가 로그 파일 10개 미만입니다.
조건의 일곱 번째 집합을 충족하는 데이터베이스 복사본이 없는 경우 Active Manager는 조건의 여덟 번째 집합을 충족하는 데이터베이스 복사본을 찾습니다.
- 상태가 Healthy이며 콘텐츠 인덱스가 있음
조건의 여덟 번째 집합을 충족하는 데이터베이스 복사본이 없는 경우 Active Manager는 조건의 아홉 번째 집합을 충족하는 데이터베이스 복사본을 찾습니다.
- 상태가 Crawling이며 콘텐츠 인덱스가 있음
조건의 아홉 번째 집합을 충족하는 데이터베이스 복사본이 없는 경우 Active Manager는 상태가 Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing 또는 SeedingSource(조건의 열 번째 집합)인 아무 데이터베이스 복사본이나 활성화합니다. 조건의 열 번째 집합을 충족하는 데이터베이스 복사본을 찾을 수 없는 경우 데이터베이스 복사본을 자동으로 활성화할 수 없습니다.
하나 이상의 조건 집합을 충족하는 하나 이상의 복사본을 찾으면 ACLL 프로세스가 실행되어 로그 파일을 원래 원본에서 잠재적인 새 활성 복사본으로 복사합니다. ACLL 프로세스가 완료되면 PAM은 탑재 요청을 발행하여 데이터베이스가 탑재되고 클라이언트가 사용할 수 있거나 데이터베이스가 탑재되지 않고 PAM은 다음 최상의 복사본(사용 가능한 경우)을 검색합니다.
최상의 복사본 선택 예
다음 섹션에서는 Active Manager의 최상의 복사본 선택 및 활성화 프로세스에 대한 몇 가지 예를 설명합니다.
예 1: 기본 시나리오
이 예에서는 사서함 데이터베이스 DB1의 복사본이 4개 있습니다. DB1은 현재 Server1에서 활성화되어 있으며 하드웨어 오류가 발생할 수 있습니다. 다음 표는 Server2, Server3 및 Server4에서 DB1의 데이터베이스 복사본의 현재 상태를 보여 줍니다.
데이터베이스 복사본 | 활성화 기본 설정 | 복사 큐 길이 | 재생 큐 길이 | 콘텐츠 인덱스 상태 | 데이터베이스 상태 | 활성화 차단 |
---|---|---|---|---|---|---|
Server2\DB1 |
2 |
4 |
0 |
Healthy |
Healthy |
아니요 |
Server3\DB1 |
3 |
2 |
2 |
Healthy |
DisconnectedAndHealthy |
아니요 |
Server4\DB1 |
4 |
10 |
0 |
Crawling |
Healthy |
아니요 |
복사본 큐 길이를 기준으로 사용 가능한 복사본을 정렬하면(필요한 경우 활성화 기본 설정 사용) 다음 순서가 지정된 목록이 생성됩니다.
Server3\DB1
Server2\DB1
Server4\DB1
이 목록에서 다음 두 개의 데이터베이스 복사본만이 활성화를 위한 조건의 첫 번째 집합을 충족합니다.
데이터베이스 상태가 Disconnectedandhealthy이며, 복사본 큐 길이가 10 미만이고, 재생 큐 길이가 50 미만이며, 정상 콘텐츠 인덱스인 Server3의 복사본
데이터베이스 상태가 Healthy이며, 복사본 큐 길이가 10 미만이고, 재생 큐 길이가 50 미만이며, 정상 콘텐츠 인덱스인 Server2의 복사본
이 두 복사본 중에 Server3의 복사본이 가장 작은 복사본 큐 길이를 가지고 있습니다. Server3은 누락된 데이터의 양이 최소이므로 활성화할 복사본으로 선택됩니다.
Server3의 복사본이 활성화된 후 Server3의 Microsoft Exchange 복제 서비스가 ACLL 프로세스를 수행하여 이전 활성 서버(이 경우, Server1)에서 누락된 로그 파일을 복사하려고 시도합니다. ACLL 프로세스를 완료하면 PAM은 ACLL 프로세스의 결과를 알립니다. 모든 로그가 성공적으로 복사되면 데이터베이스가 활성 복사본으로 표시되며 무손실 데이터로 탑재됩니다. 하나 이상의 로그가 누락되면 AutoDatabaseMountDial 매개 변수의 값이 참조됩니다. 데이터 손실이 구성된 값 내에 있는 경우 데이터베이스가 활성 복사본으로 표시되며 데이터 손실로 탑재됩니다. 누락된 대부분의 데이터는 전송 쓰레기 수거통에서 복구됩니다.
Active Manager가 탑재 요청을 정보 저장소에 전송하고 탑재 작업이 실패한 경우, Active Manager는 다시 위의 정렬된 목록으로 돌아가 다음 최상의 복사본을 활성화합니다(이 경우, Server2).
예 2: 복사본 큐 길이가 같은 두 개의 복사본
이 예에서는 사서함 데이터베이스 DB2의 복사본이 4개 있습니다. DB2는 현재 Server1에서 활성화되어 있으며 하드웨어 오류가 발생할 수 있습니다. 다음 표는 Server2, Server3 및 Server4에서 DB2의 데이터베이스 복사본의 현재 상태를 보여 줍니다.
데이터베이스 복사본 | 활성화 기본 설정 | 복사 큐 길이 | 재생 큐 길이 | 콘텐츠 인덱스 상태 | 데이터베이스 상태 | 활성화 차단 |
---|---|---|---|---|---|---|
Server2\DB2 |
2 |
2 |
0 |
Healthy |
Healthy |
아니요 |
Server3\DB2 |
3 |
2 |
2 |
Healthy |
DisconnectedAndHealthy |
아니요 |
Server4\DB2 |
4 |
10 |
0 |
Crawling |
Healthy |
아니요 |
복사본 큐 길이를 기준으로 사용 가능한 복사본을 정렬하면(필요한 경우 활성화 기본 설정 사용) 다음 순서가 지정된 목록이 생성됩니다.
Server2\DB2
Server3\DB2
Server4\DB2
이 목록에서 다음 두 개의 데이터베이스 복사본만이 활성화를 위한 조건의 첫 번째 집합을 충족합니다.
데이터베이스 상태가 Healthy이며, 복사본 큐 길이가 10 미만이고, 재생 큐 길이가 50 미만이며, 정상 콘텐츠 인덱스인 Server2의 복사본
데이터베이스 상태가 DisconnectedandHealthy이며, 복사본 큐 길이가 10 미만이고, 재생 큐 길이가 50 미만이며, 정상 콘텐츠 인덱스인 Server3의 복사본
이 두 복사본 중에서 Server2의 복사본이 Server3의 복사본과 동일한 복사본 큐 길이를 가지고 있지만 활성화 기본 설정 값은 더 낮아 Server2의 복사본은 누락된 데이터 양이 최소이고 활성화 기본 설정 값이 가장 낮기 때문에 목록 맨 위에 있고 복사본으로 선택되어 활성화됩니다.
예 3: 데이터베이스 상태가 동일하고 콘텐츠 인덱스 상태가 다른 복사본
이 예에서는 사서함 데이터베이스 DB3의 복사본이 4개 있습니다. DB3은 현재 Server1에서 활성화되어 있으며 하드웨어 오류가 발생할 수 있습니다. 다음 표는 Server2, Server3 및 Server4에서 DB3의 데이터베이스 복사본의 현재 상태를 보여 줍니다.
데이터베이스 복사본 | 활성화 기본 설정 | 복사 큐 길이 | 재생 큐 길이 | 콘텐츠 인덱스 상태 | 데이터베이스 상태 | 활성화 차단 |
---|---|---|---|---|---|---|
Server2\DB3 |
2 |
0 |
3 |
Crawling |
Healthy |
아니요 |
Server3\DB3 |
3 |
0 |
3 |
Healthy |
DisconnectedAndHealthy |
아니요 |
Server4\DB3 |
4 |
0 |
0 |
Healthy |
Healthy |
아니요 |
복사본 큐 길이를 기준으로 사용 가능한 복사본을 정렬하면(필요한 경우 활성화 기본 설정 사용) 다음 순서가 지정된 목록이 생성됩니다.
Server2\DB3
Server3\DB3
Server4\DB3
위의 서버에서 호스트된 모든 데이터베이스 복사본 3개는 활성화 조건을 충족합니다. Server2의 활성화 기본 설정 값이 더 낮더라도 콘텐츠 인덱스 상태는 Crawling입니다. 결과적으로 Active Manager는 조건의 첫 번째 집합(상태가 Healthy인 콘텐츠 인덱스를 포함)에 대해 목록을 확인하는 경우 콘텐츠 인덱스 상태가 Healthy이므로 Server3의 데이터베이스 복사본이 선호됩니다.
예 4: 최상의 복사본 선택에 대한 AutoDatabaseMountDial의 영향
이 예에서는 사서함 데이터베이스 DB4의 복사본이 4개 있습니다. DB4는 현재 Server1에서 활성화되어 있으며 다시 부팅해야 하는 오류가 발생할 수 있습니다. 다음 표는 Server2, Server3 및 Server4에서 DB4의 데이터베이스 복사본의 현재 상태를 보여 줍니다. DAG에 있는 모든 사서함 서버의 AutoDatabaseMountDial 매개 변수는 무손실로 구성됩니다(복사본 큐 길이는 0임).
데이터베이스 복사본 | 활성화 기본 설정 | 복사 큐 길이 | 재생 큐 길이 | 콘텐츠 인덱스 상태 | 데이터베이스 상태 | 활성화 차단 |
---|---|---|---|---|---|---|
Server2\DB4 |
2 |
0 |
4523 |
Healthy |
Healthy |
아니요 |
Server3\DB4 |
3 |
100 |
25 |
Crawling |
Healthy |
아니요 |
Server4\DB4 |
4 |
6 |
62 |
Healthy |
Healthy |
아니요 |
자동 데이터베이스 탑재 다이얼 설정이 무손실로 설정되기 때문에, Active Manager는 복사본 큐 길이 대신 기본 정렬 키로 활성화 기본 설정을 사용합니다. 활성화 기본 설정을 기반으로 사용 가능한 복사본을 정렬하면 다음 순서가 지정된 목록이 생성됩니다.
Server2\DB4
Server3\DB4
Server4\DB4
조건의 첫 번째, 두 번째 또는 세 번째 집합을 충족하는 데이터베이스가 없지만 Server3의 데이터베이스 복사본은 조건의 네 번째 집합을 충족합니다(콘텐츠 인덱스 상태가 Crawling이며 재생 큐 길이는 50 미만임). Server3의 데이터베이스 복사본의 복사본 큐 길이는 100이지만, Server1이 다시 부팅을 완료하지 않았기 때문에 ACLL 프로세스는 누락된 로그 파일을 Server3에 복사할 수 없습니다. ACLL 프로세스는 누락된 데이터의 양이 AutoDatabaseMountDial 매개 변수에 대해 구성된 값 내에 있지 않음을 알리며 이로 인해 PAM이 다음으로 사용 가능한 최상의 복사본을 선택합니다.
위의 시나리오에서 Server2 및 Server4의 데이터베이스 복사본이 조건의 여섯 번째 집합을 충족합니다(정상 데이터베이스 및 콘텐츠 인덱스가 있으며 복사본 큐 길이가 10 미만임). 사용 가능한 복사본의 정렬된 순서에서 순서가 높게 지정되어 있으므로 Server2의 데이터베이스 복사본이 다음이 됩니다. ACLL 프로세스는 Server2에서 실행하지만 Server1이 네트워크에서 여전히 통신하지 않아 ACLL은 로그를 복사할 수 없습니다. 복사본 큐 길이가 AutoDatabaseMountDial 매개 변수에 대해 구성된 값 내에 있기 때문에, ACLL은 성공 메시지를 PAM에 전송하며 PAM은 RPC를 통해 데이터베이스 탑재 요청을 발행합니다.
© 2010 Microsoft Corporation. 모든 권리 보유.