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

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

Протестированным и наиболее распространенным вариантом обеспечения отказоустойчивости и равномерного распределения трафика между компонентами Astra Automation является балансировщик нагрузки HAProxy. Для шлюза платформы (Platform Gateway) поддерживается балансировка на прикладном уровне (L7): балансировщик завершает клиентский сеанс TLS, обрабатывает запрос HTTP/1.1, добавляет служебные заголовки и устанавливает новое соединение HTTPS до узлов шлюза платформы. Такими узлами являются ВМ или физические серверы, выделенные под шлюз платформы.

Схема прохождения трафика:

Клиент -- HTTPS, HTTP/1.1 --> Балансировщик нагрузки -- HTTPS, HTTP/1.1 --> Узлы шлюза платформы

Балансировка на уровне L7 применяется потому, что балансировщик должен работать с запросом на уровне HTTP, а именно:

• завершать сеанс TLS на стороне клиента и повторно шифровать трафик до узлов шлюза платформы;

• добавлять заголовки X-Forwarded-For и X-Forwarded-Proto;

• выполнять проверку доступности (health check) по адресу /api/gateway/v1/ping/;

• сохранять заголовки установления соединения WebSocket;

• ограничивать протокол версией HTTP/1.1.

Важно

Балансировка на уровне TCP (L4) в режиме SSL passthrough, при котором зашифрованный трафик передается на узлы шлюза платформы без расшифровки, для шлюза платформы не поддерживается. В этом режиме балансировщик передает поток TCP и не может выполнять перечисленные действия на уровне HTTP, поэтому часть функций платформы становится недоступна или работает некорректно.

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

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

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

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

• балансировщику выделен виртуальный IP-адрес (VIP), на который в DNS назначено доменное имя шлюза платформы, например aa.demo.example.com;

• клиенты, установочный узел и узлы платформы разрешают это доменное имя в адрес VIP;

• подготовлены сертификаты TLS для балансировщика и узлов шлюза платформы.

Приведенный далее пример настройки рассчитан на HAProxy версии 2.2 и новее: директива http-check send с параметрами meth, uri и ver появилась в этой версии, а в более ранних версиях разбор файла настройки завершается ошибкой. Версию установленного пакета необходимо проверить до применения примера.

Доменное имя, назначенное на VIP балансировщика, необходимо указать в переменной automationgateway_main_url описания инвентаря. При использовании внешнего балансировщика указание этой переменной обязательно.

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

Требования к сертификатам

Балансировщик участвует в двух независимых соединениях TLS, поэтому сертификаты требуются с обеих сторон:

• Соединение «клиент – балансировщик».

  На балансировщике необходимо установить сертификат для доменного имени, указанного в automationgateway_main_url. Поле CN или SAN этого сертификата должно содержать доменное имя шлюза платформы, например aa.demo.example.com. Клиенты, установочный узел и узлы платформы должны доверять цепочке этого сертификата. Файл сертификата содержит закрытый ключ, поэтому доступ к нему необходимо ограничить: владелец root, режим доступа 0600. HAProxy читает этот файл при запуске, до понижения привилегий, поэтому учетной записи haproxy доступ к нему не требуется.

• Соединение «балансировщик – узлы шлюза платформы».

  На узлах шлюза платформы также необходимы сертификаты TLS, потому что балансировщик устанавливает до них новое соединение HTTPS. Рекомендуется использовать сертификаты, которым доверяет балансировщик, и включать проверку сертификата узла параметром verify required. При использовании самозаверенных сертификатов сертификат удостоверяющего центра необходимо импортировать в доверенное хранилище балансировщика и указать его в параметре ca-file. Проверку необходимо включить и для рабочего трафика, и для соединений проверки доступности – это обеспечивают параметры sni, check-sni и verifyhost, описанные в настройке backend.

Порядок применения сертификатов TLS на узлах платформы описан в инструкции по применению сертификатов TLS.

Предупреждение

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

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

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

