Решение

Выберите правильный алгоритм для каждой рабочей нагрузки

От классического round-robin до Maglev hashing и фирменного двухступенчатого движка Fastest+ от TR7 — 14 алгоритмов в комплекте

Разные рабочие нагрузки требуют разной логики маршрутизации. Однородный vService из идентичных веб-серверов? Round-robin. Долгоживущие сессии, где важна ёмкость? Least-connections. Сценарии с кэш-аффинностью? Consistent hash или Maglev. Разнородное оборудование или переменная нагрузка? Fastest+. TR7 ADC поставляет каждый стандартный алгоритм — плюс три современных hash-варианта и один фирменный движок — выбираемых per vService, переключаемых без перезапуска.

критериев выбора Layer 7

планировщиков Layer 4

per vService

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

Почему паттерны трафика требуют разных алгоритмов

Каждый классический алгоритм опирается на допущение о vService, которому он служит. Round-robin считает бэкенды взаимозаменяемыми. Least-connections считает, что количество сессий коррелирует с нагрузкой на бэкенд. Source-IP предполагает привязку пользователя к бэкенду без явной персистентности. Cache-affinity хэши считают, что ключ запроса — URL, заголовок или сессия — стабилен. Когда допущение справедливо, алгоритм даёт правильный ответ.

Трудные случаи — когда допущения перестают работать: бэкенды «дрейфуют» по производительности в течение рабочего дня, поколения оборудования смешиваются при rolling-обновлении, региональная задержка меняется от запроса к запросу, или у рабочей нагрузки есть пиковые тяжёлые запросы, не коррелирующие с числом запросов. В таких сценариях выбор реально самого быстрого бэкенда для каждого запроса — или использование hash-алгоритма, поглощающего изменения бэкендов без перераспределения всего — сохраняет видимую пользователю задержку.

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

Выбор алгоритма, per vService

vService в TR7 объединяет frontend-слушатель, правила трафика, проверки работоспособности и группу бэкендов в единый объект конфигурации — шире, чем классическая концепция pool, разносящая эти компоненты по разным местам. Каждый vService выбирает собственный алгоритм из выпадающего списка — без пересборки, без перезапуска. Комбинируйте на одном экземпляре TR7: round-robin на vService статических ресурсов, Fastest+ на vService API, Maglev hash на vService кэш-уровня. Фильтрация по типу сервиса происходит автоматически; UI показывает только алгоритмы, подходящие для протокола vService.

Алгоритм per vService

Выбор алгоритма живёт в объекте vService, а не в глобальной конфигурации ADC. Разные vService работают с разными алгоритмами на одном экземпляре TR7.

Фильтрация с учётом протокола

UI показывает только алгоритмы, имеющие смысл для протокола vService — HTTP, TCP или сетевые vService каждый получают свой подмножество, никаких догадок оператора.

Совместим с персистентностью сессий

Алгоритм выбирает бэкенд для первого запроса; персистентность сессий затем закрепляет последующие запросы того же пользователя. Оба уровня настраиваются независимо per vService.

Горячая замена (без перезапуска)

Измените алгоритм на работающем vService — трафик немедленно перейдёт на новую логику. Перезапуск сервиса не нужен, drain соединений не требуется.

14 алгоритмов в составе TR7 ADC

Каждый классический алгоритм, два современных варианта consistent hash, один алгоритм наименьшей задержки, плюс фирменный движок Fastest+ от TR7. Все доступны per vService — выбираются из выпадающего списка, конфигурационный код не нужен.

Round-robin (взвешенный + статический)

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

Least-connections (взвешенный)

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

Наименьшее время отклика

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

Наименьшая полоса

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

First-available

Всегда маршрутизирует к первому в списке бэкенду с ёмкостью; переходит к следующему только при перегрузке. Полезен для упорядочивания бэкендов «горячий → холодный» или поэтапных развёртываний.

Random

Случайный выбор среди здоровых бэкендов. Без состояния, статистически равномерен — полезен для больших однородных vService. Поддерживает power-of-two random для выбора наименее загруженного с минимальными накладными расходами.

Source-IP hash

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

URL hash (URI / URL-параметр)

