При планировании вместимости для баз данных почтовых ящиков 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 процента. Для данных регистрации версии календаря (включена по умолчанию) размер почтового ящика дополнительно увеличивается на 5,8 процента.

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

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

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

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

• Пример проектирования роли сервера почтовых ящиков Exchange 2010
  
  
• Общие сведения об элементах для восстановления
  
  
• Управление элементами для восстановления
  
  
• Общие сведения о восстановлении календаря
  
  
• Управление восстановлением календаря
  
  

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

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

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

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

В начало

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

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

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

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

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

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

В начало

Выбор размера 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 МБ.