Параметр	Значение
VIP-адрес балансировщика	192.168.56.10
Доменное имя шлюза платформы, назначенное на VIP	aa.demo.example.com
Узел шлюза платформы gw1	192.168.56.11
Узел шлюза платформы gw2	192.168.56.12
Внешний порт балансировщика	443
Порт узлов шлюза платформы	443
Переменная описания инвентаря	automationgateway_main_url='https://aa.demo.example.com'

Установка HAProxy

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

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

   sudo apt update
   

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

   sudo apt install haproxy --yes
   

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

   sudo systemctl status haproxy
   

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

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

4. Проверьте версию установленного пакета:

   haproxy -v
   

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

   Если в репозитории доступна только более ранняя версия, в приведенном далее примере необходимо заменить директиву http-check send: в версиях до 2.2 она принимает только hdr и body, поэтому файл настройки не разберется. Равнозначная запись для более ранних версий:

   option httpchk GET /api/gateway/v1/ping/ HTTP/1.1\r\nHost:\ aa.demo.example.com
   

   Рекомендуется использовать версию 2.2 или новее: остальные директивы примера на более ранних версиях не проверялись.

Настройка HAProxy

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

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

• HAProxy должен работать в режиме HTTP, то есть в секциях defaults, frontend и backend необходимо указать mode http.

• В секции frontend необходимо указать файл сертификата балансировщика, потому что клиентский сеанс TLS завершается на балансировщике.

• Для серверов в секции backend необходимо указать параметр ssl, потому что до узлов шлюза платформы устанавливается новое соединение HTTPS.

• Протокол необходимо ограничить версией HTTP/1.1 параметром alpn http/1.1 и в секции frontend, и в секции backend. Протокол HTTP/2 для этого сценария не поддерживается.

• Балансировщик обязательно передает заголовки X-Forwarded-For и X-Forwarded-Proto. После завершения сеанса TLS узел шлюза платформы видит источником соединения сам балансировщик, поэтому эти заголовки передают приложению исходный IP-адрес клиента и исходную схему https. Без них некорректно работают записи журнала аудита, абсолютные адреса URL и перенаправления.

• Заголовок X-Forwarded-For необходимо задавать директивой http-request set-header, которая заменяет значение, полученное от клиента. Параметр option forwardfor для этого не подходит: он дописывает свое значение в конец уже имеющегося списка, поэтому клиент может подставить произвольный адрес первым элементом. Astra Automation читает этот заголовок без списка доверенных балансировщиков, поэтому в журнал аудита попал бы адрес, выбранный клиентом.

• Заголовки Connection и Upgrade удалять и перезаписывать нельзя – они используются при установлении соединения WebSocket.

• Проверку доступности узлов шлюза платформы необходимо выполнять по адресу /api/gateway/v1/ping/. Проверка с пустым URI или с неверным заголовком Host приводит к тому, что все узлы помечаются как недоступные.

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

• Настройте административный интерфейс статистики HAProxy, доступный через порт 9000 по адресу /stats, с включенной базовой аутентификацией для мониторинга состояния компонентов backend и их нагрузки. В примере интерфейс привязан к петлевому адресу и доступен по адресу http://127.0.0.1:9000/stats с самого узла балансировщика.

  Вход осуществляется с помощью учетной записи и пароля, заданных параметром stats auth. В примере пароль приведен временным заменителем <password>: применять пример с паролем из документации нельзя.

  Предупреждение

  Интерфейс статистики отдает состав backend и состояние узлов платформы, поэтому за периметром он доступен быть не должен. Чтобы открыть его с рабочего места администратора, замените петлевой адрес на адрес узла в административной сети.

  Указывать VIP-адрес нельзя. VIP поднят только на одном узле, поэтому на резервном узле HAProxy не найдет этот адрес и не запустится – откажет весь процесс, а не одна секция настройки.

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

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 http
    option httplog
    option dontlognull
    timeout connect 5s
    timeout client 60s
    timeout server 60s
    timeout http-request 15s
    timeout tunnel 3600s
    retries 3

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

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

• mode – режим работы, для балансировки на уровне L7 необходимо указать http;

• option httplog – включение расширенного ведения журнала запросов HTTP;

• option dontlognull – исключение из журнала соединений, в которых не было передано данных;

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

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

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

• timeout http-request – максимально допустимое время ожидания полного запроса HTTP от клиента;

