.

Кроме того, комбинацией ролей определяется круг политик безопасности и приемов информационной защиты, применяемых на сервере. Например, если на одном сервере развернуть роли Mailbox и Client Access, роль сервера клиентского доступа будет уязвимой, так как придется установить и открыть для доступа дополнительные службы. У каждой роли есть своя область ответственности, и на долю сервера клиентского доступа выпадает немалая нагрузка. Многие думают, что роль сервера клиентского доступа состоит лишь в обеспечении интерфейса для электронной почты на основе Web, но в действительности ее обязанности гораздо шире, особенно в Exchange 2010. Однако, прежде чем заняться непосредственно Exchange 2010, познакомимся с основными функциями сервера клиентского доступа.

В Exchange 2007 роль сервера клиентского доступа была введена с целью снять часть нагрузки с серверов почтовых ящиков и предоставить общую точку входа в почтовую организацию для клиентов по разным протоколам, в том числе для соединений браузеров, мобильных телефонов и даже клиентов электронной почты через Интернет. В результате освобожденные ресурсы серверной роли Mailbox можно направить на обработку данных, содержащихся в сообщениях. Кроме того, повышается защищенность серверов Mailbox, так как администраторы реже запускают на них службы, используемые внешними клиентами (хотя в любом случае делать это рекомендуется с помощью обратного прокси-сервера).

Чтобы обеспечить точки подключения, сервер клиентского доступа использует комбинацию служб Windows и виртуальных каталогов Web, предоставляемых через сервер Microsoft Internet Information Server (IIS). Чтобы увидеть виртуальные каталоги, предоставленные сервером клиентского доступа, загляните в панель Connections (слева) в диспетчере IIS Manager (экран 1). Некоторые из этих служб, вероятно, покажутся знакомыми, но назначение других непонятно. В таблице дана сводка виртуальных каталогов на сервере клиентского доступа Exchange 2010.

 

Экран 1. Виртуальные каталоги сервера клиентского доступа, показанные в области Connections диспетчера IIS

 

 

 

Таблица. Виртуальные каталоги в серверах клиентского доступа Exchange 2010

Клиентский доступ в Exchange 2010

В сервере клиентского доступа Exchange 2010 появилось много новых функций, ряд улучшений в существующих и некоторые назревшие усовершенствования интерфейса, облегчающие задачу администраторов Exchange. Два новых виртуальных каталога на сервере клиентского доступа Exchange 2010 дополняют архитектуру на основе Web, унаследованную от Exchange 2007. Прежде всего, панель управления Exchange Control Panel (ECP) обеспечивает новый интерфейс для клиентов электронной почты на основе браузера. ECP действует совместно с Outlook Web App (OWA, в прошлом — Outlook Web Access), предоставляя пользователям расширенное управление настройками почтовых ящиков.

Пользователи могут изменить свою контактную информацию в глобальном списке адресов Global Address List (GAL) и управлять группами рассылки, которыми владеют через ECP. Пользователи, наделенные административными ролями через реализацию управления доступом на основе ролей Role Based Access Control (RBAC) в Exchange, могут выполнять дополнительные действия по управлению в организации Exchange, в частности осуществлять поиск во многих почтовых ящиках и назначать роли другим пользователям. Как показано на экране 2, дополнительные возможности представлены в виде добавочных вкладок в пользовательском интерфейсе ECP.

 

Экран 2. Пользовательский интерфейс ECP с вкладками для доступа к дополнительным функциям

Второй новый виртуальный каталог сервера клиентского доступа Exchange 2010 — Remote PowerShell, с помощью которого можно подключиться к оболочке Exchange Management Shell (EMS) с любого компьютера, располагающего соединением SSL с сервером клиентского доступа. Поскольку соединение устанавливается по протоколу HTTPS, можно использовать даже компьютеры вне сети. Команды запускаются с клиента, но выполняются они с сервера клиентского доступа. Поэтому можно задействовать Remote PowerShell для управления 64-разрядными серверами Exchange с 32-разрядных клиентов Windows 7, Windows Vista SP1 и Windows XP SP3.

