Muitas vezes, um único método de persistência não basta. O BIG-IP permite que um virtual server combine um método primário com um fallback, e permite que um perfil de persistência controle até onde os registros dele são compartilhados entre virtuals e pools. Os dois mecanismos são poderosos, e os dois são fáceis de errar sem que ninguém perceba.

Primário e fallback

Num virtual server, o perfil de persistência padrão é o método primário, e o fallback-persistence define um segundo método, usado quando o primário não encontra nenhum registro. O exemplo clássico é cookie como primário e afinidade por endereço de origem como fallback: os clientes que aceitam cookies persistem pelo cookie, e os que descartam cookies continuam caindo no mesmo lugar pelo IP de origem. Outra combinação comum é a persistência SSL como primário e a afinidade por endereço de origem como fallback; assim, um cliente que não apresenta um session ID reutilizável, seja por estar no TLS 1.3, seja simplesmente por não reutilizar a sessão, ainda é pego pelo endereço.

Para o fallback fazer sentido, ele precisa usar um método diferente do primário. Um primário e um fallback que resultam no mesmo método não acrescentam resiliência nenhuma; só fazem a mesma coisa duas vezes. O explicador de métodos de persistência resolve as duas pontas da cadeia e aponta esse caso, além de reconhecer as combinações recomendadas.

Match Across Services

A primeira das três configurações de compartilhamento, a Match Across Services, permite que um cliente continue no mesmo membro em virtual servers que compartilham o mesmo endereço virtual. Se v1:http e v1:ssl usam essa opção, um cliente com persistência num deles é enviado ao mesmo node no outro, porque os dois compartilham o endereço virtual v1. Uma conexão para um virtual com outro endereço, digamos v2, começa uma sessão de persistência nova. Para isso funcionar, os virtuals envolvidos precisam apontar para os mesmos endereços de node. Atenção: nos perfis de cookie, essa configuração vale só para o método Cookie Hash.

Match Across Virtual Servers e Match Across Pools

A Match Across Virtual Servers é mais ampla: mantém o cliente no mesmo node, qualquer que seja o virtual que recebe a conexão, mesmo entre endereços virtuais diferentes. A Match Across Pools é mais ampla ainda, e a mais perigosa: ela deixa o BIG-IP usar qualquer pool que tenha um determinado registro de persistência, o que significa que o tráfego pode ir para um pool diferente daquele que o virtual server especifica. A F5 documenta isso explicitamente como um aviso, porque essa opção pode mandar clientes para um lugar que a configuração, à primeira vista, não pretendia. Habilite as opções mais amplas só quando a topologia exigir de verdade uma persistência compartilhada, e confirme que os virtuals e os pools envolvidos têm os mesmos membros.

Como ler a cadeia de persistência

Como essas configurações interagem entre si, conferir tudo no olho, espalhado por vários perfis e virtuals, é um convite ao erro. O explicador de métodos de persistência mostra o primário e o fallback de cada virtual lado a lado, com as observações que se aplicam a cada caso, e exibe as configurações match-across de cada perfil com o que cada uma faz. Para os métodos em si, veja métodos de persistência do BIG-IP; para escolher entre eles, veja como escolher um método de persistência.

Fontes

As configurações Match Across e a persistência de fallback estão definidas na referência de perfis da F5; o motivo pelo qual um cliente TLS 1.3 pode não apresentar um session ID reutilizável está na especificação do protocolo.