この章の内容は次のとおりです。
<address-provider>
を使用してオペレーション構成オーバーライド・ファイルに定義されたTCPソケット・アドレスを参照できます。 親トピック: はじめに
<address-provider>
を使用して、オペレーション構成オーバーライド・ファイルに定義された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>
要素の使用もサポートされています。
デフォルトのプロキシベースの戦略では、クライアント接続を、最も使用率の低いプロキシ・サービスのメンバーに配布します。必要に応じてカスタムのプロキシベースの戦略の作成や、デフォルトの戦略の変更が可能です。また別の戦略として、クライアント側アドレス・プロバイダを作成するか、プロキシ・サービス・メンバーへのクライアント接続のランダム化によってクライアントベースのロード・バランシングの戦略を実装できます。ランダム化のアプローチによってもたらされるバランシングは、プロキシベースのロード・バランシングと比べて最小限にとどまります。
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が含まれています。
カスタムの戦略では、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
要素の使用もサポートされています。Oracle Coherenceでのアプリケーションの開発のinstanceを参照してください。
クライアントベースのロード・バランシングの戦略は、プロキシ・サービス・メンバー間でのクライアントの分配を処理するクライアント・アドレス・プロバイダ実装に依存しています。クライアント・アドレス・プロバイダ実装が提供されていない場合、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*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>