Балансировка нагрузки сайта с помощью HAProxy

Если ваш провайдер предоставляет возможность для лёгкого вертикального масштабирования (вы можете менее чем за минуту значительно увеличить производительность своего сервера), однако иногда требуется масштабирование горизонтальное - когда обработка запросов/задач распределяется между несколькими серверами, это повышает отказоустойчивость (выход из строя одного из серверов пула останется незамеченным пользователями, в то время как в случае вертикально-масштабированного сервиса потери могут весьма высокими) и даёт значительную гибкость в настройке и управлении. Рассмотрим балансировку на примере специализированного решения - HAProxy. HAProxy используется такими гигантами как Twitter, Instagram, Github, StackOverflow, Reddit и многими другими. Программа может быть установлена на множество различных систем, мы же будем использовать Ubuntu 16.04.

Технические требования

один сервер под балансировщик
3 сервера под обработчики запросов
на каждом из серверов пользователь с sudo-правами

Шаг 1. Подготовка бэкендов

Если вы масштабируете существующий проект, то скорее всего у вас уже есть как минимум один сервер, обрабатывающий пользовательские запросы, тогда вам необходимо воссоздать его рабочее окружение (набор и конфигурация ПО) на одном или нескольких новых серверах.
Мы же создадим 3 новых сервера, благо vscale позволяет сделать это в несколько кликов мышкой. HAProxy проксирует пользовательские запросы, распределяя их между серверами по некоторому алгоритму, поэтому нам на каждой машине нужен веб-сервер. Следовательно, на каждом сервере обновим индекс пакетного менеджера и поставим nginx:

sudo apt-get update
sudo apt-get install nginx -y

А также изменим приветственную страницу, чтобы можно было определить, какой из серверов сгенерировал ответ:

nano /var/www/html/index.nginx-debian.html

Оставим такое содержимое (поставив везде уникальную строку в тег h1):

<!DOCTYPE html>
<html>
<head>
<title>HAProxy test!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to Backend #1!</h1>
</body>
</html>

На этом подготовку бэкендов можно считать завершённой, переходим к самому интересному.

Шаг 2. Установка балансировщика

При выборе сервера для балансировщика стоит исходить из того, что 1Гб ОЗУ хватает для обслуживания примерно 20-30 тысяч одновременных сессий, другими словами, пока ваш сервис не вырос до размеров фейсбука или твиттера, для работы балансировщика будет достаточно почти любого сервера.

HAProxy входит в официальный репозиторий Ubuntu. Обновляем индекс менеджера пакетов и устанавливаем HAProxy:

sudo apt-get update
sudo apt-get install haproxy

Шаг 4. Настройка балансировщика

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

mv /etc/haproxy/haproxy.cfg{,.backup}

Пояснение для тех, кто не сталкивался с сокращённым видом записи: содержимое фигурных скобок говорит интерпретатору командной строки, что команду нужно развернуть до вида "mv /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.backup"

Начнём редактирование конфига:

nano /etc/haproxy/haproxy.cfg

Итак, перед нами чистый лист. Что нам нужно? HAProxy имеет очень гибкие настройки и конфиругация может содержать большое количество директив и условий, однако мы начнём с простого. Конфигурационный файл состоит из нескольких секций. Некоторые секции (frontend, backend, listen) должны иметь своё имя, некоторые (например, defaults) - могут, но не обязаны, некоторые (global) - не должны.

Добавим глобальные настройки:

global
        log /dev/log    local0
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s
        maxconn 2048
        user haproxy
        group haproxy
        daemon

Здесь мы дали HAProxy следующие указания:

log - вести лог в /dev/log сохраняя в "объект" local0
chroot - настройки безопасности, "запирающие" HAProxy в указанной директории
stats socket - настройки сокета, по которому будет передаваться статистика
maxconn - максимальное количество конкурирующих соединений на один процесс
user - пользователь, от имени которого будет запущена программа
group - группа пользователя, от имени которого будет запущена программа
daemon - запуск процесса как демона

Выставим значения по умолчанию:

defaults
        log global
        mode http
        retries 3
        option httplog
        option redispatch
        maxconn 2000
        contimeout 2000

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

