プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Coherenceでのアプリケーションの開発
12c (12.2.1.1)
E77322-02
目次へ移動
目次

前
次

6 クラスタの設定

この章では、Coherenceクラスタのセットアップおよび構成方法と、デフォルトの即時利用可能なクラスタ設定を変更する方法について説明します。

この章の内容は次のとおりです。

6.1 クラスタの設定の概要

Coherenceには、デフォルトで、デモの目的で即時利用できるクラスタ構成が用意されています。これを使用すると、クラスタを容易に作成でき、ほとんどの場合、構成を変更する必要はなく、あるとしてもわずかです。一方、テストとデモを目的としていない場合は、デフォルトの設定を使用しないことをお薦めします。その場合は、クラスタを実行するネットワーク環境とクラスタを使用するアプリケーションの要件に基づいて、独自のクラスタを設定します。ユニットのテストおよび基本的な開発で使用するのであれば、単一サーバー・モードで動作するクラスタを構成してもかまいません。

クラスタの設定には、クラスタの名前の定義が含まれます。マルチキャストが望ましくない環境や使用できない環境では、Well Knownアドレス(WKA)機能の設定が必要になります。以降のこの章で説明するタスクは、クラスタを設定する場合に使用するものであり、デフォルトの設定を変更する必要がある場合には、このすべてのタスクを実行する必要があります。

クラスタは、オペレーション・オーバーライド・ファイル(tangosol-coherence-override.xml)の中で設定します。各クラスタ・メンバーはオーバーライド・ファイルを使用して、オペレーション・デプロイメント・ディスクリプタで定義されているデフォルトの構成をオーバーライドする固有の値を指定します。オペレーション・オーバーライド・ファイルの使用方法の詳細は、オペレーション構成ファイルの指定を参照してください。また、この章で取り上げているすべてのオペレーション要素の説明と使用方法は、オペレーション構成要素を参照してください。

6.2 クラスタの名前の指定

クラスタ名は、ネットワークの中で各クラスタを一意に識別するユーザー定義の名前です。複数のクラスタ・メンバーが参加してクラスタを構成するには、同じクラスタ名を指定する必要があります。既存のクラスタにクラスタ・メンバーとして参加するときに、誤ったクラスタ名を指定すると、そのクラスタ・メンバーは起動できません。

注意:

名前が明示的に指定されていない場合、クラスタ名はオペレーティング・システムのユーザー名に基づいて自動的に生成されます。推奨されるベスト・プラクティスは、システムで生成されたクラスタ名を使用しないことです。

クラスタ名を指定するには、オペレーション・オーバーライド・ファイルを編集して、クラスタ名を記述した<cluster-name>要素を<member-identity>要素に追加します。次に例を示します。

<?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>
      <member-identity>
         <cluster-name system-property="coherence.cluster">MyCluster
         </cluster-name>
      </member-identity>
   </cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.clusterシステム・プロパティを使用してクラスタ名を指定できます。次に例を示します。

-Dcoherence.cluster=name

6.3 クラスタ・メンバーの識別情報の指定

クラスタの中でクラスタ・メンバーに識別情報を指定するには、一連の識別子を使用します。この識別情報を使用して、クラスタの中でクラスタ・メンバーを区別し、メンバーのロールを扱います。一部のIDは、クラスタ・タスクの実行時にクラスタ・サービスによっても使用されます。最後に、管理情報(JMXなど)を表示する際は、ID情報が役に立ちます。また、ID情報により、ログ・エントリの解釈が容易になります。次に各識別子を示します。

  • サイト名 - クラスタ・メンバーをホストする地理的なサイトの名前。名前が指定されない場合、サーバーのドメイン名が使用されます。WANクラスタリングの場合、この値は、メンバーが存在するデータセンターを識別します。サイト名は、高度なルーティング、ロード・バランシングおよび障害時リカバリ計画(地理的に別のサイトにあるデータの明示的なバックアップ)の基盤として使用できます。サイト名は、分散キャッシングおよびデフォルト・パーティション割当て戦略を使用している場合にデータのバックアップ先を決定するために役立ちます。最後に、この名前は、管理情報(例、JMX)の表示およびログ・エントリの解釈にも有用です。

  • ラック名 - メンバーがホストされている地理的サイト内の場所の名前。多くの場合、ケージ、ラックまたはブレードフレームの識別子です。ラック名は、高度なルーティング、ロード・バランシングおよび障害時リカバリ計画(別のブレードフレームにあるデータの明示的なバックアップ)の基盤として使用できます。ラック名は、分散キャッシングおよびデフォルト・パーティション割当て戦略を使用している場合にデータのバックアップ先を決定するために役立ちます。最後に、この名前は、管理情報(例、JMX)の表示およびログ・エントリの解釈にも有用です。

  • マシン名 - クラスタ・メンバーをホストするサーバーの名前。名前の指定がない場合は、サーバーのホスト名が使用されます。この名前は、IDを作成する際の基礎として使用されます。クラスタ・サービスでは、データが別のコンピュータにバックアップされていることをこのIDを使用して確認し、単一障害点の発生を防止します。

  • プロセス名 - クラスタ・メンバーをホストするJVMプロセスの名前。名前の指定がない場合は、JVMプロセス番号が使用されます。プロセス名を使用すると、同じコンピュータで稼動している複数のJVMを容易に区別できます。

  • メンバー名 - クラスタ・メンバーの一意な名前。この名前を使用すると、特に同じコンピュータや同じJVMで稼動している複数のクラスタ・メンバーを容易に区別できます。メンバー名の指定が必要ない場合でも、(ベスト・プラクティスとして)必ずメンバー名を指定することをお薦めします。

  • ロール名 - クラスタでクラスタ・メンバーが持っているロール。ロール名を使用すると、クラスタ・メンバーをキャッシュ・サーバーやキャッシュ・クライアントなどの専門のロールにアプリケーションで整理できます。名前の指定がない場合は、デフォルトのロール名(キャッシュ・サーバーの場合はCoherenceServer、キャッシュ・クライアントの場合はapplication_class_name)が使用されます。

