«

»

fev 21 2016

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

Antes de começar, aproveito para informar que no dia 23-02 (próxima 3a) teremos uma promoção relâmpago no site da CloudCampus, com descontos de 50% em vários de nossos cursos! Aproveitem, é apenas no dia 23-02 (à partir das 00:00hs)!


 

Como prometido, vamos em frente com a série de posts sobre ADCs e ADNs. Sempre complicando um pouco mais, a cada passo… 🙂

PS: Como referência, a parte 1 do artigo pode ser encontrada em: http://cldcmp.us/1VkVjfi

Vamos começar falando de terminologia. Eu vou usar como referência o fabricante F5 Networks, por dois motivos bastante simples:

  1. A F5 é líder no mercado de ADCs e
  2. Além de ser sócio da CloudCampus, eu também trabalho na F5 Networks como instrutor sênior 🙂

Antes de nos aprofundarmos no tema, é preciso conhecer alguns elementos e terminologias. Vamos a eles:

  • ADC – Application Delivery Controller (os elementos que fazem o balanceamento de carga para os servidores de aplicações)
  • ADN – Application Delivery Network (o conjunto de elementos – incluindo os ADCs – necessários para distribuir solicitações para um grupo de servidores.
  • Node – No mundo de redes, um node identifica um elemento de camada 3 (como um router, por exemplo). No mundo dos ADCs, um node e a referência feita ao endereço IP associado ao serviço / aplicação. Por exemplo: Se você tem um servidor WEB configurado como 172.16.10.1:80, o node, neste caso, é 172.16.10.1.
  • Host – Refere-se ao elemento que gera a solicitação. O lado cliente da conexão.
  • Member – Nome dado à associação do Node à uma porta lógica (TCP ou UDP), que acaba por definir o serviço em si. Também é chamado de SOCKET ADDRESS na área de programação. Por exemplo,172.16.20.1:80 identifica um Member no mundo dos ADCs.
  • Pool – Um conjunto de members que referem-se a um mesmo serviço. Observe que “mesmo serviço” não necessariamente significa mesma porta lógica. Por exemplo: um Pool pode ter 3 membros definidos como 172.16.20.1:80, 172.16.20.2: 8080 e 172.16.20.3:81. Porém TODOS eles devem estar configurados (e sincronizados) para responder ao mesmo tipo de requisição (uma requisição HTTP, no exemplo). Assim, não interessa ao ADC a porta, desde que o serviço esteja devidamente configurado.
  • Virtual Server – É o ponto de contato dos Hosts com o serviço sendo balanceado pelo ADC. Normalmente é definido por um endereço IP público e porta lógica, mas pode ser também um endereço de rede ou mesmo um wildcard (qualquer rede / porta). Veremos algumas possibilidades mais adiante.

Existem muitos outros elementos e definições, mas estas são as principais para começarmos. Como eu expliquei no post anterior, há um fluxo que deve ser seguido sempre que um ADC encontra-se “no meio do caminho”. Vamos supor que você queira publicar um blog (como este). E que, devido à elevada demanda, é importante zelar pela disponibilidade e performance do mesmo. Afinal, você não quer ver seus leitores recebendo páginas com alto delay, ou mesmo erros de servidor. Então, você configura 2 servidores Linux Ubuntu rodando Apache na porta 80, com exatamente o mesmo conteúdo – um é espelho do outro. A única coisa que muda, claro, é o endereço IP de cada servidor.

Algo como ilustrado abaixo:

figura1

Tenho certeza que algum de vocês vai dizer “Peraí, mas estes caras estão usando endereços IP privados… não vai dar para criar um serviço para o público geral assim…!“. E eu respondo: Calma, amigos… calma! Vamos em frente…!

Bom, temos agora que criar os elementos em nosso ADC. Para efeitos de exemplo, vamos usar o BigIP da F5, que é o que eu tenho fácil aqui à mão. Vamos criar os Membros, o Pool que conterá os mesmos e, por fim, o Virtual Server. Vamos assumir, para este nosso exercício, que nosso Virtual Server terá o endereço público 86.180.114.42 e estará configurado para receber tráfego na porta 80.

cenario2

Reparem que o pool pode conter membros configurados com IPs privados (sim, mesmo em ambientes de produção!). O motivo é simples: O host (cliente) está “falando” com o Virtual Server e o ADC é quem fala com os servidores. Assim, apenas o Virtual Server precisa de um IP público neste cenário. Os servidores, não. E isso é bom pois protege os servidores reais de ataques diretos ou de tentativas de acesso mal-intencionadas. Quem fica na linha de frente, agora, é o VS.

Para evitar que nossos clientes (vocês) tenham que ficar decorando o endereço IP, vamos criar uma entrada em nossa zona DNS para que este IP seja mapeado para o nome loadbalancer.cldcmp.us. Assim, basta vocês acessarem em seus navegadores o seguinte: http://loadbalancer.cldcmp.us e vocês verão uma página de teste montada com elementos dos dois servidores de nossa configuração – o que ilustra o funcionamento do balanceamento:

teste_html2

Teste atualizando a página algumas vezes (melhor dar um “hard refresh” com CTRL+F5). Perceba como as figuras mudam, assim como o texto em HTML. A cada atualização, o ADC balanceia as conexões TCP entre os dois servidores, resultando nestas alterações.

Antes que me perguntem, a resposta é SIM: Tem SIM um ADC neste endereço e ele está SIM balanceando requests para 2 servidores Apache. É… vida de amante de tecnologia tem destas… a gente monta os labs mais insanos em nossas casas 🙂 !

PS: Vale ressaltar que em um ambiente de produção, ambos os servidores estariam operando de forma sincronizada, servindo exatamente o mesmo conteúdo aos seus requisitantes. Além disso, para que fosse possível a mesma página ser gerada com elementos de ambos os servidores, eu tive que desabilitar o recurso “keepalives” nos meus servidores Apache (ver abaixo). Ao desabilitar este recurso no servidor web, forçamos a abertura de uma nova conexão TCP para cada elemento existente na página (comportamento padrão até a versão 0.9 do HTTP), o que por sua vez dispara o balanceamento pelo ADC (reparem portanto que os ADCs, por definição, balanceiam sessões TCP). Por isso é que vocês podem ver a página sendo montada com elementos de ambos os servidores. Normalmente – com a opção “keepalive” ativada – isso não aconteceria.

keepalive

A configuração do BigIP para este cenário é bastante simples. Seguem as telas abaixo:

Configuração do Pool:

bigip_pool

Configuração do Virtual Server:

bigip_vs

Nem tudo o que eu configurei está ilustrado nas telas acima, mas o básico para fazer este cenário funcionar está aí. Eu tive que realizar uma configuração adicional para capturar o endereço IP de origem real, por exemplo (feito via profile HTTP com a opção XFF habilitada) e aplicar esta configuração ao Virtual Server. A gente fala sobre isso num próximo post.

Lembram-se quando eu disse, lá no 1o post sobre este tema, que trabalhar com ADCs poderia ser um desafio bem maior do que se imagina para quem tem um background forte apenas em redes? O motivo é simples: Apesar dos ADCs se encontrarem na rede, eles não são elementos de rede convencionais e NÃO encaminham pacotes como faz um router ou um switch. Além disso, para configurar adequadamente o balanceamento para um determinado serviço, é preciso que você conheça o serviço, e bem. Pelo menos conheça à fundo os fluxos de dados gerados e como eles se comportam, além dos cabeçalhos existentes na requisição e na resposta. Também é importante entender quantas conexões cada requisição demanda e em quais portas lógicas. Nem vou falar sobre TCP, SSL, um pouco de programação (Python e Bash script são sempre bem-vindos!), além de um monte de outras coisas que, normalmente, um engenheiro de redes não precisa saber no seu dia-a-dia. É um desafio, porque agora o foco é mais na camada 7… entendem?

Enfim, divirtam-se com os testes e aguardem o próximo post da série, que eu devo publicar ainda esta semana…!

Abraço!

Marco Filippetti



Comente usando o Facebook!
6
0

Deixe uma resposta