페푸리의 Office Server 이야기

All previous versions of Exchange Server, from Exchange Server 4.0 to Exchange Server 2010, have supported running a single instance of the Information Store process (Store.exe) on the Mailbox server role. This single Store instance hosts all databases on the server: active, passive, lagged, and recovery. In the previous Exchange architectures, there is little, if any, isolation between the different databases hosted on a Mailbox server. An issue with a single mailbox database has the potential to negatively affect all other databases, and crashes resulting from a mailbox corruption can affect service for all users whose databases are hosted on that server.

Another challenge with a single Store instance in previous versions of Exchange is that the Extensible Storage Engine (ESE) scales well to 8-12 processor cores, but beyond that, cross-processor communication and cache synchronization issues lead to negative scale. Given today’s much larger servers, with 16+ core systems available, this would mean impose the administrative challenge of managing the affinity of 8-12 cores for ESE and using the other cores for non-Store processes (for example, Assistants, Search Foundation, Managed Availability, etc.). Moreover, the previous architecture restricted scale-up for the Store process.

The Store.exe process has evolved considerably throughout the years as Exchange Server itself evolved, but as a single process, ultimately its scalability is limited, and it represents a single point of failure. Because of these limits, Store.exe is gone in Exchange 2013 and replaced by the Managed Store.

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

이전 버전의 Exchange에서 하나의 Store 인스턴스에 대한 또 다른 문제는 Extensible Storage Engine (ESE)이 8-12 개의 프로세서 코어까지 잘 확장되지만 크로스 프로세서 통신 및 캐시 동기화 문제가 부정적인 스케일로 이어지는 것입니다. 16 개 이상의 핵심 시스템을 사용할 수있는 오늘날의 훨씬 큰 서버를 감안할 때 ESE 용 8-12 코어의 친화력 관리와 비 Store 프로세스 (예 : 보조자, 검색 기반, 가용성 관리 등). 또한 이전 아키텍처는 저장 프로세스의 규모를 제한했습니다.

Store.exe 프로세스는 Exchange Server 자체가 진화함에 따라 수년 동안 진화 해 왔지만 단일 프로세스로서 궁극적으로 확장 성은 제한적이며 단일 실패 지점을 나타냅니다. 이러한 한계로 인해 Store.exe는 Exchange 2013에서 사라지고 Managed Store로 대체되었습니다.

Managed Store

The Managed Store is the name for the Information Store (aka the Store) processes in Exchange Server 2013. The Managed Store uses a controller/worker process model that provides storage process isolation and faster database failover. The Managed Store also includes a new static database caching mechanism that replaces the dynamic buffer algorithm in previous versions of Exchange Server. In the multi-process model used by the Managed Store, there is a single store service controller process (in this case, Microsoft.Exchange.Store.Service.exe aka MSExchangeIS), and one worker process (in this case, Microsoft.Exchange.Store.Worker.exe) for each mounted database. When a database is mounted, a new worker process is instantiated that services only that database. When a database is dismounted, the worker process for that database is terminated.

For example, if you have 40 databases mounted on a server, there will be 41 processes running for the Managed Store, one for each database, and one for the store service process controller.

Managed Store는 Exchange Server 2013의 Information Store (store 라고도 함) 프로세스의 이름입니다. Managed Store는 저장소 프로세스 격리 및 더 빠른 데이터베이스 장애 조치를 제공하는 컨트롤러 / 작업자 프로세스 모델을 사용합니다. 또한 Managed Store에는 이전 버전의 Exchange Server에서 동적 버퍼 알고리즘을 대체하는 새로운 정적 데이터베이스 캐싱 메커니즘이 포함되어 있습니다. Managed Store에서 사용하는 다중 프로세스 모델에는 단일 저장소 서비스 컨트롤러 프로세스 (이 경우 MSExchangeIS라는 Microsoft.Exchange.Store.Service.exe)와 하나의 작업자 프로세스 (이 경우 Microsoft.Exchange .Store.Worker.exe)가 있습니다. 데이터베이스가 마운트되면 해당 데이터베이스에만 서비스를 제공하는 새 작업자 프로세스가 인스턴스화됩니다. 데이터베이스가 분리되면 해당 데이터베이스의 작업자 프로세스가 종료됩니다.

예를 들어, 서버에 40 개의 데이터베이스가 마운트되어있는 경우 Managed Store에 대해 41 개의 프로세스가 실행되며 각 데이터베이스에는 하나, Store Service 프로세스 컨트롤러에는 하나의 프로세스가 실행됩니다.

All previous versions of Exchange Server, from Exchange Server 4.0 to Exchange Server 2010, have supported running a single instance of the Information Store process (Store.exe) on the Mailbox server role.

모든 이전 버전의 Exchange Server는 Exchange Server 4.0에서 Exchange Server 2010으로 사서함 서버 역할에 Information Store 프로세스 (Store.exe)의 단일 인스턴스 실행을 지원했습니다.

