.

В двух других статьях серии, «Клиентский доступ в сервере Exchange: введение» и «Клиентский доступ в Exchange: развертывание серверов», дается первоначальное представление о серверной роли клиентского доступа и краткое описание действий по ее развертыванию в организации. В данной статье основное внимание будет уделено тому, как наделять серверы Client Access отказоустойчивостью и избыточностью. Я расскажу о том, как функционирует механизм балансировки нагрузки, а также как он реализуется в роли Client Access.

Общее представление о балансировке нагрузки

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

Балансировка нагрузки на основе сети — одна из форм кластеризации, однако не следует путать ее с концепцией кластеризации ресурсов. Различие между этими понятиями состоит в том, что в случае кластеризации ресурсов имеются некоторые ресурсы, совместно используемые группами серверов. Эти ресурсы могут быть облечены в разные формы, такие как системные службы, IP-адреса или данные. Когда же мы говорим о балансировке нагрузки на базе сети, то в этом случае о ресурсах, совместно используемых различными узлами, речи нет. Балансировка нагрузки базируется на протоколах TCP/IP. Пользователь обращается к сетевой службе через конкретный порт (скажем, при подключении по протоколу HTTPS это порт 443), и балансировщик нагрузки следит за тем, чтобы один из серверов массива отвечал на это обращение.

Балансировщики нагрузки бывают двух видов: внешние устройства и серверное программное обеспечение. Различные средства балансировки нагрузки отличаются друг от друга не только методами функционирования, но и механизмом масштабирования. Кроме того, они оснащаются уникальными функциями. Впрочем, в целом все эти средства предназначены для решения одних и тех же задач — перехвата сетевого трафика до того, как он достигнет службы, и распределения нагрузки по серверам массива.

Внешние балансировщики нагрузки располагаются перед массивом серверов; конечный пользователь или сервер-посредник обращаются не напрямую к индивидуальным серверам, а к балансировщику нагрузки. На рисунке 1 представлен массив серверов Client Access с балансировкой нагрузки, оснащенный внешним балансировщиком. В этой конструкции балансировщик нагрузки имеет уникальное имя (mail.contoso.com), к которому пользователи обращаются напрямую. При установлении соединения с балансировщиком нагрузки устройство определяет, какой сервер Client Access выполнит эту операцию, и далее выступает в роли посредника при установлении соединения с этим серверным узлом.

 

Рисунок 1. Массив серверов Client Access с балансируемой нагрузкой, оснащенный внешним балансировщиком нагрузки

 

Чтобы определить, с каким сервером Client Access будет устанавливаться соединение, внешние балансировщики нагрузки применяют различные методы. Так, они могут следовать заранее заданным правилам, таким как сопоставление клиент-подсеть, где ответственность за весь трафик, исходящий из некоторого диапазона IP-адресов, возлагается на один сервер, или использовать алгоритм кругового обслуживания. Разные типы балансировщиков нагрузки могут осуществлять мониторинг различных типов, например определять, выполняется ли та или иная служба либо доступен ли тот или иной порт на сервере с ролью Client Access; некоторые продукты могут использовать результаты такого мониторинга для определения, к какому серверу следует обращаться.

