Поделиться через

Новые возможности ядра хранилища Exchange

  • Статья

 

Применимо к: Exchange Server 2010 SP2

Последнее изменение раздела: 2016-11-28

В Microsoft Exchange Server 2010 реализовано много усовершенствований архитектуры базы данных Exchange.

  • Было улучшено ведение отчетов для общих папок.

  • Базы данных больше не сопоставляются с группами хранения. Группы хранения были удалены.

  • Инвестиции в оптимизацию схемы хранилища и расширенного обработчика хранилищ (ESE) позволили снизить количество операций ввода-вывода в секунду на 70 процентов.

В следующих разделах данные улучшения рассмотрены более подробно.

Содержание

Расширенное ведение отчетов для общих папок

Управление базой данных

Изменения хранилища

Новые функции расширенного обработчика хранилищ

Расширенное ведение отчетов для общих папок

Ведение отчетов для общих папок было улучшено посредством добавления возможности просмотра инициированных пользователем изменений любого элемента в общей папке. Эти сведения можно просмотреть с помощью командлета Get-PublicFolderStatistics в командной консоли Exchange. Дополнительные сведения см. в разделе Использование PowerShell с Exchange 2010 (командная консоль Exchange).

Управление базой данных

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

В Exchange 2010 базами данных почтовых ящиков и общих папок можно управлять в узле Конфигурация организации консоли управления Exchange. (В Exchange Server 2007 управление базами данных осуществлялось в узле Конфигурация сервера.)

Хотя функция управления базами данных общих папок была перенесена вместе с базами данных почтовых ящиков с узла Конфигурация сервера на узел Конфигурация организации, функциональные возможности баз данных общих папок в Exchange 2010 остались прежними. Как и в Exchange 2007, нельзя создавать копии баз данных общих папок и добавлять базы данных общих папок в группу обеспечения доступности баз данных. Однако базы данных общих папок можно размещать на серверах почтовых ящиков, являющихся частью группы обеспечения доступности баз данных, хотя при этом на базы данных общих папок не распространяются функции группы обеспечения доступности баз данных, включая доставку журналов.

Изменения командлетов баз данных

В связи с удалением групп хранения в Exchange 2010 использованные в Exchange 2007 командлеты групп хранения были удалены, а их функции теперь выполняют командлеты баз данных Exchange 2010, как показано в следующих таблицах.

Командлеты баз данных в Exchange 2010, заменяющие командлеты групп хранения Exchange 2007

Командлет Exchange 2007 Описание изменения функциональных возможностей в Exchange 2010

New-StorageGroup

Данный командлет был удален, а параметры конфигурации были перемещены в командлеты New-MailboxDatabase и New-PublicFolderDatabase.

Remove-StorageGroup

Данный командлет был удален, а параметры конфигурации были перемещены в командлеты Remove-MailboxDatabase и Remove-PublicFolderDatabase.

Set-StorageGroup

Данный командлет был удален, а параметры конфигурации были перемещены в командлеты Set-MailboxDatabase и Set-PublicFolderDatabase.

Get-StorageGroup

Данный командлет был удален, а параметры конфигурации были перемещены в командлеты Get-MailboxDatabase и Get-PublicFolderDatabase.

Move-StorageGroupPath

Данный командлет был удален, а параметры конфигурации были перемещены в командлет Move-DatabasePath.

Командлеты баз данных в Exchange 2010, имеющие расширенные функциональные возможности по сравнению с командлетами Exchange 2007

Командлет Exchange 2010 Описание расширения функциональных возможностей в Exchange 2010

New-MailboxDatabase

New-PublicFolderDatabase

Эти командлеты были дополнены параметрами и функциональными возможностями командлета New-StorageGroup. Они также обновляют объект сервера с использованием ссылки на новую базу данных и объект базы данных с использованием имени сервера размещения.

Remove-MailboxDatabase

Remove-PublicFolderDatabase

Эти командлеты были дополнены параметрами и функциональными возможностями командлета Remove-StorageGroup. Кроме того, они обновляют объект сервера с использованием ссылки на новую базу данных и объект базы данных с использованием имени сервера размещения.

Set-MailboxDatabase

Set-PublicFolderDatabase

Эти командлеты были дополнены параметрами и функциональными возможностями командлета Set-StorageGroup. При изменении несущих серверов они также обновляют объект сервера с использованием ссылки на новую базу данных и объект базы данных с использованием имени сервера размещения.

Get-MailboxDatabase

