Среди архитектурных нововведений, привнесенных в Exchange Server 2010, есть и новая служба клиентского доступа RPC Client Access Service, изменяющая знакомую нам бизнес-логику клиентского доступа. Эта новая служба передает почтовые соединения Outlook MAPI от back-end’ных почтовых серверов и доступ к каталогам от контроллеров доменов/серверов глобальных каталогов на уровне данных к серверам Client Access промежуточного звена.

В этой статье мы начнем с ностальгического обзора бизнес-логики во времена Exchange 2000/2003 с ее концепцией front-end’ных и back-end’ных серверов. Потом поговорим об улучшениях, внесенных при введении серверной роли Client Access в Exchange 2007. После этого мы вплотную займемся новой службой RPC Client Access Service из Exchange 2010. Мы узнаем, как работает эта служба, и как можно назначить статические порты для MAPI-соединений.

Давайте приступим.

Краткий обзор архитектуры front-end’ов и back-end’ов в Exchange 2000/2003

В Exchange 2000 и 2003 у нас была базовая архитектура front-end’ов и back-end’ов, в которой front-end-серверы принимали запросы от клиентов и передавали их back-end-серверам для обработки. Front-end-сервер в Exchange 2000/2003 мог передавать RPC на базе HTTP (сейчас это называется Outlook Anywhere), HTTPS (OWA, Entourage и т.д.), POP и IMAP соответствующим back-end-серверам. Front-end-серверы также поддерживали множественные обращения к данным общей папки на back-end-серверах.

В Exchange 2000/2003 внутренние клиенты Outlook MAPI вообще не использовали front-end-серверы, они напрямую соединялись с back-end-серверами с помощью MAPI на базе RPC. И вообще, так как компонент DSProxy не запускался на front-end-серверах, у вас не было возможности указать клиентам Outlook MAPI NetBIOS-имя или FQDN front-end-сервера.

В Exchange 2000/2003 компонент DSAccess также получал доступ к службе Netlogon на серверах контроллера домена и глобального каталога в Active Directory непосредственно с помощью Remote Procedure Call (RPC), а затем клиенты Outlook подключаются прямо к DC/GC. Outlook 2000 и более ранние версии подключались к DSProxy.

Одним из преимуществ front-end-серверов в Exchange 2000/2003 было то, что они позволяли вам настраивать одно пространство имен (например, mail.domain.com). В таком пространстве имен пользователям не нужно было знать имя сервера, на котором хранился их почтовый ящик. Другим преимуществом было то, что шифрование и дешифрование SSL было отдано front-end-серверам, что освобождало дорогое процессорное время back-end-серверов. Но все-таки front-end-серверы были всего лишь прокси-серверами, которые сами ничего не обрабатывали. Они лишь производили аутентификацию и отправляли запросы на доступ к back-end-серверам; при этом сказывались еще и ограничения 32-битной архитектуры, которая, помимо прочего, ограничивала максимальный объем памяти серверов Exchange 2000/2003 до 4ГБ.

Общая информация о серверной роли Client Access в Exchange 2007

Когда был выпущен Exchange 2007, все значительно улучшилось. Смысл введения роли Client Access Server (CAS) в Exchange 2007 был в том, чтобы оптимизировать работу серверной роли Mailbox. В отличие от front-end-серверов в Exchange 2007, роль CAS – это не просто прокси-сервер. Например, серверу CAS достается обработка бизнес-логики политик Exchange ActiveSync Policies и сегментации OWA. Кроме того, рендеринг UI OWA также происходит на сервере CAS, а не на сервере Mailbox. Вообще, все клиентские соединения, кроме Outlook (MAPI) используют серверы CAS в качестве конечной точки соединения в инфраструктуре Exchange 2007. Это снимает большую часть нагрузки, которая лежала на back-end-почтовых ящиках в Exchange 2000/2003.

Затем появляется служба PRC Client Access Server в Exchange 2010

В Exchange 2010 все заходит еще дальше. В Exchange 2010 соединения MAPI и соединения с каталогами также отданы роли CAS. Это реализовано с помощью новой службы в CAS, известной как служба RPC Client Access.

Это значит, что клиенты MAPI теперь не подключаются непосредственно к серверу Mailbox, когда они открывают почтовый ящик. Вместо этого они подключаются к службе RPC Client Access, которая далее обращается к Active directory и серверу Mailbox. Для получения информации по каталогу Outlook подключается к конечной точке NSPI на сервере Client Access Server, а затем NSPI обращается к Active Directory через соответствующий драйвер. Как известно, конечная точка NSPI замещает компонент DSProxy в Exchange 2007.

Чем это отличается от клиентов Outlook Anywhere (RPC на базе HTTP), подключающихся к почтовому ящику в Exchange 2007? Ну, хотя клиенты Outlook Anywhere подключались к компоненту RPC Proxy на сервере CAS, они также обращались с помощью MAPI на базе RPC напрямую к серверу Mailbox и к конечной точке NSPI в Active Directory.

