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

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

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


Авторизация

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

Подписка

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

Статистика

Hits 2085807
11251
Hosts 1617630
2345
Visitors 166751
2878

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

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


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

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

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

Если вы хотите прочитать другие части этого цикла статей, пожалуйста, перейдите по ссылкам:

Введение

В третьей части этого многочастного цикла я объяснял, как обеспечить по-настоящему высокую доступность для внутренних клиентов Outlook MAPI при помощи балансирования нагрузки службы RPC Client Access (RPC CA), используя комбинацию массива Client Access Server (CAS array) и технологии балансирования нагрузки Windows network load balancing (WNLB).

В этой части мы рассмотрим, как обеспечить по-настоящему высокую доступность для внутренних клиентов Outlook MAPI с помощью комбинации массива CAS и внешнего аппаратного решения балансирования нагрузки.

Многие считают, что аппаратное решение балансирования нагрузки – это роскошь для больших организаций с соответствующими бюджетами на IT. Но знаете что? Аппаратное решение балансирования нагрузки не обязательно стоит тысячи долларов. Вы вполне можете получить достаточно сложные, высокопроизводительные устройства по разумной цене (просто нужно найти соответствующего производителя). То есть, даже если вы работаете на небольшую или средних размеров организацию с очень ограниченным бюджетом на IT, это не означает, что организация не сможет себе позволить вложить средства в аппаратное решение балансирования нагрузки. Лично я рекомендовал различные аппаратные решения балансирования нагрузки от разных производителей моим клиентам многие годы, а для Exchange 2010 мне очень нравятся дешевые устройства от KEMP Technologies. Самое маленькое их устройство (LoadMaster 2000) имеет ценник всего в 1590 долларов, куда даже входит техподдержка на год. То есть вы можете получить аппаратное решение балансирования нагрузки за примерно 3000 долларов! В конце концов, у устройства LoadMaster 2000 тот же набор функций, что и у моделей LoadMaster 2500, 3500 и 5500, что означает, что у него есть полная поддержка множества возможностей, например, балансирование нагрузки с использованием уровней 4 и 7, кластер автоматического обхода сбоя (активный резерв со временем обработки отказа меньше 3 секунд в моей тестовой среде), разгрузка SSL, сохранность уровня 7, до 256 виртуальных служб (всего более 1000 реальных серверов!), проверка состояния сервера/приложения и т.д. Эти возможности обычно можно увидеть только у дорогих устройств балансирования нагрузки от более известных производителей на рынке.

Кстати, если вы поддались моде на виртуализацию (а кто нет?), у KEMP Technologies есть виртуальное устройство с набором функций, идентичным наборам аппаратных устройств.

Поскольку у меня очень положительных опыт работы с устройствами от KEMP Technologies, и поскольку они доступны даже для небольших и средних по размером организаций, часто планирующих развернуть полностью избыточное решение Exchange, состоящее из двух многоролевых серверов Exchange 2010, я использовать два устройства LoadMaster 2000, сконфигурированных в кластер (одно активное, а другое в качестве резерва), как основу для данной статьи.

Рисунок 1: Топология Рисунок 1: Топология

Замечание:Я никоим образом не связан с KEMP Technologies. Кроме того, мне не платили за то, чтобы я рассказывал читателям об их устройствах для балансирования нагрузки.

Ладно, достаточно рекламы; давайте двигаться дальше.

Зачем нужно аппаратное решение балансирования нагрузки при наличии Windows NLB?

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

Технология Windows Network Load Balancing (WNLB) может оказаться правильным выбором для организаций, которые не планируют установку многоролевых серверов Exchange 2010 с почтовыми базами данных, защищенными DAG, и с серверами CAS с сбалансированной нагрузкой и высокодоступностью. Кроме того, использование WNLB может подойти организациям, у которых не более 8 узлов в массиве WNLB (команда Exchange Product не рекомендует более 8 узлов в кластере WNLB из-за ограничений на масштаб и функциональность).

Однако, если вы планируете устанавливать многоролевые серверы Exchange 2010, вы не сможете использовать WNLB из-за аппаратных конфликтов между Windows Failover Cluster (WFC) и WNLB (подробности см. в этой статье). Также, в зависимости от вашей среды и топологии сети настроек, предоставляемых WNLB, может оказаться недостаточно. Например, рекомендуется использовать аппаратное решение балансирования нагрузки, когда вы не можете воспользоваться настройками клиентского IP-адреса для проверки персистентности сессии.

