Exchange Server 2013: Планирование размера базы

Часто задают вопрос о том, как определить размер будущей базы почтовых ящиков  и соответственно принять правильное решение при покупке дисков или дисковой системы под Exchange Server 2013. Подобные гадания на кофейной гуще называются capacity planning  или sizing. В рамках данной заметки я постараюсь перевести на великий и могучий язык последние рекомендации по расчетам от производителя, касающиеся Exchange Server 2013.

 

1. Размер почтового ящика.

Начинается все именно с размера ящика.  Для начала нужно определиться с профилем ваших почтовых ящиков. Профиль это типовые показатели использования почтового ящика (как правило размер, тип клиента, способ подключения, объем корреспонденции). В нашем случае необходимо понять сколько писем в день получает и отправляет среднестатистический пользователь. Посчитать это можно как используя утилиту Exchange Profile Analyzer (EPA). так и счетчики производительности MSExchangeIS\Messages Submitted/sec и  MSExchangeIS\Messages Delivered/sec, либо скрипты.

 

Понятно, что использовать утилиту или скрипты можно если у вас уже есть почтовая система, если же система внедряется с 0, то профиль будет определяться “на глаз”.

 

Для определение актуального размера ящика необходимо учесть три фактора:

 

  • Квота на размер почтового ящика
  • Свободное место базы данных (Whitespace)
  • Размер удаленных элементов

 

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

Свободное место базы данных (есть такой термин — Whitespace) это объем в файле баз данных, который уже занят на диске где хранится база, но еще не заполнен информацией. Т.е это место которое будет использоваться для будущего роста. При удалении почтовых сообщений и ящиков из базы данных освободившееся место пополняет Whitespace и используется для записи новых данных. Рекомендуется планировать свободное место базы данных как равное размеру почтовых сообщений наработанных за один день.

 

Если отталкиваться от того, что размер среднего сообщения в организации равен 75KB, а это для среднестатистической организации берется как стандарт и один пользователь получает\оправляет до 100 писем в день,  то получается, что приблизительный Whitespace на один почтовый ящик будет равен:

100 сообщений\день * 75 Kb = 7.5 MB

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

 

 

Рисунок 1. Корзина почтового ящика. (Уровень 1)

 

Рисунок 2. Корзина второго уровня (Recover Deleted items). (Уровень 2)

 

Рисунок 3. Корзина третьего уровня папка Purges,  (Singlle Item Recovery). (Уровень 3)

 

Так вот если Singlle Item Recovery включен, то при стандартном интервале в 14 дней ожидается увеличение размера ящика на 1.2 процента. Если включено логгирование версий событий календаря. то это еще 3 процентный рост. Если учесть что в конечном итоге количество нового контента будет примерно равно количеству удаленного контента, чтобы оставаться в пределах квоты, то можно ожидать, что размер корзины третьего уровня будет равен размеру отправленных и полученных сообщений за срок хранения в корзине, который по умолчанию равен 14 дням.

 

Recoverable Items Folder Size = (per-user daily message profile x average message size x deleted item retention window) + (mailbox quota size x 0.012) + (mailbox quota size x 0.03)

 

Если мы возьмем предполагаемые 200 сообщений в день и 75kb как средний размер сообщения,  а так же 14 дней хранения в Singlle Item Recovery и 10Gb квоты на ящик, то ожидаемый размер корзины третьего уровня составит:

 

(200 messages/day x 75KB x 14 days) + (10GB x 0.012) + (10GB x 0.03)

= 210,000KB + 125,819.12K + 314,572.8KB = 635.16MB

Собрав все данные воедино, мы можем посчитать размер почтового ящика на диске, для этого возьмем квоту, добавим свободное место и то, что будет занято при включении Singlle Item Recovery:

 

Mailbox Size on disk = 10GB mailbox quota + 14.65MB database whitespace + 635.16MB Recoverable Items Folder = 10.63GB

2. Индексация содержимого базы.

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

Per-Database Content Indexing Space = database size x 0.20

В добавок вы должны учесть еще один дополнительный индекс (20% от объема одной из баз на разделе) чтобы позволить индексирующим задачам выполниться штатно.

Per-Volume Content Indexing Space =

(average database size x (databases on the volume + 1) x 0.20 )

Получается что место под индекс считается так: вы берете средний размер базы, количество баз данных увеличенное на одну и умножаете на 20%.

