В наши дни многие компании самых разных размеров представлены не в одном, а в двух или даже в нескольких государствах. Часто они имеют несколько точек соединения, через которые подключенные к внутренним сетям пользователи могут выходить в Internet. Как правило, такие компании используют эти точки соединения в качестве точек входа и выхода сообщений электронной почты, входящих и исходящих из внутренней среды Exchange Server. Маршрутизация исходящей почты через самую близкую географически точку выхода обычно проблем не представляет. Нужно просто использовать коэффициенты стоимости, ассоциированные с группами маршрутизации и с коннекторами (как разъясняется во врезке " Оптимизация исходящего потока электронной почты"). Организовать интеллектуальную маршрутизацию входящей электронной почты через точку входа, ближе других расположенную к получателю сообщения, сложнее. Однако вы сможете реализовать такой механизм маршрутизации с помощью базовых функций системы Exchange Server 2003.

Оптимизации потока входящей электронной почты с использованием средств пространства имен

Простейший механизм оптимизации трафика входящей электронной почты состоит в том, что в почтовый адрес включается компонент, указывающий на географический регион, куда должно быть направлено сообщение еще в процессе прохождение по каналам Internet. Представьте, к примеру, что базирующийся в США служащий Уилли Нелсон имеет электронный адрес Willie.Nelson@us.cantaz.com. Чтобы оптимизировать входящий почтовый трафик, нужно опубликовать запись DNS MX, в соответствии с которой все сообщения с адресами, содержащими компонент us.cantaz.com., должны направляться на ретранслятор почты mailrelay.us.cantaz.com, расположенный в США. Тогда почтовые сообщения, направляемые Уилли, будут поступать к нему по самому эффективному маршруту на SMTP-коннектор, расположенный ближе всего от того места, где он находится. Обычно в такую MX-запись включаются и другие точки входа с указанием на то, что расходы на передачу сообщений в эти точки будет выше. Таким образом, даже в том случае, если самая малозатратная точка входа выйдет из строя, сообщение тем не менее будет доставлено. Впрочем, надо иметь в виду, что результат перенаправления сообщения на более затратный ретранслятор в связи с отказом будет неоптимальным с точки зрения использования ресурсов. Подобным же образом, все остальные связанные с конкретными точками записи MX будут настраиваться с использованием резервных серверов-ретрансляторов почты.

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

Оптимизации потока входящей электронной почты методом перенаправления адресов

Оптимизация потока входящей электронной почты с использованием адресов, содержащих указание на географическое местоположение получателя, представляет собой эффективное решение, но оно не вполне эстетично; к тому же таким образом нельзя получить согласованный формат почтового адреса для всей компании. Более того, компании, как правило, не хотят пользоваться адресами, указывающими на местоположение; обычно корпоративные клиенты предпочитают пользоваться нормализованными, или плоскими почтовыми адресами (такими, как, скажем, cantaz.com). А плоские почтовые адреса не дают возможности формировать механизмы для интеллектуальной маршрутизации сообщения в заданную географическую точку. При работе с пространствами плоских адресов можно использовать перенаправление адресов: ретранслятор SMTP принимает сообщение электронной почты у точки входа, преобразует его в форму, содержащую указание на местоположение адресата, и затем перенаправляет сообщение обратно в Internet, где оно обрабатывается средствами интеллектуальной доставки в соответствующую географическую точку. Такой механизм представлен на Рис. 2. В данном примере электронное сообщение направляется пользователю Джонни Кэшу по плоскому адресу Johnny.Cash@cantaz.com. Запись MX, ответственная за обработку SMTP-домена cantaz.com, направляет всю адресованную в этот домен почту расположенному в США SMTP-ретранслятору gatekeeper.us.cantaz.com. Когда этот ретранслятор приступает к обработке вновь поступивших на адрес Johnny.Cash@cantaz.com электронных посланий, он, сверившись с таблицей маршрутизации, указывающей на тот или иной каталог, определяет, что данный пользователь находится не в Соединенных Штатах, а в Европе. Соответственно, gatekeeper.us.cantaz.com переписывает содержащийся в сообщении почтовый адрес, меняя cantaz.com на eu.cantaz.com. Сообщение, адресованное теперь получателю Johnny.Cash@eu.cantaz.com, доставляется уже другому SMTP-ретранслятору, а именно, gatekeeper.eu.cantaz.com, благодаря MX-записи для eu.cantaz.com. По получении сообщения gatekeeper.eu.cantaz.com доставляет его получателю.

Создание соответствующей сетевой инфраструктуры

Архитектура, представленная на Рис. 2, обеспечивает успешное выполнение задач маршрутизации благодаря использованию ряда факторов. Один из этих ключевых факторов состоит в том, что почта, полученная в одной географической точке, но предназначенная для другой географической точки, не просто перенаправляется в эту другую точку, но перенаправляется туда через Internet.

В основе архитектуры интеллектуальной маршрутизации сообщений электронной почты лежит следующая идея: снять нагрузку с внутренних почтовых систем таким образом, чтобы сообщения, предназначенные для пользователей, находящихся в той или иной географической точке, передавались в эту точку с использованием наименьшего объема внутренних ресурсов. В только что рассмотренном примере ретранслятор SMTP (т.е. gatekeeper.us.cantaz.com), приводящий адрес получателя Johnny.Cash@cantaz.com к виду Johnny.Cash@eu.cantaz.com, не является частью организации Exchange. Если бы в адрес не было внесено каких-либо изменений, американская организация Exchange просто приняла бы это сообщение и затем по каналам внутренней сети Exchange передала бы его соответствующему серверу почтовых ящиков. Сообщение прошло бы через группы маршрутизации и через серверы Routing Group Connector (RGC). Выполнив процедуру модификации адреса и задействовав внутреннюю запись MX, система обеспечила эффективную (в той или иной мере) маршрутизацию сообщения, что способствовало снижению нагрузки в организации Exchange. Однако этот подход предполагает некоторую нагрузку на внутрисетевые каналы, поскольку сообщение было принято в сеть компании и перенаправляется по внутренним трансатлантическим сетевым соединениям. Иначе говоря, описанный мною подход - это некоторый шаг вперед в сфере перенаправления электронной почты, но возможности для дальнейшего совершенствования остаются открытыми. Перенаправление сообщений по каналам Internet освобождает от нагрузки внутренние трансатлантические сетевые каналы. Как показано на Рис. 3, организовать такой предпочтительный маршрут перенаправления совсем несложно. Для этого нужно сконфигурировать MX-запись для eu.cantaz.com таким образом, чтобы последний разрешался в имя хоста, доступного лишь по каналам Internet и никогда - по внутрисетевым каналам. Я старался не перегружать свой пример излишними деталями, и потому исходил из предположения, что все поступающие в домен cantaz.com сообщения имели лишь одну точку входа, а именно - ретранслятор почты SMTP gatekeeper.us.cantaz.com. А что если имеется два "привратника": один в американском домене, а другой - в европейском? Если 50 процентов всех почтовых отправлений в адрес cantaz.com предназначены для получателей в Соединенных Штатах, а 50 процентов - для получателей, находящихся в Европе, тогда для обеспечения устойчивости системы почту для домена cantaz.com можно с помощью MX-записей с равной стоимостью распределить между ретрансляторами gatekeeper.us.cantaz.com и gatekeeper.eu.cantaz.com. Почтовый SMTP-ретранслятор gatekeeper.eu.cantaz.com будет модифицировать адреса поступающих сообщений для получателей в США, заменяя строку cantaz.com строкой us.cantaz.com и направляя эти сообщения через Internet на почтовый ретранслятор gatekeeper.us.cantaz.com.

