Обслуживание баз данных в Exchange 2010 SP1

Основой Microsoft Exchange Server являются базы данных, хотя это не так очевидно, как для приложений типа Microsoft SQL Server. Базы данных требуют постоянного внимания для поддержания нужного уровня производительности. .

Необходимость в обслуживании

Некоторые специалисты утверждают, что правильно спроектированное приложение для работы с базами данных должно быть самообслуживаемым. Однако эта цель пока еще не достигнута в реальных приложениях, в том числе в Exchange. Обслуживание необходимо для оптимизации внутренних структур баз данных, удаления устаревших данных и применения политик управления. Большая часть этой работы производится в фоновом режиме, как часть непрерывного обслуживания, осуществляемого процессом Exchange Information Store, а помощник для управляемых папок Managed Folder Assistant отвечает за применение правил политик сохранения (retention policies) к почтовым ящикам, которые подпадают под действие этих политик.

В Exchange 2010 реализована новая схема базы данных, это первая полная переработка внутренней структуры после выхода Exchange Server 4.0 в 1996 году. Предыдущие модификации, например увеличение размера страницы с 4 до 8 Кбайт в Exchange Server 2007, помогли Exchange справиться с запросами к современным почтовым системам, но не могли стать основой для системы, в которой даже в корпоративной среде нормой вскоре будут почтовые ящики размером 10 Гбайт. Новая схема, реализованная в Exchange 2010, использует набор внутренних таблиц, принадлежащих отдельным почтовым ящикам, а не относящихся ко всей базе данных в целом. Это изменение не выглядит значительным, но оно позволяет процессу Store более эффективно извлекать данные в ответ на запросы пользователей, особенно в современных средах, в которых на одном сервере хранится несколько тысяч почтовых ящиков. Другие изменения, такие как увеличение размера страницы до 32 Кбайт и отсрочка обновления представлений до запроса элементов пользователем, меняют структуру ввода-вывода с огромного количества небольших произвольных операций ввода-вывода на малое количество крупных последовательных операций. Существенно, что Exchange 2010 обрабатывает больше данных значительными порциями, а не мелкими кусочками. В Microsoft иногда называют использование мелких произвольных операций ввода-вывода nickel and diming, что дословно означает «монеты по 5 и 10 центов», а перевести можно как «разорение на мелких монетах».

Этот подход обусловлен возрастанием среднего размера сообщения с 4 Кбайт в 1996 году до более 100 Кбайт сегодня и отсюда значительным снижением количества выполняемых операций ввода-вывода в секунду (IOPS) на один почтовый ящик. Что касается производительности в целом, то ваши результаты будут сильно зависеть от многих параметров среды, особенно от используемого оборудования для системы хранения и от размещения различных файлов (операционная система, Exchange, базы данных, журналы транзакций), но в целом можно утверждать, что компании, внедрившие Exchange 2010 в производственной среде, получат значительное снижение операций ввода-вывода по сравнению с Exchange 2007 и гигантское снижение по сравнению с Exchange Server 2003. Рекламные публикации Microsoft по Exchange 2010 говорят о снижении количества операций ввода-вывода на 70% при переходе с Exchange 2003 на Exchange 2007 и примерно таком же улучшении после изменений, сделанных в Exchange 2010. Все эти цифры не нужно принимать за чистую монету, пока вы не проверите показатели производительности на своих производственных серверах. Но нет никакого сомнения, что улучшение будет. Вопрос в том, насколько лучше будет работать Exchange 2010 на оборудовании, выбранном вами для его развертывания.

Работа в режиме 24×7

Exchange всегда обладал возможностью фонового обслуживания баз данных. Отличие Exchange 2010 в том, что работа механизма Extensible Storage Engine (ESE), или обслуживание структур баз данных, выполняется по умолчанию в режиме 24 часа 7 дней в неделю, а не в заданном временном окне, как это было в предыдущих версиях (при необходимости вы могли задать в Exchange нужное именно вам временное окно). Недостаток использования временного окна заключается в том, что его могло не хватить для выполнения всей работы. И эта проблема росла с увеличением базы данных, так что приходилось увеличивать это окно в надежде, что удастся успеть выполнить всю работу.

Операции по обслуживанию очень важны для баз данных Exchange, так как они выполняют следующие действия:

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

Exchange 2010 выполняет все эти операции по обслуживанию, но теперь сканирование ESE может осуществляться непрерывно в режиме 24×7, если только вы не отключите фоновое обслуживание базы данных путем изменения ее свойств, как показано на экране 1.

Экран 1. Установка параметров обслуживания базы данных почтовых ящиков

Если для базы данных разрешено сканирование ESE в режиме 24×7, процесс Store непрерывно вычисляет контрольные суммы страниц, гарантируя, что целостность базы данных постоянно проверятся. Это очень важно, так как Exchange 2010 также предоставляет возможность исправлять отдельные проблемные страницы внутри группы доступности баз данных database availability group (DAG). Если процесс Store обнаруживает проблемную страницу (для которой не выполняется проверка контрольной суммы), он может отправить серверам, хранящим другие копии этой базы данных, запрос на предоставление корректной копии страницы. После получения корректной копии Store может исправить базу данных и восстановить ее целостность. Автоматическое обнаружение и исправление проблемных страниц — значительное преимущество использования серверов почтовых ящиков в группе DAG, так как это избавляет администраторов от классической ошибки с кодом 1018 (нарушение целостности страницы).

