Haproxy loadbalancer, балансировка нагрузки на веб-сервер

В архитектурных системах, обслуживающих популярные веб-сайты, типовой задачей является балансировка нагрузки. Чаще всего для реализации задачи применяется front-end сервер Haproxy. Он может быть один или несколько — функция данного программного обеспечения заключается в переадресации запросов пользователя на один из back-end серверов. Для Haproxy настройка базовой конфигурации не представляет сложностей.

Используемые back-end сервера перечисляются в конфигурационном файле Haproxy, также задается стратегия согласно которой будут распределяться запросы. Основная функция системы — снижение нагрузки на веб-серверы, непосредственно обрабатывающие скрипты, также подобная реализация обеспечивает некоторую избыточность.

При выходе из строя одного из back-end серверов Haproxy автоматически определит, что он недоступен и не будет направлять на него запросы. Это означает возрастание нагрузки на доступные back-end сервера (часть пользователей на короткое время увидят ошибку на сайте), однако система останется работоспособна.

В качестве сервера обрабатывающего скрипты может применяться любое программное обеспечение — чаще всего это Apache или широко использующийся в нагруженных системах Nginx с PHP-FPM (Nginx используется и как фронтэнд).

Настройку веб-сервера в рамках статьи разбирать не будем и условно примем, что используем Nginx.

В примере Nginx используется исключительно для обработки пользовательских запросов.

Будем использовать три VDS, объединенных в локальную сеть. Этого можно не делать — разницы помимо белых IP адресов не будет.
Haproxy настройка
Настраиваем два сервера (их может быть любое количество) таким образом, чтобы они начали отдавать содержимое файла index.html.

На первой машине — Server 1:

mcedit /var/www/example.com/index.html

<html>

<p>Server 1</p>

</html>

На втором VDS аналогичным образом добавляем строку Server 2

Цель настройки — заставить систему отдавать содержимое index.html на рандомном сервере при обращении к IP адресу front-end сервера.

На третьем сервере устанавливаем программный пакет Haproxy.

apt-get update

apt-get install haproxy -y

Проверяем статус службы

service haproxy status

Вывод пуст — причина в том, что данное ПО предполагает его непосредственное включение в конфигурационном файле

mcedit /etc/default/haproxy

ENABLE=1

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

Переходим в главный конфигурационный файл

mcedit /etc/haproxy/haproxy.cfg

frontend haproxy_in    bind *:80
default_backend haproxy_http

После указания функции сервера — frontend задаем произвольное имя — например, haproxy_in, затем задаем дополнительные опции

backend haproxy_http
balance roundrobin
mode http
server be1 172.16.11.48:80 check
server be2 172.16.11.49:80 check

Перечисляем сервера с Nginx, которые будут обрабатывать контент — имена задаются произвольно, после локальных IP адресов указываем check — благодаря этой опции haproxy будет каждый раз проверять доступность сервера прежде чем направлять на него запросы пользователя.

Здесь используется принцип распределения запросов roundrobin, который является стандартным и часто применяется. Но используются и другие.

Даем команду на перечитывание конфигурационных файлов и запуск службы

service haproxy reload

В браузере проверяем результат — при обращении по IP каждый раз будет отдаваться строка Server 1 или Server 2.

Фронтэнд сервера тоже могут оказываться недоступны и их нужно дублировать и объединять в кластеры избегая образования единой точки отказа.