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

Введение

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

В этой статье я, помимо всего прочего, объяснил, как использовать компенсацию нагрузки для службы RPC CA с помощью технологии Windows NLB и HLB, но не вдавался в подробности о том, как настраивать компенсацию нагрузки протоколов и сервисов, таких как Outlook Web Access (OWA), Exchange ActiveSync (EAS), Exchange Control Panel (ECP), Offline Address Book (OAB), Post Office Protocol (POP), Internet Message Access Protocol (IMAP), Exchange Web Services (EWS) и AutoDiscover (AutoD).

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

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

Поскольку архитектурные изменения в Exchange 2010, которые имеют место помимо всего прочего, представляют новую службу RPC Client Access (которая перемещает соединения почтовых ящиков Outlook MAPI с внутреннего сервера Mailbox на уровень данных в серверах CAS среднего звена), обеспечение решения компенсации нагрузки и высокой доступности серверов CAS является более важным, чем в предыдущих версиях продукта Exchange.

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

• Более восьми узлов в массиве на базе WNLB (группа разработчиков Exchange не рекомендует использовать более восьми узлов в кластере WNLB по причинам ограничений масштабности и функциональности).
• Требований к LB решению, которое должно знать о приложениях (проверка состояний приложений и не простая проверка IP подключения, которую выполняет WNLB).
• Необходимость в способе родства помимо родства на основе исходных IP адресов, поскольку это единственный способ, предоставляемый решением WNLB (HLB решение предоставляет другие способы родства, такие как родство на основе cookie и SSL ID).

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

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

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

Это может быть особенно верно, если брать один из пяти основных представителей на рынке (таких как F5 BIG-IP, Cisco ACE, Citrix NetScaler и т.д.), но, знаете, что? Решение компенсации нагрузки на основе аппаратных средств – это не просто дорогостоящая роскошь для больших организаций с не менее большими бюджетами в секторе ИТ. Решение компенсации нагрузки на базе аппаратных средств необязательно должно стоить тысячи долларов. На самом деле можно приобрести довольно хорошие, высокопроизводительные устройства по весьма доступным ценам (просто нужно найти подходящего производителя). Это означает, что даже несмотря на то, что ваша организация работает с ограниченным ИТ бюджетом, это вовсе не значит, что вы не можете позволить себе инвестировать в аппаратное решение компенсации нагрузки.

Лично я рекомендовал различные аппаратные решения компенсации нагрузки от различных производителей своим клиентам на протяжении многих лет, но для Exchange 2010, мне действительно нравится недорогое устройство от компании KEMP Technologies. Их самое небольшое устройство (LoadMaster 2000) идет по цене в $1,590 долларов, куда входит плата за обслуживание в течение года. Это означает, что вы можете получить избыточное решение аппаратного компенсатора нагрузки примерно за $3,000 долларов, если вы работаете в малой или средней компании! Плюс к этому, устройство LoadMaster 2000 обладает таким же богатым набором функций, что и LoadMaster 2200 (если совсем немного доплатить за это устройство, вы получаете гораздо больше, чем при покупке LM 2000 модели, хотя разница в цене практически незаметна!), и 2500, 3500 и 5500 модели, предназначенные для больших организаций. Он обладает полной поддержкой функций премиум класса, таких как компенсация нагрузки с помощью уровней 4 и 7, автоматический кластер обхода отказа, SSL выгрузка, персистентность 7 уровня, до 256 виртуальных служб (с общим количеством до 1000 действительных серверов!), проверка здоровья серверов/приложений и т.п. Обычно такой набор функций встречается только в дорогих устройствах компенсации нагрузки от самых известных производителей, упомянутых выше.

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

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

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

Рисунок 1: Топология, используемая в этой тестовой среде

Примечание: очень важно выделить тот факт, что я никак не связан с компанией KEMP Technologies. К тому же мне не платили, чтобы я советовал читателям использовать устройства распределения нагрузки, поставляемые этой компанией. Я просто делаю это исключительно по той причине, что у меня есть очень удачный опыт работы с этими устройствами.

Как на счет обратных прокси, таких как TMG/ISA/IAG/UAG?

