Балансировка нагрузки выполняет две основные задачи. Она сокращает влияние сбоя одного сервера клиентского доступа на одном из сайтов Служба каталогов Active Directory. Также балансировка нагрузки обеспечивает равномерное распределение нагрузки на сервере клиентского доступа и транспортных серверах-концентраторах.

Некоторые изменения в версии Exchange 2010 привели к тому, что балансировка нагрузки стала важной задачей в организации. Служба клиентского доступа RPC Exchange и служба адресной книги Exchange в роли сервера клиентского доступа улучшают работу пользователей во время отработки отказа почтовых ящиков благодаря перемещению конечных точек подключения для доступа к почтовым ящикам из приложения Outlook и других клиентов MAPI на сервер клиентского доступа, а не на сервер почтовых ящиков. В более ранних версиях Exchange клиент Outlook подключался напрямую к серверу почтовых ящиков, на котором размещался почтовый ящик пользователя, а подключения к каталогам передавались через прокси-соединение через роль сервера почтовых ящиков или ссылались непосредственно на определенный сервер глобального каталога Служба каталогов Active Directory. Теперь, когда эти подключения обрабатываются ролью сервера клиентского доступа, необходимо выполнить балансировку нагрузки на внешние и внутренние подключения Outlook в массиве серверов клиентского доступа, чтобы обеспечить отказоустойчивость в развертывании.

Рекомендуется создать массив серверов клиентского доступа с балансировкой нагрузки для каждого сайта Служба каталогов Active Directory и для каждой версии Exchange. Невозможно совместно использовать один массив серверов клиентского доступа с балансировкой нагрузки на нескольких сайтах Служба каталогов Active Directory или совместно работать с различными версиями Exchange либо версиями пакетов обновления Exchange в одном массиве.

При установке сервера Exchange 2010 в существующей организации и настройке пространства имен прежней версии для совместной работы с предыдущими версиями Exchange клиенты будут автоматически подключаться к серверу клиентского доступа или массиву серверов Exchange 2010. Затем сервер клиентского доступа или массив таких серверов Exchange 2010 будут передавать через прокси-соединение или перенаправлять клиентские запросы для почтовых ящиков прежних версий Exchange на серверы переднего плана Exchange 2003 или серверы клиентского доступа Exchange 2007, соответствующие версии почтового ящика. Дополнительные сведения см. в разделе Общие сведения об обновлении до Exchange 2010.

Примечание.
Можно одновременно применять различные исправления QFE и накопительные пакеты обновления ко всему массиву или к определенным серверам. Исправления QFE и накопительные пакеты обновления рекомендуется применять ко всем компьютерам массива.

Конфигурация балансировки нагрузки будет оказывать непосредственное влияние на имена узлов, используемые клиентами для установки подключений, и на используемые сертификаты SSL (Secure Sockets Layer). Дополнительные сведения о сертификатах Exchange 2010 см. в разделе Общие сведения о цифровых сертификатах и протоколе SSL.

Настройка массива серверов клиентского доступа

Если решение балансировки нагрузки обеспечивает соответствие клиента серверу клиентского доступа, это значит, что создается долговременная связь между определенным клиентом и сервером клиентского доступа. Клиентом может быть приложение Outlook, запущенное на ноутбуке, служба Microsoft Exchange ActiveSync, запущенная на мобильном устройстве, приложение Microsoft Office Outlook Web App, веб-службы Exchange и другие клиентские приложения.

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

Балансировка сетевой нагрузки Windows (WNLB) — это наиболее распространенная подсистема балансировки нагрузки, используемая для серверов Exchange. Существуют некоторые ограничения, связанные с развертыванием подсистемы WNLB в системе Microsoft Exchange.

