O pai ta on!!
Dando continuidade à série de artigos sobre balanceadores, onde ja vimos como instalar um balanceador, como criar os nodes e monitors, e como vincular ambos em um pool, onde temos a junção de um node com uma porta de serviço (conhecido como pool-member).
Hoje daremos mais um passo e falaremos sobre profiles (que é onde conseguimos mexer em alguns parâmetros de TCP/HTTP e etc.) e persistências (que é como o bigIP vai garantir que sua conexão cai no mesmo servidor).
Profiles
Dentro do ‘Local Traffic’, clique em ‘Profiles’:
Existem vários tipos de profiles, desde HTTP, passando por web acceleration, indo até a TCP e SSL. Por conta do bigIP ser um full proxy ele é capaz de alterar os parâmetros dos protocolos que passam por ele, para assim otimizar a conexão. Os profiles são um método de estes alterar parâmetros.
Podemos então por exemplo, alterar o timeout de uma sessão HTTP, alterar o janelamento do TCP, e inserir informações no header.
Neste exemplo criaremos um profile HTTP, pois utilizaremos persistência no modo de coockie, e ter um profile HTTP é mandatório para isso.
Dentro de profiles, vá em “services”, e depois clique em HTTP:
Detalhamento do profile HTTP
De um nome para o profile (inicie com prof_http_(serviço)):
X-forwarded-for
O XFF é um recurso do HTTP, onde mantemos o IP de origem no header do HTTP. Esta opção é extremamente último quando a aplicação precisa ter rastreabilidade da conexão (aplicações de banco por exemplo). Como isso não influencia em nada no balanceador, recomendo deixá-la habilitada.
Profile Persistência
A persistência de sessão é uma característica do bigIP que garante que com base em alguns parâmetros a conexão sempre caia no mesmo servidor. Este tipo de característica é importante para casos que a aplicação trata algumas informações localmente (um carrinho de compras por exemplo).
Sem ela, se o cliente abrir uma conexão, cairia no server01, colocar 3 itens no carrinho de compras, e atualizar a página por exemplo, cairia em outro servidor e o carrinho de compras estaria vazio.
Existem vários tipos de persistência, sendo as mais usadas o cookie, que a persistência baseada em uma informação de cookie que o bigIP insere no navegador. E a source_addr, que é a persistência baseada no IP de origem da conexão.
Aqui se formos fazer o paralelo com a AWS, o mais próximo que o ELB pode fazer é o Stickiness, que é basicamente uma implementação da persistência por coockie, contudo não vejo isso como uma limitação. Em uma aplicação descentralizada, podemos ter o gerenciador de sessões em um dynamoDB, ou em um Redis. Utilizar persistências na prática (sob meu ponto de vista) acaba sendo um limitador de escalabilidade, uma vez que uma vez persistido a conexão, deleta-la significa necessariamente finalizar a sessão do usuário.
Cada uma tem sua particularidade, mas como regra geral se a aplicação for HTTP use coockie se for outra, ou use o sourceIP ou nenhuma persistência.
Persistência por cookie
Dê um nome para a persistência, iniciando com: pers_(tipo-da-persistência)_(serviço).Exemplo: pers_ck_sagara
Cookie Name
Esta opção é onde colocamos o nome do cookie que iremos inserir no browser. Esta informação é pode ser visualizada inclusive no browser pelo aplicativo: BIGIP Cookie Decoder, disponível na loja de aplicativos do chrome.
Expiration
Este é o tempo que o bigIP espera para ‘matar’ a sessão ativa (desde que ela não tenha tráfego). Por padrão o bigIP respeita as sessões da aplicação, contudo é possível alterar estes dados (vide exemplo abaixo):
Tempos de sessão default
Por padrão o apache possui um timeout de 300 segundos (5min), e o IIS possui um timeout de 20min.
É importante saber os temos default de cada servidor, pois caso você não altere o expiration no balanceador ele vai assumir
este tempo de persistência, e isso é MUITO importante.
Já tive um problema em que o usuário solicitava um relatório que era gerado em um banco de dados, contudo este relatório demorava uns 40min para ser gerado. Assim quando o usuário pedia o relatório, dava 5min a página era ‘atualizada’.
Isso acontecia justamente porque o tempo de timeout do apache tinha chegado ao limite. Resolvi o problema aumentando o tempo de timeout no bigIP.
Espero que tenham gostado!! No próximo artigo criaremos o virtual-server, e falaremos um pouco sobre estatísticas e tshoot.
That’s all folks! Be Happy!!!
thiago.marques@darede.com.br
Technical Account Manager da Darede, formato em Rede de Computadores, e pós graduado em Segurança da Informação. Possui ampla experiência em Datacenters e Service Providers, além de ser um entusiasta em DevOps e mercado financeiro.
