Qual è il rovescio della medaglia delle sessioni appiccicose con bilanciamento del carico?

Abbiamo una web farm di macchine IIS7 che funzionano alla grande. Di fronte a loro c'è un bilanciamento del carico hardware F5 Big-IP , che funziona anche bene :)

_{(fonte: www.f5.com )}

Attualmente stiamo usando un ASP.NET State Serviceper gestire il nostro stato OutProc . Ciò è necessario quando si dispone di una Web farm per conservare qualsiasi tipo di informazione sulla sessione.

Mi chiedevo se potevamo avere sessioni appiccicose sull'F5 Big-IP e quindi passare da OutProc a InProc? In tal caso, qual è il rovescio della medaglia di questo? Conosco il rovescio della medaglia di InProc vs OutProc, quindi non preoccuparti di spiegarlo. Sono più interessato ai pro / contro delle sessioni appiccicose con F5 Big-IP .

Qualcuno può far luce e / o esperienza?

Ci sono due aspetti negativi principali:

1. Il tuo carico non è distribuito uniformemente. Le sessioni appiccicose resteranno attaccate, da qui il nome. Mentre le richieste iniziali saranno distribuite in modo uniforme, potresti finire con un numero significativo di utenti che trascorrono più tempo di altri. Se tutti questi sono inizialmente impostati su un singolo server, quel server avrà molto più carico. In genere, questo non avrà davvero un impatto enorme e può essere mitigato avendo più server nel cluster.

2. I proxy conglomerano gli utenti in singoli IP, che verrebbero inviati a un singolo server. Sebbene ciò non danneggi in genere, a parte l'aumento dei singoli carichi del server, i proxy possono anche operare in un cluster. Una richiesta nel tuo F5 da un tale sistema non sarebbe necessariamente rispedita allo stesso server se la richiesta proviene da un server proxy diverso nel loro cluster proxy.

AOL, a un certo punto, utilizzava i proxy proxy e si era davvero fregato di bilanciamento del carico e sessioni appiccicose. La maggior parte dei sistemi di bilanciamento del carico ora offre sessioni permanenti basate su intervalli netti di Classe C o, nel caso di F5, sessioni adesive basate su cookie che memorizzano il nodo finale in un cookie di richiesta Web.

Mentre le sessioni basate su cookie dovrebbero funzionare, ho avuto alcuni problemi con loro e in genere ho scelto sessioni basate su IP. GRANDE TUTTAVIA: lavoro principalmente su app interne - il chilometraggio DMZ potrebbe variare.

Detto questo, abbiamo avuto un grande successo con i siti che gestiscono F5 con sessioni appiccicose e sessioni In-Proc.

Potresti anche dare un'occhiata a uno dei sistemi di memorizzazione nella cache distribuiti in memoria come Memcached o Velocity per un'alternativa alla sessione archiviata in SQL o al servizio di memoria out of proc. Ti avvicini alla velocità della memoria in-proc con la possibilità di eseguirla su più server.

Di recente ho letto un ottimo articolo in TechNet su "Fornire scalabilità per le applicazioni ASP.NET". È andato in pro e contro di ogni possibile soluzione. Leggi:

TechNet giugno 2009: fornire scalabilità per le applicazioni ASP.NET

Oltre all'eccellente risposta di Christopher, le sessioni appiccicose significano che hai perso un paio di enormi vantaggi dei server ridondanti: la capacità di eliminare uno o più down per la manutenzione e la trasparenza di fronte al fallimento del sistema.

Considero sessioni appiccicose un forte indicatore della scarsa architettura dell'applicazione e / o della scarsa programmazione. "Evitare a tutti i costi" è il mio motto.