• Подсистему WNLB невозможно использовать на серверах Exchange, на которых используются группы обеспечения доступности баз данных почтовых ящиков, так как балансировка сетевой нагрузки Windows несовместима с отказоустойчивым кластером Windows. При использовании группы обеспечения доступности баз данных Exchange 2010 и необходимости использовать подсистему WNLB требуется установить роль сервера клиентского доступа и роль сервера почтовых ящиков на отдельных серверах.
  
  
• Во избежание проблем с производительностью не рекомендуется включать более восьми серверов клиентского доступа в массив, для которого выполняется балансировка нагрузки с помощью подсистемы WNLB.
  
  
• Подсистема WNLB не обнаруживает простои в работе служб. Она обнаруживает только простои в работе серверов по IP-адресу. Это значит, что если в работе определенной веб-службы, например Outlook Web App, происходит сбой, но сервер по-прежнему работает, то подсистема WNLB не обнаружит неполадку и будет маршрутизировать запросы на этот сервер клиентского доступа. Администратору необходимо вручную удалить простаивающий сервер клиентского доступа из пула балансировки нагрузки.
  
  
• Конфигурация подсистемы WNLB может приводить к переполнению портов и перегрузке сетевой инфраструктуры.
  
  
• Так как балансировка сетевой нагрузки Windows обеспечивает соответствие для клиента только с помощью исходного IP-адреса, решение будет неэффективным, если в нем используется пул исходных IP-адресов небольшого размера. Это может происходить при использовании пула исходных IP-адресов из удаленной подсети или в случае применения преобразования сетевых адресов (NAT) в организации.
  
  

Первым вариантом балансировки нагрузки является балансировка сетевой нагрузки Windows на основе соответствия исходному IP-адресу. Это решение можно использовать, если на одном сайте Служба каталогов Active Directory существует больше одного сервера клиентского доступа, но не больше восьми. Это решение является встроенным решением Windows и не требует наличия дополнительных компьютеров.

Ниже приведены два сценария, в которых не требуется использовать балансировку сетевой нагрузки Windows.

• В организации работает обратный прокси-сервер, который взаимодействует с сервером клиентского доступа напрямую, а не через виртуальный IP-адрес подсистемы WNLB. Обратный прокси-сервер скрывает IP-адреса клиентов от массива серверов клиентского доступа. Поэтому соответствие исходному IP-адресу будет работать неправильно. Однако подсистема WNLB позволяет выполнять балансировку нагрузки для внутреннего трафика.
  
  
• В организации существуют различные клиенты, получающие доступ к серверам клиентского доступа через небольшой набор IP-адресов. Подсистема WNLB обычно используется для установления соответствия всей подсети класса C с одним сервером клиентского доступа.
  
  

Если на одном сайте Служба каталогов Active Directory существует больше восьми серверов клиентского доступа, то в организации необходимо использовать более надежное решение балансировки нагрузки. Несмотря на доступность надежных программных решений балансировки нагрузки, аппаратное решение балансировки нагрузки обеспечивает повышенную эффективность. Дополнительные сведения о решениях балансировки нагрузки для серверов Exchange 2010 см. в статье Развертывание аппаратного решения балансировки нагрузки для единой системы обмена сообщениями. 

Аппаратные подсистемы балансировки нагрузки поддерживают передачу очень большого объема трафика и могут быть настроены на балансировку нагрузки различными способами. Большинство поставщиков аппаратных подсистем балансировки нагрузки предоставляют подробную документацию, в которой описывается характер взаимодействия продукта с системой Exchange 2010. Наиболее простым способом настройки аппаратных подсистем балансировки нагрузки является создание списка резервных методов обеспечения соответствия, которые будут применяться подсистемой балансировки нагрузки. Например, подсистема балансировки нагрузки в первую очередь будет применять соответствие файлам Cookie, а затем соответствие идентификатору сеанса SSL и исходному IP-адресу.

При наличии решения с обратным прокси-сервером, позволяющего выполнять балансировку нагрузки для серверов, публикуемых в Интернете, например шлюза Microsoft Forefront Threat Management Gateway (TMG) или шлюза Forefront Unified Access Gateway (UAG), рекомендуется использовать его.

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

