ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理
12c (12.1.2)
E48070-02
  目次へ移動
目次

前
 
次
 

12 Coherenceクラスタの構成と管理

この章では、WebLogic ServerドメインでCoherenceクラスタを定義する手順、およびCoherenceクラスタを複数のWebLogic Serverクラスタに関連付ける方法について説明します。この章の手順は、WebLogic Serverドメインがすでに作成されていることを前提としています。

この章の内容は次のとおりです。

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クラスタの概念を示します。

図12-1 Coherenceドメインのトポロジの概念

WLSドメイン内のCoherenceクラスタ
「図12-1 Coherenceドメインのトポロジの概念」の説明

Coherenceクラスタの設定

WebLogic Serverドメインには通常、単一のCoherenceクラスタが含まれます。クラスタは、単一のシステムレベル・リソース(CoherenceClusterSystemResource)として表されます。CoherenceClusterSystemResourceインスタンスは、管理コンソールまたはWLSTを使用して作成されます。

Coherenceクラスタには、任意の数の管理対象Coherenceサーバーを含めることができます。サーバーは、スタンドアロンの管理対象サーバーでも、Coherenceクラスタに関連付けられているWebLogic Serverクラスタのメンバーでもかまいません。通常、Coherenceクラスタには、複数のWebLogic Serverクラスタが関連付けられています。Coherenceが使用するWebLogic Serverクラスタの作成の詳細は、「Coherenceデプロイメント層の作成」を参照してください。


注意:

管理対象Coherenceサーバーをクローニングしても、Coherenceクラスタへの関連付けはクローニングされません。管理対象サーバーは、Coherenceクラスタのメンバーにはなりません。クローニングされた管理対象サーバーをCoherenceクラスタに手動で関連付ける必要があります。


Coherenceクラスタ・リソースの定義

Coherenceクラスタ・リソースを定義する手順は次のとおりです。

  1. WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「Coherenceクラスタ」をクリックします。

  2. 「Coherenceクラスタのサマリー」ページで、「新規」をクリックします。

  3. 「Coherenceクラスタ構成の作成」ページの「名前」フィールドに、クラスタの名前を入力します。「次へ」をクリックします。

  4. 「Coherenceクラスタのアドレス指定」セクションで、クラスタリング・モードを選択するか、デフォルトの設定のままにします。デフォルト設定は、開発およびテスト環境でのみお薦めします。ユニキャストを使用する場合は、すべてのクラスタ・メンバーが使用するデフォルト・ポートを選択します(通常は8088)。マルチキャストを使用する場合は、すべてのクラスタが使用するデフォルトのアドレスとポートを選択します。クラスタリング・モードの構成の詳細は、「クラスタ通信の構成」を参照してください。

  5. 「Coherenceクラスタ・メンバー」セクションで、Coherenceクラスタのメンバーとする管理対象CoherenceサーバーまたはWebLogic Serverクラスタをクリックして選択します。管理対象CoherenceサーバーおよびWebLogicクラスタがまだ定義されていない場合は、このセクションをスキップします。

  6. 「終了」をクリックします。「Coherenceクラスタのサマリー」画面が表示され、「Coherenceクラスタ」表にクラスタ・リソースが示されます。

スタンドアロンの管理対象Coherenceサーバーの作成

管理対象Coherenceサーバーは、Coherenceクラスタに関連付けられている管理対象サーバー・インスタンスです。管理対象Coherenceサーバーは、全体でCoherenceクラスタを形成し、多くの場合、クラスタ・メンバーと呼ばれます。クラスタ・メンバーには年功序列があり、古参のメンバーがクラスタ・タスク(クラスタ・ハート・ビートの発行など)を実行します。


注意:

  • WebLogic Serverドメイン内で管理されている管理対象Coherenceサーバーは、スタンドアロンのJVMクラスタ・メンバーから構成されている外部Coherenceクラスタに参加してはいけません。スタンドアロンのJVMクラスタ・メンバーを、WebLogic Serverドメイン内で管理することはできません。

  • 管理対象Coherenceサーバーは、Coherenceサーバーと同じではありません。管理対象Coherenceサーバーは、WebLogicサーバーのCoherence統合に固有のものです。Coherenceサーバー(以前のActiveCache統合で定義されたリソース)の使用は、非推奨となっており、下位互換性のためにサポートされています。

  • 管理サーバーは通常、本番環境では管理対象Coherenceサーバーとしては使用されません。


