| Oracle® Fusion Middleware Oracle Coherenceの管理 12c (12.2.1) E69908-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
スタンドアロンCoherenceアプリケーションは、異なるロールを実行する分散プロセスから構成されます。デプロイメントの場合、これらのプロセスをそのロールに基づいた層に論理的にグループ化すると有益な場合がありますが、これはデプロイメントの要件ではありません。最も一般的な層は、データ層、アプリケーション層、プロキシ層およびExtendクライアント層です。層により、共通のアーティファクト、パッケージ化およびスクリプトを定義して各層用に設定できるためデプロイメントが容易になります。
この項には次のトピックが含まれます:
データ層はキャッシュ・オブジェクトを格納するキャッシュ・サーバーから構成されます。Coherenceアプリケーションでは、データ層に任意の数のキャッシュ・サーバーが必要な場合があります。キャッシュ・サーバーの数は、キャッシュに予想されるデータの量と、そのデータをバックアップしてサーバー障害後も存続させる必要があるかどうかに依存します。各キャッシュ・サーバーがCoherenceクラスタ・メンバーで独自のJVMプロセスで稼働し、複数のキャッシュ・サーバーを1つの物理サーバー上で連結できます。アプリケーション用キャッシュ・サーバーの数の計画の詳細は、「キャッシュ・サイズ計算の推奨事項」および「ハードウェアの推奨事項」を参照してください。
キャッシュ・サーバーは、通常、com.tangosol.net.DefaultCacheServerクラスを使用して起動されます。このクラスにはmainメソッドが含まれ、コマンド行から起動されます。キャッシュ・サーバーの起動の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
次のアプリケーション・アーティファクトは、キャッシュ・サーバーでデプロイされることがあります。
オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。
POFシリアライザおよびドメイン・オブジェクト
問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。
イベント処理実装。
データ・ソースからオブジェクトをキャッシュする際のキャッシュ・ストアおよびローダー実装。
アプリケーション・アーティファクトをデータ層にパッケージ化する方法に制限はありません。ただし、アーティファクトはサーバーのクラスパスにあり、すべての構成ファイルがcoherence.jarライブラリの前にある必要があります(デフォルトの名前を使用している場合)。それ以外の場合、coherence.jarライブラリにあるデフォルトの構成ファイルがロードされます。次の例では、単一のキャッシュ・サーバーがAPPLICATION_HOME\configディレクトリにある構成ファイルを使用して起動し、APPLICATION_HOME\lib\myClassesライブラリにある実装クラスを使用します。
java -server -Xms4g -Xmx4g -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer
(オペレーション・オーバーライド・ファイルを変更せずに)構成オーバーライドをシステム・プロパティとして含める場合、javaコマンドに対して-D引数として含めることができます。便利な方法としてCOHERENCE_HOME\bin\cache-serverスクリプトを再利用して適宜変更できます。
GARデプロイメント
Coherenceアプリケーション・アーティファクトは、グリッド・アーカイブ(GAR)としてパッケージ化してDefaultCacheServerクラスでデプロイできます。GARは特定のディレクトリ構造に準拠し、アプリケーション・ディスクリプタを含みます。GARパッケージ化の詳細は、「Coherence GARモジュールの構築」を参照してください。手順はWebLogicサーバー・デプロイメントの一部として含まれていますが、DefaultCacheServerクラスでデプロイ中のGARにも適用できます。
次の例では、キャッシュ・サーバーを起動してMyGar.garファイルにパッケージ化されているアプリケーション・アーティファクトを使用します。デフォルト名(MyGAR)はアプリケーション名として使用され、クラスタ上のアプリケーションの有効範囲を提供します。
java -server -Xms4g -Xmx4g -cp APPLICATION_HOME\config;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer D:\example\MyGAR.gar
デフォルト名は引数として別の名前を指定することでオーバーライドできます。有効なDefaultCacheServer引数の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。アプリケーション・スコープの詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。
アプリケーション層は、キャッシュ操作を実行する任意の数のクライアントから構成されます。キャッシュ操作には、キャッシュへのオブジェクトのロード、キャッシュされたオブジェクトの使用、キャッシュされたデータの処理およびキャッシュ保守の実行などがあります。クライアントはCoherenceクラスタ・メンバーですが、データの格納は行いません。
次のアプリケーション・アーティファクトは、クライアントとともにデプロイされることがあります。
オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。
POFシリアライザおよびドメイン・オブジェクト
問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。
イベント処理実装。
データ・ソースからオブジェクトをキャッシュする際のキャッシュ・ストアおよびローダー実装。
アプリケーション・アーティファクトをアプリケーション層にパッケージ化する方法に制限はありません。クライアントでは、そのアプリケーションのクラスパスにCOHERENCE_HOME/lib/coherence.jarライブラリを含める必要があります。Coherence構成ファイルは、クラスパスに含まれcoherence.jarライブラリの前にある必要があります(デフォルトの名前を使用している場合)。それ以外の場合、coherence.jarライブラリにあるデフォルトの構成ファイルがロードされます。次の例では、クライアントがAPPLICATION_HOME\configディレクトリにある構成ファイルを使用して起動し、APPLICATION_HOME\lib\myClassesライブラリにある実装クラスを使用します。
java -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.MyApp
(オペレーション・オーバーライド・ファイルを変更せずに)システム・プロパティの構成オーバーライドを含める場合、javaコマンドに対して-D引数として含めることができます。たとえば、クライアントへの格納を無効にするには、tangosol.coherence.distributed.localstorageシステム・プロパティを次のように使用できます。
java -Dcoherence.distributed.localstorage=false -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.MyApp
注意:
キャッシュ・サーバーへのデプロイメントにGARが使用されている場合、キャッシュ・サービスはアプリケーション・スコープ名によって制限されます。クライアントは同じアプリケーション・スコープ名を使用する必要があります。それ以外の場合、クライアントはキャッシュ・サービスにアクセスできません。アプリケーション・スコープ名の指定の詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。
プロキシ層はExtendクライアントのリクエストを処理するプロキシ・サーバーから構成されます。プロキシ層では任意の数のプロキシ・サーバーが必要な場合があります。プロキシ・サーバーの数は、予想されるExtendクライアントの数および予想されるクライアントのリクエスト負荷に依存します。各プロキシ・サーバーがクラスタ・メンバーで独自のJVMプロセスを実行し、複数のプロキシ・サーバーを1つの物理サーバー上で連結できます。Extendクライアントの詳細およびプロキシの設定の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。
プロキシ・サーバーは、通常、com.tangosol.net.DefaultCacheServerクラスを使用して起動されます。このクラスにはmainメソッドが含まれ、コマンド行から起動されます。キャッシュ・サーバーの起動の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。プロキシ・サーバーとキャッシュ・サーバーとの違いは、プロキシ・サーバーはデータを格納しない点と、Extendクライアントのリクエストを処理するプロキシ・サービスをホストしないという点です。
次のアプリケーション・アーティファクトは、プロキシとともにデプロイされることがあります。
オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。
POFシリアライザおよびドメイン・オブジェクト。ExtendクライアントがC++または.NETを使用して実装されている場合、オブジェクトのJavaバージョンも特定のユース・ケース用にデプロイする必要があります。
問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。
イベント処理実装。
データ・ソースからオブジェクトをキャッシュする際のキャッシュ・ストアおよびローダー実装。
アプリケーション・アーティファクトをプロキシ層にパッケージ化する方法に制限はありません。ただし、アーティファクトはサーバーのクラスパスにあり、すべての構成ファイルがcoherence.jarライブラリの前にある必要があります。それ以外の場合、coherence.jarライブラリにあるデフォルトの構成ファイルがロードされます。次の例では、単一のプロキシ・サーバーがAPPLICATION_HOME\configディレクトリにある構成ファイルを使用して起動し、APPLICATION_HOME\lib\myClassesライブラリにある実装クラスを使用します。
java -server -Xms512m -Xmx512m -Dcoherence.distributed.localstorage=false -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer
GARデプロイメント
Coherenceアプリケーション・アーティファクトは、グリッド・アーカイブ(GAR)としてパッケージ化してDefaultCacheServerクラスでデプロイできます。GARは特定のディレクトリ構造に準拠し、アプリケーション・ディスクリプタを含みます。GARパッケージ化の詳細は、「Coherence GARモジュールの構築」を参照してください。手順はWebLogicサーバー・デプロイメントの一部として含まれていますが、DefaultCacheServerクラスでデプロイ中のGARにも適用できます。
次の例では、プロキシ・サーバーを起動してMyGar.garファイルにパッケージ化されているアプリケーション・アーティファクトを使用します。デフォルト名(MyGAR)はアプリケーション名として使用され、クラスタ上のアプリケーションの有効範囲を提供します。
java -server -Xms512m -Xmx512m -Dcoherence.distributed.localstorage=false -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer D:\example\MyGAR.gar
デフォルト名は引数として別の名前を指定することでオーバーライドできます。有効なDefaultCacheServer引数の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。アプリケーション・スコープの詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。
ExtendクライアントはJava、C++または.NETアプリケーションとして実装されます。また、RESTクライアントAPIを提供する任意のクライアント・テクノロジでCoherenceクラスタにキャッシング・サービスを使用できます。ExtendクライアントはCoherenceキャッシュを使用するアプリケーションですが、Coherenceクラスタのメンバーではありません。これらのクライアントに固有のデプロイメントの詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。
次のCoherenceアーティファクトは、Extendクライアントとともにデプロイされることがあります。
オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。
POFシリアライザおよびドメイン・オブジェクト。
問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。
イベント処理実装。
WebLogic Serverには、WebLogic Serverドメイン内にCoherenceアプリケーションをデプロイして管理できる方法を標準化するCoherence統合機能が含まれています。この統合機能により、管理者は使い慣れたWebLogic Serverコンポーネントとインフラストラクチャ(Java EEスタイルのパッケージ化とデプロイメント、リモート・サーバー管理、サーバー・クラスタ、WebLogic Scripting Tool (WLST)自動化や管理コンソールからの構成など)を使用して分散Coherence環境の設定ができます。
この項で説明する手順は、WebLogicサーバーについてある程度の知識があることを想定しています。また、WebLogicサーバー・ドメインが作成済であることを想定しています。すべての手順の説明では、WebLogic Server管理コンソールを使用します。WebLogic Server管理コンソールの使用の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。Coherenceクラスタの構成および管理の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。
この項には次のトピックが含まれます:
CoherenceはWebLogic Serverと統合されます。統合により、Coherenceクラスタ・メンバーのライフサイクルを、管理対象サーバーのライフサイクルに合せ、つまり、サーバーJVMの開始と終了に合せてCoherenceクラスタ・メンバーを開始および終了することになります。クラスタの最初のメンバーがクラスタ・サービスを開始し、シニア・メンバーになります。
その他のJava EEモジュールと同様に、Coherenceは、グリッド・アーカイブ(GAR)という独自のアプリケーション・モジュールをサポートします。GARには、Coherenceアプリケーションのアーティファクトが格納され、デプロイメント・ディスクリプタが含まれています。GARは、その他のJava EEモジュールと同じ方法でデプロイおよびアンデプロイするため、クラスタ・サービス・ライフタイムから分離されます。Coherenceアプリケーションは、サービスの名前空間ごと、およびクラス・ローダーごとに分離されます。
Coherenceは、通常、Weblogic Serverドメイン内への機能的分離を提供する層に設定されます。最も一般的な層は、データをキャッシングするためのデータ層およびキャッシュされたデータを使用するためのアプリケーション層です。プロキシ・サーバー層およびExtendクライアント層は、Coherence*Extendを使用する際に設定する必要があります。HTTPセッション層は、Coherence*Webを使用する際に設定する必要があります。Coherence*WebのデプロイおよびHTTPセッション・データの管理の手順は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。
Coherenceクラスタに関連付けられたWebLogic管理対象サーバーは、管理対象Coherenceサーバーと呼ばれます。各層内の管理対象Coherenceサーバーは個別に管理することもできますが、通常はそれぞれのWebLogicサーバー・クラスタに関連付けられます。GARは、データ層サーバーおよびプロキシ層サーバーごとにデプロイする必要があります。その後で、同一のGARは1つのEAR内にパッケージ化し、それぞれのアプリケーションおよびExtendクライアント層サーバーにデプロイします。クライアント層とは別の専用の記憶域層を使用することが、最適なパフォーマンスを実現するためのベスト・プラクティスになります。
Coherenceアプリケーションは、GARモジュールとしてデプロイメントするためにパッケージ化する必要があります。GARモジュールは、Coherenceアプリケーションから成るアーティファクトを含み、特定のディレクトリ構造を保持します。GARは、アーカイブ化解除されたディレクトリとして残すことも、.gar拡張子を付けてアーカイブ化することもできます。GARは、スタンドアロン・モジュールとしてデプロイするか、EAR内にデプロイします。EARは複数のGARモジュールを含むことができません。
CoherenceはWebLogic Serverドメインの各種ドメイン・トポロジをサポートすることで、様々なレベルのパフォーマンス、スケーラビリティおよび使いやすさを実現します。たとえば、開発時には単一の管理対象Coherenceサーバー・インスタンスを、キャッシュ・サーバーとしても、キャッシュ・クライアントとしても使用できます。単一サーバー・トポロジは、設定と使用が容易ですが、最適なパフォーマンスまたはスケーラビリティを提供しません。本番の場合、Coherenceは、通常、WebLogic Serverクラスタを使用して設定します。1つのWebLogic Serverクラスタが、Coherenceデータ層として使用され、1つ以上のキャッシュ・サーバーをホストします。Coherenceアプリケーション層には別のWebLogic Serverクラスタが使用され、1つ以上のキャッシュ・クライアントをホストします。そして、(必要な場合) 1つ以上の管理対象Coherenceプロキシ・サーバーをホストするCoherenceプロキシ層、および拡張クライアントをホストするCoherence拡張クライアント層には、さらに別のWebLogic Serverクラスタが使用されます。階層型トポロジのアプローチにより、最適なスケーラビリティとパフォーマンスが提供されます。ドメイン・トポロジは、常にアプリケーションの要件に基づいている必要があります。
Coherence用のドメイン・トポロジを作成する際には、次のガイドラインを使用してください。
ドメインは、通常、単一のCoherenceクラスタを含んでいます。
1つのCoherenceクラスタには、複数のWebLogic Serverクラスタを関連付けることができます。
Coherenceクラスタに関連付けられた管理対象サーバーは、管理対象Coherenceサーバーとみなされ、Coherenceクラスタ・メンバーと同じになります。
別の管理対象Coherenceサーバー・インスタンス(可能ならば別のWebLogic Serverクラスタ)を使用して、Coherenceのキャッシュ・サーバーとクライアントを分離します。
WebLogic Serverドメイン内で管理されるCoherenceメンバーは、スタンドアロンのJVMメンバーで構成される外部のCoherenceクラスタに参加してはいけません。スタンドアロンのJVMクラスタ・メンバーを、WebLogic Serverドメイン内で管理することはできません。
WLSドメインにCoherenceを設定する際に優先されるアプローチでは、Coherenceキャッシュのサーバー、クライアントおよびプロキシを、同一のCoherenceクラスタに関連付けられた別々の層に分割します。一般に、各層は管理対象Coherenceサーバーの独自のWebLogic Serverクラスタに関連付けられます。ただし、1つの層が複数のスタンドアロン管理対象Coherenceサーバーから構成されていることもあります。前者のアプローチを使用すると、Coherenceの管理とスケールは最も簡単になります。これは、管理対象CoherenceサーバーはWebLogic ServerクラスタのCoherence設定を継承してデプロイメントできるためです。この項の手順を使用して、データ層、アプリケーション層およびプロキシ層に個別のWebLogic Serverクラスタを作成します。WebLogic Serverクラスタ作成の詳細な手順は、Oracle WebLogic Serverのクラスタ管理を参照してください。
Coherenceデプロイメント層を作成するには:
Coherenceクラスタに関連付けられた管理対象サーバーは、Coherenceクラスタのメンバーになり、管理対象Coherenceサーバーと呼ばれます。この項の手順を使用して、管理対象サーバーを作成し、そのサーバーをWebLogic Serverクラスタに関連付けます。このクラスタは、Coherenceデプロイメント層として構成します。管理対象サーバーは、WebLogic ServerクラスタからCoherence設定を自動的に継承します。同様に、既存の管理対象CoherenceサーバーもWebLogic Serverクラスタに関連付けできます。管理対象サーバーの作成手順および構成手順の詳細は、Oracle WebLogic Server管理コンソール・オンラン・ヘルプを参照してください。
Coherenceデプロイメント層用の管理対象サーバーを作成するには:
各Coherenceデプロイメント層には、Coherenceアプリケーション・モジュールを含める必要があります。アプリケーション・モジュールのデプロイで、GARのキャッシュ構成ファイルに定義されたサービスが開始します。Coherenceアプリケーションをパッケージ化する方法の詳細は、「WebLogic Server用のCoherenceアプリケーションのパッケージ化」を参照してください。コンソールを使用してアプリケーションをデプロイする方法の詳細は、WebLogic Server管理コンソール・ヘルプを参照してください。
Coherenceモジュールは、次のようにデプロイします。
データ層(キャッシュ・サーバー): スタンドアロンのGARをデータ層の各管理対象Coherenceサーバーにデプロイします。データ層がWebLogic Serverクラスタとして設定されている場合、GARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象Coherenceサーバーにモジュールがコピーされます。
アプリケーション層(キャッシュ・クライアント): GARおよびクライアント実装(WebアプリケーションやEJBなど)を格納するEARをクラスタ内の各管理対象Coherenceサーバーにデプロイします。アプリケーション層がWebLogic Serverクラスタとして設定されている場合、EARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象Coherenceサーバーにモジュールがコピーされます。
プロキシ層(プロキシ・サーバー): スタンドアロンのGARをプロキシ層の各管理対象Coherenceサーバーにデプロイします。プロキシ層がWebLogic Serverクラスタとして設定されている場合、GARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象Coherenceサーバーにモジュールがコピーされます。
注意:
プロキシ層の管理対象Coherenceサーバーには、キャッシュ構成ファイルにプロキシ・サービスの定義が含まれている必要があります。同じGARを各層にデプロイしてから、クラスタレベル・キャッシュ構成ファイルを使用してプロキシ層サーバーのみのキャッシュ構成ファイルをオーバーライドできます。クラスタレベル・キャッシュの指定の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。
Extendクライアント層(Extendクライアント) – GARおよびExtendクライアント実装を含むEARが、Extendクライアントをホストする各管理対象サーバーにデプロイされます。Extendクライアント層がWebLogic Serverクラスタとして設定されている場合、EARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象サーバーにモジュールがコピーされます。
注意:
Extend層の管理対象サーバーには、キャッシュ構成ファイルにリモート・キャッシュ・サービスの定義が含まれている必要があります。同じGARを各層にデプロイしてから、クラスタレベル・キャッシュ構成ファイルを使用してExtend層サーバーのみのキャッシュ構成ファイルをオーバーライドできます。クラスタレベル・キャッシュの指定の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。
データ層にGARをデプロイするには:
アプリケーション層にEARをデプロイするには:
プロキシ層にGARをデプロイするには:
管理者は、WebLogic Serverツールを使用して、WebLogicドメイン内のCoherence環境を管理します。これらのツールを使用すると、クラスタやクラスタ・メンバーの管理タスクが簡単になります。この項では、基本的な管理タスクを実行するために、管理コンソール・ツールを使用する方法の概要について説明します。これらのタスクを完了する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。WebLogic Scripting Tool (WLST)の使用の詳細は、『WebLogic Scripting Toolの理解』を参照してください。
表1-1 管理コンソールでの基本的な管理タスク
| 目的 | 使用対象 |
|---|---|
Coherenceクラスタの作成 |
「Coherenceクラスタ」ページ |
クラスタ・メンバーの追加または削除、またはCoherenceクラスタからのWebLogic Serverクラスタの追加または削除 |
Coherenceクラスタの「設定」ページにある「メンバー」タブ。 |
Coherenceクラスタのユニキャスト設定またはマルチキャスト設定の構成 |
Coherenceクラスタの「設定」ページにある「一般」タブ。ユニキャストを選択した場合、デフォルトのウェル・ノウン・アドレス構成は、「Well Knownアドレス」タブを使用してオーバーライドできます。 |
Coherenceクラスタを構成するためのカスタム構成ファイルの使用 |
Coherenceクラスタの「設定」ページにある「一般」タブ |
クラスタ・メンバーへのキャッシュ構成ファイルのインポート、およびGARにデプロイしたキャッシュ構成ファイルのオーバライド |
Coherenceクラスタの「設定」ページにある「構成」タブ |
ロギングの構成 |
Coherenceクラスタの「設定」ページにある「ロギング」タブ |
Coherenceクラスタへの管理対象サーバーの割当て |
管理対象サーバーの「設定」ページにある「Coherence」タブ |
Coherenceクラスタ・メンバーのプロパティの構成 |
管理対象サーバーの「設定」ページにある「Coherence」タブ |
WebLogic ServerクラスタとCoherenceクラスタとの関連付け、およびクラスタの管理対象Coherenceサーバーの記憶域の有効化または無効化 |
WebLogic Serverクラスタの「設定」ページにある「Coherence」タブ |
Coherenceクラスタに関連付けられたWebLogic Serverクラスタへの管理対象サーバーの割当て |
管理対象サーバーの「設定」ページにある「一般」タブ |
WebLogic Server以外のアプリケーション・サーバーにデプロイされるJava EEアプリケーションには、Coherenceをデプロイするための2つのオプション(アプリケーション・サーバー・ライブラリとして、またはJava EEモジュールの一部としてデプロイ)があります。Coherenceクラスタのメンバーにはクラス・ローダーのスコープが設定されています。そのため、オプションの選択によってデプロイメント・シナリオが異なります。Coherenceがアプリケーション・サーバー・ライブラリとしてデプロイされている場合、すべてのモジュールは単一のクラスタ・メンバーを共有します。その一方で、Coherenceがモジュールの一部としてデプロイされている場合、Java EEモジュールは、そのモジュール自体がクラスタ・メンバーになります。どちらのオプションにも利点と前提条件があり、一般的にクラスタ・メンバーが他のモジュールから分離されている程度とリソース利用率とのバランスが取られます。
注意:
Coherence*WebのデプロイおよびHTTPセッション・データのクラスタリングの手順は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。
Coherenceをアプリケーション・サーバー・ライブラリとしてデプロイできます。このデプロイメント・シナリオでは、アプリケーション・サーバーの起動クラスパスをCOHERENCE_HOME/lib/coherence.jarライブラリが含まれるように変更します。また、キャッシュに配置するオブジェクトはすべて、サーバーのクラスパスで使用できる必要があります。ライブラリをサーバーのクラスパスに追加する手順は、アプリケーション・サーバーのベンダーのドキュメントを参照してください。
このシナリオでは、サーバーのコンテナにデプロイされたすべてのアプリケーションで1つのクラスタ・メンバーを共有するようになります。このシナリオでは、Coherenceクラスの1つのコピーのみがJVMにロードされるため、リソース使用率が最小限に抑えられます。このデプロイメント・スタイルを選択したときに、Coherenceアプリケーションを相互に分離する手順の詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。
CoherenceをEARファイルまたはWARファイル内にデプロイできます。一般に、このデプロイメント・スタイルは、アプリケーション・サーバーの実行時環境に変更を加える必要がなく、クラスタ・メンバーはEARまたはWARのどちらかに分離されているため、優先的に選択されます。
CoherenceをEARの一部としてデプロイできます。このデプロイメント・シナリオでは、EAR内のすべてのWebアプリケーションで1つのクラスタ・メンバーを共有することになります。EARごとにCoherenceクラスのコピーが1つのみロードされるため、リソース使用率は中程度になります。ただし、クラスタ・メンバーによる、いずれか1つのモジュールの使用が、すべてのWebアプリケーションに影響を与える可能性があります。Coherenceアプリケーションを相互に分離する手順の詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。
Coherenceをエンタープライズ・アプリケーション内にデプロイする手順は次のとおりです。
CoherenceをWebアプリケーションの一部としてデプロイできます。このデプロイメント・シナリオでは、それぞれのWebアプリケーションが固有のクラスタ・メンバーを持ち、他のすべてのWebアプリケーションから分離されるようになります。このシナリオでは、Coherenceを含むWebアプリケーションがデプロイされる数と同じ数のCoherenceクラスのコピーがロードされるため、リソースを最も大量に使用します。このシナリオは、1つのアプリケーション・サーバーに数個のWebアプリケーションのみをデプロイする場合に適しています。
CoherenceをWebアプリケーション内にデプロイする手順は次のとおりです。
WEB-INF/libディレクトリにcoherence.jarライブラリをコピーします。WEB-INF/libディレクトリまたはWEB-INF/classesディレクトリに配置されていることを確認します。 Coherenceは、独自のCoherenceキャッシュとサーバーのセットを定義すれば、複数のアプリケーションが同一のクラスタを使用する共有環境にデプロイできます。このようなシナリオの場合、各アプリケーションは、スコープ名を含む独自のキャッシュ構成ファイルを使用します。このスコープ名によって、アプリケーション間でキャッシュとサービスを共有できるようにするかどうかを制御します。
この項の内容は、次のとおりです。
<scope-name>要素を使用して、キャッシュ構成ファイル内でキャッシュとサービスを一意に特定するサービスの名前空間を指定します。これが指定されていると、すべてのキャッシュとサービスは分離され、同一クラスタで実行する他のアプリケーションからは使用できなくなります。
次の例では、accountsというスコープ名を構成します。これにより、その構成に基づいて作成されたConfigurableCacheFactoryインスタンスでインスタンス化されるすべてのサービスは、接頭辞としてaccountsを使用するようになります。スコープ名は、キャッシュ・ファクトリ・インスタンスの属性であり、キャッシュ・ファクトリのインスタンスにのみ影響します。
注意:
この接頭辞は、サービス名にのみ使用します。キャッシュ名には使用しません。
<?xml version='1.0'?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<scope-name>accounts</scope-name>
</defaults>
<caching-scheme-mapping>
...
WebLogic Serverにデプロイするときには、デプロイされた複数のCoherenceアプリケーション(GAR)が、サービスの名前空間ごと、およびデフォルトのClassLoaderごとにWebLogic Server内で分離されるため、スコープ名の構成は必要ありません。ただし、スコープ名はGAR間でキャッシュを共有するために構成することもできます。キャッシュ構成ファイルでのスコープの直接構成は、通常、上級ユーザー・ケースで実行されます。
デプロイメント名は、GARのデプロイ時にデフォルトのスコープ名として使用されます。デプロイメント名がデプロイ中に指定されない場合、アーティファクト名がデプロイメント名として使用されます。たとえば、MyApp.garモジュールの場合、デフォルトのデプロイメント名はMyAppです。EARにパッケージ化されたGARの場合、デプロイメント名はweblogic-application.xmlファイルのGARに指定されたモジュール名です。
アプリケーション・サーバー・ライブラリまたはEARの一部としてCoherenceをデプロイすると、複数のアプリケーションが単一のクラスタ・メンバー(1つのJVM)として同一のクラスタを使用できます。このようなデプロイメント・シナリオでは、複数のアプリケーションが、単一のcoherence-cache-config.xmlファイルで構成された1つのCoherenceのキャッシュとサービスのセットを使用することを選択できます。このタイプのデプロイメントは、アプリケーションのデプロイメントが調整された制御環境においてのみお薦めします(また、その場合にのみ実用的になります)。キャッシュ間、サービス間およびその他の構成設定間で衝突する可能性が高く、想定外の結果を招くことがあります。さらに、Coherenceノードの1つのアプリケーションの使用が、すべてのアプリケーションに影響を及ぼす可能性もあります。
別の方法として、各アプリケーションに独自のキャッシュ構成ファイルを含めるようにします。この構成ファイルでは、そのアプリケーションに固有のキャッシュとサービスを定義します。この構成は、キャッシュ構成ファイル内の<scope-name>要素を使用して指定したスコープ名で分離されます。同様に、アプリケーションは、その他のアプリケーションが必要とするときにはキャッシュとサービスの共有を明示的に許可できます。このシナリオでは、それぞれが1つのアプリケーションに関連する複数のConfigurableCacheFactoryインスタンスが、1つのJVMに含まれていることを想定しています。
次の例では、2つのWebアプリケーション(trade.warおよびaccounts.war)を分離するために必要な手順を示します。これにより、それぞれのアプリケーションのキャッシュとサービスを相互に使用しないようにします。
単一のCoherenceクラスタを使用するスタンドアロン・アプリケーションには独自のキャッシュ構成ファイルを含めることができますが、これらの構成は単一のConfigurableCacheFactoryに結合されます。ConfigurableCacheFactoryとDefaultCacheServerの間には1対1の関係があるため、単一のクラスタ・ノード内でアプリケーションのスコープを設定できません。そのかわりに、DefaultCacheServerの1つ以上のインスタンスはキャッシュ構成ごとに開始される必要があり、各キャッシュ構成にスコープ名を含める必要があります。
次の例では、2つのアプリケーション(tradeおよびaccounts)を分離します。これにより、それぞれのアプリケーションが相互のキャッシュとサービスを使用しないようにします。
注意:
アプリケーション間でデータを共有する場合、それらのアプリケーションは同一のキャッシュ構成ファイルを使用する必要があります。Coherenceでは、同一のスコープ名を指定する複数のキャッシュ構成の使用をサポートしていません。
com.tangosol.net.ScopeResolverインタフェースを使用すると、コンテナとアプリケーションが実行時に特定のConfigurableCacheFactoryのスコープ名を変更して、アプリケーション間の分離を強制(または無効化)できるようになります。ScopeResolverインタフェースを実装し、必要に応じてカスタム機能に追加します。
カスタム・スコープ・リゾルバを有効にするには、<cache-factory-builder-config>ノード内の<scope-resolver>要素を使用して、実装クラスの完全修飾名をオペレーション・オーバライド・ファイルに定義する必要があります。次に例を示します。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cache-factory-builder-config>
<scope-resolver>
<class-name>package.MyScopeResolver</class-name>
</scope-resolver>
</cache-factory-builder-config>
<coherence>
<instance>要素で、<class-factory-name>要素および<method-name>要素を指定することもできます。前者の要素は、ScopeResolverインスタンスを作成するファクトリ・クラスを使用します。後者の要素は、オブジェクトをインスタンス化するファクトリ・クラスに対して静的なファクトリ・メソッドを指定します。次の例では、MyScopeResolverFactoryクラスのgetResolverメソッドを使用して、カスタム・スコープ・リゾルバのインスタンスを取得しています。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cache-factory-builder-config>
<scope-resolver>
<class-factory-name>package.MyScopeReolverFactory</class-factory-name>
<method-name>getResolver</method-name>
</scope-resolver>
</cache-factory-builder-config>
<coherence>
実装に必要な初期化パラメータはすべて、<init-params>要素を使用して指定できます。次の例では、isDeployedパラメータにtrueを設定しています。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cache-factory-builder-config>
<scope-resolver>
<class-name>package.MyScopeResolver</class-name>
<init-params>
<init-param>
<param-name>isDeployed</param-name>
<param-value>true</param-value>
</init-param>
</init-params>
</scope-resolver>
</cache-factory-builder-config>
<coherence>
