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

Балансировщик нагрузки служит для приема входящего трафика и передачи его на эндпоинты бэкендов. Маршрутизация запросов происходит по настройкам обработчиков балансировщика. Подача трафика на бэкенды настраивается в группах бэкендов.

Балансировщик хранит список эндпоинтов, куда должен направляться поступающий трафик и снимает TLS-шифрование перед отправкой трафика на бэкенды. При работе с TLS балансировщик использует современные протоколы (TLSv1.2, TLSv1.3) и шифры. Если балансировщик нагрузки будет обслуживать несколько доменов, можно сконфигурировать разные сертификаты и разные HTTP-роутеры для разных доменов, используя механизм TLS SNI.

Для удобства и безопасности можно использовать балансировщик вместе с сервисом Yandex Certificate Manager для хранения ваших TLS-сертификатов. Также можно задействовать сервисы Yandex Monitoring для мониторинга обработки запросов.

Группы безопасностиГруппы безопасности

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

Чтобы балансировщик работал корректно:

• Группы безопасности балансировщика должны разрешать:

  • Получение внешнего входящего трафика на портах, указанных в обработчике. Например, для HTTP(S)-трафика — TCP-соединения на портах 80 и 443 с любых адресов (CIDR — 0.0.0.0/0).
  • Получение входящего трафика для проверки состояния узлов балансировщика в разных зонах доступности — TCP-соединения на порте 30080 с источником Проверки состояния балансировщика.
  • Отправку трафика на ВМ бэкендов — виртуальные машины, IP-адреса которых включены в целевые группы. Например, любые исходящие соединения на внутренние адреса ВМ (любой протокол, весь диапазон портов, CIDR — <внутренний_IP-адрес_ВМ>/32).

  Примечание

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

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

О том, как настроить группы безопасности для Ingress-контроллера и Gateway API, см. в разделе Настройка групп безопасности для инструментов Application Load Balancer для Managed Service for Kubernetes.

Расположение балансировщика и его внутренние IP-адресаРасположение балансировщика и его внутренние IP-адреса

При создании балансировщика указываются сеть и подсети в зонах доступности. В этих подсетях будут располагаться узлы балансировщика нагрузки. Трафик на бэкенды приложения будет поступать от узлов балансировщика в этих подсетях.

О рекомендуемом размере подсетей для балансировщика см. ниже.

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

Внутренние IP-адресаВнутренние IP-адреса

Балансировщик резервирует внутренние IP-адреса в указанных подсетях и назначает адреса своим узлам. Эти адреса используются для связи между узлами балансировщика и бэкендами. IP-адреса узлов отображаются в списке внутренних адресов.

Чтобы нагрузка корректно распределялась на бэкенды, добавьте разрешение на входящий трафик из подсетей, в которых находятся узлы балансировщика:

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

Например, балансировщик использует подсети с CIDR 10.0.1.0/24 и 10.0.2.0/24, а бэкенды принимают трафик на порт 8080. Тогда, чтобы разрешить трафик от узлов балансировщика, потребуется два правила:

Направление трафика	Диапазон портов	Протокол	Источник	CIDR блоки
Входящий	8080	TCP	CIDR	10.0.1.0/24
Входящий	8080	TCP	CIDR	10.0.2.0/24

Автомасштабирование и ресурсные единицыАвтомасштабирование и ресурсные единицы

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

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

• 1000 запросов в секунду (RPS);
• 4000 одновременно активных соединений;
• 300 новых соединений в секунду;
• 22 МБ (176 Мбит) трафика в секунду.

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

Например, рассмотрим следующую нагрузку:

• 6000 RPS;
• 29 000 одновременно активных соединений;
• 750 новых соединений в секунду;
• 20 МБ трафика в секунду.

Эти показатели соответствуют 8 ресурсным единицам:

• 6000 / 1000 = 6 — количество ресурсных единиц, рассчитанное на 6000 RPS.
• 29 000 / 4000 = 7,25 ~ 8 — количество единиц, рассчитанное на 30 000 активных соединений.
• 750 / 300 = 2,5 ~ 3 — количество единиц, рассчитанное на 750 новых соединений.
• 20 / 22 = 0,9090... ~ 1 — количество единиц, рассчитанное на 20 МБ трафика в секунду.

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

От количества ресурсных единиц зависит стоимость использования балансировщика. Подробнее см. в разделе Правила тарификации для Yandex Application Load Balancer.

Настройки автомасштабированияНастройки автомасштабирования

В настройках балансировщика вы можете указать:

Минимальное количество ресурсных единиц в каждой зоне доступности

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

По умолчанию минимум равен 2. Указать минимальное значение меньше 2 нельзя.

Максимальное суммарное количество ресурсных единиц

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

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

Значение должно быть не меньше, чем количество зон доступности балансировщика, умноженное на минимальное количество ресурсных единиц в каждой зоне.

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

Рекомендуемые размеры подсетейРекомендуемые размеры подсетей

Чтобы Application Load Balancer обеспечивал доступность балансировщика, как указано в документе об уровне обслуживания сервиса, в подсетях балансировщика должно быть доступно достаточное количество внутренних IP-адресов. Рекомендуется рассчитывать размер подсетей так, чтобы на каждую ресурсную единицу пикового потребления приходилось минимум по два свободных IP-адреса.

Например, если балансировщик использует в каждой зоне доступности 8 ресурсных единиц, как в примере, то в каждой подсети рекомендуется иметь хотя бы 8 × 2 = 16 свободных адресов. Для балансировщика желательно указать подсети размером не меньше /27.

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

Обработчик определяет, на каких портах, адресах и по каким протоколам балансировщик будет принимать трафик.

Некоторые входящие порты, например порт 22, зарезервированы для служебных целей, использовать их нельзя.

Принципы маршрутизации запросов к группам бэкендов зависят от типа обработчика:

• HTTP: балансировщик принимает HTTP- или HTTPS-запросы и распределяет их между группами бэкендов по правилам, описанным в HTTP-роутерах, либо перенаправляет HTTP-запросы на HTTPS. Группы бэкендов, получающие трафик, должны иметь тип HTTP или gRPC.
• Stream: балансировщик принимает входящий трафик в открытых или зашифрованных TCP-соединениях и транслирует его группам бэкендов типа Stream.

Если обработчик принимает зашифрованный трафик, для него настраиваются основной обработчик и необязательные обработчики SNI. В каждом обработчике SNI доменному имени, указанному при установке TLS-соединения как Server Name Indication (SNI), сопоставляются TLS-сертификат и HTTP-роутер (если тип обработчика — HTTP) либо группа бэкендов (если тип обработчика — Stream). Основной обработчик отвечает за TLS-соединения с доменными именами, которым не соответствует ни один обработчик SNI.

Один балансировщик может обслуживать и обычный, и шифрованный трафик на разных портах, а также иметь публичные и внутренние IP-адреса на разных обработчиках.

ПримерПример

Обработчик может описывать прием HTTP-трафика на 80-м порту и делать перенаправление на 443 порт и протокол HTTPS. Обработчик получит HTTP-запрос от клиента и вернет ответ с HTTP-кодом 302. Дальнейшие запросы будут поступать уже на порт 443 по протоколу HTTPS.

Если используется HTTPS-обработчик, то необходимо указать сертификат из Certificate Manager который будет использоваться для терминирования TLS.

СтатистикаСтатистика

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

• HTTP-статистика:

  • RPS — количество запросов к балансировщику в секунду (requests per second).
  • 4XX, 5XX — количество ответов балансировщика с HTTP-кодами 4XX и 5XX и соответствующими им gRPC-кодами в секунду.
  • Request size — суммарный объем запросов к балансировщику в секунду.
  • Response size — суммарный объем ответов балансировщика в секунду.
  • Latency — задержка ответа (время от получения балансировщиком первого байта запроса до отправки последнего байта ответа), от 50-го до 99-го перцентиля.

• Статистика масштабирования:

  • Active connections — количество активных соединений.
  • Connections per second — количество соединений в секунду.
  • Requests per second — количество запросов в секунду.
  • Bytes per second — объем обрабатываемых данных в секунду.

