Share via

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

  • Article

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

Добро пожаловать еще раз. В статье Разрушение мифов об объекте массива CAS. Часть 1 мы обсудили три элемента, связанные с мифами об объекте массива CAS в Exchange Server 2010.

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

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

  1. Объект массива CAS не должен разрешаться через DNS внешними клиентами
  2. Объект массива CAS не должен настраиваться или изменяться после создания баз данных почтовых ящиков Exchange 2010 и перемещения ящиков в базы данных
  3. Объект массива CAS необходимо настраивать, даже если у вас всего один CAS или один сервер с несколькими ролями.

Объект массива CAS не должен разрешаться через DNS внешними клиентами

Как говорилось в Части 1 (по крайней мере дважды, потом я перестал считать), полное доменное имя вашего объекта массива CAS не должно совпадать с полным доменным именем, используемым для других служб, таких как OWA, ECP, EWS, EAS, автообнаружение, или внешним именем узла Outlook Anywhere.

Основная причина этого связана с тем, что клиенты Outlook Anywhere сначала пытаются разрешить полное доменное имя объекта массива CAS через DNS, чтобы узнать, нужно ли пытаться использовать подключение RPC (через TCP) или сразу переходить на HTTPS. Вы разрешаете подключения RPC (через TCP) из Интернета в вашей интрасети? Надеюсь, что нет, иначе в отчете по программе оценки рисков и работоспособности Exchange вы увидите большой красный флаг. Если клиент не пытается сначала подключиться по RPC (через TCP) из-за того, что он может успешно разрешить полное доменное имя объекта массива CAS, может возникнуть значительная задержка перед тем, как клиент попытается использовать HTTPS для подключения к URL-адресу прокси-сервера Outlook Anywhere. Эта задержка может привести к увеличению числа обращений в службу поддержки, если конечные пользователи будут воспринимать ее как ухудшение производительности или нарушение работы службы.

Чтобы избежать этой ситуации, просто убедитесь, что внутреннее полное доменное имя объекта массива CAS уникально для внутренней системы DNS (например, outlook.corp.contoso.com), а URL-адреса других служб, отличных от RPC (через TCP) внутренне используют адреса наподобие mail.contoso.com, для внешних подключений используют разделенную DNS.

Если у вас нет возможности использовать разделенную DNS, набор внутренних И внешних DNS-серверов обрабатывают запросы для одной зоны прямого просмотра, например contoso.com. Две инфраструктуры DNS полностью изолированы друг от друга. Данные между зонами не передаются, и они не используют друг друга как DNS-перенаправители. Эта конфигурация позволяет внутренним пользователям применять внутреннюю инфраструктуру DNS для разрешения узла mail.contoso.com во внутренний IP-адрес (например, 192.168.1.10), который записывается в VIP-адрес средства балансировки нагрузки, в то время как внешние пользователи разрешают его в общедоступный IP-адрес, который может указывать на инфраструктуру Forefront TMG/UAG с выходом в Интернет в вашей сети периметра. IP-адрес объекта массива CAS и внутренний IP-адрес URL-адресов служб, отличных от RPC (через TCP), таких как OWA, ECP, EWS и др., часто являются одним VIP-адресом средства балансировки нагрузки, но они могут использовать разные проверки для обнаружения состояния службы.

Обслуживает ли система DNS множественный ответ?

Я общался по крайней мере с одним пользователем с внешним DNS-сервером, который использовал запись шаблона в качестве ответа на любой запрос, полученный для несуществующего имени узла. Это означает, что можно отправить запрос DNS для SomeFunkyNameThatDoesNotExist.contoso.com, а DNS-сервер всегда будет возвращать IP-адрес корпоративного веб-сайта. (Записи шаблонов допустимы с точки зрения интернет-стандартов. Дополнительные сведения см. в разделе 4.3.3 документа RFC 1034 — прим. редактора).

Из-за этого клиенты Outlook Anywhere всегда могут разрешить полное доменное имя объекта массива CAS и сначала пытаются использовать подключение RPC (через TCP) перед переходом на HTTPS. Если вы оказались в схожей ситуации с внешним DNS-сервером, использующим шаблонные ответы для определенной зоны прямого просмотра, я бы рекомендовал пытаться избежать использования этой зоны прямого просмотра для вашего URL-адреса прокси-сервера Outlook Anywhere.

Напоминаем о том, что рекомендуется настроить нужные мониторы работоспособности службы для вашего решения балансировки нагрузки. Для получения наилучших результатов мониторинга проконсультируйтесь с поставщиком решения балансировки нагрузки. В статье Развертывание средства балансировки нагрузки Exchange Server 2010 можно найти список поставщиков систем балансировки нагрузки, которые прошли тестирование решений для Exchange 2010, а также ссылки на соответствующие веб-страницы (для Exchange 2010). Учтите, что этот список *не* является полным списком поддерживаемых поставщиков систем балансировки нагрузки. Это просто список поставщиков, которые решили напрямую взаимодействовать с Майкрософт для тестирования и поддержки своих решений.

Быстрый и наглядный пример: полные доменные имена на основе HTTPS-службы проверяются по ответам в TCP-порту 443, а решение балансировки нагрузки перестает отправлять новый клиентский трафик любым серверам клиентского доступа, которые перестают отвечать по TCP-порту 443. Полное доменное имя RPC (через TCP) объекта массива CAS проверяется в сопоставителе конечных точек RPC по TCP-порту 135, а также двум статическим TCP-портам, выбранным для клиентского доступа к RPC и службы адресной книги. Если один из этих портов перестает отвечать на определенном сервере клиентского доступа, решение балансировки нагрузки не будет отправлять новый клиентский трафик этому CAS для RPC (через TCP), пока все порты опять не станут отвечать. Если не настроить статические TCP-порты, то Exchange выберет динамический TCP-порт для каждой службы при запуске, что сделает тестирование более сложным, если не вообще невозможным для некоторых решений балансировки нагрузки.

5. Объект массива CAS не следует настраивать после создания баз данных Exchange Server 2010

Зачастую мы в спешке устанавливаем серверы почтовых ящиков, создаем почтовые ящики и начинаем проверку решения с помощью Jetstress. Могу ли я посоветовать вам немного притормозить, чтобы избавиться от неприятностей в будущем? Многие считают серверы почтовых ящиков самой важной ролью сервера, поэтому будет не очень практично запретить к ним доступ через серверы клиентского доступа.

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

Он выглядит не так, как должен (используйте полное доменное имя объекта массива CAS)


Рис. 1. Если объект массива CAS создан, свойство RpcClientAccessServer базы данных почтовых ящиков заполняется с использованием полного доменного имени массива объекта CAS

Она выглядит примерно так:


Рис. 2. Если объект массива CAS не создан, свойство RpcClientAccessServer базы данных почтовых ящиков заполняется с использованием полного доменного имени сервера клиентского доступа

Клиентские профили выглядят следующим образом…


Рис. 3. Если объект массива CAS не создан, клиенты Outlook настраиваются с использованием полного доменного имени сервера клиентского доступа

Клиенты будут подключаться следующим образом…


Рис. 4. Клиенты подключаются к полному доменному имени сервера клиентского доступа

На первый взгляд это может казаться безвредным, и все будет нормально работать, но в будущем возникнут неприятности. Если начать перемещать почтовые ящики в среду Exchange Server 2010 с такой конфигурацией, Outlook будет использовать имя CAS в поле «Сервер» профиля пользователя. Это будет работать, если позже сервер клиентского доступа не будет отключен или выведен из эксплуатации и замещен на сервер с другим именем. Не лучше ли использовать к этому моменту пул серверов клиентского доступа с балансировкой нагрузки? ? Да, конечно.

Вы можете подумать: «Хорошо, если этот день настанет, я создам объект массива CAS и исправлю атрибут RpcClientAccessServer в базах данных, и все наладится». Я скажу вам, что это сработает только для почтовых ящиков, перемещенных в Exchange 2010 после происшествия. Любой пользователь с существующим профилем Outlook, указывающим на имя CAS, а не объект массива CAS, будет подключаться к имени CAS и не сможет обновиться для использования полного доменного имени объекта массива CAS.

Профиль не сможет обновиться, так как клиент не получит ответ ecWrongServer от CAS. Это произойдет потому, что CAS является допустимой точкой подключения для любой базы данных почтовых ящиков с использованием RPC (через TCP), поэтому клиенты смогут пережить переключение или сбой центра обработки данных без повторной настройки, а администратор должен указать в записи DNS объекта массива CAS доступный пул CAS. На данный момент единственный способ исправить профили почтовых ящиков — вручную восстановить профиль в Outlook, опубликовав PRF-файл Office через объект групповой политики (это не будет работать для компьютеров, не подключенных к домену) или выведя из эксплуатации сервер CAS, указанный в профилях пользователей, чтобы конечная точка больше не была доступной. Последний вариант (не забудьте все проверить) приводит к полному восстановлению профилей службой автообнаружения в Outlook 2007 и Outlook 2010. Ошибки в Outlook 2003 можно исправить только с помощью восстановления профиля или PRF-файла. Служба автообнаружения не обновит профиль с новым именем сервера в процессе обычной работы автообнаружения, в котором обновляется конфигурация Outlook Anywhere и обнаруживаются URL-адреса EWS для других компонентов, таких как управление OOF, сведения о доступности и управление правилами для папки «Входящие».

Это также значит, что при перемещении почтового ящика из базы данных на сайт Site-A AD, использующий объект массива CAS с именем Boston-CASArray, в базу данных на сайте Site-B AD, которая использует объект массива CAS с именем Redmond-CASArray, не обновляемый профилем, а поле имени сервера останется равным полному доменному имени Boston-CASArray. Это можно запомнить, если вы переносите некоторых пользователей на разные сайты из-за рабочих изменений или выполняете массивное перемещение почтовых ящиков на другой сайт в течение жизненного цикла решения. Если вы создаете базы данных Exchange 2010 перед созданием объекта массива CAS, вы должны вернуться и исправить атрибут RpcClientAccessServer баз данных, чтобы использовать объект массива CAS перед перемещением почтовых ящиков в базы данных.

6. Объект массива CAS необходимо настраивать, даже если у вас всего один сервер CAS или один сервер с несколькими ролями.

Вспомните, что мы обсуждали в предыдущем пункте. Клиент не сможет обновиться, чтобы использовать объект массива CAS, если вы добавите его позже. А что если у вас всего один CAS? Возможно, вы подумаете, что это неважно. Я думаю, кто-то может сказать, что это неважно именно в данный момент, но почему будущее говорит о другом? Что если через год вам придется заменить CAS? Если профили клиентов указывают на имя CAS, то вы не сможете просто обновить их без прерывания работы системы или ручной работы. Вам придется восстановить их профили одним из описанных выше способов после добавления нового CAS или же вам потребуется вывести существующий CAS из эксплуатации и установить новый CAS с таким же именем узла, для чего потребуется остановить работу системы. Для меня ни один из этих вариантов не является приемлемым.

Что если позднее ваши бизнес-требования изменятся и потребуют более высокой степени доступности клиентского доступа? Вы можете добиться этой цели, только добавив второй CAS и решение балансировки нагрузки. Вы опять окажетесь в той же ситуации, в которой вам потребуется восстановить все профили одним из описанных способов. Опять же, для меня это неприемлемо.

Я рекомендую создать объект массива CAS в самом начале. Как это сделать, если у вас нет средства балансировки нагрузки и всего один CAS? Просто! Настройте объект массива CAS как обычно. Укажите для него имя, сайт AD и полное доменное имя, а затем просто укажите в записи «A» DNS IP-адрес единственного CAS или сервера с несколькими ролями. Вы только что обезопасили себя от будущих неприятностей, а если вам потребуется заменить один CAS или сервер с несколькими ролями, вам нужно будет всего лишь настроить новый сервер и изменить IP-адрес записи DNS, после чего все будет работать без перерывов. Если позже вам потребуется обеспечить высокую доступность, то вам нужно будет обеспечить работу решения балансировки нагрузки и изменить IP-адрес записи DNS объекта массива CAS так, чтобы он указывал на VIP-адрес решения балансировки нагрузки. Все просто!

Надеюсь, что эта статья помогла вам понять некоторые несогласованности с объектом массива CAS и что она поможет всем в реализации перехода на Exchange Server 2010.

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

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

Comments

  • Anonymous
    October 24, 2013
    Огромное спасибо, эта статья очень помогла мне.