Новая конфигурация балансировки

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

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

2. Нажмите Добавить конфигурацию.

3. Последовательно заполните вкладки формы: L4/L7, Сервисы, Обработка трафика, Безопасность. Все поля, отмеченные , являются обязательными для заполнения.

4. Нажмите Добавить для создания конфигурации балансировки.

L4/L7

На вкладке L4/L7 определяются базовые настройки конфигурации, которые формируют основной набор её параметров.

Все параметры сгруппированы по четырём секциям:

• Общие настройки конфигурации,
• Отказоустойчивость (HA),
• Расширенные настройки,
• Производительность.

Общие настройки конфигурации

• Название — название для добавляемой конфигурации балансировки, которое будет использоваться в системе 5А.

• Адрес — сетевой адрес сервера, на котором запущен балансировщик. Может быть IP-адресом или доменным именем. Поддерживается ввод IP-адресов в формате IPv4 и IPv6.

• Порт — сетевой порт сервера, на котором запущен балансировщик.

  ⚠️

  Важно: указываемый порт должен быть уникальным среди конфигураций балансировки в рамках текущего кластера балансировки для всех протоколов, кроме протоколов HTTP и HTTPS. Конфигурации балансировки с протоколами HTTP и HTTPS могут использовать один и тот же порт при условии, что значение параметра Имена хостов у них будет отличаться.

• VRF – VRF-профиль, к которому будет привязана данная конфигурация балансировки. Трафик, проходящий через эту конфигурацию, будет маршрутизироваться через указанный VRF. Выбирается из списка существующих VRF. Если поле не заполнено, используется глобальная таблица маршрутизации.

• L4 протокол — протокол для балансировки трафика на транспортном уровне (L4) согласно семиуровневой модели OSI. Возможные варианты:

  • TCP,
  • UDP.
  ⚠️

  Важно: В релизе системы 5А версии 1.4 и ниже не поддерживается возможность одновременной балансировки трафика на протоколах L4 и L7 в рамках одного кластера. Если требуется к одному сервису иметь балансировку на уровнях L4 и L7, то следует создать два кластера: в первом должны быть конфигурации балансировки только с протоколами уровня L4, во втором — уровня L7.

• L7 протокол — протокол для балансировки TCP-трафика на прикладном уровне (L7) согласно семиуровневой модели OSI. Возможные варианты:

  • пустое значение,

  • HTTP,

  • HTTPS,

  • gRPC.

    ℹ️

    При выборе протокола gRPC недоступны следующие настройки конфигурации балансировки:

    • подключение мониторов;
    • функции обработки трафика с помощью политик и сценариев;
    • секция Аутентификация: профиль аутентификации к сервису с протоколом gRPC не привязывается, поэтому такие запросы не проверяются;
    • опции JA3 и JA4 в настройках безопасности.

Отказоустойчивость (HA)

Секция Отказоустойчивость (HA) позволяет настроить механизмы обеспечения непрерывности работы сервисов при отказе отдельных компонентов инфраструктуры.

Пример заполнения секции "Отказоустойчивость (HA)"

• Тип — определяет архитектуру отказоустойчивости. Доступные варианты:

  • BGP (Active-Active) — оба модуля балансировки активны и одновременно обрабатывают трафик. Распределение трафика между модулями осуществляется с помощью протокола BGP через анонс виртуального IP-адреса (VIP). При недоступности одного из модулей BGP-сессия разрывается, и весь трафик автоматически перенаправляется на оставшийся активный модуль балансировки.

  • VRRP (Active-Passive) — один модуль балансировки является активным (MASTER) и обрабатывает трафик, остальные находятся в режиме ожидания (BACKUP). При отказе MASTER один из BACKUP автоматически становится активным. Протокол VRRP работает в пределах одного L2-сегмента. Для настройки VRRP требуется создать группу VIP.

  ℹ️

  Подробная настройка VRRP описана в разделе Настройка VRRP.

  ⚠️

  При использовании BGP все заполненные значения параметров после сохранения конфигурации балансировки сформируют новую FRR-конфигурацию BGP для сетевых агентов, которая перезапишет конфигурацию, доступную в разделе Сеть на вкладке Конфигурация. Если вам требуется дополнительно поддерживать OSPF и VRRP, то следует вручную сформировать FRR-конфигурацию со всеми необходимыми настройками без использования настроек секции "Отказоустойчивость (HA)".

Параметры BGP (выбираются при типе BGP (Active-Active))

• VIP — виртуальный IP-адрес или подсеть, используемые для доступа к сервису. Этот адрес анонсируется в BGP и может быть доступен с модулей балансировки в режиме Active-Active. Клиенты сервиса подключаются именно к этому адресу.

  ⚠️

  Важно: Использование механизмов отказоустойчивости блокирует использование параметра Адрес из секции Общие настройки конфигурации. В таком случае вся конфигурация балансировки будет работать по адресу, указанному в параметре VIP. Информация об этом VIP будет доступна в разделе Сеть на вкладке IP/VIP после создания конфигурации балансировки.

• ASN — номер автономной системы (AS), который будет использоваться модулем балансировки при установлении BGP-сессии с соседними маршрутизаторами. Номер должен соответствовать настройкам сетевой инфраструктуры.

Управление анонсом VIP (RHI) — блок параметров, управляющих автоматическим анонсом VIP через BGP с использованием Route Health Injection (RHI).

• Автоанонс VIP (RHI) при доступности сервисов — опция включает автоматическое управление анонсом VIP. Если опция включена, то VIP анонсируется только тогда, когда доля доступных клиентских серверов не ниже заданного порога, с учётом задержек для предотвращения частых переключений.

• Порог доступности для анонса VIP, % — минимальный процент доступных бэкенд-узлов, при котором VIP остаётся в BGP-анонсе. Если доступность падает ниже этого порога, VIP снимается с анонса. Значение по умолчанию — 50.

