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

Во второй части этого цикла мы говорили о том, какие клиенты Outlook поддерживаются новой службой RPC Client Access, а также о том, почему подключения к публичными папкам все еще исходят непосредственно от Outlook MAPI к серверу почтовых ящиков. Я также показал, как настраивать статичные RPC порты, чтобы вам не приходилось указывать большие диапазоны RPC портов в вашем устройстве компенсации нагрузки или в вашем Windows NLB массиве.

Как вы узнали из предыдущих частей этого цикла, в Exchange 2010 сервер Client Access Server (CAS) стал действительным сервером среднего звена. В Exchange 2010 все клиенты Exchange, включая Entourage и внутренних Outlook MAPI клиентов, теперь подключаются непосредственно к роли сервера CAS. Это также означает, что задача достижения высокой доступности этого сервера посредством технологии компенсации нагрузки стала еще более важной по сравнению с предыдущими версиями Exchange Server.

В этой части цикла мы рассмотрим то, как обеспечивать действительную высокую доступность для внутренних клиентов Outlook MAPI путем сочетания массива Client Access Server (CAS) с технологией компенсации нагрузки Windows Network Load Balancing (NLB).

Итак, приступим!

Что такое технология Windows Network Load Balancing и как она работает?

Технология компенсации сетевой нагрузки Network Load Balancing (NLB) может использоваться для распределения клиентских запросов среди нескольких серверов. Windows NLB часто используется для обеспечения того, чтобы приложение с неизменным состоянием (stateless applications), такие как серверы приложений или веб серверы на базе IIS, могли быть разгружены с помощью дополнительных серверов по мере возрастания клиентских запросов. Это позволяет обеспечивать приемлемый уровень производительности для клиентов. К тому же, это снижает время простоя, вызванное неправильной работой сервера, так как конечные пользователи никогда не знают о том, что определенный сервер-участник Windows NLB находится или находился в нерабочем состоянии по каким-либо причинам.

Кластеры Windows NLB позволяют обеспечить масштабность служб и приложений на базе протоколов TCP и UDP. Помимо этого, в кластере Windows-based NLB можно использовать до 32 серверов. Хотя наличие до 32 узлов в кластере WNLB является возможным для некоторых веб серверов и серверов приложений, в рамках лучших методик рекомендуется использовать максимум 8 Exchange 2010 Client Access Server (CAS) серверов, настроенных в WNLB. Если вам нужно обеспечить компенсацию нагрузки для более чем 8 CAS серверов, рекомендуется использовать решения по распределению нагрузки на базе аппаратного оборудования.

Windows NLB включена в Standard и Enterprise версии продукта Windows Server 2008 SP2/R2, и поскольку WNLB является стандартным компонентом, она не требует использования каких-либо специальных аппаратных серверных средств для каждого узла в кластере NLB. Однако если смотреть с точки зрения сервера Exchange 2010, вам, конечно, нужно следовать руководству по размерности серверов CAS, которое доступно в онлайн документации Exchange 2010 на Microsoft TechNet.

Когда Windows NLB массив настроен корректно, все серверы в массиве представлены единым виртуальным IP (VIP) адресом и полным доменным именем (FQDN). Когда пользовательский запрос поступает, он будет направлен на все серверы в массиве Windows NLB. Затем клиент будет сопоставлен с определенным сервером, и запросы на все остальные серверы будут прекращены. Принимая это во внимание, можно использовать сходство (affinity) для направления определенных клиентских запросов на определенные серверы в массиве. Можно даже настроить приоритеты для каждого сервера-участника, хотя оба этих момента конфигурации не рассматриваются в этой статье.

Одноадресный или многоадресный режим?

Массив Windows NLB можно настроить на работу в одноадресном или многоадресном режиме. Поскольку технология WNLB не является тем, с чем администраторам или консультантам Exchange приходится ежедневно иметь дело, им может быть сложно выбрать, какой режим использовать, когда придет время для распределения нагрузки RPC трафика для сервиса RPC Client Access на серверах CAS в инфраструктуре Exchange 2010.

Давайте рассмотрим каждый режим WNLB:

Одноадресный режим (Unicast Mode)

Если WNLB настроен на работу в одноадресном режиме, MAC адрес сетевого адаптера каждого сервера будет заменен виртуальным MAC адресом кластера, который является MAC адресом, что будет использоваться всеми серверами кластера Windows NLB. Когда включен одноадресный режим, клиенты смогут подключаться к серверам через VIP адрес сетевой карты, который был настроен с MAC адресом кластера.

Многоадресный режим (Multicast mode)

Если кластер Windows NLB настроен на работу в многоадресном режиме, многоадресный MAC адрес добавляется в адаптер кластера на каждом сервере в кластере. Обратите внимание, что я сказал «добавляется», так как каждый сервер сохраняет свой оригинальный MAC адрес.

Кластер Windows NLB, независимо от того, в каком режиме он настроен, работает лишь с одним сетевым адаптером, установленным на каждом сервере, чтобы достичь оптимальной производительности и разделять обычный и кластерный сетевой трафик.

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

