Camada 4 versus o balanceamento de carga da camada 7

Question

Estou tentando decidir entre usar uma solução de balanceamento de carga de camada 4 para meu datacenter ou uma solução de camada 7. Infelizmente (para minha sanidade, isto é), meu caso de uso é simples o suficiente para que ambas as soluções funcionem bem, evitando a maioria das fraquezas e não utilizando as forças do outro. Seja qual for a solução que acabamos usando, ela precisa ter alta disponibilidade e alto rendimento. Mas estamos planejando usá-lo apenas para balancear a carga em um cluster de servidores da web, nenhum dos quais tem requisitos para gerenciamento de sessão "pegajoso" (cookie ou IP), regras complexas de reconfiguração - ou, se for o caso, regras de reescrita tudo.

Os balanceadores de carga serão conectados a dois switches, ambos com uma conexão independente até a camada de agregação do datacenter e mesclados usando o Rapid Spanning Tree e qualquer protocolo proprietário que os switches usem para virtualizar. Os balanceadores de carga também serão interligados entre si por um cabo crossover. Todos os servidores no cluster estão conectados a ambos os switches. Tudo o que os balanceadores de carga precisam fazer é apontar o tráfego sobre eles.

Como é apenas HTTP, posso usar uma solução de balanceamento de carga de camada 7, como HAProxy ou nginx. Mas eu também poderia usar o projeto LVS com ldirectord ou keepalived ou o que quer que seja.

Eu tentei quebrar os prós e contras quando os vejo, mas isso acaba em uma lavagem. O que você recomendaria e por quê? Estou faltando alguma coisa?

    

Answer 1

Um benefício útil de "L7", como haproxy, é poder usar cookies para manter o mesmo navegador acessando o mesmo servidor de back-end. Isso faz com que os clientes de depuração sejam muito mais fáceis.

O balanceamento de L4 pode reverter um único usuário em vários servidores de back-end. (o que em certos casos pode ser vantajoso, mas em um sentido de depuração / perfilamento, usar "L7" é muito mais valioso).

EDITAR: Há também uma vantagem de velocidade potencial do uso do balanceamento HTTP. Com o keep-alives, os clientes podem estabelecer uma única sessão TCP para seu balanceador e, em seguida, enviar muitos HITs sem a necessidade de restabelecer novas sessões TCP (handshake de 3 vias). Da mesma forma, muitos LBs mantêm sessões keep-alive para sistemas back-end, eliminando a necessidade de fazer o mesmo handshake no back-end.

O balanceamento de carga de TCP restrito pode não conseguir esses dois com facilidade.

/ * FWIW: Eu não diria "L7" ou "L4", eu diria HTTP ou TCP. Mas eu sou um defensor para evitar usar o OSI para descrever as coisas que não combinam bem. * /

Eu acho que fundamentalmente, se você não tem certeza do que implantar, vá com o que parece simples e natural para você. Teste-o (use o banco apache?) E certifique-se de que ele funciona para as suas necessidades. Para mim, o HTTP LB é mais natural.

    

Answer 2

Dada a falta de vantagem para você de fazer o balanceamento L7, eu preferiria me equilibrar com L4. Eu sou um grande fã de mantê-lo o mais simples possível, sem sacrificar muito.

O L7 requer que os balanceadores inspecionem os cabeçalhos http nos pacotes que estão passando por eles para o roteamento apropriado, adicionando sobrecarga adicional e um aumento marginal na latência para o usuário final. Parece uma despesa inútil para mim se você não ganhar nada com isso.

    

Answer 3

Alguns provedores DNS têm funcionalidade simples de failover. Você mencionou quais são os seus requisitos e não o que eles são, mas se tudo o que você precisa é round robin com failover se algo estiver errado, então você pode usar, por exemplo, O failover do zoneedit.com . Dependendo das suas necessidades de HA, isso pode ser bom o suficiente e você pode pular uma camada inteira em sua arquitetura.