Балансировка нагрузки

Балансировка нагрузки#

На этой стадии происходит настройка балансировщика нагрузки для топологии уровня предприятия.

../../_images/day1-lb-blue.svg ../../_images/day1-deploy-white.svg ../../_images/day1-subscription-white.svg ../../_images/day1-test-white.svg ../../_images/day1-lb-blue.svg ../../_images/day1-deploy-dark.svg ../../_images/day1-subscription-dark.svg ../../_images/day1-test-dark.svg

Протестированным и наиболее распространенным вариантом обеспечения отказоустойчивости и равномерного распределения трафика между компонентами Astra Automation является балансировщик нагрузки HAProxy. HAProxy работает на уровне TCP с использованием режима SSL passthrough, при котором шифрованный HTTPS-трафик передается напрямую на целевые узлы без расшифровки на уровне балансировщика. Для Astra Automation такими узлами являются ВМ или физические серверы, выделенные под шлюз платформы.

Предварительные требования#

Начальные условия:

  • у вас есть выделенный сервер или ВМ с установленной ОС, например, Astra Linux Special Edition, для установки HAProxy;

  • подготовлено запланированное количество узлов для последующего развертывания на них шлюза платформы (Platform Gateway);

  • у шлюза платформы есть доменное имя, например aa.demo.example.com.

Если вы настраиваете балансировщик для использовании модели развертывания в нескольких кластерах Kubernetes, то в качестве узлов надо использовать ingress-интерфейсы кластеров Kubernetes с распределением нагрузки между ними.

Пример настройки#

Следующий пример демонстрирует настройку HAProxy для двух узлов будущего шлюза или интерфейсов кластеров Kubernetes.

Название узла

IP-адрес

Доменное имя

Компонент

gw1

192.168.56.11

aa.demo.example.com

Platform Gateway

gw2

192.168.56.12

aa.demo.example.com

Platform Gateway

Установка HAProxy#

Для установки HAProxy выполните следующие действия на узле балансировщика:

  1. Обновите список доступных пакетов:

    sudo apt update

  2. Установите пакет HAProxy:

    sudo apt install haproxy --yes

  3. Убедитесь, что служба запущена:

    sudo systemctl status haproxy

    В выводе ожидается наличие следующей примерной строки:

    Active: active (running) since Wed 2026-11-12 14:22:58 MSK; 1min 33s ago

Настройка HAProxy#

Файл настройки HAProxy по умолчанию находится в каталоге /etc/haproxy/, обычно это /etc/haproxy/haproxy.cfg.

При настройке HAProxy обратите внимание на следующие особенности:

  • HAProxy должен работать в режиме TCP, то есть для всех компонентов frontend и backend необходимо указать mode tcp, чтобы обеспечить передачу зашифрованного трафика без его расшифровки.

  • Для маршрутизации трафика HTTPS по доменному имени сервера (SNI) настройте соответствующие правила, которые направляют соединения с конкретным доменным именем (aa.demo.example.com) в соответствующую группу компонентов backend.

  • В настройках backend используйте стратегию балансировки balance source, которая обеспечивает постоянное распределение трафика от одного клиента на один и тот же сервер, основываясь на IP-адресе клиента. В документации HAProxy вы найдете также описание и других стратегий балансировки.

  • Для каждого сервера в backend настройте проверку доступности с помощью опции check, чтобы HAProxy мог автоматически исключать недоступные серверы из списка рабочих узлов.

  • Настройте административный интерфейс статистики HAProxy, доступный через порт 9000 по адресу /stats, с включенной базовой аутентификацией для мониторинга состояния компонентов backend и их нагрузки. Интерфейс мониторинга в этом случае доступен по адресу http://<haproxy-ip>:9000/stats. Вход осуществляется с помощью учетной записи и пароля, заданных в настройке, например, admin:password.

Ниже приведен пример настройки HAProxy для маршрутизации трафика HTTPS по SNI и балансировки нагрузки между несколькими backend компонентами. Каждая секция файла настройки (загрузить файл) описана отдельно.

Global#

В секции global задаются глобальные параметры HAProxy.

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon
    stats socket /var/lib/haproxy/stats level admin
    tune.ssl.default-dh-param 2048
    maxconn 4096

Как правило, они задаются один раз и не требуют изменения после настройки. Некоторые из них имеют эквиваленты в командной строке. Полный список параметров доступен в документации HAProxy.

Для настройки HAProxy в Astra Automation используйте следующие параметры:

  • log – настройка централизованного сбора сообщений от HAProxy через сервер системного журнала. В примере использованы следующие настройки:

    • Первая строка задает отправку записей журнала в системный сокет /dev/log с категорией local0 без ограничения по уровню важности.

    • Вторая строка также задает отправку через сокет /dev/log, но с категорией local1 и ограничением на уровень важности сообщений – будут фиксироваться только события с уровнем важности notice и выше.

  • chroot – задание виртуального корневого каталога файловой системы для процессов HAProxy. Это повышает безопасность, ограничивая доступ HAProxy в файловой системе заданным каталогом.

  • user – учетная запись, привилегии которой будут использовать процессы HAProxy.

  • group – группа, в которую входит учетная запись для процессов HAProxy.

  • daemon – запуск HAProxy в фоновом режиме.

  • stats socket – Unix-сокет для доступа к статистике HAProxy.

  • tune.ssl.default-dh-param – размер параметра Диффи-Хеллмана для соединений SSL.

  • maxconn – максимальное количество одновременных соединений, которые HAProxy может обслуживать.

