6

この件に関する多くの Q&A を見つけましたが、サーバーの適切な構成をまだ理解していません。背景は次のとおりです。ロード バランサーの背後に 2 つの Web サーバーがあり、ユーザーのセッションが失われないようにする必要があります。

  • Web サーバーは IIS7/ASP.NET 4 です。
  • 現在、個別のセッション状態サーバーをセットアップできないため、LB でスティッキー セッションを使用する必要があります。

私が理解している限り、次のことを保証する必要があります。

  • 両方の Web サーバーで同じマシンキーを設定します。
  • アセンブリが両方のマシンで同じ名前になるように、プリコンパイル済みサイトを使用します。
  • IP 番号または Cookie に基づいてスティッキー セッションを作成する必要があります (後者が推奨されます)。

サイトをプリコンパイルする必要はありますか? (高速であることはわかっていますが、柔軟性が失われます)

スティッキー セッションがあるため、同じマシンキーを持つことは、ユーザーのセッションがタイムアウトした場合にのみ影響し、ユーザーが別のサーバーで終了するというのは正しいですか (つまり、ビュー ステートを含むポスト バックは有効でない場合があります)。同じマシンキー?)

4

1 に答える 1

6

あなたはすべての点で正しいです-LBのスティッキーセッションは、同じWebサーバーが後続のリクエストでヒットすることを保証するため、正しいインプロセスセッション状態が利用可能になります. ただし、LB の粘着性が ASP.NET セッションのタイムアウト値と一致する (またはそれ以上である) ことが不可欠です。たとえば、LB が粘着性のために Cookie を使用している場合、Cookie の有効期限は ASP.NET セッションの有効期限よりも長くする必要があります。

同じマシンキー引数は、リクエストのポストバックが何らかの理由で他のサーバーに送信される場合に役立ちます。クライアント側の状態 (ビューステートやイベントの検証、おそらく認証チケットなど) はマシン キーで暗号化されるため、同じキーを使用すると、どのサーバーでもポストバックを処理できます。余談ですが、すべての Web ファーム シナリオにおいて、予期せぬ事態を避けるために、すべての Web サーバーに正確な S/W 環境 (および可能な H/W 環境) を用意することは 100% 理にかなっています。

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

于 2013-01-18T09:27:15.407 に答える