• Задержка снятия анонса VIP, мс — время в миллисекундах, которое система ждёт перед снятием VIP из BGP-анонса после того, как доступность сервиса упала ниже порога. Помогает не реагировать на кратковременные сбои.

• Задержка повторного анонса VIP, мс — время в миллисекундах, которое система ждёт после восстановления доступности сервиса выше порога, прежде чем снова объявить VIP. Позволяет убедиться, что восстановление устойчивое.

• Интервал после снятия VIP, мс — интервал после снятия VIP, в течение которого повторный анонс временно подавляется. Используется для избежания частых переключений (flapping) при нестабильной работе сервиса.

• Соседи (BGP пиры) — блок, в котором указывается информация о BGP-соседях. Добавление информации о BGP-соседе выполняется после нажатия на Добавить соседа. В качестве BGP-соседей следует указывать либо отдельный маршрутизатор с поддержкой BGP (например, роутер от Cisco), либо сервер, на котором развёрнут только сетевой агент системы 5А без дополнительных модулей. Такой сервер также будет выполнять роль маршрутизатора. Сохранённая информация о BGP-соседях представлена в виде таблицы, каждый элемент которой можно редактировать или удалить .

  

  Пример заполнения формы "Новый сосед"

  • IP — сетевой адрес BGP-соседа, с которым устанавливается BGP-сессия. Если в предложенном списке нет адресов подходящих сетевых агентов 5А, то выберите значение "Ввести вручную" и в поле ниже укажите сетевой адрес маршрутизатора, который будет использоваться как BGP-сосед.
  • AS — номер автономной системы (AS) BGP-соседа. Этот параметр должен соответствовать конфигурации на стороне маршрутизатора.
  ℹ️

  Информация о добавленных BGP-соседях будет доступна в разделе Сеть на вкладке Соседи после создания конфигурации балансировки.

• BFD — блок для настройки протокола BFD. Используется для ускорения реакции на сбои канала связи между узлами по сравнению со стандартными механизмами BGP. Параметры BFD позволяют настроить чувствительность и частоту проверок:

  • BFD-множитель — количество последовательных пропущенных BFD-пакетов, после которого соединение считается разорванным.

    ℹ️

    Например, при множителе 3 и интервале приема 300 таймаут обнаружения отказа составит 900 мс.

  • Интервал приема — минимальный интервал в миллисекундах, с которым локальный узел готов принимать BFD-пакеты от удалённой стороны. Значение должно быть согласовано с настройками соседнего устройства.

  • Интервал передачи — желаемый интервал в миллисекундах, с которым локальный узел отправляет BFD-пакеты удалённой стороне. Фактический интервал может быть скорректирован в зависимости от возможностей удалённого узла.

Расширенные настройки

Пример заполнения секции "Расширенные настройки"

• Маска для фильтрации запросов — URI или регулярное выражение, по которому происходит дополнительная фильтрация запросов. Если поле не заполнено, то фильтрация не используется.

• Версия HTTP проксирования — параметр определяет версию протокола HTTP, которую система балансировки будет использовать при установке соединений с бэкенд-серверами. Доступные варианты:

  • HTTP/1.1 (рекомендуется),
  • HTTP/1.0

• Поддержка WebSocket — опция включает WebSocket для обеспечения двусторонней связи между клиентом и сервером сервиса.

• Proxy Protocol — опция включает поддержку Proxy Protocol v1, что позволяет передавать информацию о реальном IP-адресе клиента при балансировке TCP-трафика, где стандартные HTTP-заголовки недоступны. При включении этой опции балансировщик добавляет специальный заголовок в начало TCP-соединения, содержащий метаданные о клиенте, включая его исходный IP-адрес и порт. Этот механизм важен в сценариях, где серверу необходимо знать реальный IP-адрес клиента, например, для логирования, геолокации, ограничения доступа по IP или аудита, но трафик проходит через балансировщик нагрузки, скрывающий исходный адрес.

• HTTP2 — опция позволяет обрабатывать трафик по протоколу HTTP/2 (по умолчанию используется только HTTP 1.1).

• Поддержка IPv6 — опция включает обработку трафика по протоколу IPv6 на уровне балансировщика. Если опция выключена, агенты балансировки не будут использовать IPv6-адреса для приёма и передачи трафика.

  ℹ️

  Отключение IPv6 актуально только для сетевых агентов балансировщика и не влияет на работу других компонентов системы 5А.

Производительность

Пример заполнения секции "Производительность"

• Время ответа балансировщика — значение определяет таймаут в секундах для передачи ответа клиенту. Таймаут устанавливается только между двумя последовательными операциями записи, а не для передачи всего ответа. Если клиент ничего не получает в течение этого времени, соединение закрывается. Рекомендуется устанавливать значение в зависимости от производительности сервисов и требований к задержкам.

• Максимальный размер тела запроса — максимально допустимый размер тела HTTP в килобайтах, который балансировщик может передать клиенту. Если запрос от сервера превышает это значение, клиенту может быть возвращена ошибка. Параметр используется для защиты от чрезмерного потребления ресурсов при передаче больших файлов. Увеличивайте значение, если приложение активно работает с крупными файлами (например, загрузка/выгрузка документов, медиа и т.д.).

• Переиспользование порта — опция включает на агенте использование флага SO_REUSEPORT, что позволяет нескольким процессам (или потокам) агента слушать один и тот же порт одновременно. Ядро ОС автоматически распределяет входящие соединения между этими процессами, что значительно повышает производительность на многоядерных серверах. Рекомендуется включать на серверах с 4+ ядрами и высокой нагрузкой (например, >10 KReq/s) для лучшего распределения входящих соединений.

Блок параметров "Буферизация":

• Буферизация ответа — опция включает буферизацию ответов от сервера. При включении балансировщик накапливает ответ перед отправкой клиенту, что улучшает производительность и снижает нагрузку на сеть. При отключении данные передаются потоково.

  При включении опции становятся доступными дополнительные параметры настройки буферизации:

  • Размер буфера для ответа (KB) — размер одного буфера в килобайтах, используемого для временного хранения части ответа от сервера перед отправкой клиенту. Чем больше размер буфера, тем меньше операций ввода-вывода при передаче данных, что может повысить производительность. Рекомендуется устанавливать значение, кратное размеру страницы файловой системы (обычно 4 КБ или 8 КБ). Слишком малое значение может снизить производительность, слишком большое — увеличить потребление памяти.

  • Размер буфера для соединения (KB) — общий размер буферов в килобайтах, выделенных для одного соединения при буферизации ответа. Это значение определяет, сколько данных может быть временно сохранено в памяти до отправки клиенту. Используется в связке с параметром "Число буферов для соединения".

    ⚠️

    Важно: Значение должно быть кратно значению "Размер буфера для ответа", если используется несколько буферов.

  • Число буферов для соединения — количество буферов, используемых для одного соединения. Вместе с параметром "Размер буфера для соединения" определяет общий объём памяти, доступный для временного хранения ответа. Настройка применяется при работе с ответами среднего размера, которые не помещаются в один буфер, но не требуют сохранения на диск.

  • Максимальный размер файла буферизации — максимальный объём данных в килобайтах, который может быть сохранён во временном файле на диске, если объём ответа превышает объём оперативной памяти, выделенной для буферизации. Если ответ больше этого значения, клиенту может быть возвращена ошибка. Рекомендуется увеличивать значение при необходимости передачи больших ответов (например, экспорт данных, видео и т.п.)

• Буферизация запроса — опция включает буферизацию запросов от клиента. При включении тело запроса полностью считывается до отправки серверу, что позволяет повторно отправлять запросы при переподключении.

Блок "Keepalive для клиентских соединений" содержит настройки, управляющие жизненным циклом соединений между клиентом и балансировщиком. Позволяют повторно использовать TCP-соединения, избегая накладных расходов на TLS-рукопожатие и установку TCP-сессий.

• Таймаут keepalive для клиента — время в секундах, в рамках которого балансировщик будет держать клиентское соединение открытым после последнего запроса в ожидании следующего. Рекомендуется увеличивать значение при высокой частоте запросов от одного клиента. Слишком маленькое значение вызывает лишние рукопожатия, слишком большое — удерживает ресурсы без пользы.

• Максимум запросов на одном клиентском соединении — параметр ограничивает количество HTTP-запросов, которые могут быть обработаны по одному TCP-соединению до его закрытия. Рекомендуется увеличивать значение при работе с API-клиентами, использующими долгие сессии. Для браузеров достаточно указать значение 50–100.

• Максимальное время жизни клиентского keepalive — время в секундах, определяющее максимальный срок существования клиентского соединения независимо от его активности. После истечения соединение принудительно закрывается. Рекомендуется использовать для предотвращения "висячих" соединений, также полезно при DDoS-защитах или в средах с нестабильными клиентами.

• TCP keepalive для клиентских сокетов — опция включает механизм TCP-level keepalive на стороне клиента, который отправляет периодические пакеты для проверки соединения. Рекомендуется включать при использовании сетей с долгими таймаутами.

Блок "Keepalive для соединений на серверы" содержит настройки, управляющие соединениями между балансировщиком и бэкенд-серверами. Используются для снижения нагрузки на серверы и ускорения ответов.

• Количество сохраняемых соединений — максимальное число активных keepalive-соединений, которые балансировщик будет кэшировать для каждого бэкенда. Рекомендуется увеличивать значение при высокой частоте обращений к одному upstream-серверу (например, микросервисы с низкой задержкой). При этом слишком высокие значения увеличивают потребление файловых дескрипторов и памяти.

• Таймаут keepalive для серверов — время в секундах, в течение которого балансировщик будет держать соединение с бэкендом открытым после завершения запроса в ожидании следующего. Рекомендуется указывать значение меньше или равное таймауту бэкенда. Если бэкенд закрывает соединение раньше, то оно будет пересоздаваться.

• Максимум запросов на одном соединении к серверу — параметр ограничивает количество HTTP-запросов, которые могут быть выполнены по одному соединению к бэкенду перед его закрытием. Рекомендуется увеличивать значение при работе с медленными или неоптимизированными бэкендами, чтобы минимизировать создание новых TCP-сессий. Для сервисов с высокой нагрузкой достаточно указать значение 50–200.

• Максимальное время жизни keep-alive соединения с сервером — время в секундах, определяющее максимальный срок существования соединения с бэкендом, независимо от количества запросов. После истечения соединение закрывается, даже если оно ещё активно. Рекомендуется использовать для предотвращения накопления "устаревших" соединений.

• TCP keepalive на прокси-сокетах — опция включает механизм TCP-level keepalive на соединениях между балансировщиком и бэкендами. Рекомендуется включать при использовании нестабильных сетей, где соединение может "зависнуть" без явного разрыва.

Блок "Ограничение запросов" содержит настройки, ограничивающие интенсивность HTTP-запросов для предотвращения перегрузки системы и атак типа DoS/DDoS. Работает на уровне приложения (L7) и применяется до маршрутизации к бэкенду.

• Критерий ограничения — параметр определяет признак, по которому применяется ограничение запросов:

  • Не ограничивать — ограничения отключены, все запросы обрабатываются без контроля частоты запросов.
  • По IP клиента — ограничения применяются к каждому уникальному IP-адресу клиента. Подходит для защиты от перебора или сканирования.
  • По адресу сервера — ограничения применяются ко всем запросам, направляемым к конкретному бэкенду. Полезно при защите уязвимых сервисов.
  • По конфигурации — ограничения применяются на основе конфигурации.

• Средняя скорость r/s — среднее количество запросов в секунду, разрешенное для одного объекта ограничения. Превышение этого значения активирует механизм ограничения.

