ヘッダーをスキップ
Oracle Coherence開発者ガイド
リリース3.5
B56039-01
  目次
目次

戻る
戻る
 
次へ
次へ
 

17 Coherence*Extendの構成と使用

Coherence*Extendは、コアとなるCoherence TCMPクラスタの作用範囲を、デスクトップ、リモート・サーバー、WANに接続されたマシンなどのより広範な顧客環境に拡張します。Coherence*Extendの一般的な用途は、Coherenceキャッシュ(ニア・キャッシュや連続問合せのサポートを含む)にアクセスできるデスクトップ・アプリケーションを提供したり、待機時間の長い不安定なWANを介して接続された複数のCoherenceクラスタをリンクするCoherenceクラスタのブリッジを提供したりすることです。

Coherence*Extendは、1つのクライアントと、1つ以上のDefaultCacheServerプロセスでホストされるCoherence*Extendクラスタ・サービスとの2つの基本コンポーネントで構成されます。アダプタ・ライブラリには、CacheServiceインタフェースとInvocationServiceインタフェースの両方の実装が含まれており、これらによって、すべてのリクエストはCoherenceクラスタ内で実行されるCoherence*Extendクラスタ・サービス・インスタンスにルーティングされます。Coherence*Extendクラスタ・サービスはその後、実際のCoherenceクラスタ・サービス(パーティション・キャッシュ・サービスやレプリケーション・キャッシュ・サービスなど)に委任することによってクライアント・リクエストに応答します。クライアント・アダプタ・ライブラリとCoherence*Extendクラスタ・サービスは、低レベルのメッセージ・プロトコルを使用して相互に通信します。Coherence*Extendには、高性能でスケーラブルなTCP/IPベースの通信レイヤーを使用してクラスタに接続する、このプロトコル用のExtend-TCP転送バインディングが含まれています。


注意:

Coherence*Extend-JMSのサポートは非推奨になりました。

転送バインディングの選択は、構成により、Coherence*Extendを使用するクライアント・アプリケーションに対して完全に透過的に行われます。Coherenceクラスタ・サービスと同様に、Coherence*ExtendサービスはCacheFactoryクラスを使用して取得します。Coherence*Extendサービスを取得したクライアントは、サービスをCoherenceクラスタ・ノードと同様の方法で使用します。リモート・クラスタ・ノードに送信される操作は、クライアント・アプリケーションに対して透過的になります。

一般的な手順

Coherence*Extendの構成および使用には、次の4つの基本的な手順が必要です。

  1. クライアント側のCoherenceキャッシュ・コンフィギュレーション・ディスクリプタを作成して、1つ以上の<remote-cache-scheme>および<remote-invocation-scheme>構成要素を含めます。

  2. クラスタ側のCoherenceキャッシュ・コンフィギュレーション・ディスクリプタを作成して、1つ以上の<proxy-scheme>構成要素を含めます。

  3. 1つ以上のDefaultCacheServerプロセスを起動します。

  4. 1つ以上のCoherence*Extendサービスを使用するクライアント・アプリケーションを作成します。詳細は、「Coherence*Extendクライアント・アプリケーションのサンプル」を参照してください。

  5. クライアント・アプリケーションを起動します。

Coherence*Extend-TCPの構成と使用

クライアント側のキャッシュ・コンフィギュレーション・ディスクリプタ

Extend-TCP転送バインディングを使用するCoherence*Extendクライアントは、Coherenceキャッシュ・コンフィギュレーション・ディスクリプタを定義して、TCP/IP固有の様々な構成情報を指定した<tcp-initiator>子要素を持つ<remote-cache-scheme>および<remote-invocation-scheme>要素を含める必要があります。例17-1にディスクリプタのサンプルを示します。

例17-1 Extend-TCPを使用するCoherence*Extendクライアント・ディスクリプタ

<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">

