この章の内容は次のとおりです。
親トピック: 高度な管理
複数フェデレーション・トポロジ
フェデレーテッド・キャッシュでは、複数のフェデレーション・トポロジをサポートしています。これらには、アクティブ/アクティブ、アクティブ/パッシブ、ハブ/スポーク、集中型のフェデレーションなどがあります。トポロジでは、クラスタ間の一般的なフェデレーション戦略を定義し、様々なユース・ケースをサポートします。必要に応じて、カスタム・フェデレーション・トポロジを作成することもできます。
競合の解決
フェデレーテッド・キャッシュでは、ローカルまたはリモートで格納されているキャッシュ・エントリの受入れ、拒否、または変更をアプリケーションで実行できます。競合解決は、フェデレーション・ルールを定義する場合に柔軟性を最大限に高めることができるアプリケーションです。
フェデレーション構成
フェデレーテッド・キャッシュは、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プラグインのタブを使用して管理および監視できます。
フェデレーテッド・キャッシュの設定手順:
フェデレーション参加者を定義するには、<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>
<address>
要素はローカル・アドレスを示す外部NATアドレスもサポートします。ただし、外部およびローカル・アドレスは同一のポート番号を使用する必要があります。デフォルト設定は次のとおりです。
クラスタの起動時のクラスタ参加者のフェデレーションの状態
宛先クラスタに対する接続タイムアウト
宛先クラスタからの確認メッセージの送信タイムアウト
フェデレートされたデータを送信するための最大帯域幅
参加者の場所のメタデータ
フェデレーション参加者のデフォルト設定を変更するには、クラスタのオペレーション・オーバーライド・ファイルを編集して、<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> <name-service-addresses> <address>192.168.1.7</address> </name-service-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>
...
フェデレーション・サービス・リソースの使用を制限するには、フェデレーテッド・キャッシュ・スキームを編集して、<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>
この項には次のトピックが含まれます:
フェデレーテッド接続イベント(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-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には、宛先クラスタ参加者からローカル・クラスタ参加者へのデータの受信効率が表示されます。