Diariamente as empresas têm investido cada vez mais em tecnologia em consequência da enorme demanda e a necessidade de manter seus negócios sempre no ar. A F5 Networks possui muito forte nesse cenário o BIG-IP, nele existem módulos que atendem às necessidades diversas. Uma delas é o módulo Local Traffic Manager ou LTM que é responsável por garantir a alta disponibilidade entre aplicações, ou seja, ele é um load balancer. Para que seja possível configurar o ambiente e balancear as conexões entrantes é necessário criar um virtual server.
Mas o que é Virtual Server? Como funciona cada tipo de virtual server? Estas são perguntas que todo administrador de rede faz quando existe a necessidade de utilizar o LTM para garantir a qualidade do serviço.
Neste artigo, serão explicados os tipos de virtuais servers existentes no BIG-IP – LTM e como cada um funciona. A partir daí você poderá analisar e tentar identificar melhor qual que responderá melhor em conjunto com a sua aplicação.
O virtual server é o caminho de entrada do cliente para a sua aplicação. Ele responderá por um IP e porta específicos, que quando acessados, direcionará a conexão do cliente de acordo com as instruções de configuração associadas a ele. Portanto, para cada tipo de tráfego, seja ele TCP, UDP, SSL, HTTP, teremos um grupo de configurações que poderão ser utilizadas para manipular o tráfego até que ele chegue ao seu destino.
Uma outra alternativa para manipular as conexões que passam por um virtual server, além das próprias configurações que estão disponíveis ao escolher cada tipo de VS ou protocolo, é associar uma Irule, que nada mais é que um script baseado na linguagem TCL (Tools Command Language).
Existem os seguintes tipos de virtual server: Standard, Forwarding (Layer 2), Forwarding (IP), Performance (HTTP), Performance (Layer 4), Stateless, Reject, DHCP Relay e Internal, cada um com a sua particularidade e funcionalidade.
A seguir, descreveremos como cada um funciona:
- Virtual Server: Standard
O virtual server Standard tem como principal funcionalidade o balanceamento direto das conexões. Quando configurado com um profile TCP, o sistema operacional do BIG-IP, o TMOS, habilita a arquitetura Full Proxy.
Na arquitetura Full proxy, quando o cliente faz uma requisição a uma aplicação, é fechada uma comunicação a princípio com o virtual server e, após esta conexão estabelecida, o BIG-IP abre uma nova conexão com o servidor do pool para qual esta conexão foi balanceada. Este comportamento pode variar de acordo com o tipo do profile associado ao virtual server. Desta forma, podemos levar como premissa que para que um virtual server standard funcione de maneira adequada deve-se adicionar a ele um profile, seja ele TCP ou UDP, e opcionalmente pode ser configurado com profiles HTTP, SSL – cliente/server – ou FTP de acordo com a sua aplicação.
Abaixo está um diagrama de como a comunicação funciona em algumas situações:
– Virtual Server Standard com profile TCP
Conforme pode ser visto na imagem abaixo, quando o cliente faz uma requisição a conexão TCP ocorre primeiramente com o BIG-IP, ou seja, o Three-Way Handshake com o virtual server, após a conexão estabelecida, o LTM fecha uma nova conexão TCP com o pool member (Servidor).
Imagem01 – Diagrama conexão VS com profile TCP
– Virtual Server Standard com profile HTTP
Quando utilizado com um profile HTTP, por exemplo, a comunicação full proxy é alterada e antes de o big-ip abrir uma comunicação com o servidor de aplicação, o cliente envia o GET para o BIG-IP, que responde com um ACK. Após isto, toda a comunicação é refeita do lado do servidor. Portanto, o big-ip fechará o Three-Way Handshake com o servidor e repassará o GET para o servidor, como pode ser visto na Imagem02:
Imagem02 – Diagrama com o VS com profiles TCP e HTTP
Comumente, um virtual server em modo standard é utilizado para aplicações Web devido sua facilidade em manipular estes tipos de protocolo. Além disso permite o SSL Offload, que consiste no virtual server atrelado a um profile ssl com um certificado que corresponde ao Sudject Name da aplicação ao invés deste estar no servidor, livrando-o de processar as requisições criptografadas e consequentemente poupando recursos de hardware.
- Virtual Server: Forwarding (Layer 2)
O virtual server Forwarding Layer 2 é responsável por receber a requisição do cliente e direcioná-la para um node especifico, o qual o virtual server pode compartilhar do mesmo IP, e executar o encaminhamento baseado nas rotas pré-estabelecidas. Vale lembrar que este tipo de virtual server não possui pool e não tem como funcionalidade o balanceamento de requisições como virtual server standard. Este tipo de virtual server, assim como os demais, possui configurações que possibilitam ao administrador manipular o tráfego de acordo com a necessidade, além de aceitar ser possível associar Irules.
A seguir, podemos enxergar como este VS funciona e como a requisição do cliente chega ao seu destino:
Imagem03 – Diagrama de comunicação do virtual server Forwarding Layer 2.
- Virtual Server: Forwarding (IP)
O Forwarding IP tem a funcionalidade semelhante ao virtual server Forwarding Layer 2, não possui pool de servidores, portanto, não tem como característica o balanceamento das conexões entrantes, e sim processar as conexões pacote por pacote encaminhando-a ao seu destino. Geralmente é utilizado quando precisamos de um virtual server de trânsito ou forward, ou seja, todas as conexões de alguma forma passam pelo big-ip. Desta forma se faz necessário criar um meio para que as conexões que não tem destino um virtual server especificamente, passem pelo big-ip e atinjam o seu destino baseado nas rotas e do default gateway. Isto vai depender muito da topologia utilizada pelo administrador e como os elementos da rede estão ligados logicamente.
Ao observar a imagem abaixo, vemos que assim como no virtual server Forwarding Layer 2, o virtual server Forwarding IP encaminha o tráfego diretamente ao seu IP de destino, sem fazer o full proxy.
Imagem04 – Diagrama de comunicação do virtual server Forwarding IP.
- Virtual Server: Performance (HTTP)
O virtual server Performance HTTP, tem como principal objetivo melhorar as requisições http para determinada aplicação quando atrelado com o profile Fast HTTP, além de reduzir a quantidade de conexões do lado do servidor da aplicação. Para garantir uma melhor experiência para o usuário, podemos, além do profile Fast HTTP, adicionar um profile OneConnect, que tem como objetivo manter um canal de comunicação aberto para que futuras conexões o reutilizem, fazendo com que a comunicação seja realizada de forma mais rápida.
Como funciona este virtual server? Ele garante que o big-ip estabeleça uma comunicação com os servidores antes de haver uma conexão de um cliente, portanto, quando um cliente faz a requisição, o virtual server utiliza a sessão já estabelecida, que está como “idle” do lado do servidor, e a marca como “no idle” e envia requisição realizada pelo cliente para o pool member.
A seguir pode se ver como esta estrutura funciona:
Imagem05 – Diagrama de conexão utilizando o virtual server Performance HTTP
Caso esta conexão idle não seja encontrada o big-ip criará uma nova conexão e encaminhará a solicitação do cliente para o pool member seguindo o fluxo de balanceamento.
- Virtual Server: Performance (Layer 4)
Assim como os virtual servers Forwarding (Layer 2) e Forwarding (IP), o virtual server Performance (Layer 4) utiliza o profile fastl4. Neste profile, temos a opção de configurar o PVA Acceleration, que é possível devido ao hardware do big-ip que possui um chip para aceleração. A tecnologia PVA ASIC (Packet Velocity ASIC) tem como característica, além da aceleração, a proteção contra ataques DOS e 3 formas de aceleração: Full Acceleration, Partial Acceleration e No Acceleration (None). Porém, cada uma delas funcionará de acordo com as demais configurações existentes no virtual server. Abaixo, falaremos um pouco sobre cada um:
– Full Acceleration: Este modo não é compatível com features de Layer 7, portanto, persistência por cookie e inserção cabeçalho não são otimizadas por ele. Este modo vai trabalhar somente com virtual server que operam com IP e Porta.
– Partial Acceleration: Os pacotes são primeiramente processados via software e depois acelerados, neste caso, o software definirá qual pacote será acelerado de acordo com o que for ou não da Layer 4.
– No Acceleration(None): Nenhum trafego é acelerado.
O virtual server de Performance (Layer 4) trabalha da seguinte forma: Ao receber uma conexão TCP do cliente, o virtual server encaminha pacote por pacote para o destino, no caso, os servidores que estão no pool. Portanto, podemos dizer que quando o virtual server recebe um SYN ele repassa esse mesmo SYN para o servidor balanceado sem fazer o full proxy.
- Virtual Server: Stateless
O virtual server do tipo Stateless garante performance quando configurado para balancear tráfegos de protocolo UDP, que em alguns casos, necessita de um processamento high level.
Quando recebe um determinado tráfego, a conexão é removida da tabela de conexão, sendo assim, este tipo de VS não é adequado quando se faz necessário balancear um tipo de tráfego que necessita de rastreamento de estado como o protocolo TCP.
Este virtual server possui algumas limitações que não encontramos em um virtual server standard, por exemplo:
– Não é possível atrelar Irules à um virtual server stateless;
– Não é possível realizar a configuração de Connection Mirroring, que garante que as mesmas conexões de um determinado virtual server ou interface, seja replicada para o equipamento em Standby;
– Não é possível realizar a configuração de Rate Shaping;
– Não é possível configurar persistência;
De acordo com o fabricante, os melhores cenários para configuração de um VS stateless é no balanceamento de um tráfego de syslog para um pool onde estão os servidores de syslog e no balanceamento de queries DNS, que são necessariamente realizadas através do protocolo UDP.
- Virtual Server: Reject
Basicamente, este virtual server tem como objetivo rejeitar todo e qualquer tráfego que seja direcionado a ele, portanto, ao tentar realizar um Three-Way Handshake e enviar um SYN, imediatamente o big-ip devolverá um reset da conexão para o cliente.
- Virtual Server: DHCP Relay
Quando uma máquina é ligada, ela envia um broadcast para toda a rede procurando um servidor de DHCP disponível para adquirir um endereço IP. Ao receber esse broadcast, o servidor DHCP informa ao dispositivo que está disponível e o dispositivo faz a requisição de um endereço IP para o servidor que por sua vez verifica sua tabela de endereçamento, e disponibiliza um IP livre para o dispositivo. Em um ambiente complexo, com uma rede segmentada por vlans, se o dispositivo estiver em uma vlan e o servidor de DHCP em outra, não será possível essa comunicação. É aí que entra o virtual server de DHCP Relay que, além de balancear as requisições, faz com que seja possível que um dispositivo em uma vlan X possa chegar a um servidor de DHCP que está na vlan Y. Como podemos visualizar na estrutura abaixo:
Imagem06 – Estrutura de comunicação virtual server DHCP Relay
Na estrutura acima, o cliente está na rede 192.168.106.0/24 e envia um broadcast através do virtual server do big-ip que por sua vez balanceia o tráfego para um dos servidores de DHCP do pool.
- Virtual Server: Internal
O Virtual Server Internal pode ser configurado para receber requisições e/ou respostas e encaminhá-las para um pool de servidores ICAP(Internet Content Adaptation Protocol ), utilizado normalmente em servidores proxy e para integração serviços, como filtros URL e Software antivírus.
O virtual server internal só pode ser acessado por um virtual server standard. Portanto, ao receber uma conexão, o virtual server standard encaminha o tráfego que necessita de adaptação de conteúdo para o virtual server internal que por sua vez balanceia e encaminha a conexão para o pool de servidores ICAP. Após o conteúdo ser processado pelos servidores do pool ele retorna para o virtual server standard para seguir o fluxo de comunicação.
O BIG-IP Local Traffic Manager é um módulo todo voltado para garantir a alta disponibilidade e desempenho das aplicações críticas de um ambiente e, neste artigo, pode se observar e entender um pouco de cada virtual server e para qual finalidade cada um foi criado, quais são suas particularidades e como o tráfego passa por ele para atingir o objetivo do administrador da aplicação.