|
|
以下の節では、複数の地域的な Oracle Communications Converged Application Server インストール (サイト) 全体を通して呼状態トランザクションをレプリケートする方法について説明します。
Oracle Communications Converged Application Server SIP データ層で使用可能な基本的な呼状態のレプリケーション機能は、単一サイトへのインストールに優れたフェイルオーバ機能を備えています。しかし、SIP データ層内で実行されたアクティブなレプリケーションは、ほとんどのプロダクション ネットワークでレイテンシ パフォーマンスの要求に合わせるために高域のネットワークの帯域幅を必要とします。この帯域幅が要求されると、たとえば 1 つの地域のデータ センターからもう一方の地域のデータ センターまで、単一の SIP データ層クラスタで遠距離間のデータをレプリケートすることが難しくなります。
Oracle Communications Converged Application Server の地理的永続性機能は、複数の Oracle Communications Converged Application Server インストール (複数の管理ドメインまたは「サイト」) 全体で、呼状態のトランザクションのレプリケートを可能にします。地理的に冗長なコンフィグレーションは、たとえば長時間の地域的な停電など、サイト全体に壊滅的障害が発生した場合も呼の破棄を最小限にとどめます。
地理的永続性を使用する場合、主要サイトの単一レプリカは、変更された呼状態データを分散された JMS キューに移動します。デフォルトでは、データは SIP ダイアログの境界のみでキューに移動します。(SIP アプリケーションでの永続性ヒントの使用で説明しているように、カスタム API はさらに細かくデータをレプリケートする必要があるアプリケーション開発者向けです)。セカンダリ サイトでは、エンジン層サーバはメッセージを受け取ってデータをそのサーバの SIP データ層クラスタに書き込むために、分散されたキューをモニタするメッセージ リスナを使用します。セカンダリ サイトが長期間維持する呼状態の格納に RDBMS を使用する場合 (推奨) は、分散されたキューから書き込まれるデータはすべて、SIP データ層のメモリ内の格納場所ではなく、RDBMS に直接移動します。
別のドメインからデータを永続性するセカンダリ Oracle Communications Converged Application Server ドメイン自体が SIP トラフィックを処理する場合と、単なるアクティブな予備ドメインとして存在する場合があります。最も一般的なコンフィグレーションでは、2 つのサイトが互いの呼状態データをレプリケートするようにコンフィグレーションされ、各サイトがそれぞれのローカル SIP トラフィックを処理します。管理者はどちらかのドメインで障害が発生した場合、もう一方のドメインを「セカンダリ」サイトとして使用することができます。
代替コンフィグレーションは複数の他のサイトからのデータを永続性する 1 つのドメインを使用して、それらのサイトのセカンダリ サイトとして機能します。このコンフィグレーションのセカンダリサイトはそれ自体のローカル SIP トラフィックも処理できますが、他のいくつかのインストールからのアクティブなトラフィックを永続性する必要があるため、サイトのリソース要件が大きくなる可能性があります。
Oracle Communications Converged Application Server の地理的に冗長な永続性の機能は、RDBMS で長期的に維持される呼状態データの管理に非常に便利です。Oracle Communications Converged Application Server はサイト間でレプリケートする前に複数の呼状態データの収集を選択する可能性があるため、存続期間の短い呼はセカンダリ サイトへの移行中に失われることがあります。
所定の地域のサイトで稼動状態をモニタすると共に、地理的に異なる場所の間で呼を分割できる、信頼性のあるサイト対応のロード バランス ソリューションを使用する必要があります。Oracle Communications Converged Application Server には自動的にドメイン全体の障害を検出したり、セカンダリ サイトにフェイルオーバする機能はありません。所定のサイトに障害が発生した場合は、管理者が責任を持って判断を下し、そのサイトの呼を適切なセカンダリ サイトにリダイレクトします。その上、サイト対応のロード バランサは特定の callId へのすべてのメッセージを単一のホーム サイトに向けなければなりません (「アクティブ」サイト)。フェイルオーバの後、障害が発生したサイトが復元されると、ロード バランサは、2 つのサイトの間で呼を分割せずに、アクティブなサイトへの呼を続行しなければなりません。
セカンダリ サイトにフェイルオーバが起こった場合、一部の呼が破棄される可能性があります。一般的に、Oracle Communications Converged Application Server ではサイトのレプリケーションに用いる呼状態データが SIP ダイアログの境界のみでキューイングされるため、このような結果が生じます。データがキューに書き込まれる前に障害が発生すると、キューイングされたデータは削除されます。
また、SIP ダイアログの境界で呼状態を変更する場合のみ、Oracle Communications Converged Application Server はサイト全体の呼状態データをレプリケートします。セカンダリ サイトを起動する前にプライマリ サイトに長期に渡り実行中の呼が存在し、しかも呼状態にずっと変更がない場合、このような呼のデータはセカンダリ サイトにレプリケートされません。長期に渡り実行中の呼状態がレプリケートされる前に障害が発生した場合は、呼はフェイルオーバ中に失われます。
Oracle Communications Converged Application Server インストールのキャパシティを計画するとき、フェイルオーバの後、所定のサイトはそのサイト自体の地理的位置からだけでなく、障害が発生したサイトからすべての呼をサポートできるようにしておく必要があります。つまり、地理的に冗長なコンフィグレーションに関連するすべてのサイトは、フェイルオーバが発生しないかぎり、最大処理能力以下で動作することになります。
Oracle Communications Converged Application Server の地理的永続性機能を使用するには、プライマリ「ホーム」サイトとセカンダリ レプリケーション サイトの両方で特定のコンフィグレーション タスクを行う必要があります。表 5-1
| 注意 : | ほとんどのプロダクション デプロイメントでは、2 つのサイトが相互に複製サービスを行うため、一般的にはインストールをそれぞれプライマリおよびセコンダリ サイトとしてコンフィグレーションします。 |
Oracle Communications Converged Application Server は、表 5-1 で説明されたほとんどのリソースのコンフィグレーションを自動化するドメイン テンプレートを備えています。テンプレートの使用の詳細については、「地理的永続性のコンフィグレーション ウィザード テンプレートの使用」を参照してください。
既存の Oracle Communications Converged Application Server ドメインで地理的永続性を使用する場合は、「地理的冗長性の手動コンフィグレーション」の手順に従ってリソースを作成します。
Oracle Communications Converged Application Server は、地理的な永続性の機能を使用するために、2 種類のコンフィグレーション ウィザード テンプレートを備えています。
どちらのドメイン テンプレートのサーバ ポート番号も固有の番号であるため、必要に応じて 1 台のマシンで地理的永続性の機能をテストすることができます。各ドメインのインストールとコンフィグレーションを行うには、次の節に示す手順に従います。
テンプレートから新しいプライマリ ドメインを作成するには、以下の手順に従います。
cd ~/bea/wlserver_10.3 /common/bin
./config.sh
geo1domain.jar という名前のテンプレートを選択して [OK] をクリックします。
テンプレートはクラスタに 2 つのエンジン層サーバと SIP データ層サーバ、および管理サーバ (AdminServer) を持つ新しいドメインを作成します。エンジン層クラスタには、以下のリソースおよびコンフィグレーションが含まれます。
wlss.callstate.datasource。この機能を使用する場合は、JDBC データソース接続情報の変更で説明しているように、RDBMS 接続情報を含めるよう JDBC データソースを変更します。
「geo1」ドメインから呼状態データをレプリケートしてセカンダリ サイトを作成するテンプレートを使用するには、以下の手順に従います。
cd ~/bea/wlserver_10.3 /common/bin
./config.sh
geo2domain.jar という名前のテンプレートを選択して [OK] をクリックします。
テンプレートはクラスタに 2 つのエンジン層サーバと SIP データ層サーバ、および管理サーバ (AdminServer) を持つ新しいドメインを作成します。エンジン層クラスタには、以下のリソースおよびコンフィグレーションが含まれます。
wlss.callstate.datasource。この機能を使用する場合は、JDBC データソース接続情報の変更で説明しているように、RDBMS 接続情報を含めるよう JDBC データソースを変更します。SystemModule-Callstate は以下を含みます。JMSServer-1 および JMSServer-2 はそれぞれ engine1-site2 および engine2-site2 にデプロイされます。
既存のレプリケートされた Oracle Communications Converged Application Server インストール、または 1 組のインストールをお持ちの場合、地理的な冗長性を有効化にするために必要な JMS および JDBC リソースを手動で作成する必要があります。また、レプリケーションを行うには、各サイトをコンフィグレーションする必要があります。地理的な冗長性を有効化にするための基本的な手順を以下に示します。
長期間維持する呼状態を RDBMS へ格納する際に必要な JDBC リソースをコンフィグレーションするには、長期間維持する呼状態データの RDBMS への格納の手順に従います。
地理的な冗長なレプリケーションを有効化にするために、プライマリおよびセカンダリ サイトに正しく永続性の設定を行う必要があります。永続性をコンフィグレーションするには、以下の手順に従います。
もう一方のサイトから呼状態データをレプリケートするサイトはすべて、特定の JMS リソースをコンフィグレーションする必要があります。一方のサイトからデータをレプリケートしないサイトには、リソースは必要ありません。
この節では、複数のサイトが呼状態データをレプリケートする方法について詳しく説明します。管理者は地理的に冗長なレプリケーションの仕組みに対する理解を深め、このようなコンフィグレーションで発生する可能性のある問題をより効率的に解決するために、この情報を使用できます。Oracle Communications Converged Application Server インストール全体のレプリケーションの内部機能は、製品の将来的なリリースで変更される可能性があります。
Oracle Communications Converged Application Server のプライマリ サイトで呼が発生すると、呼の設定と処理が正常に始まります。SIP ダイアログの境界に達すると、サイトの SIP データ層に呼がレプリケートされ (インメモリ)、セカンダリ サイトへのレプリケーションが可能になります。Oracle Communications Converged Application Server はネットワークの使用を最適化するために、レプリケーションに複数の呼状態を集めることを選択することもあります。
次に SIP データ層の単一レプリカは、レプリカ サイトでコンフィグレーションされた JMS キューにレプリケートする呼状態データを格納します。データはラウンドロビン方式で、使用可能なエンジンの一つ (sipserver.xml の geo-remote-t3-url 要素で指定) に送信されます。セカンダリ サイトのエンジンは、新しいメッセージをローカル キューでモニタします。
メッセージを取得すると、セカンダリ サイトのエンジンは呼状態データを永続性し、それをプライマリ サイトのサイト ID 値に割り当てます。サイト ID はセカンダリ サイトでレプリケートされた呼状態データをセカンダリ サイトで管理されるその他すべての呼状態データから区別します。レプリケートされた呼状態データのタイマーはセカンダリ サイトで休止状態を続けるので、タイマー処理が動作の妨げになることはありません。
フェイルオーバを実行するには、管理者はグローバルなロード バランサ ポリシーを変更して障害が発生したプライマリ サイトからセカンダリ サイトへの呼のルーティングを始める必要があります。この処理を終了したあとで、セカンダリ サイトはバックアップされた呼状態データのリクエスト処理を始めます。障害が発生したサイトからレプリケートしたデータへのリクエストが行われると、エンジンはデータを取得し、呼のオーナーシップを取得して呼状態を起動します。起動処理には以下の動作が含まれます。
デフォルトでは、呼状態は個々の呼に対してのみ、またバックアップ サイトでそれらの呼がリクエストされた後にのみ起動されます。SipServerRuntimeMBean にはもう一方のサイトから複製された呼状態データをすべて引き継ぐ際に使用する activateBackup(byte site) メソッドが含まれています。管理者は WLST コンフィグレーション スクリプトを使用してこのメソッドを実行できます。また、サーバでデプロイされたアプリケーションはレプリケートされたサイト データへのリクエストがあるとこれを検出し、その後にメソッドを実行することもできます。コード リスト 5-1 にサイト 1 からレプリケートされた呼状態データすべてのオーナーシップを変更し、セカンダリ サイトを起動する JSP のサンプルコードを示します。デプロイされたサーブレット内でも同様のコードを使用できます。JSP またはサーブレットのどちらかを activateBackup メソッドを実行するために特権を持つユーザとして実行する必要があります。
特定の呼状態リクエストかどうかを検出するために、サーブレットは WlssSipApplicationSession.getGeoSiteId() メソッドを使用して呼に関連するサイト ID を検証できます。サイト ID の 0 以外の値は、サーブレットがもう一方のサイトからレプリケートされた呼状態データを使用して動作していることを示します。
<%
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 つの地理的なサイトの間で呼を分割してはいけない。
リモート サイトでメンテナンスを行うため、またはバックアップ サイトを完全に変更するために、リモート サイトへの呼状態のレプリケートを停止することもできます。レプリケーションは「永続性オプションのコンフィグレーション (プライマリおよびセカンダリ サイト)」で説明されるように、プライマリ サイトの Site Handling 属性を「none」に設定すると停止できます。
主要なサイトの地理的レプリケーションを無効にした後で、セカンダリ サイトのバックアップの呼状態も削除することもできます。SipServerRuntimeMBean には、あるサイトでもう一方のサイトからレプリケートされたすべての呼状態データを強制的に削除する際に使用できる deleteBackup(byte site) メソッドが含まれています。管理者は WLST コンフィグレーション スクリプトを使用するか、セカンダリ サイトにデプロイされたアプリケーションを通じてこのメソッドを実行できます。このメソッドを実行する手順は、「フェイルオーバ後の呼状態の処理」で説明される activateBackup メソッドの使用手順と同様です。
ReplicaRuntimeMBean には地理的に冗長なレプリケーションについてデータを取得する 2 つの新しいメソッドが含まれています。
ReplicaRuntimeMBean の詳細については、「JavaDoc」を参照してください。
「地域的サイト全体のレプリケーションのモニタ」で説明されている ReplicaRuntimeMBean メソッドの使用に加えて、管理者は障害が発生したデータベースがセカンダリ サイトのインストールに書き込むことを示す、すべての SNMP トラップをモニタする必要があります。
管理者は地理的に冗長なコンフィグレーションに属しているすべてのサイトが固有のサイト ID を使用しているか確認する必要があります。
|