Однако если 70 процентов поступающей в домен cantaz.com почты будет предназначено для получателей в Соединенных Штатах и только 30 процентов - для получателей в Европе, такой механизм распределения нагрузки нельзя будет считать рациональным. В этом случае 35 процентов всей поступившей почты будет перенаправляться из Европы в Соединенные Штаты и 15 процентов всей поступившей почты будет перенаправляться из Соединенных Штатов в Европу; таким образом, перенаправлению будет подлежать 50 процентов от всего объема почтовых отправлений. Если же почта для домена cantaz.com не будет распределяться по нескольким ретрансляторам с целью снижения нагрузок на каждый из них, а будет поступать только на ретранслятор gatekeeper.us.cantaz.com, тогда перенаправлять придется лишь 30 процентов сообщений от числа всех полученных. Названные выше показатели приводятся только для иллюстрации. Разные почтовые программы SMTP по-разному обрабатывают зафиксированные в записях MX показатели стоимости, так что на практике доли перенаправляемых сообщений более или менее соответствуют названным мною показателям. Однако при том, что метод распределения нагрузки в этом примере явно не является оптимальным, все же есть смысл предусмотреть его в виде MX-записи для cantaz.com с меньшим уровнем предпочтения - с тем, чтобы полный выход из строя ретранслятора gatekeeper.us.cantaz.com не повлек за собой прекращения доставки корпоративной почты. Следовательно, для организации интеллектуальной и эффективной маршрутизации электронной почты целесообразно, проанализировав реальную статистику потоков почтовых сообщений, выяснить, каковы конечные адресаты поступающих писем и затем соответственно сконфигурировать и установить стоимость в MX-записях.

Успешная модификация адресов почтовых сообщений

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

К настоящему времени разработано множество SMTP-агентов для передачи сообщений MTA (SMTP Message Transfer Agent); на ум приходит бесплатно распространяемый продукт Postfix и агент PMDF фирмы Process Software. Почти все они облегчают обработку сообщений SMTP в сочетании с просмотрами каталогов и модификацией адресов (т.е. заголовков). Кроме того, вы можете воспользоваться входящим в комплект поставки Exchange 2003 средством Exchange Address Rewrite Tool, известным также под названием Exarcfg. Это средство является частью набора инструментов Exchange 2003 RTW (release to Web), и его можно загрузить по адресу http://www.microsoft.com/exchange/downloads/2003/default.mspx. После загрузки исполнимого файла exarcfg.exe запустите его на исполнение. Программа создаст папку Exarcfg, содержащую утилиту конфигурации (она тоже называется exarcfg.exe), файл лицензионного соглашения и документацию.

Утилиту Exarcfg можно запускать из административной учетной записи на любой системе (она не обязательно должна быть сервером Exchange) из леса Active Directory (AD), содержащего систему Exchange, на которой вы хотите выполнять модификацию адресов. Для успешного функционирования утилиты Exarcfg требуется, чтобы учетная запись, с которой вы ее запускаете, являлась членом группы Local Administrators на сервере Exchange и имела административные полномочия на уровне организации Exchange. В рассмотренном нами примере ретранслятор gatekeeper.us.cantaz.com находился внутри собственной организации Exchange - а значит, в собственном лесу. Это необходимое условие, поскольку указанные в среде модификации пользовательские объекты будут принимать участие в процессе модификации адресов, а эти адреса будут отличаться по своей природе от почтовых адресов, указанных в той организации Exchange, где содержатся почтовые ящики пользователей. В сущности ретранслятор gatekeeper.us.cantaz.com просто-напросто выполняет SMTP-функцию обработки и практически не имеет отношения к организации Exchange, где размещаются почтовый ящик конечного получателя. Такое ограничение ретрансляционных систем от целевой организации Exchange имеет важное значение. Без него невозможна реализация функции модификации адреса и перенаправления электронной почты.

Чтобы SMTP-система ретрансляции электронной почты могла осуществлять модификацию почтовых адресов, надо активизировать соответствующую функцию на этой системе. Для этого откройте окно командной строки и (на одной строке) выполните следующую команду:

exarcfg -e -s:  -v:

