| Oracle® Fusion Middleware ActiveCacheの使用 11gリリース1 (10.3.6) B65046-02 |
|
 前 |
 次 |
ActiveCacheを使用すると、アプリケーションはCoherenceデータ・キャッシュに簡単にアクセスできます。ActiveCacheは@Resourceアノテーションを提供します。これによって、Coherence NamedCacheキャッシュ・オブジェクトが識別され、サーブレットまたはEJBに動的に注入できるようになります。リソース・インジェクションの代替手段として、ActiveCacheを使用するアプリケーションは、コンポーネント・ベースのJNDIツリーを使用してNamedCacheを参照できます。
次の手順は、ActiveCacheをWebLogic Server上で実行されるアプリケーションと共に使用するための手順の概要を説明します。
アプリケーションを実行するクラスタ・トポロジを選択します。ActiveCacheデプロイメント・トポロジの選択に関する項を参照してください。
アプリケーションが使用するCoherenceキャッシュの構成を指定します。データ・キャッシュの作成と構成に関する項を参照してください。
Coherenceキャッシュにアクセスするため、Webアプリケーションにコードを追加します。JNDI参照またはリソース・インジェクションのいずれかを使用して、Coherence NamedCacheキャッシュ・オブジェクトにアクセスします。アプリケーションからデータ・キャッシュへのアクセスに関する項を参照してください。
アプリケーションと共にキャッシュ構成ファイルを保存します。ファイルの保存場所は、デプロイされたアプリケーションに対してキャッシュをどのように表示するかに依存します。キャッシュ構成ファイルの配置に関する項を参照してください。
起動時にサーバーがキャッシュ構成ファイルにアクセスする仕組みを決めます。サーバー起動時のキャッシュ構成へのアクセスに関する項を参照してください。
Coherenceクラスタは、クラスローダー・スコープです。クラスローダー階層内にcoherence.jarをデプロイする場所は、クラスタ・メンバーシップの処理方法を決定します。アプリケーションのパッケージ化とCoherenceクラスタ・スコープの構成に関する項を参照してください。
必要に応じて、デプロイしたアプリケーションの事前定義クラスタ値を調整します。WLSTまたはWebLogic Server管理コンソールを使用して、一部のクラスタ関連値を構成できます。Coherenceクラスタの作成と構成に関する項を参照してください。
スタンドアロンCoherenceキャッシュ・サーバーを起動します。キャッシュ・サーバーの起動に関する項を参照してください。
任意の方法を使用してWebLogic Serverを起動します。WebLogic Serverの起動に関する項を参照してください。
WebLogic Server管理コンソールからCoherenceクラスタのランタイム・ステータスを監視します。Coherenceクラスタ・プロパティの監視に関する項を参照してください。
通常、信頼性と拡張性を高めるため、複数のコンピュータがデータ、リソース、およびサービスの保存と管理を抑制するためにクラスタを使用できます。Coherenceクラスタは、アプリケーションのオブジェクトとデータを保存・管理します。Coherenceデータ・キャッシュに挿入されるデータはすべて、同一のキャッシュ構成を共有するアプリケーションのCoherenceクラスタにあるすべてのサーバーによってアクセス可能です。
ActiveCacheは、いくつかの異なる組合せのアプリケーションとデータ層、またはクラスタ・トポロジに利用できます。WebLogic ServerインスタンスとスタンドアロンCoherenceキャッシュ・サーバー(ここでは、データ保持専用のJVMインスタンスで稼働するCoherenceデータ・サーバーとして定義)を組み合せることで、様々なクラスタ・トポロジを形成できます。
In-Processトポロジでは、クラスタ内の(ActiveCacheを活用する)すべてのWebLogic Serverインスタンスは、ストレージが有効化されています。この場合、ストレージの有効化とは、当該サーバーがキャッシュ・ストレージとバックアップ・ストレージを提供することを意味します。個別のデータ層を作成する必要はありません。アプリケーションとデータ・キャッシュは連結され、各サーバー・インスタンスはリクエストとキャッシュ・データを送信できます。
このトポロジは、開発とテストを主な目的としてサポートされます。処理中のセッション・データをアプリケーション・サーバーを使用して保存することで、このトポロジはきわめて簡単に設定でき、開発とテストを目的として迅速に稼働します。このトポロジは本番向けにお薦めできません。
プロセス外トポロジでは、スタンドアロンCoherenceキャッシュ・サーバーを使用してデータをホストします。WebLogic Serverインスタンスがストレージ無効になるように構成します。このインスタンスは、リクエストの送信に使用されます。このトポロジは、正しい個別のデータ層を作成し、リクエストを処理中のWebLogic Serverインスタンスのオーバーヘッドを削減します。
WebLogic Out-Of-Processトポロジは、Out-Of-Processトポロジ上の少し異なるバリエーションです。このトポロジでは、スタンドアロンCoherenceキャッシュ・サーバーのかわりに、ストレージが有効なWebLogic Serverインスタンスが使用されます。ストレージが有効/無効なWebLogic Serverインスタンスの組合せが混在します。このトポロジでは、リクエストとデータも独自のサーバーに対して分離されるため、リクエストの処理待機時間も短縮されます。
|
注意: In-ProcessおよびOut-of-Processデプロイメント・トポロジの詳細は、『Oracle Coherence*Webユーザー・ガイド』のトポロジのデプロイメントに関する項を参照してください。 |
ActiveCacheは、Oracle Coherenceによってサポートされる任意のキャッシュ・タイプを使用するように構成できます。Coherenceキャッシュとその構成に関する詳細は、『Oracle Coherence開発者ガイド』のCoherenceキャッシュの作成と使用に関する項を参照してください。
WebLogic Server 10.3.3以降で実行されるアプリケーションは、ActiveCacheを使用してデータ・キャッシュにアクセスできます。データ・キャッシュは、Coherence NamedCacheキャッシュ・オブジェクトによって表示されます。このオブジェクトは、Coherenceクラスタのメンバー間で共有されるリソースを保持するために設計されています。このようなリソースはメモリー内で管理され、通常はデータベースに恒久的に保存されるデータまたはアセンブル/クラスタ化されたデータから構成されます。つまり、こうしたリソースはキャッシュ済と言われます。
コンポーネント・スコープのJNDIリソース・ツリー内でリソース・インジェクションまたは参照のいずれかによって、アプリケーションはNamedCacheを取得できます。参照を使用する手法は、EJB、サーブレット、またはJSPで使用できます。リソースを注入する手法は、サーブレットまたはEJBで使用できます。
|
注意: Coherenceの名前が付けられたキャッシュにもCoherence*WebベースのHTTPセッションにも、リモートEJB参照を保存しないことをお勧めします。 |
リソースを注入してNamedCacheを取得するには
@Resourceアノテーションは、動的にNamedCacheを注入するためにサーブレットまたはEJBで使用されます。このアノテーションは、JSPでは使用できません。アノテーションで使用されるキャッシュの名前は、Coherenceキャッシュ構成ファイルcoherence-cache-config.xmlで定義する必要があります。
例3-1は、NamedCache myCacheのリソース・インジェクションを示します。
例3-1 リソース・インジェクションによるNamedCacheの取得
... @Resource(mappedName="myCache") com.tangosol.net.NamedCache nc; ...
JNDIを参照してNamedCacheを取得するには
コンポーネント・スコープJNDIツリーは、NamedCacheを参照するためにEJB、サーブレット、またはJSPで使用されます。
コンポーネント・スコープJNDI参照を使用するには、web.xmlまたはejb-jar.xmlファイルで、com.tangosol.net.NamedCache型のresource-refを定義します。例3-2は、myCacheをNamedCacheとして識別する<resource-ref>スタンザを示します。
|
注意: <res-auth>および<res-sharing-scope>要素は、この例には登場しません。現在、データ・キャッシュにアクセスするためにリソース・サインオンは実行されないため、<res-auth>要素は無視されます。データ・キャッシュはデフォルトで共有可能でこの挙動はオーバーライドされないため、<res-sharing-scope>要素は無視されます。 |
キャッシュ構成ファイルを保存する場所によってキャッシュ・スコープ(つまり、デプロイされたアプリケーションに対するキャッシュの可視性)が決まります。キャッシュ・スコープによってCoherenceノードが定義されます。Coherenceノードは、単一のサーバー・プロセス(WebLogic Serverインスタンス(Coherenceが稼働)またはスタンドアロンCoherenceキャッシュ・サーバー)、WebLogic Serverアプリケーション(EAR)、またはアプリケーション・モジュール(Webアプリケーション)になります。1つのCoherenceノード内には多数のデータ・キャッシュが存在できます。
キャッシュの可視性には次の3つのオプションがあります。
アプリケーション・サーバー・スコープ: コンテナ内にデプロイされたすべてのアプリケーションは、1つのCoherenceノードの一部となります。キャッシュは、サーバー上でデプロイされたすべてのアプリケーションにグローバルに表示されます。
EARスコープ: 各EAR内にデプロイされたすべてのアプリケーションは、1つのCoherenceノードの一部となります。キャッシュは、EAR内のすべてのモジュールに対して表示されます。たとえば、すべてのモジュールが同一キャッシュを共有する必要がある場合にはこれが推奨デプロイメントとなります。
WARスコープ: デプロイされた各Webアプリケーションは、独自のCoherenceノードになります。キャッシュは、個々のモジュールに対してのみ表示されます。たとえば、スタンドアロンWARデプロイメントまたはスタンドアロンEJBデプロイメントに対してこれは推奨デプロイメントとなります。
|
注意: キャッシュ構成は、WebLogic ServerインスタンスとスタンドアロンCoherenceキャッシュ・サーバーの両方に対して整合性を持つ必要があります。 |
表3-1 キャッシュのスコープによるキャッシュ構成ファイルの配置
| このキャッシュのスコープを指定するには... | キャッシュ構成ファイルを保存するには... | コメント |
|---|---|---|
|
アプリケーション・サーバー・スコープ |
|
詳細は、「サーバー起動時のキャッシュ構成へのアクセス」を参照してください。 |
|
EARファイルのアプリケーション・スコープのキャッシュ |
|
EARレベルで定義されたキャッシュは、EAR内の個別のアプリケーションに対してのみ表示されますが、アプリケーションにおいてすべてのEAR全体で一意のサービス名を持つ必要があります。また、EARレベルとモジュール・レベルの両方でキャッシュを定義する場合、キャッシュ名、スキーム名、およびサービス名は、EARレベルのキャッシュ構成およびモジュール・キャッシュ構成全体で一意である必要があります。 |
|
EARにおけるWebコンポーネント・スコープ・キャッシュ、またはスタンドアロンWARデプロイメント |
|
モジュール・レベルで定義されたキャッシュは、個々のモジュールに対してのみ表示されますが、アプリケーションにおいてすべてのモジュール全体で一意のサービス名を持つ必要があります。また、EARレベルとモジュール・レベルの両方でキャッシュを定義する場合、キャッシュ名、スキーム名、およびサービス名は、EARレベルのキャッシュ構成およびモジュール・キャッシュ構成全体で一意である必要があります。 |
|
スタンドアロンEJBデプロイメント |
|
EAR内のEJBモジュールは、モジュール・スコープのキャッシュを持つことはできません。アプリケーション・スコープのキャッシュのみ持つことができます。 |
サーバーは、起動時にキャッシュ構成ファイルにアクセスできる必要があります。これを行うには次の2つの方法があります。
キャッシュ構成ファイルをサーバー・クラスパスに配置するか、または
tangosol.coherence.cacheconfigシステム・プロパティを持つサーバー起動コマンドで、キャッシュ構成ファイルの場所を宣言します。このプロパティの詳細は、『Oracle Coherence開発者ガイド』を参照してください。
例3-3は、サンプルのキャッシュ・サーバー起動コマンドにおけるtangosol.coherence.cacheconfigシステム・プロパティを示します。
例3-3 サーバー起動コマンドにおけるキャッシュ構成ファイルの宣言
java -server -Xms512m -Xmx512m
-cp <Coherence installation dir>/lib/coherence.jar
-Dtangosol.coherence.management.remote=true
-Dtangosol.coherence.cacheconfig=WEB-INF/classes/coherence-cache-config.xml
-Dtangosol.coherence.session.localstorage=true com.tangosol.net.DefaultCacheServer
2つ(以上)のアプリケーションを取り扱う場合、2つ(以上)の異なるキャッシュ構成を持つ可能性があります。この場合、Coherenceキャッシュ・サーバー上のキャッシュ構成にはこれらを統合した構成が含まれる必要があります。これによって、アプリケーションが同一キャッシュ・クラスタでサポートされるようになります。これはスタンドアロン・キャッシュ・サーバー用にのみ有効です。
Coherenceクラスタは、クラスタの通信を可能にするグループ・アドレスを共有するCoherenceノードのグループです。Coherenceクラスタは、クラスローダー階層内にcoherence.jarファイルを配置する場所に従い、クラスローダー・スコープを指定されます。Coherenceクラスタは次のようになります。
アプリケーション・サーバー・スコープ: JVM全体は1つのCoherenceクラスタとして機能します。
EARスコープ: 各アプリケーションがCoherenceクラスタになります。
WARスコープ: アプリケーション内の各WebモジュールがCoherenceクラスタになります。
これら3つのスコープ・シナリオのパッケージングおよび構成オプションは、次の項で説明されます。
この構成を使用すると、Coherenceキャッシュに直接アクセスしているWebLogic Serverインスタンス上でデプロイされたすべてのアプリケーションは、1つのCoherenceクラスタの一部となります。キャッシュは、サーバー上でデプロイされたすべてのアプリケーションに表示されます。この構成は、クラスタ内で最小限の数のCoherenceノードを作成します(各WebLogic Serverインスタンス用)。
Coherenceライブラリはサーバーのクラスパスでデプロイされるため、Coherenceクラスのコピーが1つのみJVMに読み込まれ、リソース使用率が最小になります。ただし、すべてのアプリケーションがCoherenceクラスタ構成を使用しているため、1つのアプリケーションが誤動作を起こすとすべてのアプリケーションに影響が及びます。
Coherenceデータ・キャッシュをアプリケーション・サーバー・スコープのCoherenceクラスタと共に使用するには、
WebLogic Serverシステム・クラスパスを編集し、coherence.jarとWL_HOME/common/deployable-libraries/active-cache.jarをシステム・クラスパス内にインクルードします。active-cache.jarは、システム・クラスパス内のdeployable-librariesフォルダからのみ参照し、他の場所にコピーしないでください。
(オプション) Coherenceクラスタ・プロパティを構成する場合は、CoherenceClusterSystemResourceMBeanを作成し、ServerMBean内でそれを参照します。WebLogic Server管理コンソールまたはWLSTを使用して、MBeanを作成・参照できます。例3-9のcreateServerScopedCoherenceSystemResourceを参照してください。
この構成を使用すると、各EAR内にデプロイされたすべてのアプリケーションは、1つのCoherenceクラスタの一部となります。キャッシュは、EAR内のすべてのモジュールに対して表示されます。たとえば、すべてのモジュールが同一のCoherenceノードを共有する必要がある場合にはこれが推奨デプロイメントとなります。1つのEARのみをアプリケーション・サーバーにデプロイする場合にも推奨構成となります。
この構成は、クラスタ内で2番目に最小限の数のCoherenceノードを作成します(デプロイされた各EAR用)。Coherenceライブラリはアプリケーションのクラスパスでデプロイされるため、Coherenceクラスのコピーが1つのみ各EARに読み込まれます。
EAR内のすべてのWebアプリケーションは同一クラスタ構成を共有するため、任意のアプリケーションで誤動作が起こると、EAR内のすべてのWebアプリケーションに影響が及びます。EARスコープCoherenceクラスタは、アプリケーション・サーバー・クラスパスへの変更が必要ないため、デプロイメントの手間を省けます。
CoherenceキャッシュをEARスコープのCoherenceクラスタと共に使用するには、
次の方法のいずれかを使用し、coherence.jarおよびactive-cache.jarファイルを、アプリケーションがデプロイされるすべてのターゲット・サーバーに共有ライブラリとしてデプロイします。
WebLogic Server管理コンソールを使用し、coherence.jarおよびactive-cache.jarを共有ライブラリとしてデプロイします。『Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプ』のJava EEライブラリのインストールに関する項を参照してください。
管理コンソールの代替手段として、コマンドライン上でJARファイルをデプロイできます。次はデプロイメント・コマンドのサンプルです。
java weblogic.Deployer -username <> -password <> -adminurl <> -deploy coherence.jar -name coherence -library -targets <> java weblogic.Deployer -username <> -password <> -adminurl <> -deploy active-cache.jar -name active-cache -nostage -library -targets <>
coherence.jarおよびactive-cache.jarをアプリケーションのEAR APP-INF/libフォルダにコピーします。ただし、共有ライブラリとしてデプロイする方法が優先されます。
ライブラリとしてcoherence.jarおよびactive-cache.jarファイルを参照します。例3-4は、サンプルのweblogic-application.xml構成ファイルを示します。
(オプション) Coherenceクラスタ・プロパティを構成する場合は、CoherenceClusterSystemResourceMBeanを作成し、weblogic-application.xmlファイル内のcoherence-cluster-ref要素として参照します。この要素によって、アプリケーションはCoherenceClusterSystemResourceMBean属性によって指定されるとおりにCoherenceクラスタに登録できます。
例3-5はサンプル構成を示します。サンプル内のmyCoherenceCluster MBeanは、CoherenceClusterSystemResourceMBean型です。
アプリケーション・スコープCoherenceクラスタにフィルタ処理クラスローダーを定義するには、
coherence.jarがアプリケーション・サーバー・クラスパス内に配置される場合、フィルタ処理クラスローダーを定義してEARスコープ・クラスタを構成できます。これは、次の手順で示されます。
coherence.jarをアプリケーション・クラスパスに配置します。
EARファイル内のフィルタ処理クラスローダーを構成します。
フィルタ処理クラスローダーは、weblogic-application.xmlファイルの<prefer-application-packages>スタンザで定義されます。例3-6はサンプルのフィルタ処理クラスローダー構成を示します。package-name要素は、coherence.jarおよびactive-cache.jar内のクラスのパッケージ名を示します。
この構成を使用するか、または1つのアプリケーションのみがCoherenceキャッシュを使用できるようにする場合、デプロイされた各Webアプリケーションは独自のCoherenceクラスタになります。キャッシュは、個々のモジュールに対してのみ表示されます。たとえば、スタンドアロンWARデプロイメントまたはスタンドアロンEJBデプロイメントに対してこれは推奨デプロイメントとなります。
複数のWARファイルをデプロイしている場合、この構成はクラスタ内で最大数のCoherenceノード(coherence.jarを使用するデプロイされた各WARファイル用)を作成します。また、これによって3つの構成のリソース使用率が最大になります。つまり、Coherenceクラスの1つのコピーがデプロイされた各WARに読み込まれます。他方、デプロイされた各Webアプリケーションはその独自クラスタであるため、Webアプリケーションは他の潜在的に誤動作を起こす可能性があるWebアプリケーションから完全に孤立します。
|
注意: EAR内のWebモジュールには、モジュール・スコープCoherenceノードを含めることができますが、EAR内のEJBモジュールにはアプリケーション・スコープCoherenceノードを含めることができます。 |
CoherenceキャッシュをWARスコープのCoherenceクラスタと共に使用するには
WebLogic Server管理コンソールを使用し、coherence.jarおよびactive-cache.jarを、アプリケーションがデプロイされるすべてのターゲット・サーバーに共有ライブラリとしてデプロイします。『Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプ』のJava EEライブラリのインストールに関する項を参照してください。
管理コンソールの代替手段として、コマンド・ライン上でJARファイルもデプロイできます。次はデプロイメント・コマンドのサンプルです。
java weblogic.Deployer -username <> -password <> -adminurl <> -deploy coherence.jar -name coherence -library -targets <> java weblogic.Deployer -username <> -password <> -adminurl <> -deploy active-cache.jar -name active-cache -nostage -library -targets <>
coherence.jarおよびactive-cache.jarをオプション・パッケージとして、Coherenceを使用する各モジュールのmanifest.mfファイルにインポートします。
マニフェスト・ファイル使用の代替手段として、coherence.jarおよびactive-cache.jarを各WARファイルのWEB-INF/libディレクトリにコピーします。
例3-7は、サンプルのmanifest.mfファイルのコンテンツを示します。
(オプション) Coherenceクラスタ・プロパティを構成する場合は、CoherenceClusterSystemResourceMBeanを作成し、weblogic.xmlまたはweblogic-ejb-jar.xmlファイル内のcoherence-cluster-ref要素として参照します。
例3-8は、weblogic.xmlファイル内のWARスコープ・クラスタのサンプル構成を示します。myCoherenceCluster MBeanは、CoherenceClusterSystemResourceMBean型です。
WLSTまたは管理コンソールを使用し、Coherenceクラスタを作成および構成し、クラスタ構成がアクセス可能になるWebLogic Serverインスタンスまたはクラスタを選択できます。
例3-9で示されるcreateCoherenceClusterMBean.py WLSTスクリプトは、管理サーバー(myserver)にデプロイしたサーバー・スコープ構成を含む3つのCoherenceクラスタを構成します。
次のサンプル・コマンドを使用してWLSTを呼び出してスクリプトを実行します。
java -Dadmin.username=weblogic -Dadmin.password=welcome1 -Dadmin.host=localhost -Dadmin.port=7001 -Dtangosol-override="c:/temp/tangosol-coherence-override.xml" weblogic.WLST c:/temp/createCoherenceClusterMBean.py
例3-9 createCoherenceClusterMBean.py
from java.util import *
from javax.management import *
from java.lang import *
import javax.management.Attribute
"""
This script configures three Coherence Cluster System Resource MBeans and deploys them to the admin server
"""
def createCoherenceSystemResource(wlsTargetNames, coherenceClusterSourceName):
name = coherenceClusterSourceName
# start creation
print 'Creating CoherenceClusterSystemResource with name '+ name
cohSR = create(name,"CoherenceClusterSystemResource")
cohBean = cohSR.getCoherenceClusterResource()
cohCluster = cohBean.getCoherenceClusterParams()
cohCluster.setUnicastListenAddress("localhost")
cohCluster.setUnicastListenPort(7001)
cohCluster.setUnicastPortAutoAdjust(true)
# you can set up the multicast port or define WKAs
cohCluster.setMulticastListenAddress("231.1.1.1")
cohCluster.setMulticastListenPort(8001)
cohCluster.setTimeToLive(5)
for wlsTargetName in wlsTargetNames:
cd("Servers/"+wlsTargetName)
target = cmo
cohSR.addTarget(target)
cd("../..")
def createServerScopedCoherenceSystemResource(wlsTargetNames, coherenceClusterSourceName):
name = coherenceClusterSourceName
# start creation
print 'Creating CoherenceClusterSystemResource with name '+ name
cohSR = create(name,"CoherenceClusterSystemResource")
cohBean = cohSR.getCoherenceClusterResource()
cohCluster = cohBean.getCoherenceClusterParams()
cohCluster.setUnicastListenAddress("localhost")
cohCluster.setUnicastListenPort(7002)
cohCluster.setUnicastPortAutoAdjust(true)
# you can set up the multicast port or define WKAs
cohWKAs = cohCluster.getCoherenceClusterWellKnownAddresses()
cohWKA = cohWKAs.createCoherenceClusterWellKnownAddress("wka1")
cohWKA.setName("wka1")
cohWKA.setListenAddress("localhost")
cohWKA.setListenPort(9001)
for wlsTargetName in wlsTargetNames:
cd("Servers/"+wlsTargetName)
target = cmo
cohSR.addTarget(target)
print cmo
serverBean = cmo
serverBean.setCoherenceClusterSystemResource(cohSR)
cd("../..")
def createCustomCoherenceSystemResource(wlsTargetNames, coherenceClusterSourceName, tangosolOverrideFile):
name = coherenceClusterSourceName
# start creation
cohSR = getMBean("/CoherenceClusterSystemResources/"+name)
if cohSR == None:
print 'Creating CoherenceClusterSystemResource with name '+ name
cohSR = create(name,"CoherenceClusterSystemResource")
cohSR.importCustomClusterConfigurationFile(tangosolOverrideFile)
for wlsTargetName in wlsTargetNames:
cd("Servers/"+wlsTargetName)
target = cmo
cohSR.addTarget(target)
cd("../..")
props = System.getProperties()
ADMIN_NAME = props.getProperty("admin.username")
ADMIN_PASSWORD = props.getProperty("admin.password")
ADMIN_HOST = props.getProperty("admin.host")
ADMIN_PORT = props.getProperty("admin.port")
ADMIN_URL = "t3://"+ADMIN_HOST+":"+ADMIN_PORT
TANGOSOL_OVERRIDE = props.getProperty("tangosol-override")
TARGETS = [ 'myserver' ]
print "Starting the script ..."
try :
connect(ADMIN_NAME, ADMIN_PASSWORD, ADMIN_URL)
edit()
startEdit()
createCoherenceSystemResource(TARGETS, 'cohSystemResource')
createServerScopedCoherenceSystemResource(TARGETS, 'serverScopedCohSystemResource')
createCustomCoherenceSystemResource(TARGETS, 'customCohSystemResource',TANGOSOL_OVERRIDE)
save()
activate(block="true")
disconnect()
print 'Done configuring the Coherence Cluster System Resources'
except:
dumpStack()
undo('true','y')
管理コンソールの手順は、『Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプ』のCoherenceの構成に関する項を参照してください。
クラスタ関連値は、WebLogic Server構成リポジトリの記述子ファイルに保存されます。
DOMAIN_HOME/config/coherence/CoherenceClusterSystemResourceName/CoherenceClusterSystemResourceName-####-coherence.xml、ここでDOMAIN_HOMEは、d:/oracle/MW_HOME/user_projects/domains/domain_nameなどのWebLogic Serverドメインをインストールした場所を示します。
たとえば、C:\Oracle\Middleware\user_projects\domains\base_domain\config\coherence\cohSystemResource\cohSystemResource-0759-coherence.xml
あるいは、例3-10で示すように、tangosol-coherence-override.xmlなどのカスタム構成ファイル内で構成することで、クラスタに指定されていないプロパティを構成できます。
例3-10 tangosol-coherence-override.xml
<?xml version='1.0'?>
<!--
This operational configuration override file is for use with Coherence in
a development mode.
-->
<coherence xml-override="/tangosol-coherence-override.xml">
<cluster-config>
<multicast-listener>
<time-to-live system-property="tangosol.coherence.ttl">4</time-to-live>
<join-timeout-milliseconds>3000</join-timeout-milliseconds>
</multicast-listener>
<packet-publisher>
<packet-delivery>
<timeout-milliseconds>30000</timeout-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
<logging-config>
<severity-level system-property="tangosol.coherence.log.level">5</severity-level>
<character-limit system-property="tangosol.coherence.log.limit">0</character-limit>
</logging-config>
</coherence>
WLSTを使用して、カスタム・クラスタ構成ファイル(例3-9のcreateCustomCoherenceSystemResourceを参照)またはWebLogic Server管理コンソールをインポートします。『Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプ』のカスタム・クラスタ構成のインポートに関する項を参照してください。
|
注意: カスタム構成ファイルをインポートしてクラスタ関連プロパティを指定する場合、ファイル内で指定されるプロパティは、WLSTまたはWebLogic Server管理コンソールを使用して指定されたプロパティと同一にしてはなりません。 |
スタンドアロンCoherenceキャッシュ・サーバーは、すべてのキャッシュ・データの保存および管理に関与する専用のJVMです。Coherenceデータ・クラスタ内のシニア・ノード(1番目のノード)は、起動に数秒かかる可能性がありますが、後続のノードの起動にかかる時間は最短になります。そのため、パフォーマンスを最適化するには、常にCoherenceキャッシュ・サーバーを起動してからWebLogic Serverインスタンスを起動する必要があります。これによって、ActiveCacheを使用するアプリケーションは、最短の時間(単位はミリ秒)で起動できることが保証されます。ActiveCacheを使用する任意の追加Webアプリケーションは、シニア・データ・メンバーとなることが保証されません。そのため、WebLogic Serverの起動には最小限の影響しか及ぼされません。
|
注意: 最初にキャッシュ・サーバーを起動するか、またはWebLogic Serverインスタンスを起動するかは、利用するクラスタ・トポロジに依存します。
|
WebLogic Server 10.3.4では、WebLogic Server管理サーバー(管理コンソールまたはWLSTによる)およびjavaベースのノード・マネージャを使用して、スタンドアロンのCoherenceキャッシュ・サーバーのライフサイクルを管理および監視できます。
ノード・マネージャは、WebLogic Serverユーティリティです。これを使用すると、サーバーを起動・停止したり、自動的にリモートで再起動したりできます。ノード・マネージャは、ノード・マネージャを使用して制御するCoherenceサーバー・インスタンスをホストする各コンピュータ上で実行する必要があります。
ノード・マネージャを使用してキャッシュ・サーバーを起動する前提条件の手順は次のとおりです。
サーバーを起動するようにノード・マネージャを構成します。
『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャの一般的な構成に関する項を参照してください。
ノード・マネージャを起動します。
ノード・マネージャは、コマンド・プロンプトまたはスクリプトを使用して手動で起動できます。『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』の「ノード・マネージャの起動」を参照。
WLSTを使用してノード・マネージャを起動するには次を実行します。
c:\>java weblogic.WLST wls:/offline> startNodeManager()
ノード・マネージャでWLSTを使用する方法の詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のノード・マネージャ・コマンドに関する項を参照してください。
Windowsでは、「スタート」メニューのショートカットからノード・マネージャを起動できます(WebLogic Server>「ツール」>「ノード・マネージャ」)。
|
注意: ユーザー・クラスをクラスパスに追加する必要がある場合、FEATURES_HOME/weblogic.server.modules.coherence.server_10.3.4.0.jar:COHERENCE_HOME/lib/coherence.jarも追加する必要があります。ここで、FEATURES_HOMEは、ノード・マネージャ・マシン上のfeaturesディレクトリ(通常、MW_HOME\modules\features)、COHERENCE_HOMEはCoherenceディレクトリ(通常、MW_HOME\coherence_3.6)です。クラスパスを指定しない場合、先出のクラスパスがデフォルトで使用されます。 |
管理コンソールを使用してキャッシュ・サーバーを起動する方法については、『Oracle Fusion Middleware Oracle WebLogic Serverの管理コンソール・オンライン・ヘルプ』の管理コンソールからのCoherenceサーバーの起動に関する項を参照してください。
例3-11で示されるstartCoh.py WLSTスクリプトは、スタンドアロンCoherenceサーバー(COH_server1)を起動します。
次のサンプル・コマンドを使用してWLSTを呼び出してスクリプトを実行します。
java weblogic.WLST d:/temp/startCoh.py
例3-11 startCoh.py
props = System.getProperties()
ADMIN_NAME = props.getProperty("admin.username")
if ADMIN_NAME == None: ADMIN_NAME = 'weblogic'
ADMIN_PASSWORD = props.getProperty("admin.password")
if ADMIN_PASSWORD == None : ADMIN_PASSWORD = 'welcome1'
ADMIN_HOST = props.getProperty("admin.host")
if ADMIN_HOST == None : ADMIN_HOST = 'localhost'
ADMIN_PORT = props.getProperty("admin.port")
if ADMIN_PORT == None : ADMIN_PORT = '7001'
ADMIN_URL = "t3://" + ADMIN_HOST + ":" + ADMIN_PORT
COH_SERVER = props.getProperty("server")
if COH_SERVER == None : COH_SERVER = 'COH_server1'
connect(ADMIN_NAME, ADMIN_PASSWORD, ADMIN_URL)
domainRuntime()
lifecycle = getMBean('/CoherenceServerLifeCycleRuntimes/' + COH_SERVER)
seconds = 5
print("starting: " + COH_SERVER);
print("before state:" + lifecycle.getState())
lifecycle.start()
print("after state:" + lifecycle.getState())
java.lang.Thread.sleep(seconds * 1000)
print("after state:" + lifecycle.getState())
disconnect()
例3-12で示すように、stopCoh.py WLSTスクリプトを使用し、同一のCoherenceキャッシュ・サーバーをシャットダウンできます。
例3-12 stopCoh.py
props = System.getProperties()
ADMIN_NAME = props.getProperty("admin.username")
if ADMIN_NAME == None: ADMIN_NAME = 'weblogic'
ADMIN_PASSWORD = props.getProperty("admin.password")
if ADMIN_PASSWORD == None : ADMIN_PASSWORD = 'welcome1'
ADMIN_HOST = props.getProperty("admin.host")
if ADMIN_HOST == None : ADMIN_HOST = 'localhost'
ADMIN_PORT = props.getProperty("admin.port")
if ADMIN_PORT == None : ADMIN_PORT = '7001'
ADMIN_URL = "t3://" + ADMIN_HOST + ":" + ADMIN_PORT
COH_SERVER = props.getProperty("server")
if COH_SERVER == None : COH_SERVER = 'COH_server1'
connect(ADMIN_NAME, ADMIN_PASSWORD, ADMIN_URL)
domainRuntime()
lifecycle = getMBean('/CoherenceServerLifeCycleRuntimes/' + COH_SERVER)
seconds = 5
print("forceShutdown: " + COH_SERVER);
lifecycle.forceShutdown()
print("after state:" + lifecycle.getState())
disconnect()
もう1つの方法として、WebLogic Server管理サーバーを使用せずにCoherenceキャッシュ・サーバーを起動するには、次の手順を実行します。
Coherenceキャッシュ・サーバーを起動するためのスクリプトを作成します。次に示す例は、ActiveCacheと共に使用するためにストレージが有効なキャッシュ・サーバーを起動するスクリプトの非常にシンプルな例です。この例では、Sun JVMを使用することを想定します。詳細は、『Oracle Coherence開発者ガイド』のJVMチューニングに関する項を参照してください。
java -server -Xms512m -Xmx512m -cp <Coherence installation dir>/lib/coherence.jar -Dtangosol.coherence.management.remote=true -Dtangosol.coherence.cacheconfig=WEB-INF/classes/cache_configuration_file-Dtangosol.coherence.session.localstorage=true com.tangosol.net.DefaultCacheServer
この例では、cache_configuration_fileは、coherence-cache-config.xmlファイル内のキャッシュ構成を参照します。キャッシュ・サーバーに定義されたキャッシュ構成は、同一のCoherenceクラスタ上で稼働するアプリケーション・サーバー用に定義された構成と同一にする必要があります。
前の手順で説明されたスクリプトを使用して、1つ以上のCoherenceキャッシュ・サーバーを起動します。
Coherenceキャッシュ・サーバーは、ライフサイクル情報(ステータス)をDOMAIN_HOME/servers_coherence/COHserver_name/data/nodemanager/COHserver_name.stateに書き込みます。ノード・マネージャは、当該ディレクトリ内にあるこのファイルとその他のファイルを監視し、キャッシュ・サーバーが稼働中かどうかを検出し、そのステータス(クリーン・シャットダウンによって、クラッシュや起動失敗とは異なる最終状態が生成される)に基づいて、再起動するかどうかを検出します。
また、ノード・マネージャを再起動する場合、CrashRecoveryEnabledプロパティの値も考慮します。この値は、weblogic.nodemanager.NodeManager起動コマンド内で指定するか、またはnodemanager.propertiesファイル内で定義できます。このファイルは、WL_HOME/common/nodemanagerの直下に配置され、WL_HOMEはWebLogic Serverをインストールした場所を示します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャとシステム・クラッシュのリカバリに関する項とノード・マネージャ・プロパティの確認に関する項参照してください。
|
注意: ノード・マネージャが実行されていない場合(ダウンしている場合またはまだ起動していない場合)、キャッシュ・サーバーは状態をunknownとして報告します。また、ノード・マネージャがサーバー起動にまったく使用されていない場合(初期作成時など)、キャッシュ・サーバーは状態をunknownとして報告します。これは、キャッシュ・サーバーのライフサイクル・ステータスが、DOMAIN_HOME/servers_coherence/COHserver_name/data/nodemanager/COHserver_name.stateファイルから情報を取得するノード・マネージャによってのみ決定されるためです。 |
Coherenceキャッシュ・サーバー・ログ・ファイルおよびサーバー固有のノード・マネージャ情報ファイルは、DOMAIN_HOME/servers_coherence/COHserver_name/の直下に配置されます。ここで、DOMAIN_HOMEは、d:/oracle/MW_HOME/user_projects/domains/domain_nameなどのWebLogic Serverドメインをインストールした場所を示し、COHserver_nameはCoherenceキャッシュ・サーバー名です。
WebLogic Serverでは、複数の方法でサーバー・インスタンスを起動および停止できます。どの方法を選ぶかは、管理コンソールとコマンド・ライン・インタフェースのどちらを使用するか、およびサーバーのライフサイクルの管理にノード・マネージャを使用するかどうかによって決まります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。クイック・リファレンスについては、「サーバーの起動と停止: クイック・リファレンス」を参照してください。
デフォルトでは、ActiveCacheを利用しているWebLogic Serverインスタンスは、ストレージが有効モードで起動します。WebLogic Serverインスタンスをストレージが有効モードで起動するには、コマンドライン・プロパティ-Dtangosol.coherence.session.localstorage=trueをサーバー起動コマンドにインクルードします。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド・ラインからサーバー・インスタンスを起動に関する項を参照してください。
WebLogic Server管理コンソールには、クラスタのサイズ、メンバー、およびバージョンなどの特定のアプリケーションまたはモジュールに関連付けられたCoherenceクラスタのランタイム監視情報が表示されます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの管理コンソール・オンライン・ヘルプ』のCoherenceクラスタのモニタリングに関する項を参照してください。
