Балансировщики нагрузки
Балансировщик нагрузки служит для приема входящего трафика и передачи его на эндпоинты бэкендов. Маршрутизация запросов происходит по настройкам обработчиков балансировщика. Подача трафика на бэкенды настраивается в группах бэкендов.
Балансировщик хранит список эндпоинтов, куда должен направляться поступающий трафик и снимает TLS-шифрование перед отправкой трафика на бэкенды. При работе с TLS балансировщик использует современные протоколы (TLSv1.2, TLSv1.3) и шифры. Если балансировщик нагрузки будет обслуживать несколько доменов, можно сконфигурировать разные сертификаты и разные HTTP-роутеры для разных доменов, используя механизм TLS SNI.
Для удобства и безопасности можно использовать балансировщик вместе с сервисом Yandex Certificate Manager для хранения ваших TLS-сертификатов. Также можно задействовать сервисы Yandex Monitoring для мониторинга обработки запросов.
Группы безопасности
Примечание
Группы безопасности находятся на стадии Preview. Если они недоступны в вашей сети, для ресурсов будет разрешен весь входящий и исходящий трафик, и дополнительной настройки не требуется.
При создании балансировщика указываются группы безопасности — они содержат набор правил, по которым балансировщик получает входящий трафик и отправляет его на виртуальные машины бэкендов. Каждой ВМ также назначены группы безопасности.
Чтобы балансировщик работал корректно:
- Группы безопасности балансировщика должны разрешать:
- Получение внешнего входящего трафика на портах, указанных в обработчике. Например, для HTTP(S)-трафика — TCP-соединения на портах
80
и443
с любых адресов (CIDR —0.0.0.0/0
). - Получение входящего трафика для проверки состояния узлов балансировщика в разных зонах доступности — TCP-соединения на порте
30080
с IP-адресов из диапазонов198.18.235.0/24
и198.18.248.0/24
. - Отправку трафика на ВМ бэкендов. Например, любые исходящие соединения на внутренние адреса ВМ (CIDR —
<внутренний IP ВМ>/32
), в подсе́ти или группы безопасности, содержащие ВМ.
- Получение внешнего входящего трафика на портах, указанных в обработчике. Например, для HTTP(S)-трафика — TCP-соединения на портах
- Группы безопасности ВМ бэкендов должны разрешать получение входящего трафика от балансировщика на портах, указанных в группах бэкендов. Например, любые входящие соединения из подсетей, в которых расположен балансировщик, или хотя бы из одной из его групп безопасности.
Расположение балансировщика
При создании балансировщика указываются сеть и подсети в трех зонах доступности. В этих подсетях будут располагаться узлы балансировщика нагрузки. Трафик на бэкенды приложения будет поступать от узлов балансировщика в этих подсетях.
Балансировщик можно отключить в выбранных зонах доступности. В этом случае внешний трафик перестанет поступать на узлы балансировщика в этих зонах доступности. При этом узлы балансировщика в других зонах продолжат подавать трафик на бэкенды в зонах, где балансировщик был отключен, если настройки локализации трафика позволяют это.
Рекомендуемые размеры подсетей
Чтобы Application Load Balancer обеспечивал доступность балансировщика, как указано в документе об уровне обслуживания сервиса, в подсетях балансировщика должно быть доступно достаточное количество внутренних IP-адресов. Рекомендуется рассчитывать размер подсетей так, чтобы на каждую ресурсную единицу пикового потребления приходилось минимум по два свободных IP-адреса.
Например, балансировщик расположен в двух зонах доступности, на каждую из них в пиковые часы приходится:
- 6000 RPS;
- 30 000 одновременно активных соединений;
- 500 новых соединений в секунду;
- 20 МБ трафика в секунду.
Эти показатели соответствуют 8 ресурсным единицам (см. расчет) в каждой зоне доступности. Значит, в каждой подсети рекомендуется иметь хотя бы 8 × 2 = 16 свободных адресов. Желательно указать для балансировщика подсети размером не меньше /27.
Обработчик
Обработчик определяет, на каких портах, адресах и по каким протоколам балансировщик будет принимать трафик.
Принципы маршрутизации запросов к группам бэкендов зависят от типа обработчика:
- HTTP: балансировщик принимает HTTP- или HTTPS-запросы и распределяет их между группами бэкендов по правилам, описанным в HTTP-роутерах, либо перенаправляет HTTP-запросы на HTTPS. Группы бэкендов, получающие трафик, должны иметь тип HTTP или gRPC.
- Stream: балансировщик принимает входящий трафик в открытых или зашифрованных TCP-соединениях и транслирует его группам бэкендов типа Stream.
Если обработчик принимает зашифрованный трафик, для него настраиваются основной обработчик и необязательные обработчики SNI. В каждом обработчике SNI доменному имени, указанному при установке TLS-соединения как Server Name Indication (SNI), сопоставляются TLS-сертификат и HTTP-роутер (если тип обработчика — HTTP) либо группа бэкендов (если тип обработчика — Stream). Основной обработчик отвечает за TLS-соединения с доменными именами, которым не соответствует ни один обработчик SNI.
Примечание
В обработчике типа HTTP можно указывать (через HTTP-роутеры) только группы бэкендов типов HTTP и gRPC, в обработчике типа Stream — только группы бэкендов типа Stream.
Один балансировщик может обслуживать и обычный, и шифрованный трафик на разных портах, а также иметь публичные и внутренние IP-адреса на разных обработчиках.
Пример
Обработчик может описывать прием HTTP-трафика на 80-м порту и делать перенаправление на 443 порт и протокол HTTPS. Обработчик получит HTTP-запрос от клиента и вернет ответ с HTTP-кодом 302. Дальнейшие запросы будут поступать уже на порт 443 по протоколу HTTPS.
Если используется HTTPS-обработчик, то необходимо указать сертификат из Certificate Manager который будет использоваться для терминирования TLS.
Статистика
Статистика работы балансировщика автоматически записывается в метрики сервиса Yandex Monitoring. Доступны следующие показатели:
- RPS — количество запросов к балансировщику в секунду (requests per second).
- 4XX, 5XX — количество ответов балансировщика с HTTP-кодами 4XX и 5XX и соответствующими им gRPC-кодами в секунду.
- Request size — суммарный объем запросов к балансировщику в секунду.
- Response size — суммарный объем ответов балансировщика в секунду.
- Latency — задержка ответа (время от получения балансировщиком первого байта запроса до отправки последнего байта ответа), от 50-го до 99-го перцентиля.
В Application Load Balancer доступна обобщенная статистика балансировщика. В Yandex Monitoring можно смотреть статистику с разбивкой по ресурсам, привязанным к балансировщику (HTTP-роутерам, виртуальным хостам, маршрутам и т. д.), а также создавать алерты.
Инструкции по просмотру статистики см. в разделе Посмотреть статистику L7-балансировщика.
Логирование
При создании балансировщика для него создается лог-группа в Yandex Cloud Logs, в которую записываются сообщения о входящих запросах. Логи можно посмотреть в консоли управления. Полный список параметров представлен в справочнике логов.
Настроить обработку логов можно с помощью Yandex Cloud Functions. Для этого нужно создать триггер для Cloud Logs с идентификатором лог-группы и функцию, вызываемую триггером, с логикой обработки сообщений.
Важно
Сейчас получить идентификатор лог-группы балансировщика и создать триггер с этим идентификатором можно только через CLI или API Yandex Cloud.
Пример обработки логов см. в сценарии Запись логов балансировщика в PostgreSQL.