Примечание: Вы можете прочитать о плюсах и минусах каждого режима NLB здесь.

Windows NLB массивы в виртуальной среде

Многие организации сегодня предпочитают виртуализировать большую часть своих серверов, и этим организациям часто приходится виртуализировать Exchange серверы в своей инфраструктуре. Как многие из вас знают, все роли сервера Exchange 2010 можно смело виртуализировать (за исключением Unified Messaging), и они полностью поддерживаются компанией Microsoft, однако есть несколько моментов, о которых следует знать, когда речь заходит о настройке виртуальных серверов Exchange 2010 CAS в массиве WNLB.

VMware ESX Server

Когда вы планируете настройку WNLB массива для виртуальных Exchange 2010 CAS серверов, которые используют VMware ESX Server в качестве платформы виртуализации, рекомендуется настраивать WNLB в многоадресном режиме, поскольку в противном случае вы будете испытывать трудности, связанные с некорректной работой массива WNLB. Для подробной информации по данным проблемам смотрите эту статью базы знаний VMware.

Если вы все же желаете использовать одноадресный режим, компания VMware предлагает альтернативный способ решения этой проблемы. Этот способ также описан в статье базы знаний VMware.

Hyper-V Server

Когда вы планируете настройку WNLB массива для виртуальных серверов Exchange 2010 CAS, которые используют Hyper-V Server или Hyper-V Server R2 в качестве платформы виртуализации, вам нужно настраивать WNLB массив в одноадресном режиме. Но вы столкнетесь с «ожидаемой» проблемой во время настройки WNLB массива. Эта проблема возникает из-за того, что MAC адрес сетевой карты, которую вы используете для WNLB массива, изменяется, когда вы создаете WNLB массив. Это сделает MAC адрес, назначенный Hyper-V сетевой карте отличным от оригинального адреса, назначенного во время добавления сетевой карты в настройках Hyper-V виртуальной машины. Для решения этой проблемы вам нужно настроить новый статический MAC адрес, идентичный адресу, назначенному для WNLB (рисунок 1). Если вы используете виртуальные серверы Exchange 2010 CAS под управлением Hyper-V Server R2, вам нужно отметить флаг Включить спуфинг МАС адресов (Enable spoofing of MAC addresses).

Более подробно эта проблема описана в данной Microsoft KB статье.

Так как многие из вас, вероятнее всего, захотят установить решение, подобное тому, что я описал в этой статье, в виртуальной среде Exchange 2010, я решил, что следует упомянуть об этих проблемах.

Настройка сетевых параметров

Хотя это и необязательно (как говорилось ранее), мы будем использовать одноадресный режим с двумя сетевыми адаптерами, установленными в этой конфигурации (это обеспечит максимально оптимальную производительность).Для настройки второго сетевого адаптера на каждом сервере Exchange 2010 Client Access, откройте Сетевые подключения (Network Connections) и задайте каждому LAN подключению значимое название, например NLB, как показано на рисунке 2.

Также обязательно измените порядок привязки сетевых карт на каждом сервере, который будет входить в массив WNLB. Производственная сетевая карта должна быть первой в списке, как показано ниже. Для этого нужно перейти в закладку Расширенные параметры (Advanced Settings), открыв Сетевые подключения (Network Connections) и выбрав опцию Дополнительно (Avanced) в меню. Возможно, вам придется нажать и удерживать клавишу CTRL, чтобы сделать меню сетевых подключений видимым, так как оно скрыто по умолчанию.

Установка компонента Windows Server 2008 NLB

В отличие от предыдущих версий Windows Server, компонент WNLB не установлен по умолчанию в Windows Server 2008 и Windows Server 2008 R2. Для установки WNLB на Windows Server 2008 вы можете воспользоваться либо графическим интерфейсом диспетчера сервера (Server Manager GUI), либо командой ServerManagercmd.exe (используя ServerManagercmd.exe -install NLB). Для установки компонента на Windows Server 2008 R2 вы также можете воспользоваться PowerShell. В нашем случае мы воспользуемся GUI. Итак, открываем диспетчер сервера и выбираем Функции (Features), нажимаем Добавить функции (Add Features). У нас откроется окно мастера добавления новых функций Add Features Wizard, где мы просто отмечаем флаг Network Load Balancing и жмем Установить (Install). Когда функция NLB установлена, жмем Готово (Finish) и выходим из диспетчера сервера.

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

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

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

Когда вы ввели имя записи хоста, введите IP адрес, который планируете использовать для WNLB массива, который мы создадим в следующем.

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

New-ClientAccessServer 'Name 'name of CAS array' 'Fqdn <fqdn of CAS array> -Site <name of AD site>

Создание Windows NLB массива

Итак, мы дошли до той части, в которой мы собственно создаем WNLB массив. Это можно сделать из интерпретатора команд, или, если вы установили роль сервера Exchange 2010 CAS на Windows Server 2008 R2, можно воспользоваться оболочкой PowerShell. Я хочу создать наглядную презентацию того, что происходит, когда вы настраиваете решение, поэтому я воспользуюсь консолью Network Load Balancing Manager. Итак, запускаем эту консоль путем переход в меню Пуск > Администрирование (Administrative Tools). Здесь выбираем Кластер (Cluster) в меню, а затем Новый (New).

