test

Sun GlassFish Communications Server 1.5 高可用性 (HA) 管理ガイド

融合ロードバランサの動作

ロードバランサの目的は、スタンドアロンまたはクラスタ化された複数のインスタンスの間でワークロードを均等に分散させ、それにより、システムの全体的なスループットを向上させることです。

融合ロードバランサにより、Java EE アプリケーションサーバーに配備されるサービスの高可用性を実現できます。負荷分散処理の間、それまでサービスを提供していたインスタンスが稼働していないか、または正常な状態でないために要求を処理できないことが検出された場合、融合ロードバランサはセッション要求を同じクラスタの別のサーバーインスタンスにフェイルオーバーします。

注 –

ロードバランサは、8K バイトを超える URI や URL を処理しません。

次の図は、ロードバランサの動作を表しています。

融合ロードバランサの機能

  1. IP スプレーヤがクライアント要求を受信します。

    注 –

    IP スプレーヤはクラスタ内のすべてのインスタンスに要求を均等に分散させるもので、ハードウェア IP スプレーヤが使用されることもあります。IP スプレーヤなどのネットワーク要素は、融合ロードバランサの前面に出て、トランスポートレベルでクラスタのトラフィックを分散させます。

  2. IP スプレーヤはクラスタ内の任意の SailFin インスタンスを選択して、そのインスタンスに要求を転送します。この例および図では、要求はインスタンス 1 に転送されています。

  3. インスタンス 1 の融合ロードバランサはインスタンス (この場合はインスタンス 2) を選択して、要求を処理します。

    要求を転送するためのサーバーインスタンスの選択は、設定されている「融合負荷分散アルゴリズム」に基づいて行われます。このキーは、スティッキネスを維持するためのヘッダーまたはパラメータとして要求に追加されます。

  4. この例では、インスタンス 1 の融合ロードバランサは要求をインスタンス 2 に転送します。融合ロードバランサがこの要求を処理するためにインスタンス 1 を選択した場合、ステップ 5 は省略されます。

  5. インスタンス 2 の融合ロードバランサは要求を受信し、要求がすでに別のインスタンスからプロキシされていることを検出します。さらなる処理がない場合、インスタンス 2 は要求をコンテナに受け渡して、処理できるようにします。インスタンス 2 の融合ロードバランサは応答をインスタンス 1 の融合ロードバランサに戻します。

  6. インスタンス 1 の融合ロードバランサは応答をクライアントに戻します。

  7. セッションが確立されると、応答にスティッキ情報が設定され、後続の要求にはこのスティッキ情報が保持されます。クライアントからの後続の要求には、ヘッダー/パラメータにスティッキ情報が含まれます。インスタンス 1 はこの要求を受信した場合でも、スティッキ情報を検出して、要求をインスタンス 2 の融合ロードバランサに転送します。

    HTTP および HTTPS のスティッキネスを保つために、ロードバランサはクッキーまたは (ブラウザがクッキーをサポートしていない場合) URL リライティングを使用します。SIP/SIPS セッションの場合、ロードバランサは BEKey および BERoute などのパラメータを使用します。たとえば、融合ロードバランサは BERoute パラメータを送信要求の一部として VIA ヘッダーに貼り付けます。

融合負荷分散アルゴリズム

ロードバランサは次のアルゴリズムのいずれかを自動的に使用します。

Web アプリケーション向けの融合負荷分散アルゴリズム

純粋な Web アプリケーションに属す HTTP および HTTPS メッセージに対して、融合ロードバランサはデフォルトでは「スティッキラウンドロビン」アルゴリズムを使用します。新規要求がロードバランサに送信されると、単純なラウンドロビン方式に基づいてアプリケーションサーバーインスタンスに転送されます。要求がセッションベースのアプリケーション向けである場合、セッションが作成されることがあります。このような場合、応答にスティッキ情報が含まれ、後続のメッセージで戻されます。同じセッションベースのアプリケーション向けの同一クライアントから送信された後続のメッセージは、割り当てメッセージまたはスティッキメッセージと見なされ、ロードバランサによって同じインスタンス (そのインスタンスが健全と判定された場合) にルーティングされます。スティッキ (sticky: 粘着性の) ラウンドロビンという名前が付いているのはそのような理由からです。セッションベースでないアプリケーションへの要求や、セッションベースのアプリケーションに対する最初の要求は新規要求です。

SIP アプリケーション向けの融合負荷分散アルゴリズム

純粋な SIP アプリケーションに属する SIP および SIPS メッセージに対して、融合ロードバランサはデフォルトでは「コンシステントハッシュ」アルゴリズムを使用します。DCR ファイルの中に SIP/SIPS 要求と一致するルールがある場合、ハッシュキーはそのルールを使用して抽出されます。DCR ファイルの中に SIP または SIPS 要求と一致するルールまたは命令がない場合、ハッシュキーは要求の from-tag,call-id パラメータを使用して生成されます。

融合アプリケーション向けの融合負荷分散アルゴリズム

融合ロードバランサは、融合アプリケーションからの HTTP/HTTPS および SIP/SIPS メッセージに対して適切なアルゴリズムを次のように適用します。

融合ロードバランサの配備

ロードバランサは、目標や環境に応じて、以下の節で説明している各種の方法で設定できます。

自己負荷分散クラスタの使用

開発環境または本稼働環境では、1 つのクラスタに含まれるすべてのサーバーインスタンスが、専用の負荷分散インスタンスをまったく使用することなく、要求のリダイレクトおよび処理の両方にかかわるように指定できます。 これは、ターゲットと LB ターゲットが同じクラスタである「自己負荷分散」クラスタです。

フロントエンドハードウェア IP スプレーヤは、クラスタ内のすべてのインスタンスに要求を均等に分散させます。ハードウェア IP スプレーヤを使用しない場合、要求はクラスタ内のどのサーバーインスタンスにも転送できます。そのインスタンスの融合ロードバランサコンポーネントにより、要求は確実にクラスタ全体に分散されます。ただし、そのインスタンスはシングルポイント障害です。ハードウェア IP スプレーヤがあると、高可用性を実現できます。

専用負荷分散サーバーインスタンスの使用

開発環境では、1 つ以上のスタンドアロンサーバーインスタンスを、クラスタへの要求のリダイレクト、または要求を処理するその他のスタンドアロンインスタンスへの要求のリダイレクトを実行する専用ロードバランサとして指定できます。これらの専用ロードバランサは、ロードバランサの「ターゲット」と呼ばれます。

要求を処理するクラスタまたはインスタンスはロードバランサの「LB ターゲット」と呼ばれます。特定のロードバランサの LB ターゲットにはクラスタまたはスタンドアロンインスタンスを使用できますが、クラスタとインスタンスを混ぜることはできません。

注 –

専用ロードバランサは本稼働環境ではサポートされません。