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

Область действия: Exchange Server 2013

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

Еще одна проблема с одним экземпляром Store в предыдущих версиях Exchange заключается в том, что расширяемый модуль хранилища (ESE) хорошо масштабируется до 8–12 ядер процессора, но при превышении этого порогового значения проблемы с обменом данными между процессорами и синхронизацией кэша приводят к отрицательному масштабированию. Учитывая современные гораздо более крупные серверы с более чем 16 основными системами, это означает, что администрирование будет означать, что управление сходством 8–12 ядер для ESE и использование других ядер для процессов, отличных от Store (например, Assistants, Search Foundation, Managed Availability и т. д.). Кроме того, предыдущая архитектура ограничивала увеличение масштаба для процессов хранилища.

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

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

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

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

Контроллер процесса службы хранилища является тонким и надежным, но если он завершается или завершается, все его рабочие процессы завершаются (они обнаруживают, что процесс контроллера службы отсутствует и завершается). Контроллер процесса хранилища отслеживает работоспособность всех рабочих процессов хранилища на сервере. Принудительное или непредвиденное завершение Microsoft.Exchange.Store.Service.exe приводит к немедленной отработке отказа всех активных копий базы данных. Управляемое хранилище также тесно интегрировано со службой репликации Microsoft Exchange (MSExchangeRepl.exe) и Active Manager. Процесс контроллера, рабочие процессы и служба репликации работают вместе для повышения доступности и надежности:

  • Процесс службы репликации Microsoft Exchange (MSExchangeRepl.exe):

    • отвечает за выдачу хранилищу операций по подключению и отключению;

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

    • обнаруживает неожиданные сбои баз данных;

    • предоставляет интерфейс администрирования задач управления.

  • Процесс службы хранилища или контроллер (Microsoft.Exchange.Store.Service.exe):

    • управляет жизненным циклом каждого рабочего процесса на основании операций по подключению и отключению, полученных из службы репликации;

    • обрабатывает входящие запросы из диспетчер служб Windows;

    • записывает в журнал элементы со сбоями в случае обнаружения проблем с рабочими процессами (например, завершение или неожиданный выход);

    • завершает рабочие процессы хранилища в ответ на отработку отказа.

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

    • отвечает за выполнение операций RPC для почтовых ящиков в базе данных;

    • экземпляр конечной точки RPC в рабочем процессе — это GUID базы данных;

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

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

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

Статический алгоритм, используемый в Exchange 2013, выделяет память для кэша ESE каждого рабочего процесса хранилища исходя из физической оперативной памяти. Эта память называется целевым объектом максимального кэша базы данных. На кэш ESE выделено 25 % всей памяти сервера. Эта доля памяти называется целевым значением размера кэша сервера.

Примечание

Целевой размер кэша сервера и, следовательно, объем памяти, выделенный в Хранилище для кэша ESE, можно переопределить с помощью атрибута msExchESEParamCacheSizeMax объекта InformationStore в Active Directory (заданное значение — количество страниц 32 КБ для выделения во всех процессах хранения).

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

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

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

Ниже приведены расчеты кэша базы данных на основе объема памяти сервера почтовых ящиков и конфигурации базы данных.

Пример 1

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

Чтобы узнать целевой размер кэша сервера, умножьте объем памяти на 25 %:

48 ГБ X 25 % = 12 ГБ

Чтобы определить максимальный целевой кэш базы данных, разделите целевой размер кэша сервера на общее количество активных и пассивных баз данных:

12 ГБ/4 базы данных = 3 ГБ

Чтобы определить объем памяти, используемый копиями пассивных баз данных, умножьте максимальный целевой кэш базы данных на 20 %:

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

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

Пример 2

В этом примере сервер почтовых ящиков также содержит 48 ГБ памяти и размещает две активные базы данных и две пассивные базы данных. Однако параметр MaximumActiveDatabases настраивается со значением 2. В этой конфигурации объем кэша базы данных — 5 ГБ для каждого активного рабочего процесса копирования базы данных и 0,2 ГБ для каждого пассивного рабочего процесса копирования базы данных. Вот как были получены эти значения.

Чтобы узнать целевой размер кэша сервера, умножьте объем памяти на 25 %:

48 ГБ X 25 % = 12 ГБ

Чтобы получить целевой объект максимального размера кэша базы данных, разделите целевой размер кэша сервера на общее число активных баз данных и общее число пассивных баз данных, умноженное на 20 %:

12 ГБ/(2А + (2П X 20 %)) = 5 ГБ

Чтобы определить объем памяти, используемый копиями пассивных баз данных, умножьте максимальный целевой кэш базы данных на 20 %:

5 ГБ X 20 % = 1 ГБ

Из 12 ГБ памяти, назначенного целевому объекту размера кэша сервера, 12 ГБ будут использоваться рабочими процессами базы данных, и хранилище сведений не будет резервировать память для двух пассивных копий базы данных, так как они не могут стать активными копиями в этой конфигурации (так как maximumActiveDatabases настроен со значением 2, и на сервере уже есть две активные копии базы данных.