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

В третьей части этого многочастного цикла я объяснял, как обеспечить по-настоящему высокую доступность для внутренних клиентов 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, сконфигурированных в кластер (одно активное, а другое в качестве резерва), как основу для данной статьи.

Замечание:Я никоим образом не связан с 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-адрес, который вы планируете использовать для виртуальных служб, которые мы создадим в следующем разделе.

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

New-ClientAccessArray 'Name 'имя массива CAS 'Fqdn <fqdn массива CAS > -Site <имя сайта AD >

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

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

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

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

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

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

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

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

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

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

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

Set-MailboxDatabase <name of DB> -RpcClientAccessServer 'outlook.domain.com'

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

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

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

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

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

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

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