| Oracle® Fusion Middleware Oracle Coherenceリモート・クライアントの開発 12c (12.1.3) E56210-03 |
|
 前 |
 次 |
この章では、Coherence*Extendを構成する手順について説明します。この手順は、基本設定を行うためのものであり、完全な構成方法を示すものではありません。また、追加の構成手順については、このガイドのプラットフォーム固有の項を参照してください。
構成および設定も含むJavaの完全な例については、第3章「最初のExtendクライアントの構築」を参照してください。
この章には次の項が含まれます:
Coherence*Extendでは、クライアント側とクラスタ側の両方の構成が必要です。クラスタ側では、クライアント・リクエストを受け入れるために拡張プロキシ・サービスが設定されます。プロキシ・サービスを使用することにより、クラスタ上で実行されるキャッシュ・サービス・インスタンスおよび起動サービス・インスタンスにアクセスできます。クライアント側では、リモート・キャッシュ・サービスおよびリモート起動サービスを構成し、それを使用して拡張プロキシ・サービス経由でクラスタにアクセスします。Extendクライアントと拡張プロキシ・サービスの間の通信にはTCP/IPが使用されます。
拡張プロキシ・サービスは、キャッシュ構成デプロイメント・ディスクリプタで構成されます。このデプロイメント・ディスクリプタは、多くの場合、クラスタ側のキャッシュ構成ファイルと呼ばれます。これは、クラスタでキャッシュを設定する際に使用するキャッシュ構成ファイルと同じです。Extendクライアントも、キャッシュ構成デプロイメント・ディスクリプタを使用して構成されます。このデプロイメント・ディスクリプタは、クライアントでデプロイされ、多くの場合、クライアント側のキャッシュ構成ファイルと呼ばれます。キャッシュ構成デプロイメント・ディスクリプタの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
Coherenceクラスタには、Extendクライアントの接続を受け入れるための拡張プロキシ・サービスと、クライアントでデータを取得して格納する際に使用するキャッシュが組み込まれている必要があります。拡張プロキシ・サービスもキャッシュも、クラスタのキャッシュ構成デプロイメント・ディスクリプタで構成されます。拡張プロキシ・サービスおよびキャッシュは、キャッシュ・サーバー(DefaultCacheServer)のプロセスの一環として開始されます。
この項は、次のトピックで構成されています。
拡張プロキシ・サービス(ProxyService)は、ExtendクライアントからTCP/IPを使用してCoherenceクラスタにアクセスできるクラスタ・サービスです。プロキシ・サービスには、CacheServiceクラスタ・サービス(クライアントからキャッシュへのアクセスに使用)、およびInvocationServiceクラスタ・サービス(クライアントがクラスタ上でInvocableオブジェクトを実行する際に使用)の2種類のクラスタ・サービス用のプロキシが組み込まれています。
この項には、次のトピックが含まれます:
拡張プロキシ・サービスは、<caching-schemes>ノード内で、<proxy-scheme>要素を使用して構成します。子要素の<tcp-acceptor>には、TCP/IPクライアント通信のために拡張プロキシ・サービスがリスニングするアドレス(IPまたはDNS名と、ポート)が含まれます。アドレスは、<local-address>要素を使用して明示的に定義するか、オペレーション構成オーバーライド・ファイル内で定義できます。さらに、<address-provider>要素を使用して参照できます。後者の方法は、アドレス構成をプロキシ・スキーム定義から分離し、プロキシ定義を変更することなくランタイムでのアドレスの変更を可能にします。アドレス定義の参照の詳細は、「TCPアドレス用のアドレス・プロバイダ参照の使用」を参照してください。
例4-1では、198.168.1.5およびポート9099にバインドされているTCP/IPソケットでクライアント・リクエストをリスニングするように設定されている、ExtendTcpProxyServiceという名前のプロキシ・サービスを定義します。キャッシュと起動の両方のクラスタ・サービス・プロキシが、クライアント・リクエストに対して有効になっています。さらに、クラスタ・ノードでサービスが自動的に開始されるように、<autostart要素がtrueに設定されています。<proxy-schemeのすべてのサブ要素の一覧と説明は、『Oracle Coherenceでのアプリケーションの開発』の<proxy-scheme要素参照を参照してください。
例4-1 拡張プロキシ・サービスの構成
...
<caching-schemes>
<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>192.168.1.5</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<proxy-config>
<cache-service-proxy>
<enabled>true</enabled>
</cache-service-proxy>
<invocation-service-proxy>
<enabled>true</enabled>
</invocation-service-proxy>
</proxy-config>
<autostart>true</autostart>
</proxy-scheme>
</caching-schemes>
...
|
注意:
|
予想されるクライアント接続数をサポートするため、およびフォルト・トレランスとロード・バランシングをサポートするために、複数の拡張プロキシ・サービス・インスタンスを定義できます。クライアント接続は、プロキシ・サービス・インスタンス間で自動的に調整されます。接続の調整に使用されているアルゴリズムは、構成されているロード・バランシングの戦略によって変わります。ロード・バランシングの詳細は、「ロード・バランシング接続」を参照してください。
複数のプロキシ・サービス・インスタンスを定義するには、単一のプロキシ・サービス定義を複数のキャッシュ・サーバーで読み込んで、各プロキシ・サービスに同じサービス名を使用します。同じサービス名のプロキシ・サービスはピアと見なすことができます。
次の例では、ExtendTcpProxyServiceプロキシ・サービスの2つのインスタンスを定義し、ポート9099にバインドされているTCP/IP ServerSocketでクライアント・リクエストをリスニングするように設定しています。プロキシ・サービス定義は、各キャッシュ・サーバーのそれぞれのキャッシュ設定ファイルで <proxy-scheme>要素内に含まれています。
キャッシュ・サーバー1:
...
<caching-schemes>
<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>192.168.1.5</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
</caching-schemes>
...
キャッシュ・サーバー2:
...
<caching-schemes>
<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>192.168.1.6</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
</caching-schemes>
...
複数の拡張プロキシ・サービスを定義することにより、それぞれのプロキシで異なるアプリケーションを提供できます。より予測性の高い環境を構築するために、特定のアプリケーションのExtendクライアントを特定のプロキシに誘導できます。
次の例では、2つの拡張プロキシ・サービスを定義します。ExtendTcpProxyService1は、198.168.1.5およびポート9099にバインドされているTCP/IP ServerSocketでクライアント・リクエストをリスニングするように設定します。ExtendTcpProxyService2は、198.168.1.5およびポート9098にバインドされているTCP/IP ServerSocketでクライアント・リクエストをリスニングするように設定します。
...
<caching-schemes>
<proxy-scheme>
<service-name>ExtendTcpProxyService1</service-name>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>192.168.1.5</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
<proxy-scheme>
<service-name>ExtendTcpProxyService2</service-name>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>192.168.1.5</address>
<port>9098</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
</caching-schemes>
...
キャッシュ・サービス・プロキシと起動サービス・プロキシは、拡張プロキシ・サービス定義内で無効化できます。これらのプロキシはいずれもデフォルトで有効になっており、クライアントにサービスが不要な場合は明示的に無効化できます。
クラスタ・サービス・プロキシは、それぞれ<cache-service-proxy>内および<invocation-service-proxy>内で<enabled>要素をfalseに設定することによって無効にします。
次の例では、Extendクライアントがクラスタ内でInvocableオブジェクトを実行できないように、起動サービス・プロキシを無効にします。
<proxy-scheme>
...
<proxy-config>
<invocation-service-proxy>
<enabled>false</enabled>
</invocation-service-proxy>
</proxy-config>
...
</proxy-scheme>
同様に、次の例では、Extendクライアントがクラスタ内のキャッシュへアクセスしないようにキャッシュ・サービス・プロキシを無効にします。
<proxy-scheme>
...
<proxy-config>
<cache-service-proxy>
<enabled>false</enabled>
</cache-service-proxy>
</proxy-config>
...
</proxy-scheme>
デフォルトでは、Extendクライアントは、プロキシ設定されたNamedCacheインスタンスに対するデータの読取りおよび書込みがいずれも許可されています。<cache-service-proxy>要素内で<read-only>要素を指定すると、Extendクライアントでは、クラスタ上でキャッシュされているコンテンツを変更できなくなります。例:
<proxy-scheme>
...
<proxy-config>
<cache-service-proxy>
<read-only>true</read-only>
</cache-service-proxy>
</proxy-config>
...
</proxy-scheme>
|
注意: NamedCacheロックAPIは非推奨です。入力プロセッサAPI (JavaおよびC++用のEntryProcessor、および.NET用のIEntryProcessor)で提供されるロック・サポートをかわりに使用してください。 |
デフォルトでは、ExtendクライアントはNamedCacheロックを取得できません。<cache-service-proxy>要素内で<lock-enabled>要素を指定すると、Extendクライアントでロックを実行できます。例:
<proxy-scheme>
...
<proxy-config>
<cache-service-proxy>
<lock-enabled>true</lock-enabled>
</cache-service-proxy>
</proxy-config>
...
</proxy-scheme>
クライアント側のロックを有効にして、クライアント・アプリケーションでNamedCache.lock()メソッドおよびunlock()メソッドを使用する場合は、パーティション化またはレプリケートされたキャッシュを使用するときに、(スレッドベースではなく)メンバーベースのロック戦略を構成することが重要です。ロック戦略は、クラスタ側のキャッシュを定義するときに、<lease-granularity>要素を使用して構成します。粒度の値がthread(デフォルト設定)の場合、ロックはそのロックを取得したスレッドによって保持され、そのスレッドによってのみ解放されます。粒度の値がmemberの場合、ロックはクラスタ・ノードによって保持され、ロックを取得したクラスタ・ノード上で実行される任意のスレッドによって解放できます。拡張プロキシ・クラスタ化サービスではクライアント・リクエストを同時実行するスレッド・プールが使用されるため、同じExtendクライアントからの後続のリクエストが同じスレッドで実行される保証はありません。
次の例では、パーティション化されたキャッシュに関してリース粒度をmemberに設定する場合を示します。
...
<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>
...
Extendクライアントは、クラスタ上のキャッシュに対してデータの読取りおよび書込みを行います。クライアント・データは、どのようなキャッシュ・タイプでも格納できます。Extendクライアントの場合、クラスタ上のキャッシュは、クライアント側で使用されているキャッシュと同じ名前である必要があります。「リモート・キャッシュの定義」を参照してください。キャッシュの定義の詳細は、『Oracle Coherenceでのアプリケーションの開発』のキャッシュの使用に関する項を参照してください。
次の例では、dist-extendという名前のパーティション化されたキャッシュを定義します。
...
<caching-scheme-mapping>
<cache-mapping>
<cache-name>dist-extend</cache-name>
<scheme-name>dist-default</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<distributed-scheme>
<scheme-name>dist-default</scheme-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
...
プロキシ・サービスは通常、クラスタ内でデータの保存を担当していないクラスタ・メンバーで実行されます。ストレージに対応するクラスタ・メンバーは、逆にプロキシ・サービスの影響を受ける場合があり、クライアントの負荷を処理するには、追加のリソースが必要です。ストレージ対応メンバーへのプロキシ・サービスの配置は、単純化された開発では通常は可能ですが、テストや実務環境では使用しないでください。
分散キャッシュで、プロキシ・サーバーとして構成されたクラスタ・メンバーにデータを保存しないようにするには、クラスタ・メンバーの起動時にtangosol.coherence.distributed.localstorage Javaプロパティをfalseに設定します。例:
-Dtangosol.coherence.distributed.localstorage=false
ストレージは、分散キャッシュの定義の際に、キャッシュ構成ファイルで無効にすることもできます。これには、<local-storage要素をfalseに設定します。詳細は、『Oracle Coherenceでのアプリケーションの開発』の<distributed-scheme要素のリファレンスを参照してください。
...
<distributed-scheme>
<scheme-name>dist-default</scheme-name>
<local-storage>false</local-storage>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
...
Extendクライアントは、リモート・キャッシュ・サービスおよびリモート起動サービスを使用して、Coherenceクラスタと相互作用します。これらのサービスは、クラスタ上で実行されている拡張プロキシ・サービスに接続するように構成する必要があります。リモート・キャッシュ・サービスとリモート起動サービスはいずれも、拡張ベースのクライアント・アプリケーションが起動するときにクラスパス上で検出されるキャッシュ構成・デプロイメント・ディスクリプタで構成されます。
この項には、次のトピックが含まれます:
リモート・キャッシュとは、キャッシュ操作をクラスタ上のキャッシュにルーティングする、専用のキャッシュ・サービスです。リモート・キャッシュとクラスタ上のキャッシュは、同じ名前である必要があります。Extendクライアントでは、NamedCacheインタフェースを通常どおりに使用して、キャッシュのインスタンスを取得します。実行時、キャッシュ操作は、ローカルでは実行されず、TCP/IPを使用してクラスタ上の拡張プロキシ・サービスに送信されます。キャッシュ操作をクラスタ上のキャッシュに委任する処理は、Extendクライアントに対して透過的に行われます。
リモート・キャッシュは、<caching-schemesノード内で、<remote-cache-scheme要素を使用して定義されます。クライアントの接続先のクラスタ上にある拡張プロキシ・サービスのアドレス(IPまたはDNS名と、ポート)を定義するには、<tcp-initiator要素を使用します。<remote-cache-schemeサブ要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
例4-2では、dist-extendという名前のリモート・キャッシュを定義し、<socket-address>要素を使用して、拡張プロキシ・サービスがリスニングするアドレス(198.168.1.5およびポート9099)を明示的に構成しています。アドレスは、オペレーション構成オーバーライド・ファイル内で定義でき、<address-provider>要素を使用して参照できます。後者の方法は、アドレス構成をリモート・キャッシュ定義から分離し、リモート・キャッシュ定義を変更することなくランタイムでのアドレスの変更を可能にします。アドレス定義の参照の詳細は、「TCPアドレス用のアドレス・プロバイダ参照の使用」を参照してください。
|
注意: このリモート・キャッシュを使用するには、同じくdist-extendという名前の、クラスタ上で定義されたキャッシュが存在する必要があります。クラスタ上でのキャッシュ定義の詳細は、「Extendクライアントで使用するキャッシュの定義」を参照してください。 |
例4-2 リモート・キャッシュの定義
...
<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>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>
</caching-schemes>
...
Extendクライアントでは通常、リモート・キャッシュをニア・キャッシュの一部として使用します。この場合、ローカル・キャッシュをフロント・キャッシュとして使用し、リモート・キャッシュをバック・キャッシュとして使用します。詳細は、「C++クライアント用ニア・キャッシュの定義」および「.NETクライアント用ニア・キャッシュの定義」をそれぞれ参照してください。
次の例では、ローカル・キャッシュとリモート・キャッシュを同時に使用するニア・キャッシュを作成します。
...
<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>
<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>
</caching-schemes>
...
リモート起動スキームでは、クライアントがリモートのCoherenceクラスタでタスクを実行する際に使用する起動サービスを定義します。Extendクライアントでは、InvocationServiceインタフェースを通常どおりに使用します。実行時に、拡張プロキシ・サービスに対してTCP/IP接続が行われ、InvocationServiceの実装が返されます。これによって、クライアントの接続先のリモート・クラスタJVM内で同期Invocableタスクが実行されます。
リモート起動スキームは、<caching-schemesノード内で、<remote-invocation-scheme要素を使用して定義されます。クライアントの接続先のクラスタ上にある拡張プロキシ・サービスのアドレス(IPまたはDNS名と、ポート)を定義するには、<tcp-initiator要素を使用します。<remote-invocation-schemeサブ要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
例4-3では、ExtendTcpInvocationServiceという名前のリモート起動スキームを定義し、<socket-address>要素を使用して、拡張プロキシ・サービスがリスニングするアドレス(198.168.1.5およびポート9099)を明示的に構成しています。アドレスは、オペレーション構成オーバーライド・ファイル内で定義でき、<address-provider>要素を使用して参照できます。後者の方法は、アドレス構成をリモート起動キャッシュ定義から分離し、リモート起動キャッシュ定義を変更することなく実行時でのアドレスの変更を可能にします。アドレス定義の参照の詳細は、「TCPアドレス用のアドレス・プロバイダ参照の使用」を参照してください。
例4-3 リモート起動スキームの定義
...
<caching-schemes>
<remote-invocation-scheme>
<scheme-name>extend-invocation</scheme-name>
<service-name>ExtendTcpInvocationService</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<socket-address>
<address>198.168.1.5</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>
...
リモート・キャッシュ・スキームとリモート起動スキームには、クライアントがいつでも必ずクラスタに接続できるように、拡張プロキシ・サービスのアドレスを複数含めることができます。接続の調整に使用されているアルゴリズムは、構成されているロード・バランシングの戦略によって変わります。ロード・バランシングの詳細は、「ロード・バランシング接続」を参照してください。
複数のアドレスを構成するには、必要に応じて、<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>9099</port>
</socket-address>
<socket-address>
<address>192.168.1.6</address>
<port>9099</port>
</socket-address>
</remote-addresses>
</tcp-initiator>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
...
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リクエストへの応答を待機する時間を制御します。ベスト・プラクティスとしては、ハートビート・タイムアウトはハートビート間隔未満とし、その他のメンバーが不必要にpingされないように、また未処理のpingが複数存在しないようにする必要があります。
次の例は、例4-2から抜粋したもので、リクエスト・タイムアウトを5秒に設定する場合を示しています。
...
<initiator-config>
<tcp-initiator>
<remote-addresses>
<socket-address>
<address>198.168.1.5</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>
...
次の例では、ハートビート間隔を3秒に、ハートビート・タイムアウトを2秒に設定します。
...
<initiator-config>
<tcp-initiator>
<remote-addresses>
<socket-address>
<address>198.168.1.5</address>
<port>9099</port>
</socket-address>
</remote-addresses>
<connect-timeout>10s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<heartbeat-interval>3s</heartbeat-interval>
<heartbeat-timeout>2s</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="tangosol.coherence.tcmp.enabled">false
</enabled>
</packet-publisher>
</cluster-config>
...
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.tcmp.enabledシステム・プロパティを使用して、TCMPを有効にするかどうかを指定します。例:
-Dtangosol.coherence.tcmp.enabled=false
プロキシ・サービス、リモート・キャッシュおよびリモート起動定義では、キャッシュ構成ファイルで明示的にアドレスを定義するかわりに、<address-provider>を使用して、オペレーション構成オーバーライド・ファイルに定義されたTCPソケット・アドレスを参照できます。ソケット・アドレス定義を参照することで、キャッシュ構成ファイルを更新することなく、ネットワーク・アドレスを変更できます。
TCPアドレス用のアドレス・プロバイダ参照を使用する手順は次のとおりです。
ソケットのアドレスとポートを含んでいる<address-provider要素内で、tangosol-coherence-override.xmlファイル(クライアント上とクラスタ側の両方)を編集し、<socket-address定義を追加します。<address-provider要素のid属性を使用して、ソケット・アドレスの固有IDを定義します。オペレーション構成オーバーライド・ファイルの<address-provider要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。次の例は、proxy1のIDでアドレスを定義しています。
...
<cluster-config>
<address-providers>
<address-provider id="proxy1">
<socket-address>
<address>198.168.1.5</address>
<port>9099</port>
</socket-address>
</address-provider>
</address-providers>
</cluster-config>
...
クラスタ側のcoherence-cache-config.xmlを編集して、プロキシ・サービス定義を作成または更新し、<tcp-acceptor>要素内の<address-provider>要素の値としてソケット・アドレス定義のIDを指定することで、ソケット・アドレス定義を参照します。次の例は、手順1で定義したアドレスを参照するプロキシ・サービスを定義しています。
...
<caching-schemes>
<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<address-provider>proxy1</address-provider>
</tcp-acceptor>
</acceptor-config>
<proxy-config>
<cache-service-proxy>
<enabled>true</enabled>
</cache-service-proxy>
<invocation-service-proxy>
<enabled>true</enabled>
</invocation-service-proxy>
</proxy-config>
<autostart>true</autostart>
</proxy-scheme>
</caching-schemes>
...
クライアント側のcoherence-cache-config.xmlを編集して、リモート・キャッシュまたはリモート起動定義を作成または更新し、<tcp-initiator>要素内の<address-provider>要素の値としてソケット・アドレス定義のIDを指定することで、ソケット・アドレス定義を参照します。次の例は、手順1で定義したアドレスを参照するリモート・キャッシュを定義しています。
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>ExtendTcpCacheService</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<address-provider>proxy1</address-provider>
</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>
ネーム・サービスは特殊化されたTCPアクセプタで、Extendクライアントでは、プロキシ・サービス・アドレスではなく、プロキシ・サービス名を指定することでプロキシに接続できます。クライアントは、要求されたプロキシの実際のアドレスを提供するネーム・サービス・アクセプタへ接続します。ネーム・サービス・アクセプタを使用することで、キャッシュ構成ファイルを更新することなく、実際のプロキシ・アドレスを変更できます。
ネーム・サービス・アクセプタは、プロキシ・サービスがクラスタ・メンバー上に構成されている場合、TCMPソケットと同じポート(デフォルトで8088)で自動的に起動します。さらに、クラスタでTCMPソケットが使用するリスニング・ポートを複数のプロキシ・サービスが使用するように構成することもできます。TCMP、ネーム・サービスおよびプロキシ・サービスと同じポートを使用することは、Coherenceで使用されるポートの数を最小限にして、ファイアウォールの構成を単純化できます。
|
注意: ネーム・サービス・アクセプタを使用するように構成されたクライアントは、ネーム・サービス・アクセプタをサポートするクラスタにしか接続できません。 |
ネーム・サービス・アクセプタを使用してプロキシへ接続する手順は次のとおりです。
クラスタ側のcoherence-cache-config.xmlを編集して、プロキシ・サービス定義を作成または更新します。<tcp-acceptor>要素内で明示的にソケット・アドレスを定義しないでください。次の例は、TCMPが使用するポートにバインドするTcpExtendという名前のプロキシ・サービスを定義しています。
...
<caching-schemes>
<proxy-scheme>
<service-name>TcpExtend/service-name>
<acceptor-config/>
<autostart>true</autostart>
</proxy-scheme>
</caching-schemes>
...
クライアント側のcoherence-cache-config.xmlを編集して、リモート・キャッシュまたはリモート起動定義を作成または更新し、<tcp-initiator>要素内に<name-service-addresses>要素を追加します。この要素は、クラスタ上のネーム・サービス・アクセプタのソケット・アドレスを含みます。次の例は、手順1で構成したTcpExtendプロキシ・サービスへの接続を確立するネーム・サービスへ接続するためのリモート・キャッシュ定義を指定しています。この例では、ポート8088をTCMPクラスタ・ポート、ネーム・サービス・ポートおよびプロキシ・サービス・ポートとして使用しています。
|
注意:
|
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>TcpExtend</service-name>
<initiator-config>
<tcp-initiator>
<name-service-addresses>
<socket-address>
<address>198.168.1.5</address>
<port>8088</port>
</socket-address>
</name-service-addresses>
<connect-timeout>5s</connect-timeout>
</tcp-initiator>
</initiator-config>
</remote-cache-scheme>
カスタム・アドレス・プロバイダは、サーバー・ソケットにバインドするとき、TCPアドレスおよびポートの設定を動的に割り当てます。アドレス・プロバイダは、com.tangosol.net.AddressProviderインタフェースの実装である必要があります。アドレスの動的割当ては通常、カスタムのロード・バランシング・アルゴリズムを実装するために使用します。
アドレス・プロバイダは、拡張プロキシ・スキームの場合は<tcp-acceptor>要素内、リモート・キャッシュ・スキームおよびリモート起動スキームの場合は<tcp-initiator>要素内で使用できる、<address-provider>要素を使用して定義します。
次の例は、拡張プロキシ・スキームを構成するときに、MyAddressProviderという名前のAddressProviderの実装をTCPアクセプタ用に構成する方法を示しています。
...
<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<address-provider>
<class-name>com.MyAddressProvider</class-name>
</address-provider>
</tcp-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
...
次の例は、リモート・キャッシュ・スキームを構成するときに、MyClientAddressProviderという名前のAddressProviderの実装をTCPイニシエータ用に構成する方法を示しています。
...
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>ExtendTcpCacheService</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<address-provider>
<class-name>com.MyClientAddressProvider</class-name>
</address-provider>
</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>
...
さらに、<address-provider>要素では、AddressProviderインスタンスを作成するためのファクトリ・クラスを使用するために<class-factory-name>要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name>要素の使用もサポートされています。
Extendクライアント接続は、プロキシ・サービスのメンバー間で自動的にロード・バランシングされます。デフォルトでは、クライアント接続を利用率の低いプロキシ・サービス・メンバーに分散するプロキシベースの戦略が使用されます。必要に応じてカスタムのプロキシベースの戦略の作成や、デフォルトの戦略の変更が可能です。また別の戦略として、クライアント側アドレス・プロバイダを作成するか、プロキシ・サービス・メンバーへのクライアント接続のランダム化によってクライアントベースのロード・バランシングの戦略を実装できます。ランダム化のアプローチによってもたらされるバランシングは、プロキシベースのロード・バランシングと比べて最小限にとどまります。
Coherence*Extendは、ハードウェアベースのロード・バランシングを提供するF5 BIG-IP Local Traffic Manager (LTM)と併用できます。詳細は、付録B「F5 BIG-IP LTMとの統合」を参照してください。
この項には、次のトピックが含まれます:
プロキシベースのロード・バランシングは、クライアント接続を複数の同じプロキシ・サービスのメンバーで調整するデフォルトの戦略です。この戦略は、プロキシの既存接続数、プロキシのデーモン・プールの利用率、プロキシのメッセージ・バックログの順番に重み付けされています。
プロキシベースのロード・バランシングの戦略は、<proxy-scheme>定義内で <load-balancer>要素を使用し、proxyに設定することで構成します。わかりやすいように、次の例ではこの戦略を明示的に指定しています。ただし、戦略が指定されていない場合もこの戦略が使用されるため、プロキシ・スキーム定義では必須ではありません。
...
<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>192.168.1.5</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<load-balancer>proxy</load-balancer>
<autostart>true</autostart>
</proxy-scheme>
...
|
注意: プロキシベースのロード・バランシングを使用するとき、クライアントでは、キャッシュ構成に全プロキシ・サービス・メンバーのリストを必要としません。ただし、冗長化の目的で、常に最低2つのプロキシ・サービス・メンバーを構成する必要があります。クライアントによって使用する複数のリモート・アドレスの定義方法の詳細は、「複数のリモート・アドレスの定義」を参照してください。 |
プロキシベースのロード・バランシング・アルゴリズムは、プロキシ・サービスのメンバーに均等にクライアント接続を分配します。このアルゴリズムは、利用率の低いプロキシ・サービス・メンバーにクライアントをリダイレクトします。プロキシの使用率の決定には次の係数が使用されています。
接続の使用率 - この使用率は、現在の接続数と保留接続の数を合計して計算されます。プロキシに設定済の接続制限があり、現在の接続数と保留接続の数の合計が接続制限と同じ場合、使用率は無限大と見なされます。
デーモン・プールの使用率 - この使用率は、アクティブなデーモン・スレッドの現在の数と同じになります。すべてのデーモン・スレッドが現在アクティブな場合、使用率は無限大と見なされます。
メッセージ・バックログの使用率 - この使用率は、現在の受信バックログと現在の送信メッセージ・バックログを合計して計算されます。
各プロキシ・サービスでは、使用率順に並べられた全プロキシ・サービスのメンバーのリストが維持されます。この順序付けは、接続の使用率、デーモン・プールの使用率、メッセージ・バックログの順番で重み付けされます。このリストでは、プロキシ・サービス・メンバーの使用率が変わるたびに、並替えが行われます。プロキシ・サービス・メンバーは互いに、接続数が変わるごとまたは10秒ごと(いずれかが先に発生したとき)に現在の使用率を送信します。
プロキシで新しい接続が試行されたとき、リストは次のように更新されます。
現在のプロキシの接続使用率が低い場合は接続が許可され、そうでない場合は、低い接続使用率のプロキシ・サービス・メンバーの順番に並べられたリストがある接続の試行に返信することでその新規接続がリダイレクトされます。次に、クライアントは戻されたリストの順にプロキシ・サービス・メンバーへ接続を試行します。
プロキシの接続使用率が同じ場合は、プロキシのデーモン・プールの使用率で優先順位が決定されます。現在のプロキシのデーモン・プール使用率が低い場合は接続が許可され、そうでない場合は、低いデーモン・プール使用率のプロキシ・サービス・メンバーが順番に並べられたリストがある接続の試行に返信することでその新規接続がリダイレクトされます。次に、クライアントは戻されたリストの順にプロキシ・サービス・メンバーへ接続を試行します。
プロキシのデーモン・プール使用率が同じ場合は、プロキシのメッセージ・バックログで優先順位が決定されます。現在のプロキシのメッセージ・バックログ使用率が低い場合は接続が許可され、そうでない場合は、低いメッセージ・バックログ使用率のプロキシ・サービス・メンバーが順番に並べられたリストがある接続の試行に返信することでその新規接続がリダイレクトされます。次に、クライアントは戻されたリストの順にプロキシ・サービス・メンバーへ接続を試行します。
すべてのプロキシが同じ使用率の場合、クライアントは現在のプロキシに接続します。
com.tangosol.coherence.net.proxyパッケージには、プロキシ・サービスのメンバー間でクライアントの負荷を調節するために使用するAPIが含まれています。プロキシベースのロード・バランシングAPIの使用方法の詳細は、Oracle Coherence Java APIリファレンスを参照してください
カスタムの戦略では、ProxyServiceLoadBalancerインタフェースを実装する必要があります。必要に応じて新規の戦略を作成するか、デフォルトの戦略(DefaultProxyServiceLoadBalancer)を拡張または変更できます。たとえば、プロキシ・サービスのリストで優先する使用率係数を変更するには、目的の順番を強制するコンストラクタでDefaultProxyServerLoadBalancerを拡張し、カスタムComparatorオブジェクトを渡します。最後に、クライアントのMemberオブジェクト(各クライアントを一意に定義)を戦略に渡します。Memberオブジェクトは、クライアントに重み付けをした戦略を実装する手段となります。クライアントのメンバー識別情報を構成する方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
カスタムのロード・バランシング戦略を有効にするには、<load-balancer>要素内に<instance>のサブ要素を追加し、ProxyServiceLoadBalancerインタフェースを実装する完全修飾クラス名を指定します。次の例は、MyProxyServiceLoadBalancerクラスに実装されているカスタムのプロキシベース・ロード・バランシングの戦略を有効化します。
...
<load-balancer>
<instance>
<class-name>package.MyProxyServiceLoadBalancer</class-name>
</instance>
</load-balancer>
...
さらに、<instance要素では、ProxyServiceLoadBalancerインスタンスを作成するためのファクトリ・クラスを使用するために<class-factory-name要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name要素の使用もサポートされています。<instance要素の詳細な手順は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
クライアントベースのロード・バランシングの戦略は、プロキシ・サービス・メンバー間でのクライアントの分配を処理するクライアント・アドレス・プロバイダ実装に依存しています。クライアント・アドレス・プロバイダ実装が提供されていない場合、Extendクライアントは、接続が成功するまで構成済の各プロキシ・サービスへランダムな順序で接続を試行します。アドレス・プロバイダ実装の提供方法の詳細は、「TCPアドレス用のアドレス・プロバイダの使用」を参照してください。
クライアントベースのロード・バランシングの戦略は、<proxy-scheme>定義内で <load-balancer>要素を使用し、clientに設定することで構成します。例:
...
<proxy-scheme>
<service-name>ExtendTcpProxyService1</service-name>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>192.168.1.5</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<load-balancer>client</load-balancer>
<autostart>true</autostart>
</proxy-scheme>
...
前述の構成は、クライアントの戦略を1つのプロキシ・サービスに設定するため、クライアントの戦略を使用するすべてのプロキシ・サービスで繰り返し設定する必要があります。戦略が指定されていない場合に、クライアントの戦略をすべてのプロキシ・サービスのデフォルトの戦略として設定するには、オペレーション・オーバーライド・ファイルでプロキシ・サービス・タイプにload-balancerパラメータをオーバーライドします。例:
...
<cluster-config>
<services>
<service id="7">
<init-params>
<init-param id="12">
<param-name>load-balancer</param-name>
<param-value>client</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
...
Coherenceクラスタ化サービス同様、Coherence*Extendサービスはプラガブルなネットワーク・フィルタをサポートします。フィルタは、送信前のネットワーク・トラフィックのコンテンツを変更します。フィルタの構成方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
Coherence*Extendでネットワーク・フィルタを使用するには、<use-filters>要素を、クライアント側のキャッシュ構成ディスクリプタの<initiator-config>要素とクラスタ側のキャッシュ構成ディスクリプタの<acceptor-config>要素に追加する必要があります。
|
注意: <use-filters>要素の内容は、クライアント側およびクラスタ側のキャッシュ構成ディスクリプタで同じにする必要があります。 |
たとえば、Extendクライアントとクラスタ化サービスとの間で事前定義のgzipフィルタを使用して交換されるネットワーク・トラフィックを圧縮するには、次に示すように、クライアント側の<remote-cache-scheme>要素および<remote-invocation-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>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
<use-filters>
<filter-name>gzip</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>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
<use-filters>
<filter-name>gzip</filter-name>
</use-filters>
</initiator-config>
</remote-invocation-scheme>
クラスタ側では、クライアント側の構成と同じ名前のフィルタを指定する<use-filters>要素を<proxy-scheme>要素内に追加します。
<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>localhost</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
<use-filters>
<filter-name>gzip</filter-name>
</use-filters>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
