Maneira econômica de manipular tráfego SSL alto?

Question

Algum tempo no futuro, talvez precise criar um farm SSL dedicado (conforme descrito em Como tornar os aplicativos escaláveis com Balanceamento de carga ou algo semelhante para lidar com muito tráfego SSL. Embora não seja um problema imediato para mim, gostaria de planejar um pouco mais adiante. Então minha pergunta é:

É mais econômico usar hardware dedicado para isso, ou posso reutilizar servidores de aplicativos, talvez com uma placa de expansão de hardware? Ou é melhor ter isso integrado em balanceadores de carga (ao contrário do que o artigo mencionado acima declarou em 2006)?

Alguns links para hardware específico também seriam legais - atualmente, eu realmente não sei onde começar a procurar.

    

Answer 1

AFAIK o artigo ainda permanece.

Se você realmente precisa de um farm com vários proxies reversos SSL balanceados por carga e alguns servidores web / de aplicativos por trás deles, sugiro que você consulte uma solução blade. Isso não é mais barato do que os simples servidores 1U em rack, mas economizará espaço em rack. A maioria dos principais fabricantes de servidores faz soluções blade (Dell, HP, IBM, etc.). Alguns links: IBM | Dell | HP

Eu criaria os balanceadores de carga dos servidores Linux (pares redundantes conectados via Heartbeat , veja Projeto LVS ), e possuem poucas redes dedicadas para o tráfego de proxy e o tráfego do segundo balanceador de carga para os servidores web / de aplicativos.

    

Answer 2

A solução mais econômica é o NGINX como proxy reverso, uma vez que o preço / desempenho supera a maioria das soluções de hardware como o F5 Networks Big-IP 6900.
 Minha configuração do NGINX: link

    

Answer 3

A Fig2 no seu link fornece o estado da arte para construir um farm SSL.

Sobre a maneira de construir sua fazenda e seu custo, isso dependerá da sua necessidade.

Ter terminação SSL no balanceador de carga provavelmente é mais barato hoje (mesmo com balanceador de carga dedicado, como Cisco CSS , Cisco ACE , F5 BIG-IP , ... mas ainda depende do fabricante do balanceador de carga). O balanceador de carga poderá fazer o balanceamento L7 conforme visualizar dados não criptografados. Portanto, você não precisará de 2 camadas de balanceador de carga e algum proxy reverso SSL. Isso pode reduzir o custo. (menos hardware para comprar, menos espaço em rack, ...)

Mas ter terminação SSL no balanceador de carga não é muito escalonável, portanto, se você vir que seu balanceador de carga começa a ser sobrecarregado por SSL, você terá um problema. Se você pegou um dispositivo dedicado, precisará atualizá-lo e isso será caro. Se você construir seu próprio balanceador de carga com um servidor, precisará descarregar o SSL em um novo servidor dedicado.

Ter o cartão no servidor de aplicativos pode ser uma opção se o balanceamento de carga L4 for suficiente e se o seu aplicativo fornecer um alto throughput para um uso baixo de cpu.
Quero dizer: um cartão SSL de hardware é caro, então você quer usá-lo o máximo possível. Com um hardware de terminação SSL dedicado, você utilizará o cartão com a maior frequência possível. Se o cartão estiver no servidor de aplicativos e o aplicativo tiver um baixo throughput, você não usará o cartão muito tempo. Mas se o aplicativo for algo rápido, não usar muita CPU, mas com um alto throughput, ter a terminação SSL no servidor com uma placa dedicada pode ser uma opção. Isso geralmente não é o caso. Isso também reduz a alta disponibilidade.

    

Answer 4

Suponho que você esteja falando sobre o tráfego HTTP aqui (há uma grande diferença entre protocolos com e sem estado).

O problema é que, para obter o melhor desempenho, você deseja que a retomada da sessão SSL funcione - o que favorece uma abordagem de sessão fixa -, mas se as sessões forem muito complicadas, você não terá nenhum failover. As grandes e caras caixas da f5, Cisco e cols podem lidar com isso, mas é difícil fazer isso em caixas de commodities rodando (por exemplo) stunnel.

Ainda acho que a melhor solução para a maioria dos problemas de balanceamento de carga é o DNS round-robin - onde a detecção de falhas é o único local em que uma falha pode ser detectada com segurança (o cliente) e é onde o failover é implementado. fornece afinidade de servidor, mas ainda permite o failover de pedidos (note que ele não suporta a retomada de pedidos - mas ainda não encontrei nada que suporte isso para HTTP).

Uma outra coisa a ter em mente é que o suporte keep-alive da Microsoft para o HTTP O SSL é diferente daquele implementado por todos os outros. Isto não é apenas uma coisa openSSL - outros fornecedores dão o mesmo conselho. Dadas as sobrecargas adicionais na negociação SSL e o enorme retorno usando keep-alives para o tráfego HTTP, pode valer a pena considerar o uso do MS-ISA para terminação SSL - embora eu esteja supondo que é possível configurar o software como tal e eu Nunca fiquei impressionado com a escalabilidade / confiabilidade dos produtos. Então, se eu tivesse muito dinheiro para gastar, provavelmente veria o MSISA para a terminação SSL, mas não usaria o software de cluster da Microsoft e moveria o failover para outro lugar (por exemplo, para o cliente!).

Para uma solução barata, termine o SSL nas caixas do servidor web com o DNS round-robin. Adicione muitos servidores da Web. Opcionalmente, use uma placa aceleradora de criptografia (não uma placa de rede com capacidade SSL) no servidor da Web para aumentar a potência.

Para uma solução muito rápida - (possivelmente) vários nós MSISA endereçados via DNS round-robin, conversando com um cluster LVS de servidores web .

HTH

    

Answer 5

O tráfego de HTTPs pode gerar uma carga muito alta devido aos requisitos de criptografia. Eles criam placas adicionais que permitem descarregar criptografia / descriptografia SSL em hardware especificamente projetado. Como mencionado acima, você pode encerrar o SSL em um balanceador de carga, o que reduzirá os custos porque (pelo menos para o F5) esses dispositivos vêm com esse equipamento de transferência de SSL. Alternativamente, eles podem ser comprados e instalados diretamente no seu servidor, embora eu não tenha certeza de como isso funcionaria com o VMWare. A compactação também pode ser descarregada usando um balanceador de carga.