Eu tenho um monte de perguntas com relação a SSL, sessões locais e balanceamento de carga que parecem estar interconectadas, então peço desculpas antecipadamente pela duração dessa pergunta.
Eu tenho um site que usa sessões baseadas em arquivos. A natureza do site é que a maioria é http, mas algumas seções são ssl. Atualmente, devido às sessões baseadas em arquivo, é necessário que qualquer solicitação SSL atinja o mesmo servidor que qualquer solicitação HTTP anterior.
Devido a restrições de tempo, desejo fazer o mais fácil possível para aumentar o saldo do tráfego http e ssl.
Parece haver duas opções para algoritmos de balanceamento de carga:
A solução baseada em IP provavelmente funcionará, mas o algoritmo de hash mudará potencialmente o servidor para o qual um usuário acessa quando um servidor é desativado ou é adicionado, o que é indesejável com a configuração atual da sessão baseada em arquivo. Eu também suponho que seja tecnicamente possível que um usuário mude legitimamente os ips enquanto navega em um site.
O algoritmo baseado em cookie parece melhor, mas a incapacidade de inspecionar o cookie quando criptografado por SSL aparentemente apresenta seus próprios problemas.
Estive procurando exemplos em como balancear a carga ssl, e não consigo encontrar nenhum exemplo explícito de configurações que possam fazer balanceamento de carga baseado em cookie E que possa lidar com o aumento da carga SSL adicionando outro decodificador ssl.
A maioria dos exemplos explícitos que vi têm o decodificador ssl (geralmente hardware, apache_mod_ssl ou nginx) entre o cliente do navegador e o balanceador de carga. Os exemplos geralmente parecem ter algo parecido com isso (modificado de link ):
192.168.1.1 192.168.1.11-192.168.1.14
-------+-----------+-----+-----+-----+
| | | | |
+--+--+ +-+-+ +-+-+ +-+-+ +-+-+
| LB1 | | A | | B | | C | | D |
+-----+ +---+ +---+ +---+ +---+
apache 4 cheap web servers
mod_ssl
haproxy
A parte de decodificação ssl no exemplo acima parece ser um gargalo potencial que não é escalonável horizontalmente.
Eu olhei para haproxy, e parece ter uma opção 'modo tcp' que permitiria algo assim, o que permitiria que você tivesse vários decodificadores ssl:
haproxy
|
-------------
| |
ssl-decoder-1 ssl-decoder2
| |
-------------------
| | |
web1 web2 web3
No entanto, em tal configuração, parece que você perderia o ip do cliente porque o haproxy não está decodificando o ssl: link
Eu também olhei para o nginx, e também não vejo exemplos explícitos de decodificadores ssl horizontalmente escaláveis. Parece haver muitos exemplos de pessoas tendo nginx como um potencial gargalo. E pelo menos este link parece sugerir que o nginx nem tem a opção da configuração haproxy-like onde você perderia o ip dizendo que o nginx "não suporta transparentemente a passagem de conexões TCP para um backend" Como passar o tráfego SSL do Apache através do proxy nginx? .
Perguntas:
Supondo que tudo o que eu disse é verdade, essas parecem ser minhas opções:
A "coisa mais simples", com toda a seriedade, é mudar para um armazenamento de sessão centralizado. Você precisa configurar todo esse encanamento com balanceadores de carga, haproxy, SSL e o restante, quando todo código de tratamento de sessão que eu já vi torna quase trivial conectar diferentes mecanismos de armazenamento, de modo que Um pouco de código e muito, muito pouca complexidade extra resolve todos os seus problemas.
womble está certo sobre o armazenamento de sessão compartilhada, tornando as coisas muito mais fáceis ao redor. Além de sua resposta, posso expandir um pouco nas partes de balanceamento de carga da pergunta:
PCs com vários núcleos podem fazer vários milhares de transações SSL por segundo. E se isso se tornar um gargalo, um appliance dedicado da F5 , da Citrix, da Cisco ou de outros, pode ser ainda mais rápido. Assim, a maioria dos sites nunca supera um bom SSL e & solução de balanceamento de carga.Why don't there seem to be more examples of setups adding more ssl decoders to deal with increased traffic?
Assuming that everything I've said is true, these appear to be my options:
Existem opções para escalar a descriptografia SSL horizontalmente, se você precisar disso.
A abordagem comum é usar o DNS Round Robin para pares de aceleradores SSL altamente disponíveis, ou seja, publicar vários endereços IP para o domínio, cada endereço IP apontando para um par de aceleradores SSL.
Nesse caso, você pode se preocupar com o tempo limite do TTL do DNS no meio de uma sessão do usuário, pressionando o usuário para outro servidor de aplicativos. Isso não deveria ser uma ocorrência comum, mas poderia acontecer. Um armazenamento de sessão compartilhada é a solução comum, mas pode ser tratado de outras maneiras.
Como um exemplo, você pode separar a descriptografia SSL do balanceamento do servidor de aplicativos. O processamento de SSL exige mais CPU do que o balanceamento de carga básico, portanto, um único balanceador de carga deve ser capaz de saturar alguns aceleradores de SSL. Assim:
Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers
Como mencionado no início, um armazenamento de sessão compartilhada simplifica muitas coisas e é quase certamente uma solução melhor a longo prazo do que colocar muita complexidade em sua camada de balanceamento de carga / SSL.
É divertido responder a perguntas com 2 anos de idade como este quando os produtos evoluíram. No momento, o haproxy suporta o protocolo PROXY, que permite que ele passe o IP do cliente para o próximo salto, mesmo no modo TCP puro. Ele também suporta SSL nativa, assim como SSL, se você quiser usá-lo como uma primeira camada em frente a um farm SSL (possivelmente feito de servidores haproxy). Portanto, parece que sua solicitação foi um pouco adiantada e que as implementações alcançaram: -)
Concordo com womble e Jesper aqui. O caminho mais fácil / melhor é consertar o código. É claro que, como sysadmins, muitas vezes não temos essa opção, mas mesmo nesse caso, há truques suficientes que você pode usar para obter um hardware moderno relativamente barato para escalar o suficiente, mesmo que não na horizontal.
Eu só queria postar para comentar onde você está preocupado em perder o client-ip. Em qualquer uma das principais soluções L7 / proxy, você pode inserir um cabeçalho X-Forwarded-For (ou o que você quiser) na solicitação. Em seguida, no servidor de backend que recebe a solicitação, você pode alterar o formato do arquivo de log para registrar esse valor no mesmo espaço no arquivo usado para registrar o ip do cliente da camada 3. Dessa forma, qualquer software de análise de log não enxerga a diferença (nem quando você faz o tailing).
Há compensações para tudo e não ouvimos o suficiente sobre sua configuração para saber, mas com o trio de ha-proxy, nginx e verniz do tipo "você não pode errar", provavelmente é uma boa ideia Mova seu balanceamento de carga para uma ferramenta de camada de proxy. Isso resolverá seu problema de SSL, além de oferecer uma série de novas opções, como cache, troca de conteúdo e manipulação de cabeçalho.
Alguns pensamentos aleatórios;)
Primeiro, grave a pessoa que decidiu usar os dados da sessão baseada em arquivo. Não há como os dados de leitura / gravação de um sistema de arquivos serem mais rápidos do que voltar para a origem para extrair os dados de que você precisa. Esta é sobre a pior maneira de fazer isso.
Pessoalmente, nunca vi uma situação em que armazenar dados em uma sessão fosse melhor do que apenas extraí-los diretamente do banco de dados, conforme necessário. Dito isso, tenho visto onde usar o memcache ou estratégias de cache semelhantes pode ajudar um site a ser escalado para milhões de usuários, mas isso não é nem no mesmo estádio que o uso de sessões.
Em segundo lugar, você acabou de encontrar o motivo número um para não usar sessões: balanceamento de carga. FYI - Sticky não significa preso. Mesmo com as sessões do Sticky ativadas, você corre a possibilidade real de o usuário ser arrastado para outro servidor no meio do uso do seu aplicativo. Isso acontecerá nos momentos mais inoportunos. Pegajosa significa apenas que o balanceador de carga tentará tentar empurrar o usuário de volta para o servidor em que ele começou, mas isso não significa garantia.Esse ponto geralmente leva as pessoas a armazenarem a sessão no banco de dados ... O que eu acredito ser uma falha completa. Para que a sessão funcione, ela deve ser carregada e gravada em cada solicitação de página. Quando é armazenado em um banco de dados (necessário para servidores de carga balanceada), isso requer duas consultas do servidor: a primeira para obter os dados e a segunda para gravar as atualizações.
A falha é que as pessoas geralmente usam sessões para não precisar voltar ao banco de dados para puxar coisas como o nome do usuário ... Mas se a página tiver que consultar o banco de dados para carregar uma sessão, então ... bem, você deve poder ver o problema lógico aqui.
Só piora com as sessões ... porque o processador de páginas precisa gravar os dados da sessão no banco de dados no final do ciclo de vida da página. no caso de alguma alteração. O que significa que, em vez da única consulta para puxar o nome desse usuário, você acaba com dois. Para cada carregamento de página única. Além disso, significa serializar e desserializar os dados que têm seu próprio impacto no desempenho.
Meu ponto é: a sessão é má e você geralmente fica melhor sem ela. Sites de baixo tráfego que só são executados em um servidor da Web não precisam do aumento de desempenho que pode ocorrer; e sites de alto tráfego em execução em um web farm são limitados em escala devido a isso.
Em vez de usar o Haproxy na frente, você pode usar o round robin DNS para fazer o balanceamento grosso entre vários decodificadores SSL e passá-lo ao haproxy para o balanceamento de carga adequado.
Tags ssl nginx load-balancing haproxy