Dois ajustes no BIG-IP, um só no XC
Quem vem do BIG-IP está acostumado a configurar duas coisas de forma independente num virtual server: o método de load balancing (Round Robin, Least Connections, Ratio e assim por diante) e, à parte, um profile de persistência (Source Address Affinity, Cookie, sessão SSL). O método decide como o tráfego se distribui; o profile de persistência decide como um cliente que volta fica preso ao mesmo servidor que o atendeu antes. São duas configurações, dois objetos. O F5 Distributed Cloud resolve isso com um só, e entender esse ponto é todo o segredo para configurar persistência no XC.
A lista de algoritmos do XC
Num origin pool do XC, você escolhe um único Load Balancing Algorithm. As opções são Round Robin, Least Active Request, Random, Source IP Stickiness, Cookie Based Stickiness, Ring Hash e Load Balancer Override. Alguns desses nomes descrevem distribuição, e outros descrevem persistência, e é exatamente isso que importa aqui. No XC, eles ficam no mesmo dropdown porque o algoritmo e a persistência são a mesma decisão.
O consistent hashing é a persistência
Os algoritmos de consistent hashing (hash consistente), que são o Source IP Stickiness, o Cookie Based Stickiness e o Ring Hash, funcionam assim: clientes e origin servers são colocados num anel, e o algoritmo calcula o hash de alguma informação de cada requisição para mapear o cliente num ponto desse anel. Como os mesmos critérios da requisição sempre resultam no mesmo hash, e portanto no mesmo origin, o cliente continua voltando para o mesmo servidor. Esse mapeamento é a persistência: não existe profile separado, porque o algoritmo já é sticky por natureza. Como diz a própria explicação da F5, o consistent hashing é um algoritmo próprio, mas também inclui, por definição, um método de persistência; na prática, ele é o método de persistência. E ele tem uma segunda vantagem: quando origins entram ou saem do pool, só uma pequena parte dos clientes é remapeada, e é por isso que ele é a escolha certa para pools dinâmicos, como os serviços do .
As três coisas que podem entrar no hash
O consistent hashing precisa de uma chave, e o XC oferece três. Source IP faz o hash do endereço do cliente: é simples, mas joga num único origin todo mundo que está atrás de um mesmo (network address translation) ou de um proxy compartilhado, então a distribuição fica desequilibrada quando há pouca variedade de clientes. Cookie faz o hash de um cookie identificado pelo nome, com e path que você configura, e funciona bem com navegadores que devolvem o cookie de forma confiável. Ring Hash com uma hash policy customizada deixa você fazer o hash de um header escolhido por você, normalmente um que carrega um session ID, e é o encaixe mais limpo para microsserviços que já passam um token de sessão. Escolha a chave que seja, ao mesmo tempo, estável dentro da sessão e bem distribuída entre os clientes.
Quando você não precisa de persistência
Se a aplicação é stateless, você não quer nenhum algoritmo de hash: você quer distribuição uniforme. O Round Robin é o padrão e distribui as requisições em rodízio. O Least Active Request manda cada requisição para o origin com menos requisições em andamento, e é a melhor escolha quando as requisições têm custos diferentes ou as conexões são longas. O Random é estatisticamente uniforme em pools grandes. Nenhum desses três mantém um cliente num mesmo origin, e isso não é problema para cargas stateless; só vira problema se você precisava de stickiness e escolheu um deles por engano.
Persistência por rota com o Load Balancer Override
Às vezes, um mesmo pool atende vários domínios ou rotas que precisam de persistências diferentes. É para isso que serve o Load Balancer Override: configure o algoritmo do pool como Load Balancer Override e depois, nas Advanced Options da rota do HTTP load balancer, use o Load Balancing Control para escolher stickiness por Cookie ou por Source IP em cada rota ou em cada domínio. É o único lugar em que o XC deixa você separar a decisão de persistência do pool e levá-la para a rota, do jeito que os profiles de persistência por virtual server funcionam no BIG-IP.
Como escolher
A versão curta é esta. Stateless, com carga uniforme: Round Robin. Stateless, mas com requisições desiguais ou longas: Least Active Request. Persistência pelo IP do cliente: Source IP Stickiness, a menos que seus clientes estejam atrás de um IP compartilhado. Persistência por cookie: Cookie Based Stickiness. Persistência por um token de sessão num header: Ring Hash com uma hash policy customizada. Persistência diferente por rota: Load Balancer Override. A ferramenta que acompanha este artigo percorre essas perguntas e entrega o algoritmo, o equivalente no BIG-IP e os cuidados a tomar; um seletor de métodos do BIG-IP está a caminho, para comparar os dois lado a lado.