Фоновое обслуживание серверов 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 выполняет фоновые задачи по обслуживанию между полуночью и пятью часами утра по местному времени. Можно установить специальное расписание для каждого сервера, открыв 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 дней по умолчанию. Во время фонового обслуживания 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 в режим «Native», необходимость в этой задаче отпадает.

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_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem, M - подуровень для хранилища почтовых ящиков, а P - подуровень для общих папок. В младшей версии Exchange 2000 все основные параметры для хранилища размещались в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem, но поскольку 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_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
² - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ \Private-
³ - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ \Public-

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