Dissecando Persistência no BIG-IP — Parte 3

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

Fala pessoal!! Chegamos ao terceiro e último artigo da nossa série sobre persistência de tráfegos no BIG-IP aqui no TechRebels! Você pode encontrar todos os meus posts publicados 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.

No segundo artigo, falamos sobre persistências por cookies. Pudemos ver que, neste tipo, muitas vezes o cliente pode estar atrás de um proxy e, portanto, depende do browser para identificá-lo corretamente e é aí que os cookies nos ajudam.

No artigo de hoje vamos conversar sobre a persistência que a F5 chama de universal. Um nome arrojado, não é mesmo!? Mas vamos ver que realmente é possível utilizar esse tipo de persistência quando todos os outros não foram possíveis.

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

A persistência universal foi criada pela F5 com o intuito de prover o canivete suíço das persistências. Pense só. Se a F5 tivesse que inventar um tipo de persistência para cada protocolo e aplicação existente no mundo, seria um trabalho enorme e que não teria fim nunca. Com isso em mente, os engenheiros de lá uniram o poder das iRules com uma tabela dinâmica para controlar persistência de praticamente qualquer aplicação.

É isso mesmo! iRules + persistência!

Como podemos ver, ao tentar criar um profile de persistência universal, poucas opções existem. Basicamente é qual iRule está amarrada e o timeout que a entrada na tabela dinâmica da persistência universal terá. E é isso pe-pe-pessoal!

Dito isto, podemos dizer que, para a persistência universal funcionar corretamente, é necessário ter um fluxo avaliado por uma iRule. Quando há um match na iRule, a tabela de persistência é populada com a informação e o tráfego então é encaminhado para o pool-member correto.

Cito como dois exemplos comuns aplicações weblogic (que necessitam persistir o JSESSIONID) e aplicações RADIUS (que precisam persistir por called-station-id). Mas sinceramente, é possível persistir por uma infinidade de coisas, desde que você consiga desenvolver uma iRule que olhe o que for preciso. E é aí que a coisa pode ficar bastante complicada.

Se você não manja nada de iRules, temos uma série de três artigos fazendo uma introdução básica. O primeiro artigo você pode achar aqui.

Para provar que essa persistência é realmente universal, bolei um cenário maluco aqui da minha cabeça, que no mundo real talvez não faça sentido, mas que prova o ponto. Temos no laboratório um pool de servidores web, os clássicos SRV-GREEN e SRV-RED. Eles são nossos velhos conhecidos de outros artigos. O que fiz de diferente, foi configurar o Apache deles para inserir um header HTTP em cada um. No servidor SRV-GREEN, o header inserido é “servidor: srv-green” e no SRV-RED o header é “servidor: srv-red”.

A ideia é a seguinte: Quando o cliente enviar novas solicitações preservando esse header, a iRule verifica a tabela de persistência e o servidor é balanceado para o pool-member especificado.

Vamos começar olhando a iRule:

when HTTP_RESPONSE {
  if { [HTTP::header exists "servidor"] } {
    persist add uie [HTTP::header "servidor"]
  }
}
when HTTP_REQUEST {
  if { [HTTP::header exists "servidor"] } {
    persist uie [HTTP::header "servidor"]
  }
}

Dois eventos são avaliados: HTTP_RESPONSE e HTTP_REQUEST. No HTTP_RESPONSE, é avaliado se o header de nome “servidor” existe. Se existir, uma entrada de persistência é criada com o valor do header “servidor”. Já no evento HTTP_REQUEST, se o header “servidor” existir, a entrada da tabela com o valor do header será utilizada.

Agora em humanês: Quando o pool-member responder, olha o valor do header “servidor” e adiciona na tabela de persistência. E quando o cliente enviar tráfego, olha na tabela de persistência e, se tiver uma entrada com o valor, usa o pool-member anotado na entrada.

Muito bem. Depois de criada a iRule, você precisa criar um profile de persistência do tipo universal e especificar a iRule que você acabou de criar.

É interessante também especificar um timeout. Esse timeout é o tempo que a entrada na tabela de persistência será mantida.

Por fim, basta anexar o profile de persistência universal ao virtual-server da sua aplicação. Lembrando que você NÃO deve anexar a mesma iRule no virtual-server. A iRule é acionada via profile de persistência. Outro detalhe importante é que, para que o BIG-IP possa olhar o tráfego, ele pode precisar ir na camada da aplicação, então anexe os demais profiles necessários. No nosso exemplo, como a iRule procura por informações de header HTTP, precisei anexar também um profile HTTP no virtual-server.

Se tudo deu certo, na resposta do servidor, vemos o header “servidor: srv-xxx” presente.

O BIG-IP pega esse valor e adiciona na tabela de persistência.

Repare que o “Value” é o conteúdo do header na resposta, ou seja, “srv-red” para esse caso. Junto a esse valor, é anotado o pool-member associado, que no caso é 10.10.10.102 na porta 80.

A partir daí, se o cliente retornar com outras solicitações, mas que possuam dentro um header “servidor” com valor “srv-red” o BIG-IP sempre irá encaminhar para o pool-member 10.10.10.102 na porta 80.

Por fim, quando essa entrada atingir os 60 segundos de inatividade, ela será eliminada, respeitando o valor do timeout configurado.

Vamos ao vídeo de demonstração para não perder o hábito! Segura o carioquêxxx!

E é por isso que a persistência universal é a mais casca grossa de todas! Um verdadeiro canivete suíço! Vale lembrar que apesar de ser extremamente poderosa, a persistência universal pode ficar complexa muito rápido. Além disso, o uso de iRules que fazem diversos checks em um virtual-server muito acessado podem aumentar o consumo de CPU do seu equipamento, então use com cuidado e, se possível, valide tudo em laboratório primeiro.

O que vocês acharam da persistência universal? Viram como ela é poderosa? Este foi o terceiro e último artigo sobre persistências no BIG-IP. Fique ligado aqui no TechRebels para os próximos assuntos.

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