|
|
以下の節では、デプロイメントの SIP データ層クラスタを構成する Oracle Communications Converged Application Server インスタンスをコンフィグレーションする方法について説明します。
Oracle Communications Converged Application Server SIP データ層は、同時 SIP 呼のアプリケーション呼状態を管理するサーバ インスタンスのクラスタです。SIP データ層では、呼状態の単一のコピーを処理することも、サーバ マシンで障害が発生したりネットワーク接続が中断された場合でも呼状態データが失われないように、必要に応じて複数のコピーを処理することもできます。
SIP データ層クラスタは、1 つまたは複数の「パーティション」として構成します。1 つのパーティションは、同時呼状態データの同じ部分を管理する、1 つまたは複数の SIP データ層サーバ インスタンスで構成されます。単一サーバの Oracle Communications Converged Application Server インストールや、エンジン層と 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 Communications Converged Application Server データ層の機能を読み込みます。datatier.xml に名前が指定されていないサーバは、エンジン層ノードとして機能し、sipserver.xml コンフィグレーション ファイルでコンフィグレーションされる SIP サーブレット コンテナの機能を提供します。
以下の節では、SIP データ層の一般的なコンフィグレーションに対応する datatier.xml の内容のサンプルを示します。XML スキーマおよび要素の詳細については、『コンフィグレーション リファレンス マニュアル』の「SIP データ層のコンフィグレーション リファレンス (datatier.xml)」を参照してください。
SIP データ層に属するすべてのサーバは、同一の WebLogic Server クラスタのメンバーです。クラスタ コンフィグレーションにより、各サーバが他のサーバのステータスをモニタできます。また、クラスタを使用すると、すべてのサーバに対して sipserver と datatier カスタム リソースをデプロイメントすることも簡単です。
信頼性を高めるために、1 つのパーティション内に最大 3 つのレプリカをコンフィグレーションできます。
レプリカやエンジン層ノードの実行中に SIP データ層コンフィグレーションを変更することはできません。SIP データ層のメンバシップの変更や、パーティションまたはレプリカの再コンフィグレーションを行うためには、ドメインのサーバを再起動する必要があります。
図 3-1 に示すように、SipServer ノードの Administration Console の [コンフィグレーション｜データ層] ページから、現在の SIP データ層のコンフィグレーションを参照できます。
レプリカを追加すると、システム全体としての信頼性が向上しますが、パーティションにサーバを追加するごとに、レプリケートされたデータを処理するためのネットワークの帯域幅が余分に必要となるという点には留意が必要です。レプリカが 3 つのパーティションでは、呼状態を変更する各トランザクションに対し、3 つのサーバそれぞれのデータが更新されることになります。
レプリカを使用するときには、高い信頼性を確実に実現するために、同じパーティションの各サーバ インスタンスはそれぞれ別個のマシンに配置します。1 つのマシンで 2 つ以上のレプリカをホストすると、マシンまたはネットワークで障害が発生した場合に、ホストされたそれらのレプリカすべてが影響を受けることになります。
SIP データ層サーバが取り得るステータスは、次の 3 つのいずれかです。
定期的な保守のためにいずれかの SIP データ層サーバ インスタンスをオフラインにする必要がある場合、同じパーティション内の少なくとも 1 つのサーバが active であるようにします。active サーバを停止し、同じパーティションの他のすべてのサーバが offline または recovering の場合には、アクティブな呼状態の一部が失われます。
Oracle Communications Converged Application Server は、呼状態がコンフィグレーションされたパーティションすべてに対して均等に、自動的に分割されます。
以下の節では、別個の SIP データ層を使用する Oracle Communications Converged Application Server インストールの典型的な例を説明します。
単一パーティションで単一サーバの SIP データ層は、最も単純なデータ層のコンフィグレーションを表します。コード リスト 3-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 エントリを定義するだけです。たとえば、コード リスト 3-2 に示した datatier.xml のコンフィグレーション ファイルは、2 つのレプリカのコンフィグレーションを再作成します。
<?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>
</data-tier>
複数パーティションの作成は簡単です。コード リスト 3-3 に示すように、datatier.xml で複数の partition エントリを定義します。
<?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 データ層サーバを定義すると、呼状態のレプリカを追加できます。コード リスト 3-4 には、各パーティションにある 2 つのパーティションおよび 2 つのサーバ (レプリカ) でシステムを定義するために使用される datatier.xml のコンフィグレーション ファイルを示します。
<?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>
実行時 MBean である com.bea.Wcp.sip.management.runtime.ReplicaRuntimeMBean からは、SIP データ層の現在の状態とコンフィグレーションについての有用な情報が得られます。この MBean が持つ属性の詳細については、「Oracle Communications Converged Application Server の API JavaDoc 」を参照してください。
これらの属性の多くは、「Administration Console での SIP データ層のモニタ」に示すように、Administration Console の SIP サーバの [モニタ｜データ層の情報] タブで参照できます。
コード リスト 3-5 は、単一の管理対象サーバ インスタンスの現在の属性を SIP データ層パーティションでクエリする、シンプルな WLST セッションを示します。表 3-1 ReplicaRuntimeMBean のメソッドと属性の概要は MBean サービスの詳細を示します。
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
BackupStoreInboundStatistics |
|||
BackupStoreOutboundStatistics |
|||
|
|||
|