Руководство по обратным прокси

Помимо выполнения роли «базового» веб-сервера и предоставления статического и динамического контента конечным пользователям, Apache httpd (как и большинство других веб-серверов) также может действовать как сервер обратного проксирования, также известный как сервер «шлюза».

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

Существует множество причин для такой реализации, но, как правило, типичными мотивами являются безопасность, высокая доступность, балансировка нагрузки и централизованная аутентификация/авторизация. В таких реализациях крайне важно, чтобы структура, дизайн и архитектура инфраструктуры бэкенда (серверов, которые фактически обрабатывают запросы) были изолированы и защищены от внешнего доступа; с точки зрения клиента, сервер обратного проксирования является единственным источником всего контента.

Типичная реализация приведена ниже:

Обратный прокси

Простое обратное проксирование

Директива ProxyPass задаёт сопоставление входящих запросов с сервером бэкенда (или кластером серверов, известным как группа Balancer). Простейший пример перенаправляет все запросы ("/") на один сервер бэкенда:

ProxyPass "/"  "http://www.example.com/"

Чтобы гарантировать, что заголовки, сгенерированные сервером бэкенда, и Location: изменены так, чтобы указывать на обратный прокси, а не на себя, обычно требуется директива ProxyPassReverse.

ProxyPass "/"  "http://www.example.com/"
ProxyPassReverse "/"  "http://www.example.com/"

Перенаправлять можно только определённые URI, как показано в этом примере:

ProxyPass "/images"  "http://www.example.com/"
ProxyPassReverse "/images"  "http://www.example.com/"

В приведённом примере все запросы, начинающиеся с пути /images, будут перенаправлены на указанный сервер бэкенда, в противном случае они будут обработаны локально.

Кластеры и балансировщики

Несмотря на полезность вышеописанного, оно всё же имеет недостатки: если узел (единственный) сервера бэкенда выйдет из строя или сильно загрузится, перенаправление запросов не принесёт реальной выгоды. Необходимо иметь возможность определять набор или группу серверов бэкенда, которые могут обрабатывать такие запросы, и чтобы обратный прокси мог осуществлять балансировку нагрузки и отказоустойчивость между ними. Такую группу иногда называют кластером, но в Apache httpd она называется балансировщиком. Определяется балансировщик с использованием директив <Proxy> и BalancerMember, как показано:

<Proxy balancer://myset>
    BalancerMember http://www2.example.com:8080
    BalancerMember http://www3.example.com:8080
    ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass "/images/"  "balancer://myset/"
ProxyPassReverse "/images/"  "balancer://myset/"

Схема balancer:// указывает httpd, что мы создаём набор балансировщиков с именем myset. Он включает 2 сервера бэкенда, которые httpd называет BalancerMembers. В этом случае все запросы на /images будут перенаправлены на один из 2 серверов бэкенда. Директива ProxySet указывает, что балансировщик myset использует алгоритм балансировки нагрузки, основанный на байтах ввода-вывода.

Настройка балансировщика и членов балансировщика

Вы можете настроить множество параметров конфигурации балансировщиков и работников, используя различные параметры, определённые в ProxyPass. Например, если нам нужно, чтобы http://www3.example.com:8080 обрабатывал в 3 раза больше трафика с таймаутом в 1 секунду, мы изменим конфигурацию следующим образом:

<Proxy balancer://myset>
    BalancerMember http://www2.example.com:8080
    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
    ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass "/images"  "balancer://myset/"
ProxyPassReverse "/images"  "balancer://myset/"

Отказоустойчивость

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

1. http://spare1.example.com:8080 и http://spare2.example.com:8080 будут получать трафик только в том случае, если один или оба из http://www2.example.com:8080 или http://www3.example.com:8080 недоступны. (Один резервный будет использован для замены одного неработоспособного члена того же набора балансировщиков.)
2. http://hstandby.example.com:8080 будет получать трафик только в том случае, если все другие работники в наборе балансировщиков 0 недоступны.
3. Если все работники, резервные и резервные работники набора балансировщиков 0 недоступны, только тогда работники http://bkup1.example.com:8080 и http://bkup2.example.com:8080 из набора балансировщиков 1 будут включены в работу.

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

<Proxy balancer://myset>
    BalancerMember http://www2.example.com:8080
    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
    BalancerMember http://spare1.example.com:8080 status=+R
    BalancerMember http://spare2.example.com:8080 status=+R
    BalancerMember http://hstandby.example.com:8080 status=+H
    BalancerMember http://bkup1.example.com:8080 lbset=1
    BalancerMember http://bkup2.example.com:8080 lbset=1
    ProxySet lbmethod=byrequests
</Proxy>

ProxyPass "/images/"  "balancer://myset/"
ProxyPassReverse "/images/"  "balancer://myset/"

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

Менеджер балансировщика

Одним из самых уникальных и полезных функций обратного прокси-сервера Apache httpd является встроенное приложение balancer-manager. Аналогично mod_status, balancer-manager отображает текущую рабочую конфигурацию и состояние включённых балансировщиков и работников, используемых в данный момент. Однако, помимо отображения этих параметров, он также позволяет динамически, во время работы, переконфигурировать почти все из них, включая добавление новых BalancerMembers (работников) в существующий балансировщик. Для активации этих возможностей необходимо добавить следующее в вашу конфигурацию:

<Location "/balancer-manager">
    SetHandler balancer-manager
    Require host localhost
</Location>

При обращении к серверу обратного проксирования по этому URL-адресу (например: http://rproxy.example.com/balancer-manager/, вы увидите страницу, подобную приведённой ниже:

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

А при нажатии на работника отобразится эта страница:

Чтобы эти изменения сохранились после перезапуска обратного проксирования, убедитесь, что BalancerPersist включён.

Динамические проверки состояния

Перед тем как httpd перенаправит запрос работнику, он может «проверить» доступность этого работника, установив параметр ping для этого работника с помощью ProxyPass. Зачастую полезнее проверять состояние работников вне зоны, динамически. Это достигается в Apache httpd модулем mod_proxy_hcheck.

Флаги состояния BalancerMember

В balancer-manager отображается текущее состояние, или статус, работника, и его можно установить/сбросить. Значения этих статусов следующие: