この章では、WebLogic Server 12.1.3において、WebLogic ServerドメインでCoherenceクラスタを定義する手順、およびCoherenceクラスタを複数のWebLogic Serverクラスタに関連付ける方法について説明します。この章の手順は、WebLogic Serverドメインがすでに作成されていることを前提としています。
この章の内容は次のとおりです。
Coherenceクラスタは、アプリケーションのスケーラビリティ、可用性およびパフォーマンスを向上させるためにデータをメモリー内に分散する、複数の管理対象Coherenceサーバー・インスタンスで構成されています。アプリケーションは、ローカル・キャッシュ内のデータと相互作用し、データの分散とバックアップは、クラスタ・メンバー間で自動的に実行されます。
Coherenceクラスタは、WebLogic Serverクラスタとは異なります。これらのクラスタは、別のクラスタリング・プロトコルを使用し、別々に構成されます。複数のWebLogic ServerクラスタをCoherenceクラスタに関連付けることができ、WebLogic Serverドメインには通常、単一のCoherenceクラスタが含まれます。Coherenceクラスタ・メンバーとして構成されている管理対象サーバーは、管理対象Coherenceサーバーと呼ばれます。
管理対象Coherenceサーバーは、Coherenceクラスタに明示的に関連付けることができます。または、Coherenceクラスタに関連付けられているWebLogic Serverクラスタに関連付けることも可能です。管理対象Coherenceサーバーは通常、タイプに基づいた層(データを格納する場合はデータ層、アプリケーションをホストする場合はアプリケーション層、および外部クライアントがキャッシュにアクセスできるようにするにはプロキシ層)で設定されます。
図12-1に、WebLogic Serverドメイン内の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クラスタ・リソースを定義する手順は次のとおりです。
WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「Coherenceクラスタ」をクリックします。
「Coherenceクラスタのサマリー」ページで、「新規」をクリックします。
「Coherenceクラスタ構成の作成」ページの「名前」フィールドに、クラスタの名前を入力します。「次へ」をクリックします。
「Coherenceクラスタのアドレス指定」セクションで、クラスタリング・モードを選択するか、デフォルトの設定のままにします。デフォルト設定は、開発およびテスト環境でのみお薦めします。ユニキャストを使用する場合は、すべてのクラスタ・メンバーが使用するデフォルト・ポートを選択します(通常は8088)。マルチキャストを使用する場合は、すべてのクラスタが使用するデフォルトのアドレスとポートを選択します。クラスタリング・モードの構成の詳細は、「クラスタ通信の構成」を参照してください。
「Coherenceクラスタ・メンバー」セクションで、Coherenceクラスタのメンバーとする管理対象CoherenceサーバーまたはWebLogic Serverクラスタをクリックして選択します。管理対象CoherenceサーバーおよびWebLogicクラスタがまだ定義されていない場合は、このセクションをスキップします。
「終了」をクリックします。「Coherenceクラスタのサマリー」画面が表示され、「Coherenceクラスタ」表にクラスタ・リソースが示されます。
管理対象Coherenceサーバーは、Coherenceクラスタに関連付けられている管理対象サーバー・インスタンスです。管理対象Coherenceサーバーは、全体で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は、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
MBeanを使用してCoherenceクラスタ・リソースに関連付けることができます。WebLogic Serverクラスタに関連付けられている管理対象サーバーは、クラスタのCoherence設定を継承します。ただし、設定はサーバー設定ページに反映されない場合があります。
Coherenceデータ層は、Coherenceクラスタに関連付けられているWebLogic Serverクラスタであり、ストレージが有効な任意の数の管理対象Coherenceサーバーをホストします。データ層内の管理対象Coherenceサーバーは、クラスタに(プライマリとバックアップの両方の)データを格納および分散します。データ層で必要な管理対象Coherenceサーバーの数は、Coherenceクラスタ内に格納されるデータの予想量および各サーバーで使用可能なメモリー量によって異なります。さらに、コンピュータの障害の際にデータが失われる可能性を回避するために、クラスタには、少なくとも4台の物理コンピュータが含まれている必要があります。
Coherenceアーティファクト(Coherence構成ファイル、POFシリアライゼーション・クラス、フィルタ、エントリ・プロセッサ、Aggregatorなど)は、GARとしてパッケージ化され、データ層にデプロイされます。Coherenceアプリケーションのパッケージ化とデプロイの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。キャッシュ・サイズの計算およびハードウェア要件の詳細は、『Oracle Coherenceの管理』の本番環境に移行する際のチェックリストを参照してください。
Coherenceデータ層を作成する手順は次のとおりです。
WebLogic Serverクラスタを作成します。詳細は、第10章「WebLogicクラスタの設定」を参照してください。
「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。
「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。デフォルトでは、このWebLogic Serverクラスタに割り当てられる管理対象サーバーは、「ローカル記憶域有効」フィールドに示されているとおり、ストレージが有効なCoherenceメンバーになります。
Coherenceデータ層の管理対象サーバーを作成する手順は次のとおりです。
WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。
「新規」をクリックして、新しい管理対象サーバーを作成します。
「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。
「はい」オプションをクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してデータ層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic Serverクラスタから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アプリケーション層を作成する手順は次のとおりです。
WebLogic Serverクラスタを作成します。詳細は、第10章「WebLogicクラスタの設定」を参照してください。
「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。
「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。
「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、アプリケーション層でストレージを無効にします。このWebLogic Serverクラスタに割り当てられる管理対象Coherenceサーバーは、ストレージが無効なCoherenceメンバー(キャッシュ・ファクトリ・クライアント)になります。アプリケーション層内のサーバーは、キャッシュ・データの格納には使用しないでください。ストレージが有効なサーバーは、データを格納および分散するためのリソースを必要とし、クライアントのパフォーマンスに悪影響を与えるおそれがあります。
「保存」をクリックします。
Coherenceアプリケーション層の管理対象サーバーを作成する手順は次のとおりです。
WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。
「新規」をクリックして、新しい管理対象サーバーを作成します。
「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。
「はい」オプションをクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してアプリケーション層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic ServerクラスタからCoherence設定を継承します。
「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。
これらの手順を繰り返して、必要に応じて追加の管理対象サーバーを作成します。
「制御」タブで、起動するサーバーを選択し、「起動」をクリックします。
Coherenceプロキシ層は、Coherenceクラスタに関連付けられているWebLogic Serverクラスタであり、任意の数の管理対象Coherenceプロキシ・サーバーをホストします。管理対象Coherenceプロキシ・サーバーにより、Coherence*Extendクライアントは、クラスタ・メンバーにならなくてもCoherenceキャッシュを使用することが可能になります。プロキシ層で必要な管理対象Coherenceプロキシ・サーバーの数は、予想されるクライアントの数によって異なります。ロード・バランシングを可能にするには、少なくとも2台のプロキシ・サーバーを作成する必要があります。ただし、多数のクライアント接続およびリクエストをサポートする場合は、追加のサーバーが必要になることがあります。
Coherence*Extendおよび拡張クライアントの作成の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。
Coherenceプロキシ層を作成する手順は次のとおりです。
WebLogic Serverクラスタを作成します。詳細は、第10章「WebLogicクラスタの設定」を参照してください。
「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。
「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。
「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、プロキシ層でストレージを無効にします。プロキシ・サーバーは、キャッシュ・データの格納には使用しないでください。プロキシ・サービスによって、ストレージが有効なクラスタ・メンバーが悪影響を受けるおそれがあります。プロキシ・サービスは、クライアント負荷の処理に追加のリソースを必要とします。
「保存」をクリックします。
Coherenceプロキシ層の管理対象サーバーを作成する手順は次のとおりです。
WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。
「新規」をクリックして、新しい管理対象サーバーを作成します。
「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。
「はい」オプションをクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してプロキシ層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic Serverクラスタから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ポート上でネーム・サービスを有効にする手順は次のとおりです。
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> ...
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>
注意:
|
アドレス・プロバイダは、プロキシ・サービスのTCPリスナー・アドレス(IPまたはDNS名、およびポート)を指定します。リスナー・アドレスは、coherence-cache-config.xml
ファイルの<proxy-scheme>
要素で明示的に定義できます。ただし、望ましい方法は、クラスタ構成ファイルでアドレス・プロバイダを定義し、<proxy-scheme>
要素内からアドレスを参照することです。後者の方法では、アプリケーション構成からデプロイメント構成を分離し、coherence-cache-config.xml
ファイルを更新せずにネットワーク・アドレスを変更することが可能です。
アドレス・プロバイダを使用する手順は次のとおりです。
Coherenceクラスタの「設定」ページの「アドレス・プロバイダ」タブを使用して、アドレス・プロバイダ定義を作成します。CoherenceAddressProvidersBean
MBeanも、アドレス・プロバイダ定義を公開します。アドレス・プロバイダには、プロキシ・サービスのリスナー・アドレスに加えて、一意の名前が含まれます。たとえば、proxy1
というアドレス・プロバイダでは、リスナー・アドレスとしてホスト192.168.1.5
およびポート9099
を指定することが考えられます。
手順1を繰り返し、各プロキシ・サービスのアドレス・プロバイダ定義を作成します(それぞれの管理対象Coherenceプロキシ・サーバーについて少なくとも1つ)。
管理対象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> ...
各coherence-cache-config.xml
ファイルを、それぞれの管理対象Coherenceプロキシ・サーバーにデプロイします。通常、coherence-cache-config.xml
ファイルは、GARファイル内に含まれています。ただし、プロキシ層では、クラスタ・キャッシュ構成ファイルを使用します。クラスタ・キャッシュ構成ファイルは、GARに格納されているcoherence-cache-config.xml
ファイルより優先されます。これにより、同じGARをすべてのクラスタ・メンバーにデプロイできますが、この場合プロキシ層に固有の一意の設定が使用されます。クラスタ・キャッシュ構成ファイルの使用の詳細は、「キャッシュ構成ファイルのオーバーライド」を参照してください。
プロキシ・サービスに接続するには、クライアントの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にアクセスできるようにします。
既存のどの管理対象サーバー・インスタンスも、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ユーティリティおよび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
クラスタ・メンバーは、Tangosol Cluster Management Protocol (TCMP)を使用して通信します。このプロトコルは、WLSクラスタ・プロトコルとは関係なく動作します。TCMPは、クラスタ・メンバーの検出、クラスタの管理、サービスのプロビジョニングおよびデータの送信を行うためのIPベースのプロトコルです。TCMPでは、様々なトランスポート・プロトコルを介して送信でき、マルチキャストとユニキャストの両方を使用できます。デフォルトでは、TCMPは、UDPを介して送信され、ユニキャストを使用します。別のトランスポート・プロトコルおよびマルチキャストを使用する場合は、基礎となるネットワークがそれをサポートしている必要があります。
Coherenceクラスタの「設定」ページの「全般」タブを使用して、クラスタ通信を構成します。CoherenceClusterParamsBean
およびCoherenceClusterWellKnownAddressesBean
MBeanは、クラスタ通信パラメータを公開します。
Coherenceクラスタは、ユニキャスト通信とマルチキャスト通信の両方をサポートしています。マルチキャストは、デフォルトのオプションではありません。明示的に構成する必要があります。マルチキャストが適切にサポートされていない環境やマルチキャストが許可されていない環境では、マルチキャストの使用は避けてください。ユニキャストの使用により、すべてのマルチキャスト送信は無効になり、自動的にCoherence Well Knownアドレス(WKA)機能を使用して、クラスタ・メンバーの検出およびクラスタ・メンバー間の通信が行われます。「Well Knownアドレス・メンバーの指定」を参照してください。
Coherenceでのマルチキャスト、ユニキャストおよびWKAの使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
Coherenceクラスタ・モードでのユニキャストの選択
クラスタ通信でユニキャストを使用するには、「クラスタリング・モード」ドロップダウン・リストから「ユニキャスト」を選択し、ユニキャスト・ポートを入力するか、デフォルト・ポート0のままにします。クラスタ・メンバーが別のポートを明示的に指定しないかぎり、この構成済のポートが、すべてのクラスタ・メンバーによって使用されるデフォルト・ポートになります。クラスタ・メンバーのデフォルトのユニキャスト・ポートのオーバーライドの詳細は、「Coherenceクラスタ・メンバーのユニキャスト設定の構成」を参照してください。
ポートが0の場合、オフセット・アルゴリズムを使用してユニキャスト・リスニング・ポートが次のように決定されます。
ドメイン内の管理対象サーバーがスキャンされて、最大のユニキャスト・リスニング・ポートが検出されます。最大ポートが65535より大きい場合、ユニキャスト・リスニング・ポートはデフォルト・ポートの9321に設定されます。それ以上の処理や構成は行われません。
最大ポートを切り上げて100の位までの概数にします。最大ポートの最後の2桁が75より大きい場合は、ポートにさらに100が追加されます。そのように算出したポートが、動的サーバーの開始ポートである7100となった場合には、そのポートにさらに100を追加します。手順3に進みます。
次に例を示します。
最大ポートが7412の場合、ポートは7500に丸められます。
最大ポートが7482の場合、ポートは7600に丸められます。
最大ポートが7020の場合、ポートは7200に丸められます。
Coherenceユニキャスト・リスニング・ポートを手順2により算出した100番台の最初の数に設定します。たとえば、7500のポートの値の場合、Coherenceユニキャスト・リスニング・ポートは7501に設定されます。同じホスト上の後続のサーバーは、Coherenceポート自動調整機能を使用して次の空きポートに設定されます。
Well Knownアドレス・メンバーの指定
ユニキャストが有効な場合は、「Well Knownアドレス」タブを使用してWKAメンバーとして使用するクラスタ・メンバーを明示的に構成します。クラスタに対してWKAメンバーが定義されていない場合、システムによりWKAメンバーが自動的に割り当てられます。ユニキャストを使用する際は、WKAメンバーを常に明示的に指定するのがベスト・プラクティスです。システムにより割り当てられるWKAメンバー機能は、単一のサーバー上でのテストおよび開発向けの設計にすぎず、オフセット・アルゴリズムを使用してポートが選択されているため、ポートの競合が発生することがあります。さらに、システムの割当てによるWKAメンバー設定を使用した場合、別のサーバー上のクラスタ・メンバーがクラスタへの参加できないことがあります。
注意:
|
Coherenceクラスタ・モードでのマルチキャストの選択
クラスタ通信でマルチキャストを使用するには、「クラスタリング・モード」ドロップダウン・リストから「マルチキャスト」を選択し、一意のマルチキャスト・アドレスおよびポートを入力します。
「存続時間」フィールドを使用して、マルチキャスト・パケットが到達できるネットワーク範囲を指定します。存続時間値(TTL)はパケットが存続し続けるホップの数で表現されます。1つのネットワーク・インタフェース、ルーターまたは管理対象スイッチが1ホップと見なされます。TTL値には、実効性のある最も小さい整数値を指定します。
次のトランスポート・プロトコルは、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のサポートを提供します。
SSL付きTMB (TMBS) – TMBSにはSSLソケット・プロバイダを使用する必要があります。『Oracle Coherenceでのアプリケーションの開発』を参照してください。
ソケット・ダイレクト・プロトコル・メッセージ・バス(SDMB) – ソケット・ダイレクト・プロトコル(SDP)は、ストリーム接続のサポートを提供します。SDMBは、Exalogicでのみ有効です。
SSL付きSDMB (SDMBS) – SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。『Oracle Coherenceでのアプリケーションの開発』を参照してください。
インフィニバンド・メッセージ・バス(IMB) – IMBは、ネイティブのInfiniBand Verbに基づいた最適なプロトコルを使用します。IMBは、Exalogicでのみ有効です。
軽量メッセージ・バス(LWMB) – LWMBはInfinibus通信にIMBのMSGQLT/LWIPCライブラリを使用します。LWMBはOracle Exalogicシステムでのみ使用でき、サービス通信とユニキャスト通信の両方でデフォルト・トランスポートになっています。LWMBは、TCMPがSSLで構成されていなければ、自動的に使用されます。
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()
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サーバーは、特定のドメイン用に構成可能ないくつかのクラスタ・メンバー設定を公開します。次のタスクを使用して、管理対象Coherenceサーバーを構成します。
多くの設定では、必要に応じて変更可能なデフォルト値が使用されます。この項に記載されている手順は、管理対象サーバーがすでに作成されて、Coherenceクラスタに関連付けられていることを前提としています。管理対象Coherenceサーバーの作成の詳細は、「スタンドアロンの管理対象Coherenceサーバーの作成」を参照してください。
管理対象サーバーの「設定」ページの「Coherence」タブを使用して、Coherenceクラスタ・メンバー設定を構成します。CoherenceMemberConfig
MBeanが各管理対象サーバーに対して作成され、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におけるユニキャストの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
「Coherence」タブ上の次のフィールドを使用して、ユニキャスト設定を構成します。
ユニキャスト・リスニング・アドレス – このフィールドでは、サーバーがユニキャスト通信をリスニングするアドレスを指定します。クラスタ・メンバーは、java.net.InetAddress.getLocalHost()
呼出しを使用して、バインド先のIPを取得しようとします。ローカルホストがループバック・アドレスとして定義されているシステムでは、ローカルホストの使用は機能しません。その場合、コンピュータ名または具体的なIPアドレスを指定する必要があります。コンピュータに複数のIPまたはNICがある場合は、アドレスも明示的に指定する必要があります。アドレス・フィールドでは、クラスレス・ドメイン間ルーティング(CIDR)表記法もサポートされています。この表記法は、正確なIPアドレスを指定するかわりに、バインド先のローカルIPアドレスのサブネットおよびマスク・パターンを使用します。
ユニキャスト・リスニング・ポート – このフィールドでは、サーバーがユニキャスト通信をリスニングするポートを指定します。クラスタ・メンバーは、2つのユニキャストUDPポートを使用します。すべてのクラスタ・メンバー用に構成されているデフォルト・ポート(0
という値で示されます)と、次に使用可能なポートです。すべてのクラスタ・メンバーに向けて構成されたデフォルト・ポートの変更の詳細は、「Coherenceクラスタ・モードでのユニキャストの選択」を参照してください。デフォルト・ポートが使用できない場合は、別のポートを入力します。または、「ユニキャスト・ポートの自動調整」オプションを選択して、ポートが自動的に選択されるようにします。
ユニキャスト・ポートの自動調整 – このフィールドでは、デフォルト・ポートがすでに使用されている場合、ポートを自動的に増分するかどうかを指定します。
Coherenceクラスタは、JConsoleやJava VisualVMなど、JMX互換の任意のクライアントから管理できます。管理情報には、実行時統計と操作設定が含まれています。この管理情報はCoherence管理ドメイン固有であり、com.bea管理ドメインの一部としてCoherenceに提供されている管理情報とは異なります。Coherence MBeansの詳細は、Oracle Coherenceの管理を参照してください。
Coherence管理情報を表示する場合、1つのクラスタ・メンバーを管理ノードとして構成する必要があります。管理ノードは、他のすべてのクラスタ・メンバーからの管理情報を集計します。その際、WebLogicドメインの管理サーバーはこの情報を統合し、ドメインの実行時MBeanサーバーを介して使用可能になります。
管理ノードを構成するには、管理対象Coherenceサーバーの「Coherence」タブで「Coherence管理ノード」フィールドを選択します。1つの管理対象Coherenceサーバーのみを管理ノードとして構成でき、変更した場合は、すべての管理対象サーバーを再起動してその変更を有効にする必要があります。
実行時にJMXクライアントを使用してドメイン実行時MBeanサーバーに接続します。Coherence管理情報はこのサーバーのCoherence管理ネームスペース内に格納されています。ドメイン実行時MBeanサーバーへの接続の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照してください。
クラスタ内の管理対象CoherenceサーバーにIDを付与するために、一連の識別子が使用されます。ID情報は、クラスタ内でサーバーを区別し、サーバーのロールを伝達するために使用されます。一部のIDは、クラスタ・タスクの実行時にクラスタ・サービスによっても使用されます。最後に、管理情報(JMXなど)を表示する際は、ID情報が役に立ちます。また、ID情報により、ログ・エントリの解釈が容易になります。
「Coherence」タブ上の次のフィールドを使用して、メンバーID設定を構成します。
サイト名 – このフィールドでは、管理対象Coherenceサーバーをホストしている地理的サイトの名前を指定します。名前が指定されない場合、サーバーのドメイン名が使用されます。WANクラスタリングの場合、この値は、メンバーが存在するデータセンターを識別します。インテリジェントなルーティング、ロード・バランシングおよび障害回復計画(つまり、別の地理的サイトにあるデータの明示的なバックアップ)の基盤として、サイト名を使用できます。サイト名は、分散キャッシングの使用時のデータのバックアップ先や、デフォルト・パーティションの割当て戦略を決定するために役立ちます。最後に、管理情報(JMXなど)を表示したり、ログ・エントリを解釈したりする際は、名前が役に立ちます。
ラック名 – このフィールドでは、管理対象Coherenceサーバーがホストされている地理的サイト内の場所の名前を指定します。これは多くの場合、ケージ、ラックまたはブレードフレームの識別子です。インテリジェントなルーティング、ロード・バランシングおよび障害回復計画(つまり、別のブレードフレームにあるデータの明示的なバックアップ)の基盤として、ラック名を使用できます。ラック名は、分散キャッシングの使用時のデータのバックアップ先や、デフォルト・パーティションの割当て戦略を決定するために役立ちます。最後に、管理情報(JMXなど)を表示したり、ログ・エントリを解釈したりする際は、名前が役に立ちます。
ロール名 – このフィールドでは、クラスタにおける管理対象Coherenceサーバーのロールを指定します。ロール名により、アプリケーションは、クラスタ・メンバーを、ストレージが有効、ストレージが無効など、特化したロールに編成することができます。
管理対象CoherenceサーバーがWebLogic Serverクラスタのメンバーである場合、ロール名としてクラスタ名が自動的に使用され、このフィールドを設定することはできません。名前が指定されない場合、使用されるデフォルトのロール名はWebLogicServer
です。
各管理対象Coherenceサーバーについてロギング・レベルを構成できます。デフォルトのロギング・レベルはD5で、これはサーバーの「ロギング」タブを使用して変更できます。WebLogic Serverロギングの詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』を参照してください。
管理対象Coherenceサーバーのロギングを構成するには:
「サーバーのサマリー」画面で、管理対象Coherenceサーバーを選択します。
サーバーの設定ページで、「ロギング」タブを選択します。
「一般」タブで、「詳細」
を選択します。
「プラットフォーム・ロガー・レベル」フィールドに、ロギング・レベルを入力します。
値 | 表示されるメッセージ |
---|---|
com.oracle.coherence=FINEST |
D9 |
com.oracle.coherence=INFO |
D3 |
D5 (デフォルト) |
「保存」をクリックします。
単一サーバー・クラスタは、単一の管理対象サーバー・インスタンス上で実行するように制限されている、ネットワークにアクセスしないクラスタです。サーバー・インスタンスは、ストレージが有効なクラスタ・メンバー、クライアントおよびプロキシとして機能します。単一サーバー・クラスタは、セットアップが容易で、クラスタを起動および停止するための簡単な方法を提供します。単一サーバー・クラスタは、開発時に使用されます。本番環境またはテスト環境では使用しないでください。
単一サーバー・クラスタを作成する手順は次のとおりです。
Coherenceクラスタ・リソースの定義 – Coherenceクラスタを作成し、クラスタのメンバーにする管理対象サーバー・インスタンスを選択します。管理サーバー・インスタンスを使用して、容易に設定を行うことができます。
クラスタ通信の構成 – クラスタを構成し、存続時間の値を0
に設定します(マルチキャスト通信を使用している場合)。
Coherenceクラスタ・メンバーのユニキャスト設定の構成 – 管理対象サーバー・インスタンスを構成し、ユニキャスト・アドレスを、ループバックにルーティングされるアドレスに設定します。ほとんどのコンピュータで、アドレスを127.0.0.1
に設定すれば問題ありません。
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') set('ManagementProxy', '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()