Опирайтесь на факты!

Оценка размеров системы Exchange Server 2003 при миграции или обновлении становится нетривиальной задачей. Приступая к проектированию системы, администраторы часто используют специальный калькулятор (например, HP ProLiant Server Sizer for Microsoft Exchange Server 2003) и утилиты для тестирования нагрузки (например, Exchange Server Load Simulator «LoadSim» 2003). Но нередко в такие программы вводятся приблизительные данные (подробнее об этих утилитах и данных для ввода рассказано во врезке «Инструменты и ресурсы для проектирования систем с Exchange 2003»). При выполнении предварительных оценок при проектировании системы меня всегда удивляли ответы на основной вопрос: как используется в данный момент система Exchange? Чтобы ответить на этот вопрос, надо определиться как минимум со следующей информацией:

  • стандартная продолжительность рабочего дня;
  • пиковые часы работы;
  • как часто пользователи задействуют почтовую систему;
  • как часто пользователи открывают сообщения или присоединенные файлы;
  • сколько используется дискового пространства.

Исследование точек максимума и минимума

Прежде чем выполнять расчет системы Exchange, надо ответить на два важных вопроса — какова продолжительность рабочего дня пользователей и какие часы работы являются пиковыми? Эта информация важна, поскольку от нее зависит оценка производительности в пиковое время. Обычно рабочий день для большинства пользователей длится 8 или 9 часов, но многие офисы имеют гибкий график работы, и начало рабочего дня может варьироваться. Например, у некоторых пользователей рабочий день может начинаться в 6:00, в то время как остальные начинают работу в 9:00. Тенденция работать дома делает расписание еще более гибким, но это пока исключение. Гибкое расписание увеличивает продолжительность рабочего дня сверх стандартных 8 часов.

Другим интересующим нас фактором является распределение пользователей по часовым поясам. Если сотрудники организации находятся в нескольких часовых поясах и планируется создавать централизованные серверы, необходимо определить фактическую продолжительность рабочего дня. Например, если пользователи находятся в Калифорнии и Вашингтоне, то минимальное рабочее время будет длиться 11-12 часов, поскольку присутствует разница в 3 часа между часовыми поясами. Если используется гибкий график работы, то реальный рабочий день может длиться от 15 до 18 часов.

Знать продолжительность рабочего дня важно, но еще важнее знать время пиковых нагрузок и продолжительность периодов нагрузки. Многие администраторы считают, что наибольшая нагрузка возникает утром и после обеда. Однако реальная нагрузка зависит от типа деятельности организации. Чтобы определить периоды нагрузки и их продолжительность, следует постоянно осуществлять мониторинг системы. Это легко сделать с помощью утилиты Windows Performance Monitor.

Performance Monitor имеет для Information Store (IS) четыре счетчика, которые могут быть полезными: User Count, Active User Count, Connection Count и Active Connection Count. User Count и Active User Count считают общее количество подключений, основываясь на процедурах регистрации в системе. Connection Count и Active Connection Count считают общее количество подключений к ресурсам внутри IS. Различие для счетчиков типа active заключается в том, что они показывают информацию об активности в течение последних 10 минут измерений. Connection Count и User Count отличаются тем, что один пользователь может установить множество соединений. Поэтому Connection Count всегда больше по значению, чем User Count, поскольку пользователи устанавливают несколько соединений с IS. Например, пользователь может иметь три подключения: одно на доступ к почтовому ящику, одно на доступ к общим папкам и еще одно — для доступа к календарям других пользователей.

Почтовые приложения, такие как BlackBerry Enterprise Server фирмы Research In Motion, также могут создавать соединения. Необходимо изучить источники соединений, поскольку они могут создавать нагрузку для системы, отличную от стандартной. Например, в HP обнаружили, что каждый пользователь BlackBerry создает нагрузку, аналогичную 2,21 пользователя Outlook. Такой фактор нагрузки необходимо учитывать при подсчете количества пользователей на сервере.

На рисунке дан график, показывающий текущую ситуацию с загрузкой одного сервера в узле. На графике добавлены вертикальные линии, которые помогают определить значения в конкретные моменты времени. Администратор этого сервера предполагал, что максимальная загрузка бывает утром и в обеденное время, но, как видно на графике, пользователи этой организации устанавливают соединения по прибытии на работу и не закрывают их до конца рабочего дня. Также пользователи со стабильной частотой в течение дня активно пользуются почтовой системой. В данном примере на сервере с 750 пользователями в пиковое время было подключено 660 пользователей. Измерения в другие дни показали похожие результаты. Таким образом, примерно 80% пользователей могут находиться в один момент времени в активном состоянии. Эта информация поможет определить, сколько почтовых ящиков способен поддерживать сервер.