• Максимальный размер всплеска — максимальное число запросов, которые могут быть "всплеском", т.е. приняты немедленно, даже если средняя скорость временно превышена. Используется для поддержки естественных скачков нагрузки.

• Не задерживать запросы всплеска — если опция включена, запросы, превышающие лимит средней скорости и всплеска, не ставятся в очередь, а немедленно отклоняются с ошибкой 503 Service Unavailable. Если опция выключена, избыточные запросы задерживаются (rate limiting с очередью) для сглаживания пиков, но это может увеличить время ответа.

• Размер хранилища (МБ) — объём памяти в мегабайтах, выделенный для хранения состояния ограничителя. Чем больше хранилище, тем больше объектов (IP клиента, адреса серверов) может одновременно отслеживаться.

Блок "Ограничение соединений" содержит настройки, управляющие количеством одновременных соединений для защиты от перегрузки сети и исчерпания ресурсов бэкенда. Работает на транспортном уровне (L4).

• Критерий ограничения — параметр определяет признак, по которому применяется ограничение соединений:

  • Не ограничивать — ограничения отключены, обрабатываются все соединения.
  • По IP клиента — ограничивает количество соединений с одного IP. Защищает от flood-атак и злоупотребления ресурсами.
  • По адресу сервера — ограничивает общее число соединений, направленных к конкретному бэкенду. Полезно при защите медленных или слабых серверов.
  • По конфигурации — ограничения применяются на основе конфигурации.

• Максимальное число соединений — максимальное количество одновременных соединений, разрешенных для одного объекта ограничения.

• Размер хранилища (МБ) — объём памяти в мегабайтах, выделенный для хранения состояния ограничителя. Чем больше хранилище, тем больше объектов (IP клиента, адреса серверов) может одновременно отслеживаться.

Сервисы

Вкладка "Сервисы" — на ней определяются настройки пользовательского сервиса, на который будет балансироваться трафик. Все параметры сгруппированы по трём секциям.

Настройки сервиса

Пример заполнения секции "Настройки сервиса"

• Время ожидания ответа — значение определяет таймаут в секундах для чтения ответа от сервера. Таймаут устанавливается только между двумя последовательными операциями чтения, а не для передачи всего ответа. Если сервер ничего не передаст в течение этого времени, соединение закрывается.

• Время ожидания подключения — значение определяет таймаут в секундах для установления соединения с сервером. Таймаут не может превышать 75 секунд.

• Группы серверов — блок, содержащий описание групп клиентских серверов, на которые может распределяться трафик в рамках текущей конфигурации балансировки. Во время работы модуля балансировки трафик направляется только на одну группу — ту, которая одновременно:

  • имеет наивысший приоритет (наименьшее числовое значение приоритета) среди всех добавленных групп,
  • обладает статусом "Активна".

  Добавление информации о группах происходит построчно, одна строка описывает одну группу. Новая строка появляется после нажатия на Добавить группу серверов:

  • Приоритет — числовое значение, определяющее относительный приоритет группы серверов среди всех групп в рамках одной конфигурации балансировки. Чем меньше значение приоритета, тем выше приоритет группы. Таким образом, группа с минимальным числовым значением будет выбрана для балансировки в первую очередь.

    ⚠️

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

  • Группа — группа клиентских серверов сервиса, на которую может распределяться трафик.

  • Состояние — колонка, отображающая текущий статус группы серверов в контексте балансировки трафика:

    • Неактивна — группа временно исключена из балансировки, поскольку не соответствует условиям работоспособности. Если состояние серверов в группе восстановится и группа снова станет пригодной для использования, она получит статус "Активна" только в том случае, если её приоритет выше, чем у текущей активной группы. В противном случае она останется в состоянии "Резерв".
    • Активна — группа признана работоспособной и в данный момент используется для распределения трафика. Дополнительно отображается соотношение количества работоспособных серверов к общему числу серверов в группе, что позволяет оценить её текущую загрузку и надёжность.
    • Неизвестно - состояние группы не может быть определено (например, отсутствуют данные от мониторов здоровья).
    • Выключена - группа принудительно исключена из процессов балансировки администратором и не будет использоваться даже при недоступности активной группы.
    • Резерв — группа находится в ожидании и не участвует в балансировке, но будет автоматически активирована в случае, если текущая активная группа перестанет удовлетворять заданному в ней правилу переключения (например, из-за снижения числа или процента доступных серверов).
    • Неоднозначно - часть серверов в группе доступна, часть недоступна, при этом группа всё ещё может участвовать в балансировке в зависимости от настроек условия переключения.
  ℹ️

  Если в конфигурацию добавлено несколько групп, то все они, за исключением текущей активной, автоматически получают статус "Резерв". Выбор активной группы осуществляется в соответствии с алгоритмом Priority Group Activation (PGA), основанным на приоритетах и состоянии работоспособности групп:

  • Если активная группа перестаёт удовлетворять заданному в ней условию переключения (например, из-за недостаточного количества или процента доступных серверов), то её статус меняется на "Неактивна", и балансировщик автоматически переключает трафик на следующую по приоритету группу со статусом "Активна".
  • Последняя группа в порядке приоритетов (с наименьшим приоритетом) продолжает использоваться до тех пор, пока в ней остаётся хотя бы один работоспособный сервер, даже если общее состояние группы формально не соответствует условиям активности. Это обеспечивает максимальную отказоустойчивость в крайнем резервном сценарии.

Правила балансировки

Пример заполнения секции "Правила балансировки"