Программный балансировщик нагрузки устанавливается на всех серверах массива. В небольших массивах серверов с ролями Client Access для балансировки нагрузки нередко используют программное средство — службу балансировки сетевой нагрузки Network Load Balancing (NLB), интегрированную в Windows Server. Для выбора сервера, который будет обслуживать пользовательские запросы, программные балансировщики нагрузки обычно используют заранее заданные алгоритмы. На рисунке 2 представлена типичная конфигурация Windows NLB. В данном случае пользователь устанавливает соединение с виртуальным именем и IP-адресом, которыми пользуются все серверы массива. Этому совместно используемому IP-адресу назначается уникальный MAC-адрес, используемый каждым узлом в режиме одноадресной (unicast) или многоадресной (multicast) рассылки. В одноадресном режиме MAC-адрес одного из сетевых адаптеров каждого узла заменяется общим MAC-адресом. В многоадресном режиме добавляется дополнительный MAC-адрес (для многоадресной рассылки), так что сетевые адаптеры сохраняют и свои исходные MAC-адреса. В любом случае каждый сервер получает сетевой трафик по совместно используемому IP-адресу. Для выбора узла массива с балансировкой нагрузки, который будет обрабатывать сетевые пакеты, используется алгоритм фильтрации. При использовании средств Windows NLB в основе этого алгоритма лежит IP-адрес клиента, который устанавливает соединение с массивом. Каждый узел массива применяет один и тот же алгоритм, так что в итоге на тот или иной пакет будет реагировать лишь один узел, а остальные узлы оставят его без внимания.

 

Рисунок 2. Типичная конфигурация Windows NLB для серверов Client Access

Надо сказать, что в большинстве сетей механизм Windows NLB не подходит для балансировки нагрузки. Теоретически средства Windows NLB дают возможность работать с числом узлов до 32, но я настоятельно рекомендую не использовать Windows NLB для распределения нагрузки по массиву серверов с ролями Client Access, если он состоит из более чем 8 систем, потому что после преодоления этого порога могут возникнуть проблемы с масштабированием. Если ваш массив включает более 8 серверов Client Access, Microsoft рекомендует задействовать аппаратный балансировщик нагрузки. Еще один недостаток механизма Windows NLB состоит в ограниченности его «интеллектуальных» ресурсов. Данный балансировщик в состоянии определить, функционирует ли тот или иной порт, но не более того. В случае выхода из строя службы или другого сбоя на сервере Client Access балансировщик Windows NLB может по-прежнему исходить из того, что служба функционирует нормально, и продолжать направлять клиенты на этот сервер. Кроме того, в сетях Exchange, где используется несколько серверов класса «все в одном», которые входят в группу доступности базы данных Database Availability Group (DAG), балансировщик Windows NLB применять нельзя по причине его несовместимости со средствами обеспечения отказоустойчивости Windows.

Что такое долговременное хранение

Средства балансировки нагрузки функционируют превосходно, если для каждого соединения нет необходимости сохранять данные, определяемые сеансом, например сведения о том, когда именно нужно устанавливать соединение с фермой веб-серверов, где хранятся статические данные. Впрочем, это ограничение не касается серверов с ролью Client Access. При работе с веб-клиентом Outlook (OWA), панелью Exchange Control Panel (ECP) и службами Exchange Web Services (EWS) необходимо, чтобы данные о состоянии сеанса сохранялись. Чтобы понять, каким образом специфичные для сеансов данные влияют на работу этих служб, рассмотрим такой пример. Пусть в массиве имеется два узла Client Access (с именами CAS1 и CAS2) и пусть массиву присвоено виртуальное имя mail.contoso.com. Пользователь обращается к ресурсу https://mail.contoso.com/owa с тем, чтобы зарегистрироваться со своей почтовой учетной записью. Когда он обращается к ресурсу mail.contoso.com, соединение обрабатывается узлом CAS1. Пользователь вводит свои учетные данные и начинает сеанс аутентификации. Что бы произошло, если бы пользователь открыл сообщение, а балансировщик нагрузки пришел к выводу, что обрабатывать данный запрос будет узел CAS2? Здесь нужно пояснить, что данные сеанса не являются общими для узлов CAS1 и CAS2, поэтому CAS2 не имеет сведений о результатах аутентификации пользователя. И вот, вместо того чтобы открыть сообщение, пользователь получает приглашение еще раз пройти процедуру аутентификации.