管理対象Coherenceサーバーは、クラスタにおけるそれぞれのロールによって区別されます。ベスト・プラクティスは、クラスタ・ロールごとに異なる管理対象サーバー・インスタンス(およびできれば異なるWebLogic Serverクラスタ)を使用することです。

  • ストレージが有効 – クラスタへのデータの格納を行う管理対象Coherenceサーバー。Coherenceアプリケーションは、グリッド・アーカイブ(GAR)としてパッケージ化され、ストレージが有効な管理対象Coherenceサーバーにデプロイされます。

  • ストレージが無効 – クラスタへのデータの格納を行わず、Coherenceアプリケーション(キャッシュ・クライアント)のホストに使用される管理対象Coherenceサーバー。CoherenceアプリケーションGARは、EAR内にパッケージ化され、ストレージが無効な管理対象Coherenceサーバーにデプロイされます。

  • プロキシ – ストレージが無効であり、かつ外部クライアント(非クラスタ・メンバー)によるキャッシュの使用を許可する管理対象Coherenceサーバー。CoherenceアプリケーションGARは、管理対象Coherenceプロキシ・サーバーにデプロイされます。

管理対象Coherenceサーバーを作成する手順は次のとおりです。

  1. WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。

  2. 「新規」をクリックして、新しい管理対象サーバーを作成します。

  3. 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。

  4. このサーバーをWebLogic Serverクラスタのメンバーとするかどうかを選択します。Coherenceデプロイメント層として使用するWebLogic Serverクラスタの作成の詳細は、「Coherenceデプロイメント層の作成」を参照してください。

  5. 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。

  6. 新しいサーバーを選択して、その設定を構成します。

  7. 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこの管理対象サーバーに関連付けます。デフォルトでは、管理対象サーバーは、「ローカル記憶域有効」フィールドに示されているとおり、ストレージが有効なCoherenceメンバーです。管理対象Coherence設定の変更の詳細は、「管理対象Coherenceサーバーの構成」を参照してください。

  8. 「保存」をクリックします。「サーバーのサマリー」ページが表示されます。

  9. 「サーバーのサマリー」ページで、「制御」タブをクリックし、サーバーを起動します。

Coherenceデプロイメント層の作成

Coherenceは、WebLogic Serverドメイン内で複数のトポロジをサポートしており、それにより、様々なレベルのパフォーマンス、スケーラビリティおよび使いやすさが提供されます。たとえば、開発時、単一のスタンドアロンの管理対象サーバー・インスタンスを、キャッシュ・サーバーとキャッシュ・クライアントの両方として使用できます。単一サーバー・トポロジは、設定と使用が容易ですが、最適なパフォーマンスまたはスケーラビリティを提供しません。本番では、Coherenceは通常、WebLogic Serverクラスタを使用して設定されます。あるWebLogic Serverクラスタは、Coherenceデータ層として使用され、1つ以上のキャッシュ・サーバーをホストします。別のWebLogic Serverクラスタは、Coherenceアプリケーション層として使用され、1つ以上のキャッシュ・クライアントをホストします。そして、(必要に応じて)また別のWebLogic Serverクラスタは、Coherenceプロキシ層で使用され、1つ以上の管理対象Coherenceプロキシ・サーバー、および拡張クライアントをホストするCoherence拡張クライアント層をホストします。層になったトポロジを使用することで、最適なスケーラビリティとパフォーマンスが得られます。

この項の手順では、管理コンソールのクラスタ設定ページとサーバー設定ページの両方を使用して、Coherenceデプロイメント層を作成します。WebLogic Serverクラスタおよび管理対象サーバー・インスタンスは、それぞれClusterMBeanおよびServerMBean MBeanを使用して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データ層を作成する手順は次のとおりです。

  1. WebLogic Serverクラスタを作成します。詳細は、第10章「WebLogicクラスタの設定」を参照してください。

  2. 「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。

  3. 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。デフォルトでは、このWebLogic Serverクラスタに割り当てられる管理対象サーバーは、「ローカル記憶域有効」フィールドに示されているとおり、ストレージが有効なCoherenceメンバーになります。

データ層の管理対象Coherenceサーバーの作成

Coherenceデータ層の管理対象サーバーを作成する手順は次のとおりです。

  1. WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。

  2. 「新規」をクリックして、新しい管理対象サーバーを作成します。

  3. 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。

  4. 「はい」オプションをクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してデータ層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic ServerクラスタからCoherence設定を継承します。

  5. 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。

  6. これらの手順を繰り返して、必要に応じて追加の管理対象サーバーを作成します。

  7. 「制御」タブで、起動するサーバーを選択し、「起動」をクリックします。

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アプリケーション層を作成する手順は次のとおりです。

  1. WebLogic Serverクラスタを作成します。詳細は、第10章「WebLogicクラスタの設定」を参照してください。

  2. 「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。

  3. 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。

  4. 「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、アプリケーション層でストレージを無効にします。このWebLogic Serverクラスタに割り当てられる管理対象Coherenceサーバーは、ストレージが無効なCoherenceメンバー(キャッシュ・ファクトリ・クライアント)になります。アプリケーション層内のサーバーは、キャッシュ・データの格納には使用しないでください。ストレージが有効なサーバーは、データを格納および分散するためのリソースを必要とし、クライアントのパフォーマンスに悪影響を与えるおそれがあります。

  5. 「保存」をクリックします。

アプリケーション層の管理対象Coherenceサーバーの作成

Coherenceアプリケーション層の管理対象サーバーを作成する手順は次のとおりです。

  1. WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。

  2. 「新規」をクリックして、新しい管理対象サーバーを作成します。

  3. 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。

  4. 「はい」オプションをクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してアプリケーション層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic ServerクラスタからCoherence設定を継承します。

  5. 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。

  6. これらの手順を繰り返して、必要に応じて追加の管理対象サーバーを作成します。

  7. 「制御」タブで、起動するサーバーを選択し、「起動」をクリックします。

Coherenceプロキシ層の構成と管理

Coherenceプロキシ層は、Coherenceクラスタに関連付けられているWebLogic Serverクラスタであり、任意の数の管理対象Coherenceプロキシ・サーバーをホストします。管理対象Coherenceプロキシ・サーバーにより、Coherence*Extendクライアントは、クラスタ・メンバーにならなくてもCoherenceキャッシュを使用することが可能になります。プロキシ層で必要な管理対象Coherenceプロキシ・サーバーの数は、予想されるクライアントの数によって異なります。ロード・バランシングを可能にするには、少なくとも2台のプロキシ・サーバーを作成する必要があります。ただし、多数のクライアント接続およびリクエストをサポートする場合は、追加のサーバーが必要になることがあります。

Coherence*Extendおよび拡張クライアントの作成の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

Coherenceプロキシ層の作成

Coherenceプロキシ層を作成する手順は次のとおりです。

  1. WebLogic Serverクラスタを作成します。詳細は、第10章「WebLogicクラスタの設定」を参照してください。

  2. 「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。

  3. 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。

  4. 「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、プロキシ層でストレージを無効にします。プロキシ・サーバーは、キャッシュ・データの格納には使用しないでください。プロキシ・サービスによって、ストレージが有効なクラスタ・メンバーが悪影響を受けるおそれがあります。プロキシ・サービスは、クライアント負荷の処理に追加のリソースを必要とします。

  5. 「保存」をクリックします。

プロキシ層の管理対象Coherenceサーバーの作成

Coherenceプロキシ層の管理対象サーバーを作成する手順は次のとおりです。

  1. WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。

  2. 「新規」をクリックして、新しい管理対象サーバーを作成します。

  3. 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。

  4. 「はい」オプションをクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してプロキシ層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic ServerクラスタからCoherence設定を継承します。

  5. 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。

  6. これらの手順を繰り返して、必要に応じて追加の管理対象サーバーを作成します。

  7. 「制御」タブで、起動するサーバーを選択し、「起動」をクリックします。

Coherenceプロキシ・サービスの構成

Coherenceプロキシ・サービスは、拡張クライアントからのリモート接続を管理するクラスタ化されたサービスです。プロキシ・サービスは、<proxy-scheme要素内のcoherence-cache-config.xmlファイルで定義および構成されます。定義には、その他の設定の他に、クライアント接続の受入に使用されるTCPリスナー・アドレス(IPまたはDNS名、およびポート)があります。<proxy-scheme要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。プロキシ・サービスを設定する方法は2つあります。1つはネーム・サービスを使用する方法、もう1つはアドレス・プロバイダを使用する方法です。ネーミング・サービスを使用すると、効率的な設定を行うことができ、Coherenceプロキシ層では通常、ネーミング・サービスの使用が推奨されます。

ネーム・サービスの使用

