Loucuras de Verão com iRules — Parte 3

Syn, syn-ack, ack…

Fala pessoal!! Sejam bem vindos à parte 3 (e talvez a última) da nossa série sobre iRules! Você pode encontrar todos os meus posts de F5 publicados aqui no TechRebels 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 último artigo da nossa série sobre iRules vimos as condições “if” e “else”, e como elas podem ser utilizadas para dar mais inteligência para todo o processo. Hoje, como prometido, vamos ver as famosas variáveis!

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

As variáveis no mundo BIG-IP nada mais são do que espaços na memória do equipamento que armazenam uma dada informação. Essa informação pode ser um número inteiro, uma string e assim vai. Depois que esse espaço em memória é preenchido, você pode utilizar o conteúdo para fazer uma comparação e tomar uma decisão na sua aplicação.

A grande polêmica que gira em torno das variáveis no mundo iRules é o escopo delas: local, global ou global estática!

Local → A variável existe somente dentro do TMM que a criou e em tempo de execução da iRule. Quando o evento da iRule é finalizado, a variável local também é encerrada. A consequência disso é que uma variável local não pode ser “reutilizada”.

Global → O nome global faz referência à linguagem TCL, porém no mundo BIG-IP é global somente dentro da instância do TMM que a iRule existe, ou seja, enquanto a iRule existir, a variável global estará carregada na memória. Por conta disso, variáveis globais causam o rebaixamento do CMP do virtual-server. Falaremos mais sobre isso em breve!

Global Estática → Assim como uma variável global, a global estática existe no contexto global da linguagem TCL, porém não causa o rebaixamento do CMP. Efetivamente uma cópia dessa variável é feita para cada processo do TMM (no momento da compilação da iRule), mas em casos de alteração em tempo execução, somente a cópia dentro do TMM que a executou é alterada.

Se esses tipos todos não disseram muita coisa para você, tudo bem. Nos exemplos vamos clarear isso. Segura um cadinho! ;)

A polêmica está na consequência de se utilizar uma variável global. Quando você cria uma variável global em uma iRule e anexa essa iRule a um virtual-server, você efetivamente está realizando o “rebaixamento” do VS para não-CMP.

Viajou na maionese? Sem problemas! Vamos viajar no tempo, lá para o primeiro artigo que postei aqui no TechRebels!

Lá aprendemos que o BIG-IP é uma aplicação como qualquer outra que roda em um servidor Linux! Essa aplicação é chamada de TMM. E nos appliances com múltiplos CPUs (assim como em VMs com múltiplos cores), o que acontece por trás dos panos é que o Linux sobe um TMM por core de CPU:

Dessa forma, em um appliance com oito cores, você teria 8 instâncias de TMM. Essas 8 instâncias do TMM trabalham em conjunto para atender todas as requisições que chegam ao BIG-IP. Assim que o fluxo chega ao BIG-IP, a carga entre processos do TMM é dividida. Isso resulta em uma distribuição das requisições entre os oito CPUs do equipamento. Vamos checar isso na nossa VM aqui do laboratório, que tem apenas 2 cores!

Através do comando “show sys cpu” podemos ver que de fato temos duas CPUs — CPU-0 e CPU-1. Agora vejamos os processos do TMM.

Com o “show sys tmm-info” vemos também dois processos do TMM — TMM0.0 e TMM0.1. Observe que para o processo TMM0.0, o CPU ID é o 0 e para o TMM0.1 o CPU ID é 1. E é isso mesmo que você está pensando! Tudo que é atendido pelo TMM0.0 é processado no CPU-0 assim como tudo que é recebido pelo TMM0.1 é processado pelo CPU-1.

Dito isto, normalmente, todo virtual-server é CMP, ou seja, um fluxo ao atingir o VS é distribuído entre todos os processos TMM e consequentemente pode estar sendo distribuído por todas as CPUs do equipamento. Já um virtual-server que é não-CMP será sempre atendido pelo mesmo processo do TMM, que por sua vez fica “preso” ao mesmo CPU… E, obviamente, isso é muito ruim em termos de desempenho!

Não pense nessa distribuição entre processos TMM como o resultado do algoritmo de balanceamento utilizado no pool. Não é a mesma coisa. O algoritmo de balanceamento é para seleção do node. O CMP é no nível de arquitetura interna do BIG-IP mesmo, para a correta utilização de todos os CPUs da caixa.

De volta para o assunto em questão: variáveis globais!

Quando você utiliza em uma iRule uma variável global, o que acontece é que, assim que você anexa a iRule no virtual-server, o BIG-IP realiza o rebaixamento do virtual-server para não-CMP. Inclusive uma mensagem de log é anotada no /var/lo/ltm, vejam:

A partir desse momento, qualquer tráfego atendido pelo VS em questão será sempre processado pelo mesmo TMM/CPU do equipamento. E se por acaso esse virtual-server em questão receber muito tráfego, a sua aplicação pode acabar sofrendo uma lentidão muito grande pois efetivamente está sendo atendida por um BIG-IP mono-CPU! =D

Feito esse pequeno desvio no tempo-espaço, vamos aos nossos testes! A topologia do nosso lab continua a mesma:

Começando então pelas variáveis locais, vejamos o primeiro exemplo:

Vamos analisar linha a linha dessa iRule…

1. Evento CLIENT_ACCEPTED, ou seja, assim que a conexão no VS for aceita, executaremos os comandos seguintes.
2. Atribuição da variável chamada varlocal. É atribuído o valor “0” para ela.
3. A variável varlocal é acrescida de +1.
4. É logada uma mensagem no /var/log/ltm. Essa mensagem informa qual o IP do cliente, em seguida é informado qual o processo TMM que recebeu esse tráfego e por último é exibido o valor atual da varlocal.

Vamos ao vídeo! Vão ter que aturar o sotaque de Cariocaxxx! =D

Agora vamos ver o exemplo de uma iRule com variável global!

Vejamos linha a linha…

1. RULE_INIT é o evento que é executado no momento de compilação da iRule. É importante ressaltar que toda variável declarada dentro desse evento automaticamente passa a ser uma variável global. Uma outra forma de detectar que uma variável é global é pelo prefixo “::” antes do nome.
2. Declaração da variável “::varglobal” para o valor 0.
3. Na linha 5, evento CLIENT_ACCEPTED padrão.
4. Linha 6, novamente é feito o incremento de +1 na variável “::varglobal”.
5. E por fim, na linha 7, o comando para exibir a mensagem de log no /var/log/ltm da mesma forma que antes, mostrando o IP do cliente, o ID do TMM que processou o tráfego e por último o valor da variável “::varglobal”.

Vamos ver essa iRule em funcionamento no lab!

Por último, mas não menos importante, vamos ver uma variável global estática.

Linha a linha temos:

1. Evento RULE_INIT para a declaração.
2. O comando “set” atribuindo a variável global estática. Toda variável estática tem como prefixo “static::”. Foi atribuído o valor zero.
3. Na linha 5 o evento CLIENT_ACCEPTED padrão.
4. Na linha 6, o comando de incrementar a variável global estática em +1
5. E finalizando, na linha 7, o comando para logar no /var/log/ltm as nossas informações de interesse.

Vamos ao terceiro vídeo de demonstração!

Então resumindo…

1. Variáveis locais existem somente dentro do contexto de execução da iRule e garantem a utilização do CMP, porém não podem ser re-utilizadas em novas sessões pois seu conteúdo é zerado ao final da execução.
2. Variáveis globais existem dentro do mesmo contexto da iRule, porém ficam “presas” dentro do mesmo processo do TMM, rebaixando o virtual-server para não-CMP. Seu conteúdo, porém, é mantido atualizado para novas sessões que utilizem aquela mesma iRule.
3. Variáveis globais estáticas existem também dentro do contexto da iRule e uma cópia delas é feita para cada processo TMM disponível, mantendo o CMP ativo para o virtual-server, porém, quando são modificadas, essas atualizações não chegam para seus “clones” nos outros TMMs, ou seja, é introduzida uma dessincronização dos valores dessas variáveis perante suas cópias dentro de cada TMM.

Pode parecer besteira, mas esse pequeno detalhe de arquitetura do TMM pode causar um transtorno enorme. Inclusive já vi ambientes se arrastando por conta do uso de iRules com variáveis globais, então muito cuidado.

Nossos estudos sobre iRules a princípio terminam por aqui. Minha ideia não é abordar cada comando ou evento das iRules pois eles são muitos, mas apresentar a vocês o básico e encorajá-los a pesquisar e testar essa ferramenta! Se você acredita que eu poderia ter abordado alguma outra coisa, deixe um comentário! Se for o caso eu faço uma parte 4!

Links Úteis
https://devcentral.f5.com/s/articles/irules-101-01-introduction-to-irules
https://clouddocs.f5.com/api/irules/
https://support.f5.com/csp/article/K13033

Continuem ligados aqui no TechRebels para os próximos artigos! ;)

O que acharam? Gostaram desse novo formato com pequenos videos? Ficaram com alguma dúvida? Não deixe de comentar! Os comentários 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 F5 Solutions Expert Security, 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