log - указывает, в какой лог вести записи (global в данном случае означает, что используются параметры, заданные в секции global)
mode - устанавливает протокол взаимодействия, принимает одно из значений: tcp, http, health
retries - количество попыток соединения с сервером в случае отказа
option httplog - формат лога, в случае использования HAProxy для проксирования HTTP-запросов, рекомендуется включать данную настройку
option redispatch - разрешает программе разорвать и переназначить сессию в случае отказа сервера
contimeout - максимальное время ожидания успешного соединения с сервером

Теперь укажем HAProxy, какие запросы он должен слушать, для этого нужна секция frontend, которую в нашем примере мы назовём "front":

frontend front
        bind *:80
        default_backend backend_servers

Параметр bind со значением *:80 говорит о том, что HAProxy должен принимать все запросы на 80-й порт. Параметр default_backend указывает, какие сервера будут обрабатывать эти запросы. В данном случае - backend_servers, так мы назвали следующую секцию:

backend backend_servers
        balance roundrobin
        server backend1 78.155.206.25 weight 1
        server backend2 78.155.206.26 weight 2
        server backend3 78.155.206.27 weight 8

В этой секции мы задали алгоритм балансировки (параметр balance) и список серверов-обработчиков (server). В качестве алгоритма балансировки мы указали простейший roundrobin, более подробно различные аглоритмы мы рассмотрим позднее.
При перечислении серверов используется следующий формат: ключевое слово server, название сервера, IP-адрес, дополнительные параметры (в данном случае - задание весов).

Теперь всё готово к тестированию, однако, вероятно, вы захотите следить за состоянием своей "фермы" и её статистикой, для этого добавим ещё одну секцию в файл конфигурации:

listen stats
        bind :10001
        stats enable
        stats uri /haproxy_stats
        stats auth admin:password

bind :10001 означает, что HAProxy будет ожидать запросы к порту 10001
stats enable - включить отчёты со статистикой
stats uri - установка адреса страницы с отчётом
stats auth - логин и пароль для авторизации на странице со статистикой (может быть задано несколько)

Таким образом, в данной секции мы указали HAProxy, что он должен показывать статистику на странице "/haproxy_stats" на порту 10001, если пользователь введёт логин "admin" и пароль "password".

Шаг 3. Тестирование

Переходим в браузере по адресу балансировщика, в моём примере это 95.213.203.49. На экране я вижу строку "Welcome to Backend #1!" - эту строку отдаёт первый бэкенд. Обновив страницу, получаю "Welcome to Backend #2!" - ответ от другого бэкенда. Продолжая нажимать F5 я получаю последовательно адреса всех бэкендов. Здесь стоит упомянуть про веса серверов, которые мы задали в секции backend: вес выражается числом от 0 до 256, и запросы распределяются между серверами пропорционально их весу, что применяется в основном для распределения запросов между серверами с разной мощностью/производительностью. Мы видим, что ответы от сервера, которому задали больший вес, приходят чаще, чем от двух других.
Посмотрим статистику. Для этого нам нужно подключиться, используя параметры, заданные в секции stats: ввожу в адресной строке браузера 95.213.203.49:10001/haproxy_stats, указываю логин и пароль, получаю:

Шаг 4. Выбор алгоритма балансировки

HAProxy предлагает несколько алгоритмов балансировки, и в зависимости от вашей задачи можно выбрать наиболее подходящий:

roundrobin - каждый сервер получает запросы пропорционально своему весу, при этом веса серверов могут меняться на лету
static-rr - то же, что и roundrobin, только изменение весов на лету не даст никакого эффекта
leastconn - выбирает сервер с наименьшим количеством активных соединений
first - выбирает первый сервер с доступными слотами для соединения
source - на основе хэша IP-адреса отправителя запроса и весов серверов назначается сервер для соединения
uri - сервер выбирается на основе адреса (без параметров) страницы
url_param - сервер выбирается на основе GET-параметров запроса
hdr - сервер выбирается на основе заголовков запроса
rdp-cookie - сервер выбирается на основе cookie (если они не установлены, то применяется обычный round robin)

Как установить HAProxy на CentOS 8

Было ли это полезно?

От qwert

8 февраля, 2021

Войти

Балансировка нагрузки сайта с помощью HAProxy

Обратная связь

Рекомендуемые комментарии

Создайте учетную запись или войдите, чтобы комментировать

Создать аккаунт

Войти

Сообщество

Файлы

Новости

Документация