• Алгоритм балансировки — используемый алгоритм балансировки нагрузки и распределения трафика. Доступные варианты:

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

  • Least Connections — алгоритм направляет новые соединения на сервер с наименьшим количеством активных подключений. Он подходит для ситуаций, когда нагрузка на серверы может сильно варьироваться. Алгоритм эффективен в условиях динамически изменяющегося трафика, так как учитывает текущее состояние серверов.

  • IP Hash — алгоритм использует хэш-функцию для распределения трафика на основе IP-адресов источника и назначения. Он генерирует уникальное значение хэша, которое определяет, какой сервер будет обрабатывать запрос. Алгоритм обеспечивает постоянство сессий, так как все запросы от одного и того же IP-адреса направляются на один и тот же сервер, что важно для приложений, требующих сохранения состояния.

  • Random — алгоритм распределяет запросы по серверам случайным образом. Алгоритм может быть эффективным в условиях равномерного распределения нагрузки, но не обеспечивает сессионной устойчивости.

  • Random two with Least Connections — алгоритм сначала случайным образом выбирает 2 сервера из списка серверов сервиса, а потом направляет соединение на тот сервер, у которого наименьшее количество активных подключений. Алгоритм может быть эффективным в условиях равномерного распределения нагрузки и позволяет избежать перегрузки отдельных серверов, но не обеспечивает сессионной устойчивости.

  • Custom Hash — алгоритм использует хэш-функцию для распределения трафика на основе хэширования определённых ключей. Этот метод обеспечивает "прилипание" запросов к конкретным серверам, что может быть полезно для сохранения состояния сессий. Параметры для хэширования указываются в поле Параметр, доступные варианты:

    • remote_addr,
    • request_uri,
    • host,
    • http_user_agent,
    • ssl_session_id,
    • request_method.

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

Persistence-балансировка

• Persistence-балансировка — опция, включающая механизм привязки сессий. То есть обеспечивается постоянное направление запросов одного и того же пользователя на один и тот же сервер в течение сессии.

При включении становится доступной таблица настройки источников.

• Приоритет — числовое значение, определяющее порядок проверки источников. Чем меньше число, тем выше приоритет.

• Источник — тип идентификатора, по которому будет строиться привязка. Доступные варианты:

  • Cookie — привязка на основе HTTP-cookie. Для этого типа требуется указать Имя cookie (поле «Параметр»).
  • Source IP — привязка по IP-адресу клиента. Для этого типа требуется выбрать Источник Client IP (поле «Параметр»):
    • remote_addr — IP-адрес из соединения;
    • x_forwarded_for — из заголовка X-Forwarded-For;
    • x_real_ip — из заголовка X-Real-IP;
    • real_ip — адрес, определённый модулем ngx_http_realip_module.
  • Destination IP — привязка по IP-адресу назначения (VIP или адрес, на который пришёл запрос). Дополнительных параметров не требует.
  • Source IP + Destination IP — комбинированная привязка по паре IP клиента + IP назначения. Дополнительных параметров не требует, но для выбора источника Client IP используется поле «Параметр» (аналогично Source IP).
  • HTTP Header — привязка по значению произвольного HTTP-заголовка. Для этого типа требуется указать Имя заголовка (поле «Параметр»), например X-User-ID или Authorization. Работает только при наличии L7-протокола.

• TTL, сек — время жизни привязки в секундах. По истечении этого срока запись удаляется, и клиент будет направлен на бэкенд по стандартному алгоритму балансировки (при следующем запросе может быть создана новая привязка). Диапазон допустимых значений: от 1 до 86400. Значение по умолчанию — 180.

• Параметр — дополнительное значение, зависящее от выбранного Источника (см. выше):

  • Cookie — Имя cookie.
  • Source IP (и Source IP + Destination IP) — Источник Client IP (выбор из remote_addr, x_forwarded_for, x_real_ip, real_ip).
  • HTTP Header — HTTP Header (имя заголовка).
  • Destination IP - поле не используется.

  Добавление нового источника выполняется нажатием на Добавить источник. Удаление — нажатием на справа от строки.

Исходящий трафик

Трансляция адресов

В блоке Трансляция адресов настраивается Режим трансляции адресов.

• Автоматически (режим по умолчанию) — балансировщик использует свой собственный IP-адрес в качестве источника. Подходит для большинства сценариев, когда не требуется строгий контроль над исходящими адресами.
• SNAT группы — используется предварительно созданная SNAT-группа — пул IP-адресов. Позволяет обойти ограничение ~65 000 сессий на один IP и даёт гибкое управление. При выборе этого режима необходимо указать существующую SNAT-группу из выпадающего списка.
• Прозрачный IP (IP Transparency) — балансировщик подменяет исходный IP-адрес в пакетах, идущих к бэкенду, на адрес реального клиента. Бэкенд видит запрос так, как будто он пришёл напрямую от клиента. Настройка IP Transparency
  ⚠️

  Важно: Для работы IP Transparency администратор инфраструктуры обязан вручную настроить на каждом бэкенде default gateway, указывающий на IP-адрес балансировщика (или VIP кластера). Без этого ответные пакеты не вернутся на балансировщик, и соединение разорвётся. Балансировщик не автоматизирует эту настройку, так как бэкенды находятся вне его зоны управления.

Стратегия распределения — поле, которое появляется только при выборе режима SNAT группы. Определяет, как балансировщик будет распределять исходящие соединения между IP-адресами выбранной SNAT-группы.

• mapping (Уникально для каждого агента / статическое сопоставление) — каждому клиентскому IP или подсети статически назначается конкретный IP-адрес источника. Используйте, когда требуется, чтобы определённые клиенты всегда выходили через один и тот же IP (например, для white-листинга на сервере сервиса).
• percentage (Полное дублирование / процентное распределение) — трафик распределяется между IP-адресами группы в заданной пропорции. Выбор адреса основан на хеше IP клиента. Используйте для равномерной нагрузки на все адреса группы, когда не важна жёсткая привязка клиента к конкретному IP.

Примечание. Конкретные IP-адреса и правила распределения (проценты или статические маппинги) настраиваются внутри самой SNAT-группы, а не в конфигурации балансировки. Здесь вы лишь выбираете группу и стратегию.

Обработка трафика

Вкладка "Обработка трафика" — на ней настраиваются правила обработки трафика путем выбора соответствующих политик и сценариев, добавленных ранее в систему 5А.