メンバーの識別情報を指定するには、オペレーション・オーバーライド・ファイルを編集して、次に示すように<member-identity>要素にメンバーの識別情報要素を追加します。

<?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>
      <member-identity>
         <site-name system-property="coherence.site">pa-1</site-name>
         <rack-name system-property="coherence.rack">100A</rack-name>
         <machine-name system-property="coherence.machine">prod001
         </machine-name>
         <process-name system-property="coherence.process">JVM1
         </process-name>
         <member-name system-property="coherence.member">C1</member-name>
         <role-name system-property="coherence.role">Server</role-name>
      </member-identity>
   </cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、次のシステム・プロパティを使用してクラスタ・メンバーの識別情報を指定できます。

-Dcoherence.site=pa-1
-Dcoherence.rack=100A
-Dcoherence.machine=prod001
-Dcoherence.process=JVM1
-Dcoherence.member=C1
-Dcoherence.role=Server

6.4 マルチキャスト通信の構成

マルチキャスト通信は、<multicast-listener>ノードのオペレーション・オーバーライド・ファイルの中で構成します。クラスタ・メンバーを起動するときにマルチキャスト通信を構成するためのシステム・プロパティも多数用意されています。

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

6.4.1 クラスタのマルチキャスト・アドレスおよびポートの指定

クラスタ・メンバーにはマルチキャスト・アドレスとポートを指定できます。複数のクラスタ・メンバーが参加してクラスタを構成するには、それぞれが同じマルチキャスト・アドレスとポートを使用する必要があります。デフォルトのマルチキャスト・アドレスは239.192.0.0です。デフォルトのクラスタ・ポートは7574です。

注意:

  • マルチキャスト・クラスタ・アドレスとポートは、複数のCoherenceクラスタによって安全に共有できます。ただし、SSLを使用するように構成されたクラスタでは、マルチキャスト・アドレスとポートを共有できません。さらに、同じIPプロトコル(たとえば、IPv6またはIPv4のいずれか)を使用するように、すべてのクラスタを構成する必要があります。

  • クラスタ・ポートは、マルチキャストではなく、Well Knownアドレス(WKA)を使用するように構成されているクラスタによっても使用されます。WKA使用の詳細は、Well Knownアドレスの使用を参照してください。

Coherenceのデフォルトのクラスタ・ポートは、Internet Assigned Numbers Authority (IANA)に登録されており、ほとんどのクラスタで、ポートを変更する必要はありません。異なるポートが必要な場合、推奨されるベスト・プラクティスは、1024から8999の間の値を選択することです。これらの値は、一般にほとんどのオペレーティング・システムのエフェメラル・ポートの範囲外になります。エフェメラル・ポートは、他のプロセスにランダムに割り当てることができるため、Coherenceがポートにバインドできなくなり、起動が失敗します。選択したポートがエフェメラル・ポートの範囲内にないことを確認するには、オペレーティング・システムのドキュメントを参照してください。

クラスタのマルチキャスト・アドレスとポートを指定するには、オペレーション・オーバーライド・ファイルを編集して、<address>要素と<port>要素の両方を追加し、クラスタ・メンバーが使用するアドレスとポートを指定します。次に例を示します。

<?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>
      <multicast-listener>
         <address system-property="coherence.clusteraddress">224.7.2.9
         </address>
         <port system-property="coherence.clusterport">3206</port>
      </multicast-listener>
   </cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、システム・プロパティであるcoherence.clusteraddresscoherence.clusterportを使用して、クラスタのマルチキャスト・アドレスを指定できます。次に例を示します。

-Dcoherence.clusteraddress=224.7.2.9
-Dcoherence.clusterport=3206

6.4.1.1 マルチキャスト・ソケット・インタフェースの変更

マルチキャスト・ソケットは、ユニキャスト・リスナーと同じIPアドレスのネットワーク・インタフェース(NIC)にバインドされます。異なるNICをマルチキャストに使用すると、クラスタの部分的な障害を引き起こす可能性があり、障害検出とフェイルオーバーに時間がかかることから、ベスト・プラクティスではなく強くお薦めできません。

デフォルトのマルチキャスト・ネットワーク・インタフェースを変更するには、オペレーション・オーバーライド・ファイルを編集して、マルチキャスト・ソケットのバインド先とするIPアドレスを指定した<interface>要素を追加します。次に例を示します。

<?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>
      <multicast-listener>
         <interface>192.168.0.1</interface>
      </multicast-listener>
   </cluster-config>
</coherence>

6.4.2 マルチキャスト通信の無効化

ネットワーク環境によっては、マルチキャスト・トラフィックが望ましくない場合や許可されない場合があり得ます。その場合はWell Knownアドレス機能を使用して、Coherenceでマルチキャストが使用されないようにします。これにより、マルチキャスト検出が無効になり、ユニキャスト(ポイント・ツー・ポイント)がかわりに使用されます。Coherenceは、マルチキャストが有効な場合は可能なかぎりポイントツーポイント通信を使用するように設計されているため、大半のアプリケーション・プロファイルでは、パフォーマンスに対する実質的な影響はありません。Well Knownアドレスの使用を参照してください。

注意:

マルチキャストを無効にすると、ネットワークに対する負荷が大きくなります。しかし、これが問題になるのは、メンバー数が100を超える大規模なクラスタのみです。

6.4.3 マルチキャストの有効時間の指定

存続時間(TTL)値の設定は、マルチキャスト・パケットがネットワーク上を移動できる範囲を指定します。TTLは、パケットが存続するホップ数で表されます。各ネットワーク・インタフェース、ルーターおよびマネージド・スイッチが1ホップと見なされます。

TTL値には、機能するうえで必要な最小の整数値を指定します。過剰に大きい値を設定すると、他のLANセグメントに不必要に大きい帯域幅が使用される可能性があり、オペレーティング・システムやネットワーク・デバイスでマルチキャスト・トラフィックが無効になることさえあります。一般的に、シンプルなスイッチ構成のバックボーンでは、TTL値を1に設定すれば問題ありません。インテリジェントなスイッチを備えた高度なバックボーンでは、2以上の値が必要になることがあります。値0は、開発やテストに使用するシングル・サーバー・クラスタで使用します。シングル・サーバー・クラスタの詳細は、単一サーバー・モードの有効化を参照してください。

TTLを指定するには、オペレーション・オーバーライド・ファイルを編集して、TTL値を指定した<time-to-live>要素を追加します。次に例を示します。

<?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>
      <multicast-listener>
         <time-to-live system-property="coherence.ttl">3</time-to-live>
      </multicast-listener>
   </cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.ttlシステム・プロパティを使用してTTL値を指定できます。次に例を示します。

-Dcoherence.ttl=3

6.4.4 マルチキャストの参加タイムアウトの指定

マルチキャストの参加タイムアウトは、クラスタへの参加をクラスタ・メンバーが待機する時間を定義します。このタイムアウトが経過しても既存のクラスタが検出されない場合、そのクラスタ・メンバーは独自にクラスタを起動し、自身がそのクラスタの上位クラスタ・メンバーになります。開発やテストでは、短いタイムアウトを指定してもかまいません。本番環境では一般的に30秒のタイムアウトで十分です。

注意:

クラスタの最初のメンバーは、参加タイムアウトの全期間を待機してから、上位メンバーのロールが必要であると見なします。クラスタの起動タイムアウトが参加タイムアウトよりも短いと、クラスタが起動している間にそのクラスタの最初のメンバーは動作を停止します。クラスタ・メンバーのタイムアウトは、パケット・パブリッシャのタイムアウトを使用して指定します(<timeout-milliseconds>)。packet-deliveryを参照してください。

参加タイムアウトを指定するには、オペレーション・オーバーライド・ファイルを編集して、タイムアウト値を指定した<join-timeout-milliseconds>要素を追加します。次に例を示します。

<?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>
      <multicast-listener>
         <join-timeout-milliseconds>6000</join-timeout-milliseconds>
      </multicast-listener>
   </cluster-config>
</coherence>

注意:

<join-timeout-milliseconds>の設定は、マルチキャスト通信およびユニキャスト通信の両方で使用されます。

6.4.5 マルチキャストのしきい値の変更

クラスタ・メンバーは、クラスタのパケットの送信でマルチキャスト通信とユニキャスト通信の両方を使用します。マルチキャストのしきい値を使用して、パケットの配信にマルチキャストを使用するかユニキャストを使用するかを判断します。このしきい値に大きい値または小さい値を設定することで、クラスタではどちらか一方の通信スタイルが頻繁に使用されるようになります。マルチキャスト通信を無効にすると、このしきい値設定は使用されません。

マルチキャストのしきい値は、1 - 100%の範囲の比率で指定します。n個のメンバーで構成するクラスタでは、d個(範囲は0 - n-1)のノードにパケットを送信するクラスタ・メンバー(dにこのクラスタ自身は算入しません)は、次の条件が成立する場合にのみ、マルチキャストを使用してパケットを送信します。

  • ネットワークを介して複数のノード(d > 1)にパケットを送信する。

  • そのノードの数が、指定のしきい値よりも大きい(d > (n-1) * (しきい値/100))。

    たとえば、マルチキャストのしきい値が25%でメンバーが25個のクラスタの場合、そのクラスタ・メンバーではパケットの送信先メンバーが6個以上の場合にのみ、マルチキャストを使用します(24 * .25 = 6)。

