| Oracle Communication and Mobility Server管理者ガイド 10gリリース3（10.1.3） B50835-01 |
|
 戻る |
 次へ |
この章では、OCMSのデプロイメント・トポロジについて説明します。
OCMSは、単一ノードとクラスタ、および複数ノードのデプロイメント・トポロジをサポートします。
単一ノード・デプロイは、単一のSIPアプリケーション・サーバー・インスタンスで構成されます。このデプロイは、通常データベース・サーバーとともにSIPアプリケーションをホストしますが、テスト環境や、OCMSのきわめて小規模のデプロイを実行する場合に適しています。
SIPアプリケーション・サーバー・クラスタは、アプリケーションに関係する状態を共有する一連のSIPアプリケーション・サーバー・インスタンスと定義されます。クラスタは1つまたは複数のアプリケーション・サーバー・ノードで構成され、各ノードが1つのOCMSインスタンスを実行します。
高可用性のOCMSクラスタは次の機能を提供します。
SIPアプリケーション・セッションに含まれるオブジェクトと値のレプリケーション
データベースによってバックアップされるロケーション・サービス・データ
複数のOCMS SIPアプリケーション・サーバーへの着信リクエストのロード・バランシング
オーバーロード発生時のサーバーの誤作動の保護や、適切に処理できないトラフィックの拒否を行うオーバーロード保護
クラスタ内のアプリケーション間の透過的なフェイルオーバー。アプリケーションのインスタンスに障害が発生した場合、そのインスタンスの応答はなくなり、セッションはクラスタ内の別のノード上の別のアプリケーション・インスタンスにフェイルオーバーできます。
表2-1 追加情報
| 詳細な情報 | 関連項目: |
|---|---|
|
OCMSのインストール |
Oracle Communication and Mobility Serverのインストレーション・ガイド |
|
高可用性OCMSクラスタがサポートするオペレーティング・システム |
『Oracle Communication and Mobility Server Certification Guide』 |
|
高可用性クラスタ化されたOracle Application Server環境の構成 |
|
|
高可用性のOCMSトポロジの構成 |
このガイドの第5章「高可用性の構成」 |
高可用性トポロジのコンポーネントには、次のものが含まれます。
サード・パーティ製ロード・バランサは、着信トラフィックの負荷をEdge Proxyノード間に分配します。また、障害が発生したEdge Proxyノードを回避し、他のEdge Proxyノードにトラフィックをリダイレクトします。
Edge Proxyノードは、セッションが継続している間、クライアントとサーバーの間にスティッキーな接続を確立して、クライアントとサーバーの間にパスを作成し、そのパスを通してSIPトラフィックを送信します。Edge Proxyノードは、SIPトラフィックの負荷をSIPアプリケーション・サーバー間に分配します。
どちらのEdge Proxyサーバーにも、仮想IPアドレスを構成します。Edge Proxyノードは、障害が発生したSIPアプリケーション・サーバーを検出し、残っているSIPアプリケーション・サーバー・ノードにフェイルオーバーします。
すべてのSIPアプリケーション・サーバーは、各Edge Proxyノードにリンクされます。SIPアプリケーション・サーバー間は、OPMNで相互にリンクされます。各コンピュータでのOCMS SIPの状態は、他の2つのノードにレプリケートされます。1つのSIPアプリケーション・サーバー・ノードで障害が発生すると、障害が発生したノードのレプリケートされた状態を使用して、別のノードが処理を引き継ぎます。
OASインスタンス間での状態のレプリケーションおよびクラスタの構成の詳細は、「OCMSノードの高可用性クラスの設定」を参照してください。
Aggregation Proxyは、Webサービス・コールを認可し、XCAPトラフィックを認証します。その後、Aggregation Proxyは、このトラフィックをParlay X Web ServiceおよびXDMSにプロキシします。これはオプションのコンポーネントです。
OCMS Proxy Registrarは、SIPプロキシ・サーバーとレジストラの機能を結合します。主なタスクとしては、サブスクライバの登録、サブスクライバのロケーションの検索、前方へのリクエストのプロキシなどがあります。Proxy Registrarは、ユーザーのロケーション・データと登録データを、Oracle Databaseに格納します。これはオプションのコンポーネントです。
詳細は、「Proxy Registrar」を参照してください。
User Dispatcherを使用すると、PresenceアプリケーションとXDMSアプリケーションのスケール変更を行えます。User Dispatcherは、SIPおよびXCAPの各リクエストを（HTTPで）適切な宛先に一貫した基準でディスパッチするプロキシです。
サポートされるOCMSのトポロジには次のものがあります。
|
注意: 高可用性は、Oracle Application Serverインストール・モードでのみサポートされています。詳細は、Oracle Communication and Mobility Serverのインストレーション・ガイドを参照してください。 |
高可用性SIPネットワークとしてデプロイすると、OCMSを使用して基本的なVoIPシステムを実装し、音声コールおよびビデオ・コールを利用できるようにすることができます。（図2-1に示す）このトポロジは、次の機能を提供します。
ハードウェア・ロード・バランサ
Edge Proxyサーバーのクラスタ
それぞれがSIPサーブレット・コンテナを実行する2台のSIPアプリケーション・サーバーのクラスタ
ユーザー・データ、認証データおよびユーザー・ロケーション情報を含むレプリケートされたデータベース
このトポロジは、何百万ものユーザーを処理できる高可用性SIPネットワークを提供します。各SIPアプリケーション・サーバーは、Oracle DatabaseとProxy Registrarアプリケーションを実行する必要があります。
SIPネットワーク・トポロジは、表2-2のハードウェアおよびソフトウェア・コンポーネントを含みます。
表2-2 SIPネットワーク・トポロジのハードウェアおよびソフトウェア要件
| ハードウェア | ソフトウェア | インストールの種類脚注1 |
|---|---|---|
|
ロード・バランサ |
該当なし |
該当なし |
|
4GB以上のRAMとデュアル2.8GHz CPUを備えた2台のコンピュータ |
Edge Proxy |
カスタム・インストール |
|
4GB以上のRAMとデュアル2.8GHz CPUを備えた2台のコンピュータ |
|
標準インストール |
脚注1 詳細は、OCMSのインストレーション・ガイドを参照してください。
ロード・バランサ
ロード・バランサまたはDNSラウンドロビン・アルゴリズムは、着信トラフィックの負荷をEdge Proxyノード間に分配します。DNSラウンドロビン・アルゴリズムを使用するには、すべてのクライアントがDNS参照を実装する必要があります。
OCMSは、プレゼンス・サーバーとしてデプロイできます。プレゼンス・サーバー・トポロジは2つのノードにデプロイされ、1つのノードはPresenceサーバーを実行し、もう1つのノードはAggregation ProxyとXDMSを実行します。（図2-2に示す）このトポロジをIMSネットワーク内に実装し、プレゼンス機能を提供できます。
プレゼンス・サーバー・トポロジには次のものが含まれます。
Presenceサーバーを実行する1つのSIPアプリケーション・サーバー・ノード
XDMSとAggregation Proxyを実行する1つのSIPアプリケーション・サーバー・ノード
プレゼンス・サーバー・トポロジは、表2-3のハードウェアおよびソフトウェア・コンポーネントを含みます。
表2-3 プレゼンス・サーバー・トポロジのハードウェアおよびソフトウェア要件
| ハードウェア | ソフトウェア | インストールの種類脚注1 |
|---|---|---|
|
4GB以上のRAMとデュアル2.8GHz CPUを備えた1台のコンピュータ |
|
標準インストール |
|
4GB以上のRAMとデュアル2.8GHz CPUを備えた1台のコンピュータ |
|
標準インストール |
脚注1 詳細は、OCMSのインストレーション・ガイドを参照してください。
XDMS
XDMSとしてのプレゼンスの構成など、インストール後にXDMSを手動で構成する必要があります。詳細は、Oracle Communication and Mobility Serverのインストレーション・ガイドを参照してください。
この項では、Presence、XDMSおよびUser Dispatcherを必要とする大規模なプレゼンス・ソリューションに対して推奨およびサポートされるデプロイメント・トポロジについて説明します。複数ノードの観点から、一般的な流れを示します。
複数ノード間でスケールを調整する場合、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と状態を共有しない場合でも、Presenceサーバー層を同じ観点で捉える必要があります。
下層レイヤーは、Presenceサーバー・インスタンスが存在する場所です。各インスタンスはそれ以外のインスタンスと分けられ、他のインスタンスと状態を共有しません。Presenceサーバー層の目的は、プレゼンス・イベント・パッケージ行きのSUBSCRIBEリクエストおよびPUBLISHリクエストを着信し、presence.winfoイベント・パッケージに対するサブスクリプションを処理することです。
Presenceクラスタは、次の物理ノードで構成されています。
F5などのロード・バランサ
次のコンポーネントで構成されるPresenceノード
User Dispatcher
Presenceサーバー
XDMクラスタは、XDMノードのセットが1つ以上のロード・バランサの後に接続されている状態として定義されます。XDMクラスタは、XDM関連のすべてのトラフィック、つまりua-profileイベント・パッケージに対するSIP SUBSCRIBEトラフィックとXCAPトラフィックを処理します。同様に、XML文書の操作に関連があるすべてのトラフィックを処理します。XDMクラスタは、XML文書の実際の記憶域のデータベースを使用しますが、データベース（場合によってはそのクラスタ）がXDMクラスタの一部ではない点に注意してください。
XDMクラスタは、次のレイヤーで構成されます。
load-balancing層: SIPトラフィックとXCAPトラフィックの両方を次のレイヤーにディスパッチします。XCAPトラフィックの場合、次の層はAggregation Proxyですが、SIPの場合、トラフィックはUser Dispatcherレイヤーに直接移動します。
Aggregation Proxyレイヤー: 着信トラフィックを認証します。認証が成功するとすぐに、リクエストをUser Dispatcherレイヤーに転送します。外部トラフィックのXCAPトラフィックはすべて、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クライアントがXDMSで管理する文書を操作するには、適切なXCAP操作を発行します。XCAP操作が成功すると、文書の内容が変更される場合があります。これにより、XDMSはその文書のサブスクライバにNOTIFYメッセージを送信して、その変更を知らせます。XDMSがXML文書を取得する必要がある場合は、常に次のレイヤー（データベース・レイヤー）に問合せを行います。
データベース層は、XDMSで管理するXML文書を物理的に格納します。この層では、データベース・レイヤーのいずれかのノードに障害が発生した場合でも、そのノード上に存在するドキュメントにXDMSから引き続きアクセスできるように高可用性とスケーラビリティが保証されます。データやサービスが失われることはありません。
XDMクラスタは、次の物理ノードで構成されます。
F5などのロード・バランサ
次のコンポーネントで構成されるXDMノード
Aggregation Proxy
User Dispatcher
XDMサーバー（XDMS）
データベース
Presenceクラスタの主要コンポーネントであるPresenceノードは、着信トラフィックを適切なPresenceサーバー・インスタンスにディスパッチし、プレゼンス情報によるユーザーへのサービスを提供します。User Dispatcherは、単一ノード・デプロイでも複数ノード・デプロイでも同じ役割を果します。つまり、その目的は特定のPSインスタンスに着信トラフィックをディスパッチすることです。このインスタンスが同じ物理ノードで実行しているかどうかは、User Dispatcherには関係ありません。User Dispatcherは、特定のノードをその完全アドレス（IPアドレスとポート）で識別します。ローカル・インスタンスの概念はありません。
Presenceノードには、ノード自体への入り口として機能するUser Dispatcherが常にデプロイされます。通常、User Dispatcherはポート5060でリスニングし、そのノード上の他のPresenceサーバーは他のポートでリスニングします。この方法では、単一ノードはクライアントに対して1つのPresenceサーバーのように見えますが、実際はUser Dispatcherの後ろで複数のインスタンスが実行されています。Presenceノードにデプロイされている各コンポーネントは、各自のJava仮想マシンで実行されています。つまり、User DispatcherとPresenceサーバー・インスタンスは、それぞれのOC4Jコンテナおよび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インスタンスは他のインスタンスを認識せずに、個別に実行されます。
Aggregation ProxyとUser Dispatcherは、同じOC4Jコンテナにデプロイされ、同じJava仮想マシンを使用します。
図2-3に、必要なコンポーネントをすべて備えた完全なPresenceクラスタとXDMクラスタを示します。この図では、2つのクラスタ（PresenceおよびXDM）が2つの別々のクラスタとして扱われ、最初のトラフィックがその2つのネットワークに入るには、必ず各自のロード・バランサを経由します。サブスクリプションを設定する際に、PresenceサーバーもXDMクラスタのロード・バランサを実際に通過します。ただし、一度サブスクリプションが確立されると、その後のリクエストはロード・バランサを通過せず、サブスクリプションをホストするXDMSインスタンスに直接移動します。XDMクラスタのすべてのノードには、Presenceクラスタから直接アクセスできます。
OCMSインスタント・メッセージング・トポロジは、インスタント・メッセージング・クライアント・アプリケーションなどのメッセージングを使用できるようにする高可用性トポロジです。図2-4は、3クラスタの6つのノードで構成されるサンプル・トポロジを示しています。IMトポロジは、4ノードのSIPネットワーク・トポロジと2ノードのプレゼンス・サーバー・トポロジで構成され、Application Routerを追加できます。Application Routerは、SIPリクエストをProxy RegistrarまたはPresenceサーバーにルーティングし、ユーザーの連絡先とロケーションのデータの登録と取得、およびプレゼンスの発行と通知のあらゆる部分の処理を可能にします。いずれかのSIPアプリケーション・サーバー・ノードのAggregation Proxyは、XDMSに格納されているプレゼンス・ドキュメントへのサブスクライバのアクセスを認証するために使用されます。このトポロジは、インスタント・メッセージング・クライアント・アプリケーションの背後のサーバー側機能を提供します。
このトポロジは、表2-4のハードウェアおよびソフトウェア・コンポーネントを含みます。
表2-4 トポロジのハードウェアおよびソフトウェア要件
| ハードウェア | ソフトウェア | インストールの種類脚注1 |
|---|---|---|
|
ロード・バランサ |
該当なし |
該当なし |
|
4GB以上のRAMとデュアル2.8GHz CPUを備えた2台のコンピュータ |
Edge Proxy |
カスタム・インストール |
|
4GB以上のRAMとデュアル2.8GHz CPUを備えた2台のコンピュータ |
|
標準インストール |
|
4GB以上のRAMとデュアル2.8GHz CPUを備えた1台のコンピュータ |
|
標準インストール |
|
4GB以上のRAMとデュアル2.8GHz CPUを備えた1台のコンピュータ |
|
標準インストール |
脚注1 詳細は、OCMSのインストレーション・ガイドを参照してください。
このハイブリッド・トポロジの各部分に関する詳細は、「高可用性SIPネットワークとしての」および「プレゼンス・サーバーとしてのOCMSのデプロイ」を参照してください。
OCMSテスト環境は、単一SIPアプリケーション・サーバー・ノードにデプロイされます。単一ノードのOCMSトポロジは、テスト、デモおよび小規模企業に適しています。
|
注意: このテスト環境は単一ノードにデプロイされるため、高可用性は提供されません。 |
図2-5に、Proxy Registrarが含まれる単一ノードのデプロイを示します。
図2-6に、Proxy Registrar、Presence、Aggregation Proxy、XDMSおよびApplication Routerが含まれる単一ノードのデプロイを示します。
単一ノード・トポロジは、表2-5のハードウェアおよびソフトウェア・コンポーネントを含みます。
表2-5 単一ノード・トポロジのハードウェアおよびソフトウェア要件
| ハードウェア | ソフトウェア | インストールの種類脚注1 |
|---|---|---|
|
4GB以上のRAMとデュアル2.8GHz CPUを備えた1台のコンピュータ |
|
標準インストール |
|
デプロイにPresenceが含まれる場合:
|
標準インストール |
脚注1 詳細は、OCMSのインストレーション・ガイドを参照してください。
トランスポート・プロトコルとしてTCPを使用します。 SIPクライアントは、SIPメッセージを送信するためにUDPまたはTCPを使用します。UDP MTUのサイズ制限の超過について考慮する場合は、TCPを使用する必要があります。DNSにNAPTRおよびSRVレコードを追加して推奨プロトコルがTCPであることを示すことで、TCPの優先使用を適用できます。OCMSに接続するクライアントがNAPTRおよびSRVレコードを完全にサポートすることを確認してください。
OCMS SIPサーバーをデフォルトのレコード-ルート・モードで実行します。クライアントがネットワーク内のNAT/FWを処理する最善の方法は、登録時にサーバーに対するTCP接続を確立し、すべての着信および発信SIPトラフィックでこの接続を再利用することです。そのためには、クライアントにはProxy Registrarを指し示すoutboundproxyを設定し、record-routeを使用するようにProxy Registrarを構成する必要があります。
