Группы бэкендов

Группа бэкендов определяет настройки, на основании которых L7-балансировщик будет подавать трафик на эндпоинты бэкендов:

• протокол для соединения с экземплярами приложения;
• настройки проверок состояния эндпоинтов;
• правила распределения трафика между эндпоинтами.

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

Если группа бэкендов используется хотя бы в одном HTTP-роутере или балансировщике, удалить ее нельзя. Сначала удалите ее из всех HTTP-роутеров и балансировщиков.

Типы групп бэкендовТипы групп бэкендов

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

• HTTP — HTTP- или HTTPS-трафик.
• gRPC — HTTP- или HTTPS-трафик с вызовами gRPC-процедур.
• Stream — TCP-трафик без шифрования или с TLS-шифрованием.

Группы типов HTTP и gRPC подключаются к обработчикам типа HTTP через HTTP-роутеры, группы типа Stream — к обработчикам типа Stream напрямую.

Бэкендам типа Stream по умолчанию доступен только IP-адрес балансировщика. Чтобы дополнительно передавать в бэкенд IP-адрес клиента и другие метаданные, включите протокол PROXY от HAProxy в настройках бэкенда. Подробнее см. Создать группу бэкендов.

Типы бэкендовТипы бэкендов

В зависимости от типа группы бекендов определяются возможные типы бекендов:

• HTTP:

  • Целевые группы — набор IP-адресов виртуальных машин Compute Cloud, на которых запущены ваши сетевые приложения. К одному бэкенду может относится несколько целевых групп. Трафик между всеми ВМ из целевых групп, относящихся к одному бэкенду, распределяется равномерно с учетом настроек бэкенда и результатов проверок состояния.

  • Бакет Yandex Object Storage — набор файлов (объектов) и настроек, связанных с их хранением.

    Важно

    Чтобы бакет можно было использовать в качестве бэкенда, откройте публичный доступ к списку объектов в бакете и к их чтению.

  В группе бэкендов HTTP вы можете одновременно использовать бэкенды обоих типов.

• gRPC и Stream — только целевые группы. К одному бэкенду может относится несколько целевых групп.

Привязка сессий (session affinity)Привязка сессий (session affinity)

Чтобы запросы в рамках одной пользовательской сессии обрабатывал один и тот же эндпоинт бэкенда, вы можете включить для группы бэкендов привязку сессий (session affinity).

Режим привязки сессий определяет, как входящие запросы группируются в одну сессию. Для групп бэкендов типов HTTP и gRPC доступны следующие режимы:

• По IP-адресу: в сессию объединяются запросы, полученные с одного IP-адреса.

• По HTTP-заголовку: в сессию объединяются запросы с одинаковым значением указанного HTTP-заголовка, например с аутентификационными данными пользователя.

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

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

Для групп типа Stream доступна только привязка сессий по IP-адресу клиента.

Настройки протокола и балансировкиНастройки протокола и балансировки

Для бэкендов, состоящих из целевых групп, можно настроить:

• протокол коммуникации с балансировщиком;
• балансировку трафика между эндпоинтами.

ПротоколПротокол

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

Если тип группы бэкендов — HTTP, для обмена данными между балансировщиком и эндпоинтами бэкенда можно выбрать версию протокола HTTP: 1.1 или 2. Группы бэкендов типа gRPC поддерживают только HTTP/2-соединения.

Режим балансировкиРежим балансировки

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

• ROUND_ROBIN: все эндпоинты будут получать запросы по очереди. Когда все эндпоинты получили по одному запросу, снова наступает очередь первого эндпоинта, и т. д.

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

• LEAST_REQUEST: запросы распределяются исходя из нагрузки эндпоинтов по алгоритму power of two random choices. Среди всех эндпоинтов бэкенда случайным образом выбираются два, и запрос получает тот из них, который работает с меньшим количеством соединений. Алгоритм позволяет снизить нагрузку на самый загруженный эндпоинт бэкенда. Подробнее о работе и эффективности алгоритма см. статью The Power of Two Random Choices: A Survey of Techniques and Results (Mitzenmacher et al.).

• MAGLEV_HASH: запросы распределяются по алгоритму Maglev hashing.

  1. Для каждого эндпоинта вычисляется значение хеш-функции — от 0 до 65536.
  2. В соответствии с вычисленными значениями хеш-таблица из 65 537 строк полностью заполняется так, чтобы каждому эндпоинту соответствовало одинаковое количество строк.
  3. Для каждого входящего запроса балансировщик вычисляет значение той же хэш-функции и находит в хэш-таблице строку с соответствующим номером. Эта строка указывает на эндпоинт, который будет обрабатывать запрос. Если для группы бэкендов включена привязка сессий, то в зависимости от режима привязки хэш-функция вычисляется от IP-адреса клиента, значения HTTP-заголовка или файла cookie.

  Подробнее о работе и эффективности алгоритма Maglev hashing см. статью Maglev: A Fast and Reliable Software Network Load Balancer (Eisenbud et al.; глава 3.4).

  Примечание

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

Режим паникиРежим паники

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

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

Локализация трафикаЛокализация трафика

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

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

Проверки состоянияПроверки состояния

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

Поддерживаются проверки типов HTTP, gRPC и Stream. Они соответствуют типам групп бэкендов, но тип проверки не обязан совпадать с типом группы.

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

• Таймаут — время ожидания ответа.

• Интервал — интервал времени между проверочными запросами.

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

• Настройки HTTP-проверок:

  • Доменное имя для заголовка Host (HTTP/1.1) или псевдозаголовка :authority (HTTP/2).
  • Путь в URI запроса к эндпоинту.
  • Флаг использования протокола HTTP/2.

• Настройки gRPC-проверок:

  • Имя проверяемого сервиса.

• Настройки Stream-проверок (TCP):

  • Тело запроса.
  • Подстрока в ответе, которая будет означать успешное прохождение проверки. Если тело запроса или ответа не указано, будет проверяться успех соединения с бэкендом.

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

• если используется HTTP-проверка, она будет происходить по протоколу HTTPS;

• для Stream-проверок будет установлено TLS-соединение, и результаты проверок будут возвращаться через это соединение.

См. такжеСм. также

• Рекомендации по настройке проверок состояния Yandex Application Load Balancer