Как сбалансировать нагрузку на серверы с помощью HAProxy

Дата публикации:

В этой статье мы попробуем разобраться в том,  что же такое HAProxy, а также рассмотреть его возможности и преимущества. Прежде всего, договоримся о понятиях. HAProxy — это серверное ПО, целью которого является обеспечение высокой доступности и балансировки нагрузки для TCP и HTTP-приложений, благодаря распределению входящих запросов на несколько обслуживающих серверов.

HAProxy активно используется в различных высоконагруженных веб-сайтах, таких как Instagram, Twitter, Reddit и т.д. К числу его основных функций можно отнести:

  • Балансировка HTTP и TCP соединений
  • Возможность перезапуска без потери активных соединений
  • Встроенный веб-интерфейс для просмотра статистики с HTTP basic аутентификацией
  • Возможность терминировать SSL (можно ставить перед веб-приложениями вместо nginx)

Балансировка HTTP и TCP соединений

HAProxy поддерживает балансировку, как  HTTP/HTTPS/HTTP2 (например, веб-серверы или Elasticsearch), так и TCP соединений (например, postgres или redis). Поддерживаются разные алгоритмы балансировки запросов. Из наиболее важных можно выделить:

roundrobin: запросы отправляются к бэкендам по очереди. Это крайне удобно для балансировки stateless протоколов, вроде HTTP. Однако если в приложениях есть данные, которые хранятся не в разделяемом хранилище, а на конкретном бэкенде (например, сессии или загруженные файлы), этот метод не подходит.

leastconn: запрос отправляется к бекенду с наименьшим количеством открытых соединений.

source: запросы с одного IP всегда отправляются на один и тот же бэкенд. Может быть полезным для таких сервисов, как memcached.

Существуют вариации и других алгоритмов, некоторые из них специфичны для HTTP. Они детально описаны в документации HAproxy.

Возможность перезапуска без потери активных соединений

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

Использование разных алгоритмов балансировки

Source-based балансировка

Часто, особенно для TCP бэкендов, возникает необходимость гарантировать что запросы от одного и того же клиента всегда пойдут на один и тот же бэкенд. Для этого применяется алгоритм балансировки «source». Таким образом можно распределить нагрузку между разными экземплярами memcached или redis (при условии, что все redis’ы независимы и не являются master/slave друг друга).

Допустим, нам необходимо обеспечить единую точку входа для memcached. Для клиентов это должно выглядеть, как один memcached сервер. При этом, если клиент сохранил данные в бэкенд X, то и запрос на чтение должен быть отправлен на бэкенд X.

Этого можно добиться следующим конфигом:

listen memcached *:11211

option tcplog

balance source # ip-based balancing

server memcached-1 host-1.example.com:11211 check inter 3s fall 3 minconn 50

server memcached-2 host-2.example.com:11211 check inter 3s fall 3 minconn 50

server memcached-3 host-3.example.com:11211 check inter 3s fall 3 minconn 50

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

Round-robin балансировка

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

listen *:9200

option tcplog

server elastic-1 host-1.example.com:9200 check inter 3s fall 3 minconn 50

server elastic-2 host-2.example.com:9200 check inter 3s fall 3 minconn 50

server elastic-3 host-3.example.com:9200 check inter 3s fall 3 minconn 50

Использование TCP-бекендов редисов в схеме master-slave

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

В качестве примера можно рассмотреть несколько экземпляров redis,  один из которых является мастером, а остальные — его репликами. Запросы от пользователя должны уходить только на мастер, поэтому необходимо, чтобы HAProxy понял, какой из бэкендов в любой момент времени является мастером.

По умолчанию для того чтобы понять — жив ли бэкенд, HAProxy использует простую проверку доступности порта. Помимо этого он поддерживает и сложные проверки. Они состоят из отсылки в указанный порт неких данных и проверки полученного ответа. Таким образом, HAProxy может общаться непосредственно с redis-демоном для получения его роли (master/slave). Вот один из примеров такой настройки.

