第 2 章 融合負荷分散の設定

この章では、融合負荷分散について説明します。ここで説明する内容は次のとおりです。

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

• 「融合負荷分散の設定」

• 「融合ロードバランサの設定」

• 「データ中心ルールファイル」

この章では、Communications Server に含まれている融合ロードバランサを使用して、HTTP、HTTPS、SIP、および SIPS メッセージの負荷を分散する方法について説明します。

もう 1 つの 負荷分散オプションは、Communications Server で Sun Secure Application Switch を使用し、ハードウェアベースの負荷分散ソリューションを構築するというものです。このソリューションの設定については、Clustering and Securing Web Applications: A Tutorial を参照してください。

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

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

融合ロードバランサにより、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 ヘッダーに貼り付けます。

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

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

• ラウンドロビンアルゴリズム — ロードバランサは新規メッセージを処理するためのインスタンスをラウンドロビン方式で選択します。

• コンシステントハッシュ - ロードバランサは新規メッセージを処理するためのインスタンスを、要求から抽出したハッシュキーに基づいて選択します。ハッシュキーは、(提供されている場合) DCR ファイルで指定されたルールを使用して抽出されます。DCR ファイルが提供されていない場合、ハッシュキーはデフォルトのヘッダーを使用して抽出されます。

  DCR ファイル data-centric-rules.xml は、融合アプリケーションまたは純粋な SIP アプリケーションからの HTTP/HTTPS および SIP/SIPS メッセージの両方に対してコンシステントハッシュを適用するためのルールを規定します。このファイルが指定されている場合、このファイル内の命令はデフォルトのヘッダーを使用してハッシュキーを抽出するメカニズムよりも優先されます。DCR ファイルが提供されていない場合、SIP および HTTP メッセージが同じセッションの一部であっても、異なるインスタンスによって処理されることがあります。融合アプリケーションを配備する場合、必ず DCR ファイルを提供してください。デフォルトのヘッダーを使用した場合、SIP メッセージの正しい負荷分散を実現できない場合もあります。したがって、純粋な SIP アプリケーションの場合でも、DCR ファイルを提供することをお勧めします。このファイルの詳細については、「設定の編集」 および 「データ中心ルールファイル」を参照してください。

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

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

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

純粋な 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 アドレス) として認識される必要があります。ユーザーのマシンにあるホストファイルが正しく設定されていることを確認してください。

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

融合負荷分散の設定

この節では、ロードバランサを設定する方法について説明します。次の項目が含まれています。

• 「融合負荷分散を設定するための前提条件」

• 「融合負荷分散を設定するための手順」

融合負荷分散を設定するための前提条件

ロードバランサを設定する前に、次の手順を実行する必要があります。

• クラスタプロファイルを使用して、負荷分散にかかわる Communications Server クラスタまたはサーバーインスタンスを作成します。詳細は、第 3 章Communications Server でのクラスタの設定を参照してください。

• グループ管理サービス (GMS) が有効になっていることを確認します。デフォルトでは有効になっています。詳細は、「グループ管理サービス」を参照してください。

• 該当するクラスタまたはサーバーインスタンスのノードエージェントを作成します。詳細は、第 4 章ノードエージェントの設定を参照してください。

• これらのクラスタまたはインスタンスに対してアプリケーションを配備します。詳細は、『Sun GlassFish Communications Server 1.5 Application Deployment Guide』を参照してください。

融合負荷分散を設定するための手順

ユーザーの環境で負荷分散を設定するには、管理コンソールまたは asadmin コマンドを使用します。以降の節では、さらに詳しい情報を示します。

管理コンソールを使用して融合負荷分散を設定する

1. ロードバランサを作成します。

   左側の区画で「融合ロードバランサ」をクリックし、「新規」をクリックします。「新しい融合ロードバランサ」ページで、ロードバランサ名を入力し、ロードバランサの役割を果たすターゲットクラスタまたはインスタンスも選択します。

   任意で、次の設定を指定できます。

   • 設定ファイル名 — 融合ロードバランサの設定ファイルの名前を指定します。 設定ファイルのデフォルトのパスおよび名前は、domain-dir/config/cluster-config /converged-loadbalancer.xml です。

   • 変更を自動的に適用 — 設定変更をターゲットサーバーインスタンスに自動的に適用するかどうかを指定します。 デフォルトでは、この設定はオフになっています。この設定を true にして、融合ロードバランサの設定ファイルを生成します。

   • 自己負荷分散 — ターゲットクラスタを自己負荷分散にするかどうかを指定します。デフォルトでは、この設定はオンになっています。本稼働環境では、自己負荷分散ターゲットクラスタのみがサポートされます。