Можно ли использовать одно из этих решений для компенсации нагрузки различных протоколов и служб на сервере CAS? Конечно же, можно! По крайней мере, можно компенсировать нагрузку для всего, что идет по протоколам HTTP и HTTPS. Однако ни одно из этих решений не может выполнять компенсацию нагрузки для RPC трафика. Читайте дополнительную информацию в этом новостном письме , которое я написал пару месяцев назад. К тому же вам, возможно, не нужно, отправлять трафик с внешних клиентов на решение обратного прокси в своей демилитаризованной зоне и обратно. Наконец, если вы осуществляете компенсацию нагрузки для трафика HTTP/HTTPS, используя одно из вышеупомянутых решений в качестве внутреннего решения HLB, также важно упомянуть, что вам нельзя настраивать их обращение к VIP/FQDN устройства HLB, а вместо этого обратный прокси-сервер будет самостоятельно распределять трафик между CAS серверами массива CAS.

Какой тип родства (affinity) мне следует использовать?

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

Поэтому в зависимости от клиента или службы Exchange есть различные рекомендации относительно того, какие настройки родства использовать. Ниже я указал, какие настройки являются предпочтительными для каждого клиента и службы.

Клиенты Exchange:

• Outlook Web App (OWA) - для OWA рекомендуемым способом родства является клиентский IP (IP адрес источника) или Cookie (существующие cookie или созданные аппаратным компенсатором нагрузки, также известные как LB-cookie). Оба способа работают в большинстве конфигураций, но если вы работаете со средами, где клиенты представляются, как исходящие с одного IP адреса источника, следует избегать использования Client IP и вместо этого использовать cookie. Не рекомендуется использовать персистентность на базе SSL ID в OWA, поскольку этом может привести к тому, что пользователям нужно будет повторно проходить проверку подлинности, потому что такие обозреватели, как Internet Explorer 8, создают новые отдельные рабочие процессы, например, при создании нового сообщения в OWA. Проблема здесь в том, что с каждым новым рабочим процессом используется новый SSL ID.
• Exchange Control Panel (ECP) - те же рекомендации, что и для предыдущего клиента.

• Exchange ActiveSync (EAS) - для Exchange ActiveSync рекомендуемым способом родства являются Client IP (исходный IP адрес) или заголовок авторизации (Authorization header). Если ваша организация использует одного поставщика мобильных/сотовых сетей для всех пользователей, подключающихся к Exchange с помощью EAS, то велики шансы того, что они все будут представляться, как исходящие с одного IP адреса, поскольку NAT часто используется в сотовых сетях. Это означает, что вы не сможете получить оптимального распределения EAS трафика между CAS серверами за NLB массивом. Поэтому для EAS лучше использовать HTTP заголовок авторизации в качестве ключа родства. И опять же, не рекомендуется использовать персистентность на основе SSL ID для EAS, поскольку некоторые мобильные устройства пересматривают параметры SSL безопасности довольно часто.

• Outlook Anywhere (OA) - для Outlook Anywhere (также известной как RPC через HTTP) рекомендуемым методом родства будет Client IP (исходный IP адрес), заголовок авторизации или персистентность на основе 'OutlookSession' cookie. Если клиенты OA представляются, как исходящие с одного Client IP, то следует использовать заголовок авторизации или 'OutlookSession' cookie. Следует помнить, что родство на основе 'OutlookSession' поддерживается только в клиентах Outlook 2010.

• IMAP и POP3 - IMAP и POP3 не требуют никаких параметров родства, поэтому здесь нет рекомендаций к настройке персистентности.

Сервисы Exchange:

• Autodiscover- служба Autodiscover не требует никаких определенных параметров родства, поэтому здесь нет рекомендаций к настройке персистентности.

• RPC Client Access Service (RPC CA)- для службы RPC CA, используемой в качестве конечной точки для внутренних клиентов Outlook, рекомендуемым способом родства является Client IP.

• Exchange Address Book Service- те же рекомендации, что и для службы RPC CA.

• Exchange Web Services (EWS)- для EWS рекомендуемым способом родства является cookie или SSL ID.

Теперь, поскольку многие из вышеуказанных клиентов и служб используют один и тот же порт, зачастую можно указывать лишь один способ родства для всех клиентов и служб, использующих один порт/IP адрес. Если вы хотите использовать различные способы персистентности, допустим для OWA и OA, в зависимости от вашего HLB решения, это может быть возможным (с использованием раздельного родства и т.п.), но это не входит в рамки нашей статьи. Вместо этого я рекомендую вам связаться с поставщиком вашего HLB решения.

Параметры таймаута для каждого протокола и службы

Для каждой виртуальной службы вы можете задавать значения таймаута для сеансов, которые создаются с различных клиентов к HLB решению (память, ЦП и т.д.).

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

