以下の節では、Oracle WebLogic Communication Services と Oracle WebLogic Server で共通のコンフィグレーション タスクについて概要を説明します。 次のトピックがあります。
節 2.1「Oracle WebLogic Communication Services と Oracle WebLogic Serverで共通のコンフィグレーション タスク 」
節 2.2「Oracle WebLogic Communication Services のコンフィグレーションの概要」
Oracle WebLogic Communication Services は、定評のある Oracle WebLogic Server 10g リリース 3 アプリケーション サーバを基盤としており、システム レベルのコンフィグレーション タスクの多くは両製品で共通しています。このガイドでは、Oracle WebLogic Communication Services に固有のシステム レベルのコンフィグレーション タスクのみを取り上げます。たとえば、ネットワークとセキュリティのコンフィグレーションや、エンジン層と SIP データ層のクラスタ コンフィグレーションに関連するタスクなどです。
HTTP サーバのコンフィグレーションや、その他の基本的なコンフィグレーション タスク (サーバのロギングなど) については、Oracle WebLogic Server のドキュメントを参照してください。インストール概要については、『Oracle Fusion Middleware Oracle WebLogic Server インストールの概要』を参照してください。
Oracle WebLogic Communication Services の SIP Servlet コンテナ、SIP データ層のレプリケーション、および Diameter プロトコル機能はカスタム リソースとして Oracle WebLogic Server 10g Release 3 製品に実装されています。カスタム リソースの sipserver
と datatier
のペアには、エンジン層の SIP サブレット コンテナ機能と SIP データ層のレプリケーション機能が実装されています。通常、プロダクション環境へのデプロイには、両方のリソースがインストールされています。特化したデプロイメントでは、節 15.7「他のコンフィグレーション」で説明される SIP 対応ロード バランサと連動する sipserver
リソースのみが使用できます。
もう一方のカスタム リソース、diameter
は、Diameter に基づくプロトコル機能を提供します。1 つまたは複数の Diameter プロトコル アプリケーションを利用するデプロイメントにのみ必要です。
Oracle WebLogic Communication Services カスタム リソースの割り当ては、ドメイン コンフィグレーション ファイル config.xml
で参照できますが、変更はできません。各リソースの定義は、例 2-1 に表示されます。sipserver
と datatier
リソースは、それぞれ 例 2-1 で同じサーバとクラスタに割り当てる必要があります。リソースはエンジン層と SIP データ層の両方のクラスタでデプロイされます。
例 2-1 Oracle WebLogic Communication Services カスタム リソース
<custom-resource> <name>sipserver</name> <target>ORA_DATA_TIER_CLUST,ORA_ENGINE_TIER_CLUST</target> <descriptor-file-name>custom/sipserver.xml</descriptor-file-name> <resource-class>com.bea.wcp.sip.management.descriptor.resource.SipServerResource</resource-class> <descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.SipServerBean</descriptor-bean-class> </custom-resource> <custom-resource> <name>datatier</name> <target>ORA_DATA_TIER_CLUST,ORA_ENGINE_TIER_CLUST</target> <descriptor-file-name>custom/datatier.xml</descriptor-file-name> <resource-class>com.bea.wcp.sip.management.descriptor.resource.DataTierResource</resource-class> <descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.DataTierBean</descriptor-bean-class> </custom-resource> <custom-resource> <name>diameter</name> <target>ORA_ENGINE_TIER_CLUST</target> <deployment-order>200</deployment-order> <descriptor-file-name>custom/diameter.xml</descriptor-file-name> <resource-class>com.bea.wcp.diameter.DiameterResource</resource-class> <descriptor-bean-class>com.bea.wcp.diameter.management.descriptor.beans.ConfigurationBean</descriptor-bean-class> </custom-resource>
Oracle WebLogic Communication Services カスタム リソースは、config.xml
に定義されたネットワーク チャネル、クラスタとサーバ コンフィグレーション、Java EE リソースのような基本的なドメイン リソースを利用します。しかし、Oracle WebLogic Communication Services の特定のリソースは、機能に基づき別々のコンフィグレーション ファイルで設定されます。
sipserver.xml
は SIP コンテナ プロパティと一般的な Oracle WebLogic Communication Services エンジン層の機能を設定します。
datatier.xml
は、SIP データ層にレプリカとして属するサーバを識別し、SIP データ層パーティションの数とレイアウトも定義します。
diameter.xml
は Diameter ノードおよびドメインで使用する Diameter プロトコル アプリケーションを設定します。
approuter.xml
は、デフォルト アプリケーション ルータをコンフィギュレーションします。 DAR のコンフィギュレーションの詳細については、『Oracle WebLogic Communication Services インストールガイド』を参照してください。
ドメイン コンフィグレーション ファイル config.xml
は、ドメインで使用可能なすべての管理対象サーバを定義することに留意してください。sipserver
アプリケーションに含まれる sipserver.xml
、datatier.xml
および diameter.xml
コンフィグレーション ファイルは、SIP データ層レプリカ、エンジン層ノード、Diameter クライアント ノードとして行動するかどうかなど、各サーバ インスタンスのロールを決定します。
SIP サーブレット コンテナのプロパティのコンフィグレーションの変更は、Administration Console、または WLST ユーティリティのコマンドラインを使用して、稼動中のサーバに対して動的に適用できます (一部の SIP サーブレット コンテナのプロパティでは再起動の必要性を示すアイコンが表示される場合がありますが、この場合は変更後の再起動が必要であることを示しています)。SIP データ層ノードのコンフィグレーションは動的に変更できないので、パーティションやレプリカの数を変更するには、SIP データ層サーバを再起動する必要があります。
Diameter プロトコルの実装は、SIP Servlet コンテナ機能とは別に、カスタム リソースとして行われます。Diameter コンフィグレーション ファイルは、Diameter ノード機能を提供する 1 つまたは複数の Diameter プロトコル アプリケーションを設定します。Oracle WebLogic Communication Services は Diameter プロトコル アプリケーションを提供し、以下のノード タイプをサポートします。
Diameter Sh インタフェース クライアント ノード (Home Subscriber Service のクエリ用)
Diameter Rf インタフェース クライアント ノード (オフラインでのチャージ用)
Diameter Ro インタフェース クライアント ノード (オンラインでのチャージ用)
Diameter リレー ノード
HSS シミュレータ ノード (テストおよび開発にのみ適しており、プロダクション デプロイメントには適さない)
Diameter カスタム リソースは、Diameter クライアント ノードまたはリレー エージェントの役割をする必要があるサーバを持つドメイン、あるいは HSS シミュレーション機能を提供するサーバにのみデプロイされます。サーバ インスタンスの実際の機能は、diameter.xml
ファイルで定義されるコンフィグレーションによって異なります。
Oracle WebLogic Communication Services ドメインで Diameter Web アプリケーションをコンフィグレーションする手順については、「ネットワーク リソースのコンフィグレーション」の節 10.2「Diameter クライアント ノードとリレー エージェントをコンフィグレーションする手順」を参照してください。 Diameter アプリケーションの開発に関する詳細は、『Oracle WebLogic Communication Services 開発者ガイド』を参照してください。
Oracle WebLogic Communication Services には、SIP サーブレット コンテナのコンフィグレーションを変更するための方法として、以下が用意されています。
Oracle WebLogic Communication Services には、変更可能な Administration Console 拡張、SIP サーブレット ドメイン、グラフィカル ユーザ インタフェースを使用する Diameter コンフィグレーション プロパティが用意されています。Oracle WebLogic Communication Services の Administration Console の拡張は、Oracle WebLogic Server 10g リリース 3 で利用できるコア コンソールと似ています。すべての Oracle WebLogic Communication Services コンフィグレーションとモニタは、コンソールの左ペインにある次のノードを介して提供されます。
SipServer — SIP Servlet コンテナのプロパティとその他のエンジン層の機能をコンフィグレーションを行います。この拡張を使って、新規のパーティションの作成と SIP データ層のパーティションとレプリカの表示 (変更は不可) もできます。Administration Console を使用した SIP サーブレット コンテナのコンフィグレーションの詳細については、節 3.1「SIP コンテナのコンフィグレーションの概要」を参照してください。
Diameter — Diameter ノードとアプリケーションのコンフィグレーションを行います。
注意 : Oracle WebLogic Server Administration Console の使用方法の詳細については、『Oracle Fusion Middleware Administrator's Guide』の「Getting Started with Oracle WebLogic Server Administration Console」を参照してください。 |
WebLogic Scripting Tool (WLST) では、コマンドライン インタフェースを使用して、対話形式または自動化された (バッチの) コンフィグレーション操作を実行できます。WLST は稼動中の Oracle WebLogic Communication Services ドメインで利用可能な MBeans の表示や操作ができる JMX ツールです。節 3.1「SIP コンテナのコンフィグレーションの概要」では、WLST を使用して SIP サーブレット コンテナのプロパティを変更する手順を説明します。
Oracle WebLogic Communication Services コンフィグレーションの大半は、Administration Console または WLST を使用して実行されます。コンフィグレーション タスクによっては、以下の節で述べる方法も使用できます。
sipserver.xml
、datatier.xml
、diameter.xml
、および approuter.xml を手動で編集することもできます。 コンフィグレーション ファイルを手動で編集する場合は、コンフィグレーションの変更を適用するために、すべてのサーバを再起動する必要があります。
Oracle WebLogic Communication Services のプロパティは、JMX-compliant MBeans で表されます。 したがって、適切な Oracle WebLogic Communication Services の MBean を使用して、SIP コンテナ プロパティをコンフィグレーションする JMX アプリケーションをプログラムできます。
JMX を使用して WebLogic SIP Server の MBean プロパティを変更する一般的な手順については、節 3.3「WLST (JMX) によるコンテナ プロパティのコンフィグレーション」で説明されています (WLST 自体、JMX ベースのアプリケーションです)。 SIP コンテナ プロパティの処理に使用する個々の Mbean の詳細については、『Oracle Fusion Middleware Communication Services Java API Reference』を参照してください。
ログ レベルの設定は、logging.xml
ファイルを手動で編集するか、setLoggerLevel
(String loggerName, String logLevel)
MBean を設定するか、または Oracle Enterprise Manager から行うことができます。詳細については、節 12.2.1「ロギングのコンフィグレーション」を参照してください。 『Oracle Fusion Middleware 2 Day Administration Guide』も参照してください。
Oracle WebLogic Communication Services の起動スクリプトでは、パフォーマンスを左右する多数の JVM パラメータにデフォルト値が使用されています。たとえば、JVM のガベージ コレクションやヒープ サイズのパラメータが省略されていることや、評価や開発以外の目的には適切でない値を使用していることがあります。プロダクション システムでは、十分なパフォーマンスを実現するために、さまざまなヒープ サイズやガベージ コレクションの設定でアプリケーションのプロファイリングを厳密に行う必要があります。プロダクション ドメインで JVM のパフォーマンスを最大限に引き出す方法については、節 8.8「プロダクション デプロイメントにおける JVM ガベージ コレクションのチューニング」を参照してください。
警告 : 複数のエンジン層サーバおよび SIP データ層サーバで構成されるドメインをコンフィグレーションするときには、SIP プロトコル スタックを正しく機能させるために、すべてのシステムの時計を共通の時刻設定元に合わせて、誤差 1 ~ 2 ミリ秒以内で正確に同期する必要があります。詳細は、節 3.5.2「SIP タイマーの正確な同期に必要な NTP のコンフィグレーション」を参照してください。 |
通常、Oracle WebLogic Communication Services ドメインは、多数のエンジン層サーバと SIP データ層サーバで構成されており、異なる種類のサーバ間に依存関係があります。したがって、ドメインを起動するときには、一般に次の手順に従う必要があります。
ドメインの管理サーバを起動する。ドメインでエンジンおよび SIP データ層サーバに初期のコンフィグレーションを提供するには、管理サーバを起動します。管理サーバは、各管理対象サーバの起動/停止のステータスをモニタする目的にも使用します。通常、管理サーバの起動にはコンフィグレーション ウィザードでインストールされた startWebLogic.cmd
スクリプトを使用するか、またはカスタムの起動スクリプトを使用します。
各パーティションの SIP データ層サーバを起動する。SIP データ層のサーバで呼状態データを処理できる状態にならないと、エンジン層が機能しません。リクエストの処理を開始するためには、各パーティションのレプリカがすべて利用できる状態になっている必要はありませんが、同時呼状態を処理するためには、コンフィグレーションされた各パーティションにつき少なくとも 1 つのレプリカを利用できる必要があります。プロダクション ネットワーク トラフィックに対してシステムをオープンするためには、全レプリカが起動して利用可能な状態になっている必要があります。
通常、各データ層サーバの起動には、コンフィグレーション ウィザードでインストールされた startManagedWebLogic.cmd
スクリプトを使用するか、またはカスタムの起動スクリプトを使用します。startManagedWebLogic.cmd
では、起動するサーバの名前と、ドメインの管理サーバの URL を指定する必要があります。たとえば次のように指定します。
startManagedWebLogic.cmd datanode0-0 t3://adminhost:7001
エンジン層サーバを起動する。SIP データ層サーバを起動したら、エンジン層でサーバを起動して、クライアント リクエストの処理を開始できます。エンジン層サーバも、SIP データ層サーバと同様に、通常はstartManagedWebLogic.cmd
スクリプトまたはカスタムの起動スクリプトを使用して起動します。
以上の起動シーケンスに従うと、すべての管理対象サーバで、最新の SIP サーブレット コンテナと SIP データ層のコンフィグレーションが確実に使用されます。また、この起動シーケンスなら、SIP データ層のサーバを利用できないときに生成されるエンジン層のエラー メッセージも回避できます。
Oracle WebLogic Communication Services インストールの管理サーバは、サービスおよびアプリケショーンがコンフィグレーションする、デプロイする、およびモニタするには必要です。
注意 : ハードウェア、ソフトウェア、またはネットワークの問題によって管理サーバで障害が発生した場合に、その影響が及ぶのは、管理、デプロイメント、およびモニタの処理に対してのみです。管理対象サーバが稼動を続けるうえでは、管理サーバは必要ありません。つまり、管理サーバで障害が発生した場合でも、管理対象サーバ インスタンスで実行中の Java EE アプリケーションと SIP 機能は引き続き動作します。 |
Oracle WebLogic Communication Services ドメインの管理サーバと管理対象サーバのインスタンスをコンフィグレーションするうえでは、以下のベスト プラクティスをお勧めします。
管理サーバのインスタンスは、専用のマシンで稼動させます。管理サーバ マシンには管理対象サーバ マシンと同程度のメモリ容量が必要ですが、管理という目的のうえでは、通常は単一の CPU で問題ありません。
管理対象サーバのすべてのインスタンスで、管理対象サーバの独立を使用するようにコンフィグレーションします。管理対象サーバの独立とは、ネットワーク、ハードウェア、またはソフトウェアの障害によって管理サーバにアクセスできない場合でも管理対象サーバを再起動できる機能です。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバの起動と停止の管理』を参照してください。
Oracle WebLogic Communication Services ドメインのすべての管理対象サーバを自動的に再起動するようにノード マネージャ ユーティリティをコンフィグレーションします。詳細については、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool ガイド』を参照してください。
管理サーバのインスタンスまたはマシンで障害が発生した場合でも、その影響が及ぶのは、コンフィグレーション、デプロイメント、およびモニタの各機能のみであり、管理対象サーバは引き続き動作して、クライアント リクエストの処理を続けます。管理サーバの障害によって欠落が生じる可能性があるのは、以下の点です。
進行中の管理およびデプロイメントの処理の欠落。
進行中のロギング機能の欠落。
WebLogic Server インスタンスの SNMP トラップ生成の欠落 (Oracle WebLogic Communication Services インスタンスのトラップ生成ではありません)。管理対象サーバでは、Oracle WebLogic Communication Services のトラップは管理サーバがなくても生成されます。
通常の運用を再開するために、障害が発生した管理サーバ インスタンスはできるだけ早く再起動してください。
Oracle WebLogic Communication Services の一般的な管理と保守では、WebLogic Server のコンフィグレーション プロパティと Oracle WebLogic Communication Services のコンテナ プロパティの両方を管理することが必要です。こうした一般的なコンフィグレーション タスクを表 2-1 に示します。
表 2-1 Oracle WebLogic Communication Services の一般的なコンフィグレーション タスク
タスク | 説明 |
---|---|
|
|
第 6 章「SIP データ層のパーティションとレプリカのコンフィグレーション」 |
|
|
|
|
|
|
|