Обязательное условие доступа клиентов к Remote PowerShell: Windows Remote Management (WinRM) 2.0 и Windows Power Shell 2.0 должны быть установлены заранее. Эти компоненты предоставляются в инфраструктуре Windows Management Framework (support.microsoft.com/default.aspx/kb/968929). После того как среда Windows Management Framework установлена на клиентах, не обязательно устанавливать на них инструментарий Exchange Management или присоединять клиенты к домену. Проверка подлинности выполняется через Remote PowerShell путем создания объекта сеанса и задания указателя URI веб-служб PowerShell, как показано в следующем фрагменте программного кода:

$Session = New-PSSession
   -ConfiguratonName Microsoft.Exchange
   -ConnectionUri https://contoso-cas01
   .contoso.com/PowerShell/
   -Authentication
      NegotiateWithImplicitCredential
Import-PSSession $Session

Здесь исходный текст показан на нескольких строках, но в действительности его нужно вводить одной строкой. Наряду с проверкой подлинности Kerberos (для которого требуется соединение с доменом), Remote PowerShell поддерживает NTLM, обычную и краткую проверку подлинности и протокол Credential Security Support Provider (CredSSP).

Сервер клиентского доступа определяет роли RBAC, назначенные пользователю, и представляет ему только команды EMS и параметры, разрешенные для этих ролей. Например, владельцы роли Mailbox Import Export получают доступ к команде Export-Mailbox.

Наряду с новыми виртуальными каталогами в Exchange 2010 к роли сервера клиентского доступа добавлено несколько новых служб Windows, вследствие чего резко изменился порядок подключения клиентов. Самая важная из этих новых служб Windows — служба RPC Client Access (RPCCA), с появлением которой конечная точка для клиентов при удаленном вызове процедур (RPC) перемещается с сервера Mailbox на сервер клиентского доступа. Клиенты связываются с сервером клиентского доступа с использованием RPC, и сервер клиентского доступа устанавливает соединение MAPI RPC от имени пользователя. С помощью клиентского компонента Active Manager сервер клиентского доступа определяет, на каком сервере почтовых ящиков размещается база данных пользователя, затем подключается к этой базе данных, выступая посредником в организации трафика MAPI.

Клиенты Outlook 2010 и Outlook 2007 не нуждаются в дополнительной настройке для подключения к RPCCA. Однако если используется Outlook 2003, необходимо изменить режим шифрования. Этот параметр можно изменить на клиенте Outlook с помощью групповой политики или вручную в профиле Outlook. Другой вариант — отключить обязательное шифрование на сервере клиентского доступа, хотя делать этого обычно не рекомендуется.

Благодаря перемещению конечной точки MAPI для внутренних клиентов Outlook на сервер клиентского доступа открывается ряд новых возможностей. Вероятно, с наибольшим нетерпением многие ожидали оперативного перемещения почтовых ящиков и улучшения отработки отказов. Переключение базы данных после отказа возможно только в том случае, если серверы почтовых ящиков находятся в группе обеспечения доступности базы данных (DAG). Служба репликации Exchange (MSExchangeRepl) отслеживает базы данных и сообщает об отказах компоненту Active Manager, функционирующему на серверах почтовых ящиков в DAG. При замене активного экземпляра базы данных служба MSExchangeRepl обновляет клиентский компонент Active Manager в службе RPCCA.

Все клиенты Outlook подключаются к серверу клиентского доступа напрямую, поэтому почтовые ящики могут перемещаться между базами данных и даже между серверами Mailbox, пока пользователь зарегистрирован в системе и работает с Outlook. Сервер клиентского доступа обеспечивает перемещение почтовых ящиков, используя для этого службу репликации почтовых ящиков Mailbox Replication Service (MRS). Процесс протекает асинхронно, поэтому можно создать запрос на перемещение и продолжать работать, пока сервер клиентского доступа выполняет задание. Дополнительные сведения об оперативных перемещениях почтовых ящиков можно найти в статье «Перенос почтовых ящиков: способ Exchange 2010» (Windows IT Pro/RE № 6 за 2010 год).

