Балансировка нагрузки фермы серверов дает администратору Шлюз Microsoft Forefront Threat Management следующие возможности при публикации фермы веб-серверов, выполняющих одинаковую функцию или служащих для размещения одинакового содержимого.

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

Создание ферм серверов

Forefront TMG позволяет объединять серверы в группы, если они отвечают следующим условиям.

  • Все серверы в составе фермы содержат одинаковую информацию, например дублирующие серверы.

  • Все серверы в составе фермы выполняют одинаковую функцию, например опубликованные серверы веб-клиента Microsoft Outlook.

Веб серверы объединяются в ферму путем создания фермы серверов. В Forefront TMG все веб-серверы в составе определенной фермы рассматриваются как единый объект. При создании фермы серверов необходимо указать следующие параметры.

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

  • Метод наблюдения за подключениями к каждому серверу в составе фермы. Возможные методы включают отправку HTTP-запроса GET, запроса PING или запроса на установление TCP-подключения на определенный порт. В зависимости от выбранного метода Forefront TMG автоматически создает средство проверки подключения ко всем серверам фермы. Запрос проверки подключения посылается каждому участнику фермы каждые 30 секунд, и время ответа сравнивается с пороговым значением времени ожидания, равным по умолчанию 5000 мсек. Forefront TMG использует ответы для определения состояния серверов в составе фермы. Обратите внимание на следующие ограничения при выборе HTTP-запросов GET в качестве метода проверки подключения к серверам фермы.

    • Отправка HTTP-запросов GET поддерживается только для серверов, в именах которых содержатся только символы латинского алфавита.

    • В качестве узла в URL-адресе необходимо указывать подстановочный знак (*). Forefront TMG подставляет вместо него имена серверов фермы. Например, если в состав фермы входят серверы А и Б, а URL-адрес задан в виде http://*/status.htm, Forefront TMG будет проверять подключения по URL-адресам http://A/status.htm и http://B/status.htm.

    • В большинстве случаев необходимо включить правило системной политики «Разрешить отправлять запросы HTTP/HTTPS с сервера Forefront TMG на выбранные серверы для средств проверки подключения». Однако если в URL-адресе указывается нестандартный порт (например, http://*:88/status.htm), использование предопределенного правила системной политики становится невозможным. Вместо этого необходимо создать пользовательское правило доступа, чтобы разрешить передачу трафика по протоколам HTTP и HTTPS от сервера Forefront TMG к ферме серверов через произвольный порт.

    • При выборе HTTP-запросов GET в качестве метода проверки подключения можно указать произвольный заголовок узла для включения в запросы проверки подключения. Это полезно в случае, если веб-приложение, публикуемое фермой серверов, требует определенного заголовка узла.

После создания фермы серверов с помощью мастера создания фермы серверов на страницах свойств фермы серверов можно настроить следующие дополнительные свойства.

  • Пороговое значение времени ожидания для средства проверки подключения. По умолчанию Forefront TMG устанавливает это значение равным 5000 миллисекунд.

  • В целях мониторинга можно настроить срабатывание оповещения в случае, если ответ не был получен в течение указанного временного периода.

Инструкции по созданию ферм серверов см. в разделе Создание сетевых объектов.

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

Для реализации алгоритма балансировки нагрузки Forefront TMG может использовать соответствие сеансов (балансировка нагрузки на основе файлов cookie) и соответствие IP-адресов (балансировка нагрузки на основе IP-адресов источника).

Соответствие сеансов

Соответствие сеансов использует файлы cookie для определения клиента и установления его соответствия с определенным веб-сервером. Для использования данной функции веб-обозреватель должен уметь принимать файлы cookie по HTTP. Прием файлов cookie поддерживается всеми обозревателями, совместимыми с HTTP 1.1, а также некоторыми версиями, совместимыми с HTTP 1.0. Соответствие сеансов поддерживается до тех пор, пока веб-обозреватель не будет закрыт на клиентском компьютере.

Назначением соответствия сеансов является равномерное распределение клиентских сеансов (под сеансом здесь понимается некоторое число последовательных веб-запросов по одному TCP-соединению) среди участников фермы. Соответствие сеансов не поддерживает неравномерное распределение запросов (например, 50 процентов трафика к серверу 1 фермы, 20 процентов - к серверу 2 и т.д.). Вместо этого функция соответствия сеансов использует механизм циклического обслуживания для обеспечения равномерного распределения сеансов, которые устанавливаются между обозревателями и веб-приложениями, обслуживаемыми фермой серверов, между участниками фермы.

При использовании соответствия сеансов, если веб-сервер, например Веб-сервер 1, выходит из строя, подключенные к нему клиенты будут перенаправлены Forefront TMG на другой сервер, например Веб-сервер 2. При этом контекст веб-сеанса будет утерян. Если Веб-сервер 1 снова становится доступен, соответствие сеансов поддерживается с Веб-сервером 2 до завершения сеанса.

Любые ответы на HTTP-запросы, созданные во время сеанса веб-обозревателя, передаются отправившему их клиенту. При наличии такой возможности рекомендуется использовать соответствие сеансов, поскольку оно обеспечивает более надежное соответствие клиентов при перезапуске веб-сервера. Иногда это называют привязкой клиентов. Привязка обеспечивается файлом cookie, который Forefront TMG вставляет в ответ на клиентский запрос. Этот файл cookie включается обозревателем клиента в последующие запросы и указывает на то, к какому серверу фермы Forefront TMG должен выполнить подключение.

Соответствие сеансов пригодно для публикации серверов веб-клиента Outlook и веб-узлов SharePoint. Его использование нецелесообразно при публикации сервера Exchange с помощью RPC через HTTP, когда в роли клиентского приложения выступает не веб-обозреватель, а экземпляр Microsoft Outlook, не умеющий работать с файлами cookie.

Соответствие IP-адресов

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

Назначением соответствия IP-адресов является равномерное распределение запросов с различных IP-адресов между участниками фермы. Равномерное распределение сохраняется и в случае отказа каких-либо серверов. Отказоустойчивость достигается путем выявления не отвечающих на запросы серверов и распределения нагрузки между доступными серверами. Администраторы Forefront TMG могут удалить сервер из фермы с помощью двухэтапной процедуры, не разрывая существующие клиентские подключения.

При использовании соответствия на основе IP-адресов, если веб-сервер выходит из строя, подключенные к нему клиенты будут перенаправлены Forefront TMG на другой сервер При этом контекст веб-сеанса будет утерян. Подобным образом, при перезапуске этого веб-сервера запросы от этих клиентов будут направлены на него, и контекст снова теряется.

Соответствие на основе IP-адресов имеет преимущество перед соответствием сеансов, поскольку оно поддерживается клиентами, не имеющими полной совместимости с HTTP 1.1 (не поддерживающими файлы cookie HTTP), например некоторыми мобильными устройствами.

Соответствие IP-адресов не следует использовать в случае, когда удаленные клиенты расположены за устройством преобразования сетевых адресов, или если Forefront TMG выступает в качестве вышестоящего сервера и ему доступен только IP-адрес нижестоящего сервера Forefront TMG. В этом случае следует использовать только соответствие сеансов.

Соответствие IP-адресов оказывается особенно полезным в случае публикации сервера Exchange с помощью RPC через HTTP, когда соответствие сеансов не может быть использовано, поскольку файлы cookie не поддерживаются клиентским приложением Outlook.

Наблюдение за состоянием фермы серверов

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

  • Активен. Это нормальное состояние сервера, добавленного к ферме. Оно означает, что сервер может принимать запросы, направляемые к ферме.

  • Недоступен. Это состояние сервера означает, что средство проверки подключения не получило от сервера ответ по истечении заданного периода ожидания (по умолчанию 5000 миллисекунд). Этому участнику фермы запросы не направляются.

  • Завершение работы. Данное состояние указывает на то, что сервер постепенно завершает работу. Сервер продолжит обработку уже полученных запросов, но новые запросы направляться на него не будут.

  • Удален. Это состояние указывает на то, что сервер был удален из фермы и не принимает запросы.

  • Не удается выполнить проверку. Это состояние указывает на то, что состояние сервера не удается проверить.

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

Состояние участников фермы можно проверить на вкладке Средства проверки подключения узла Наблюдение диспетчера Forefront TMG. Значок в виде зеленой галочки указывает на то, что время отклика участника фермы меньше порогового значения времени ожидания. Красный значок ошибки указывает на то, что средство проверки подключения не получило ответ по истечении периода ожидания. Текущее время отклика отображается в столбце Пороговое значение, а состояние - в столбце Результат.

Постепенное завершение работы и удаление серверов

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

Публикация фермы серверов

Публикация фермы серверов производится аналогично публикации отдельного веб-сервера при помощи мастеров публикации Forefront TMG.

  • Для публикации фермы серверов веб-клиента Outlook или фермы серверов Outlook с помощью RPC через HTTP используется мастер создания правила публикации доступа веб-клиента Exchange.

  • Для публикации веб-узла SharePoint на ферме серверов используется мастер создания правила публикации веб-узла SharePoint.

  • Для публикации фермы веб-узла используется мастер создания правила публикации веб-узла.

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

  • Укажите имя правила.

  • В случае публикации веб-клиента Outlook укажите почтовые службы, которые необходимо опубликовать.

  • Выберите публикацию фермы серверов с балансировкой нагрузки.

  • Выберите вариант подключения по HTTP или HTTPS между сервером Forefront TMG и фермой серверов. При выборе HTTPS-подключения учетные данные клиента пересылаются сервером Forefront TMG на опубликованный веб-сервер в зашифрованном виде.

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

    • Когда приложение обозревателя вырабатывает запрос, в него включается заголовок узла, определяющий указанный пользователем в URL-адресе узел. По умолчанию, когда сервер Forefront TMG получает запрос, он изменяет имя узла в заголовке узла и использует внутреннее имя узла в качестве имени узла в HTTP-запросах, посылаемых веб-серверам в составе фермы. Если вместо настроек Forefront TMG по умолчанию выбрано использование исходного заголовка узла клиента, внутреннее имя узла не используется.

    • Если правило веб-публикации требует SSL-соединения между сервером Forefront TMG и участником опубликованной фермы серверов, можно установить уникальный сертификат на каждом участнике фермы, либо копии одного сертификата на всех участниках. При создании сертификата необходимо использовать внутреннее имя узла, указанное в правиле веб-публикации, в качестве общего имени.

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

    • Даже если отсутствует необходимость в обеспечении внутреннего доступа к ферме серверов или преобразовании ссылок, модуль обработки правил Forefront TMG должен производить разрешение внутреннего имени узла. В этом случае рекомендуется присвоить внутреннему имени узла DNS-имя одного из серверов фермы.

  • Выберите ферму серверов для публикации. Если ферма серверов не была создана ранее, ее можно создать с помощью мастера публикации.

  • Укажите внешнее имя, которое внешние пользователи будут вводить в веб-обозревателе для получения доступа к опубликованной ферме серверов.

  • Укажите веб-прослушиватель для данного правила. Веб-прослушиватель определяет: будут ли клиенты подключаться к серверу Forefront TMG по протоколу HTTP или HTTPS; сеть, в которой веб-прослушиватель будет принимать клиентские запросы; сжатие содержимого по запросу клиента; IP-адреса, которые будут прослушиваться на запросы; параметры проверки подлинности клиентов и сертификат веб-прослушивателя при использовании SSL-подключения. Можно выбрать один сертификат для веб-прослушивателя или сертификат для конкретного IP-адреса. Несколько сертификатов не могут быть привязаны к одному IP-адресу.

  • Укажите метод проверки подлинности, который будет использоваться сервером Forefront TMG при проверке подлинности на опубликованном сервере.

Балансировка нагрузки в сценариях безопасной публикации

Обратите внимание на следующие особенности балансировки HTTPS-запросов к ферме серверов.

  • Балансировка нагрузки не поддерживается для SSL-соединений, устанавливаемых по туннелю через Forefront TMG (публикация сервера). Оно поддерживается в случае веб-публикации, только если HTTPS-соединение завершается на сервере Forefront TMG и далее перенаправляется по протоколам HTTP или HTTPS к ферме серверов (мост HTTPS-HTTP и HTTPS-HTTPS).

  • В случае использования моста HTTPS поддерживается как соответствие IP-адресов (на основе IP-адресов источника), так и соответствие сеансов (на основе файлов cookie).

  • В случае использования моста HTTPS-HTTPS серверы в составе фермы проходят проверку подлинности на сервере Forefront TMG с помощью сертификата сервера. Возможны следующие варианты установки этих сертификатов.

    • Установка сертификата сервера на каждом сервере в составе фермы. Например, если ферма серверов состоит из серверов Server1.internal.net, Server2.internal.net и Server3.internal.net, необходимо приобрести уникальный сертификат для каждого сервера с именем участника фермы, как оно представлено в самой ферме.

    • Установка сертификата сервера для фермы серверов. В этом случае необходимо получить сертификат с внутренним именем узла, которые было указано в правиле веб-публикации для фермы, и установить сертификат на каждом сервере в составе фермы.