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
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
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!!!
Technical Account Manager da Darede, formado 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.