Когда аппаратно сбалансированный массив CAS правильно настроен, все серверы в массиве представляются одним виртуальным IP(VIP)-адресом и FQDN. Когда приходит клиентский запрос, он отправляется на сервер CAS Exchange 2010 в массиве CAS, выбранным DNS по методу round robin. И, конечно, у нас есть возможность предпочесть один сервер другому и т.п.

Какой тип персистентности стоит использовать для службы RPC CA?

Персистентность (другие названия: живучесть, стойкость и т.п.) – это способность балансировщика нагрузки поддерживать соединение между клиентом и сервером. Персистентность позволяет убедиться в том, что все запросы от клиента отправляются одному и тому же серверу в массиве NLB или в серверной ферме.

Для службы RPC CA рекомендуется использовать персистентность на базе клиентской IP-сессии (в качестве IP-адреса источника). При этом сессионные запросы от индивидуального клиента направляются на тот же сервер CAS на основании только IP-адреса источника клиентского пакета.

Я не буду углубляться в подробности работы персистентности в этой статье. Я оставлю эту тему для будущей статьи, в которой я сконцентрируюсь на том, как сбалансировать нагрузку не только для RPC CA, а вообще для всех служб, находящихся на CAS-сервере (включая OWA, ECP, EAS, OA, EWS и т.д.). Важно, чтобы вы поняли, что рекомендуемый тип персистентности для клиентов Outlook MAPI, подключающихся к RPC CA на CAS-сервере – это 'Client IP' (он же 'Source IP address').

Создание записи о хосте массива CAS в DNS

Если вы этого еще не сделали, пора создать запись в DNS о массиве CAS. Я объяснял, как это сделать, еще в первой части нашего цикла.

В общем, вы просто заходите в контроллер домена в вашем лесу Active Directory, затем открываете менеджер DNS, щелкнув Start и Run и набрав dnsmgmt.msc. Теперь раскройте контейнер Forward Lookup Zones и щелкните правой кнопкой мыши на соответствующем узле forward lookup zone для вашей Active Directory. В контекстом меню выберите New Host (A), затем введите имя, которое вы хотите использовать. Как вы видите на Рисунке 2, я использовал OUTLOOK для данной конкретного случая. Лучше всего использовать outlook.domain.com.

После ввода записи с именем хоста, введите IP-адрес, который вы планируете использовать для виртуальных служб, которые мы создадим в следующем разделе.

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

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

New-ClientAccessArray 'Name 'имя массива CAS 'Fqdn -Site

Рисунок 3: Создание объекта массива CAS в Active Directory Рисунок 3: Создание объекта массива CAS в Active Directory

Настройка аппаратного балансировщика на работу с массивом CAS

Настало время настроить наше аппаратное решение балансирования нагрузки. При наличии пары балансировщиков LoadMaster это очень просто, и требует всего нескольких действий.

Важно: Устройство LoadMaster (вне зависимости от того, о какой модели идет речь) не поддерживает определенный диапазон портов для виртуальной службы, о которой идет речь. В следующих версиях это должно быть исправлено. Но это значит, что для использования устройств LoadMaster с целью балансирования трафика, проходящего через массив CAS Exchange 2010, требуется настроить статические порты для RPC. Пожалуйста, обратитесь к части 2 этого цикла за описанием действий, необходимых для этого.

Когда мы зайдем в веб-GUI, нужно щелкнуть Virtual Services и Add New.

Рисунок 4: Открытие страницы Add News виртуальной службы Рисунок 4: Открытие страницы Add News виртуальной службы

На странице Add a new Virtual Service введите IP-адрес массива CAS. Это VIP, который мы указывали ранее на Рисунке 2. Затем введите номер порта и тип протокола. Сначала нам нужно создать порт 135, который является End Point Mapper для TCP. Теперь щелкните Add this Virtual Service.

Рисунок 5: Указание IP-адреса, порта и типа протокола виртуальной службы Рисунок 5: Указание IP-адреса, порта и типа протокола виртуальной службы
Теперь нас отправят на страницу Basic Properties, где мы должны разобраться с настройками персистентности и т.п. Тут мы включаем Force L7 и L7 Transparency и указываем Source IP Address под Persistence Options. Опция Scheduling Method (то есть метод распределения клиентского трафика, отправляемого на серверы CAS) должна быть установлена в round robin. Когда все эти опции настроены, можно отправиться дальше, нажав Add New в низу страницы.
Рисунок 6: Страница свойств виртуальной службы
Это страница, на которой мы указываем IP-адрес реальных серверов (Exchange 2010 CAS-серверы). Рисунок 6: Страница свойств виртуальной службы Это страница, на которой мы указываем IP-адрес реальных серверов (Exchange 2010 CAS-серверы).
Рисунок 7: Добавление реальных серверов к виртуальной службе Рисунок 7: Добавление реальных серверов к виртуальной службе

