プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Coherenceの管理
12c (12.2.1.1)
E77318-02
目次へ移動
目次
前
前 		次
次

7 クラスタ間のキャッシュのフェデレート

この章では、Coherenceフェデレーテッド・キャッシュ機能を使用して、クラスタ間でキャッシュ・データをフェデレートする手順について説明します。

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

7.1 フェデレーテッド・キャッシュの概要

フェデレーション・キャッシュ機能は、地理的に分散している複数のクラスタ間で非同期的にキャッシュ・データを結合します。キャッシュ内のデータはクラスタ間で結合され、地理的に異なる場所のアプリケーション・ユーザーに対して冗長性、オフサイト・バックアップおよび複数のアクセス・ポイントを提供します。

複数フェデレーション・トポロジ

フェデレーテッド・キャッシュでは、複数のフェデレーション・トポロジをサポートしています。これらには、アクティブ/アクティブ、アクティブ/パッシブ、ハブ/スポーク、集中型のフェデレーションなどがあります。トポロジでは、クラスタ間の一般的なフェデレーション戦略を定義し、様々なユース・ケースをサポートします。必要に応じて、カスタム・フェデレーション・トポロジを作成することもできます。

競合の解決

フェデレーテッド・キャッシュでは、ローカルまたはリモートで格納されているキャッシュ・エントリの受入れ、拒否、または変更をアプリケーションで実行できます。競合解決は、フェデレーション・ルールを定義する場合に柔軟性を最大限に高めることができるアプリケーションです。

フェデレーション構成

フェデレーテッド・キャッシュは、Coherence構成ファイルを使用して構成されるため、アプリケーション・コードを変更する必要はありません。オペレーション・オーバーライド・ファイルは、フェデレーション参加者とフェデレーション・トポロジを構成するように使用されます。キャッシュ構成ファイルは、フェデレーテッド・キャッシュ・スキームの作成に使用されます。フェデレーテッド・キャッシュは、一種のパーティション・キャッシュ・サービスであり、フェデレーテッド・キャッシュ・サービス・インスタンスで管理されます。

管理および監視

フェデレーテッド・キャッシュは、FederationManagerMBean、DestinationMBean、OriginMBeanおよびTopologyMBean MBeanからの属性および操作を使用して管理されます。これらのMBeanにより、フェデレーションの開始と停止などの管理操作や、フェデレーション構成とパフォーマンス統計の監視を簡単に実行できます。これらの統計および操作の多くは、Coherence Java VisualVMプラグインから使用することもできます。

フェデレーション属性および統計は、federation-status、federation-originおよびfederation-destinationレポートで集計されます。フェデレーション統計は、Coherence Java VisualVMプラグインでも集計されます。どちらのツールでも、発生する可能性のあるリソースおよびパフォーマンス問題をトラブルシューティングできます。

また、分散キャッシュと同様、フェデレーテッド・サービスおよびキャッシュは、ServiceMBean MBeanおよびCacheMBean MBeanの属性操作、および関連するレポートとJava VisualVMプラグインのタブを使用して管理および監視できます。

7.2 フェデレーテッド・キャッシュの設定の一般的な手順

フェデレーテッド・キャッシュの設定手順:

  1. フェデレーションに参加しているすべてのクラスタが稼働しており、各クラスタの少なくとも1つのキャッシュ・サーバーのアドレス(ホストおよびクラスタ・ポート)が判明していることを確認します。
  2. 「フェデレーション参加者の定義」で説明しているように、フェデレーション内のクラスタ参加者のリストで、各クラスタを構成します。
  3. 「フェデレーション・トポロジの定義」で説明しているように、クラスタ参加者間でデータがどのようにフェデレートされるかを指定するトポロジ定義で、各クラスタを構成します。
  4. 「フェデレーテッド・キャッシュ・スキームの定義」で説明しているように、キャッシュ・データの格納に使用されるフェデレーテッド・キャッシュ・スキームで、各クラスタを構成します。
  5. 「フェデレーテッド・キャッシュとフェデレーション・トポロジの関連付け」で説明しているように、定義済のフェデレーション・トポロジを使用するように、各クラスタでフェデレーテッド・キャッシュを構成します。

7.3 フェデレーション参加者の定義

フェデレーション内の各Coherenceクラスタは、フェデレーション参加者として定義する必要があります。フェデレーション参加者は、オペレーション・オーバーライド・ファイルに定義されます。フェデレーションの各クラスタのオペレーション・オーバーライド・ファイルには、フェデレーション対象の参加者のリストを含める必要があります。参加者のリストには、ローカル・クラスタ参加者およびリモート・クラスタ参加者を含める必要があります。

フェデレーション参加者を定義するには、<participants>要素内に任意の数の<participant>要素を含めます。<name>要素を使用して、参加者の名前を定義し、<name—service-addresses>要素を使用して、参加者クラスタに配置されている少なくとも1つのキャッシュ・サーバーのアドレスを定義します。次に例を示します。

<federation-config>
   <participants>
      <participant>
         <name>LocalClusterA</name>
         <name-service-addresses>
            <address>192.168.1.7</address>
         </name-service-addresses>
      </participant>
      <participant>
         <name>RemoteClusterB</name>
         <name-service-addresses>
            <address>192.168.10.16</address>
         </name-service-addresses>
      </participant>
      <participant>
         <name>RemoteClusterC</name>
         <name-service-addresses>
            <socket-address>
               <address>192.168.19.25</address>
                     <port>1234</port>
                </socket-address>
         </name-service-addresses>
      </participant>
   </participants>
</federation-config>

7.4 フェデレーション参加者のデフォルト設定の変更

