proxy reverso e arquitetura do servidor de balanceamento de carga

Question

Ao criar uma arquitetura baseada em carga balanceada e proxy reverso, como os dois seriam colocados?

Esta é a arquitetura correta? First LB server, then proxy: - Quando o cliente atinge uma URL, é basicamente um balanceador de carga, que tem vários servidores proxy reversos atrás dele. Ele chama um servidor proxy reverso, que, por sua vez, reúne dados de vários servidores e atende à solicitação

Existe a possibilidade de First proxy server then LB server ?

Ou eu estou totalmente perdendo o enredo?

    

Answer 1

Como Jesper mencionou, você precisa de mais detalhes.

Qual é o papel do proxy reverso nessa situação? O desempenho da meta, alta disponibilidade ou ambos?

Alguns balanceadores de carga fazem filtragem de URL, portanto, se o proxy for apenas o tráfego de roteamento (não o armazenamento em cache), talvez você não precise de um proxy.

Quanto do tráfego pode ser armazenado em cache? Onde estão seus gargalos?

Ultimamente, tenho usado essa pilha com bons resultados para um aplicativo baseado em PHP:

HAProxy --> Varnish --> Nginx --> PHP-FPM --> MySQL/NFS server

O que descobrimos é que cerca de 70% de todas as solicitações podem ser atendidas no cache do Varnish. Nós consideramos colocar o Varnish na frente, mas um único servidor Varnish não pode lidar com a carga. Então, precisaríamos balancear a carga de qualquer maneira.

Isso cria um ponto único de falha no nível LB, mas nosso cliente está bem com isso, já que podemos criar uma nova instância em cerca de 5 minutos. Eles estão dispostos a arriscar uma interrupção de 5 a 10 minutos em vez de ter uma infraestrutura mais complicada com dois servidores HA-Proxy.

Cada caso de uso varia e somente por meio de testes é possível encontrar a melhor solução que se encaixa no orçamento.

    

Answer 2

Aqui está o que eu geralmente faço.

Ter dois servidores de verniz na frente com um IP compartilhado via keepalive no caso de um morre. como meu proxy reverso.

Por trás dele (ou no mesmo servidor), observe o haproxy fazendo o balanceamento de carga.

O Varnish também suporta o balanceamento de carga para backends, mas você não obtém as estatísticas ou controle legais como faz com o haproxy. Se você for com um balanceador de carga de hardware ... as chances são de que seja o primeiro a ser lançado, pois esse também pode ser seu firewall.

No final ... isso realmente depende de como você quer distribuir.

    

Answer 3

Depende das suas necessidades mais detalhadas e específicas, por isso não é realmente possível responder com base nas informações que você forneceu. Ambas as suas sugestões são válidas e boas soluções em certos casos.

Como sempre, crie um perfil da sua carga de produção ativa e faça um benchmark dos appliances / software com os quais você está trabalhando para fazer proxy e balanceamento de carga.

Em geral:

• Se você precisar de SSL, muito dependerá do fato de o LB ou proxy lidar com SSL melhor. Geralmente, você deseja manipular o SSL na borda da sua rede, ou seja, no primeiro servidor (es).

• Se você precisar de vários servidores proxy para lidar com a carga, isso levará em direção a LB --> proxie(s) --> LB --> App Servers (ou usando o DNS Round Robin bruto para distribuir grosseiramente a carga a vários proxies).

• Se você precisar de um hash consistente na frente de seus proxies, isso será um avanço para LB --> proxie(s) --> LB --> App Servers e um balanceador de carga que suporta hashing consistente.

• Se um único proxy puder manipular sua carga, então proxy --> LB --> App Servers é o mais simples. Alguns proxies, como o Varnish, até possuem um balanceador de carga básico integrado.

Willy Tarreau, autor do excelente HAProxy, escreveu um bom artigo sobre balanceamento comum de carga de front end / SSL offload / arquiteturas proxy .