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 (Protocolo de Área de Trabalho Remota da Microsoft, do inglês Microsoft Remote Desktop Protocol) rastreia sessões de Microsoft Remote Desktop para que um cliente que reconecta retorne ao mesmo host de sessão. A persistência (Protocolo de Iniciação de Sessão, do inglês Session Initiation Protocol) 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.