Sitzungsstatus Server-Redundanz

Question

Wir haben derzeit eine ASP.NET-Webanwendung, die auf einem einzelnen Server ausgeführt wird. Dieser Server ist im Begriff, die Gefahrenzone bezüglich der CPU-Auslastung zu treffen, und wir möchten einen zweiten Server bereitstellen.

Was wäre der beste Weg, um Session State zu behandeln?

Wir führen derzeit InProc. Aber das ist keine Option mit 2+ Servern, da wir manchmal einen einzelnen Server von der WLB-Rotation ausschließen möchten, um Wartungsarbeiten durchzuführen. Auch wenn wir den Sticky Load Balancing verwenden, müssen wir warten, bis alle Benutzer den Vorgang beendet haben, bevor wir den Server von der WLB-Rotation ausschließen können.

So wurde ich auf dieser MSDN-Seite suchen: http://msdn.microsoft.com/en-us/library/ms178586(VS.80).aspx

ich meine Hauptfrage erraten ist: Wenn wir den Staat Server-Modus verwenden. Können wir Redundanz sicherstellen, indem wir den Statusserver auf zwei Servern bereitstellen? Um zu vermeiden, einen einzigen Fehlerpunkt zu haben.

Answer 1

Wenn Sie eine der Standardoptionen möchten, würde ich SQL Server in einem Failovercluster verwenden. BTW haben Sie in Betracht Memcacheddb?

Answer 2

Verwenden Sie entweder Scale Out State Server (schneller besser) oder SQL State (langsamer einfacher). Aber Vorsicht, wenn Sie keine serialisierbaren Objekte im Sitzungszustand speichern, da Sie nach der Migration Ausnahmen erhalten.

Answer 3

Sql-Status-Server wäre eine bessere Option: Dieser Link kann Sql State Server helfen. Ich glaube nicht, dass Sie den Statusserver auf mehreren Rechnern ausführen können.

Answer 4

möchten Sie vielleicht in Projekt Geschwindigkeit (http://msdn.microsoft.com/en-us/data/cc655792.aspx). Es hat jetzt nur eingeschränkte Unterstützung, da es auf CTP3 läuft, aber später in diesem Jahr wäre es RTM. Ich sehr empfehlen Sie die MIX09 Sitzung sehen darüber here

Answer 5

würde ich vorschlagen, p2p Session State-Server sucht in - Link hier: http://www.codeproject.com/KB/aspnet/p2pstateserver.aspx

für mich gearbeitet. Der einzige Nachteil ist, dass es bei der Verwendung eines großen Datenbestands immer wieder Zeit brauchte, um zwischen Peers zu replizieren.