<cache-config>
  <caching-scheme-mapping>
    <cache-mapping>
      <cache-name>dist-extend</cache-name>
      <scheme-name>extend-dist</scheme-name>
    </cache-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>
          <remote-addresses>
            <socket-address>
              <address>localhost</address>
              <port>9099</port>
            </socket-address>
          </remote-addresses>
          <connect-timeout>10s</connect-timeout>
        </tcp-initiator>
        <outgoing-message-handler>
          <request-timeout>5s</request-timeout>
        </outgoing-message-handler>
      </initiator-config>
    </remote-cache-scheme>

    <remote-invocation-scheme>
      <scheme-name>extend-invocation</scheme-name>
      <service-name>ExtendTcpInvocationService</service-name>
      <initiator-config>
        <tcp-initiator>
          <remote-addresses>
            <socket-address>
              <address>localhost</address>
              <port>9099</port>
            </socket-address>
          </remote-addresses>
          <connect-timeout>10s</connect-timeout>
        </tcp-initiator>
        <outgoing-message-handler>
          <request-timeout>5s</request-timeout>
        </outgoing-message-handler>
      </initiator-config>
    </remote-invocation-scheme>
  </caching-schemes>
</cache-config>

このキャッシュ・コンフィギュレーション・ディスクリプタでは、2つのキャッシング・スキームを定義しています。1つはExtend-TCPを使用してリモートCoherenceクラスタに接続し(<remote-cache-scheme>)、もう1つはリモートCoherenceキャッシュのサイズ制限のあるインプロセス・ニア・キャッシュを保持します(このアクセスにもExtend-TCPを使用します)。さらにこのキャッシュ・コンフィギュレーション・ディスクリプタでは、クライアント・アプリケーションによるリモートCoherenceクラスタ内のタスク実行を可能にする<remote-invocation-scheme>を定義します。<remote-cache-scheme>および<remote-invocation-scheme>の両要素は<tcp-initiator>子要素を持ちます。これには、クライアントから、リモートCoherenceクラスタ内で実行されているCoherence*Extendクラスタ・サービスに接続するために必要なTCP/IP固有の情報がすべて含まれます。

クライアント・アプリケーションでCacheFactory(たとえば名前dist-extend)を使用してNamedCacheを取得する場合、Coherence*Extendアダプタ・ライブラリはTCP/IP(アドレスlocalhostおよびport 9099を使用)を使用してCoherenceクラスタに接続し、リモート・クラスタ内で実行されている同じ名前のNamedCacheにリクエストをルーティングするNamedCacheの実装を返します。同様に、クライアント・アプリケーションでCacheFactory.getConfigurableCacheFactory().ensureService("ExtendTcpInvocationService")をコールしてInvocationServiceを取得する場合、Coherence*Extendアダプタ・ライブラリは同じTCP/IP(再度、アドレスlocalhostおよびport 9099を使用)を使用してCoherenceクラスタに接続し、クライアントが接続されているリモート・クラスタJVM内で同期的に起動可能なタスクを実行するInvocationServiceの実装を返します。

<remote-addresses>構成要素(<tcp-initiator>を参照)には複数の<socket-address>子要素を含めることができます。Coherence*Extendアダプタ・ライブラリは、そのリストを使い果たすかTCP/IP接続が確立されるまで、ランダムな順序でアドレスへの接続を試行します。

クラスタ側のキャッシュ(Coherence拡張プロキシ)コンフィギュレーション・ディスクリプタ

Coherenceクラスタに接続するCoherence*Extend-TCPクライアントでは、Coherenceキャッシュ・コンフィギュレーション・ディスクリプタを使用する1つ以上のDefaultCacheServerプロセスを実行する必要があります。このディスクリプタには、TCP/IP固有の様々な構成情報を指定した<tcp-acceptor>子要素を持つ<proxy-scheme>要素を含める必要があります。例17-2にディスクリプタのサンプルを示します。

例17-2 Extend-TCPを使用するクラスタ側のキャッシュ・コンフィギュレーション・ディスクリプタ

<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">