この値を1に設定すると、クラスタでは基本的にすべてのマルチポイントトラフィックにマルチキャストを使用できます。この値を100に設定すると、クラスタでは、明示的なブロードキャスト・トラフィック(クラスタのハートビートやクラスタの検出など)を除いてすべてのマルチポイント・トラフィックにユニキャストが使用されます。これは、100%のしきい値を超過することはあり得ないからです。25 (デフォルト値)に設定すると、パケットの送信先が全ノードの1/4未満であれば、クラスタ・メンバーは送信にユニキャストを使用します。パケットの送信先が全ノードの1/4以上であれば、マルチキャストを使用して送信します。

マルチキャストのしきい値を指定するには、オペレーション・オーバーライド・ファイルを編集して、しきい値を指定した<multicast-threshold-percent>要素を追加します。次に例を示します。

<?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>
      <multicast-listener>
         <multicast-threshold-percent>40</multicast-threshold-percent>
      </multicast-listener>
   </cluster-config>
</coherence>

6.5 クラスタ・メンバーのユニキャスト・アドレスの指定

ユニキャスト通信は、<unicast-listener>ノード内のオペレーション・オーバーライド・ファイルに構成されます。クラスタ・メンバーを起動するときにユニキャスト通信を構成するためのシステム・プロパティも用意されています。

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

6.5.1 デフォルトのユニキャスト・アドレスの変更

クラスタ・メンバーは、java.net.InetAddress.getLocalHost()のコールを使用してバインド先のIPアドレスを取得しようとします。複数のIPまたはNICを持つコンピュータでは、Coherenceは最も高いMTUのルーティング可能なIPを自動的に選択します。WKAが構成されている場合、Coherenceは、WKAリストのIPにルーティング可能なIPを選択します。選択したNICを使用しない場合、デフォルトをオーバーライドするには手動構成が必要です。

注意:

マルチキャスト・ソケットは、ユニキャスト・アドレスで定義したものと同じインタフェースにバインドします。マルチキャスト・ソケット・インタフェースの変更を参照してください。

ユニキャスト・アドレスは、正確なIPアドレスを指定するかわりに、バインド先のローカルIPアドレスのサブネットおよびマスク・パターンを使用する、クラスレス・ドメイン間ルーティング(CIDR)表記法を使用して入力できます。CIDRでは、同じサブネット上の複数のコンピュータで1つのアドレス構成を共有できるため、構成が単純になります。各クラスタ・メンバーで同じCIDRアドレス・ブロックを指定すると、各コンピュータのローカルNICでは、自動的にアドレス・パターンの一致が検出されます。たとえば、同じネットワーク上に配置されており、それらの192.168.1.*アドレス上でクラスタを実行する複数のマルチNICコンピュータのユニキャスト・アドレスを指定するには、192.168.1.0/24などのアドレスを指定します。すると、各ノードが、そのパターンに一致するローカルNICを検出します。/24接頭辞サイズは、192.168.1.0から192.168.1.255までの最大256個の使用可能アドレスに一致します。

クラスタ・メンバーのユニキャスト・アドレスを指定するには、オペレーション・オーバーライド・ファイルを編集して、ユニキャスト・アドレスを含む<address>要素を追加します。次に例を示します。

<cluster-config>
   <unicast-listener>
      <address system-property="coherence.localhost">192.168.1.0/24
      </address>
   </unicast-listener>
</cluster-config>

オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.localhostシステム・プロパティを使用してユニキャスト・アドレスを指定できます。次に例を示します。

-Dcoherence.localhost=192.168.1.0/24

6.5.2 デフォルトのユニキャスト・ポートの変更

クラスタ・メンバーのユニキャスト・ポートは、オペレーティング・システムの使用可能なエフェメラル・ポートの範囲から自動的に割り当てられます。これにより、Coherenceと他のアプリケーションの間でポートの競合が誤って発生することがなくなります。ただし、クラスタ・メンバー間でファイアウォールが必要な場合は(特殊な構成)は、ポートを手動で構成する必要があります。ファイアウォール・ポートの要件の詳細は、クラスタ・メンバーのファイアウォールの構成を参照してください。

クラスタ・メンバーでは、2つのユニキャスト・ポートが必要です。2つのポートを使用する理由は次のとおりです。

  • インバウンド・トラフィックとアウトバウンド・トラフィック間の競合を削減し、両方での大量の転送を回避して、同じポートで受信する。

  • コヒーレンスなメンバー間では、オペレーティング・システムのMTU (Maximum Transmission Unit)に基づく最適なパケット・サイズでの通信が可能になる。サイズが大きなパケットに一方のポートを使用し、サイズがネットワークのMTU以下であるパケットにもう一方のポートを使用します。この分離によって、サイズに基づいて別個のパケット・バッファを使用できます。

  • ソケット・バッファの表面的なサイズを増やさずに、メンバー数が500を超える大規模なクラスタを実行できる。

