A afinidade de endereço de origem e a persistência por cookie juntas cobrem a maioria das necessidades, e é por isso que são os padrões usuais. Mas um padrão só é uma boa escolha quando você conhece seu modo de falha, e cada método tem um que importa.
Afinidade de endereço de origem: o problema do NAT
A afinidade de origem é simples e independente de protocolo, mas baseia-se no IP do cliente, e essa suposição quebra sempre que muitos usuários compartilham um endereço. Atrás de um gateway (tradução de endereços de rede, do inglês network address translation), um proxy corporativo ou um concentrador de , centenas de clientes podem chegar com o mesmo IP de origem. A afinidade de origem fixará todos eles em um único membro do pool, e a distribuição de carga desmorona silenciosamente sobre um servidor. Ela também consome memória no BIG-IP: com a máscara padrão 255.255.255.255, cada endereço de cliente distinto recebe seu próprio registro de persistência. Uma máscara mais ampla reduz a contagem de registros, mas agrupa mais clientes, o que troca um problema por outro. A afinidade de origem só é adequada quando os clientes têm endereços estáveis e genuinamente distintos.
Persistência por cookie: a exigência de HTTP
A persistência por cookie evita o problema do endereço compartilhado identificando cada cliente de forma única na camada HTTP. Seu custo é que só funciona para HTTP, ou para HTTPS que o BIG-IP descriptografa, porque precisa de um perfil HTTP para inserir ou ler o cookie. Ela também depende da cooperação do cliente: um cliente que remove cookies não persistirá de forma alguma. Essa única dependência é o motivo mais comum para configurar um método de fallback, para que clientes que recusam cookies ainda cheguem a algum lugar consistente.
Persistência SSL: o precipício do TLS 1.3
Quando o tráfego é criptografado e não descriptografado no BIG-IP, nem cookie nem métodos de camada de aplicação conseguem ver nada, e a persistência SSL torna-se atraente porque se baseia no ID de sessão SSL trocado em texto claro durante o handshake. Ela até sobrevive a uma mudança no IP do cliente. O problema é a versão do protocolo. O mecanismo de ID de sessão foi efetivamente aposentado no TLS 1.3, então a persistência SSL não pode ser usada de forma confiável ali, e mesmo no TLS 1.2 alguns clientes não reutilizam o ID de sessão de forma consistente. É exatamente por isso que a persistência SSL é tão frequentemente combinada com um fallback de endereço de origem.
Persistência universal: quando você precisa de controle
Quando a chave certa não é nenhuma das anteriores, um token de aplicação em um cabeçalho ou payload, a persistência universal permite que uma iRule extraia precisamente esse valor. É o método mais flexível, mas transfere o trabalho para uma iRule que você deve escrever e manter, e exige que o BIG-IP veja o valor, então o tráfego criptografado precisa ser terminado primeiro. Recorra a ela quando a noção de sessão da aplicação não corresponder a um cookie ou a um endereço.
Deixando a ferramenta revelar os trade-offs
O explicador de métodos de persistência imprime os modos de falha de cada método ao lado de sua configuração, então um perfil de endereço de origem mostra a ressalva do NAT e um perfil SSL mostra a ressalva do TLS 1.3 diretamente ao lado das configurações. Para o catálogo completo de métodos, veja métodos de persistência do BIG-IP; para como um primário e um fallback se combinam, veja fallback de persistência e match-across.