Компенсация нагрузки на серверах Exchange 2010 Client Access Servers с помощью аппаратного решения компенсации нагрузки (часть 2)

В первой части этого цикла статей я рассказывал о том, почему полезно использовать решение компенсации нагрузки на базе аппаратного оборудования (HLB) в вашем CAS массиве, а также объяснил, какие типы параметров родства (affinity) являются предпочтительными для каждого протокола/сервиса. Наконец, я вкратце рассказал о предпочтительных значениях таймаутов для различных Exchange 2010 протоколов и служб.

В этой части я покажу, как создавать и настраивать виртуальные службы, необходимые для протоколов/сервисов, а также как изменять внешние и внутренние URL адреса для каждой службы.

Теперь организации, которые используют решение обратного прокси на базе TMG/ISA/IAG/UAG, установленных в демилитаризованной зоне, обычно будут использовать возможности компенсации нагрузки фермы веб серверов в своем решении для публикации клиентов и сервисов на основе HTTP для клиентов и приложений, расположенных в таких внешних сетях, как интернет. Однако все же полезно создавать виртуальные службы для использования HTTP, чтобы внутренние клиенты и приложения на базе HTTP могли использовать внутреннее HLB решение вместо решения обратного прокси в демилитаризованной зоне. Говоря другими словами, более удобно позволять внутренним клиентам связываться с виртуальной службой на внутреннем HLB решении вместо того, чтобы выходить в интернет, а затем использовать обратный прокси в демилитаризованной зоне.

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

Примечание: Двухступенчатые конфигурации не входят в тему нашей статьи. Для дополнительной информации лучше просмотреть документацию о вашем конкретном решении HLB.

Создание необходимых виртуальных служб в решении компенсатора нагрузки

В части 4 цикла статей о новой службе RPC CA говорилось о том, как создавать виртуальные службы, используемые внутренними Outlook клиентами (сопоставитель TCP End Point и закрепленные порты RPC для службы Exchange Address Book и Mailbox access), поэтому я не буду повторять эти шаги здесь.

Итак, если продолжить с того места установки, на котором мы закончили в вышеуказанной статье, у нас есть виртуальные службы, показанные на рисунке 1. К этой конфигурации также был добавлен дополнительный сервер Exchange 2010 CAS в CAS массив, поэтому теперь у меня есть три CAS сервера, связанных с каждым правилом, а не два.

Рисунок 1: Виртуальные службы, созданные в предыдущем цикле статей о RPC CA сервисе

Пришло время создать новую виртуальную службу для HTTPS и HTTP соответственно. Виртуальная служба HTTPS будет использоваться внутренними клиентами и приложениями и, в зависимости от наличия решения обратного прокси в демилитаризованной зоне или его отсутствия, внешними клиентами. Виртуальная служба HTTP будет использоваться для перенаправления, поэтому нам не нужно упрощать OWA URL с помощью функции IIS HTTP Redirect на каждом сервере CAS в массиве CAS.

Для создания новых виртуальных служб давайте перейдем в KEMP GUI интерфейс и нажмем Виртуальные службы (Virtual Services) > Добавить новую (Add New).

Увеличить

Рисунок 2: Интерфейс KEMP Web GUI

Это вызовет страницу, показанную на рисунке 3. Здесь нам нужно указать виртуальный IP адрес и порт (в данном случае TCP/443), а затем нажать 'Добавить эту виртуальную службу (Add this Virtual Service)'.

Увеличить

Рисунок 3: Указание IP адреса и порта для виртуальной службы HTTPS

На странице свойств виртуальной службы нам нужно задать определенные параметры, такие как уровень 4 или 7, способ родства, значения таймаута, а также модель распределения. Для способа родства лучше выбирать родство на основе cookie с откатом к исходному IP, поскольку этот способ будет поддерживаться и клиентами, использующими cookie (OWA, ECP и Outlook 2010), и клиентами, которые не поддерживают родство на основе cookie, а вместо этого используют исходный IP.

Примечание: в качестве альтернативы можно использовать два виртуальных IP адреса, настроенных в HLB решении, после чего нужно настроить один способ родства на основе cookie (для OWA и ECP), и один для других клиентов/служб, используемых в организации.

