HAProxy и концепции балансировки нагрузки: основы

Введение

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

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

Основные термины HAProxy

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

ACL (список контроля доступа)

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

В этом случае ACL срабатывает, если запрашиваемый пользователем путь начинается с /blog. Например, этот запрос будет указывать на http://yourdomain.com/blog/blog-entry-1. HAProxy Configuration Manual содержит подробное руководство по использованию ACL.

Бэкенд (Backend)

Перенаправленные запросы принимаются набором серверов, называемым бэкендом. Запросы определяются в разделе backend конфигурации HAProxy. Простыми словами, бэкенд может быть определен используемыми алгоритмами балансировки нагрузки и списком портов и серверов. Бэкенд может состоять из одного или нескольких серверов. По мере добавления серверов в бэкенд потенциальная пропускная способность увеличивается, а обработка распределяется между несколькими серверами. Если некоторые из серверов бэкенда отключаются, остальные будут служить в качестве резервных для обработки запросов.

Давайте’с рассмотрим пример конфигурации двух бэкендов. В данном случае это blog-backend и web-backend. Каждый из них имеет два веб-сервера, работающих на порту 80:

Строка balance roundrobin предназначена для указания алгоритма балансировки нагрузки. Подробности можно найти в следующем разделе Algorithms for Load Balancing, а mode http настраивает использование проксирования на уровне 7. Мы объясним это в разделе Load Balancing Types. Кроме того, опция check после директивы серверов указывает на то, что на этих конкретных серверах бэкенда будут выполняться проверки работоспособности.

Фронтенд (Frontend)

Определение того, как запросы перенаправляются на бэкенд, называется фронтендом. Запросы определяются в разделе frontend конфигурации HAProxy. Они состоят из ACL, порта, набора IP-адресов и правила, определяющего, какие бэкенды использовать в зависимости от того, какие условия ACL были выполнены, называемого правилом use_backend. Кроме того, существует правило default_backend для обработки любых других случаев. В следующем разделе будет объяснено, как можно настроить фронтенд для различных типов сетевого трафика.

Load Balancing Types

Определив базовые компоненты, используемые для балансировки нагрузки, мы можем перейти к основным типам балансировки нагрузки.

Отсутствие балансировки нагрузки

В самом элементарном виде отсутствие балансировки нагрузки можно проиллюстрировать следующим образом:

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

Балансировка нагрузки (уровень 4)

Один из самых простых и прагматичных способов балансировки сетевого трафика между несколькими серверами — использование методов балансировки транспортного уровня или уровня 4. Этот способ балансировки нагрузки направляет любого подключающегося пользователя на основе диапазона IP-адресов, в который попадает его IP-адрес, и порта. Другими словами, если http://yourdomain.com/anything — это то, откуда поступает запрос, бэкенд, определенный для обработки этих запросов, в конечном итоге и будет их обрабатывать. Он будет перенаправлять эти запросы для yourdomain.com на порт 80.

Базовая схема балансировки нагрузки уровня 4 выглядит следующим образом:

Когда пользователь получает доступ к балансировщику нагрузки, его запросы перенаправляются в группу серверов web-backend. Настроенный бэкенд-сервер напрямую ответит на запрос пользователя. Чтобы пользователь не столкнулся с несогласованными данными, все серверы web-backend должны отдавать идентичный контент. Как показано на диаграмме выше, оба веб-сервера в конечном итоге подключаются к одному и тому же серверу базы данных.

Балансировка нагрузки (уровень 7)

Существует другой, более сложный метод балансировки сетевого трафика. Это использование балансировки нагрузки уровня 7, или прикладного уровня. Этот подход позволяет перенаправлять запросы пользователей на различные бэкенд-серверы в зависимости от содержимого запросов. Этот метод позволяет осуществлять балансировку нагрузки между несколькими серверами веб-приложений через один и тот же порт и домен. Для получения более подробной информации об этом уровне ознакомьтесь с подразделом HTTP нашего руководства «The Nitty Gritty of Networking: Learn about Terminology, Interfaces, and Protocols».

Следующая диаграмма иллюстрирует балансировку нагрузки уровня 7:

