Пример проектирования роли сервера почтовых ящиков Exchange 2010

 

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

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

В этом разделе приведен пример, в котором показан способ определения необходимых требований к объему памяти, емкости, системе ввода-вывода и производительности ЦП для роли сервера почтовых ящиков и ее архитектуры.

Можно использовать калькулятор требований для роли сервера почтовых ящиков Exchange Server 2010, чтобы определить необходимые требования для роли сервера почтовых ящиков с учетом ряда факторов. Калькулятор позволяет определить требования, описанные в этом примере. Получить дополнительные сведения о калькуляторе (а также загрузить его) можно в статье блога команды разработчиков сервера ExchangeExchange 2010 Mailbox Server Role Requirements Calculator (на английском языке).

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

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

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

• Одна группа доступности баз данных включает в себя шесть серверов почтовых ящиков

• На сервере почтовых ящиков Exchange также размещены роли транспортного сервера-концентратора и сервера клиентского доступа

• Три копии базы данных почтовых ящиков высокой доступности (неизолированные)

• Использование дисков SATA объемом 1 терабайт (7200 об/мин)

• Конфигурация хранилища JBOD (1 логический номер устройства (LUN) и архитектура LUN базы данных)

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

• Восстановление LUN развертывается для выполнения операций обслуживания и восстановления

• Каждый LUN имеет по крайней мере 20 процентов свободного места

• Решение должно быть способно перенести двойной сбой сервера

• Необходимо установить только роль сервера почтовых ящиков

Содержание

Требования к емкости почтового ящика

Требования к копии базы данных

Требования к объему памяти для почтового ящика

Требования к системе ввода-вывода почтового ящика

Требования к производительности ЦП для почтового ящика

Требования к емкости почтового ящика

В следующем примере показан способ определения необходимой емкости хранилища для среды, в которой 24 000 почтовых ящиков размером 2 ГБ каждый, способных обрабатывать до 100 сообщений в день, распределены между шестью серверами почтовых ящиков, входящими в одну группу доступности баз данных, база данных каждого из которых имеет три копии. Эти почтовые ящики принимают в среднем 37 МБ почты за пятидневную рабочую неделю, а средний размер сообщения составляет 75 КБ. Для восстановления отдельного элемента включено окно хранения удаленного элемента в течение 14 дней. Следующие вычисления используются для определения размера почтового ящика:

Размер почтового ящика = ограничение почтового ящика + свободное пространство + корзина

Свободное пространство = 100 сообщений в день x 75/1024 МБ = 7,32 МБ

Корзина = (100 сообщений в день x 75/1024 МБ * 14 дней) + (2048 МБ x 0,012) + (2048 МБ x 0.03) = 188,6 МБ

Примеры значений для определения фактического размера почтового ящика на диске

Квота почтового ящика	Размер корзины (2 недели)	Свободное пространство	Общий размер на диске
2 ГБ	188,7 МБ	7,3 МБ	2,19 ГБ (+12%)

Поскольку в этой среде используется хранилище JBOD, максимальный размер развертываемой базы данных зависит от размера диска. Чтобы определить максимальный размер базы данных в случае использования хранилища JBOD, используйте следующую формулу, в которой емкость диска размером 1 ТБ после форматирования равна 931 ГБ, процент необходимого свободного места равен 20 %, а процент индекса содержимого равен 10 %:

Максимальный размер базы данных = [емкость форматированного диска x (1 – процент необходимого свободного места)] / (1 + процент индекса содержимого)

= [931 ГБ x (1 - 0,2)] / ( 1+ 0,10)

= 744,8 ГБ / 1,1

= 677 ГБ

В этой среде почтовый ящик каждого пользователя будет использовать 2,25 ГБ дискового пространства. Для поддержки 24 000 почтовых ящиков при размере базы данных, равном 667 ГБ, требуется наличие 102 баз данных. Поэтому одна база данных должна содержать 235 почтовых ящиков.

Тем не менее, так как в этом решении используется архитектура хранилища JBOD, необходимо убедиться, что количество почтовых ящиков в одной базе данных не превышает количество случайных операций ввода-вывода, которые можно выполнить на одном диске. Так как в этом решении используются диски SATA больших размеров (7200 об/мин), диск позволяет выполнять не более 55 случайных операций ввода-вывода в секунду (IOPS) при полной нагрузке. А так как коэффициент роста буфера при выполнении операций ввода-вывода равен 20 процентам, диск может обрабатывать до 44 случайных операций ввода-вывода в секунду.

При способности обрабатывать до 100 сообщений в день для одного пользователя каждый почтовый ящик может обрабатывать 0,1 операции ввода-вывода в секунду, поэтому диск может поддерживать до 440 почтовых ящиков при таком профиле IOPS. Так как определенное при расчете емкости максимальное число поддерживаемых почтовых ящиков, равное 235, меньше 440 почтовых ящиков, которые можно использовать для профиля IOPS, это решение можно развернуть на одном диске.

Чтобы определить фактический размер базы данных, используйте следующую формулу:

Размер базы данных = количество почтовых ящиков x размер почтового ящика на диске x коэффициент роста буфера базы данных

С учетом такого количества и фактического размера почтовых ящиков, а также коэффициента роста буфера базы данных, равного 20 процентам, размер базы данных составляет 619 ГБ, как показано в следующей таблице.

Требования к емкости базы данных

Количество почтовых ящиков в базе данных	Общее количество баз данных	Требования к размеру базы данных
235	102	619 ГБ

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

