Найти в Дзене

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

Введение HAProxy (High Availability Proxy) — написанный на C популярный прокси-сервер для Linux, Solaris и FreeBSD с возможностью балансировки нагрузки TCP/HTTP. HAProxy используется в ряде высоконагруженных веб-сайтов, включая Twitter, GitHub, Imgur и Instagram. HAProxy является программой с открытым исходным кодом и распространяется в соответствии с GNU General Public License (GNU GPL v2). Во многих проектах рано или поздно встаёт вопрос масштабирования. И в этой статье мы расскажем как легко распределить нагрузку между серверами с помощью HAProxy. Так как в интернете достаточно сайтов, на которых подробно расписаны основные моменты и понятия HAProxy, мы перейдём сразу к настройке HAProxy. Подробнее с основными понятиями HAProxy можно ознакомиться здесь. С основной документацией по HAProxy можно ознакомиться здесь. В данной статье будут приведены примеры конфигураций HAProxy для распределения нагрузки между кластером http-серверов и Percona XtraDB Cluster. Начнём с установки HAProxy.
Оглавление

Введение

HAProxy (High Availability Proxy) — написанный на C популярный прокси-сервер для Linux, Solaris и FreeBSD с возможностью балансировки нагрузки TCP/HTTP. HAProxy используется в ряде высоконагруженных веб-сайтов, включая Twitter, GitHub, Imgur и Instagram.

HAProxy является программой с открытым исходным кодом и распространяется в соответствии с GNU General Public License (GNU GPL v2).

Во многих проектах рано или поздно встаёт вопрос масштабирования. И в этой статье мы расскажем как легко распределить нагрузку между серверами с помощью HAProxy.

Так как в интернете достаточно сайтов, на которых подробно расписаны основные моменты и понятия HAProxy, мы перейдём сразу к настройке HAProxy. Подробнее с основными понятиями HAProxy можно ознакомиться здесь.

С основной документацией по HAProxy можно ознакомиться здесь.

В данной статье будут приведены примеры конфигураций HAProxy для распределения нагрузки между кластером http-серверов и Percona XtraDB Cluster.

Начнём с установки HAProxy.

Часть 1. Установка HAProxy

В качестве операционной системы используется Ubuntu 16.04.

$ sudo apt-get update -y && sudo apt-get install haproxy -y

Настройка

Прежде чем настраивать HAProxy, сделаем бэкап основного конфига, поставляемого с установкой балансировщика.

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

Если вы не сталкивались раньше с этой формой записи, то данная команда преобразуется интерпретатором в следующее

$ sudo mv /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.backup

После установки необходимо включить HAProxy, чтобы балансировщик мог запускаться при помощи скрипта инициализации:

$ sudo sed -i "s/ENABLED=0/ENABLED=1/" /etc/default/haproxy

Создадим папку для HAProxy, которая пригодится для файла конфигурации. Для чего она нужна, будет рассказано ниже.

$ sudo mkdir /usr/share/haproxy

Часть 2. Настройка HAProxy для http-серверов

Предположим у вас есть 2 сервера, принимающих http-запросы. В нашем случае это:

  • 172.20.0.2:3000
  • 172.20.0.3:3000

Требуется распределить нагрузки между ними. Приступим к написанию файла конфигурации:

$ sudo vim /etc/haproxy/haproxy.cfg

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

-2

Здесь мы задали следующие параметры:

  • log — этот параметр задаёт логирование, и здесь мы указали, что логи будут посылаться на ip-адрес 127.0.0.1, т.е. на localhost. local1 — это имя. Где это использовать, будет показано ниже.
  • maxconn — максимальное количество одновременных соединений на один процесс.
  • chroot — настройки безопасности, "запирающие" HAProxy в указанной директории. Данная настройка повышает уровень безопасности в случае, если злоумышленник постарается использовать вашу систему.
  • user — пользователь, от имени которого будет запущена программа.
  • group — группа пользователя, от имени которого будет запущена программа.

Зададим настройки по умолчанию:

-3

Рассмотрим эти настройки подробнее:

  • log — указывает, в какой лог вести записи (global в данном случае означает, что используются параметры, заданные в секции global).
  • option httplog — формат лога, в случае использования HAProxy для проксирования HTTP-запросов, рекомендуется включать данную настройку
  • mode — устанавливает протокол взаимодействия, принимает одно из значений: tcp, http, health. В нашем случае http, потому что в данной статье настраивается балансировка для http-серверов.
  • retries — количество попыток соединения с сервером в случае отказа.
  • timeout connect — устанавливает максимальное время ожидания при попытке подключения к серверу.
  • timeout server — устанавливает максимальное время бездействия на стороне сервера.
  • timeout client — устанавливает время бездействия на стороне клиента для незавершенных ("полузакрытых") соединений.

Рекомендуется timeout server и timeout client задавать одинаково.

Теперь переходим к главной части. Укажем HAProxy, какие запросы он должен обрабатывать. Эти настройки задаются в части frontend.

-4

Здесь мы указали параметр bind со значением *:6000, что HAProxy будет принимать все запросы на порт 6000 (порт можно указать любой свободный). Frontend часть мы назвали haproxy.

Параметр default_backend указывает, какой набор серверов (backend) будет обрабатывать эти запросы. В данном примере мы указали, что это будет "back". Так мы и назвали следующую часть:

-5

