O pai ta on!!
No último artigo falamos sobre como criar os Nodes, que são os servidores reais, e os Monitors, que são basicamente a forma com que o bigIP vai validar se um serviço está ou não no ar.
Hoje falaremos de como vincular ambos em um grupo que é chamado de pool.
Pools
Pools são agrupamentos dos nodes
que criamos, adicionando a porta do serviço. Em Nodes fazemos a representação
lógica do servidor, e nos pools a representação lógica do serviço interno.
Imagine o cenário onde possuímos
um frontend web que é suportado por 2 nodes (servidores), ambos
funcionando no apache na porta 80. Em Nodes, cadastraríamos esses dois
servidores, e em pools cadastraríamos os nodes configurados + a porta TCP do
serviço.
Essa junção de NODE+PORTA é
chamada de Pool-Member:
Em comparação com a AWS, o Pools
seria o target group.
Para configurar, dentro do ‘Local
Traffic’, clique em ‘Pools:
Em pool-list clique em
“Create…”:
Detalhamento do pool e pool-member
Existem diversas opções para
configurar / alterar no pool, contudo vamos passar apenas pelas principais.
De um nome para o pool (inicie
com pool_(protocolo)_(serviço)). Exemplo:
pool_http_sagara
Health Monitors
O health monitor é o campo onde
vinculamos o monitor criado com o pool, ou seja, o bigIP vai utilizar o que
estiver nesta lista para validar se o pool-member está no ar ou não.
Caso você coloque mais de um
monitor nesta lista, o balanceador assume a lógica AND, ou seja, APENAS se os
TODOS os monitors estivem fora ele considera como down.
Action on service down
Esta opção por padrão vem como
‘none’, ou seja, o bigIP não toma nenhuma ação caso um serviço fique down.
Contudo não é o que recomendo, uma vez que isso significa que caso um
pool-member fique indisponível, o cliente vai precisar abrir outra sessão TCP
com o balanceador, o que significa algumas vezes um disconnected para
o cliente.
A opção que recomendo neste caso é
utilizar o ‘Reselect’.
Resources
Ainda na mesma página temos a
parte de resources, que é basicamente onde colocamos o método de
balanceamento e os servidores com as portas.
Aqui eu abro parênteses para uma
das principais diferenças entre ter um serviço de balanceamento (como o ELB) e
um balanceador: os métodos de balanceamento.
Na AWS até 2019 existia apenas o round
robin, e no reinvent:2019 lançaram o least outstanding request. Em
um balanceador como o BigIP, por exemplo, temos desde métodos estáticos (como é
o caso do round robin), dinâmicos (least connections), e até híbridos
com scripts. Por padrão o método de balanceamento é o round robin,
que vai ser eficiente dependendo da aplicação. Recomendo fortemente a
utilização do “Least Connections (member)”, que basicamente faz
balanceamento para o pool-member que tem menos conexões.
Após escolher o método de balanceamento,
iremos adicionar o node que criamos no passo 01. Para isso basta clicar em
‘Node list’, selecionar o servidor e colocar a porta do serviço.
É importante ressaltar que a porta
do serviço aqui é a que está aberta no servidor, e não necessariamente a que
será aberta para o virtual-server. Isso é importante em casos que é utilizado
JVMs, onde cada JVM utiliza uma porta específica, mas o serviço responde para a
porta 80 para o mundo externo.
Clicando em “Finished”, teremos
criado o pool:
É possível ver que ele está
com status com uma bolinha verde, o que significa que ao menos
1(um) pool-member está no ar. Caso queria ver detalhadamente todos os
pool-members, clique no nome do pool, e depois em ‘members’:
Com isso terminamos de configurar
o pool, e caso queria adicionar mais servidor a ele basta clicar em ‘Add…’.
No próximo artigo falaremos sobre Profiles e Persistências!!
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.