Get-PublicFolderDatabase

Эти командлеты были дополнены параметрами и функциональными возможностями командлета Get-StorageGroup. Функции параметра Status расширены для возвращения сведений о состоянии, возвращенных командлетом Get-StorageGroupCopyStatus.

Move-DatabasePath

Этот командлет был дополнен параметрами и функциональными возможностями командлета Move-StorageGroupPath.

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

Изменения хранилища

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

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

  • Карантин незаконных почтовых ящиков

  • Остановка транспорта для баз данных с менее чем 1 ГБ свободного места

  • Определение времени ожидания потока и ведение отчетов

Дополнительные сведения об устойчивости и работоспособности хранилища см. в разделе Общие сведения о хранилище Exchange 2010.

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

Новые функции расширенного обработчика хранилищ

Расширенный обработчик хранилищ (ESE) в Exchange 2010 был улучшен для достижения следующих целей:

  • Увеличение размера операций ввода-вывода и последовательный ввод-вывод для уменьшения количества операций ввода-вывода в секунду.

  • Оптимизация хранилища общих ресурсов.

  • Сокращение объема операций управления базами данных.

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

  • Проверка баз данных при оперативном обслуживании.

Увеличение размера операций ввода-вывода и последовательный ввод-вывод

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

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

Дефрагментация сбалансированного дерева

Процесс дефрагментации сбалансированного дерева был улучшен: число операций ввода-вывода было уменьшено посредством обеспечения последовательности данных в сбалансированном дереве.

Дефрагментация сбалансированного дерева выполняется на месте (в противоположность созданию нового сбалансированного дерева и переименованию индексов и таблиц) с использованием трех новых операций:

  • Перемещение страницы   Перемещение страницы состоит из перемещения всех данных с одной страницы на новую выделенную страницу.

  • Частичное левое слияние   Частичное левое слияние похоже на правое слияние в Exchange 2007 и более ранних версий, за исключением того, что данные перемещаются с левой страницы на правую страницу.

  • Полное левое слияние   Полное левое слияние имеет то же назначение, что и полное правое слияние в Exchange 2007 и более ранних версий.

В целях оптимизации производительности правые слияния для дефрагментации были заменены на левые слияния. Данные записываются на жесткий диск или считываются с него справа налево. Если дефрагментация базы данных выполняется в том же направлении, что и операции чтения/записи, возникает конфликт дефрагментации и операций чтения/записи. Кроме того, функция выделения дискового пространства допускает выделение следующей страницы в области памяти, но не предыдущей страницы. Поскольку для перемещения страницы требуется выделение новой страницы, гораздо более эффективна дефрагментация базы данных слева направо.

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

Увеличение размера страницы до 32 КБ

Все данные базы данных хранятся в сбалансированных деревьях, которые делятся на страницы. Размер страницы — это минимальный размер операции чтения или записи для базы данных, он также является единицей изменения при кэшировании базы данных. Чтение с диска осуществляется медленнее, чем выполняются операции в памяти, поэтому с помощью увеличения размера страницы до 32 КБ расширенный обработчик хранилищ снижает количество операций ввода-вывода в секунду, что повышает производительность благодаря кэшированию страниц увеличенного размера в памяти.

Оптимизация хранилища общих ресурсов

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

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

Увеличение среднего размера операций ввода-вывода базы данных посредством слияния ввода-вывода предоставляет следующие преимущества:

  • Повышение эффективности использования дисков   Диски обеспечивают более эффективную обработку крупных операций ввода-вывода. Чем более эффективно используется диск, тем больше почтовых ящиков можно на нем разместить.

  • Ускорение подготовки кэша   Подготовка кэша — это процесс, который помогает сократить время выполнения с помощью предварительной загрузки начальных запросов, выполненных для базы данных при ее прошлом запуске. После перезапуска, отработки отказа или переключения сервера более крупный размер операций ввода-вывода позволяет расширенному обработчику хранилищ увеличить скорость подготовки кэша.

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

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

Облуживание базы данных делится на следующие задачи:

  • Обслуживание почтового ящика хранилища.

  • Обслуживание базы данных расширенного обработчика хранилищ.

В Exchange 2007 обслуживание базы данных расширенного обработчика хранилищ требовало интенсивного использования диска. В Exchange 2010 были внесены изменения, направленные на повышение производительности. В Exchange 2010 на крупных серверах с высокой загрузкой задача обслуживания почтового ящика хранилища занимает около 45 минут, а обслуживание базы данных расширенного обработчика хранилищ обычно занимает от шести до восьми часов, что позволяет за ночь выполнить данную операцию для крупных баз данных Exchange 2007 (с квотами 2 ГБ).