ネーム・サービスは、拡張クライアントがプロキシ・サービスに名前で接続できるようにする専用のリスナーです。クライアントは、ネーム・サービスに接続し、ネーム・サービスは、クラスタ上のすべてのプロキシ・サービスのアドレスを戻します。


注意:

ドメインに複数の層(データ層、アプリケーション層、プロキシ層など)が含まれている場合、クライアントがプロキシに接続できるようにするために、まずプロキシ層を起動する必要があります。


プロキシ・サービスを管理対象Coherenceプロキシ・サーバー上で構成すると、ネーム・サービスがポート8088 (TCMPソケットが使用するものと同じデフォルト・ポート)で自動的に起動します。さらに、複数のプロキシ・サービスが、TCMPソケットが使用するものと同じリスニング・ポートを使用することも可能です。同じポートを再利用することで、Coherenceが使用するポートの数を最小限に抑え、ファイアウォール構成を簡素化できます。

プロキシ・サービスを構成し、デフォルトのTCMPポート上でネーム・サービスを有効にする手順は次のとおりです。

  1. coherence-cache-config.xmlファイルを編集し、<proxy-scheme>定義を作成します。この際、ソケット・アドレスは明示的に定義しないでください。次の例では、TCMPが使用するものと同じホストとポートにバインドされる、TcpExtendという名前のプロキシ・サービスを定義し、同じホストとポート上でネーム・サービスを有効にします。

    ...
    <caching-schemes>
       ...
       <proxy-scheme>
          <service-name>TcpExtend/service-name>
          <acceptor-config/>
          <autostart>true</autostart>
       </proxy-scheme>
    </caching-schemes>
    ...
    
  2. Coherenceプロキシ層内の管理対象Coherenceプロキシ・サーバーそれぞれにcoherence-cache-config.xmlファイルをデプロイします。通常、coherence-cache-config.xmlファイルは、GARファイル内に含まれています。ただし、プロキシ層では、クラスタ・キャッシュ構成ファイルを使用します。これにより、単一のGARをクラスタおよびプロキシ層にデプロイして、GARにあるcoherence-cache-config.xmlファイルをオーバーライドすることができます。クラスタ・キャッシュ構成ファイルの使用の詳細は、「キャッシュ構成ファイルのオーバーライド」を参照してください。

ネーム・サービスに接続するには、クライアントのcoherence-cache-config.xmlファイルのリモート・キャッシュまたはリモート呼出し定義の<tcp-initiator要素内に、<name-service-addresses要素が含まれている必要があります。<name-service-addresses要素は、管理対象Coherenceプロキシ・サーバー上のネーム・サービスのソケット・アドレスを提供します。次の例では、リモート・キャッシュを定義し、ポート8088でホスト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>8088</port>
            </socket-address>
         </name-service-addresses>
      </tcp-initiator>
   </initiator-config>
</remote-cache-scheme>

注意:

  • <service-name>値は、プロキシ・スキームの<service-name>値に一致している必要があります。それ以外の場合、プロキシ・スキーム内で構成されている<service-name>要素の値を含むリモート・キャッシュおよびリモート呼び出しスキームで、<proxy-service-name>要素も提供する必要があります。

  • アドレス・プロバイダを使用して、ネーム・サービス・アドレスを指定することもできます。


アドレス・プロバイダの使用

アドレス・プロバイダは、プロキシ・サービスのTCPリスナー・アドレス(IPまたはDNS名、およびポート)を指定します。リスナー・アドレスは、coherence-cache-config.xmlファイルの<proxy-scheme>要素で明示的に定義できます。ただし、望ましい方法は、クラスタ構成ファイルでアドレス・プロバイダを定義し、<proxy-scheme>要素内からアドレスを参照することです。後者の方法では、アプリケーション構成からデプロイメント構成を分離し、coherence-cache-config.xmlファイルを更新せずにネットワーク・アドレスを変更することが可能です。

アドレス・プロバイダを使用する手順は次のとおりです。

  1. Coherenceクラスタの「設定」ページの「アドレス・プロバイダ」タブを使用して、アドレス・プロバイダ定義を作成します。CoherenceAddressProvidersBean MBeanも、アドレス・プロバイダ定義を公開します。アドレス・プロバイダには、プロキシ・サービスのリスナー・アドレスに加えて、一意の名前が含まれます。たとえば、proxy1というアドレス・プロバイダでは、リスナー・アドレスとしてホスト192.168.1.5およびポート9099を指定することが考えられます。

  2. 手順1を繰り返し、各プロキシ・サービスのアドレス・プロバイダ定義を作成します(それぞれの管理対象Coherenceプロキシ・サーバーについて少なくとも1つ)。

  3. 管理対象Coherenceプロキシ・サーバーそれぞれについて、coherence-cache-config.xmlファイルを編集し、<proxy-scheme>定義を作成して、<address-provider>要素内のアドレス・プロバイダ定義を名前で参照します。次の例では、proxy1というアドレス・プロバイダを参照するプロキシ・サービスを定義します。

    ...
    <caching-schemes>
       <proxy-scheme>
          <service-name>TcpExtend</service-name>
          <acceptor-config>
             <tcp-acceptor>
                <address-provider>proxy1</address-provider>
             </tcp-acceptor>
          </acceptor-config>
          <autostart>true</autostart>
       </proxy-scheme>
    </caching-schemes>
    ...
    
  4. coherence-cache-config.xmlファイルを、それぞれの管理対象Coherenceプロキシ・サーバーにデプロイします。通常、coherence-cache-config.xmlファイルは、GARファイル内に含まれています。ただし、プロキシ層では、クラスタ・キャッシュ構成ファイルを使用します。これにより、単一のGARをクラスタおよびプロキシ層にデプロイして、GARにある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クラスタの設定」を参照してください。この項には、Coherenceの保護に関する説明は含まれていません。セキュリティの詳細は、『Oracle Coherenceの保護』を参照してください。

Coherenceクラスタの「設定」ページの「Coherence」タブを使用して、クラスタ通信を構成します。CoherenceClusterSystemResource MBeanおよびそれに関連付けられているCoherenceClusterResource MBeanがクラスタ設定を公開します。CoherenceClusterResource MBeanは、Coherenceクラスタを構成するために複数のMBeanにアクセスできるようにします。

Coherenceクラスタ・メンバーの追加と削除

既存のどの管理対象サーバー・インスタンスも、Coherenceクラスタに追加できます。さらに、管理対象Coherenceサーバーをクラスタから削除できます。クラスタ・メンバーの追加と削除は、Coherenceクラスタの構成時に行うことができ、各インスタンスを明示的に構成するかわりに使用できる簡便な方法です。ただし、既存の管理対象サーバー・インスタンスを追加する場合は、デフォルトのCoherence設定を変更する必要があります。管理対象Coherenceサーバーの構成の詳細は、「管理対象Coherenceサーバーの構成」を参照してください。

Coherenceクラスタの「設定」ページの「メンバー」タブを使用して、Coherenceクラスタに関連付ける管理対象サーバーまたはWebLogic Serverクラスタを選択します。WebLogic Serverクラスタを選択する場合は、WebLogic Serverクラスタ内のすべての管理対象サーバーをCoherenceクラスタに関連付けることをお薦めします。CoherenceClusterSystemResourceは、すべての管理対象Coherenceサーバーをターゲットとして公開します。CoherenceMemberConfig MBeanが各管理対象サーバーに対して作成され、Coherenceクラスタ・メンバーのパラメータを公開します。

クラスタ構成の詳細オプションの設定

WebLogic Server MBeanは、ほとんどのユースケースで十分なCoherence操作設定のサブセットを公開します。これについては、この章全体で詳細に説明します。これらの設定は、WLSTユーティリティおよび管理コンソールでネイティブに使用できます。より高度なユースケースでは、外部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

クラスタ通信の構成

クラスタ・メンバーは、Tangosol Cluster Management Protocol (TCMP)を使用して通信します。このプロトコルは、WLSクラスタ・プロトコルとは関係なく動作します。TCMPは、クラスタ・メンバーの検出、クラスタの管理、サービスのプロビジョニングおよびデータの送信を行うためのIPベースのプロトコルです。TCMPでは、様々なトランスポート・プロトコルを介して送信でき、マルチキャストとユニキャストの両方を使用できます。デフォルトでは、TCMPは、UDPを介して送信され、ユニキャストを使用します。別のトランスポート・プロトコルおよびマルチキャストを使用する場合は、基礎となるネットワークがそれをサポートしている必要があります。

Coherenceクラスタの「設定」ページの「全般」タブを使用して、クラスタ通信を構成します。CoherenceClusterParamsBeanおよびCoherenceClusterWellKnownAddressesBean MBeanは、クラスタ通信パラメータを公開します。

Coherenceクラスタ・モードの変更

