На главную страницу
 
  Главная 
  Новости 
  Статьи  RSS
  Программное обеспечение 
  Форум 
  Опросы 
  Полезные ссылки 
MSExchange.ru ISADocs.ru WinSecurity.ru NetDocs.ru

Exchange 5.5
Exchange 2000
Exchange 2003
Exchange 2007
Общее
Exchange 2010

Поиск по сайту


Авторизация

Запомнить меня на этом компьютере
  Забыли свой пароль?
  Регистрация

Подписка

Изменение параметров

Статистика

Hits 2075360
804
Hosts 1616519
290
Visitors 164703
314

17
Мониторинг активности принтеров

Главная / Статьи / Exchange 2010 / Новая служба RPC Client Access Service в Exchange 2010 (часть 1)


Новая служба RPC Client Access Service в Exchange 2010 (часть 1)

Версия для печати Версия для печати

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.

Введение

Среди архитектурных нововведений, привнесенных в 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.

Рисунок 1: Архитектура front-end’ов и back-end’ов в Exchange 2000/2003 Рисунок 1: Архитектура front-end’ов и back-end’ов в Exchange 2000/2003

Одним из преимуществ 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.

Рисунок 2: Архитектура клиентского доступа в Exchange 2007 Рисунок 2: Архитектура клиентского доступа в Exchange 2007

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

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

Рисунок 3: Служба RPC Client Access в оснастке MMC Services на сервере CAS Рисунок 3: Служба RPC Client Access в оснастке MMC Services на сервере CAS

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

Рисунок 4: Архитектура клиентского доступа в Exchange 2010 Рисунок 4: Архитектура клиентского доступа в Exchange 2010

Чем это отличается от клиентов 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 | fl RpcClientAccessserver

Рисунок 5: FQDN сервера RPC Client Access Server, указанный в почтовой базе данных Рисунок 5: FQDN сервера RPC Client Access Server, указанный в почтовой базе данных
Если массив CAS существует в узле AD, при создании новой почтовой базы данных атрибут автоматически устанавливается на FQDN массива CAS. Поэтому массиву CAS известно, на какой почтовый сервер и на какую базу данных нужно направлять пользователя.

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

New-ClientAccessServer 'Name 'название массива CAS' 'Fqdn -Site

Рисунок 6: Создание нового массива CAS Рисунок 6: Создание нового массива CAS

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

Рисунок 7: Создание записи для массива CAS в DNS Рисунок 7: Создание записи для массива CAS в DNS

Все еще можно использовать 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 -RpcClientAccessServer 'outlook.domain.com'

Рисунок 8: Изменение значения атрибута RpcClientAccessServer для любых существующих почтовых баз данных Рисунок 8: Изменение значения атрибута RpcClientAccessServer для любых существующих почтовых баз данных

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

Рисунок 9: Атрибут RpcClientAccessServer установлен в качестве FQDN массива CAS Рисунок 9: Атрибут RpcClientAccessServer установлен в качестве FQDN массива CAS

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

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

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





Рейтинг:  
5.0 (голосов 2)  
 1   2   3   4   5    

Автор: Генрик Валзер (Henrik Walther)
Генрик Валзер (Henrik Walther) является Microsoft Exchange MVP и работает в качестве Старшего Технического Консультанта в Interprise, Золотом Партнере Microsoft, расположенном в Дании. Вы можете посетить его web-сайт по адресу: www.exchange-faq.dk (на датском).
Эта статья переведена и опубликована с разрешения www.msexchange.org

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.





Работает на «Битрикс: Управление сайтом»
Работает на «Битрикс:
 Управление сайтом»
© MSExchange.ru, 2005-2010