В данной статье мы рассмотрим нововведения и изменения в маршрутизации сообщений, появившиеся в Microsoft Exchange 2013. Будут описаны важные различия в доставке сообщений, рассмотрена внутренняя маршрутизация почты. В завершающей части статьи мы проследим весь путь сообщения, проходящего через все механизмы маршрутизации Exchange 2013, и рассмотрим важные для разработчиков изменения, коснувшиеся очередей сообщений.
В сравнении с версиями 2010 и 2007, в Exchange 2013 появились серьёзные изменения архитектурного характера. Некоторые из этих изменений влияют исключительно на внутреннюю маршрутизацию почты, но есть и такие, которые оказывают влияние на процесс доставки сообщений. Для понимания работы механизмов доставки сообщений в Exchange 2013 важно понимать, как устроена система.
Для понимания того, как происходит маршрутизация сообщений в новой архитектуре Exchange 2013, необходимо понимание того, как устроены серверные роли в новой архитектуре. Как мы уже говорили, в Exchange 2013 произошли серьезные архитектурные изменения, коснувшиеся в том числе и ролей серверов. Вместо пяти ролей сервера, реализованными в Exchange 2007 и 2010, в редакции 2013 количество серверных ролей сократилось до двух. Оставшиеся серверные роли включают роль сервера клиентского доступа и сервера почтовых ящиков. Важно отметить отсутствие в последней версии Exchange такой важной роли, как роль центрального транспортного сервера Hub Transport. Эта роль была упразднена, а её функции распределены между ролями сервера клиентского доступа и почтовых ящиков. Итак, вот полный список ролей, доступных в Exchange 2013:
В результате изменений в архитектуре Exchange 2013 многие вещи стали недоступны, встроены или переопределены. Упразднены многие серверные роли – в частности, имевшая ранее важное значение роль Hub Transport. Рассмотрим, что исчезло из Exchange 2013.
Exchange 2013 более не поддерживает выделенный сервис MAPI. В данной редакции Exchange Server, соединения MAPI инкапсулированы в обёртку RPC-over-HTTPS, что позволяет внешним Интернет-клиентам получать безопасный доступ к Microsoft Exchange Server без необходимости предварительной авторизации в VPN.
В версии Exchange 2013 Microsoft не поставляет роль пограничного транспортного сервера Edge Server. Отдельной сущности Edge Server в Exchange 2013 более не существует, а предоставляемые им сервисы теперь обеспечиваются сервером клиентского доступа. В документации Microsoft отмечается, что при насущной необходимости Exchange 2013 будет работать с ролью Edge Server из состава Exchange 2007 или 2010.
Изменения в архитектуре Exchange 2013 привели к ряду важных последствий. Упразднены многие роли сервера – в Exchange 2013 их осталось всего две. Новые роли разделены таким образом, чтобы резко упростить внедрение в масштабе предприятия. Оставшиеся роли сервера не имеют тесной связи между собой. Сервер почтовых ящиков теперь выполняет все виды нагрузки, связанные с обработкой активных почтовых ящиков, а сервер клиентского доступа отвечает за авторизацию и перенаправление клиентов, а также выполняет роль прокси. Новое распределение ролей весьма логично, т.к. активная копия почтовой базы физически расположена на почтовом сервере. Передача ответственности почтовых ящиков соответствующей серверной роли обеспечивает полный цикл обработки данных в локальной копии почтовой базы данных, что в свою очередь уменьшает количество взаимодействий между сервером почтовых ящиков и сервером клиентского доступа.
Сервер клиентского доступа не сохраняет данных о состоянии или сеансе. Как сервер клиентского доступа, так и сервер почтовых ящиков могут обновляться или перезагружаться независимо друг от друга. Важное следствие независимых обновлений – сервер почтовых ящиков и сервер клиентского доступа могут быть разных версий и будут корректно продолжать совместную работу.
Новая архитектура всего с двумя ролями значительное повлияла на транспортный процесс. Сообщения в Exchange 2013 передаются через транспортный конвейер. Весь входящий SMTP трафик обслуживается новой службой Front End Transport. В текущей редакции Exchange транспортный конвейер состоит из следующих частей:
Служба Front End Transport принадлежит роли сервера клиентского доступа и обслуживает весь внешний трафик SMTP. Данная служба исполняется на сервере клиентского доступа. Служба Front End Transport не сохраняет данных о состоянии или сеансе, исполняя роль прокси для всех входящих и исходящих соединений. Служба Front End Transport обладает следующими свойствами:
Служба Transport выполняется на всех серверах почтовых ящиков. Эта служба используется в Exchange 2013 вместо серверной роли центрального транспортного сервиса Hub Transport, которая была удалена в редакции Exchange 2013. Транспортная служба Transport обрабатывает весь входящий и исходящий трафик SMTP. Транспортная служба Transport обладает следующими свойствами:
Служба Mailbox Transport выполняется на всех серверах почтовых ящиков. Данная служба состоит из двух самостоятельных служб:
Как мы упоминали ранее, в состав Exchange 2013 более не входит пограничный транспортный сервер Edge Server. Соответственно, внешние сообщения могут обрабатываться одним из следующих способов:
Очевидно, по умолчанию предлагается использовать сервер клиентского доступа. В таком сценарии внешние почтовые сообщения будут приняты коннектором получения (Receive) службы Front End Transport, после чего будут маршрутизированы транспортной службе Transport на сервере почтовых ящиков.
В отличие от Exchange 2010 и 2007, Exchange 2013 способен принимать сообщения из Интернет в стандартной конфигурации. Сервер клиентского доступа поставляется с уже настроенным коннектором получения (Receive Connector), что и позволяет принимать сообщения из-за пределов локальной сети. Коннектор Receive по умолчанию назван “Default Frontend <название_сервера>”, и способен обрабатывать анонимные соединения (разрешён доступ анонимным пользователям “Anonymous Users”):
Сообщение может попасть в транспортную службу Transport на сервере почтовых ящиков одним из следующих четырёх способов:
Собственно транспортная служба Transport состоит из следующих процессов и компонент:
На приведённой ниже схеме показаны компоненты Exchange 2013 и их взаимосвязи:
Роль транспортных агентов не изменилась с предыдущей редакции Exchange. Транспортные агенты – это пользовательские расширения для обработки сообщений, проходящих через транспортный конвейер.
Организации могут создавать собственные агенты или использовать готовые транспортные агенты из состава поставки Microsoft Exchange. Кроме того, на рынке доступно множество агентов, разработанных сторонними компаниями.
Частный случай применения транспортных агентов – перехват сообщений, полученных по протоколу SMTP, и их конвертация в простой текст. Другой пример – обработка сообщений с целью удаления вложений или добавления обязательной корпоративной подписи. Важно отметить, что транспортные агенты имеют полный доступ ко всем сообщениям, поступающим к ним в обработку. В Exchange не предусмотрено внутренних защитных механизмов или «песочницы»; в результате действия транспортных агентов никак не контролируются и не ограничиваются. Соответственно, ошибки в коде транспортного агента могут привести к нарушению работы всего почтового конвейера. По этой же причине не рекомендуется использование агентов из непроверенных источников и с точки зрения информационной безопасности. В то же время транспортные агенты, полученные из надёжных источников могут принести немалую пользу.
В Exchange 2013 доступно несколько типов транспортных агентов: SmtpReceiveAgent (агент получения), RoutingAgent (агент маршрутизации) и DeliveryAgent (агент доставки). В состав пакета Exchange 2013 входит несколько встроенных транспортных агентов. Большинство встроенных агентов невидимы и недоступны из пользовательского интерфейса. Только небольшую часть транспортных агентов можно увидеть, выполнив команду Get-TransportAgent:
Итак, мы рассмотрели основные изменения в архитектуре Exchange 2013 в сравнении с более ранними версиями. Рассмотрим теперь, как в Exchange 2013 реализованы механизмы маршрутизации и категоризации почты. Эта глава в основном теоретическая; в ней будет много текста и почти не будет иллюстраций. Знакомство с теоретическими основами маршрутизации в Exchange 2013 важно для правильного понимания того, как входящее сообщение достигает конечной точки назначения. Если для вас больший интерес представляет практика, вы можете пропустить эту главу и перейти к следующей части, в которой будет отслежен маршрут почтового отправления через все службы и механизмы Exchange.
Направление сообщения к месту назначения осуществляется транспортной службой Transport, которая выполняется на всех серверах почтовых ящиков. Решение о том, каким образом будет проложен маршрут для каждого конкретного сообщения, принимается в результате категоризации. Категоризация – важная часть транспортной службы. В процессе категоризации обрабатывается вся входящая почта и определяются действия по доставке в зависимости от точки назначения сообщения. В первой главе мы описали архитектурные изменения в Exchange 2013. В результате этих изменений транспортная служба физически расположена непосредственно на серверах почтовых ящиков, что позволило улучшить процесс маршрутизации. В результате архитектурных изменений процесс маршрутизации получает всю информацию о группах Database Availability Group (DAG). Членство в группе DAG используется в качестве границы маршрутизации.
Что это означает на практике? Использование сайта Active Directory в качестве первичной границы маршрутизации неэффективно при распространении группы DAG на множество сайтов Active Directory. Соответственно, если почтовый ящик принадлежит какой-либо группе DAG, маршрутизация сообщений становится тесно связанной с данной группой.
Разумеется, если сервер почтовых ящиков не принадлежит ни к одной группе DAG, Exchange 2013 продолжает использовать членство в сайте Active Directory в качестве границы маршрутизации. В этом случае поведение Exchange 2013 не будет отличаться от поведения предыдущих версий.
Сам процесс маршрутизации претерпел существенные изменения в версии Exchange 2013. На рисунке ниже показана работа транспортного конвейера в Exchange 2013:
Все сообщения, полученные транспортной службой Transport, должны в обязательном порядке пройти категоризацию. Это необходимо для корректной маршрутизации до конечного пункта назначения. В процессе категоризации в первую очередь определяется адресат. Конечный пункт назначения сообщения определяется только после того, как будет определён адресат. Наконец, после определения пункта назначения Exchange вычисляет маршрут, по которому сообщение должно будет проследовать для доставки конечному получателю. Маршрутный пункт назначения определяется следующим образом:
В Exchange 2013 введено новое понятие группы доставки - Delivery Group. В архитектуре Exchange 2013, каждому пункт назначения маршрутизации соответствует один или несколько транспортных серверов. Роль транспортного сервера может выполнять или сервер почтовых ящиков Exchange, или транспортный сервер Exchange 2010 Hub Transport. Эти транспортные серверы получили названия групп доставки - Delivery Group. Группы доставки несут ответственность за маршрутизацию сообщения до конечной точки назначения.
Процесс усложняет ещё и тот факт, в группе доставки могут сосуществовать транспортные серверы разных версий. Если маршрутный пункт назначения – база данных почтовых ящиков, то версия транспортного сервера в группе доставки будет совпадать с версией Exchange в базе данных почтовых ящиков. Если же маршрутный пункт назначения – коннектор или сервер расширения группы рассылки, то группа доставки может состоять из множества серверов почтовых ящиков Exchange 2013 и транспортных серверов Exchange 2010 Hub Transport.
В Exchange 2013 определено пять типов групп доставки:
Членство в группе доставки не является эксклюзивным. К примеру, сервер почтовых ящиков Exchange 2013 может одновременно являться членом группы DAG и в то же время выполнять роль исходного сервера при коннекторе отправки Send. С точки зрения баз данных почтовых ящиков в группе DAG, данный сервер почтовых ящиков принадлежит к маршрутизируемой группе доставки DAG. В то же время с точки зрения коннектора отправки Send, тот же сервер служит коннектором группы доставки исходного сервера.
При доставке сообщения в удалённую группу доставки, Exchange 2013 должен определить корректный маршрут. Алгоритм определения маршрута не изменился с предыдущей версии. Exchange попытается определить маршрут с наименьшей стоимостью. При равной стоимости нескольких маршрутов будут учтены и другие параметры:
Новая архитектура Exchange 2013 с двумя серверными ролями оказала значительное влияние на транспортный процесс. Попробуем проследить весь маршрут сообщения, полученного системой Exchange с момента получения и до момента доставки в конечный пункт назначения. В этой части статьи мы рассмотрим работу транспортной службы Front End Transport и транспортной службы почтовых ящиков Mailbox Transport. В заключительной части статьи мы рассмотрим функционирование очередей.
Новая транспортная служба Front End Transport отвечает за приём и отправку внешних сообщений по протоколу SMTP. Служба Front End Transport принимает соединения по протоколу SMTP, выполняет фильтрацию и определяет маршрут к оптимальному серверу почтовых ящиков перед началом процесса доставки.
Служба Front End Transport всегда располагается на сервере клиентского доступа, и именно она играет роль централизованной точки входа и выхода для всего SMTP-трафика организации. Служба Front End Transport не сохраняет данных о состоянии или сессии. Эта служба принципиально отличается подходом к приему и доставке сообщений: в ней нет постоянных транспортных очередей. Соответственно, Front End Transport представляет собой исключительно SMTP прокси. В свою очередь, это означает, что если служба Front End Transport не может подключиться к серверу почтовых ящиков или если сервер не способен принять сообщение, то отправителю сразу же возвращается код ошибки, означающий необходимость повторить попытку.
Обработка исходящих сообщений осуществляется транспортной службой Transport, выполняющейся на серверах почтовых ящиков. Эта служба обменивается информацией со службой Front End Transport Service через коннекторы отправки Send. Служба Front End Transport выполняет роль прокси для исходящих сообщений при условии, что параметр FrontEndProxyEnabled соответствующего коннектора Send в управляющей оболочке Exchange Management Shell установлен в значение $True, либо если выбран параметр “Proxy through client access server” в административном центре Exchange Administration Center:
Как мы знаем, в Exchange 2013 в компании Microsoft отказались от роли центрального транспортного сервера Hub Transport. Её функции выполняет в основном служба Mailbox Transport. Это единственная служба, которая поддерживает связь со службой Front End Transport.
Для обработки входящих сообщений служба Front End Transport пытается найти активную транспортную службу Transport на соответствующем сервере почтовых ящиков. Помните, мы говорили о том, что у службы Front End Transport отсутствует транспортная очередь? Этот факт имеет важное значение: если найти активную транспортную службу не удаётся, то служба Front End Transport принимает решение о недоступности почтового сервиса, и попытка доставки сообщения заканчивается сообщением об ошибке.
Корректная база данных почтовых ящиков для каждого получателя определяется опросом Active Directory. Служба Front End Transport осуществляет поиск группы доставки и связанной с ней информации о маршруте по каждой базе данных почтовых ящиков. Роль группы доставки может исполнять Routable DAG, группа доставки почтовых ящиков или сайт Active Directory.
В зависимости от числа и типа получателей, служба Front End Transport производит одно из следующих действий (Таблица 1):
Сообщения с единственным потовым ящиком в качестве получателя | В данном случае выбирается сервер почтовых ящиков в целевой группе доставки. Предпочтение отдаётся ближайшему серверу почтовых ящиков по расстоянию до сайта Active Directory. |
Сообщения с получателями с несколькими почтовыми ящиками | Выбирается сервер почтовых ящиков, находящийся ближе всего к сайту Active Directory. Выбор производится на основании анализа первых 20 получателей. Обратите внимание, что в любом случае выбирается единственный сервер почтовых ящиков, т.к. ветвление службой Front-End Transport не поддерживается. |
Сообщение без получателей с почтовыми ящиками | Выбирается случайный сервер почтовых ящиков, принадлежащий локальному сайту Active Directory. |
Транспортная служба доставки в почтовые ящики Mailbox Transport Delivery доставляет входящие сообщения, принимая почту от транспортной службы Transport по протоколу SMTP. После этого осуществляется соединение с локальной базой данных почтовых ящиков с использованием Remote Procedure Call (RPC).
Исходящие сообщения изымаются из локальной базы данных почтовых ящиков по протоколу RPC службой транспортной службой Mailbox Transport Delivery, после чего сообщения передаются транспортной службе Transport по протоколу SMTP.
Служба Mailbox Transport не сохраняет данных о сессии или состоянии и не поддерживает транспортной очереди.
Что же произойдёт, когда пользователь отправит сообщение? В первую очередь будут определены базы данных почтовых ящиков, соответствующие каждому получателю. Эта работа выполняется службой Mailbox Transport Submission путём опроса Active Directory. Информация о маршруте извлекается путём поиска группы доставки для каждой базы данных почтовых ящиков. Группой доставки может служить Routable DAG, группа доставки почтовых ящиков или сайт Active Directory.
В зависимости от количества и типа получателей, служба Mailbox Transport Submission выполнит одно из действий, описанных в Таблице 1.
Как мы уже упоминали, служба Mailbox Transport Delivery не сохраняет данных сессии или состояния и не обладает собственной транспортной очередью. В результате сообщения принимаются или отклоняются на месте в зависимости от того, находится ли получатель в активной копии локальной базы данных почтовых ящиков.
Если получатель не находится в активной копии локальной базы данных почтовых ящиков, служба Mailbox Transport Delivery отклоняет сообщение с генерацией соответствующего сообщения об ошибке доставки сообщения, которое и передаётся транспортной службе Transport. Именно так и происходит в случаях, когда активная копия базы данных почтовых ящиков была недавно перемещена на другой сервер, а сообщение было неправильно маршрутизировано транспортной службой Transport на сервер почтовых ящиков, содержащий неактивную копию базы данных почтовых ящиков.
Если такое происходит, служба Mailbox Transport Delivery может сгенерировать один из следующих кодов ошибки:
Для понимания того, как устроен транспортный поток в Exchange 2013, необходимо обратить внимание на то, как службы Front End Transport и Mailbox Transport маршрутизируют сообщения. Проще всего понять, как работает транспортный поток, можно на примере конкретного сообщения. Давайте проследим, как именно почтовое сообщение проходит через транспортные службы Exchange 2013.
Так же, как и в предыдущих версиях Exchange, в Exchange 2013 создаются отчёты о доставке, которые можно использовать для отслеживания входящих и исходящих сообщений. Обратите внимание, что таким образом можно отслеживать только сообщения, отправленные с использованием Outlook или Outlook Web App, но не через POP или IMAP.
Однако в Exchange 2013 появился более интересный механизм, позволяющий проследить путь сообщения через журнал отслеживания доставки - Message Tracking Logs. Как мы уже обсуждали, в Exchange 2013 роль центрального транспортного сервера Hub Transport была удалена, а ее функции разделены между ролями сервера клиентского доступа и почтовых ящиков. Соответственно, роль командлета TransportServer теперь выполняют два новых командлета:
Итак, давайте отследим путь сообщения, отправленного локальным пользователем Test1 с почтовым ящиком на сервере MBX1 локальному пользователю Test2 с почтовым ящиком на сервере MBX2. Для того, чтобы получить информацию о данном конкретном сообщении, можно использовать любой из двух описанных выше командлетов. Для примера используем первый из них:
Get-TransportService | Get-MessageTrackingLog –ResultSize Unlimited –Start “01/09/2013” –Sender test1@e2013.advsoft.info -Recipients test2@e2013.advsoft.info –MessageSubject “Mail flow example” | Sort TimeStamp | Select ClientHostname, ServerHostname, ConnectorId, Source, EventId
Данный командлет возвращает имена всех серверов почтовых ящиков, которые могут участвовать в транспортном потоке. Проанализировав результат работы командлета, можно построить следующую диаграмму Рисунок 2:
В результате получается следующая схема:
Наконец, пришло время поговорить о транспортных очередях. Как мы помним, в архитектуре Exchange 2013 произошли важные архитектурные изменения в сравнении с предыдущими версиями продукта. В серверах Edge Server, использующихся в Exchange 2007 и 2010, присутствовала транспортная очередь сообщений. В Exchange 2013 нет ни серверов Edge Server, ни транспортных очередей в большинстве служб, ответственных за доставку сообщений. Из трёх служб, несущих транспортную нагрузку, транспортная очередь присутствует только в транспортной службе Transport. Службы Front End Transport и Mailbox Transport собственных очередей не имеют.
Такая архитектура ведёт к важным последствиям в процессе доставки сообщений. При использовании сервера клиентского доступа в качестве основного почтового шлюза необходимо чётко понимать, что при отсутствии или недоступности сервера почтовых ящиков, способного принять сообщение, отправитель мгновенно получит сообщение об ошибке. Для обычной переписки эта особенность не представляет особой проблемы, т.к. большинство почтовых серверов осуществляет несколько попыток доставки в течение 24, 48 или 72-часового периода. Проблемы начинаются при использовании других устройств и приложений.
Если у вас есть нестандартный коннектор получения Receive Connector для приложений, принтеров или других устройств, принадлежащих организации Exchange 2013, то этот коннектор лучше создавать на серверах почтовых ящиков вместо серверов клиентского доступа именно по этой причине.
В этой статье мы попытались осветить то новое, что изменилось в Exchange 2013. В статье описаны архитектурные изменения в Exchange 2013, подробно описаны процессы и службы транспортного потока и детально рассказано о транспортном конвейере. В заключительной части статьи мы проследили путь почтового сообщения, проходящего через все службы и процессы Exchange 2013. Мы увидели, как работают очереди сообщений, и сделали выводы о правильном использовании коннекторов получения Receive Connectors собственной или сторонней разработки.
Подавляющее большинство документации по Exchange Server доступно исключительно на английском языке. В целях улучшить понимание статьи автором был переведён ряд стандартных терминов. В то же время ряд терминов оставлен без перевода в том виде, в каком они названы в интерфейсе и документации Exchange 2013. Ниже приводится краткий глоссарий.
Mailbox Server – сервер почтовых ящиков
Client Access Server – сервер клиентского доступа
Edge Server - пограничный транспортный сервер
Transport Pipeline – транспортный конвейер
Hub Transport - центральный транспортный сервис
Теги: Exchange Server