После добавления всех серверов CAS, участвующих в массиве CAS, мы можем перейти к созданию следующей виртуальной службы с помощью аналогичных шагов и конфигурационных опций.

Рисунок 8: Список реальных серверов, добавленных в виртуальную службу Рисунок 8: Список реальных серверов, добавленных в виртуальную службу

Кроме порта 135 вам нужно еще создать виртуальную службу для статического набора портов для соединений RPC с почтовыми серверами и для статического набора портов для службы адресной книги. Опять же, подробности настройки во второй части. В нашем цикле я использую порт 55000 для почтовых соединений и порт 55001 для службы адресной книги. Ими я ограничиваю список виртуальных служб (см. Рисунок 9).

Если реальные серверы доступны для указанных портов, вы должны увидеть зеленый индикатор.

Рисунок 9: Список требуемых виртуальных служб Рисунок 9: Список требуемых виртуальных служб

Теперь у нас есть рабочий массив CAS, который балансирует нагрузку для соединений RPC между клиентами Outlook MAPI и службой RPC Client Access на каждом сервере CAS, который использует аппаратное решение балансирования нагрузки. Но перед тем как клиенты Outlook MAPI начнут использовать массив CAS, мы должны настроить все почтовые базы данных на сайте AD, где создавался массив CAS, на использование FQDN массива CAS (outlook.domain.com).

Для этого откройте Exchange Management Shell и введите следующую команду:

Set-MailboxDatabase -RpcClientAccessServer 'outlook.domain.com'

Рисунок 10: Указание FQDN массива CAS в почтовых базах данных Рисунок 10: Указание FQDN массива CAS в почтовых базах данных

Подключение к массиву CAS клиента Outlook MAPI

А теперь пришло время проверить, сможем ли мы подключиться к почтовому ящику Exchange 2010, и используется ли новый массив CAS (то есть точка подключения RPC) при создании профиля Outlook.

Поэтому давайте запустим Outlook 2010 на подключившейся к домену клиентской машине. При этом вызывается мастер Add New Account wizard, где автоматически вводится почтовый адрес пользователя, работающего на клиентской машине, в поле e-mail address, как показано ниже.

Рисунок 11: Запуск Outlook 2010 с целью создания нового профиля Рисунок 11: Запуск Outlook 2010 с целью создания нового профиля

После нажатия Next Outlook создает новый профиль автоматически. После этого нажмем Manually configure server settings, а затем - Next, чтобы можно было увидеть новую точку подключения RPC.

Рисунок 12: Успешно созданный профиль Outlook 2010 Рисунок 12: Успешно созданный профиль Outlook 2010

Как видно из Рисунка 13, используется новый массив CAS, так же как и точка RPC. Щелкните Finish.

Рисунок 13: Новый FQDN массива CAS используется в качестве конечно точки соединения RPC Рисунок 13: Новый FQDN массива CAS используется в качестве конечно точки соединения RPC

Запускается Outlook, и создается локальная копия почтового ящика. Теперь зажмите CTRL и щелкните правой кнопкой мыши на значок Outlook в системном трее в правом нижнем углу. Выберите Connection status в контекстном меню. Как мы видим в окне статуса соединения, у нас два почтовых ящика, два подключения к каталогам напротив FQDN массива CAS и одно подключение к общей папке напротив сервера mailboks, где хранится база данных общей папки. Как вы узнали из второй части цикла, ожидается подключение к общей папке на сервере mailboxs, так как общие папки все еще находятся непосредственно на почтовых серверах (конкретнее, служба RPC Client Access — на почтовой серверной роли).

Рисунок 14: Окно статуса соединения, показывающее, что массив CAS используется в качестве конечной точки подключения к RPC Рисунок 14: Окно статуса соединения, показывающее, что массив CAS используется в качестве конечной точки подключения к RPC

Этим мы завершаем цикл статей. Надеюсь, он вам понравился!

Если вы хотите прочитать другие части этого цикла статей, пожалуйста, перейдите по ссылкам:





Рейтинг:  
0 (голосов 0)  
 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