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プラグインのタブを使用して管理および監視できます。
Coherenceフェデレーションの管理の詳細は、「フェデレーテッド・キャッシングの管理」を参照してください。
親トピック: クラスタ間のキャッシュのフェデレート
フェデレーテッド・キャッシュの設定の一般的なステップ
フェデレーテッド・キャッシュを設定するには:
- フェデレーションに参加しているすべてのクラスタが稼働しており、各クラスタの少なくとも1つのキャッシュ・サーバーのアドレス(ホストおよびクラスタ・ポート)が判明していることを確認します。
- フェデレーション内にあるクラスタ参加者のリストを使用して、各クラスタを構成します。フェデレーション参加者の定義を参照してください。
- クラスタ参加者間でデータをどのようにフェデレートするかを指定するトポロジ定義を使用して、各クラスタを構成します。フェデレーション・トポロジの定義を参照してください。
- キャッシュ・データの格納に使用されるフェデレーテッド・キャッシュ・スキームを使用して、各クラスタを構成します。フェデレーテッド・キャッシュ・スキームの定義を参照してください。
- 定義されたフェデレーション・トポロジを使用するよう各クラスタでフェデレーテッド・キャッシュを構成します。フェデレーテッド・キャッシュとフェデレーション・トポロジの関連付けを参照してください。
親トピック: クラスタ間のキャッシュのフェデレート
フェデレーション参加者の定義
フェデレーション参加者を定義するには、<participants>
要素内に任意の数の<participant>
要素を含めます。<name>
要素を使用して、参加者の名前を定義し、<remote-addresses>
要素を使用して、参加者クラスタに配置されている少なくとも1つのキャッシュ・サーバーまたはプロキシのアドレスおよびポートを定義します。NameService
サービスを使用してエフェメラル・ポートを検索する場合は、クラスタ・ポートを入力します。正確なポートを入力すると、通常はアドレス参照にNameService
サービスを使用できない環境でのみ使用されます。次の例では、複数の参加者を定義しており、リモート・アドレスを指定する両方の方法を説明しています。
<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>9001</port> </socket-address> </remote-addresses> </participant> <participant> <name>RemoteClusterC</name> <remote-addresses> <socket-address> <address>192.168.19.25</address> <port>9001</port> </socket-address> </remote-addresses> </participant> </participants> </federation-config>
<address>
要素はローカル・アドレスを示す外部NATアドレスもサポートします。ただし、外部およびローカル・アドレスは同一のポート番号を使用する必要があります。
親トピック: クラスタ間のキャッシュのフェデレート
フェデレーション参加者のデフォルト設定の変更
デフォルト設定は次のとおりです。
-
クラスタの起動時のクラスタ参加者のフェデレーションの状態
-
宛先クラスタに対する接続タイムアウト
-
宛先クラスタからの確認メッセージの送信タイムアウト
-
フェデレートされたデータを宛先参加者に送信するためのメンバー当たりの最大帯域幅。この値は、宛先参加者のソース・メンバーの構成からロードされます。
ノート:
最大帯域幅の値は、10進数と単位(Mbps、KBpsなど)の組合せとして指定できます。単位が指定されていない場合、bps (ビット/秒)の単位が使用されます。 -
参加者の場所のメタデータ
フェデレーション参加者のデフォルト設定を変更するには、クラスタのオペレーション・オーバーライド・ファイルを編集して、<participant>
定義を変更します。必要に応じて、各設定の値を更新します。たとえば:
<participant> <name>ClusterA</name> <initial-action>start</initial-action> <connect-timeout>1m</connect-timeout> <send-timeout>5m</send-timeout> <max-bandwidth>100Mbps</max-bandwidth> <geo-ip>Philadelphia</geo-ip> <remote-addresses> <socket-address> <address>192.168.1.7</address> <port>7574</port> </socket-address> </remote-addresses> </participant>
親トピック: クラスタ間のキャッシュのフェデレート
フェデレーション・トポロジの理解
サポートされるフェデレーション・トポロジは次のとおりです。
アクティブ/パッシブ・トポロジ
アクティブ/パッシブ・トポロジは、アクティブ・クラスタからパッシブ・クラスタにデータをフェデレートする場合に使用されます。アクティブ・クラスタに置かれるデータは、パッシブ・クラスタにフェデレートされます。データがパッシブ・クラスタに置かれると、アクティブ・クラスタにはフェデレートされません。キャッシュ・データのコピーが読取り専用の操作に必要な場合、またはオフサイト・バックアップが必要な場合は、アクティブ/パッシブ・トポロジの使用を検討してください。
図7-1に、アクティブ/パッシブ・トポロジの概念図を示します。
アクティブ/アクティブ・トポロジ
アクティブ/アクティブ・トポロジは、アクティブ・クラスタ間でデータをフェデレートする場合に使用されます。一方のアクティブ・クラスタに置かれるデータは、もう一方のアクティブ・クラスタでフェデレートされます。アクティブ/アクティブ・トポロジにより、キャッシュ・データは常にクラスタ間で同期されます。地理的に分散した複数の場所のアプリケーションからローカル・クラスタ・インスタンスにアクセスできるようにするには、アクティブ/アクティブ・トポロジの使用を検討してください。
図7-2に、アクティブ/アクティブ・トポロジの概念図を示します。
ハブおよびスポーク・トポロジ
ハブおよびスポーク・トポロジは、単一のハブ・クラスタから複数のスポーク・クラスタにデータをフェデレートする場合に使用されます。ハブ・クラスタはデータの送信のみ可能で、スポーク・クラスタはデータの受信のみ可能です。地理的に分散したクラスタの複数のコピーが必要な場合は、ハブおよびスポーク・トポロジの使用を検討してください。各スポーク・クラスタは読取り専用を実行するためにローカル・アプリケーションで使用できます。
図7-3に、ハブおよびスポーク・トポロジの概念図を示します。
集中型フェデレーション・トポロジ
集中型フェデレーション・トポロジは、単一のハブから複数のリーフ・クラスタにデータをフェデレートする場合に使用されます。さらに、各リーフでは、データをハブ・クラスタに送信可能で、ハブ・クラスタは、データを他のすべてのリーフ・クラスタに再送信する(繰り返す)ことができます。地理的に分散した複数の場所のアプリケーションからローカル・クラスタ・インスタンスにアクセスできるようにするには、集中型フェデレーション・トポロジの使用を検討してください。
図7-4に、集中型フェデレーション・トポロジの概念図を示します。
カスタム・フェデレーション・トポロジ
カスタム・フェデレーション・トポロジは、自由形式のトポロジの作成に使用されます。クラスタはグループに編成され、各クラスタはグループ内のロールで指定されます。ロールには、送信者、受信者またはリピータが含まれます。送信者の参加者は、ローカル・クラスタ上で発生している変更のフェデレートのみが可能です。リピータは、ローカル・クラスタの変更および他の参加者から受信した変更の両方をフェデレートします。グループ内の他のクラスタにデータをフェデレートできるのは、送信者およびリピータのクラスタのみです。事前定義済のフェデレーション・トポロジでキャッシュのフェデレーション要件に対応できない場合は、カスタム・フェデレーション・トポロジの作成を検討してください。
図7-5に、1つの予想される構成のカスタム・フェデレーション・トポロジの概念図を示します。
親トピック: クラスタ間のキャッシュのフェデレート
フェデレーション・トポロジの定義
フェデレーション・トポロジは、<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-active>
要素を<topology-definitions>
要素内に含めます。<name>
要素を使用して、このトポロジの参照に使用される名前を含めます。<active>
要素を使用して、アクティブ参加者を定義します。たとえば:
<federation-config> ... <topology-definitions> <active-active> <name>MyTopology</name> <active>LocalClusterA</active> <active>RemoteClusterB</active> </active-active> </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>
要素は、フェデレーテッド・キャッシュの定義に使用されます。キャッシュ構成ファイルで、フェデレーテッド・キャッシュを必要な数だけ定義できます。Oracle Coherenceでのアプリケーションの開発のfederated-schemeを参照してください。
すべての参加者のフェデレーテッド・キャッシュは、同じフェデレーテッド・サービス・インスタンスで管理する必要があります。サービスは、<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>
親トピック: クラスタ間のキャッシュのフェデレート
フェデレートからのキャッシュの除外
キャッシュがフェデレートされないように除外するには、キャッシュ・マッピング定義の一部として、<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>
...
親トピック: クラスタ間のキャッシュのフェデレート
フェデレーション・サービス・リソースの使用の制限
ERROR
状態に移行され、保留中のすべてのエントリがフェデレーションの内部バックログ・キャッシュから削除されます。
フェデレーション・サービス・リソースの使用を制限するには、フェデレーテッド・キャッシュ・スキームを編集して、<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>2G</journalcache-highunits> </federated-scheme>
ノート:
<journalcache-highunits>
の有効な値は、G、K、Mでのメモリー値(1G、2K、3Mなど)または正の整数とゼロです。メモリー値は、フェデレーションのバックログに対するメモリー制限とみなされます。単位が指定されていない場合、値はバックログのエントリ数に対する制限とみなされます。ゼロは制限がないことを示します。デフォルト値は0 (ゼロ)です。
親トピック: クラスタ間のキャッシュのフェデレート
フェデレーションの競合の解消
この項には次のトピックが含まれます:
フェデレーテッド接続イベントの処理
フェデレーテッド接続イベント(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(); }
-
フェデレーテッド・キャッシュ・スキームにインターセプタを登録します。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>
-
インターセプタ実装が実行時にクラスパス上にあることを確認します。
親トピック: フェデレーションの競合の解消
カスタム参加者へのイベントのフェデレート
フェデレートされたChangeRecord
オブジェクトは、他のクラスタ・メンバーに加えて、クラスタ参加者以外のカスタム参加者にもフェデレートできます。たとえば、ChangeRecord
オブジェクトは、ログ、メッセージ・キューまたは場合によっては1つまたは複数のデータベースに保存できます。カスタム参加者は変更レコードのイベント・インターセプタとして実装されます。カスタム参加者は受信者の参加者のみです。
ChangeRecord
オブジェクトをカスタム参加者にフェデレートするには:
-
REPLICATING
イベント・タイプを処理し、ChangeRecord
オブジェクトにカスタム・ロジックを実装するには、FederatedChangeEvent
インターセプタを作成します。Oracle Coherenceでのアプリケーションの開発のライブ・イベントの処理を参照してください。次の例に、フェデレーション変更レコードを処理するREPLICATING
イベントのインターセプタを示します。ChangeRecord
オブジェクトのMap
は複数のキャッシュからなりうることに注意してください。Map
内の各エントリに対し、キーはキャッシュ名および値はそのキャッシュ内のChangeRecord
オブジェクトのリストです。@Interceptor(identifier = "MyInterceptor", federatedChangeEvents = FederatedChangeEvent.Type.REPLICATING) public class MyInterceptorImplChangeEvents implements EventInterceptor<FederatedChangeEvent> { @Override public void onEvent(FederatedChangeEvent event) { final String sParticipantName = "ForLogging"; 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() + "\n"); } else { System.out.printf("modified 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; }
-
カスタム参加者を操作構成ファイルで構成し、参加者タイプとして
interceptor
を入力し、インターセプタ・クラスを<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>
ノート:
インターセプタ・クラスを参加者構成で指定することも(例に示したように)、フェデレーテッド・キャッシュ・スキーマで登録することもできます。参加者構成でインターセプタ・クラスを登録した場合、その参加者を使用するすべてのフェデレーテッド・キャッシュ・サービスに適用されます。インターセプタを使用するサービスを制御するには、フェデレーテッド・キャッシュ・スキームでインターセプタを指定します。Oracle Coherenceでのアプリケーションの開発のfederated-schemeを参照してください。
-
カスタム参加者をイベントをフェデレートするフェデレーション・トポロジの一部として含めます。たとえば:
<topology-definitions> <active-active> <name>Active</name> <active>BOSTON</active> <active>NEWYORK</active> <interceptor>ForLogging</interceptor> </active-active> </topology-definitions>
-
インターセプタ実装が実行時にクラスパス上にあることを確認します。
親トピック: フェデレーションの競合の解消
フェデレーション通信への特定のネットワーク・インタフェースの使用
異なるネットワーク構成をフェデレーション通信に使用するには:
親トピック: クラスタ間のキャッシュのフェデレート
フェデレーテッド接続のロード・バランシング
フェデレーテッド・サービス・メンバー間の接続は、既存の接続数および受信メッセージのバックログに基づいて、フェデレーテッド・サービス・メンバー間で均等に分散されます。一般に、このアルゴリズムでは、最適なロード・バランシング戦略が提供されます。ただし、必要に応じて、異なるロード・バランシング戦略の実装を選択することもできます。
この項には次のトピックが含まれます:
親トピック: クラスタ間のキャッシュのフェデレート
フェデレーション・ベースのロード・バランシングの使用
フェデレーション・ベースのロード・バランシングは、接続を複数の同じフェデレーション・サービスのメンバーで調整するデフォルトの戦略です。この戦略では、既存の接続数および受信メッセージのバックログに基づいて、フェデレーテッド・サービス・メンバー間で接続を均等に分散します。
フェデレーション・ベースのロード・バランシング戦略は、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が含まれています。
カスタムの戦略では、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>
要素の使用もサポートされています。Oracle Coherenceでのアプリケーションの開発のinstanceを参照してください。
親トピック: フェデレーテッド接続のロード・バランシング
クライアントベースのロード・バランシングの使用
クライアントベースのロード・バランシングの戦略は、フェデレーテッド・サービス・メンバー間での接続の分散を指定するcom.tangosol.net.AddressProvider
実装に依存しています。アドレス・プロバイダ実装が提供されていない場合、構成済の各クラスタ参加者メンバーは、接続が成功するまでランダムな順序で試行されます。Oracle Coherenceでのアプリケーションの開発のaddress-providerを参照してください。
クライアントベースのロード・バランシングの戦略は、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 VisualVMプラグイン: 『Oracle Coherenceのマネージメント』のCoherence VisualVMプラグインの使用に関する項を参照してください。
- Coherenceレポート: 『Oracle Coherenceのマネージメント』のフェデレーション宛先レポートの理解に関する項を参照してください。
- Coherence MBean: 『Oracle Coherenceのマネージメント』の宛先MBeanに関する項を参照してください。
- Coherenceコマンドライン・インタフェース: Coherence CLIを参照してください。
- Coherence Grafanaダッシュボード: 『Oracle Coherenceのマネージメント』のGrafanaでのメトリックのビジュアル化に関する項を参照してください。
この項には次のトピックが含まれます:
クラスタ参加者のステータスの監視
フェデレーション内の各クラスタ参加者のステータスを監視し、問題がないことを確認します。
Coherence-Java VisualVMプラグイン
Coherence Java VisualVMプラグインの「フェデレーション」タブを使用して、ローカル・クラスタ参加者のコンテキストから、各クラスタ参加者のステータスを表示します。つまり、各宛先クラスタ参加者がリストされ、そのステータスが表示されます。また、ローカル・クラスタ参加者の各ノードのフェデレーション状態が「アウトバウンド」タブにレポートされます。クラスタ参加者のステータスがError
の場合は、「エラーの説明」フィールドを選択して、エラー・メッセージを表示します。
Coherenceレポート
フェデレーション宛先レポート(federation-destination.txt
)を使用して、各宛先クラスタ参加者のステータスおよび各ノードのフェデレーション状態を時系列で表示します。
Coherence MBean
Destination
MBeanのフェデレーション属性を使用して、各宛先クラスタ参加者のステータスおよびローカル・クラスタ参加者の各ノードのフェデレーション状態を表示します。
Grafanaダッシュボード
GrafanaでCoherenceフェデレーション・サマリー・ダッシュボードに移動し、各サービスおよび参加者の「Status」列を表示します。この値がWARNINGまたはERRORになっている場合は、送信ノードのCoherenceログ・ファイルを調査して、ステータスの理由を判断する必要があります。
親トピック: フェデレーテッド・キャッシュの管理
フェデレーションのパフォーマンスおよびスループットの監視
フェデレーション・パフォーマンスとスループットを監視し、大幅な遅延やデータの損失がなく、ローカル・クラスタ参加者が各参加者にデータをフェデレートしていることを確認します。パフォーマンおよびスループットの問題は、クラスタ参加者間のネットワーク接続またはローカル・クラスタ参加者に問題が発生していることを示す場合があります。
Coherence-Java VisualVMプラグイン
Coherence-Java VisualVMプラグインの「フェデレーション」タブを使用して、ローカル参加者から各宛先クラスタ参加者への現在のフェデレーション・パフォーマンスの統計とスループットを表示します。宛先クラスタ参加者を選択して、そのフェデレーション・パフォーマンス統計を表示し、「アウトバウンド」タブの「現行のスループット」列を表示して、ローカル・クラスタの各ノードから、選択した参加者へのスループットを確認します。「アウトバウンド」タブで各ノードを選択して、帯域幅の使用量とフェデレーション・パフォーマンスをグラフ・タブでそれぞれ確認します。最後に、「インバウンド」タブを選択して、宛先クラスタ参加者からローカル・クラスタ参加者へのデータの受信効率を表示します。
Coherenceレポート
フェデレーション宛先レポート(federation-destination.txt
)およびフェデレーション・オリジン・レポート(federation-origin.txt
)を使用して、フェデレーション・パフォーマンス統計を表示します。宛先レポートには、ローカル・クラスタ参加者の各ノードから各宛先クラスタ参加者へのデータの送信効率が表示されます。フェデレーション・オリジン・レポートには、宛先クラスタ参加者からローカル・クラスタ参加者の各ノードへのデータの受信効率が表示されます。
Coherence MBean
DestinationMBean
MBeanおよびOriginMBean
MBeanの永続性の属性を使用して、フェデレーション・パフォーマンス統計を表示します。DestinationMBean
MBeanの属性には、ローカル・クラスタ参加者の各ノードから各宛先クラスタ参加者へのデータの送信効率が表示されます。OriginMBean
MBeanには、宛先クラスタ参加者からローカル・クラスタ参加者へのデータの受信効率が表示されます。
Grafanaダッシュボード
- 宛先表には、その宛先の各送信ノードのメトリックおよび接続のステータスが表示されます。各ステータス値の詳細は、『Oracle Coherenceのマネージメント』の宛先MBeanに関する項を参照してください。
- 現在のエンベロープ・サイズは、すべてのノードで宛先への送信を待機しているメッセージの数を示します。
- 現在使用中のRAMジャーナルおよびフラッシュ・ジャーナル。
- 各ノードの平均適用時間、ラウンドトリップ遅延およびバックログ遅延。
ノート:
パーティションごとに少なくとも1つのエントリがあるため、現在のエンベロープ・サイズがゼロになることはありません。この値を監視する必要があります。値が(RAMまたはフラッシュ・ジャーナルとともに)継続的な上昇傾向にある場合、メンバーが宛先参加者にデータを送信する能力に問題がある可能性があります。これらの値は、replicate-all操作が原因で上昇傾向を示すことがありますが、操作の完了後は通常のレベルに戻るはずです。戻らない場合は、宛先参加者の状態をさらに調査して根本原因を特定する必要があります。親トピック: フェデレーテッド・キャッシュの管理