Однако большинство современных обратных прокси-серверов позволяют выполнять балансировку нагрузки для служб, публикуемых в Интернете. Эти обратные прокси-серверы поддерживают балансировку нагрузки на основе файлов Cookie, созданных подсистемой балансировки нагрузки, для служб Exchange, поддерживающих такое решение. Такое решение является более надежным по сравнению с балансировкой нагрузки на основе соответствия исходному IP-адресу. Для его работы необходимо, чтобы обратный прокси-сервер позволял считывать и изменять поток данных HTTP. При использовании протокола SSL обратный прокси-сервер должен расшифровывать трафик для чтения содержимого и создавать файл Cookie в потоке. Расшифровка бывает невозможна в некоторых случаях, например при использовании проверки подлинности сертификата клиента, при которой клиент подключается к серверу клиентского доступа.

В начало

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

При использовании этого варианта соответствия следует учитывать следующее.

• Подсистема балансировки нагрузки должна поддерживать этот тип соответствия. В настоящее время только аппаратные подсистемы балансировки нагрузки поддерживают такое соответствие.
  
  
• Этот вариант соответствия работает только для протоколов, передающих трафик через HTTP.
  
  
• В протоколе должен существовать файл Cookie или заголовок, остающийся неизменным на протяжении сеанса клиента и являющийся уникальным для каждого клиента (или небольшого набора клиентов).
  
  
• Решение балансировки нагрузки должно позволять считывать и интерпретировать поток данных HTTP. При использовании протокола SSL подсистема балансировки нагрузки должна расшифровывать трафик для чтения содержимого. Иногда это приводит к увеличению нагрузки на подсистему балансировки нагрузки. Кроме того, расшифровка бывает невозможна в некоторых случаях, например при использовании проверки подлинности сертификата клиента с сеансом SSL, в котором клиент подключается к серверу клиентского доступа.
  
  

Существующие файлы Cookie и заголовки HTTP, поддерживаемые для балансировки нагрузки и доступные в протоколах Exchange 2010, приведены ниже.

• Заголовок авторизации для обычной проверки подлинности HTTP   Этот заголовок работает при использовании обычной проверки подлинности HTTP. Обычная проверка подлинности используется по умолчанию и является наиболее распространенным типом проверки подлинности для службы Exchange ActiveSync. Этот заголовок в редких случаях используется для других протоколов и методов проверки подлинности. Заголовок авторизации для обычной проверки подлинности отправляет весь трафик, использующий обычную проверку подлинности и направляемый от определенного пользователя на тот же самый сервер клиентского доступа. Этот заголовок также используется, когда весь трафик Outlook передается по протоколу HTTP, а клиенты находятся за обратным прокси-сервером.
  
  
• Файл Cookie HTTP UserContext для OWA   Этот файл Cookie используется только клиентом Outlook Web App. При использовании проверки подлинности на основе форм (FBA) для приложения Outlook Web App (в соответствии с конфигурацией по умолчанию) в начале сеанса Outlook Web App перед созданием файла Cookie UserContext создается небольшое число запросов. Чтобы обеспечить соответствие для этих запросов для подключения клиента к одному и тому же серверу клиентского доступа, что является обязательным условием для работы проверки подлинности на основе форм, должен существовать резервный вариант соответствия при использовании файла Cookie UserContext. Рекомендуется использовать соответствие идентификатору сеанса SSL или исходному IP-адресу в качестве резервного варианта обеспечения соответствия для этих начальных запросов перед началом использования подсистемой балансировки нагрузки файла Cookie UserContext.
  
  

  Примечание.

  Запросы Outlook Web App, использующие явный вход в систему для получения доступа к определенному почтовому ящику, приводят к необходимости использования файла Cookie UserContext с другим именем и идентификатором. Имя этого файла Cookie начинается с UserContext, но к нему добавляется строка, идентифицирующая определенный почтовый ящик. Это усложняет балансировку нагрузки, использующую файл Cookie UserContext, так как подсистеме балансировки нагрузки необходимо в первую очередь найти файл Cookie, имя которого начинается с UserContext. В результате производительность может снижаться.

