Installazione corretta per il carico bilanciato web che richiede sessioni persistenti?

Question

Ho trovato molti q su questo argomento, ma non ho ancora trovato la configurazione corretta per i nostri server. Lo sfondo è questo: abbiamo due server Web dietro un sistema di bilanciamento del carico e dobbiamo assicurarci che gli utenti non perdano le loro sessioni.

• server Web sono IIS7/ASP.NET 4.
• Al momento non può configurare un server di stato sessione separata e deve Perciò usare le sessioni appiccicose sul LB.

Per quanto ho capito, deve essere assicurato il seguente:

• Situato stessa machinekey su entrambi i server web.
• Utilizzare siti precompilati in modo che gli assembly ottengano lo stesso nome su entrambe le macchine.
• O ci dobbiamo basare sessione appiccicoso su ip-numero o biscotto (quest'ultimo è preferito)

È necessario avere siti precompilate? (So ​​che è più veloce, ma perdiamo un po 'di flessibilità)

Poiché abbiamo sessioni appiccicose, è corretto che avere lo stesso tasto macchina abbia effetto solo su quei casi in cui la sessione utente scade e finisce quindi sull'altro server (il che significa che un post contenente lo stato della vista potrebbe non essere valido a meno che non abbiano la stessa chiave macchina?)

Answer 1

Sei corretto su tutti i punti - le sessioni persistenti su LB assicurerebbero che lo stesso server web venga colpito nelle richieste successive e quindi lo stato della sessione in-proc corretto sarebbe disponibile. Tuttavia, è imperativo che la viscosità LB debba corrispondere (o dovrebbe essere maggiore) al valore di timeout della sessione ASP.NET. Ad esempio, se LB sta utilizzando cookie per la stickiness, il tempo di scadenza del cookie deve essere maggiore di quello della sessione ASP.NET.

Lo stesso argomento chiave macchina è utile nei casi in cui i postback per le richieste vengono inoltrati ad altri server per qualsiasi motivo. Lo stato lato client (come view-state e convalida degli eventi, forse ticket di autenticazione) viene crittografato con la chiave della macchina in modo che la stessa chiave garantisca che qualsiasi server possa servire il postback. Nella nota a margine, in tutti gli scenari di Web farm, è sensato al 100% avere un ambiente S/W esatto (e un possibile ambiente H/W) su tutti i server Web per evitare sorprese.

La pre-compilazione dei siti Web è necessaria per evitare conflitti di serializzazione: i nomi dei tipi devono essere uguali durante la serializzazione/deserializzazione. Quindi non è possibile avere tipi serializzati da assiemi generati dinamicamente e per-compilazione evita tale. IMO, è più probabile che questo influenzi lo storage dello stato di visualizzazione piuttosto che lo stato della sessione (perché lo stato della sessione è in qualche modo non condiviso e non sarà disponibile sul secondo server). Infine, se non si utilizzano siti Web e si utilizzano invece progetti di applicazioni Web, questo punto diventa più o meno irrilevante in quanto i file di codice saranno comunque rispettati durante la creazione di progetti. Solo le pagine (markup) dovrebbero essere soddisfatte dinamicamente e avere probabilità di tipi serializzabili nel markup è quasi zero (e suona comunque come cattiva idea).