Рассмотрим эти настройки подробнее:

  • balance roundrobin — указывает алгоритм балансировки (в нашем случае balance roundrobin). Подробнее об алгоритмах балансировки описано ниже.
  • option httpchk — активирует http протокол для проверки состояния серверов. При такой настройке HAProxy будет посылать обычный http-запрос на каждый сервер для проверки состояния. Если сервер вернет статус 200, значит сервер ещё способен принимать запросы, иначе сервер исключается из доступных для перенаправления запроса.
  • server — данная настройка добавляет сервер для перенаправления запросов.
  • check — указывает, что перед направлением запроса на этот сервер необходимо проверить, что сервер ещё доступен.
  • inter — задаёт интервал в миллисекундах, через сколько времени необходимо снова проверять сервер на работоспособность
  • rise — указывает, что сервер будет считаться работоспособным после определенного количества проверок.
  • fall — указывает, что сервер будет считаться не работоспособным после определенного количества проверок.
  • weight — задаёт вес (приоритет) сервера.

В конечном итоге файл конфигурации выглядит следующим образом:

-6

Перезапускаем HAProxy и всё готово:

$ sudo service haproxy restart

Часть 3. Настройка HAProxy для Percona XtraDB Cluster

Предполагается, что для Percona XtraDB Cluster у вас уже настроена Galera мастер-мастер репликация.

Предположим есть список серверов:

  • 10.0.1.2:3306
  • 10.0.1.3:3306
  • 10.0.1.4:3306

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

-7
-8

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

Первым главным отличием от настроек для http-серверов является настройка "mode tcp". MySQL не обрабатывает http-запросы, поэтому запросы перенаправляются по tcp.

Но тут может возникнуть вопрос: почему тогда стоит проверка состояния сервера по http? (option httpchk)

Сам MySQL http-запросы обрабатывать не будет. Но в состав пакетов Percona XtraDB Cluster входит утилита clustercheck, которая должна быть установлена на каждом сервере. После чего HAProxy будет способен проверять состояние сервера MySQL через HTTP.

Скрипт clustercheck — это обычный shell-скрипт, который принимает http-запросы и проверяет MySQL на входящие запросы. Если данный сервер кластера отвечает на запрос MySQL, скрипт возвращает ответ с HTTP кодом 200, иначе он вернёт статус 503.

Чтобы установить этот скрипт, необходимо создать clustercheck пользователя:

-9

Если вы хотите использовать другого пользователя или другой пароль, то в скрипте нужно внести эти изменения тоже. В Ubuntu 16.04 этот скрипт находится по пути "/usr/bin/clustercheck".

Теперь можно тестировать:

$ sudo clustercheck

В случае если у вас всё настроено правильно, вы увидите результат:

-10

Если вы хотите "демонизировать" скрипт clustercheck , можно использовать xinetd. Для его установки выполняем команду:

$ sudo apt-get update -y && sudo apt-get install xinetd -y

Новый сервис должен быть настроен в файле /etc/xinetd.d/mysqlchk:

-11

Также необходимо этот новый сервис добавить в файл "/etc/services":

# Local services
mysqlchk 9200/tcp

После чего перезапускаем xinetd:

$ sudo service xinetd restart

Осталось обратить внимание на последнюю деталь: port 9200. Напомним, что в конфигурации HAProxy для Percona XtraDB Cluster мы писали в backend части следующее:

backend pxc-back
...
option httpchk
...
server db1 10.0.1.2:3306 check port 9200 ...
server db2 10.0.1.3:3306 check port 9200 ...
server db3 10.0.1.4:3306 check port 9200 ...

В данном случае говорится, что проверка состояния сервера будет осуществляться путем запроса на порт 9200 каждого сервера. Как раз этот порт мы указывали в файле "/etc/xinetd.d/mysqlchk".

На этом настройка HAProxy для Percona XtraDB Cluster завершается. Не забудьте открыть порты на серверах кластера для HAProxy.

Напоследок хочется добавить, что не рекомендуется обращаться к MySQL через root пользователя. Следует создать другого пользователя, например:

-12

Перезапускаем HAProxy и всё готово:

$ sudo service haproxy restart

Часть 4. Логи и ещё раз логи

После настройки конфигурации настроим, чтобы все логи записывались в файл. Для этого установим rsyslog.

$ sudo apt-get update -y && sudo apt-get install rsyslog -y

Напомним, что в глобальных настройках мы задавали:

global
log 127.0.0.1 local1
...

Это означает, что все логи HAProxy будет посылать на localhost. Настроим теперь rsyslog, чтобы он принимал эти логи и записывал в файл:

$ sudo vim /etc/rsyslog.conf

Раскомментируем следующие строчки:

...
$ModLoad imudp
$UDPServerRun 514

# И добавим следующую строчку
$UDPServerAddress 127.0.0.1
...

Теперь создадим файл /etc/rsyslog.d/haproxy.conf:

$ sudo vim /etc/rsyslog.d/haproxy.conf

И напишем следующее:

local1.* /var/log/haproxy.log

Перезапускаем rsyslog и всё готово:

$ sudo service rsyslog restart

Теперь, чтобы посмотреть логи, можно открыть файл /var/log/haproxy.log либо в терминале выполнить команду:

$ sudo tail -f /var/log/haproxy.log

Таким образом, новые логи HAProxy автоматически будут появляться в терминале.

__________________________________________________________________________________________

На этом всё. Статью писал по опыту 2019 года. Что-то могло измениться. Поэтому буду рад, если укажите на дополнения)