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

Область применения: 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 (например, Помощники, Search Foundation, Управляемая доступность и т. д.). Кроме того, предыдущая архитектура ограничивала увеличение масштаба для процессов хранилища.

За многие годы процесс 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 % всей памяти сервера. Эта доля памяти называется целевым размером кэша сервера.

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