Нет нужды говорить о том, что вам нужно задавать значения таймаутов для протоколов и служб, таких как OWA, ECP, EAS, Outlook Anywhere и RPC CA на довольно высоком уровне (несколько часов, например, рабочие часы), а для таких служб как IMAP, POP, AutoD, EWS, OAB эти значения должны быть относительно низкими (как правило, всего несколько минут). Чтобы не попасть в трудности, свяжитесь с поставщиком вашего HLB решения для получения информации о том, какие настройки рекомендованы для него.

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

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

В части 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.

Введение

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

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

Зачем включать SSL разгрузку?

Есть ряд преимуществ при включении SSL разгрузки при использовании аппаратного компенсатора нагрузки (HLB). Когда вы включаете SSL разгрузку, вы завершаете входящие SSL соединения на HLB, а не на серверах CAS. В результате вы перемещаете рабочую нагрузку SSL (задачи шифрования и расшифровки), которые потребляют много ресурсов ЦП, с CAS серверов на HLB устройство. Поскольку в последнее время CAS серверы получают все больше задач с введением новых функций, таких как MailTips, Move Request Service (MRS) и поскольку они теперь являются конечными точками для MAPI клиентов, имеет еще больший смысл позволять HLB заботиться о рабочей нагрузке SSL.

Еще одной важной причиной является тот факт, что можно использовать обработку только 7 уровня (L7), например устойчивость на основе файлов cookie. Если вы не будете разгружать SSL на HLB решение, вы сможете использовать устойчивость только на основе IP адреса источника, что не идеально. Особенно не идеально, если у вас есть клиенты, которые представляются с одного IP адреса.

Большинство устройств HLB поддерживают программную SSL. Когда используется SSL программного уровня, устройство HLB использует общий процессор (ЦП) для выполнения задач SSL шифрования и расшифровки. Поскольку главный ЦП также выполняет такие задачи как балансировка нагрузки, проверка здоровья и прочие административные задачи, если у вас есть тысячи пользователей в вашей среде обмена сообщениями, рекомендуется использовать HLB с отдельным ЦП, который выделен под задачи обработки SSL.

Включение SSL ускорения на HLB

В этой статье я покажу вам, как настраивать Load Master 2000 HA пару от KEMP Technologies для SSL ускорения, но в общих чертах, эти шаги по настройке должны быть идентичными для подобных устройств от других производителей.

Чтобы включить SSL ускорение для виртуальной службы HTTPS, созданной нами ранее в этой статье, войдите в веб интерфейс LoadMaster и разверните пункт виртуальных служб 'Virtual Services', затем нажмите 'Показать/изменить службы (View/Modify Services) '. Теперь найдите виртуальную службу HTTPS и нажмите 'Изменить (Modify) '.

Рисунок 1: Страница свойств виртуальной службы HTTPS

На странице свойств виртуальной службы HTTPS отметьте опцию ускорения 'SSL Acceleration'

Рисунок 2: Включение SSL ускорения

Теперь откроется диалог, как показано на рисунке 3.

Рисунок 3: Будет использоваться временный сертификат

После нажатия 'OK' страница свойств развернется и отобразит дополнительные SSL опции.

Рисунок 4: Включение SSL ускорения разворачивает страницу свойств и отображает новые опции SSL

Как вы могли заметить, самозаверяющийся сертификат автоматически установлен, когда вы включаете SSL ускорение. Поскольку мы собираемся использовать сертификат SAN/UC стороннего поставщика, который в настоящее время используется на наших серверах CAS массива CAS, нажимаем опцию добавления нового сертификата 'Add New'. Затем либо вставляем полностью тело сертификата или указываем файл сертификата нажатием кнопки 'Обзор (Browse) '.

Рисунок 5: Установка UC/SAN сертификата

Нажимаем 'Отправить (Submit) ' и 'OK', после чего сертификат будет установлен для виртуальной службы HTTPS.

Рисунок 6: Рисунок 6: UC/SAN сертификат установлен

Теперь необходимо убедиться, что портом для каждого реального сервера (CAS сервера) является порт 80.

Рисунок 7: Проверка того, что порт 80 выбран в качестве порта целевого сервера

Теперь мы видим общее имя для сертификата (mail.exchangelabs.dk) в списке виртуальных служб, и на этом работа на стороне HLB завершена. В следующем разделе мы рассмотрим шаги, необходимые для настройки SSL разгрузки на CAS серверах в массиве CAS.

Рисунок 8: Сертификат корректно установлен на виртуальной службе HTTPS

Включение SSL разгрузки для служб Exchange 2010 CAS

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