Если переместить почтовый ящик в базу данных Exchange 2010 из базы данных Exchange 2007 SP2 или другой базы данных Exchange 2010, пока пользователи подключены к сети, не требуется изменять профиль, манипулировать с записями DNS или ждать репликации Active Directory (AD). Поскольку пользователь подключен к серверу клиентского доступа, только этому серверу необходимы сведения о местоположении базы данных в учетной записи AD пользователя. При получении запроса на перемещение почтового ящика атрибуты AD обновляются, и сервер клиентского доступа в этом сайте оповещается о том, что идет обработка запроса перемещения.

Для полного перехода на RPCCA необходимо перенести на сервер клиентского доступа еще одну службу. Доступ к каталогам в Exchange предоставляется клиентам через интерфейс Name Service Provider Interface (NSPI). В Exchange 2007 и предшествующих версиях ссылки на конечную точку NSPI предоставлялись компонентом DSProxy. В Exchange 2010 компонент DSProxy заменен новой службой Address Book, запускаемой на сервере клиентского доступа. Перемещение служб Address Book и RPCCA позволяет пользователям Outlook более не подключаться напрямую к серверам почтовых ящиков.

Планирование инфраструктуры клиентского доступа

Рассмотрим подготовительные меры для планирования инфраструктуры клиентского доступа. Несомненно, один из главных вопросов: где разместить серверы? В Exchange 2010 ответ такой же, как и в Exchange 2007: где угодно!

Серверы клиентского доступа связываются с серверами почтовых ящиков через протокол RPC, поэтому сервер клиентского доступа может установить соединение с сервером почтовых ящиков только в том же сайте. Из-за этого ограничения одно из требований Exchange 2010 заключается в наличии по крайней мере одного сервера с ролью клиентского доступа в каждом сайте AD, в котором есть серверы почтовых ящиков. Это требование не вызывает трудностей, если предоставляется доступ только пользователям внутри сети. Но если нужно предоставить доступ к электронной почте пользователям вне сети (через OWA, Outlook Anywhere, POP/IMAP или ActiveSync), то требуется уделить больше внимания структуре сервера клиентского доступа.

Важный фактор при выборе серверов клиентского доступа, обращенных в Интернет, — внешнее пространство имен. Если существует более одного сайта AD с сервером клиентского доступа, обращенным в Интернет, единое пространство имен организовать трудно. Чтобы понять причину, рассмотрим два важных параметра виртуальных каталогов: InternalURL и ExternalURL. InternalURL содержит URL-адрес, используемый клиентами во внутренней сети. ExternalURL содержит URL-адрес, используемый клиентами при доступе через Интернет. Например, в OWA это может быть https://mail.contoso.com/owa. При наличии нескольких обращенных в Интернет серверов клиентского доступа каждый из них имеет собственный ExternalURL, определенный для их виртуальных каталогов.

Чтобы проиллюстрировать влияние этих параметров, посмотрим, что произойдет, когда пользователь Lincoln, имеющий почтовый ящик на сайте Baltimore на сервере BAL-MB01, обращается к серверу клиентского доступа в Сиэттле (SEA-CAS01). Когда Lincoln пытается использовать OWA на сервере SEA-CAS01, сервер клиентского доступа обнаруживает, что почтовый ящик пользователя Lincoln находится в Балтиморе. Если в поле ExternalURL для OWA на сервере BAL-CAS01 указаны какие-то сведения, SEA-CAS01 «знает», что сервер BAL-CAS01 обращен в Интернет и вручную перенаправляет пользователя Lincoln на применение ExternalURL для BAL-CAS01. Но если у BAL-CAS01 нет указателя ExternalURL, SEA-CAS01 использует InternalURL, определенный на сервере BAL-CAS01, как прокси для подключения пользователя. Если при использовании прокси пользователь открывает сообщение в OWA, запрос для сообщения передается от пользователя серверу SEA-CAS01, затем на сервер BAL-CAS01 и на сервер почтовых ящиков, на котором находится почтовый ящик пользователя (BAL-MB01). Процесс показан на рисунке.

 

Рисунок. Передача запроса сообщения через InternalURL

Можно видеть, что при наличии нескольких серверов клиентского доступа, обращенных в Интернет, полезно назначить каждому сайту собственное пространство имен. Если пространство имен общее, не всегда удается правильно преобразовать ExternalURL для сайта, на котором находится почтовый ящик пользователя. Другой, более распространенный вариант — организовать только один сайт с серверами клиентского доступа, обращенными в Интернет. В этом случае все пользователи обращаются к нему через единое пространство имен. Если почтового ящика пользователя в этом сайте нет, соединение всегда передается на сервер клиентского доступа, расположенный в нужном сайте.

