Estratégias de balanceamento de carga e HTTPS

7

Estou diante do seguinte problema: os servidores ficam saturados, já que a estratégia de balanceamento de carga atual é baseada no IP do cliente. Alguns clientes corporativos acessam nossos servidores por trás de grandes proxies para que todos os clientes apareçam com o mesmo IP em nosso balanceador de carga. Eu acho que estamos usando algum dispositivo de balanceamento de carga de hardware (pode investigar mais, se necessário). Precisamos manter a afinidade de sessão (o site é construído em ASP), portanto, todas as solicitações com o mesmo IP são roteadas para o mesmo nó.

Como toda a comunicação passa pelo HTTPS, nenhum dado da solicitação (como ID da sessão) está disponível para o balanceador como um discriminador do cliente. Existe uma maneira de usar outros dados além do IP para distinguir entre clientes e rotear os clientes, mesmo quando provenientes do mesmo IP para nós diferentes?

Observação: preciso manter o tráfego entre o balanceador e os nós seguros (criptografados).

    
por Dan 02.02.2010 / 15:48

5 respostas

6

A maneira mais fácil de fazer isso se você tiver um balanceador de carga em vigor é descriptografar os dados no balanceador de carga e examinar um cookie. Nesse ponto, você pode enviar a solicitação para o servidor de back-end não criptografado ou pode criptografá-lo novamente e enviá-lo.

A maioria das configurações que conheço considera a conexão de rede entre o balanceador de carga e o servidor de back-end segura e não se preocupa em criptografar novamente o tráfego por vários motivos. Um motivo é que os balanceadores de carga baseados em hardware também agem como aceleradores SSL e Esta é outra razão pela qual o tráfego HTTPS termina em sua porta. Outra é que permite que o tráfego seja inspecionado para ataques .

    
por 02.02.2010 / 16:00
2

Existem três maneiras comuns de fazer isso:

Primeiro, você pode alterar a lógica de encaminhamento do balanceador de carga (acompanhar o número de conexões para cada host e tentar distribuir a carga uniformemente, executar um round-robin simples etc.). Qualquer uma das opções mencionadas elimina a natureza determinística da sua configuração atual (os clientes do IP X não vão mais ao servidor Y), o que também elimina (ou reduz) o seu problema.

Note that you want to implement "sticky sessions" or their equivalent so that once a client is randomly assigned to a back-end server they keep going to the same one as long as their connection is active.

Em segundo lugar, você pode descriptografar as informações, ler alguns identificadores de servidor e, em seguida, passá-las para fora (criptografá-las novamente ou transmiti-las à clareza pela rede de back-end). Observe que isso não é realmente prático em larga escala, a menos que seu hardware de balanceamento de carga seja acelerado por SSL (por exemplo, um switch de conteúdo da Cisco com módulos SSL), pois o dispositivo para o qual você canaliza todo o tráfego precisa ser ALL o trabalho SSL.

Per note in the original question, #2 is probably not an option since the traffic needs to be kept encrypted end-to-end (sounds like decrypting on the load balancer would be a policy violation?)

O terceiro método que eu não recomendo: Configurar DNS split-horizon ou round-robin para o servidor de destino (apontando diretamente para um servidor de back-end ou apontando para IPs separados no balanceador de carga que estão estaticamente vinculados a um back-end, ter pools de balanceamento diferentes etc.) - Isso é bastante comum em operações menores como "balanceamento de carga do gueto", mas na sua situação (onde você já tem um equipamento de balanceamento de carga) adiciona complexidade desnecessária em comparação com as outras soluções.

    
por 02.02.2010 / 16:25
1

A única maneira de fazer o que você deseja é encerrar o SSL antes ou no balanceador de carga e, em seguida, fazer o balanceamento de carga com base no ID da sessão. As soluções de código aberto para executar as duas etapas em um software seriam nginx, haproxy, verniz e muitas outras.

Alguns balanceadores de carga de hardware costumavam balancear com base no ID de sessão SSL, mas agora os navegadores renegociam as sessões SSL, portanto isso não funciona mais de forma confiável.

    
por 21.02.2010 / 06:22
0

Depende do tipo exato de caixa, mas se você puder alterar o discriminador de balanceamento de carga para levar em conta (src ip + src port) em vez de apenas (src ip) , será feito. Eu sei que o Citrix Netscaler suporta isso, provavelmente outros dispositivos também.

    
por 30.01.2011 / 07:46
0

Não sei se seu problema está resolvido. De qualquer forma, uma boa solução é usar a afinidade de sessão com base no ID SSL.

Nesse caso, seu dispositivo lembra o ID SSL na tabela de memória para rotear solicitações do usuário com o mesmo ID SSL para o mesmo nó do servidor.

Então você terá que investigar mais se o seu dispositivo de balanceamento de carga estiver em conformidade.

    
por 19.08.2013 / 14:49