17 クォーラムの使用

この章では、クラスタの適切なプロビジョニングを確保するためにクラスタ内で特定のサービス・アクションが許可されるタイミングを制御するクォーラム・ポリシーの使用方法と構成方法について説明します。

この章には次の項が含まれます:

クォーラムの使用の概要
クラスタ・クォーラムの使用
パーティション・キャッシュ・クォーラムの使用
プロキシ・クォーラムの使用
カスタムのアクション・ポリシーの使用

17.1 クォーラムの使用の概要

Coherenceでは、クォーラムとは、サービス・アクションを許可または禁止する前にクラスタに必要なサービス・メンバーの最小数のことです。クォーラムを使用すると、メンバー数がしきい値に達したときにクラスタが予測どおりに動作することが自動的に保証されるため、クォーラムは有用です。たとえば、パーティション・キャッシュのバックアップのクォーラムには、パーティション・キャッシュ・サービスがパーティションのバックアップを許可される前に、記憶域が有効なメンバーが5つ以上必要となる場合があります。

クォーラムはサービス固有で、クォーラム・ポリシー内で定義されます。クラスタ・サービスのクラスタ・クォーラム・ポリシー、パーティション・キャッシュ・サービスのパーティション・クォーラム・ポリシーおよびプロキシ・サービスのプロキシ・クォーラム・ポリシーがあります。クォーラムのしきい値は、キャッシュ構成ファイルを使用してポリシーに設定されます。

各クォーラムには、それぞれの特定のサービスに関する利点があります。ただし、一般的にクォーラムは次のとおりです。

様々なサービス・メンバー・レベルでサービスの動作を制御します。
サービスの操作に必要な最小限のサービス・メンバー・レベルを指定する必要があります。
特定のアプリケーションまたはソリューションに最適なクラスタおよびキャッシュ環境を保証します。

17.2 クラスタ・クォーラムの使用

クラスタ・クォーラム・ポリシーによって、クラスタ・サービスに1つのクォーラム(タイムアウト・サバイバ・クォーラム)が定義されます。タイムアウト・サバイバ・クォーラムでは、疑いのあるメンバーをクラスタ・サービスが終了するときに、クラスタに保持しておく必要があるクラスタ・メンバーの最小数を指定する必要があります。メンバーは、ネットワーク通信に応答しておらず、クラスタから切断される危険が迫っている場合に、疑いがあると見なされます。クォーラムをすべてのメンバーに汎用的に指定することも、クライアント・メンバーやサーバー・メンバーなどクラスタ内で特定のロールを持っているメンバーに制約することもできます。クラスタ・メンバーのロール名の定義の詳細は、「member-identity」の<role-name>要素を参照してください。

このクォーラムは通常、ネットワーク・パフォーマンスが変化する環境で使用されます。たとえば、断続的なネットワーク停止によって多くのクラスタ・メンバーがクラスタから削除されてしまう場合があります。このクォーラムを使用すると、一定の数のメンバーが停止時に保持され、ネットワークの回復時に使用可能になります。また、この動作によって、メンバーの再起動に必要な手動の介在が最小限に抑えられます。当然ながら、応答していないノードからの協調関係を必要とするリクエストは完了できず、停止時間中はブロックされるか、またはタイムアウトになります。

17.2.1 クラスタ・クォーラム・ポリシーの構成

タイムアウト・サバイバ・クォーラムのしきい値は、<timeout-survivor-quorum>要素とオプションでrole属性を使用して、オペレーション・オーバーライド・ファイルに構成します。この要素は、<cluster-quorum-policy>要素内で使用する必要があります。次の例では、疑いのあるメンバーを削除するときに、serverロールが付与された5つのクラスタ・メンバーが常にクラスタに保持されるように、タイムアウト・サバイバ・クォーラムのしきい値が構成されます。

<cluster-config>
   <member-identity>
      <role-name>server</role-name>
   </member-identity>
   <cluster-quorum-policy>
      <timeout-survivor-quorum role="Server">5</timeout-survivor-quorum>
   </cluster-quorum-policy>
</cluster-config>

17.3 パーティション・キャッシュ・クォーラムの使用

