С выходом 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.