ユニキャスト・ポートを手動で構成する場合は、単一のポートが指定され、2番目のポートが自動的に選択されます。いずれかのポートが使用できない場合、デフォルトの動作では、使用可能な次のポートを選択します。たとえば、ポート9000が最初のポート(port1)に構成されており、使用不可の場合、使用可能な次のポートが自動的選択されます。2番目のポート(port2)が自動的に開き、デフォルトでport1の次に使用可能なポート(使用可能であれば、port1 + 1)として設定されます。自動ポート調整を無効にできますが、この場合は、port1を使用可能にする必要があり、2番目のポートは常にport1 + 1になります。自動ポート調整は、ポート範囲の上限を指定する場合に使用することもできます。

クラスタ・メンバーのユニキャスト・ポートを指定するには、オペレーション・オーバーライド・ファイルを編集して、ポート値を含む<port>要素を追加します。次に例を示します。

<cluster-config>
   <unicast-listener>
      <port system-property="coherence.localport">9000</port>
   </unicast-listener>
</cluster-config>

自動ポート調整を無効にするには、値falseを含む<port-auto-adjust>要素を追加します。または、ポートが選択されるポートの範囲を指定するには、ポート範囲の上限を表すポート値を含めます。次の例では、9000から9200のポート範囲を設定します。

<cluster-config>
   <unicast-listener>
      <port system-property="coherence.localport">9000</port>
      <port-auto-adjust system-property="coherence.localport.adjust">9200
      </port-auto-adjust>
   </unicast-listener>
</cluster-config>

オペレーション・オーバーライド・ファイルを使用するかわりに、システム・プロパティであるcoherence.localhostcoherence.localportおよびcoherence.localport.adjustを使用して、ユニキャスト・ポートと自動ポート調整の設定を指定できます。次に例を示します。

-Dcoherence.localport=9000 -Dcoherence.localport.adjust=9200

6.6 Well Knownアドレスの使用

Well Knownアドレス(WKA)機能は、クラスタ・メンバーがマルチキャストのかわりにユニキャストを使用してクラスタを検出し、それに参加できるようにするメカニズムです。マルチキャスト・ネットワーキングが望ましくないか使用できない環境やマルチキャストを適切にサポートするように構成されていない環境でWKAを使用することが普通です。WKAを有効にすると、すべてのクラスタでマルチキャスト通信が無効になります。

クラスタを起動できるクラスタ・メンバー・アドレスの小さいサブセットを指定することでWKAが有効になります。WKAアドレスの最適な数はクラスタのサイズで異なります。一般的に、WKAアドレスはクラスタの10%未満になるようにしてください。スイッチごとのWKAアドレスを1つか2つにすることをお薦めします。

各WKAアドレスは、クラスタの稼働中は利用可能な状態を維持している必要がありますが、どの時点でも同時にアクティブになっている必要はありません。クラスタ・メンバーがクラスタを検出してそこに参加するためには、WKAアドレスが1つのみ稼働可能になっている必要があります。さらに、クラスタに参加したクラスタ・メンバーは、すべてのクラスタ・メンバーのアドレスの通知を受け、各クラスタ・メンバーに個別にメッセージを送信することでブロードキャストを実行します。これにより、すべてのWKAアドレスが動作を停止しても、クラスタは稼働できます。ただし、クラスタ・メンバー自身がWKAアドレス上にホストされるか、WKAアドレス上のクラスタ・メンバーが起動されないかぎり、このクラスタに新しいクラスタ・メンバーは参加できません。この場合は、クラスタの最上位メンバーがWKAアドレスのリストをポーリングし、そのWKAアドレスが既存のクラスタに再度参加できるようにします。

WKAアドレスを指定する方法は2つあります。まず、WKAアドレスのリストを指定する方法があります。もう1つは、アドレス・プロバイダの実装を使用してWKAアドレスのリストを取得する方法です。どちらの方法も、オペレーション・オーバーライド・ファイルの中で<unicast-listener>要素の<well-known-addresses>サブ要素で構成します。

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

6.6.1 WKAアドレスの指定

WKAアドレス(IPアドレスまたはDNS名)は、<address>要素を使用して指定されます。任意の数のWKAアドレスを指定できますが、一意のid属性をアドレスごとに含める必要があります。様々なクラスタ・メンバーが他のクラスタ・メンバーとは無関係に稼働することがないように、すべてのクラスタ・メンバーに対してWKAアドレスのリストは同一であることが必要です。独自のアドレスを指定したクラスタ・メンバーがあれば、クラスタを起動できます。

注意:

WKAはクラスタ・ポートを使用します。クラスタ・ポートの詳細は、クラスタのマルチキャスト・アドレスおよびポートの指定を参照してください。

次の例では2つのWKAアドレスを指定しています。

<?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>
      <unicast-listener>
         <well-known-addresses>
            <address id="1">Server1</address>
            <address id="2">Server2</address>
         </well-known-addresses>
      </unicast-listener>
   </cluster-config>
</coherence>