パーティション・キャッシュ・クォーラム・ポリシーでは、様々なパーティション・キャッシュ・サービス操作の実行を許可する前に、必要なサービス・メンバーの数を指定する必要がある4つのクォーラムがパーティション・キャッシュ・サービス(DistributedCache)に定義されます。

分散クォーラム - このクォーラムでは、パーティション・キャッシュ・サービスによるパーティション分散の実行を許可する前に、存在している必要のある、パーティション・キャッシュ・サービスの記憶域が有効なメンバーの最小数を指定する必要があります。
リストア・クォーラム - このクォーラムでは、失われたプライマリ・パーティションをバックアップからリストアするパーティション・キャッシュ・サービスによる操作を許可する前に、存在している必要のある、パーティション・キャッシュ・サービスの記憶域が有効なメンバーの最小数を指定する必要があります。
読取りクォーラム - このクォーラムでは、読取りリクエストを処理するために存在している必要のあるパーティション・キャッシュ・サービスの記憶域が有効なメンバーの最小数を指定します。読取りリクエストとは、キャッシュの状態や内容を変化させないリクエストです。
書込みクォーラム - このクォーラムでは、書込みリクエストを処理するために存在している必要のあるパーティション・キャッシュ・サービスの記憶域が有効なメンバーの最小数を指定します。書込みリクエストとは、キャッシュの状態や内容を変化させる可能性のあるリクエストです。

これらのクォーラムは通常、分散キャッシュを意図された使用方法と要件で使用する場合に、様々なサービス操作が最適に実行されるサービス・メンバー・レベルを示すために使用されます。たとえば、小さな分散キャッシュで、適切にデータを格納し、予想されるリクエスト量を処理するために、記憶域が有効なメンバーが3つのみ必要な場合があります。一方、大きな分散キャッシュで、適切にデータを格納し、予想されるリクエスト量を処理するために、記憶域が有効なメンバーが10以上必要な場合があります。最適なメンバー・レベルは、開発時にテストし、それに合わせて本番環境で最小のサービス・メンバー・レベルが使用できるように設定します。

サービスを実行する、記憶域が有効なノードの数が、読取りまたは書込みクォーラムの構成レベルを下回った場合は、com.tangosol.net.RequestPolicyExceptionのスローによって対応するクライアント操作が拒否されます。記憶域が有効なノードの数が分散クォーラムの構成レベルを下回った場合は、クォーラムに達するまで一部のデータが消失の危険がある状態(バックアップがない)になることがあります。リストア・クォーラムを下回った場合は、クォーラムに達するかタイムアウトになるまで一部の操作がブロックされることがあります。

17.3.1 パーティション・キャッシュ・クォーラム・ポリシーの構成

パーティション・キャッシュ・クォーラムは、キャッシュ構成ファイルの<partitioned-quorum-policy-scheme>要素内で構成します。この要素は、<distributed-scheme>要素内で使用する必要があります。次の例では、パーティション・キャッシュ・クォーラムにしきい値を構成しています。しきい値には、操作の実行に必要なサービス・メンバーの最小数を指定することをお薦めします。

<distributed-scheme>
   <scheme-name>partitioned-cache-with-quorum</scheme-name>
   <service-name>PartitionedCacheWithQuorum</service-name>
   <backing-map-scheme>
      <local-scheme/>
   </backing-map-scheme>
   <partitioned-quorum-policy-scheme>
      <distribution-quorum>4</distribution-quorum>
      <restore-quorum>3</restore-quorum>
      <read-quorum>3</read-quorum>
      <write-quorum>5</write-quorum>
   </partitioned-quorum-policy-scheme>
   <autostart>true</autostart>
</distributed-scheme>

<partitioned-quorum-policy-scheme>要素では、スキーム参照の使用もサポートされています。次の例では、partitioned-cache-quorumという名前の<partitioned-quorum-policy-scheme>が、<distributed-scheme>要素内から参照されます。

<distributed-scheme>
   <scheme-name>partitioned-cache-with-quorum</scheme-name>
   <service-name>PartitionedCacheWithQuorum</service-name>
   <backing-map-scheme>
      <local-scheme/>
   </backing-map-scheme>
   <partitioned-quorum-policy-scheme>
      <scheme-ref>partitioned-cache-quorum</scheme-ref>
   </partitioned-quorum-policy-scheme>
   <autostart>true</autostart>
