Receive connectors: Hub transport или Frontend Transport?


Сразу скажу, что речь идёт исключительно про Exchange Server 2013 (и раздельных CAS и Mailbox ролях). Недавно на форумах TechNet-RU увидел рекомендацию одного из участников по созданию анонимного коннектора получения (receive connector) с привязкой к сервису Hub transport – фактически к серверу MailBox. Эту рекомендацию следом повторил другой участник форума. Это меня озадачило (почему опишу ниже) и я решил посмотреть, что по этому поводу рекомендуетTechNet. К моему огромному удивлению на TechNet действительно обнаружилось описание процедуры создания коннектора с привязкой к сервису Hub transport.

Вот список статей TechNet с описанием создания коннектора получения и отметкой, к какому сервису делается привязка:

Frontend transport  — Create a Receive connector to receive email from the Internet

Frontend transport  — Create a secure Receive connector to receive email from a partner

Hub Transport  —  Create a Receive connector to receive email from a system not running Exchange

Hub Transport  —  Create a Receive connector to receive messages from an internal Exchange server

Собственно вопрос о третьей статье, которую по всей видимости читают и цитируют: почему внешний по отношению к Exchange отправитель должен подключаться к MBX и сервису Hub transport?

Именно это меня озадачило и вот почему. Exchange Server 2013 имеет новую архитектуру и состоит их двух основных частей: CAS – client access server или FrontEnd и MBX – mailbox server или BackEnd. В этой архитектуре все клиенты должны подключаться к FrontEnd или CAS серверу. Под клиентами тут подразумевается не только пользовательские клиенты (Outlook и т.п.), но и серверные приложения (иные почтовые системы, Sharepoint и т.п.). Теоретически (и фактически тоже) MBX может иметь клиентский коннектор, но стоит ли так делать как рекомендует TechNet?

Вот более детальное разъяснение по новой архитектуре от одного из разработчиков Exchange Server Ross Smith IV:

«The Front-End Transport service provides network protection – a centralized, load balanced egress/ingress point for the Exchange organization, whether it be POP/IMAP clients, SharePoint, other third-party or custom in-house mail applications, or external SMTP systems.

For incoming messages, the Front-End Transport service must quickly find a single, healthy Transport service on a Mailbox server to receive the message transmission, regardless of the number or type of recipients…»

Речь идёт о том, что все клиенты должны подключаться к CAS (Front-End Transport) и что Front-End Transport сам находит наиболее подходящий MBX сервер для обработки трафика.

Если же привязать клиента прямо к конкретному серверу MBX, то тот может в какой-то момент оказаться в нерабочем состоянии: на обслуживании или в аварии. Таким образом подключение к CAS серверу или даже к балансировщику перед массивом CAS серверов является более надежным фактически и более правильным архитектурно.

По идее Technet должен рекомендовать то же самое, и я могу предположить, что статья TechNet является просто «copy-paste» от старых версий Exchange, в которых «Hub Transport» тоже есть, но представляет собой совсем другой сервис!

Полезные ссылки:

  1. Exchange 2013 Client Access Server Role
  2. Exchange 2013 Mail Flow Demystified…Hopefully!
  3. Mail flow
  4. Mail routing

Дополнение.

Как уточнил Михаил Готч, в многоролевом сервере службы Front-End Transport  и Hub Transport находятся на одном сервере и реализуются в виде двух отдельных процессов: первый занимает порт 25, а второй порт 2525; если ко второму попробовать привязать коннектор с портом 25, то команды выполнятся, но два процесса будут захватывать один и тот же порт 25, что приводит к аварийному завершению одного их этих процессов. Это ещё один аргумент пользу создания коннектора получения с привязкой к Front-End Transport/CAS. Возможен вариант указания не порта 25, а иного, но во-первых, большинство почтовых систем/клиентов не имеют настройки альтернативного порта SMTP, а во-вторых, ситуация в этом случае сводится к рассмотренной в основном тексте статьи.

Реклама

комментария 2

  1. Илья, создать такой коннектор можно, но делать это категорически нельзя. Receive Connector должен быть привязан только к Frontend. Иначе SMTP служба будет работать с непредсказуемыми ошибками
    https://exchangemaster.wordpress.com/2014/01/24/incorrectly-adding-new-receive-connector-breaks-exchange-2013-transport/

    Я лично ходил по этим ошибкам — SMTP служба падала каждые 2 часа.

    • Спасибо за замечание, Михаил. Это ещё один аргумент за создание коннектора на FrontEnd. Я держал в голове конфигурацию с раздельными ролями, когда писал эту статью. Сейчас внёс уточнение в текст.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: