| Oracle® WebLogic Server SIP Container管理者ガイド 11g リリース1(11.1.1) B61429-02 |
|
 前 |
 次 |
次の項では、Oracle WebLogic Server SIP Containerアーキテクチャとデプロイメント・トポロジの概要について説明します。
Oracle WebLogic Server SIP Containerは、SIPアプリケーションのデプロイを目的とした、高スケーラビリティの可用性に優れた高パフォーマンスのサーバーとして設計されています。OWLSCがJSR 289準拠の任意のSIPアプリケーションのデプロイに使用されます。
Oracle WebLogic Server SIP Containerアーキテクチャは、管理が容易で、利用可能なハードウェアに簡単に対応できます。基本的なアーキテクチャの構成要素は次のとおりです。
図7-1は、基本的なOracle WebLogic Server SIP Containerインストールの構成要素を示します。次の項で、アーキテクチャの各構成要素について詳しく説明します。
図7-1 Oracle WebLogic Server SIP Containerアーキテクチャ
ロード・バランサは、Oracle WebLogic Server SIP Container製品の一部として用意されているものではありませんが、Oracle WebLogic Server SIP Container製品インストールにおいては、1つまたは複数のロード・バランサが構成要素として不可欠です。ロード・バランサの主な目的は、単一のパブリック・アドレスで受け取ったSIPリクエストを、Oracle WebLogic Server SIP Containerエンジン層の利用可能なサーバーに分散させることです。リクエストの分散によって、Oracle WebLogic Server SIP Containerエンジンが最大限に活用されます。
ロード・バランサの多くには、構成可能なポリシーがあり、各マシンのキャパシティと可用性に応じて、またはインストールで必要なその他のロード・ポリシーに応じて、クライアント・リクエストを分散できるようになっています。ロード・バランサの中には、SIPネットワーク・トラフィックを管理するための追加の機能を備えているものがあります。たとえば、SIPメッセージのヘッダーに含まれている送信元のIPアドレスやポート番号などのフィールドに基づく、ルーティング・ポリシーのサポートなどです。ロード・バランサ製品の多くは、テレフォニ・ネットワーク向けのフォルト・トレランス機能も備えており、特定の呼出しへのSIPリクエストを、その呼出しが開始された同じエンジン層サーバーに常に転送するように構成することができます。
Oracle WebLogic Server SIP Containerインストールでは、ロード・バランサは、個々のサーバー(Oracle WebLogic Server SIP Containerソフトウェアまたはハードウェア)をアップグレードしたり、既存のSIPクライアントで混乱を起こずにアプリケーションをアップグレードしたりといった保守作業を実行するうえでも不可欠です。管理者は、ロード・バランサ・ポリシーを変更して、1つまたは複数のサーバーへのクライアント・トラフィックを他へ移動したうえで、使用していないサーバー・インスタンスに対し、必要なアップグレードを実行します。その後、アップグレードが済んだサーバーでクライアント・トラフィックが元どおりに処理されるよう、ロード・バランサ・ポリシーを再度変更します。
Oracleでは、Oracle WebLogic Server SIP Containerエンジン層でロード・バランサを設定し、基本的なロード分散を行うための詳細な情報を提供しています。Oracle WebLogic Server SIP Containerとともに使用するロード・バランサの構成の詳細は、3.2項「ロード・バランサのアドレスの構成」を参照してください。
エンジン層は、SIPクライアントに対して機能を提供するSIPサーブレットおよびその他のアプリケーションをホストするOracle WebLogic Server SIP Containerインスタンスのクラスタです。エンジン層は、SIPダイアログの状態について、永続的情報や一時的情報を格納しないステートレス・サーバーのクラスタです。そのかわりに、SIPダイアログに関するすべてのステートフルな情報は、SIPデータ層(7.4項)に格納されてそこから取得され、SIPセッション・データのレプリケーションおよびフェイルオーバー・サービスも提供されます。
エンジン層サーバーはSIPデータ層で管理するセッション・データの一部をキャッシュすることができます。キャッシュはSIP対応ロード・バランサを使用する構成に非常に便利です。詳細は、4.7項「エンジン層でのSIPデータのキャッシュ」を参照してください。
エンジン層の主な役割は、SIPクライアントに対し、最大限のスループットを実現し、レスポンス時間を短縮することです。システムが処理する呼出しの数や平均時間が増したときには、エンジン層にサーバー・インスタンスを簡単に追加して、負荷の増加に対応できます。
エンジン層は、複数のOracle WebLogic Server SIP Containerインスタンスで構成されますが、単一の論理エンティティとして処理します。SIPサーブレットのデプロイは、クラスタ自体をターゲットとすることにより、すべてのサーバー・インスタンスに対して均一に行われ、ロード・バランサは、SIPクライアントとエンジン層のサーバーとの間のアフィニティを維持する必要はありません。
|
注意: Oracle WebLogic Server SIP Containerの開始スクリプトでは、パフォーマンスに影響する多くのJVMパラメータにデフォルト値が使用されています。たとえば、JVMのガベージ・コレクションやヒープ・サイズのパラメータが省略されていることや、評価や開発以外の目的には適切でない値を使用していることがあります。本番システムでは、十分なパフォーマンスを実現するために、様々なヒープ・サイズやガベージ・コレクションの設定でアプリケーションのプロファイリングを厳密に行う必要があります。本番ドメインでJVMのパフォーマンスを最大限に引き出す方法は、5.8項「本番デプロイメントにおけるJVMガベージ・コレクションのチューニング」を参照してください。エンジン層ではSIPデータ層サーバーを利用して呼出し状態データを取得するので、エンジン層とSIPデータ層のマシンで2枚のギガ・ビット・イーサネット・ネットワーク・インタフェース・カード(NIC)を使用してネットワーク接続を二重化することをお勧めします。 |
SIPデータ層は、SIPサーブレットのセッション状態データを格納および取得するための、高いパフォーマンスと可用性に優れたインメモリー・データベースを提供するOracle WebLogic Server SIP Containerインスタンスのクラスタです。IPデータ層の目的は次のとおりです。
Oracle WebLogic Server SIP Containerエンジン層のSIPアプリケーションが必要とするセッション・データを格納する、信頼性のある高いパフォーマンスのストレージを提供します。
同時呼出しのセッション状態に対応できるよう、ハードウェア・リソースとソフトウェア・リソースの規模を管理者が必要に応じて簡単に変更できるようにします。
SIPデータ層の中では、セッション・データは1つ以上の「パーティション」で管理され、各パーティションは同時呼出し状態の特定の部分を処理します。たとえば、2つのパーティションを使用するシステムの場合、1つ目のパーティションでは、同時呼出し状態の半分(AからMまでのセッション)を処理し、2つ目のパーティションでは、同時呼出し状態の残りの半分(NからZまでのセッション)を処理します。パーティションが3つの場合には、各パーティションは呼出し状態全体の3分の1ずつを処理します。大量の同時呼出しを管理するときには、必要に応じてパーティションを追加できます。簡単なハッシュ・アルゴリズムは、各呼出し状態が1つのSIPデータ層パーティションのみに一意に割り当てられているか確認するために使用します。
各パーティションには複数のサーバーを追加でき、パーティション内の他のサーバーで障害が発生した場合の冗長性とフェイルオーバーを提供できます。同じパーティションに複数のサーバーが属する場合、それらのサーバーは、各サーバーがパーティションの呼出し状態の複製コピーを処理するため、「レプリカ」と呼ばれます。たとえば、2パーティション・システムの最初のパーティションに2つのサーバーがあると、各サーバーはAからMの呼出し状態のレプリカを管理します。パーティション内の1つまたは複数のサーバーが起動しない場合やネットワークから切断されている場合、任意の使用可能なレプリカが呼出し状態のデータを自動的にエンジン層に提供します。2つのレベルの冗長性を提供するため、SIPデータ層には最大3つのレプリカを含めることができます。
高可用性のためのSIPデータ層の構成の詳細は、第4章「SIPデータ層のパーティションとレプリカの構成」を参照してください。
|
注意: エンジン層ではSIPデータ層サーバーを利用して呼出し状態データを取得するので、エンジン層とSIPデータ層のマシンで2枚のネットワーク・インタフェース・カード(NIC)を使用してネットワーク接続を二重化することをお勧めします。 |
初期のSIPメッセージを受信した場合は、Oracle WebLogic Server SIP Containerは、メッセージをエンジン層にデプロイされた適当なSIPサーブレットに送信するためにサーブレット・マッピング・ルールを使用します。エンジン層は、SIPダイアログに関するステートフルな情報を保持しません。そのかわりに、SIPトランザクション境界でエンジン層に呼出し状態を保存します。ハッシュ・アルゴリズムは、呼出し状態データを格納する1つのSIPデータ層パーティションを選択するために呼出し状態に適用します。次に、エンジン層サーバーは、そのパーティション内にある各レプリカの呼出し状態を「書き込み」、呼出し状態をロックします。たとえば、各パーティション内の2つのサーバーを使用するようにSIPデータ層を構成した場合、エンジン層はパーティション内の両方のレプリカへの接続を開き、各レプリカに呼出し状態を書き込み、ロックします。
デフォルト構成では、レプリカはメモリーにのみ(利用可能なRAM)呼出し状態情報を保持します。呼出し状態データをRDBMSに長期的に格納するように構成することもでき、地理的冗長性を実現するため、オフサイトのOracle WebLogic Server SIP Containerインストールに対して永続化することもできます。
SIPダイアログに対応して以降のSIPメッセージが生成された場合は、エンジン層はSIPデータ層から呼出し状態データを取得する必要があります。ハッシング・アルゴリズムを再度適用して、呼出し状態データを格納するパーティションを決定します。次に、エンジン層は、パーティション内の各レプリカのロックを解除し、呼出し状態データを取得するように求めます。そうすると、エンジン層上のサーブレットは呼出し状態データを更新することができます。
Oracle WebLogic Server SIP Containerでは、長期間維持する呼出し状態データをOracle RDBMSに格納してRAMを節約することができます。呼出しダイアログの確立後、SIPデータ層では呼出し状態のデータをRDBMSに永続化し、呼出し状態を変更または削除するために、必要に応じて永続化された呼出し状態データを取得または削除します。詳細は、4.4項「長期間維持する呼出し状態データのRDBMSへの格納」を参照してください。
複数の地域データ・センターを持ち、サイトに致命的な障害が発生した場合も継続的に稼働を行う必要がある顧客のために、Oracle WebLogic Server SIP Containerは地理的に冗長な構成でインストールできます。地理的に冗長な構成は、複数のOracle WebLogic Server SIP Containerインストール(エンジンおよびSIPデータ層クラスタ)を有効にし、インストール間の呼出し状態トランザクションをレプリケートします。特定のサイトへのインストールがクリティカル障害に陥った場合は、管理者は呼出しの損失を最少限に留めるため、すべてのネットワーク・トラフィックをレプリケートされたセカンダリ・サイトにリダイレクトすることができます。詳細は、4.6項「地理的に冗長なSIPデータ層の使用」を参照してください。
Oracle WebLogic Server SIP Containerアーキテクチャは柔軟であるため、高スループットや高可用性を提供するように、エンジン層およびSIPデータ層を様々な方法で構成できます。
Oracle WebLogic Server SIP Containerの要件によっては、エンジン層とSIPデータ層に複数サーバーを配置してパフォーマンスと信頼性を高めることが必ずしも必要でない場合もあります。たとえば、開発用マシンの場合は、通常は複数サーバーのクラスタにではなく単一のサーバーにアプリケーションをデプロイしてテストする方が好都合です。
Oracle WebLogic Server SIP Containerでは、呼出し状態のレプリケーションが不要な場合には、エンジン層およびSIPデータ層のサービスを単一のサーバー・インスタンスと組み合せることができます。こうした組合せ層構成では、SIPサーブレット・コンテナの機能と、サーバーがホストするアプリケーション向けの呼出し状態処理の機能を、1つのOracle WebLogic Server SIP Containerインスタンスが兼任します。組合せ層構成は、開発やテストの目的で使用するのが一般的ですが、呼出し状態データのレプリケーションが必要ない場合には、本番環境でも使用できます。図7-2に、本番環境における複数の組合せ層サーバーのデプロイメント例を示します。
組合せ層サーバー・デプロイメントでは、各サーバーは、自らがホストするアプリケーションの呼出し状態のみを処理します。そのため、ロード・バランサは完全に「SIP対応」であることが必要です。つまり、ロード・バランサは、同じ呼出しに対する複数のリクエストを、同一のOracle WebLogic Server SIP Containerインスタンスに対してアクティブにルーティングする必要があります。同じ呼出しのリクエストが同一のサーバーに対応付けられない場合は、呼出し状態を取得できません。また、図7-2に示す構成においてOracle WebLogic Server SIP Containerインスタンスで障害が発生した場合は、そのサーバーによって処理されたすべての呼出しが失われるという点にも注意してください。