Рисунок 4: Настройка основных параметров в свойствах виртуальной службы HTTPS

Если вы планируете выполнять SSL разгрузку, это также настраивается здесь для данной виртуальной службы. В закладке дополнительных свойств (Advanced Properties) можно указать URL адрес проверки здоровья (проверка подключения) и порт 80 перенаправителя, а также такие вещи, как кэширование, сжатие и т.д.

Рисунок 5: Настройка параметров дополнительных свойств виртуальной службы HTTPS Наконец, нам нужно добавить реальные серверы (Exchange 2010 CAS серверы), которые будут связаны с этой виртуальной службой.

Увеличить

Рисунок 6: Добавление реальных серверов для виртуальной службы HTTPS

Готово! Хорошим моментом здесь является то, что нам не нужно вручную создавать виртуальную службу HTTP, поскольку она была создана автоматически, когда мы указали URL адрес перенаправления.

Как видно на рисунке 7, теперь у нас есть виртуальные службы, требующиеся для различных Exchange 2010 клиентов и сервисов.

Рисунок 7: Параметр перенаправления виртуальной службы HTTPS также создает виртуальную службу HTTP Redirect

Изменение внешних External Exchange 2010 CAS URL адресов для обращения к HLB

Теперь, когда мы подготовили HLB решение путем создания необходимых виртуальных служб HTTP/HTTPS, внутренние (обычно mail.domain.com и outlook.domain.com) и внешние DNS записи (mail.domain.com и autodiscover.domain.com) необходимо изменить, чтобы они обращались к виртуальному IP адресу (VIP), связанному с виртуальной службой, которая используется для публикации CAS массива. Если вы не используете решение обратного прокси, такое как TMG/ISA/IAG/UAG, вам следует также настроить эти записи во внешнем DNS, чтобы они обращались к HLB VIP (если решение HLB двухступенчатое, эта настройка производится иначе). Если вы используете TMG/ISA/IAG/UAG, внешние DNS записи должны обращаться к публичному IP адресу на внешнем интерфейсе массива обратного прокси.

Рисунок 8: Изменение DNS записи во внутренней DNS инфраструктуре

Изменение внутреннего и внешнего Exchange 2010 CAS URL адреса для обращения к HLB

Рисунок 9: Стандартные параметры для OWA и других виртуальных каталогов

Приятным усовершенствованием в мастере настройки Exchange 2010 является то, что когда вы устанавливаете роль сервера CAS, у вас есть возможность указать внешний домен на сервере CAS с выходом в интернет (рисунок 10). Вводя FQDN во время установки, вам не придется изменять внешний URL адрес для различных виртуальных каталогов IIS после установки.

Рисунок 10: Настройка внешнего домена на серверах Exchange 2010 CAS с выходом в интернет

Если вы не настроили внешний домен во время установки роли сервера CAS, вы, конечно же, сможете сделать это с помощью Exchange Management Shell (EMS) или страницы свойств каждого виртуального каталога, как это было в Exchange 2007. Но Exchange 2010 позволяет вам делать это с помощью мастера 'Configure External Client Access Domain'. Этот новый мастер можно запустить, нажав правой клавишей на Client Access в рабочей панели конфигурации сервера (Server Configuration) консоли управления Exchange Management Console (EMC), как показано на рисунке 11.

Увеличить

Рисунок 11: Запуск мастера Configure External Client access Domain

В мастере 'Configure External Client Access Domain' введите имя домена, используемого для внешнего доступа к серверам Exchange 2010 CAS, затем добавьте все серверы CAS с выходом в интернет и нажмите 'Настроить (Configure)'.

Увеличить

Рисунок 12: Ввод имени внешнего домена и добавление серверов CAS с выходом в интернет

Этот мастер задаст указанное FQDN имя в качестве внешнего URL адреса для различных клиентов/сервисов, как показано на рисунке 13.

Рисунок 13: Внешний URL адрес задан для соответствующих виртуальных каталогов IIS Directories

Если вы хотите изменить внешние URL адреса с помощью команд Exchange PowerShell, вы можете воспользоваться следующими командами:

Outlook Web App (OWA)

