Ролевая архитектура сервера Exchange 2013

Предыстория: Exchange 2007 и Exchange 2010

В 2005 году команда Exchange приступила к разработке Exchange 2007. При предварительном проектировании Exchange 2007 было выяснено, что модель архитектуры сервера должна развиваться таким образом, чтобы соответствовать ограничениям аппаратного обеспечения (например, процессора), которые существуют сейчас и не исчезнут ещё долгое время, пока будет существовать данный продукт. Результатом изменений в архитектуре стали пять ролей сервера, три из которых являются основой продукта:

Edge Transport – для маршрутизации и защиты от вредоносных программ из внешней границы организации
Hub Transport – для внутренней маршрутизации и осуществления политики
Mailbox – для хранения данных
Client Access – для возможности подключения к клиенту и веб-сервисов
Unified Messaging – для голосовой почты и голосового доступа

Рис. 1 Архитектура серверной роли в Exchange 2007 и Exchange 2010

Целью разработки стала реализация автономной работы приведённых выше ролей сервера. К сожалению, эта цель не была достигнута ни в Exchange 2007, ни в Exchange 2010. Эти роли сервера были тесно связаны четырьмя ключевыми параметрами:

Функциональность была разбросана по всем серверным ролям таким образом, что возникло следующее требование: серверные роли Hub Transport и Client Access должны быть развёрнуты на каждой из платформ Active Directory, на которых развёрнуты сервера Mailbox.
Требуется точная настройка контроля версий: Hub Transport или Client Access более ранних версий не взаимодействуют с сервером Mailbox более поздней версии. В некоторых случаях их принуждают к взаимодействию (например, сервера Hub Transport Exchange 2007 не могут доставить сообщения на сервера Mailbox Exchange 2010), а в других – нет (например, сервер Client Access пакета обновления 1 (англ. SP1) Exchange 2010 может интерпретировать данные, полученные с сервера Mailbox пакета обновления 2 (англ. SP2) Exchange 2010). Ограничение контроля версий также означает то, что вы не можете просто обновить одну роль сервера, чтобы воспользоваться возможностями новой функциональности – вы должны обновить все роли.
Серверные роли взаимосвязаны также с точки зрения «geographical affinity» (когда пользователи, обслуживаемые определённым сервером Mailbox, всегда обслуживаются определённым набором серверов CAS и HTS) из-за среднего уровня серверных ролей, использующих удалённый вызов процедур (англ. Remote Procedure Call или RPC) в качестве механизма коммуникации с ролью сервера Mailbox.
Аналогичным образом это выглядит с пользовательской точки зрения: серверные роли тесно взаимосвязаны –пользователи, которые обслуживаются определённым сервером Mailbox, всегда обслуживаются определённым набором серверов Hub Transport и Client Access.

Функциональность и контроль версий являются ключевыми вопросами. Для лучшего понимания, давайте посмотрим на следующую схему (рис. 2):

Рис. 2 Связи между серверами на разных слоях функциональности

Как вы можете видеть на приведённой выше схеме, существует три уровня: 1) протоколы (Protocols), 2) бизнес-логика (Business Logic) и 3) хранилище (Storage). Если вы знакомы с моделью взаимодействия открытых систем OSI (англ. Open Systems Interconnection model), вы можете предположить, что уровень протокола похож на уровень приложений и что данные должны перемещаться из уровня приложений через другие уровни, чтобы попасть на физический уровень (или наоборот). Однако это не касается Exchange 2007 и Exchange 2010: протокол может напрямую взаимодействовать с уровнем хранилища. Например, транспортный элемент на Сервере 1 (Exchange 2010 SP1) может доставить почту в службу хранилища (Store service) на Сервер 2 (Exchange 2010 SP2). Обратное также верно: хранилище может передать сообщение с помощью службы Store Submission на Сервере 2 в транспортную службу на Сервер 1. В любом случае, преобразование содержимого происходит на сервере с более низкой версией (так, в данном примере преобразование содержимого происходит внутри транспортных компонентов). В то время как более новая версия взаимодействует с более старой версией без проблем, то же самое нельзя сказать об обратном. Так, более старая версия просто не знает о каких-либо изменениях, которые произошли в более новой версии, что может привести к нарушениям в функциональности (это объясняет, почему в определённых случаях мы выставляем блокаторы или даём указания относительно процедур обновления).

Конечным результатом является то, что при развёртывании Exchange 2007 или Exchange 2010 серверные роли развёрнуты в виде одного целого.

Настоящее: сервер Exchange 2013

Перед началом проектирования Exchange 2013, команда Exchange сосредоточилась на одном единственном принципе – улучшение архитектуры для удовлетворения потребностей при развёртываниях любых масштабов: от маленьких магазинов со 100 пользователями до хостинга сотен миллионов почтовых ящиков в Office 365. Реализация этого единственного принципа привела к значительным изменениям в архитектуре и изменениям во всём продукте. Это изменение частично, потому что в отличие от процесса проектирования Exchange 2007, в данном случае не было ограничений в возможностях процессора. На самом деле это выглядит так: существует такое огромное количество доступных процессоров на современном серверном оборудовании, что такое понятие, как специализированные серверные роли, больше не имеют смысла, поскольку, в конечном счёте, аппаратное обеспечение тратится впустую (отсюда следуют рекомендации по развёртыванию многих ролей сервера Exchange 2010).

