Фоновое обслуживание серверов Exchange

Все базы данных имеют свою внутреннюю структуру, которая требует обслуживания, и хранилище Exchange Server Store в этом не отличается от других баз данных. Поскольку Exchange разрабатывался как система высокой надежности с малым временем простоя, Store выполняет множество операций по обслуживанию в виде фоновых задач. Эти задачи выполняются каждую ночь для обеспечения логической целостности почтовых ящиков и общих папок, а также для удаления ненужных данных. Рассмотрим задачи, которые Store выполняет ночью в фоновом режиме и определим, какие из них наиболее важны для сервера Exchange.

Ночная смена

В Таблице 1 показано, какие 11 фоновых задач по обслуживанию выполняет Store каждую ночь. Если Store не может выполнить все задачи в течение отведенного времени, он завершает последнюю выполняемую задачу и записывает параметры о месте остановки, чтобы в следующий период по обслуживанию начать с того же самого места. Store выполняет первые 10 задач из Таблицы 1, а затем делает обращение к ядру базы данных Extensible Storage Engine (ESE) для выполнения последней задачи: дефрагментации хранилища. Store должен выполнить по крайней мере одну из 10 задач перед вызовом ESE. По идее, набор задач, выполняемых Store и ESE это ни что иное, как выполнение действий утилит Isinteg и Eseutil. Isinteg работает со структурой таблиц и индексов, которые Store собирает в страницы базы данных, а Eseutil обрабатывает эти страницы базы данных, работая на более низком уровне.

Очевидно, что 11 задач создают большое число изменений содержимого хранилища. Store отражает все изменения в журналах транзакций, которые появляются в большом количестве за ночной период обслуживания. Их можно вычислить по пользовательской активности, которая ночью должна быть минимальной или по количеству репликаций общих папок. Резервное копирование может выполняться одновременно с задачами по обслуживанию системы, но если резервное копирование столкнется с выполнением фоновой дефрагментации, ESE остановит процесс дефрагментации, пока процедура резервного копирования не завершится.

По умолчанию, Exchange выполняет фоновые задачи по обслуживанию между полуночью и 5:00 по местному времени. Можно установить специальное расписание для каждого сервера, открыв Exchange System Manager (ESM), выбрав базу данных, открыв диалоговое окно ее свойств и перейдя на закладку Database. Другим способом является создание серверной политики и применения ее к множеству серверов единовременно, что, безусловно, является хорошим решением для большой организации Exchange. Рисунок 1 показывает пример расписания, установленного с помощью серверной политики. Это расписание поручает Store запускать фоновое обслуживание с 23:00 до 6:00, с понедельника до пятницы (с завершением в субботу утром) и с 19:00 субботы до 6:00 понедельника. Создание большого периода обслуживания в выходные дни позволяет Store выполнить все длительные процедуры, пока пользовательская активность на низком уровне. Следует отметить, что можно создать такое расписание, для которого будет установлен режим постоянного выполнения (Always), при котором Store будет постоянно выполнять операции по обслуживанию, включая такие, как дефрагментация. Однако работа сервера в таком режиме не очень хорошая идея, поскольку фоновые задачи будут его постоянно загружать, а дефрагментация и резервное копирование вообще являются конфликтующими задачами.

Фоновые задачи

Теперь, когда вы знаете про фоновые задачи по обслуживанию, рассмотрим некоторые детали этих процессов, которые помогут еще лучше разобраться в обслуживании почтовой системы. Такие клиенты, как Outlook, сильно нагружают ESE, динамически создавая индексы или отображения данных. Например, если пользователь решает, что ему надо отображать письма в папке Входящие по автору, а не по дате, Outlook выполняет запрос к Store для создания такого отображения. Если Store ранее создавал такое отображение, то оно было кэшировано и ответ будет в данном случае быстрым, хотя Store может быстро обработать запрос и для нового отображения (через ESE). С течением времени, Store накапливает множество отображений - каждая папка в почтовых ящиках может иметь множество видов и такая ситуация не очень хороша, так как каждое отображение занимает пространство в базе данных, а некоторые отображения могли использоваться лишь однажды. Для управления этими отображениями, Store назначает каждому виду время жизни и заносит их во внутреннюю таблицу, которая называется таблицей устаревших индексов. Когда работает фоновое обслуживание, Store сканирует таблицу устаревших индексов для нахождения отображений, которым больше 40 дней (8 дней для систем с Exchange Server 5.5) и удаления всех просроченных отображений. Естественно, при каждом обращении к отображению счетчик времени жизни сбрасывается на ноль.

Следующей задачей является обслуживание «мертвых» объектов. Store обрабатывает список удаленных сообщений (т.е. сообщений, которые пользователи удалили из своих папок «Удаленные») и список «мертвых» объектов (каждое удаленное сообщение имеет свою «метку на удаление» с информацией для определения необходимости окончательного удаления). Метка на удаление особенно важен для реплицируемых папок, таких как общие папки, поскольку Store использует список удаленных сообщений для репликации некоего замороженного состояние общих папок. После того, как содержимое успешно реплицировано, Store очищает ссылки в списке меток на удаление во время фонового обслуживания.

Когда пользователь удаляет сообщение, Store устанавливает особый флаг для скрытия этого сообщения в почтовом ящике (т.е. Store выполняет мягкое удаление). Пользователь может восстановить сообщение из кэша Удаленных элементов, очистив значение флага удаленного сообщения. Во время фонового обслуживания Store проверяет флаг удаленния в каждом сообщении, находящемся в кэше Удаленных элементов, для определения сообщений с истекшим периодом хранения. Если такое сообщение находится, то Store удаляет его навсегда (т.е. Store выполняет жесткое удаление). Период хранения можно установить на почтовый ящик, на хранилище, общую папку. Управлять этими настройками можно с помощью серверных политик, устанавливаемых через ESM. Рисунок 2 показывает ограничения, установленные на общие папки. В данном случае период хранения удаленных элементов равен 7 дням. Например, это можно использовать для поддержки содержимого форума службы Network News Transfer Protocol (NNTP) в определенных объемах и требуется систематически удалять устаревшие сообщения. С течением времени надо следить за тем, насколько сильно папка растет в объеме, чтобы определить критерий для удаления устаревших сообщений. Также происходит процесс для удаленных сообщений в обычных общих папках - Store проверяет сообщения, у которых истек срок хранения и удаляет их.

Следующей проверкой является поиск удаленных общих папок, срок хранения которых истек. По умолчанию, если удаляется общая папка, Store создает могильную плиту для папки, предоставляя механизму репликаций время на распространение информации об удалении на все серверы с помощью замороженного состояния копий папок. Поскольку полные репликации могут быстро не выполняться в некоторых случаях, Store назначает срок для метки на удаление 180 дней по умолчанию. Если репликация не распространила метки на удаление в течение 180 дней, это означает, что в вашей организации серьезные проблемы и несколько ложных меток на удаление могут привести к новым проблемам. Во время фонового обслуживания Store проверяет срок жизни меток на удаление для папок и удаляет максимум 500 устаревших элементов за 24-х часовой период. Store также проверяет удаленные почтовые ящики, для которых по умолчанию установлен срок жизни в 30 дней, и удаляет все просроченные. Удаление устаревших папок и почтовых ящиков очищает структуру таблиц внутренних баз данных и увеличивает эффективность.

Репликация общих папок является тяжелой задачей для Exchange. Очень легко возникают конфликты общих папок. Например, несколько пользователей могут изменить один и тот же элемент в разных копиях общих папок или несколько пользователей не смогут одновременно записать один и тот же элемент в одной копии папки. Когда конфликт возникает, Store отправляет сообщение пользователям о возникновении проблемы с запросом ее разрешить. Store может обслуживать разные версии сообщения. Если пользователь не ответит на запрос, Store проверит каждую версию во время фонового обслуживания и сам разрешит проблему, обычно принимая за правильную версию более свежее сообщение. Можно программным путем управлять процессом разрешения конфликтов, используя свойство Messaging API (MAPI) PR_RESOLVE_METHOD на папке. Большинство администраторов оставляет эту задачу серверу Exchange, но можно создать и собственную форму, помогающую разрешить конфликтную ситуацию. Детальней об этом можно посмотреть на странице Microsoft "Resolving Message Conflicts with Forms" по адресу http://msdn.microsoft.com/library/default.asp?url=/library/en-us/exchserv/html/forms_3goj.asp.