Coherenceクラスタは、ユニキャスト通信とマルチキャスト通信の両方をサポートしています。マルチキャストは、デフォルトのオプションではありません。明示的に構成する必要があります。マルチキャストが適切にサポートされていない環境やマルチキャストが許可されていない環境では、マルチキャストの使用は避けてください。ユニキャストの使用により、すべてのマルチキャスト送信は無効になり、自動的にCoherence Well Knownアドレス(WKA)機能を使用して、クラスタ・メンバーの検出およびクラスタ・メンバー間の通信が行われます。ユニキャストを使用する際、クラスタに対してWKAメンバーが定義されていない場合は、システムによりWKAメンバーが自動的に割り当てられます。


注意:

ユニキャストを使用する際は、WKAメンバーを常に明示的に指定するのがベスト・プラクティスです。システムにより割り当てられるWKAメンバー機能は、単一のサーバー上でのテストおよび開発向けの設計にすぎず、オフセット・アルゴリズムを使用してポートが選択されているため、ポートの競合が発生することがあります。さらに、システムの割当てによるWKAメンバー設定を使用した場合、別のサーバー上のクラスタ・メンバーがクラスタへの参加できないことがあります。


Coherenceでのマルチキャスト、ユニキャストおよびWKAの使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

Coherenceクラスタ・モードでのユニキャストの選択

クラスタ通信でユニキャストを使用するには、「クラスタリング・モード」ドロップダウン・リストから「ユニキャスト」を選択し、ユニキャスト・ポートを入力するか、デフォルト・ポート0のままにします。(ポートが0の場合、管理対象サーバー・ポートのオフセット・アルゴリズムを使用してユニキャスト・リスニング・ポートが決定されます。)クラスタ・メンバーが別のポートを明示的に指定しないかぎり、この構成済のポートが、すべてのクラスタ・メンバーによって使用されるデフォルト・ポートになります。クラスタ・メンバーのデフォルト・ユニキャスト・ポートのオーバーライドの詳細は、「Coherenceクラスタ・メンバーのユニキャスト設定の構成」を参照してください。どのクラスタ・メンバーをWKAメンバーとして使用するかを明示的に構成するには、「Well Knownアドレス」タブを使用します。


注意:

  • WKAメンバーは、ユニキャスト・ポートと同じポートを使用する必要があります。

  • WKAメンバーは、本番環境で明示的に定義される必要があります。本番モードで、WKAメンバーが明示的に定義されていない場合、管理対象Coherenceサーバーは起動に失敗します。自動的に割り当てられたWKAメンバーは、設計時の便宜を図るためのもので、開発時に単一サーバー上でのみ使用できます。


Coherenceクラスタ・モードでのマルチキャストの選択

クラスタ通信でマルチキャストを使用するには、「クラスタリング・モード」ドロップダウン・リストから「マルチキャスト」を選択し、一意のマルチキャスト・アドレスおよびポートを入力します。

「存続時間」フィールドを使用して、マルチキャスト・パケットが到達できるネットワーク範囲を指定します。存続時間値(TTL)はパケットが存続し続けるホップの数で表現されます。1つのネットワーク・インタフェース、ルーターまたは管理対象スイッチが1ホップと見なされます。TTL値には、実効性のある最も小さい整数値を指定します。

Coherenceクラスタ・トランスポート・プロトコルの変更

次のトランスポート・プロトコルは、TCMPでサポートされており、「トランスポート」ドロップダウン・リストを使用して選択できます。CoherenceClusterParamsBean MBeanは、トランスポート・プロトコル設定を公開します。

  • ユーザー・データグラム・プロトコル(UDP) – UDPは、デフォルトのTCMPトランスポート・プロトコルで、マルチキャスト通信とユニキャスト通信の両方に使用されます。マルチキャストが無効な場合、すべての通信はUDPユニキャストを使用して行われます。

  • 伝送制御プロトコル(TCP) – TCPトランスポート・プロトコルは、TCP通信が優先されているネットワーク環境で使用されます。ユニキャストが有効な場合、すべてのTCMP通信はTCPを使用します。マルチキャストが有効な場合、TCPはユニキャスト通信でのみ使用され、マルチキャスト通信にはUDPが使用されます。

  • Secure Sockets Layer (SSL) – SSL/TCPトランスポート・プロトコルは、クラスタ・メンバー間で高度にセキュアな通信が必要なネットワーク環境で使用されます。SSLは、ユニキャスト通信でのみサポートされています。SSLを使用する場合は、マルチキャストを無効にしてください。SSLを使用するには、追加の構成が必要です。WebLogic Server内のCoherenceの保護の詳細は、『Oracle Coherenceの保護』を参照してください。

  • TCPメッセージ・バス(TMB) – TMBプロトコルは、TCP/IPのサポートを提供します。

  • ソケット・ダイレクト・プロトコル・メッセージ・バス(SDMB) – ソケット・ダイレクト・プロトコル(SDP)は、ストリーム接続のサポートを提供します。SDMBは、Exalogicでのみ有効です。

  • インフィニバンド・メッセージ・バス(IMB) – IMBは、ネイティブのInfiniBand Verbに基づいた最適なプロトコルを使用します。IMBは、Exalogicでのみ有効です。

キャッシュ構成ファイルのオーバーライド

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アプリケーションの開発』を参照してください。

次の例では、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クラスタの「設定」ページにあります)を使用して、クラスタ・ロギングを構成します。または、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サーバーの構成

管理対象Coherenceサーバーは、特定のドメイン用に構成可能ないくつかのクラスタ・メンバー設定を公開します。次のタスクを使用して、管理対象Coherenceサーバーを構成します。

多くの設定では、必要に応じて変更可能なデフォルト値が使用されます。次の手順は、管理対象サーバーがすでに作成されて、Coherenceクラスタに関連付けられていることを前提としています。管理対象Coherenceサーバーの作成の詳細は、「スタンドアロンの管理対象Coherenceサーバーの作成」を参照してください。

管理対象サーバーの「設定」ページの「Coherence」タブを使用して、Coherenceクラスタ・メンバー設定を構成します。CoherenceMemberConfig MBeanが各管理対象サーバーに対して作成され、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セッション・マネージメントの管理』を参照してください。

Coherenceクラスタ・メンバーのユニキャスト設定の構成

管理対象Coherenceサーバーは、ユニキャスト(ポイント・ツー・ポイント)通信を使用して相互に通信します。クラスタがマルチキャスト通信を使用するように構成されている場合でも、ユニキャストが使用されます。Coherenceにおけるユニキャストの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

「Coherence」タブ上の次のフィールドを使用して、ユニキャスト設定を構成します。

  • ユニキャスト・リスニング・アドレス – このフィールドでは、サーバーがユニキャスト通信をリスニングするアドレスを指定します。クラスタ・メンバーは、java.net.InetAddress.getLocalHost()呼出しを使用して、バインド先のIPを取得しようとします。ローカルホストがループバック・アドレスとして定義されているシステムでは、ローカルホストの使用は機能しません。その場合、コンピュータ名または具体的なIPアドレスを指定する必要があります。コンピュータに複数のIPまたはNICがある場合は、アドレスも明示的に指定する必要があります。アドレス・フィールドでは、クラスレス・ドメイン間ルーティング(CIDR)表記法もサポートされています。この表記法は、正確なIPアドレスを指定するかわりに、バインド先のローカルIPアドレスのサブネットおよびマスク・パターンを使用します。

  • ユニキャスト・リスニング・ポート – このフィールドでは、サーバーがユニキャスト通信をリスニングするポートを指定します。クラスタ・メンバーは、2つのユニキャストUDPポートを使用します。すべてのクラスタ・メンバー用に構成されているデフォルト・ポート(0という値で示されます)と、次に使用可能なポートです。すべてのクラスタ・メンバーに向けて構成されたデフォルト・ポートの変更の詳細は、「Coherenceクラスタ・モードでのユニキャストの選択」を参照してください。デフォルト・ポートが使用できない場合は、別のポートを入力します。または、「ユニキャスト・ポートの自動調整」オプションを選択して、ポートが自動的に選択されるようにします。

  • ユニキャスト・ポートの自動調整 – このフィールドでは、デフォルト・ポートがすでに使用されている場合、ポートを自動的に増分するかどうかを指定します。

Coherenceクラスタ・メンバーのID設定の構成

クラスタ内の管理対象CoherenceサーバーにIDを付与するために、一連の識別子が使用されます。ID情報は、クラスタ内でサーバーを区別し、サーバーのロールを伝達するために使用されます。一部のIDは、クラスタ・タスクの実行時にクラスタ・サービスによっても使用されます。最後に、管理情報(JMXなど)を表示する際は、ID情報が役に立ちます。また、ID情報により、ログ・エントリの解釈が容易になります。