• timeout tunnel – максимально допустимое время простоя установленного соединения WebSocket. Соединение закрывается, если в течение этого времени по нему не передаются данные; активное соединение продолжает работать;

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

Frontend https-in

Frontend https-in принимает трафик на порту 443, завершает клиентский сеанс TLS и передает запрос в backend с узлами шлюза платформы.

# Прием клиентских соединений и завершение сеанса TLS
frontend https-in
    bind *:443 ssl crt /etc/haproxy/certs/gateway.pem alpn http/1.1
    mode http

    http-request set-header X-Forwarded-For %[src]
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    http-request set-header X-Forwarded-Port %[dst_port]
    http-request set-header X-Forwarded-Host %[req.hdr(Host)]

    default_backend gateway_backend

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

• bind – IP-адрес и порт для входящих соединений, а также параметры TLS:

  • ssl crt – файл с закрытым ключом и цепочкой сертификата балансировщика. Закрытый ключ в этом файле располагается первым, за ним следует цепочка сертификата;

  • alpn http/1.1 – список протоколов, о поддержке которых балансировщик сообщает клиенту. Протокол HTTP/2 в этот список не входит.

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

• http-request set-header – заголовки, которые балансировщик добавляет к запросу, заменяя значения, полученные от клиента:

  • X-Forwarded-For – IP-адрес клиента, взятый из параметров соединения (%[src]), а не из запроса;

  • X-Forwarded-Proto – исходная схема запроса, устанавливается в https при поступлении запроса по TLS;

  • X-Forwarded-Port – порт, на который поступило соединение;

  • X-Forwarded-Host – доменное имя из исходного запроса клиента.

• default_backend – backend, в который направляется трафик.

Backend gateway_backend

Секция backend gateway_backend определяет узлы шлюза платформы, между которыми распределяется трафик, и порядок проверки их доступности.

# Группа узлов шлюза платформы
backend gateway_backend
    mode http
    balance source

    option httpchk
    http-check send meth GET uri /api/gateway/v1/ping/ ver HTTP/1.1 hdr Host aa.demo.example.com
    http-check expect status 200

    http-reuse safe

    default-server inter 10s fall 3 rise 2 ssl verify required ca-file /etc/haproxy/certs/gateway-ca.pem sni str(aa.demo.example.com) check-sni aa.demo.example.com verifyhost aa.demo.example.com alpn http/1.1
    server gw1 192.168.56.11:443 check
    server gw2 192.168.56.12:443 check

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

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

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

• option httpchk – включение проверки доступности на уровне HTTP.

• http-check send – параметры запроса проверки доступности: метод, адрес /api/gateway/v1/ping/, версия протокола и заголовок Host с доменным именем шлюза платформы.

• http-check expect – код ответа, при котором узел считается доступным.

• http-reuse safe – повторное использование соединений с узлами шлюза платформы.

• default-server – параметры, общие для всех серверов backend:

  • inter, fall, rise – интервал проверки доступности, количество неудачных проверок для перевода узла в недоступное состояние и количество успешных проверок для возврата в рабочее состояние;

  • ssl – установление соединения HTTPS до узла;

  • verify required и ca-file – проверка сертификата узла и файл сертификата удостоверяющего центра, которому доверяет балансировщик;

  • sni – доменное имя, передаваемое узлу при установлении соединения TLS для рабочего трафика;

  • check-sni – то же доменное имя для соединений проверки доступности;

  • verifyhost – доменное имя, с которым сверяется сертификат узла, если соединение установлено без SNI;

  • alpn http/1.1 – ограничение протокола версией HTTP/1.1.

  Параметры sni и check-sni задаются отдельно, потому что HAProxy устанавливает рабочее соединение и соединение проверки доступности независимо друг от друга. Параметр sni на проверки доступности не распространяется, и без check-sni они выполняются без SNI. Если узел шлюза платформы выбирает сертификат по SNI, на такую проверку он отдает сертификат по умолчанию, который может не соответствовать параметру ca-file. В этом случае все узлы переходят в недоступное состояние, а внешний адрес платформы начинает отвечать кодом 503. Параметр verifyhost дополнительно задает доменное имя для сверки с сертификатом узла, если SNI в соединении отсутствует.

