Модуль Apache mod_proxy_balancer

Обзор

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

• HTTP, используя mod_proxy_http
• FTP, используя mod_proxy_ftp
• AJP13, используя mod_proxy_ajp
• WebSocket, используя mod_proxy_wstunnel

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

• mod_lbmethod_byrequests
• mod_lbmethod_bytraffic
• mod_lbmethod_bybusyness
• mod_lbmethod_heartbeat

Таким образом, для получения возможности балансировки нагрузки, mod_proxy, mod_proxy_balancer и по крайней мере один из модулей алгоритмов планировщика балансировки нагрузки должны присутствовать в сервере.

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

В настоящее время доступны 4 алгоритма планировщика балансировки нагрузки: подсчет запросов (mod_lbmethod_byrequests), взвешенный подсчет трафика (mod_lbmethod_bytraffic), подсчет ожидающих запросов (mod_lbmethod_bybusyness) и подсчет трафика по сигналам «жизнеспособности» (mod_lbmethod_heartbeat). Они контролируются значением lbmethod определения балансировщика. См. директиву ProxyPass для получения дополнительной информации, особенно о настройке балансировщика и его членов.

Привязка балансировщика нагрузки

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

Модуль mod_proxy_balancer реализует привязку на основе двух альтернативных способов: куки и кодирование URL. Предоставление куки может быть выполнено либо бэкендом, либо самим веб-сервером Apache. Кодирование URL обычно выполняется на бэкенде.

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

Прежде чем углубляться в технические детали, вот пример того, как вы можете использовать mod_proxy_balancer для балансировки нагрузки между двумя бэкенд-серверами:

<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80"
    BalancerMember "http://192.168.1.51:80"
</Proxy>
ProxyPass        "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

Еще один пример балансировки нагрузки с привязкой, используя mod_headers, даже если бэкенд-сервер не устанавливает подходящий куки сессии:

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80" route=1
    BalancerMember "http://192.168.1.51:80" route=2
    ProxySet stickysession=ROUTEID
</Proxy>
ProxyPass        "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

Экспортированные переменные среды

В настоящее время экспортированы 6 переменных среды:

BALANCER_SESSION_STICKY

Присваивается значение stickysession, используемое для текущего запроса. Это имя куки или параметра запроса, используемого для привязки сессий.

BALANCER_SESSION_ROUTE

Присваивается значение route, разобранное из текущего запроса.

BALANCER_NAME

Присваивается имя балансировщика, используемого для текущего запроса. Значение — что-то вроде balancer://foo.

BALANCER_WORKER_NAME

Присваивается имя обработчика, используемого для текущего запроса. Значение — что-то вроде http://hostA:1234.

BALANCER_WORKER_ROUTE

Присваивается route обработчика, который будет использоваться для текущего запроса.

BALANCER_ROUTE_CHANGED

Устанавливается в 1, если маршрут сессии не совпадает с маршрутом обработчика (BALANCER_SESSION_ROUTE != BALANCER_WORKER_ROUTE) или сессия еще не имеет установленного маршрута. Это можно использовать для определения того, когда/если клиенту необходимо отправить обновленный маршрут при использовании привязки сессий.

Включение поддержки менеджера балансировщика

Этот модуль требует сервиса mod_status. Менеджер балансировщика позволяет динамически обновлять членов балансировщика. Вы можете использовать менеджер балансировщика для изменения коэффициента баланса определенного члена или перевести его в автономный режим.

Таким образом, для получения возможности управления балансировщиком нагрузки, mod_status и mod_proxy_balancer должны присутствовать в сервере.

Для включения управления балансировщиком нагрузки для браузеров из домена example.com добавьте этот код в свой файл конфигурации httpd.conf.

<Location "/balancer-manager">
    SetHandler balancer-manager
    Require host example.com
</Location>

Теперь вы можете получить доступ к менеджеру балансировщика, используя веб-браузер для доступа к странице http://your.server.name/balancer-manager. Обратите внимание, что только балансировщики, определенные вне контейнеров <Location ...>, могут динамически контролироваться менеджером.

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

При использовании привязки на основе куки необходимо настроить имя куки, содержащей информацию о том, какой бэкенд использовать. Это делается с помощью атрибута stickysession, добавленного к ProxyPass или ProxySet. Имя куки чувствительно к регистру. Балансировщик извлекает значение куки и ищет обработчик-участник с route, равным этому значению. route также должен быть установлен в ProxyPass или ProxySet. Куки может быть установлен бэкендом или, как показано в вышеприведенном примере, самим веб-сервером Apache.

Некоторые бэкенды используют несколько другую форму куки привязки, например Apache Tomcat. Tomcat добавляет имя экземпляра Tomcat в конец куки идентификатора сессии, разделенного точкой (.) с идентификатором сессии. Таким образом, если веб-сервер Apache находит точку в значении куки привязки, он использует только часть за точкой для поиска маршрута. Чтобы уведомить Tomcat об имени своего экземпляра, необходимо установить атрибут jvmRoute в файле конфигурации Tomcat conf/server.xml в значение route обработчика, подключенного к соответствующему Tomcat. Имя куки сессии, используемое Tomcat (и более широко приложениями Java на основе сервлетов), равно JSESSIONID (заглавными буквами), но может быть настроено на другое значение.

Второй способ реализации привязки — кодирование URL. Веб-сервер ищет параметр запроса в URL запроса. Имя параметра снова указывается с помощью stickysession. Значение параметра используется для поиска обработчика-участника с route, равным этому значению. Поскольку сложно извлечь и изменить все ссылки URL, содержащиеся в ответах, обычно работа по добавлению параметров к каждой ссылке выполняется бэкендом, генерирующим контент. В некоторых случаях это может быть выполнимо с помощью веб-сервера, используя mod_substitute или mod_sed. Однако это может негативно повлиять на производительность.

Стандарты Java реализуют кодирование URL несколько иначе. Они используют путь info, добавленный к URL с помощью точки с запятой (;) в качестве разделителя и добавляют идентификатор сессии позади. Как и в случае с куки, Apache Tomcat может включить настроенный jvmRoute в этот путь info. Чтобы позволить Apache найти этот тип пути info, необходимо установить scolonpathdelim на On в ProxyPass или ProxySet.

Наконец, вы можете одновременно поддерживать куки и кодирование URL, настроив имя куки и имя параметра URL, разделенные вертикальной чертой (|), как в следующем примере:

ProxyPass "/test" "balancer://mycluster" stickysession=JSESSIONID|jsessionid scolonpathdelim=On
<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80" route=node1
    BalancerMember "http://192.168.1.51:80" route=node2
</Proxy>

Если куки и параметр запроса оба предоставляют информацию о маршрутизации для одного запроса, используется информация из параметра запроса.

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

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

Чтобы проверить вашу конфигурацию, сначала проверьте, основана ли привязка на куки или на кодировании URL. Следующим шагом будет регистрация соответствующих данных в журнале доступа, используя расширенный LogFormat. Следующие поля полезны:

%{MYCOOKIE}C

Значение, содержащееся в куки с именем MYCOOKIE. Имя должно быть таким же, как указано в атрибуте stickysession.

%{Set-Cookie}o

Это регистрирует любые куки, установленные бэкендом. Вы можете отслеживать, устанавливает ли бэкенд ожидаемый куки сессии и какое значение он имеет.

%{BALANCER_SESSION_STICKY}e

Имя куки или параметра запроса, используемого для поиска информации о маршрутизации.

%{BALANCER_SESSION_ROUTE}e

Информация о маршруте, найденная в запросе.

%{BALANCER_WORKER_ROUTE}e

Маршрут выбранного обработчика.

%{BALANCER_ROUTE_CHANGED}e

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

Общие причины потери сессии — тайм-ауты сессии, которые обычно настраиваются на сервере бэкенда.

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