Полный список метрик, передаваемых в Yandex Monitoring, представлен в справочнике.

В Application Load Balancer доступна обобщенная статистика балансировщика. В Monitoring можно смотреть статистику с разбивкой по ресурсам, привязанным к балансировщику (HTTP-роутерам, виртуальным хостам, маршрутам и т. д.), а также создавать алерты.

Инструкции по просмотру статистики см. в разделе Посмотреть статистику L7-балансировщика.

ЛогированиеЛогирование

Вы можете настроить поставку логов балансировщика в лог-группу Yandex Cloud Logging.

Подробности о просмотре логов см. в Посмотреть логи L7-балансировщика.

Полный список сохраняемых параметров представлен в справочнике логов.

Также вы можете передавать логи балансировщика в БД PostgreSQL.

Правила отбрасывания логовПравила отбрасывания логов

Запись и хранение логов в Cloud Logging тарифицируются согласно правилам сервиса. Чтобы записывать меньше логов, добавьте правила их отбрасывания.

Доступные правила:

Правило	Значение
HTTP-коды	100 — Continue 101 — Switching Protocol 102 — Processing 200 — OK 201 — Created 202 — Accepted 203 — Non Authoritative Information 204 — No Content 205 — Reset Content 206 — Partial Content 207 — Multi-Status 300 — Multiple Choices 301 — Moved Permanently 302 — Found 303 — See Other 304 — Not Modified 305 — Use Proxy 307 — Temporary Redirect 308 — Permament Redirect 400 — Bad Request 401 — Unauthorized 402 — Payment Required 403 — Forbidden 404 — Not Found 405 — Method Not Allowed 406 — Not Acceptable 407 — Proxy Authentication Required 408 — Request Timeout 409 — Conflict 410 — Gone 411 — Length Required 412 — Precondition Failed 413 — Request Entity Too Large 414 — Request-URI Too Long 415 — Unsupported Media Type 416 — Requested Range Not Satisfiable 417 — Expectation Failed 418 — I'm a teapot 419 — Insufficient Space on Resource 420 — Method Failure 422 — Unprocessable Entity 423 — Locked 424 — Failed Dependency 428 — Precondition Required 429 — Too Many Requests 431 — Request Header Fields Too Large 451 — Unavailable For Legal Reasons 500 — Inernal Server Error 501 — Not Implemented 502 — Bad Gateway 503 — Service Unavailable 504 — Gateway Timeout 505 — HTTP Version Not Supported 507 — Insufficient Storage 511 — Network Authentication Required
Классы HTTP-кодов	1XX 2XX 3XX 4XX 5XX ALL
gRPC-коды	GRPC_OK GRPC_CANCELLED GRPC_UNKNOWN GRPC_INVALID_ARGUMENT GRPC_DEADLINE_EXCEEDED GRPC_NOT_FOUND GRPC_ALREADY_EXISTS GRPC_PERMISSION_DENIED GRPC_UNAUTHENTICATED GRPC_RESOURCE_EXHAUSTED GRPC_FAILED_PRECONDITION GRPC_ABORTED GRPC_OUT_OF_RANGE GRPC_UNIMPLEMENTED GRPC_INTERNAL GRPC_UNAVAILABLE

Примеры использованияПримеры использования

• Организация виртуального хостинга
• Создание балансировщика с защитой от DDoS
• Создание L7-балансировщика Application Load Balancer с профилем безопасности Yandex Smart Web Security
• Миграция сервисов с балансировщика NLB на L7-балансировщик ALB для защиты от DDoS-атак с помощью Yandex Smart Web Security
• Настройка L7-балансировщика Yandex Application Load Balancer с помощью Ingress-контроллера
• Отказоустойчивый сайт с балансировкой нагрузки через Yandex Application Load Balancer с помощью консоли управления
• Проверка состояния приложений в кластере Yandex Managed Service for Kubernetes с помощью L7-балансировщика Yandex Application Load Balancer
• Запись логов балансировщика в PostgreSQL
• Настройка логирования для L7-балансировщика Yandex Application Load Balancer с помощью Ingress-контроллера