Количественные характеристики серверов

После решения вопроса о местоположении серверов клиентского доступа требуется определить количество серверов и необходимые для них аппаратные средства. Нельзя не признать, что определение количественных характеристик серверов клиентского доступа — в большей степени искусство, чем наука. За исключением случаев очень простой информационной инфраструктуры, почти невозможно определить заранее, сколько пользователей будет подключаться к серверу клиентского доступа, как часто они будут это делать и какой протокол использовать. Тем не менее при определении числа серверов необходимо учитывать все эти факторы. К сожалению, нагрузка от 10 000 пользователей, подключающихся через OWA, отличается от нагрузки, создаваемой 10 000 пользователей Outlook Anywhere или ActiveSync. Задачу также усложняет необходимость учитывать многие факторы вне роли сервера клиентского доступа, которые могут привести к неполадкам связи для клиентов, в частности ограничения, свойственные соединениям TCP/IP, или неудачно выбранный масштаб реализации AD.

Компания Microsoft предоставляет общие указания по определению необходимого количества серверов клиентского доступа в статье «Understanding Exchange Performance» (technet.microsoft.com/library/dd351192.aspx). Однако полученные результаты являются обобщенными и не всегда применимы к конкретным условиям.

В соответствии с рекомендациями Microsoft для Exchange 2010, если сервер клиентского доступа — единственная роль сервера, необходимо три ядра процессора в сервере клиентского доступа на каждые четыре ядра в сервере почтовых ящиков в том же сайте. Например, если в сайте расположены 2 сервера почтовых ящиков, каждый с 8 ядрами (всего 16 ядер), общее число ядер сервера клиентского доступа должно быть не менее 12 (то есть 3 сервера по 4 ядра в каждом или даже 6 серверов по 2 ядра в каждом).

Память серверов клиентского доступа должна быть не менее 4 Гбайт, плюс 2 Гбайт на каждое ядро процессора. Максимальное значение составляет 16 Гбайт. Например, для сервера клиентского доступа с четырьмя вычислительными ядрами необходимо 8 Гбайт оперативной памяти. Возьмите эти рекомендации за основу, но проведите собственное исследование и тестирование, чтобы убедиться в правильности выбора масштабов инфраструктуры клиентского доступа.

Исследование и тестирование. В первую очередь, следует осведомиться о протоколах, используемых клиентами при обращениях к серверу клиентского доступа. Клиентский трафик будет состоять из MAPI, Outlook Anywhere, ActiveSync, EWS и OWA. Пользователи Exchange 2007 могут начать собирать данные, выполняя простой мониторинг на существующих серверах почтовых ящиков и клиентского доступа. Собирая данные со счетчиков быстродействия для каждого из этих протоколов в течение нескольких дней, недель или месяцев, можно получить ясное представление о протоколах, используемых клиентами для доступа к почте. Чем продолжительнее сроки мониторинга, тем точнее оценка. Помимо системного мониторинга, можно воспользоваться таким инструментом, как Exchange Server User Monitor (www.microsoft.com/downloads/details.aspx?FamilyID=9a49c22e-e0c7-4b7c-acef-729d48af7bc9), для анализа трафика MAPI.

С помощью собранных внутренних статистических данных можно определить технические характеристики серверов. Серверы в выбранной аппаратной конфигурации следует развернуть в лаборатории, затем протестировать под нагрузкой и с набором протоколов, определенным в ходе исследования. С помощью Exchange Load Generator 2010 (www.microsoft.com/downloads/details.aspx?familyid=CF464BE7-7E52-48CDB852-CCFC915B29EF) можно моделировать трафик клиентского протокола. По результатам моделирования можно обнаружить узкие места аппаратных средств и скорректировать аппаратную конфигурацию или при необходимости увеличить число серверов клиентского доступа.

Кен Сен-Сир (ken.stcyr@microsoft.com) — архитектор решений компании Microsoft с более чем 10-летним опытом работы. Имеет сертификат Microsoft Certified Master in Directory Services