Defaults#

Секция defaults определяет параметры, которые будут наследоваться всеми другими секциями, если они не переопределены.

defaults
    log global
    mode tcp
    option tcplog
    timeout connect 5s
    timeout client 50s
    timeout server 50s
    retries 3

Для настройки HAProxy в Astra Automation используйте следующие параметры:

  • log – настройка централизованного сбора сообщений, в которой можно указать log global для использования параметров из секции global;

  • mode – режим работы;

  • option tcplog – включение расширенного ведения журнала соединений TCP;

  • timeout connect – максимально допустимое время ожидания успешной попытки подключения к серверу;

  • timeout client – максимально допустимое время ожидания активности от клиента;

  • timeout server – максимально допустимое время ожидания активности от сервера;

  • retries – максимально допустимое количество попыток переподключения к серверу при сбоях.

Frontend https-in#

Frontend https-in принимает трафик на порту 443 и маршрутизирует его по SNI. Для разных доменных имен создаются правила, которые перенаправляют запросы соответствующим backend компонентам. В этом примере используется одно доменное имя.

# --- HTTPS passthrough frontend ---
frontend https-in
    bind *:443
    mode tcp

    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }

    acl is_gateway req.ssl_sni -i aa.demo.example.com
    use_backend gateway_backend if is_gateway

Для настройки HAProxy в Astra Automation используйте следующие параметры:

  • bind – IP-адрес и порт для входящих соединений.

  • mode – режим работы frontend.

  • tcp-request – опции обработки запросов на уровне TCP:

    • inspect-delay – время ожидания анализа первых пакетов;

    • content accept if { req_ssl_hello_type 1 } – условие, при котором соединение принимается, например при обнаружении TLS ClientHello.

  • acl – правила фильтрации трафика, например, по SNI.

  • use_backend – компонент backend в который необходимо перенаправить трафик при выполнении условия.

Backend gateway_backend#

Секция backend gateway_backend обеспечивает направление трафика если клиент обратился к домену aa.demo.example.com.

# --- Gateway backend ---
backend gateway_backend
    mode tcp
    balance source
    server ctrl1 192.168.56.11:443 check
    server ctrl2 192.168.56.12:443 check

Для настройки HAProxy в Astra Automation используйте следующие параметры:

  • mode – режим работы серверов Automation Controller;

  • balance – алгоритм балансировки нагрузки;

  • server – сервер Automation Controller с IP-адресом, портом и проверкой доступности.

Listen stats#

Секция listen stats включает встроенный веб-интерфейс статистики HAProxy, доступный, например, по адресу http://<ip>:9000/stats.

listen stats
    bind *:9000
    mode http
    stats enable
    stats uri /stats
    stats refresh 10s
    stats auth admin:password
    stats realm Haproxy\ Statistics

Для настройки HAProxy в Astra Automation используйте следующие параметры:

  • bind – IP-адрес и порт веб-интерфейса статистики.

  • mode – режим работы веб-интерфейса.

  • stats – настройки веб-интерфейса статистики:

    • enable – включение отображения статистики;

    • uri – URI страницы статистики;

    • refresh – интервал обновления данных;

    • auth – логин и пароль для аутентификации;

    • realm – текстовое сообщение в диалоге аутентификации.

Добавление технического заголовка для идентификации узла#

Для упрощения диагностики балансировки через HAProxy можно добавить дополнительный HTTP-заголовок X-Served-By. Для этого на всех узлах шлюза выполните следующие действия:

  1. В каталоге /etc/nginx/conf.d/ создайте конфигурационный файл NGINX со следующим содержимым:

    server {
      listen 443 ssl;
      server_name <hostname>;

      ssl_certificate     </path/to/cert.pem>;
      ssl_certificate_key </path/to/key.key>;

      location / {
               add_header X-Served-By "<host>";
      }
}

    Здесь:

    • <hostname> – доменное имя сервера (SNI), например, aa.demo.example.com;

    • <host> – название узла, например, gw1.

  2. Обновите настройки сервиса nginx:

    sudo systemctl reload nginx

  3. Проверьте заголовок ответа:

    curl -I https://aa.demo.example.com

    Ожидаемый результат выполнения команды:

    X-Served-By: gw1

Обеспечение отказоустойчивости балансировщика#

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

  • Использование VRRP и keepalived.

    При использовании физических серверов в одном сегменте сети доступен уровень L2 сети, что позволяет использовать сетевое оборудование с классическим механизмом VRRP для организации виртуального IP-адреса. В этом случае несколько узлов с установленным HAProxy объединяются в кластер, где один из узлов активен, а остальные работают в режиме ожидания. При отказе активного узла виртуальный IP-адрес автоматически переносится на резервный узел. Пример настройки VRRP с использованием Keepalived для физических серверов приведен в документации Yandex Cloud.

  • Использование внешнего балансировщика уровня TCP.

    В инфраструктуре, где нет поддержки VRRP (например, в облачных средах без доступа к протоколам L2), рекомендуется использовать внешний сетевой балансировщик, который обеспечивает распределение соединений TCP между несколькими узлами с HAProxy и поддерживает проверку их доступности. В качестве примера можно использовать Yandex Network Load Balancer, который работает на уровне TCP и автоматически исключает недоступные узлы из схемы балансировки.

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