2. 自己負荷分散でないロードバランサの場合、ロードバランサが管理できるように、クラスタまたはスタンドアロンサーバーインスタンスに参照を追加します。

   左側の区画で「融合ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。「融合ロードバランサの LB ターゲット」タブを開いて、「LB ターゲットの管理」をクリックし、「LB ターゲットの管理」ページで必要な LB ターゲットを選択します。

   クラスタまたはスタンドアロンインスタンスを LB ターゲットとして選択できます。クラスタとスタンドアロンインスタンスの組み合わせを LB ターゲットとして選択することはできません。

   ---

   注 –

   このステップは、本稼働環境ではサポートされません。

   ---

3. ロードバランサを作成したときにクラスタがすでに起動している場合、ロードバランサを起動するには、クラスタを再起動する必要があります。

参照

詳細については、管理コンソールのオンラインヘルプを参照してください。

asadmin コマンドを使用して融合負荷分散を設定する

1 つの asadmin コマンド、create-converged-lb を使用すると、次のステップを実行できます。

1. ロードバランサ設定を作成します。

   asadmin create-converged-lb-config コマンドを使用します。

2. ロードバランサが管理するクラスタまたはスタンドアロンサーバーインスタンスへの参照を追加します。

   asadmin create-converged-lb-ref コマンドを使用します。

   ---

   注 –

   クラスタ配備の設定および定義の繰り返し処理を実行するときは、--autocommit を false に設定することをお勧めします。デフォルトで、このオプションは false に設定されています。これは主に中間融合ロードバランサファイルの生成を防止することが目的です。この設定がないと、domain.xml の変更のたびに中間ファイルが生成され、融合ロードバランサ自体の設定の表示に影響を及ぼします。クラスタ配備定義が展開の安定段階に達した時点で、--autocommit を true に設定します。

   ---

例 2–1 融合ロードバランサの作成

次の一連の asadmin コマンドでは、クラスタ、ノードエージェント、および自己負荷分散融合ロードバランサを設定します。

asadmin> create-cluster cluster1
    Command create-cluster executed successfully.
asadmin>create-node-agent --user admin --passwordfile pass.txt 
--host host1 nodeagent1
    Command create-node-agent executed successfully.
asadmin>create-node-agent --user admin --passwordfile pass.txt 
--host host1 nodeagent2
    Command create-node-agent executed successfully.
asadmin>create-instance --user admin --passwordfile pass.txt --nodeagent nodeagent1 
--cluster cluster1 cluster1_instance1
   Command create-instance executed successfully.
asadmin> create-instance --user admin --passwordfile pass.txt 
--nodeagent nodeagent2 --cluster cluster1 cluster1_instance2
   Command create-instance executed successfully.
asadmin> create-converged-lb --user admin --passwordfile pass.txt 
--configfile clb.xml --autocommit=true --lbenableallinstances=true 
--target cluster1 clb-1
   Command create-converged-lb executed successfully.
asadmin> start-node-agent nodeagent1
   Command start-node-agent started successfully.
asadmin> start-node-agent nodeagent2
   Command start-node-agent started successfully.
asadmin> start-cluster cluster1
 cluster1_instance1 is running, does not require restart
 cluster1_instance2 is running, does not require restart
 Command start-cluster executed successfully.

ロードバランサを作成したときにクラスタがすでに起動している場合、ロードバランサを起動するには、クラスタを再起動する必要があります。

参照

これらの asadmin コマンドの詳細については、『Sun GlassFish Communications Server 1.5 Reference Manual 』 を参照してください。

融合ロードバランサの設定

次の節では、ロードバランサ設定を変更および使用する方法についてさらに詳しく説明します。

• 「管理コンソールでのロードバランサ設定の編集」

• 「ロードバランサ設定の編集」

• 「サーバーインスタンスの負荷分散の有効化または無効化」

• 「融合ロードバランサのログメッセージレベルの変更」

管理コンソールでのロードバランサ設定の編集

融合ロードバランサの作成後、次の節の説明に従うと、管理コンソールで融合ロードバランサの設定を編集できます。

• 「設定の編集」

• 「ロードバランサの詳細編集」