<cache-config>
  <caching-scheme-mapping>
    <cache-mapping>
      <cache-name>dist-*</cache-name>
      <scheme-name>dist-default</scheme-name>
    </cache-mapping>
  </caching-scheme-mapping>

  <caching-schemes>
    <distributed-scheme>
      <scheme-name>dist-default</scheme-name>
      <lease-granularity>member</lease-granularity>
      <backing-map-scheme>
        <local-scheme/>
      </backing-map-scheme>
      <autostart>true</autostart>
    </distributed-scheme>

    <proxy-scheme>
      <service-name>ExtendTcpProxyService</service-name>
      <thread-count>5</thread-count>
      <acceptor-config>
        <tcp-acceptor>
          <local-address>
            <address>localhost</address>
            <port>9099</port>
          </local-address>
        </tcp-acceptor>
      </acceptor-config>
      <autostart>true</autostart>
    </proxy-scheme>
  </caching-schemes>
</cache-config>

このキャッシュ・コンフィギュレーション・ディスクリプタでは、2つのクラスタ・サービスを定義しています。1つはExtend-TCPを使用してリモートExtend-TCPクライアントをCoherenceクラスタに接続するサービス、もう1つは標準のパーティション・キャッシュ・サービスです。このディスクリプタはDefaultCacheServerで使用されるため、各サービスの<autostart>構成要素をtrueに設定して、異常終了時にはクラスタ・サービスが自動的に再起動されるようにすることが重要です。<proxy-scheme>要素には、TCP/IPを介したクライアント接続リクエストの受入れに必要な、すべてのTCP/IP固有情報を含む<tcp-acceptor>子要素があります。

Coherence*Extendクラスタ・サービスは、接続リクエストのTCP/IP ServerSocket(アドレスlocalhostおよびport 9099にバインドされている)をリスニングします。たとえば、クライアントがdist-extend-directというCoherence NamedCacheに接続しようとすると、Coherence*Extendクラスタ・サービスがプロキシとなって、後続のリクエストを同じ名前のNamedCache(この場合はパーティション・キャッシュ)に送信します。

Extend-TCP DefaultCacheServerプロセスの起動

前述したクラスタ側のCoherenceキャッシュ・コンフィギュレーションを使用するDefaultCacheServerを起動し、TCP/IPを使用してExtend-TCPクライアントをCoherenceクラスタに接続するには、次を実行する必要があります。

  • 現在のディレクトリをCoherenceのライブラリ・ディレクトリに変更します(Windowsの場合は%COHERENCE_HOME%\lib、UNIXの場合は$COHERENCE_HOME/lib)。

  • Javaコマンドが実行されるようにパスを構成します。

  • 前述のクラスタ側のCoherenceキャッシュ・コンフィギュレーション・ディスクリプタの場所に設定した-Dtangosol.coherence.cacheconfigシステム・プロパティを指定して、DefaultCacheServerコマンドライン・アプリケーションを起動します。

たとえば次のように起動します(ここでは形式上複数行に分けて表示してありますが、実際は単一のコマンドとして1行に入力します)。

java -cp coherence.jar:<classpath to client application>
     -Dtangosol.coherence.cacheconfig=file://<path to the server-side cache configuration descriptor>
     com.tangosol.net.DefaultCacheServer

Extend-TCPクライアント・アプリケーションの起動

Extend-TCPを使用し、TCP/IPを介してリモートCoherenceクラスタに接続するクライアント・アプリケーションを起動するには、次を実行する必要があります。

  • 現在のディレクトリをCoherenceのライブラリ・ディレクトリに変更します(Windowsの場合は%COHERENCE_HOME%\lib、UNIXの場合は$COHERENCE_HOME/lib)。

  • Javaコマンドが実行されるようにパスを構成します。

  • 前述のクライアント側のCoherenceキャッシュ・コンフィギュレーション・ディスクリプタの場所に設定した-Dtangosol.coherence.cacheconfigシステム・プロパティを指定して、クライアント・アプリケーションを起動します。

たとえば次のように起動します(例17-3のコマンドは形式上複数行に分けて表示してありますが、実際は単一のコマンドとして1行に入力します)。

例17-3 Extend-TCPを使用してクライアント・アプリケーションを起動するコマンド

java -cp coherence.jar:<classpath to client application>
     -Dtangosol.coherence.cacheconfig=file://<path to the client-side cache configuration descriptor>
     <client application Class name>

Coherence*Extendクライアント・アプリケーションのサンプル

例17-4は、Coherence*ExtendのCacheServiceおよびInvocationServiceを取得して使用する方法を示しています。この例では、リモート・パーティション・キャッシュのInteger値を増分した後、クライアントが接続されているクラスタ化されたJVMでInvocableを実行することによってその値を取得しています。

例17-4 Coherence*Extendアプリケーションのサンプル

public static void main(String[] asArg)
        throws Throwable
    {
    NamedCache cache  = CacheFactory.getCache("dist-extend");
    Integer    IValue = (Integer) cache.get("key");
    if (IValue == null)
        {
        IValue = new Integer(1);
        }
    else
        {
        IValue = new Integer(IValue.intValue() + 1);
        }
    cache.put("key", IValue);

    InvocationService service = (InvocationService)
            CacheFactory.getConfigurableCacheFactory()
                .ensureService("ExtendTcpInvocationService");

    Map map = service.query(new AbstractInvocable()
            {
            public void run()
                {
                setResult(CacheFactory.getCache("dist-extend").get("key"));
                }
            }, null);

    Integer IValue = (Integer) map.get(service.getCluster().getLocalMember());
    }

この例は、Coherenceノード(つまりクラスタ内)でもそのまま実行できます。TCPを介してリモート・クラスタ・ノードに送信される操作は、クライアント・アプリケーションに対して完全に透過的になります。

Coherence*Extend InvocationService

当然、Coherence*Extendクライアントはクラスタやクラスタ内で実行されているメンバーを直接認識しないため、Coherence*Extend InvocationServiceInvocableタスクを実行できるのは、クライアントが接続されているJVMに対してのみです。したがって、必ずnullメンバーをquery()メソッドに設定して渡す必要があります。その結果、実行による単一の結果がローカルのMemberを使用してキー設定されます(クライアントがクラスタの一部でない場合はnullに設定されます)。このMemberは、service.getCluster().getLocalMember()をコールすることで取得できます。またCoherence*Extend InvocationServiceは、同期タスクの実行のみをサポートします(つまりexecute()メソッドはサポートされません)。

高度な構成

ネットワーク・フィルタ

Coherenceクラスタ・サービス同様、Coherence*Extendサービスはプラッガブルなネットワーク・フィルタをサポートします。フィルタを使用すると、送信前のネットワーク・トラフィックのコンテンツを変更できます。圧縮および対称暗号化フィルタを含む、ほとんどの標準的なCoherenceネットワーク・フィルタがサポートされます。このフィルタ構成の詳細は、第8章「ネットワーク・フィルタ」を参照してください。

Coherence*Extendでネットワーク・フィルタを使用するには、<use-filters>要素を、クライアント側のキャッシュ・コンフィギュレーション・ディスクリプタの<initiator-config>要素とクラスタ側のキャッシュ・コンフィギュレーション・ディスクリプタの<acceptor-config>要素に追加する必要があります。

たとえば、Coherence*Extendクライアントとクライアントが接続されるクラスタ・サービスとの間でやりとりされるネットワーク・トラフィックを暗号化するには、例17-5(対称暗号化フィルタの名前がsymmetric-encryptionであると仮定)に示すように、クライアント側の<remote-cache-scheme>および<remote-invocation-scheme>要素を構成します。

例17-5 暗号化ネットワーク・トラフィックに対するクライアント側の構成

<remote-cache-scheme>
  <scheme-name>extend-dist</scheme-name>
  <service-name>ExtendTcpCacheService</service-name>
  <initiator-config>
    <tcp-initiator>
      <remote-addresses>
        <socket-address>
          <address>localhost</address>
          <port>9099</port>
        </socket-address>
      </remote-addresses>
      <connect-timeout>10s</connect-timeout>
    </tcp-initiator>
    <outgoing-message-handler>
      <request-timeout>5s</request-timeout>
    </outgoing-message-handler>
    <use-filters>
      <filter-name>symmetric-encryption</filter-name>
    </use-filters>
  </initiator-config>
</remote-cache-scheme>

<remote-invocation-scheme>
  <scheme-name>extend-invocation</scheme-name>
  <service-name>ExtendTcpInvocationService</service-name>
  <initiator-config>
    <tcp-initiator>
      <remote-addresses>
        <socket-address>
          <address>localhost</address>
          <port>9099</port>
        </socket-address>
      </remote-addresses>
      <connect-timeout>10s</connect-timeout>
    </tcp-initiator>
    <outgoing-message-handler>
      <request-timeout>5s</request-timeout>
    </outgoing-message-handler>
    <use-filters>
      <filter-name>symmetric-encryption</filter-name>
    </use-filters>
  </initiator-config>
</remote-invocation-scheme>

例17-6は、クラスタ側の<proxy-scheme>要素の構成を示しています。

例17-6 クラスタ側のプロキシ・スキーム構成

<proxy-scheme>
  <service-name>ExtendTcpProxyService</service-name>
  <thread-count>5</thread-count>
  <acceptor-config>
    <tcp-acceptor>
      <local-address>
        <address>localhost</address>
        <port>9099</port>
      </local-address>
    </tcp-acceptor>
    <use-filters>
      <filter-name>symmetric-encryption</filter-name>
    </use-filters>
  </acceptor-config>
  <autostart>true</autostart>
</proxy-scheme>

注意:

<use-filters>要素の内容は、クライアント側およびクラスタ側のキャッシュ・コンフィギュレーション・ディスクリプタで同じにする必要があります。

接続エラーの検出とフェイルオーバー

Coherence*Extendサービスで(ネットワーク、ソフトウェアまたはハードウェア障害などに起因する)クライアントとクラスタの接続の切断が検出されると、Coherence*Extendクライアント・サービスの実装(CacheServiceまたはInvocationService)により、登録されているすべてのMemberListenersMemberEvent.MEMBER_LEFTイベントがディスパッチされ、サービスが停止します。その後クライアント・アプリケーションでサービスを使用しようとすると、サービスが自動的に再起動され、クラスタとの再接続が試行されます。接続が確立されると、サービスはMemberEvent.MEMBER_JOINEDイベントをディスパッチします。接続に失敗した場合は、致命的な例外がクライアント・アプリケーションにスローされます。

Coherence*Extendサービスには、接続の切断を検出するメカニズムがいくつか用意されています。その中には、基礎となるTCP/IPプロトコルを継承するものや、サービス自体によって実装されるものがあります。後者のメカニズムは、<outgoing-message-handler>構成要素を使用して構成します。

Coherence*Extendクライアント・サービスで接続の切断を検出するために使用される構成可能な主要メカニズムは、リクエスト・タイムアウトです。サービスでリクエストをリモート・クラスタに送信し、リクエスト・タイムアウト時間内にレスポンスを受信しなかった場合(<outgoing-message-handler>のサブ要素<request-timeout>を参照)、サービスはその接続が切断されたと見なします。接続に対して周期的なハートビートを送信するよう、Coherence*Extendクライアントおよびクラスタ・サービスを構成することもできます(<outgoing-message-handler>のサブ要素<heartbeat-interval>および<heartbeat-timeout>を参照)。構成されたハートビート・タイムアウト時間内にサービスがレスポンスを受信しなかった場合、サービスはその接続が切断されたと見なします。


警告:

<request-timeout/>を指定しない場合、Coherence*Extendサービスでは無限のリクエスト・タイムアウトが使用されます。一般にアプリケーションが応答しなくなる可能性があるため、この構成は推奨されません。ほとんどの場合は、適切な有限のリクエスト・タイムアウトを指定します。