The store service process controller is very thin and very reliable, but if it dies or is terminated, all of its worker processes die (they will detect the service controller process is gone and exit). The store process controller monitors the health of all store worker processes on the server. A forcible or unexpected termination the Microsoft.Exchange.Store.Service.exe causes an immediate failover of all active database copies. The Managed Store is also tightly integrated with the Microsoft Exchange Replication service (MSExchangeRepl.exe) and Active Manager. The controller process, worker processes, and Replication service work together to provide greater availability and reliability:

• Microsoft Exchange Replication service process (MSExchangeRepl.exe)
• Responsible for issuing mount and dismount operations to the Store
• Initiates recovery action on storage or database failures reported by the Store, the Extensible Storage Engine (ESE), and Managed Availability responders
• Detects unexpected database failures
• Provides the administrative interface for management tasks
• Store service process/controller (Microsoft.Exchange.Store.Service.exe)
• Manages each worker process lifetime based on the mount and dismount operations received from the Replication service
• Handles incoming requests from the Windows Service Control Manager
• Logs failure items when store worker process problems detected (for example, hang or unexpected exit)
• Terminates store worker processes in response failover event
• Store worker process (Microsoft.Exchange.Store.Worker.exe)
• Responsible for executing RPC operations for mailboxes on a database
• RPC endpoint instance within worker process is the database GUID
• Provides database cache for a database

Store 서비스 프로세스 컨트롤러는 매우 얇고 신뢰성이 높지만 죽거나 종료되면 모든 Worker프로세스가 종료됩니다. (서비스 컨트롤러 프로세스가 사라지고 종료됨을 감지 함). Store 프로세스 컨트롤러는 서버의 모든 Store Worker 프로세스의 상태를 모니터합니다. 강제 또는 예기치 않은 종료 Microsoft.Exchange.Store.Service.exe는 모든 활성 데이터베이스 복사본을 즉시 장애 조치합니다. 또한 Managed Store는 Microsoft Exchange 복제 서비스 (MSExchangeRepl.exe) 및 활성 관리자와 긴밀하게 통합됩니다. 컨트롤러 프로세스, Worker 프로세스 및 복제 서비스는 함께 작동하여 더 높은 가용성과 안정성을 제공합니다.

• Microsoft Exchange Replication service process (MSExchangeRepl.exe)
• 저장소에 대한 마운트 및 마운트 해제 작업을 담당합니다.
• 저장소, ESE (Extensible Storage Engine) 및 Managed Availability 응답자가보고 한 저장소 또는 데이터베이스 오류에 대한 복구 작업을 시작합니다.
• 예기치 않은 데이터베이스 오류 감지
• 관리 작업을위한 관리 인터페이스를 제공합니다.
• Store service process/controller (Microsoft.Exchange.Store.Service.exe)
• 복제 서비스에서받은 마운트 및 분리 작업을 기반으로 각 Worker 프로세스 수명을 관리합니다.
• Windows 서비스 제어 관리자로부터 들어오는 요청을 처리합니다.
• Store Worker 프로세스 문제가 감지 될 때 실패 항목 기록 (예 : 중단 또는 예기치 않은 종료)
• 응답 장애 조치 이벤트에서 Store Worker 프로세스를 종료합니다.
• Store worker process(Microsoft.Exchange.Store.Worker.exe)
• 데이터베이스의 사서함에 대해 RPC 작업을 실행하는 책임이 있습니다.
• woker 프로세스 내의 RPC 끝점 인스턴스는 데이터베이스 GUID입니다.
• 데이터베이스에 대한 데이터베이스 캐시를 제공합니다.

Static Database Caching Algorithm

The database caching algorithm known as dynamic buffer allocation that was introduced in Exchange Server 5.5 and also used by the Information Store in Exchange 2000 Server, Exchange Server 2003, Exchange Server 2007 and Exchange Server 2010, is also gone from Exchange 2013. Exchange 2013 uses a very simple and straightforward algorithm for determining database cache. The Managed Store no longer dynamically reallocates cache between databases when failover occurs, which greatly simplifies internal cache management. Instead, the memory allocated for each database cache (e.g., each store worker process) is based on number of local database copies and value of MaximumActiveDatabases, if configured. If the value of MaximumActiveDatabases is greater than number of current database copies, then the cache calculation is based on the number of database copies.

The static algorithm used by Exchange 2013 allocates memory for each store worker process’ ESE cache based on physical RAM. This is referred to as a database’s Max Cache Target. 25% of total server memory is allocated to the ESE cache. This is referred to as the Server Cache Size Target.

A static amount of this cache is allocated to active and passive copies. The store worker process will be allocated the Max Cache Target only when servicing an active database copy. Passive database copies are allocated 20 percent of the Max Cache Target. The remainder is reserved by the Store, and allocated to the worker process if the database transitions from passive to active.

Max Cache Target is calculated only at Store startup. Therefore, if you add or remove databases or database copies, you must restart the Store controller service (MSExchangeIS) so that the cache can be adjusted accordingly. If the service is not restarted, then newly created databases will have a smaller cache size target than databases created prior to the service startup. In this event, the sum of database cache size targets will likely exceed the Server Cache Size Target until MSExchangeIS is restarted.

정적 데이터베이스 캐싱 알고리즘