Почтовый ящик, обрабатывающий 100 сообщений в день, создает в среднем 20 журналов транзакций в день, поэтому в среде, содержащей 24 000 почтовых ящиков, может быть создано 576 000 журналов транзакций в день. Это значит, что каждая база данных будет создавать 5647 журналов в день. Один процент почтовых ящиков перемещается еженедельно в один день (субботу). В этом решении используются функции собственной системы защиты данных Exchange, поэтому резервное копирование не выполняется и расчет размера производится с учетом возможности работы в течение трех дней без усечения журналов.

Как показано в следующей таблице, этому серверу требуется 23 ГБ места на диске для каждой копии базы данных.

Требования к емкости журналов

Количество журналов в базе данных	Размер файла журнала	Размер ежедневно создаваемых журналов	Размер перемещаемых почтовых ящиков и баз данных	Устойчивость к ошибкам усечения	Требования к размеру журналов
5647	1 МБ	5,65 ГБ	6 ГБ (240 × 2,19 ГБ х 1,2 / 102)	16,5 ГБ (3 × 5,65 ГБ)	23 ГБ (16,5 ГБ + 6 ГБ)

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

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

= (размер базы данных + размер журнала транзакций + размер индекса содержимого) ÷ (1 - 0.2)

= (619 ГБ + 23 ГБ + 61,9 ГБ) / 0,8

= 879 ГБ

Определение требуемого размера LUN

Размер базы данных	Размер журнала транзакций	Размер индекса содержимого	Размер LUN базы данных
619 ГБ	23 ГБ	61,9 ГБ	879 ГБ

В начало

Требования к копии базы данных

Так как для поддержки 24 000 почтовых ящиков требуется 102 база данных, а каждая база данных имеет три копии, группа доступности баз данных будет поддерживать до 306 баз данных. 306 баз данных распределяются между шестью серверами почтовых ящиков, поэтому каждый сервер почтовых ящиков может размещать 51 копию баз данных. Необходимо распределить копии баз данных между серверами в группе доступности базы данных так, чтобы при ошибках сервера активные базы данных могли выполнить переход на как можно большее число доступных серверов (копии баз данных распределяются несимметрично).

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

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

При сбое двух серверов почтовых ящиков 34 копии баз данных будут распределены между оставшимися серверами почтовых ящиков, что увеличит количество активных копий баз данных на сервер до 26. Это и будет количеством активных копий баз данных, используемым для расчета требований к объему памяти и производительности ЦП для сервера почтовых ящиков.

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

В начало

Требования к объему памяти для почтового ящика

При использовании профиля почтового ящика, обрабатывающего до 100 сообщений в день, минимальным объемом памяти для одного почтового ящика, необходимым для поддержки кэша базы данных, будет 6 МБ. При увеличении количества активных копий баз данных почтовых ящиков на сервер до 26 каждый сервер сможет размещать до 6110 почтовых ящиков Live. Также один сервер может размещать до 51 базы данных. Сервер почтовых ящиков требует минимальный размер кэша базы данных, равный 12 ГБ. Поэтому объем памяти, необходимой для поддержки кэша базы данных, равен:

Обязательный минимальный размер кэша базы данных = МАКС((количество почтовых ящиков Live x необходимый объем памяти для почтового ящика), минимальный объем памяти для баз данных)

= МАКС(6110 x 6/1024 ГБ, 12 ГБ)

= МАКС(36 ГБ, 12 ГБ)

= 36 ГБ

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

В начало

Требования к системе ввода-вывода почтового ящика

Каждый почтовый ящик отправляет или получает 100 сообщений в день. Поэтому каждый почтовый ящик имеет значение профиля IOPS, равное 0,1. Каждая база данных содержит 235 почтовых ящиков. Поэтому общее количество операций ввода-вывода для тома базы данных равно:

Количество операций ввода-вывода для тома базы данных = количество почтовых ящиков x профиль IOPS x (1 + коэффициент роста буфера системы ввода-вывода)

= 235 x 0,1 x 1,2

= 28,2 операций ввода-вывода в секунду

Коэффициент профиля операций ввода-вывода для чтения базы данных для этой архитектуры равен 60 процентам. Поэтому каждый том базы данных создает 16,92 операций ввода-вывода в секунду для чтения операций ввода-вывода и 11,28 операций ввода-вывода в секунду для записи операций ввода-вывода.

В этой архитектуре каждый поток журнала создает 50 процентов операций ввода-вывода для записи базы данных. Поэтому количество операций ввода-вывода для записи журнала для одного тома равно 5,64 операций ввода-вывода в секунду.

26 активных копий баз данных также создают число операций ввода-вывода для чтения журнала, равное 10 процентам от количества операций ввода-вывода для записи журнала; поэтому количество операций ввода-вывода для чтения журнала для этих копий баз данных равно 0,56 операций ввода-вывода в секунду.

Так как каждый диск SATA больших размеров (7200 об/мин) позволяет создавать 55 случайных операций ввода-вывода в секунду, не имеет значения, что такой диск не удовлетворяет требованиям к системе ввода-вывода для базы данных.

В начало

Требования к производительности ЦП для почтового ящика

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

Определение требований к мегациклу процессора

Требования к мегациклу процессора для активных почтовых ящиков	Требования к мегациклу процессора для пассивных почтовых ящиков	Общие требования к мегациклу процессора
14,682	1,765	16,447

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

В начало

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