</distributed-scheme>
 
<distributed-scheme>
   <scheme-name>dist-example</scheme-name>
   <service-name>DistributedCache</service-name>
   <backing-map-scheme>
      <local-scheme/>
   </backing-map-scheme>
   <partitioned-quorum-policy-scheme>
      <scheme-name>partitioned-cache-quorum</scheme-name>
      <distribution-quorum>4</distribution-quorum>
      <restore-quorum>3</restore-quorum>
      <read-quorum>3</read-quorum>
      <write-quorum>5</write-quorum>
   </partitioned-quorum-policy-scheme>
   <autostart>true</autostart>
</distributed-scheme>

17.4 プロキシ・クォーラムの使用

プロキシ・クォーラム・ポリシーによって、プロキシ・サービスに1つのクォーラム(接続クォーラム)が定義されます。接続クォーラムでは、プロキシ・サービスでクライアント接続が許可される前に使用可能にしておく必要のあるプロキシ・サービス・メンバーの最小数を指定する必要があります。

このクォーラムは通常、指定のTCPクライアント・セットを最適にサポートするために十分なプロキシ・サービス・メンバーが使用可能であることを保証するために使用します。たとえば、少数のクライアントから2つのプロキシ・サービスを使用してクラスタに効率的に接続する場合があります。一方、多数のクライアントで、クラスタに効率的に接続するには3つ以上のプロキシ・サービスが必要な場合があります。最適なレベルは、開発時にテストし、それに合わせて本番環境で最小のサービス・メンバー・レベルが使用できるように設定します。

17.4.1 プロキシ・クォーラム・ポリシーの構成

接続クォーラムのしきい値は、キャッシュ構成ファイルの<proxy-quorum-policy-scheme>要素内で構成します。この要素は、<proxy-scheme>要素内で使用する必要があります。次の例では、プロキシ・サービスでTCPクライアント接続の受入れが許可される前にクラスタに必ず3つのプロキシ・サービス・メンバーが存在するように接続クォーラムのしきい値を構成しています。

<proxy-scheme>
   <scheme-name>proxy-with-quorum</scheme-name>
   <service-name>TcpProxyService</service-name>
   <acceptor-config>
      <tcp-acceptor>
         <local-address>
            <address>localhost</address>
            <port>32000</port>
         </local-address>
      </tcp-acceptor>
   </acceptor-config>
   <proxy-quorum-policy-scheme>
      <connect-quorum>3</connect-quorum>
   </proxy-quorum-policy-scheme>
   <autostart>true</autostart>
</proxy-scheme>

<proxy-quorum-policy-scheme>要素では、スキーム参照の使用もサポートされています。次の例では、proxy-quorumという名前の<proxy-quorum-policy-scheme>が、<proxy-scheme>要素内から参照されます。

<proxy-scheme>
   <scheme-name>proxy-with-quorum</scheme-name>
   <service-name>TcpProxyService</service-name>
   ...
   <proxy-quorum-policy-scheme>
      <scheme-ref>proxy-quorum</scheme-ref>
   </proxy-quorum-policy-scheme>
   <autostart>true</autostart>
</proxy-scheme>
<proxy-scheme>
   <scheme-name>proxy-example</scheme-name>
   <service-name>TcpProxyService</service-name>
   ...
   <proxy-quorum-policy-scheme>
      <scheme-name>proxy-quorum</scheme-name>
      <connect-quorum>3</connect-quorum>
   </proxy-quorum-policy-scheme>
   <autostart>true</autostart>
</proxy-scheme>

17.5 カスタムのアクション・ポリシーの使用

カスタムのアクション・ポリシーは、クラスタ・サービス、パーティション・キャッシュ・サービスおよびプロキシ・サービスのデフォルトのクォーラム・ポリシーのかわりに使用できます。カスタムのアクション・ポリシーは、com.tangosol.net.ActionPolicyインタフェースを実装する必要があります。

この項には次のトピックが含まれます:

