관리되는 저장소
적용 대상: Exchange Server 2013
Exchange Server 4.0부터 2010년 Exchange Server Exchange Server 모든 이전 버전은 사서함 서버 역할에서 단일 instance 정보 저장소 프로세스(Store.exe) 실행을 지원했습니다. 이 단일 Store instance 서버의 모든 데이터베이스(활성, 수동, 지연 및 복구)를 호스트합니다. 이전 Exchange 아키텍처에서는 사서함 서버에서 호스트되는 다른 데이터베이스 간에 격리가 거의 없습니다. 단일 사서함 데이터베이스의 문제는 다른 모든 데이터베이스에 부정적인 영향을 줄 수 있으며 사서함 손상으로 인한 충돌은 해당 서버에서 데이터베이스가 호스트되는 모든 사용자의 서비스에 영향을 줄 수 있습니다.
이전 버전의 Exchange에서 단일 Store instance 또 다른 과제는 ESE(Extensible Storage Engine)가 8-12 프로세서 코어로 잘 확장되지만 해당 임계값을 초과하면 프로세서 간 통신 및 캐시 동기화 문제가 음수 크기로 이어진다는 점입니다. 16개 이상의 코어 시스템을 사용할 수 있는 오늘날의 더 큰 서버를 감안할 때, 이는 ESE에 대한 8-12개 코어의 선호도를 관리하고 비 스토어 프로세스(예: Assistants, Search Foundation, Managed Availability 등)에 다른 코어를 사용하는 관리 과제를 부과한다는 것을 의미합니다. 또한 이전 아키텍처는 Store 프로세스에 대한 확장을 제한했습니다.
Store.exe 프로세스는 Exchange Server 자체적으로 발전함에 따라 수년에 걸쳐 상당히 발전해 왔지만, 단일 프로세스로서 궁극적으로 확장성이 제한되며 단일 실패 지점을 나타냅니다. 이러한 제한으로 인해 Store.exe Exchange 2013에서 사라지고 관리 저장소로 대체됩니다.
관리되는 저장소
관리 저장소는 2013년 Exchange Server 정보 저장소(즉, 스토어) 프로세스의 이름입니다. Managed Store는 스토리지 프로세스 격리 및 더 빠른 데이터베이스 장애 조치(failover)를 제공하는 컨트롤러/작업자 프로세스 모델을 사용합니다. Managed Store에는 이전 버전의 Exchange Server 동적 버퍼 알고리즘을 대체하는 새로운 정적 데이터베이스 캐싱 메커니즘도 포함되어 있습니다. Managed Store에서 사용하는 다중 프로세스 모델에는 탑재된 각 데이터베이스에 대해 단일 저장소 서비스 컨트롤러 프로세스(이 경우 Microsoft.Exchange.Store.Service.exe 일명 MSExchangeIS)와 하나의 작업자 프로세스(이 경우 Microsoft.Exchange.Store.Worker.exe)가 있습니다. 데이터베이스가 탑재되면 해당 데이터베이스에만 서비스를 제공하는 새 작업자 프로세스가 인스턴스화됩니다. 데이터베이스가 분리되면 해당 데이터베이스에 대한 작업자 프로세스가 종료됩니다.
예를 들어 서버에 40개의 데이터베이스가 탑재된 경우 관리 저장소에 대해 실행되는 프로세스 41개, 각 데이터베이스에 대해 하나씩, 저장소 서비스 프로세스 컨트롤러용으로 41개의 프로세스가 실행됩니다.
스토어 서비스 프로세스 컨트롤러는 얇고 안정적이지만, 죽거나 종료되면 모든 작업자 프로세스가 종료됩니다(서비스 컨트롤러 프로세스가 종료된 것을 감지합니다). 저장소 프로세스 컨트롤러는 서버의 모든 매장 작업자 프로세스의 상태를 모니터링합니다. Microsoft.Exchange.Store.Service.exe 강제 종료되거나 예기치 않은 종료로 인해 모든 활성 데이터베이스 복사본이 즉시 장애 조치(failover)됩니다. 또한 관리되는 저장소는 Microsoft Exchange 복제 서비스(MSExchangeRepl.exe) 및 Active Manager와 긴밀하게 통합됩니다. 컨트롤러 프로세스, 작업자 프로세스 및 복제 서비스는 함께 작동하여 가용성과 안정성을 향상합니다.
Microsoft Exchange 복제 서비스 프로세스(MSExchangeRepl.exe)
스토어에 탑재 및 분리 작업 발급 담당
저장소, ESE(Extensible Storage Engine) 및 관리되는 가용성 응답자가 보고한 스토리지 또는 데이터베이스 오류에 대한 복구 작업을 시작합니다.
예기치 않은 데이터베이스 오류를 검색합니다.
관리 작업에 대한 관리 인터페이스를 제공합니다.
스토어 서비스 프로세스/컨트롤러(Microsoft.Exchange.Store.Service.exe)
복제 서비스에서 받은 탑재 및 분리 작업에 따라 각 작업자 프로세스 수명을 관리합니다.
Windows 서비스 제어 관리자에서 들어오는 요청을 처리합니다.
저장소 작업자 프로세스 문제가 감지될 때 오류 항목을 기록합니다(예: 중단 또는 예기치 않은 종료).
응답 장애 조치(failover) 이벤트에서 저장소 작업자 프로세스를 종료합니다.
저장소 작업자 프로세스(Microsoft.Exchange.Store.Worker.exe)
데이터베이스의 사서함에 대한 RPC 작업 실행 담당
작업자 프로세스 내의 RPC 엔드포인트 instance 데이터베이스 GUID입니다.
데이터베이스에 대한 데이터베이스 캐시 제공
정적 데이터베이스 캐싱 알고리즘
Exchange Server 5.5에서 도입되었으며 Exchange 2000 Server, Exchange Server 2003, Exchange Server 2007 및 Exchange Server 2010의 정보 저장소에서도 사용되는 동적 버퍼 할당이라고 하는 데이터베이스 캐싱 알고리즘도 Exchange 2013에서 사라졌습니다. Exchange 2013은 데이터베이스 캐시를 결정하는 간단하고 간단한 알고리즘을 사용합니다. 관리되는 저장소는 장애 조치(failover)가 발생할 때 데이터베이스 간에 캐시를 더 이상 동적으로 다시 할당하지 않으므로 내부 캐시 관리가 크게 간소화됩니다. 대신 각 데이터베이스 캐시에 할당된 메모리(예: 각 저장소 작업자 프로세스)는 구성된 경우 로컬 데이터베이스 복사본 수와 MaximumActiveDatabases 값을 기반으로 합니다. MaximumActiveDatabases 값이 현재 데이터베이스 복사본 수보다 큰 경우 캐시 계산은 데이터베이스 복사본 수를 기반으로 합니다.
Exchange 2013에서 사용하는 정적 알고리즘은 실제 RAM을 기반으로 각 저장소 작업자 프로세스의 ESE 캐시에 대한 메모리를 할당합니다. 이 메모리를 데이터베이스의 최대 캐시 대상이라고 합니다. 전체 서버 메모리의 25%가 ESE 캐시에 할당됩니다. 이 메모리 비율을 서버 캐시 크기 대상이라고 합니다.
참고
서버 캐시 크기 대상 및 따라서 ESE 캐시용 Store에 할당된 메모리 양은 Active Directory의 InformationStore 개체의 msExchESEParamCacheSizeMax 특성을 사용하여 재정의할 수 있습니다(구성된 값은 모든 저장소 프로세스에 할당할 32KB 페이지 수).
이 캐시의 정적 크기는 활성 및 수동 복사본에 할당됩니다. 저장소 작업자 프로세스는 활성 데이터베이스 복사본을 서비스할 때만 최대 캐시 대상이 할당됩니다. 수동 데이터베이스 복사본은 최대 캐시 대상의 20%가 할당됩니다. 나머지는 Store에서 예약하고 데이터베이스가 수동에서 활성으로 전환되는 경우 작업자 프로세스에 할당됩니다.
최대 캐시 대상은 스토어 시작 시만 계산됩니다. 따라서 데이터베이스 또는 데이터베이스 복사본을 추가하거나 제거하는 경우 캐시를 적절하게 조정할 수 있도록 MSExchangeIS(Store 컨트롤러 서비스)를 다시 시작해야 합니다. 서비스를 다시 시작하지 않으면 새로 만든 데이터베이스는 서비스 시작 전에 만든 데이터베이스보다 더 작은 캐시 크기 대상을 갖게 됩니다. 이 경우 데이터베이스 캐시 크기 대상의 합계는 MSExchangeIS가 다시 시작될 때까지 서버 캐시 크기 대상을 초과할 가능성이 높습니다.
예제 데이터베이스 캐시 계산
다음은 사서함 서버의 메모리 및 데이터베이스 구성을 기반으로 하는 데이터베이스 캐싱 계산 예제입니다.
예 1
이 예제에서 사서함 서버에는 48GB의 메모리가 있으며 활성 데이터베이스 2개와 수동 데이터베이스 2개가 호스트됩니다. 또한 MaximumActiveDatabases 매개 변수가 구성되지 않았습니다. 이 구성에서 데이터베이스 캐시의 양은 각 활성 데이터베이스 복사 작업자 프로세스에 대해 3GB, 수동 데이터베이스 복사 작업자 프로세스당 0.6GB입니다. 이러한 값을 얻은 방법은 다음과 같습니다.
서버 캐시 크기 대상을 얻으려면 메모리 양을 25% 곱합니다.
48GB X 25% = 12GB
데이터베이스 최대 캐시 대상을 얻으려면 서버 캐시 크기 대상을 활성 및 수동 데이터베이스의 총 수로 나눕니다.
12GB/4개 데이터베이스 = 3GB
수동 데이터베이스 복사본에 사용되는 메모리 양을 확인하려면 데이터베이스 최대 캐시 대상을 20%로 곱합니다.
3GB X 20% = 0.6GB
서버 캐시 크기 대상에 할당된 12GB 메모리 중 7.2GB는 데이터베이스 작업자 프로세스에서 사용되며, 활성 복사본이 될 경우 두 개의 수동 데이터베이스 복사본에 대해 정보 저장소에서 4.8GB를 예약합니다. 이 경우 최대 캐시 대상인 3GB를 사용합니다.
예 2
이 예제에서 사서함 서버에는 48GB의 메모리가 있으며 두 개의 활성 데이터베이스와 2개의 수동 데이터베이스를 호스트합니다. 그러나 MaximumActiveDatabases 매개 변수는 값 2로 구성됩니다. 이 구성에서 데이터베이스 캐시의 양은 각 활성 데이터베이스 복사 작업자 프로세스에 대해 5GB, 수동 데이터베이스 복사 작업자 프로세스당 0.2GB입니다. 이러한 값을 얻은 방법은 다음과 같습니다.
서버 캐시 크기 대상을 얻으려면 메모리 양을 25% 곱합니다.
48GB X 25% = 12GB
데이터베이스 최대 캐시 대상을 얻으려면 서버 캐시 크기 대상을 활성 데이터베이스의 총 수와 20%를 곱한 수동 데이터베이스의 총 수로 나눕니다.
12GB/(2A + (2P X 20%)) = 5GB
수동 데이터베이스 복사본에 사용되는 메모리 양을 확인하려면 데이터베이스 최대 캐시 대상을 20%로 곱합니다.
5GB X 20% = 1GB
서버 캐시 크기 대상에 할당된 12GB 메모리 중 12GB는 데이터베이스 작업자 프로세스에서 사용되며, 이 구성에서 활성 복사본이 될 수 없기 때문에 정보 저장소에서 이 구성에서 활성 복사본이 될 수 없으므로 메모리가 예약되지 않습니다( MaximumActiveDatabases 는 값 2로 구성되었기 때문에 서버에 이미 2개의 활성 데이터베이스 복사본이 있습니다.)