• 「自己負荷分散の編集 (ロードバランサターゲットの詳細)」

設定の編集

管理コンソールでロードバランサを設定するには、左側の区画で「融合ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。「設定」タブを開きます。「融合ロードバランサ設定を編集」ページが表示されます。

次の表では、ロードバランサ設定の設定について説明します。

ロードバランサの詳細編集

融合ロードバランサの作成後、融合ロードバランサ設定を変更できます。

管理コンソールでロードバランサの詳細を編集するには、左側の区画で「融合ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。「ターゲット」タブを開きます。「Edit Load Balancer Details」を選択します。「Edit Load Balancer Details」ページが表示されます。

次の表では、ロードバランサの詳細設定について説明します。

自己負荷分散の編集 (ロードバランサターゲットの詳細)

ロードバランサの作成後、ロードバランサターゲットクラスタを自己負荷分散にするかどうかを変更できます。

管理コンソールでロードバランサターゲットの詳細を編集するには、左側の区画で「融合ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。「LB ターゲット」タブを開きます。「LB ターゲットの詳細を編集」を選択します。「LB ターゲットの詳細を編集」ページが表示されます。このページでは、「自己負荷分散」だけが編集可能な設定です。この設定は有効または無効にすることができます。

自己負荷分散を無効にしたロードバランサは、本稼働環境ではサポートされません。

ロードバランサ設定の編集

ロードバランサの作成後、asadmin set コマンドを使用すると、ロードバランサ設定を編集できます。

融合ロードバランサ設定を編集するには、次のコマンドを使用します。

asadmin set config-name-config.availability-service.converged-load-balancer.setting

次に例を示します。

asadmin set c1-config.availability-service.converged-load-balancer.config-file=myclb.xml

asadmin set c1-config.availability-service.converged-load-balancer.auto-commit=true

asadmin set c1-config.availability-service.converged-load-balancer.converged-lb-config-name=myclb-config

融合ロードバランサプロキシ設定を編集するには、次のコマンドを使用します。

asadmin set config-name-config.availability-service.converged-load-balancer.proxy.setting

次に例を示します。

asadmin set c1-config.availability-service.converged-load-balancer.proxy.request-pool-size=50
asadmin set c1-config.availability-service.converged-load-balancer.proxy.send-retry-count=3
asadmin set c1-config.availability-service.converged-load-balancer.proxy.read-time-out=1500

融合ロードバランサプロキシ設定ポリシーの設定を編集するには、次のコマンドを使用します。

asadmin set domain.converged-lb-config.clb-config.converged-lb-policy.setting

次に例を示します。

asadmin set domain.converged-lb-configs.myclb-config.converged-lb-policy.http=round-robin

asadmin set domain.converged-lb-configs.myclb-config.converged-lb-policy.sip=from-tag,call-id

クラスタの self-loadbalance 設定を編集するには、次のコマンドを使用します。

asadmin set domain.converged-lb-config.clbcfg.converged-lb-cluster-ref.cluster.self-loadbalance=setting

次に例を示します。

asadmin set domain.converged-lb-configs.myclb-config.converged-lb-cluster-ref.clust1.self-loadbalance=true

自己負荷分散を無効にしたロードバランサは、本稼働環境ではサポートされません。

asadmin set コマンドの詳細については、『Sun GlassFish Communications Server 1.5 Reference Manual』を参照してください。

サーバーインスタンスの負荷分散の有効化または無効化

サーバーインスタンスを停止する前に、要求が別のインスタンスにフェイルオーバーされるように、そのインスタンスの負荷分散を無効にする必要があります。サーバーインスタンスまたはクラスタの負荷分散を無効にするには、asadmin disable-converged-lb-server コマンドを使用します。

次に例を示します。

asadmin disable-converged-lb-server --user admin --passwordfile pass.txt cluster1

asadmin enable-converged-lb-server コマンドを使用すると、サーバーインスタンスまたはクラスタの負荷分散を有効にすることができます。デフォルトでは、新規のインスタンスまたはクラスタを作成したとき、lb-enabled オプションは false に設定されます。ユーザーはインスタンスまたはクラスタの負荷分散を明示的に有効にする必要があります。

次に例を示します。

asadmin enable-converged-lb-server --user admin --passwordfile pass.txt cluster1

asadmin disable-converged-lb-server コマンドおよび asadmin enable-converged-lb-server の詳細については、『Sun GlassFish Communications Server 1.5 Reference Manual』を参照してください。