Хэш по компоненту URL — длине URL, пути URI или конкретному query-параметру (например, ?user_id). Маршрутизирует один и тот же URL или пользователя к одному бэкенду для кэш-аффинности.

Header hash

Хэш по пользовательскому HTTP-заголовку. Полезен для мультитенантной маршрутизации (заголовок tenant-id), feature-флагов или A/B-тестирования.

RDP cookie hash

Считывает cookie RDP-сессии для выбора бэкенда. Полезен для RDP-шлюзов и ферм удалённых рабочих столов, где требуется сессионная аффинность.

Consistent hash

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

Maglev hash

Алгоритм consistent-хэширования от Google, созданный для программных балансировщиков нагрузки в масштабе. Меньший разброс, чем у классического consistent hash, детерминированный по репликам. Отлично подходит для stateless-сервисов, которым нужна предсказуемая привязка к бэкенду.

SED — Shortest Expected Delay

Маршрутизирует к бэкенду с наименьшим ожидаемым временем ожидания, учитывая активные соединения и вес per бэкенд. Латентно-осознанная альтернатива least-connections, когда ёмкости бэкендов существенно различаются.

Fastest

Маршрутизирует к бэкенду с наименьшим недавним временем отклика. Более простой латентно-осознанный вариант, когда время отклика — единственный значимый сигнал.

Fastest+

Фирменный двухступенчатый движок TR7. Оператор выбирает два из восьми живых сигналов сервиса — время отклика, время соединения, заполненность очереди, частоту ошибок и другие; Fastest+ по первичному сигналу сужает круг кандидатов, а вторичным сигналом разделяет оставшихся в равенстве. Подробности см. в разделе деталей ниже.

Fastest+ — двухступенчатый движок TR7, настраиваемый оператором

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

Время отклика

Средняя задержка отклика от бэкенда, сэмплируется непрерывно. Основной сигнал — бэкенд, у которого увеличивается время ответа, немедленно опускается в рейтинге.

Время соединения

Время установки TCP/TLS-соединения. Бэкенд, у которого растёт время соединения, приближается к насыщению — даже если время отклика ещё выглядит нормально.

Время в очереди

Время, которое запросы проводят в очереди до достижения бэкенда. Рост времени в очереди — самый ранний признак того, что бэкенд не справляется.

Активные сессии

Текущие открытые сессии per бэкенд. Маршрутизация с учётом ёмкости без шума от исторических итогов.

Глубина активной очереди

Запросы, ожидающие в данный момент. Бэкенд с 0 в очереди предпочтительнее одинаково быстрого с 50 ожидающими.

Ошибки соединений

Недавние неудачные соединения. Бэкенд, отклонивший 3 из последних 10 попыток, опускается в рейтинге раньше, чем это заметит проверка работоспособности.

Прерывания на стороне сервера

Прерывания сессий, инициированные бэкендом в недавнем окне. Фиксирует случай, когда бэкенд жив, но отказывает на полпути.

Использованные соединения

Утилизация пула соединений — насколько близко к ёмкости keep-alive пул каждого бэкенда. Обнаруживает исчерпание пула до того, как оно станет заметно пользователю.

ДВА УРОВНЯ, ОДНА ПОЛИТИКА

Четырнадцать на Layer 7, одиннадцать на уровне пакетов

На Layer 7 решение принимается по содержимому запроса: заголовок, путь, cookie, живое время отклика. На Layer 4 — по пакету, ещё до того как трафик поднимется на прикладной уровень: именно там максимальная пропускная способность. В обоих случаях алгоритм выбирается для каждой службы и меняется на работающем устройстве.

Layer 7 — 14 критериев выбора

Round robin — по очереди, со взвешиванием или строго поровну

Взвешенный round robin — разница в ёмкости учитывается

Наименьшее число соединений — побеждает наименее занятый

Наименьшее время отклика — кто отвечает быстрее прямо сейчас

Наименьшая полоса — кто передаёт меньше всего трафика сейчас

Первый доступный — заполнить один сервер, прежде чем трогать следующий

Случайный — статистически ровно, без состояния

Fastest — один живой сигнал, побеждает минимум

Fastest+ — два живых сигнала: первый сужает, второй разрешает ничью

IP источника — тот же клиент, тот же сервер

URI — тот же путь, тот же сервер; кэш остаётся горячим

Параметр URL — маршрутизация по значению в строке запроса

Заголовок — по любому заголовку, включая ваш собственный

Cookie RDP — сессии рабочего стола попадают на свой брокер

Layer 4 — 11 планировщиков на уровне пакетов

rr — round robin

wrr — взвешенный round robin

lc — наименьшее число соединений

wlc — взвешенное наименьшее число соединений

lblc — наименьшее число соединений с учётом локальности

lblcr — то же с репликацией

sh — хеш источника

dh — хеш назначения

sed — кратчайшая ожидаемая задержка

nq — никогда не ставить в очередь

mh — хеш Maglev: минимум перераспределений при изменении пула

Когда каждый алгоритм себя проявляет

Однородные vService

Идентичные бэкенды, одинаковая ёмкость — round-robin сохраняет простоту математики и симметрию нагрузки. Добавьте random для больших stateless vService.

Долгоживущие сессии

WebSocket'ы, стриминговые сервисы, видеозвонки — сессии остаются открытыми минутами или часами. Least-connections или SED отслеживают активную нагрузку значительно лучше, чем счётчик запросов.

vService кэш-уровня

Ротация бэкендов не должна инвалидировать весь кэш. Consistent hash или Maglev перераспределяет лишь малую долю ключей при изменении бэкендов.

Разнородная или переменная нагрузка

Смешанное оборудование, rolling-развёртывания, региональный разброс задержек — Fastest+ оценивает бэкенды вживую, так что маршрутизация выбирает реально самый быстрый, а не теоретически лучший.

Часто задаваемые вопросы

Могу ли я изменить алгоритм без перезапуска сервиса?

Да. Алгоритм — это выпадающий список per vService. Измените его на работающем vService, и трафик немедленно перейдёт на новую логику — перезапуск сервиса не нужен, drain соединений не требуется.

Как Fastest+ соотносится с least-connections?

Least-connections высокоэффективен для многих vService — особенно для долгоживущих сессий, где число сессий тесно коррелирует с нагрузкой на бэкенд. Fastest+ расширяет картину, позволяя выбрать из восьми живых сигналов — заполненность очереди, недавнее время отклика, время соединения, частоту ошибок и другие — и решать на основе двух из них в двухступенчатом выборе. Сценарии использования различаются: least-connections часто является правильным выбором для однородных vService с предсказуемыми паттернами сессий; Fastest+ проявляет себя там, где число сессий не отражает реальную загрузку бэкенда — переменное время запросов, смешанные поколения оборудования или rolling-развёртывания.

Как выбрать между Consistent hash и Maglev hash?

Оба минимизируют перераспределение при изменении бэкендов. Consistent hash — классический алгоритм, простой, предсказуемый, хорошо изученный. Maglev — вариант Google, созданный для программных балансировщиков нагрузки в масштабе — меньший разброс в распределении нагрузки, детерминированный по репликам. Для большинства рабочих нагрузок consistent hash достаточен; выбирайте Maglev, когда нужна строгая равномерность нагрузки или когда несколько экземпляров TR7 должны согласованно маршрутизировать.

Что SED делает того, чего не делает least-connections?

SED (Shortest Expected Delay) учитывает и активные соединения, и вес per бэкенд, чтобы оценить, какой бэкенд быстрее всего ответит на следующий запрос. Это улучшение взвешенного least-connections — полезно, когда ёмкости бэкендов существенно различаются и вы хотите, чтобы маршрутизация это учитывала, без полной сложности Fastest+.

Требует ли выбор алгоритма внешнего мониторинга или интеграции APM?

Нет. Все сигналы — включая каждый вход Fastest+ — измеряются TR7 из трафика, который он уже проксирует. Никакого агента, никакого APM-хука, никакого внешнего конвейера метрик.

Какой алгоритм используется по умолчанию?

Round-robin — вариант по умолчанию для обратной совместимости с существующими развёртываниями. Переключение на другой алгоритм — это изменение одного выпадающего списка в конфигурации vService.

Сопоставьте алгоритм с рабочей нагрузкой

Посмотрите, как TR7 ADC позволяет задавать алгоритм per vService — и как Fastest+ справляется с рабочими нагрузками, с которыми другие не справляются.