| Oracle® Fusion Middleware Oracle Coherenceリモート・クライアントの開発 12c (12.2.1.1) E77321-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
プロキシ・サービス、リモート・キャッシュおよびリモート起動定義では、キャッシュ構成ファイルで明示的にアドレスを定義するかわりに、<address-provider>を使用して、オペレーション構成オーバーライド・ファイルに定義されたTCPソケット・アドレスを参照できます。ソケット・アドレス定義を参照することで、キャッシュ構成ファイルを更新することなく、ネットワーク・アドレスを変更できます。
TCPアドレス用のアドレス・プロバイダ参照を使用する手順は次のとおりです。
カスタム・アドレス・プロバイダは、サーバー・ソケットにバインドするとき、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>
</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)と併用できます。詳細は、「F5 BIG-IP LTMとの統合」を参照してください。
この項の内容は、次のとおりです。
プロキシベースのロード・バランシングは、クライアント接続を複数の同じプロキシ・サービスのメンバーで調整するデフォルトの戦略です。この戦略は、プロキシの既存接続数、プロキシのデーモン・プールの利用率、プロキシのメッセージ・バックログの順番に重み付けされています。
プロキシベースのロード・バランシングの戦略は、<proxy-scheme>定義内で <load-balancer>要素を使用し、proxyに設定することで構成します。わかりやすいように、次の例ではこの戦略を明示的に指定しています。ただし、戦略が指定されていない場合もこの戦略が使用されるため、プロキシ・スキーム定義では必須ではありません。
... <proxy-scheme> <service-name>ExtendTcpProxyService</service-name> <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> <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>7077</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>7077</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>7077</port>
</local-address>
</tcp-acceptor>
<use-filters>
<filter-name>gzip</filter-name>
</use-filters>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