Кто-нибудь из вас обязательно поинтересуется, каковы же преимущества службы RPC Client Access. Их несколько. Во-первых, так как MAPI-соединения и соединения с каталогами отошли к роли Client Access Server (промежуточное звено), у Exchange теперь есть только один общий путь, через который происходит передача всех данных. Это не только улучшает целостность при применении бизнес-логики у клиентов. Это упрощает работу с клиентом при перенастройке или при сбоях в случае, если вы установили высокодоступное решение, использующее функцию Database Availability Group (DAG), о которой я расскажу подробнее в последующих статьях. Если пользователь клиента Outlook и заметит отключение, оно будет длиться не более 30 секунд; в Exchange 2007 это занимало несколько минут, дело могло дойти до получаса при наличии сложной топологии AD, состоящей из множества узлов AD и контроллеров доменов, с помощью которых работал DNS.

И, наконец, наличие одного пути доступа к данным позволяет увеличить число одновременных соединений и почтовых ящиков на почтовом сервере. В Exchange 2007 почтовый сервер мог работать с 64000 соединений, а в Exchange 2010 это число увеличено до 250000.

Массивы CAS в Exchange 2010

Теперь, когда в инфраструктуре Exchange 2010 большая роль отводится серверам Client Access Server, клиентам необходимо уметь быстро переподключаться к другому серверу CAS в случае, если тот сервер, с которым они работали, отключается по плановым или внеплановым причинам. Знакомьтесь с новой функцией Exchange 2010 – массивом Client Access! Как ясно из названия, это массив серверов CAS. Точнее, это массив, состоящий из всех серверов CAS в том узле Active Directory, где создавался этот массив. То есть, вместо подключения к FQDN сервера CAS, клиент Outlook может подключиться к FQDN массива CAS (например, outlook.domain.com). Это гарантирует, что у клиентов Outlook, соединенных через MAPI, соединение не пропадает даже в случае сбоя базы данных почтовых ящиков и в случаях перенастройки.

Вот как все это работает в отношении массивов CAS. В базе данных почтовых ящиков в Exchange 2010 есть атрибут под названием RpcClientAccessServer. При создании новой почтовой базы данных в узле Active Directory, где массив CAS не был создан, этот атрибут получает значение первого сервера CAS, установленного в данном узле AD. Значение данного атрибута можно посмотреть, запустив следующую команду:

Get-MailboxDatabase <DB name> | fl RpcClientAccessserver

Массив CAS настраивается следующим образом. Сначала происходит создание массива CAS при помощи следующей команды:

New-ClientAccessServer 'Name 'название массива CAS' 'Fqdn <fqdn of CAS array> -Site <name of AD site>

После создания массива CAS вам нужно создать запись в вашем внутреннем DNS под названием outlook.domain.com, указывающую на виртуальный IP-адрес вашего внутреннего решения по балансировке нагрузки.

Все еще можно использовать Windows NLB вместе с массивом CAS, поскольку серверная роль Mailbox не установлена на той же машине, и все почтовые базы данных на сервере не защищены Database Availability Group (WNLB и кластеризация могут при этом конфликтовать, поэтому такой сценарий не поддерживается). Вы, конечно, также можете решить использовать массив CAS вместе с внешними устройствами балансировки нагрузки, что рекомендуется, особенно в случае, если у вас более 8 узлов CAS.

Если вы пользуетесь WNLB, есть резон в создании кластера WNLB, при этом нужно занести в DNS запись с указанием на WNLB VIP и убедиться в том, что TCP-порт 135 (EndPoint Mapper) и динамический диапазон RPC (TCP 1023-65535) добавлены в список правил для портов.

Замечание: Далее в этом цикле статей я покажу вам, как установить статические порты для MAPI и для доступа к каталогам.

Если вы пользуетесь третьесторонним решением для балансировки нагрузки, вам необходимо создать правила на соответствующем устройстве, работающем с round-robin-трафиком, для нужных портов.

И, наконец, если вы создавали почтовые базы данных на серверах Mailbox в узле AD перед тем, как создавать массив CAS, вам следует поменять FQDN, указанный в атрибуте RpcClientAccessServer, для этих баз данных. Это делается при помощи следующей команды:

Set-MailboxDatabase <name of DB> -RpcClientAccessServer 'outlook.domain.com'

Теперь outlook.domain.com у нас должен быть виден как FQDN.

Если вы защищаете почтовые базы данных с помощью Database Availability Group, и копия соответствующей базы данных на другом узле AD становится активной, не забывайте, что серверы CAS напрямую обращаются к серверу Mailbox, на котором располагается почтовая база данных. Это взаимодействие будет происходить с помощью RPC, поскольку и серверы CAS, и серверы Mailbox работают с RPC. Это важное обстоятельство. Если весь узел прекратит работу, клиенты не будут автоматически переподключаться к серверам CAS на другом узле. Это потребует ручного вмешательства. Такая тема заслуживает отдельной статьи и выходит за рамки данной статьи.

Наконец, не забывайте, что массив CAS используется только клиентами Outlook MAPI для подключения к почтовым ящикам, общим папкам и active directory. Вам все еще нужен WNLB или внешним балансировщиком нагрузки для OWA, Autodiscover, Exchange ActiveSync, службы доступности и так далее.

Это все, чем я хотел поделиться с вами в первой части; ждите выхода второй части этого цикла статей – ее опубликуют в скором будущем.

Автор: Генрик Валзер (Henrik Walther)