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

Применяется к: Exchange Server 2013 г.

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

Еще одна проблема с одним экземпляром Store в предыдущих версиях Exchange заключается в том, что extensible служба хранилища Engine (ESE) масштабирует до 8-12 ядер процессора, но за пределами этого порога проблемы межобработки связи и синхронизации кэша приводят к отрицательной шкале. Учитывая сегодняшние гораздо более крупные серверы с доступными 16+ базовыми системами, это будет означать введение административной проблемы управления близостью 8-12 ядер для ESE и использования других ядер для процессов, не хранимых в магазине (например, 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 каждого рабочего процесса хранилища исходя из физической оперативной памяти. Эта память называется целевой базой данных Max Cache. На кэш 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 ГБ

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

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

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

5 ГБ X 20 % = 1 ГБ

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