В Exchange 2010 были внесены улучшения, направленные на обеспечение поддержки как крупных почтовых ящиков, так и хранилища JBOD и хранилища без использования RAID.

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

Дефрагментация базы данных

Дефрагментация делает внутренние страницы базы данных Exchange непрерывными. Дефрагментация может запускаться системой автоматически, когда база данных находится в оперативном режиме (оперативная дефрагментация), или вручную администратором, когда база данных переведена в автономный режим (автономная дефрагментация).

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

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

Размер свободного пространства в базе данных можно приблизительно определить по объему почты, отправленной и полученной пользователями, почтовые ящики которых расположены в этой базе данных. Например, если в базе данных имеется 100 почтовых ящиков размером по 2 ГБ каждый (всего 200 ГБ), пользователи которых ежедневно отправляют и получают в среднем 10 МБ почты, приблизительный размер свободного пространства составляет 1 ГБ (100 почтовых ящиков × 10 МБ на почтовый ящик). Размер фрагментированного пространства может превысить это значение, если не удалось выполнить полный цикл фонового обслуживания базы данных.

Настройка каких-либо параметров для данного компонента не требуется. Exchange отслеживает базу данных во время ее использования, со временем внося небольшие изменения, чтобы поддерживать базу данных в дефрагментированном состоянии для освобождения места и обеспечения непрерывности данных. Если база данных осуществляет анализ диапазона страниц и обнаруживает отсутствие у них правильной последовательности, она запускает асинхронный поток для дефрагментации данной области сбалансированного дерева/таблицы. Оперативная дефрагментация осуществляется под контролем и поэтому не оказывает негативного влияния на производительность клиентов.

Используйте набор счетчиков производительности расширенного обработчика хранилищ «MSExchange Database ==> Задачи дефрагментации» для просмотра выполняемых задач. Дополнительные сведения см. на странице Включение расширенных счетчиков производительности ESE.

Автономная дефрагментация

Автономная дефрагментация — это процесс, осуществляемый вручную администратором после перевода базы данных в отключенное состояние. Во время этой процедуры используется средство ESEUTIL, которое считывает файл базы данных и записывает новый файл базы данных, упорядочивая его содержимое. Автономная дефрагментация не приводит к копированию фрагментированного пространства из исходной базы данных, поэтому размер нового файла базы данных на диске меньше, чем размер исходной базы данных (возможно, намного меньше в зависимости от объема фрагментированного пространства в базе данных). Исторически так сложилось, что типичные причины для выполнения автономной дефрагментации базы данных состоят в следующем:

  • Уменьшение размера файла базы данных на диске.

  • Устранение фрагментированного пространства в базе данных.

  • Обеспечение наличия свободного места на диске.

  • Исправление поврежденной базы данных (второй шаг в процессе восстановления вслед за ESEUTIL /p).

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

  • Это приводит к простою, так как базу данных необходимо перевести в автономный режим.

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

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

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

Проверка баз данных при оперативном обслуживании

Кроме того, была изменена проверка баз данных при оперативном обслуживании (также называется проверкой контрольных сумм баз данных). В Exchange 2007 с пакетом обновления 1 (SP1) можно было использовать половину времени интерактивной дефрагментации для данного процесса проверки базы данных (Exchange выполняет чтение каждой страницы из базы данных за определенное время для обнаружения повреждений).

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

  • Выполнение последней задачи в запланированной процедуре обслуживания баз данных почтовых ящиков. Можно настроить продолжительность ее выполнения, изменив расписание обслуживания баз данных почтовых ящиков. Данный вариант отлично подходит для небольших баз данных, имеющих размер менее 1 терабайта (ТБ), на проверку которых нужно меньше времени.

  • Круглосуточное выполнение в фоновом режиме 24 x 7, используется по умолчанию. Этот вариант подходит для всех случаев, но рекомендуется для больших баз данных (1–2 ТБ). Exchange проверяет базу данных не чаще раза в день. Данная операция ввода-вывода полностью последовательна (поэтому легко обрабатывается диском), и на большинстве систем скорость проверки контрольных сумм осуществляется со скоростью около 5 мегабайт (МБ)/с.

Дополнительные сведения о настройке обслуживания баз данных см. в разделе Обслуживание баз данных почтовых ящиков.

 © Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены.