Разрушение мифов об объекте массива CAS. Часть 1

Исходная статья опубликована в субботу 24 марта 2012 г.

После выпуска Exchange 2010 в 2009 г. интерес к этой системе был просто фантастическим. Обучая и подготавливая клиентов для перехода на Exchange 2010, мы обнаружили некоторые распространенные недоразумения. Одна из тенденций состояла в неправильном понимании объекта массива сервера клиентского доступа или сокращенно CAS. Технический писатель и блогер Скотт Шнолль (Scott Schnoll) предложил мне взять в руки перо... то есть клавиатуру, когда я комментировал эту тенденцию во внутренней группе рассылки Майкрософт. В результате появилась эта запись блога.

Я не будут обсуждать в этой записи все технические аспекты объекта массива CAS. Их уже прекрасно описал Наджеш Магадев (Nagesh Magadev) в предыдущей записи: Изучение службы клиентского доступа Exploring Exchange 2010 RPC.

Далее представлен список с фактами, касающихся объекта массива CAS, о которых многие клиенты не знают, и я попытаюсь развенчать некоторые мифы. В части 1 мы обсудим первые три элемента, а остальные три мы опишем в части 2.

1. Объект массива CAS не выполняет балансировку нагрузки вашего трафика
2. Объект массива CAS не обслуживает службу автообнаружения, OWA, ECP, EWS, IMAP, POP и SMTP
3. Полное доменное имя объекта массива CAS не должно быть частью вашего сертификата SSL
4. Объект массива CAS не должен разрешаться через DNS внешними клиентами
5. Объект массива CAS не должен настраиваться или изменяться после создания баз данных почтовых ящиков Exchange 2010 и перемещения ящиков в базы данных
6. Объект массива CAS необходимо настраивать, даже если у вас всего один CAS или один сервер с несколькими ролями.

Запутались? Хорошо. Теперь попробуем исправить все и пройдемся поочередно по каждому элементу списка. В этой статье вы увидите некоторые имена серверов, так почему бы мне сначала не показать вам, с чем я работаю в своей лаборатории?

Имя	ServerRole	AdminDisplayVersion
E2K10-MLT-01	Mailbox, ClientAccess, HubTransport	Версия 14.2 (сборка 247.5)
E2K10-MLT-02	Mailbox, ClientAccess, HubTransport	Версия 14.2 (сборка 247.5)
E2K7-MLT-02	Mailbox, ClientAccess, HubTransport	Версия 8.3 (сборка 83.6)
E2003-BE	Нет	Версия 6.5 (сборка 7638.2: пакет обновлений 2)

А теперь перейдем к делу.

1. Объект массива CAS не выполняет балансировку нагрузки вашего трафика

Объект сервера CAS не выполняет балансировку нагрузки. Это объект Active Directory, используемый для автоматизации некоторых функций Exchange, и это все. В документации Exchange 2010 везде говорится, что рекомендуется использовать средства балансировки нагрузки (LB) для балансировки трафика CAS. Итак, что я имею в виду, говоря, что объект массива CAS не занимается балансировкой нагрузки?

Средство балансировки нагрузки осуществляет балансировку трафика в пуле CAS или, возможно, это можно назвать массивом CAS, но не самого объекта массива CAS. Разница небольшая, но отчетливая. Возможно, мы не совсем четко разделили названия, чтобы предотвратить несогласованность.

Основная и, возможно, единственная причина существования объекта массива CAS — автоматическое заполнение атрибута RpcClientAccessServer каждой новой базы данных почтовых ящиков Exchange 2010 на том же сайте Active Directory (как объекта массива CAS).

Атрибут RpcClientAccessServer используется для того, чтобы сообщить клиентам Outlook во время создания профиля, какое имя сервера должно быть указано в профиле. Вот, собственно, и все, больше никакого волшебства, а после создания объекта массива CAS он становится просто объектом в Active Directory, который не выполняет никакой балансировки нагрузки в данный момент времени.

Остальное зависит от вас. Вы можете:

• Создать запись «A» в DNS, которая позволит клиентскому компьютеру разрешить имя узла в IP-адрес. Этот IP-адрес скорее всего будет виртуальным IP-адресом (VIP) LB, доступным для внутренних клиентов. С помощью этого VIP-адреса Outlook или другое приложение с поддержкой MAPI/RPC подключается для получения доступа к ресурсам почтовых ящиков Exchange 2010.
• Настроить решение балансировки нагрузки для передачи трафика в пул серверов CAS по VIP-адресу.

Сами CAS не знают о том, что выполняется балансировка нагрузки.

Вас также может смутить то, что можно увидеть после создания объекта массива CAS с помощью командлета New-ClientAccessArray или просмотра существующего объекта массива CAS с помощью командлета Get-ClientAccessArray.