IPアドレスまたはDNS名のいずれかを使用できる場合、DNS名には、DNS名に関連付けられているIPアドレスが実行時に自動的に解決されるというメリットもあります。これにより、WKAアドレスのリストをDNSサーバーに格納できるため、WKAアドレスをリアルタイムで一元的に管理および更新できます。たとえば、cluster1という名前のクラスタのWKAアドレス・リストが192.168.1.1192.168.1.2192.168.1.3になる場合、これらのアドレスをホスト名cluster1の単独のDNSエントリに含め、cluster1という名前の単独のアドレスをWKAアドレスに指定できます。

<?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>
      <unicast-listener>
         <well-known-addresses>
            <address>cluster1</address>
         </well-known-addresses>
      </unicast-listener>
   </cluster-config>
</coherence>

WKAシステム・プロパティの使用

オペレーション・オーバーライド・ファイルでアドレスを指定するかわりに、coherence.wkaシステム・プロパティを使用して単独のWKAアドレスを指定できます。これらのシステム・プロパティは、デモやテストのシナリオで単独のWKAアドレスを簡単に指定できるようにすることを目的としたものです。次に例を示します。

-Dcoherence.wka=192.168.0.100

複数のWKAアドレスを指定するシステム・プロパティを別途作成するには、オペレーション・オーバーライド・ファイルを使用して複数のWKAアドレスを定義し、WKAアドレス要素ごとにsystem-property属性を定義する必要があります。この属性には、目的の要素をオーバーライドするために使用するシステム・プロパティ名を指定する必要があります。次の例では、システム・プロパティを指定した2つのアドレスを定義しています。

注意:

WKAアドレスのリストを指定する追加のシステム・プロパティは、テストの際または管理された本番環境で定義できます。ただし、ベスト・プラクティスは、オペレーション・オーバーライド・ファイルを重点的に使用して本番環境でWKAアドレスを指定することです。これにより、各クラスタ・メンバーに対して同じWKAアドレスのリストが存在するようになります。

<?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>
      <unicast-listener>
         <well-known-addresses>
            <address id="1" system-property="coherence.wka"></address>
            <address id="2" system-property="coherence.wka2"></address>
         </well-known-addresses>
      </unicast-listener>
   </cluster-config>
</coherence>

前述の例では、次のようにシステム・プロパティを使用してWKAアドレスを指定しています。

-Dcoherence.wka=192.168.0.102 -Dcoherence.wka2=192.168.0.103

システム・プロパティの定義の詳細は、カスタム・システム・プロパティの作成を参照してください。

6.6.2 WKAアドレス・プロバイダの指定

WKAアドレス・プロバイダは、プログラムでWKAアドレスを定義する方法を実現します。WKAアドレス・プロバイダはcom.tangosol.net.AddressProviderインタフェースを実装する必要があります。静的リストのような簡素な実装から、動的な検出プロトコルを使用するような複雑な実装まで可能です。このアドレス・プロバイダは、存在するすべてのアドレスを返したことを示す終端NULLアドレスを返す必要があります。クラスタ・メンバーが起動するときに、このアドレス・プロバイダ実装がコールされます。

注意:

返された例外や処理されない例外によって遅延が発生すると、検出の遅延の原因となり、その結果、メンバーに対するクラスタ・サービスが全面的にシャットダウンすることがあります。したがって、実装では細心の注意が必要です。負荷の大きい操作(ネットワーク・フェッチなど)が関わる実装では、com.tangosol.net.RefreshableAddressProviderクラスを拡張することによって、そのような操作を非同期で処理できます。

WKAアドレス・プロバイダの実装を使用するには、<address-provider>要素を追加し、<class-name>要素の中で実装クラスの完全修飾名を指定します。次に例を示します。

<?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>
      <unicast-listener>
         <well-known-addresses>
            <address-provider>
               <class-name>package.MyAddressProvider</class-name>
            </address-provider>
         </well-known-addresses>
      </unicast-listener>
   </cluster-config>
</coherence>

<address-provider>要素で<class-factory-name>要素および<method-name>要素を使用することもできます。前者の要素は、AddressProviderインスタンスを作成するためのファクトリ・クラスを指定します。後者の要素は、オブジェクトをインスタンス化するファクトリ・クラスに対して静的ファクトリ・メソッドを指定します。次の例では、MyAddressProviderFactoryクラスでgetAddressProviderメソッドを使用してアドレス・プロバイダのインスタンスを取得します。

<?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>
      <unicast-listener>
         <well-known-addresses>
            <address-provider>
               <class-factory-name>package.MyAddressProviderFactory
               </class-factory-name>
               <method-name>getAddressProvider</method-name>
            </address-provider>
         </well-known-addresses>
      </unicast-listener>
   </cluster-config>
</coherence>

クラスやクラス・ファクトリの実装に必要な初期化パラメータはすべて、<init-params>要素を指定して指定できます。初期化パラメータには、一致するシグネチャを持つパブリック・コンストラクタが含まれる実装によってアクセスできます。次の例では、iMaxTimeパラメータが2000に設定されます。

<?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>
      <unicast-listener>
         <well-known-addresses>
            <address-provider>
               <class-name>package.MyAddressProvider</class-name>
               <init-params>
                  <init-param>
                     <param-name>iMaxTime</param-name>
                     <param-value>2000</param-value>
                  </init-param>
               </init-params>
            </address-provider>
         </well-known-addresses>
      </unicast-listener>
   </cluster-config>
