構成および設定も含むJavaの完全な例については、「最初のExtendクライアントの構築」を参照してください。
この章の内容は次のとおりです。
Coherence*Extendでは、クライアント側とクラスタ側の両方の構成が必要です。クラスタ側では、クライアント・リクエストを受け入れるために拡張プロキシ・サービスが設定されます。プロキシ・サービスを使用することにより、クラスタ上で実行されるキャッシュ・サービス・インスタンスおよび起動サービス・インスタンスにアクセスできます。クライアント側では、リモート・キャッシュ・サービスおよびリモート起動サービスを構成し、それを使用して拡張プロキシ・サービス経由でクラスタにアクセスします。Extendクライアントと拡張プロキシ・サービスの間の通信にはTCP/IPが使用されます。
拡張プロキシ・サービスは、キャッシュ構成デプロイメント・ディスクリプタで構成されます。このデプロイメント・ディスクリプタは、多くの場合、クラスタ側のキャッシュ構成ファイルと呼ばれます。これは、クラスタでキャッシュを設定する際に使用するキャッシュ構成ファイルと同じです。Extendクライアントも、キャッシュ構成デプロイメント・ディスクリプタを使用して構成されます。このデプロイメント・ディスクリプタは、クライアントでデプロイされ、多くの場合、クライアント側のキャッシュ構成ファイルと呼ばれます。キャッシュ構成デプロイメント・ディスクリプタの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
Extendクライアントは、リモート・キャッシュ・サービスおよびリモート起動サービスを使用して、Coherenceクラスタと相互作用します。リモート・キャッシュ・サービスとリモート起動サービスはいずれも、Extendクライアント・アプリケーションが起動するときにクラスパス上で検出されるキャッシュ構成デプロイメント・ディスクリプタで構成されます。
リモート・キャッシュとは、キャッシュ操作をクラスタ上のキャッシュにルーティングする、専用のキャッシュ・サービスです。リモート・キャッシュとクラスタ上のキャッシュは、同じキャッシュ名である必要があります。Extendクライアントでは、NamedCache
インタフェースを通常どおりに使用して、キャッシュのインスタンスを取得します。実行時、キャッシュ操作は、ローカルでは実行されず、TCP/IPを使用してクラスタ上の拡張プロキシ・サービスに送信されます。キャッシュ操作をクラスタ上のキャッシュに委任する処理は、Extendクライアントに対して透過的に行われます。
リモート・キャッシュは、<caching-schemes
ノード内で、<remote-cache-scheme
要素を使用して定義されます。例4-1 では、ExtendTcpCacheService
という名前のリモート・キャッシュ・スキームを作成してネーム・サービスに接続し、このネーム・サービスが、リクエストされたプロキシ・サービスのアドレスにリクエストをリダイレクトします。ネーム・サービスを使用すると、ポート管理とファイアウォール構成が簡素化します。<remote-cache-scheme
サブ要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
例4-1 リモート・キャッシュの定義
... <caching-scheme-mapping> <cache-mapping> <cache-name>dist-extend</cache-name> <scheme-name>extend-dist</scheme-name> </cache-mapping> </caching-scheme-mapping> <caching-schemes> <remote-cache-scheme> <scheme-name>extend-dist</scheme-name> <service-name>ExtendTcpCacheService</service-name> <initiator-config> <tcp-initiator> <name-service-addresses> <socket-address> <address>198.168.1.5</address> <port>7574</port> </socket-address> </name-service-addresses> </tcp-initiator> <outgoing-message-handler> <request-timeout>5s</request-timeout> </outgoing-message-handler> </initiator-config> </remote-cache-scheme> </caching-schemes> ...
<service-name>
の値がクラスタ上のプロキシ・スキームの<service-name>
の値と異なる場合、<proxy-service-name>
要素を使用して、プロキシ・スキームで構成された<service-name>
要素の値を入力します。次に例を示します。
<remote-cache-scheme> <scheme-name>extend-dist</scheme-name> <service-name>ExtendTcpCacheService</service-name> <proxy-service-name>SomeOtherProxyService</proxy-service-name> ...
例4-1 に構成されているように、リモート・キャッシュ・スキームは<name-service-addresses>
要素を使用して、クラスタ上のネーム・サービスのソケット・アドレス(IPまたはDNS名、およびポート)を定義します。ネーム・サービスは、デフォルトでクラスタ・ポート(7574)でリスニングし、クラスタ・ノードを実行するすべてのマシンで使用できます。ターゲット・クラスタがデフォルトのクラスタ・ポートを使用する場合、ポートを構成から省略できます。さらに、Extendクライアントは、デフォルトでクラスタ検出アドレスを使用して、クラスタとプロキシを検出します。Extendクライアントがクラスタと同じネットワーク上にある場合は、クラスタ側の同じクラスタ名を指定するキャッシュ構成ファイルをクライアントが使用しないかぎり、特定の構成は不要です。
<name-services-addresses>
要素では、オペレーション・オーバーライド構成ファイルで構成されたソケット・アドレスの参照に<address-provider>
を使用することもできます。詳細は、「TCPアドレス用のアドレス・プロバイダ参照の使用」を参照してください。プロキシのアドレスおよびポートの明示的な定義の詳細は、「特定のプロキシ・アドレスへの接続」を参照してください。
注意:
ネーム・サービスを使用するように構成されたクライアントは、そのネーム・サービスもサポートするCoherenceバージョンにしか接続できません。さらに、以前のCoherenceリリースでは、ネーム・サービスは、クラスタ・ポートではなく、メンバーのユニキャスト・ポートで自動的にリスニングしていました。
Extendクライアントでは通常、リモート・キャッシュをニア・キャッシュの一部として使用します。この場合、ローカル・キャッシュをフロント・キャッシュとして使用し、リモート・キャッシュをバック・キャッシュとして使用します。次の例では、ローカル・キャッシュとリモート・キャッシュを同時に使用するニア・キャッシュを作成します。
... <caching-scheme-mapping> <cache-mapping> <cache-name>dist-extend-near</cache-name> <scheme-name>extend-near</scheme-name> </cache-mapping> </caching-scheme-mapping> <caching-schemes> <near-scheme> <scheme-name>extend-near</scheme-name> <front-scheme> <local-scheme> <high-units>1000</high-units> </local-scheme> </front-scheme> <back-scheme> <remote-cache-scheme> <scheme-ref>extend-dist</scheme-ref> </remote-cache-scheme> </back-scheme> <invalidation-strategy>all</invalidation-strategy> </near-scheme> <remote-cache-scheme> <scheme-name>extend-dist</scheme-name> <service-name>ExtendTcpCacheService</service-name> <initiator-config> <tcp-initiator> <name-service-addresses> <socket-address> <address>198.168.1.5</address> <port>7574</port> </socket-address> </name-service-addresses> </tcp-initiator> <outgoing-message-handler> <request-timeout>5s</request-timeout> </outgoing-message-handler> </initiator-config> </remote-cache-scheme> </caching-schemes> ...
リモート起動スキームでは、クライアントがリモートのCoherenceクラスタでタスクを実行する際に使用する起動サービスを定義します。Extendクライアントでは、InvocationService
インタフェースを通常どおりに使用します。実行時に、拡張プロキシ・サービスに対してTCP/IP接続が行われ、InvocationService
の実装が返されます。これによって、クライアントの接続先のリモート・クラスタJVM内で同期Invocable
タスクが実行されます。
リモート起動スキームは、<caching-schemes
ノード内で、<remote-invocation-scheme
要素を使用して定義されます。例4-2 では、ExtendTcpInvocationService
という名前のリモート起動スキームを定義し、<name-service-address
要素を使用して、ネーム・サービスがリスニングするアドレスを構成します。<remote-invocation-scheme
サブ要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
例4-2 リモート起動スキームの定義
... <caching-schemes> <remote-invocation-scheme> <scheme-name>extend-invocation</scheme-name> <service-name>ExtendTcpInvocationService</service-name> <initiator-config> <tcp-initiator> <name-service-addresses> <socket-address> <address>198.168.1.5</address> <port>7574</port> </socket-address> </name-service-addresses> </tcp-initiator> <outgoing-message-handler> <request-timeout>5s</request-timeout> </outgoing-message-handler> </initiator-config> </remote-invocation-scheme> </caching-schemes> ...
<service-name>
の値がクラスタ上のプロキシ・スキームの<service-name>
の値と異なる場合、<proxy-service-name>
要素を使用して、プロキシ・スキームで構成された<service-name>
要素の値を入力します。次に例を示します。
<remote-cache-scheme> <scheme-name>extend-dist</scheme-name> <service-name>ExtendTcpInvocationService</service-name> <proxy-service-name>SomeOtherProxyService</proxy-service-name> ...
クライアントがネーム・サービス機能に対応していない、またはクライアントに特定のファイアウォールの制約がある場合、そのクライアントは特定のプロキシ・アドレスに接続できます。ファイアウォール構成の詳細は、「Extendクライアントのファイアウォールの構成」を参照してください。
例4-1 では、<socket-address>
要素を使用して、拡張プロキシ・サービスがリスニングするアドレス(198.168.1.5
およびポート7077
)を明示的に構成しています。アドレスは、オペレーション構成オーバーライド・ファイル内で定義でき、<address-provider>
要素を使用して参照できます。後者の方法は、アドレス構成をリモート・キャッシュ定義から分離し、リモート・キャッシュ定義を変更することなくランタイムでのアドレスの変更を可能にします。アドレス定義の参照の詳細は、「TCPアドレス用のアドレス・プロバイダ参照の使用」を参照してください。
例4-3 明示的なアドレスによるリモート・キャッシュ定義
... <caching-scheme-mapping> <cache-mapping> che-name>dist-extend</cache-name> <scheme-name>extend-dist</scheme-name> </cache-mapping> </caching-scheme-mapping> <caching-schemes> <remote-cache-scheme> <scheme-name>extend-dist</scheme-name> <service-name>ExtendTcpCacheService</service-name> <initiator-config> <tcp-initiator> <remote-addresses> <socket-address> <address>198.168.1.5</address> <port>7077</port> </socket-address> </remote-addresses> </tcp-initiator> <outgoing-message-handler> <request-timeout>5s</request-timeout> </outgoing-message-handler> </initiator-config> </remote-cache-scheme> </caching-schemes> ...
複数のプロキシ・サービス・インスタンスが構成されている場合、リモート・キャッシュ・スキームまたは起動スキームには、クライアントがいつでも必ずクラスタに接続できるように、各プロキシ・サービスのアドレスを含めることができます。接続の調整に使用されているアルゴリズムは、構成されているロード・バランシングの戦略によって変わります。ロード・バランシングの詳細は、「ロード・バランシング接続」を参照してください。
複数のアドレスを構成するには、必要に応じて、<remote-cache-scheme>
ノードおよび<remote-invocation-scheme>
ノードの<tcp-initiator>
要素内に、子要素<socket-address>
を追加します。次の例では、リモート・キャッシュ・スキームの拡張プロキシ・アドレスを2つ定義します。
... <caching-schemes> <remote-cache-scheme> <scheme-name>extend-dist</scheme-name> <service-name>ExtendTcpCacheService</service-name> <initiator-config> <tcp-initiator> <remote-addresses> <socket-address> <address>192.168.1.5</address> <port>7077</port> </socket-address> <socket-address> <address>192.168.1.6</address> <port>7077</port> </socket-address> </remote-addresses> </tcp-initiator> </initiator-config> </remote-cache-scheme> </caching-schemes> ...
IPアドレスまたはDNS名のいずれかを使用できる場合、DNS名には、DNS名に関連付けられているIPアドレスが実行時に自動的に解決されるというメリットもあります。これにより、プロキシ・アドレスのリストをDNSサーバーに格納し、集中管理とリアルタイムの更新が可能になります。たとえば、プロキシ・アドレス・リストが192.168.1.1
、192.168.1.2
および192.168.1.3
になる場合、これらのアドレスをホスト名ExtendTcpCacheService
の単一のDNSエントリに含め、ExtendTcpCacheService
という名前の単一のアドレスをプロキシ・アドレスに指定できます。
<tcp-initiator> <remote-addresses> <socket-address> <address>ExtendTcpCacheService</address> <port>7077</port> </socket-address> </remote-addresses> </tcp-initiator>
Coherence*Extendサービスで(ネットワーク、ソフトウェアまたはハードウェア障害などに起因する)クライアントとクラスタ間の接続の切断が検出されると、Coherence*Extendクライアント・サービスの実装(CacheService
またはInvocationService
)により、登録されているすべてのMemberListeners
にMemberEvent.MEMBER_LEFT
イベントがディスパッチされ、サービスが停止します。アプリケーションがCacheFactory.shutdown()
をコールする場合は、サービスの実装により、MemberEvent.MEMBER_LEAVING
イベントと、続いてMemberEvent.MEMBER_LEFT
イベントがディスパッチされます。いずれの場合も、その後クライアント・アプリケーションでサービスを使用しようとすると、サービスが自動的に再起動され、クラスタとの再接続が試行されます。このサービスが接続に成功するとMemberEvent.MEMBER_JOINED
イベントがディスパッチされ、接続に失敗するとクライアント・アプリケーションに修復できないエラーの例外がスローされます。
Coherence*Extendサービスには、接続の切断を検出するためのメカニズムがいくつか用意されています。その中には、(Extend-TCPのTCP/IPのように)基底プロトコルに固有のものもあれば、サービス自体に実装されるものもあります。後者のメカニズムは、<outgoing-message-handler
要素を使用して構成されます。この要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。特に、<request-timeout
値は、リクエストを中止するまでの応答を待機する時間を制御します。<heartbeat-interval
および<heartbeat-timeout
値は、接続を閉じるまでのpingリクエストへの応答を待機する時間を制御します。
次の例は、例4-1 から抜粋したもので、リクエスト・タイムアウトを5
秒に設定する場合を示しています。
... <initiator-config> ... <outgoing-message-handler> <request-timeout>5s</request-timeout> </outgoing-message-handler> </initiator-config> ...
次の例では、ハートビート間隔を500
ミリ秒に、ハートビート・タイムアウトを10
秒に設定します。
... <initiator-config> ... <outgoing-message-handler> <heartbeat-interval>500ms</heartbeat-interval> <heartbeat-timeout>10s</heartbeat-timeout> </outgoing-message-handler> </initiator-config> ...
ネットワーク内に配置されたJavaベースのExtendクライアントでは、拡張プロキシを使用して排他的にクラスタ化サービスに接続するために、TCMP通信を無効にする必要があります。TCMPが無効でない場合、JavaベースのExtendクライアントが互いにクラスタ化される可能性があり、既存のクラスタに追加される可能性もあります。TCMPはクラスタ側のtangosol-coherence-override.xml
ファイルで無効にします。
TCMP通信を無効にするには、<packet-publisher>
内の<enabled>
要素をfalse
に設定します。次に例を示します。
... <cluster-config> <packet-publisher> <enabled system-property="coherence.tcmp.enabled">false </enabled> </packet-publisher> </cluster-config> ...
オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.tcmp.enabled
システム・プロパティを使用して、TCMPを有効にするかどうかを指定します。次に例を示します。
-Dcoherence.tcmp.enabled=false