Exchange 2007 - Транспорт

О роли транспорта в Exchange 2007 и вообще о ролях Exchange 2007

Exchange 2003 может быть установлен и функционировать на отдельном сервере в роли back-end (по умолчанию) или front-end (после дополнительной конфигурации). В Exchange 2007 таких ролей стало пять. Такое увеличение произошло по двум причинам. Во-первых, в Exchange 2007 появилась новая функциональность, не попадающая под имеющуюся классификацию. Во-вторых, существующие роли были конкретизированы, чтобы иметь возможность более гибко использовать доступные аппаратные ресурсы и устанавливать только те части продукта, которые будут реально использоваться данной компанией/организацией. В результате при установке Exchange 2007 доступны следующие серверные роли:

  • Mailbox Server роль - это база данных где хранятся почтовые ящики пользователей и Public Folders. Эта роль также отвечает за хранение и управление календарями.
  • Client Access Server роль - это новое название знакомой по Exchange 2003 роли front-end. Эта роль позволяет организовать доступ к почтовым ящикам через Web (OWA), с мобильных устройств, через POP и IMAP, а также Web Services для разработки и интеграции с другими приложениями.
  • Unified Messaging Server роль позволяет принимать и направлять в почтовые ящики пользователей факсовые и голосовые сообщения, таким образом предоставляя унифицированный доступ ко всем типам сообщений. Эта роль также организует доступ по телефону к почтовым ящикам и календарям пользователей с помощью системы распознавания речи.
  • Hub Transport Server роль отвечает за маршрутизацию и пересылку сообщений между Exchange серверами внутри корпоративной сети ("внутри организации"). Сразу отмечу, что без этой роли невозможно организовать пересылку сообщений по SMTP между разными Mailbox серверами в сети организации.
  • Edge Transport Server роль устанавливается на серверах на периметре корпоративной сети (DMZ или "снаружи организации") и используется для контроля сообщений, приходящих в организацию из Internet и уходящих из организации в Internet. Здесь сообщения проходят через анти-вирусные и анти-спам фильтры.

Все роли кроме Edge Transport или любую их комбинацию можно устанавливать на одном физическом сервере. При инсталляции Exchange 2007 также можно выбрать опцию "Admin only", и тогда будут установлены только инструменты для администрирования Exchange. Иногда "Admin only" упоминают как отдельную роль.

Как видно из списка, за транспорт в Exchange 2007 отвечают две роли. О том, почему их две, и в чем разница между "внутри организации" и "снаружи организации" для Exchange, мы поговорим в следующий раз.

Published Monday, June 05, 2006 1:37 AM by gregour

Comments

 

msexpert said:

Привет, Григорий!
В принципе, все те же роли (за исключением UM Server, для этой функциональности использовались third party продукты) были и в Exchange 2000/2003:
Mailbox Server (2007) = Mailbox Server (back-end) (2000/2003)
Client Access Server (2007) = Front-End Server (2000/2003)
Hub Transport Server (2007) = Bridgehead Server (2000/2003)
Edge Transport Server (2007) = SMTP gateway / mail relay server (2000/2003)
Такое ощущение, что в сфере общего дизайна и архитектуры практически ничего нового не появилось. Зато о внутренней маршрутизации, имхо, стоит поговорить подробнее. Ведь в Exchange 12 больше нет routing groups, правильно? Вся маршрутизация строится на базе информации о сайтах AD? Как в связи с этим изменились маршрутизационные протоколы и алгоритмы? Строится ли по-прежнему дерево, link state, алгоритм Дийкстры и все прочее? Или просто берется репликационная схема AD и применяется к Exchange?
Заранее спасибо за разъяснения. Отличная идея с этими блогами!
June 6, 2006 4:42 PM
 

gregour said:

Большое спасибо за комментарии. Про роли и общую архитектуру: мне кажется, что Edge роль можно отнести к разряду новых хотя бы потому, что она может работать на отдельном сервере, который не принадлежит никакому домену (другими словами, Edge не использует AD). Об этом я собираюсь поговорить более подробно в обещанной теме про "внутри/снаружи организации". Также я бы отметил более четкое разграничение между Hub Transport и Mailbox ролями (чем в 2003 back-end) - на Hub невозможно создать почтовые ящики, а на Mailbox нет SMTP стэка. Но несмотря на эти аргументы, я очень рад был услышать Ваше мнение, так как находясь внутри проекта мы воспринимаем многие вещи по-другому, чем это видят люди "независимые".

Отдельная благодарность за интерес к маршрутизации - эта тема мне особенно дорога, так как я этому посвятил много времени. Обещаю обо всем этом поговорить подробно. В целом Вы правы - Exchange 2007 использует AD сайты вместо routing groups, так что больше нет необходимости дублировать информацию о топологии сети для Exchange и для AD репликации. Link state тоже больше не будет, а дерево строится только для внешних адресов. Следите за новыми материалами!
June 6, 2006 9:56 PM
 

