4

アプリケーション制御のセッション スティッキネス (この場合は Amazon の AWS) を備えた HTTP ロード バランサーを使用する場合、ロード バランサーは明らかに、すべてのセッション Cookie とそのターゲット インスタンスをマップに記憶する必要があります。したがって、このグローバル マップは、「セッション Cookie からインスタンスへ」の関係を維持する必要があります。

Web アプリのユーザーがブラウザーを閉じることにした場合、セッションはセッション タイムアウト後にアプリ サーバーでサイレントに終了します。

これは、ロード バランサーがグローバル マップで「セッション Cookie からインスタンスへ」の関係を保持していることを意味します。このマッピングは現在役に立たず、セッション cookie には有効期限がないため、(リソースを解放するために) ガベージ コレクションを実行する必要があります。

私の質問は次のとおりです。

  1. 一般に、ロード バランサーはリソースを使い果たすことなくこのシナリオにどのように対処しますか?

  2. 特に、リソースを使い果たすことなく、このシナリオで Amazon AWS ロード バランサーを処理するにはどうすればよいでしょうか?

4

1 に答える 1

6

通常、アプリケーション対応 (レイヤー 7) の LB は、セッションの (大きな) マップを維持しません。かもしれない：

  1. クライアントへの最初の応答に独自の Cookie を挿入します (クライアントは後続の要求でそれを再送信するため、LB はターゲット Web サーバーを決定できます)。

  2. たとえば、既知のセッション Cookie (JSESSIONID など) を、ターゲット Web サーバーを識別する情報 (および、LB が後続の要求で Web サーバーに提示する前に削除する情報) を追加することによって書き換えます。

重要な点は、LB がセッションからターゲットへのマップを維持しないことです。その情報は、各クライアントに存在する Cookie 内に存在します。

私は、AWS が (AWSELB という名前の Cookie を使用して) 1 位だと思います。

于 2013-03-15T01:11:57.193 に答える