Управляемое хранилищеManaged Store

Применимо к: Exchange Server 2013Applies to: Exchange Server 2013

Все предыдущие версии Exchange Server, от Exchange Server 4.0 до Exchange Server 2010, поддерживали запуск единого экземпляра процесса хранилища данных (Store.exe) на роли сервера почтовых ящиков. В этом едином хранилище размещены все базы данных на сервере: активные, пассивные, изолированные и базы данных восстановления. В предыдущих архитектурах Exchange существует незначительная изоляция между различными базами данных, размещенными на сервере почтовых ящиков. Проблемы с единой базой данных почтовых ящиков могут негативно сказаться на всех остальных базах данных, а аварийное завершение в результате повреждения почтового ящика может повлиять на работу служб для всех пользователей, базы данных которых размещены на таком сервере.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.

Еще одна трудность при использовании единого экземпляра хранилища в предыдущих версиях Exchange состоит в том, что расширенный обработчик хранилищ (ESE) хорошо масштабируется для 8–12 процессорных ядер, а кроме этого взаимодействие между процессорами и проблемы синхронизации кэша могут привести к отрицательному масштабированию. В условиях использования современных серверов с системами с 16 и большим числом ядер это усложняет администрирование, ведь придется управлять сходством 8–12 ядер для ESE, а остальные ядра использовать для процессов, не связанных с хранилищем (например, для помощников, платформ поиска, управляемой доступности и т. п.). Кроме того, предыдущая архитектура ограничивала увеличение масштаба для процессов хранилища.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.

За многие годы процесс Store.exe был значительно усовершенствован, как и Exchange Server, но в конечном итоге его масштабируемость как одного процесса ограничена и представляет единственную точку отказа. Из-за этих ограничений в Exchange 2013 процесс Store.exe заменен на управляемое хранилище.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.

Управляемое хранилищеManaged Store

Управляемое хранилище — это имя процессов банка данных (или хранилища) в Exchange Server 2013. Управляемое хранилище использует модель процессов-контроллеров и рабочих процессов, которая обеспечивает изоляцию процессов хранилища и более быструю отработку отказа базы данных. Оно также включает новый механизм кэширования статических баз данных, который заменяет алгоритм динамической буферизации в предыдущих версиях Exchange Server. В модели нескольких процессов, используемой в управляемом хранилище, для каждой подключенной базы данных есть один процесс-контроллер службы хранилища (в этом случае Microsoft.Exchange.Store.Service.exe, он же — MSExchangeIS) и один рабочий процесс (в этом случае Microsoft.Exchange.Store.Worker.exe). После подключения базы данных создается экземпляр нового рабочего процесса, который обслуживает только эту базу данных. После отключения базы данных ее рабочий процесс завершается.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.

Например, если на сервере подключено 40 баз данных, для управляемого хранилища будет выполняться 41 процесс: по одному для каждой базы данных и один для процесса-контроллера службы хранилища.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.

Процесс-контроллер службы хранилища — очень тонкий и надежный. Но в случае его прекращения или завершения прекращаются все его рабочие процессы (они обнаружат, что процесс-контроллер службы исчез и выйдут). Процесс-контроллер хранилища наблюдает за работоспособностью всех рабочих процессов на сервере. Принудительное или неожиданное завершение процесса Microsoft.Exchange.Store.Service.exe приводит к немедленной отработке отказа всех копий активных баз данных. Управляемое хранилище также тесно интегрировано со службой репликации Microsoft Exchange (MSExchangeRepl.exe) и компонентом Active Manager. Процесс-контроллер, рабочие процессы и служба репликации вместе работают над обеспечением большей доступности и надежности.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 (MSExchangeRepl.exe):Microsoft Exchange Replication service process (MSExchangeRepl.exe)

    • отвечает за выдачу хранилищу операций по подключению и отключению;Responsible for issuing mount and dismount operations to the Store

    • инициирует действие по восстановлению хранилища или базы данных после сбоя, о котором сообщило хранилище, расширенный обработчик хранилищ (ESE) и ответчики управляемой доступности;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

  • Процесс службы хранилища или контроллер (Microsoft.Exchange.Store.Service.exe):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

    • обрабатывает входящие запросы из диспетчер служб Windows;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

  • Рабочий процесс хранилища (Microsoft.Exchange.Store.Worker.exe):Store worker process (Microsoft.Exchange.Store.Worker.exe)

    • отвечает за выполнение операций RPC для почтовых ящиков в базе данных;Responsible for executing RPC operations for mailboxes on a database

    • экземпляр конечной точки RPC в рабочем процессе — это GUID базы данных;RPC endpoint instance within worker process is the database GUID

    • предоставляет кэш базы данных для базы данных.Provides database cache for a database

Алгоритм кэширования статических баз данныхStatic Database Caching Algorithm

Базы данных, кэширование алгоритм, известных как выделения динамических буфера, который был появившихся в Exchange Server 5.5 и также используемый банка данных в Exchange 2000 Server, Exchange Server 2003, Exchange Server 2007 и Exchange Server 2010 также исчезла с Exchange 2013. Exchange 2013 использует алгоритм очень просто и удобно для определения кэш базы данных. Управляемое хранилище перешла к больше не динамически кэша между базами данных, когда переход на другой ресурс, который существенно упрощает управление внутреннего кэша. Вместо этого объем памяти, выделенный для каждой базы данных кэша (например, каждый хранилища рабочий процесс) на основе числа копий локальной базы данных и значение MaximumActiveDatabases, если настроена. Если значение MaximumActiveDatabases больше, чем число копий текущей базы данных, кэш расчет основан на количество копий базы данных.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.

