Причины перехода на Exchange Server 2007

Что может побудить руководство предприятия, использующего почтовую систему на базе сервера Exchange Server 2003 или более старую, задуматься о переходе на новую версию? Модернизация влечет за собой расходы на программное обеспечение и, скорее всего, новое оборудование. Вкладывать дополнительные средства, не вполне понимая, ради чего, вряд ли кто согласится.

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

Новая версия почтового сервера производит революцию в отказоустойчивости, восстанавливаемости и контролируемости почтовых систем на базе Exchange. Однако значимость этих новшеств определяется для каждого предприятия индивидуально, и оправдают ли они расходы на модернизацию, руководство в каждом случае должно решать самостоятельно. А вот одно из революционных изменений в новой версии — переход на 64-разрядную платформу — имеет большое значение для многих предприятий, поскольку касается производительности, самого важного аспекта любой системы, определяющего ее эффективность. Кроме того, производительность есть самая сложная для анализа характеристика, так как контроль ее уровня требует специальных знаний и в области сервера Exchange, и в области операционной системы. С другой стороны, недостаточный уровень производительности — критерий наиболее чувствительный для конечных пользователей. При этом в крупных организациях, активно использующих почтовую систему, администраторы предприятия могут регулярно сталкиваться с катастрофическим падением производительности сервера Exchange после некоторого периода его работы, и им приходится перезагружать сервер, чтобы восстановить нормальное функционирование почтовой системы. Или, опять же после некоторого периода работы, пользователи заявляют, что не могут подключиться к своим почтовым ящикам (см. экран 1), и снова администраторам приходится перезагружать сервер, чтобы дать пользователям возможность продолжить работу.

Однако под производительностью следует понимать не только скорость, с которой работают приложения пользователей. Нужно помнить о таких, заметных часто только администраторам, проблемах, вызванных чрезмерной нагрузкой, как неожиданные ошибки при обработке писем на сервере. Следствием подобных ошибок может стать потеря сообщения или даже крах операционной системы сервера. Таким образом, недостаточная производительность снижает эффективность работы всего предприятия. Проблема же заключается в том, что в версии сервера Exchange 2003 и более старых этой самой производительности как раз и не хватает, причем наращивание аппаратной мощности сервера не только не способствует решению проблемы, а даже усугубляет ее. Здесь может помочь как раз переход на 64-разрядную платформу. Сложность решения о переходе заключается в том, что нужно убедиться, что узким местом в системе является версия почтового сервера, что ограничения накладываются именно платформой, а не неоптимальной конфигурацией, и тогда это очевидный повод для перехода на новую версию. Поэтому речь в данной статье пойдет об анализе причин, вызывающих проблемы с производительностью, и о признаках ситуации, когда сервер Exchange практически исчерпал себя.

Пределы Exchange

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

Но прежде давайте разберемся, чем обусловлен этот самый пресловутый порог производительности и как он отодвинут в новой версии сервера Exchange. Начать изучение проблемы следует с определения главного тезиса статьи, который заключается в том, что главные ограничения Exchange Server 2003 относительно его производительности вытекают непосредственно из его 32-разрядной архитектуры, и это наверняка известное всем ограничение в 4 Гбайт на объем доступного адресного пространства. Объем в 4 Гбайт адресного пространства включает и количество данных, которые сервер Exchange может обрабатывать одновременно, и объем памяти, доступный операционной системе для управления компьютером вообще и сервером Exchange в частности. Иначе говоря, операционной системе и серверу Exchange на двоих доступно только 4 Гбайт памяти. Они делят этот объем сначала между собой, потом между компонентами, и в результате для конкретных операций остается совсем немного по современным меркам. А еще точнее, когда разрабатывалась 32-разрядная архитектура, получившиеся объемы памяти казались огромными, но ведь это было более 20 лет назад. Но сегодня для востребованных функций операционной системы и сервера Exchange этих объемов может оказаться просто недостаточно. Отсюда вытекают проблемы:

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

Другими словами, главная причина всех проблем — недостаток памяти. Памяти не хватает серверу Exchange, не хватает операционной системе. Операционная система делит эти 4 Гбайт пополам, резервируя 2 Гбайт для компонентов операционной системы и 2 Гбайт выделяя непосредственно коду приложения и его данным, обращающимся к компонентам операционной системы в первых 2 Гбайт. Почтовый сервер Exchange представляет собой набор служб, каждая из которых является отдельным приложением и получает от операционной системы до 2 Гбайт адресного пространства. Но основной потребитель памяти в сервере Exchange — служба Information Store, управляющая базами данных и реализованная как процесс store.exe. Именно на работе этой службы в первую очередь сказывается предел возможностей сервера Exchange 2003. В 2 Гбайт оперативной памяти для приложения store.exe 576 Мбайт выделяются под буфер для данных, с которыми работает служба. Соответственно, все данные, которые запрашивают пользователи из своих ящиков или общих папок, помещаются в этот буфер, обрабатываются и предоставляются пользователям. При сохранении данных пользователями выполняется та же процедура, только в обратном порядке. Теперь осталось разделить объем буфера на число пользователей в корпоративной сети, а полученное значение — на средний объем электронного сообщения в организации. Результат вряд ли будет впечатляющим, поэтому, чтобы обработать данные всех активных пользователей, службе приходится сбрасывать не используемые в текущий момент данные обратно в базу, а потом загружать снова. Осталось назвать самый медленный компонент современного компьютера, и получим искомый предел производительности. Таким образом, фразу «серверу Exchange не хватает памяти» следует понимать так, что памяти не хватает именно буферу процесса store.exe. Конечно, можно увеличить размер буфера, например, вы можете добавить в файл boot.ini ключ /3GB, что приведет к автоматическому увеличению буфера до 896 Мбайт. Можно, впрочем, и непосредственно увеличить максимальный размер буфера в настройках сервера Exchange. Только откуда берутся эти 320 Мбайт? Ответ в ключе /3GB, который увеличивает объем адресного пространства, доступного процессу, до 3 Гбайт. Служба Information Store в этом случае автоматически увеличивает максимальный размер буфера. Однако откуда берется этот дополнительный гигабайт? Очень просто — за счет адресного пространства, доступного операционной системе в режиме ядра, которой теперь остается 1 Гбайт. Перераспределение адресного пространства позволяет повысить производительность подсистемы хранения данных сервера Exchange, т. е. процесса store.exe, но ограничивает возможности операционной системы, например, по количеству одновременных сетевых подключений пользователей к тому компьютеру, на котором работает сервер Exchange. И это наша вторая проблема.

Заколдованный круг

Снижение производительности операционной системы станет следствием уменьшения объемов памяти, которые используют компоненты операционной системы для хранения рабочих данных. Прежде всего это относится к разделу в системной части адресного пространства, называемого «невыгружаемым пулом», в котором драйверы, в том числе драйвер Exchange IFS и драйверы сетевых карт, сохраняют данные операций, характер которых не позволяет выгрузить их в файл подкачки. Меньший размер, а при использовании ключа /3GB размер автоматически сокращается с 256 до 128 Мбайт, приводит к тому, что быстрее заканчивается место в пуле и в случае сервера Exchange это может вылиться либо в катастрофическое снижение производительности, либо в невозможность подключения к серверу вообще. Причем, чтобы восстановить приемлемый уровень производительности, придется перезагрузить сервер. Кроме невыгружаемого пула, такая же проблема касается и выгружаемого пула (название говорит само за себя), а также таблицы PTE, которая позволяет управлять физической памятью, проецируя адреса виртуальной адресного пространства в адреса физической памяти. Исчерпание выгружаемого пула приведет к снижению производительности или сервер просто не сможет продолжать работу без перезапуска (службы Information Store или даже всего сервера). А недостаток записей в таблице PTE не позволит операционной системе задействовать имеющуюся физическую память.

Снова Exchange

Третья архитектурная проблема Exchange Server 2003 заключается во фрагментации виртуального адресного пространства, т. е. того объема адресов, которые операционная система выделила серверу Exchange для хранения данных и программного кода. Причем проблема возникает не столько из-за самой фрагментации, сколько из-за относительно малого объема этого виртуального адресного пространства. Дело в том, что место в виртуальном адресном пространстве выделяется непрерывными участками. По умолчанию приложению выделяется столько памяти, сколько оно запрашивает. Например, если нужно процессу store.exe загрузить страницу из базы в память, ему будет выделено место под страницу — 4 Кбайт (размер страницы в базе сервера Exchange 2003 — 4 Кбайт). Место в адресном пространстве выделяется по необходимости, затем выделенные адреса освобождаются приложением по завершении операции, которой требовалось это пространство. В результате выделение и освобождение выполняются в случайном порядке и зависят исключительно от приложений, что и вызывает фрагментацию адресного пространства, поскольку невозможно предсказать, где, когда и какой адрес будет занят, а какой освобожден. Негативное же следствие этого заключается в том, что в результате подобного случайного выделения адресов может просто не остаться достаточных по размеру непрерывных областей адресного пространства для необходимых операций. Например, операция монтирования базы данных требует 10 Мбайт, и, если не найдется подходящего блока непрерывных адресов, сервер не сможет подключить базу.