Настройка Outlook Web App

Чтобы настроить SSL разгрузку для Outlook Web App (OWA), необходимо выполнить два шага на каждом CAS сервере в массиве CAS. Сначала нужно добавить ключ реестра REG_DWORD для разгрузки SSL. Для этого открываем редактор реестра и переходим в раздел:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA

В этом разделе создаем REG_DWORD ключ под названием 'SSLOffloaded' и устанавливаем его значение на '1', как показано на рисунке 9.

Рисунок 9: Создание ключа разгрузки SSL для OWA в системном реестре

Теперь нам нужно отключить SSL требование на виртуальном каталоге OWA. Для этого открываем диспетчер IIS Manager и разворачиваем пункт Default Web Site. В пункте Default Web Site выбираем виртуальный каталог 'OWA'. В окне вида функций дважды нажимаем на параметрах 'SSL Settings'.

Рисунок 10: Доступ к параметрам SSL для виртуального каталога OWA

Теперь убираем флажок с опции 'Требовать SSL (Require SSL) ' и нажимаем 'Применить (Apply) ' в панели действий Actions.

Рисунок 11: Отключение требования SSL для виртуального каталога OWA

Наконец, открываем окно интерпретатора команд и выполняем команду 'iisreset /noforce', чтобы применить изменения.

Настройка панели управления Exchange

В отличие от OWA настройка SSL разгрузки для панели управления Exchange Control Panel (ECP) не требует создания ключа системного реестра. Если говорить точнее, ECP будет использовать тот же ключ реестра, который мы создали для OWA.

Чтобы включить SSL разгрузку для ECP, нам лишь нужно отключить SSL требование для виртуального каталога ECP. Для этого открываем диспетчер IIS Manager и разворачиваем пункт Default Web Site. В пункте Default Web Site выбираем виртуальный каталог 'ecp'. В окне вида функций дважды нажимаем на параметрах 'SSL Settings'.

Рисунок 12: Доступ к SSL параметрам виртуального каталога ECP

Теперь убираем флажок с опции 'Require SSL' и нажимаем 'Применить' в панели задач Actions.

Рисунок 13: Отключение SSL требования для виртуального каталога ECP

Наконец, открываем интерпретатор команд и выполняем команду 'iisreset /noforce', чтобы изменения вступили в силу.

Настройка Outlook Anywhere

Чтобы включить SSL разгрузку для Outlook Anywhere, требуется всего один шаг, который, в зависимости от того, включена ли Outlook Anywhere или нет, может быть выполнен из консоли Exchange Management Console (EMC) или оболочки Exchange Management Shell (EMS).

Если вы еще не включили Outlook Anywhere, вы можете использовать SSL разгрузку при запуске мастера 'Enable Outlook Anywhere'. Этот мастер можно запустить путем нажатия правой клавишей на соответствующем сервере CAS в EMC и выбора опции 'Enable Outlook Anywhere' из контекстного меню.

Рисунок 14: Включение Outlook Anywhere с помощью EMC

Это вызовет мастера, в котором вы можете ввести имя внешнего узла, который будет использоваться, и отметить опцию 'Разрешить разгрузку защищенного канала (SSL) (Allow secure channel (SSL) offloading)'.

Рисунок 15: Разрешение SSL разгрузки для Outlook Anywhere

Если вы уже включили Outlook Anywhere в своей среде, вам нужно воспользоваться командой Set-OutlookAnywhere для включения SSL разгрузки. Если дело обстоит так, откройте Exchange Management Shell и введите следующую команду:

Set-OutlookAnywhere 'Identity CAS_server\RPC* -SSLOffloading $true

Рисунок 16: Включение SSL разгрузки с помощью EMS

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

Настройка Exchange ActiveSync

Некоторые из вас, возможно, читали на Microsoft TechNet или в других источниках о том, что SSL разгрузка не поддерживается в Exchange ActiveSync. Это было так, но сейчас она полностью поддерживается (хотя документация Exchange на Microsoft TechNet не была обновлена этой информацией).

Однако следует помнить, что SSL разгрузка поддерживается в Exchange ActiveSync только для точки входа интернета (Internet ingress point). Она все еще не поддерживается в сценариях CAS-CAS прокси между сайтами Active Directory.

Настройка Exchange ActiveSync на поддержку SSL разгрузки крайне проста. Нам лишь нужно убрать требование SSL в IIS. Для этого открываем диспетчер IIS и разворачиваем Default Web Site. В Default Web Site выбираем виртуальный каталог 'Microsoft-Server-ActiveSync'. В окне вида функций дважды нажимаем на 'SSL Settings'.