где параметр -e предписывает Exarcfg активизировать функцию модификации адресов; параметр -s указывает, на каком сервере вы хотите ее активизировать; вместо server следует указать FQDN-имя (Fully Qualified Domain Name) этого сервера, а параметр -v обозначает виртуальный сервер SMTP, где vsi - это фактический экземпляр виртуального сервера (как правило, 1 для стандартного экземпляра виртуального сервера). Таким образом, для того чтобы активизировать функцию модификации адресов на стандартном экземпляре виртуального сервера SMTP расположенного в США сервера-ретранслятора электронной почты, используйте команду

exarcfg -e -s: gatekeeper.us.cantaz.com -v: 1

Стоит добавить, что Exarcfg позволяет также использовать параметр -l, выводящий список текущих настроек данного сервера, и параметр -d, отключающий функцию модификации адресов на данном сервере. Если при использовании параметра -l одновременно не будет задан параметр -s, Exchange возвратит текущие настройки всех серверов данного домена.

При выполнении утилиты Exarcfg устанавливается последний бит эвристического атрибута указанного сервера Exchange, поэтому ту же функцию можно активизировать на SMTP-системе ретрансляции почты с помощью средства ADSI Edit. Нужно переместиться на DC=com, DC=cantaz, CN=Configuration, CN=Services CN=Microsoft Exchange, CN=cantaz CN=Administrative Groups, CN=relay, CN=ServersCN=gatekeeper, CN= Protocols, CN=SMTP, CN=1. Затем нужно выбрать эвристический атрибут и заменить его стандартное значение (131072) на 131073.

После активизации функции модификации адресов на сервере Exchange SMTP-адреса всех сообщений, которые служба SMTP получает, выступая в роли ретранслятора, будут модифицироваться службой Transport. Сервер Exchange должен обнаружить либо соответствующий контакт, оснащенный средствами для обработки электронной почты, либо оснащенный такими же средствами объект "пользователь" с локальным AD (но не с AD целевой организации Exchange). Соответствующий объект должен иметь вторичный прокси-адрес SMTP, совпадающий с текущим SMTP-адресом сообщения, а первичный SMTP-адрес данного объекта должен представлять собой модифицированный SMTP-адрес. В нашем примере ретранслятор gatekeeper.us.cantaz.com получает сообщения, адресованные получателю Johnny.Cash@ cantaz.com и переадресовывает их получателю Johnny.Cash@eu.cantaz.com. На Рис. 4 показан объект AD, облегчающий эту модификацию адресов.

Когда происходит модификация адреса, SMTP-система ретрансляции перенаправляет сообщение обратно в Internet, и оно доставляется ретранслятору gatekeeper.eu.cantaz.com. Этот расположенный в Европе ретранслятор почты, располагающийся, как правило, в отдельной организации Exchange (хотя он может находиться в той же организации, что и американский SMTP-ретранслятор почты), никаких манипуляций с адресом не производит, а просто переправляет сообщение серверу-мосту SMTP в целевой организации Exchange. Объект "пользователь", представляющий почтовый ящик Exchange для получателя, имеет два адреса SMTP: почтовый адрес, содержащий указание на географическую точку, должен быть вторичным прокси-адресом SMTP, обеспечивающим доставку сообщения, но первичный адрес SMTP должен быть нормализованным SMTP-адресом, как показано на Рис. 5. Таким образом, первичный и вторичный адреса SMTP между модифицированным объектом и фактическим пользовательским объектом являются зеркальными отображениями друг друга. Для того чтобы организация Exchange принимала все требуемые почтовые адреса, вам придется создать соответствующие политики для получателей.

Используйте интеллектуальные механизмы маршрутизации почты