Пример заполнения секции "Обработка трафика"

• Подключенные политики — список названий политик, которые используются для обработки трафика в рамках текущей конфигурации балансировки. Если список пуст или требуется добавить новую политику, нажмите Управление политиками для её добавления.
• Подключенные сценарии — список названий сценариев, которые используются для обработки трафика в рамках текущей конфигурации балансировки. Если список пуст или требуется добавить новый сценарий, нажмите Управление сценариями для его добавления.

Безопасность

Вкладка "Безопасность" — на ней определяются настройки безопасности трафика.

Безопасность трафика

Пример заполнения секции "Безопасность трафика"

• Сертификат — название выбранного сертификата, который подтверждает подлинность веб-сервера у пользовательского сервиса.

  ℹ️

  Сертификат в этом поле выбирается из списка сертификатов, добавленных ранее в систему 5А. Если список сертификатов пуст или требуется добавить новый сертификат, нажмите Управление сертификатами и добавьте новый сертификат.

• Имена хостов — список доменных имён, которые будет обслуживать данная конфигурация балансировки.
  Это позволяет на одном порту обслуживать несколько доменов (виртуальный хостинг) с использованием одного сертификата, покрывающего все указанные имена.

  Поддерживаются:

  • точные домены (например, api.example.com, app.example.com);
  • wildcard-домены вида *.example.com (соответствуют api.example.com, но не api.staging.example.com).

  Правила заполнения:

  • Поле обязательно для L7-конфигураций с протоколом HTTP, HTTPS или GRPC: список не может быть пустым, нужно указать хотя бы одно имя.
  • Недопустимы дубли, пустые значения, а также невалидные wildcard-шаблоны (например, *, api.*.example.com).

  Добавление нового имени выполняется нажатием на Добавить имя хоста, удаление – нажатием на справа от строки.

• Подобрать по именам хостов — кнопка, которая фильтрует список доступных сертификатов, показывая только те, которые покрывают все указанные в поле Имена хостов домены.
  При нажатии вызывается API-запрос, возвращающий все подходящие сертификаты (не только первый).
  В результатах отображается тип совпадения: exact (точное совпадение) или wildcard (совпадение по wildcard-шаблону).
  Точные совпадения считаются более приоритетными, чем wildcard.
  Если ни один сертификат не подходит, отображается соответствующее сообщение.
  Чтобы вернуться к полному списку сертификатов, нажмите Показать все.

  ⚠️

  Если выбранный вручную сертификат не покрывает хотя бы одно из указанных имён хостов, система покажет ошибку при сохранении конфигурации.

• Поддерживаемые протоколы — набор протоколов, обеспечивающих безопасность трафика. Доступные варианты:

  • SSLv3,
  • TLS1.0,
  • TLS1.1,
  • TLS1.2 (рекомендуемый вариант),
  • TLS1.3 (рекомендуемый вариант).
  ⚠️

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

• Strict Transport Security Header — использование заголовка Strict Transport Security (HSTS). Доступные варианты:

  • Add the Strict Transport Security Header - include subdomains — заголовок указывает, что сайт должен посещаться только по HTTPS, и политика HSTS распространяется на все поддомены сайта.
  • Add the Strict Transport Security Header - include subdomains + preload — заголовок аналогичен предыдущему, но также включает флаг preload: браузеры могут предварительно загружать этот домен в свой встроенный список HSTS. Это делает политику HSTS более постоянной, так как она применяется даже для недавно установленных браузеров.
  • Add the Strict Transport Security Header - no subdomains — заголовок HSTS только для основного домена, без распространения на поддомены, т.е. поддомены будут доступны по HTTP.
  • Add the Strict Transport Security Header - no subdomains + preload — заголовок аналогичен предыдущему, но также включает флаг preload: политика HSTS будет применяться только к основному домену, но браузеры смогут предварительно загружать его в свой встроенный список HSTS.
  ⚠️

  Если ничего из указанных вариантов не выбрано, то заголовок HSTS не добавляется. В таком случае браузеры не будут применять политику принудительного использования HTTPS для сайта. Это менее безопасно, так как оставляет возможность атак типа SSL stripping.

• Pass Through SNI Hostname — опция включает передачу имени сервера через TLS без изменений, позволяя клиенту видеть истинный сервер, даже если прокси-сервер использует общий SSL-сертификат. Это важно для приложений, которые могут быть настроены на работу с конкретными именами серверов, поскольку это позволяет им правильно обрабатывать запросы и выбирать соответствующие ресурсы или сертификаты.

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

  ℹ️

  Включение данной опции также позволяет балансировать HTTP-трафик на серверы сервиса, требующих защищённое HTTPS-соединение.

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

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

• Алгоритмы шифрования — опция определяет набор криптографических алгоритмов, используемых при установлении защищённого TLS-соединения между сервисами и модулями балансировки.

  ⚠️

  Важно: Выбор алгоритма должен соответствовать типу установленного сертификата (RSA или ECDSA). Если используется сертификат, сгенерированный средствами системы 5А, то следует выбирать алгоритмы с использованием RSA.

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

  • Метод обмена ключами (ECDHE), обеспечивающий прямую секретность;
  • Тип цифровой подписи (RSA или ECDSA), используемый для аутентификации серверного сертификата;
  • Симметричный шифр (AES128-GCM, AES256-GCM или CHACHA20-POLY1305) для шифрования передаваемых данных;
  • Хэш-функция (SHA256 или SHA384), применяемая в процессе генерации ключей и проверки целостности.

  Доступные значения:

  • ECDHE-ECDSA-AES256-GCM-SHA384 — высокий уровень безопасности с использованием эллиптических кривых, ECDSA-подписей и 256-битного AES в режиме GCM. Подходит для сред с поддержкой сертификатов на основе ECDSA.
  • ECDHE-RSA-AES256-GCM-SHA384 — аналогичный уровень защиты, но с использованием RSA-сертификатов.
  • ECDHE-ECDSA-CHACHA20-POLY1305 — современный и производительный шифр, особенно эффективен на устройствах без аппаратной поддержки AES. Требует ECDSA-сертификат.
  • ECDHE-RSA-CHACHA20-POLY1305 — та же конфигурация, но с RSA-сертификатом.
  • ECDHE-ECDSA-AES128-GCM-SHA256 — сбалансированный выбор: обеспечивает прямую секретность и хорошую производительность при умеренном уровне защиты. Требует ECDSA-сертификат.
  • ECDHE-RSA-AES128-GCM-SHA256 — наиболее широко совместимый вариант с RSA-сертификатами и поддержкой большинством современных клиентов.

