| Oracle® WebLogic Communication Services 管理ガイド 11g リリース 1 （11.1.1) B55505-01 |
|
 戻る |
 次へ |
以下の節では、デプロイメントの SIP データ層クラスタを構成する Oracle WebLogic Communication Services インスタンスをコンフィグレーションする方法について説明します。
Oracle WebLogic Communication Services SIP データ層は、同時 SIP 呼のアプリケーション呼状態を管理するサーバ インスタンスのクラスタです。SIP データ層では、呼状態の単一のコピーを処理することも、サーバ マシンで障害が発生したりネットワーク接続が中断された場合でも呼状態データが失われないように、必要に応じて複数のコピーを処理することもできます。
SIP データ層クラスタは、1 つまたは複数の「パーティション」として構成します。1 つのパーティションは、同時呼状態データの同じ部分を管理する、1 つまたは複数の SIP データ層サーバ インスタンスで構成されます。単一のサーバ Oracle WebLogic Communication Services インストールや、エンジン層と SIP データ層にそれぞれ 1 つずつサーバがある 2 つのサーバのインストールでは、すべての呼状態データが単一のパーティションで管理されます。同時呼状態のサイズが、単一のサーバ インスタンスで処理できる最大サイズを超える場合には、複数のパーティションが必要です。複数のパーティションを使用する場合、同時呼状態はそれらのパーティション間で分割され、各パーティションはそれぞれデータの別々の部分を処理します。たとえば、2 つのパーティションで構成される SIP データ層の場合、1 つ目のパーティションでは、同時呼状態の半分 (たとえばセッション A ～ M) を処理し、2 つ目のパーティションでは、残りの呼 (セッション N ～ Z) を処理します。
多くの場合、個々のサーバで処理できる呼状態の最大サイズは、Java 仮想マシンの制限に対応し、サーバ 1 つあたり約 1.6GB です。
同じパーティション内でサーバを追加して、呼状態データのコピーを処理できます。同じパーティションに複数のサーバが属する場合には、各サーバは、呼データの同じ部分のコピー (呼状態の「レプリカ」) を処理します。パーティション内のサーバで障害が発生したり、ネットワーク障害のためにアクセスできない場合には、エンジン層に対する呼状態データの提供は、パーティション内の別のレプリカによって行われます。Oracle では機器やネットワークの障害に備え、プロダクション インストール用の各パーティションに 2 つのサーバをコンフィグレーションすることを推薦します。冗長性を強化するため、1 つのパーティションには最大 3 つのレプリカを含めることができます。
datatier.xml コンフィグレーション ファイルはドメイン ディレクトリの config/custom サブディレクトリにあり、SIP データ層サーバを特定し、呼状態の管理に使うパーティションとレプリカを定義します。サーバ名が datatier.xml にある場合は、そのサーバが起動時に Oracle WebLogic Communication Services SIP データ層の機能を読み込みます。datatier.xml に名前が指定されていないサーバは、エンジン層ノードとして機能し、sipserver.xml コンフィグレーション ファイルでコンフィグレーションされる SIP サーブレット コンテナの機能を提供します。
以下の節では、SIP データ層の一般的なコンフィグレーションに対応する datatier.xml の内容のサンプルを示します。
SIP データ層に属するすべてのサーバは、同一の WebLogic Server クラスタのメンバーです。クラスタ コンフィグレーションにより、各サーバが他のサーバのステータスをモニタできます。また、クラスタを使用すると、すべてのサーバに対して sipserver と datatier カスタム リソースをデプロイすることも簡単です。
信頼性を高めるために、1 つのパーティション内に最大 3 つのレプリカをコンフィグレーションできます。
レプリカやエンジン層ノードの実行中に SIP データ層コンフィグレーションを変更することはできません。SIP データ層のメンバシップの変更や、パーティションまたはレプリカの再コンフィグレーションを行うためには、ドメインのサーバを再起動する必要があります。
図 6-1 に示すように、SipServer ノードの Administration Console の [コンフィグレーション｜データ層] ページから、現在の SIP データ層のコンフィグレーションを参照してコンフィグレーションできます。
図 6-1 Administration Console での SIP データ層のコンフィグレーションの表示 (読み取り専用)
レプリカを追加すると、システム全体としての信頼性が向上しますが、パーティションにサーバを追加するごとに、レプリケートされたデータを処理するためのネットワークの帯域幅が余分に必要となるという点には留意が必要です。レプリカが 3 つのパーティションでは、呼状態を変更する各トランザクションに対し、3 つのサーバそれぞれのデータが更新されることになります。
レプリカを使用するときには、高い信頼性を確実に実現するために、同じパーティションの各サーバ インスタンスはそれぞれ別個のマシンに配置します。1 つのマシンで 2 つ以上のレプリカをホストすると、マシンまたはネットワークで障害が発生した場合に、ホストされたそれらのレプリカすべてが影響を受けることになります。
SIP データ層サーバが取り得るステータスは、次の 3 つのいずれかです。
ONLINE - サーバが呼状態トランザクションを処理できることを示します。
OFFLINE - サーバが停止中または利用できないことを示します。
ONLINE_LOCK_AUTHORITY_ONLY - サーバが再起動され、現在の呼状態データで他のレプリカから更新されている途中であることを示します。回復を進行中のサーバでは、呼状態トランザクションの処理は実行できません。そのパーティションが管理する呼状態の完全なコピーをまだ保持していないからです。
定期的な保守のためにいずれかの SIP データ層サーバ インスタンスをオフラインにする必要がある場合、同じパーティション内の少なくとも 1 つのサーバが active であるようにします。active サーバを停止し、同じパーティションの他のすべてのサーバが offline または recovering の場合には、アクティブな呼状態の一部が失われます。
呼状態は、コンフィグレーションされたパーティションすべてに対して均等に、自動的に分割されます。
以下の節では、別個の SIP データ層を使用する Oracle WebLogic Communication Services インストールの典型的な例を説明します。
単一パーティションで単一サーバの SIP データ層は、最も単純なデータ層のコンフィグレーションを表します。例 6-1 は、単一サーバ デプロイメントでの SIP データ層のコンフィグレーションを示します。
例 6-1 小規模デプロイメントでの SIP データ層のコンフィグレーション
<?xml version="1.0" encoding="UTF-8"?> <data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300"> <partition> <name>part-1</name> <server-name>replica1</server-name> </partition> </data-tier>
既存のパーティションにレプリカを追加するには、同じパーティションに別の server-name エントリを定義するだけです。たとえば、例 6-2 に示した datatier.xml のコンフィグレーション ファイルは、2 つのレプリカのコンフィグレーションを再作成します。
複数パーティションの作成は簡単です。例 6-3 に示すように、datatier.xml で複数の partition エントリを定義します。
例 6-3 2 つのパーティションの SIP データ層のコンフィグレーション
<?xml version="1.0" encoding="UTF-8"?> <data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300"> <partition> <name>Partition0</name> <server-name>DataNode0-0</server-name> </partition> <partition> <name>Partition1</name> <server-name>DataNode1-0</server-name> </partition> </data-tier>
各パーティションに複数の SIP データ層サーバを定義すると、呼状態のレプリカを追加できます。例 6-4 には、各パーティションにある 2 つのパーティションおよび 2 つのサーバ (レプリカ) でシステムを定義するために使用される datatier.xml のコンフィグレーション ファイルを示します。
例 6-4 小規模デプロイメントでの SIP データ層のコンフィグレーション
<?xml version="1.0" encoding="UTF-8"?> <data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300"> <partition> <name>Partition0</name> <server-name>DataNode0-0</server-name> <server-name>DataNode0-1</server-name> </partition> <partition> <name>Partition1</name> <server-name>DataNode1-0</server-name> <server-name>DataNode1-1</server-name> </partition> </data-tier>
Oracle WebLogic Communication Services では、RAM を保存するために、長期間維持する呼状態データを Oracle または MySQL RDBMS に格納できます。RDBMS 永続性を有効にすると、SIP データ層は、呼の接続が確立された後、呼状態データをデフォルトで RDBMS に保存します。それ以降のダイアログ境界で、呼状態を変更したり、削除する必要がある場合は、RDBMS に保存した呼状態データを抽出するか、削除します。
Oracle では、アプリケーション設計者用の API を用意し、どのようなときに呼状態データを SIP データ層に保持すべきかについてのヒントを提供しています。呼状態データを頻繁に RDBMS で永続性したり、一定の呼び出しの永続性を無効にするためにこれらのヒントを使用できます。
Oracle WebLogic Communication Services は、インメモリ レプリケーション機能の SIP データ層に追加するためだけに RDBMS を使用します。RDBMS の使用時にレイテンシ パフォーマンスを改善するため、SIP データ層はアクティブに変更されている呼状態 (たとえば、設定中の新しい呼に対応している状態) と共に、メモリにある SIP タイマーを維持します。呼状態はダイアログが確立された後に自動的に保持され、それ以降のダイアログ境界で呼は進行中か、アプリケーション開発者が加えた保持に関するヒントに対応しているかのどちらかです。
RDBMS と組み合わせて使用した場合、SIP データ層はデータベースに書き込む (またはデータベースから削除する) 呼状態を処理するために、レプリカ サーバ インスタンスを 1 つ選択します。使用可能なレプリカならどれでも、次の読み込みのために必要に応じて永続的な保持から呼状態を検索するために使用できます。
ドメインがエンジン層への接続を管理するため SIP 対応ロード バランサを使用している場合、RDBMS への呼状態の格納をエンジン層キャッシュと組み合わせて使用することができます。節 6.7「エンジン層での SIP データのキャッシング」を参照してください。
以下のすべての基準に一致した場合のみ、RDBMS への呼状態の格納が有効になります。
システムで管理された呼状態は通常、長期間維持されます。
格納する呼状態のサイズが大きい。呼状態が非常に大きい場合は、呼状態の格納に大量の RAM が必要です。
レイテンシ パフォーマンスはデプロイされたアプリケーションに必須ではありません。
RDBMS への呼状態データの格納を選択する前に、特にレイテンシ要件をよく理解しておく必要があります。RDBMS への呼状態の格納のオプションは、SIP データ層クラスタを使用する場合と比較すると、SIP メッセージ処理を行うためにレイテンシがある程度増加します。システムで短い応答時間で多数の存続期間の短い SIP トランザクションを処理しなければならない場合、データ層に呼状態データを格納することをお勧めします。
|
注意 : RDBMS の永続性は、大規模な長期間維持する呼状態の SIP データ層で RAM 要件を抑えるように設計されています。永続性されたデータは、障害が発生した SIP データ層パーティションやレプリカを復元する目的では使用できません。 |
RDBMS への呼状態の格納機能を使用するためには、Oracle WebLogic Communication Services ドメインに必要な JDBC コンフィグレーション、SIP サーブレット コンテナ コンフィグレーション、および呼状態の格納に必要なスキーマを持つデータベースが含まれている必要があります。RDBMS 呼状態テンプレートと共に新しいドメインを設定するコンフィグレーション ウィザードを使用して、ほとんどの必須コンフィグレーションを自動化できます。節 6.4.3「コンフィグレーション ウィザード RDBMS 格納テンプレートの使用」を参照してください。
既存の Oracle WebLogic Communication Services ドメインがある場合、RDBMS ストアをユーザ自身がコンフィグレーションする場合、JDBC および RDBMS 格納を使用する Oracle WebLogic Communication Services のコンフィグレーション方法については、節 6.4.4「RDBMS への呼状態の格納の手動コンフィグレーション」を参照してください。
コンフィグレーション ウィザードでは、RDBMS への呼状態の格納の使用とテストを簡単に行うための単純なテンプレートを提供します。テンプレートから新しいドメインを作成するには、以下の手順に従います。
次のように、コンフィグレーション ウィザード アプリケーション (config.sh) を起動します。
デフォルト選択をそのまま使用して、新しい WebLogic ドメインを作成し、[次へ] をクリックします。
[既存のテンプレートを、このドメインのベースにする] を選択し、[参照] をクリックして [テンプレートを選択] ダイアログを表示します。
replicateddomain.jar という名前のテンプレートを選択し、[OK] をクリックします。
[次へ] をクリックします。
新しいドメインの管理者のユーザ名とパスワードを入力し、[次へ] をクリックします。
使用する JDK を選択し、[次へ] をクリックします。
ソース テンプレート ファイルに定義されている設定をそのまま使用する場合は [いいえ] を選択し、[次へ] をクリックします。
[作成] をクリックしてドメインを作成します。
テンプレートはクラスタに 2 つのエンジン層サーバと SIP データ層サーバ、および管理サーバ (AdminServer) を持つ新しいドメインを作成します。エンジン層クラスタには、以下のリソースおよびコンフィグレーションが含まれます。
長期間維持する呼状態データの格納に必要な JDBC データソース、wlss.callstate.datasource。お使いの RDBMS サーバのデータソースをコンフィグレーションするには、このコンフィグレーションを変更する必要があります。節 6.4.3.1「JDBC データソース接続情報の変更」を参照してください。
RDBMS と地理的冗長、両方の保持に関するヒントのデフォルト処理を定義する永続性コンフィグレーション (Administration Console の ［SipServer］ ノードにある ［コンフィグレーション｜Persistence］ タブ に表示)。
[完了] をクリックして、コンフィグレーション ウィザードを終了します。
RDBMS に必要なテーブルを変更するには、節 6.4.3.1「JDBC データソース接続情報の変更」にある手順に従います。
RDBMS に必要なテーブルを作成するには、節 6.4.4.3 「データベース スキーマの作成」にある手順に従います。
新しいドメインのインストール後、RDBMS サーバの接続情報を含めるようテンプレート JDBC データソースを変更します。
ブラウザを使用して http://address:port/console にアクセスします。address には管理サーバの実際のリスン アドレスを指定し、port の位置には実際のリスン ポートを指定してください。
左ペインの [サービス｜JDBC｜データ ソース] タブを選択します。
右ペインの wlss.callstate.datasource というデータソースを選択します。
右ペインの [コンフィグレーション｜接続プール] タブを選択します。
以下の接続プール プロパティを変更します。
URL : RDBMS サーバのホスト名とポート数を指定するため URL を変更します。
プロパティ : RDBMS の接続情報と一致するようにユーザ、portNumber、SID および serverName プロパティの値を変更します。
［パスワード］ および ［パスワードの確認］ : 指定された RDBMS ユーザのパースワードを記入します。
[保存] をクリックして変更内容を保存します。
右ペインで ［対象］ タブを選択します。
［Select targets］ ページで、SIP データ層クラスタ名 (たとえば、BEA_DATA_TIER_CLUST) を選択して [保存] をクリックします。
[保存] をクリックします。
RDBMS に必要なテーブルを作成するには、節 6.4.4.3 「データベース スキーマの作成」にある手順に従います。
既存の Oracle WebLogic Communication Services ドメインを変更して Oracle または MySQL RDBMS で呼状態データを格納するためには、必要な JDBC データソースをコンフィグレーションし、Oracle WebLogic Communication Services コンフィグレーションを編集して、データベースに必要なスキーマを追加する必要があります。Oracle データベースをコンフィグレーションするには、以下の節にある手順に従います。
ドメインに必要な JDBC リソースを作成するには、以下の手順に従います。
ドメインの管理サーバが実行中でなければ、起動します。
ドメインの Administration Console にアクセスします。
左ペインの [サービス｜JDBC｜データ ソース] タブを選択します。
[New] をクリックして、新しいデータ ソースを作成します。
[Create a New JDBC Data Source] ページの各フィールドに、次の情報を入力します。
［Name］ : wlss.callstate.datasource と入力します。
［JNDI Name］ : wlss.callstate.datasource と入力します。
［Database Type］ : ［Oracle］ を選択します。
［Database Driver］ : ［Database Driver］ リストから適切な JDBC ドライバを選択します。このフィールドのリストに記載されたドライバの一部は、ユーザのシステムにデフォルトでインストールできない場合があります。RDBMS ベンダが提供する説明に従い、必要に応じてサード パーティーのドライバをインストールします。
[次へ] をクリックします。
使用するデータベースの接続情報を使用して、[接続プロパティ] タブのフィールドに入力します。[次へ] をクリックして続行します。
[コンフィグレーションをテスト] をクリックして RDBMS への接続をテストするか、[次へ] をクリックして続行します。
［Select Targets］ ページで、SIP データ層クラスタ名 (たとえば、BEA_DATA_TIER_CLUST) を選択します。
[Finish] をクリックして変更内容を保存します。
RDBMS への呼状態の格納を使用するために Oracle WebLogic Communication Services の永続性オプションをコンフィグレーションするには、以下の手順に従います。
ドメインの管理サーバが実行中でなければ、起動します。
ドメインの Administration Console にアクセスします。
左ペインで [SipServer] ノードをクリックします。
右ペインの [コンフィグレーション｜永続性] タブを選択します。
［Default Handling］ ドロップダウン メニューで「db」または「all」を選択します。［Geo Site ID］ および ［Geo Remote T3 URL］ フィールドが設定されていないかぎり地理的に冗長なレプリケーションが行われないので、「all」を選択しても問題ありません。
[保存] をクリックして変更内容を保存します。
Oracle WebLogic Communication Services には呼状態情報の格納に必要なテーブルを作成するために使用可能な callstate.sql SQL スクリプトが含まれています。コンフィグレーション ウィザードを使用してレプリケートされたドメインをコンフィグレーションした場合、スクリプトはドメイン ディレクトリの user_staged_config サブディレクトリにインストールされます。スクリプトは WLSS_HOME/common/templates/scripts/db/oracle ディレクトリでも使用可能です。
callstate.sql SQL スクリプトの内容を例 6-5 に示します。
例 6-5 呼状態の格納スキーマの callstate.sql スクリプト
drop table callstate; create table callstate ( key1 int, key2 int, bytes blob default empty_blob(), constraint pk_callstate primary key (key1, key2) );
SQL*Plus を使用してスクリプト コマンドを実行するには、以下の手順に従います。
SQL スクリプトを格納する Oracle WebLogic Communication Services utils ディレクトリに移動します。
cd ~/bea/wlcserver_10.3/common/templates/scripts/db/oracle
必要なテーブルを作成する Oracle データベースに接続し、SQL*Plus アプリケーションを起動します。同じユーザ名とパスワードを使用して、節 6.4.4.1「JDBC リソースのコンフィグレーション」で JDBC ドライバのコンフィグレーション時に指定したのと同じデータベースに接続します。次に例を示します。
sqlplus username/password@connect_identifier
connect_identifier を使って JDBC 接続プールで指定されたデータベースに接続します。
Oracle WebLogic Communication Services SQL スクリプト、callstate.sql を実行します。
callstate.sql を起動します。
SQL*Plus を終了します。
終了
Oracle WebLogic Communication Services では簡単な API を用意し、どのようなときに呼状態データを SIP データ層に保持する必要があるかについてのヒントを提供しています。特定の呼び出しまたは SIP リクエストの永続性を無効にしたり、デフォルト設定より (ダイアログ境界で) 頻繁にデータを永続性したりする場合には、API を使用できます。
API を使用するには、WlssSipApplicationSession インスタンスを取得して、永続性の有効化と無効化を行う setPersist メソッドを使用します。RDBMS 格納または地理的に冗長な Oracle WebLogic Communication Services インストールに対して永続性を有効化または無効化できます (節 6.6「地理的に冗長な SIP データ層の使用」を参照してください)。
たとえば、いくつかの SIP 対応ロード バランサ製品では、SIP サーバがアクティブであるかどうかを確認するために SIP OPTIONS メッセージが使用されています。これらのメッセージの RDBMS および地理的に冗長なサイトへの永続性を回避するには、サーブレットは doOptions 例 6-6 に示すように、メソッドを実装して、リクエストをエコーし、永続性を無効にする可能性があります。
例 6-6 オプション メソッドに対する RDBMS 永続性の無効化
protected void doOptions(SipServletRequest req) throws IOException {
WlssSipApplicationSession session =
(WlssSipApplicationSession) req.getApplicationSession();
session.setPersist(WlssSipApplicationSession.PersistenceType.DATABASE,
false);
session.setPersist(WlssSipApplicationSession.PersistenceType.GEO_REDUNDANCY, false);
req.createResponse(200).send();
}
地理的な冗長性では、地理的に分割された SIP サーバのデプロイメントを使用することで、プロバイダの途切れることのないトランザクションと通信が保証されます。
プライマリ サイトでは、各種の SIP トランザクションおよび通信を処理し、トランザクションの境界が確定した時点で、処理中のトランザクションに関連付けられている状態データをセカンダリ サイトにレプリケートできます。プライマリ サイトに障害が発生すると、呼は処理のために障害の発生したプライマリ サイトからセカンダリ サイトにルーティングされます。同様に、障害からの回復時、呼はプライマリ サイトに再び戻されます。
上の図は、地理的な冗長性を示しています。処理は次のように進行します。
プライマリ OCCAS クラスタ サイトで呼が開始され、呼の設定と処理が正常に行われます。
呼は通常どおりサイトの SIP 状態層にレプリケートされ、セカンダリ サイトへのレプリケーションが可能になります。
次に SIP 状態層の単一レプリカは、コンフィグレーションされた JMS キューにレプリケートする呼状態データを格納します。
WAN 上の JMS を使用して、使用可能ないずれかのエンジンに呼が送信されます。
セカンダリ サイトのエンジンは、新しいメッセージをローカル キューでモニタします。メッセージを取得すると、セカンダリ サイト OCCAS クラスタのエンジンは呼状態データを永続化し、それをプライマリ サイトのサイト ID 値に割り当てます。
表 6-1 地理的冗長性のフロー
| 通常の運用 | フェイルオーバ |
|---|---|
|
プライマリ OCCAS サイトでセッションが発生すると、呼の設定と処理が正常に始まります。 |
グローバル LB ポリシーが更新され、プライマリ サイトからセカンダリ サイトへの呼のルーティングを始めます。 |
|
SIP トランザクション境界に達すると、サイトのデータ層に呼がレプリケートされ (インメモリ)、セカンダリ サイトへのレプリケーションが可能になります。 |
完了すると、セカンダリ サイトはバックアップされた呼状態データのリクエスト処理を始めます。 |
|
次にデータ層の単一レプリカは、レプリカ サイトでコンフィグレーションされた JMS キューにレプリケートする呼状態データを格納します。 |
セカンダリ サイトへのリクエストが行われると、エンジンはデータを取得し、呼のオーナーシップを取得して呼状態を起動します。 |
|
データはラウンドロビン方式で、使用可能なエンジンの 1 つに送信されます。 |
呼に関連するサイト ID をゼロに設定します (ローカルに指定)。 |
|
セカンダリ サイトのエンジンは、新しいメッセージをローカル キューでモニタします。 |
呼状態に存在するすべての休止タイマーを起動します。 |
|
メッセージを取得すると、セカンダリ サイトのエンジンは呼状態データを永続化し、それをプライマリ サイトのサイト ID 値に割り当てます。 |
デフォルトでは、呼状態は個々の呼に対してのみ、またバックアップ サイトでそれらの呼がリクエストされた後にのみ起動されます。 |
|
サイト ID はセカンダリ サイトでレプリケートされた呼状態データをセカンダリ サイトで管理されるその他すべての呼状態データから区別します。 |
サーブレットは WlssSipApplicationSession.getGeoSiteId() メソッドを使用して、呼に関連付けられているサイト ID を検証できます。 |
|
レプリケートされた呼状態データのタイマーはセカンダリ サイトで休止状態を続けるので、タイマー処理が動作の妨げになることはありません。 |
サイト ID の 0 以外の値は、サーブレットがもう一方のサイトからレプリケートされた呼状態データを使用して動作していることを示します。 |
地理的冗長性を活用するのに最も適切な場面は、以下のとおりです。
長時間維持される SIP ダイアログ状態 (SUBSCRIBE ダイアログまたはカンファレンスなど、通常 30 秒以上維持されるダイアログ状態) をアプリケーションが使用する場合
レプリケートされた状態からアプリケーションが合理的にセッションを再構築できる場合 (再 INVITE、SUBSCRIBE ダイアログを期限切れにして再サブスクリプションをトリガする、など)
2 つの OCCAS クラスタまたはサイト間のリンクの帯域幅が小さい (各方向 1Gb/秒未満)、またはレイテンシが高いか変動する (5 ミリ秒 95% を超える) 場合
地理的冗長性を使用するのに不適切な場面は、以下のとおりです。
サイト間で高キャパシティのリンクが使用可能な場合
致命的なエラーが発生した際、すべてのトラフィックをセカンダリ サイトに再ルーティングするのに要する時間 (15 ～ 30 秒) よりも長時間維持される可能性のある SIP ダイアログの対応状態に、アプリケーションが到達しない場合
アプリケーションがセッションを再構築する前に、ユーザがアプリケーション セッションを終了する場合 (たいていのユーザは、セカンダリ サイトからのセッションが再確立される前に呼を切断します)
アプリケーションによって作成されたセッション ステート オブジェクトの量が、サイトの相互接続でサポートできる量を超えている場合
地理的冗長性を計画する際は、以下の考慮事項に留意してください。
システムのサイト リンクを設定します。
通信時の各ダイアログ状態は 25KB までです (25600 ビット)。
一般的な B2BUA には 2 つのダイアログが存在します。
リンク上の「ジッター」と持続されたレイテンシへの適合のため、25% の活用を目指してください (特定の機器やサイトのトポロジによってはさらに低い値)。
たとえば、100 Mb/秒のリンクは、1 秒間に約 1000 の呼状態を処理できます。一般的な B2BUA は、(デフォルトのコンフィグレーションで) 呼の間に 4 つ (各ダイアログに 2 つ) の状態を生成します。つまり、100 Mb/秒のリンクは、ピーク時の到着速度 (コール レート) が 250 CPS に設定された単一の OWLCS クラスタをサポートします。
地理的冗長性は、アプリケーションに対して「透過的」ではありません。多くの場合は、アプリケーションが SetPersist() を適切に使用するように設計する必要があります。開発者は、サイト間のレプリケーションのためアプリケーションがキューに入れる状態の量を考慮する必要があります。
長時間維持されるダイアログ状態を選択的に識別するため、SetPersist() をアプリケーション コード内で使用する必要があります。
セカンダリ サイトにトラフィックをルーティングするのに通常要する時間を考慮すると、より頻繁に状態をレプリケートするアプリケーションでは、JMS キューおよびサイトの相互接続が不必要に飽和状態になります。
JMS を特定のアプリケーションの環境にチューニングする必要があります。シリアライズ オプション、メッセージの一括処理、信頼性のある配信オプション、およびキュー サイズはすべて、特定のアプリケーションやサイトの特徴に応じて変動します。
地理的冗長性のデフォルトの動作は、コンテナで地理的冗長性が有効にされたときに、すべてのダイアログ状態の変更をレプリケートすることです (これはプロダクション デプロイメントでは推奨されません)。
セカンダリ サイトにトラフィックをルーティングするのに通常要する時間を考慮すると、より頻繁に状態をレプリケートするアプリケーションでは、サイトの相互接続が不必要に飽和状態になります。
長時間 (適切なしきい値は 20 ～ 30 秒以上) 維持されるダイアログ状態を選択的に識別するため、SetPersist() をアプリケーション コード内で使用する必要があります。
Oracle WebLogic Communication Services SIP データ層で使用可能な基本的な呼状態のレプリケーション機能は、単一サイトへのインストールに優れたフェイルオーバ機能を備えています。しかし、SIP データ層内で実行されたアクティブなレプリケーションは、ほとんどのプロダクション ネットワークでレイテンシ パフォーマンスの要求に合わせるために高域のネットワークの帯域幅を必要とします。この帯域幅が要求されると、たとえば 1 つの地域のデータ センターからもう一方の地域のデータ センターまで、単一の SIP データ層クラスタで遠距離間のデータをレプリケートすることが難しくなります。
Oracle WebLogic Communication Services の地理的な永続性の機能は、複数の Oracle WebLogic Communication Services インストール (複数の管理ドメインまたは「サイト」) 全体で、呼状態のトランザクションのレプリケートを可能にします。地理的に冗長なコンフィグレーションは、たとえば長時間の地域的な停電など、サイト全体に壊滅的障害が発生した場合も呼の破棄を最小限にとどめます。
図 6-3 Oracle WebLogic Communication Services の地理的永続性
別のドメインからデータを永続化するセカンダリ Oracle WebLogic Communication Services ドメイン自体が SIP トラフィックを処理する場合と、単なるアクティブな予備ドメインとして存在する場合があります。最も一般的なコンフィグレーションでは、2 つのサイトが互いの呼状態データをレプリケートするようににコンフィグレーションされ、各サイトがそれぞれのローカル SIP トラフィックを処理します。管理者はどちらかのドメインで障害が発生した場合、もう一方のドメインを「セカンダリ」サイトとして使用することができます。
代替コンフィグレーションは複数の他のサイトからのデータを永続性する 1 つのドメインを使用して、それらのサイトのセカンダリ サイトとして機能します。このコンフィグレーションのセカンダリサイトはそれ自体のローカル SIP トラフィックも処理できますが、他のいくつかのインストールからのアクティブなトラフィックを永続性する必要があるため、サイトのリソース要件が大きくなる可能性があります。
地理的永続性を使用する場合、主要サイトの単一レプリカは、変更された呼状態データを分散された JMS キューに移動します。デフォルトでは、データは SIP ダイアログの境界のみでキューに移動します。(節 6.4.5「SIP アプリケーションでの永続性ヒントの使用」で説明しているように、カスタム API はさらに細かくデータをレプリケートする必要があるアプリケーション開発者向けです)。セカンダリ サイトでは、エンジン層サーバはメッセージを受け取ってデータをそのサーバの SIP データ層クラスタに書き込むために、分散されたキューをモニタするメッセージ リスナを使用します。セカンダリ サイトが長期間維持する呼状態の格納に RDBMS を使用する場合 (推奨) は、分散されたキューから書き込まれるデータはすべて、SIP データ層のメモリ内の格納場所ではなく、RDBMS に直接移動します。
Oracle WebLogic Communication Services の地理的に冗長な永続性の機能は、RDBMS で長期的に維持される呼状態データの管理に非常に便利です。Oracle WebLogic Communication Services はサイト間でレプリケートする前に複数の呼状態データの収集を選択する可能性があるため、存続期間の短い呼はセカンダリ サイトへの移行中に失われることがあります。
所定の地域のサイトで稼動状態をモニタすると共に、地理的に異なる場所の間で呼を分割できる、信頼性のあるサイト対応のロード バランス ソリューションを使用する必要があります。Oracle WebLogic Communication Services には自動的にドメイン全体の障害を検出したり、セカンダリ サイトにフェイルオーバする機能はありません。所定のサイトに障害が発生した場合は、管理者が責任を持って判断を下し、そのサイトの呼を適切なセカンダリ サイトにリダイレクトします。その上、サイト対応のロード バランサは特定の callId へのすべてのメッセージを単一のホーム サイトに向けなければなりません (「アクティブ」サイト)。フェイルオーバの後、障害が発生したサイトが復元されると、ロード バランサは、2 つのサイトの間で呼を分割せずに、アクティブなサイトへの呼を続行しなければなりません。
セカンダリ サイトにフェイルオーバが起こった場合、一部の呼が破棄される可能性があります。一般的に、Oracle WebLogic Communication Services ではサイトのレプリケーションに用いる呼状態データが SIP ダイアログの境界のみでキューイングされるため、このような結果が生じます。データがキューに書き込まれる前に障害が発生すると、キューイングされたデータは削除されます。
また、SIP ダイアログの境界で呼状態を変更する場合のみ、Oracle WebLogic Communication Services はサイト全体の呼状態データをレプリケートします。セカンダリ サイトを起動する前にプライマリ サイトに長期に渡り実行中の呼が存在し、しかも呼状態にずっと変更がない場合、このような呼のデータはセカンダリ サイトにレプリケートされません。長期に渡り実行中の呼状態がレプリケートされる前に障害が発生した場合は、呼はフェイルオーバ中に失われます。
Oracle WebLogic Communication Services インストールのキャパシティを計画するとき、フェイルオーバの後、所定のサイトはそのサイト自体の地理的位置からだけでなく、障害が発生したサイトからすべての呼をサポートできるようにしておく必要があります。つまり、地理的に冗長なコンフィグレーションに関連するすべてのサイトは、フェイルオーバが発生しないかぎり、最大処理能力以下で動作することになります。
Oracle WebLogic Communication Services の地理的永続性機能を使用するには、プライマリ「ホーム」サイトとセカンダリ レプリケーション サイトの両方で特定のコンフィグレーション タスクを行う必要があります。
表 6-2 地理的永続性のコンフィグレーションの手順
| プライマリ「ホーム」サイトでの手順 | セカンダリ「レプリケーション」サイトでの手順 |
|---|---|
|
|
|
注意 : ほとんどのプロダクション デプロイメントでは、2 つのサイトが相互に複製サービスを行うため、一般的にはインストールをそれぞれプライマリおよびセコンダリ サイトとしてコンフィグレーションします。 |
Oracle WebLogic Communication Services は、表 6-2 で説明されたほとんどのリソースのコンフィグレーションを自動化するドメイン テンプレートを備えています。テンプレートの使用の詳細については、節 6.6.4「地理的永続性のコンフィグレーション ウィザード テンプレートの使用」を参照してください。
既存の Oracle WebLogic Communication Services ドメインで地理的永続性を使用する場合は、節 6.6.5「地理的冗長性の手動コンフィグレーション」の手順に従ってリソースを作成します。
Oracle WebLogic Communication Services は、地理的永続性の機能を使用するために、2 種類のコンフィグレーション ウィザード テンプレートを備えています。
WLSS_HOME/common/templates/domains/geo1domain.jar は、サイト ID が 1 のプライマリ サイトをコンフィグレーションします。ドメインは geo2domain.jar で作成されたエンジン層サーバにデータをレプリケートします。
WLSS_HOME/common/templates/domains/geo2domain.jar は、geo1domain.jar で作成されたドメインから呼状態データをレプリケートするセカンダリ サイトをコンフィグレーションします。このインストールのサイト ID は 2 です。
どちらのドメイン テンプレートのサーバ ポート番号も固有の番号であるため、必要に応じて 1 台のマシンで地理的永続性の機能をテストすることができます。各ドメインのインストールとコンフィグレーションを行うには、次の節に示す手順に従います。
テンプレートから新しいプライマリ ドメインを作成するには、以下の手順に従います。
次のように、コンフィグレーション ウィザード アプリケーション (config.sh) を起動します。
デフォルト選択をそのまま使用して、新しい WebLogic ドメインを作成し、[次へ] をクリックします。
[既存のテンプレートを、このドメインのベースにする] を選択し、[参照] をクリックして [テンプレートを選択] ダイアログを表示します。
geo1domain.jar という名前のテンプレートを選択して [OK] をクリックします。
[次へ] をクリックします。
新しいドメインの管理者のユーザ名とパスワードを入力し、[次へ] をクリックします。
使用する JDK を選択し、[次へ] をクリックします。
ソース テンプレート ファイルに定義されている設定をそのまま使用する場合は [いいえ] を選択し、[次へ] をクリックします。
[作成] をクリックしてドメインを作成します。
テンプレートはクラスタに 2 つのエンジン層サーバと SIP データ層サーバ、および管理サーバ (AdminServer) を持つ新しいドメインを作成します。エンジン層クラスタには、以下のリソースおよびコンフィグレーションが含まれます。
長期間維持する呼状態データの格納に必要な JDBC データソース、wlss.callstate.datasource。この機能を使用する場合は、節 6.4.3.1「JDBC データソース接続情報の変更」で説明しているように、RDBMS 接続情報を含めるよう JDBC データソースを変更します。
永続性なコンフィグレーション ([SipServer] ノードにある Administration Console の [コンフィグレーション｜永続性] タブに表示) は以下の項目を定義します。
RDBMS および地理的永続性の両方に対する永続性のヒントのデフォルト処理。
Geo Site ID は 1 です。
地理的冗長性のレプリケーション サイトとして「geo2」ドメインのエンジン層サーバを特定する Geo Remote T3 の URL、t3://localhost:8011,localhost:8061。
[完了] をクリックして、コンフィグレーション ウィザードを終了します。
節 6.6.4.2「セカンダリ サイトのインストール」に示す手順に従って、レプリケーションを行うドメインを作成します。
「geo1」ドメインから呼状態データをレプリケートしてセカンダリ サイトを作成するテンプレートを使用するには、以下の手順に従います。
次のように、コンフィグレーション ウィザード アプリケーション (config.sh) を起動します。
デフォルト選択をそのまま使用して、新しい WebLogic ドメインを作成し、[次へ] をクリックします。
[既存のテンプレートを、このドメインのベースにする] を選択し、[参照] をクリックして [テンプレートを選択] ダイアログを表示します。
geo2domain.jar という名前のテンプレートを選択して [OK] をクリックします。
[次へ] をクリックします。
新しいドメインの管理者のユーザ名とパスワードを入力し、[次へ] をクリックします。
使用する JDK を選択し、[次へ] をクリックします。
ソース テンプレート ファイルに定義されている設定をそのまま使用する場合は [いいえ] を選択し、[次へ] をクリックします。
[作成] をクリックしてドメインを作成します。
テンプレートはクラスタに 2 つのエンジン層サーバと SIP データ層サーバ、および管理サーバ (AdminServer) を持つ新しいドメインを作成します。エンジン層クラスタには、以下のリソースおよびコンフィグレーションが含まれます。
長期間維持する呼状態データの格納に必要な JDBC データソース、wlss.callstate.datasource。この機能を使用する場合は、節 6.4.3.1「JDBC データソース接続情報の変更」で説明しているように、RDBMS 接続情報を含めるよう JDBC データソースを変更します。
永続性なコンフィグレーション ([SipServer] ノードにある Administration Console の [コンフィグレーション｜永続性] タブに表示) は以下の項目を定義します。
RDBMS および地理的な永続性の両方に対する永続性ヒントのデフォルト処理。
Geo Site ID は 2 です。
JMS システム モジュール、SystemModule-Callstate は以下を含みます。
ConnectionFactory-Callstate、プライマリ サイトからの呼状態データをバックアップするために必要な接続ファクトリ
ConnectionFactory-Callstate、プライマリ サイトからの呼状態データをバックアップするために必要な均等に分散されたキュー
サイトのエンジン層クラスタには、JMS システム モジュールが割り当てられています。
2 つのJMS サーバ、JMSServer-1 および JMSServer-2 はそれぞれ engine1-site2 および engine2-site2 にデプロイされます。
[完了] をクリックして、コンフィグレーション ウィザードを終了します。
既存のレプリケートされた Oracle WebLogic Communication Services インストール、または 1 組のインストールをお持ちの場合、地理的な冗長性を有効にするために必要な JMS および JDBC リソースを手動で作成する必要があります。また、レプリケーションを行うには、各サイトをコンフィグレーションする必要があります。地理的な冗長性を有効化にするための基本的な手順を以下に示します。
JDBC リソースのコンフィグレーション。長期間維持する呼状態データを RDBMS に格納する場合、プライマリとセカンダリの両方のサイトをコンフィグレーションすることをお勧めします。
永続性オプションのコンフィグレーション。エンジン層のヒントの RDBMS への書き込みを有効化するか、地理的な冗長なインストールにデータをレプリケートするには、プライマリおよびセカンダリの両方のサイトに永続性のオプションをコンフィグレーションする必要があります。
JMS リソースのコンフィグレーション。セカンダリ サイトは、もう一方のサイトから呼状態データをレプリケートするために利用可能な JMS サーバおよび固有の JMS モジュール リソースを持つ必要があります。
以下の節では、各手順について詳しく説明します。
長期間維持する呼状態を RDBMS へ格納する際に必要な JDBC リソースをコンフィグレーションするには、節 6.4「長期間維持する呼状態データの RDBMS への格納」の手順に従います。
地理的な冗長なレプリケーションを有効化にするために、プライマリおよびセカンダリ サイトに正しく永続性の設定を行う必要があります。永続性をコンフィグレーションするには、以下の手順に従います。
ブラウザを使用して http://address : port/console にアクセスします。address には管理サーバの実際のリスン アドレスを指定し、port の位置には実際のリスン ポートを指定してください。
コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。
左ペインで [SipServer] ノードをクリックします。コンソールの右ペインにある 2 つのレベルのタブ付きページで Oracle WebLogic Communication Services をコンフィグレーションし、モニタします。
右ペインの [コンフィグレーション｜永続性] タブを選択します。
永続性の属性を以下のようにコンフィグレーションします。
デフォルトの処理 : 長期間維持する呼状態データを RDBMS に永続化し、地理的な冗長性を得るために外部サイトにデータをレプリケートする (推奨) には、[all] を選択します。インストールで呼状態データを RDBMS に格納できない場合は、[all] の代わりに [geo] を選択します。
Geo Site ID : 他のすべての設定されたサイトからこのサイトを識別するために、1 ～ 9 から固有の番号を 1 つ選んで入力します。0 のサイト ID は、問題のあるサイト (もう一方のサイトから呼状態を複製できないサイト) にローカルな呼状態を示すために使用します。
Geo Remote T3 URL : プライマリ サイト (またはそのサイトのデータをもう一方のサイトにレプリケートするセカンダリ サイト) では、T3 URL、またはこのサイトの呼状態データを複製するエンジン層サーバの URL を入力します。セカンダリ エンジン層のクラスタがクラスタ アドレスを使用する場合、t3://mycluster:7001 のような単一の T3 URL を入力できます。セカンダリ エンジン層クラスタがクラスタ アドレスを使用しない場合は、t3://engine1-east-coast:7001,t3://engine2-east-coast:7002,t3://engine3-east-coast:7001,t4://engine4-east-coast:7002 のように、エンジン層サーバの URL をカンマで区切って入力します。
[保存] をクリックしてコンフィグレーションの変更を保存します。
エンジン層サーバに変更を適用するには [変更のアクティブ化] をクリックします。
もう一方のサイトから呼状態データをレプリケートするサイトはすべて、特定の JMS リソースをコンフィグレーションする必要があります。一方のサイトからデータをレプリケートしないサイトには、リソースは必要ありません。
JMS リソースを設定するには、以下の手順に従います。
ブラウザを使用して http://address : port/console にアクセスします。address には管理サーバの実際のリスン アドレスを指定し、port の位置には実際のリスン ポートを指定してください。
コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。
左ペインの [サービス｜Messaging｜JMS Servers] タブを選択します。
右ペインの [New] をクリックします。
JMS サーバに固有の名前を入力するか、デフォルト名を取得します。[次へ] をクリックして続行します。
対象リストには、インストール内の単一のエンジン層サーバ ノード名を選択します。[Finish] をクリックして、新しいサーバを作成します。
インストールで各エンジン層サーバノードに専用の JMS サーバを作成するには、手順 3 ～ 6 を繰り返します。
左ペインの [サービス｜Messaging｜JMS Modules] ノードを選択します。
右ペインの [New] をクリックします。
［JMS System Module] ページのフィールドに、以下の情報を入力します。
[名前] : 新しいモジュール名を入力するか、デフォルト名を取得します。
[記述子ファイル名] : JMS モジュール コンフィグレーションを格納するコンフィグレーション ファイル名のプレフィックスを入力します (たとえば、systemmodule-callstate)。
[次へ] をクリックして続行します。
エンジン層クラスタ名を選択して、［クラスタ内の全サーバ］ オプションを選択します。
[次へ] をクリックして続行します。
[Would you like to add resources to this JMS system module] を選択し、[終了] をクリックしてモジュールを作成します。
モジュールに新しいリソースを追加するには、[New] をクリックします。
[Connection Factory] オプションを選択して [次へ] をクリックします。
[Create a new JMS System Module Resource] の各フィールドに、以下の情報を入力します。
[Name] : ConnectionFactory-Callstate のようなリソースの記述名を入力します。
[JNDI Name] : wlss.callstate.backup.site.connection.factory という名前を入力します。
[次へ] をクリックして続行します。
[Finish] をクリックして、新しいリソースを作成します。
今作成した接続ファクトリ リソース名を選択します。
右ペインで [コンフィグレーション｜Load Balance] タブを選択します。
[Server Affinity Enabled] オプションを選択解除して、[保存] をクリックします。
左ペインの [サービス｜Messaging｜JMS Modules] ノードをもう一度選択します。
右ペインに作成された JMS モジュール名を選択します。
もう一つの JMS リソースを作成するため [New] をクリックします。
[Distributed Queue] オプションを選択して [次へ] をクリックします。
[Create a new JMS System Module Resource] の [名前] フィールドに、DistributedQueue-Callstate のようなリソースの記述名を入力します。
[JNDI Name] : 名前を入力し、[Create a new JMS System Module Resource] ページの各フィールドに以下の情報を入力します。
[Name] : ConnectionFactory-Callstate のようなリソースの記述名を入力します。
[JNDI Name] : wlss.callstate.backup.site.queue という名前を入力します。
[次へ] をクリックして続行します。
[Finish] をクリックして、新しいリソースを作成します。
[保存] をクリックしてコンフィグレーションの変更を保存します。
エンジン層サーバに変更を適用するには [変更のアクティブ化] をクリックします。
この節では、複数のサイトが呼状態データをレプリケートする方法について詳しく説明します。管理者は地理的に冗長なレプリケーションの仕組みに対する理解を深め、このようなコンフィグレーションで発生する可能性のある問題をより効率的に解決するために、この情報を使用できます。Oracle WebLogic Communication Services インストール全体のレプリケーションの内部機能は、製品の将来的なリリースで変更される可能性があります。
Oracle WebLogic Communication Services のプライマリ サイトで呼が発生すると、呼の設定と処理が正常に始まります。SIP ダイアログの境界に達すると、サイトの SIP データ層に呼がレプリケートされ (インメモリ)、セカンダリ サイトへのレプリケーションが可能になります。Oracle WebLogic Communication Services はネットワークの使用を最適化するために、レプリケーションに複数の呼状態を集めることを選択することもあります。
次に SIP データ層の単一レプリカは、レプリカ サイトでコンフィグレーションされた JMS キューにレプリケートする呼状態データを格納します。データはラウンドロビン方式で、使用可能なエンジンの一つ (sipserver.xml の geo-remote-t3-url 要素で指定) に送信されます。セカンダリ サイトのエンジンは、新しいメッセージをローカル キューでモニタします。
メッセージを取得すると、セカンダリ サイトのエンジンは呼状態データを永続性し、それをプライマリ サイトのサイト ID 値に割り当てます。サイト ID はセカンダリ サイトでレプリケートされた呼状態データをセカンダリ サイトで管理されるその他すべての呼状態データから区別します。レプリケートされた呼状態データのタイマーはセカンダリ サイトで休止状態を続けるので、タイマー処理が動作の妨げになることはありません。
フェイルオーバを実行するには、管理者はグローバルなロード バランサ ポリシーを変更して障害が発生したプライマリ サイトからセカンダリ サイトへの呼のルーティングを始める必要があります。この処理を終了したあとで、セカンダリ サイトはバックアップされた呼状態データのリクエスト処理を始めます。障害が発生したサイトからレプリケートしたデータへのリクエストが行われると、エンジンはデータを取得し、呼のオーナーシップを取得して呼状態を起動します。起動処理には以下の動作が含まれます。
呼に関連するサイト ID をゼロに設定する (ローカルに指定する)。
呼状態に存在するすべての休止タイマを起動する。
デフォルトでは、呼状態は個々の呼に対してのみ、またバックアップ サイトでそれらの呼がリクエストされた後にのみ起動されます。SipServerRuntimeMBean にはもう一方のサイトから複製された呼状態データをすべて引き継ぐ際に使用する activateBackup(byte site) メソッドが含まれています。管理者は WLST コンフィグレーション スクリプトを使用してこのメソッドを実行できます。また、サーバでデプロイされたアプリケーションはレプリケートされたサイト データへのリクエストがあるとこれを検出し、その後にメソッドを実行することもできます。例 6-7 にサイト 1 からレプリケートされた呼状態データすべてのオーナーシップを変更し、セカンダリ サイトを起動する JSP のサンプルコードを示します。デプロイされたサーブレット内でも同様のコードを使用できます。JSP またはサーブレットのどちらかを activateBackup メソッドを実行するために特権を持つユーザとして実行する必要があります。
特定の呼状態リクエストかどうかを検出するために、サーブレットは WlssSipApplicationSession.getGeoSiteId() メソッドを使用して呼に関連するサイト ID を検証できます。サイト ID の 0 以外の値は、サーブレットがもう一方のサイトからレプリケートされた呼状態データを使用して動作していることを示します。
例 6-7 JMX を使用したセカンダリ サイトの起動
<%
byte site = 1;
InitialContext ctx = new InitialContext();
MBeanServer server = (MBeanServer) ctx.lookup("java:comp/env/jmx/runtime");
Set set = server.queryMBeans(new ObjectName("*:*,Type=SipServerRuntime"), null);
if (set.size() == 0) {
throw new IllegalStateException("No MBeans Found!!!");
}
ObjectInstance oi = (ObjectInstance) set.iterator().next();
SipServerRuntimeMBean bean = (SipServerRuntimeMBean)
MBeanServerInvocationHandler.newProxyInstance(server,
oi.getObjectName());
bean.activateBackup(site);
%>
フェイルオーバの後、ロード バランサは、新しく起動されたサイトに同じ callId を持っすべての呼をルートしなければならないことに注意してください。障害が発生した元のサイトをサービスに復元しても、ロード バランサは 2 つの地理的なサイトの間で呼を分割してはいけない。
リモート サイトでメンテナンスを行うため、またはバックアップ サイトを完全に変更するために、リモート サイトへの呼状態のレプリケートを停止することもできます。レプリケーションは節 6.6.5.2「永続性オプションのコンフィグレーション (プライマリおよびセカンダリ サイト)」で説明されるように、プライマリ サイトの Site Handling 属性を「none」に設定すると停止できます。
主要なサイトの地理的レプリケーションを無効にした後で、セカンダリ サイトのバックアップの呼状態も削除することもできます。SipServerRuntimeMBean には、あるサイトでもう一方のサイトからレプリケートされたすべての呼状態データを強制的に削除する際に使用できる deleteBackup(byte site) メソッドが含まれています。管理者は WLST コンフィグレーション スクリプトを使用するか、セカンダリ サイトにデプロイされたアプリケーションを通じてこのメソッドを実行できます。このメソッドを実行する手順は、節 6.6.6.2「フェイルオーバー後の呼状態の処理」で説明される activateBackup メソッドの使用手順と同様です。
ReplicaRuntimeMBean には地理的に冗長なレプリケーションについてデータを取得する 2 つの新しいメソッドが含まれています。
getBackupStoreOutboundStatistics() はセカンダリ サイトの JMS キューにキューイングされている呼数に関する情報を提供します。
getBackupStoreInboundStatistics() はセカンダリ サイトがもう一方のサイトからレプリケートする呼状態データに関する情報を提供します。
ReplicaRuntimeMBean の詳細については、『Oracle Fusion Middleware Communication Services Java API Reference』を参照してください。
節 6.6.8「地域的サイト全体のレプリケーションのモニタ」で説明されている ReplicaRuntimeMBean メソッドの使用に加えて、管理者は障害が発生したデータベースがセカンダリ サイトのインストールに書き込むことを示す、すべての SNMP トラップをモニタする必要があります。
管理者は地理的に冗長なコンフィグレーションに属しているすべてのサイトが固有のサイト ID を使用しているか確認する必要があります。
第 15 章「Oracle WebLogic Communication Services 基本プラットフォーム トポロジ」で説明したように、デフォルトの Oracle WebLogic Communication Servicesでは、エンジン層クラスタはステートレスです。独立した SIP データ層クラスタが 1 つまたは複数のパーティションで呼状態データを管理します。また、エンジン層サーバは必要に応じて SIP データ層にデータを取得し、書き込みます。エンジンは各パーティションにある複数のレプリカに呼状態データを書き込んで、SIP データ層レプリカがオフラインになった場合に自動フェイルオーバを提供することができます。
Oracle WebLogic Communication Services は呼状態データの一部をローカルにキャッシュするオプションをエンジン層サーバに提供し、これを SIP データ層内でも行います。ローカル キャッシュを使用すると、エンジン層サーバは最初に既存の呼び出し状態データのローカル キャッシュをチェックします。キャッシュに必要なデータが含まれており、かつデータのローカルコピーが （SIP データ層コピーと比較して） 最新データの場合、エンジンは SIP データ層の呼び出し状態をロックしますが、直接キャッシュから読み込みます。エンジンは SIP データ層サーバから呼状態データを取り込む必要がないので、リクエストへの応答時間のパフォーマンスが改善されます。
エンジン層キャッシュは、常に最後にエンジン層サーバで使用された呼状態データのみ格納します。クライアントのリクエストに応答するため、または期限切れデータをリフレッシュするために、必要に応じて呼状態データをエンジンのローカル キャッシュに移動します。キャッシュに新しい呼状態を書き込む際にキャッシュがいっぱいだと、アクセスされた順番が古い順に呼状態エントリから削除されます。エンジン層キャッシュのサイズはコンフィグレーション不可です。
SIP 対応ロード バランサがエンジン層クラスタにリクエストを管理する場合は、ローカル キャッシュの使用が最も有利です。SIP 対応ロード バランサでは、確立された呼に対するリクエストはすべて同じエンジン層サーバに転送され、キャッシュの有効性を改善します。同じ呼に次のリクエストが (様々なキャッシュ コンテンツを持つ) 別のエンジン層サーバから分散されるため、SIP 対応ロード バランサを使用しないとキャッシュの有効性が限定されます。
デフォルトでは、エンジン層キャッシングは有効になっています。エンジン層で呼状態データの部分的キャッシングを無効にするため、sipserver.xml : の engine-call-state-cache-enabled 要素を指定します。
<engine-call-state-cache-enabled>false</engine-call-state-cache-enabled>
使用可能になると、キャッシュ サイズは呼状態 250 回で固定されます。エンジン層キャッシュのサイズはコンフィグレーション不可です。
SipPerformanceRuntime エンジン層キャッシュの動作をモニタします。表 6-3 では MBean 属性を説明します。
表 6-3 SipPerformanceRuntime 属性の概要
| 属性 | 説明 |
|---|---|
cacheRequests |
セッション データ項目の総数を追跡します。 |
cacheHits |
セッション データをリクエストした結果、エンジン層サーバのローカル キャッシュに同じデータのバージョンが新たにみつかるたびに、この属性がサーバによりインクリメントされます。このカウンタは、キャッシュ データが期限切れで SIP データ層にあるデータで更新する必要がある場合にもインクリメントされます。 |
cacheValidHits |
この属性は、セッション データのリクエストがデータのキャッシュ バージョンで完全に満たされるごとにインクリメントされます。 |
使用可能になると、キャッシュ サイズは呼状態 250 回で固定されます。キャッチはメモリを消費するので、パフォーマンスの目的を達成するためには、エンジン層サーバの実行に使用する JVM 設定を変更する必要があります。キャッシュされた呼状態は、ガベージ コレクションの永続的な格納場所で維持されます。キャッシュが使用可能 (たとえば、-XX:MaxNewSize=32m -XX:NewSize=32m） な場合、固定値「NewSize」を削減します。実際の価は、アプリケーションで使用された呼状態サイズだけでなく、アプリケーション自体のサイズにもよります。
実行時 MBean である (ReplicaRuntimeMBean) からは、SIP データ層の現在の状態とコンフィグレーションについての有用な情報が得られます。この MBean が持つ属性の詳細については、『Oracle Fusion Middleware Communication Services Java API Reference』を参照してください。
これらの属性の多くは、図 6-6 に示すように、Administration Console の SIP サーバの [モニタ｜データ層の情報] タブで参照できます。
例 6-8 は、単一の管理対象サーバ インスタンスの現在の属性を SIP データ層パーティションでクエリする、シンプルな WLST セッションを示します。表 6-1 は、MBean のサービスについて詳しく説明します。
例 6-8 ReplicaRuntimeMBean の属性の表示
connect('weblogic','weblogic','t3://datahost1:7001')
custom()
cd('com.bea')
cd('com.bea:ServerRuntime=replica1,Name=replica1,Type=ReplicaRuntime')
ls()
-rw- BackupStoreInboundStatistics null
-rw- BackupStoreOutboundStatistics null
-rw- BytesReceived 0
-rw- BytesSent 0
-rw- CurrentViewId 2
-rw- DataItemCount 0
-rw- DataItemsToRecover 0
-rw- DatabaseStoreStatistics null
-rw- HighKeyCount 0
-rw- HighTotalBytes 0
-rw- KeyCount 0
-rw- Name replica1
-rw- Parent com.bea:Name=replica1,Type=S
erverRuntime
-rw- PartitionId 0
-rw- PartitionName part-1
-rw- ReplicaId 0
-rw- ReplicaName replica1
-rw- ReplicaServersInCurrentView java.lang.String[replica1, replica2]
-rw- ReplicasInCurrentView [I@75378c
-rw- State ONLINE
-rw- TimerQueueSize 0
-rw- TotalBytes 0
-rw- Type ReplicaRuntime
表 6-4 ReplicaRuntimeMBean のメソッドと属性の概要
| メソッド/属性 | 説明 |
|---|---|
dumpState() |
選択した SIP データ層サーバ インスタンスの全体の状態を、Oracle WebLogic Communication Services ログ ファイルに記録します。 |
BackupStoreInboundStatistics |
遠隔地の地理的サイトからレプリケーションされた呼状態データに関する統計を提供します。 |
BackupStoreOutboundStatistics |
遠隔地の地理的サイトにレプリケーションされた呼状態データに関する統計を提供します。 |
BytesReceived |
この SIP データ層サーバが受信した総バイト数です。バイト データを受信するのは、格納する呼状態データがエンジン層のサーバから渡されたときです。 |
BytesSent |
この SIP データ層サーバが送信した総バイト数です。バイト データをエンジン層サーバに送信するのは、格納された呼状態データを提供するよう要求されたときです。 |
CurrentViewId |
現在のビュー ID。SIP データ層のレイアウトが変更になるたびに、ビュー ID はインクリメントされます。たとえば、SIP データ層クラスタの複数サーバが最初に起動されるときには、各サーバが SIP データ層に加わった時点でビュー ID がインクリメントされます。同様に、意図的または障害によって SIP データ層からサーバが抜けたときにも、ビュー ID はインクリメントされます。 |
DataItemCount |
このサーバがデータを持つ、格納された呼状態キーの総数です。サーバが現在データを回復する途中の場合には、この属性の値は |
DataItemsToRecover |
パーティション内の他のレプリカから回復する必要がある呼状態キーの総数です。SIP データ層サーバは、保守のためにオフラインにした後で、再起動してパーティションに参加したときに、必要に応じてキーを回復します。 |
HighKeyCount |
このサーバで起動以降に処理した呼状態キーの総数の最大値です。 |
HighTotalBytes |
このサーバで起動以降に処理した呼状態データの総バイト数の最大値です。 |
KeyCount |
レプリカに格納されている呼データ キーの数です。 |
PartitionId |
このサーバのパーティションのパーティション ID を表す数 (0 ～ 7) です。 |
PartitionName |
このサーバのパーティションの名前。 |
ReplicaId |
このサーバのレプリカのレプリカ ID を表す数 (0 ～ 2) です。 |
ReplicaName |
このサーバのレプリカの名前。 |
ReplicaServersInCurrentView |
同じパーティションに属している他の Oracle WebLogic Communication Services インスタンスの名前です。 |
State |
レプリカの現在の状態です。SIP データ層サーバが取り得るステータスは、次の 3 つのいずれかです。
|
TimerQueueSize |
SIP データ層サーバにキューイングされたタイマーの現在の数です。通常は KeyCount 値に一致しますが、追加された新しい呼状態に対応するタイマーがまだキューイングされていない場合には、この値の方が小さいこともあります。 注意 : エンジン層サーバは、SIP データ層インスタンスを定期的にチェックして、呼に対応するタイマーが時間切れになったかどうかを判断します。SIP タイマーが適切に機能するためには、共通の時刻設定元に合わせて、すべてのエンジン層サーバがシステム時計をアクティブに同期することが必要です。エンジン層の各インスタンスで、NTP (Network Time Protocol) クライアントまたはデーモンを使用し、特定の NTP サーバに同期することをお勧めします。節 3.5「タイマー処理のコンフィグレーション」を参照してください。 |
TotalBytes |
このサーバで扱った呼状態によって消費された総バイト数です。 |