Сканирование ESE в режиме 24×7 — не единственный вид постоянно выполняемого обслуживания. Exchange 2010 выполняет дефрагментацию в режиме онлайн для оптимизации внутренней структуры, элементы удаляются из базы данных непосредственно сразу после истечения срока хранения, не дожидаясь наступления очередного окна обслуживания, а удаленные страницы сразу же возвращаются в повторное использование для хранения новых элементов. И наконец, процесс Store анализирует состояние непрерывности базы данных после выполнения транзакций и при необходимости запускает фоновый поток для перемещения данных между страницами, чтобы Exchange мог загружать большие непрерывные порции данных, вместо выискивания и извлечения из разных частей базы данных всех страниц, необходимых для выполнения транзакции.

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

Для выполнения обработки, например перемещения страниц, необходимой для обслуживания в режиме 24×7, требуются некоторые дополнительные циклы процессора и подсистемы ввода-вывода. Однако это не должно быть проблемой для большинства современных многоядерных серверов, особенно если операции ввода-вывода осуществляются не самим сервером.

Обслуживание по требованию

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

Логические ошибки проявляются в таких проблемах, как неверное количество элементов в папке или неправильное их представление, которое не включает все нужные элементы. Логические ошибки часто возникают в результате сбоев на стороне клиента, когда клиент при обработке элементов в папке некорректно обновляет флаги MAPI. Такие проблемы обычно терпимы в том смысле, что вы можете нормально работать, даже если в папке или почтовом ящике есть ошибки. Некоторые пользователи вообще не замечают таких ошибок. Ведь если Outlook выдает информацию, что в папке имеется 1119 элементов, будет ли у кого-нибудь время сосчитать все элементы и убедиться, что Outlook верно отобразил их количество, предоставленное ему сервером Exchange?

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

В предыдущих версиях Exchange обслуживание по требованию осуществлялось с помощью двух утилит командной строки, входящих в набор инструментов Exchange. ISINTEG (Information Store Integrity, утилита поддержания целостности хранилища информации) исправляла логические ошибки, ESEUTIL (или даже EDBUTIL, если вы помните такое давнее название) боролась с проблемами на физическом уровне, в недрах базы данных. Эти утилиты — напоминание о тех днях, когда было допустимо отключить базы данных на несколько часов для выполнения обслуживания. По этой причине утилиты были проклятием для администраторов. Принимая во внимание размеры нынешних почтовых баз данных, их обработка может длиться много часов, а это ставит под угрозу возможность соответствия соглашениям об уровне обслуживания (SLA) и другим эксплуатационным требованиям.

Новый подход к исправлению логических ошибок

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

В Exchange 2010 SP1 специалисты Microsoft вместо утилиты ISINTEG предложили новый набор команд для исправления баз данных почтовых ящиков и общих папок, с помощью которых администраторы могут создавать запросы на восстановление, способные устранить большинство причин сбоев в представлениях и отображении количества элементов. Это следующие виды повреждений:

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

Данные команды восстановления используют примерно такую же модель, как и запросы на перемещение, импорт и экспорт почтовых ящиков в Exchange 2010, где администратор создает запрос на восстановление, который помещается в очередь для обработки процессом Store, а тот в свою очередь асинхронно в режиме онлайн исполняет запрошенные восстановительные действия для баз данных. У пользователя нет необходимости завершать сеанс работы со своим почтовым ящиком в то время, пока Store проверяет и исправляет внутреннюю структуру почтового ящика. В Exchange 2010 SP1 отсутствуют какие-либо средства графического интерфейса для выполнения запросов на восстановление в консоли управления Exchange Management Console (EMC) или панели управления Exchange Control Panel (ECP), все действия должны выполняться с помощью команд консоли Exchange Management Shell (EMS). Вы также не сможете выполнять запросы на восстановление почтовых ящиков или общих папок на предыдущих версиях серверов Exchange, так как данная возможность зависит от обновлений схемы Active Directory, внесенных установкой Exchange 2010 SP1.

Команда New-MailboxRepairRequest создает запрос на восстановление почтового ящика, а команда New-PublicFolder DatabaseRepairRequest — запрос на восстановление базы данных общих папок. Например, следующая команда создает запрос для проверки корректности представления папки:

New-MailboxRepairRequest -Mailbox
   'Redmond, Tony' -CorruptionType
   FolderView

Если вы добавите к запросу параметр -DetectOnly, Exchange сообщит обо всех найденных повреждениях, но не будет их устранять. Существуют и другие типы повреждений почтовых ящиков, которые могут быть исправлены: SearchFolder, AggregateCounts и ProvisionedFolder. Они служат для исправления повреждений папок поиска, количества элементов в папках и подготовленных папок (provisioned folders).

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

