Применимо к: Exchange Server 2010 SP1

Последнее изменение раздела: 2010-09-14

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

Помимо балансировки нагрузки, система Microsoft Exchange Server 2010 предоставляет некоторые решения переключения и отказоустойчивости. К этим решениям относятся следующие.

Содержание

Обзор балансировки нагрузки

Общие сведения о распределении трафика в системе Exchange 2010

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

Рекомендации по выбору балансировки нагрузки

Варианты соответствия

Обзор балансировки нагрузки

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

Архитектурные изменения в балансировке нагрузки Exchange 2010

Некоторые изменения в версии 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.

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

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

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

Общие сведения о распределении трафика в системе Exchange 2010

Чтобы настроить балансировку нагрузки, необходимо иметь представление о нагрузке на сервер клиентского доступа Exchange 2010. Сервер клиентского доступа Exchange 2010 получает трафик следующих трех типов:

  • трафик от внешних клиентов;

  • трафик от внутренних клиентов;

  • прокси-трафик с других серверов клиентского доступа.

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

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

В начало

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

Существует несколько ключевых различий в технологиях решений балансировки нагрузки.

  • Производительность   Количество запросов, которое решение может обрабатывать в секунду.

  • Управляемость   Сложность настройки и развертывания решения балансировки нагрузки.

  • Автоматизация отработки отказа и определение сбоя   Точность и скорость определения подсистемой балансировки нагрузки сбоя службы или сервера клиентского доступа.

  • Соответствие   Типы соответствия клиента серверу клиентского доступа, поддерживаемые решением балансировки нагрузки.

Общие сведения о соответствии

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

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

Балансировка сетевой нагрузки Windows

Балансировка сетевой нагрузки 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-адресу

Первым вариантом балансировки нагрузки является балансировка сетевой нагрузки 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 в потоке. Расшифровка бывает невозможна в некоторых случаях, например при использовании проверки подлинности сертификата клиента, при которой клиент подключается к серверу клиентского доступа.

В начало

Варианты соответствия

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

  • Подсистема WNLB поддерживает только соответствие исходному IP-адресу или не использует соответствие.

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

  • Аппаратные подсистемы балансировки нагрузки с разгрузкой SSL позволяют настраивать более сложное поведение. Например, можно настроить набор существующих файлов Cookie, которые будут применяться для протоколов, поддерживающих эти файлы, а также соответствие файлам Cookie, созданным подсистемой балансировки нагрузки, соответствие идентификатору сеанса SSL и соответствие исходному IP-адресу.

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

Существующие файлы Cookie или заголовки HTTP

Использование существующих файлов 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, созданного подсистемой балансировки нагрузки. Подсистема балансировки нагрузки добавляет файл 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

Балансировка нагрузки на основе соответствия идентификатору сеанса 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-адрес клиента и передает весь трафик с определенного исходного 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.

В начало

Сводка вариантов балансировки нагрузки

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

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

Аппаратная подсистема балансировки нагрузки

В зависимости от протокола и клиента в качестве резервных могут использоваться следующие варианты:

  1. существующий файл Cookie;

  2. файл Cookie, созданный подсистемой балансировки нагрузки;

  3. идентификатор SSL;

  4. исходный IP-адрес.

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

++++

$$$

Программная подсистема балансировки нагрузки на уровне отдельного сервера

Примечание. Использование шлюзов TMG и UAG является единственным допустимым решением для внешнего трафика.

Файл Cookie, созданный подсистемой балансировки нагрузки, или исходный IP-адрес (в зависимости от протокола и клиента).

Автоматическая отработка отказа с минимальным временем простоя клиента.

++

$$

Программная подсистема балансировки нагрузки на одном уровне сервера с сервером клиентского доступа (подсистема WNLB)

Исходный IP-адрес.

Автоматическая отработка отказа с минимальным временем простоя клиента.

+

$

Циклический перебор DNS

Каждый клиент получает случайный IP-адрес сервера клиентского доступа.

Выполнение шагов по обнаружению неполадок и отработке отказа вручную. Использование кэшей DNS в клиенте является причиной медленной отработки отказа. Это решение нарушает соответствие для некоторых протоколов, таких как Outlook Web App, веб-службы Exchange и панель управления Exchange.

+++

$

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

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

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

+

Недоступно

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

  • Аппаратные подсистемы балансировки нагрузки обычно включают в себя функции, повышающие производительность и безопасность, например разгрузку SSL и проверку трафика.

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