12 Coherenceクラスタの構成と管理
Oracle WebLogic ServerドメインでOracle Coherenceクラスタを定義する手順、およびCoherenceクラスタを複数のOracle WebLogic Serverクラスタに関連付ける方法を学習します。
この章の内容は次のとおりです。
- Coherenceクラスタの概要
Coherenceクラスタは、アプリケーションのスケーラビリティ、可用性およびパフォーマンスを向上させるためにデータをメモリー内に分散する、複数の管理対象Coherenceサーバー・インスタンスで構成されています。アプリケーションは、ローカル・キャッシュ内のデータと相互作用し、データの分散とバックアップは、クラスタ・メンバー間で自動的に実行されます。 - Coherenceクラスタの設定
WebLogic Serverドメインには通常、単一のCoherenceクラスタが含まれます。クラスタは、単一のシステムレベル・リソース(CoherenceClusterSystemResource)
として表されます。CoherenceClusterSystemResource
インスタンスは、WebLogic Server管理コンソールまたはWLSTを使用して作成されます。 - Coherenceデプロイメント層の作成
Coherenceは、WebLogic Serverドメイン内で複数のトポロジをサポートしており、それにより、様々なレベルのパフォーマンス、スケーラビリティおよび使いやすさが提供されます。 - Coherenceクラスタの構成
Coherenceクラスタ・リソースは、特定のドメイン用に構成可能ないくつかのクラスタ設定を公開します。 - 管理対象Coherenceサーバーの構成
管理対象Coherenceサーバーは、特定のドメイン用に構成可能ないくつかのクラスタ・メンバー設定を公開します。 - 単一サーバー・クラスタの使用
単一サーバー・クラスタは、単一の管理対象サーバー・インスタンス上で実行するように制限されている、ネットワークにアクセスしないクラスタです。 - CoherenceでのWLSTの使用
WLSTは、Coherenceクラスタの構成と管理などのドメイン構成タスクの自動化に使用できるコマンド行インタフェースです。 - WLSTを使用したCoherence MBeanへのアクセス
管理対象Coherenceサーバー環境のWebLogic Server内でCoherenceを実行すると、WebLogic ServerドメインのランタイムMBeanサーバーにより管理プロキシからJMX情報が収集され、この情報にはWLSTを使用してアクセスできます。 - WLSTによるCoherenceキャッシュの保持
WLSTには、ディスクのキャッシュ済データの保持と回復に使用できる一連のコマンドがあります。コマンドは、管理サーバー・ドメインのランタイムMBeanサーバーに接続されている場合に自動で利用できます。
Coherenceクラスタの概要
Coherenceクラスタは、アプリケーションのスケーラビリティ、可用性およびパフォーマンスを向上させるためにデータをメモリー内に分散する、複数の管理対象Coherenceサーバー・インスタンスで構成されています。アプリケーションは、ローカル・キャッシュ内のデータと相互作用し、データの分散とバックアップは、クラスタ・メンバー間で自動的に実行されます。
Coherenceクラスタは、WebLogic Serverクラスタとは異なります。これらのクラスタは、別のクラスタリング・プロトコルを使用し、別々に構成されます。複数のWebLogic ServerクラスタをCoherenceクラスタに関連付けることができ、WebLogic Serverドメインには通常、単一のCoherenceクラスタが含まれます。Coherenceクラスタ・メンバーとして構成されている管理対象サーバーは、管理対象Coherenceサーバーと呼ばれます。
管理対象Coherenceサーバーは、Coherenceクラスタに明示的に関連付けることができます。または、Coherenceクラスタに関連付けられているWebLogic Serverクラスタに関連付けることも可能です。管理対象Coherenceサーバーは通常、タイプに基づいた層(データを格納する場合はデータ層、アプリケーションをホストする場合はアプリケーション層、および外部クライアントがキャッシュにアクセスできるようにするにはプロキシ層)で設定されます。
図12-1に、WebLogic Serverドメイン内のCoherenceクラスタの概念を示します。
親トピック: Coherenceクラスタの構成と管理
Coherenceクラスタの設定
WebLogic Serverドメインには通常、単一のCoherenceクラスタが含まれます。クラスタは、単一のシステムレベル・リソース(CoherenceClusterSystemResource)
として表されます。CoherenceClusterSystemResource
インスタンスは、WebLogic Server管理コンソールまたはWLSTを使用して作成されます。
Coherenceクラスタには、任意の数の管理対象Coherenceサーバーを含めることができます。サーバーは、スタンドアロンの管理対象サーバーでも、Coherenceクラスタに関連付けられているWebLogic Serverクラスタのメンバーでもかまいません。通常、Coherenceクラスタには、複数のWebLogic Serverクラスタが関連付けられています。Coherenceが使用するWebLogic Serverクラスタの作成の詳細は、「Coherenceデプロイメント層の作成」を参照してください
ノート:
管理対象Coherenceサーバーをクローニングしても、Coherenceクラスタへの関連付けはクローニングされません。管理対象サーバーは、Coherenceクラスタのメンバーにはなりません。クローニングされた管理対象サーバーをCoherenceクラスタに手動で関連付ける必要があります。
Coherenceクラスタ・リソースの定義
Coherenceクラスタ・リソースを定義するには:
- WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「Coherenceクラスタ」をクリックします。
- 「Coherenceクラスタのサマリー」ページで、「新規」をクリックします。
- 「Coherenceクラスタ構成の作成」ページの「名前」フィールドに、クラスタの名前を入力し、「次」をクリックします。
- 「Coherenceクラスタのアドレス指定」セクションで、クラスタリング・モードを選択するか、デフォルトの設定のままにします。ほとんどのクラスタの場合、デフォルトのクラスタ・リスニング・ポート(7574)を変更する必要はありません。クラスタリング・モードの構成の詳細は、「クラスタ通信の構成」を参照してください
- 「Coherenceクラスタ・メンバー」セクションで、Coherenceクラスタのメンバーとする管理対象CoherenceサーバーまたはWebLogic Serverクラスタをクリックして選択します。管理対象CoherenceサーバーおよびWebLogicクラスタがまだ定義されていない場合は、このセクションをスキップします。
- 「終了」をクリックします。「Coherenceクラスタのサマリー」画面が表示され、「Coherenceクラスタ」表にクラスタ・リソースが示されます。
親トピック: Coherenceクラスタの設定
スタンドアロンの管理対象Coherenceサーバーの作成
管理対象Coherenceサーバーは、Coherenceクラスタに関連付けられている管理対象サーバー・インスタンスです。管理対象Coherenceサーバーは、全体でCoherenceクラスタを形成し、多くの場合、クラスタ・メンバーと呼ばれます。クラスタ・メンバーには年功序列があり、古参のメンバーがクラスタ・タスク(クラスタ・ハート・ビートの発行など)を実行します。
ノート:
-
管理対象Coherenceサーバーおよび(WebLogic Serverドメイン内で管理されていない)スタンドアロンのCoherenceクラスタ・メンバーが、同じクラスタに参加できます。ただし、スタンドアロンのクラスタ・メンバーはWebLogic Serverドメイン内からは管理できません。操作構成およびアプリケーション・ライフサイクルは手動で管理およびモニターする必要があります。
-
スタンドアロンのCoherenceクラスタ・メンバーは、WebLogic Serverドメインで管理されているCoherenceクラスタに参加する際には、Well Knownアドレス(WKA)を使用するように構成する必要があります。
-
管理サーバーは通常、本番環境では管理対象Coherenceサーバーとしては使用されません。
管理対象Coherenceサーバーは、クラスタにおけるそれぞれのロールによって区別されます。ベスト・プラクティスは、クラスタ・ロールごとに異なる管理対象サーバー・インスタンス(およびできれば異なるWebLogic Serverクラスタ)を使用することです。
-
ストレージが有効: クラスタへのデータの格納を行う管理対象Coherenceサーバー。Coherenceアプリケーションは、グリッド・アーカイブ(GAR)としてパッケージ化され、ストレージが有効な管理対象Coherenceサーバーにデプロイされます。
-
ストレージが無効: クラスタへのデータの格納を行わず、Coherenceアプリケーション(キャッシュ・クライアント)のホストに使用される管理対象Coherenceサーバー。CoherenceアプリケーションGARは、エンタープライズ・アーカイブ(EAR)内にパッケージ化され、ストレージが無効な管理対象Coherenceサーバーにデプロイされます。
-
プロキシ: ストレージが無効であり、かつ外部クライアント(非クラスタ・メンバー)によるキャッシュの使用を許可する管理対象Coherenceサーバー。CoherenceアプリケーションGARは、管理対象Coherenceプロキシ・サーバーにデプロイされます。
管理対象Coherenceサーバーを作成するには:
- WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。
- 「新規」をクリックして、新しい管理対象サーバーを作成します。
- 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。
- このサーバーをWebLogic Serverクラスタのメンバーとするかどうかを選択します。Coherenceデプロイメント層として使用するWebLogic Serverクラスタの作成の詳細は、「Coherenceデプロイメント層の作成」を参照してください
- 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。
- 新しいサーバーを選択して、その設定を構成します。
- 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこの管理対象サーバーに関連付けます。デフォルトでは、管理対象サーバーは、「ローカル記憶域有効」フィールドに示されているとおり、ストレージが有効なCoherenceメンバーです。管理対象Coherence設定の変更の詳細は、「管理対象Coherenceサーバーの構成」を参照してください
- 「保存」をクリックします。「サーバーのサマリー」ページが表示されます。
- 「サーバーのサマリー」ページで、「制御」タブをクリックし、サーバーを起動します。
親トピック: Coherenceクラスタの設定
Coherenceデプロイメント層の作成
Coherenceは、WebLogic Serverドメイン内で複数のトポロジをサポートしており、それにより、様々なレベルのパフォーマンス、スケーラビリティおよび使いやすさが提供されます。
たとえば、開発時、単一のスタンドアロンの管理対象サーバー・インスタンスを、キャッシュ・サーバーとキャッシュ・クライアントの両方として使用できます。単一サーバー・トポロジは、設定と使用が容易ですが、最適なパフォーマンスまたはスケーラビリティを提供しません。本番では、Coherenceは通常、WebLogic Serverクラスタを使用して設定されます。1つのWebLogic Serverクラスタが、Coherenceデータ層として使用され、1つ以上のキャッシュ・サーバーをホストします。Coherenceアプリケーション層には別のWebLogic Serverクラスタが使用され、1つ以上のキャッシュ・クライアントをホストします。そして、(必要な場合) 1つ以上の管理対象Coherenceプロキシ・サーバーをホストするCoherenceプロキシ層、および拡張クライアントをホストするCoherence拡張クライアント層には、さらに別のWebLogic Serverクラスタが使用されます。階層型トポロジのアプローチにより、最適なスケーラビリティとパフォーマンスが提供されます。
この項の手順では、WebLogic Server管理コンソールのクラスタ設定ページとサーバー設定ページの両方を使用して、Coherenceデプロイメント層を作成します。WebLogic Serverクラスタおよび管理対象サーバー・インスタンスは、それぞれClusterMBean
およびServerMBean
を使用してCoherenceクラスタ・リソースに関連付けることができます。WebLogic Serverクラスタに関連付けられている管理対象サーバーは、クラスタのCoherence設定を継承します。ただし、設定はサーバー設定ページに反映されない場合があります。
Coherenceデータ層の構成と管理
Coherenceデータ層は、Coherenceクラスタに関連付けられているWebLogic Serverクラスタであり、ストレージが有効な任意の数の管理対象Coherenceサーバーをホストします。データ層内の管理対象Coherenceサーバーは、クラスタに(プライマリとバックアップの両方の)データを格納および分散します。データ層で必要な管理対象Coherenceサーバーの数は、Coherenceクラスタ内に格納されるデータの予想量および各サーバーで使用可能なメモリー量によって異なります。さらに、コンピュータの障害の際にデータが失われる可能性を回避するために、クラスタには、少なくとも4台の物理コンピュータが含まれている必要があります。
Coherenceアーティファクト(Coherence構成ファイル、POFシリアライゼーション・クラス、フィルタ、エントリ・プロセッサ、Aggregatorなど)は、GARとしてパッケージ化され、データ層にデプロイされます。Coherenceアプリケーションのパッケージ化とデプロイの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。キャッシュ・サイズの計算およびハードウェア要件の詳細は、『Oracle Coherenceの管理』の本番環境に移行する際のチェックリストを参照してください。
Coherenceデータ層の作成
Coherenceデータ層を作成するには:
- WebLogic Serverクラスタを作成します。「WebLogicクラスタの設定」を参照してください。
- 「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。
- 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。デフォルトでは、このWebLogic Serverクラスタに割り当てられる管理対象サーバーは、「ローカル記憶域有効」フィールドに示されているとおり、ストレージが有効なCoherenceメンバーになります。
- HTTPセッション・レプリケーションにCoherenceを使用している場合は、「Coherence Webローカル記憶域有効」または「Coherence Webフェデレーテッド記憶域有効」オプションのどちらかを選択してセッション・レプリケーションを有効にします。フェデレーテッド記憶域オプションを選択すると、構成されているデフォルトのフェデレーション・トポロジが使用されます。フェデレーションの構成の詳細は、キャッシュ・フェデレーションの構成を参照してください。
親トピック: Coherenceデータ層の構成と管理
データ層の管理対象Coherenceサーバーの作成
Coherenceデータ層の管理対象サーバーを作成するには:
- WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。
- 「新規」をクリックして、新しい管理対象サーバーを作成します。
- 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。
- サーバーを既存のクラスタに追加する場合は「はい」オプションをクリックし、ドロップダウン・リストでデータ層WebLogic Serverクラスタを選択します。管理対象サーバーは、WebLogic Serverクラスタのデータ層からCoherence設定を継承します。
- 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。
- これらのステップを繰り返して、必要に応じて追加の管理対象サーバーを作成します。
- 「制御」タブで、起動するサーバーを選択し、「起動」をクリックします。
親トピック: Coherenceデータ層の構成と管理
Coherenceアプリケーション層の構成と管理
Coherenceアプリケーション層は、Coherenceクラスタに関連付けられているWebLogic Serverクラスタであり、ストレージが無効な任意の数の管理対象Coherenceサーバーをホストします。アプリケーション層内の管理対象Coherenceサーバーは、Coherenceクラスタ・メンバーであり、アプリケーション(キャッシュ・ファクトリ・クライアント)をホストします。異なるアプリケーションに対して複数のアプリケーション層を作成できます。
アプリケーション層内のクライアントは、EARとしてデプロイされ、サーブレット、JSP、EJBなどのJava EE標準を使用して実装されます。Coherenceアーティファクト(Coherence構成ファイル、POFシリアライゼーション・クラス、フィルタ、エントリ・プロセッサ、Aggregatorなど)は、GARとしてパッケージ化され、EAR内にもデプロイされる必要があります。Coherenceアプリケーションのパッケージ化とデプロイの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。
Coherenceアプリケーション層の作成
Coherenceアプリケーション層を作成するには:
- WebLogic Serverクラスタを作成します。「WebLogicクラスタの設定」を参照してください。
- 「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。
- 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。
- 「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、アプリケーション層でストレージを無効にします。このWebLogic Serverクラスタに割り当てられる管理対象Coherenceサーバーは、ストレージが無効なCoherenceメンバー(キャッシュ・ファクトリ・クライアント)になります。アプリケーション層内のサーバーは、キャッシュ・データの格納には使用しないでください。ストレージが有効なサーバーは、データを格納および分散するためのリソースを必要とし、クライアントのパフォーマンスに悪影響を与えるおそれがあります。
- 「保存」をクリックします。
親トピック: Coherenceアプリケーション層の構成と管理
アプリケーション層の管理対象Coherenceサーバーの作成
Coherenceアプリケーション層の管理対象サーバーを作成するには:
- WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。
- 「新規」をクリックして、新しい管理対象サーバーを作成します。
- 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。
- 「はい」をクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してアプリケーション層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic ServerクラスタからCoherence設定を継承します。
- 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。
- これらのステップを繰り返して、必要に応じて追加の管理対象サーバーを作成します。
- 「制御」タブで、起動するサーバーを選択し、「起動」をクリックします。
親トピック: Coherenceアプリケーション層の構成と管理
Coherenceプロキシ層の構成と管理
Coherenceプロキシ層は、Coherenceクラスタに関連付けられているWebLogic Serverクラスタであり、任意の数の管理対象Coherenceプロキシ・サーバーをホストします。管理対象Coherenceプロキシ・サーバーにより、Coherence*Extendクライアントは、クラスタ・メンバーにならなくてもCoherenceキャッシュを使用することが可能になります。プロキシ層で必要な管理対象Coherenceプロキシ・サーバーの数は、予想されるクライアントの数によって異なります。ロード・バランシングを可能にするには、少なくとも2台のプロキシ・サーバーを作成する必要があります。ただし、多数のクライアント接続およびリクエストをサポートする場合は、追加のサーバーが必要になることがあります。
Coherence*Extendおよび拡張クライアントの作成の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。
Coherenceプロキシ層の作成
Coherenceプロキシ層を作成するには:
- WebLogic Serverクラスタを作成します。「WebLogicクラスタの設定」を参照してください。
- 「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。
- 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。
- 「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、プロキシ層でストレージを無効にします。プロキシ・サーバーは、キャッシュ・データの格納には使用しないでください。プロキシ・サービスによって、ストレージが有効なクラスタ・メンバーが悪影響を受けるおそれがあります。プロキシ・サービスは、クライアント負荷の処理に追加のリソースを必要とします。
- 「保存」をクリックします。
親トピック: Coherenceプロキシ層の構成と管理
プロキシ層の管理対象Coherenceサーバーの作成
Coherenceプロキシ層の管理対象サーバーを作成するには:
- WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。
- 「新規」をクリックして、新しい管理対象サーバーを作成します。
- 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。
- 「はい」をクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してプロキシ層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic ServerクラスタからCoherence設定を継承します。
- 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。
- これらのステップを繰り返して、必要に応じて追加の管理対象サーバーを作成します。
- 「制御」タブで、起動するサーバーを選択し、「起動」をクリックします。
親トピック: Coherenceプロキシ層の構成と管理
Coherenceプロキシ・サービスの構成
Coherenceプロキシ・サービスは、拡張クライアントからのリモート接続を管理するクラスタ化されたサービスです。プロキシ・サービスは、<proxy-scheme>
要素内のcoherence-cache-config.xml
ファイルで定義および構成されます。定義には、その他の設定の他に、クライアント接続の受入に使用されるTCPリスナー・アドレス(IPまたはDNS名、およびポート)があります。<proxy-scheme>
要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。プロキシ・サービスを設定する方法は2つあります:
親トピック: Coherenceプロキシ層の構成と管理
ネーム・サービスの使用
ネーム・サービスは、拡張クライアントがプロキシ・サービスに名前で接続できるようにする専用のリスナーです。クライアントは、ネーム・サービスに接続し、ネーム・サービスは、クラスタ上のすべてのプロキシ・サービスのアドレスを戻します。ネーミング・サービスを使用すると、効率的な設定を行うことができ、Coherenceプロキシ層では通常、ネーミング・サービスの使用が推奨されます。
ノート:
ドメインに複数の層(データ層、アプリケーション層、プロキシ層など)が含まれている場合、クライアントがプロキシに接続できるようにするために、まずプロキシ層を起動する必要があります。
プロキシ・サービスを管理対象Coherenceプロキシ・サーバー上で構成すると、ネーム・サービスがポート7574
(Tangosol Cluster Management Protocol (TCMP)ソケットが使用するものと同じデフォルト・ポート)で自動的に起動します。同じポートを再利用することで、Coherenceが使用するポートの数を最小限に抑え、ファイアウォール構成を簡素化できます。
プロキシ・サービスを構成し、デフォルトのTCMPポート上でネーム・サービスを有効にするには:
ネーム・サービスに接続するには、クライアントのcoherence-cache-config.xml
ファイルのリモート・キャッシュまたはリモート呼出し定義の<tcp-initiator>
要素内に、<name-service-addresses>
要素が含まれている必要があります。<name-service-addresses>
要素は、管理対象Coherenceプロキシ・サーバー上のネーム・サービスのソケット・アドレスを提供します。次の例では、リモート・キャッシュを定義し、ポート7574
でホスト192.168.1.5
をリスニングするネーム・サービスを指定します。クライアントは、ネーム・サービスに自動的に接続し、TcpExtend
プロキシ・サービスが含まれているすべての管理対象Coherenceプロキシ・サーバーのリストを取得します。クラスタ上のキャッシュも、TcpExtend
という名前である必要があります。この例では、単一のアドレスが提供されます。プライマリ・アドレスでの障害に備えて、2つ目のネーム・サービス・アドレスを提供することも可能です。クライアント構成およびプロキシ・サービスのロード・バランシングの詳細は、『Oracle Coherenceリモート・クライアントの開発』の「拡張プロキシの構成」を参照してください。
<remote-cache-scheme> <scheme-name>extend-dist</scheme-name> <service-name>TcpExtend</service-name> <initiator-config> <tcp-initiator> <name-service-addresses> <socket-address> <address>192.168.1.5</address> <port>7574</port> </socket-address> </name-service-addresses> </tcp-initiator> </initiator-config> </remote-cache-scheme>
ネーム・サービスは、デフォルトでクラスタ・ポート(7574
)にリスニングし、Coherenceクラスタ・ノードを実行するすべてのマシンで利用できます。ターゲット・クラスタでデフォルトのTCMPクラスタ・ポートを使用する場合、構成からポートを省略できます。
ノート:
-
<service-name>
値は、プロキシ・スキームの<service-name>
値に一致している必要があります。それ以外の場合、プロキシ・スキーム内で構成されている<service-name>
要素の値を含むリモート・キャッシュおよびリモート呼び出しスキームで、<proxy-service-name>
要素も提供する必要があります。 -
以前のCoherenceリリースでは、ネーム・サービスは、クラスタ・ポートではなくメンバーのユニキャスト・ポートに自動でリスニングしていました。
-
アドレス・プロバイダを使用して、ネーム・サービス・アドレスを指定することもできます。
アドレス・プロバイダの使用
アドレス・プロバイダは、プロキシ・サービスのTCPリスナー・アドレス(IPまたはDNS名、およびポート)を指定します。リスナー・アドレスは、coherence-cache-config.xml
ファイルの<proxy-scheme>
要素で明示的に定義できます。ただし、望ましい方法は、クラスタ構成ファイルでアドレス・プロバイダを定義し、<proxy-scheme>
要素内からアドレスを参照することです。後者の方法では、アプリケーション構成からデプロイメント構成を分離し、coherence-cache-config.xml
ファイルを更新せずにネットワーク・アドレスを変更することが可能です。
アドレス・プロバイダを使用するには:
プロキシ・サービスに接続するには、クライアントのcoherence-cache-config.xml
ファイルのリモート・キャッシュまたはリモート呼出し定義の<tcp-initiator>
要素内に、<remote-addresses>
要素(これにはアドレス・プロバイダ名が含まれます)が含まれている必要があります。たとえば:
<remote-cache-scheme> <scheme-name>extend-dist</scheme-name> <service-name>TcpExtend</service-name> <initiator-config> <tcp-initiator> <remote-addresses> <address-provider>proxy1</address-provider> </remote-addresses> </tcp-initiator> </initiator-config> </remote-cache-scheme>
クライアントは、リモート・アドレスを明示的に指定することもできます。次の例では、リモート・キャッシュを定義し、ホスト192.168.1.5
およびポート9099
でプロキシ・サービスを指定します。クライアントは、プロキシ・サービスに自動的に接続し、TcpExtend
という名前のクラスタ上のキャッシュを使用します。この例では、単一のアドレスが提供されます。プライマリ・アドレスでの障害に備えて、2つ目のアドレスを提供することも可能です。クライアント構成およびプロキシ・サービスのロード・バランシングの詳細は、『Oracle Coherenceリモート・クライアントの開発』の「拡張プロキシの構成」を参照してください。
<remote-cache-scheme> <scheme-name>extend-dist</scheme-name> <service-name>TcpExtend</service-name> <initiator-config> <tcp-initiator> <remote-addresses> <socket-address> <address>192.168.1.5</address> <port>9099</port> </socket-address> </remote-addresses> </tcp-initiator> </initiator-config> </remote-cache-scheme>
親トピック: ネーム・サービスの使用
Coherenceクラスタの構成
Coherenceクラスタ・リソースは、特定のドメイン用に構成可能ないくつかのクラスタ設定を公開します。
多くの設定では、必要に応じて変更可能なデフォルト値が使用されます。次の手順は、クラスタ・リソースがすでに作成されていることを前提としています。クラスタ・リソースの作成の詳細は、Coherenceクラスタの設定を参照してください。セキュリティの詳細は、『Oracle Coherenceの保護』を参照してください。
Coherenceクラスタの「設定」ページの「Coherence」タブを使用して、クラスタ通信を構成します。CoherenceClusterSystemResource
MBeanおよびそれに関連付けられているCoherenceClusterResource
MBeanがクラスタ設定を公開します。CoherenceClusterResource
MBeanは、Coherenceクラスタを構成するために複数のMBeanにアクセスできるようにします。
ノート:
WLS構成は、Coherenceシステム・プロパティよりも優先されます。通常は、システム・プロパティを使用するかわりに、WLSTまたはCoherenceクラスタ構成ファイルを使用してWLSのCoherence構成を変更します。
次のタスクを使用して、クラスタ設定を構成します。
- Coherenceクラスタ・メンバーの追加と削除
- クラスタ構成の詳細オプションの設定
- クラスタ通信の構成
- キャッシュ構成ファイルのオーバーライド
- Coherenceロギングの構成
- キャッシュ永続性の構成
- キャッシュ・フェデレーションの構成
親トピック: Coherenceクラスタの構成と管理
Coherenceクラスタ・メンバーの追加と削除
既存のどの管理対象サーバー・インスタンスも、Coherenceクラスタに追加できます。さらに、管理対象Coherenceサーバーをクラスタから削除できます。クラスタ・メンバーの追加と削除は、Coherenceクラスタの構成時に行うことができ、各インスタンスを明示的に構成するかわりに使用できる簡便な方法です。ただし、既存の管理対象サーバー・インスタンスを追加する場合は、デフォルトのCoherence設定を変更する必要があります。管理対象Coherenceサーバーの構成の詳細は、「管理対象Coherenceサーバーの構成」を参照してください
Coherenceクラスタの「設定」ページの「メンバー」タブを使用して、Coherenceクラスタに関連付ける管理対象サーバーまたはWebLogic Serverクラスタを選択します。WebLogic Serverクラスタを選択する場合は、WebLogic Serverクラスタ内のすべての管理対象サーバーをCoherenceクラスタに関連付けることをお薦めします。CoherenceClusterSystemResource
は、すべての管理対象Coherenceサーバーをターゲットとして公開します。CoherenceMemberConfig
MBeanが各管理対象サーバーに対して作成され、Coherenceクラスタ・メンバーのパラメータを公開します。
親トピック: Coherenceクラスタの構成
クラスタ構成の詳細オプションの設定
WebLogic Server MBeanは、ほとんどのユースケースで十分なCoherence操作設定のサブセットを公開します。これについては、この項全体で詳細に説明します。これらの設定は、WLSTユーティリティおよびWebLogic Server管理コンソールでネイティブに使用できます。より高度なユースケースでは、外部Coherenceクラスタ構成ファイル(tangosol-coherence-override.xml
)を使用します。このファイルは、Coherence操作設定に対する完全な制御を提供します。
ノート:
外部クラスタ構成ファイルの使用をお薦めするのは、提供されているMBeanでは使用できない操作設定に対してのみです。つまり、外部クラスタ構成ファイルとMBeanの両方で同じ操作設定を構成することは避けてください。
Coherenceクラスタの「設定」ページの「全般」タブを使用して、管理サーバー上にあるクラスタ構成ファイルのパスと名前を入力するか、CoherenceClusterSystemResource
MBeanを使用します。Coherenceクラスタ構成ファイルの使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』の「オペレーション構成ファイルの指定」を参照してください。このマニュアルには、各要素の使用方法および詳細なスキーマ・リファレンスも記載されています。
どの操作構成が使用されるかのチェック
Coherenceは、WebLogic Server MBean、Coherenceクラスタ構成ファイル(インポートされている場合)およびCoherenceシステム・プロパティ(設定されている場合)から操作構成を生成します。システム・プロパティweblogic.debug.DebugCoherence=true
が設定されている場合、結果は、管理対象Coherenceサーバーのログに書き込まれます。WebLogic起動スクリプトを使用すると、JAVA_PROPERTIES
環境変数を使用できます。たとえば、
export JAVA_PROPERTIES=-Dweblogic.debug.DebugCoherence=true
親トピック: Coherenceクラスタの構成
クラスタ通信の構成
クラスタ・メンバーどうしはTCMPを使用して通信します。このプロトコルは、WLSクラスタ・プロトコルとは関係なく動作します。TCMPは、クラスタ・メンバーの検出、クラスタの管理、サービスのプロビジョニングおよびデータの送信を行うためのIPベースのプロトコルです。TCMPでは、様々なトランスポート・プロトコルを介して送信でき、マルチキャストとユニキャストの両方を使用できます。TCMPでは、デフォルトで、マルチキャストUDPが検出用に、TCPがデータ送信用に使用されます(TCP/IPメッセージ・バス(TMB)を使用)。WKAが構成されている場合、TCMPは検出用のユニキャスト・ユーザー・データグラム・プロトコル(UDP)およびデータ送信用のTransmission Control Protocol (TCP)を介して送信されます。Secure Sockets Layer (SSL)がTCMP用に構成されている場合は、SSL over TCPが検出とデータ送信の両方に使用されます。別のトランスポート・プロトコルおよびマルチキャストを使用する場合は、基礎となるネットワークがそれをサポートしている必要があります。
Coherenceクラスタの「設定」ページの「全般」タブを使用して、クラスタ通信を構成します。CoherenceClusterParamsBean
およびCoherenceClusterWellKnownAddressesBean
MBeanは、クラスタ通信パラメータを公開します。
Coherenceクラスタ・モードの変更
Coherenceクラスタは、ユニキャスト通信とマルチキャスト通信の両方をサポートしています。マルチキャストは、デフォルトのオプションではありません。明示的に構成する必要があります。マルチキャストが適切にサポートされていない環境やマルチキャストが許可されていない環境では、マルチキャストの使用は避けてください。ユニキャストの使用により、すべてのマルチキャスト送信は無効になり、自動的にCoherence WKA機能を使用して、クラスタ・メンバーの検出およびクラスタ・メンバー間の通信が行われます。
Coherenceでのマルチキャスト、ユニキャストおよびWKAの使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』の「クラスタの設定」を参照してください。
Coherenceクラスタ・モードでのユニキャストの選択
クラスタ通信でユニキャストを使用するには、「クラスタリング・モード」ドロップダウン・リストから「ユニキャスト」を選択し、クラスタ・ポートを入力するか、デフォルト・ポート7574
のままにします。Coherence 12.2.1以降は、Coherenceクラスタ名を設定するだけで、すべてのクラスタで同じクラスタ・ポートを使用できます。ほとんどのクラスタの場合、ポートの変更は必要ありません。クラスタ・ポートを変更するのは、そのポートを使用している別のアプリケーションと衝突がある場合のみです。別のポートが必要な場合、お薦めのベスト・プラクティスとして、1024
から8999
までの値を選択します。
ノート:
Coherenceのデフォルト・クラスタ・ポートは、Coherenceアプリケーションで使用できるようにIANAに登録されています。Well Knownアドレス・メンバーの指定
ユニキャストが有効な場合は、「ウェル・ノウン・アドレス」タブを使用してWKAマシン・アドレスを明示的に構成します。クラスタに対してアドレスが定義されていない場合、アドレスが自動的に割り当てられます。ユニキャストを使用する際は、お薦めのベスト・プラクティスとして、WKAマシン・アドレスを常に明示的に指定します。
さらに、異なるマシン上にある複数の管理対象Coherenceサーバーがドメインに含まれる場合、Coherenceクラスタが確実に形成されるように少なくとも1つの非ローカルWKAマシン・アドレスを定義する必要があります。そうでない場合、各マシンに複数の個別クラスタが形成されます。管理対象Coherenceサーバーがすべて同じマシン上で実行している場合、非ローカル・リスニング・アドレスを指定せずにクラスタを作成できます。
ノート:
WKAマシン・アドレスは、本番環境で明示的に定義される必要があります。本番モードで、WKAマシン・アドレスが明示的に定義されていない場合、管理対象Coherenceサーバーは起動に失敗します。自動的に割り当てられたWKAマシン・アドレスは、設計時の便宜を図るためのもので、開発時に単一サーバー上でのみ使用する必要があります。
Coherenceクラスタ・モードでのマルチキャストの選択
クラスタ通信でマルチキャストを使用するには、「クラスタリング・モード」ドロップダウン・リストから「マルチキャスト」を選択し、クラスタ・ポートとマルチキャスト・リスニング・アドレスを入力します。クラスタが同じコンピュータまたはマルチキャスト・アドレスで実行されている場合でも、同じクラスタ・ポートを異なるクラスタ間で(クラスタ名で識別して),共有できます。したがって、クラスタ名が環境内で一意の値に設定されている場合は、クラスタ・ポートを変更する必要はありません。別のポートが必要な場合、お薦めのベスト・プラクティスとして、1024
から8999
までの値を選択します。
「TTL」フィールドを使用して、マルチキャスト・パケットが到達できるネットワーク範囲を指定します。存続時間値はパケットが存続し続けるホップの数で表現されます。1つのネットワーク・インタフェース、ルーターまたは管理対象スイッチが1ホップと見なされます。TTL値には、実効性のある最も小さい整数値を指定します。
親トピック: クラスタ通信の構成
Coherenceクラスタ・トランスポート・プロトコルの変更
次のトランスポート・プロトコルが、TCMPでサポートされています。
-
ユーザー・データグラム・プロトコル(UDP) – UDPは、デフォルトのTCMPトランスポート・プロトコルで、マルチキャスト通信とユニキャスト通信の両方に使用されます。マルチキャストが無効な場合、すべての通信はUDPユニキャストを使用して行われます。
-
伝送制御プロトコル(TCP) – TCPトランスポート・プロトコルは、TCP通信が優先されているネットワーク環境で使用されます。ユニキャストが有効な場合、すべてのTCMP通信はTCPを使用します。マルチキャストが有効な場合、TCPはユニキャスト通信でのみ使用され、マルチキャスト通信にはUDPが使用されます。
ノート:
「TCP」を選択すると、クラスタ検出で使用されるTMBとTCPの両方のソケット・プロバイダが設定されます。 -
Secure Sockets Layer (SSL) – SSL/TCPトランスポート・プロトコルは、クラスタ・メンバー間で高度にセキュアな通信が必要なネットワーク環境で使用されます。SSLは、ユニキャスト通信でのみサポートされています。SSLを使用する場合は、マルチキャストを無効にしてください。SSLを使用するには、追加の構成が必要です。WebLogic Server内のCoherenceの保護の詳細は、『Oracle Coherenceの保護』を参照してください。
-
インフィニバンド・メッセージ・バス(IMB) – IMBは、ネイティブのInfiniBand Verbに基づいた最適なプロトコルを使用します。IMBは、Exalogicでのみ有効です。
CoherenceClusterParamsBean
MBeanは、次のオプションが含まれる「トランスポート」ドロップダウン・リストでトランスポート・プロトコル設定を公開します:
- TMB: UDP + TMB (デフォルト)
- TCP: TCP + TMB
- UDP: UDP + datagram
- SSL: SSL over TCP + TMBS
- SSLUDP: SSL over TCP + SSL over datagram
- SDMB: UDP + SDMB
- IMB: UDP + IMB
これらのオプションは、クラスタ・サービス通信用のCoherenceクラスタ・トランスポート・プロトコルと、信頼できるポイントツーポイント・データ・サービス通信の組合せです。次の表で、これらの組合せを説明します:
表12-1 トランスポート・タイプ
トランスポート・タイプ | 説明 |
---|---|
|
トランスポート・タイプTMB (TCP/IPメッセージ・バス)の場合、クラスタ・サービス通信ではUDPが使用され、信頼性の高いポイントツーポイント・データ・サービス通信ではTMBが使用されます。 |
|
トランスポート・タイプTCPの場合、クラスタ・サービス通信ではTCPが使用され、信頼性の高いポイントツーポイント・データ・サービス通信ではTMBが使用されます。 |
|
トランスポート・タイプUDPの場合、クラスタ・サービス通信ではUDPが使用され、信頼性の高いポイントツーポイント・データ・サービス通信ではdatagramが使用されます。 |
|
トランスポート・タイプSSLの場合、クラスタ・サービス通信ではSSL over TCPが使用され、信頼性の高いポイントツーポイント・データ・サービス通信ではTMBSが使用されます。 |
|
トランスポート・タイプSSLUDPの場合、クラスタ・サービス通信ではSSL over TCPが使用され、信頼性の高いポイントツーポイント・データ・サービス通信ではSSL over datagramが使用されます。 |
|
トランスポート・タイプSDMB (ソケット・ダイレクト・プロトコル・メッセージ・バス)の場合、クラスタ・サービス通信ではUDPが使用され、信頼性の高いポイントツーポイント・データ・サービス通信ではSDMBが使用されます。 |
|
トランスポート・タイプIMBの場合、クラスタ・サービス通信ではUDPが使用され、信頼性の高いポイントツーポイント・データ・サービス通信ではIMBが使用されます。 |
これらのプロトコルの変更の詳細は、『Oracle Coherenceでのアプリケーションの開発』の「トランスポート・プロトコルの変更」を参照してください。
親トピック: クラスタ通信の構成
キャッシュ構成ファイルのオーバーライド
Coherenceキャッシュ構成ファイルでは、アプリケーションが使用するキャッシュを定義します。通常、キャッシュ構成ファイルは、GARモジュールに含まれています。GARは、データ層内のすべての管理対象Coherenceサーバーにデプロイされますが、EARの一部としてアプリケーション層にデプロイすることもできます。GARにより、キャッシュ構成がすべてのOracle Coherenceクラスタ・メンバー上で使用できるようになります。ただし、特定の管理対象Coherenceサーバーで別のキャッシュ構成ファイルを使用する必要があるユースケースも存在します。たとえば、プロキシ層では、GAR内のすべてのアーティファクトにアクセスする必要がありますが、起動するプロキシ・サービスが定義されている別のキャッシュ構成ファイルが必要です。
キャッシュ構成ファイルは、実行時にWebLogicクラスタまたは管理対象Coherenceサーバーに関連付けることができます。この場合、そのキャッシュ構成が、GARに含まれているキャッシュ構成ファイルをオーバーライドします。GARファイル内のキャッシュ構成ファイルを省略し、実行時に割り当てることもできます。実行時にキャッシュ構成ファイルをオーバーライドするには、キャッシュ構成ファイルがJNDI名にバインドされている必要があります。JNDI名は、<cache-configuration-ref>
要素のoverride-property
属性を使用して定義されます。この要素は、GARファイル内にパッケージ化されているcoherence-application.xml
ファイルにあります。coherence-application.xml
ファイルの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』の「Coherenceアプリケーションのデプロイメント・ディスクリプタの作成」を参照してください。
次の例では、GAR内のMETA-INF/example-cache-config.xml
キャッシュ構成ファイルのオーバーライドに使用できる、cache-config/ExamplesGar
という名前のオーバーライド・プロパティを定義します。
... <cache-configuration-ref override-property="cache-config/ExamplesGar"> META-INF/example-cache-config.xml</cache-configuration-ref> ...
実行時、Coherenceクラスタの「設定」ページの「キャッシュ構成」タブを使用して、キャッシュ構成ファイルをオーバーライドします。override-property
属性で定義されているものと同じJNDI名を指定する必要があります。キャッシュ構成は、管理サーバーに置くことも、URLで場所を指定することもできます。さらに、ドメインにファイルをインポートするか、それを指定の場所から使用するかを選択できます。「ターゲット」タブを使用して、どのOracle Coherenceクラスタ・メンバーがキャッシュ構成ファイルを使用するかを指定します。
次のWLST(オンライン)の例では、CoherenceClusterSystemResource
オブジェクトを使用してクラスタ・キャッシュ構成をどのようにオーバーライドできるかを示します。
edit() startEdit() cd('CoherenceClusterSystemResources/myCoherenceCluster/CoherenceCacheConfigs') create('ExamplesGar', 'CoherenceCacheConfig') cd('ExamplesGar') set('JNDIName', 'ExamplesGar') cmo.importCacheConfigurationFile('/tmp/cache-config.xml') cmo.addTarget(getMBean('/Servers/coh_server')) save() activate()
WLSTの例では、CoherenceCacheConfig
リソースを子として作成します。このスクリプトでは次に、キャッシュ構成ファイルがドメインにインポートされ、リソースのバインド先となるJNDIが指定されます。ファイルは、指定されたパスに存在している必要があります。最後に、キャッシュ構成が特定のサーバーにターゲット指定されます。キャッシュ構成リソースを特定のサーバーまたはWebLogic Serverクラスタにターゲット指定できることで、アプリケーションが、サーバーのコンテキスト(キャッシュ・サーバー、キャッシュ・クライアント、プロキシ・サーバーなど)に応じて異なる構成をロードすることが可能になります。
次の例は、キャッシュ構成リソースをURLとして構成する方法を示しています。
edit() startEdit() cd('CoherenceClusterSystemResources/myCoherenceCluster/CoherenceCacheConfigs') create('ExamplesGar', 'CoherenceCacheConfig') cd('ExamplesGar') set('JNDIName', 'ExamplesGar') set('CacheConfigurationFile', 'http://cache.locator/app1/cache-config.xml') cmo.addTarget(getMBean('/Servers/coh_server')) save() activate()
親トピック: Coherenceクラスタの構成
Coherenceロギングの構成
WebLogic Server管理コンソールのCoherenceクラスタの「設定」ページにある「ロギング」タブ、またはCoherenceLoggingParamsBean
MBeanを使用して、クラスタ・ロギングを構成します。WebLogic Serverロギングの詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』を参照してください。Coherenceロギング構成には次のものが含まれます。
-
ロギングの無効化と有効化
-
デフォルトのロガー名の変更
WebLogic Serverには、Coherenceロギングで使用できる2つのロガーが用意されています。1つはデフォルトの
com.oracle.coherence
ロガー、もう1つはcom.oracle.wls
ロガーです。com.oracle.wls
ロガーは、汎用的なもので、WebLogic Serverログ出力用に構成されているのと同じハンドラを使用します。このロガーでは、Coherence固有の構成は許可されません。com.oracle.coherence
ロガーでは、Coherenceログで別のハンドラを使用するなど、Coherence固有の構成が許可されます。ノート:
標準のlogging.properties
ファイルを通じてロギングを構成する場合、そのファイルで、Coherenceロギング用に現在構成されているものと同じロガー名が使用されていることを確認してください。 -
ログ・メッセージの書式の変更
ログ・メッセージに情報を追加、またはログ・メッセージから情報を削除します。ログ・メッセージには、静的テキストの他に、実行時に置き換えられるパラメータ(
{date}
など)も含めることができます。サポートされているログ・メッセージ・パラメータの詳細は、『Oracle Coherenceでのアプリケーションの開発』「ログ・メッセージの書式の変更」を参照してください。
ノート:
次のロガー構成により、Coherenceの動的ロギングが有効になります:
<logger-severity>Trace</logger-severity>
<log-file-severity>Trace</log-file-severity>
<stdout-severity>Debug</stdout-severity>
<platform-logger-levels>com.oracle.coherence=FINEST</platform-logger-levels>
親トピック: Coherenceクラスタの構成
キャッシュ永続性の構成
Coherence保持は、Coherence分散キャッシュの永続性およびリカバリを管理します。致命的障害や、計画的メンテナンスによるクラスタ再起動の後に迅速なリカバリができるように、キャッシュされたデータは保持されます。Coherenceのキャッシュ永続性の詳細は、『Oracle Coherenceの管理』の「キャッシュの保持」を参照してください。
Coherenceクラスタ設定ページの「永続性」タブを使用して、アクティブ永続性を有効にし、永続性ファイルの格納先となるデフォルトの場所をオーバーライドします。CoherencePersistenceParamsBean
MBeanが永続性パラメータを公開します。永続性の変更を有効にするために、管理対象Coherenceサーバーを再起動する必要があります。
オンデマンド永続性では、キャッシュ・サービスを手動で永続化し、リクエスト時(スナップショット)に永続性コーディネータを使用してリカバリできます。永続性コーディネータは、キャッシュ・サービスのスナップショットの作成、アーカイブおよびリカバリの操作を提供するMBeanインタフェース(PersistenceCoordinatorMBean
)として公開されています。MBeanを使用するには、JMXをクラスタに対して有効にする必要があります。JMX管理の有効化およびCoherence MBeanへのアクセスの詳細は、『Oracle Coherenceのマネージメント』の「JMXの使用によるOracle Coherenceの管理」を参照してください。アクティブ永続性では、キャッシュの内容はすべてのミューテーションで自動的に永続化され、内容はクラスタ/サービスの起動時に自動的にリカバリされます。その場合も、永続性コーディネータをアクティブ永続性モードで使用して、オンデマンド・スナップショットを実行できます。
親トピック: Coherenceクラスタの構成
キャッシュ・フェデレーションの構成
フェデレーション・キャッシュ機能は、地理的に分散している複数のクラスタ間で非同期的にキャッシュ・データを結合します。キャッシュ内のデータはクラスタ間で結合され、地理的に異なる場所のアプリケーション・ユーザーに対して冗長性、オフサイト・バックアップおよび複数のアクセス・ポイントを提供します。Coherenceフェデレーションの詳細は、『Oracle Coherenceの管理』の「複数クラスタにわたるキャッシュのフェデレート」を参照してください。
Coherenceクラスタ設定ページの「フェデレーション」タブを使用して、フェデレーション・トポロジを有効にし、キャッシュをフェデレートするリモート・クラスタ・メンバーを構成します。トポロジを選択すると、トポロジ構成が自動的に作成され、Default-Topology
という名前が付けられます。フェデレーションは、ローカル・クラスタ・メンバーとリモート・クラスタ・メンバーの両方で構成する必要があります。リモート・クラスタ上のホストを1つ以上提供する必要があります。リモート・クラスタ・メンバー上でカスタム・ポートが使用されている場合は、それに応じてクラスタ・ポートを変更します。フェデレーションの変更を有効にするために、管理対象Coherenceサーバーを再起動する必要があります。CoherenceFederationParamsBean
MBeanは、クラスタ・フェデレーション・パラメータも公開し、キャッシュ・フェデレーションを構成するために使用できます。
ノート:
-
Default-Topology
トポロジ構成が作成され、キャッシュ構成ファイルでフェデレーション・トポロジが指定されていない場合に使用されます。 -
フェデレーションの使用時は、ローカル・クラスタとリモート・クラスタの両方で一致するトポロジを構成する必要があります。たとえば、ローカル・クラスタでのトポロジに
none
を、リモート・クラスタでのトポロジとしてactive-active
を選択すると、予期しない動作が発生する可能性があります。同様に、ローカル・クラスタをactive-passiveを使用するよう設定した場合は、リモート・クラスタをpassive-activeを使用するよう設定する必要があります。
親トピック: Coherenceクラスタの構成
管理対象Coherenceサーバーの構成
管理対象Coherenceサーバーは、特定のドメイン用に構成可能ないくつかのクラスタ・メンバー設定を公開します。
多くの設定では、必要に応じて変更可能なデフォルト値が使用されます。この項に記載されている手順は、管理対象サーバーがすでに作成されて、Coherenceクラスタに関連付けられていることを前提としています。管理対象Coherenceサーバーの作成の詳細は、「スタンドアロンの管理対象Coherenceサーバーの作成」を参照してください
管理対象サーバーの「設定」ページの「Coherence」タブを使用して、Coherenceクラスタ・メンバー設定を構成します。CoherenceMemberConfig
MBeanが各管理対象サーバーに対して作成され、Coherenceクラスタ・メンバーのパラメータを公開します。
ノート:
WLS構成は、Coherenceシステム・プロパティよりも優先されます。WLSのCoherence構成は一般に、システム・プロパティを使用するのではなく、WLSTまたはCoherenceクラスタ構成ファイルを使用して変更する必要があります。
次のタスクを使用して、管理対象Coherenceサーバーを構成します。
- Coherenceクラスタ・メンバーのストレージ設定の構成
- Coherenceクラスタ・メンバーのユニキャスト設定の構成
- 動的管理の使用
- Coherenceクラスタ・メンバーのID設定の構成
- Coherenceクラスタ・メンバーのロギング・レベルの構成
親トピック: Coherenceクラスタの構成と管理
Coherenceクラスタ・メンバーのストレージ設定の構成
必要に応じて、管理対象Coherenceサーバーのストレージ設定を構成できます。サーバー上でストレージを有効にするということは、サーバーがCoherenceクラスタのプライマリ・データとバックアップ・データの両方の一部を格納することを意味します。データを格納するサーバーは、ストレージが有効なサーバーとして構成されている必要があります。キャッシュ・アプリケーションをホストするサーバーおよびクラスタ・プロキシ・サーバーは、ストレージが無効なサーバーとして構成する必要があり、通常は、データの格納を行いません。共有リソースに問題が生じ、アプリケーションとクラスタのパフォーマンスに影響を及ぼすおそれがあるためです。
ノート:
管理対象CoherenceサーバーがWebLogic Serverクラスタのメンバーである場合、WebLogic Serverクラスタで指定されているCoherenceストレージ設定は、サーバー上のストレージ設定をオーバーライドします。ストレージ設定は、サーバー設定がWebLogic Serverクラスタ設定をオーバーライドするという原則の例外です。さらに、最終ランタイムの構成は、コンソールに反映されません。したがって、WebLogic Serverクラスタの「Coherence」タブでストレージが有効化されているにもかかわらず、管理対象Coherenceサーバーでは、ストレージが無効であると表示される場合があります。管理対象Coherenceサーバーのストレージが有効か無効かを判別するには、必ずWebLogic Serverクラスタの設定を確認してください。
「Coherence」タブ上の次のフィールドを使用して、ストレージ設定を構成します:
-
ローカル記憶域有効 – このフィールドでは、管理対象Coherenceサーバーがデータを格納するかどうかを指定します。このオプションが選択されない場合、管理対象Coherenceサーバーは、データを格納せず、クラスタ・クライアントと見なされます。
-
Coherence Webローカル記憶域有効 – このフィールドでは、管理対象CoherenceサーバーがHTTPセッション・データを格納するかどうかを指定します。Coherenceを使用したセッション・データの格納の詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』の「WebLogic ServerでのCoherence*Webの使用方法」を参照してください。
親トピック: 管理対象Coherenceサーバーの構成
Coherenceクラスタ・メンバーのユニキャスト設定の構成
管理対象Coherenceサーバーは、ユニキャスト(ポイント・ツー・ポイント)通信を使用して相互に通信します。クラスタがマルチキャスト通信を使用するように構成されている場合でも、ユニキャストが使用されます。Coherenceにおけるユニキャストの詳細は、『Oracle Coherenceでのアプリケーションの開発』の「クラスタ・メンバーのユニキャスト・アドレスの指定」を参照してください。
「Coherence」タブ上の次のフィールドを使用して、ユニキャスト設定を構成します:
-
ユニキャスト・リスニング・アドレス – このフィールドでは、サーバーがユニキャスト通信をリスニングするアドレスを指定します。アドレスを指定しない場合、ルーティング可能IPアドレスが自動的に選択されます。アドレス・フィールドでは、クラスレス・ドメイン間ルーティング(CIDR)表記法もサポートされています。この表記法は、正確なIPアドレスを指定するかわりに、バインド先のローカルIPアドレスのサブネットおよびマスク・パターンを使用します。
-
ユニキャスト・リスニング・ポート – このフィールドでは、サーバーがユニキャスト通信をリスニングするポートを指定します。クラスタ・メンバーは、オペレーティング・システムの使用可能なエフェメラル・ポート範囲(値
0
で示される)から自動で割り当てられる2つのユニキャストUDPポートを使用します。デフォルト値の場合、Coherenceが原因で他のアプリケーションとのポート競合が誤って生じることはありません。ただし、クラスタ・メンバー間でファイアウォールが必要な場合(特殊な構成)、ポートを手動で割り当てることができ、2番目のポートが自動的に選択されます(port1 +1)。 -
ユニキャスト・ポートの自動調整 – このフィールドでは、ポートがすでに使用されている場合、ポートを自動的に増分するかどうかを指定します。
親トピック: 管理対象Coherenceサーバーの構成
動的管理の使用
Coherenceクラスタは、JConsoleやJava VisualVMなど、JMX互換の任意のクライアントから管理できます。管理情報には、実行時統計と操作設定が含まれています。この管理情報はCoherence管理ドメイン固有であり、WebLogic管理ドメインの一部としてCoherenceに提供されている管理情報とは異なります。Coherence MBeansの詳細は、『Oracle Coherenceのマネージメント』の「Oracle Coherence MBeanのリファレンス」を参照してください。
Coherenceを構成して、動的管理モードで起動します。1つのクラスタ・メンバーが管理プロキシとして自動で選択され、他のすべてのクラスタ・メンバーの管理情報を集約する責任があります。その後、管理情報はWebLogicドメインの管理サーバーによって統合され、ドメイン・ランタイムMBeanサーバーを通じて使用できるようになります。そのクラスタ・メンバーが稼働していない場合、別のクラスタ・メンバーが管理プロキシとして自動で選択されます。
実行時にJMXクライアントを使用してドメイン実行時MBeanサーバーに接続します。Coherence管理情報はこのサーバーのCoherence管理ネームスペース内に格納されています。ドメイン実行時MBeanサーバーへの接続の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の「JMXを使用したWebLogic Server MBeanへのアクセス」を参照してください。
親トピック: 管理対象Coherenceサーバーの構成
Coherenceクラスタ・メンバーのID設定の構成
クラスタ内の管理対象CoherenceサーバーにIDを付与するために、一連の識別子が使用されます。ID情報は、クラスタ内でサーバーを区別し、サーバーのロールを伝達するために使用されます。一部のIDは、クラスタ・タスクの実行時にクラスタ・サービスによっても使用されます。最後に、管理情報(JMXなど)を表示する際は、ID情報が役に立ちます。また、ID情報により、ログ・エントリの解釈が容易になります。
「Coherence」タブ上の次のフィールドを使用して、メンバーID設定を構成します:
-
サイト名 – このフィールドでは、管理対象Coherenceサーバーをホストしている地理的サイトの名前を指定します。名前が指定されない場合、サーバーのドメイン名が使用されます。WANクラスタリングの場合、この値は、メンバーが存在するデータ・センターを識別します。インテリジェントなルーティング、ロード・バランシングおよび障害回復計画(つまり、別の地理的サイトにあるデータの明示的なバックアップ)の基盤として、サイト名を使用できます。サイト名は、分散キャッシングの使用時のデータのバックアップ先や、デフォルト・パーティションの割当て戦略を決定するために役立ちます。最後に、管理情報(JMXなど)を表示したり、ログ・エントリを解釈したりする際は、名前が役に立ちます。
-
ラック名 – このフィールドでは、管理対象Coherenceサーバーがホストされている地理的サイト内の場所の名前を指定します。これは多くの場合、ケージ、ラックまたはブレードフレームの識別子です。インテリジェントなルーティング、ロード・バランシングおよび障害回復計画(つまり、別のブレードフレームにあるデータの明示的なバックアップ)の基盤として、ラック名を使用できます。ラック名は、分散キャッシングの使用時のデータのバックアップ先や、デフォルト・パーティションの割当て戦略を決定するために役立ちます。最後に、管理情報(JMXなど)を表示したり、ログ・エントリを解釈したりする際は、名前が役に立ちます。
-
ロール名 – このフィールドでは、クラスタにおける管理対象Coherenceサーバーのロールを指定します。ロール名により、アプリケーションは、クラスタ・メンバーを、ストレージが有効、ストレージが無効など、特化したロールに編成することができます。
管理対象CoherenceサーバーがWebLogic Serverクラスタのメンバーである場合、ロール名としてクラスタ名が自動的に使用され、このフィールドを設定することはできません。名前が指定されない場合、使用されるデフォルトのロール名は
WebLogicServer
です。
親トピック: 管理対象Coherenceサーバーの構成
Coherenceクラスタ・メンバーのロギング・レベルの構成
各管理対象Coherenceサーバーについてロギング・レベルを構成できます。デフォルトのロギング・レベルはD5で、これはサーバーの「ロギング」タブを使用して変更できます。WebLogic Serverロギングの詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』を参照してください。
管理対象Coherenceサーバーのロギングを構成するには:
親トピック: 管理対象Coherenceサーバーの構成
単一サーバー・クラスタの使用
単一サーバー・クラスタは、単一の管理対象サーバー・インスタンス上で実行するように制限されている、ネットワークにアクセスしないクラスタです。
単一サーバー・クラスタを作成するには:
-
Coherenceクラスタを作成し、クラスタのメンバーにする管理対象サーバー・インスタンスを選択します。管理サーバー・インスタンスを使用して、容易に設定を行うことができます。「Coherenceクラスタ・リソースの定義」を参照してください。
-
クラスタを構成し、存続時間の値を
0
に設定します(マルチキャスト通信を使用している場合)。「クラスタ通信の構成」を参照してください。 -
管理対象サーバー・インスタンスを構成し、ユニキャスト・アドレスを、ループバックにルーティングされるアドレスに設定します。ほとんどのコンピュータで、アドレスを
127.0.0.1
に設定すれば問題ありません。「Coherenceクラスタ・メンバーのユニキャスト設定の構成」を参照してください。
親トピック: Coherenceクラスタの構成と管理
CoherenceでのWLSTの使用
詳細は、『WebLogic Scripting Toolの理解』を参照してください。
WLSTによるCoherenceの設定(オフライン)
WLSTを使用してCoherenceクラスタを設定できます。次の例では、WLSTをオフライン・モードで使用してCoherenceクラスタを作成および構成する方法を示します。この例は、ドメインはすでに作成されており、記載されている順番で実行されることを前提としています。また、この例では、データ層のみが作成されます。その他の層は、必要に応じて作成できます。最後に、この例は、すべてのCoherence MBeanの例を示すことを意図していません。Coherence MBeanの完全なリストは、Oracle WebLogic Server MBeanリファレンスを参照してください。
readDomain('/ORACLE_HOME/user_projects/domains/base_domain')
Coherenceクラスタの作成
create('myCoherenceCluster', 'CoherenceClusterSystemResource')
管理対象Coherenceサーバーの層の作成
create('coh_server1', 'Server') cd('Server/coh_server1') set('ListenPort', 7005) set('ListenAddress', '192.168.0.100') set('CoherenceClusterSystemResource', 'myCoherenceCluster') cd('/') create('coh_server2','Server') cd('Server/coh_server2') set('ListenPort', 7010) set('ListenAddress', '192.168.0.101') set('CoherenceClusterSystemResource', 'myCoherenceCluster') cd('/') create('DataTier', 'Cluster') assign('Server', 'coh_server1,coh_server2','Cluster','DataTier') cd('Cluster/DataTier') set('MulticastAddress', '237.0.0.101') set('MulticastPort', 8050) cd('/CoherenceClusterSystemResource/myCoherenceCluster') set('Target', 'DataTier')
Coherenceクラスタ・パラメータの構成
cd('CoherenceClusterSystemResource/myCoherenceCluster/CoherenceResource/ myCoherenceCluster/CoherenceClusterParams/NO_NAME_0') set('ClusteringMode', 'unicast') set('SecurityFrameworkEnabled','false') set('ClusterListenPort', 7574)
Well Knownアドレスの構成
create('wka_config','CoherenceClusterWellKnownAddresses') cd('CoherenceClusterWellKnownAddresses/NO_NAME_0') create('WKA1','CoherenceClusterWellKnownAddress') cd('CoherenceClusterWellKnownAddress/WKA1') set('ListenAddress', '192.168.0.100') cd('../..') create('WKA2','CoherenceClusterWellKnownAddress') cd('CoherenceClusterWellKnownAddress/WKA2') set('ListenAddress', '192.168.0.101')
ロギング・プロパティの設定
cd('/') cd('CoherenceClusterSystemResource/myCoherenceCluster/CoherenceResource/ myCoherenceCluster') create('log_config)','CoherenceLoggingParams') cd('CoherenceLoggingParams/NO_NAME_0') set('Enabled', 'true') set('LoggerName', 'com.oracle.coherence')
管理対象Coherenceサーバーの構成
cd('/') cd('Servers/coh_server1') create('member_config', 'CoherenceMemberConfig') cd('CoherenceMemberConfig/member_config') set('LocalStorageEnabled', 'true') set('RackName', '100A') set('RoleName', 'Server') set('SiteName', 'pa-1') set('UnicastListenAddress', '192.168.0.100') set('UnicastListenPort', 0) set('UnicastPortAutoAdjust', 'true') cd('/') cd('Servers/coh_server2') create('member_config', 'CoherenceMemberConfig') cd('CoherenceMemberConfig/member_config') set('LocalStorageEnabled', 'true') set('RackName', '100A') set('RoleName', 'Server') set('SiteName', 'pa-1') set('UnicastListenAddress', '192.168.0.101') set('UnicastListenPort', 0) set('UnicastPortAutoAdjust', 'true') updateDomain() closeDomain()
クラスタ名およびポートの設定
readDomain('/ORACLE_HOME/user_projects/domains/base_domain')
cd('CoherenceClusterSystemResource/myCoherenceCluster/CoherenceResource/
myCoherenceCluster)
set('Name', 'MyCluster')
cd('CoherenceClusterSystemResource/myCoherenceCluster/CoherenceResource/
myCoherenceCluster/CoherenceClusterParams/NO_NAME_0')
set('ClusterListenPort', 9123)
updateDomain()
closeDomain()
親トピック: Coherenceクラスタの構成と管理
WLSTを使用したCoherence MBeanへのアクセス
管理対象Coherenceサーバー環境のWebLogic Server内でCoherenceを実行すると、WebLogic ServerドメインのランタイムMBeanサーバーにより管理プロキシからJMX情報が収集され、この情報にはWLSTを使用してアクセスできます。
WLSTを使用して接続して、domainRuntime()に切り替えた後は、mbs
オブジェクトを介してMBeanServerが使用可能になり、そこで標準のCoherence MBeanに対する問合せや操作を実行できます。
次に、MBeanの様々な値と操作にアクセスする方法の例を示します。これは完全なリストではなく、WLSTを使用してMBeanにアクセスする方法を示すためのものです。属性および操作を含むCoherence MBeanのリストについては、『Oracle Coherenceのマネージメント』のOracle Coherence MBeanのリファレンスに関する項を参照してください。
ノート:
WebLogic ServerはMBeanを戻す際に追加のロケーション・キーを追加するため、一部の例では、次のWLST関数を使用してこのロケーション・キーを含む完全修飾名が返されています。# Return the fully qualified Name for a query
def coh_getFullyQualifiedName(query):
beans = list(mbs.queryMBeans(ObjectName(query),None))
if len(beans) == 0:
raise RuntimeException('No results found')
for bean in beans:
return bean.getObjectName()
例12-1 単一のMBean (ClusterMBean
など)へのアクセス
この例では、ClusterMBean
にアクセスして様々な属性を表示する方法を示します。
# Return the fully qualified Name for a query
def coh_getFullyQualifiedName(query):
beans = list(mbs.queryMBeans(ObjectName(query),None))
if len(beans) == 0:
raise RuntimeException('No results found')
for bean in beans:
return bean.getObjectName()
#
## Entry point
#
connect ("username","password", "t3://host:port")
# Enter the WebLogic Server administrator username, password, and the administration server host and port.
domainRuntime()
query = coh_getFullyQualifiedName('Coherence:type=Cluster,*')
print 'Fully qualified query: ' + str(query)
beans = list(mbs.queryMBeans(query, None))
# Should only be one cluster MBean
if len(beans) == 0:
print 'Unable to find ClusterMBean'
else:
# Normally there is only one ClusterMBean but if you had multiple
# Coherence clusters then > 1 could be returned
bean = beans[0]
cluster = bean.getObjectName()
clusterName = mbs.getAttribute(cluster, 'ClusterName')
clusterSize = mbs.getAttribute(cluster, 'ClusterSize')
clusterVersion = mbs.getAttribute(cluster, 'Version')
print 'Cluster Name: ' + clusterName
print 'Cluster Size: ' + str(clusterSize)
print 'Coherence Version: ' + clusterVersion
出力例:
Location changed to domainRuntime tree. This is a read-only tree
with DomainMBean as the root MBean.
For more help, use help('domainRuntime')
Fully qualified query: Coherence:cluster=CoherenceCluster,Location=storage1,type=Cluster
Cluster Name: CoherenceCluster
Cluster Size: 4
例12-2 複数のMBean (CacheMBean
など)からの表示情報
この例では、すべての定義済キャッシュのCoherenceMBeanにアクセスする方法を示します。
connect ("username","password", "t3://host:port")
# Enter the WebLogic Server administrator username, password, and the administration server host and port.
domainRuntime()
beans = list(mbs.queryMBeans(ObjectName('Coherence:type=Cache,*'),None))
for bean in beans:
cache = bean.getObjectName()
cacheSize = mbs.getAttribute(cache, 'Size')
cacheUnits = mbs.getAttribute(cache, 'Units')
print 'Mbean: ' + str(cache)
print 'Size: ' + str(cacheSize)
print 'Units: ' + str(cacheUnits)
出力例
Mbean: Coherence:Location=storage1,nodeId=1,type=Cache,cluster=CoherenceCluster,service="ExampleGAR:PartitionedPofCache",member=storage1,name=control,tier=back
Size: 0
Units: 0
Mbean: Coherence:Location=storage1,nodeId=2,type=Cache,cluster=CoherenceCluster,service="ExampleGAR:PartitionedPofCache",member=storage2,name=stores,tier=back
Size: 12
Units: 3488
Mbean: Coherence:Location=storage1,nodeId=1,type=Cache,cluster=CoherenceCluster,service="ExampleGAR:PartitionedPofCache",member=storage1,name=contacts,tier=back
Size: 10
Units: 3360
Mbean: Coherence:Location=storage1,nodeId=2,type=Cache,cluster=CoherenceCluster,service="ExampleGAR:PartitionedPofCache",member=storage2,name=contacts,tier=back
Size: 10
Units: 3352
Mbean: Coherence:Location=storage1,nodeId=2,type=Cache,cluster=CoherenceCluster,service="ExampleGAR:PartitionedPofCache",member=storage2,name=control,tier=back
Size: 0
Units: 0
Mbean: Coherence:Location=storage1,nodeId=1,type=Cache,cluster=CoherenceCluster,service="ExampleGAR:PartitionedPofCache",member=storage1,name=stores,tier=back
Size: 8
Units: 2328
例12-3 MBeanに対して永続性リカバリを強制するための操作の起動
この例では、forceRecovery
操作を起動して特定のサービスに対して永続性リカバリを強制する方法を示します。
# Return the Persistence coordinator MBean
def coh_getPersistenceCoordinator(serviceName):
query = 'Coherence:type=Persistence,service=' + serviceName + ',responsibility=PersistenceCoordinator,*'
beans = list(mbs.queryMBeans(ObjectName(query), None))
if len(beans) == 0:
raise RuntimeException('No results found')
for bean in beans:
return bean.getObjectName()
##
## Entry Point
##
connect("username","password", "t3://host:port")
# Enter the WebLogic Server administrator username, password, and the administration server host and port.
domainRuntime()
# if serviceName includes ':' it must be quoted
serviceName = '"ExampleGAR:PartitionedPofCache"'
objectName = coh_getPersistenceCoordinator(serviceName)
print 'Coordinator is ' + str(objectName)
mbs.invoke(objectName, 'forceRecovery', None, None)
print 'Force Recovery invoked'
例12-4 値を戻す操作の起動
この例では、PartitionAssignment
MBeanでreportScheduledDistributions
を起動することにより値を戻すMBean操作の起動方法を示します。
# Return the fully qualified Name for a query
def coh_getFullyQualifiedName(query):
beans = list(mbs.queryMBeans(ObjectName(query),None))
if len(beans) == 0:
raise RuntimeException('No results found')
for bean in beans:
return bean.getObjectName()
##
## Entry Point
##
connect("username","password", "t3://host:port")
# Enter the WebLogic Server administrator username, password, and the administration server host and port.
domainRuntime()
# if serviceName includes ':' it must be quoted
serviceName = '"ExampleGAR:PartitionedPofCache"'
partitionAssignment = coh_getFullyQualifiedName('Coherence:type=PartitionAssignment,service=' + serviceName + ',responsibility=DistributionCoordinator,*')
print 'Partition Assignment is ' + str(partitionAssignment)
print mbs.invoke(partitionAssignment, 'reportScheduledDistributions', [java.lang.Boolean("true")], ["boolean"])
出力例
Location changed to domainRuntime tree. This is a read-only tree
with DomainMBean as the root MBean.
For more help, use help('domainRuntime')
Partition Assignment is Coherence:service="ExampleGAR:PartitionedPofCache",cluster=CoherenceCluster,responsibility=DistributionCoordinator,Location=storage1,type=PartitionAssignment
No distributions are currently scheduled for this service.
例12-5 フェデレーション操作の起動
この例では、サービスのFederation
操作を起動する方法を示します。
# Return the fully qualified Name for a query
def coh_getFullyQualifiedName(query):
beans = list(mbs.queryMBeans(ObjectName(query),None))
if len(beans) == 0:
raise RuntimeException('No results found')
for bean in beans:
return bean.getObjectName()
##
## Entry Point
##
connect("username","password", "t3://host:port")
# Enter the WebLogic Server administrator username, password, and the administration server host and port.
domainRuntime()
# if serviceName includes ':' it must be quoted
serviceName = '"ExampleGAR:PartitionedPofCache"'
targetCluster = 'Boston'
command = 'start'
# Other Federation commands could be stop, pause or replicateAll
federation = coh_getFullyQualifiedName('Coherence:type=Federation,service=' + serviceName + ',responsibility=Coordinator,*')
print 'Federation MBean is ' + str(federation)
print mbs.invoke(federation, command, [java.lang.String(target)], ["java.lang.String"])
出力例
Location changed to domainRuntime tree. This is a read-only tree
with DomainMBean as the root MBean.
For more help, use help('domainRuntime')
Federation Mbean is Coherence:service="ExampleGAR:PartitionedPofCache",cluster=CoherenceCluster,responsibility=Coordinator,Location=storage1,type=Federation
親トピック: Coherenceクラスタの構成と管理
WLSTによるCoherenceキャッシュの保持
WLSTには、ディスクのキャッシュ済データの保持と回復に使用できる一連のコマンドがあります。コマンドは、管理サーバー・ドメインのランタイムMBeanサーバーに接続されている場合に自動で利用できます。
Coherenceキャッシュの永続性の詳細は、『Oracle Coherenceの管理』の「キャッシュの永続化」を参照してください。
表12-2に、Coherenceキャッシュを保持するためのWLSTコマンドを示します。例12-6に、コマンドの使用例を示します。
表12-2 WLSTのCoherence保持コマンド
コマンド | 説明 |
---|---|
|
サービスのデータ・パーティションをディスクに保持します
|
|
サービスのデータ・パーティションをディスクから復元します。サービスのキャッシュ内の既存データが失われます。
|
|
使用可能なスナップショットのリストを返します
|
|
エラーが発生せずにスナップショットが完了するかどうかを確認します
|
|
スナップショットを中央の場所に保存します。場所は、サービスに関連付けられているスナップショット・アーカイバ定義で指定します。
|
|
coh_recoverSnapshotコマンドを使用して回復できるように、アーカイブ済スナップショットを取得します
|
|
使用可能なアーカイブ済スナップショットのリストを返します
|
|
エラーが発生せずにアーカイブ済スナップショットが完了するかどうかを確認します。アーカイバを含む操作オーバーライド構成ファイルがクラスパスで利用できる必要があります。
|
|
アーカイブ済スナップショットをディスクから削除します
|
|
スナップショットをディスクから削除します
|
ノート:
serviceNameにコロン(:
)が含まれている場合は、二重引用符で囲みます。たとえば:coh_createSnapshot('Snapshot1', '"ExampleGAR:PartitionedPofCache"')
例12-6に、WLSTの永続性APIを使用してパーティション化キャッシュ・サービスのキャッシュを保持する例を示します。
例12-6 キャッシュを保持するためのWLSTの例
serviceName = '"ExampleGAR:ExamplesPartitionedPofCache"';
snapshotName = 'new-snapshot'
connect('weblogic','password','t3://machine:7001')
# Must be in domain runtime tree otherwise no MBeans are returned
domainRuntime()
try:
coh_listSnapshots(serviceName)
coh_createSnapshot(snapshotName, serviceName)
coh_listSnapshots(serviceName)
coh_recoverSnapshot(snapshotName, serviceName)
coh_archiveSnapshot(snapshotName, serviceName)
coh_listArchivedSnapshots(serviceName)
coh_removeSnapshot(snapshotName, serviceName)
coh_retrieveArchivedSnapshot(snapshotName, serviceName)
coh_recoverSnapshot(snapshotName, serviceName)
coh_listSnapshots(serviceName)
except PersistenceException, rce:
print 'PersistenceException: ' + str(rce)
except Exception,e:
print 'Unknown Exception' + str(e)
else:
print 'All operations complete'
親トピック: Coherenceクラスタの構成と管理