Статические алгоритм, используемый в Exchange 2013 выделение памяти для кэша ESE каждого хранилища рабочего процесса, основанный на физической памяти. Это называется базы данных Конечного кэша Max. 25% общий объем памяти сервера, выделенный для кэша ESE. Это называется Конечного размера кэша сервера.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.

Примечание

Целевой размер кэша сервера и, следовательно, объем памяти, выделенный для хранилища для кэша ESE можно переопределить с помощью атрибута msExchESEParamCacheSizeMax объекта InformationStore в Active Directory (настроить значение равно число страниц 32 КБ для выделения во всех хранилища процессы).The Server Cache Size Target, and therefore the amount of memory allocated to the Store for ESE cache, can be overridden using msExchESEParamCacheSizeMax attribute of the InformationStore object in Active Directory (the value configured is the number of 32 KB pages to allocate across all store processes).

Для активных и пассивных копий выделяется статический объем этого кэша. Для рабочих процессов хранилища максимальный целевой кэш выделяется только при обслуживании копии активной базы данных. Для копий пассивных баз данных выделяется 20 % максимального целевого кэша. Остальную часть резервирует хранилище и выделяет ее для рабочих процессов при переходе базы данных из пассивного в активное состояние.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.

Максимальный целевой кэш рассчитывается только во время запуска хранилища. Потому в случае добавления или удаления баз данных или их копий необходимо перезапустить службу контроллера хранилища (MSExchangeIS) для соответствующей регулировки кэша. Если не перезапустить службу, целевой размер кэша новых баз данных будет меньше, чем у баз данных, созданных до запуска службы. В этом случае сумма целевых размеров кэшей баз данных скорее всего будет превышать целевой размер кэша сервера, пока не будет перезапущена служба MSExchangeIS.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.

Примеры расчетов кэша базы данныхExample Database Cache Calculations

Ниже приведены расчеты кэша базы данных на основе объема памяти сервера почтовых ящиков и конфигурации базы данных.Below are example database caching calculations that are based on a Mailbox server’s memory and database configuration.

Пример 1Example 1

В этом примере на сервере почтовых ящиков выделен 48 ГБ оперативной памяти и размещенных на нем двух активных баз данных и два пассивных баз данных. Кроме того параметр MaximumActiveDatabases не настроен. В этой конфигурации объем кэша базы данных — 3 ГБ для каждой активной базы данных копии рабочего процесса и 0,6 ГБ для каждого пассивная копия рабочего процесса. Вот, как были получены следующие значения.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.

Чтобы узнать целевой размер кэша сервера, умножьте объем памяти на 25 %:To get the Server Cache Size Target, multiply the amount memory by 25%:

48 ГБ X 25 % = 12 ГБ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 ГБ/4 базы данных = 3 ГБ12 GB / 4 databases = 3 GB

Чтобы определить объем памяти, используемый копиями пассивных баз данных, умножьте максимальный целевой кэш базы данных на 20 %:To determine the amount of memory used for the passive database copies, multiply the Database Max Cache Target by 20%:

3 ГБ X 20 % = 0,6 ГБ3 GB X 20% = 0.6 GB

Из 12 ГБ памяти, выделенных на целевой размер кэша сервера, 7,2 ГБ будут использовать рабочие процессы базы данных, а 4,8 ГБ хранилище данных зарезервирует для двух копий пассивных баз данных на тот случай, если они станут активными. В таком случае они будут использовать максимальный целевой кэш в размере 3 ГБ.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.

Пример 2Example 2

В этом примере на сервере почтовых ящиков также установлен 48 ГБ памяти и два активных баз данных узлов и два пассивных баз данных; Тем не менее параметр MaximumActiveDatabases задано значение 2. В этой конфигурации объем кэша базы данных — 5 для каждой активной базы данных копии рабочего процесса и 0,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.

Чтобы узнать целевой размер кэша сервера, умножьте объем памяти на 25 %:To get the Server Cache Size Target, multiply the amount memory by 25%:

48 ГБ X 25 % = 12 ГБ48 GB X 25% = 12 GB

Чтобы определить максимальный целевой кэш базы данных, разделите целевой размер кэша сервера на сумму общего количества активных баз данных и общего количества пассивных баз данных, умноженного на 20 %: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 ГБ/(2А + (2П X 20 %)) = 5 ГБ12 GB / (2A + (2P X 20%)) = 5 GB

Чтобы определить объем памяти, используемый копиями пассивных баз данных, умножьте максимальный целевой кэш базы данных на 20 %:To determine the amount of memory used for the passive database copies, multiply the Database Max Cache Target by 20%:

5 ГБ X 20 % = 1 ГБ5 GB X 20% = 1 GB

Из него 12 ГБ памяти, назначенный конечного размера кэша сервера 12 ГБ будет используется база данных рабочих процессов, а не памяти необходимо зарезервировать с банка данных для двух пассивных копий базы данных, так как они не могут стать активные копии в этом Конфигурация (так как MaximumActiveDatabases настроено со значением 2, и на сервере уже существует 2 активных копий базы данных).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).