Для решения данной проблемы балансировщики нагрузки используют прием, именуемый «долговременное хранение» (persistence), или «вязкие соединения» (sticky connections). Этот прием позволяет добиться такого положения, когда в случае установления соединения с узлом CAS1 все данные передаются именно на этот узел до завершения текущего сеанса. Возможность переключения соединения на узел CAS2 возникает только при сбое в работе узла CAS1. В этом случае пользователь проходит повторную аутентификацию и продолжает взаимодействовать с узлом CAS2. При использовании внешнего балансировщика нагрузки функция долговременного хранения настраивается не на сервере Client Access, а непосредственно на этом устройстве. Как правило, внешние балансировщики обеспечивают долговременное хранение данных с использованием IP-адреса клиента, идентификатора сеанса SSL-соединения или с помощью файлов cookie; обеспечение долговременного хранения данных с использованием файлов cookie является самым распространенным приемом при балансировке нагрузок веб-клиентов Outlook.

В среде Windows NLB функция долговременного хранения данных конфигурируется с помощью настройки подобия (affinity). При использовании этой настройки пользователь имеет три варианта выбора: Network, Single или None. В таблице 1 показано, что происходит, когда выбирается каждый из этих вариантов.

 

Таблица 1. Настройки Affinity Windows NLB

Балансировка нагрузки при использовании трафика HTTP

Методы и конфигурации балансировки нагрузки определяются в зависимости от того, какие службы серверов Client Access при этом используются. Давайте рассмотрим службы на основе протокола HTTP.

OWA и панель управления Exchange (ECP). Балансировку нагрузки соединений OWA-ECP можно осуществлять так же, как балансировку нагрузки стандартного веб-приложения. При балансировке нагрузки этих служб целесообразно обеспечивать долговременное хранение данных, чтобы в вашем распоряжении всегда были сведения о сеансе. Если это условие не выполняется, пользователям, направляемым на другой сервер в массиве, будут произвольно поступать предложения повторно пройти процедуру аутентификации. Механизм долгосрочного хранения данных на базе cookie-файлов широко применяется при использовании внешних балансировщиков нагрузки. Проследите за тем, чтобы и в клиенте OWA, и в панели ECP использовалась та же конфигурация балансировщика нагрузки; в этом случае пользователь, нажавший кнопку Options в OWA, не будет направляться на другой сервер при подключении к ECP. В клиенте OWA, как и в ECP, целесообразно осуществлять балансировку нагрузки через TCP-порт 443.

Веб-службы Exchange (EWS). Балансировку нагрузки EWS-соединений можно выполнять таким же образом, как и в случае с клиентом OWA. Если клиент EWS осуществляет вызов, в ходе которого данные о состоянии в той или иной форме хранятся в памяти сервера Client Access (например, в форме события на основе оповещения, известной также под названием «подписка»), у нас должна быть гарантия того, что при осуществлении следующих вызовов данный клиент вновь будет направлен на тот же узел Client Access. Некоторые клиенты EWS не требуют использования средств долговременного хранения; для других же клиентов эти средства являются обязательными. Поэтому нелишним будет оснастить подобными средствами балансировщик нагрузки для EWS. Однако клиенты EWS, возможно, не принимают cookie-файлы, так что вам придется работать со средствами долговременного хранения на основе идентификатора сеанса SSL или IP-адреса клиента. Чтобы запросы EWS, передаваемые с сайта на сайт посредством прокси, не стирались из памяти, служба EWS использует особый параметр своего виртуального каталога, именуемый InternalNLBBypassUrl. В процессе установки сервера с ролью Client Access этот параметр принимает в качестве значения внутреннее имя данного сервера Client Access. Параметр используется для того, чтобы в процессе выполнения сценариев с прокси EWS был задействован надлежащий узел Client Access, поэтому изменять данный указатель URL не следует.

