«

»

fev 16 2016

Application Delivery Controllers (ADCs) e Application Delivery Networks (ADNs) – Parte 1

Conforme prometido, aqui vai o primeiro post (de uma série de 3 que pretendo escrever) tratando de application load balancers. No último, pretendo ilustrar como criar um lab sobre o tema, integrando roteadores Cisco e load balancers F5 BigIP. Vai valer a pena, esperem para ver 🙂


 

O que são ADCs?

Há muitos e muitos anos que ADCs exercem um papel fundamental no delivery de serviços online. E – ainda bem – quase ninguém sabe da existência deles. Antes de serem conhecidos como ADCs, chamavam-se apenas “load balancers” – ou balanceadores de carga. O conceito por trás destes elementos é relativamente simples: Intermediar requisições no lado cliente e, no lado servidor, distribuí-las à um grupo de servidores que operam de forma sincronizada. A vantagem em se fazer isso? São várias:

  • Performance
  • Eficiência
  • Resiliência
  • Uso mais inteligente dos servidores – o que resulta em um menor TCO (total cost of ownership)
  • Escalabilidade

Eu comecei a trabalhar efeitivamente com ADCs há cerca de 1 ano. Antes disso, apenas sabia de sua existência, mas tinha pouca – para não dizer nenhuma – experiência com eles. E, admito: Trabalhar com eles me fascinou. ADCs são um grande desafio para quem vem da área de redes, unicamente. E, mais adiante, vou lhes explicar porque.

Voltando para o tema… e como funcionam estes elementos? Como eu disse, a idéia por trás dos ADCs é relativamente simples. Se formos decompor o processo em etapas, temos basicamente 3 delas:

  1. Requisição do cliente chega a um “listener” configurado no ADC. O ADC e o cliente estabelecem uma conexão L4 (normalmente, TCP, mas pode ser UDP) e o cliente tem a certeza que o ADC é o destino final de sua solicitação – ou seja: O ADC age como um proxy.
  2. O ADC – por meio de métodos de decisão previamente configurados – identifica quais servidores possuem o serviço procurado pela requisição do cliente e, com base em um algoritmo de decisão, seleciona um destes servidores.
  3. O ADC encaminha a requisição para o servidor escolhido e aguarda a resposta – ou seja: O servidor enxerga o ADC como o cliente (novamente, a figura do proxy em ação). Uma vez que a resposta seja encaminhada pelo servidor, o ADC se encarrega de encaminhá-la de volta ao solicitante original.

A figura abaixo ilustra um exemplo simples de implantação de um destes elementos.

adc

Os hosts (H1 e H2) conectam-se ao ADC apontando seus programas clientes (navegador Web, por exemplo) para o endereço IP do “listener” configurado (em ADCs, estes elementos são comumente chamados de Virtual Servers, ou VS). A conexão TCP é fechada entre o host e o ADC que, por sua vez, seleciona um dos servidores disponíveis no pool associado ao VS, abre uma nova conexão TCP com o servidor escolhido e encaminha a requisição para ele.

Para que isso possa funcionar à contento, o ADC normalmente realiza um processo de tradução do endereço IP de destino original (o do VS) para o endereço IP do servidor escolhido. Portanto, a resposta do servidor, neste caso, PRECISA retornar pelo ADC, do contrário, a tradução não será desfeita e o host receberá uma resposta originada por um endereço IP que ele não conhece (ou não está esperando), ocasionando falha na comunicação. Este tipo de problema é conhecido como “asymmetric routing”, e pode ser facilmente corrigido via 2 opções:

  1. Configurando os servidores para usarem o ADC como default gateway, forçando o tráfego de retorno para eles (nem sempre isso é possível)
  2. Implementando-se a tradução do endereço IP de origem para algum endereço IP que pertença ao ADC (Source NAT ou SNAT). Este artifício resolve o problema de roteamento, mas pode causar problemas adicionais. Por exemplo, os servidores agora passarão a ver milhares de conexões sendo originadas pelo mesmo endereço IP, o que pode não ser interessante para alguns tipos de serviços. Troubleshooting com SNAT é também mais complexo do que sem ele. Enfim, é preciso certificar-se que a ativação do SNAT não irá causar problemas.

Fluxos e SNAT

A figura abaixo ilustra o que foi discutido anteriormente.

snat

Por hoje, ficamos por aqui. Eu vou seguir esta série de posts e, se for preciso mais de 3, podem ficar tranquilos que eu vou criando e postando 😉

Espero que tenham gostado deste primeiro, apesar de ser bem introdutório e mais básico. Mas, vamos complicar… aguardem 🙂

Marco Filippetti



Comente usando o Facebook!
6
0

6 comentários

Pular para o formulário de comentário

  1. Marcelo Gois Souza

    Marco,

    Belo post inicial! Aguardo os próximos posts mais complicados! 🙂

    Obrigado por compartilhar.

    Gois

    2

    0
  2. rogerio.telecom

    Marco. Mais uma vez o seu post vem nos esclarecer de forma objetiva o que parece ser uma “caixa preta”. Já faz certo tempo

    2

    0
  3. Marco Filippetti

    E vamos complicar um pouco mais 😉 Valeu pessoal!

    1

    0
  4. rogerio.telecom

    Marco. Mais uma vez o seu post vem nos esclarecer de forma objetiva o que parece ser uma “caixa preta”. Já faz certo tempo que ouço falar sobre os balanceadores de carga F5, mas não tinha ideia nem do funcionamento básico. Espero que você possa logo escrever os outros posts sobre o assunto e aguardo o lab integrando routers cisco e os load-balancers. Por fim: Parabéns pelo seu post!!!

    3

    0
  5. Clayton Coelho

    Parabéns Marco pelo post. Muito bom. Trabalho com F5 a quase 5 anos, e são bem poucos blogs q abordam o assunto.
    Abs

    1

    0
  6. santos_ligeiro

    Parabéns pelo Post Marco aqui na Empresa existe F5 e já estou envolvido em alguns projetos que envolve ADC essas dicas irão ajudar muito.

    Obrigado !!

    Att,
    Santos

    0

    0

Deixe uma resposta