Балансировщик HAProxy. Часть 2: секция Backend и алгоритмы балансировки

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

За алгоритм выбора сервера отвечает секция Backend конфигурационного файла. Всего у Haproxy 9 алгоритмов.

Roundrobin

Первый в списке и самый простой алгоритм — Round Robin. Включается записью balance roundrobin в секции backend. С этой опцией HAProxy будет перебирать сервера по очереди и равномерно покрывать нагрузкой вашу «ферму». Пример конфигурации:

backend
    balance roundrobin
        server srv1 luna-1:80
        server srv2 luna-2:80
* в моем случае luna-1 — это внутренний alias сервера, у вас скорее всего будет IP-адрес.

Если к серверам добавить параметр weight, то получится более продвинутая версия алгоритма — weighted roundrobin:

backend
    balance roundrobin
        server srv1 luna-1:80 weight 2
        server srv2 luna-2:80 weight 1

Благодаря разным значением весов, балансировщик будет распределять нагрузку исходя из физических возможностей серверов. И сервер с параметром weight 2 из примера выше будет получать в 2 раза больше запросов, чем с параметром weight 1.

Плюсы и минусы алгоритма

Artem Zaytsev

Evil marketer

+

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

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

Static-rr

Об этом алгоритме скажу кратко. По сути, Static-rr — это тот же Roundrobin. Одно исключение: изменение веса серверов на лету с его применением не даст никакого эффекта. Зато Statc-rr не ограничен по количеству бэкендов в отличие от Roundrobin, который может работать максимум с 4095 активными серверами. 

Включается с помощью записи «balance static-rr»  в секции бэкенда.

backend
    balance static-rr
        server srv1 luna-1:80
        server srv2 luna-2:80

Least Connections

Алгоритм с названием «Least connections» учитывает количество подключений на серверах. Таким образом, каждый следующий запрос передаётся серверу с наименьшим количеством активных подключений. Включить алгоритм можно с помощью опции «balance leastconn» в секции backend.

backend
    balance leastconn
        server srv1 luna-1:80
        server srv2 luna-2:80

Алгоритм «Least connections» в Haproxy динамический и способен назначать веса серверам «на лету».

Плюсы и минусы Least connections

+

Least connections подходит для задач, сопряженных с длительными соединениями. Например, для распределения нагрузки между серверами БД. Если на каких-то узлах будет слишком много активных подключений, новых запросов они уже не получат, и наоборот.

Нет никакого смысла применять алгоритм для задач с короткими сессиями, характерными, например, для http протокола. Там подойдет Round Robin.

First

Алгоритм First появился в HAProxy в версии 1.5. Если применить его , то балансировщик начнет заполнять свободные для соединений слоты начиная с первого сервера в списке бэкенда и по порядку.

Чтобы использовать алгоритм First, нужно прописать в секции Backend «balance first» и определить желаемое значение «maxconn» для серверов.

backend
    balance first
        server srv1 luna-1:80 maxconn 1000
        server srv2 luna-2:80 maxconn 2000

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

Плюсы и минусы алгоритма First

+

Главная цель алгоритма First — использовать наименьшее количество серверов. Это позволяет выключать дополнительные сервера в неинтенсивные часы работы.

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

Не сказать, что это минус ввиду специфики алгоритма, однако алгоритм First совершенно не учитывает веса серверов и распределяет нагрузку в зависимости от заданного вручную значения maxconn.

Source

При использовании этого алгоритма, IP-адрес источника хэшируется и делится на общий вес работающих серверов, чтобы определить, какой сервер будет получать запрос. Таким образом источник с одним и тем же IP всегда обращается к одному серверу. Включить эту опцию можно при помощи «balance source».

Плюсы и минусы алгоритма

+

Этот алгоритм обычно используют для работы по TCP протоколу, где невозможно присвоить cookie.

Если у источника динамический IP, алгоритм не сможет привязать его сессии к одному и тому же серверу.

URI

Алгоритм выбирает сервер исходя из адреса страницы. Благодаря ему один и тот же сервер будет обрабатывать определенные конечные адреса страниц. Включить алгоритм можно с помощью опции «balance uri«.

Плюсы и минусы алгоритма

+

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

Минус алгоритма заключается в его узкой специфике применения. На мой взгляд, история с кэширующими серверами — единственная, где решение находит применение.

URL parameter

Алгоритм URL parameter выбирает сервер на основе GET-параметров запроса. Если используется модификатор «check_post», то алгоритм будет принимать решение, в том числе в зависимости от аргумента параметра. Для наглядности приведу 2 примера использования алгоритма:

 balance url_param userid
 balance url_param session_id check_post 64

В первом случае алгоритм будет запросы пользователей направлять на одинаковые сервера, руководствуясь значением их userid. Во втором случае алгоритм назначит определенный сервер для обработки запросов с id сессии 64.

Если никаких параметров передано не будет, алгоритм будет распределять нагрузку по принципу Round robin.

Плюсы и минусы алгоритма

+

URL parameter может быть полезен, если вы хотите закрепить сервера за авторизованными пользователями, а для анонимных распределять нагрузку с помощью простого Round Robin.

Алгоритм будет работать только в http mode. Для TCP трафика он бесполезен.

HDR

Выбирается сервер на основе заголовка HTTP запроса. Если искомое значение отсутствует в заголовке, то используется принцип Round Robin.

balance hdr(User-Agent: Mozilla/5.0)

В данном случае HAProxy будет искать в заголовке запроса запись User-Agent: Mozilla/5.0.

Плюсы и минусы алгоритма

+

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

Опять же, алгоритм для очень специфических узких задач. Пригодится не многим.

rdp-cookie

Алгоритм эквивалентен ACL ‘req_rdp_cookie()’ секции Frontend. Его задача —  передавать одного и того же пользователя на один и тот же сервер с идентификацией по cookie.

Плюсы и минусы алгоритма

+

Алгоритм предназначен привязки к серверам сессии с определенными cookie.

Если cookie не используются клиентом, то алгоритм будет работать как простой Round robin.

В сухом остатке

В широкой практике обычно используются 2 алгоритма из списка: Round Robin и Leastconn. Первый для http трафика, второй — для обслуживания кластера баз данных. Остальные по ситуации.

Если у вас несколько кэширующих серверов, то пригодится URI. Если требуется привязать источники запросов к определенным серверам, помогут source и rdp-cookie. Если захотите распределить запросы по каким-то их свойствам, то пригодятся HDR и URL parameter.

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

Понравилась статья?