Когда балансировка нагрузки ломает сессии
Round-robin по замыслу отправляет каждый запрос на разный backend. Для stateless-сервисов это идеально. Но как только пользователь входит в систему, наполняет корзину или начинает удалённый рабочий стол, приложение начинает хранить состояние на одном конкретном backend. Если запрос №2 попадёт на другой — пользователь увидит пустую корзину, экран выхода из системы или зависшую RDP-сессию.
Персистентность сессий (или «affinity») решает это, закрепляя пользователя за выбранным backend на время сессии. Загвоздка в том, что нет единственно верного способа привязки. Source-IP работает для пользователей с уникальными IP, но ломается за корпоративным NAT. Cookie работают в браузерах, но не для raw TCP. URL-parameter hash работает для stateless URL, но не для user-scoped потоков. Каждый метод правильный в своём контексте.
Ответ — поставлять все методы и выбирать per vService.
Выберите метод персистентности, per vService
Каждый vService выбирает метод персистентности из выпадающего списка — наряду с алгоритмом балансировки нагрузки. Оба слоя независимы: выберите Fastest+ для выбора backend и TR7 cookie для affinity, или round-robin с source-IP, или любую комбинацию под нагрузку. Выбор метода — горячая замена, без перезапуска.
9 методов в комплекте
Пять самоперсистентных алгоритмов балансировки (source, URI, URL-param, header, RDP-cookie) плюс четыре явных метода персистентности (TR7 cookie, backend cookie, dynamic, SAM). Охватывают все распространённые случаи.
SAM — полный контроль над cookie
Session Affinity Manager позволяет задать источник cookie (генерируется TR7 или backend), формат сессии (UUID, IP-timestamp-random, IP-random, custom) и флаги безопасности (HttpOnly, Secure, SameSite=Strict/Lax) — без изменений в коде backend.
Компонуется с любым алгоритмом ADC
Персистентность работает поверх алгоритма балансировки нагрузки: алгоритм выбирает backend для первого запроса, персистентность закрепляет остальные. Fastest+ для cold-start, sticky cookie для сессии — работает вместе.
Горячая замена (без перезапуска)
Измените метод персистентности на работающем vService — новые сессии немедленно примут новый метод. Существующие закреплённые сессии продолжатся без прерывания до истечения.
9 методов персистентности сессий в комплекте
Выберите метод, подходящий для протокола, популяции клиентов и модели сессий приложения. Все 9 доступны per vService — без кода, без плагина. Девять — это число именованных методов: метод динамического хеша строит ключ из языка выражений, поэтому набор ключей, по которым можно закреплять сессию, девятью не ограничен.
Source-IP
Один и тот же клиентский IP всегда попадает на один и тот же backend. Простой, без кода, работает для любого протокола. Оптимален когда клиентские IP разнообразны — ломается за общим NAT или корпоративными прокси.
URI-length hash
Хэш по длине URL распределяет нагрузку по сложности URL, закрепляя идентичные URL на одном backend. Полезен для сценариев с cache-affinity.
URL-parameter hash
Хэш по конкретному query-параметру (например ?user_id, ?session_token). Маршрутизирует один и тот же user-scoped запрос на один backend без использования cookie.
Header hash
Хэш по пользовательскому HTTP-заголовку. Полезен когда upstream вставляет tenant или correlation ID, или для header-based A/B маршрутизации.
RDP cookie
Считывает RDP session cookie, встроенный в протокольное согласование. Необходим для RDP-шлюзов и ферм удалённых рабочих столов — удерживает пользователей на одном RDP-хосте после переподключения.
TR7 cookie
TR7 ADC сам генерирует и управляет affinity cookie — без кода backend. Оператор задаёт имя cookie и таймаут простоя max-idle; ADC читает его при каждом запросе, backend игнорирует. Простейшая персистентность для добавления к legacy-приложению.
Backend cookie
Используйте собственный session cookie приложения для affinity — оператор называет cookie (PHPSESSID, JSESSIONID, app-id, любой кастомный) и TR7 ADC читает существующее значение. Никаких новых cookie не добавляется. Правильный выбор, когда приложение уже отслеживает сессии и вы не хотите добавлять второй cookie.
Dynamic persistence
Таблица персистентности по hash-ключу, хранящаяся в памяти. Каждая запись сопоставляет ключ — любую комбинацию заголовков запроса, cookie, source IP или URL-параметров — с backend. Оператор задаёт размер таблицы (от 10K до 100M записей, дефолт 3M) и время истечения записи. Используйте когда правила персистентности должны быть более гибкими, чем единственный фиксированный cookie или заголовок.
SAM — Session Affinity Manager
Расширенный движок персистентности на основе cookie. Выберите, кто генерирует cookie, формат session-id и флаги безопасности — всё из UI, без изменений backend. Подробности ниже.
SAM — Session Affinity Manager
SAM — наиболее гибкий метод персистентности TR7. Там, где обычный cookie закрепляет сессию, SAM позволяет контролировать каждое свойство этого cookie из выпадающего списка — без изменений backend, без написания кода правил.
Два источника cookie
Выберите, кто генерирует affinity cookie: TR7-generated (дефолт — без участия backend) или backend-generated (используйте существующий session cookie приложения). Переключайтесь между ними без прерывания активных сессий.
Четыре формата session-ID — включая открытый режим Custom
Опции формата идентификатора сессии: UUID (случайный 128-битный), IP-timestamp-random (отслеживаемый, упорядоченный по времени), IP-random (анонимный в рамках тенанта) или Custom. Режим Custom открывает полную поверхность переменных трафика — комбинируйте любые заголовки запросов, cookie, компоненты URL, информацию TLS-сессии, source IP (raw или маскированный), JWT-claims, query-параметры и даже поля тела запроса с пользовательскими функциями преобразования (маскирование, хэширование, извлечение подстроки, нормализация регистра, конкатенация). Тот же движок переменных и преобразований управляет hash-ключами Dynamic persistence. Реальные комбинации смотрите в spotlight ниже.
Четыре комбинации флагов безопасности
Флаги безопасности cookie: HttpOnly (без доступа JavaScript — защита от XSS), Secure (только HTTPS), SameSite=Strict (без межсайтовой отправки — защита от CSRF), SameSite=Lax (совместимый вариант). Комбинируйте по потребности.
Настраивается оператором, без кода
Всё вышеперечисленное — это per-vService выпадающий список в панели SAM. Никакого кода пользовательских правил, никакой интеграции backend, никакого отдельного WAAP-правила для обработки cookie. SAM — это конфигурация, а не скрипт.
Выйдите за рамки cookie и IP — комбинируйте любую переменную трафика
SAM Custom Format и hash-ключи Dynamic persistence принимают любую переменную трафика, которую видит TR7 ADC — комбинируйте их, преобразуйте, создавайте именно то правило персистентности, которое нужно вашему приложению
SAM Custom Format — реальные комбинации
Dynamic persistence — hash-ключи из нескольких переменных
Функции преобразования для любой переменной
Когда персистентность важна больше всего
Корзины и оформление заказов в e-commerce
Пользователи добавляют товары на нескольких загрузках страниц. Backend cookie или TR7 cookie удерживает состояние корзины на одном backend — оформление заказа никогда не видит пустую корзину.
Авторизованные дашборды
Сессии вошедших пользователей, где кэш разрешений живёт на одном backend. SAM с TR7-generated cookie + HttpOnly + Secure работает без изменений кода backend.
RDP-шлюзы и фермы удалённых рабочих столов
RDP-сессии должны переподключаться к одному хосту. RDP cookie персистентность читает native session ID протокола — без дополнительной конфигурации, без инъекции cookie.
Legacy-приложения без управления сессиями
Приложения, которые сами не отслеживают сессии. Source-IP или URL-parameter персистентность закрепляет пользователей без изменений кода legacy-приложения.
Распространённые вопросы
Нужно ли выбирать между алгоритмом балансировки нагрузки и персистентностью?
В чём разница между TR7 cookie и SAM?
Что происходит когда закреплённый backend выходит из строя?
Можно ли использовать source-IP персистентность за корпоративным NAT?
Влияет ли персистентность сессий на WebSocket и HTTP/2 соединения?
Сопоставьте метод персистентности с вашей нагрузкой
Посмотрите, как 9 методов персистентности охватывают все распространённые случаи — от RDP-шлюзов до legacy-приложений и SAM-управляемых cookie.