Solução

Escolha o algoritmo certo para cada carga de trabalho

Do round-robin clássico ao Maglev hashing e ao motor proprietário Fastest+ em dois estágios do TR7 — 14 algoritmos disponíveis

Cargas de trabalho diferentes merecem lógicas de roteamento diferentes. Um vService uniforme com servidores web idênticos? Round-robin. Sessões de longa duração onde a capacidade determina? Least-connections. Cenários de afinidade de cache? Consistent hash ou Maglev. Hardware heterogêneo ou carga variável? Fastest+. TR7 ADC inclui todos os algoritmos padrão — mais três variantes modernas de hash e um motor proprietário — escolhidos por vService, trocados sem reinicialização.

critérios de seleção no Layer 7

escalonadores no Layer 4

por vService

Escolha do algoritmo — alteração ao vivo sem reinicialização

Por que padrões de tráfego exigem algoritmos diferentes

Cada algoritmo clássico parte de uma suposição sobre o vService que atende. Round-robin assume que os backends são intercambiáveis. Least-connections assume que a contagem de sessões se correlaciona com a carga do backend. Source-IP assume afinidade entre usuário e backend sem persistência explícita. Hashes de afinidade de cache assumem que a chave da requisição — URL, header ou sessão — é estável. Quando a suposição se sustenta, o algoritmo é a resposta certa.

Os casos mais difíceis são quando essas suposições deixam de valer: backends oscilam em desempenho durante o dia útil, gerações de hardware se misturam durante uma atualização gradual, a latência regional varia de requisição para requisição, ou a própria carga tem rajadas de consultas pesadas que não correspondem à contagem bruta de requisições. Nesses cenários, escolher o backend realmente mais rápido por requisição — ou usar um algoritmo de hash projetado para absorver mudanças de backend sem redistribuir tudo — é o que preserva a latência visível ao usuário.

A resposta certa é adequar o algoritmo à carga de trabalho — por vService, não globalmente.

Escolha de algoritmo, por vService

Um vService no TR7 reúne o listener de frontend, regras de tráfego, verificações de integridade e o grupo de backends em um único objeto de configuração — mais abrangente do que o conceito clássico de pool que distribui esses elementos em lugares separados. Cada vService escolhe seu próprio algoritmo em um menu suspenso — sem reconstrução, sem reinicialização. Misture e combine em uma única instância TR7: round-robin no vService de ativos estáticos, Fastest+ no vService de API, Maglev hash no vService de camada de cache. O filtro por tipo de serviço acontece automaticamente; a interface exibe apenas os algoritmos válidos para o protocolo do vService.

Algoritmo por vService

A escolha do algoritmo vive no objeto vService, não na configuração global do ADC. Diferentes vServices executam algoritmos diferentes na mesma instância TR7.

Filtragem por protocolo

A interface exibe apenas os algoritmos que fazem sentido para o protocolo do vService — vServices HTTP, TCP ou de camada de rede recebem cada um o subconjunto relevante, sem suposições do operador.

Combinável com persistência de sessão

O algoritmo escolhe o backend para a primeira requisição; a persistência de sessão então fixa as requisições subsequentes do mesmo usuário. Ambas as camadas configuráveis de forma independente por vService.

Troca a quente (sem reinicialização)

Mude o algoritmo em um vService ativo e o tráfego muda para a nova lógica imediatamente. Sem reinicialização de serviço, sem necessidade de drenagem de conexões.

14 algoritmos incluídos no TR7 ADC

Todos os algoritmos clássicos, duas variantes modernas de consistent hash, um algoritmo de menor atraso, mais o motor proprietário Fastest+ do TR7. Todos disponíveis por vService — escolhidos em um menu suspenso, sem necessidade de código de configuração.

Round-robin (ponderado + estático)

Distribuição uniforme pelo vService, ponderada ou não. O padrão para vServices uniformes onde cada backend tem capacidade idêntica.

Least-connections (ponderado)

Roteia para o backend com menor número de conexões abertas no momento. Altamente eficaz para sessões de longa duração onde a contagem de sessões se correlaciona com a carga do backend. A variante ponderada leva em conta diferenças de capacidade.

Menor tempo de resposta

Encaminha para o backend que responde mais rápido neste momento, medido continuamente e não por amostragem. Adequado a pools com capacidade igual mas latência variável por nó: um cache aquecendo, um nó sob pressão de GC, um vizinho barulhento.

Menor largura de banda

Encaminha para o backend que move menos tráfego naquele instante. É o critério certo quando as respostas diferem em tamanho e não em número — mídia, downloads de arquivos, exportação de relatórios —, onde o número de conexões nada diz sobre a carga real.

First-available