Вот я создаю объект массива CAS в моей лаборатории с именем CASArray-A, Полным доменным именем outlook.lab.local и сайтом Active Directory с подходящим именем Site-A.

Рис. 1. Создание массива клиентского доступа

Во-первых, все мои поля Полное доменное имя и Имя не совпадают, так как «Имя» — это отображаемое имя, необходимое только для внешнего вида. Здесь вы можете указать любое имя, позволяющее узнать, для чего используется объект массива CAS. Полное доменное имя — это запись, которую необходимо создать в DNS, иначе клиенты не смогут разрешить ее в IP-адрес, к которому необходимо подключиться. На данный момент я напомню о том, что для сайта Active Directory может быть всего один объект массива CAS.

Так почему свойство Участники заполняется двумя CAS сразу после создания? Я вам не говорил, что на данный момент балансировка нагрузки не выполняется? Выглядит так, будто я солгал вам, не так ли?

Честно говоря, свойство Участники вводит нас в заблуждение. Если вы не читали о действиях по созданию объекта массива CAS, вы можете подумать, что на этом этапе все будет закончено. Вы создали объект массива CAS, после чего два CAS автоматически присоединились к массиву. К этому времени вы можете открывать шампанское или идти в другой кабинет, чтобы взять печенье у этого человека. Не так скоро, мои друзья.

Из-за того, что мы связали объект массива CAS с сайтом Active Directory (Site-A), командлет просто ищет все серверы клиентского доступа, зарегистрированные как хранящиеся на сайте Site-A, а затем перечисляет их в столбце «Участники». Я хотел бы, чтобы пользователи считали этот столбец столбцом «Потенциальные участники» или, как предлагает мой коллега Камал Аббури (Kamal Abburi), еще один PFE в Майкрософт, столбцом «Участники CAS сайта». Вы можете добавить эти серверы клиентского доступа как узлы в решение балансировки нагрузки, так как они все размещаются на одном сайте Active Directory. Но до настройки средства балансировки нагрузки никакая балансировка не выполняется.

Как командлеты узнали, на каком сайте расположены CAS? Что ж, я рад, что вы спросили, потому что мы выйдем за пределы всем знакомого AdsiEdit.msc и углубимся в раздел Конфигурация Active Directory, чтобы найти волшебные бобы.

Рис. 2. Атрибут msExchServerSite сервера Exchange 2010 содержит сайт Active Directory, на котором хранится сервер

У каждого сервера Exchange есть атрибут msExchServerSite, содержащий сайт Active Directory, в котором он хранится. Он динамически обновляется при перемещении сервера Exchange на новый сайт, при этом служба топологии Microsoft Exchange Active Directory может запуститься и выполнить ряд задач. Но атрибут AutoDiscoverSiteScope (часть Get/Set-ClientAccessServer) не обновляется динамически, а это может привести к странным результатам автообнаружения, в зависимости от конфигурации сайта, сервера и клиента.

2. Объект сервера CAS не обслуживает OWA, ECP, EWS, службу автообнаружения, IMAP, SMTP и POP

Вернемся немного назад к тому, что на самом деле делает объект массива CAS. Он заполняет атрибут RpcClientAccessServer базы данных почтовых ящиков Exchange 2010, который затем используется, чтобы сообщить Outlook о подключении при использовании RPC (по протоколу TCP). Для клиентов Outlook Anywhere (HTTPS) он указывает, где трафик, покидающий прокси-сервер RPC через HTTP, должен подключиться от лица клиента, чтобы достичь нужного почтового ящика.

К каким службам пытается подключиться клиент Outlook при использовании RPC (по TCP)?

Сначала Outlook подключается к объекту массива CAS по TCP-порту 135 для связи с сопоставителем конечных точек RPC для обнаружения портов TCP, которые прослушивают две следующие службы.

1. Клиентский доступ к Microsoft Exchange RPC (MSExchangeRPC)
2. Адресная книга Microsoft Exchange (MSExchangeAB)

Вот и все для режима RPC (по TCP).

Клиенты Outlook Anywhere (RPC через HTTP) подключаются к компоненту прокси-сервера RPC через HTTP по TCP-порту 443 в CAS, разрешая внешнее имя узла Outlook Anywhere или то, что профиль Outlook называет прокси-сервером.

Небольшое занимательное отклонение для всех заинтересованных: Outlook автоматически добавляет /rpc/rpcproxy.dll к указанному имени сервера, так как именно к этому элементу нужно подключиться, но если бы мы просили пользователей вводить свои имена, как это было в Outlook 2003, представьте, сколько бы пользователей ввели бы их неправильно?

Рис. 3. Указание URL-адреса прокси-сервера RPC в Outlook 2003

Трафик передается из прокси-сервера RPC через HTTP в соответствующую конечную точку MAPI/RPC, используя список строго заданных, а не динамически назначенных TCP-портов (TCP 6001, TCP 6002 и TCP 6004). Внешнее имя узла Outlook Anywhere специально не совпадает с полным доменным именем объекта массива CAS, позже я объясню почему.