融合ロードバランサのログメッセージレベルの変更

融合ロードバランサメッセージのデフォルトのログレベルは、INFO に設定されています。この設定を変更するには、asadmin set コマンドを使用して javax.enterprise.system.container.clb プロパティーを変更します。たとえば、次のようにすると、c1-config のログレベルを FINE に変更できます。

asadmin set c1-config.log-service.module-log-levels.property.clb=FINE

asadmin set c1-config.log-service.module-log-levels.property.sip=FINE

データ中心ルールファイル

データ中心ルールファイルのデフォルトのパスおよび名前は、domain-dir /cluster/config/ data-centric-rules.xmlです。データ中心ルールファイルを指定する融合ロードバランサ設定がクラスタまたはスタンドアロンサーバーインスタンスをまったく参照しない場合、デフォルトのパスおよび名前は domain-dir/config/ data-centric-rules.xmlです。ファイル形式を検証する DTD ファイルは、as-install/lib/dtds/ sun-data-centric-rule_1_0.dtd です。

データ中心ルールファイルが指定されている場合、コンシステントハッシュアルゴリズムにより、要求の転送先のサーバーインスタンスが特定されます。サーバーインスタンスの選択は、ハッシュキーに基づいて行われます。キーは、データ中心ルールに従って、受信される SIP および HTTP 要求から抽出されます。これらのルールは、LB ターゲットに配備されたすべてのアプリケーションに適用され、操作中に変更できます。そのような変更は、新規の初期要求のみに影響を及ぼします。

データ中心ルール言語は、要求をサーブレットにマッピングするためのトリガー言語に似ています。ルール言語は、SIP および HTTP キー抽出をサポートする変数および条件から構成されます。サーブレットマッピング言語と対照的に、データ中心ルールファイルは、non-null (true) または null (false) のいずれかの値を返す必要があります。

個々の受信される SIP および HTTP 要求は、現在のルールセットと合わされます。一致する最初のルールがキー抽出に使用されます。条件が non-null 値を返すまで、ルールは順次評価されます。OR 式の場合、最初の non-null sub-result が返されます。AND 式の場合、最後の sub-result が返されます。一致するルールがない場合、キーは null に設定されます。

HTTP 要求が DCR ファイルルールにまったく一致しない場合、ハッシュキーはリモートホストおよびポートを使用して生成されます。SIP 要求が DCR ファイルルールにまったく一致しない場合、ハッシュキーは from-tag,call-id を使用して生成されます。

次はデータ中心ルールファイルの例です。

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE user-centric-rules PUBLIC "-//Sun Microsystems Inc.//DTD Sailfin 1.0//EN" 
"http://www.sun.com/software/appserver/dtds/sun-data-centric-rule_1_0.dtd">
<user-centric-rules>
  <sip-rules>
    <if>
      <session-case>
        <equal>ORIGINATING</equal>
        <if>   
          <header name="P-Asserted-Identity" 
              return="request.P-Asserted-Identity.uri.resolve.user">
            <exist/>
          </header>    
          <if> 
            <header name="P-Asserted-Identity" 
                return="request.from.uri.resolve.user">
              <notexist/>
            </header>    
            <if> 
              <header name="P-Asserted-Identity" 
                  return="request.to.uri.resolve.user">
                <notexist/>
              </header>    
            </if>
          </if>
        </if>
      </session-case>
      <else return="request.uri.resolve.user" />
    </if>
  </sip-rules>
  <http-rules>   
    <or>
      <request-uri return="match.resolve.user">
        <match>/users/([^/]+)</match>
      </request-uri>
      <and>
        <request-uri>
          <match>^/css/</match>
        </request-uri>
        <or>
          <request-uri parameter="referredBy" 
              return="parameter.requestUri.uri.resolve.user">
            <exist/>
          </request-uri>
          <request-uri parameter="referredBy" 
              return="parameter.from.uri.resolve.user">
            <notexist/>
          </request-uri>
        </or>
      </and>
    </or>
  </http-rules>    
</data-centric-rules>

次の節では、data-centric-rules.xml ファイルの要素について説明します。

トップレベル要素

トップレベル要素は SIP/SIPS および HTTP/HTTPS 要求のルールを決定します。

user-centric-rules

これは data-centric-rules.xml ファイルのトップレベルまたはルート要素です。

サブ要素

次のサブ要素のいずれかまたは両方を指定できます: 「sip-rules」、「http-rules」