• Файл «cookie» HTTP Exchange Control Panel msExchEcpCanary   Этот файл Cookie используется только для панели управления Exchange.
  
  
• Файл Cookie HTTP OutlookSession для Outlook 2010   Аппаратные подсистемы балансировки нагрузки поддерживают файл Cookie OutlookSession, а также другие универсальные файлы Cookie.
  
  
• Файл Cookie HTTP MS-WSMAN для Remote PowerShell   Этот метод используется только для удаленной среды Remote PowerShell.
  
  

В начало

Второй по надежности способ связи сеанса клиента с сервером клиентского доступа — использование файла Cookie, созданного подсистемой балансировки нагрузки. Подсистема балансировки нагрузки добавляет файл Cookie HTTP в процесс обмена служебными данными между клиентом и сервером по протоколу, а затем использует этот файл для определения того сервера клиентского доступа, который должен обрабатывать входящий запрос. Приложениями Exchange 2010, поддерживающими этот способ, являются Outlook Web App, панель управления Exchange и удаленная среда Remote PowerShell. Существуют некоторые ограничения, связанные с использованием этого типа файлов Cookie.

• Подсистема балансировки нагрузки должна поддерживать этот тип соответствия. В настоящее время только аппаратные подсистемы балансировки нагрузки и программные подсистемы, запущенные на уровне отдельного сервера, поддерживают это соответствие.
  
  
• Этот способ работает только для протоколов, передающих трафик через протокол HTTP. Его невозможно использовать для службы клиентского доступа RPC, службы адресной книги Exchange, служб POP3 или IMAP4.
  
  
• Решение балансировки нагрузки должно позволять считывать и интерпретировать поток данных HTTP. При использовании протокола SSL подсистема балансировки нагрузки должна расшифровывать трафик для чтения содержимого. Иногда это приводит к увеличению нагрузки на подсистему балансировки нагрузки. В некоторых случаях подсистема балансировки нагрузки не может интерпретировать поток данных HTTP, например при использовании проверки подлинности сертификата клиента на сервере клиентского доступа.
  
  
• Клиент должен позволять получать произвольные файлы Cookie с сервера и включать эти файлы во все будущие запросы, отправляемые от этого клиента на сервер. Клиенты Exchange ActiveSync, Outlook Anywhere и некоторые клиенты веб-служб Exchange, например устройства Microsoft Office Communications Server 2007, не поддерживают эту возможность.
  
  

Балансировка нагрузки на основе соответствия идентификатору сеанса SSL предоставляет больше сведений по сравнению с соответствием исходному IP-адресу и позволяет разделять трафик, передаваемый различными клиентами, даже если эти клиенты выполняют вход с одного IP-адреса. Кроме того, балансировку нагрузки на основе соответствия идентификатору сеанса SSL можно выполнять без расшифровки трафика SSL. Это является обязательным условием при использовании проверки подлинности сертификата клиента и при завершении SSL-подключения на сервере клиентского доступа.

Не рекомендуется использовать соответствие идентификатору сеанса SSL в следующих двух случаях.

• Некоторые клиенты, например Internet Explorer 8, повторно создают сеанс SSL для каждого процесса браузера, выполняемого на клиентском компьютере. Это приводит к созданию нового сеанса SSL для каждого окна Outlook Web App. Так как в результате этого нарушается соответствие клиента для приложения Outlook Web App, такой способ развертывания балансировки нагрузки не поддерживается для системы Exchange 2010. Некоторые мобильные устройства, например Apple iPhone, также создают новые сеансы SSL для некоторых этапов взаимодействия службы Exchange ActiveSync с системой Exchange.
  
  

  Примечание.
  Во время проверки подлинности сертификата клиента браузеры будут использовать один сеанс SSL для всего трафика, передаваемого на заданное имя узла. Когда проверка подлинности сертификата клиента включена, идентификатор сеанса SSL является допустимым вариантом обеспечения соответствия для приложения Outlook Web App и панели управления Exchange.

