Quantos proxies reversos (nginx, haproxy) são muitos?

Question

Estou configurando um cluster de HA (alta disponibilidade) usando nginx, haproxy & apache.

Eu tenho lido grandes coisas sobre nginx e haproxy. As pessoas tendem a escolher uma ou outra, mas gosto de ambas. O haproxy é mais flexível para balanceamento de carga do que o simples round robin do nginx (mesmo com o patch upstream fair). Mas eu gostaria de manter o nginx para redirecionar o não-https para o https, entre outras coisas, no ponto de entrada do cluster.

Por outro lado, o nginx é muito mais rápido para servir conteúdo estático e reduziria a carga no poderoso apache que adora comer muita RAM!

Aqui está minha configuração planejada:

Balanceador de carga: o nginx escuta na porta 80/443 e proxy_forwards no haproxy no 8080 no mesmo servidor para balancear a carga entre os vários nós.

Nós: nginx no nó atende a solicitações vindas do haproxy no 8080, se o conteúdo for estático, atenda-o. Mas se for um script de backend (no meu caso PHP), o proxy encaminhará para o apache2 no mesmo servidor de nó que estiver ouvindo em um número de porta diferente.

Tecnicamente, essa configuração funciona, mas minhas preocupações são se ter solicitações passando por vários proxies vai atrasar as solicitações? A maioria dos pedidos será de PHP, já que os backends são serviços (o que significa groing de nginx - > haproxy - > nginx - > apache).

Pensamentos? Felicidades

    

Answer 1

De uma perspectiva puramente de desempenho, permita que o benchmarking tome essas decisões por você, em vez de assumir - usando uma ferramenta como link é inestimável ao fazer alterações na arquitetura.

De uma perspectiva de filosofia de arquitetura, estou um pouco curioso porque você tem nginx e apache nos servidores de aplicativos. O Nginx brilha em conteúdo estático e lida eficientemente com a maioria das frameworks / tecnologias de backend (Rails, PHP via FastFCGI, etc), então eu descartaria a camada final do Apache. Mais uma vez, isso vem de uma compreensão limitada das tecnologias que você está usando, então você pode ter uma necessidade que eu não estou antecipando (mas, se esse for o caso, você sempre pode descartar nginx nos servidores de aplicativos e apenas use o apache - não é TÃO ruim em conteúdo estático quando configurado corretamente).

Atualmente, uso nginx - > haproxy em servidores de balanceamento de carga e nginx nos servidores de aplicativos com muito sucesso. Como Willy Tarreau afirmou, nginx e haproxy são uma combinação muito rápida, então eu não me preocuparia com a velocidade de ter ambos no front-end, mas tenha em mente que adicionar camadas adicionais aumenta a complexidade, bem como o número de pontos de falha.

    

Answer 2

Sua configuração é cada vez mais comum. Você não precisa se preocupar. Tanto o nginx quanto o haproxy são extremamente rápidos para processar e encaminhar solicitações HTTP. Ambos combinam muito bem juntos e fazem seu trabalho muito bem. Não precisa escolher. Instale os dois e seja feliz. Dessa forma, você fornecerá arquivos estáticos muito rapidamente e também garantirá um dimensionamento suave de seus servidores dinâmicos.

Não se preocupe com o número de proxies. O problema é muitas vezes "posso usar um proxy". Às vezes não é prático. Se você pode ter um, você pode ter dois ou três. Muitas arquiteturas complexas envolvem até 5-6 níveis de proxies e ainda são muito bem dimensionadas. Você deve ter cuidado apenas com uma coisa: não instale mais desses proxies em uma única máquina do que essa máquina tem de núcleos de CPU, ou os proxies terão que compartilhar seu tempo de CPU sob altas cargas, o que aumentará os tempos de resposta. Mas para isso acontecer com nginx e haproxy em uma máquina, isso significaria dezenas de milhares de solicitações por segundo, o que não é problema de todos do dia.

Além disso, evite misturar proxies de encadeamento único com softwares massivamente multiencadeados / multiprocessos, como apache, java, etc., no mesmo sistema.

Depois de levar essas regras em consideração, basta desenhar a arquitetura que atenda às suas necessidades, colocar nomes nas caixas, combiná-las de maneira correta e instalá-las.

    

Answer 3

Lembre-se que a complexidade pode ser tanto (se não mais) um impedimento para escalar como código / design. À medida que você espalha seus detalhes de implementação em mais e mais serviços e arquivos de configuração, você cria algo mais difícil de dimensionar, mais curva de aprendizado para qualquer pessoa nova na equipe, requer mais software / pacotes para gerenciar, complica a solução de problemas com mais potenciais pontos de falha, etc. A configuração de uma pilha de camada com 4 proxy para um site que teria funcionado bem com just-apache ou just-nginx é basicamente a versão sysadmin de "otimização prematura".

    

Answer 4

Por que não usar Verniz ? Dessa forma, você combina o armazenamento em cache, o proxy e o balanceamento de carga em um aplicativo e é muito mais simples do ponto de vista da arquitetura. O dimensionamento de scale-out é bastante fenomenal. Há também a vantagem de que o balanceador de carga pode tomar decisões mais inteligentes com base na integridade real dos nós.

O arquivo de configuração permitirá examinar os cabeçalhos e tomar decisões sobre onde exibir conteúdo estático e dinâmico.

Se você está realmente prevendo estar oferecendo MUITO conteúdo estático, talvez desviar a maior parte disso para um CDN seria uma solução econômica?

    

Answer 5

"Tecnicamente essa configuração funciona, mas minhas preocupações são se ter solicitações passando por vários proxies vai desacelerar as solicitações?"

Sim, mas não muito especialmente se você prestar atenção ao lado da rede do seu sistema dimensionado. Isso tem que ser robusto.

Geralmente, para obter ganho de escala e distribuir o trabalho em muitas máquinas, você geralmente deve sacrificar algum desempenho em algumas ou todas as máquinas individuais. É inevitável e geralmente algo que não vale a pena se preocupar (além dos testes que você deve sempre fazer para garantir que o desempenho do todo esteja sugando o vento). Otimizar as partes não é necessariamente a melhor maneira de otimizar o todo.