4 Extendクライアントの構成

Coherence*Extendクライアントは、クラスタ上のプロキシ・サービスに接続し、Coherenceキャッシュにアクセスするように構成されています。この手順は、基本設定を行うためのものであり、完全な構成方法を示すものではありません。また、追加の構成手順については、このガイドのプラットフォーム固有の項を参照してください。

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

Extendクライアントの構成の概要

Coherence*Extendでは、クライアント側とクラスタ側の両方の構成が必要です。クライアント側では、リモート・キャッシュ・サービスおよびリモート起動サービスを構成し、それを使用して拡張プロキシ・サービス経由でクラスタにアクセスします。クラスタ側では、クライアント・リクエストを受け入れるために拡張プロキシ・サービスが設定されます。Extendクライアントと拡張プロキシ・サービスの間の通信にはTCP/IPが使用されます。

Extendクライアントは、キャッシュ構成デプロイメント・ディスクリプタを使用して構成されます。このデプロイメント・ディスクリプタは、クライアントでデプロイされ、多くの場合、クライアント側のキャッシュ構成ファイルと呼ばれます。拡張プロキシ・サービスは、キャッシュ構成デプロイメント・ディスクリプタで構成されます。このデプロイメント・ディスクリプタは、多くの場合、クラスタ側のキャッシュ構成ファイルと呼ばれます。これは、クラスタでキャッシュを設定する際に使用するキャッシュ構成ファイルと同じです。Oracle Coherenceでのアプリケーションの開発キャッシュ構成ファイルの指定を参照してください。

Extendクライアントは、リモート・キャッシュ・サービスおよびリモート起動サービスを使用して、Coherenceクラスタと相互作用します。リモート・キャッシュ・サービスとリモート起動サービスはいずれも、Extendクライアント・アプリケーションが起動するときにクラスパス上で検出されるキャッシュ構成デプロイメント・ディスクリプタで構成されます。

リモート・キャッシュの定義

リモート・キャッシュは、キャッシュ操作をCoherenceクラスタ上のキャッシュにルーティングする、専用のキャッシュ・サービスです。リモート・キャッシュとクラスタ上のキャッシュは、同じキャッシュ名である必要があります。Extendクライアントでは、NamedCacheインタフェースを通常どおりに使用して、キャッシュのインスタンスを取得します。実行時、キャッシュ操作は、ローカルでは実行されず、TCP/IPを使用してクラスタ上の拡張プロキシ・サービスに送信されます。キャッシュ操作をクラスタ上のキャッシュに委任する処理は、Extendクライアントに対して透過的に行われます。

リモート・キャッシュは、<caching-schemes>ノード内で、<remote-cache-scheme>要素を使用して定義されます。例4-1では、ExtendTcpCacheServiceという名前のリモート・キャッシュ・スキームを作成してネーム・サービスに接続し、このネーム・サービスが、リクエストされたプロキシ・サービスのアドレスにリクエストをリダイレクトします。ネーム・サービスを使用すると、ポート管理とファイアウォール構成が簡素化します。『Oracle Coherenceでのアプリケーションの開発』remote-cache-schemeに関する項を参照してください。

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

クライアントがプロキシ・サーバーとは異なるクラスタにある場合は、<cluster-name>要素を使用してプロキシ・サーバーのクラスタ名を指定します。たとえば:

<remote-cache-scheme>
      <scheme-name>extend-dist</scheme-name>
      <service-name>ExtendTcpCacheService</service-name>
      <cluster-name
system-property="cache.server.cluster">CacheCluster</cluster-name>
      ...

例4-1に構成されているように、リモート・キャッシュ・スキームは<name-service-addresses>要素を使用して、クラスタ上のネーム・サービスのソケット・アドレス(IPまたはDNS名、およびポート)を定義します。<address>要素は、ローカル・アドレスにルーティングする外部NATアドレスもサポートしますが、両方のアドレスで同じポート番号を使用する必要があります。ネーム・サービスは、デフォルトでクラスタ・ポート(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>要素を使用して、ネーム・サービスがリスニングするアドレスを構成します。『Oracle Coherenceでのアプリケーションの開発』remote-invocation-schemeに関する項を参照してください。

例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>要素は、ローカル・アドレスにルーティングする外部NATアドレスもサポートしますが、両方のアドレスで同じポート番号を使用する必要があります。アドレスは、オペレーション構成オーバーライド・ファイル内で定義でき、<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.1192.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サービスで(ネットワーク、ソフトウェアまたはハードウェア障害などに起因する)クライアントとクラスタ間の接続の切断が検出されると、Coherence*Extendクライアント・サービスの実装(CacheServiceまたはInvocationService)により、登録されているすべてのMemberListenersMemberEvent.MEMBER_LEFTイベントがディスパッチされ、サービスが停止します。アプリケーションがCacheFactory.shutdown()をコールする場合は、サービスの実装により、MemberEvent.MEMBER_LEAVINGイベントと、続いてMemberEvent.MEMBER_LEFTイベントがディスパッチされます。いずれの場合も、その後クライアント・アプリケーションでサービスを使用しようとすると、サービスが自動的に再起動され、クラスタとの再接続が試行されます。このサービスが接続に成功するとMemberEvent.MEMBER_JOINEDイベントがディスパッチされ、接続に失敗するとクライアント・アプリケーションに修復できないエラーの例外がスローされます。

Coherence*Extendサービスには、接続の切断を検出するためのメカニズムがいくつか用意されています。その中には、(Extend-TCPのTCP/IPのように)基底プロトコルに固有のものもあれば、サービス自体に実装されるものもあります。後者のメカニズムは、<outgoing-message-handler>要素を使用して構成されます。『Oracle Coherenceでのアプリケーションの開発』outgoing-message-handlerに関する項を参照してください。特に、<request-timeout>値は、リクエストを中止するまでの応答を待機する時間を制御します。<heartbeat-interval>および<heartbeat-timeout>値は、接続を閉じるまでのpingリクエストへの応答を待機する時間を制御します。ベスト・プラクティスとして、ハートビート・タイムアウトはハートビート間隔未満にして、他のメンバーが不必要にpingを受信して、複数のpingが未処理の状態にならないようにしてください。

次の例は、例4-1から抜粋したもので、リクエスト・タイムアウトを5秒に設定する場合を示しています。

...
<initiator-config>
   ...
   <outgoing-message-handler>
      <request-timeout>5s</request-timeout>
   </outgoing-message-handler>
</initiator-config>
...

次の例では、ハートビート間隔を3ミリ秒に、ハートビート・タイムアウトを2秒に設定します。

...
<initiator-config>
   ...
   <outgoing-message-handler>
      <heartbeat-interval>3s</heartbeat-interval>
      <heartbeat-timeout>2s</heartbeat-timeout>
   </outgoing-message-handler>
</initiator-config>
...

TCMP通信の無効化

ネットワーク内に配置された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