O pai ta on!!
Hoje
falaremos do virtual server (que na AWS chamamos de listener).
Nos
artigos anteriores, passamos por criação de nodes, monitors, pools, profiles e
persistências, e hoje criaremos o VIP que responderá pela aplicação.
Virtual Servers
Virtual
Servers é a “etapa final” da nossa receita de bolo. Obviamente o BigIP tem uma série
de parâmetros e funcionalidades que não abordamos, contudo com esses 5 passos
que postamos, é possível configurar um balanceamento sem problemas.
Existem
alguns tipos de virtuais servers, sendo o padrão, e o performance-layer4 os
mais comuns. A diferença base entre eles é que ao passo que o padrão (standard)
as características da conexão TCP podem ser alteradas, e no performance-layer4
elas são preservadas.
Na
prática isso significa que no standard podemos ter uma característica na
conexão cliente <> bigIP, e outra característica na conexão bigIP
<> pool-member. Assim poderíamos ter um MTU de 1500 na primeira conexão e
um de 9000 na segunda. No performan-layer4 todos os padrões de conexão são
‘espelhados’ entre as conexões, o que muitas vezes acaba sendo necessário para
a aplicação.
Para
a criação de um virtual server, dentro do ‘Local Traffic’, clique em ‘Virtual
Server’:
Na
tela de virtual servers list, clique em ‘Create…’
Detalhamento do virtual server
Nessa
etapa vincularemos tudo que já criamos no virtual server.
A
primeira ação é dar um nome para o VS, utilize o padrão: vs_(protocolo)_(serviço). Exemplo: vs_http_sagara
Source Address
Nesta
opção você vai colocar a rede que pode ‘usar’ este virtual server. Recomendo
fortemente que deixe com o ip e mask full (0.0.0.0/0), assim qualquer um pode
utilizar o serviço (filtro de pacotes é função do firewall, e não do
balanceador).
Destination Address
Aqui
colocamos o IP que teremos o virtual server. Este é o IP que o cliente vai
utilizar para a conexão. Obviamente é ele que deve ser adicionado em um DNS
como IP da aplicação.
Em
paralelo a AWS, esse seria o public-IP caso o ELB for internet-facing.
Service Port
Assim
como no destination address, aqui colocamos a porta que o bigIP vai responder
para a conexão, na grande maioria das vezes é a mesma porta do pool-member.
Note
que nesse caso podemos inclusive fazer um ‘PAT’, ou seja, externamente o
serviço ‘ouvir’ na porta 8080, e internamente falar com os servidores na porta
80.
Configuration Advanced
Esta
é a parte (ainda na mesma página) que vinculamos o profile http ao VS. Nesta
etapa também é possível vincular os profiles de SSL e TCP, o que também
possibilita trabalharmos com ssl-offload.
Source Address Translation
Este
é o método com que o bigIP vai utilizar para se conectar nas máquinas, e assim
repassar a conexão recebida.
Existem
basicamente 3 tipos: none, SNAT e AutoMap.
O
primeiro (none) o bigIP não toma nenhuma ação, de forma que o IP
de origem do cliente vai ser enviado como IP de origem para o servidor. Neste
tipo de implementação o bigIP atua como um tipo de proxy transparente,
com a diferencia que ele ainda vai manter as conexões do cliente e as conexões
do servidor. Para isso funcionar o bigIP PRECISA ser o gateway das máquinas.
O
segundo (SNAT), criamos um pool de IPs que o
bigIP vai utilizar para se conectar nos servidores. Esta opção é útil quando
você precisa de um ambiente escalável, pois no automap existe um limite de
65535 conexões no mesmo servidor. (limite do TCP). No SNAT pool, você pode colocar
quantos IPs for necessário para conexão com os servidores.
Por
fim temos o automap, onde o bigIP procura a melhor interface
(baseado na tabela de roteamento) para se conectar nos servidores. Esta opção é
boa quando o bigIP está na mesma rede dos servidores, de forma com que a
procura vai para a tabela de connected.
Resources
O
resource é a última relação que faremos com os itens criados. Nele vincularemos
o pool que criamos, assim como a persistência.
Após
vincular basta clicar em ‘Finished’.
Com
isso criamos nosso virtual-server. No nosso último arquivo testaremos o serviço
subindo uma aplicação web, e validando o balanceamento.
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.