• При взаимодействии с функцией Outlook Anywhere серверы клиентского доступа будут использовать компонент прокси Windows RPC для сочетания подключений RPC_DATA_IN и RPC_DATA_OUT. Это может снизить производительность.
  
  

Наиболее распространенным способом обеспечения соответствия между клиентами и серверами клиентского доступа является использование соответствия исходному IP-адресу. Подсистема балансировки нагрузки оценивает IP-адрес клиента и передает весь трафик с определенного исходного IP-адреса на определенный сервер клиентского доступа. Это единственный тип соответствия, поддерживаемый подсистемой WNLB. При использовании соответствия исходному IP-адресу необходимо принять во внимание два следующих важных положения.

• Соответствие нарушается при изменении IP-адреса клиентом. Это может происходить при перемещении ноутбука из проводной локальной сети в сеть Wi-Fi или выполнении роуминга между различными сетями Wi-Fi. При изменении IP-адреса клиентом требуется вмешательство пользователя. Например, при работе с приложением Outlook Web App пользователям потребуется выполнять проверку подлинности при каждом получении компьютером нового IP-адреса.
  
  
• Если различные клиенты получают доступ к решению балансировки нагрузки с одного IP-адреса, распределение нагрузки будет неравномерным. Степень неравномерности распределения зависит от количества клиентов, скрытых с помощью данного IP-адреса. Например, если существует четыре сервера клиентского доступа и 50 процентов клиентов получают доступ к подсистеме балансировки нагрузки с одного IP-адреса, то по меньшей мере 50 процентов трафика будет направляться на один сервер клиентского доступа, а другие три сервера будут обрабатывать оставшийся объем трафика. Существует две основные причины, по которым большинство клиентов будут получать доступ к организации Exchange через один IP-адрес.
  
  
  • Трансляторы сетевых адресов (NAT) или прокси-серверы исходящего трафика, например шлюз Microsoft Forefront Threat Management Gateway (TMG). При наличии транслятора сетевых адресов или прокси-сервера исходящего трафика между клиентами и серверами клиентского доступа исходные IP-адреса клиентов маскируются транслятором NAT или прокси-сервером исходящего трафика.
    
    
  • Прокси-трафик между серверами клиентского доступа. В некоторых сценариях один сервер клиентского доступа передает трафик через прокси-соединение на другой сервер клиентского доступа. Обычно это происходит между сайтами Служба каталогов Active Directory, так как клиенту необходимо получить доступ к серверу клиентского доступа на том же сайте Служба каталогов Active Directory, на котором расположен почтовый ящик. Дополнительные сведения о передаче через прокси-соединение см. в разделе Общие сведения по передаче данных через прокси-соединения и перенаправление.
    
    

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

Рекомендуется не использовать соответствие для протоколов, не требующих соответствия, когда настроена разгрузка SSL.

В начало

В следующей таблице приведена сводка доступных вариантов балансировки нагрузки.

У каждого из этих вариантов существуют преимущества и недостатки.

• Аппаратные подсистемы балансировки нагрузки обычно включают в себя функции, повышающие производительность и безопасность, например разгрузку SSL и проверку трафика.
  
  
• Программные подсистемы балансировки нагрузки на уровне отдельного сервера обычно входят в комплект поставки более крупных программных пакетов и предоставляют функции обратного прокси-сервера, такие как предварительная проверка подлинности, разгрузка SSL и расширенная проверка трафика. Когда программная подсистема балансировки нагрузки выполняет предварительную проверку подлинности пользователей, то им не требуется выполнять повторную проверку подлинности, если в работе сервера клиентского доступа, с которым для них установлено соответствие, произойдет сбой. Однако некоторые программные подсистемы балансировки нагрузки требуют установки соответствия между клиентом и обратным прокси-сервером. В этом случае требуется обеспечить дополнительный уровень балансировки нагрузки перед обратными прокси-серверами, чтобы эти серверы могли выполнять балансировку нагрузки для серверов клиентского доступа.