Вводим имя первого узла, который хотим добавить в WNLB массив, затем жмем Подключить (Connect). Спустя некоторое время вы увидите сетевые карты, доступные для настройки нового NLB массива. Выбираем карту с названием NLB и жмем Далее.

На странице Параметры хоста (Host Parameter) оставляем настройки по умолчанию и жмем Далее.

Пришло время добавить IP адрес, который мы хотим связать с WNLB массивом. Помните, это должен быть тот же самый IP адрес, который вы указывали, когда создавали DNS запись (outlook.domain.com) для CAS массива. После добавления IP адреса жмем Далее.

На следующей странице нам нужно указать FQDN массива WNLB, а также режим его работы. В этой статье я назову массив WNLB как array01.exchangelabs.dk, но если вы хотите использовать какой-либо специальный стандарт именований, вы можете воспользоваться другим именем. Если ваши серверы Exchange 2010 CAS не установлены на VMware ESX или имеют другие требования к выбору многоадресного режима, убедитесь, что выбрана опция режима одноадресного режима и нажмите Далее.

На странице Правила портов (Port rules) удаляем стандартное правило портов.

Нажимаем Добавить (Add). На странице добавления и изменения правил портов (Add/Edit Port Rule) убираем флажок Все (All), а затем указываем первый порт, который вы хотите добавить в массив WNLB. В данном случае это будет TCP 135 порт сопоставителя конечных точек, который требуется для CAS массива. Убедитесь, что правило порта установлено на нераспределенное обслуживание (single affinity) и нажмите OK.

Теперь создаем дополнительное правило порта, где нужно указать RPC порты, которые используются Outlook клиентами и массивом CAS. Поскольку мы настроили статические порты для RPC коммуникации между Exchange 2010 CAS серверами и Outlook MAPI клиентами, и поскольку мы выбрали использование порта TCP 55000 для подключений почтовых ящиков и порта TCP 55001 для подключений к каталогу, именно их мы и добавим здесь.

Если вы решили использовать статические RPC порты или просто по умолчанию динамический диапазон RPC портов, вам нужно будет указать их. Если вы не указали статические RPC порты для использования, вам нужно добавить TCP порты 1024-65535 в правило порта.

Также выберите нераспределенное обслуживание для этого правила портов и нажмите OK.

Так как есть большая вероятность того, что вам понадобится использовать этот WNLB массив и для других Exchange клиентов, вам нужно добавить правила портов и для них. На рисунке ниже я также добавил правила портов, требуемые для Outlook Anywhere (TCP/443), Exchange ActiveSync (TCP/443), Outlook Web App (TCP/443), Secure IMAP (TCP/993), secure POP (TCP/995). Я также добавил порт 80, поскольку он используется для внутреннего IIS перенаправления (HTTP > HTTPS).

Также обратите внимание, что в рамках лучших методик нужно настроить secure IMAP и PPOP правила портов, сходство которых задано как none (нет).

Теперь выбираем Готово (Finish). NLB массив будет настроен и через некоторое время у вас будет работающий WNLB массив с одним узлом.

Примечание: некоторым из вас, возможно, захочется использовать стандартное правило порта для всех типов клиентов и сервисов Exchange, и хотя это должно нормально работать для большинства клиентов/служб Exchange, лично я предпочитаю создавать отдельные правила портов. Причина такой позиции заключается в том, что не все клиенты/службы Exchange используют одинаковые параметры сходства. Например, IMAP/POP протоколы должны быть настроены с параметром сходства, имеющим значение none, в отличие от других клиентов/служб Exchange, которые используют нераспределенное обслуживание. С точки зрения безопасности у нас, конечно, на всех серверах работает брандмауэр Windows Firewall, поэтому разделение портов не дает дополнительной безопасности.

Теперь нам просто нужно добавить дополнительные узлы в массив WNLB. Для этого нажимаем правой клавишей на новом массиве WNLB и выбираем опцию Добавить хост к кластеру (Add Host to Cluster), как показано на рисунке 17 ниже.

Теперь вводим NetBIOS или FQDN сервера Exchange 2010 CAS, который хотим добавить в массив WNLB, а затем жмем Подключить (Connect).

На странице Параметры хоста (Host Parameters) жмем Далее.

Нажимаем Готово на странице Правила портов.

Теперь WNLB массив начнет добавлять новый дополнительный узел и обновит свою конфигурацию нужным образом.

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

Для этого открываем оболочку 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, где адрес электронной почты пользователя, вошедшего на клиентскую машину, вводится автоматически в адресное поле, как показано ниже.

Нажимая Далее, Outlook создаст новый профиль автоматически. Когда все готово, давайте отметим опцию Настроить параметры сервера вручную (Manually configure server settings), а затем нажмем Далее, чтобы убедиться в том, что используется новая точка подключения RPC.

Как видно на рисунке 25, новый массив CAS используется в качестве конечной точки RPC. Нажимаем Закончить.

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

На этом закончим данный цикл статей.