IIS7マシンのWebファームがあり、非常にうまく機能しています。それらの前にF5 Big-IPハードウェアロードバランサーがあり、これも正常に動作しています:)
（ソース：www.f5.com）
現在ASP.NET State Service、OutProc状態を処理するためにを使用しています。これは、あらゆるタイプのセッション情報を保持するWebファームがある場合に必要です。
F5 Big-IPでスティッキーセッションを行うことができ、したがってOutProcからInProcに戻すことができるかどうか疑問に思っていました。もしそうなら、これの欠点は何ですか？InProcとOutProcの欠点を知っているので、それを説明することを心配しないでください。F5 Big-IPを使用したスティッキーセッションの長所/短所にもっと興味があります。
誰もが光や経験を流すことができますか？
回答:
2つの主な欠点があります。
負荷が均等に分散されていません。スティッキーセッションは固定されるため、名前が付けられます。最初のリクエストは均等に配信されますが、かなりの数のユーザーが他のユーザーよりも多くの時間を費やすことになります。これらすべてが最初に単一のサーバーに設定されている場合、そのサーバーの負荷ははるかに大きくなります。通常、これは実際には大きな影響を与えることはなく、クラスター内のサーバーを増やすことで緩和できます。
プロキシはユーザーを単一のIPに統合し、そのすべてが単一のサーバーに送信されます。通常は害はありませんが、ここでも個々のサーバーの負荷を増やす以外に、プロキシはクラスタ内でも動作できます。このようなシステムからF5へのリクエストは、リクエストがプロキシクラスター内の別のプロキシサーバーから送信された場合、必ずしも同じサーバーに返されるとは限りません。
AOLはある時点でプロキシクラスターを使用していましたが、実際にはロードバランサーとスティッキーセッションを使用していました。ほとんどのロードバランサは、Cクラスのネット範囲に基づいたスティッキーセッションを提供します。F5の場合、Web要求Cookieにエンドノードを保存するCookieベースのスティッキーセッションを提供します。
Cookieベースのセッションは機能するはずですが、私はそれらにいくつかの問題があり、通常はIPベースのセッションを選択します。しかし、私は主に内部アプリに取り組んでいます-DMZマイレージは異なる場合があります。
述べられていることはすべて、スティッキーセッションとIn-Procセッションを使用してF5を実行しているサイトで大きな成功を収めました。
また、MemcachedやVelocityなどのメモリ分散キャッシュシステムの1つを調べて、SQLまたはout of procメモリサービスに保存されているセッションの代替手段を調べることもできます。複数のサーバーで実行できるため、インプロセスメモリの速度に近づきます。
最近、TechNetで「ASP.NETアプリケーションにスケーラビリティを提供する」という素晴らしい記事を読みました。それぞれの可能な解決策の賛否両論になりました。読んでください：
クリストファーからの優れた答えに加えて、スティッキーセッションは、冗長サーバーの2つの大きな利点（メンテナンスのために1つ以上を停止する機能、およびシステム障害に直面した場合の透過性）を失ったことを意味します。
スティッキーセッションは、アプリケーションアーキテクチャやプログラミングが不十分であることを示す強力な指標であると考えています。「すべての費用を避けて」が私のモットーです。