Экспорт (0) Печать
Развернуть все
правки на данРазделы снуюРазделы с тему
Loading
Ресурсы не найдены.
Статьи в блогах на данную тему
Loading
Ресурсы не найдены.
Обсуждения в форумах на данную тему
Развернуть Свернуть

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

Exchange 2010
 

Последнее изменение раздела: 2012-02-24

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

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

Например, если имеются 5000 пользователей на сервере с квотой почтового ящика 250 МБ, потребуется не менее 1,25 ТБ дискового пространства, не считая места для элементов для восстановления. Если для квот хранилища почтовых ящиков не задано предельное значение, будет трудно оценить вместимость базы данных. Квоты хранилища почтовых ящиков для Exchange 2010 должны включать в себя место для основного почтового ящика и почтового ящика личного архива (когда они используются). Дополнительные сведения см. в разделах Управление серверами почтовых ящиков и Управление личным архивом.

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

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

В начало

У каждой базы данных есть корзина, в которой хранятся удаленные элементы, которые можно восстановить. По умолчанию удаленные элементы с возможностью восстановления хранятся на сервере Exchange 2010 в течение 14 дней, а элементы календаря — 120 дней.

Кроме того, Exchange 2010 также позволяет предотвратить очистку данных до окончания периода хранения удаленных элементов. Эта возможность называется восстановлением отдельного элемента. Восстановление отдельных элементов по умолчанию отключено. Если же восстановление отдельного элемента включено, в течение периода 14-дневного хранения удаленных элементов размер почтового ящика увеличивается на 1,2 процента. Для данных регистрации версии календаря размер почтового ящика дополнительно увеличивается на 3 процента. Регистрация данных о версии календаря включена по умолчанию.

Формула для определения необходимого для корзины места на диске в течение периода 14-дневного хранения удаленных элементов при включенных восстановлении отдельного элемента и регистрации версии календаря имеет вид:

Размер корзины = (ежедневная входящая/исходящая почта x средний размер сообщения x период хранения удаленных элементов) + (размер квоты почтовых ящиков x 0,012) + (размер квоты почтовых ящиков x 0,03)

Например, если размер почтового ящика равен 2 ГБ, для включения восстановления отдельного элемента на период 14-дневного хранения удаленных элементов дополнительно требуется 25 МБ места, а для включения регистрации версии календаря — дополнительно 61 МБ.

Дополнительные сведения приведены в следующих разделах:

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

Дополнительные сведения по определению размера базы данных с почтовыми ящиками размером 2 ГБ без использования личного архива см. в подразделе «Требования к емкости почтового ящика» раздела Пример проектирования роли сервера почтовых ящиков Exchange 2010.

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

Во время индексирования содержимого создается индекс или каталог, позволяющий пользователям быстро и просто находить письма без необходимости искать их вручную. Сервер Exchange 2010 создает индекс размером примерно в 10 % от общего размера базы данных, который размещается на устройстве с тем же логическим номером устройства (LUN), что и база данных. Поэтому необходимо дополнительно прибавить 10 % к объему LUN базы данных для индексирования содержимого.

В начало

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

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

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

Именно размер базы данных в конечном итоге определяет количество развертываемых в каждой базе данных почтовых ящиков и количество развертываемых баз данных. Размер развертываемой базы данных зависит от нескольких факторов.

  • Соглашения об уровне обслуживания при резервном копировании/восстановлении   Размер базы данных однозначно определяет скорость резервного копирования и восстановления данных за разумное время.

  • Архитектура высокой доступности   Если планируется использовать несколько копий баз данных, можно задать для баз данных размер 2 ТБ, поскольку копии становятся первым уровнем защиты при выполнении операций восстановления.

  • Архитектура хранилища   Если планируется выполнять развертывание на хранилище, состоящее просто из нескольких жестких дисков (на одном диске размещаются как база данных, так и ее журналы транзакций), то размер используемого диска определяет максимальный размер базы данных. Например, на диске размером 1 ТБ (емкость после форматирования — около 917 ГБ) необходимо также выделить место для журналов транзакций и индекса контента и убедиться, что занято не все свободное место.

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

В начало

Файлы журнала транзакций — это журнал всех транзакций, выполненных ядром базы данных. Все транзакции сначала записываются в журнал, а затем постепенно записываются в базу данных. В отличие от Exchange Server 2003 размер файлов журнала транзакций в Exchange 2010 уменьшен с 5 МБ до 1 МБ. Это сделано для поддержки функции непрерывной репликации и для минимизации потери данных в случае отказа основного хранилища.

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

