Всистеме Exchange Server 2007 корпорация Microsoft реализовала новую транспортную службу, и неудивительно, что производственный опыт разработчиков позволил им изыскать ресурсы для повышения пропускной способности и надежности в этой сфере, а когда пришло время готовить пакет обновлений SP1, они воспользовались данной возможностью для реализации скрытых резервов. Одна из особенностей этой транспортной службы — обратная связь или обратное давление, функция, позволяющая транспортной службе ограничивать свою способность получать и обрабатывать новые сообщения, когда сервер испытывает какие-либо ограничения в ресурсах, например не хватает свободного дискового пространства или исчерпаны ресурсы памяти. При резком повышении обратного давления сервер прекращает прием входящих сообщений до тех пор, пока не будут обработаны все ожидающие своей очереди исходящие сообщения.
Основная идея состоит в том, что обратное давление — явление временное, и пока оно сохраняется, транспортная служба должна позаботиться о тех сообщениях, которые находятся в процессе обработки, и не принимать новые соединения. Когда острота ограничения — обычно речь идет о нехватке свободного дискового пространства — снимается, обратное давление падает и возобновляется нормальная процедура обработки. Скорость, с которой транспортная служба обрабатывает сообщения, весьма высока, поэтому большинство пользователей даже не замечают, что имеет место обратная связь. Да и к чему им знать об этом, если только сервер не испытывает серьезной перегрузки и ограничение в связи с этим не сохраняется в течение нескольких минут.
Рассматриваемая функция подробно описана в статье Understanding Back Pressure (http://technet.microsoft.com/en-us/library/bb201658.aspx), подготовленной специалистами сайта TechNet. В ней говорится, что в версии SP1 критический порог для диска с очередью сообщений был снижен с 4 Гбайт до 500 Мбайт, но о других изменениях, внесенных в настройки специалистами Microsoft, в этом тексте не упоминается.
Перед тем как приступать к более детальному рассмотрению предмета, важно отметить, что настройки функции обратной связи хранятся в системе Exchange в файле EdgeTransport.exe.config, размещенном в каталоге C:Program FilesMicrosoftExchange ServerBin. Этот файл используется как центральным транспортным сервером, так и пограничными транспортными серверами. Образец файла представлен на рисунке.
Разработчики Microsoft не рассчитывали на то, что этот файл будет модифицироваться администраторами (кроме тех случаев, когда это абсолютно необходимо), и не реализовали пользовательский интерфейс для просмотра или редактирования настроек в указанном файле. Поиск в Internet показывает, что документов с описанием значений всех настроек и того, какой эффект могут иметь те или иные изменения в них, явно недостаточно. В дополнение к упомянутой выше статье, опубликованной на сайте TechNet, можно назвать статью How to Change the Location of the Queue Database (http://technet.microsoft.com/en-us/library/bb125177.aspx), где речь идет о том, как можно изменить место расположения базы данных с очередью сообщений. Некоторые сведения о том, как работать с файлом EdgeTransport.exe.config, можно отыскать в блогах, написанных обладателями званий Microsoft MVP и другими специалистами, — и это, пожалуй, все, что удастся найти.
Файл EdgeTransport.exe.config (см. рисунок) можно редактировать с помощью любого текстового редактора, но это не следует делать на рабочем сервере из-за высокой вероятности того, что внесенное изменение будет иметь непредсказуемые последствия. Простые текстовые редакторы не оснащаются анализаторами ошибок для файлов настроек приложений! Внесение изменений в файлы конфигурации приложений напоминает работу со старым инструментальным средством Exchange Server 5.5, admin.exe, в режиме без обработки или внесение изменений в Active Directory с помощью редактора ADSI Edit: вы имеете полный контроль над данными, но ничто не защитит вас от самых серьезных ошибок.
Всякий раз при запуске транспортной службы из файла конфигурации считываются пороговые значения, которые следует применять функции обратной связи, а также другие настройки, необходимые для эффективного выполнения службы. Применение базы данных Extensible Storage Engine (ESE) для размещения очереди сообщений стало одним из существенных изменений в архитектуре Exchange 2007, поэтому для достижения оптимальных показателей производительности важно (как и в случае с Information Store) иметь эффективный механизм кэширования. Так, общий разрешенный размер всех журналов незавершенных транзакций для базы данных очереди сообщений определяется параметром DatabaseCheckPointDepthMax. По умолчанию его значение — 20 971 520 байт; это означает, что в памяти базы данных ESE, где хранится очередь сообщений, может содержаться не более 20 Мбайт несовершенных транзакций.
Настройку быстродействия транспортной службы можно выполнять, внося изменения в файл конфигурации приложения; возможно, вы захотите выполнить эту операцию для повышения производительности пограничного транспортного сервера или узлового транспортного сервера, через который проходит большой объем трафика. В версии Exchange 2007 специалисты Microsoft коренным образом переработали транспортную систему; теперь для захвата сообщений, проходящих через центральный транспортный сервер или граничный транспортный сервер, транспортная система использует базу данных ESE. Этот процесс протекает не так, как в системах Exchange 2003 и Exchange 2000, которые предусматривают запись файлов в файловую систему NTFS. ESE — полнофункциональный процессор баз данных, и вас не должно удивлять, что подстройка его быстродействия выполняется по-другому.
Перед внесением изменений даже на тестовом сервере следует ознакомиться с информацией, представленной командой разработчиков Exchange в посте «A study of Exchange 2007 SP1 Hub throughput with different message sizes» (http://msexchangeteam.com/archive/2008/05/16/448901.aspx). В нем можно найти ряд базовых критериев для настройки системы с целью обработки рабочих нагрузок, генерируемых при различных размерах сообщений от 25 Кбайт до 10 Мбайт.
Мой опыт подсказывает, что в крупных организациях средний размер сообщения колеблется в пределах от 70 Кбайт до 120 Мбайт, включая вложенные файлы. Большой разброс объясняется такими факторами, как, скажем, корпоративная культура. К примеру, если политика компании предусматривает, что ее служащие направляют объемные файлы в репозитории, такие как SharePoint, и по электронной почте передают только ссылки на эти файлы, а не сами файлы в виде вложений, средний размер сообщений в такой компании будет меньше. Размер сообщений можно увеличить, включая в документы и в файлы автоподписи, богатые графикой и логотипами корпораций.
В 1996 году средний размер сообщения составлял порядка 4 Кбайт. Логично предположить, что с течением времени этот показатель возрастает — несмотря на тот факт, что новейшие форматы документов, реализованные в пакете Office 2007, занимают меньше места, чем их предшественники. В статье «A study of Exchange 2007 SP1 Hub throughput with different message sizes» рассказано о том, как настраивать диски для транспортного механизма Exchange 2007 и как этот механизм масштабирует увеличение размеров сообщения, включая базовые этапы настройки, такие как увеличение размера транспортного кэша. Коллектив разработчиков Exchange более подробно рассматривает этот аспект настройки в статье «New maximum database cache size guidance for Exchange 2007 Hub Transport Server role» (http://msexchangeteam.com/archive/2008/05/14/448890.aspx), где разъясняется, когда может возникнуть необходимость в увеличении размера кэша базы данных на центральных транспортных серверах с большими объемами трафика.
Так что же, если вы обновили систему до уровня Exchange 2007 SP1, на этом можно и остановиться? Оказывается, все не так просто. Новые настройки применяются в тех случаях, когда пакет Exchange 2007 SP1 устанавливается на новый сервер, но не применяются, если осуществляется обновление сервера с уровня Exchange 2007 RTM до уровня SP1. Логика ясна: специалисты Microsoft не хотели переопределять оптимизированные настройки, которые, возможно, были зафиксированы в файле конфигурации приложения. Но разработчики вполне могли бы объединить новые настройки в существующий файл на селективной основе и известить системного администратора о том, что же, собственно, было сделано в процессе установки.
К сожалению, при существующем положении вещей в корпоративных сетях сегодня имеется множество пограничных и центральных транспортных серверов Exchange 2007, которые, казалось бы, функционируют под управлением SP1, но на деле используют настройки версии RTM.
Разумеется, эта проблема возникает лишь в тех случаях, когда в организации функционируют пограничные транспортные серверы или центральные транспортные серверы с большими рабочими нагрузками, сообщающие об обратном давлении или о других проблемах, связанных с производительностью. Как и любая база данных, хранилище, используемое для диска, который содержит базу данных с очередью сообщений, должно удовлетворять определенным требованиям к производительности, поэтому будем исходить из того, что азы вам известны и вы убрали из накопителя C или из любого другого накопителя, задействованного для выполнения рутинных функций, все файлы, применяемые транспортной системой, включая базу данных очереди сообщений. После этого любые указания на то, что у вас возникли транспортные проблемы, следует искать в записях журнала событий с ID 15006 (существенный недостаток дискового пространства) или ID 15007 (значительный недостаток памяти) журнала MSExchangeTransport; если же вы еще не обновили серверы до уровня SP1, обращайте внимание на события с ID 15002 и 15003.
В случае если в ходе проверок журналов регистрации событий на ваших центральных транспортных серверах ни одна из названных выше записей не обнаруживается и вы не получаете сообщений о том, что почта не доставляется с положенной скоростью, а также нет указаний на наличие на серверах других связанных с быстродействием проблем, тогда, по всей вероятности, настройки транспортного приложения указаны правильно и можно сосредоточиться на других вещах. Все это говорит о том, что когда Microsoft вносит усовершенствования в пакет обновлений и вы устанавливаете этот пакет, вполне возможно, что для гарантии точной настройки серверов вам все же придется проверить детали конфигурации.
Тони Редмонд (exchguru@windowitpro.com) — редактор журнала Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services