В этом случае пользователь запрашивает yourdomain.com/blog, и его запрос перенаправляется на бэкенд блога (blog backend). Это набор бэкенд-серверов, выделенный специально для работы приложения блога. Тем временем остальные запросы будут перенаправляться на web-backend. Тем не менее, оба бэкенда в итоге обращаются к одному и тому же серверу базы данных.

Пример небольшого фрагмента конфигурации фронтенда для балансировки нагрузки уровня 7 выглядит примерно так, как показано в следующих командах. Они настраивают фронтенд http для обработки входящего трафика через порт 80:

Если путь запроса пользователя начинается с /blog, то acl url_blog path_beg /blog будет соответствовать запросу.

use_backend blog backend if url_blog проксирует трафик на blog-backend с помощью ACL.

defaut_backen web_backend направляет всю остальную пересылку трафика на web-backend.

Алгоритмы балансировки нагрузки

При выполнении балансировки нагрузки именно алгоритм балансировки определяет, какой сервер бэкенда будет выбран для этой цели. HAProxy предлагает несколько вариантов алгоритмов. Кроме того, серверам можно назначить параметр веса (weight), чтобы управлять тем, насколько часто выбирается один сервер по сравнению с другими. Доступных алгоритмов слишком много, чтобы описывать их все. Поэтому в данном руководстве мы сосредоточимся только на наиболее распространенных. Вы можете обратиться к HAProxy Documentation Converter , чтобы увидеть полный список. К наиболее часто используемым относятся:

• roundrobin: алгоритм по умолчанию, который выбирает серверы по очереди.
• leastconn: автоматически выбирается сервер с наименьшим количеством подключений. Однако серверы внутри одного бэкенда должны чередоваться по принципу round-robin.
• source: алгоритм выбирает сервер на основе IP-адреса, с которого поступает запрос пользователя. Этот метод гарантирует, что пользователь всегда будет подключаться к одному и тому же серверу.

Sticky Sessions

Для некоторых приложений требуется, чтобы подключающиеся пользователи всегда связывались с одним и тем же сервером. С помощью «липких сессий» и использования параметра appsession в требующем этого бэкенде можно обеспечить такое постоянство.

Processing Health Checks

HAProxy необходим метод, с помощью которого он может определять способность сервера бэкенда обрабатывать запросы. Это позволяет исключить сервер из бэкенда, если он уходит в офлайн. По умолчанию запускается «проверка работоспособности» (health check), которая пытается установить TCP-соединение. Она делает это путем прослушивания настроенного IP-адреса и порта.

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

Alternate Solutions

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

• Nginx: это надежный и быстрый веб-сервер, который можно использовать для балансировки нагрузки и проксирования. На самом деле Nginx часто используется в тандеме с HAProxy, который задействует его возможности сжатия и кэширования.
• Linux Virtual Servers (LVS): это простой балансировщик нагрузки уровня 4 (layer 4), который входит в состав многих систем Linux.

High Availability

До сих пор мы говорили о балансировке нагрузки уровней 4 и 7. В обоих случаях используется балансировщик нагрузки для определения того, какому из множества серверов бэкенда будет поручено ответить на запрос пользователя. Но важно помнить об ограничениях балансировщика нагрузки. А именно о том, что он является единой точкой отказа. Это означает, что если он выйдет из строя или будет перегружен запросами пользователей, это приведет к простою или задержке обработки запросов соответственно. Однако конфигурация HA (высокой доступности) представляет собой инфраструктуру, лишенную какой-либо единой точки отказа. Это предотвращает простои из-за сбоя сервера за счет внедрения избыточности на каждом уровне архитектуры системы. Хотя балансировщик нагрузки помогает обеспечить избыточность бэкенда, сами балансировщики нагрузки также должны обладать избыточностью.

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

Эта инфраструктура имеет несколько балансировщиков нагрузки (один активный, остальные пассивные), привязанных к статическому IP-адресу. Этот IP-адрес может быть переназначен на другой сервер, если того потребует ситуация. Запрос пользователя проходит через внешний IP-адрес к активному в данный момент балансировщику нагрузки. Если балансировщик нагрузки в это время находится в автономном режиме, отказоустойчивый механизм обнаружит его состояние и переназначит IP-адрес пассивному серверу (серверам).

Conclusion

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

Приятной работы!