sip-rules

SIP および SIPS 要求のデータ中心ルールを決定します。

上位要素

「user-centric-rules」

サブ要素

次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。

「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」

http-rules

HTTP および HTTPS 要求のデータ中心ルールを決定します。

上位要素

「user-centric-rules」

サブ要素

次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。

「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」

演算子要素

演算子要素は、複数のルール間での決定を指定します。 or、and、および if 要素は再帰的です。これらの要素の分岐およびレベルは、各分岐の最も低いレベルに「条件要素」の 1 つが含まれている限り、何個でも指定できます。

or

含まれている条件の少なくとも 1 つが non-null 値と評価されるときに限り、true と評価されます。

上位要素

「sip-rules」、「http-rules」、「or」、「and」、「if」

サブ要素

次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。

「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」

and

含まれている条件のすべてが non-null 値と評価されるときに限り、true と評価されます。

上位要素

「sip-rules」、「http-rules」、「or」、「and」、「if」

サブ要素

次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。

「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」

if

1 つの条件を含みます。条件が non-null 値と評価された場合、評価は if 分岐で続行されます。条件が null と評価された場合、評価はオプションの else 分岐で続行されます。

上位要素

「sip-rules」、「http-rules」、「or」、「and」、「if」

サブ要素

次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。

「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」

「else」 サブ要素はオプションです。指定する場合には、最後に置く必要があります。

else

親の if 要素の条件が null と評価された場合に、代替文を指定します。

上位要素

「if」

属性

次の属性が必須です。大文字と小文字は区別されます。

return

戻り値として評価される変数を指定します。「変数」を参照してください。

条件要素

条件要素は、ルール決定の基になるデータの種類を指定します。すべての属性値は大文字と小文字が区別されます。

header

要求ヘッダーに基づいてルールを指定します。

上位要素

「sip-rules」、「http-rules」、「or」、「and」、「if」

サブ要素

次のサブ要素が厳密に 1 つ必要です。

「exist」、「notexist」

属性

次の属性が必要です。

name

要求ヘッダーの名前を指定します。

return

戻り値として評価される変数を指定します。「変数」を参照してください。

request-uri

要求 URI とそのパラメータに基づいてルールを指定します。

上位要素

「sip-rules」、「http-rules」、「or」、「and」、「if」

サブ要素

次のサブ要素が厳密に 1 つ必要です。

「exist」、「notexist」、「match」

属性

次の属性は、サブ要素が exist または notexist である場合は必須で、サブ要素が match である場合はオプションです。

parameter

要求 URI パラメータを指定します。

return

戻り値として評価される変数を指定します。「変数」を参照してください。

session-case

SIP セッションの call パラメータに基づいてルールを指定します。IMS/3GPP (Internet Protocol Multimedia Subsystem Third Generation Partnership Project: インターネットプロトコルマルチメディアサブシステム / 第 3 世代移動体通信システムの標準化プロジェクト) 環境でのみ関連性があります。詳細は、「equal」 サブ要素の説明を参照してください。

上位要素

「sip-rules」、「http-rules」、「or」、「and」、「if」

サブ要素

「equal」 サブ要素は必須で、先頭に置く必要があります。

次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。

「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」

cookie

HTTP クッキーに基づいてルールを指定します。

上位要素

「sip-rules」、「http-rules」、「or」、「and」、「if」

サブ要素

次のサブ要素が厳密に 1 つ必要です。

「exist」、「notexist」

属性

次の属性が必要です。

name

クッキーの名前を指定します。

return

戻り値として評価される変数を指定します。「変数」を参照してください。

条件型要素

条件型要素は要求データをルールによって予測されているデータと比較します。すべての比較で、大文字と小文字は区別されます。

exist

要求に存在する header、 request-uri、または cookie として変数が評価されるように指定します。「変数」を参照してください。

上位要素

「header」、「request-uri」、「cookie」

notexist

要求に存在しない header、 request-uri、または cookie として変数が評価されるように指定します。「変数」を参照してください。

上位要素

「header」、「request-uri」、「cookie」

equal

呼び出しのどの部分 (呼び出しの発信側または終端側) が処理されるかを指定します。 IMS/3GPP 環境でのみ関連性があります。指定できる値は次のとおりです。

• EXTERNAL — SIP 要求にルートヘッダーがない、またはルートヘッダーに call パラメータがないことを指定します。

• ORIGINATING — ルートヘッダーに call=orig が含まれることを指定します。

