Sem persistência, cada nova conexão é balanceada de forma independente, então um cliente pode cair em um membro diferente do pool a cada vez. Para aplicações com estado, um carrinho de compras, uma sessão de login, um formulário em várias etapas, isso significa perda de estado. A persistência resolve o problema registrando qual membro atendeu um cliente e devolvendo esse cliente ao mesmo membro. O BIG-IP fornece vários métodos, e escolher bem depende de entender em que cada um se baseia.
Persistência por cookie
A persistência por cookie vincula um cliente a um membro por meio de um cookie HTTP. Ela tem quatro modos. Insert adiciona o cookie à resposta e o lê de volta depois, então o mapeamento fica no cliente e nenhum registro do lado do servidor é necessário. Rewrite faz o servidor emitir um cookie em branco que o BIG-IP sobrescreve. Passive faz o próprio servidor definir o cookie no formato especial, que o BIG-IP apenas lê. Hash balanceia com base em um hash de um cookie definido pelo servidor. Por funcionar na camada HTTP, a persistência por cookie precisa de um perfil HTTP, o que significa que o tráfego deve ser HTTP ou HTTPS que o BIG-IP descriptografa. O decodificador de cookie de persistência companheiro mostra o que o valor codificado dentro desse cookie de fato contém.
Afinidade por endereço de origem e de destino
A afinidade por endereço de origem registra o IP de origem do cliente e envia conexões posteriores daquele endereço ao mesmo membro. Funciona para qualquer protocolo, mas sua precisão é definida por uma máscara: o padrão 255.255.255.255 dá a cada endereço seu próprio registro, enquanto uma máscara mais ampla agrupa uma sub-rede. A afinidade por endereço de destino, também chamada de persistência sticky, faz o espelho, baseando-se no endereço de destino independentemente do cliente, o que é útil principalmente para balancear servidores de cache, para que o mesmo destino sempre chegue ao mesmo cache.
Persistência SSL
A persistência SSL baseia-se no ID de sessão SSL, que o cliente envia em texto claro durante o handshake TLS. Como o ID de sessão sobrevive a uma mudança no endereço IP do cliente, ela serve para clientes atrás de endereços traduzidos ou dinâmicos, e funciona em tráfego criptografado que o BIG-IP não descriptografa. Sua grande limitação é a versão do protocolo: o mecanismo de ID de sessão existe apenas no TLS 1.2 e anteriores, então a persistência SSL não pode ser usada de forma confiável com o TLS 1.3.
Persistência universal e por hash
A persistência universal é a opção flexível: uma expressão de iRule extrai qualquer valor do tráfego, um JSESSIONID, um cabeçalho, um campo do payload, e esse valor torna-se a chave de persistência. A persistência por hash é a mesma ideia, exceto que a chave é um hash do valor escolhido em vez do próprio valor, o que distribui a carga de forma mais uniforme ao custo de possíveis colisões. Ambas dependem de uma iRule para definir em que se basear, e ambas exigem que o BIG-IP veja o valor, então o tráfego criptografado precisa ser terminado primeiro.
Os métodos específicos de protocolo
Dois métodos existem para protocolos específicos. A persistência MSRDP rastreia sessões de Microsoft Remote Desktop para que um cliente que reconecta retorne ao mesmo host de sessão. A persistência SIP baseia-se em um cabeçalho SIP, por padrão o Call-ID, para que todas as mensagens de uma chamada cheguem ao mesmo servidor. Cada um faz sentido apenas para seu protocolo.
Lendo-os em uma configuração
O explicador de métodos de persistência identifica cada perfil de persistência em uma configuração, nomeia seu método e lista os campos que importam. O próximo passo é decidir qual método se encaixa em uma dada aplicação, abordado em escolhendo um método de persistência, e entender como um primário e um fallback funcionam juntos, abordado em fallback de persistência e match-across.