Outlook Anywhere. Всякий, кто использовал службу Outlook Anywhere в среде Exchange 2007 без функции долговременного хранения данных или с этой функцией на основе идентификатора сеанса SSL, может столкнуться с проблемами удаленного вызова процедур (RPC) в связи со службой DSProxy. RPC-соединения являются дуплексными: они предусматривают возможность одновременной передачи и получения данных. Протокол HTTP не обеспечивает такой возможности, ибо является полудуплексным. Поэтому для симулирования необходимого механизма в режиме RPC over HTTP создаются два соединения: RPC_IN_DATA — для входящих соединений и RPC_OUT_DATA — для исходящих соединений. Каждое из этих соединений ассоциируется с идентификатором сеанса для клиентов. Когда компонент RPC получает такие соединения с соответствующим идентификатором сеанса, он «понимает», что на запросы RPC_IN_DATA нужно отвечать через соединение RPC_OUT_DATA. Если для соединения RPC_IN_DATA предусмотрена та же конечная точка RPC, что и для соединения RPC_OUT_DATA, это значит, что согласование соединения может осуществляться через любой сервер с ролью Client Access. В прошлом в таких ситуациях не было проблем ни при связи с базой данных (порт 6001), ни при связи со службой ссылок (порт 6002).

Однако в среде Exchange 2007 служба DSProxy (порт 6004), не являясь реальной конечной точкой, в сущности, выступала в качестве обычного прокси. В этих обстоятельствах соединения RPC_IN_DATA и RPC_OUT_DATA иногда устанавливаются с различными контроллерами доменов DC в нарушение соединений каталогов. В ряде случаев администраторы систем Exchange 2007 во избежание подобных результатов прибегали к разного рода обходным маневрам, но это влекло за собой дополнительные риски, например опасность привязывания создания профиля Outlook к единственному контроллеру домена.

В системе Exchange 2010 эта проблема решается путем отказа от использования DSProxy. Соединения с каталогами осуществляются с помощью ссылок. Интерфейс Name Service Provider Interface (NSPI) теперь представлен на сервере Client Access в форме службы адресной книги, так что клиент устанавливает соединение с каталогом с помощью сервера Client Access, а сервер Client Access подключается к контроллеру домена по протоколу LDAP. Средства долговременного хранения не являются обязательными, но их все же можно использовать для минимизации объема подтверждающих сообщений в ходе сеанса. Правда, средства долговременного хранения данных на основе cookie-файлов не могут использоваться при работе со службой Outlook Anywhere.

Балансировка нагрузки при передаче трафика MAPI

Организация балансировки нагрузки при передачи трафика MAPI — это новая проблема, с которой мы сталкиваемся при эксплуатации Exchange 2010. Раньше трафик MAPI направлялся непосредственно на серверы почтовых ящиков, так что балансировка нагрузки в какой бы то ни было форме не требовалась. Но поскольку в среде Exchange 2010 клиенты MAPI подключаются к серверу Client Access через службу RPC Client Access service, для получения полностью избыточной и высоконадежной конфигурации необходимо задействовать средства балансировки нагрузки. И вот в системе Exchange 2010 появился предназначенный для балансировки нагрузки MAPI-трафика объект Active Directory (AD), именуемый «объект массива Client Access». Этот объект позволяет обращаться к группе размещенных в одном сайте серверов Client Access как к единому массиву. В одном сайте AD можно иметь не более одного массива Client Access.

При организации трафика MAPI используется механизм коммуникации RPC, который в этом случае действует иначе, чем при обработке трафика HTTP, используемого другими службами Client Access. RPC применяется для выполнения кода на другой системе в сети или в другом адресном пространстве в той же системе. Для установления RPC-соединения формируется запрос к порту преобразователя конечного узла RPC под номером 135. Оттуда порт изымается из динамического диапазона (порты 1024–65535), и этот порт назначается соединению RPC. Последующий обмен данными для данного соединения осуществляется через этот назначенный порт.

