Dissecando Persistência no BIG-IP — Parte 1

Álcool gel… Syn, syn-ack, ack!!! (pa dum tss)…

Fala pessoal!! Sejam bem-vindos a mais nova série de F5 BIG-IP aqui no TechRebels! Você pode encontrar todos os meus posts publicados por aqui neste link. Recomendo que sejam lidos na ordem, caso você tenha chegado agora.

E como sempre, fiquem ligados no TechRebels e sigam-me no Medium clicando follow lá em cima para acompanhar os próximos posts.

Em nosso último encontro, conversamos sobre a topologia nPath/DSR. Se você perdeu, clica aqui. Tentei demonstrar as principais vantagens desse design e os principais pontos de atenção que você tem que ficar ligado. Vamos começar uma nova série e analisar os tipos mais comuns de persistência em ambientes com o BIG-IP.

Então, como sempre, prepare seu café ou coca-cola geladinha e vamos nessa!

Antes de começarmos, gostaria de deixar aqui o meu pensamento positivo e desejar a todos nós, nossas famílias e amigos, que passemos por esse período de quarentena sem maiores problemas e com muita saúde. Teremos tempos difíceis à frente mas juntos vamos superar tudo isso, um passo de cada vez. Força, pessoal!

A ideia pra essa série surgiu de um comentário de um colega de trabalho. Estávamos em um troubleshoot de um cliente e ele mandou no MS Teams um “pô Bianco… não achei artigo seu falando de persistência”. Vamos corrigir isso pra já! Obrigado pela idéia, Tiago Carlos!

Antes de falarmos especificamente de persistência, é preciso recordar algumas regrinhas que o BIG-IP segue para balancear um tráfego. São elas:

1. Ao dar match em um VS, o BIG-IP verifica se existe um profile de persistência anexado ao VS. Se houver, ele tenta seguir a entrada dessa tabela de persistência e encaminha para o pool-member escolhido anteriormente.
2. Se não for possível encaminhar para o pool-member anterior, o BIG-IP apenas balanceia para o próximo pool-member que o algorítmo de balanceamento determinar.
3. Uma vez que esse balanceamento acontece, o BIG-IP anota nessa tabela de persistência essa nova decisão.
4. Toda vez que há fluxo na conexão, o timer da tabela de persistência é reiniciado.

Então, vamos começar pela persistência mais simples de entender: source-address!

As formas de persistência são definidas em um profile de persistência dentro do nosso amigo BIG-IP. Para quem nunca viu um profile de persistência, tá aí:

1. O tipo da persistência, no caso por source-address ou ip de origem.
2. Mirror Persistence, para que a tabela de persistência seja sincronizada entre caixas em cluster/HA. Essa opção só aparece na GUI se o seu BIG-IP fizer parte de um cluster ou for um Viprion.
3. Match Across Service faz com que o profile possa atuar em VSs que possuem o mesmo virtual-address (VIP). Ideal para quando você tem mais de uma porta de serviço e precisa tomar a mesma decisão de balanceamento e os VSs possuem o mesmo IP.
4. Match Across Virtual Server toma a decisão de balanceamento mesmo que os VSs tenham IPs diferentes.
5. O timeout para a entrada da tabela de persistência. Pode ser infinito ou um valor em segundos.
6. Prefix Length, indica se a decisão de mandar para o mesmo pool-member será IP a IP (com prefixo /32), ou para uma rede inteira (prefixo /24 por exemplo) e assim vai.

Muito bem. Vamos agora olhar nossa topologia do lab.

Para a demonstração, montamos um pool com os dois servidores: green e red. Repare que esses servidores estão na mesma rede que o virtual-server, então estamos utilizando SNAT auto-map para evitar assimetria. O pool que contém os dois servidores utiliza o modo de balanceamento round-robin. Estamos rodando a v15.1.0 do TMOS.

