ロードバランサの目的は、スタンドアロンまたはクラスタ化された複数のインスタンスの間でワークロードを均等に分散させ、それにより、システムの全体的なスループットを向上させることです。
融合ロードバランサにより、Java EE アプリケーションサーバーに配備されるサービスの高可用性を実現できます。負荷分散処理の間、それまでサービスを提供していたインスタンスが稼働していないか、または正常な状態でないために要求を処理できないことが検出された場合、融合ロードバランサはセッション要求を同じクラスタの別のサーバーインスタンスにフェイルオーバーします。
ロードバランサは、8K バイトを超える URI や URL を処理しません。
次の図は、ロードバランサの動作を表しています。
IP スプレーヤがクライアント要求を受信します。
IP スプレーヤはクラスタ内のすべてのインスタンスに要求を均等に分散させるもので、ハードウェア IP スプレーヤが使用されることもあります。IP スプレーヤなどのネットワーク要素は、融合ロードバランサの前面に出て、トランスポートレベルでクラスタのトラフィックを分散させます。
IP スプレーヤはクラスタ内の任意の SailFin インスタンスを選択して、そのインスタンスに要求を転送します。この例および図では、要求はインスタンス 1 に転送されています。
インスタンス 1 の融合ロードバランサはインスタンス (この場合はインスタンス 2) を選択して、要求を処理します。
要求を転送するためのサーバーインスタンスの選択は、設定されている「融合負荷分散アルゴリズム」に基づいて行われます。このキーは、スティッキネスを維持するためのヘッダーまたはパラメータとして要求に追加されます。
この例では、インスタンス 1 の融合ロードバランサは要求をインスタンス 2 に転送します。融合ロードバランサがこの要求を処理するためにインスタンス 1 を選択した場合、ステップ 5 は省略されます。
インスタンス 2 の融合ロードバランサは要求を受信し、要求がすでに別のインスタンスからプロキシされていることを検出します。さらなる処理がない場合、インスタンス 2 は要求をコンテナに受け渡して、処理できるようにします。インスタンス 2 の融合ロードバランサは応答をインスタンス 1 の融合ロードバランサに戻します。
インスタンス 1 の融合ロードバランサは応答をクライアントに戻します。
セッションが確立されると、応答にスティッキ情報が設定され、後続の要求にはこのスティッキ情報が保持されます。クライアントからの後続の要求には、ヘッダー/パラメータにスティッキ情報が含まれます。インスタンス 1 はこの要求を受信した場合でも、スティッキ情報を検出して、要求をインスタンス 2 の融合ロードバランサに転送します。
HTTP および HTTPS のスティッキネスを保つために、ロードバランサはクッキーまたは (ブラウザがクッキーをサポートしていない場合) URL リライティングを使用します。SIP/SIPS セッションの場合、ロードバランサは BEKey および BERoute などのパラメータを使用します。たとえば、融合ロードバランサは BERoute パラメータを送信要求の一部として VIA ヘッダーに貼り付けます。
ロードバランサは次のアルゴリズムのいずれかを自動的に使用します。
ラウンドロビンアルゴリズム — ロードバランサは新規メッセージを処理するためのインスタンスをラウンドロビン方式で選択します。
コンシステントハッシュ - ロードバランサは新規メッセージを処理するためのインスタンスを、要求から抽出したハッシュキーに基づいて選択します。ハッシュキーは、(提供されている場合) DCR ファイルで指定されたルールを使用して抽出されます。DCR ファイルが提供されていない場合、ハッシュキーはデフォルトのヘッダーを使用して抽出されます。
DCR ファイル data-centric-rules.xml は、融合アプリケーションまたは純粋な SIP アプリケーションからの HTTP/HTTPS および SIP/SIPS メッセージの両方に対してコンシステントハッシュを適用するためのルールを規定します。このファイルが指定されている場合、このファイル内の命令はデフォルトのヘッダーを使用してハッシュキーを抽出するメカニズムよりも優先されます。DCR ファイルが提供されていない場合、SIP および HTTP メッセージが同じセッションの一部であっても、異なるインスタンスによって処理されることがあります。融合アプリケーションを配備する場合、必ず DCR ファイルを提供してください。デフォルトのヘッダーを使用した場合、SIP メッセージの正しい負荷分散を実現できない場合もあります。したがって、純粋な SIP アプリケーションの場合でも、DCR ファイルを提供することをお勧めします。このファイルの詳細については、「設定の編集」 および 「データ中心ルールファイル」を参照してください。
純粋な Web アプリケーションに属す HTTP および HTTPS メッセージに対して、融合ロードバランサはデフォルトでは「スティッキラウンドロビン」アルゴリズムを使用します。新規要求がロードバランサに送信されると、単純なラウンドロビン方式に基づいてアプリケーションサーバーインスタンスに転送されます。要求がセッションベースのアプリケーション向けである場合、セッションが作成されることがあります。このような場合、応答にスティッキ情報が含まれ、後続のメッセージで戻されます。同じセッションベースのアプリケーション向けの同一クライアントから送信された後続のメッセージは、割り当てメッセージまたはスティッキメッセージと見なされ、ロードバランサによって同じインスタンス (そのインスタンスが健全と判定された場合) にルーティングされます。スティッキ (sticky: 粘着性の) ラウンドロビンという名前が付いているのはそのような理由からです。セッションベースでないアプリケーションへの要求や、セッションベースのアプリケーションに対する最初の要求は新規要求です。
純粋な SIP アプリケーションに属する SIP および SIPS メッセージに対して、融合ロードバランサはデフォルトでは「コンシステントハッシュ」アルゴリズムを使用します。DCR ファイルの中に SIP/SIPS 要求と一致するルールがある場合、ハッシュキーはそのルールを使用して抽出されます。DCR ファイルの中に SIP または SIPS 要求と一致するルールまたは命令がない場合、ハッシュキーは要求の from-tag,call-id パラメータを使用して生成されます。
融合ロードバランサは、融合アプリケーションからの HTTP/HTTPS および SIP/SIPS メッセージに対して適切なアルゴリズムを次のように適用します。
DCR ファイルが指定されていない場合、HTTP/HTTPS メッセージには「スティッキラウンドロビン」アルゴリズムを適用し、SIP/SIPS メッセージには「コンシステントハッシュ」アルゴリズムを適用します。
DCR ファイルが指定されている場合、HTTP/HTTPS メッセージおよび SIP/SIPS メッセージの両方に「コンシステントハッシュ」アルゴリズムを適用します。
融合アプリケーションに属する HTTP および HTTPS メッセージに対しては、DCR ファイルの中に HTTP/HTTPS 要求と一致するルールがある場合、そのルールを使用してハッシュキーが抽出されます。DCP ファイルの中に HTTP/HTTPS 要求と一致するルールまたは命令がない場合、HTTP 要求のポートおよびリモートホストを使用してハッシュキーが抽出されます。
SIP および SIPS メッセージに対しては、DCR ファイルの中に SIP/SIPS 要求と一致するルールがある場合、ハッシュキーはそのルールを使用して抽出されます。DCR ファイルの中に SIP または SIPS 要求と一致するルールまたは命令がない場合、ハッシュキーは要求の from-tag,call-id パラメータを使用して生成されます。
ロードバランサは、目標や環境に応じて、以下の節で説明している各種の方法で設定できます。
開発環境または本稼働環境では、1 つのクラスタに含まれるすべてのサーバーインスタンスが、専用の負荷分散インスタンスをまったく使用することなく、要求のリダイレクトおよび処理の両方にかかわるように指定できます。 これは、ターゲットと LB ターゲットが同じクラスタである「自己負荷分散」クラスタです。
フロントエンドハードウェア IP スプレーヤは、クラスタ内のすべてのインスタンスに要求を均等に分散させます。ハードウェア IP スプレーヤを使用しない場合、要求はクラスタ内のどのサーバーインスタンスにも転送できます。そのインスタンスの融合ロードバランサコンポーネントにより、要求は確実にクラスタ全体に分散されます。ただし、そのインスタンスはシングルポイント障害です。ハードウェア IP スプレーヤがあると、高可用性を実現できます。
開発環境では、1 つ以上のスタンドアロンサーバーインスタンスを、クラスタへの要求のリダイレクト、または要求を処理するその他のスタンドアロンインスタンスへの要求のリダイレクトを実行する専用ロードバランサとして指定できます。これらの専用ロードバランサは、ロードバランサの「ターゲット」と呼ばれます。
要求を処理するクラスタまたはインスタンスはロードバランサの「LB ターゲット」と呼ばれます。特定のロードバランサの LB ターゲットにはクラスタまたはスタンドアロンインスタンスを使用できますが、クラスタとインスタンスを混ぜることはできません。
クラスタ化されたサーバーインスタンスを LB ターゲットとして使用 - ロードバランサを配備する最も一般的な方法は、サーバーインスタンスのクラスタを LB ターゲットとして使用する方法です。デフォルトでは、クラスタ内のすべてのインスタンスは同じ設定を持ち、同じアプリケーションが配備されています。ロードバランサは、サーバーインスタンスの間でワークロードを分散させ、正常でないインスタンスから正常なインスタンスへのフェイルオーバーを要求します。複数のクラスタがある場合、要求はクラスタ間で負荷分散されますが、要求のフェイルオーバーは単一クラスタ内のインスタンス間でのみ行われます。
複数のスタンドアロンインスタンスを LB ターゲットとして使用 - 複数のスタンドアロンインスタンスを LB ターゲットとして使用し、これらの LB ターゲット間で要求を負荷分散およびフェイルオーバーするようにロードバランサを設定することもできます。ただし、この設定では、それぞれのスタンドアロンインスタンスに同種の環境が確保され、同じアプリケーションが配備されていることを手動で確認する必要があります。クラスタでは自動的に同種の環境が維持されるため、ほとんどの状況では、クラスタの使用がより適切で、より容易な方法です。
1 つのクラスタ内のすべてのインスタンスは、相互の IP アドレスに対して同様のビューが必要です。たとえば、インスタンス 1 およびインスタンス 2 という 2 つのインスタンスを持つクラスタについて考えてみます。インスタンス 1 がインスタンス 2 の IP アドレスを調べたときに、a.b.c.d を取得したとします。インスタンス 2 が自らの IP アドレスを調べたときにも、a.b.c.d (インスタンス 1 から見た場合と同じ IP アドレス) として認識される必要があります。ユーザーのマシンにあるホストファイルが正しく設定されていることを確認してください。
専用ロードバランサは本稼働環境ではサポートされません。