Exchange Server 5.5에서 도입되었으며 Exchange 2000 Server, Exchange Server 2003, Exchange Server 2007 및 Exchange Server 2010의 Information Store에서 사용되는 동적 버퍼 할당이라는 데이터베이스 캐싱 알고리즘도 Exchange 2013에서 사라졌습니다.

Exchange 2013은 데이터베이스 캐시를 결정하기 위한 매우 간단하고 쉬운 알고리즘을 사용합니다.

장애 조치가 발생할 때 Managed Store는 데이터베이스간에 캐시를 더 이상 동적으로 재 할당하지 않으므로 내부 캐시 관리가 크게 단순화됩니다. 대신, 각 데이터베이스 캐시 (예를 들어, 각 Worker 프로세스)에 할당 된 메모리는 로컬 데이터베이스 복사본의 수 및 MaximumActiveDatabases (구성된 경우)의 값을 기반으로합니다. MaximumActiveDatabases 값이 현재 데이터베이스 사본 수보다 크면 캐시 계산은 데이터베이스 사본 수에 기초합니다.

Exchange 2013에서 사용되는 정적 알고리즘은 실제 RAM을 기반으로 각 Store Worker 프로세스의 ESE 캐시에 메모리를 할당합니다. 이를 데이터베이스의 최대 캐시 대상이라고 합니다. 전체 서버 메모리의 25 %가 ESE 캐시에 할당됩니다. 이것을 서버 캐시 크기 목표 라고합니다 .

노트 :

서버 캐시 크기 대상 및 ESE 캐시 저장소에 할당 된 메모리 양은 Active Directory 의 InformationStore 개체 의 msExchESEParamCacheSizeMax 특성을 사용하여 재정의 할 수 있습니다 (구성된 값은 모든 저장소 프로세스에 할당 할 32KB 페이지의 수입니다) ).

이 캐시의 고정 된 양은 Active 및 Passive 복사본에 할당됩니다. Store Worker 프로세스는 활성 데이터베이스 사본을 서비스 할 때만 Max Cache Target을 할당받습니다. 패시브 데이터베이스 복사본은 Max Cache Target의 20 % 할당됩니다. 나머지는 저장소에 의해 예약되며 데이터베이스가 수동에서 활성으로 전환하는 경우 Worker 프로세스에 할당됩니다.

Max Cache Target은 Store 시작시에만 계산됩니다. 따라서 데이터베이스 또는 데이터베이스 복사본을 추가 또는 제거하는 경우 적절하게 캐시를 조정할 수 있도록 Store Controller 서비스 (MSExchangeIS)를 다시 시작해야합니다. 서비스가 다시 시작되지 않으면 새로 작성된 데이터베이스는 서비스 시작 전에 작성된 데이터베이스보다 작은 캐시 크기 대상을가집니다. 이 경우 MSExchangeIS가 다시 시작될 때까지 데이터베이스 캐시 크기 대상의 합계가 서버 캐시 크기 대상을 초과 할 수 있습니다.

Example Database Cache Calculations

Below are example database caching calculations that are based on a Mailbox server’s memory and database configuration.

Example 1

In this example, the Mailbox server has 48 GB of memory, and it hosts two active databases and two passive databases. In addition, the MaximumActiveDatabases parameter is not configured. In this configuration, the amount of database cache is 3 GB for each active database copy worker process and 0.6 GB for each passive database copy worker process. Here’s how these values were obtained.

To get the Server Cache Size Target, multiply the amount memory by 25%:

48 GB X 25% = 12 GB

To get the Database Max Cache Target, divide the Server Cache Size Target by the total number of active and passive databases:

12 GB / 4 databases = 3 GB

To determine the amount of memory used for the passive database copies, multiply the Database Max Cache Target by 20%:

3 GB X 20% = 0.6 GB

Out of the 12 GB of memory assigned to the Server Cache Size Target, 7.2 GB will be in use by database worker processes, and 4.8 GB will be reserved by the Information Store for the two passive database copies in case they become active copies. In that event, they will use their Max Cache Target of 3 GB.

Example 2

In this example, the Mailbox server also has 48 GB of memory and hosts two active databases and two passive databases; however, the MaximumActiveDatabases parameter is configured with a value of 2. In this configuration, the amount of database cache is 5 GB for each active database copy worker process and 0.2 GB for each passive database copy worker process. Here’s how these values were obtained.

To get the Server Cache Size Target, multiply the amount memory by 25%:

48 GB X 25% = 12 GB

To get the Database Max Cache Target, divide the Server Cache Size Target by the total number of active database plus the total number of passive databases multiplied by 20%:

12 GB / (2A + (2P X 20%)) = 5 GB

To determine the amount of memory used for the passive database copies, multiply the Database Max Cache Target by 20%:

5 GB X 20% = 1 GB

Out of the 12 GB of memory assigned to the Server Cache Size Target, 12 GB will be in use by database worker processes, and no memory will be reserved by the Information Store for the two passive database copies because they cannot become active copies in this configuration (because MaximumActiveDatabases is configured with a value of 2, and there are already 2 active database copies on the server).