Pensando em um nova conexão de um cliente, o BIG-IP receberia o tráfego no virtual-server, verificaria que o VS tem um profile de persistência anexado. Em seguida, iria consultar a tabela de persistência. Não encontrando uma entrada nessa tabela, ele aplicaria o algorítmo de balanceamento definido no pool e anotaria nessa tabela de persistência a decisão que ele tomou para o caso de novas conexões desse mesmo cliente chegarem. Vamos ver isso no primeiro vídeo de demonstração.

Agora vamos ver uma pegadinha. Lá em cima, na regrinha nº4, eu disse que o BIG-IP só atualiza o timer da tabela de persistência se houver tráfego passando na conexão ou se uma nova conexão acontecer. Isso significa que se a sua aplicação utiliza o que chamamos de “long lived connections”, ou conexões de longa duração, pode acontecer de o cliente estar pendurado por horas, mas não trafegando, ocasionando a expiração da entrada da tabela de persistência antes da conexão como um todo ser finalizada. E caso o seu cliente venha com uma nova conexão, o BIG-IP não irá achar uma entrada de persistência para ele e irá aplicar o algorítmo de balanceamento novamente, podendo entregar a nova conexão para o pool-member “errado”. Vídeo com direito até a surpresa pro cara chegar a suar frio, no melhor estilo “a demonstração que deu quase errado”, olhem só!

Agora, por último, mas não menos importante, eu quero comentar com vocês a questão do “match across services” e “match across virtual servers”. O primeiro — match across services — permite que você utilize o profile de persistência em virtual-servers que possuem o mesmo IP. Um exemplo seria uma aplicação que é acessada pelo IP 10.122.18.200, mas que utiliza duas portas. E você precisaria garantir que o usuário fosse encaminhado para o mesmo pool-member. O que me veio em mente agora foi um balanceamento de uma solução de VPN que utilizava o mesmo IP, mas precisava de 3 portas (TCP-443, UDP-500 e UDP-4500). O match across services foi necessário para isso.

Já o match across virtual servers teria o mesmo propósito, porém para aplicações que utilizam IPs diferentes. Como exemplo, posso citar dois VS de porta 80, mas com IPs diferentes que precisam garantir que o cliente é encaminhado para o mesmo pool-member.

Vamos olhar os dois cenários no próximo vídeo.

Interessante, não?! Então, em resumo, profiles de persistência nos auxiliam a garantir que o cliente sempre irá cair no mesmo pool-member. Existem vários tipos de persistência, mas vimos nesse primeiro artigo a persistência por source-address, que avalia o IP de origem da conexão e anota isso em uma tabela. Observamos também que a tabela de persistência pode expirar em casos que a conexão fica pendurada por muito tempo, sem que haja transferência de dados. Olhamos também como pode ser útil que a persistência seja avaliada entre aplicações com o mesmo IP e até com IPs diferentes, para que o BIG-IP mantenha a integridade das aplicações que precisam trabalhar em conjunto.

Podemos dizer então, que tão importante quanto entender o tráfego da sua aplicação, é tambem entender como o seu usuário a utiliza. Pois os testes podem indicar uma coisa e a prática outra. Fiquem atentos!

O que você achou dessa primeira forma de persistência? Ela já resolveu algum problema de alguma aplicação sua? Me conta aí nos comentários! No próximo artigo iremos explorar a persistência por cookies.

Ficou com alguma dúvida? Pode perguntar! Os comentários e perguntas ajudam a direcionar os próximos artigos! Não deixe de seguir o TechRebels e a mim aqui no Medium clicando no “follow” ali embaixo e também no Twitter!

/FIN=1

Sobre o autor

Rafael Bianco Nacif é analista de redes sênior. Graduado em Redes de Computadores, certificado 2xF5 Solutions Expert (Cloud/Sec), Cisco CCNP DC e RS e também AWS CSA. Iniciou a carreira na área de TI como help-desk e hoje atua em projetos de DC de alta complexidade. linkedin.com/in/rafaelbn