Microsoft Exchange 2010 – самый распространенный и популярный продукт для обмена корпоративными сообщениями в среде Windows. Довольно часто у наших заказчиков встает вопрос в подборе необходимых конфигураций для почтовых серверов и систем хранения данных. В это статье я постараюсь рассказать про особенности, которые появились у продукта Microsoft Exchange 2010, какие требования необходимо учитывать при расчете спецификаций, и какие решения есть у HP.
В продукте Exchange 2010 появилось несколько особенностей, связанных с механизами репликации и отказоустойчивостью.
Exchange Server тесно интегрирован с Active Directory: большая часть пользовательских данных хранится в Active Directory (связь учётных записей пользователей и почтовых ящиков, списки контактов). Отдельно от Active Directory хранятся только сами почтовые ящики. Благодаря механизму репликации Active Directory в случае использования нескольких серверов Microsoft Exchange Server сохраняется актуальность данных на всех серверах.
Для реализации отказоустойчивости в Exchange 2010 предлагается единственная технология DAG, прежние технологии SCR,LCR,CCR и кластер с единым хранилищем изъяты. DAG (Database Availability Group) — технология асинхронной репликацей баз между узлами с защитой от потери данных. DAG не является кластерной технологией в чистом виде, т.к. нет виртуального общего узла. В связи с этим, точка подключения клиентов перенесена с роли Mailbox на роль Client Access. В DAG кластеризуется только база, которая может перемещаться между серверами включенными в DAG. Но служба кластеризации Windows все же используется, для определения кворума. DAG может работать только на блочных устройствах (локальные диски и SAN) и не может работать на сетевых дисках NAS.
Исходя из особенностей архитектуры Exchange 2010, а так же с появлением более производительного оборудования (в первую очередь это относится к процессорам) изменился подход к сайзингу архитектуры.
Корпорация Microsoft на своем сайте публикует серию документов, которые описывают роль каждого компонента решения. Разобраться во множестве статей – довольно нетривиальная задача. Далее приведены теоретические сайзинги.
Для продуктивной среды необходим процессор, который работает с 64-bit версией Exchange 2010 на ОС Windows Server 2008 или 2008 R2. Microsoft рекомендует использовать процессоры Intel, поддерживающие технологию Intel Extended Memory 64 Technology или процессоры AMD, поддерживающие AMD64.
Применение опции Hyperthreading требует тщательного планирования, а эффект от внедрения в среде Exchange обычно не значительный.
По умолчанию опция Hyperthreading должна быть выключена. Использование возможно только в виде временной меры для повышения производительности процессора, пока дополнительное оборудование не будет введено в эксплуатацию.
Ниже приведена таблица с минимальными и рекомендованными максимальными параметрами для Exchange 2010.
Рекомендованная Microsoft конфигурация — 8 процессорных ядер, для среды, где предполагается использовать несколько серверов и несколько тысяч почтовых ящиков. Сервер с большим числом ядер можно эффективно использовать когда роль Hub Transport сконфигурирована для работы с антивирусным и анти-спам ПО. Коэффициент нагрузки на процессоры зависит от таких показателей, как средний размер сообщения, число пересылаемых сообщений, число задействованных транспортных агентов, конфигурация антивируса и других приложений.
В Microsoft Exchange 2010 большинство клиентских функций было перемещено из роли Mailbox Server в роль Client Access Server. В среде Exchange 2010 сообщения обрабатываются на сервере Client Access server, если они отправлены не-MAPI клиентом (например, POP3 или IMAP4). Кроме того, рендеринг Microsoft Office Web App осуществляется ролью Client Access server, а не сервисом Microsoft Exchange Information Store, как в предыдущих версиях Exchange.
Эти архитектурные особенности позволяют Client Access server серьезно разгрузить Mailbox server и эффективно использовать 8 процессорных ядер. Для организаций с небольшим числом почтовых ящиков или с невысоким объемом трафика от не-MAPI клиентов рекомендуется использовать 2 ядра.
Корпорацией Microsoft рекомендуется конфигурация Unified Messaging Server с 8-ю процессорными ядрами. Такое количество ядер необходимо для работы голосовой почты, например, конвертации .wav формата в Windows Media Audio (WMA). Сервер с 2-мя ядрами может быть использован для организаций с небольшим числом почтовых ящиков или в среде с небольшой активностью роли Unified Server Messaging.
Microsoft рекомендует конфигурацию этой роли в зависимости от числа почтовых ящиков и профилей пользователей. 4 ядра процессора дают хороший баланс между производительностью и стоимостью, такое количество ядер способно обработать до нескольких тысяч почтовых ящиков. Оценка ресурсов требует понимания среднего профиля пользователя. Такой образ может быть получен, при использовании счетчиков transport performance. Также допускается использование сторонних утилит.
Выбор оперативной памяти определяется следующими значениями
Exchange 2010 на операционной системе Windows Server 2010 эффективно работает оперативной памятью объемом до 64 GB на сервер.
Таблица ниже показывает минимальные и максимальные значения на каждую роль.
Эти роли не требуют большого объема оперативной памяти, минимум 4GB достаточно для обработки всех запросов, оптимальное значение 1GB на ядро, но не менее 4 GB в сумме.
Потребление оперативной памяти в этой роли имеет практически линейную зависимость от числа клиентских подключений и количества транзикций. Основываясь на рекомендациях Microsoft — конфигурация роли с 2GB на ядро является сбалансированной.
Эта роль является довольно сложной в расчетах, т.к. оптимальные параметры оперативной памяти зависят от числа развернутых ролей, количества почтовых ящиков, от среднего профиля пользователя и количества активных баз данных.
Расчет памяти этой роли является критичным для уменьшения нагрузки ввода/ввывода на дисковую подсистему сервера.
В Exchange 2010 применяется механизм уменьшения нагрузки на дисковую подсистему сервера или хранилища данных, основанный на использовании кэша Extensible Storage Engine (ESE). Чем больше кэша доступно серверу Exchange 2010, тем меньше нагрузка I/O на дисковую подсистему.
Эффективность кэша в Microsoft Exchange 2010 была повышена в ходе нескольких технических изменений. Одно из самых значительных изменений — увеличение журнала проверки depth target. Этот журнал испльзуется для того, чтобы убедиться, что логи и кэш базы данных записываются в базу данных в разумных временных пределах. Размер журнала зависит от количества копий и типа базы данных:
С применением механизма Extensible Storage Engine нагрузка на ввод/ввыод для базы данных с двумя и более копиями может быть до 40% ниже, чем для конфигурации с одиночной базой данных. В ситуациях с высокой нагрузкой на дисковую подсистему база данных хранит файлы изменений в памяти продолжительное время, такое поведение снижает количество операций последовательной записи (repeated write) и создает эффект слияния (coalescing), т.н. гибридную модель хранения. Это позволяет быстрее восстанавливать базу данных в случае неисправности. В тоже время неактивные копии баз данных также используют память для хранения журнала (5MB), это позволяет быстро переводить неактивную базу данных в активный режим.
Объем кэша, а, соответственно, объем физической памяти напрямую зависит от количества баз данных и может быть вычислен по таблице:
В предыдущих версиях Echange ключевой метрикой был объем операций ввода/вывода, сейчас текущими метриками стали объем кэша баз данных и число сообщений, отправляемых пользователем в день.
Следующая таблица позволяет определить IOPS, исходя из объема ящика 2GB и среднего размера письма 75KB.
В Exchange 2010 один и тот же сервер может обрабатывать как активные копиии баз данных, так и неактивные, в конфигурации с отказоустойчивым решением. Требования к процессору для обработки неактивных копий также должны учитываться на этапе проектировки. Неактивные копии баз данных используют ресурсы процессора для проверки реплицированных логов и обработки индекса базы данных. Каждый ящик неактивной базы данных требует 15% ресурсов CPU от ресурсов почтового ящика активной базы данных.
Каждой базе данных Exchange 2010 можно создать до 16 копий. Каждая копия базы данных потребляет 10% CPU от основной базы данных.
Понимание количества копий и количества неактивных баз необходимо для возможности создания нескольких моделей поведения среды Exchange 2010 в зависимости от внешних условий (например, от количества вышедших из строя серверов или площадок). Типичными моделями для среды Exchange 2010 являются модель при 100% использовании всех почтовых ящиков и модель поведения в случае худшего сценария.
Шаги по планированию следующие:
Параметр мегациклов определяется производительностью ядра процессора в MHz, например, 2 x 4 core Intel Xeon x5470 3.33-gigahertz (GHz) дают по 3333 мегациклов на ядро.
Выбор системы хранения данных зависит от множества факторов, но в первую очередь определяется количеством почтовых ящиков и требованием к расширению.
Для небольших организаций с 1000 почтовых ящиков HP и Microsoft рекомендуют использовать iSCSI хранилища P2000G3 начального уровня или дисковую подсистему ProLiant.
Для больших инсталляций рекомендуются хранилища высокого уровня, поддерживающие большое количество дисков. Одним из таких массивов является 3PAR StoreServ, анонсированный 4-го декабря 2012 года. Этот массив уже прошел испытания по программе Exchange 2010 Solution Reviewed Program (ESRP) – Storage v3.0.
Как известно, массивы 3PAR предназначены для использования под задачи виртуализации в среде с непредсказуемыми нагрузками. Еще одно из возможных предназначений — корпоративная почта.
Совместно с корпорацией Microsoft был проведен тест массива 3PAR StoreServ для почты на 60000 пользователей. В решении использовались блейд-серверы HP Proliant Bl460c Gen8, блейд-корзины C7000, оптические коммутаторы Brocade.
ПО теста: Microsoft Windows Server 2008 R2 и Microsoft Exchange 2010.
Документ дает информацию о тестировании массива в среде на 60 000 пользователей.
Высокая эффективность организована благодаря применению технологии wide-striping (использовании всех дисков для построения отказоустойчивого RAID) на массиве 3PAR с использованием Database Availability Group (DAG), где каждую копию DAG обслуживают 18 серверов (9 активных серверов обслуживают 60 000 пользователей в 2 DAG). Высокая доступность данных может быть обеспечена благодаря организации репликации данных между двумя массивами 3PAR. В тестовом решении использовался один массив и 9 серверов.
В дисковом массиве 3PAR все используемые диски автоматически делятся на блоки размером в 1 GB (chunklet), блоки с одинаковыми типами дисков и одним уровнем RAID формируют логический диск. Common Provisioning Group (CPG) – набор политик, отвечающих за формирование RAID групп. CPG также отвечает за формирование виртуальных томов (LUN), которые презентуются хосту.
В описанном решении 3PAR сконфигурирован с одной CPG для всех хостов в обеих DAGs, содержащих активные базы данных. В случае выхода из строя диска, массив продожит обслуживание всех хостов, процессы перестроения RAID будут использовать блоки spare chunklets на всех оставшихся дисках.
На рис.1 показан процесс формирования логических дисков в массиве 3PAR.
В тестовой среде конфигурация содержит 18 серверов, подключенных к массиву 3PAR с 216 2TB NL SAS. Виртуальные тома презентованы хостам. Из этих виртуальных томов каждому серверу были предоставлены 12 томов под базы данных / логи и один том под восстановление / обслуживание.
В этом решении виртуальные тома были созданы на массиве 3PAR, что позволило легко увеличивать размер тома по мере роста баз данных. Активные и неактивные копии баз данных размещаются на разных массивах для обеспечения отказоустойчивости решения.
Все тома баз данных, тома обслуживания и восстановления были созданы с применением защиты RAID. Реальный размер баз данных и томов для каждого конкретного заказчика зависит от большого числа факторов, включающих Service Level Agreement (SLA), методологии бэкапа, факторы управления виртуальных томов и желаемый размер баз данных на диске.
На рис.2 показаны активный датацентр с разметкой томов и серверов.
На рисунке 3 показана схема полного решения с 18 серверами, в каждой группе DAG по 9 серверов. В случае потери связи или в случае отключения питания на удаленной площадке, 9 оставшихся серверов в состоянии обслужить все базы данных.
Схема презентованных баз данных каждому хосту:
В случае выхода из строя первичной площадки — оставшиеся серверы будут способны продолжить обработку запросов:
Рассмотрим примерный сценарий расчета для описанного решения.
Число почтовых ящиков: 60000
Профиль пользователя: 100 писем в день (0.14 IOPS на пользователя почтового ящика с запасом в 20%).
Профиль нагрузки: 0.12 x 60000 = 8400 IOPS на активные почтовые ящики.
Размер почтового ящика: 2GB.
Архитектура системы хранения данных: RAID 10.
DAGs: 2.
Серверы: 18 (9 серверов на каждую DAG).
Рассчитаем количество почтовых ящиков на сервер: 60000 / 18 = ~3300.
Количество почтовых ящиков на базу данных: 833.
Размер виртуального тома на системе хранения для каждой базы данных (LUN) Database + Log = 1740.88GB.
Система хранения данных обеспечивает сырую емкость не менее 418 608 GB.
Тип подключения к хранилищу: Fibre Channel SAN.
Скоость подключения к массиву: 12x 8Gb = 96Gb/s
Коммутаторы: 2x Brocade 8/24
Северная платформа: 18 серверов 2 x 8 core Intel Xeon E5-2650 2.0 GHz, 64 GB RAM.
Т.к. DAG должна работать в случае выхода из строя 9 серверов, то начинаем расчет с 18 нод. Предполагая, что все базы данных равнозначно распределяются по 18 узлам, получаем по 3300 почтовых ящиков на сервер. Рассчитываем показатель почтовых ящиков в случае выхода из строя 9 узлов (60 000 / 9) = ~6700 почтовых ящиков на сервер.
Рассчитываем количество мегациклов на почтовые ящики: 6700 x 2 (по таблице мегациклов на почтовый ящик) = 13400 мегациклов. Умножаем это значение на 10% для каждой копии. В этом примере на каждую активную копию приходится 2 неактивных, следовательно, число мегациклов возрастает на 20%: 13400 x 1.2 = 17700 мегациклов.
Умножаем число неактивных почтовых ящиков (когда сервер обрабатывает максимальное число ящиков) на показатель мегациклов на неактивный почтовый ящик из таблицы (3300 x 0.3 мегациклов = 990 мегациклов).
Складываем значения мегациклов для активных почтовых ящиков со значениями для неактивных почтовых ящиков: 17700 + 990 = 18690 мегациклов. Переводим эти значения на платформу.
2 восьмиядерных процессора Intel Xeon E5-2650 2.0 GHz соответствуют значению 16x 2000 = 32000 мегациклов. Считаем пиковую утилизацию сервера: 18690 / 32000 = 60%. Это значение показывает, что в момент пика обращений всех пользователей, в случае выхода из строя половины физических серверов, мы получим нагрузку 60% на процессор, этот показатель считается приемлимым. Рекомендуется рассчитывать параметы так, чтобы коэффициент загрузки процессора в пиковой ситуации не превышал 70%.
Рассчитаем необходимое количество ядер для активных почтовых ящиков.
Для отказоустойчивого решения:
Необходимое число ядер = (требуемая производительность CPU для активных ящиков) / (мегациклы на ядро) x (число оставшихся серверов) x (количество DAGs).
Для решения без отказоустойчивости:
Необходимое число ядер = (требуемая производительность CPU для активных ящиков) / (мегациклы на ядро) x (число серверов в датацентре)
Исходя из наших значений:
6700 / 2000 x 9 = 30 ядер
30 ядер из 144 (9 серверов по 16 ядер) обрабатывают активные почтовые ящики, в случае, когда 14 серверов вышли из строя.
Исходя из этого рассчитаем число ядер, необходимых для ролей Exchange (по рекомендациям Microsoft).
Ядра Hub Transport = необходимое число ядер / 5 = 30/5= 6.
Ядра для Client Access server = необходимое число ядер x 3 / 4 = 30 x 3 / 4 = 22.
Ядра Global catalog = необходимое число ядер / 8 = 30 / 8 = 4.
Аналогичным образом рассчитывается значение оперативной памяти.
Исходя из показателя 6700 почтовых ящиков на сервер, в случае выхода из строя второй площадки, и параметра 100 писем на почтовый ящик мы получает значение кэша ~40GB для роли Mailbox. Для остальных ролей на сервер оставляем ~40% RAM. Таким образом, сервер с 56GB RAM должен справиться с нагрузкой в 6700 почтовых ящиков. В нашем случае использовались тестовые сервера с большим запасом оперативной памяти (64GB RAM).
Исходя из рекомендованных значений Microsoft делается расчет IOPS (число почтовых ящиков умножаем на значение IOPS для активных и неактивных копий): 60000 x (0.12 + 2 x 0.1) = ~19200 IOPS. В текущей конфигурации массив обеспечивает производительность 21 363 IOPS 25read/75write согласно рекомендациям Microsoft по расчету кэша для систем хранения.
Продукт Microsoft Exchange 2010 остается самым популярным на сегодняшний день продуктом корпоративной почты. Совместно с Microsoft компания HP регулярно проводит тестирование своих продуктов и выкладывает показатели производительности.
Примером подобного тестирования является решение на массиве 3PAR StoreServ 7400 на 60000 пользователей.
Тест был запущен на 24 часа и показал способность массива 3PAR StoreServ справляться с длительными высокими нагрузками при работе с Microsoft Exchange. Базы данных и лог файлы были проанализированы после теста на возможные ошибки.
Отчет по тестированию решения:
1. Были ли зафиксированы какие-либо ошибки в журнале событий?
— Нет
2. Были ли зафиксированы какие-либо ошибки в лог файлах и базах данных в результате проверки контрольных сумм?
— Нет
Средние показатели производительности дисковой подсистмы на стороне хоста во время пиковых нагрузок:
Database I/O
Database Disk Transfers/sec 1921
Database Disk Reads/sec 1210
Database Disk Writes/sec 711
Average Database Disk Read Latency (ms) 19.79
Average Database Disk Write Latency (ms) 1.96
Transaction Log I/O
Log Disk Writes/sec 632
Average Log Disk Write Latency (ms) 0.58
При расчете необходимых конфигураций можно пользоваться как результатами уже тестированных решений HP ESRP, так и рекомендованными параметрами для каждых ролей на сайте Microsoft.
Литература:
1. Расчет массива на 140000 пользователей Exchange
2. Расчет массива на 60000 пользователей Exchange
3. Расчет массива на 1000 пользователей Exchange
4. Расчет на 1000 пользователей Exchange на дисковой подсистеме серверов ProLiant
5. Калькулятор ролей Microsoft
6. Performance and Scalability for Exchange Server 2010 SP1
Особенности архитектуры Exchange 2010
В продукте Exchange 2010 появилось несколько особенностей, связанных с механизами репликации и отказоустойчивостью.
Exchange Server тесно интегрирован с Active Directory: большая часть пользовательских данных хранится в Active Directory (связь учётных записей пользователей и почтовых ящиков, списки контактов). Отдельно от Active Directory хранятся только сами почтовые ящики. Благодаря механизму репликации Active Directory в случае использования нескольких серверов Microsoft Exchange Server сохраняется актуальность данных на всех серверах.
Для реализации отказоустойчивости в Exchange 2010 предлагается единственная технология DAG, прежние технологии SCR,LCR,CCR и кластер с единым хранилищем изъяты. DAG (Database Availability Group) — технология асинхронной репликацей баз между узлами с защитой от потери данных. DAG не является кластерной технологией в чистом виде, т.к. нет виртуального общего узла. В связи с этим, точка подключения клиентов перенесена с роли Mailbox на роль Client Access. В DAG кластеризуется только база, которая может перемещаться между серверами включенными в DAG. Но служба кластеризации Windows все же используется, для определения кворума. DAG может работать только на блочных устройствах (локальные диски и SAN) и не может работать на сетевых дисках NAS.
Исходя из особенностей архитектуры Exchange 2010, а так же с появлением более производительного оборудования (в первую очередь это относится к процессорам) изменился подход к сайзингу архитектуры.
Сайзеры Exchange 2010
Корпорация Microsoft на своем сайте публикует серию документов, которые описывают роль каждого компонента решения. Разобраться во множестве статей – довольно нетривиальная задача. Далее приведены теоретические сайзинги.
1. Выбор подходящего процессора
Для продуктивной среды необходим процессор, который работает с 64-bit версией Exchange 2010 на ОС Windows Server 2008 или 2008 R2. Microsoft рекомендует использовать процессоры Intel, поддерживающие технологию Intel Extended Memory 64 Technology или процессоры AMD, поддерживающие AMD64.
Hyperthreading
Применение опции Hyperthreading требует тщательного планирования, а эффект от внедрения в среде Exchange обычно не значительный.
По умолчанию опция Hyperthreading должна быть выключена. Использование возможно только в виде временной меры для повышения производительности процессора, пока дополнительное оборудование не будет введено в эксплуатацию.
Ниже приведена таблица с минимальными и рекомендованными максимальными параметрами для Exchange 2010.
| Роль сервера Exchange 2010 | Минимальная конфигурация |
(рекомендованная) максимальная конфигурация |
пример (рекомендованной) максимальной конфигурации |
| Edge Transport | 1x processor core | 2x processors | 12x processor cores |
| Hub Transport | 1x processor core> | 2x processors | 12x processor cores |
| Client Access | 2x processor cores | 2x processors | 12x processor cores |
| Unified Messaging | 2x processor cores | 2x processors | 12x processor cores |
| Mailbox | 2x processor cores | 2x processors | 12x processor cores |
| Client Access/ Hub Transport combined | 2x processor cores | 2x processors | 12x processor cores |
| Multiple (Client Access, Hub Transport, Mailbox roles) | 2x processor cores | 4x processors | 24x processor cores |
Роль Hub Transport
Рекомендованная Microsoft конфигурация — 8 процессорных ядер, для среды, где предполагается использовать несколько серверов и несколько тысяч почтовых ящиков. Сервер с большим числом ядер можно эффективно использовать когда роль Hub Transport сконфигурирована для работы с антивирусным и анти-спам ПО. Коэффициент нагрузки на процессоры зависит от таких показателей, как средний размер сообщения, число пересылаемых сообщений, число задействованных транспортных агентов, конфигурация антивируса и других приложений.
Роль Client Access Server
В Microsoft Exchange 2010 большинство клиентских функций было перемещено из роли Mailbox Server в роль Client Access Server. В среде Exchange 2010 сообщения обрабатываются на сервере Client Access server, если они отправлены не-MAPI клиентом (например, POP3 или IMAP4). Кроме того, рендеринг Microsoft Office Web App осуществляется ролью Client Access server, а не сервисом Microsoft Exchange Information Store, как в предыдущих версиях Exchange.
Эти архитектурные особенности позволяют Client Access server серьезно разгрузить Mailbox server и эффективно использовать 8 процессорных ядер. Для организаций с небольшим числом почтовых ящиков или с невысоким объемом трафика от не-MAPI клиентов рекомендуется использовать 2 ядра.
Unified Messaging Server role
Корпорацией Microsoft рекомендуется конфигурация Unified Messaging Server с 8-ю процессорными ядрами. Такое количество ядер необходимо для работы голосовой почты, например, конвертации .wav формата в Windows Media Audio (WMA). Сервер с 2-мя ядрами может быть использован для организаций с небольшим числом почтовых ящиков или в среде с небольшой активностью роли Unified Server Messaging.
Mailbox Server role
Microsoft рекомендует конфигурацию этой роли в зависимости от числа почтовых ящиков и профилей пользователей. 4 ядра процессора дают хороший баланс между производительностью и стоимостью, такое количество ядер способно обработать до нескольких тысяч почтовых ящиков. Оценка ресурсов требует понимания среднего профиля пользователя. Такой образ может быть получен, при использовании счетчиков transport performance. Также допускается использование сторонних утилит.
2. Выбор оперативной памяти
Выбор оперативной памяти определяется следующими значениями
- Скорость оперативной памяти
- Объем модуля памяти / стоимость модуля памяти
- Число слотов в сервере.
Exchange 2010 на операционной системе Windows Server 2010 эффективно работает оперативной памятью объемом до 64 GB на сервер.
Таблица ниже показывает минимальные и максимальные значения на каждую роль.
| Exchange 2010 server role | Minimum supported | Recommended maximum |
| Edge Transport | 4GB | 1GB per core |
| Hub Transport | 4GB | 1GB per core |
| Client Access | 4GB | 2GB per core |
| Unified Messaging | 4GB | 2GB per core |
| Mailbox | 4GB | 4GB +database cache |
| Client Access/ Hub Transport combined | 4GB | 2GB per core |
| Multiple roles (Hub transport + Client Access + Mailbox) | 4GB | 4GB + 3-30 MB additional per mailbox. |
Роль Edge Transport и Hub Transport
Эти роли не требуют большого объема оперативной памяти, минимум 4GB достаточно для обработки всех запросов, оптимальное значение 1GB на ядро, но не менее 4 GB в сумме.
Роль Client Access Server
Потребление оперативной памяти в этой роли имеет практически линейную зависимость от числа клиентских подключений и количества транзикций. Основываясь на рекомендациях Microsoft — конфигурация роли с 2GB на ядро является сбалансированной.
Роль Mailbox Server
Эта роль является довольно сложной в расчетах, т.к. оптимальные параметры оперативной памяти зависят от числа развернутых ролей, количества почтовых ящиков, от среднего профиля пользователя и количества активных баз данных.
Расчет памяти этой роли является критичным для уменьшения нагрузки ввода/ввывода на дисковую подсистему сервера.
3. Расчет кэша Mailbox Database
В Exchange 2010 применяется механизм уменьшения нагрузки на дисковую подсистему сервера или хранилища данных, основанный на использовании кэша Extensible Storage Engine (ESE). Чем больше кэша доступно серверу Exchange 2010, тем меньше нагрузка I/O на дисковую подсистему.
Эффективность кэша в Microsoft Exchange 2010 была повышена в ходе нескольких технических изменений. Одно из самых значительных изменений — увеличение журнала проверки depth target. Этот журнал испльзуется для того, чтобы убедиться, что логи и кэш базы данных записываются в базу данных в разумных временных пределах. Размер журнала зависит от количества копий и типа базы данных:
| Database configuration | Log checkpoint depth target |
| Одиночная база данных | 20MB |
| База данных с копиями | 100MB |
| Неактивная база данных | 5MB |
С применением механизма Extensible Storage Engine нагрузка на ввод/ввыод для базы данных с двумя и более копиями может быть до 40% ниже, чем для конфигурации с одиночной базой данных. В ситуациях с высокой нагрузкой на дисковую подсистему база данных хранит файлы изменений в памяти продолжительное время, такое поведение снижает количество операций последовательной записи (repeated write) и создает эффект слияния (coalescing), т.н. гибридную модель хранения. Это позволяет быстрее восстанавливать базу данных в случае неисправности. В тоже время неактивные копии баз данных также используют память для хранения журнала (5MB), это позволяет быстро переводить неактивную базу данных в активный режим.
Объем кэша, а, соответственно, объем физической памяти напрямую зависит от количества баз данных и может быть вычислен по таблице:
| Количество баз данных | Минимальный объем оперативной памяти |
| 1-10 | 2 GB |
| 11-20 | 4 GB |
| 21-30 | 6 GB |
| 31-40 | 8 GB |
| 41-50 | 10 GB |
| 51-60 | 12 GB |
| 61-70 | 14 GB |
| 71-80 | 16 GB |
| 81-90 | 18 GB |
| 91-100 | 20 GB |
В предыдущих версиях Echange ключевой метрикой был объем операций ввода/вывода, сейчас текущими метриками стали объем кэша баз данных и число сообщений, отправляемых пользователем в день.
Следующая таблица позволяет определить IOPS, исходя из объема ящика 2GB и среднего размера письма 75KB.
| Сообщений на почтовый ящик в день (~75KB средний размер сообщения) | Кэш базы данных на пользователя (MB) | Одиночная база данных (stand-alone): IOPS на ящик | Копия базы данных: IOPS на ящик |
| 50 | 3 | .060 | .050 |
| 100 | 6 | .120 | .100 |
| 150 | 9 | .180 | .150 |
| 200 | 12 | .240 | .200 |
| 250 | 15 | .300 | .250 |
| 300 | 18 | .360 | .300 |
| 350 | 21 | .420 | .350 |
| 400 | 24 | .480 | .400 |
| 450 | 27 | .540 | .450 |
| 500 | 30 | .600 | .500 |
4. Активные/неактивные базы данных и копии баз данных
Неактивные базы данных.
В Exchange 2010 один и тот же сервер может обрабатывать как активные копиии баз данных, так и неактивные, в конфигурации с отказоустойчивым решением. Требования к процессору для обработки неактивных копий также должны учитываться на этапе проектировки. Неактивные копии баз данных используют ресурсы процессора для проверки реплицированных логов и обработки индекса базы данных. Каждый ящик неактивной базы данных требует 15% ресурсов CPU от ресурсов почтового ящика активной базы данных.
Копии баз данных.
Каждой базе данных Exchange 2010 можно создать до 16 копий. Каждая копия базы данных потребляет 10% CPU от основной базы данных.
Понимание количества копий и количества неактивных баз необходимо для возможности создания нескольких моделей поведения среды Exchange 2010 в зависимости от внешних условий (например, от количества вышедших из строя серверов или площадок). Типичными моделями для среды Exchange 2010 являются модель при 100% использовании всех почтовых ящиков и модель поведения в случае худшего сценария.
Шаги по планированию следующие:
- Определяем необходимый уровень отказоустойчивости, количество необходимых копий и количество Data Availability Groups (DAGs) для защиты от выхода из строя различных компонент.
- Если используем отказоустойчивость, определяем модель поведения: активация всех почтовых ящиков или задаем худший сценарий.
- В зависмости от выбранной модели выбираем значения из приведенной таблицы, основанной на типе профиля (10 часов с двухчасовым пиком загрузки в утреннее время):
| Количество писем в день на почтовый ящик | Кэш базы данных на почтовый ящик (MB) | Одиночная база данных с оценками IOPS на ящик | Копии базы данных (IOPS на mailbox) | Мегациклы для активного ящика | Мегациклы для неактивного ящика |
| 50 | 3 | .06 | .05 | 1 | 0.15 |
| 100 | 6 | 0.12 | 0.1 | 2 | 0.3 |
| 150 | 9 | 0.18 | 0.15 | 3 | 0.45 |
| 200 | 12 | 0.24 | 0.2 | 4 | 0.6 |
| 250 | 15 | 0.3 | 0.25 | 5 | 0.75 |
| 300 | 18 | 0.36 | 0.3 | 6 | 0.9 |
| 350 | 21 | 0.42 | 0.35 | 7 | 1.05 |
| 400 | 24 | 0.48 | 0.4 | 8 | 1.2 |
| 450 | 27 | 0.54 | 0.45 | 9 | 1.35 |
| 500 | 30 | 0.6 | 0.5 | 10 | 1.5 |
Параметр мегациклов определяется производительностью ядра процессора в MHz, например, 2 x 4 core Intel Xeon x5470 3.33-gigahertz (GHz) дают по 3333 мегациклов на ядро.
5. Система хранения данных
Выбор системы хранения данных зависит от множества факторов, но в первую очередь определяется количеством почтовых ящиков и требованием к расширению.
Для небольших организаций с 1000 почтовых ящиков HP и Microsoft рекомендуют использовать iSCSI хранилища P2000G3 начального уровня или дисковую подсистему ProLiant.
Для больших инсталляций рекомендуются хранилища высокого уровня, поддерживающие большое количество дисков. Одним из таких массивов является 3PAR StoreServ, анонсированный 4-го декабря 2012 года. Этот массив уже прошел испытания по программе Exchange 2010 Solution Reviewed Program (ESRP) – Storage v3.0.
Как известно, массивы 3PAR предназначены для использования под задачи виртуализации в среде с непредсказуемыми нагрузками. Еще одно из возможных предназначений — корпоративная почта.
Совместно с корпорацией Microsoft был проведен тест массива 3PAR StoreServ для почты на 60000 пользователей. В решении использовались блейд-серверы HP Proliant Bl460c Gen8, блейд-корзины C7000, оптические коммутаторы Brocade.
ПО теста: Microsoft Windows Server 2008 R2 и Microsoft Exchange 2010.
Документ дает информацию о тестировании массива в среде на 60 000 пользователей.
Высокая эффективность организована благодаря применению технологии wide-striping (использовании всех дисков для построения отказоустойчивого RAID) на массиве 3PAR с использованием Database Availability Group (DAG), где каждую копию DAG обслуживают 18 серверов (9 активных серверов обслуживают 60 000 пользователей в 2 DAG). Высокая доступность данных может быть обеспечена благодаря организации репликации данных между двумя массивами 3PAR. В тестовом решении использовался один массив и 9 серверов.
В дисковом массиве 3PAR все используемые диски автоматически делятся на блоки размером в 1 GB (chunklet), блоки с одинаковыми типами дисков и одним уровнем RAID формируют логический диск. Common Provisioning Group (CPG) – набор политик, отвечающих за формирование RAID групп. CPG также отвечает за формирование виртуальных томов (LUN), которые презентуются хосту.
В описанном решении 3PAR сконфигурирован с одной CPG для всех хостов в обеих DAGs, содержащих активные базы данных. В случае выхода из строя диска, массив продожит обслуживание всех хостов, процессы перестроения RAID будут использовать блоки spare chunklets на всех оставшихся дисках.
На рис.1 показан процесс формирования логических дисков в массиве 3PAR.
Рис.1
В тестовой среде конфигурация содержит 18 серверов, подключенных к массиву 3PAR с 216 2TB NL SAS. Виртуальные тома презентованы хостам. Из этих виртуальных томов каждому серверу были предоставлены 12 томов под базы данных / логи и один том под восстановление / обслуживание.
В этом решении виртуальные тома были созданы на массиве 3PAR, что позволило легко увеличивать размер тома по мере роста баз данных. Активные и неактивные копии баз данных размещаются на разных массивах для обеспечения отказоустойчивости решения.
Все тома баз данных, тома обслуживания и восстановления были созданы с применением защиты RAID. Реальный размер баз данных и томов для каждого конкретного заказчика зависит от большого числа факторов, включающих Service Level Agreement (SLA), методологии бэкапа, факторы управления виртуальных томов и желаемый размер баз данных на диске.
На рис.2 показаны активный датацентр с разметкой томов и серверов.
Рис.2
На рисунке 3 показана схема полного решения с 18 серверами, в каждой группе DAG по 9 серверов. В случае потери связи или в случае отключения питания на удаленной площадке, 9 оставшихся серверов в состоянии обслужить все базы данных.
Схема презентованных баз данных каждому хосту:
В случае выхода из строя первичной площадки — оставшиеся серверы будут способны продолжить обработку запросов:
6. Расчет для сценария на 60000 пользователей
Рассмотрим примерный сценарий расчета для описанного решения.
Число почтовых ящиков: 60000
Профиль пользователя: 100 писем в день (0.14 IOPS на пользователя почтового ящика с запасом в 20%).
Профиль нагрузки: 0.12 x 60000 = 8400 IOPS на активные почтовые ящики.
Размер почтового ящика: 2GB.
Архитектура системы хранения данных: RAID 10.
DAGs: 2.
Серверы: 18 (9 серверов на каждую DAG).
Рассчитаем количество почтовых ящиков на сервер: 60000 / 18 = ~3300.
Количество почтовых ящиков на базу данных: 833.
Размер виртуального тома на системе хранения для каждой базы данных (LUN) Database + Log = 1740.88GB.
Система хранения данных обеспечивает сырую емкость не менее 418 608 GB.
Тип подключения к хранилищу: Fibre Channel SAN.
Скоость подключения к массиву: 12x 8Gb = 96Gb/s
Коммутаторы: 2x Brocade 8/24
Северная платформа: 18 серверов 2 x 8 core Intel Xeon E5-2650 2.0 GHz, 64 GB RAM.
Начинаем расчет.
Т.к. DAG должна работать в случае выхода из строя 9 серверов, то начинаем расчет с 18 нод. Предполагая, что все базы данных равнозначно распределяются по 18 узлам, получаем по 3300 почтовых ящиков на сервер. Рассчитываем показатель почтовых ящиков в случае выхода из строя 9 узлов (60 000 / 9) = ~6700 почтовых ящиков на сервер.
Рассчитываем количество мегациклов на почтовые ящики: 6700 x 2 (по таблице мегациклов на почтовый ящик) = 13400 мегациклов. Умножаем это значение на 10% для каждой копии. В этом примере на каждую активную копию приходится 2 неактивных, следовательно, число мегациклов возрастает на 20%: 13400 x 1.2 = 17700 мегациклов.
Умножаем число неактивных почтовых ящиков (когда сервер обрабатывает максимальное число ящиков) на показатель мегациклов на неактивный почтовый ящик из таблицы (3300 x 0.3 мегациклов = 990 мегациклов).
Складываем значения мегациклов для активных почтовых ящиков со значениями для неактивных почтовых ящиков: 17700 + 990 = 18690 мегациклов. Переводим эти значения на платформу.
2 восьмиядерных процессора Intel Xeon E5-2650 2.0 GHz соответствуют значению 16x 2000 = 32000 мегациклов. Считаем пиковую утилизацию сервера: 18690 / 32000 = 60%. Это значение показывает, что в момент пика обращений всех пользователей, в случае выхода из строя половины физических серверов, мы получим нагрузку 60% на процессор, этот показатель считается приемлимым. Рекомендуется рассчитывать параметы так, чтобы коэффициент загрузки процессора в пиковой ситуации не превышал 70%.
Рассчитаем необходимое количество ядер для активных почтовых ящиков.
Для отказоустойчивого решения:
Необходимое число ядер = (требуемая производительность CPU для активных ящиков) / (мегациклы на ядро) x (число оставшихся серверов) x (количество DAGs).
Для решения без отказоустойчивости:
Необходимое число ядер = (требуемая производительность CPU для активных ящиков) / (мегациклы на ядро) x (число серверов в датацентре)
Исходя из наших значений:
6700 / 2000 x 9 = 30 ядер
30 ядер из 144 (9 серверов по 16 ядер) обрабатывают активные почтовые ящики, в случае, когда 14 серверов вышли из строя.
Исходя из этого рассчитаем число ядер, необходимых для ролей Exchange (по рекомендациям Microsoft).
Ядра Hub Transport = необходимое число ядер / 5 = 30/5= 6.
Ядра для Client Access server = необходимое число ядер x 3 / 4 = 30 x 3 / 4 = 22.
Ядра Global catalog = необходимое число ядер / 8 = 30 / 8 = 4.
Аналогичным образом рассчитывается значение оперативной памяти.
Исходя из показателя 6700 почтовых ящиков на сервер, в случае выхода из строя второй площадки, и параметра 100 писем на почтовый ящик мы получает значение кэша ~40GB для роли Mailbox. Для остальных ролей на сервер оставляем ~40% RAM. Таким образом, сервер с 56GB RAM должен справиться с нагрузкой в 6700 почтовых ящиков. В нашем случае использовались тестовые сервера с большим запасом оперативной памяти (64GB RAM).
Исходя из рекомендованных значений Microsoft делается расчет IOPS (число почтовых ящиков умножаем на значение IOPS для активных и неактивных копий): 60000 x (0.12 + 2 x 0.1) = ~19200 IOPS. В текущей конфигурации массив обеспечивает производительность 21 363 IOPS 25read/75write согласно рекомендациям Microsoft по расчету кэша для систем хранения.
Рекомендации :
- В Windows Server 2008R2 не требуется использование специальных утилит для форматирования и «выравнивания» блоков на физическом носителе, как этого требовали ОС Windows Server 2003. Windows Vista, Windows 7, Windows Server 2008 и более поздние продукты по умолчанию выравнивают раздел на 1MB.
- Microsoft рекомендует использовать SAS диски для почтового окружения, в то время как диски SSD для задач почты являются неэффективными: In general, Exchange 2010 Mailbox servers don’t require the performance characteristics of SSD storage.
- Использовать MPIO на стороне хоста вместе с двухпортовыми HBA адаптерами.
- Всегда считать нагрузку по худшему сценарию (как мы считали нагрузку на процессоры хостов ранее).
- Использовать разделяемые ресурсы (Shared Logical Disks) во время развертывания Microsoft Exchange, чтобы получить максимальную пользу от технологии wide-striping дискового массива 3PAR.
- Для дисков SAS 7.2k Microsoft рекомендует использовать уровень RAID 1+0.
Выводы:
Продукт Microsoft Exchange 2010 остается самым популярным на сегодняшний день продуктом корпоративной почты. Совместно с Microsoft компания HP регулярно проводит тестирование своих продуктов и выкладывает показатели производительности.
Примером подобного тестирования является решение на массиве 3PAR StoreServ 7400 на 60000 пользователей.
Тест был запущен на 24 часа и показал способность массива 3PAR StoreServ справляться с длительными высокими нагрузками при работе с Microsoft Exchange. Базы данных и лог файлы были проанализированы после теста на возможные ошибки.
Отчет по тестированию решения:
1. Были ли зафиксированы какие-либо ошибки в журнале событий?
— Нет
2. Были ли зафиксированы какие-либо ошибки в лог файлах и базах данных в результате проверки контрольных сумм?
— Нет
Средние показатели производительности дисковой подсистмы на стороне хоста во время пиковых нагрузок:
Database I/O
Database Disk Transfers/sec 1921
Database Disk Reads/sec 1210
Database Disk Writes/sec 711
Average Database Disk Read Latency (ms) 19.79
Average Database Disk Write Latency (ms) 1.96
Transaction Log I/O
Log Disk Writes/sec 632
Average Log Disk Write Latency (ms) 0.58
При расчете необходимых конфигураций можно пользоваться как результатами уже тестированных решений HP ESRP, так и рекомендованными параметрами для каждых ролей на сайте Microsoft.
Литература:
1. Расчет массива на 140000 пользователей Exchange
2. Расчет массива на 60000 пользователей Exchange
3. Расчет массива на 1000 пользователей Exchange
4. Расчет на 1000 пользователей Exchange на дисковой подсистеме серверов ProLiant
5. Калькулятор ролей Microsoft
6. Performance and Scalability for Exchange Server 2010 SP1