100GB database size x (2 databases + 1) x 0.20 = 60GB

Следую формуле, если у вас на диске две базы по 100Gb, то около 60Gb вам понадобится под хранение и обеспечение работы индексов.

3. Место под транзакционные логи.

Довольно много места требует под транзакционные логи, создаваемые при работе базы данных Exchange Server. Размер одного  транзакционного лога составляет 1 мегабайт и прежде чем оценивать требуемое место на диске, давайте рассчитаем сколько логов генерируется за день под один почтовый ящик. Для этого есть готовая таблица:

 

Рисунок 4. Количество логов генерируемых за день одним пользователем, в зависимости от профиля пользователя.

 

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

 

Transaction logs at 200 messages/day with 150KB average message size = 40 logs/day (at 75KB average message size) x 1.9 = 76

Transaction logs at 200 messages/day with 300KB average message size = 40 logs/day (at 75KB average message size) x (1.9 x 2) = 152

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

 

Log Capacity to Support 3 Days of Truncation Failure = (65 mailboxes/database x 40 logs/day x 1MB log size) x 3 days = 7.62GB

 

А если при этом порядка одного процента ящиков будет перемещено, то уже по другой формуле мы дополнительных логов:

 

Log Capacity to Support 1% mailbox moves per week = 65 mailboxes/database x 0.01 x 10.63GB mailbox size = 6.91GB

 

Итого суммарное количество логов сгенерированных за 3 дня получится:

Total Local Capacity Required per Database = 7.62GB + 6.91GB = 14.53GB

Естественно полученные размеры транзакционных логов нужно учитывать при покупке дисков.

4. Собираем все показатели вместе для расчета итоговых цифр

Самый просто способ выбрать размер хранилища без использования калькуляторов это оттолкнуться от данных о серверах и хранилищах, которые будут использоваться. В рамка продуктовой группы используются 2U сервера с 12 дисками. Это позволяет собрать RAID из двух дисков под операционную систему, установить Exchange и транспортные базы, а оставшиеся 10 дисков объединить в JBOD без каких либо RAID массивов. Если это заполнить 4 ТБ SATA или SAS дисками, то получается большое хранилище, которое довольно легко расширяется через подключения дополнительных полок.

 

Используя примеры больших развертывания и думая о том как  посчитать размер на производственном сервере, мы можем рассмотреть масштабирование сервера  имеющего 24  диска SAS по 4 ТБ. Два диска  уходят по операционную систему и файлы Exchange, оставшиеся диски будут использованы под хранение баз данных почтовых ящиков. 12 дисков мы возьмем под хранение баз данных, а оставшиеся 10 дисков будут пустые. В рамках расчетов предположим, что на один диск мы будем класть по 4 базы. Каждый диск в отформатированном состоянии будет иметь размер

3725GB.  Выясним количество почтовых ящиков на базу данных отталкиваясь от среднего размера ящика, контентных индексов, и требования к свободному месту. (не менее 5%).

Берем формулу:

Available Space (excluding required free space) = Formatted capacity of the drive x (1 – free space)

 

Available Space это полезное место диска, то которое на выходе можно будет занять базой. Free space — пространство, которое мы хотим оставить пустым (занимать 100% дискового пространства — очень плохая идея). В Exchange 2013 снизили рекомендацию свободного пространства с 20% до 5% (потому что уж очень большие диски теперь выпускают, 20% от 4TB было бы 800GB — это слишком много пространства, чтобы держать свободным). То есть, Available Space = 95% пространства, доступного на диске/томе после его форматирования.

 

Далее мы можем вычесть из полученного место требуемое для индекса контента. Как говорилось ранее это 20% от размера каждой  базы плюс 20% размера одной базы для задач обслуживания. Специальный коэффициент позволяющий узнать сколько места уйдет под контентный индекс считается по формуле:

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

 

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

 

В случае с цифрами все будет выглядеть так:

   

Ну и финишной чертой считаем максимальное количество ящиков, которые можно поместить в одну базу, а для этого максимальный размер базы делим на размер ящика, учитывая и свободное место и Singlle Item Recovery

 

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

 

P.S Курсы по Exchange Server 2010/2013, которые читаю я, можно найти здесь.

P.S2 Если вы не хотите сами напрягать мозг, но Exchange внедрять надо, то вам сюда

Источник: itband.ru

Категория: Электронная почта

Похожие статьи: