Введение
HAProxy, что расшифровывается как High Availability Proxy, является популярным программным обеспечением с открытым исходным кодом для балансировки нагрузки TCP/HTTP и решения для прокси, которое может работать на Linux, macOS и FreeBSD. Его наиболее распространенное использование – улучшение производительности и надежности серверной среды путем распределения нагрузки между несколькими серверами (например, веб, приложение, база данных). Он используется во многих известных средах, включая: GitHub, Imgur, Instagram и Twitter.
В этом руководстве вы получите общий обзор того, что такое HAProxy, ознакомитесь с терминологией балансировки нагрузки и примерами того, как его можно использовать для улучшения производительности и надежности вашей собственной серверной среды.
Терминология HAProxy
Существует много терминов и концепций, которые важны при обсуждении балансировки нагрузки и прокси. Вы рассмотрите часто используемые термины в следующих подразделах.
Прежде чем перейти к основным типам балансировки нагрузки, вы должны начать с обзора ACL, бекэндов и фронтэндов.
Список контроля доступа (ACL)
В отношении балансировки нагрузки ACL используются для проверки определенного условия и выполнения действия (например, выбор сервера или блокировка запроса) на основе результата теста. Использование ACL позволяет гибко направлять сетевой трафик на основе различных факторов, таких как сопоставление шаблонов и количество соединений с бэкендом, например.
Пример ACL:
acl url_blog path_beg /blog
Этот ACL сопоставляется, если путь запроса пользователя начинается с /blog. Например, это совпадет с запросом http://yourdomain.com/blog/blog-entry-1.
Для подробного руководства по использованию ACL см. Руководство по настройке HAProxy.
Бэкенд
A backend is a set of servers that receives forwarded requests. Backends are defined in the backend section of the HAProxy configuration. In its most basic form, a backend can be defined by:
- какой алгоритм балансировки использовать
- a list of servers and ports
A backend can contain one or many servers in it. Generally speaking, adding more servers to your backend will increase your potential load capacity by spreading the load over multiple servers. Increased reliability is also achieved through this manner, in case some of your backend servers become unavailable.
Вот пример конфигурации с двумя бэкендами, web-backend и blog-backend, с двумя веб-серверами в каждом, слушающими порт 80:
backend web-backend
balance roundrobin
server web1 web1.yourdomain.com:80 check
server web2 web2.yourdomain.com:80 check
backend blog-backend
balance roundrobin
mode http
server blog1 blog1.yourdomain.com:80 check
server blog1 blog1.yourdomain.com:80 check
Строка balance roundrobin указывает алгоритм балансировки нагрузки, который подробно описан в разделе Алгоритмы балансировки нагрузки.
mode http указывает, что будет использоваться проксирование уровня 7, что объясняется в разделе Типы балансировки нагрузки.
Опция check в конце директив server указывает, что на этих серверах бэкенда должны выполняться проверки состояния.
Фронтенд
A frontend defines how requests should be forwarded to backends. Frontends are defined in the frontend section of the HAProxy configuration. Their definitions are composed of the following components:
- a set of IP addresses and a port (e.g. 10.1.1.7:80, *:443, etc.)
- ACL
- Правила
use_backend, которые определяют, какие бэкенды использовать в зависимости от совпадения условий ACL, и/или правилоdefault_backend, которое обрабатывает все остальные случаи
A frontend can be configured to various types of network traffic, as explained in the next section.
Типы балансировки нагрузки
Теперь, когда вы понимаете основные компоненты, используемые при балансировке нагрузки, вы можете перейти к основным типам балансировки нагрузки.
Без балансировки нагрузки
A simple web application environment with no load balancing might look like the following:
В этом примере пользователь подключается напрямую к вашему веб-серверу, по адресу yourdomain.com, и здесь нет балансировки нагрузки. Если ваш единственный веб-сервер выйдет из строя, пользователь больше не сможет получить доступ к вашему веб-серверу. Кроме того, если множество пользователей пытаются одновременно получить доступ к вашему серверу, и он не справляется с нагрузкой, они могут испытывать медленный опыт работы или вообще не смогут подключиться.
Балансировка нагрузки уровня 4
Самый простой способ балансировки нагрузки сетевого трафика на несколько серверов – использовать балансировку нагрузки уровня 4 (транспортного уровня). При балансировке нагрузки таким образом трафик пользователя будет перенаправляться на основе диапазона IP-адресов и порта (т.е. если запрос поступает на http://yourdomain.com/anything, трафик будет перенаправлен на бэкэнд, который обрабатывает все запросы для yourdomain.com на порту 80). Для получения более подробной информации об уровне 4 см. подраздел TCP нашего Введение в сетевые технологии.
Вот диаграмма простого примера балансировки нагрузки уровня 4:
Пользователь получает доступ к балансировщику нагрузки, который перенаправляет запрос пользователя к группе серверов веб-бэкенда. Любой выбранный сервер бэкенда напрямую отвечает на запрос пользователя. Как правило, все серверы в веб-бэкенде должны обслуживать идентичный контент, в противном случае пользователь может получить несогласованный контент. Обратите внимание, что оба веб-сервера подключены к одному и тому же серверу базы данных.
Балансировка нагрузки уровня 7
Еще один, более сложный способ балансировки сетевого трафика – использовать балансировку нагрузки уровня 7 (прикладной уровень). Используя уровень 7, балансировщик нагрузки может перенаправлять запросы к разным серверам бэкенда на основе содержания запроса пользователя. Этот способ балансировки нагрузки позволяет запускать несколько веб-приложений на одном домене и порту. Дополнительные сведения о уровне 7 можно найти в разделе HTTP нашего Введения в сетевые технологии.
Вот диаграмма простого примера балансировки нагрузки уровня 7:
В этом примере, если пользователь запрашивает yourdomain.com/blog, его перенаправляют на бэкенд блога, который представляет собой набор серверов, работающих под управлением приложения блога. Другие запросы перенаправляются на веб-бэкенд, который может выполнять другое приложение. Оба бэкенда используют один и тот же сервер базы данных, в данном примере.
A snippet of the example frontend configuration would look like this:
frontend http
bind *:80
mode http
acl url_blog path_beg /blog
use_backend blog-backend if url_blog
default_backend web-backend
Это настраивает фронтэнд с именем http, который обрабатывает весь входящий трафик на порту 80.
acl url_blog path_beg /blog соответствует запросу, если путь запроса пользователя начинается с /blog.
use_backend blog-backend if url_blog использует ACL для проксирования трафика на blog-backend.
default_backend web-backend указывает, что весь остальной трафик будет перенаправлен на web-backend.
Алгоритмы балансировки нагрузки
Алгоритм балансировки нагрузки, который используется, определяет, какой сервер из бэкэнда будет выбран при балансировке нагрузки. HAProxy предлагает несколько вариантов алгоритмов. Кроме того, серверам может быть назначен параметр веса, чтобы управлять частотой выбора сервера по сравнению с другими серверами.
A few of the commonly used algorithms are as follows:
roundrobin
Round Robin выбирает серверы по очереди. Это алгоритм по умолчанию.
leastconn
Выбирается сервер с наименьшим количеством подключений. Это рекомендуется для длительных сеансов. Серверы в одном и том же бекенде также перебираются по кругу.
источник
Это выбирает сервер на основе хэша IP-адреса источника, от которого пользователи отправляют запросы. Этот метод гарантирует, что одни и те же пользователи будут подключаться к одним и тем же серверам.
Клейкие сеансы
Некоторые приложения требуют, чтобы пользователь продолжал подключаться к тому же бекенд-серверу. Это можно достичь с помощью клейких сеансов, используя параметр appsession в бекенде, который его требует.
Проверка состояния
HAProxy использует проверку состояния, чтобы определить, доступен ли бекенд-сервер для обработки запросов. Это позволяет избежать ручного удаления сервера из бекенда, если он становится недоступным. Стандартная проверка состояния заключается в попытке установить TCP-соединение с сервером.
Если сервер не проходит проверку на состояние здоровья и, следовательно, не может обслуживать запросы, он автоматически отключается в бэкенде, и трафик к нему не будет перенаправлен до тех пор, пока он снова не станет здоровым. Если все серверы в бэкенде не проходят проверку, услуга станет недоступной до тех пор, пока хотя бы один из этих серверов в бэкенде снова не станет здоровым.
Для определенных типов бэкендов, таких как серверы баз данных, проверка состояния по умолчанию не обязательно определяет, является ли сервер по-прежнему здоровым.
Веб-сервер Nginx также может использоваться в качестве автономного прокси-сервера или балансировщика нагрузки и часто используется с HAProxy из-за его возможностей кэширования и сжатия.
Высокая доступность
Описанные в этом руководстве настройки балансировки нагрузки на уровнях 4 и 7 оба используют балансировщик нагрузки для направления трафика на один из множества серверов в бэкенде. Однако ваш балансировщик нагрузки является единой точкой отказа в этих настройках; если он выйдет из строя или будет перегружен запросами, это может вызвать высокую задержку или простой службы.
A high availability (HA) setup is broadly defined as infrastructure without a single point of failure. It prevents a single server failure from being a downtime event by adding redundancy to every layer of your architecture. A load balancer facilitates redundancy for the backend layer (web/app servers), but for a true high availability setup, you need to have redundant load balancers as well.
Вот диаграмма настройки высокой доступности:
В этом примере у вас есть несколько балансировщиков нагрузки (один активный и один или несколько пассивных) за статическим IP-адресом, который может быть переназначен с одного сервера на другой. Когда пользователь обращается к вашему веб-сайту, запрос проходит через внешний IP-адрес к активному балансировщику нагрузки. Если этот балансировщик нагрузки выходит из строя, ваш механизм аварийного переключения обнаружит это и автоматически переназначит IP-адрес одному из пассивных серверов. Существует несколько различных способов реализации активно-пассивной настройки HA. Чтобы узнать больше, читайте Как использовать зарезервированные IP-адреса.
Заключение
Теперь, когда у вас есть понимание балансировки нагрузки и вы знаете, как использовать HAProxy, у вас есть прочная основа для начала улучшения производительности и надежности вашей собственной серверной среды.
Если вас интересует сохранение вывода HAProxy для последующего просмотра, ознакомьтесь с Как настроить ведение журнала HAProxy с помощью Rsyslog на CentOS 8 [Быстрый старт]
Если вы хотите решить проблему, ознакомьтесь с Общими ошибками HAProxy. Если требуется дополнительная отладка, посмотрите Как отладить общие ошибки HAProxy.