При использовании данной модели механизм коммуникации RPC требует, чтобы широкий диапазон портов оставался открытым для клиентов. Поэтому в модели балансировки нагрузки MAPI через RPC все эти порты — от порта 135 и до диапазона портов от 1024 до 65535 — должны быть указаны в конфигурации. Впрочем, имеется возможность статического задания используемых портов RPC. Если вы хотите воспользоваться этой возможностью, проследите, чтобы балансировщик нагрузки был настроен как для доступа к почтовым ящикам, так и для взаимодействия со службой адресной книги, поскольку в этих случаях применяются различные соединения RPC. Чтобы настроить статический порт для доступа к почтовым ящикам, нужно создать на сервере Client Access в разделе реестра HKLM\System\Current-ControlSet\Services\MSExchangeRPC\ParametersSystem параметр реестра типа DWORD с именем TCP/IP Port. Если подраздел ParametersSystem не существует, его необходимо создать. В качестве значения этого параметра введите номер порта, который вы хотите использовать. Как видно на экране, я использую порт 50000.

 

Экран. Определение значения типа DWORD с целью создания статического порта для доступа к почтовым ящикам

Для службы адресной книги следует отредактировать XML-файл с именем microsoft.exchange.addressbook.service.exe.config, размещенный в папке Bin, где вы установили Exchange. В случае установки по умолчанию этот путь будет иметь следующий вид: C:\Program Files\Microsoft\Exchange Server\V14\Bin\. Откройте этот файл в редакторе Notepad и найдите строку

Измените значение value: вместо 0 введите номер порта, который вы хотите использовать. Завершив все эти изменения, перезапустите сервер Client Access.

Если вы формируете статические порты, проследите, чтобы именно такие порты были созданы на каждом сервере Client Access в вашем массиве. Затем вы можете настроить балансировщик нагрузок таким образом, чтобы при балансировке нагрузка распределялась только по этим портам, а не по портам всего диапазона. При использовании статических портов стоит проследить, чтобы балансировщик нагрузки был настроен на порт 135 в дополнение к определенным вами двум статическим портам.

Завершив настройку балансировщика нагрузки, можете считать, что вы прошли половину пути к цели — организации балансировки нагрузки клиентов MAPI. Для завершения этого процесса остается еще создать объект «массив Client Access», назначенный сайту AD, где размещены эти серверы с ролью Client Access. Данную задачу можно решить с помощью следующей команды оболочки Exchange Management Shell (EMS):

New-ClientAccessArray
   -FQdn outlook.contoso.com
   -Site "Baltimore"

Далее требуется сконфигурировать каждую из баз данных почтовых ящиков в сайте так, чтобы они использовали этот массив Client Access. Данный шаг имеет большое значение, поскольку упомянутый параметр используется для того, чтобы указать клиентам Outlook, какой сервер Client Access служит для организации соединений с каталогами; помните: сейчас сервер Client Access содержит конечную точку NSPI. Если объект «массив Client Access» уже создан и назначен сайту, все новые базы данных почтовых ящиков, созданные в этом сайте, будут корректно настроены в автоматическом режиме. Но если до создания объекта «массив Client Access» у вас уже имелись базы данных, вы можете настроить базу данных для работы с массивом с помощью следующей команды EMS:

Set-Mailboxdatabase dB01
   -rpcclientaccessServer outlook
      . contoso.com

Завершающий этап

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

  1. Запустите серверы и при необходимости настройте статические порты для соединений RPC клиентов MAPI.
  2. Создайте записи DNS для имен с балансировкой нагрузки. В данной статье я использовал имя mail.contoso.com для веб-клиентов и outlook.contoso.com для клиентов MAPI.
  3. Установите и настройте балансировщик нагрузки. В таблице 2 приводится краткое описание портов и настроек долговременного хранения, необходимых для работы всех служб Client Access.
  4. Создайте массив Client Access с помощью команды New-ClientAccessArray.
  5. Настройте существующие на данном узле базы данных почтовых ящиков так, чтобы они могли использовать новый объект «массив Client Access».

 

Таблица 2. Порты и настройки долговременного хранения для служб Client Access

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

Кен Сен-Сир (ken.stcyr@microsoft.com) — архитектор решений компании Microsoft с более чем 10-летним опытом работы. Имеет сертификат Microsoft Certified Master in Directory Services