В большой почтовой организации, когда на одном сервере хранится более 500 почтовых ящиков становится важным вопрос о производительности дисковой подсистемы почтового сервера. Часто именно дисковая подсистема, точнее её неудовлитворительная производительность становится причиной заметных “тормозов” в работе почтового сервера. Для пользователя это выливается в частые подвисания при процессе синхронизации с сервером и при открытии больших папок в ящике (в которой хранится больше 5000 элементов). В связи с этим становится важным вопрос проверки производительности дисковой подсистемы нового почтового сервера. В случае недостаточной производительности она может стать узким местом в системе и доставить много неприятных минут в общении с пользователями.
Процесс оценки и проверки производительности сильно упрощается при наличии рабочей почтовой системы. На первом этапе можно сделать оценку необходимой производительности при текущем размере почтовой организации. Кроме этого можно оценить производительность на случай роста организации. На втором этапе, исходя из оценок производительности, можно протестировать дисковую подсистему будущего сервера почтовых ящиков.
1. Попробуем оценить необходимую производительность будущего почтового сервера, точнее его дисковую подсистему. Для этого можно использовать замечательный бесплатный инструмент – Mailbox Server Role Storage Requirements Calculator. По ссылке дано достаточно подробное описание его работы. На первой странице мы заполняем необходимые данные, на остальных получаем результаты расчётов. Очень удобно. Для получения оценок нужно указать следующие данные по серверам:
- Версия Exchange-сервера (RTM или SP1)
- Количество серверов почтовых ящиков (в случае кластера считаются кластеры, а не количество узлов)
- Указываем тип используемой кластеризации (SCC, CCR, LCR или не будет кластеризации)
- Указываем индексировать ли данные (имеет смысл это делать, для ускорения поиска по почтовым ящикам)
- Время хранения удалённых сообщений
Следующим шагом указываем данные для почтовых ящиков (собрать их поможет утилита Profile Analizer):
- Общее количество ящиков
- Процент роста ящиков (в принципе можно поставить 0% для оценки текущих потребностей)
- Количество отсылаемых/получаемых сообщений в день
- Средний размер сообщений
- Ограничения размера ящиков
На следующем шаге нужно будет указать количество логов генерируемых нашим почтовым сервером в течение дня и задержку в работе сети. Количество первых можно банально вручную или с помощью скрипта посчитать (главное помнить, что Exchange 2003 генерирует логи 5Мб размером, а Exchange 2007 – 1Мб), а задержку можно определить, например, с помощью утилиты ping.
Остальные данные для меня большого интереса не представляют, поэтому я их оставляю без изменений.
На закладке Storage Requirements я получаю искомое значение IOPS для диска/дисков с почтовыми базами и для диска с логами. Кроме этого на закладке LUN Requirements можно посмотреть рекомендуемое количество почтовых баз и их размещение по LUN’ам хранилища. На этом наша работа с калькулятором хранилища заканчивается.
2. Теперь переходим к нашему будущему серверу почтовых ящиков. Для тестирования его производительности можно использовать утилиту Jetstress. Утилита при необходимости создает тестовые базы и производит операции чтения/записи из них. Параллельно с этим снимаются данные с различных счётчиков системы и в конце процесса тестирования мы получаем информацию с результатами.
Под Windows 2008 Jetstress надо запускать с правами администратора (Run as administrator). Причём предварительно надо определить с какими параметрами запускать тестирование. Для этого проводятся несколько оценочных тестирований. Главным параметром который надо определить – количество потоков чтения записи на каждую почтовую базу (Suppress tuning and use thread count (per-storage group)). По умолчанию их предлагается 16. На самом деле это достаточно большое значение и скорее всего его в реальных условиях надо будет снижать. Время оценочного тестирования 2-4 часа.
По итогам оценочного тестирования мы получаем отчеты в формате html, в котором отображаются скорости чтения/записи и IOPS сервера. Что здесь важно – скорость чтения должна быть большой. Переменная Avg. Disk sec/Read должна быть меньше 0,02. Иначе оценочное тестирование не пройдёт успешно (в связи с этим стоит помнить, что скорость чтения с RAID10 больше чем с RAID5). Ну и значение IOPS должно быть больше чем то, которое посчитано с помощью Storage Calculator на первом шаге.
После успешного прохождения оценочного тестирования и установки рабочих параметров можно запустить стрессовое тестирование. Длится оно должно не меньше 12 часов, а лучше 24 часа. По итогам тестирования так же формируется отчет. В случае успешного прохождения стрессового тестирования можно приступать к установке сервера почтовых ящиков и надеяться, что он справится с нагрузкой. В случае неудачи – нужно возвращаться на стадию оценочного тестирования и снижать количество потоков на почтовую базу.