「Coherence」タブ上の次のフィールドを使用して、メンバーID設定を構成します。

  • サイト名 – このフィールドでは、管理対象Coherenceサーバーをホストしている地理的サイトの名前を指定します。名前が指定されない場合、サーバーのドメイン名が使用されます。WANクラスタリングの場合、この値は、メンバーが存在するデータセンターを識別します。インテリジェントなルーティング、ロード・バランシングおよび障害回復計画(つまり、別の地理的サイトにあるデータの明示的なバックアップ)の基盤として、サイト名を使用できます。サイト名は、分散キャッシングの使用時のデータのバックアップ先や、デフォルト・パーティションの割当て戦略を決定するために役立ちます。最後に、管理情報(JMXなど)を表示したり、ログ・エントリを解釈したりする際は、名前が役に立ちます。

  • ラック名 – このフィールドでは、管理対象Coherenceサーバーがホストされている地理的サイト内の場所の名前を指定します。これは多くの場合、ケージ、ラックまたはブレードフレームの識別子です。インテリジェントなルーティング、ロード・バランシングおよび障害回復計画(つまり、別のブレードフレームにあるデータの明示的なバックアップ)の基盤として、ラック名を使用できます。ラック名は、分散キャッシングの使用時のデータのバックアップ先や、デフォルト・パーティションの割当て戦略を決定するために役立ちます。最後に、管理情報(JMXなど)を表示したり、ログ・エントリを解釈したりする際は、名前が役に立ちます。

  • ロール名 – このフィールドでは、クラスタにおける管理対象Coherenceサーバーのロールを指定します。ロール名により、アプリケーションは、クラスタ・メンバーを、ストレージが有効、ストレージが無効など、特化したロールに編成することができます。

    管理対象CoherenceサーバーがWebLogic Serverクラスタのメンバーである場合、ロール名としてクラスタ名が自動的に使用され、このフィールドを設定することはできません。名前が指定されない場合、使用されるデフォルトのロール名はWebLogicServerです。

単一サーバー・クラスタの使用

単一サーバー・クラスタは、単一の管理対象サーバー・インスタンス上で実行するように制限されている、ネットワークにアクセスしないクラスタです。サーバー・インスタンスは、ストレージが有効なクラスタ・メンバー、クライアントおよびプロキシとして機能します。単一サーバー・クラスタは、セットアップが容易で、クラスタを起動および停止するための簡単な方法を提供します。単一サーバー・クラスタは、開発時に使用されます。本番環境またはテスト環境では使用しないでください。

単一サーバー・クラスタを作成する手順は次のとおりです。

Coherenceクラスタ設定でのWLST(オフライン)の使用

WebLogic Scripting Tool (WLST)は、Coherenceクラスタの構成と管理などのドメイン構成タスクの自動化に使用できるコマンドライン・インタフェースです。WLSTの詳細は、『WebLogic Scripting Toolの理解』を参照してください。

次の例では、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('/')
assign('Cluster','DataTier','CoherenceClusterSystemResource','myCoherenceCluster')

cd('/CoherenceClusterSystemResource/myCoherenceCluster')
set('Target', 'DataTier')

Coherenceクラスタ・パラメータの構成

cd('CoherenceClusterSystemResource/myCoherenceCluster/CoherenceResource/
myCoherenceCluster/CoherenceClusterParams/NO_NAME_0')
set('ClusteringMode', 'unicast')
set('SecurityFrameworkEnabled','false')
set('UnicastListenAddress', '192.168.0.100')
set('UnicastListenPort', 8088)
set('UnicastPortAutoAdjust', 'true')

Well Knownアドレスの構成

create('wka_config','CoherenceClusterWellKnownAddresses')
cd('CoherenceClusterWellKnownAddresses/NO_NAME_0')
 
create('WKA1','CoherenceClusterWellKnownAddress')
cd('CoherenceClusterWellKnownAddress/WKA1')
set('ListenAddress', '192.168.0.100')
set('ListenPort', 8088) 
cd('../..')

create('WKA2','CoherenceClusterWellKnownAddress')
cd('CoherenceClusterWellKnownAddress/WKA2')
set('ListenAddress', '192.168.0.101')
set('ListenPort', 8088)

ロギング・プロパティの設定

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('Server/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', 8088)
set('UnicastPortAutoAdjust', 'true')

cd('/')
cd('Server/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', 8088)
set('UnicastPortAutoAdjust', 'true')

updateDomain()
closeDomain()