Клиент также может устанавливать HTTPS-подключения к службам, таким как служба автообнаружения, OAB, EWS, POP и IMAP, но эти службы определяются другими методами, такими как URL-адреса виртуальных каталогов или значением AutoDiscoverServiceInternalUri. Ни одна из этих дополнительных служб не обслуживается объектом массива CAS, так как ни одна из них не использует RPC, хотя они, скорее всего, подключаются к одному и тому же серверу. VIP-адрес полного доменного имени объекта сервера CAS может совпадать с URL-адресами других служб, но мы настоятельно рекомендуем, чтобы полное доменное имя объекта массива CAS не совпадало с URL-адресами других служб, если используется раздельная система DNS. Я опишу последнюю рекомендацию более подробно позже.

3. Полное доменное имя объекта массива CAS не должно быть частью списка имен сертификатов SSL.

Это очень распространенное заблуждение, которое обычно формируется из-за элемента, описанного выше. Сертификаты SSL в сфере этой статьи используются, только если мы хотим выполнить такую задачу, как создать HTTP-сеанс с защитой SSL. Так как сеанс RPC (через TCP) не является HTTP-сеансом, он не будет защищен с помощью SSL, поэтому нам не требуется включать полное доменное имя объекта массива CAS в список имен тем сертификата SSL. Рассмотрим это более подробно.

Далее показано приложение Outlook 2010 в режиме MAPI/RPC, подключенное к объекту массива CAS Exchange 2010.

Рис. 4. Подключения RPC (через TCP) Outlook 2010 к CAS Exchange 2010

Можно увидеть, что создано одно подключение к каталогу и два подключения к почтовым ящикам. В результатах выполнения команды netstat (показанных над снимком экрана) мы видим, что компьютер установил одно подключение сопоставителя конечных точек (порт TCP 135) к объекту сервера CAS, а также подключения к портам TCP 59531 и TCP 59532, которые представляют статически назначенные TCP-порты для служб MSExchangRPC и MSExchangeAB и соответственно.

На сервере можно увидеть службы, прослушивающие порты с помощью команды netstat –n –b.

Рис. 5. Службы, к которым Outlook должен подключиться при использовании RPC (через TCP)

Как и ожидалось, протокол HTTP (порт TCP 443) не используется для подключения ни к одной службе. Поэтому вам не нужно полное доменное имя объекта массива CAS в сертификате SSL.

Такое заблуждение может возникнуть из-за того, как Outlook отображает подключения в режиме HTTPS, как показано ниже.

Рис. 6. Подключения Outlook Anywhere

На этот раз приложение Outlook 2010 установило два почтовых подключения и одно подключение к общей папке на момент создания снимка экрана. Мы также можем увидеть, что используется HTTPS. Из Outlook это выглядит так, будто мы подключились к outlook.lab.local и E2K10-MLT-01.lab.local, но после выполнения netstat мы видим, что фактически мы подключены к RPC через HTTP-прокси по адресу webmail.lab.local по TCP-порту 443 (HTTPS). Outlook всегда отображает, к какому серверу он подключен для получения данных через самого себя или RPC через HTTP-прокси. Если вы удивлены тем, что netstat отображает 6 подключений, а не 3, это связано с тем, что HTTP — полудуплексный протокол, поэтому мы создаем канал RPC_DATA_IN и RPC_DATA_OUT для каждого подключения в Outlook.

Вы также можете подумать следующее: «Подождите. Outlook 2007 и 2010 по умолчанию шифруют сеансы RPC. Нам нужно имя в сертификате». Неправильно, мои друзья, потому что параметр шифрования, который вы видите ниже, использует шифрование RPC и никак не связан с SSL. Взаимодействие осуществляется по RPC, а не HTTPS.

Рис. 7. При подключении с использованием RPC (через TCP) Outlook применяет шифрование RPC

Просто, не так ли. Если бы объект массива CAS повстречал центр сертификации и тот сказал: «Я тебе действительно нужен. Давай я продам тебе отличный сертификат по низкой цене!», объект массива CAS просто ответил бы: «Спасибо, не заинтересован». Это произойдет, если вы следовали нашим рекомендациям по использованию полного доменного имени для объекта сервера CAS, отличного от полного доменного имени других служб. Скоро я опишу причину…

Надеюсь, что Часть 1 этой статьи была полезной для вас и вы смогли понять некоторые распространенные заблуждения, связанные с объектами массива CAS. Я надеюсь, что вы прочитаете и Часть 2, в которой мы обсудим оставшиеся три заблуждения об объектах массива CAS.

Брайан Дэй (Brian Day)
старший сервис-инженер, группа обмена сообщениями

Это локализованная запись блога. Исходная статья доступна по адресу Demystifying the CAS Array Object - Part 1