Apache: Модуль Apache mod_proxy

RU EN

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

Предупреждение

Не включайте прокси, пока не защитите свой сервер. Открытые прокси-серверы опасны как для вашей сети, так и для Интернета в целом.

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

В настоящее время доступно 3 алгоритма планировщика балансировки нагрузки: подсчет запросов, взвешенный подсчет трафика и подсчет ожидающих запросов. Они контролируются значением lbmethod определения Balancer. См. ProxyPass директиву для получения дополнительной информации, особенно о том, как настроить Balancer и BalancerMembers.

Прилипчивость балансировщика нагрузки

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

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

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

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

 <Прокси "balancer://mycluster">
 BalancerMember "http://192.168.1.50:80"
 BalancerMember "http://192.168.1.51:80"
</прокси>
ProxyPass "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

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

 Добавить заголовок Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<Прокси "balancer://mycluster">
 BalancerMember "http://192.168.1.50:80" route=1
 BalancerMember "http://192.168.1.51:80" route=2
 ProxySet stickysession=ROUTEID
</прокси>
ProxyPass "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

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

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

BALANCER_SESSION_STICKY: Этому присваивается значение stickysession , используемое для текущего запроса. Это имя файла cookie или параметра запроса, используемого для закрепленных сеансов.
BALANCER_SESSION_ROUTE: Этому назначен маршрут , проанализированный из текущего запроса.
БАЛАНСЕР_ИМЯ: Этому присваивается имя балансировщика, используемого для текущего запроса. Значение примерно такое balancer://foo .
BALANCER_WORKER_NAME: Этому присваивается имя работника, используемого для текущего запроса. Значение примерно такое http://hostA:1234 .
BALANCER_WORKER_ROUTE: Это назначает маршрут работника, который будет использоваться для текущего запроса.
BALANCER_ROUTE_CHANGED: Это значение равно 1, если маршрут сеанса не соответствует рабочему маршруту (BALANCER_SESSION_ROUTE != BALANCER_WORKER_ROUTE) или сеанс еще не имеет установленного маршрута. Это можно использовать для определения того, когда и нужно ли клиенту отправлять обновленный маршрут при использовании закрепленных сеансов.

Включение поддержки Balancer Manager

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

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

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

 <Расположение "/balancer-manager">
 Балансировщик-менеджер SetHandler
 Требуется хост example.com
</местоположение>

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

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

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

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

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

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

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

 ProxyPass "/test" "balancer://mycluster" stickysession=JSESSIONID|jsessionid scolonpathdelim=On
<Прокси "balancer://mycluster">
 BalancerMember "http://192.168.1.50:80" route=node1
 BalancerMember "http://192.168.1.51:80" route=node2
</прокси>

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