• server – узел шлюза платформы с IP-адресом, портом и проверкой доступности.

Listen stats

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

listen stats
    bind 127.0.0.1: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 – текстовое сообщение в диалоге аутентификации.

Поддержка WebSocket

Шлюз платформы и другие компоненты Astra Automation используют протокол WebSocket для обмена данными в реальном времени, например для вывода журнала выполнения задания. Клиент устанавливает соединение WebSocket обычным запросом GET по протоколу HTTP/1.1 с заголовками Connection: Upgrade, Upgrade: websocket, Sec-WebSocket-Key и Sec-WebSocket-Version. Если узел шлюза платформы принимает такой запрос, он отвечает кодом 101 Switching Protocols, после чего соединение остается открытым для двустороннего обмена данными.

Дополнительные правила преобразования запросов для HAProxy не требуются: в режиме mode http заголовки Connection и Upgrade сохраняются, если настройка не удаляет их явно. Для корректной работы соединений WebSocket соблюдайте следующие требования к настройке балансировщика:

• не удаляйте и не перезаписывайте заголовки Connection и Upgrade;

• ограничьте протокол версией HTTP/1.1;

• задайте параметр timeout tunnel, например 3600s;

• не включайте протокол HTTP/2 ни в секции frontend, ни в секции backend.

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

curl -i --http1.1 \
  -H 'Connection: Upgrade' \
  -H 'Upgrade: websocket' \
  -H 'Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==' \
  -H 'Sec-WebSocket-Version: 13' \
  https://aa.demo.example.com<websocket-path>

Здесь:

• <websocket-path> – адрес точки доступа WebSocket того компонента платформы, соединение с которым проверяется;

• dGhlIHNhbXBsZSBub25jZQ== – одноразовый ключ из примера в RFC 6455. Ключ должен содержать 16 байт в кодировке Base64, иначе узел отвечает кодом 400 независимо от настройки балансировщика.

Ожидаемый результат: 101 Switching Protocols. Такой ответ возможен только при успешной аутентификации и доступной точке доступа, поэтому ответы 400, 401 или 403 не всегда указывают на ошибку балансировщика. Для проверки балансировщика важно, чтобы запрос доходил до шлюза платформы, не обрывался на балансировщике и не преобразовывался в HTTP/2.

Проверка балансировщика до развертывания платформы

До развертывания платформы узлы шлюза еще не отвечают на порту 443, поэтому ответ от компонентов платформы получить нельзя. На этом этапе проверяется готовность VIP, завершения сеанса TLS и маршрутизации.

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

1. Убедитесь, что доменное имя из automationgateway_main_url разрешается в адрес VIP:

   getent hosts aa.demo.example.com
   

2. Убедитесь, что сертификат балансировщика доверенный и проходит стандартную проверку TLS:

   curl -v --http1.1 --max-time 10 https://aa.demo.example.com/
   

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

   curl --cacert /path/to/ca.crt -v --http1.1 --max-time 10 https://aa.demo.example.com/
   

   Ожидаемый результат: сеанс TLS устанавливается, а балансировщик возвращает ответ HTTP, обычно 503 Service Unavailable, потому что узлы шлюза платформы еще не запущены. Если соединение не устанавливается или завершается по таймауту, проверьте VIP, настройки межсетевого экрана, DNS и параметры балансировщика.

Балансировщик готов к развертыванию платформы, если выполнены следующие условия:

• доменное имя из automationgateway_main_url разрешается с установочного узла;

• установочный узел доверяет сертификату балансировщика, и сеанс TLS устанавливается без отключения проверки сертификата;

• балансировщик отвечает кодом HTTP, а не таймаутом TCP;

• в проверке доступности указан адрес /api/gateway/v1/ping/, а не пустой URI.

Примечание

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

Проверка балансировщика после развертывания платформы

После развертывания платформы необходимо проверить не только доступность графической консоли, но и служебные точки доступа API, которые использует утилита развертывания и реестр образов. Все проверки рекомендуется выполнять без параметра -k: он отключает проверку сертификата и допустим только для локализации неисправностей TLS.

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

