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