При использовании Performance Monitor нужно делать измерения несколько дней. Измерения следует производить в течение длительного периода времени, а затем собрать результаты и вывести среднее. Например, в понедельник и в пятницу картина будет сильно отличаться от остальных дней недели. Также можно увидеть, что в определенные недели месяца нагрузка будет одинаково изменяться, в зависимости от каких-то повторяющихся событий. Не стоит пренебрегать такими нетипичными периодами, как время праздников и отпусков. Не следует также считать, что каждый сервер в организации испытывает одинаковые нагрузки. Если в организации серверов много, то, возможно, потребуется распределение их между различными бизнес-подразделениями. Такие подразделения работают по-разному, и одно из них может работать равномерно, как показано на рис. 1, а другое иметь зазубренный график с большими пиковыми нагрузками и периодами простоя. Данные надо собирать с большинства серверов, если не со всех, для определения типа серверов и необходимой конфигурации. Эта информация поможет определить, например, сколько требуется внедрить серверов — пять-шесть высокопроизводительных централизованных серверов, или два средних сервера для удаленных офисов, или серию идентичных серверов со средней конфигурацией для всех территорий.

Рисунок. Примерные результаты, выводимые четырьмя счетчиками хранилища IS

Как работают пользователи?

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

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

Одна из таких утилит называется StorStat, находится она в Microsoft BackOffice Resource Kit (BORK) 4.5. Эта утилита собирает информацию об использовании почтовых ящиков. Несмотря на то что специалисты Microsoft разрабатывали StorStat для Exchange Server 5.5, ее можно задействовать и в повседневном администрировании, поскольку она работает с помощью Messaging API (MAPI) для доступа к элементам в почтовом ящике.

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

Другое ограничение StorStat заключается в том, что он суммирует результаты по выбранным почтовым ящикам и дает посчитанные значения только для данной выборки. Но это несколько искажает результаты для дальнейшего анализа. Например, StorStat предоставляет среднее значение для отправленных в течение дня сообщений, но при этом не упоминается, сколько пользователей какое количество сообщений отправляет (например, три человека отправляют от 0 до 10 сообщений, 23 человека — от 10 до 20). StorStat можно использовать для сбора информации, но для более детальных результатов надо задействовать другие измерения, чтобы получить реальную картину.

Количество отправленных и принятых сообщений, размер этих сообщений и количество сообщений с присоединенными файлами являются начальной информацией для разделения пользователей по категориям: тяжелая, средняя и легкая. Для сбора такой информации можно использовать MAPI Messaging Benchmark (MMB) 3 (стандарт для измерения производительности и масштабируемости компьютеров с работающим Exchange 2003). MMB3 предназначен для среднего уровня загрузки. Например, по количеству отправляемых сообщений в день категории делятся следующим образом: 55 сообщений — средний уровень, 41 сообщение (это 75% от среднего) — легкий уровень и 69 сообщений (125% от среднего) — тяжелый уровень. Следует иметь в виду, что MMB3 разработан для совместимости с оборудованием разных производителей и возможные различия в конфигурациях не имеют большого значения.

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

Повторное открытие

Другим важным показателем для распределения пользователей по категориям является то, как часто они повторно открывают сообщения и присоединенные файлы. Если используется клиент без кэширования, такой как Outlook 2000, то при каждом чтении сообщения или доступе к присоединенным файлам происходит обращение к IS. Если пользователи обращаются к своим данным множество раз, то почтовая система работает в качестве файлового хранилища. Но такое использование не свидетельствует о неправильной работе с почтовой системой (хранение документов в почтовом ящике удобно тем, что доступ к ним можно получить из разных мест), оно означает только «тяжелый» режим использования.

Повторный доступ создает большую нагрузку на сервер Exchange. Но если в организации планируется внедрение Microsoft Office Outlook 2003 как основного клиента, то проблема повторного доступа его не касается. Одна из новых возможностей Outlook 2003 называется «режим кэширования». При этом режиме создается локальная копия почтового ящика на компьютере пользователя. Когда пользователь перечитывает свои сообщения, доступ выполняется к элементам в локальной копии почтового ящика, что уменьшает загрузку сервера. Если внедрение Outlook 2003 не планируется или не предполагается использовать режим кэширования, следует определить, как много «тяжелых» пользователей будет работать с сервером, чтобы учесть это при выборе сервера. К сожалению, сбор такой информации сложен из-за того, что ответ на него могут дать только сами пользователи в ходе прямого опроса.