mTLS

Пример заполнения секции "mTLS"

Секция определяет параметры взаимной аутентификации между клиентом и сервером при установке защищённого соединения. В отличие от стандартного TLS, где аутентифицируется только сервер, mTLS требует, чтобы обе стороны подтвердили свою подлинность с помощью цифровых сертификатов, выданных доверенным центром сертификации (CA).

• Блок "Проверка клиента" содержит параметры, по которым балансировщик проверяет подлинность клиентов, инициирующих соединение.

  • Сертификат CA — сертификат удостоверяющего центра (CA), используемого для проверки клиентского сертификата. Балансировщик принимает соединение только в том случае, если клиент предоставляет сертификат, подписанный этим CA.

• Блок "Проверка сервера" содержит параметры, используемые балансировщиком при установке защищённого соединения с серверами сервиса.

  • Сертификат CA — сертификат удостоверяющего центра (CA), доверяя которому балансировщик проверяет подлинность сертификата, представленного сервером сервиса. Соединение с сервером устанавливается только в том случае, если его сертификат подписан этим CA.

  • Сертификат — сертификат, который балансировщик предъявляет серверу сервиса в рамках взаимной аутентификации. Этот сертификат должен быть подписан CA, доверенным серверу.

  • Имя сервера для SNI — имя сервера, которое будет использоваться при установлении TLS-соединения с бэкендом (SNI) при проверке его сертификата. Если значение не указано, то будет использоваться значение из полей Имена хостов или Название.

Производительность

Пример заполнения секции "Производительность"

Секция содержит параметры, которые управляют оптимизацией производительности SSL/TLS-соединений на уровне балансировщика. Настройка этих параметров напрямую влияет на задержки установления соединений, нагрузку на серверы и общую пропускную способность TLS-терминации.

• Кэширование клиентских SSL-сессий — параметр определяет, как балансировщик кэширует SSL-сессии для ускорения повторных рукопожатий.

  • Выключено — кэширование отключено. Каждое новое соединение требует полного TLS-рукопожатия. Максимальная безопасность, минимальная производительность.
  • Мягко выключено — кэширование включено, но не используется для принятия решений о маршрутизации. Сессии кэшируются локально, но не влияют на выбор бэкенда.
  • Включено — полное кэширование сессий. Повторные соединения от одного клиента могут восстанавливаться без полного рукопожатия, снижая задержку и нагрузку на CPU. Рекомендуется для стабильных окружений с высокой частотой повторных подключений.

• Размер кэша (сессий) — максимальное количество SSL-сессий, которые могут храниться в локальном кэше балансировщика. Увеличение значения повышает вероятность успешного возобновления сессий, особенно при высокой нагрузке, но потребляет больше памяти. Рекомендуется устанавливать значение, превышающее ожидаемое количество одновременных активных клиентов (например, 2–5x среднее количество одновременных соединений). Слишком малое значение приводит к частому сбросу сессий и снижению эффективности кэширования.

• Возобновление SSL-сессий с помощью TLS tickets — опция включает использование TLS Session Tickets для возобновления сессий.

• Время ожидания SSL-рукопожатия, сек — максимальное время в секундах, в течение которого балансировщик ожидает завершения TLS-рукопожатия от клиента. Если клиент не завершает рукопожатие в течение этого времени, соединение разрывается.

• Время жизни SSL-сессии, сек — время в секундах, в течение которого SSL-сессия считается валидной для возобновления (как через кэш, так и через TLS tickets). После истечения этого времени клиент должен выполнить полное рукопожатие.

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

ICAP

Секция передаёт трафик сервиса на проверку внешней DLP-системы по протоколу ICAP. Для неё нужен ICAP-сервер, созданный в этом же кластере: пока таких серверов нет, поле ICAP-сервер выбрать нельзя.

Секция доступна сервисам с протоколом TCP. Для сочетания TCP и HTTP, HTTPS или gRPC доступны все поля. Для TCP без прикладного протокола доступно только зеркалирование сырого потока: режим Синхронная проверка не предлагается, фильтр и Код ответа при блокировке не показываются. Для остальных протоколов флажок ICAP инспекция для сервера неактивен, под ним выводится подпись «ICAP доступен только для TCP без L7 либо TCP с HTTP/HTTPS/gRPC».

• ICAP инспекция для сервера — включает передачу трафика сервиса на проверку. При выключенном флажке остальные поля секции не отображаются.
• Режим инспекции — способ проверки:
  • Зеркалирование — копия запроса передаётся на проверку асинхронно, клиент не ожидает вердикта, трафик не изменяется;
  • Синхронная проверка — вердикт ожидается до отправки запроса клиентскому серверу, при блокировке тело запроса на сервер не передаётся. Доступна только для HTTP, HTTPS и gRPC.