1. Проверьте доступность API шлюза платформы:

   curl -sS -D - --max-time 20 https://aa.demo.example.com/api/gateway/v1/ -o /dev/null
   

   Ожидаемый результат: код 200 и документ JSON с описанием API шлюза платформы.

2. Проверьте точку доступа, используемую для проверки доступности:

   curl -sS -D - --max-time 20 https://aa.demo.example.com/api/gateway/v1/ping/ -o /dev/null
   

   Ожидаемый результат: код 200.

3. Проверьте запрос учетных данных реестра образов:

   curl -sS -I --max-time 20 https://aa.demo.example.com/v2/
   

   Ожидаемый результат: код 401 Unauthorized с заголовками WWW-Authenticate и docker-distribution-api-version: registry/2.0.

4. Получите токен доступа к реестру образов:

   TOKEN=$(curl -sS -u <user>:<password> --max-time 20 \
     "https://aa.demo.example.com/token/?service=aa.demo.example.com&scope=repository:<repository>:pull" \
     | python3 -c 'import json, sys; data = json.load(sys.stdin); print(data.get("token") or data.get("access_token"))')
   

   Здесь:

   • <user> и <password> – учетная запись и пароль администратора платформы;

   • <repository> – название репозитория в реестре образов, например foo/bar.

   Ожидаемый результат: код 200 и документ JSON с полем token или access_token.

5. Выполните запрос к реестру образов с полученным токеном доступа:

   curl -sS -D - --max-time 20 \
     -H "Authorization: Bearer ${TOKEN}" \
     https://aa.demo.example.com/v2/<repository>/tags/list
   

   Ожидаемый результат: ответ реестра образов. Для несуществующего репозитория ожидается код 404 с ошибкой NAME_UNKNOWN – он подтверждает, что токен принят и запрос дошел до реестра образов. Если возвращается код 401 или 403, проверьте аутентификацию, привилегии учетной записи и маршрутизацию между шлюзом платформы и реестром образов. Если вместо ответа реестра образов возвращается страница графической консоли или перенаправление, проверьте настройку маршрутизации на балансировщике.

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

Диагностика неисправностей

В следующей таблице приведены типовые неисправности при работе через балансировщик и порядок их устранения.

Симптом	Вероятная причина	Проверка
Узел шлюза платформы помечен в статистике HAProxy как недоступный	Проверка доступности выполняется без URI или с неверным заголовком Host	Убедитесь, что в http-check send указаны адрес /api/gateway/v1/ping/, версия HTTP/1.1 и доменное имя шлюза платформы в заголовке Host
Графическая консоль открывается, но загрузка образов EE завершается ошибкой	Не проходит последовательность запросов к реестру образов	Выполните проверку реестра образов, приведенную в разделе Проверка балансировщика после развертывания платформы
Не работает соединение WebSocket	Балансировщик удаляет заголовки Connection и Upgrade или использует HTTP/2	Убедитесь, что задан параметр alpn http/1.1, заголовки не перезаписываются и настроен timeout tunnel
Ошибка TLS при подключении к узлу шлюза платформы	Балансировщик не доверяет сертификату узла	Импортируйте сертификат удостоверяющего центра и укажите его в параметре ca-file
Внешний адрес возвращает код 503 после развертывания платформы	Все узлы шлюза платформы недоступны	Проверьте проверку доступности, сертификаты узлов, настройки межсетевого экрана и доступность порта 443
Развертывание контейнеризованной платформы завершается ошибкой CERTIFICATE_VERIFY_FAILED	Установочный узел не доверяет сертификату балансировщика	Проверьте цепочку сертификатов и выполнение команды curl без параметра -k

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

Для упрощения диагностики балансировки через 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 и автоматически исключает недоступные узлы из схемы балансировки.

  Балансировка уровня TCP здесь применяется на участке «клиент – узлы HAProxy» и не противоречит требованию к участку «балансировщик – шлюз платформы». Сеанс TLS по-прежнему завершается на HAProxy, а до узлов шлюза платформы трафик идет по схеме L7, описанной выше.

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