| Oracle® WebLogic Communication Services 管理ガイド 11g リリース 1 （11.1.1) B55505-01 |
|
 戻る |
 次へ |
この節では、Presence、XDMS、および User Dispatcher を必要とする大規模な Presence ソリューションに対して推奨およびサポートされているデプロイメント トポロジについて説明します。複数ノードの観点から、一般的な流れを示します。以下のトピックがあります。
Presence クラスタは、Presence ノードのセットが 1 つ以上のロード バランサの後に接続されている状態として定義されます。Presence クラスタは、プレゼンス イベント パッケージに対して行われた着信 SUBSCRIBE リクエストと PUBLISH リクエストを処理し、必要に応じて通知を送信します。presence.winfo イベント パッケージに対する SUBSCRIBE リクエストの受信と処理も行います。Presence クラスタは、この作業の完了に必要な情報を取得するために XDM クラスタと対話します。XDM クラスタに問い合わせる情報は、ユーザの presence-rules と pidf-manipulation のドキュメントです。
Presence クラスタは、次の 3 つの異なる層で構成されます。
load-balancing レイヤは、着信トラフィックを User Dispatcher にディスパッチします。ロード バランサはステートレスであり、SIP をプロトコルとして認識する必要がありません。
user-dispatching レイヤは、ユーザ情報に基づいてトラフィックをディスパッチします。ユーザは特定の Presence サーバ インスタンスに割り当てられます。そのユーザ宛てのすべてのトラフィックは、同じ Presence サーバ インスタンスにディスパッチされます。各 User Dispatcher がステートレスで、他の User Dispatcher と状態を共有しない場合でも、User Dispatcher は Presence サーバ層を同じ観点で捉える必要があります。
下層レイヤは、Presence サーバ インスタンスが存在する場所です。各インスタンスはそれ以外のインスタンスと分けられ、他のインスタンスと状態を共有しません。Presence サーバ層の目的は、プレゼンス イベント パッケージ宛ての着信 SUBSCRIBE リクエストおよび PUBLISH リクエストを処理し、presence.winfo イベント パッケージに対するサブスクリプションを処理することです。
Presence クラスタは、次の物理ノードで構成されています。
ロード バランサ (F5 Networks の BigIP など)
次のコンポーネントで構成される Presence ノード
User Dispatcher
Presence サーバ
XDM クラスタは、XDM ノードのセットが 1 つ以上のロード バランサの後に接続されている状態として定義されます。XDM クラスタは、XDM 関連のすべてのトラフィック、つまり ua-profile イベント パッケージに対する SIP SUBSCRIBE トラフィックと、XCAP トラフィックを処理します。同様に、XDM 文書の操作に関連があるすべてのトラフィックを処理します。XDM クラスタは、XDM 文書の実際の記憶域のデータベースを使用しますが、データベース (場合によってはそのクラスタ) が XDM クラスタの一部ではない点に注意してください。
XDM クラスタは、次のレイヤで構成されます。
load-balancing 層 - SIP トラフィックと XCAP トラフィックの両方を次のレイヤにディスパッチします。XCAP トラフィックの場合、次の層は Aggregation Proxy ですが、SIP の場合、トラフィックは User Dispatcher レイヤに直接移動します。
Aggregation Proxy レイヤ - 着信トラフィックを認証します。認証が成功するとすぐに、リクエストを User Dispatcher レイヤに転送します。外部ネットワークからの XCAP トラフィック (XDM クラスタの外部らのトラフィックなど) はすべて、Aggregation Proxy レイヤを通過します。内部トラフィックは Aggregation Proxy を通過せず、User Dispatcher に直接移動します。
User Dispatcher レイヤ - SIP の観点では、Presence クラスタ内と厳密に同じ作業を実行し、同様に機能します (結局は同じ種類のトラフィックになります)。XDM クラスタと Presence クラスタを比較した場合の主な違いは、XDM クラスタでは User Dispatcher が XCAP トラフィックも処理する必要がある点です。ただし、XCAP トラフィックは SIP と厳密に同じ方法で処理されます。XCAP トラフィックに対する User Dispatcher の目的は SIP の場合と同じです。つまり、リクエストに基づいてユーザ情報を抽出してから、その情報を正しい XDMS インスタンスにディスパッチします。
XDM サーバ レイヤには、Presence クラスタの Presence サーバと同じ機能があります。XDMS インスタンスは、イベント パッケージ ua-profile に対する着信 SUBSCRIBE リクエストを処理し、登録されているすべてのサブスクライバに NOTIFY メッセージを適宜送信します。XDMS は PUBLISH リクエストを受け入れない点に注意してください。XCAP 操作により、リソース (XML 文書) の状態を更新します。XDM クライアントは、適切な XCAP 操作を発行することにより、XDMS で管理する文書を操作できます。XCAP 操作が成功すると、文書の内容が変更される場合があります。その場合、XDMS はその文書のすべてのサブスクライバに NOTIFY メッセージを送信して変更を知らせます。XDMS が XML 文書を取得する必要がある場合は、常に次のレイヤ (データベース レイヤ) に問い合わせを行います。
データベース層は、XDMS で管理する XML 文書を物理的に格納します。この層では、データベース レイヤのいずれかのノードに障害が発生した場合でも、データやサービスが失われることなく、そのノード上に存在するドキュメントに XDMS から引き続きアクセスできるように高可用性とスケーラビリティが保証されます。
XDM クラスタは、次の物理ノードで構成されます。
ロード バランサ (F5 Networks の Big IP など)
次のコンポーネントで構成される XDM ノード
Aggregation Proxy
User Dispatcher
XDM サーバ (XDMS)
データベース
Presence クラスタの主要コンポーネントである Presence ノードは、着信トラフィックを適切な Presence サーバにディスパッチし、プレゼンス情報によるユーザへのサービスを提供します。User Dispatcher は、単一ノード デプロイメントでも複数ノード デプロイメントでも同じ役割を果たします。つまり、その目的は特定の Presence サーバ インスタンスに着信トラフィックをディスパッチすることです。ディスパッチ先の Presence サーバ インスタンスが User Dispatcher と同じ物理ノード上にあるかどうかは、User Dispatcher にとって重要ではありません。
Presence ノードには、ノード自体への入り口として機能する User Dispatcher が常にデプロイされます。通常、User Dispatcher はポート 5060 でリスニングし、そのノード上の Presence サーバは他のポートでリスニングします。この方法では、単一ノードはクライアントに対して 1 つの Presence サーバのように見えますが、実際は User Dispatcher の後ろで複数のインスタンスが実行されています。Presence ノードにデプロイされている各コンポーネントは、各自の Java 仮想マシンで実行されています。つまり、User Dispatcher と Presence サーバ インスタンスは、それぞれの OWLCS コンテナおよび SIP コンテナで実行されます。これは、そのマシン上の使用可能なメモリをすべて利用できるようにするためです。
XDM ノードには、XCAP トラフィックの場合に通常ポート 80 でリスニングする Aggregation Proxy が必ずデプロイされます。Aggregation Proxy は着信トラフィックを認証します。認証が成功するとすぐに、リクエストを User Dispatcher に転送します。Presence ノードと同様に、XDM ノードにも User Dispatcher がデプロイされます (通常のポートは5060)。SIP トラフィックの場合、XDM ノードと Presence ノードとの間に違いはありません。2 種類のノード間の違いは、User Dispatcher が XCAP トラフィックもディスパッチする点です。SIP と同様に、User Dispatcher はユーザ ID をリクエストから抽出し、それに基づいて転送先の特定の XDMS インスタンスにリクエストをマップします。
User Dispatcher が SIP トラフィックと XCAP トラフィックの両方をディスパッチする宛先として、数多くの XDMS インスタンスがデプロイされます。Presence ノード上の Presence サーバ インスタンスの場合と同じように、各 XDMS インスタンスは他のインスタンスを認識することなく、個別に実行されます。
図 G-1 に、必要なすべてのコンポーネントを備えた完全な Presence クラスタと XDM クラスタを示します。この図では、2 つのクラスタ (Presence および XDM) が 2 つの別々のクラスタとして扱われ、最初のトラフィックがその 2 つのネットワークに入るには、必ず各自のロード バランサを経由します。サブスクリプションを設定する際に、Presence サーバも XDM クラスタのロード バランサを実際に通過します。ただし、一度サブスクリプションが確立されると、その後のリクエストはロード バランサを通過せず、サブスクリプションをホストする XDMS インスタンスに直接移動します。XDM クラスタのすべてのノードには、Presence クラスタから直接アクセスできます。