В сервере Exchange 2013 используется два основных стандартных блока: массив Client Access и группы обеспечения доступности баз данных (англ. Database Availability Group, или DAG). Каждый из них обеспечивает блок высокой доступности и отказоустойчивость, которые отделены друг от друга. Сервера Client Access составляют массив CAS (англ. Client Access Server), в то время как сервера Mailbox входят в DAG.

Рис. 3 Новая архитектура серверной роли упрощает процесс развёртывания

Так что же представляет собой сервер Client Access в Exchange 2013? Роль сервера Client Access состоит из трёх компонентов: протоколов клиента (англ. client protocols), протокола передачи почты SMTP (Simple Mail Transfer Protocol) и службы UM Call Router. Роль CAS – тонкий протокол сервера без состояния сессии, организованного в конфигурацию со сбалансированной нагрузкой. В отличие от предыдущих версий, в балансировщике нагрузки не требуется, чтобы запросы с одного клиента приходили на один и тот же сервер (но вам всё ещё нужен балансировщик нагрузки для регулирования политики управления соединениями и проверки работоспособности). Это вызвано логикой, которая в данный момент существует в CAS для аутентификации запросов, а затем отправки запроса на сервер Mailbox, на котором находится активная копия базы данных почтового ящика.

В настоящее время роль сервера Mailbox содержит в себе все компоненты и/или протоколы, которые обрабатывают, передают и хранят данные. Клиенты не будут никогда подключаться непосредственно к серверу роли Mailbox – все соединения клиентов обрабатываются сервером роли Client Access. Сервера Mailbox могут быть присоединены к группе обеспечения доступности баз данных (DAG), тем самым формируя блок высокой доступности, который может быть развёрнут в одном или более центре обработки данных.

В отличие от двух предыдущих поколений, эти две серверные роли не допускают одних и тех же ограничений:

Функциональность не распределена по обеим серверным ролям. В настоящее время интерпретация всех данных происходит на сервере Mailbox, на котором размещена активная копия базы данных почтовых ящиков. То есть роль Client Access является обычным прокси-сервером.
Контроль версий также разделён в результате перемещения стека предоставления данных на одну серверную роль.
Сервера Client Access и сервера Mailbox больше не используют протокол RPC (удалённого вызова процедур, Remote Procedure Call) для клиентских сессий, тем самым исчезли проблемы, связанные с «geographical affinity».
С пользовательской точки зрения это выглядит следующим образом: пользователи не должны обслуживаться серверами Client Access, которые расположены на той же самой платформе Active Directory, что и сервера Mailbox, на которых размещены почтовые ящики пользователей.

Давайте вернёмся к схеме с уровнями и посмотрим на произошедшие изменения (рис. 4):

Рис. 4 Связь между серверами в Exchange 2013

Сообщение между серверами происходит не на любом уровне в стеке, а только на уровне протокола. Это гарантирует, что для соединения данного почтового ящика используемый протокол всегда обслуживается отдельным протоколом, который является локальным по отношению к активной копии базы данных. Другими словами, если мой почтовый ящик расположен на Сервере 1 и мне нужно отправить сообщение на почтовый ящик, расположенный на Сервере 2, сообщение должно быть отправлено из транспортных компонентов Сервера 1 на транспортные компоненты Сервера 2; преобразование содержимого сообщения происходит на Сервере 2, когда сообщение попадает в хранилище. Если я обновлю сервер Mailbox с помощью пакета обновлений или общим обновлением, то для данного почтового ящика, расположенного на сервере, интерпретация всех его данных и преобразование содержимого будет локальным, тем самым исчезают ограничения по версии и проблемы, связанные с функциональностью, которые возникали в предыдущих версиях.

Заключение

Сервер Exchange 2013 представляет собой новый блок архитектуры, который позволяет проводить развёртывание любых масштабов. Все основные возможности функциональности Exchange для данного почтового ящика всегда обслуживаются сервером Mailbox, на котором в настоящее время расположена активная база данных почтового ящика. Внедрение изменений в серверную роль Client Access позволяет отойти от сложных решений сессий балансировки нагрузки, что упрощает сетевой стек. С точки зрения обновления это выглядит так: все компоненты на данном сервере обновляются вместе, что избавляет от необходимости совмещать версии серверов Client Access и Mailbox. И наконец, новая архитектура серверной роли позволяет Exchange воспользоваться преимуществами тенденций, связанных с аппаратным обеспечением, в обозримом будущем – количество ядер процессора и ёмкость дискового пространства будет продолжать увеличиваться, а стоимость оперативной памяти будет снижаться.

Редакция Практики