Несмотря на то, что настройка является сравнительно простой и подходит для большинства случаев, она не обеспечивает 100% корректности определения мастера. Так как в случае с network split возможна ситуация, когда два разных redis’а будут считать себя мастером, что может ввести HAProxy в заблуждение. В таком случае, предпочтительно использовать redis sentinel в качестве источника. Дискуссию на эту тему и пример такого решения можно найти в комментариях к данной статье. Тем не менее, это значительно усложняет конфиг HAProxy.

В случае же, если вам нужно не просто слать все запросы в мастер, но и отправлять их на чтение на слейвы, лучше использовать специализированные решения (например, pgpool для postgres), а не HAProxy.

Особенности применения haproxy в docker-контейнере

Перезапуск без потери соединений

До версии 1.5.16 HAProxy запускался, как основной процесс в стандартном docker-контейнере (т.е. как PID 1). Это делало невозможным перезапуск без потери соединения. Так как при завершении PID 1 контейнер также завершался. Поэтому нам необходимо, чтобы таким процессом не был сам HAProxy. Начиная с haproxy: 1.5.16 в качестве PID 1 запускается haproxy-systemd-wrapper, который обеспечивает перезапуск HAProxy, но при этом остается живым. Дополнительный плюс — контейнер теперь нормально завершается, как по Ctrl+С, так и через docker stop.

Логирование

Ожидается, что приложения, запускаемые в docker-контейнерах, будут выводить все свои логи в stdout. В таком случае логи будут доступны через docker logs. HAProxy не поддерживает логирование в файл или stdout, только syslog. Существует способ получить логи, указав HAProxy. А дальше просто логировать в /dev/log. Для этого в конфиге haproxy указывается:

defaults

log /dev/log local0 debug

option dontlognull

option dontlog-normal

Внутрь контейнера монтируется /dev/log:

docker run haproxy -v /dev/log:/dev/log

При этом docker logs по-прежнему не будет работать. Но будет работать системный лог. В современных дистрибутивах до него можно добраться через journalctl.

Зачем использовать HAProxy?

Сегодня HAProxy не является единственным решением, предоставляющим проксирование и HTTP, и TCP. Например, c 2014 года nginx также поддерживает TCP-проксирование. Тем не менее, существуют причины, по которым, стоит отдать предпочтение именно HAProxy:

  1. Зрелость продукта. Первый релиз HAProxy состоялся в декабре 2001 года, с тех пор он активно развивается.
  2. Скорость работы. HAProxy написан на C и используется в высоконагруженных системах.
  3. Высокая настраиваемость. Документация очень обширна, настроить можно все.
  4. Надежность. HAProxy — пример такого продукта, который можно настроить и забыть, он просто будет работать.
  5. Широкий спектр применения. Reverse proxy, Load Balancing, Failover, поддержка HTTP и TCP, высокая настраиваемость — всё это позволяет использовать HAProxy во множестве сценариев.
  6. Встроенный веб-интерфейс со статистикой. Мелочь, но мелочь полезная.
  7. Мониторинг. Тот же веб-интерфейс может выводить данные не только как HTML-страницу, но и в CSV-формате, что позволяет интегрировать его с системами мониторинга.

Вывод

Наши поздравления! Вы ознакомились с основными понятиями HAProxy и балансировки нагрузки. В мире современной веб-разработки они очень и очень важны.

HAProxy — один из самых популярных открытых балансировщиков нагрузки TCP/HTTP с открытым программным кодом. И одновременно — прокси сервер для таких систем, как Linux, FreeBSD и Solaris. Чем же он вам пригодится? Прежде всего, вы сможете в значительной степени улучшить производительность и ошибкоустойчивость серверного окружения при помощи распределения рабочей нагрузки между несколькими серверами. Впечатляет, не правда ли? Итак, если вы еще не уверены в HAProxy, мы идем к вам!

Мы Крым Диджитал

С 2015 года мы предоставляем полный цикл услуг мобильной и веб-разработки клиентам из различных отраслей и разных стран.

Подпишись
на наши новости