フェデレーション参加者は、デフォルト設定をオーバーライドするように明示的に構成できます。各設定の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。デフォルト設定は次のとおりです。

  • クラスタの起動時のクラスタ参加者のフェデレーションの状態

  • 宛先クラスタに対する接続タイムアウト

  • 宛先クラスタからの確認メッセージの送信タイムアウト

  • フェデレートされたデータを送信するための最大帯域幅

  • 単一のバッチでフェデレートされるエントリの最大数

  • 参加者の場所のメタデータ

フェデレーション参加者のデフォルト設定を変更するには、クラスタのオペレーション・オーバーライド・ファイルを編集して、<participant>定義を変更します。必要に応じて、各設定の値を更新します。次に例を示します。

<participant>
   <name>ClusterA</name>
   <initial-action>start</initial-action>
   <connect-timeout>2m</connect-timeout>
   <send-timeout>6m</send-timeout>
   <max-bandwidth>10</max-bandwidth>
   <batch-size>25</batch-size>
   <geo-ip>Philadelphia</geo-ip>
   <name-service-addresses>
      <address>192.168.1.7</address>
   </name-service-addresses>
</participant>

7.5 フェデレーション・トポロジの理解

フェデレーション・トポロジでは、フェデレーション内のクラスタ参加者間でデータがどのようにフェデレートおよび同期されるかを決定します。フェデレーション・トポロジでは、キャッシュ・データを送信できるクラスタ、キャッシュ・データを受信できるクラスタ、およびキャッシュ・データを再送信できるクラスタを定義します。これらのロールは明確に定義され、データが失われたり、複数回送信されないようにします。

サポートされるフェデレーション・トポロジは次のとおりです。

アクティブ/パッシブ・トポロジ

アクティブ/パッシブ・トポロジは、アクティブ・クラスタからパッシブ・クラスタにデータをフェデレートする場合に使用されます。アクティブ・クラスタに置かれるデータは、パッシブ・クラスタにフェデレートされます。データがパッシブ・クラスタに置かれると、アクティブ・クラスタにはフェデレートされません。キャッシュ・データのコピーが読取り専用の操作に必要な場合、またはオフサイト・バックアップが必要な場合は、アクティブ/パッシブ・トポロジの使用を検討してください。

図7-1に、アクティブ/パッシブ・トポロジの概念図を示します。

図7-1 アクティブ/パッシブ・トポロジ

図7-1の説明が続きます
「図7-1 アクティブ/パッシブ・トポロジ」の説明

アクティブ/アクティブ・トポロジ

アクティブ/アクティブ・トポロジは、アクティブ・クラスタ間でデータをフェデレートする場合に使用されます。一方のアクティブ・クラスタに置かれるデータは、もう一方のアクティブ・クラスタでフェデレートされます。アクティブ/アクティブ・トポロジにより、キャッシュ・データは常にクラスタ間で同期されます。地理的に分散した複数の場所のアプリケーションからローカル・クラスタ・インスタンスにアクセスできるようにするには、アクティブ/アクティブ・トポロジの使用を検討してください。

図7-2に、アクティブ/アクティブ・トポロジの概念図を示します。

図7-2 アクティブ/アクティブ・トポロジ

図7-2の説明が続きます
「図7-2 アクティブ/アクティブ・トポロジ」の説明

ハブおよびスポーク・トポロジ

ハブおよびスポーク・トポロジは、単一のハブ・クラスタから複数のスポーク・クラスタにデータをフェデレートする場合に使用されます。ハブ・クラスタはデータの送信のみ可能で、スポーク・クラスタはデータの受信のみ可能です。地理的に分散したクラスタの複数のコピーが必要な場合は、ハブおよびスポーク・トポロジの使用を検討してください。各スポーク・クラスタは読取り専用を実行するためにローカル・アプリケーションで使用できます。

図7-3に、ハブおよびスポーク・トポロジの概念図を示します。

図7-3 ハブおよびスポーク・トポロジ

図7-3の説明が続きます
「図7-3 ハブおよびスポーク・トポロジ」の説明

集中型フェデレーション・トポロジ

集中型フェデレーション・トポロジは、単一のハブから複数のリーフ・クラスタにデータをフェデレートする場合に使用されます。さらに、各リーフでは、データをハブ・クラスタに送信可能で、ハブ・クラスタは、データを他のすべてのリーフ・クラスタに再送信する(繰り返す)ことができます。地理的に分散した複数の場所のアプリケーションからローカル・クラスタ・インスタンスにアクセスできるようにするには、集中型フェデレーション・トポロジの使用を検討してください。

図7-4に、集中型フェデレーション・トポロジの概念図を示します。

図7-4 集中型フェデレーション・トポロジ

図7-4の説明が続きます
「図7-4 集中型フェデレーション・トポロジ」の説明

カスタム・フェデレーション・トポロジ

カスタム・フェデレーション・トポロジは、自由形式のトポロジの作成に使用されます。クラスタはグループに編成され、各クラスタはグループ内のロールで指定されます。ロールには、送信者、受信者またはリピータが含まれます。送信者の参加者は、ローカル・クラスタ上で発生している変更のフェデレートのみが可能です。リピータは、ローカル・クラスタの変更および他の参加者から受信した変更の両方をフェデレートします。グループ内の他のクラスタにデータをフェデレートできるのは、送信者およびリピータのクラスタのみです。事前定義済のフェデレーション・トポロジでキャッシュのフェデレーション要件に対応できない場合は、カスタム・フェデレーション・トポロジの作成を検討してください。

図7-5に、1つの予想される構成のカスタム・フェデレーション・トポロジの概念図を示します。

図7-5 カスタム・フェデレーション・トポロジ

図7-5の説明が続きます
「図7-5 カスタム・フェデレーション・トポロジ」の説明

7.6 フェデレーション・トポロジの定義

フェデレーション・トポロジは、<federation-config>要素内のオペレーション・オーバーライド・ファイルに定義されます。使用するフェデレーション・トポロジが不明の場合は、この項の手順を完了する前に、「フェデレーション・トポロジの理解」を参照してください。

トポロジ定義には、トポロジで各クラスタ参加者が実行するフェデレーション・ロールが含まれます。複数のトポロジを定義可能で、参加者を複数のトポロジの一部にすることができます。参加者間でデータが予想通りにフェデレートされるようにするには、対応するフェデレーション・トポロジ定義がフェデレーション内の各クラスタに必要です。

注意:

トポロジが定義されていない場合、すべての参加者はアクティブ/アクティブ・トポロジ内にあると見なされます。

この項には次のトピックが含まれます:

7.6.1 アクティブ/パッシブ・トポロジの定義

アクティブ/パッシブ・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<active-passive>要素を<topology-definitions>要素内に含めます。<name>要素を使用して、このトポロジの参照に使用される名前を含めます。<active>要素を使用して、アクティブ参加者を定義し、<passive>要素を使用して、パッシブ参加者を定義します。次に例を示します。 

<federation-config>
   ...
   <topology-definitions>
      <active-passive>
         <name>MyTopology</name>
         <active>LocalClusterA</active>
         <passive>RemoteClusterB</passive>
      </active-passive>
   </topology-definitions>
</federation-config>

このトポロジでは、LocalClusterAでの変更はRemoteClusterBにフェデレートされますが、RemoteClusterBでの変更はLocalClusterAにフェデレートされません。

7.6.2 アクティブ/アクティブ・トポロジの定義

アクティブ/アクティブ・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<active-passive>要素を<topology-definitions>要素内に含めます。<name>要素を使用して、このトポロジの参照に使用される名前を含めます。<active>要素を使用して、アクティブ参加者を定義します。次に例を示します。 

<federation-config>
   ...
   <topology-definitions>
      <active-passive>
         <name>MyTopology</name>
         <active>LocalClusterA</active>
         <active>RemoteClusterB</active>
      </active-passive>
   </topology-definitions>
</federation-config>

このトポロジでは、LocalClusterAでの変更はRemoteClusterBにフェデレートされ、RemoteClusterBでの変更はLocalClusterAにフェデレートされます。

7.6.3 ハブおよびスポーク・トポロジの定義

ハブおよびスポーク・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<hub-spoke>要素を<topology-definitions>要素内に含めます。<name>要素を使用して、このトポロジの参照に使用される名前を含めます。<hub>要素を使用して、ハブ参加者を定義し、<spoke>要素を使用して、スポーク参加者を定義します。次に例を示します。 

<federation-config>
   ...
   <topology-definitions>
      <hub-spoke>
         <name>MyTopology</name>
         <hub>LocalClusterA</hub>
         <spoke>RemoteClusterB</spoke>
         <spoke>RemoteClusterC</spoke>
      </hub-spoke>
   </topology-definitions>
</federation-config>

このトポロジでは、LocalClusterAでの変更はRemoteClusterBおよびRemoteClusterCにフェデレートされますが、RemoteClusterBおよびRemoteClusterCでの変更はLocalClusterAにフェデレートされません。

7.6.4 集中型フェデレーション・トポロジの定義

集中型フェデレーション・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<central-replication>要素を<topology-definitions>要素内に含めます。<name>要素を使用して、このトポロジの参照に使用される名前を含めます。<hub>要素を使用して、ハブ参加者を定義し、<leaf>要素を使用して、リーフ参加者を定義します。次に例を示します。 

<federation-config>
   ...
   <topology-definitions>
      <central-replication>
         <name>MyTopology</name>
         <hub>LocalClusterA</hub>
         <leaf>RemoteClusterB</leaf>
         <leaf>RemoteClusterC</leaf>
      </central-replication>
   </topology-definitions>
</federation-config>

このトポロジでは、LocalClusterAでの変更はRemoteClusterBおよびRemoteClusterCにフェデレートされます。RemoteClusterBまたはRemoteClusterCでの変更はLocalClusterAにフェデレートされ、他のクラスタ参加者にデータが再送信されます。

7.6.5 カスタム・トポロジの定義

カスタム・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<custom-topology>要素を<topology-definitions>要素内に含めます。<name>要素を使用して、このトポロジの参照に使用される名前を含めます。<groups>要素内の<group>要素を使用して、グループ内の各参加者のロール(送信者、リピータまたは受信者)を定義します。次に例を示します。 

<federation-config>
   ...
   <topology-definitions>
      <custom-topology>
         <name>MyTopology</name>
         <groups>
            <group>
               <sender>LocalClusterA</sender>
               <sender>RemoteClusterB</sender>
            </group>
            <group>
               <repeater>LocalClusterA</repeater>
               <receiver>RemoteClusterC</receiver>
            </group>
         </groups>
      </custom-topology>
   </topology-definitions>
</federation-config>

このトポロジでは、LocalClusterAまたはRemoteClusterBの変更はRemoteClusterCにフェデレートされます。RemoteClusterCでの変更は、LocalCluster AまたはRemoteClusterBにフェデレートされません。

7.7 フェデレーテッド・キャッシュ・スキームの定義

<federated-scheme要素は、フェデレーテッド・キャッシュの定義に使用されます。キャッシュ構成ファイルで、フェデレーテッド・キャッシュを必要な数だけ定義できます。<federated-scheme要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

クラスタ内の各参加者では、それぞれのキャッシュ構成ファイルにフェデレーテッド・キャッシュ・スキームを含める必要があります。すべての参加者のフェデレーテッド・キャッシュは、同じフェデレーテッド・サービス・インスタンスで管理する必要があります。サービスは、<service-name>要素を使用して指定されます。

例7-1では、サービス・インスタンス名と同じスキーム名およびfederatedとして、federatedを使用する基本的なフェデレーテッド・キャッシュ・スキームを定義します。スキームは、キャッシュ名exampleにマップされます。<autostart>要素をtrueに設定すると、キャッシュ・サーバー・ノード上でフェデレーテッド・キャッシュ・サービスを開始します。

例7-1 フェデレーテッド・キャッシュ定義のサンプル

<?xml version="1.0" encoding="windows-1252"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
   coherence-cache-config.xsd">
   <caching-scheme-mapping>
      <cache-mapping>
         <cache-name>example</cache-name>
         <scheme-name>federated</scheme-name>
      </cache-mapping>
   </caching-scheme-mapping>
   <caching-schemes>
      <federated-scheme>
         <scheme-name>federated</scheme-name>
         <service-name>federated</service-name>
         <backing-map-scheme>
            <local-scheme/>
         </backing-map-scheme>
         <autostart>true</autostart>
      </federated-scheme>
   </caching-schemes>
</cache-config>

7.8 フェデレーテッド・キャッシュとフェデレーション・トポロジの関連付け

フェデレーテッド・キャッシュは、フェデレーション参加者にフェデレートされるデータのトポロジに関連付ける必要があります。トポロジは、オペレーション・オーバーライド・ファイルに定義され、フェデレーテッド・キャッシュ定義から参照されます。フェデレーション・トポロジの定義の詳細は、「フェデレーション・トポロジの定義」を参照してください。

注意:

トポロジが定義されていない場合(すべての参加者がアクティブ/アクティブ・トポロジにいると見なされる)、またはトポロジが1つしか定義されていない場合は、トポロジ名をフェデレーテッド・スキーム定義に指定する必要はありません。

フェデレーテッド・キャッシュをフェデレーション・トポロジに関連付けるには、<topology>要素を<topologies>要素内に含め、<name>要素を使用して、オペレーション・オーバーライド・ファイルに定義されているフェデレーション・トポロジを参照します。次に例を示します。

<federated-scheme>
   <scheme-name>federated</scheme-name>
   <service-name>federated</service-name>
   <backing-map-scheme>
      <local-scheme />
   </backing-map-scheme>
   <autostart>true</autostart>
   <topologies>
      <topology>
         <name>MyTopology</name>
      </topology>
   </topologies>
</federated-scheme>

フェデレーテッド・キャッシュは、複数のフェデレーション・トポロジに関連付けることができます。次に例を示します。

<federated-scheme>
   <scheme-name>federated</scheme-name>
   <service-name>federated</service-name>
   <backing-map-scheme>
      <local-scheme />
   </backing-map-scheme>
   <autostart>true</autostart>
   <topologies>
      <topology>
         <name>MyTopology1</name>
      </topology>
      <topology>
         <name>MyTopology2</name>
      </topology>
   </topologies>
</federated-scheme>

7.9 宛先キャッシュのオーバーライド

デフォルトでは、フェデレーション・サービスは、ローカル参加者に定義されているのと同じキャッシュ名を使用して、リモート参加者のキャッシュにデータをフェデレートします。必要に応じて、異なるリモート・キャッシュを明示的に指定できます。ただし、その場合も、各キャッシュは同じフェデレーション・サービスで管理する必要があり、キャッシュで<service-name>要素の同じ値を指定する必要があります。

デフォルトの宛先キャッシュをオーバーライドするには、<cache-name>要素を含め、リモート参加者の宛先キャッシュの名前に値を設定します。次に例を示します。

<federated-scheme>
   <scheme-name>federated</scheme-name>
   <service-name>federated</service-name>
   <backing-map-scheme>
      <local-scheme />
   </backing-map-scheme>
   <autostart>true</autostart>
   <topologies>
      <topology>
         <name>MyTopology</name>
         <cache-name>fed-remote</cache-name>
      </topology>
   </topologies>
</federated-scheme>

7.10 フェデレートからのキャッシュの除外

フェデレーテッド・キャッシュは、他の参加者へのフェデレートから除外できます。キャッシュを除外すると、アプリケーションが同じパーティションおよびサービスでクロスキャッシュ・トランザクションを実行でき、一部の情報を常にローカルのまま(他のクラスタにフェデレートされない)に維持できます。
キャッシュがフェデレートされないように除外するには、キャッシュ・マッピング定義の一部として、<federated>要素にfalseを設定して追加します。次に例を示します。
<caching-scheme-mapping>
   <cache-mapping>
      <cache-name>example</cache-name>
      <scheme-name>federated</scheme-name>
   </cache-mapping>
   <cache-mapping>
      <cache-name>excluded-example</cache-name>
      <scheme-name>federated</scheme-name>
      <federated>false</federated>
   </cache-mapping>
</caching-scheme-mapping>
...

7.11 フェデレーション・サービス・リソースの使用の制限

フェデレーション・サービスでは、内部キャッシュおよびジャーナルを使用して、フェデレーション中にキャッシュを保持します。内部キャッシュでは、フェデレートされるエントリの量とサイズに応じて、クラスタ・ノードで使用可能なすべてのリソースを消費できます。これにより、フェデレーションのすべてのクラスタが影響を受ける場合があります。このようなシナリオから保護するために、内部キャッシュのサイズを制限するように内部キャッシュを構成できます。上限に到達すると、クラスタ参加者は別のクラスタ参加者によってエラー状態にされ、参加者へのフェデレーションが停止します。

フェデレーション・サービス・リソースの使用を制限するには、フェデレーテッド・キャッシュ・スキームを編集して、<journalcache-highunits>要素を、上限に到達するまで内部キャッシュで許可されるキャッシュ・エントリの数に設定します。次に例を示します。

<federated-scheme>
   <scheme-name>federated</scheme-name>
   <service-name>federated</service-name>
   <backing-map-scheme>
      <local-scheme />
   </backing-map-scheme>
   <autostart>true</autostart>
   <journalcache-highunits>1000</journalcache-highunits>
</federated-scheme>

7.12 フェデレーションの競合の解消

同じエントリの同時更新の間で発生する可能性のある競合の解決に必要となる、カスタム・ロジックをアプリケーションで実装できます。競合を解決するには、は、インターセプタを作成して、フェデレーション固有のイベント・タイプを取得し、必要に応じてカスタム・ロジックを実行します。競合解決ではCoherenceライブ・イベントを使用します(ライブ・イベントの使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照)。

7.12.1 フェデレーテッド接続イベントの処理

フェデレーテッド接続イベント(FederatedConnectionEvent)は、参加者とフェデレーテッド・サービス間の通信を表します。イベント・タイプには、CONNECTING、DISCONNECTED、BACKLOG_EXCESSIVE、BACKLOG_NORMALおよびERRORイベントが含まれます。フェデレーテッド接続イベントの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

フェデレーテッド接続イベントを処理する手順:

  1. イベント・インターセプタを作成して、必要なイベント・タイプを処理し、必要に応じてカスタム・ロジックを実装します。イベント・インターセプタの作成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。次の例に、ERRORイベントを処理し、参加者名をコンソールに出力するインターセプタを示します。

    注意:

    フェデレーテッド接続イベントは、イベントが発生したスレッドと同じスレッド上で発生します。これらのイベントを処理するインターセプタでは、ブロッキング操作を実行しないでください。

    package com.examples

import com.tangosol.internal.federation.service.FederatedCacheServiceDispatcher;
import com.tangosol.net.events.EventDispatcher;
import com.tangosol.net.events.EventDispatcherAwareInterceptor;
import com.tangosol.net.events.federation.FederatedConnectionEvent;
import com.tangosol.net.events.annotation.Interceptor;
import java.util.Map;

@Interceptor(identifier = "testConnection", federatedConnectionEvents =
   FederatedConnectionEvent.Type.ERROR)
public class ConnectionInterceptorImp implements
   EventDispatcherAwareInterceptor<FederatedConnectionEvent>
   {
   @Override
   public void onEvent(FederatedConnectionEvent event)
      {
      System.out.println("Participant in Error: " + event.getParticipantName());
      }

   @Override
   public void introduceEventDispatcher(String sIdentifier, EventDispatcher
      dispatcher)
      {
      if (dispatcher instanceof FederatedCacheServiceDispatcher)
         {
         dispatcher.addEventInterceptor(sIdentifier, this);
         }
      }
   }

  2. フェデレーテッド・キャッシュ・スキームにインターセプタを登録します。イベント・インターセプタの登録の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。次に例を示します。

    <federated-scheme>
   <scheme-name>federated</scheme-name>
   <service-name>federated</service-name>
   <backing-map-scheme>
      <local-scheme />
   </backing-map-scheme>
   <autostart>true</autostart>
   <interceptors>
      <interceptor>
         <name>MyInterceptor</name>
         <instance>
            <class-name>
               com.examples.ConnectionInterceptorImp
            </class-name>
         </instance>
      </interceptor>
   </interceptors>  
   <topologies>
      <topology>
         <name>MyTopology</name>
      </topology>
   </topologies>
</federated-scheme>

  3. インターセプタ実装が実行時にクラスパス上にあることを確認します。

7.12.2 フェデレーテッド変更ベントの処理

フェデレーテッド変更イベント(FederatedChangeEvent)は、ローカル参加者で発生するすべての変更のトランザクション・ビューを表します。単一のパーティションに属するすべての変更は、単一のFederatedChangeEventオブジェクトで取得されます。イベントから、キャッシュ名によって索引付けされるChangeRecordオブジェクトのマップが提供され、変更に関連する参加者名にもアクセスできます。ChangeRecordマップを通して、変更の受入れ、値の変更、または変更の拒否が可能です。オブジェクトでは、PofExtractorおよびPofUpdater APIを使用して、POFエントリの抽出または更新するための方法が提供されます。

イベント・タイプには、COMMITTING_LOCAL、COMMITTING_REMOTEおよびREPLICATINGイベントが含まれます。REPLICATINGイベントは、ローカル・エントリがリモート参加者にフェデレートされる前にディスパッチされます。このイベントは、フェデレーションの前にエントリへの変更を実行するために使用されます。REPLICATINGイベント・インターセプタで実行される変更は、ローカル・キャッシュに反映されません。COMMITTING_LOCALイベントは、エントリがローカルに挿入される前にディスパッチされます。これは、ローカル競合の解決用に設計されています。COMMITTING_REMOTEイベントは、他の参加者からのエントリがローカルに挿入される前にディスパッチされます。これは、フェデレートするエントリとローカル・エントリ間の競合の解決用に設計されています。COMMITTING_LOCALおよびCOMMITTING_REMOTEイベントを処理して実行される変更は、ローカル参加者のキャッシュに反映されます。

注意:

  • アクティブ/アクティブ・フェデレーション・トポロジでは、COMMITTING_REMOTEイベントの処理時にエントリに加えられた変更は、元の参加者に返送されます。これにより、サイクル・ループが発生する場合があり、アクティブ参加者間で変更がループし続けます。

  • COMMITTING_LOCALイベントを取得するインターセプタは、パッシブ・スポーク参加者ではコールされません。

  • 統合操作は、フェデレーション変更イベントには含まれません。

フェデレーテッド変更イベントを処理する手順:

  1. イベント・インターセプタを作成して、必要なイベント・タイプを処理し、必要に応じてカスタム・ロジックを実装します。イベント・インターセプタの作成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。次の例に、REPLICATINGイベントを処理し、エントリがフェデレートされる前にキー名を割り当てるインターセプタを示します。

    package com.examples

import com.tangosol.coherence.federation.events.AbstractFederatedInterceptor;
import com.tangosol.coherence.federation.ChangeRecord;
import com.tangosol.coherence.federation.ChangeRecordUpdater;
import com.tangosol.net.events.annotation.Interceptor;
import com.tangosol.net.events.federation.FederatedChangeEvent;
 
@Interceptor(identifier = "yourIdentifier", federatedChangeEvents =
   FederatedChangeEvent.Type.REPLICATING)
public static class MyInterceptor extends 
   AbstractFederatedInterceptor<String, String>
   {
   public ChangeRecordUpdater getChangeRecordUpdater()
      {
      return updater;
      }
 
   public class ChangeRecordUpdate implements ChangeRecordUpdater<String, String>
      {
      @Override
      public void update(String sParticipant, String sCacheName,
         ChangeRecord<String, String> record)
         {
         if (sParticipant.equals("NewYork") && (record.getKey()).equals("key"))
            {
            record.setValue("newyork-key");
            }
         }
      }

      private ChangeRecordUpdate updater = new ChangeRecordUpdate();
   }

  2. フェデレーテッド・キャッシュ・スキームにインターセプタを登録します。イベント・インターセプタの登録の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。次に例を示します。

    <federated-scheme>
   <scheme-name>federated</scheme-name>
   <service-name>federated</service-name>
   <backing-map-scheme>
      <local-scheme />
   </backing-map-scheme>
   <autostart>true</autostart>
   <interceptors>
      <interceptor>
         <name>MyInterceptor</name>
         <instance>
            <class-name>
               com.examples.MyInterceptor
            </class-name>
         </instance>
      </interceptor>
   </interceptors>  
   <topologies>
      <topology>
         <name>MyTopology</name>
      </topology>
   </topologies>
</federated-scheme>

  3. インターセプタ実装が実行時にクラスパス上にあることを確認します。

7.12.3 カスタム参加者へのイベントのフェデレート

フェデレートされたChangeRecordオブジェクトは、他のクラスタ・メンバーに加えて、クラスタ参加者以外のカスタム参加者にもフェデレートできます。たとえば、ChangeRecordオブジェクトは、ログ、メッセージ・キューまたは場合によっては1つまたは複数のデータベースに保存できます。カスタム参加者は変更レコードのイベント・インターセプタとして実装されます。カスタム参加者は受信者の参加者のみです。

ChangeRecordオブジェクトをカスタム参加者にフェデレートするには、次の手順を実行します。

  1. REPLICATINGイベント・タイプを処理し、ChangeRecordオブジェクトにカスタム・ロジックを実装するには、FederatedChangeEventインターセプタを作成します。イベント・インターセプタの作成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。次の例に、フェデレーション変更レコードを処理するREPLICATINGイベントのインターセプタを示します。

    @Interceptor(identifier = "MyInterceptor", federatedChangeEvents = FederatedChangeEvent.Type.REPLICATING)
public static class MyInterceptorImplChangeEvents implements EventInterceptor<FederatedChangeEvent>
   {
   @Override
   public void onEvent(FederatedChangeEvent event)
      {
      final String sParticipantName = "ForLocalCacheStore";
      if (sParticipantName.equals(event.getParticipant()))
         {
         Map<String, Iterable<ChangeRecord<Object, Object>>> mapChanges = event.getChanges();
         switch (event.getType())
            {
            case REPLICATING:
               m_cEvents++;
               for (Map.Entry<String, Iterable<ChangeRecord<Object, Object>>> entry : mapChanges.entrySet())
                  {
                  for (ChangeRecord<Object, Object> record : entry.getValue())
                     { 
                     if (record.isDeleted()) 
                        { 
                        System.out.printf("deleted key: " + record.getKey()); 
                        } 
                     else 
                        { 
                        System.out.printf("added entry, key: " + record.getKey() + ", value: " + 
                           record.getModifiedEntry().getValue()); 
                        }
                     }
                  }
            break;
         default:
            throw new IllegalStateException("Expected event of type " + FederatedChangeEvent.Type.REPLICATING 
               + ", but got event of type: " + event.getType());
         }
      }
   }

   public long getMessageCount()
      { 
      return m_cEvents; 
      }

   private volatile long m_cEvents;
}

  2. カスタム参加者を操作構成ファイルで構成し、参加者タイプとしてinterceptorを入力します。次に例を示します。

    <participant>
   <name>ForLogging</name>
   <send-timeout>5s</send-timeout>
   <participant-type>interceptor</participant-type>
</participant>

  3. 参加者のインターセプタを<interceptor>要素を使用して登録し、インターセプタ・クラスを指定します。次に例を示します。

    <participant>
   <name>ForLogging</name>
   <send-timeout>5s</send-timeout>
   <participant-type>interceptor</participant-type>
   <interceptors>
      <interceptor>
         <name>MyInterceptor</name>
         <instance>
            <class-name>example.MyInterceptorImplChangeEvents</class-name>
         </instance>
      </interceptor>
   </interceptors>
</participant>

    注意:

    インターセプタ・インスタンスを参加者構成で指定することも(例に示したように)、フェデレーテッド・キャッシュ・スキーマで指定することもできます。参加者構成でインターセプタを指定した場合、その参加者を使用するすべてのフェデレーテッド・キャッシュ・サービスに適用されます。インターセプタを使用するサービスを制御するには、フェデレーテッド・キャッシュ・スキームでインターセプタを指定します。olink:COHDG-GUID-14D28324-2097-491D-987E-5A140205FF32を参照してください。

  4. カスタム参加者をイベントをフェデレートするフェデレーション・トポロジの一部として含めます。次に例を示します。

    <topology-definitions>
   <active-passive>
      <name>Active</name>
      <active>BOSTON</active>
      <active>NEWYORK</active> 
      <interceptor>ForLogging</interceptor>
   </active-passive>
</topology-definitions>

  5. インターセプタ実装が実行時にクラスパス上にあることを確認します。

7.13 フェデレーション通信への特定のネットワーク・インタフェースの使用

フェデレーション通信は、クラスタ通信に使用されるインタフェースと異なるネットワーク・インタフェースを使用するように構成できます。

異なるネットワーク構成をフェデレーション通信に使用する手順:

  1. 各クラスタ参加者でオペレーション・オーバーライド・ファイルを編集して、対象のネットワーク・インタフェースにバインドされる個別のIPアドレスとポートのNameServiceアドレスを定義する<address-provider>要素を含めます。次に例を示します。
    <cluster-config>
   <address-providers>
      <address-provider id="NameServiceAddress">
         <socket-address>
            <address system-property="coherence.nameservice.ip">
               192.168.1.5</address>
            <port system-property="coherence.nameservice.port">
               10100</port>
         </socket-address>
      </address-provider>
   </address-providers>
</cluster-config>
  2. 参加者定義を変更して、リモート・アドレスを使用します。次に例を示します。
    <federation-config>
   <participants>
      <participant>
         <name>LocalClusterA</name>
         <remote-addresses>
            <address-prover>NameServiceAddress</address-provider>
         </remote-addresses>
      </participant>
      ...
  3. クラスタメンバーの起動時(前述の例のLocalClusterA参加者)に、coherence.nameservice.addressproviderシステム・プロパティを使用して、ネーム・サービスのアドレス・プロバイダ定義を参照します。次に例を示します。
    -Dcoherence.nameservice.addressprovider=NameServiceAddress

7.14 フェデレーテッド接続のロード・バランシング

フェデレーテッド・サービス・メンバー間の接続はロード・バランシングされます。デフォルトでは、接続を利用率の低いフェデレーテッド・サービス・メンバーに分散するフェデレーテッド・ベースの戦略が使用されます。必要に応じてカスタムの戦略の作成や、デフォルトの戦略の変更が可能です。また別の戦略として、アドレス・プロバイダ実装を作成するか、フェデレーテッド・サービス・メンバーへの接続のランダム化によってクライアントベースのロード・バランシングの戦略を実装できます。ランダム化のアプローチによってもたらされるバランシングは、フェデレーテッド・ベースのロード・バランシングと比べて最小限にとどまります。

フェデレーテッド・サービス・メンバー間の接続は、既存の接続数および受信メッセージのバックログに基づいて、フェデレーテッド・サービス・メンバー間で均等に分散されます。一般に、このアルゴリズムでは、最適なロード・バランシング戦略が提供されます。ただし、必要に応じて、異なるロード・バランシング戦略の実装を選択することもできます。

7.14.1 フェデレーション・ベースのロード・バランシングの使用

フェデレーション・ベースのロード・バランシングは、接続を複数の同じフェデレーション・サービスのメンバーで調整するデフォルトの戦略です。この戦略では、既存の接続数および受信メッセージのバックログに基づいて、フェデレーテッド・サービス・メンバー間で接続を均等に分散します。

フェデレーション・ベースのロード・バランシング戦略は、federationに設定された<load-balancer>要素を使用して、<federated-scheme>定義内に構成されます。わかりやすいように、次の例ではこの戦略を明示的に指定しています。ただし、戦略が指定されていない場合も、この戦略がデフォルトで使用されるため、フェデレーテッド・スキーム定義では必須ではありません。

<federated-scheme>
   <scheme-name>federated</scheme-name>
   <service-name>federated</service-name>
   <backing-map-scheme>
      <local-scheme />
   </backing-map-scheme>
   <autostart>true</autostart>
   <load-balancer>federation</load-balancer>
   <topologies>
      <topology>
         <name>MyTopology</name>
      </topology>
   </topologies>
</federated-scheme>

7.14.2 カスタムのフェデレーション・ベース・ロード・バランシングの戦略の実装

com.tangosol.coherence.net.federationパッケージには、フェデレーテッド・サービスのメンバー間でクライアントの負荷を調節するために使用するAPIが含まれています。この項で説明するフェデレーテッド・ベースのロード・バランシングAPIの使用方法の詳細は、Oracle Coherence Java APIリファレンスを参照してください。

カスタムの戦略では、FederatedServiceLoadBalancerインタフェースを実装する必要があります。必要に応じて新規の戦略を作成するか、デフォルトの戦略(DefaultFederatedServiceLoadBalancer)を拡張または変更できます。