Контролируйте ситуацию

Все сказанное выше должно убедить администратора изучить состояние серверов Exchange 2003, чтобы понять, что является причиной неполадок с почтовой системой. Стоит ли увеличивать объем памяти, количество жестких дисков и т. д. Или же все это бессмысленно, и нужно просто переходить на 64-разрядную платформу, где объем адресного пространства, доступного операционной системе и приложениям, составляет 8 Тбайт или по 4 Тбайт системе и каждому приложению. В таком случае все проблемы разом снимаются. Ну а если переход по каким-то причинам невозможен, то, по крайней мере, администратору остается оптимизировать использование подсистемы памяти сервера и тем самым на какое-то время продлить жизнь старых серверов Exchange.

Начать же следует с изучения размера буфера подсистемы хранения в сервере Exchange, т. е. уже известного нам процесса store.exe. Ведь в конечном счете именно этому процессу не хватает адресного пространства и, по сути, именно он создает проблему производительности. Текущий размер рабочего буфера (еще называемый ESE Buffer) подсистемы хранения контролируется через счетчик Virtual Bytes процесса store.exe. Собственного счетчика у этого компонента сервера Exchange нет, поэтому задействуется общий счетчик используемого адресного пространства процесса подсистемы хранения, который опосредованно позволяет контролировать буфер, но значение, которое он показывает, включает в себя еще и адресное пространство, занятое программным кодом. В такой ситуации следует ориентироваться на текущий объем, т. е. счетчик Virtual Bytes, и максимально возможный объем виртуального адресного пространства, занимаемого процессом store.exe, который составляет значение 1,8 Гбайт по умолчанию и 2,8 Гбайт при использовании ключа /3GB. Разница между значением счетчика Virtual Bytes и теоретическими максимальными значениями показывает текущее состояние подсистемы хранения, а также возможность увеличения буфера. Если счетчик показывает значение, близкое к предельному, то сервер Exchange работает на пределе доступной производительности, и в дальнейшем нельзя допускать увеличения уровня нагрузки, а также следует задуматься о модернизации. Если нет, то, ориентируясь на рекомендации, приведенные в табл. 1, следует изучить возможность корректировки параметров буфера. Последнее замечание очень важно, поскольку слишком маленький размер буфера приводит к увеличению числа обращений к базе данных, т. е. к диску, что само по себе снижает производительность и опять же приводит к фрагментации адресного пространства. Управление размером буфера выполняется посредством трех параметров в конфигурации сервера Exchange, хранящейся в базе данных службы каталога Active Directory. Эти параметры находятся в разделе ConfigurationServicesMicrosoft ExchangeНазвание организацииAdministrative GroupsНазвание административной группыServersНазвание сервераInformation Store. В свойствах контейнера Information Store находится три атрибута:

• msExchESEParamCacheSize (постоянный размер буфера);
• msExchESEParamCacheSizeMax (максимальный размер буфера);
• msExchESEParamCacheSizeMin (минимальный размер буфера).

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

Однако, как говорилось в начале статьи, недостаток адресного пространства для подсистемы хранения — только верхушка айсберга. Следствием нехватки является фрагментация адресного пространства. А, пытаясь решить проблему, забрав память у операционной системы (имеется в виду ключ /3GB), мы получаем новые проблемы:

• недостаток свободных записей в PTE;
• недостаток места в пулах адресов.

Поэтому необходимо осуществлять постоянный мониторинг сервера при помощи оснастки Performance и набора счетчиков объекта MSExchangeIS, показывающих уровень фрагментации адресного пространства подсистемы хранения, а также счетчиков объекта Memory, показывающих состояние пулов и таблицы PTE. Необходимые счетчики показаны на экране 2.

Мониторинг — важнейшая составляющая работы администратора, но, когда ситуация достигает критического состояния, нужно действовать. Критический уровень фрагментации проявляется в журнале приложений сообщениями c ID 9582. Сообщения будут предупреждениями (warning), если объем самого большого фрагмента адресного пространства не больше 32 Мбайт, и ошибками, если оставшихся фрагментов не больше 16 Мбайт. Затем начнутся последствия — чрезмерный уровень фрагментации приводит к ошибкам в процессе обработки сообщений, которые протоколируются в журнале приложений событиями с ID 12800. Поэтому при получении предупреждения 9582 следует перезапустить службу Information Store в течение 32–76 часов. После появления ошибки 9582 следует перезагрузить службу. Кстати, возможно, что перезапуск только одной службы Information Store проблемы не решит, и тогда придется перезапускать весь сервер. Для того чтобы сократить фрагментацию, можно воспользоваться параметром HeapDeCommitFreeBlockTreshold (тип — DWORD) в разделе CurrentControlSetControlSession Manager, рекомендуемое значение 0х00040000, т. е. 256 Кбайт. Этот параметр предписывает операционной системе, выделив приложению какое-то количество адресов, зарезервировать еще 256 Кбайт адресов, следующих за выделенными адресами. Таким образом, минимальный выделяемый объем адресного пространства составит 256 Кбайт, в результате выделятся и освобождаться будут более крупные фрагменты адресного пространства. Это позволит до некоторой степени снизить уровень фрагментации, чтобы критический момент наступал позже, и система дольше сможет работать без перезагрузок.