Следующей задачей является обновление на серверах версий папок в хранилищах общих папок. Этот процесс обновляет информацию о версиях, необходимую для обслуживания системных папок с конфигурацией. Это не сложная задача и этим процессом невозможно управлять. Фоновая обработка также проверяет, чтобы не было дублирования папок, существующих в хранилищах административной группы, и удаляет дубликаты, если их находит.

Задача по защите папок, указанная в Таблице 1 применима только к общим папкам, у которых домашним сервером является сервер в узле Exchange 5.5. После перевода организации Exchange Server 2003 или Exchange 2000 Server в однородный режим, необходимость этой задачи отпадает.

Store использует модель хранения с одним экземпляром. Это позволяет хранить одну копию содержимого сообщения и использовать указатели в почтовых ящиках на это содержимое. Store отслеживает количество почтовых ящиков, которые имеют ссылку на содержимое, и физически удаляет информацию только когда этот счетчик становится равным нулю. Фоновое обслуживание проверяет сообщения на равенство счетчика ссылок нулю и может удалять до 50 000 таких сообщений в день. Store не отчитывается о том, сколько элементов было удалено, но рост количества файлов транзакций может показывать активность подобного рода. Если Store будет создавать нетипично много файлов транзакций в период с полуночи до 6 утра, то это является поводом для проверки хранилища почтовых ящиков утилитой Isinteg.

Оперативная дефрагментация