New-MailboxRepairRequest -Mailbox
   'Redmond, Tony' -CorruptionType
   FolderView, SearchFolder

Параметр Archive определяет, нужно ли процессу Store сканировать личный архив почтового ящика. Если параметр отсутствует, то архив не обрабатывается, то есть для исправления архива нужна несколько модифицированная команда:

New-MailboxRepairRequest -Mailbox
   'Redmond, Tony' -CorruptionType
   FolderView, SearchFolder –Archive

Вы также можете одновременно просканировать все почтовые ящики в базе данных, чтобы исправить все найденные в них повреждения. Например:

New-MailboxRepairRequest -Database
   'ViP Mailboxes' -CorruptionType
   FolderView, SearchFolder,
   AggregateCounts

Для баз данных общих папок сегодня можно выполнить только один вид исправлений. Это исправление списка реплик, которое делается следующим образом:

New-PublicFolderDatabaseRepairRequest
   -Identity ‘PFDatabase1’-CorruptionType
   ReplicaList

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

Экран 2. Запрос на восстановление почтового ящика

Единственное место, в котором отображается процесс восстановления, — это журнал приложений, где регистрируется событие с идентификатором 10047, когда инициируется запрос на восстановление почтового ящика (или событие с идентификатором 10059 при получении запроса на восстановление всей базы данных) и событие с идентификатором 10048, когда процесс восстановления успешно завершается и в почтовом ящике не остается никаких повреждений. Эти события регистрируются на сервере, который обрабатывает запрос. Если обнаруживается повреждение, Exchange регистрирует событие с идентификатором 10062 с описанием найденного повреждения и результатом выполненных действий. Заметим, что процессу Store может потребоваться выполнить несколько восстановительных действий, прежде чем он ликвидирует все проблемы в почтовом ящике, поэтому необходимо продолжать выполнять запросы, пока не будет зарегистрировано событие с идентификатором 10048, подтверждающее восстановление почтового ящика.

Чтобы не оказывать сильного влияния на производительность системы, вы можете выполнить только один запрос на восстановление всей базы данных. Однако на сервере можно выполнять одновременно до 100 запросов на восстановление отдельных почтовых ящиков (распределенных по нескольким базам данных).

Если база данных имеет копии внутри группы DAG, то результаты любых действий по решению проблем, обнаруженных в таблицах почтового ящика, реплицируются вместе с остальными транзакциями на все копии базы данных, а события в журнале приложений регистрируются на том сервере, на котором осуществлялось исправление. То же самое происходит и при исправлениях баз данных общих папок, за исключением того, что исправление осуществляется в одной базе данных общих папок, а результаты реплицируются с помощью механизма репликации общих папок.

Вы не можете отменить задание на восстановление или просмотреть его текущий статус. Возможно, такая функциональность будет добавлена корпорацией Microsoft в каком-либо будущем выпуске. На сегодня единственный способ прервать процесс восстановления — размонтировать базу данных или переместить ее на другой сервер. Такие действия удаляют все задания на восстановление, активные для этой базы данных.

Миф о ESEUTIL

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

Было время, когда применение ESEUTIL к базе данных являлось единственным средством освободить пространство в подсистеме хранения и решить ее внутренние проблемы. Эти времена прошли в начале нынешнего десятилетия, когда Microsoft наконец нашла решение, как можно с помощью фонового обслуживания эффективно возвращать в повторное использование удаленные страницы. Однако многие из нынешних администраторов застряли в том далеком времени!

До сих пор еще остаются веские основания для запуска ESEUTIL, но не постоянно и уж точно не для освобождения дискового пространства. Вам может потребоваться использовать ESEUTIL для приведения в согласованное состояние резервной копии базы данных, прежде чем ее можно будет смонтировать в качестве базы данных для восстановления, или вы можете получить рекомендацию службы поддержки Microsoft Customer Service and Support (CSS) использовать ESEUTIL для ликвидации низкоуровневых проблем в базе данных, которые не могут быть исправлены командами восстановления. В этом случае почти наверняка произойдет потеря данных, так как ESEUTIL просто удаляет те страницы, которые не может исправить.

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

Кроме перечисленных мной случаев я не могу представить какое-либо разумное основание, зачем мне может потребоваться размонтировать базу данных и лишить на несколько часов пользователей доступа к ней для запуска ESEUTIL, чтобы достичь некоего малозаметного улучшения в базе данных, и то не наверняка. В производственной среде это точно не имеет никакого смысла.

Обслуживание баз данных — это часть жизни администраторов Exchange. Львиная доля этой работы автоматизирована и выполняется в фоновом режиме, но иногда должны производиться некие действия по требованию для решения проблем, возникающих на логическом или физическом уровне. Новые команды восстановления, реализованные в Exchange 2010 SP1, — долгожданное улучшение, так как они позволяют избавляться от логических повреждений по требованию без прекращения доступа к базам данных. Однако мы всем еще продолжаем держаться за утилиту ESEUTIL, которая наверняка должна стать следующей в списке Microsoft для модернизации и обновления.

Тони Редмонд (exchguru@windowsitpro.com) — редактор журнала Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services