| Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.2.1.3.0) E90317-02 |
|
 前 |
 次 |
WebLogic ServerドメインでCoherenceクラスタを定義する手順、およびCoherenceクラスタを複数の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クラスタ・リソースを定義する手順は次のとおりです。
管理対象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サーバーを作成する手順は次のとおりです。
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データ層を作成する手順は次のとおりです。
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アプリケーション層の管理対象サーバーを作成する手順は次のとおりです。
Coherenceプロキシ層は、Coherenceクラスタに関連付けられているWebLogic Serverクラスタであり、任意の数の管理対象Coherenceプロキシ・サーバーをホストします。管理対象Coherenceプロキシ・サーバーにより、Coherence*Extendクライアントは、クラスタ・メンバーにならなくてもCoherenceキャッシュを使用することが可能になります。プロキシ層で必要な管理対象Coherenceプロキシ・サーバーの数は、予想されるクライアントの数によって異なります。ロード・バランシングを可能にするには、少なくとも2台のプロキシ・サーバーを作成する必要があります。ただし、多数のクライアント接続およびリクエストをサポートする場合は、追加のサーバーが必要になることがあります。
Coherence*Extendおよび拡張クライアントの作成の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。
Coherenceプロキシ層を作成する手順は次のとおりです。
Coherenceプロキシ層の管理対象サーバーを作成する手順は次のとおりです。
Coherenceプロキシ・サービスは、拡張クライアントからのリモート接続を管理するクラスタ化されたサービスです。プロキシ・サービスは、<proxy-scheme要素内のcoherence-cache-config.xmlファイルで定義および構成されます。定義には、その他の設定の他に、クライアント接続の受入に使用されるTCPリスナー・アドレス(IPまたはDNS名、およびポート)があります。<proxy-scheme要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。プロキシ・サービスを設定する方法は2つあります。1つはネーム・サービスを使用する方法、もう1つはアドレス・プロバイダを使用する方法です。ネーミング・サービスを使用すると、効率的な設定を行うことができ、Coherenceプロキシ層では通常、ネーミング・サービスの使用が推奨されます。
ネーム・サービスは、拡張クライアントがプロキシ・サービスに名前で接続できるようにする専用のリスナーです。クライアントは、ネーム・サービスに接続し、ネーム・サービスは、クラスタ上のすべてのプロキシ・サービスのアドレスを戻します。
注意:
ドメインに複数の層(データ層、アプリケーション層、プロキシ層など)が含まれている場合、クライアントがプロキシに接続できるようにするために、まずプロキシ層を起動する必要があります。
プロキシ・サービスを管理対象Coherenceプロキシ・サーバー上で構成すると、ネーム・サービスがポート7574 (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システム・プロパティよりも優先されます。WLSのCoherence構成は一般に、システム・プロパティを使用するのではなく、WLSTまたは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ユーティリティおよび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が検出用に、TCPがデータ送信用に使用されます(TMBを使用)。Well Knownアドレス(WKA)が構成されている場合、TCMPは検出用のユニキャストUDPおよびデータ送信用のTCPを介して送信されます。SSLがTCMP用に構成されている場合は、SSL over TCPが検出とデータ送信の両方に使用されます。別のトランスポート・プロトコルおよびマルチキャストを使用する場合は、基礎となるネットワークがそれをサポートしている必要があります。
Coherenceクラスタの「設定」ページの「全般」タブを使用して、クラスタ通信を構成します。CoherenceClusterParamsBeanおよびCoherenceClusterWellKnownAddressesBean MBeanは、クラスタ通信パラメータを公開します。
Coherenceクラスタは、ユニキャスト通信とマルチキャスト通信の両方をサポートしています。マルチキャストは、デフォルトのオプションではありません。明示的に構成する必要があります。マルチキャストが適切にサポートされていない環境やマルチキャストが許可されていない環境では、マルチキャストの使用は避けてください。ユニキャストの使用により、すべてのマルチキャスト送信は無効になり、自動的にCoherence Well Knownアドレス(WKA)機能を使用して、クラスタ・メンバーの検出およびクラスタ・メンバー間の通信が行われます。Well Knownアドレス・メンバーの指定を参照してください。
Coherenceでのマルチキャスト、ユニキャストおよびWKAの使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
Coherenceクラスタ・モードでのユニキャストの選択
クラスタ通信でユニキャストを使用するには、「クラスタリング・モード」ドロップダウン・リストから「ユニキャスト」を選択し、クラスタ・ポートを入力するか、デフォルト・ポート7574のままにします。ほとんどのクラスタの場合、ポートの変更は必要ありません。ただし、複数のCoherenceクラスタが同じコンピュータで実行する場合、ポートの変更が必要です。別のポートが必要な場合、お薦めのベスト・プラクティスとして、1024から8999までの値を選択します。
Well Knownアドレス・メンバーの指定
ユニキャストが有効な場合は、「ウェル・ノウン・アドレス」タブを使用してWKAマシン・アドレスを明示的に構成します。クラスタに対してアドレスが定義されていない場合、アドレスが自動的に割り当てられます。ユニキャストを使用する際は、お薦めのベスト・プラクティスとして、WKAマシン・アドレスを常に明示的に指定します。
さらに、異なるマシン上にある複数の管理対象Coherenceサーバーがドメインに含まれる場合、Coherenceクラスタが確実に形成されるように少なくとも1つの非ローカルWKAマシン・アドレスを定義する必要があります。そうでない場合、各マシンに複数の個別クラスタが形成されます。管理対象Coherenceサーバーがすべて同じマシン上で実行している場合、非ローカル・リスニング・アドレスを指定せずにクラスタを作成できます。
注意:
WKAマシン・アドレスは、本番環境で明示的に定義される必要があります。本番モードで、WKAマシン・アドレスが明示的に定義されていない場合、管理対象Coherenceサーバーは起動に失敗します。自動的に割り当てられたWKAマシン・アドレスは、設計時の便宜を図るためのもので、開発時に単一サーバー上でのみ使用する必要があります。
Coherenceクラスタ・モードでのマルチキャストの選択
クラスタ通信でマルチキャストを使用するには、「クラスタリング・モード」ドロップダウン・リストから「マルチキャスト」を選択し、クラスタ・ポートとマルチキャスト・リスニング・アドレスを入力します。クラスタが同じコンピュータまたはマルチキャスト・アドレスで実行されている場合でも、同じクラスタ・ポートを異なるクラスタ間で(クラスタ名で識別して)共有できます。したがって、クラスタ名が環境内で一意の値に設定されている場合は、クラスタ・ポートを変更する必要はありません。別のポートが必要な場合、お薦めのベスト・プラクティスとして、1024から8999までの値を選択します。
「存続時間」フィールドを使用して、マルチキャスト・パケットが到達できるネットワーク範囲を指定します。存続時間値(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クラスタ設定ページの「永続性」タブを使用して、アクティブ永続性を有効にし、永続性ファイルの格納先となるデフォルトの場所をオーバーライドします。CoherencePersistenceParamsBean MBeanが永続性パラメータを公開します。永続性の変更を有効にするために、管理対象Coherenceサーバーを再起動する必要があります。
オンデマンド永続性では、キャッシュ・サービスを手動で永続化し、リクエスト時(スナップショット)に永続性コーディネータを使用してリカバリできます。永続性コーディネータは、キャッシュ・サービスのスナップショットの作成、アーカイブおよびリカバリの操作を提供するMBeanインタフェース(PersistenceCoordinatorMBean)として公開されています。MBeanを使用するには、JMXをクラスタに対して有効にする必要があります。JMX管理の有効化およびCoherence MBeanへのアクセスの詳細は、JMXの使用によるOracle Coherenceの管理を参照してください。アクティブ永続性では、キャッシュの内容はすべてのミューテーションで自動的に永続化され、内容はクラスタ/サービスの起動時に自動的にリカバリされます。その場合も、永続性コーディネータをアクティブ永続性モードで使用して、オンデマンド・スナップショットを実行できます。
フェデレーション・キャッシュ機能は、地理的に分散している複数のクラスタ間で非同期的にキャッシュ・データを結合します。キャッシュ内のデータはクラスタ間で結合され、地理的に異なる場所のアプリケーション・ユーザーに対して冗長性、オフサイト・バックアップおよび複数のアクセス・ポイントを提供します。Coherenceフェデレーションの全詳細は、複数クラスタにわたるキャッシュのフェデレートを参照してください。
Coherenceクラスタ設定ページの「フェデレーション」タブを使用して、フェデレーション・トポロジを有効にし、キャッシュをフェデレートするリモート・クラスタ・メンバーを構成します。トポロジを選択すると、トポロジ構成が自動的に作成され、Default-Topologyという名前が付けられます。フェデレーションは、ローカル・クラスタ・メンバーとリモート・クラスタ・メンバーの両方で構成する必要があります。リモート・クラスタ上のホストを1つ以上提供する必要があります。リモート・クラスタ・メンバー上でカスタム・ポートが使用されている場合は、それに応じてクラスタ・ポートを変更します。フェデレーションの変更を有効にするために、管理対象Coherenceサーバーを再起動する必要があります。CoherenceFederationParamsBean MBeanは、クラスタ・フェデレーション・パラメータも公開し、キャッシュ・フェデレーションを構成するために使用できます。
注意:
Default-Topologyトポロジ構成が作成され、キャッシュ構成ファイルでフェデレーション・トポロジが指定されていない場合に使用されます。
フェデレーションの使用時は、ローカル・クラスタとリモート・クラスタの両方で一致するトポロジを構成する必要があります。たとえば、ローカル・クラスタでのトポロジにnoneを、リモート・クラスタでのトポロジとしてactive-activeを選択すると、予期しない動作が発生する可能性があります。同様に、ローカル・クラスタをactive-passiveを使用するよう設定した場合は、リモート・クラスタをpassive-activeを使用するよう設定する必要があります。
管理対象Coherenceサーバーは、特定のドメイン用に構成可能ないくつかのクラスタ・メンバー設定を公開します。
次のタスクを使用して、管理対象Coherenceサーバーを構成します。
多くの設定では、必要に応じて変更可能なデフォルト値が使用されます。この項に記載されている手順は、管理対象サーバーがすでに作成されて、Coherenceクラスタに関連付けられていることを前提としています。管理対象Coherenceサーバーの作成の詳細は、「スタンドアロンの管理対象Coherenceサーバーの作成」を参照してください
管理対象サーバーの「設定」ページの「Coherence」タブを使用して、Coherenceクラスタ・メンバー設定を構成します。CoherenceMemberConfig MBeanが各管理対象サーバーに対して作成され、Coherenceクラスタ・メンバーのパラメータを公開します。
注意:
WLS構成は、Coherenceシステム・プロパティよりも優先されます。WLSのCoherence構成は一般に、システム・プロパティを使用するのではなく、WLSTまたは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」タブ上の次のフィールドを使用して、ユニキャスト設定を構成します。
ユニキャスト・リスニング・アドレス – このフィールドでは、サーバーがユニキャスト通信をリスニングするアドレスを指定します。アドレスを指定しない場合、ルーティング可能IPアドレスが自動的に選択されます。アドレス・フィールドでは、クラスレス・ドメイン間ルーティング(CIDR)表記法もサポートされています。この表記法は、正確なIPアドレスを指定するかわりに、バインド先のローカルIPアドレスのサブネットおよびマスク・パターンを使用します。アドレス・フィールドでは、クラスレス・ドメイン間ルーティング(CIDR)表記法もサポートされています。この表記法は、正確なIPアドレスを指定するかわりに、バインド先のローカルIPアドレスのサブネットおよびマスク・パターンを使用します。
ユニキャスト・リスニング・ポート – このフィールドでは、サーバーがユニキャスト通信をリスニングするポートを指定します。クラスタ・メンバーは、オペレーティング・システムの使用可能なエフェメラル・ポート範囲(値0で示される)から自動で割り当てられる2つのユニキャストUDPポートを使用します。デフォルト値の場合、Coherenceが原因で他のアプリケーションとのポート競合が誤って生じることはありません。ただし、クラスタ・メンバー間でファイアウォールが必要な場合(特殊な構成)、ポートを手動で割り当てることができ、2番目のポートが自動的に選択されます(port1 +1)。
ユニキャスト・ポートの自動調整 – このフィールドでは、ポートがすでに使用されている場合、ポートを自動的に増分するかどうかを指定します。
Coherenceクラスタは、JConsoleやJava VisualVMなど、JMX互換の任意のクライアントから管理できます。管理情報には、実行時統計と操作設定が含まれています。この管理情報はCoherence管理ドメイン固有であり、com.bea管理ドメインの一部としてCoherenceに提供されている管理情報とは異なります。Coherence MBeansの詳細は、Oracle Coherenceの管理を参照してください。
1つのクラスタ・メンバーが管理プロキシとして自動で選択され、他のすべてのクラスタ・メンバーの管理情報を集約する責任があります。その後、管理情報はWebLogicドメインの管理サーバーによって統合され、ドメイン・ランタイムMBeanサーバーを通じて使用できるようになります。そのクラスタ・メンバーが稼働していない場合、別のクラスタ・メンバーが管理プロキシとして自動で選択されます。
管理対象Coherenceサーバーの「Coherence」タブで「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クラスタ・リソースの定義 – Coherenceクラスタを作成し、クラスタのメンバーにする管理対象サーバー・インスタンスを選択します。管理サーバー・インスタンスを使用して、容易に設定を行うことができます。
クラスタ通信の構成 – クラスタを構成し、存続時間の値を0に設定します(マルチキャスト通信を使用している場合)。
Coherenceクラスタ・メンバーのユニキャスト設定の構成 – 管理対象サーバー・インスタンスを構成し、ユニキャスト・アドレスを、ループバックにルーティングされるアドレスに設定します。ほとんどのコンピュータで、アドレスを127.0.0.1に設定すれば問題ありません。
『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()
WLSTには、ディスクのキャッシュ済データの保持と回復に使用できる一連のコマンドがあります。コマンドは、管理サーバー・ドメインのランタイムMBeanサーバーに接続されている場合に自動で利用できます。
Coherenceキャッシュの保持の詳細は、『Oracle Fusion Middleware Oracle Coherenceの管理』を参照してください。
表12-1に、Coherenceキャッシュを保持するためのWLSTコマンドを示します。例12-1で、コマンドの使用を実証します。
表12-1 WLSTのCoherence保持コマンド
| コマンド | 説明 |
|---|---|
|
サービスのデータ・パーティションをディスクに保持します
|
|
サービスのデータ・パーティションをディスクから復元します。サービスのキャッシュ内の既存データが失われます。
|
|
使用可能なスナップショットのリストを返します
|
|
エラーが発生せずにスナップショットが完了するかどうかを確認します
|
|
スナップショットを中央の場所に保存します。場所は、サービスに関連付けられているスナップショット・アーカイバ定義で指定します。
|
|
coh_recoverSnapshotコマンドを使用して回復できるように、アーカイブ済スナップショットを取得します
|
|
使用可能なアーカイブ済スナップショットのリストを返します
|
|
エラーが発生せずにアーカイブ済スナップショットが完了するかどうかを確認します。アーカイバを含む操作オーバーライド構成ファイルがクラスパスで利用できる必要があります。
|
|
アーカイブ済スナップショットをディスクから削除します
|
|
スナップショットをディスクから削除します
|
例12-1で、WLSTの永続性APIを使用した、パーティション化キャッシュ・サービスのキャッシュを保持する例を実証します。
例12-1 キャッシュを保持する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'