Администраторы Exchange обычно для освобождения дискового пространства выполняют автономную дефрагментацию с использованием утилиты Eseutil, которая перестраивает базу данных Exchange страницу за страницей. Для этого надо иметь как минимум 120 процентов от размера базы данных свободного места для записи временных файлов во время выполнения процедуры, поскольку это особенность такого типа дефрагментации. Если это необходимо, то для временных файлов можно указать другой диск, имеющий достаточно много свободного места. Можно запустить Eseutil и на компьютере, на котором не установлен Exchange, перенеся туда необходимые программные файлы и базы данных (детальней об этом в статье Microsoft "XADM: How to Run Eseutil on a Computer Without Exchange Server" по адресу http://support.microsoft.com/?kbid=244525). Пользователи во время такого процесса дефрагментации не смогут работать со своими почтовыми ящиками.

Store выполняет оперативную дефрагментацию по ночам для каждой базы данных на сервере Exchange, перемещая внутри базы страницы так, чтобы связанные страницы размещались рядом, а пустое пространство (т.е. незанятые страницы) собиралось в конце базы данных. Процесс обращается к ядру ESE для проверки таблиц и попытки уменьшить количество страниц, занимаемых каждой таблицей. Например, если таблица сообщений использует 100 страниц, которые наполовину пусты, процесс дефрагментации уменьшит таблицу примерно на 50 страниц. Оперативная дефрагментация не возвращает дисковое пространство файловой системе и не уменьшает размер баз данных. Хоть базы данных и сохраняют свой физический размер, оперативная дефрагментация вносит свой вклад в повышение производительности, поскольку Store уменьшает количество занятых страниц и при этом уменьшается количество и продолжительность операций вводавывода при доступе к информации.

В младших версиях оперативной дефрагментации процесс был не таким эффективным, и администраторам рекомендовалось пересоздавать базы данных с помощью утилит, чтобы предотвратить рост размеров баз. В Exchange 5.5 и старших версиях процесс оперативной дефрагментации более эффективный, не требующий обязательного выполнения автономной дефрагментации (т.е. пересоздания баз), кроме тех случаев, когда требуется освободить свободное место на дисках. Отметим, что ночные оперативные дефрагментации не влияют на потоковый файл хранилища (.stm), поскольку Exchange не перестраивает внутреннюю структуру этого файла.

После оперативной дефрагментации Store отчитывается об освободившемся незанятом пространстве в журнале Application событием с ID 1221 (database has nnn megabytes of free space after online defragmentation has terminated), как показано на Рисунке 3. На рисунке Store отчитывается в том, что освобождено 1672 Мбайт. Это примерно 12 процентов от базы данных размером 14 Гбайт, что является типичным процентным отношением незанятого пространства для сервера почтовых ящиков Exchange 2003. Это пространство можно освободить для файловой системы, запустив с помощью Eseutil автономную дефрагментацию.

Можно проверять событие с ID 700 (Information Store: Online defragmentation is beginning a full pass on) и событие с ID 701 (Information Store: Online defragmentation has completed a full pass on) для определения как долго на сервере выполняется оперативная дефрагментация. Обработка 14 Гбайт хранилища почтовых ящиков на четырехпроцессорном 900 МГц сервере с 1 Гбайт памяти выполняется примерно 4.25 часа, т.е. примерно 3.25 Гбайт в час. Время может варьироваться в зависимости от скорости процессора, скорости операций вводавывода и загрузки системы, включая загрузку от других операций, таких как очистка кэша Удаленных, дефрагментации других баз и создания новой копии Offline Address Book (OAB).

Настройки системного реестра

Exchange не был бы Exchange, если бы не имел набора настроек в системном реестре, который может значительно повлиять на его работу. Следует отметить, что с фоновым обслуживанием лучше не экспериментировать. Менять значения параметров реестра, относящиеся к фоновому обслуживанию можно только в том случае, если в этом есть реальная необходимость.

Все соответствующие параметры реестра имеют тип REG_DWORD. Они перечислены в Таблице 2, где PS означает раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystem, M означает подуровень для хранилища почтовых ящиков, P означает подуровень для общих папок. В младшей версии Exchange 2000, Microsoft размещал все основные параметры для хранилища в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystem, но поскольку Exchange 2003 и Exchange 2000 поддерживают хранилище по разному, появились новые подуровни реестра для каждого хранилища на сервере. Рисунок 4 показывает иерархию реестра и настройки хранилища, относящиеся к общим папкам на сервере Exchange 2003.

Проверка фонового обслуживания

Как и для других операций Exchange, можно установить уровень диагностики, определяющий для Store объем информации, заносимой в журнал системных событий Applications. Установить необходимый уровень журналирования можно в ESM, открыв диалоговое окно свойств сервера и перейдя на закладку Diagnostic Logging (показано на Рисунке 5). Для установки достаточного уровня информации о фоновом обслуживании, надо для параметра Background Cleanup для объектов MSExchangeIS Public Folder и Mailbox изменить уровень с None на Minimum, Medium или Maximum. Лучше установить уровень Maximum для фонового обслуживания. Это не вызовет большого потока лишних сообщений о событиях (так, как это могло бы произойти для параметра репликации общих папок) и в то же время позволит получать полную информацию о выполненных операциях. После того, как вы поймете разницу в проводимых операциях, можно будет уменьшить уровень диагностики до значения Minimum.

После применения новых настроек, Store начнет создавать сообщения о событиях при следующей операции фонового обслуживания. Таблица 3 показывает список событий, которые можно будет увидеть в системном журнале. Исключая очень большие или загруженные серверы, большинство операций выполняется быстро: за исключением операции фоновой дефрагментации. Эта «тяжелая» операция может длиться несколько часов, в зависимости от общей нагрузки, производительности сервера и объема обрабатываемой информации.

Exchange использует замысловатую технологию по работе с базами данных, чтобы обеспечить пользователям богатую функциональность. В результате этого Store обрабатывает данные без наведения порядка во время рабочего процесса. Большинство функций Store работает автоматически и не требует вмешательство администраторов, но понимание того, что происходит в фоновом режиме, будет полезным в любом случае.

Таблица 1: Фоновые задачи по обслуживанию

Таблица 2: Параметры системного реестра для управления задачами фонового обслуживания

¹ - HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystem

² - HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeIS Private-

³ - HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeIS Public-

Таблица 3: События операций фонового обслуживания