ロード・バランサのセッション永続性

アプリケーションCookieセッション永続性を構成するには、Cookie名を指定して、使用できないサーバーのフォールバックを無効にするかどうかを決定します。

ロード・バランサ・サービスは、バックエンド・サーバーによって、認識されたCookie名を含むSet-Cookieレスポンス・ヘッダーが送信されると、アプリケーションCookieセッション永続性(スティッキネス)をアクティブにします。Cookie名は、バックエンド・セットの構成で指定されている名前と一致する必要があります。構成ですべて一致パターンの'*'が指定されている場合、サーバーによって設定された任意のCookieでセッション永続性がアクティブになります。バックエンド・サーバーがセッション永続性をアクティブ化しないかぎり、サービスは、ロード・バランサの作成時に指定されたロード・バランシング・ポリシーに従います。

要件:

• ロード・バランサは、サーバー側のCookie駆動型セッション永続性をサポートするには、HTTPモードで動作している必要があります。
• クライアント・コンピュータは、ロード・バランサ・セッション永続性機能を動作させるには、Cookieを受け入れる必要があります。

ロード・バランサ・サービスは、構成済のCookieやその他のリクエスト・パラメータのハッシュを計算して、その値をCookieでクライアントに送信します。Cookieに格納された値により、サービスは後続のクライアント・リクエストを正しいバックエンド・サーバーにルーティングできます。バックエンド・サーバーが定義済のCookieを変更した場合、サービスはCookieの値を再計算してクライアントに再送信します。

バックエンド・サーバーは、セッション永続性Cookieを削除することで、アプリケーションCookie永続性を停止できます。すべて一致パターンを使用した場合は、すべてのCookieを削除する必要があります。過去の有効期限を持つSet-Cookieレスポンス・ヘッダーを送信して、Cookieを削除できます。ロード・バランサ・サービスでは、構成済のロード・バランシング・ポリシーを使用して後続のリクエストをルーティングします。

ロード・バランサCookieスティッキネスを構成すると、ロード・バランサによってCookieがレスポンスに挿入されます。Cookie内で構成されたパラメータにより、セッション・スティッキネスが有効になります。この方法は、独自のCookieを生成できるアプリケーションやWebバックエンド・サービスがある場合に役立ちます。

ロード・バランサのCookieセッション永続性を構成するには、次を指定します:

• Cookie名。

  Cookie名を指定しない場合、デフォルト名はX-Oracle-BMC-LBS-Routeです。

  ノート
  
  バックエンド・アプリケーション・サーバーで使用されるクッキー名が、ロード・バランサで使用されるCookie名と異なっています。名前の衝突の可能性を最小限に抑えるために、X-Oracle-OCI-などの接頭辞を使用することをお薦めします。

  バックエンド・サーバーとロード・バランサが両方とも同じ名前のCookieを挿入した場合、クライアントまたはブラウザの動作は、Cookieに関連付けられているドメイン値に応じて異なる可能性があります。(バックエンド・サーバーによって生成された) Set-cookieヘッダーおよび(ロード・バランサによって生成された) Set-cookieヘッダーの名前とドメインの値が同じ場合、クライアントまたはブラウザではそれらを1つのCookieとして処理します。クライアントは、後続のリクエストでそれらのCookie値の1つのみを戻します。両方のSet-cookie名が同じで、ドメイン名が異なる場合、クライアントまたはブラウザではそれらを2つの異なるCookieとして処理します。

• Cookieが有効なドメイン。ロード・バランサによって挿入されたSet-cookieヘッダーには、指定された値を持つドメイン属性が含まれます。

  この属性にデフォルト値はありません。値を指定しない場合、ロード・バランサではドメイン属性がSet-cookieヘッダーに挿入されません。

  ノート
  
  

  • RFC 6265 - HTTP状態管理メカニズムは、ドメイン属性がSet-cookieヘッダー内に存在する場合または存在しない場合のクライアントおよびブラウザの動作を説明しています。

    Set-cookieヘッダー内のDomain属性の値がexample.comである場合、example.com、www.example.comおよびwww.abc.example.comに対してHTTPリクエストを送信する際、クライアントのCookieヘッダーには同じCookieが含まれます。Domain属性が存在しない場合、クライアントは、元のリクエストが行われたドメインに対してのみCookieを返します。

  • この属性が正しいドメイン値を指定していることを確認してください。Set-cookieヘッダーのDomain属性に元のリクエストの送信先のドメインが含まれていなかった場合、クライアントまたはブラウザではCookieが拒否されることがあります。RFC 6265で指定されているように、クライアントは、www.example.comから送信されたDomain属性値がexample.comまたはwww.example.comのCookieを受け入れます。www.example.comから送信されたDomain属性がabc.example.comまたはwww.abc.example.comのCookieを受け入れません。

   
• Cookieが有効なURIパス。ロード・バランサによって挿入されたSet-cookieヘッダーには、指定された値を持つPath属性が含まれます。

  クライアントでは、request-uriのパス部分がCookieのPath属性と一致する(またはそのサブディレクトリである)場合にのみ、HTTPリクエストにCookieが含まれます。

  デフォルト値は`/`です。

• Cookieが有効な期間。ロード・バランサによって挿入されたSet-cookieヘッダーには、指定された値を持つMax-Age属性が含まれます。

  指定された値は、1秒以上である必要があります。この属性のデフォルト値は存在しません。値を指定しない場合、ロード・バランサはMax-Age属性をSet-cookieヘッダーに含めません。通常、クライアントまたはブラウザは、クライアントによる定義どおり、現在のセッションが終了するまでCookieを保持します。

• Set-cookieヘッダーにSecure属性を含めるかどうか。Secure属性は、セキュア・プロトコルを使用している場合にのみ、Cookieを送信するようクライアントまたはブラウザに指示します。
  ノート
  
  

  このフィールドをtrueに設定した場合、対応するバックエンド・セットをHTTPリスナーに関連付けることができません。

• Set-cookieヘッダーにHttpOnly属性を含めるかどうか。HttpOnly属性は、CookieのスコープをHTTPリクエストに制限します。この属性は、HTTP以外のAPIを介してCookieにアクセスする場合に、Cookieを省略するようクライアントまたはブラウザに指示します。たとえば、JavaScriptチャネルからCookieを制限します。
• 使用できないサーバーのフォールバックを無効にするかどうか。