固定セッションを必要とする負荷分散されたWeb用の適切なセットアップですか？

Question

この件に関して多くのq &が見つかりましたが、まだ私たちのサーバーの適切な構成がわかりません。これは、ロードバランサの背後に2つのWebサーバーがあり、ユーザーがセッションを失っていないことを確認する必要があります。

• Webサーバーは私たちが現在のセットアップ個別のセッション状態サーバーことができず、そのためのLBの上スティッキーセッションを使用する必要があります。4.
• IIS7/ASP.NETです
私の知る限り理解し

、以下は保証されている必要があります

• は、両方のWebサーバー上で同じのmachineKeyを設定します。
• アセンブリが両方のマシンで同じ名前を持つように、プリコンパイルされたサイトを使用します。
• 我々のどちらかが

（後者が好まれる）IP-数やクッキーのスティッキーセッションをベースにしなければならないサイトをプリコンパイルしていると、それは必要ですか？

私たちはスティッキーセッションを持っているので、同じマシンキーを持つことは、ユーザーのセッションがタイムアウトしてそのセッションが終了する場合にのみ影響します。サーバ上のビューステートを含むポストバックが有効でない可能性があります。

Answer 1

LBのスティッキセッションでは、後続のリクエストで同じWebサーバが確実にヒットすることがあります。したがって正しいin-procセッション状態が利用可能になります。しかし、LBのスティッキ性は、ASP.NETセッションのタイムアウト値と一致する必要があります（またはそれ以上である必要があります）。たとえば、LBがスティッキーにCookieを使用している場合、Cookieの有効期限はASP.NETセッションの有効期限より長くなる必要があります。

同じmachine-key引数は、何らかの理由で要求のポストバックが他のサーバーに送信される場合に便利です。クライアント側の状態（ビューステートやイベントの検証、おそらく認証チケットなど）はマシンキーで暗号化されるため、同じキーを使用すると、サーバーのいずれかがポストバックに対応できるようになります。さらに、すべてのWebファームシナリオでは、すべてのWebサーバーでS/W環境（およびH/W環境）を正確に把握して、驚きを回避します。

シリアライズの競合を回避するには、事前にWebサイトをコンパイルする必要があります。シリアライズ/デシリアライズ中にタイプ名が同じである必要があります。したがって、動的に生成されたアセンブリから直列化された型を持つことはできず、コンパイルごとにそれを避けることができます。 IMOでは、セッション状態ではなくビューステートストレージに影響を与える可能性が高くなります（セッション状態は共有されず、2番目のサーバーでは使用できないためです）。最後に、Webサイトを使用せず、Webアプリケーションプロジェクトを使用している場合は、プロジェクトを構築する際にコードファイルが随時適用されるため、この点は多かれ少なかれ無関係になります。ページ（マークアップ）だけが動的にコンパイルされ、マークアップでシリアライズ可能な型の可能性はほぼゼロです（とにかく悪い考えのように思えます）。