Сигналом о наличии проблемы является сообщение в журнале приложений с ID 9665, которое извещает о недостаточном количестве свободных записей в PTE. Это событие может появляться после добавления в файл boot.ini ключа /3GB без ключа /USERVA. При использовании ключа /3GB количество записей в таблице PTE сокращается с 300 тыс. до 24 тыс., поэтому их может просто не хватить. Для того чтобы увеличить количество записей PTE, следует добавить в файл boot.ini ключ /USERVA=ХХХХ, рекомендуемое значение которого 3030, что увеличивает количество записей в PTE до 31 тыс. Диапазон возможных значений для ключа /USERVA — от 2970 до 3030. Смысл же ключа заключается в том, чтобы из 1 Гбайт адресного пространства, которое ключ /3GB забирает у операционной системы, приложения использовали только то количество мегабайтов, которое указанно в ключе /USERVA, а остальное возвращалось системе. Таким образом, используя ключ /USERVA, можно фактически добавлять количество записей в PTE.

Третья проблема — недостаток места в пулах, что может привести в том числе и к невозможности подключения пользователей к серверу Exchange. Поэтому, если некоторые пользователи жалуются на невозможность доступа к своему почтовому ящику, следует проверить журнал приложений на наличие в нем событий с кодами 2019, 2020, которые подтверждают, что закончилось место в выгружаемом пуле. Кроме того, событие с ID 2021 информирует о том, что место в невыгружаемом пуле закончилось. В этом случае вы можете быть уверены, что снова стоите перед порогом производительности сервера Exchange 2003. Следует перешагнуть через этот порог, либо перенеся часть нагрузки на другой сервер Exchange 2003, либо перейдя на 64-разрядную платформу сервера Exchange 2007. А чтобы кризис не застал администратора врасплох, остается вести тщательный мониторинг состояния пулов операционной системы. Здесь, кстати, пригодится табл. 2. Соответственно, если до реальных проблем дело еще не дошло, а указанные в таблице параметры системы близки к порогу предупреждения, то и проблемы не за горами, а значит, следует заранее задуматься о переходе на новую версию.

Несколько советов

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

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

• оптимизировать структуру групп Active Directory: чем меньше число групп безопасности, в которые входит пользователь, тем лучше;
• для создания списков рассылки следует стремиться использовать только группы распространения;
• переместить серверы Exchange в отдельный домен Active Directory;
• сократить число групп хранения (имеются в виду Storage group);
• перенести общие папки или хотя бы папки Schedule+ Free/Busy и папку автономной адресной книги на отдельный сервер;
• установить обновление 912480 для сервера Exchange 2003 SP2;
• не совмещать почтовые серверы с другими ролями в сетевой инфраструктуре, и особенно с ролью контроллера доменов;
• не стоит на сервер, выделенный для работы только сервера Exchange 2003, устанавливать более 4 Гбайт оперативной памяти, потому что для поддержки каждого дополнительного байта физической памяти требуется кусочек в системном разделе виртуального адресного пространства (точнее, в таблице PTE), чтобы операционная система могла им управлять, и это адресное пространство может быть взято у одного из пулов.

Также следует помнить, что механизм горячей замены модулей памяти Hot Add Memory использует выгружаемый пул и соответственно уменьшает размер, доступный серверу Exchange.

И в заключение, для экономии виртуального адресного пространства имеет смысл использовать стандартный VGA драйвер вместо драйвера, предоставленного разработчиком видеокарты. Самый простой способ это сделать — вставить ключ /BASEVIDEO в файл boot.ini, что заставит систему всегда использовать только стандартный драйвер. Такая настройка позволит сэкономить около 1000 записей в таблице PTE.

Дмитрий Иванов (DmitriyI@hq.a-sys.ru ) — преподаватель сертифицированного учебного центра Microsoft «Академия корпоративных систем», специализация Microsoft Exchange Server