</coherence>

6.7 単一サーバー・モードの有効化

単一サーバー・モードは、1台のコンピュータ上でのみ実行するように制限され、ネットワークにはアクセスしないクラスタです。単一サーバー・モードは開発やユニット・テストでクラスタを容易に起動および停止できます。

単一サーバー・モードを有効にするには、オペレーション・オーバーライド・ファイルを編集して、ループバックにルーティングするアドレスに設定したユニキャスト<address>要素を追加します。ほとんどのコンピュータで、アドレスを127.0.0.1に設定すれば問題ありません。次に例を示します。

<?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>
      <unicast-listener>
         <address system-property="coherence.localhost">127.0.0.1
         </address>
      </unicast-listener>
   </cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.localhostシステム・プロパティを使用して単一サーバー・モードを有効化できます。次に例を示します。

-Dcoherence.localhost=127.0.0.1

6.8 停止検出の構成

停止検出は、クラスタ・メンバーに発生した障害を迅速に検出するためのクラスタ・メカニズムです。障害が発生したクラスタ・メンバーはクラスタから除外され、他のすべてのクラスタ・メンバーには離脱したメンバーについての通知が送信されます。検出停止を使用することで、実際に障害が発生したメンバーと応答しなくなっているメンバーとを区別できます。たとえば、JVMが完全なガベージ・コレクションを実行しているときは、メンバーが応答しなくなります。

停止検出は、プロセス障害(TcpRingコンポーネント)とハードウェア障害(IpMonitorコンポーネント)の両方を特定します。プロセス障害は、クラスタ通信に使用されるものと同じポートで開いているTCP接続のリングを使用して検出されます。各クラスタ・メンバーはユニキャストのハートビートを発行し、最も上位のクラスタ・メンバーは、ブロードキャスト・メッセージとなるクラスタ・ハートビートを発行します。ハードウェア障害は、トレースICMP Pingまたは疑似Pingを発行してTCPポート7を使用するJava InetAddress.isReachableメソッドを使用して検出します。停止検出はデフォルトで有効になっていますが、<tcp-ring-listener>要素で構成できます。

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

6.8.1 TCP-Ring設定の変更

TCPリング・リスナーのデフォルトの動作を変更するために使用する設定がいくつかあります。これには、クラスタ・メンバーをホストしているコンピュータが到達不可能になっていると判断するまでの試行回数と時間の変更などがあります。これらのデフォルトの設定はそれぞれ3回と15秒です。TCP/IPソケットのバックログ・キューも設定可能で、デフォルトではオペレーティング・システムで使用する値が設定されています。

TCPリング設定を変更するには、オペレーション・オーバーライド・ファイルを編集して、次のTCPリング要素を追加します。

注意:

<ip-timeout>および<ip-attempts>の要素の値は、許容できる一時的なネットワークの停止に影響を与えないだけの大きな値にする必要があります。

<?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>
      <tcp-ring-listener>
         <ip-timeout system-property="coherence.ipmonitor.pingtimeout">
            25s</ip-timeout>
         <ip-attempts>5</ip-attempts>
         <listen-backlog>10</listen-backlog>
      </tcp-ring-listener>
   </cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.ipmonitor.pingtimeoutシステム・プロパティを使用してタイムアウトを指定できます。次に例を示します。

-Dcoherence.ipmonitor.pingtimeout=20s

6.8.2 ハートビート間隔の変更

停止検出のハートビート間隔を変更できます。この間隔を長くすると、最低限必要なネットワーク・トラフィックを小さく抑えることができますが、障害が発生したメンバーを検出できなくなることがあります。デフォルトのハートビート値は1秒です。

注意:

ハートビート設定とは、ハートビートの発行が必要かどうかを評価する頻度を技術的に制御するものです。指定した間隔の中で実際にハートビートが発行されるかどうかは、評価プロセスによって変化します。

停止検出のハートビート間隔を変更するには、オペレーション・オーバーライド・ファイルを編集して、ハートビート値を指定した<heartbeat-milliseconds>要素を追加します。次に例を示します。

<?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>
         <packet-delivery>
            <heartbeat-milliseconds>5000</heartbeat-milliseconds>
         </packet-delivery>
      </packet-publisher>
   </cluster-config>
</coherence>

6.8.3 停止検出の無効化

停止検出はデフォルトで有効になっているので、無効にするには明示的な指定が必要です。停止検出を無効にしても、最低限必要なネットワーク・トラフィックを小さく抑えることができるのみであり、その一方で障害が発生したメンバーを検出できなくなることがあります。無効にすると、クラスタ・メンバーはパケット・パブリッシャの再送信タイムアウト間隔を使用して、他のメンバーがパケットへの応答を停止していることを判断します。デフォルトでは、このタイムアウト間隔は5分に設定されています。詳細は、パケットの再送信タイムアウトの変更を参照してください。

注意:

パケット・パブリッシャの再送信タイムアウトを使用して、障害が発生したクラスタ・メンバーを検出する方法は、エラーが発生しやすく、ガベージ・コレクションの実行時間が長くなることから誤検出を招くことがあります。