Sempre roteia para o primeiro backend listado com capacidade; cai para o próximo somente quando sobrecarregado. Útil para ordenação de backends quente-frio ou implantações graduais.

Random

Seleção aleatória entre backends saudáveis. Sem estado, estatisticamente uniforme — útil quando o vService é grande e uniforme. Suporta random de potência de dois para seleção de menor carga com baixo overhead.

Source-IP hash

O mesmo IP de cliente sempre roteia para o mesmo backend. Útil para fluxos com estado quando a aplicação não gerencia persistência de sessão explícita.

URL hash (URI / URL-parameter)

Hash em um componente de URL — o comprimento da URL, o caminho URI ou um parâmetro de consulta específico (ex.: ?user_id). Roteia a mesma URL ou usuário ao mesmo backend para afinidade de cache.

Header hash

Hash em um header HTTP personalizado. Útil para roteamento multi-tenant (header tenant-id), feature flagging ou cenários de testes A/B.

RDP cookie hash

Lê o cookie de sessão RDP para seleção de backend. Útil para gateways RDP e farms de desktop remoto onde a afinidade de sessão é necessária.

Consistent hash

Modo de hash moderno que minimiza a perturbação quando backends entram ou saem do vService — apenas uma pequena fração das chaves é redistribuída, não o vService inteiro. Ideal para camadas de cache onde a rotatividade de backends não deve invalidar todo o cache.

Maglev hash

O algoritmo de consistent hashing do Google construído para balanceadores de carga de software em escala. Menor variância que o consistent hash clássico, determinístico entre réplicas. Excelente para serviços sem estado que precisam de atribuição previsível de backend.

SED — Shortest Expected Delay

Roteia para o backend com o menor tempo de espera esperado, levando em conta conexões ativas e peso por backend. Uma alternativa sensível à latência em relação ao least-connections quando as capacidades de backend diferem significativamente.

Fastest

Roteia para o backend com o menor tempo de resposta recente. Uma opção mais simples e sensível à latência quando o tempo de resposta é o único sinal que importa.

Fastest+

O motor proprietário em dois estágios do TR7. O operador escolhe dois de oito sinais de serviço ao vivo — tempo de resposta, tempo de conexão, densidade de fila, taxas de erro e mais; o Fastest+ restringe os candidatos pelo sinal primário e, em seguida, separa os empatados pelo sinal secundário. Veja a seção de detalhes abaixo.

Fastest+ — o motor em dois estágios do TR7, ajustado pelo operador

A maioria dos algoritmos adaptativos monitora um único sinal — tempo de resposta ou contagem de conexões. O Fastest+ permite que o operador escolha dois de oito sinais de serviço ao vivo: o sinal primário restringe os candidatos aos backends de melhor pontuação, e o sinal secundário separa os empatados entre eles. Os backends em modo de manutenção e com status de saúde inadequado são filtrados automaticamente, e há um modo de sinal único disponível quando um único critério é suficiente. Estes são os oito sinais que você pode escolher:

Tempo de resposta

Latência média de resposta do backend, amostrada continuamente. O sinal principal — um backend que demora mais para responder cai no ranking imediatamente.

Tempo de conexão

Quanto tempo leva para estabelecer uma conexão TCP/TLS. Um backend cujo tempo de conexão cresce está se aproximando da saturação, mesmo que seu tempo de resposta ainda pareça bom.

Tempo de fila

Tempo que as requisições passam na fila antes de chegar ao backend. O aumento do tempo de fila é o aviso mais precoce de que um backend não consegue acompanhar.

Sessões ativas

Sessões abertas no momento por backend. Roteamento ciente de capacidade sem o ruído dos totais históricos.

Profundidade de fila ativa

Requisições atualmente aguardando. Um backend com 0 na fila é preferido a um igualmente rápido com 50 esperando.

Erros de conexão

Conexões com falha recentes. Um backend que recusou 3 das últimas 10 tentativas cai no ranking antes que uma verificação de integridade o detecte.

Abortos do lado do servidor

Abortos de sessão iniciados pelo backend na janela recente. Captura o caso em que um backend está ativo mas falha no meio do processamento.

Conexões utilizadas

Utilização do pool de conexões — quão próximo da capacidade está o pool keep-alive de cada backend. Detecta esgotamento do pool antes que se torne visível ao usuário.

DUAS CAMADAS, UMA POLÍTICA

Catorze no Layer 7, onze ao nível do pacote

No Layer 7 a decisão é tomada lendo a requisição: cabeçalho, caminho, cookie, tempo de resposta ao vivo. No Layer 4 é tomada sobre o pacote, antes de o tráfego chegar à camada de aplicação — é ali que está a maior vazão. Em ambos os casos o algoritmo é escolhido por serviço e muda com o equipamento em funcionamento.

Layer 7 — 14 critérios de seleção

Round robin — por vez, ponderado ou estritamente igual

Round robin ponderado — diferenças de capacidade respeitadas

Menos conexões — vence quem tem menos conexões abertas

Menor tempo de resposta — o backend que responde mais rápido agora

Menor largura de banda — o backend que move menos tráfego agora

Primeiro disponível — encher um backend antes de tocar no próximo

Aleatório — estatisticamente plano, sem estado

Fastest — um sinal ao vivo, vence o menor valor

Fastest+ — dois sinais: o primeiro reduz, o segundo desempata

IP de origem — mesmo cliente, mesmo backend

URI — mesmo caminho, mesmo backend; o cache fica quente

Parâmetro de URL — rotear por um valor da query string

Cabeçalho — rotear por qualquer cabeçalho, inclusive o seu

Cookie RDP — sessões de desktop caem no seu broker

Layer 4 — 11 escalonadores ao nível do pacote

rr — round robin

wrr — round robin ponderado

lc — menos conexões

wlc — menos conexões ponderado

lblc — menos conexões por localidade

lblcr — o mesmo com replicação

sh — hash de origem

dh — hash de destino

sed — menor atraso esperado

nq — nunca enfileirar

mh — hash Maglev: remapeamento mínimo quando o pool muda

Quando cada algoritmo brilha

vServices uniformes

Backends idênticos, capacidade idêntica — round-robin mantém a matemática simples e a carga simétrica. Adicione random para vServices grandes e sem estado.

Sessões de longa duração

WebSockets, serviços de streaming, chamadas de vídeo — sessões ficam abertas por minutos ou horas. Least-connections ou SED rastreia a carga ativa muito melhor do que a contagem de requisições.

vServices de camada de cache

A rotatividade de backends não deve invalidar todo o cache. Consistent hash ou Maglev redistribui apenas uma pequena fração das chaves quando backends mudam.

Carga heterogênea ou variável

Hardware misto, implantações graduais, variância de latência regional — Fastest+ pontua backends ao vivo para que o roteamento escolha o realmente mais rápido, não o teoricamente melhor.

Perguntas frequentes

Posso mudar o algoritmo sem reiniciar o serviço?

Sim. O algoritmo é um menu suspenso por vService. Mude-o em um vService ativo e o tráfego muda para a nova lógica imediatamente — sem reinicialização de serviço, sem necessidade de drenagem de conexões.

Como o Fastest+ se relaciona com o least-connections?

Least-connections é altamente eficaz para muitos vServices — especialmente sessões de longa duração onde a contagem de sessões rastreia de perto a carga do backend. Fastest+ amplia o quadro ao permitir que você escolha entre oito sinais de serviço ao vivo — densidade de fila, tempo de resposta recente, tempo de conexão, taxas de erro e mais — e decida sobre dois deles em uma seleção em dois estágios. Os casos de uso diferem: least-connections frequentemente é a escolha certa para vServices uniformes com formas de sessão previsíveis; Fastest+ brilha onde a contagem de sessões por si só não captura o quão ocupado um backend realmente está — tempos de consulta variáveis, gerações de hardware misto ou implantações graduais.

Quando devo escolher Consistent hash vs Maglev hash?

Ambos minimizam a redistribuição quando backends mudam. Consistent hash é o algoritmo clássico — simples, previsível, bem compreendido. Maglev é a variante do Google construída para balanceadores de carga de software em escala — menor variância na distribuição de carga, determinístico entre réplicas. Para a maioria das cargas de trabalho consistent hash é suficiente; escolha Maglev quando precisar de uniformidade estrita de carga ou ao executar múltiplas instâncias TR7 que precisam concordar no roteamento.

O que o SED faz que o least-connections não faz?

SED (Shortest Expected Delay) considera tanto as conexões ativas quanto o peso por backend para estimar qual backend responderá mais rapidamente à próxima requisição. É um refinamento do least-connections ponderado — útil quando as capacidades de backend diferem significativamente e você quer que o roteamento leve isso em conta sem a complexidade total do Fastest+.

A escolha do algoritmo requer monitoramento externo ou integração com APM?

Não. Todos os sinais — incluindo cada entrada do Fastest+ — são medidos pelo TR7 a partir do tráfego que já está fazendo proxy. Sem agente, sem hook de APM, sem pipeline de métricas externo.

Qual é o algoritmo padrão?

Round-robin é o padrão para compatibilidade retroativa com implantações existentes. Mudar para um algoritmo diferente é uma alteração de único menu suspenso na configuração do vService.

Adeque o algoritmo à carga de trabalho

Veja como o TR7 ADC permite definir o algoritmo por vService — e como o Fastest+ lida com as cargas de trabalho que os outros não conseguem.