Qual é a desvantagem de sessões fixas com balanceadores de carga?

Question

Temos um web farm de máquinas IIS7 que funcionam muito bem. Na frente deles, há um balanceador de carga de hardware F5 Big-IP , que também funciona bem :)

Atualmente, estamos usando um ASP.NET State Service para lidar com nosso estado OutProc . Isso é necessário quando você tem um web farm para manter qualquer tipo de informação de sessão.

Eu queria saber se poderíamos ter sessões fixas no F5 Big-IP e, portanto, mudar de OutProc de volta para o InProc? Se sim, qual é a desvantagem disso? Eu sei o lado negativo do InProc vs OutProc, então não se preocupe em explicar isso. Estou mais interessado nos prós / contras de sessões com o F5 Big-IP .

Alguém pode lançar alguma luz e / ou experiência?

    

Answer 1

Existem duas desvantagens principais:

1. Sua carga não é uniforme distribuído. Sessões pegajosas furar, daí o nome. Enquanto pedidos iniciais serão distribuído uniformemente, você pode acabar com um número significativo de usuários gastando mais tempo que outros. E se todos estes são inicialmente definidos para um único servidor, esse servidor terá muito mais carga. Normalmente, isso realmente não vai ter um enorme impacto, e pode ser mitigado por ter mais servidores em seu cluster.

2. Proxies conglomeram usuários em IPs únicos, todos enviados para um único servidor. Embora isso normalmente não cause danos, novamente, além de aumentar as cargas de servidor individuais, os proxies também podem operar em um cluster. Uma solicitação em seu F5 de tal sistema não seria necessariamente enviada de volta ao mesmo servidor se a solicitação sair de um servidor proxy diferente em seu cluster de proxy.

AOL estava em um ponto usando clusters de proxy, e realmente estragou com balanceadores de carga e sessões pegajosas. A maioria dos balanceadores de carga agora oferecerá sessões persistentes baseadas em intervalos de rede C-Class ou, no caso de F5, sessões fixas baseadas em cookies que armazenam o nó final em um cookie de solicitação da Web.

Embora as sessões baseadas em cookie devam funcionar, tive alguns problemas com elas e, normalmente, escolho sessões baseadas em IP. GRANDE NO ENTANTO: Estou trabalhando principalmente em aplicativos internos - a milhagem DMZ pode variar.

Tudo o que foi dito, tivemos um grande sucesso com os sites em exibição no F5 com sessões fixas e sessões em andamento.

Você também pode querer dar uma olhada em um dos sistemas de caching distribuídos na memória, como Memcached ou Velocity , para uma alternativa a sessão sendo armazenada em SQL ou o serviço out of proc memory. Você chega perto da velocidade da memória no processo com a capacidade de executá-la em vários servidores.

    

Answer 2

Recentemente, li um ótimo artigo no TechNet sobre "Fornecendo Escalabilidade para Aplicativos ASP.NET". Entrou nos prós e contras de cada solução possível. Faça uma leitura:

TechNet Junho de 2009 - Fornecendo escalabilidade para aplicativos ASP.NET

    

Answer 3

Além da excelente resposta de Christopher, as sessões complicadas significam que você perdeu alguns dos enormes benefícios dos servidores redundantes - a capacidade de reduzir um ou mais para manutenção e a transparência em face da falha do sistema. .

Eu considero as sessões fixas um strong indicador de má arquitetura de aplicativos e / ou pouca programação. "Evite a todo custo" é o meu lema.