msexpert said:

Спасибо, Григорий!

Мое внимание особенно привлекла вот эта фраза в Вашем ответе:
"Также я бы отметил более четкое разграничение между Hub Transport и Mailbox ролями (чем в 2003 back-end) - на Hub невозможно создать почтовые ящики, а на Mailbox нет SMTP стэка. "
Это очень интересно, и хотелось бы прочитать подробнее, как именно в Exchange 12 организован mail flow... идеально было бы прямо на уровне логической диаграммы, отдельно для исходящей и входящей почты. При этом интересна не только маршрутизация внутри Exchange организации, но и SMTP routing логика, например логические предпочтения и рекомендации при конфигурировании SMTP коннекторов и виртуальных серверов. Между прочим, для Exchange 2003/2000 тоже не существует четкого и ясного описания этой логики, приходится черпать информацию по крохам из десятков источников...

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

Ситуация: крупная компания использует сеть, состоящую из гетерогенных систем, сколько-то Windows, сколько-то Unix. Имеется также несколько messaging систем, включая Exchange, которые обязаны друг с другом сосуществовать. Вся загвоздка в том, что пользователи должны иметь ящики как на Unix серверах, так и на Exchange (ну, например, пользователь работает с Unix почтовиком со своей рабочей станции, однако таскает с собой Blackberry, на который тоже хочет получать всю почту :))
Это, конечно, некрасивая конфигурация (каждый пользователь имеет несколько копий своего почтового ящика на разных системах), но в общем жизнеспособная: ставится sendmail, который принимает все входящие письма и, сверяясь со специальной базой данных, выясняет, на каких почтовых системах у адресата имеются почтовые ящики. После чего письмо отсылается
(размножается) на все эти системы, естественно с модификацией SMTP заголовков.
При посылке письма происзодит нечто подобное - каждая почтовая система форвардит письмо на smart host, который определяет, является ли адресат локальным, и если да, то пересылает письмо на тот самый "размножитель".
Но ведь вот в чем засада: когда Exchange начинает обрабатывать исходящее сообщение, он сначала определяет, не является ли адресат локальным. И если да, то письмо напрямую (минуя даже SMTP) пересылается адресату, и на этом его обработка заканчивается, а на smart host мы благополучно забиваем.
Результат: пользователь получает письмо на свой Exchange mailbox (скажем, на Blackberry) и отвечает оттуда же. Адресат получит этот ответ ТОЛЬКО на свой Exchange mailbox, а на все другие почтовые системы оно не дойдет...
В Unix системах это решается просто: серверу говорится, что он должен форвардить на smart host невзирая ни на что, даже если адресат обнаружен локально. А в Exchange такое сделать невозможно...
Рассматривавшиеся варианты решения проблемы: event sink и игра с SMTP namespaces.

Ну вот, я изложил сумбурно, но суть проблемы, надеюсь, ясна. Хотелось бы услышать Ваше мнение.

Если будет интерес контактировать напрямую - мой алиас borisl :)
June 8, 2006 4:42 PM
 

gregour said:

Да, ситуация действительно интересная. Сразу скажу, что в Exchange 2007 все сообщения проходят через стандартную маршрутизацию на Hub Transport сервере. Никаких исключений для отправителя и получателя из одной MDB нет. Сделано это для из-за того, что на Hub Transport роли отрабатываются все messaging policies (например журнализация). Возвращаясь в 2003, хотел спросить, почему в такой ситуации не используются alternate recipients? Наверняка такое решение рассматривалось, так что хотелось бы узнать почему это не работает.

Мы действительно углубляемся в специфику данной ситуации, так что стоит продолжить напрямую. Сегодня улетаю на TechEd, так что новая информация после возвращения.
June 9, 2006 2:25 PM
 

msexpert said:

Спасибо за ответ. Про alternate recipients ( то есть forwarding to a contact, если я правильно Вас понял) я просто забыл упомянуть, sorry. Эта идея рассматривалась самой первой, потому что она наиболее очевидна. Но она не работает по двум причинам - во-первых, получается infinite message looping, когда письмо, отфорварженное на контакт, возвращается опять к получателю, а во-вторых, даже если looping как-то удастся исключить, то в ящике все равно окажутся по две копии письма (одна, доставленная сразу, и другая, прошедшая через contact forwarding).
Удачной поездки на TechEd. Have fun!
June 9, 2006 2:40 PM
Anonymous comments are disabled

This Blog

Syndication

Tags

No tags have been created or used yet.

News

Информация на данном сайте предоставляется "КАК ЕСТЬ" без каких-либо гарантий и передачи прав. Мнения, высказанные здесь, являются отражением моего личного взгляда, а не позиции работодателя.

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker