A afinidade por endereço de origem e a persistência por cookie, juntas, atendem à maioria dos casos, e é por isso que costumam ser as escolhas padrão. Mas um padrão só é uma boa escolha quando você conhece o modo de falha dele, e cada um desses métodos tem um que importa.

Afinidade por endereço de origem: o problema do NAT

A afinidade por origem é simples e não depende de protocolo, mas usa como chave o IP do cliente, e essa premissa quebra sempre que muitos usuários compartilham o mesmo endereço. Atrás de um gateway de (network address translation, a tradução de endereços de rede), de um proxy corporativo ou de um concentrador de (rede privada virtual), centenas de clientes podem chegar com o mesmo IP de origem. A afinidade por origem prende todos eles a um único membro do pool, e a distribuição de carga desmorona em silêncio sobre um só 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 diferente ganha o seu próprio registro de persistência. Uma máscara mais larga diminui o número de registros, mas junta mais clientes no mesmo registro, o que troca um problema por outro. A afinidade por origem só funciona bem quando os clientes têm endereços estáveis e realmente diferentes.

Persistência por cookie: a dependência do HTTP

A persistência por cookie evita o problema do endereço compartilhado porque identifica cada cliente de forma única na camada HTTP. O preço é que ela só funciona com HTTP, ou com HTTPS que o BIG-IP decifra, porque precisa de um perfil HTTP para inserir ou ler o cookie. Ela também depende da colaboração do cliente: um cliente que descarta cookies simplesmente não persiste. Essa dependência é o motivo mais comum para configurar um método de fallback, para que os clientes que recusam cookies ainda caiam sempre no mesmo lugar.

Persistência SSL: o limite do TLS 1.3

Quando o tráfego chega cifrado e o BIG-IP não o decifra, nem o cookie nem os métodos de camada de aplicação enxergam nada, e a persistência SSL fica atraente porque usa como chave o session ID do SSL, que é trocado em claro durante o handshake. Ela sobrevive até a uma mudança do IP do cliente. O problema é a versão do protocolo. O mecanismo de session ID foi, na prática, aposentado no TLS 1.3, então não dá para confiar na persistência SSL ali; e, mesmo no TLS 1.2, alguns clientes não reutilizam o session ID de forma consistente. É exatamente por isso que a persistência SSL aparece tantas vezes combinada com um fallback por endereço de origem.

Persistência universal: quando você precisa de controle

Quando a chave certa não é nenhuma dessas, e sim um token da aplicação num header (cabeçalho) ou no payload (a carga útil), a persistência universal deixa uma iRule extrair exatamente esse valor. É o método mais flexível, mas transfere o trabalho para uma iRule que você precisa escrever e manter, e exige que o BIG-IP enxergue o valor; ou seja, o tráfego cifrado precisa ser terminado antes. Use esse método quando a ideia de sessão da aplicação não se encaixa num cookie nem num endereço.

Deixe a ferramenta mostrar os trade-offs

O explicador de métodos de persistência mostra os modos de falha de cada método ao lado da configuração dele; assim, um perfil de endereço de origem exibe a ressalva do NAT, e um perfil SSL exibe a ressalva do TLS 1.3, logo ao lado das configurações. Para o catálogo completo de métodos, veja métodos de persistência do BIG-IP; para entender como um método primário e um fallback se combinam, veja fallback de persistência e match-across.

Fontes

Os métodos são da própria F5 e o limite de protocolo é da especificação do TLS, portanto as duas metades da ressalva sobre persistência SSL têm fontes distintas.