Исторически сложилось так, что проблему оптимизации входящей почты было трудно разрешить, не прибегая к использованию неудобного формата адресации. Однако с появлением Exchange 2003 администраторы получили возможность - предварительно выделив какое-то время на планирование и настройку конфигурации - осуществлять интеллектуальную маршрутизацию поступающих из Internet сообщений электронной почты. Правда, при этом требуется поддерживать необходимую конфигурацию, что может оказаться довольно сложным делом. Так или иначе, вам нужно будет обслуживать, по меньшей мере, две организации Exchange: одну для пользователей, а другую - для объектов модификации адресов. Чтобы доставка почты не прерывалась, нужно обеспечивать постоянную синхронизацию каталогов двух этих сред. Существует множество инструментов, с помощью которых можно выполнять синхронизацию. Одно из таких средств - Microsoft Identity Integration Server (MIIS); если ввести в поле поиска системы Google слова directory synchronization tools, можно обнаружить и многие другие программы. И, кроме того, для организации контроля за потоком почтовых сообщений вам придется модифицировать MX-записи вашей организации. Поэтому я рекомендую прежде всего решить вопрос о том, действительно ли есть необходимость в переадресации сообщений. Для этого нужно, проанализировав статистику почтового трафика, подсчитать, перекроет ли экономия за счет снижения нагрузки на внутрисетевые каналы передачи данных затраты, связанные с настройкой. В многонациональных организациях переадресация часто бывает вполне оправданной. Конечно, многое зависит от конкретных обстоятельств, но вполне вероятно, что вы сможете высвободить международные каналы связи для более рационального использования или сократить издержки за счет сужения полосы пропускания на этих каналах. Если вы уже близки к точке насыщения, реализация интеллектуальных механизмов маршрутизации электронной почты почти наверняка позволит вам высвободить ценные сетевые ресурсы и сократить время доставки почты.

Киран Маккорри (kieran.mccorry@hp.com), главный консультант подразделения HP Advanced Technology Group. Живет и работает в Ирландии. Обладатель сертификата Microsoft Exchange MVP. Последняя из опубликованных им книг - Microsoft Exchange Server 2003 Deployment and Migration (издательство Digital Press).

ОПТИМИЗАЦИЯ ИСХОДЯЩЕГО ПОТОКА ЭЛЕКТРОННОЙ ПОЧТЫ

Создание оптимального механизма маршрутизации исходящей электронной почты с выходом в Internet через ближайший коннектор SMTP - довольно простой процесс. При этом снижается нагрузка на внутренние каналы связи распределенной сети, а почта быстро попадает в Internet, поскольку маршруты ее прохождения по внутренней сети сокращаются. Для получения подобной конфигурации следует объединить серверы в географические группы маршрутизации, каждая из которых содержит выделенный коннектор SMTP. Эти выделенные локальные коннекторы SMTP ассоциируются с более низкими показателями стоимости, нежели агрегированная стоимость SMTP-коннекторов из других групп маршрутизации. Поскольку Exchange Server направляет электронную почту в Internet через свободный коннектор, имеющий самую низкую стоимость, предполагаемая к передаче по каналам Internet электронная почта обычно направляется на местный SMTP-коннектор. На Рис. A представлена примерная конфигурация, в которой электронная почта, направляемая в Internet с сервера почтовых ящиков Exchange в данной группе маршрутизации, будет всегда проходить через SMTP-коннектор той же группы маршрутизации, потому что стоимость в данном случае (10) всегда ниже, чем стоимость использования любого другого коннектора SMTP (минимальная стоимость 110, максимальная - 210).

us.cantaz.com MX preference = 10, mail exchanger = mailrelay.us.cantaz.com
us.cantaz.com MX preference = 20, mail exchanger = mailrelay.eu.cantaz.com
us.cantaz.com MX preference = 30, mail exchanger = mailrelay.ap.cantaz.com

Рис A: Пример записи DNS MX.

Рис. 1: Оптимальная маршрутизация входящих сообщений с использованием пространства имен

Рис. 2: Перенаправление электронной почты методом модификации адресов

Рис. 3: Наиболее предпочтительный маршрут доставки электронной почты

Рис 4: Свойства объекта с модифицированным адресом (??)

Рис 5: SMTP-адрес почтового ящика получателя