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.