カスタムのアクション・ポリシーの有効化
カスタム・フェイルオーバー・アクセス・ポリシーの有効化

17.5.1 カスタムのアクション・ポリシーの有効化

カスタムのポリシーを有効にするには、実装クラスの完全修飾名が含まれるクォーラム・ポリシー・スキーム要素に<class-name>要素を追加します。次の例では、分散キャッシュ・スキーム定義のパーティション・クォーラム・ポリシーにカスタムのアクション・ポリシーが追加されます。

<distributed-scheme>
   <scheme-name>partitioned-cache-with-quorum</scheme-name>
   <service-name>PartitionedCacheWithQuorum</service-name>
   <backing-map-scheme>
     <local-scheme/>
   </backing-map-scheme>
   <partitioned-quorum-policy-scheme>
      <class-name>package.MyCustomAction</class-name>
   </partitioned-quorum-policy-scheme>
   <autostart>true</autostart>
</distributed-scheme>

代替案として、ファクトリ・クラスでカスタム・アクション・ポリシー・インスタンスを作成できます。ファクトリ・クラスを定義するには、<class-factory-name>要素を使用して、完全修飾クラス名と<method-name>要素を入力し、オブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドの名前を指定します。次に例を示します。

<distributed-scheme>
   <scheme-name>partitioned-cache-with-quorum</scheme-name>
   <service-name>PartitionedCacheWithQuorum</service-name>
   <backing-map-scheme>
     <local-scheme/>
   </backing-map-scheme>
   <partitioned-quorum-policy-scheme>
      <class-factory-name>package.Myfactory</class-factory-name>
      <method-name>createPolicy</method-name>
   </partitioned-quorum-policy-scheme>
   <autostart>true</autostart>
</distributed-scheme>

17.5.2 カスタム・フェイルオーバー・アクセス・ポリシーの有効化

Coherenceは、キャッシュ・サーバーがパーティション・バックアップを適切に再確立できるよう、フェイルオーバー・イベント中にクライアント・リクエストの負荷を軽減する事前定義済カスタム・アクション・ポリシーを提供します。このポリシーは、長待機時間のリクエストによる高い負荷によって、キャッシュ・サーバーが、転送またはバックアップする必要があるパーティションへの排他アクセスを妨げたり、大幅に遅延させる可能性がある場合に使用します。

カスタム・フェイルオーバー・アクセス・ポリシーを有効化するには、フェイルオーバー・アクセス・ポリシー(com.tangosol.net.partition.FailoverAccessPolicy)の完全修飾名を含む<class-name>要素を<partition-quorum-policy-scheme>要素内に追加します。このポリシーが受け入れるパラメータは次のとおりです。

cThresholdMillis - 危険な状態になった後にポリシーによってリクエストの保留が開始されるまでの遅延を指定します。デフォルト値は5000ミリ秒です。
cLimitMillis - 危険な状態になった後にポリシーによってリクエストを保留するための最大限の取組みが行われるまでの遅延を指定します。デフォルト値は、60000ミリ秒です。
cMaxDelayMillis - リクエストを保留する時間の最大の長さを指定します。デフォルト値は5000ミリ秒です。

次の例では、カスタム・フェイルオーバー・アクセス・ポリシーを有効化し、各パラメータを設定します。

<distributed-scheme>
   <scheme-name>partitioned-cache-with-quorum</scheme-name>
   <service-name>PartitionedCacheWithQuorum</service-name>
   <backing-map-scheme>
     <local-scheme/>
   </backing-map-scheme>
   <partitioned-quorum-policy-scheme>
      <class-name>com.tangosol.net.partition.FailoverAccessPolicy/class-name>
      <init-params>
         <init-param>
            <param-name>cThresholdMillis</param-name>
            <param-value>7000</param-value>
         </init-param>
         <init-param>
            <param-name>cLimitMillis</param-name>
            <param-value>30000</param-value>
         </init-param>
         <init-param>
            <param-name>cMaxDelayMillis</param-name>
            <param-value>2000</param-value>
         </init-param>
      </init-params>
   </partitioned-quorum-policy-scheme>
   <autostart>true</autostart>
</distributed-scheme>