• TERMINATING — ルートヘッダーに call=term_registered が含まれることを指定します。

• TERMINATING_UNREGISTERED — ルートヘッダーに call=term_unregistered が含まれることを指定します。

上位要素

「session-case」

match

request-uri が一致する必要のある正規表現を指定します。戻り値は、正規表現の前方参照を行うグループの一致です。正規表現の詳細については、http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Pattern.html を参照してください。

match 要素では、オプションの接頭辞を戻り値に付加できます。

上位要素

「request-uri」

変数

データ中心ファイルの name、parameter、および return 属性と 「exist」 および 「notexist」 要素では、変数が使用されます。 文字列 resolve を含む変数には、TEL URI の ENUM 検索を実行することで取得された値が含まれます。一部の変数には、置換可能なテキストが含まれます。たとえば、request. header 変数では、header は SIP または HTTP ヘッダーの名前に置き換えられます。SIP および HTTP 要求を一致させるための構文は多少異なります。

次の SIP 変数がサポートされます。

request.uri
request.uri.scheme
request.uri.user
request.uri.host
request.uri.port
request.method

request.uri.resolve
request.uri.resolve.user
request.uri.resolve.host

request.header
request.header.uri
request.header.uri.scheme
request.header.uri.user
request.header.uri.host
request.header.uri.port
request.header.uri.display-name

request.header.uri.resolve
request.header.uri.resolve.user
request.header.uri.resolve.host

request.header.match
request.header.match.resolve.user

match
match.resolve.user

次の HTTP 変数がサポートされます。

request.header
request.header.uri
request.header.uri.user
request.header.uri.host
request.header.uri.resolve
request.header.uri.resolve.user
request.header.uri.resolve.host

parameter.parameter
parameter.parameter.uri
parameter.parameter.uri.user
parameter.parameter.uri.host
parameter.parameter.uri.resolve
parameter.parameter.uri.resolve.user
parameter.parameter.uri.resolve.host

match
match.resolve.user

cookie.cookie-name

HTTP 変数 parameter. parameter.uri.resolve.user の解決は複雑です。この変数は HTTP 要求のパラメータ値と一致します。この値は 1 つの name-addr か、またはそのシーケンス (コンマ区切り) です。name-addr 要素は、使用可能なユーザー中心ハッシュキーが見つかるまで解決されます。分解の順序は次のとおりです。

1. name-addr に user=phone パラメータが含まれている場合、TEL URL として解決されます。それ以外の場合、URI のユーザー部が抽出されます。したがって、ENUM で解決できない電話番号エンティティーを指定している場合、または SIP URI にユーザー部がない場合、SIP URI の分解は失敗することがあります。

2. すべての SIP URI が考察された後、2 回目の試行が行われ、TEL URL は左から右に読み取られます。使用可能なユーザー中心キーが見つかった時点で、評価はただちに停止します。

3. 分解がすべての試行で失敗した場合、ユーザー中心キーは見つかりません。HTTP 要求が DCR ファイルルールにまったく一致しない場合、ハッシュキーはリモートホストおよびポートを使用して生成されます。SIP 要求が DCR ファイルルールにまったく一致しない場合、ハッシュキーは from-tag,call-id を使用して生成されます。

たとえば、変数が parameter.from.uri.resolve.user で HTTP 要求が GET ...?...&from=...&...HTTP/1.1である場合、結果は次の表の値に基づきます。実際には、例示されている文字の一部は、URL エンコード処理の必要がある場合があります (例: < が %3C のように表示されることがある)。

<sip:server.xx.yy>

<sip:alice@server.xx.yy>

<tel:+1-333-555>,<sip:+1-22-22@server.xx.yy;user=phone>

ロードバランサと Enterprise Server および Communications Server

融合ロードバランサは、Communications Server ディストリビューションの一部です。HTTP 負荷分散プラグインは、Sun GlassFish Enterprise Server with HADB bundle にバンドルされます。HTTP 負荷分散プラグインは、http://glassfish.dev.java.net から別途ダウンロードすることもできます。

HTTP ロードバランサおよび融合ロードバランサ

純粋な Web アプリケーションエンタープライズ配備の場合、HTTP 負荷分散プラグインを Sun GlassFish Enterprise Server 2.1 とともに使用します。Sun GlassFish Communication Server with the Converged Load Balancer は、SIP および融合アプリケーションのエンタープライズ配備を対象にしています。