| Oracle® WebLogic Server SIP Container管理者ガイド 11g リリース1(11.1.1) B61429-02 |
|
 前 |
 次 |
次の項では、デプロイメントのSIPデータ層クラスタを形成するOracle WebLogic Server SIP Containerインスタンスの構成方法を説明します。
Oracle WebLogic Server SIP Container SIPデータ層は、同時SIP呼出しのアプリケーション呼出し状態を管理するサーバー・インスタンスのクラスタです。SIPデータ層は、サーバー・マシンに障害が発生した場合またはネットワーク接続が切断された場合、呼出し状態データが損失しないことを保証するために呼出し状態の単一のコピーまたは必要に応じて複数のコピーを管理できます。
SIPデータ層クラスタは、1つ以上のパーティションに配置されます。パーティションは、同時呼出し状態データの同一部分を管理する1つ以上のSIPデータ層サーバー・インスタンスから構成されます。単一サーバーのOracle WebLogic Server SIP Containerインストール、または2つのサーバー・インストール(1つはエンジン層、もう1つはSIPデータ層)では、すべての呼出し状態データは単一のパーティションに保持されます。複数のパーティションは、同時呼出し状態のサイズが単一のサーバー・インスタンスで管理可能な最大サイズを超えたときに必要です。1つ以上のパーティションが使用されるとき、同時呼出し状態はパーティション間で分割され、各パーティションは個別のデータ部分を管理します。たとえば、2つのパーティションを持つSIPデータ層では、1つのパーティションは同時呼出しの半分(A-Mの呼出しなど)の呼出し状態を管理し、2つ目のパーティションは残りの呼出し(N-Z)を管理します。
多くの場合、個々のサーバーで処理できる呼出し状態の最大サイズは、Java仮想マシンの制限に対応し、サーバー1つ当たり約1.6GBです。
呼出し状態データのコピーを管理するために同一のパーティション内にサーバーを追加できます。複数のサーバーが同一のパーティションのメンバーであるとき、各サーバーは、呼出し状態のレプリカと呼ばれる、呼出しデータの同一部分のコピーを管理します。パーティション内のサーバーで障害が発生した場合、またはネットワーク障害によって接続できない場合、パーティション内の別のレプリカが呼出し状態データをエンジン層に送信します。マシンやネットワークの障害から保護するために、本番インストールでは、各パーティションにおいて2つのサーバーを構成することをお薦めします。パーティションは、冗長性を強化させるために最大で3つのレプリカを持ちます。
ドメイン・ディレクトリのconfig/customサブディレクトリにあるdatatier.xml構成ファイルは、SIPデータ層サーバーを識別し、呼出し状態の管理に使用されるパーティションおよびレプリカも定義します。サーバー名がdatatier.xmlに存在する場合、そのサーバーは、起動時にOracle WebLogic Server SIP Container SIPデータ層の機能をロードします。(datatier.xmlに存在しないサーバー名は、エンジン層ノードとして機能し、sipserver.xml構成ファイルで構成されたSIPサーブレット・コンテナ機能を提供します)。
次の項では、一般的なSIPデータ層構成のdatatier.xmlコンテンツの例を示します。
SIPデータ層に参加するすべてのサーバーは、同一のWebLogic Serverクラスタのメンバーである必要があります。クラスタ構成によって、各サーバーは他のサーバーのステータスを監視できます。また、クラスタを使用すると、sipserverおよびdatatierカスタム・リソースをデプロイメント用にすべてのサーバーに容易にターゲット指定できます。
信頼性を高めるために、1つのパーティション内に最大3つのレプリカを構成できます。
レプリカやエンジン層ノードの実行中にSIPデータ層構成を変更することはできません。SIPデータ層のメンバーシップの変更や、パーティションまたはレプリカの再構成を行うためには、ドメインのサーバーを再起動する必要があります。
図4-1に示されるように、管理コンソールの「構成」>「データ層」ページ(SipServerノード)を使用して、現在のSIPデータ層構成を表示(およびデータ層を構成)できます。
レプリカを追加すると、システム全体としての信頼性が向上しますが、パーティションにサーバーを追加するごとに、レプリケートされたデータを処理するためのネットワークの帯域幅が余分に必要となるという点には留意が必要です。レプリカが3つのパーティションでは、呼出し状態を変更する各トランザクションに対し、3つのサーバーそれぞれのデータが更新されることになります。
レプリカを使用するときには、高い信頼性を確実に実現するために、同じパーティションの各サーバー・インスタンスはそれぞれ別個のマシンに配置します。1つのマシンで2つ以上のレプリカをホストすると、マシンまたはネットワークで障害が発生した場合に、ホストされたそれらのレプリカすべてが影響を受けることになります。
SIPデータ層サーバーが取り得るステータスは、次の3つのいずれかです。
ONLINE: サーバーが呼出し状態トランザクションの管理に使用可能であることを示します。
OFFLINE: サーバーがシャットダウンしているか、使用不可能であることを示します。
ONLINE_LOCK_AUTHORITY_ONLY: サーバーが再起動され、現在の呼出し状態データを使用して(他のレプリカから)現在更新中であることを示します。リカバリ中のサーバーは、パーティションによって管理される呼出し状態のフル・コピーを保持しないため、呼出し状態トランザクションをまだ処理できません。
定期保守のためにSIPデータ層サーバー・インスタンスをオフラインにする必要がある場合、同一パーティション内の少なくとも一台の別のサーバーがアクティブであることを確認します。アクティブ・サーバーをシャットダウンし、パーティション内の他のすべてのサーバーがオフラインまたはリカバリ中の場合、アクティブな呼出し状態の一部が損失する可能性があります。
Oracle WebLogic Server SIP Containerは、すべての構成されたパーティションにわたって、自動的に呼出し状態を均等分割します。
次の項では、個別のSIPデータ層を活用する一般的なOracle WebLogic Server SIP Containerインストールのいくつかについて説明します。
単一パーティションを持つ単一サーバーのSIPデータ層は、最も単純なデータ層構成を表します。例4-1は、単一サーバー・デプロイメントのSIPデータ層構成を示します。
例4-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エントリを定義するだけでレプリカを既存のパーティションに追加できます。たとえば、例4-2で示されているdatatier.xml構成ファイルは、2つのレプリカを持つ構成を再作成します。
複数のパーティションは、例4-3で示されているように、datatier.xmlで複数のパーティション・エントリを定義することによって、容易に作成できます。
例4-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データ層サーバーを定義することによって追加できます。例4-4は、各パーティションに2つのパーティションと2つのサーバー(レプリカ)を持つシステムを定義するために使用されるdatatier.xml構成ファイルを示します。
例4-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 Server SIP Containerでは、RAMを節約するためにOracleまたはMySQLのRDBMSに存続期間の長い呼出し状態データを保存できるようになります。RDBMSの永続性を有効にすると、デフォルトでは、後続のダイアログ境界で、SIPデータ層は呼出しダイアログの確立後に呼出し状態のデータをRDBMSへ保持し、必要に応じて呼出し状態を変更または削除するために保持した呼出し状態を取得または削除します。
オラクル社は、SIPデータ層が呼出し状態データを保持するタイミングに関する「ヒント」を与えるために、アプリケーション・デザイナにAPIも提供します。これらのヒントは、呼出し状態データをRDBMSへより頻繁に保持するか、または特定の呼出しの永続性を無効化するために使用できます。
Oracle WebLogic Server SIP Containerは、SIPデータ層のメモリー内レプリケーション機能を補填するためにRDBMSのみを使用します。RDBMS使用時の待機時間パフォーマンスを向上させるには、SIPデータ層は、アクティブに変更中の呼出し状態(たとえば、設定中の新しい呼出しへのレスポンス)に従ってSIPタイマーをメモリーに保持します。呼出し状態は、後続のダイアログ境界で、ダイアログの確立後に呼出しが実行中のとき、またはアプリケーション開発者によって追加された永続性ヒントのレスポンスときのみ自動的に保持されます。
RDBMSと組み合せて使用した場合、SIPデータ層はデータベースに書き込む(またはデータベースから削除する)呼出し状態を処理するために、レプリカ・サーバー・インスタンスを1つ選択します。使用可能なレプリカならどれでも、次の読込みのために必要に応じて永続的な保持から呼出し状態を検索するために使用できます。
RDBMS呼出し状態ストレージは、ドメインがエンジン層への接続管理にSIPを認識できるロード・バランサを使用する場合、エンジン層キャッシュと組み合せて使用できます。詳細は、4.7項「SIPデータのエンジン層へのキャッシュ」を参照してください。
以下のすべての基準に一致した場合のみ、RDBMSへの呼出し状態の格納が有効になります。
システムで管理された呼出し状態は通常、長期間維持されます。
格納する呼出し状態はサイズが大きなものです。呼出し状態が非常に大きい場合は、呼出し状態の格納に大量のRAMが必要です。
待機時間パフォーマンスはデプロイされたアプリケーションにクリティカルではありません。
RDBMSへの呼出し状態データの格納を選択する前に、特に待機時間要件をよく理解しておく必要があります。RDBMSへの呼出し状態の格納のオプションは、SIPデータ層クラスタを使用する場合と比較すると、SIPメッセージ処理を行うためにレイテンシがある程度増加します。システムで短いレスポンス時間で多数の存続期間の短いSIPトランザクションを処理しなければならない場合、データ層に呼出し状態データを格納することをお薦めします。
|
注意: RDBMSの永続性は、大規模な長期間維持する呼出し状態のSIPデータ層でRAM要件を抑えるように設計されています。永続性されたデータは、障害が発生したSIPデータ層パーティションやレプリカを復元する目的では使用できません。 |
RDBMS呼出し状態ストレージ機能を使用するためには、Oracle WebLogic Server SIP Containerドメインには、必要なJDBC構成、SIPサーブレット・コンテナ構成、および呼出し状態の保存に必要なスキーマを持つデータベースが含まれる必要があります。RDBMS呼出し状態テンプレートを使用して新規ドメインを設定するために構成ウィザードを使用することによって、必要な構成の多くを自動化できます。詳細は、4.4.3項「構成ウィザードのRDBMSストア・テンプレートの使用」を参照してください。
既存のOracle WebLogic Server SIP Containerドメインを持っている場合、または独自のRDBMSストアを構成する場合、RDBMSストアを使用するためにJDBCおよびOracle WebLogic Server SIP Containerを構成するための手順は、4.4.4項「手動によるRDBMS呼出し状態ストレージの構成」を参照してください。
構成ウィザードでは、RDBMSへの呼出し状態の格納の使用とテストを簡単に行うための単純なテンプレートを提供します。テンプレートから新しいドメインを作成するには、次の手順に従います。
構成ウィザード・アプリケーション(config.sh)を起動します。
デフォルトの選択「新しいWebLogicドメインの作成」を受け入れ、「次へ」をクリックします。
「既存のテンプレートを、このドメインのベースにする」を選択し、「参照」をクリックして「テンプレートの選択」ダイアログを表示します。
replicateddomain.jarという名前のテンプレートを選択し、「OK」をクリックします。
「次へ」をクリックします。
新しいドメインの管理者のユーザー名とパスワードを入力し、「次へ」をクリックします。
使用するJDKを選択し、「次へ」をクリックします。
ソース・テンプレート・ファイルに定義されている設定をそのまま使用する場合は「いいえ」を選択し、「次へ」をクリックします。
「作成」をクリックしてドメインを作成します。
テンプレートはクラスタに2つのエンジン層サーバーとSIPデータ層サーバー、および管理サーバー(AdminServer)を持つ新しいドメインを作成します。エンジン層クラスタには、次のリソースおよび構成が含まれます。
存続期間の長い呼出し状態データの保存に必要なwlss.callstate.datasourceというJDBCデータソース。独自のRDBMSサーバーにデータソースを構成するには、この構成を変更する必要があります。詳細は、4.4.3.1項「JDBCデータソース接続情報」を参照してください。
RDBMSおよび地理的冗長性の両方の永続性ヒントのデフォルト処理を定義する永続性構成(SipServerノードの管理コンソールの「構成」>「永続性」タブで表示)。
「完了」をクリックし、構成ウィザードを終了します。
RDBMSで必要な表を作成するには、4.4.3.1項「JDBCデータソース接続情報の変更」の手順に従います。
RDBMSで必要な表を作成するには、4.4.4.3項「データベース・スキーマの作成」の手順に従います。
新しいドメインのインストール後、RDBMSサーバーの接続情報を含めるようテンプレートJDBCデータ・ソースを変更します。
ブラウザを使用してURL (http://address:port/console)にアクセスします。ここで、addressは管理サーバーのリスニング・アドレス、portはリスニング・ポートです。
「ドメイン構造」パネルの(ぺジーの左)スクロール・リストから「サービス」>「データ・ソース」を選択します。
右ペインのwlss.callstate.datasourceというデータ・ソースを選択します。
右ペインで、「構成」>「接続プール」タブを選択します。
以下の接続プール・プロパティを変更します。
URL: RDBMSサーバーのホスト名およびポート番号を指定するためのURLを変更します。
プロパティ: RDBMSの接続情報に一致するようにユーザー、portNumber、SID、およびserverNameプロパティの値を変更します。
パスワードおよびパスワードの確認:指定したRDBMSユーザーのパスワードを入力します。
「保存」をクリックして変更を保存します。
右ペインで「ターゲット」タブを選択します。
「ターゲットの選択」ページで、SIPデータ層クラスタの名前(BEA_DATA_TIER_CLUSTなど)を選択してから、「保存」をクリックします。
「保存」をクリックします。
RDBMSで必要な表を作成するには、4.4.4.3項「データベース・スキーマの作成」の手順に従います。
既存のOracle WebLogic Server SIP Containerドメインが、OracleまたはMySQLのRDBMSに呼出し状態データを保存するように変更するには、必要なJDBCリソースを構成し、Oracle WebLogic Server SIP Container構成を編集し、必要なスキーマをデータベースに追加する必要があります。Oracleデータベースを構成するには、次の項の手順に従います。
ドメインに必要なJDBCリソースを作成するには、以下の手順に従います:
ドメインの管理サーバーが実行中でなければ、起動します。
ドメインの管理コンソールにアクセスします。
「ドメイン構造」パネルの(ぺジーの左)スクロール・リストから「サービス」>「データ・ソース」を選択します。
「New」をクリックして、新しいデータ・ソースを作成します。
「Create a New JDBC Data Source」ページの各フィールドに、次の情報を入力します。
名前: wlss.callstate.datasourceを入力します。
JNDI名:wlss.callstate.datasourceを入力します。
データベース・タイプ:「Oracle」を選択します。
データベース・ドライバ:「データベース・ドライバ」リストから適切なJDBCドライバを選択します。このフィールドにリストされているドライバの一部は、デフォルトではシステムにインストールされない場合があります。RDBMSベンダーからの指示がある場合、必要に応じてサードパーティのドライバをインストールします。
「次へ」をクリックします。
使用するデータベースの接続情報を使用して、「接続プロパティ」タブのフィールドに入力します。「次へ」をクリックして続行します。
「構成をテスト」をクリックしてRDBMSへの接続をテストするか、「次へ」をクリックして続行します。
「Select Targets」ページで、SIPデータ層クラスタ名(例えば、BEA_DATA_TIER_CLUST)を選択します。
「終了」をクリックして変更内容を保存します。
Oracle WebLogic Server SIP Containerの永続性オプションが、RDBMS呼出し状態ストアを使用するように構成するには、次の手順に従います。
ドメインの管理サーバーが実行中でなければ、起動します。
ドメインの管理コンソールにアクセスします。
左ペインで「SipServer」ノードをクリックします。
右ペインで、「構成」>「永続性」タブを選択します。
「デフォルトの処理」ドロップダウン・メニューで、「db」または「all」のいずれかを選択します。「地域サイトID」および「地域リモートT3 URL」フィールドが構成済の場合、地理的に冗長なレプリケーションのみが実行されるため、「all」を選択しても構いません。
「保存」をクリックして変更を保存します。
Oracle WebLogic Server SIP Containerには、呼出し状態情報の保存に必要な表を作成するために使用できるcallstate.sqlというSQLスクリプトが含まれます。このスクリプトは、構成ウィザードを使用してレプリケートされたドメインを構成するとき、ドメイン・ディレクトリのuser_staged_configサブディレクトリにインストールされます。また、このスクリプトは、WLSS_HOME/common/templates/scripts/db/oracleディレクトリでも使用できます。
callstate.sqlというSQLスクリプトのコンテンツは、例4-5で示されます。
例4-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 Server SIP Containerのutilsディレクトリに移動します。
cd ~/bea/wlcserver_10.3/common/templates/scripts/db/oracle
必要な表の作成場所となるOracleデータベースに接続し、SQL*Plusアプリケーションを起動します。同一のユーザー名およびパスワードを使用し、4.4.4.1項「JDBCリソースの構成」でJDBCドライバを構成するときに指定したのと同一のデータベースに接続します。例:
sqlplus username/password@connect_identifier
ここで、connect_identifierは、JDBC接続プールで識別されたデータベースに接続します。
Oracle WebLogic Server SIP Containerのcallstate.sqlというSQLスクリプトを実行します。
START callstate.sql
SQL*Plusを終了します。
EXIT
Oracle WebLogic Server SIP Containerは、SIPデータ層が呼出し状態データを保持する期間に関する「ヒント」を与えるための単純なAPIを提供します。このAPIを使用して固有の呼出しまたはSIPリクエストの永続性を無効化したり、(SIPダイアログ境界で)デフォルト設定よりも頻繁にデータを保持したりできます。
このAPIを使用するには、WlssSipApplicationSessionインスタンスを取得し、永続性を有効化/無効化するためのsetPersistメソッドを使用します。RDBMSストアまたは地理的に冗長なOracle WebLogic Server SIP Containerインストールのいずれかへの永続性を有効化/無効化できます(4.6項「地理的に冗長なSIPデータ層の使用」を参照してください)。
たとえば、一部のSIPを認識できるロード・バランシング製品は、SIPサーバーがアクティブかどうかの判定にSIP OPTIONSメッセージを使用します。RDBMSおよび地理的に冗長なサイトへのこれらのメッセージを保持しないようにするには、例4-6で示されるように、リクエストをエコーしてメッセージの永続性をオフにするために、サーブレットがdoOptionsメソッドを実装する場合があります。
例4-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値に割り当てます。
表4-1 地理的冗長性のフロー
| 通常操作 | フェイルオーバー |
|---|---|
|
セッションがプライマリOCCASサイト上で発信されるとき、通常は呼出し設定および処理が発生します。 |
プライマリ・サイトからセカンダリ・サイトへの呼出しのルーティングを開始するために更新されるグローバルLBポリシー |
|
SIPトランザクション境界に到達すると、呼出しはサイトのデータ層にレプリケートされ(メモリー内)、セカンダリ・サイトへのレプリケーション対象になります。 |
完了すると、セカンダリ・サイトはバックアップされた呼出し状態データのリクエストの処理を開始します。 |
|
次に、データ層の単一レプリカは、レプリカ・サイトで構成されたJMSキューでレプリケートされるように呼出し状態データを配置します。 |
リクエストがセカンダリ・サイトに到達すると、エンジンはデータを取得して呼出し状態をアクティブ化し、呼出しの所有権を取得します。 |
|
データは、使用可能なエンジンのいずれかにラウンドロビン方式で送信されます。 |
呼出しに関連付けられたサイトIDを(ローカルとして表示されるように)ゼロに設定します。 |
|
セカンダリ・サイトのエンジンは、新規メッセージのローカル・キューを監視します。 |
呼出し状態にあるすべての休眠タイマーをアクティブ化します。 |
|
メッセージの受信時に、セカンダリ・サイトのエンジンは呼出し状態データを保持し、プライマリ・サイトのサイトID値に割り当てます。 |
デフォルトでは、呼出し状態は各呼出しに対してのみ、バックアップ・サイトでリクエストされる呼出しの後でのみアクティブ化されます。 |
|
サイトIDは、セカンダリ・サイト上でレプリケートされた呼出し状態データを、セカンダリ・サイトによってアクティブに管理される他の呼出し状態データと区別します。 |
サーブレットは、呼出しに関連付けられたサイトIDを確認するために、WlssSipApplicationSession.getGeoSiteId()メソッドを使用できます。 |
|
レプリケートされた呼出し状態データのタイマーは、タイマー処理がパフォーマンスに対してボトルネックにならないようにするため、セカンダリ・サイト上で休眠状態のままです。 |
サイトIDのゼロ以外の値は、サーブレットが別のサイトからレプリケートされた呼出し状態データを使用して機能することを示します。 |
次の状況は、地理的冗長性の利用に最適です。
アプリケーションは存続期間が長いSIPダイアログ状態(SUBSCRIBEダイアログや会議などの、通常は30秒以上続くダイアログ状態)を使用します。
アプリケーションは、レプリケートされた状態からセッション(re-INVITE、再サブスクライブをトリガーするSUBSCRIBEダイアログの期限切れなど)を適切に再構築できるようになります。
2つのOCCASクラスタまたはサイト間のリンクは、帯域幅(各方向<1Gb/s)が低いか、または待機時間(>5ms 95%)が高く(または可変に)なります。
地理的冗長性は、次の状況では使用しないでください。
サイト間の高容量リンクが使用できる場合。
アプリケーションは、SIPダイアログの安定した状態に到達しません。この状態は、致命的な障害の場合に、セカンダリ・サイトへのすべてのトラフィックを再ルーティングするためにかかる時間(15から30秒)よりも長くなる可能性があります。
アプリケーションがセッションを再構築する前に、アプリケーション・セッションがユーザーによって終了される可能性がある場合(大半のユーザーは、セッションがセカンダリ・サイトから再確立する前に呼出しを切断します)。
アプリケーションによって作成されるセッション状態オブジェクトの量が、サイトの相互接続がサポート可能な量より大きくなります。
地理的冗長性を計画するとき次を考慮してください。
サイト・リンクのシステムのディメンション
伝送路上の各ダイアログ状態は25 KBまで(25600ビット)
通常のB2BUAは2つのダイアログ
リンク上で「ジッター」かつ持続された待機時間に対応するために使用率25% (固有の設備やサイトのトポロジによっては、25%以下)を目標にします。
たとえば、100 Mb/sのリンクは、呼出し状態を1秒間に約1000回処理でき、通常のB2BUA (デフォルト構成)は呼出し中に4つの状態を生成します(各ダイアログに2つ)。そのため、100 Mb/sのリンクは、ピーク時の受信率(コール率)が250 CPSのディメンションの単一のOWLSCクラスタをサポートします。
地理的冗長性は、アプリケーションに対して透過的ではありません。大半の場合、アプリケーションはSetPersist()を適切に使用するように設計される必要があり、開発者はアプリケーションがサイト間のレプリケーションのキューを実行する状態の量を考慮する必要があります。
SetPersist()は、存続期間が長いダイアログ状態を選択的に識別するために、アプリケーション・コード内で使用される必要があります。
セカンダリ・サイトへのトラフィックをルーティングするために通常かかる時間を想定すると、状態をレプリケートする頻度がより高いアプリケーションは、JMSキューおよびサイトの相互接続を不必要に飽和させることになります。
JMSを固有のアプリケーション環境にチューニング擦る必要があります。シリアライズ・オプション、メッセージのバッチ処理、信頼できる送信オプションおよびキュー・サイズは、固有のアプリケーションおよびサイトの特性に応じてすべて変化します。
地理的冗長性のデフォルト動作は、地理的冗長性がコンテナに有効化されているときにすべてのダイアログ状態の変化をレプリケートすることです(これは本番デプロイメントではお薦めできません)。
セカンダリ・サイトへのトラフィックをルーティングするために通常かかる時間を想定すると、状態をレプリケートする頻度がより高いアプリケーションはサイトの相互接続を不必要に飽和させることになります。
SetPersist()は、存続期間が長いダイアログ状態を選択的に識別するために、アプリケーション・コード内で使用される必要があります(20から30秒より長くすると適切なしきい値になります)。
Oracle WebLogic Server SIP ContainerのSIPデータ層で使用可能な基本的な呼出し状態のレプリケーション機能によって、単一のサイト・インストールに優れたフェイルオーバー機能が提供されます。ただし、SIPデータ層内で実行されるアクティブなレプリケーションでは、大半の本番ネットワークが求める待機時間パフォーマンスのニーズを満たすために、ネットワーク帯域幅を高くする必要があります。この帯域幅の要件によって、ある地域のデータ・センターから別の地域のデータ・センターまでといった、長距離に渡るデータのレプリケーションには、単一のSIPデータ層クラスタが適さないようになります。
Oracle WebLogic Server SIP Containerの地理的永続性機能によって、複数のOracle WebLogic Server SIP Containerインストール(複数の管理ドメインまたは「サイト」)全体に渡って呼出し状態トランザクションをレプリケートできるようになります。地理的に冗長な構成によって、広範囲の地域的な停電といったサイト全体の致命的な障害の場合に、呼出しの切断が最小化されます。
図4-3 Oracle WebLogic Server SIP Containerの地理的永続性
別のドメインからデータを保持するセカンダリOracle WebLogic Server SIP Containerドメインは、それ自体でSIPトラフィックを処理したり、アクティブ・スタンバイ・ドメインとして単体で存在できます。最も一般的な構成では、お互いの呼出し状態データをレプリケートするために2つのサイトが構成され、各サイトは独自のローカルSIPトラフィックを処理します。そのため、いずれかのドメインで障害が発生しても、管理者はいずれかのドメインを「セカンダリ」サイトとして使用できます。
代替構成は複数の他のサイトからのデータを永続性する1つのドメインを使用して、それらのサイトのセカンダリ・サイトとして機能します。この構成のセカンダリ・サイトはそれ自体のローカルSIPトラフィックも処理できますが、他のいくつかのインストールからのアクティブなトラフィックを永続性する必要があるため、サイトのリソース要件が大きくなる可能性があります。
地理的永続性を使用するとき、プライマリ・サイトの単一のレプリカは、変更された呼出し状態データを分散されたJMSキューに配置します。デフォルトでは、データはSIPダイアログ境界のキューにのみ配置されます。(カスタムAPIは、4.4.5項「SIPアプリケーションにおける永続性ヒントの使用」で説明されているように、粒度の高い細分度を使用してデータをレプリケートするアプリケーション開発者に提供されます。)セカンダリ・サイトでは、エンジン層サーバーはメッセージ・リスナーを使用して、メッセージを受信したり独自のSIPデータ層クラスタへデータを書き込んだりするために、分散されたキューを監視します。セカンダリ・サイトが、存続期間の長い呼出し状態を保存するためにRDBMSを使用する場合(お薦め)、分散されたキューからのすべてのデータ書込みは、SIPデータ層のメモリー内ストレージではなく、RDBMSへ直接送信されます。
Oracle WebLogic Server SIP Containerの地理的に冗長な永続性機能は、存続期間の長い呼出し状態データをRDBMSで管理するサイトに対して非常に役に立ちます。存続期間の短い呼出しは、サイト間のレプリケーションを行う前に、Oracle WebLogic Server SIP Containerが複数の呼出し状態のデータを収集することを選択する場合があるため、セカンダリ・サイトへの遷移の際に損失する可能性があります。
地理的な場所同士の呼出しを区分し、所定の地域のサイト状態を監視できる、信頼性が高くサイトを認識可能なロード・バランス・ソリューションを用意する必要があります。Oracle WebLogic Server SIP Containerには、ドメイン全体の障害検出や、セカンダリ・サイトへのフェイルオーバーの実行を自動的に行う機能はありません。所定のサイトで「障害が発生した」ときを判断し、サイトの呼出しを適切なセカンダリ・サイトへリダイレクトするのは、管理者の責任となります。また、サイトを認識可能なロード・バランサは、所定のcallIdに対するすべてのメッセージを単一のホーム・サイト(「アクティブな」サイト)へ直接送信する必要があります。フェイルオーバー後、障害の発生したサイトがリストアされる場合、ロード・バランサは2つのサイト間の呼出しを区分せずに、アクティブなサイトへの呼出しの直接送信を継続する必要があります。
セカンダリ・サイトへのフェイルオーバー中に、一部の呼出しが切断される場合があります。これは、Oracle WebLogic Server SIP Containerが通常、SIPダイアログ境界でのみ、サイト・レプリケーションの呼出し状態データのキューを実行するために発生します。データをキューへ書き込む前に発生する障害によって、キューに入れられたデータは損失してしまいます。
また、Oracle WebLogic Server SIP Containerは、SIPダイアログ境界が呼出し状態を変更するときのみサイト全体の呼出し状態データをレプリケートします。セカンダリ・サイトが起動される前にプライマリ・サイト上に実行時間の長い呼出しが存在する場合、呼出し状態は変更されず、その呼出しのデータはセカンダリ・サイトにレプリケートされません。実行時間の長い呼出し状態がレプリケートされる前に障害が発生してしまうと、呼出しはフェイルオーバー中に損失されます。
Oracle WebLogic Server SIP Containerインストールの容量を計画するとき、フェイルオーバー後には、障害の発生したサイトおよび独自の地理的位置からのすべての呼出しを所定のサイトがサポートする必要があります。本質的に、地理的に冗長な構成のすべてのサイトは、フェイルオーバーが起こるまでは最大限の容量以下で稼働することになります。
Oracle WebLogic Server SIP Containerの地理的永続性機能を使用するためには、プライマリ「ホーム」サイトおよびセカンダリ・レプリケーション・サイトの両方で、特定の構成タスクを実行する必要があります。
表4-2 地理的永続性の構成の手順
| プライマリ「ホーム」サイトの手順 | セカンダリ「レプリケーション」サイトの手順 |
|---|---|
|
|
|
注意: ほとんどの本番デプロイメントでは、2つのサイトが相互に複製サービスを行うため、一般的にはインストールをそれぞれプライマリおよびセカンダリ・サイトとして構成します。 |
Oracle WebLogic Server SIP Containerは、表4-2で説明されているように、大半のリソースの構成を自動化するためのドメイン・テンプレートを提供します。テンプレートの使用に関する詳細は、4.6.4項「構成ウィザードの地理的永続性用テンプレートの使用」を参照してください。
既存のOracle WebLogic Server SIP Containerドメインを持ち、地理的永続性を使用する場合、リソースを作成するには、4.6.5項「手動による地理的冗長性の構成」の手順に従います。
Oracle WebLogic Server SIP Containerは、地理的永続性機能に使用する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)を持つ新しいドメインを作成します。エンジン層クラスタには、次のリソースおよび構成が含まれます。
存続期間の長い呼出し状態データの保存に必要なwlss.callstate.datasourceというJDBCデータソース。この機能を使用する場合は、4.4.3.1項「JDBCデータソース接続情報の変更」で説明されているように、RDBMS接続情報を含めるようにデータソースを編集します。
永続性の構成(SipServerノードの管理コンソールの「構成」>「永続性」タブで表示)は次を定義します。
RDBMSおよび地理的永続性の両方に対する永続性のヒントのデフォルト処理
Geo Site IDは1です。
「geo2」ドメインのエンジン層サーバーを地理的冗長性のレプリケーション・サイトとして識別するt3://localhost:8011、localhost:8061の「地域リモートT3 URL」。
「完了」をクリックして、構成ウィザードを終了します。
レプリケーションを実行するドメインを作成するには、4.6.4.2項「セカンダリ・サイトのインストール」の手順に従います。
「geo1」ドメインからの呼出し状態データをレプリケートすることによってセカンダリ・サイトを作成するためにテンプレートを使用するには、次の手順に従います。
構成ウィザード・アプリケーション(config.sh)を起動します。
デフォルトの選択「新しいWebLogicドメインの作成」を受け入れ、「次へ」をクリックします。
「既存のテンプレートを、このドメインのベースにする」を選択し、「参照」をクリックして「テンプレートを選択」ダイアログを表示します。
geo2domain.jarという名前のテンプレートを選択し、「OK」をクリックします。
「次へ」をクリックします。
新しいドメインの管理者のユーザー名およびパスワードを入力し、「次へ」をクリックします。
使用するJDKを選択し、「次へ」をクリックします。
ソース・テンプレート・ファイルで定義された設定を保持するなら「いいえ」を選択し、「次へ」をクリックします。
「作成」をクリックし、ドメインを作成します。
テンプレートはクラスタに2つのエンジン層サーバーとSIPデータ層サーバー、および管理サーバー(AdminServer)を持つ新しいドメインを作成します。エンジン層クラスタには、次のリソースおよび構成が含まれます。
存続期間の長い呼出し状態データの保存に必要なwlss.callstate.datasourceというJDBCデータソース。この機能を使用する場合は、4.4.3.1項「JDBCデータソース接続情報の変更」で説明されているように、RDBMS接続情報を含めるようにデータソースを編集します。
永続性の構成(SipServerノードの管理コンソールの「構成」>「永続性」タブで表示)は次を定義します。
RDBMSおよび地理的な永続性の両方に対する永続性ヒントのデフォルト処理
Geo Site IDは2です。
SystemModule-CallstateというJMSシステム・モジュールは次を含みます。
プライマリ・サイトからの呼出し状態データのバックアップに必要なConnectionFactory-Callstateという接続ファクトリ。
プライマリ・サイトからの呼出し状態データのバックアップに必要なDistributedQueue-Callstateという共通分散キュー。
JMSシステム・モジュールは、サイトのエンジン層クラスタをターゲットにしています。
JMSServer-1およびJMSServer-2という2つのJMSサーバーは、それぞれengine1-site2およびengine2-site2へデプロイされます。
「完了」をクリックし、構成ウィザードを終了します。
レプリケートされた既存のOracle WebLogic Server SIP Containerインストールまたはインストールのペアがある場合、地理的冗長性を有効化するために必要なJMSおよびJDBCリソースを手動で作成する必要があります。また、レプリケーションを実行する各サイトを構成する必要もあります。地理的冗長性を有効化するためのこれらの基本手順は次のとおりです。
JDBCリソースを構成します。存続期間の長い呼出し状態データをRDBMSに保存するために、プライマリおよびセカンダリ・サーバーの両方を構成することをお薦めします。
永続性オプションを構成します。永続性オプションは、エンジン層のヒントがRDBMSへ書き込んだり地理的に冗長なインストールへデータをレプリケートしたりできるように、プライマリおよびセカンダリ・サイトの両方で構成される必要があります。
JMSリソースを構成します。セカンダリ・サイトは、別のサイトからの呼出し状態データをレプリケートするために、使用可能なJMSサーバーおよび固有のJMSモジュール・リソースを持つ必要があります。
以下の節では、各手順について詳しく説明します。
存続期間の長い呼出し状態をRDBMSに保存するために必要なJDBCリソースを構成するには、4.4項「存続期間が長い呼出し状態データのRDBMSへの保存」 の手順に従います。
地理的な冗長なレプリケーションを有効化にするために、プライマリおよびセカンダリ・サイトに正しく永続性の設定を行う必要があります。永続性を構成するには、次の手順に従います。
ブラウザを使用してURL (http://address:port/console)にアクセスします。ここで、addressは管理サーバーのリスニング・アドレス、portはリスニング・ポートです。
「ロックして編集」をクリックし、構成ロックを取得します。
左ペインで「SipServer」ノードを選択します。コンソールの右ペインには、Oracle WebLogic Server SIP Containerの構成および監視に使用される2レベルのタブ・ページがあります。
右ペインで「構成」>「永続性」タブを選択します。
永続性の属性を次のように構成します。
デフォルト処理: 「すべて」を選択し、存続期間の長い呼出し状態データをRDBMSへ保持し、地理的冗長性のために外部サイトへデータをレプリケートします(お薦め)。インストールが呼出し状態データをRDBMSに保存しない場合、「すべて」ではなく「geo」を選択します。
地域サイトID:1から9の一意の番号を入力し、このサイトを他のすべての構成済サイトと区別します。0のサイトIDは、対象のサイトに対してローカルな呼出し状態(別のサイトからレプリケートされていない呼出し状態)を示すために予約されます。
地域リモート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リソースを設定するには、以下の手順に従います。
ブラウザを使用してURL (http://address:port/console)にアクセスします。ここで、addressは管理サーバーのリスニング・アドレス、portはリスニング・ポートです。
「ロックして編集」をクリックし、構成ロックを取得します。
左ペインで「サービス」>「メッセージング」>「JMSサーバー」タブを選択します。
右ペインで「新規」をクリックします。
JMSサーバーの一意の名前を入力するか、またはデフォルト名を受け入れます。「次へ」をクリックして続行します。
「ターゲット」リストで、インストールにおける単一のエンジン層サーバー・ノードの名前を選択します。「終了」をクリックし、新規サーバーを作成します。
インストールで各エンジン層サーバー・ノードに専用のJMSサーバーを作成するには、手順3 - 6を繰り返します。
左ペインで「サービス」>「メッセージング」>「JMSモジュール」ノードを選択します。
右ペインで「新規」をクリックします。
「JMSシステム・モジュール」ページのフィールドに、以下の情報を入力します。
名前:新規モジュールの名前を入力するか、またはデフォルト名を受け入れます。
記述子ファイル名:JMSモジュール構成を保存する場所の構成ファイル名の接頭辞を入力します(systemmodule-callstateなど)。
「次へ」をクリックして、続行します。
エンジン層クラスタの名前を選択し、「クラスタのすべてのサーバー」オプションを選択します。
「次へ」をクリックして続行します。
「このJMSシステム・モジュールにリソースを追加しますか。」を選択し、「終了」をクリックしてモジュールを作成します。
モジュールに新しいリソースを追加するには、「New」をクリックします。
「接続ファクトリ」オプションを選択し、「次へ」をクリックします。
「Create a new JMS System Module Resource」の各フィールドに、以下の情報を入力します。
名前:ConnectionFactory-Callstateなどの、リソースの説明的な名前を入力します。
JNDI名:wlss.callstate.backup.site.connection.factoryという名前を入力します。
「次へ」をクリックして続行します。
「終了」をクリックし、新規リソースを保存します。
今作成した接続ファクトリ・リソース名を選択します。
右ペインで「構成」>「ロード・バランシング」タブを選択します。
「サーバー・アフィニティの有効化」オプションの選択を解除し、「保存」をクリックします。
左ペインで「サービス」>「メッセージング」>「JMSモジュール」ノードを再選択します。
右ペインに作成されたJMSモジュール名を選択します。
「新規」をクリックし、別のJMSリソースを作成します。
「分散キュー」オプションを選択し、「次へ」をクリックします。
DistributedQueue-Callstateなどの、リソースの説明的な名前を入力することによって、「新しいJMSシステム・モジュール・リソースの作成」の「名前」フィールドを記入します。
JNDI名:次に示すように「新しいJMSシステム・モジュール・リソースの作成」フィールドに「塗りつぶし」を入力します。
名前:ConnectionFactory-Callstateなどの、リソースの説明的な名前を入力します。
JNDI名:wlss.callstate.backup.site.queueという名前を入力します。
「次へ」をクリックして続行します。
「終了」をクリックして、新しいリソースを作成します。
「保存」をクリックし、構成の変更を保存します。
「変更のアクティブ化」をクリックし、変更をエンジン層サーバーに適用します。
この項では、複数のサイトが呼出し状態データをレプリケートする仕組みの詳細を説明します。管理者は、この情報を使用して地理的に冗長なレプリケーションのメカニズムをより深く理解し、そのような構成で生じる問題に対してより適切にトラブルシューティングを実行できます。ただし、Oracle WebLogic Server SIP Containerインストール全体の内部レプリケーション機構は、今後の製品リリースによって変更される可能性があります。
プライマリOracle WebLogic Server SIP Containerサイトで呼出しが発信されると、通常は呼出し設定および処理が発生します。SIPダイアログ境界に到達すると、呼出しはサイトのSIPデータ層にレプリケートされ(メモリー内)、セカンダリ・サイトへのレプリケーション対象になります。Oracle WebLogic Server SIP Containerは、ネットワーク使用率を最適化するために、レプリケーションの複数の呼出し状態を集計することを選択する場合があります。
次に、SIPデータ層の単一レプリカは、レプリカ・サイトで構成されたJMSキューでレプリケートされるように呼出し状態データを配置します。データは、ラウンドロビン方式で使用可能なエンジン(sipserver.xmlのgeo-remote-t3-url要素で指定される)のいずれかへ送信されます。セカンダリ・サイトのエンジンは、新規メッセージのローカル・キューを監視します。
メッセージを取得すると、セカンダリ・サイトのエンジンは呼出し状態データを永続性し、それをプライマリ・サイトのサイトID値に割り当てます。サイトIDはセカンダリ・サイトでレプリケートされた呼出し状態データをセカンダリ・サイトで管理されるその他すべての呼出し状態データから区別します。レプリケートされた呼出し状態データのタイマーはセカンダリ・サイトで休止状態を続けるので、タイマー処理が動作の妨げになることはありません。
フェイルオーバーを実行するには、管理者はグローバルなロード・バランサ・ポリシーを変更して障害が発生したプライマリ・サイトからセカンダリ・サイトへの呼出しのルーティングを始める必要があります。この処理を終了したあとで、セカンダリ・サイトはバックアップされた呼出し状態データのリクエスト処理を始めます。障害が発生したサイトからレプリケートしたデータへのリクエストが行われると、エンジンはデータを取得し、呼出しのオーナーシップを取得して呼出し状態を起動します。起動処理には以下の動作が含まれます。
呼出しに関連するサイトIDをゼロに設定します(ローカルに指定します)。
呼出し状態に存在するすべての休止タイマーを起動します。
デフォルトでは、呼出し状態は各呼出しに対してのみ、バックアップ・サイトでリクエストされる呼出しの後でのみアクティブ化されます。SipServerRuntimeMBeanには、activateBackup(byte site)というメソッドが含まれ、サイトに対して別のサイトからレプリケートしたすべての呼出し状態データを強制的に引き継ぐようにするために使用できます。管理者は、WLST構成スクリプトを使用してこのメソッドを実行できます。あるいは、サーバー上にデプロイされたアプリケーションは、レプリケートされたサイト・データへのリクエストがいつ発生したかを検出し、メソッドを実行できます。例4-7は、サイト1からレプリケートされたすべての呼出し状態データの所有権を変更し、セカンダリ・サイトをアクティブ化するJSPからのサンプル・コードを示します。同様のコードは、デプロイされたサーブレット内で使用可能です。JSPまたはサーブレットのいずれかは、activateBackupメソッドを実行するために、権限ユーザーとして実行される必要があります。
特定の呼出し状態リクエストかどうかを判定するために、サーブレットはWlssSipApplicationSession.getGeoSiteId()メソッドを使用して呼出しに関連付けられたサイトIDを確認できます。サイトIDのゼロ以外の値は、サーブレットが別のサイトからレプリケートされた呼出し状態データを使用して機能することを示します。
例4-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つの地理的なサイトの間で呼出しを分割しないことが必要です。
リモート・サイト上でメンテナンスを実行したり、バックアップ・サイト全体を変更したりするために、呼出し状態をリモート・サイトへレプリケートすることを停止するように選択することもできます。レプリケーションは、4.6.5.2項「永続性オプションの構成(プライマリおよびセカンダリ・サイト)」で説明されているように、プライマリ・サイトでSite Handling属性を"none"に設定することによって停止できます。
プライマリ・サイトで地理的なレプリケーションを無効化した後、セカンダリ・サイトで呼出し状態のバックアップを削除することもできます。SipServerRuntimeMBeanには、deleteBackup(byte site)というメソッドが含まれ、サイトに対して別のサイトからレプリケートしたすべての呼出し状態データを強制的に削除するために使用できます。管理者は、WLST構成スクリプトを使用するか、またはセカンダリ・サイトでデプロイ済アプリケーションを経由して、このメソッドを実行できます。このメソッドを実行するための手順は、4.6.6.2項「フェイルオーバー後の呼出し状態の処理」で説明されているように、activateBackupメソッドの使用による手順と酷似しています。
ReplicaRuntimeMBeanには、地理的に冗長なレプリケーションに関するデータを取得するための2つの新しいメソッドが含まれています。
getBackupStoreOutboundStatistics()は、セカンダリ・サイトのJMSキューに格納される呼出しの数に関する情報を提供します。
getBackupStoreInboundStatistics()は、セカンダリ・サイトが別のサイトからレプリケートする呼出し状態データに関する情報を提供します。
ReplicaRuntimeMBeanに関する詳細は、Oracle Fusion Middleware Communication Services Java APIリファレンスを参照してください。
4.6.8項「地域サイト全体に渡るレプリケーションの監視」で説明されているReplicaRuntimeMBeanメソッドの使用に加え、管理者は、セカンダリ・サイト・インストール上でデータベースの書込みに失敗したことを示すSNMPトラップを監視する必要があります。
管理者は地理的に冗長な構成に属しているすべてのサイトが固有のサイトIDを使用しているか確認する必要があります。
第7章「Oracle WebLogic Server SIP Containerベース・プラットホームのトポロジ」で説明されているように、デフォルトのOracle WebLogic Server SIP Container構成では、エンジン層クラスタはステートレスです。個別のSIPデータ層クラスタが1つ以上のパーティションで呼出し状態データを管理し、エンジン層サーバーが必要に応じてSIPデータ層のデータを取得して書き込みます。エンジンは、呼出し状態データを各パーティションの複数のレプリカに書き込み、SIPデータ層レプリカがオフライン状態に陥ったときに自動フェイルオーバーを実行できます。
また、Oracle WebLogic Server SIP Containerは、エンジン層サーバーが呼出し状態データの一部をローカルおよび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は、エンジン層キャッシュの動作を監視します。表4-3は、MBean属性を説明しています。
表4-3 SipPerformanceRuntime属性の概要
| 属性 | 説明 |
|---|---|
cacheRequests |
セッション・データ項目のリクエスト数を追跡します。 |
cacheHits |
サーバーは、セッション・データのリクエストが、エンジン層サーバーのローカル・キャッシュで検出されるデータのバージョンという結果になるたびに、この属性をインクリメントします。このカウンタは、キャッシュされたデータが古く、SIPデータ層からのデータを使用して更新される必要がある場合でもインクリメントされます。 |
cacheValidHits |
この属性は、セッション・データのリクエストがデータのキャッシュ・バージョンで完全に満たされるごとにインクリメントされます。 |
有効化すると、キャッシュのサイズは250の呼出し状態に固定されます。キャッシュはメモリーを消費するため、パフォーマンスの目標を満たすためには、エンジン層サーバーの稼働に使用されるJVM設定を更新する必要がある場合があります。キャッシュされた呼出し状態は、ガベージ・コレクタの古い保存域に保持されます。キャッシュが有効化されているときは、「NewSize」の固定値を減らすようにします(-XX:MaxNewSize=32m -XX:NewSize=32mなど)。実際の値は、アプリケーションによって使用される呼出し状態のサイズおよびアプリケーション自体のサイズに依存します。
ランタイムMBean (ReplicaRuntimeMBean)は、SIPデータ層の現在の状態および構成に関する貴重な情報を提供します。MBeanで提供される属性に関する説明は、Oracle Fusion Middleware Communication Services Java APIリファレンスを参照してください。
これらの属性の多くは、図4-6で示されるように、管理コンソールのSIPサーバーの監視>「データ層の情報」タブを使用して表示できます。
例4-8は、SIPデータ層パーティションにおける単一の管理対象サーバー・インスタンスの現在の属性を問い合せる単一のWLSTセッションを示します。表4-1は、MBeanサービスの詳細を説明しています。
例4-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
表4-4 ReplicaRuntimeMBeanメソッドおよび属性サマリー
| メソッド/属性 | 説明 |
|---|---|
dumpState() |
選択したSIPデータ層サーバー・インスタンスの全体の状態をOracle WebLogic Server SIP Containerのログ・ファイルに記録します。問題が発生した場合に追加の診断情報をテクニカル・サポート担当者に提供するためには、 |
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 Server SIP Containerインスタンス名。 |
State |
レプリカの現在の状態です。SIPデータ層サーバーが取り得るステータスは、次の3つのいずれかです。
|
TimerQueueSize |
SIPデータ層サーバーにキューイングされたタイマーの現在の数です。通常はKeyCount値に一致しますが、追加された新しい呼出し状態に対応するタイマーがまだキューイングされていない場合には、この値の方が小さいこともあります。 注意: エンジン層サーバーは、呼出しに関連付けられたタイマーが期限切れになったかどうかを判定するために、SIPデータ層インスタンスを定期的にチェックします。SIPタイマーが正常に機能するためには、すべてのエンジン層サーバーがシステム・クロックを共通時間ソースにアクティブに同期化する必要があります。各エンジン層インスタンスでネットワーク・タイム・プロトコル(NTP)クライアントまたはデーモンを使用し、選択したNTPサーバーに同期することをお薦めします。詳細は、2.5項「タイマー処理の構成」を参照してください。 |
TotalBytes |
このサーバーで扱った呼出し状態によって消費された総バイト数です。 |