Значение Количество ежедневно создаваемых журналов транзакций зависит от выбранного профиля сообщений и среднего размера сообщения. Оно показывает, сколько журналов транзакций будет создаваться для каждого почтового ящика в день. В количестве создаваемых журналов на профиль учитывается:

  • Влияние размера сообщения.

  • Объем отправленных и принятых данных.

  • Операции обеспечения работоспособности базы данных.

  • Операции управления записями.

  • Хранящиеся в почтовом ящике данные, которые не являются сообщением (задачи, встречи в локальном календаре, контакты)

  • Принудительный переход на новый файл журнала (механизм, который периодически закрывает файл текущего журнала транзакций)

Количество создаваемых журналов транзакций для каждого профиля почтового ящика

 

Профиль сообщения (средний размер сообщения — 75 КБ) Количество ежедневно создаваемых журналов транзакций

50

10

100

20

150

30

200

40

250

50

300

60

350

70

400

80

450

90

500

100

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

  • Если средний размер сообщения удваивается до 150 КБ, количество журналов, создаваемых для одного почтового ящика, увеличивается в 1,9 раза. Это число представляет собой часть базы данных (в процентах), которая содержит вложения и таблицы сообщений (текст сообщений и вложения).

  • Впоследствии, когда размер сообщения становится в два раза больше 150 КБ, скорость создания журналов также удваивается — с 1,9 до 3,8.

Например, при числе сообщений в день, равном 100, и:

  • среднем размере сообщения 150 КБ число создаваемых журналов на один почтовый ящик: 20 × 1,9 = 38.

  • среднем размере сообщения 300 КБ число создаваемых журналов на один почтовый ящик: 20 × 3,8 = 76.

В следующих разделах рассматриваются факторы, влияющие на объем свободного места для журналов:

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

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

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

Хотя исходный сервер заносит в журнал удаление записей, что не занимает много места, сервер назначения должен сначала записать все перемещенные данные в журналы транзакций. Если ежедневно создаются файлы журналов размером 10 ГБ и поддерживается трехдневный буфер в 30 ГБ, перемещение пятидесяти почтовых ящиков размером 2 ГБ (всего 100 ГБ) полностью заполнит LUN целевого журнала и приведет к простою. В таких случаях необходимо выделить дополнительное пространство для LUN журнала для размещения перемещенных почтовых ящиков.

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

Влияние высокой доступности на требования к свободному месту для журналов делится на три вида:

  • Число копий базы данных   Необходимое для журналов свободное место в рамках всей системы увеличивается в зависимости от числа копий базы данных при развертывании с высокой доступностью. Если имеется три копии базы данных, разнесенных по трем серверам, необходимо обеспечить свободное место для журналов каждой копии на каждом сервере.

  • Механизм усечения журналов   Высокая доступность в Exchange 2010 с возможностью использования до 16 копий каждой базы данных почтовых ящиков обеспечивает базу для применения циклического ведения журнала непрерывной репликации в качестве механизма усечения и удаления журналов в противоположность выполнению полного или добавочного резервного копирования для усечения или удаления старых журналов. Дополнительные сведения см. в подразделе «Усечение журналов без резервных копий» разделов Общие сведения об архивации, восстановлении и аварийном восстановлении и Высокая доступность и устойчивость сайтов.

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

    Когда для копи базы данных включена задержка преобразования, требования к свободному месту для журналов изменяются соответствующим образом. Если настроена 14-дневная задержка, необходимо обеспечить место для журналов за 17 дней. Дополнительное место для журналов требуется только для копии базы данных, для которой настроена задержка; для других копий этой базы данных, работающих без задержки, действуют обычные требования к свободному месту для журналов (не учитывающие задержку).

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

Требования к объему для LUN основаны на размере набора данных (база данных, журналы транзакций, индекса контента и место для восстановления) и включают в себя некоторый дополнительный объем свободного места. Большинство программ по управлению операциями имеют пороговые значения объема, которые выдают предупреждения при использовании LUN более чем на 80 %.

Подходящий размер LUN можно определить по следующей формуле:

Объем LUN = размер данных / (1 - процент необходимого свободного места)

Например, если требование к размеру данных равно 3000 МБ, а требование к свободному месту равно 20 %, то LUN, обеспечивающий размещение этих данных, должен иметь размер 3750 МБ.

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

  • Дисковое пространство на LUN для журнала транзакций. Настройте несколько пороговых значений и различные механизмы предупреждений. Например, если известно базовое значение заполнения журнала можно задать пороговое значение для оповещения о 20-процентном превышении базового значения.

  • Успешное создание резервных копий (если не используется собственная защита данных Exchange).

  • Усечение событий в журнале приложений.

  • Работоспособность репликации копии базы данных.

Чтобы устранить неполадки, связанные с необъяснимым ростом журналов транзакций, ознакомьтесь с разделом Управление ростом журнала базы данных с помощью сценария Troubleshoot-DatabaseSpace.ps1 в консоли.

 © Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены.
Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Показ:
© 2014 Microsoft