В отличие от прочих внутренних URL адресов внутренний OWA URL должен обращаться к имени FQDN сервера CAS, а не HLB FQDN, поскольку используется Kerberos при доступе к почтовому ящику с сайта без выхода в интернет.

Set-OwaVirtualDirectory -Identity "CAS_Server\OWA (Default Web Site)" -InternalURL https://serverFQDN.domain.com/OWA

Exchange Control Panel (ECP)

OWA и ECP обычно используют одинаковый код. Поэтому, как и в случае с OWA, внутренний ECP URL также должен обращаться к FQDN сервера CAS, а не HLB FQDN. Такая настройка используется, опять же, по причине того, что kerberos используется при доступе к почтовому ящику с сайта без выхода в интернет.

Set-EcpVirtualDirectory -Identity "CAS_Server\ECP (Default Web Site)" -InternalURL https://serverFQDN.domain.com/ECP -FormsAuthentication $True -BasicAuthentication $True

Exchange ActiveSync (EAS)

Set-ActivesyncVirtualDirectory -Identity "CAS_Server \Microsoft-Server-ActiveSync (Default Web Site)" -ExternalURL https://mail.domain.com/Microsoft-Server-Activesync -BasicAuthentication $True

Offline Address Book (OAB)

Set-OABVirtualDirectory -Identity "CAS_Server\oab (Default Web Site)" -ExternalUrl https://mail.domain.com/oab;

Exchange Web Services (EWS)

Set-WebServicesVirtualDirectory -Identity "CAS_Server\EWS (Default Web Site)" -ExternalUrl https://mail.domain.com/ews/exchange.asmx

Unified Messaging (UM)

Set-UMVirtualDirectory -Identity "CAS_Server\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.domain.com/unifiedmessaging/service.asmx

Поскольку мастер Configure External Domain не изменяет внутренние URL адреса, нам нужно изменить их либо с помощью консоли Exchange Management Console (EMC), либо с помощью Exchange Management Shell (EMS). Самым простым способом будет использование EMS. Просто выполняете следующую команду на сервере CAS с выходом в интернет:

Outlook Web App (OWA)

Set-OwaVirtualDirectory -Identity "CAS_Server\OWA (Default Web Site)" -InternalURL https://mail.domain.com/OWA

Exchange Control Panel (ECP)

Set-OwaVirtualDirectory -Identity "CAS_Server\ECP (Default Web Site)" -InternalURL https://mail.domain.com/ECP -FormsAuthentication $True -BasicAuthentication $True

Exchange ActiveSync

Set-ActivesyncVirtualDirectory -Identity "CAS_Server \Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.domain.com/Microsoft-Server-Activesync -BasicAuthentication $True

Offline Address Book (OAB)

Set-OABVirtualDirectory -Identity "CAS_Server\oab (Default Web Site)" -InternalUrl https://mail.domain.com/oab

Exchange Web Services (EWS)

Set-WebServicesVirtualDirectory -Identity "CAS_Server\EWS (Default Web Site)" -InternalUrl https://mail.domain.com/ews/exchange.asmx

Unified Messaging (UM)

Set-UMVirtualDirectory -Identity "CAS_Server\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.domain.com/unifiedmessaging/service.asmx Конечно, можно задавать внутренний и внешний URL адрес, используя одну команду, просто нужно включить оба параметра. Например, чтобы указать оба URL адреса для OWA, можно воспользоваться следующей командой:

Set-OwaVirtualDirectory -Identity "CAS_Server\OWA (Default Web Site)" -InternalURL https://mail.domain.com/OWA -ExternalURL https://mail.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True Наконец, нам нужно, чтобы Autodiscover Service Internal Uri обращался к FQDN нашего HLB. Это можно сделать с помощью команды:

Set-ClientAccessServer 'Identity <Server Name> -AutoDiscoverServiceInternalUri: https://mail.domain.com/Autodiscover/Autodiscover.xml

Рисунок 14: Настройка Autodiscover Service Internal Uri на обращение к HLB FQDN

Итак, мы дошли до конца второй части, но вскоре выйдет третья часть. В ней я расскажу о том, как работать с разгрузкой SSL с серверов Exchange 2010 CAS на решение HLB.