NamedCache読取り専用アクセス

Coherence*Extendクラスタ・サービスはデフォルトで、プロキシ設定されたNamedCacheインスタンスに対する読取りおよび書込みの両アクセスを許可します。キャッシュされたコンテンツの変更をCoherence*Extendクライアントに対して禁止するには、<cache-service-proxy>子構成要素を使用します。例17-7に構成のサンプルを示します。

例17-7 キャッシュに対する読取り専用アクセスを許可するクライアント側の構成

<proxy-scheme>
  ...

  <proxy-config>
    <cache-service-proxy>
      <read-only>true</read-only>
    </cache-service-proxy>
  </proxy-config>

  <autostart>true</autostart>
</proxy-scheme>

クライアント側のNamedCacheロック

Coherence*Extendクラスタ・サービスはデフォルトで、Coherence*ExtendクライアントによるNamedCacheロックの取得を許可しません。クライアント側のロックを有効にするには、<cache-service-proxy>子構成要素を使用します。次に例を示します。

例17-8 NamedCacheロックを許可するクライアントの構成

<proxy-scheme>
  ...

  <proxy-config>
    <cache-service-proxy>
      <lock-enabled>true</lock-enabled>
    </cache-service-proxy>
  </proxy-config>

  <autostart>true</autostart>
</proxy-scheme>

クライアント側のロックを有効にしてクライアント・アプリケーションでNamedCache.lock()およびunlock()メソッドを使用する場合は、クラスタ側のCoherenceキャッシュ・コンフィギュレーション・ディスクリプタで定義された任意のパーティションまたはレプリケーション・キャッシュ・サービスに対して(スレッドベースではなく)メンバーベースのロック方針を指定することが重要です。Coherence*Extendクラスタ・サービスではクライアント・リクエストを同時実行するスレッド・プールが使用されるため、同じCoherence*Extendクライアントからの後続のリクエストが同じスレッドで実行される保証はありません。

パーティションまたはレプリケーション・キャッシュ・サービスに対してメンバーベースのロック方針を指定するには、<lease-granularity>構成要素を使用します。例17-9に構成のサンプルを示します。

例17-9 パーティションまたはレプリケーション・キャッシュに対してロックを許可するクライアントの構成

<distributed-scheme>
  <scheme-name>dist-default</scheme-name>
  <lease-granularity>member</lease-granularity>
  <backing-map-scheme>
    <local-scheme/>
  </backing-map-scheme>
  <autostart>true</autostart>
</distributed-scheme>

プロキシ設定されたサービスの無効化

Coherence*Extendクラスタ・サービスはデフォルトで、CacheServiceプロキシおよびInvocationServiceプロキシという2つのプロキシ・サービスをクライアントに公開します。ときによっては、一方のプロキシを無効化することが望ましい場合があります。プロキシを無効化するには、それぞれの対応するプロキシ・コンフィギュレーション・セクションの<enabled>構成要素を使用します。たとえば、InvocationServiceプロキシを無効化してリモート・クライアントからクラスタ内のInvocableオブジェクトを実行できないようにするには、Coherence*Extendクラスタ・サービスを例17-10に示すように構成します。

例17-10 プロキシ・サービスを無効化するクライアントの構成

<proxy-scheme>
  ...

  <proxy-config>
    <invocation-service-proxy>
      <enabled>false</enabled>
    </invocation-service-proxy>
  </proxy-config>

  <autostart>true</autostart>
</proxy-scheme>

同様に、リモート・クライアントからクラスタ内のキャッシュにアクセスできないようにするには、例17-11のような構成を使用します。

例17-11 キャッシュへのアクセスを許可しないクライアントの構成

<proxy-scheme>
  ...

  <proxy-config>
    <cache-service-proxy>
      <enabled>false</enabled>
    </cache-service-proxy>
  </proxy-config>

  <autostart>true</autostart>
</proxy-scheme>