Все больше и больше

Величина занимаемого пользователем хранилища показывает, к какому уровню он относится. Например, те пользователи, которые занимают мало дискового пространства на сервере, обычно имеют тенденцию не сохранять сообщения. Они не получают много почты и поэтому к «тяжелой» категории пользователей не относятся.

В системах Exchange 2003 или Exchange 2000 можно задействовать оснастку Exchange System Manager (ESM) консоли Microsoft Management Console (MMC) для определения того, как много занято дискового пространства. В среде Exchange 5.5 для этой цели используется Microsoft Exchange Administrator. Эти утилиты дают отчет по расходованию дискового пространства в байтах для каждого почтового ящика. Утилиты также позволяют экспортировать данные в файл со значениями, разделенными запятыми (CSV), который можно загрузить в Microsoft Excel или Microsoft Access для анализа. В таблице даются инструкции, как пользоваться этими утилитами.

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

С течением времени стоимость дисковых массивов снижалась, Exchange научился поддерживать множество баз данных, утилиты для архивирования и поддержки хранилищ стали обычным явлением. Эти факторы позволяют увеличивать ограничения на почтовые ящики. Если планируется увеличить ограничения, необходимо определить, какой эффект это окажет не только на почтовую систему, но и на другие части информационной системы. Например, если желательно увеличить ограничения, поскольку планируется задействовать Outlook 2003 в режиме кэширования, следует учесть выделение большего дискового пространства локально на компьютерах пользователей для зеркального отображения содержимого почтового ящика. В зависимости от аппаратного обеспечения и стратегии резервного копирования, время на резервирование и восстановление увеличится, и может потребоваться больше внешних носителей информации.

Назначение больших значений для квот может быть полезно и пользователям, и администраторам. Пользователям это может пригодиться, так как может быть задействован механизм поиска данных по множеству хранилищ. Администраторы будут довольны, поскольку создание множества файлов PST приносит дополнительные проблемы. Если пользователи переносят свои данные в файлы PST, то эти файлы должны храниться на локальных дисках компьютера пользователя или на сетевых файловых ресурсах. Локальные файлы PST создают дополнительные проблемы, когда администраторам надо переустановить компьютер с образа для решения проблем или обновления оборудования. У пользователя могут быть файлы PST на несколько гигабайтов, и администраторы должны их находить, резервировать, восстанавливать. Выполнение этих задач может длиться часами, и при этом велик риск потери данных. Файлы PST на сетевых файловых ресурсах также могут создавать проблемы. Поскольку файлы PST персональные, администраторы должны обеспечить соответствующий доступ к ним. Следует учитывать эти моменты и обсуждать их с пользователями и руководством для выработки стратегии по распределению данных в хранилищах.

Просчет будущей системы и утилиты по тестовой загрузке дадут приблизительные параметры для настройки и спецификации серверов, но данные надо вводить аккуратно, чтобы получить наиболее точный ответ. Такие утилиты, как Performance Monitor и StorStat, могут предоставить необходимую информацию. Также следует собрать данные, проведя опрос пользователей и руководства компании. Изучив работу пользователей с почтовой системой, вы сможете оптимальным образом спроектировать будущую систему. Собирайте реальную информацию, а не стройте предположения!

Джозеф Ньюбауэр - Старший технический консультант HP, специалист по Windows и Microsoft Exchange Server. joseph.neubauer@hp.com

Инструменты и ресурсы для проектирования систем Exchange 2003

Microsoft и производители оборудования, такие как HP, предоставляют утилиты для расчетов систем Exchange Server 2003 и утилиты по созданию загрузки для тестирования таких систем. Такая утилита, как HP ProLiant Server Sizer for Microsoft Exchange Server 2003, предоставляет ключевые данные для проектирования систем Exchange 2003. Другим полезным инструментом является Exchange Server Load Simulator (LoadSim) 2003, позволяющий определиться с оптимальным оборудованием для сервера. Каждый подобный инструмент требует ввода данных о почтовой системе. Например, HP ProLiant Server Sizer запрашивает такую информацию:

  • как много хранилищ расположено на каждом сервере;
  • каковы перспективы роста в следующие 12 месяцев;
  • профили пользователей (легкий, средний или тяжелый — по типу использования почты);
  • процент активных пользователей в пиковые часы;
  • процент пользователей Outlook Web Access (OWA)

LoadSim 2003 запрашивает следующие данные:

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

По возможности следует ввести все эти данные. Более подробную информацию по этим утилитам для разработки систем Exchange 2003 можно найти на сайте Windows IT Pro/RE и по следующим ссылкам: