7 クラスタ間のキャッシュのレプリケート

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

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

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

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

複数レプリケーション・トポロジ

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

競合解決

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

レプリケーション構成

フェデレーテッド・キャッシュは、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プラグインのタブを使用して管理および監視できます。

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

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

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

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

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

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

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

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

フェデレーション参加者は、デフォルト設定をオーバーライドするように明示的に構成できます。各設定の詳細は、『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>
   <remote-addresses>
      <socket-address>
         <address>localhost</address>
         <port>7574</port>
      </socket-address>
   </remote-addresses>
</participant>

レプリケーション・トポロジの理解

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

サポートされるレプリケーション・トポロジは次のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

集中型レプリケーション・トポロジ

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

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

図7-4 集中型レプリケーション・トポロジ

「図7-4 集中型レプリケーション・トポロジ」の説明

カスタム・レプリケーション・トポロジ

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

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

図7-5 カスタム・レプリケーション・トポロジ

「図7-5 カスタム・レプリケーション・トポロジ」の説明

レプリケーション・トポロジの定義

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

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

注意:

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

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

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

アクティブ/パッシブ・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<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にレプリケートされません。

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

アクティブ/アクティブ・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<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にレプリケートされます。

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

ハブおよびスポーク・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<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にレプリケートされません。

集中型レプリケーション・トポロジの定義

集中型レプリケーション・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<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にレプリケートされ、他のクラスタ参加者にデータが再送信されます。

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

カスタム・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<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にレプリケートされません。

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

<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>

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

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

注意:

トポロジが定義されていない場合(すべての参加者がアクティブ/アクティブ・トポロジにいると見なされる)、またはトポロジが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>

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

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

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

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

フェデレーション・サービス・リソースの使用を制限するには、フェデレーテッド・キャッシュ・スキームを編集して、<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>

レプリケーション競合の解決

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

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

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

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

イベント・インターセプタを作成して、必要なイベント・タイプを処理し、必要に応じてカスタム・ロジックを実装します。イベント・インターセプタの作成の詳細は、『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);
         }
      }
   }

フェデレーテッド・キャッシュ・スキームにインターセプタを登録します。イベント・インターセプタの登録の詳細は、『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>

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

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

フェデレーテッド変更イベント(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イベントを取得するインターセプタは、パッシブ・スポーク参加者ではコールされません。
統合操作は、フェデレーション変更イベントには含まれません。

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

イベント・インターセプタを作成して、必要なイベント・タイプを処理し、必要に応じてカスタム・ロジックを実装します。イベント・インターセプタの作成の詳細は、『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();
   }

<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>

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

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

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

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

各クラスタ参加者でオペレーション・オーバーライド・ファイルを編集して、対象のネットワーク・インタフェースにバインドされる個別の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>

参加者定義を変更して、リモート・アドレスを使用します。次に例を示します。

<federation-config>
   <participants>
      <participant>
         <name>LocalClusterA</name>
         <remote-addresses>
            <address-prover>NameServiceAddress</address-provider>
         </remote-addresses>
      </participant>
      ...

クラスタメンバーの起動時(前述の例のLocalClusterA参加者)に、coherence.nameservice.addressproviderシステム・プロパティを使用して、ネーム・サービスのアドレス・プロバイダ定義を参照します。次に例を示します。
```
-Dcoherence.nameservice.addressprovider=NameServiceAddress
```

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

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

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

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

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

フェデレーション・ベースのロード・バランシング戦略は、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>

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

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

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

クライアントベースのロード・バランシングの戦略は、フェデレーテッド・サービス・メンバー間での接続の分散を指定する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>

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

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

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

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

Coherence-Java VisualVMプラグイン

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

Coherenceレポート

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

Coherence MBean

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

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

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

Coherence-Java VisualVMプラグイン

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

Coherenceレポート

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

Coherence MBean

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