カスタムのフェデレーション・ベースのロード・バランシング戦略を有効にするには、フェデレーテッド・スキームを編集して、<instance>サブ要素を<load-balancer>内に含め、FederatedServiceLoadBalancerインタフェースを実装するクラスの完全修飾名を指定します。次の例では、MyFederationServiceLoadBalancerクラスに実装されているカスタムのフェデレーション・ベースのロード・バランシング戦略を有効します。

...
<load-balancer>
   <instance>
      <class-name>package.MyFederationServiceLoadBalancer</class-name>
   </instance>
</load-balancer>
...

さらに、<instance要素では、FederatedServiceLoadBalancerインスタンスを作成するためのファクトリ・クラスを使用するために<class-factory-name要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name要素の使用もサポートされています。<instance要素の詳細な手順は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

7.14.3 クライアントベースのロード・バランシングの使用

クライアントベースのロード・バランシングの戦略は、フェデレーテッド・サービス・メンバー間での接続の分散を指定するcom.tangosol.net.AddressProvider実装に依存しています。アドレス・プロバイダ実装が提供されていない場合、構成済の各クラスタ参加者メンバーは、接続が成功するまでランダムな順序で試行されます。アドレス・プロバイダ実装の指定の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

クライアントベースのロード・バランシングの戦略は、clientに設定された<load-balancer>要素を使用して、<federated-scheme>定義内に構成されます。次に例を示します。

<federated-scheme>
   <scheme-name>federated</scheme-name>
   <service-name>federated</service-name>
   <backing-map-scheme>
      <local-scheme />
   </backing-map-scheme>
   <autostart>true</autostart>
   <load-balancer>client</load-balancer>
   <topologies>
      <topology>
         <name>MyTopology</name>
      </topology>
   </topologies>
</federated-scheme>

7.15 フェデレーテッド・キャッシュの管理

フェデレーテッド・キャッシュは、パフォーマンスとリソースの使用を最適にするために、クラスタおよび分散キャッシュと同じように、各クラスタ参加者で管理する必要があります。クラスタが適切に実行されていないと、フェデレーションの一部として含めたときに、パフォーマンスの問題が発生する場合があります。さらに、フェデレーテッド・キャッシュは、フェデレーション内のクラスタ参加者間で効率的なフェデレーション・パフォーマンスとスループット実現できるように管理する必要もあります。ワイド・エリア・ネットワーク・トポロジに固有の問題により、フェデレーション・パフォーマンスの監視が特に重要になります。

7.15.1 クラスタ参加者のステータスの監視

フェデレーション内の各クラスタ参加者のステータスを監視し、問題がないことを確認します。

Coherence-Java VisualVMプラグイン

Coherence Java VisualVMプラグインの「フェデレーション」タブを使用して、ローカル・クラスタ参加者のコンテキストから、各クラスタ参加者のステータスを表示します。つまり、各宛先クラスタ参加者がリストされ、そのステータスが表示されます。また、ローカル・クラスタ参加者の各ノードのフェデレーション状態が「アウトバウンド」タブにレポートされます。クラスタ参加者のステータスがErrorの場合は、「エラーの説明」フィールドを選択して、エラー・メッセージを表示します。

Coherenceレポート

フェデレーション宛先レポート(federation-destination.txt)を使用して、各宛先クラスタ参加者のステータスおよび各ノードのフェデレーション状態を時系列で表示します。

Coherence MBean

DestinationMBean MBeanの永続性の属性を使用して、各宛先クラスタ参加者のステータスおよびローカル・クラスタ参加者の各ノードのフェデレーション状態を表示します。

7.15.2 フェデレーションのパフォーマンスおよびスループットの監視

フェデレーション・パフォーマンスとスループットを監視し、大幅な遅延やデータの損失がなく、ローカル・クラスタ参加者が各参加者にデータをフェデレートしていることを確認します。パフォーマンおよびスループットの問題は、クラスタ参加者間のネットワーク接続またはローカル・クラスタ参加者に問題が発生していることを示す場合があります。

Coherence-Java VisualVMプラグイン

Coherence-Java VisualVMプラグインの「フェデレーション」タブを使用して、ローカル参加者から各宛先クラスタ参加者への現在のフェデレーション・パフォーマンスの統計とスループットを表示します。宛先クラスタ参加者を選択して、そのフェデレーション・パフォーマンス統計を表示し、「アウトバウンド」タブの「現行のスループット」列を表示して、ローカル・クラスタの各ノードから、選択した参加者へのスループットを確認します。「アウトバウンド」タブで各ノードを選択して、帯域幅の使用量とフェデレーション・パフォーマンスをグラフ・タブでそれぞれ確認します。最後に、「インバウンド」タブを選択して、宛先クラスタ参加者からローカル・クラスタ参加者へのデータの受信効率を表示します。

Coherenceレポート

フェデレーション宛先レポート(federation-destination.txt)およびフェデレーション・オリジン・レポート(federation-origin.txt)を使用して、フェデレーション・パフォーマンス統計を表示します。宛先レポートには、ローカル・クラスタ参加者の各ノードから各宛先クラスタ参加者へのデータの送信効率が表示されます。フェデレーション・オリジン・レポートには、宛先クラスタ参加者からローカル・クラスタ参加者の各ノードへのデータの受信効率が表示されます。

Coherence MBean

DestinationMBean MBeanおよびOriginMBean MBeanの永続性の属性を使用して、フェデレーション・パフォーマンス統計を表示します。DestinationMBean MBeanの属性には、ローカル・クラスタ参加者の各ノードから各宛先クラスタ参加者へのデータの送信効率が表示されます。OriginMBean MBeanには、宛先クラスタ参加者からローカル・クラスタ参加者へのデータの受信効率が表示されます。

前
前 		次
次
目次へ移動
目次