Round-robin envia cada requisição para um backend diferente — por design. Para serviços stateless isso é perfeito. Mas no momento em que um usuário faz login, preenche um carrinho ou inicia um desktop remoto, a aplicação começa a manter estado em um backend específico. Se a requisição #2 chegar a outro, o usuário vê um carrinho vazio, uma tela de logout ou uma sessão RDP congelada.
A persistência de sessão (ou 'afinidade') resolve isso fixando um usuário em um backend escolhido pela duração da sessão. O ponto é que não há uma única maneira correta de fazer isso. Source-IP funciona para usuários com IP único, mas quebra atrás de NAT corporativo. Cookies funcionam em browsers, mas não para TCP puro. Hash de parâmetro de URL funciona para URLs stateless, mas não para fluxos com escopo de usuário. Cada método é correto em algum cenário.
A resposta é oferecer todos os métodos e escolher por vService.
Cada vService escolhe seu método de persistência em um menu suspenso — junto com seu algoritmo de balanceamento de carga. Ambas as camadas são independentes: escolha Fastest+ para seleção de backend e um cookie TR7 para afinidade, ou round-robin com source-IP, ou qualquer combinação que se adapte à carga de trabalho. A troca de método é a quente, sem reinicialização.
Cinco algoritmos de balanceamento de carga auto-persistentes (source, URI, URL-param, header, RDP-cookie) mais quatro métodos de persistência explícitos (cookie TR7, cookie de backend, dinâmico, SAM). Cobrem todos os casos comuns.
O Session Affinity Manager permite definir a fonte do cookie (gerado pelo TR7 ou pelo backend), o formato de sessão (UUID, IP-timestamp-aleatório, IP-aleatório, personalizado) e os flags de segurança (HttpOnly, Secure, SameSite=Strict/Lax) — sem alterar o código do backend.
A persistência roda sobre o algoritmo de balanceamento de carga: o algoritmo escolhe o backend para a primeira requisição, a persistência fixa as demais. Fastest+ para cold-start, cookie sticky para a sessão — funcionam juntos.
Mude o método de persistência em um vService ativo e as novas sessões adotam o novo método imediatamente. Sessões fixadas existentes continuam sem interrupção até expirar.
Escolha o método que se adapta ao protocolo, à população de clientes e ao modelo de sessão da aplicação. Todos os 9 disponíveis por vService — sem código, sem plugin.
O mesmo IP de cliente sempre chega ao mesmo backend. Simples, sem código, funciona para qualquer protocolo. Melhor quando os IPs de clientes são diversos — quebra atrás de NAT compartilhado ou proxies corporativos.
Hash no comprimento da URL distribui a carga por complexidade de URL enquanto fixa URLs idênticas no mesmo backend. Útil para cenários de afinidade de cache.
Hash em um parâmetro de consulta específico (ex.: ?user_id, ?session_token). Roteia a mesma requisição com escopo de usuário para o mesmo backend sem exigir cookies.
Hash em um header HTTP personalizado. Útil quando o chamador upstream injeta IDs de tenant ou correlação, ou para roteamento A/B baseado em header.
Lê o cookie de sessão RDP embutido na negociação de protocolo. Necessário para gateways RDP e farms de desktop remoto — mantém os usuários no mesmo host RDP após reconexão.
O TR7 ADC gera e gerencia o cookie de afinidade por conta própria — sem necessidade de código no backend. O operador define o nome do cookie e um timeout de idle máximo; o ADC lê o cookie em cada requisição, o backend o ignora. A persistência mais fácil de adicionar a uma aplicação legada.
Use o próprio cookie de sessão da aplicação para afinidade — o operador nomeia o cookie (PHPSESSID, JSESSIONID, app-id, qualquer personalizado) e o TR7 ADC lê o valor existente. Nenhum cookie novo é adicionado. Correto quando a aplicação já rastreia sessões e você não quer adicionar um segundo cookie.
Tabela de persistência por chave de hash mantida em memória. Cada entrada mapeia uma chave — qualquer combinação de headers de requisição, cookies, source IP ou parâmetros de URL — para um backend. O operador define o tamanho da tabela (10K a 100M entradas, padrão 3M) e o tempo de expiração de entrada. Use quando as regras de persistência precisam ser mais flexíveis do que um único cookie ou header fixo.
O motor avançado de persistência baseado em cookie. Escolha quem gera o cookie, o formato do session-id e os flags de segurança — tudo pela UI, sem alterações no backend. Veja os detalhes abaixo.
O SAM é o método de persistência mais flexível do TR7. Onde um cookie simples fixa uma sessão, o SAM permite controlar cada propriedade desse cookie em um menu suspenso — sem mudanças no backend, sem escrever código de regra.
Escolha quem gera o cookie de afinidade: gerado pelo TR7 (padrão — sem envolvimento do backend) ou gerado pelo backend (use o cookie de sessão existente da aplicação). Alterne entre eles sem quebrar sessões ativas.
Opções de formato do identificador de sessão: UUID (128 bits aleatórios), IP-timestamp-aleatório (rastreável, ordenado por tempo), IP-aleatório (anônimo dentro de um tenant) ou Custom. O modo Custom abre a superfície completa de variáveis de tráfego — combine qualquer header de requisição, cookies, componentes de URL, informações de sessão TLS, source IP (bruto ou mascarado), claims de JWT, parâmetros de consulta e até campos do body da requisição com funções de transformação definidas pelo operador (mascaramento, hashing, extração de substring, normalização de capitalização, concatenação). O mesmo motor de variável e transformação impulsiona as chaves de hash de persistência Dinâmica.
Flags de segurança de cookie: HttpOnly (sem acesso JavaScript — proteção XSS), Secure (somente HTTPS), SameSite=Strict (sem envio cross-site — proteção CSRF), SameSite=Lax (variante compatível). Combine conforme necessário.
Tudo acima é um menu suspenso por vService no painel SAM. Sem código de regra personalizado, sem integração de backend, sem regra WAAP separada para tratamento de cookie. O SAM é uma configuração, não um script.
O Formato Custom do SAM e as chaves de hash de persistência Dinâmica aceitam todas as variáveis de tráfego que o TR7 ADC vê — combine-as, transforme-as, construa a regra de persistência exata que sua aplicação precisa
Usuários adicionam itens em múltiplos carregamentos de página. O cookie de backend ou o cookie TR7 mantém o estado do carrinho em um backend — o checkout nunca vê um carrinho vazio.
Sessões autenticadas onde o cache de permissões do usuário vive em um backend. SAM com cookie gerado pelo TR7 + HttpOnly + Secure funciona sem mudanças no código do backend.
Sessões RDP devem se reconectar ao mesmo host. A persistência por RDP cookie lê o session ID nativo do protocolo — sem configuração extra, sem injeção de cookie.
Aplicações que não rastreiam sessões por conta própria. A persistência por source-IP ou parâmetro de URL fixa usuários sem exigir mudanças no código da aplicação legada.
Veja como 9 métodos de persistência cobrem todos os casos comuns — de gateways RDP a aplicações legadas a cookies controlados pelo SAM.