Контакты пресс-службы

+ 7 (926) 118-80-32

WhatsApp, Viber, Telegram

Давайте обсудим Ваш проект

или свяжитесь с нами по почте projects@crimeadigital.ru

Нажимая кнопку «Отправить», вы даете согласие на обработку персональных данных

Заполните форму или свяжитесь
удобным для Вас способом

Контакты

г. Севастополь, ул. Руднева, д.41, 4 этаж технопарк ИТ-Крым +7 978 679-76-353 agro@crimeadigital.ru

Социальные сети

Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности

Крым Диджитал приняла участие в стратегической сессии

Руководители Крым Диджитал приняли участие в стратегической сессии, которая прошла на базе СевГУ 10 июня. Вместе с Правительством Севастополя, Институтом информационных технологий и управления в технических системах СевГУ и приглашенными ИТ-компаниями города обсудили перспективу развития системы высшего образования в Севастополе.Представители бизнеса, власти и образовательной системы выступали со своим видением будущих потребностей региона в кадрах, поднимали насущные вопросы обучения студентов, прохождения практики и дальнейшего трудоустройства. Крым Диджитал является амбассадором идеи образования и взращивания молодых кадров, развивает образовательные проекты и на протяжении 5 последних лет ведет активную работу в направлении поддержки и развития молодых специалистов ИТ-отрасли Крыма.

Руководители Крым Диджитал приняли участие в стратегической сессии, которая прошла на базе СевГУ 10 июня.

Вместе с Правительством Севастополя, Институтом информационных технологий и управления в технических системах СевГУ и приглашенными ИТ-компаниями города обсудили перспективу развития системы высшего образования в Севастополе.
Представители бизнеса, власти и образовательной системы выступали со своим видением будущих потребностей региона в кадрах, поднимали насущные вопросы обучения студентов, прохождения практики и дальнейшего трудоустройства.

Крым Диджитал является амбассадором идеи образования и взращивания молодых кадров, развивает образовательные проекты и на протяжении 5 последних лет ведет активную работу в направлении поддержки и развития молодых специалистов ИТ-отрасли Крыма.

Выпуск курса Software Testing

Мы поздравляем выпускников нашего первого в этом году курса Крым Диджитал Академии по Software Testing! Всего курс успешно завершили 13 человек. В течение 2 месяцев несмотря на теплую погоду и манящее море ребята ответственно посещали занятия 2 раза в неделю, делали домашние задания и проверочные работы. Трое начинающих специалистов теперь стажеры нашей компании. Следующий курс намечен на август. Не пропусти анонс записи!

Мы поздравляем выпускников нашего первого в этом году курса Крым Диджитал Академии по Software Testing!

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

Следующий курс намечен на август. Не пропусти анонс записи!

Лицензия на образовательную деятельность

В 2022 году мы получили лицензию на образовательную деятельность по программам дополнительного профессионального образования! Теперь мы можем обучать специалистов по направлениям Ruby on Rails, ReactJS и Software Testing и выдавать удостоверения о повышении квалификации государственного образца.
В 2022 году мы получили лицензию на образовательную деятельность по программам дополнительного профессионального образования! Теперь мы можем обучать специалистов по направлениям Ruby on Rails, ReactJS и Software Testing и выдавать удостоверения о повышении квалификации государственного образца.

Мы вошли в Реестр эффективно и социально значимых предприятий.

По результатам ежегодной финансово-экономической аналитики Межотраслевой рейтинговой компании Крым Диджитал включена в Реестр эффективных и социально значимых предприятий. По итогу аналитики, в рамках отрасли (ОКВЭД 62.01) и региона Крым, CDG вошло в 4% лучших компаний страны, с результатом – 92 балла!
По результатам ежегодной финансово-экономической аналитики Межотраслевой рейтинговой компании Крым Диджитал включена в Реестр эффективных и социально значимых предприятий. По итогу аналитики, в рамках отрасли (ОКВЭД 62.01) и региона Крым, CDG вошло в 4% лучших компаний страны, с результатом – 92 балла!