停止検出を無効にするには、オペレーション・オーバーライド・ファイルを編集して、falseに設定した<enabled>要素を追加します。次に例を示します。

<?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>
      <tcp-ring-listener>
         <enabled>false</enabled>
      </tcp-ring-listener>
   </cluster-config>
</coherence>

6.9 クラスタの優先度の指定

クラスタの優先度のメカニズムを使用すると、クラスタ・メンバーおよびメンバーの中で実行している様々なスレッドに優先度の値を割り当てることができます。

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

6.9.1 クラスタ・メンバーの優先度の指定

クラスタ・メンバーの優先度は、同等の複数のメンバーに対する様々な処理の順番を指定するための基礎として使用します。2つのメンバーのどちらかをクラスタから除外することが必要になった場合に、そのどちらに障害が発生していて排除すべきかを客観的に判断できないまれな条件下では、優先度の低いメンバーが除外されます。

クラスタ・メンバーの優先度を指定するには、オペレーション・オーバーライド・ファイルを編集して、優先度を指定した<priority>要素を<member-identity>ノードに追加します。優先度は1から10の値で指定し、10を指定すると優先度が最も高くなります。次に例を示します。

<?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>
      <member-identity>
         <priority system-property="coherence.priority">1</priority>
      </member-identity>
   </cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.priorityシステム・プロパティを使用してクラスタ・メンバーの優先度を指定することもできます。次に例を示します。

-Dcoherence.priority=1

6.9.2 通信スレッドの優先度の指定

スレッドの優先度をサポートするクラスタ・コンポーネントがいくつかあります。この優先度は、Javaスレッドの実行の重要度を判断するための基礎として使用します。このコンポーネントとして、マルチキャスト・リスナー、ユニキャスト・リスナー、TCPリング・リスナー、パケット・スピーカー、パケット・パブリッシャおよび受信メッセージ・ハンドラがあります。デフォルトの優先度設定では、パケット・パブリッシャの優先度が最も高く、次の順位が受信メッセージ・ハンドラで、残りのコンポーネントがこれに続きます。

スレッドの優先度は、それぞれのコンポーネントの構成要素の中で指定します(それぞれ、<unicast-listener><multicast-listener><packet-speaker><packet-publisher><tcp-ring-listener>および<incoming-message-handler>の各要素)。たとえば、ユニキャスト・リスナーに対してスレッドの優先度を指定するには、オペレーション・オーバーライド・ファイルを編集して、優先度を指定した<priority>要素を<unicast-listener>ノードに追加します。優先度は1から10の値で指定し、10を指定すると優先度が最も高くなります。

<?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>
      <unicast-listener>
         <priority>5</priority>
      </unicast-listener>
   </cluster-config>
</coherence>

6.9.3 サービスに対するスレッドの優先度の指定

クラスタ・サービスではスレッドの優先度がサポートされています。この優先度は、Javaスレッドの実行の重要度を判断するための基礎として使用し、サービスのどのスレッドが重要とみなされているのかを示します。優先度を設定できるスレッドのタイプは、サービス・スレッド、イベント・ディスパッチャ・スレッドおよびワーカー・スレッドの3つです。デフォルトの設定では、サービス・スレッドとイベント・ディスパッチャ・スレッドにワーカー・スレッドよりも高い優先度が与えられています。

サービスのスレッド優先度は、オペレーション・オーバーライド・ファイルで <service>要素をオーバーライドすることで、クラスタ内のすべてのサービスに対して変更できます。ただし、より最適な方法は、キャッシュ・スキームを定義するときにキャッシュ構成ファイル内でサービス・インスタンスに対してスレッド優先度を構成することです。キャッシュの定義方法の詳細は、キャッシュ・スキームの定義を参照してください。<service-priority><event-dispatcher-priority>および<worker-priority>サブ要素をそれぞれ使用して、値を1から10の値で入力し、10を指定すると優先度が最も高くなります。次に例を示します。

...
<distributed-scheme>
   <scheme-name>distributed</scheme-name>
   <service-name>MyDistributedService</service-name>
   <service-priority>10</service-priority>
   <event-dispatcher-priority>10</event-dispatcher-priority>
   <worker-priority>5</worker-priority>
   ...
</distributed-scheme>
...

6.10 クラスタ・メンバーのファイアウォールの構成

ファイアウォールは、通常はクラスタ・メンバー間で設定されません。ソリューションでファイアウォールを使用する必要がある場合は、次を確認します。

  • マルチキャストとユニキャストの両方の構成のUDPとTCPの両方用に、クラスタ・ポート(デフォルトで7574)が開かれている。

  • Coherence TcpRing/IpMonitor停止検出機能用に、TCPポート7が開かれている。

  • UDPとTCPの両方のトラフィック用に、ユニキャスト・ポート範囲が開かれている。システムによって割り当てられているエフェメラル・ポートに依存するのではなく、ユニキャストのリスニング・ポート範囲が明示的に設定されていることを確認します。ユニキャスト・ポートの構成の詳細は、デフォルトのユニキャスト・ポートの変更を参照してください。