Houve uma época em que os dinossauros vagavam pela Terra; os seres humanos começaram a trabalhar com ferramentas como pedras e balanceadores de carga baseados em DSR de camada 4.
Na época, essas ferramentas eram úteis porque você podia acessar os servidores com elas e também porque era fácil garantir que o servidor de aplicativos fosse apresentado com o endereço IP real do cliente.
Um balanceador de carga fica entre o cliente e o aplicativo, portanto, olhando para trás a partir do aplicativo, quem é o remetente? O cliente (sim, por favor) ou o balanceador de carga?
Isso foi bastante fácil e você tinha algumas opções à sua disposição.
Modo DSR – Retorno direto do servidor.
- O cliente se conectaria ao balanceador de carga.
- O balanceador de carga o enviaria para o aplicativo com o IP de origem do cliente.
- O aplicativo enviaria uma resposta diretamente para o cliente. Ele provavelmente notaria que o SourceIP é um IP externo e, em seguida, encaminharia a resposta para o gateway, ignorando assim o balanceador de carga na resposta.
Assim, os dinossauros gostaram dessa abordagem, pois ela usava menos recursos na infraestrutura, e o aplicativo obtinha o IP real do cliente
A desvantagem é que você precisa fazer uma configuração de rede especial no servidor de aplicativos E a grande revelação… O balanceador de carga não recebe nem vê a resposta, portanto, qualquer SSL ou troca de conteúdo está fora de questão.
A outra desvantagem é que o LB não tem ideia de como está o desempenho do servidor de aplicativos, portanto, é mais difícil fazer o balanceamento de carga para servidores que provavelmente teriam um desempenho melhor. O ADC usaria a resposta mais rápida ou o menor número de conexões. (O Stone Age Man pode instalar um agente no servidor de aplicativos para informar isso.) Ou um ADC poderia usar o SNMP para obter isso.
De qualquer forma, essa configuração funcionou bem por muitos anos, como o cavalo e a carroça, e, de fato, ainda há situações em que essa é a melhor opção, como corridas de carruagem ou alguns protocolos mais antigos, por exemplo.
O próximo é:
Modo de gateway
- O cliente se conectaria ao balanceador de carga
- O balanceador de carga o enviaria ao App Server com o IP de origem do cliente
- O aplicativo enviaria uma resposta diretamente para o cliente, MAS ATRAVÉS do balanceador de carga, porque você alterou o gateway padrão do App Server para o do balanceador de carga. Isso significa que o balanceador de carga receberá a resposta.
Isso é muito melhor em alguns aspectos, mas TODO o tráfego externo do servidor de aplicativos, como as atualizações de software, é executado por meio do balanceador de carga, o que torna as coisas confusas.
Isso era mais comum quando os balanceadores de carga se pareciam com switches e tudo era conectado diretamente com links de rede de alta velocidade.
O homem aprende a cultivar e usar o balanceamento de carga baseado em proxy
Nessa época, as redes e as velocidades da CPU estavam ficando mais rápidas, e começamos a ver a abordagem de proxy.
Decidimos ser honestos e começar a usar o balanceador de carga como o IP de origem em vez de enganar o servidor de aplicativos. Fizemos isso por vários motivos, incluindo o desempenho do TCP, a segurança e a capacidade de fornecer serviços adicionais no balanceador de carga.
Mas esse afastamento da coleta de caçadores teve um grande preço e um grande desafio.
Como você envia o IP do cliente para o servidor de aplicativos?
Felizmente, o bom e velho HTTP tinha uma ótima resposta, desde que você estivesse usando HTTP.
X_Forwarded_For Header – permite que você coloque o IP do cliente no cabeçalho e depois o envie.
Não vou explicar isso em muitos detalhes, pois é bastante simples, mas basta dizer que é um cabeçalho que qualquer pessoa pode definir facilmente. Além disso, ele pode se tornar complexo. Por exemplo, o que acontece se o balanceador de carga já tiver recebido um IP X_Forwareded_For? Você deve usá-lo ou usar o IP de origem e alterá-lo? Normalmente, isso é possível de ser configurado em um LB decente, mas todos eles têm considerações de segurança, etc.
De qualquer forma, 99% das vezes, sempre que um aplicativo da Web precisa do código-fonte, é assim que você o obtém (Observação: 99% das estatísticas são inventadas)
E quanto a outros protocolos?
Alguns têm alguns hacks específicos de protocolo, mas não há nada genérico que seja mais amplamente adotado.
Bem, isso foi até que o Proxy Protocol foi proposto e amplamente adotado.
Explicação do protocolo proxy
O protocolo proxy resolve esse problema adicionando um cabeçalho à solicitação encaminhada que contém os detalhes da conexão do cliente original.
Já existem duas versões desse protocolo.
- Protocolo de proxy v1: Usa um formato de texto simples e legível por humanos.
- Protocolo de proxy v2: Usa um formato binário, que é mais eficiente e pode suportar recursos adicionais como IPv6 e endereços de soquete Unix.
O que é diferente é que a maioria dos servidores de aplicativos será interrompida se você ativar isso sem configurá-los para aceitá-lo. Isso ocorre porque o Proxy Protocol literalmente adiciona os detalhes necessários ao início dos dados.
No entanto, a adoção está crescendo e muitos fornecedores agora oferecem suporte a isso.
Ele é ótimo para proxy de DNS, por exemplo.
Assim como no caso do X_Forwardard_For, ainda há algumas decisões a serem tomadas:
Por exemplo, o que você deseja que o balanceador de carga faça se for apresentado a um cabeçalho de protocolo proxy? Removê-lo e definir um novo, ou mantê-lo? Se você não espera que um seja enviado, deve ignorá-lo e obter o seu próprio, mas essas decisões devem ser consideradas.
O protocolo proxy é uma maneira simples de obter o IP do cliente e agora tem amplo suporte, portanto, você pode aproveitar.
Vou voltar a pensar em alta disponibilidade na nuvem, Ciao!