Рисунок 17: Доступ к параметрам SSL для виртуального каталога Microsoft-Server-ActiveSync

Теперь убираем флажок с опции 'Require SSL' и нажимаем 'Применить' в панели действий Actions.

Рисунок 18: Отключение SSL требования для виртуального каталога Microsoft-Server-ActiveSync

Наконец, открываем интерпретатор команд и выполняем команду 'iisreset /noforce', чтобы изменения вступили в силу.

Настройка веб служб Exchange

Чтобы настроить веб службы Exchange на поддержку SSL разгрузки, нам нужно выполнить два изменения. Первым изменением будет отключение SSL требования для виртуального каталога EWS в IIS. Для этого открываем IIS Manager и разворачиваем Default Web Site. В Default Web Site выбираем виртуальный каталог 'EWS'. В окне вида свойств дважды нажимаем на 'SSL Settings'.

Рисунок 19: SSL параметры для виртуального каталога EWS

Теперь снимаем флажок с опции 'Require SSL' и нажимаем 'Применить' в панели действий Actions.

Рисунок 20: Отключение SSL требования для виртуального каталога EWS

Следующим шагом будет внесение изменений в файл (web.config) для виртуального каталога EWS. Этот файл находится в C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews и его можно изменить, используя такой текстовый редактор, как Блокнот.

Рисунок 21: Расположение EWS web config файла

В web.config файле необходимо заменить все элементы 'httpsTransport' на 'httpTransport' и затем сохранить его.

Рисунок 22: Заменена httpsTransport на httpTransport

Примечание: В Exchange 2010 SP1 вам больше не потребуется вносить последнее изменение (смотрите KB article 980048 для подробной информации).

Наконец, открываем окно интерпретатора команд и вводим 'iisreset /noforce', чтобы изменения вступили в силу.

Настройка службы Autodiscover

Для настройки службы Autodiscover на поддержку SSL разгрузки нужно выполнить те же шаги, которые мы выполняли для настройки виртуального каталога веб службы Exchange.

Открываем IIS Manager и разворачиваем Default Web Site. В Default Web Site выбираем виртуальный каталог 'Autodiscover'. В окне вида функций дважды нажимаем на 'SSL Settings'.

Рисунок 23: Параметры SSL для виртуального каталога Autodiscover

Теперь снимаем флажок с 'Require SSL' и нажимаем 'Применить' в панели действий Actions.

Рисунок 24: Отключение SSL требования для виртуального каталога Autodiscover

Следующим шагом будет внесение изменений в файл конфигурации (web.config) виртуального каталога службы Autodiscover. Этот файл расположен в C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover, и его можно изменить в текстовом редакторе, например, Блокноте.

Рисунок 25: Расположение файла Autodiscover web config

В файле web.config нужно заменить все элементы 'httpsTransport' на 'httpTransport', а затем сохранить его.

Рисунок 26: Замена httpsTransport на httpTransport

Наконец, открываем окно интерпретатора команд и выполняем 'iisreset /noforce', чтобы изменения вступили в силу.

Проверка работоспособности доступа

После включения разгрузки SSL на HLB нам, конечно, нужно проверить, что доступ с различных клиентов/приложений Exchange работает должным образом. В качестве первого шага можно использовать анализатор удаленных подключений Exchange remote Connectivity Analyzer для этой цели.

Рисунок 27: Использование анализатора Exchange remote Connectivity Analyzer для проверки доступа

Чтобы проверить, что установлены все необходимые корневые и промежуточные сертификаты, а также сертификаты UC/SAN, можно использовать такие инструменты диагностики установки SSL Installation Diagnistics, как инструмент от DigiCert.

Рисунок 28: Проверка SSL цепи с помощью диагностического инструмента DigiCert SSL Diagnostics

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

На этом заканчиваем данный цикл статей. Да, в конце предыдущей части я говорил то же самое, но в этот раз я говорю наверняка :)

Автор: Генрик Валзер (Henrik Walther)

Генрик Валзер (Henrik Walther) является Microsoft Exchange MVP и работает в качестве Старшего Технического Консультанта в Interprise, Золотом Партнере Microsoft, расположенном в Дании. Вы можете посетить его web-сайт по адресу: www.exchange-faq.dk (на датском).

Источник: https://www.Redline-Software.com

Возникли вопросы?

Обращайтесь на форум! Follow us