| Oracle® Coherenceクライアント・ガイド リリース3.7.1 B65027-01 |
|
 前 |
 次 |
この章では、Coherence*Extendを構成する手順について説明します。この手順は、基本設定を行うためのものであり、完全な構成方法を示すものではありません。また、追加の構成手順については、このガイドのプラットフォーム固有の項を参照してください。構成および設定も含むJavaの完全な例については、第4章「最初の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>要素を使用して構成します。<proxy-scheme>要素には、子要素の<tcp-acceptor>があり、この子要素には、TCP/IPクライアント通信のために拡張プロキシ・サービスがリスニングするアドレス(IPまたはDNS名)およびポートが含まれます。<proxy-scheme>のすべてのサブ要素の一覧と説明は、『Oracle Coherence開発者ガイド』のproxy-scheme要素参照を参照してください。
例3-1では、198.168.1.5およびポート9099にバインドされているTCP/IP ServerSocketでクライアント・リクエストをリスニングするように設定されている、ExtendTcpProxyServiceという名前のプロキシ・サービスを定義します。キャッシュと起動の両方のクラスタ・サービス・プロキシが、クライアント・リクエストに対して有効になっています。さらに、クラスタ・ノードでサービスが自動的に開始されるように、<autostart>要素がtrueに設定されています。
例3-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>
...
|
注意: わかりやすいように、前述の例では、キャッシュおよび起動のクラスタ・サービス・プロキシを明示的に有効にしています。ただし、いずれのプロキシもデフォルトで有効なため、<cache-service-proxy>要素と<invocation-service-proxy>要素をプロキシ・スキーム定義に含める必要はありません。 |
予想されるクライアント接続数をサポートするため、およびフォルト・トレランスとロード・バランシングをサポートするために、複数の拡張プロキシ・サービス・インスタンスを定義できます。クライアント接続は、プロキシ・サービス・インスタンス間で自動的に調整されます。接続の調整に使用されているアルゴリズムは、構成されているロード・バランシングの方針によって変わります。ロード・バランシングの詳細は、「ロード・バランシング接続」を参照してください。
複数のプロキシ・サービス・インスタンスを定義するには、単一のプロキシ・サービス定義を複数のキャッシュ・サーバーで読み込んで、各プロキシ・サービスに同じサービス名を使用します。同じサービス名のプロキシ・サービスはピアと見なすことができます。
次の例では、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>
デフォルトでは、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という名前のパーティション化されたキャッシュを定義します。
<?xml version="1.0"?>
<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>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>
</cache-config>
Extendクライアントは、リモート・キャッシュ・サービスおよびリモート起動サービスを使用して、Coherenceクラスタと相互作用します。これらのサービスは、クラスタ上で実行されている拡張プロキシ・サービスに接続するように構成する必要があります。リモート・キャッシュ・サービスとリモート起動サービスはいずれも、拡張ベースのクライアント・アプリケーションが起動するときにクラスパス上で検出されるキャッシュ構成・デプロイメント・ディスクリプタで構成されます。
この項は、次のトピックで構成されています。
リモート・キャッシュとは、キャッシュ操作をクラスタ上のキャッシュにルーティングする、専用のキャッシュ・サービスです。リモート・キャッシュとクラスタ上のキャッシュは、同じ名前である必要があります。Extendクライアントでは、NamedCacheインタフェースを通常どおりに使用して、キャッシュのインスタンスを取得します。実行時、キャッシュ操作は、ローカルでは実行されず、TCP/IPを使用してクラスタ上の拡張プロキシ・サービスに送信されます。キャッシュ操作をクラスタ上のキャッシュに委任する処理は、Extendクライアントに対して透過的に行われます。
リモート・キャッシュは、<caching-schemes>ノード内で、<remote-cache-scheme>要素を使用して定義されます。クライアントの接続先のクラスタ上にある拡張プロキシ・サービスのアドレス(IPまたはDNS名)およびポートを定義するには、<tcp-initiator>要素を使用します。<remote-cache-scheme>のすべてのサブ要素の一覧と説明は、『Oracle Coherence開発者ガイド』のremote-cache-scheme要素参照を参照してください。
表3-0では、アドレス198.168.1.5、ポート9099でリスニングしている拡張プロキシ・サービスに接続する、dist-extendという名前のリモート・キャッシュを定義します。このリモート・キャッシュを使用するには、同じくdist-extendという名前の、クラスタ上で定義されたキャッシュが存在する必要があります。クラスタ上でのキャッシュ定義の詳細は、「Extendクライアントで使用するキャッシュの定義」を参照してください。
例3-2 リモート・キャッシュの定義
<?xml version="1.0"?>
<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
cache-config.xsd">
<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>
<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>
</cache-config>
Extendクライアントでは通常、リモート・キャッシュをニア・キャッシュの一部として使用します。この場合、ローカル・キャッシュをフロント・キャッシュとして使用し、リモート・キャッシュをバック・キャッシュとして使用します。詳細は、「C++クライアント用ニア・キャッシュの定義」および「.NETクライアント用ニア・キャッシュの定義」をそれぞれ参照してください。
次の例では、ローカル・キャッシュとリモート・キャッシュを同時に使用するニア・キャッシュを作成します。
<?xml version="1.0"?>
<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>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>
</cache-config>
リモート起動スキームでは、クライアントがリモートのCoherenceクラスタでタスクを実行する際に使用する起動サービスを定義します。Extendクライアントでは、InvocationServiceインタフェースを通常どおりに使用します。実行時に、拡張プロキシ・サービスに対してTCP/IP接続が行われ、InvocationServiceの実装が返されます。これによって、クライアントの接続先のリモート・クラスタJVM内で同期Invocableタスクが実行されます。
リモート起動スキームは、<caching-schemes>ノード内で、<remote-invocation-scheme>要素を使用して定義されます。クライアントの接続先のクラスタ上にある拡張プロキシ・サービスのアドレス(IPまたはDNS名)およびポートを定義するには、<tcp-initiator>要素を使用します。<remote-invocation-scheme>のすべてのサブ要素の一覧と説明は、『Oracle Coherence開発者ガイド』のremote-invocation-scheme要素参照を参照してください。
例3-3では、アドレス198.168.1.5、ポート9099でリスニングしている拡張プロキシ・サービスに接続する、ExtendTcpInvocationServiceという名前のリモート起動スキームを定義します。
例3-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サービスには、接続の切断を検出するためのメカニズムがいくつか用意されています。その中には、基礎となるTCP/IPプロトコルを継承するものや、サービス自体によって実装されるものがあります。後者のメカニズムは、<outgoing-message-handler>要素内で構成します。
<request-timeout>要素は、接続の切断を検出する主要メカニズムです。サービスがリモート・クラスタにリクエストを送信したものの、リクエストのタイムアウト時間内にレスポンスを受信しなかった場合、サービスでは接続が切断されたと想定されます。
|
警告:
|
次の例は、例3-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>
...
<heartbeat-interval>および<heartbeat-timeout>も、接続の切断を検出するために使用できます。構成されたハートビートのタイムアウト時間内にサービスがレスポンスを受信しなかった場合、サービスでは接続が切断されたと想定されます。
次の例では、ハートビート間隔を500ミリ秒に、ハートビート・タイムアウトを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>
<heartbeat-interval>500ms</heartbeat-interval>
<heartbeat-timeout>5s</heartbeat-timeout>
</outgoing-message-handler>
</initiator-config>
...
ネットワーク内に配置されたJavaベースのExtendクライアントでは、拡張プロキシを使用して排他的にクラスタ・サービスに接続するために、TCMP通信を無効にする必要があります。TCMPが無効でない場合、JavaベースのExtendクライアントが互いにクラスタ化される可能性があり、既存のクラスタに追加される可能性もあります。TCMPはクラスタ側のtangosol-coherence-override.xmlファイルで無効にします。
TCMP通信を無効にするには、<packet-publisher>内の<enabled>要素をfalseに設定します。例:
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<enabled system-property="tangosol.coherence.tcmp.enabled">false
</enabled>
</packet-publisher>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.tcmp.enabledシステム・プロパティを使用して、TCMPを有効にするかどうかを指定します。例:
-Dtangosol.coherence.tcmp.enabled=false
アドレス・プロバイダは、サーバー・ソケットにバインドするとき、TCPアドレスおよびポートの設定を動的に割り当てます。アドレス・プロバイダは、com.tangosol.net.AddressProviderインタフェースの実装である必要があります。アドレスの動的割当ては通常、カスタムのロード・バランシング・アルゴリズムを実装するために使用します。
アドレス・プロバイダは、拡張プロキシ・スキームの場合は<tcp-acceptor>要素内、リモート・キャッシュ・スキームおよびリモート起動スキームの場合は<tcp-initiator>要素内で使用できる、<address-provider>要素を使用して定義します。
次の例は、拡張プロキシ・スキームを構成するときに、MyAddressProviderという名前のAddressProviderの実装をTCPアクセプタ用に構成する方法を示しています。
...
<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<thread-count>5</thread-count>
<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パラメータをオーバーライドします。例:
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<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>