• ICAP-сервер — профиль кластера, адреса проверки запросов и ответов берутся из него. В списке только включённые профили.
• Передавать ответы (RESPMOD) — добавляет проверку ответов клиентского сервера. Флажок доступен только в режиме Зеркалирование для HTTP, HTTPS и gRPC, и только если у выбранного профиля задан RESPMOD URL; иначе под флажком выводится подпись «В выбранном ICAP-профиле не задан RESPMOD URL».
• Порог полной передачи тела запроса, КБ — размер тела запроса, передаваемого в DLP-систему целиком, от 1 КБ, по умолчанию 102400. Тело крупнее порога не пропускается мимо проверки: DLP-система получает заголовки и начало тела, до 1 МБ. Превью DLP-система может уменьшить в ответе на OPTIONS, а на 100 Continue агент передаёт остаток сохранённой части. При неизвестном размере тела проверяется так же — заголовки и начало.
• Максимальный размер TCP-потока, КБ — объём данных сессии, передаваемых на проверку, от 1 КБ, по умолчанию 102400. Поле выводится вместо Порога полной передачи тела запроса, КБ и использует то же значение. По его достижении зеркалирование прекращается, а сессия продолжает передачу данных.
• Порог полной передачи тела ответа, КБ — размер тела ответа, накапливаемого для передачи на проверку, от 1 КБ, по умолчанию 102400. Ответ, превышающий порог, передаётся заголовками и началом, до 1 МБ и не больше самого порога. Поле показывается, когда включено Передавать ответы (RESPMOD).
• Код ответа при блокировке — код, который получает клиент при блокировке запроса в режиме Синхронная проверка: от 200 до 599, по умолчанию 403. Поле показывается только в этом режиме.
• ICAP таймаут, мс — время ожидания вердикта DLP-системы: от 1 до 60000, по умолчанию 1000. По истечении таймаута инспекция считается несостоявшейся.
• HTTP-методы — методы, которые попадают на проверку, например POST, PUT, PATCH. Список пуст — проверяются все методы. Поле доступно только для HTTP, HTTPS и gRPC.
• Content-Type — типы содержимого, которые попадают на проверку, например multipart/form-data, application/json. Список пуст — проверяются все типы.
• Только пути — пути, для которых выполняется проверка, например /upload, /api/documents. Список пуст — проверяются все пути.
• Исключить пути — пути, исключённые из проверки, например /health, /metrics. Список пуст — исключений нет. Путь, попавший в оба списка, исключается: Исключить пути имеет приоритет.

Условия фильтра объединяются логическим «И»: чтобы запись попала в проверку, она должна удовлетворять всем заполненным условиям. Пустой фильтр означает «проверять всё», а если заполнены оба поля — Только пути и HTTP-методы — в проверке остаются только записи, попадающие под оба условия одновременно.

Поведение проверки, состав передаваемых данных и метрики описаны в статье ICAP/DLP-анализ сервиса.

Аутентификация

Секция привязывает к сервису профиль аутентификации: балансировщик требует учётные данные на защищённых путях и передаёт клиентскому серверу имя пользователя и группы отдельными заголовками. Пока привязок нет, сервис открыт для всех.

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

• Привязки — список профилей, включённых на сервис. У каждой привязки заданы пути, разрешённые группы, вид отказа и адреса выхода. Порядок меняется перетаскиванием, привязки проверяются сверху вниз.
• Управление профилями — открывает список профилей аутентификации кластера в соседней вкладке браузера. Правки конфигурации при этом не теряются.
• Привязать профиль — добавляет привязку. В списке выбора показываются профили кластера, ещё не привязанные к этому сервису.

Настройка привязок описана в статье Аутентификация и авторизация сервиса.

Зеркалирование трафика

Секция отправляет копию запроса на приёмники для анализа, не влияя на ответ клиенту. Приёмником может быть внешняя система сбора трафика, средство проверки или система обнаружения вторжений.

Секция появляется только для сервисов с протоколом TCP и прикладным протоколом HTTP, HTTPS или gRPC: копия снимается с расшифрованного запроса, а в потоке UDP и в stream её взять неоткуда.

• Включение зеркалирования трафика — отправлять копии запросов на приёмники. Пока флажок не установлен, остальные поля секции не отображаются.

Приёмники — список адресов, которым уходят копии, не более 32 приёмников. Каждый приёмник получает независимую копию запроса.

• Название — имя приёмника для администратора, до 255 символов. На отправку не влияет.
• Адрес — адрес приёмника вида http://172.27.1.22:8080, до 2048 символов. Обязательное поле.

Адрес указывается без пути, параметров запроса и учётных данных: http://collector.example.ru:8080 верно, а http://collector.example.ru:8080/ingest?token=abc — нет. URI и параметры запроса зеркалируемого запроса приёмник получает из самой копии. Принимаются схемы http и https; имя сервера в адресе резолвится на стороне балансировщика.

Включённое зеркалирование без единого приёмника не сохранится — интерфейс потребует добавить хотя бы один адрес.

Отбор трафика ограничивает, какие запросы копируются. Пустой список означает отсутствие ограничения по этому признаку.

• HTTP-методы — методы отбираемых запросов: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. Пусто — любой метод.
• Content-Type — типы содержимого отбираемых запросов: application/json, application/xml, application/x-www-form-urlencoded, multipart/form-data, application/octet-stream, text/plain, text/html. Пусто — любой тип. Значение добавляется в список как есть, вместе с параметрами: application/json; charset=utf-8.
• Исключить пути — пути, которые не зеркалируются, например /health, /metrics. Сравнивается начало URI.
• Только пути — пути, которые зеркалируются, например /api, /upload. Пусто — все пути. Сравнивается начало URI.

Пути добавляют через запятую или клавишей Enter. Исключить пути имеет приоритет над Только пути: путь, попавший в оба списка, не зеркалируется. Так выключают фоновые запросы приложения, не теряя интереса к полезной нагрузке.

• Максимальный размер тела копии, КБ — предел размера тела одного зеркалируемого запроса, от 1 до 2147483646. Пусто — отдельный лимит сервиса не задаётся; применяется локальный лимит агента.

Действующий предел — наименьший из лимита сервиса и локального лимита агента. Тело крупнее действующего предела — зеркальная копия не отправляется, исходный запрос продолжает обрабатываться как обычно. Если приёмнику нужно тело целиком, задайте предел больше типичного запроса.