Apache: Руководство по настройке обратного прокси

RU EN

Пункт 55. Руководство по настройке обратного прокси

Помимо того, что он является «базовым» веб-сервером и предоставляет статический и динамический контент конечным пользователям, 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> and BalancerMember , как показано ниже:

 <Прокси балансировщик://myset>
 BalancerMember http://www2.example.com:8080
 BalancerMember http://www3.example.com:8080
 ProxySet lbmethod=bytraffic
</прокси>
ProxyPass "/images/" "балансировщик://myset/"
ProxyPassReverse "/images/" "balancer://myset/"

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

Намекать

BalancerMembers также иногда называют работниками .

Конфигурация Balancer и BalancerMember

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

 <Прокси балансировщик://myset>
 BalancerMember http://www2.example.com:8080
 BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
 ProxySet lbmethod=bytraffic
</прокси>
ProxyPass "/images" "балансировщик://myset/"
ProxyPassReverse "/images" "balancer://myset/"

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

Вы также можете точно настроить различные сценарии отработки отказа, подробно указав, к каким рабочим процессам и даже к каким балансировщикам следует обращаться в таких случаях. Например, приведенная ниже настройка реализует 2 случая аварийного переключения: в первом случае http://hstandby.example.com:8080 трафик отправляется только в том случае, если все другие рабочие процессы в балансировщике myset недоступны. Если сам этот рабочий недоступен, только тогда рабочие http://bkup1.example.com:8080 и http://bkup2.example.com:8080 будут переведены в ротацию:

 <Прокси балансировщик://myset>
 BalancerMember http://www2.example.com:8080
 BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
 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
</прокси>
ProxyPass "/images/" "балансировщик://myset/"
ProxyPassReverse "/images/" "balancer://myset/"

Волшебство этой настройки аварийного переключения заключается в настройке http://hstandby.example.com:8080 с помощью +H флага состояния, который переводит его в режим горячего резерва и делает 2 bkup# сервера частью набора балансировщика нагрузки № 1 (по умолчанию установлено значение 0); для отказоустойчивости в первую очередь используются горячие резервы (если они есть), когда все штатные воркеры недоступны; Наборы балансировщика нагрузки всегда сначала проверяются с наименьшим номером.

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

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

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

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

Не включайте менеджер балансировки , пока не защитите свой сервер. В частности, убедитесь, что доступ к URL-адресу строго ограничен.

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

страница менеджера балансировщика

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

страница менеджера балансировщика

При нажатии на рабочего отображается эта страница:

страница менеджера балансировщика

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

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

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

Флаги статуса BalancerMember

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

Флаг	Нить	Описание
	Хорошо	Рабочий доступен
	В этом	Рабочий процесс был инициализирован
`D`	Дис	Worker отключен и не будет принимать запросы; будет автоматически повторена попытка.
`S`	Останавливаться	Работник административно остановлен; не будет принимать запросы и не будет автоматически повторяться
`I`	Зажечь	Рабочий находится в режиме игнорирования ошибок и всегда будет считаться доступным.
`H`	Stby	Рабочий процесс находится в режиме горячего резерва и будет использоваться только в том случае, если нет других жизнеспособных рабочих процессов.
`E`	ошибся	Worker находится в состоянии ошибки, обычно из-за сбоя проверки перед запросом; запросы не будут передаваться этому рабочему процессу, но будут повторяться в зависимости от `retry` настроек рабочего процесса.
`N`	Доктор	Worker находится в режиме слива и будет принимать только существующие закрепленные сеансы, предназначенные для себя, и игнорировать все остальные запросы.
`C`	HcFl	Рабочий процесс не прошел динамическую проверку работоспособности и не будет использоваться, пока не пройдет последующие проверки работоспособности.