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

Помимо функций «обычного» веб-сервера и предоставления конечным пользователям статического и динамического содержимого, 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 будут перенаправляться на один из двух внутренних серверов. Директива ProxySet указывает, что балансировщик myset должен использовать алгоритм балансировки нагрузки на основе объёма операций ввода-вывода.

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

Можно настроить множество параметров балансировщиков и рабочих узлов с помощью различных параметров, определённых в 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 отображается текущее состояние, или статус, рабочего узла; его можно установить или сбросить. Значения статусов описаны ниже: