Модуль 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) и подсчёт трафика по сигналам Heartbeat (mod_lbmethod_heartbeat). Они задаются с помощью значения lbmethod в определении балансировщика. Дополнительные сведения, особенно о настройке балансировщика и его участников, см. в директиве ProxyPass.

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

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

Модуль mod_proxy_balancer реализует закрепление двумя альтернативными способами: с помощью файлов cookie и кодирования URL. Файл cookie может предоставляться серверной частью или самим веб-сервером Apache. Кодирование URL обычно выполняется на серверной части.

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

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

<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, даже если сервер backend не устанавливает подходящий сеансовый файл cookie:

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

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 ...>.

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

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

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

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

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

Наконец, можно одновременно поддерживать файлы cookie и кодирование URL, указав имя файла cookie и имя параметра 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>

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

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

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

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

%{MYCOOKIE}C

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

%{Set-Cookie}o

Записывает все файлы cookie, установленные серверной частью. Это позволяет проверить, устанавливает ли серверная часть ожидаемый сеансовый файл cookie и какое значение ему присваивается.

%{BALANCER_SESSION_STICKY}e

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

%{BALANCER_SESSION_ROUTE}e

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

%{BALANCER_WORKER_ROUTE}e

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

%{BALANCER_ROUTE_CHANGED}e

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

Распространённая причина потери сеанса — истечение времени ожидания сеанса; обычно этот параметр настраивается на серверной части.

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