| Oracle® Fusion Middleware Oracle Coherenceでのアプリケーションの開発 12c (12.1.2) B70741-02 |
|
 前 |
 次 |
この章では、Coherenceクラスタのセットアップおよび構成方法と、デフォルトのそのままで使用できるクラスタ設定を変更する方法について説明します。
この章には次の項が含まれます:
Coherenceには、デフォルトのまま、デモの目的で使用できるクラスタ構成が用意されています。これを使用すると、クラスタを容易に作成でき、ほとんどの場合、構成を変更する必要はなく、あるとしてもわずかです。一方、デモを目的としていない場合は、デフォルトの設定を使用しないことをお薦めします。その場合は、クラスタを実行するネットワーク環境とクラスタを使用するアプリケーションの要件に基づいて、独自のクラスタを設定します。ユニットのテストおよび基本的な開発で使用するのであれば、単一サーバー・モードで動作するクラスタを構成してもかまいません。
クラスタの設定では、少なくともクラスタの名前およびクラスタのマルチキャスト・アドレスを定義する必要があります。マルチキャストが望ましくない環境や使用できない環境では、Well Knownアドレス(WKA)機能の設定が必要になります。以降のこの章で説明するタスクは、クラスタを設定する場合に使用するものであり、デフォルトの設定を変更する必要がある場合には、このすべてのタスクを実行する必要があります。
クラスタは、オペレーション・オーバーライド・ファイル(tangosol-coherence-override.xml)の中で設定します。各クラスタ・メンバーはオーバーライド・ファイルを使用して、オペレーション・デプロイメント・ディスクリプタで定義されているデフォルトの構成をオーバーライドする固有の値を指定します。オペレーション・オーバーライド・ファイルの使用方法の詳細は、「オペレーション構成ファイルの指定」を参照してください。また、この章で取り上げているすべてのオペレーション要素の説明と使用方法は、付録A「オペレーション構成要素」を参照してください。
クラスタ名は、ネットワークの中で各クラスタを一意に識別するユーザー定義の名前です。複数のクラスタ・メンバーが参加してクラスタを構成するには、同じクラスタ名を指定する必要があります。既存のクラスタにクラスタ・メンバーとして参加するときに、誤ったクラスタ名を指定すると、そのクラスタ・メンバーは起動できません。同じネットワークに複数の異なるクラスタを作成するには、一意のマルチキャスト・ポートを使用して、一意のクラスタ名を使用することが普通です。
|
注意: クラスタ名を明示的に指定していない場合、クラスタ・メンバーではシステムで生成されたクラスタ名が使用されます。システム生成の名前(および何も設定していない状態でのマルチキャストのデフォルト設定)を使用すると、ネットワーク上でクラスタ構成が重複する可能性が高くなります。その結果、予期しないクラスタにクラスタ・メンバーが誤って参加することがあります。 |
クラスタ名を指定するには、オペレーション・オーバーライド・ファイルを編集して、クラスタ名を記述した<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="tangosol.coherence.cluster">MyCluster
</cluster-name>
</member-identity>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.clusterシステム・プロパティを使用してクラスタ名を指定できます。例:
-Dtangosol.coherence.cluster=name
クラスタの中でクラスタ・メンバーに識別情報を指定するには、一連の識別子を使用します。この識別情報を使用して、クラスタの中でクラスタ・メンバーを区別し、メンバーのロールを扱います。クラスタのタスクを実行するときにクラスタ・サービスで使用する識別子もあります。最後に、この識別情報は管理情報(JMXなど)を表示する際に便利であり、識別情報を使用することでログのエントリの解釈も容易になります。次に各識別子を示します。
サイト名 - クラスタ・メンバーをホストする地理的なサイトの名前。名前の指定がない場合は、サーバーのドメイン名が使用されます。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="tangosol.coherence.site">pa-1</site-name>
<rack-name system-property="tangosol.coherence.rack">100A</rack-name>
<machine-name system-property="tangosol.coherence.machine">prod001
</machine-name>
<process-name system-property="tangosol.coherence.process">JVM1
</process-name>
<member-name system-property="tangosol.coherence.member">C1</member-name>
<role-name system-property="tangosol.coherence.role">Server</role-name>
</member-identity>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、次のシステム・プロパティを使用してクラスタ・メンバーの識別情報を指定できます。
-Dtangosol.coherence.site=pa-1 -Dtangosol.coherence.rack=100A -Dtangosol.coherence.machine=prod001 -Dtangosol.coherence.process=JVM1 -Dtangosol.coherence.member=C1 -Dtangosol.coherence.role=Server
クラスタ・メンバーは、他のクラスタ・メンバーを検出するときおよびクラスタに属する複数のメンバーにメッセージを伝達するときにマルチキャスト通信を使用します。マルチキャスト・ストームなどが発生しないように、マルチキャストはクラスタのプロトコルによってきわめて慎重に使用されます。デフォルトでは、全クラスタ・メンバーの25%を超えるメンバーにデータを転送する場合にのみ、マルチキャストが使用されます。マルチキャストが有効になっていても、トラフィックの大半はユニキャストを使用して転送されます。一般的なパーティション化したキャッシュを基本とするクラスタでは、ほとんどの転送はPoint-to-Pointであり、クラスタのメンバーシップとパーティションの所有権のみがクラスタ全体にブロードキャストされます。
マルチキャスト通信は、<multicast-listener>ノードのオペレーション・オーバーライド・ファイルの中で構成します。クラスタ・メンバーを起動するときにマルチキャスト通信を構成するためのシステム・プロパティも多数用意されています。
この項には次のトピックが含まれます:
クラスタ・メンバーにはマルチキャスト・アドレス(IPアドレスとポート)を指定できます。複数のクラスタ・メンバーが参加してクラスタを構成するには、それぞれが同じマルチキャスト・アドレスとポートを使用する必要があります。同じネットワーク上で互いに独立している複数のクラスタは、それぞれ異なるマルチキャスト・アドレスを使用する必要があります。
マルチキャスト・アドレスを明示的に指定していない場合、クラスタ・メンバーではデフォルトのマルチキャスト・アドレスが使用されます。このデフォルト値はリリース・バージョンによって異なり、アドレスは{build}.{major version}.{minor version}.{patch}、ポートは{major version}.{minor version}.{patch}という表記規則にそれぞれ従います。
|
注意: デフォルトのマルチキャスト・アドレスとポート(およびシステムで生成されたクラスタ名)を使用すると、ネットワーク上でクラスタ構成が重複する可能性が高くなります。その結果、予期しないクラスタにクラスタ・メンバーが誤って参加することがあります。必ず一意のポート値を使用して個々のクラスタを作成します。 |
クラスタのマルチキャスト・アドレスを指定するには、オペレーション・オーバーライド・ファイルを編集して<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="tangosol.coherence.clusteraddress">224.3.6.0
</address>
<port system-property="tangosol.coherence.clusterport">3059</port>
</multicast-listener>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、システム・プロパティであるtangosol.coherence.clusteraddressとtangosol.coherence.clusterportを使用してクラスタのマルチキャスト・アドレスを指定できます。例:
-Dtangosol.coherence.clusteraddress=224.3.6.0 -Dtangosol.coherence.clusterport=3059
マルチキャスト・ソケットは、ユニキャスト・リスナーと同じIPアドレスのネットワーク・インタフェース(NIC)にバインドされます。これと異なるNICをマルチキャストに構成することはできますが、クラスタの部分的な障害を引き起こす可能性があることから、ごくわずかな例外を除いてお薦めできません。
NICが2つある場合、マルチキャスト・トラフィックに使用するインタフェース(およびそれに伴うネットワーク)は、ユニキャスト(UDP/IP)トラフィックとTCPリング(TCP/IP)トラフィックに使用するインタフェース(およびそれに伴うネットワーク)とは別になります。このシナリオでは、一方のインタフェース(ネットワーク)に障害が発生しても、もう一方のインタフェースでは通信を正常に継続しているので、障害検出とフェイルオーバーが機能しません。クラスタ・プロトコルではメンバー(およびそれに付随するインタフェース)の障害を扱うので、障害が発生したメンバーを迅速に検出してクラスタから除外できるように、すべての通信が障害状態になるようにする方が有利です。
デフォルトのマルチキャスト・ネットワーク・インタフェースを変更するには、オペレーション・オーバーライド・ファイルを編集して、マルチキャスト・ソケットのバインド先とする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>
ネットワーク環境によっては、マルチキャスト・トラフィックが望ましくない場合や許可されない場合があり得ます。その場合はWell Knownアドレス機能を使用して、Coherenceでマルチキャストが使用されないようにします。これによってマルチキャスト検出が無効になり、同時にすべてのデータ転送に対してマルチキャストが無効になります。かわりにユニキャスト(Point-to-Point)が使用されます。Coherenceは可能なかぎりPoint-to-Point通信を使用するように設計されているため、大半のアプリケーション・プロファイルでは、パフォーマンスに対する実質的な影響はありません。「Well Knownアドレスの使用」を参照してください。
|
注意: マルチキャストを無効にすると、ネットワークに対する負荷が大きくなります。しかし、これが問題になるのは、メンバー数が100を超える大規模なクラスタのみです。 |
有効時間(TTL)値の設定は、ネットワーク上でマルチキャストのUDP/IPパケットを伝送できる最大距離を指定するものです。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="tangosol.coherence.ttl">3</time-to-live>
</multicast-listener>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.ttlシステム・プロパティを使用してTTL値を指定できます。例:
-Dtangosol.coherence.ttl=3
マルチキャストの参加タイムアウトは、クラスタへの参加をクラスタ・メンバーが待機する時間を定義します。このタイムアウトが経過しても既存のクラスタが検出されない場合、そのクラスタ・メンバーは独自にクラスタを起動し、自身がそのクラスタの上位クラスタ・メンバーになります。開発やテストでは、短いタイムアウトを指定してもかまいません。本番環境では一般的に30秒のタイムアウトで十分です。
|
注意: クラスタの最初のメンバーは、参加タイムアウトの全期間を待機してから、上位メンバーのロールが必要であると見なします。クラスタの起動タイムアウトが参加タイムアウトよりも短いと、クラスタが起動している間にそのクラスタの最初のメンバーは動作を停止します。クラスタ・メンバーのタイムアウトは、パケット・パブリッシャのタイムアウトを使用して指定します( |
参加タイムアウトを指定するには、オペレーション・オーバーライド・ファイルを編集して、タイムアウト値を指定した<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>
クラスタ・メンバーは、クラスタのパケットの送信でマルチキャスト通信とユニキャスト通信の両方を使用します。マルチキャストのしきい値を使用して、パケットの配信にマルチキャストを使用するかユニキャストを使用するかを判断します。このしきい値に大きい値または小さい値を設定することで、クラスタではどちらか一方の通信スタイルが頻繁に使用されるようになります。マルチキャスト通信を無効にすると、このしきい値設定は使用されません。
マルチキャストのしきい値は、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>
クラスタ・メンバーは、クラスタでの通信の大半を占めるメンバー間(Point-to-Point)の直接通信ではユニキャストを使用します。デフォルトのユニキャスト・アドレス(IPアドレスとポート)が使用されますが、必要に応じて<unicast-listener>要素で明示的なアドレスを指定することもできます。マルチキャスト・ソケットは、ユニキャスト・アドレスで定義したものと同じインタフェースにバインドします。「マルチキャスト・ソケット・インタフェースの変更」を参照してください。
ユニキャスト・リスナーは、次のように構成されます。
<address> - クラスタ・メンバーは、java.net.InetAddress.getLocalHost()のコールを使用してバインド先のIPアドレスを取得しようとします。localhostをループバック・アドレスとして定義しているシステムではlocalhostの使用が機能しないことがあります。その場合は、コンピュータ名または固有のIPアドレスを指定する必要があります。コンピュータに複数のIPまたはNICがある場合も、アドレスを明示的に指定する必要があります。
<address>要素では、Classless Inter-Domain Routing (CIDR)注釈がサポートされています。これは、正確なIPアドレスを指定するかわりに、バインドするローカルIPアドレスにサブネットおよびマスク・パターンを使用します。CIDRでは、同じサブネット上の複数のコンピュータで1つのアドレス構成を共有できるため、構成が単純になります。各クラスタ・メンバーは同じCIDRアドレス・ブロックを指定し、アドレス・パターンに一致する各コンピュータ上のローカルNICが自動的に検出されます。たとえば、同じネットワーク上に配置されており、それらの192.168.1.*アドレス上でクラスタを実行する複数のマルチNICコンピュータのユニキャスト・アドレスを指定するには、192.168.1.0/24などのアドレスを指定します。すると、各ノードが、そのパターンに一致するローカルNICを検出します。/24接頭辞サイズは、192.168.1.0から192.168.1.255までの最大256個の使用可能アドレスに一致します。
<port> - クラスタ・メンバーは2つのユニキャストUDPポートを使用します。デフォルトの動作では、1番目のポート(port1)としてポート8088の使用を試みます。ポート8088が使用できない場合は、自動ポート調整を使用して、次に使用可能なポートを選択します。2番目のポート(port2)が自動的に開き、デフォルトでport1の次に使用可能なポート(使用可能であれば、port1 + 1)として設定されます。自動ポート調整は無効化できます。この場合は、port1が使用可能であることが必要で、2番目のポートは必ずport1 + 1になります。
2つのUDPポートを使用する理由は次のとおりです。
インバウンド・トラフィックとアウトバウンド・トラフィック間の競合を削減し、両方での大量の転送を回避して、同じポートで受信する。
コヒーレンスなメンバー間では、オペレーティング・システムのMTU (Maximum Transmission Unit)に基づく最適なパケット・サイズでの通信が可能になる。サイズが大きなパケットに一方のUDPを使用し、サイズがネットワークのMTU以下であるパケットにはもう一方のポートを使用します。この分離によって、サイズに基づいて別個のパケット・バッファを使用できます。
ソケット・バッファの表面的なサイズを増やさずに、メンバー数が500を超える大規模なクラスタを実行できる。
クラスタ・メンバーのユニキャスト・アドレスを指定するには、オペレーション・オーバーライド・ファイルを編集して、<address>要素と<port>要素の両方(さらに、必要に応じて<port-auto-adjust>要素)を追加し、クラスタ・メンバーが使用するアドレスとポートを指定します。例:
<?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="tangosol.coherence.localhost">192.168.0.1
</address>
<port system-property="tangosol.coherence.localport">8090</port>
<port-auto-adjust system-property="tangosol.coherence.localport.adjust">
true
</port-auto-adjust>
</unicast-listener>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.localhost、tangosol.coherence.localportおよびtangosol.coherence.localport.adjustの各システム・プロパティを使用してユニキャスト・アドレスを指定できます。例:
-Dtangosol.coherence.localhost=192.168.0.1 -Dtangosol.coherence.localport=8090 -Dtangosol.coherence.localport.adjust=true
Well Knownアドレス(WKA)機能は、クラスタ・メンバーがマルチキャストのかわりにユニキャストを使用してクラスタを検出し、それに参加できるようにするメカニズムです。マルチキャスト・ネットワーキングが望ましくないか使用できない環境やマルチキャストを適切にサポートするように構成されていない環境でWKAを使用することが普通です。WKAを有効にすると、すべてのクラスタでマルチキャスト通信が無効になります。
クラスタを起動できる少数のクラスタ・メンバー(これをWKAメンバーといいます)を指定することでWKAが有効になります。WKAメンバーの最適な数はクラスタのサイズで異なります。一般的には、WKAメンバーの数はクラスタの10%程度にします。スイッチごとのWKAメンバーを1つか2つにすることをお薦めします。
各WKAメンバーは、クラスタの稼動中は利用可能な状態を維持している必要がありますが、どの時点でも同時にアクティブになっている必要はありません。クラスタ・メンバーがクラスタを検出してそこに参加するためには、WKAメンバーが1つのみ稼動可能になっている必要があります。さらに、クラスタに参加したクラスタ・メンバーは、すべてのクラスタ・メンバーのアドレスの通知を受け、各クラスタ・メンバーに個別にメッセージを送信することでブロードキャストを実行します。これにより、すべてのWKAメンバーが動作を停止しても、クラスタは稼動できます。ただし、このクラスタに新しいクラスタ・メンバーは参加できません。参加できるためには、そのクラスタ・メンバー自身がWKAメンバーになるか、いずれかのWKAメンバーが起動する必要があります。この場合は、クラスタの最上位メンバーがWKAメンバーのリストをポーリングし、そのWKAメンバーが既存のクラスタに再度参加できるようにします。
WKAメンバーを指定する方法は2つあります。まず、アドレスのリストを明示的に定義する方法があります。もう1つは、アドレス・プロバイダの実装を使用してWKAアドレスのリストを取得する方法です。どちらの方法も、オペレーション・オーバーライド・ファイルの中で<unicast-listener>要素の<well-known-addresses>サブ要素で構成します。
この項には次のトピックが含まれます:
<socket-address>要素の中でWKAメンバーを明示的に指定します。任意の数の<socket-address>要素を定義できますが、それぞれの要素では、<address>要素と<port>要素を使用してWKAメンバーのアドレスとポートの両方を定義する必要があります。独自のアドレスを指定したクラスタ・メンバーがあれば、そのクラスタ・メンバーは起動時に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>
<socket-address id="1">
<address>192.168.0.100</address>
<port>8088</port>
</socket-address>
<socket-address id="2">
<address>192.168.0.101</address>
<port>8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>
|
注意: WKAメンバーを設定する際は、そのポート値と、そのメンバーのユニキャスト・リスナー・ポートに対して指定したポート値とが一致している必要があります。ユニキャスト・ポートの設定の詳細は、「クラスタ・メンバーのユニキャスト・アドレスの指定」を参照してください。 |
WKAシステム・プロパティの使用
オペレーション・オーバーライド・ファイルでアドレスを指定するかわりに、システム・プロパティであるtangosol.coherence.wkaとtangosol.coherence.wka.portを使用して単独のWKAメンバーを指定できます。これらのシステム・プロパティは、デモやテストのシナリオで単独のWKAメンバーを簡単に指定できるようにすることを目的としたものです。例:
-Dtangosol.coherence.wka=192.168.0.100 -Dtangosol.coherence.wka.port=8088
複数の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>
<socket-address id="1">
<address system-property="tangosol.coherence.wka"></address>
<port system-property="tangosol.coherence.wka.port"></port>
</socket-address>
<socket-address id="2">
<address system-property="tangosol.coherence.wka2"></address>
<port system-property="tangosol.coherence.wka2.port"></port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>
前述の例では、次のようにシステム・プロパティを使用してWKAメンバーのアドレスを指定しています。
-Dtangosol.coherence.wka=192.168.0.102 -Dtangosol.coherence.wka.port=8090 -Dtangosol.coherence.wka2=192.168.0.103 -Dtangosol.coherence.wka2.port=8094
システム・プロパティの定義の詳細は、「カスタム・システム・プロパティの作成」を参照してください。
WKAアドレス・プロバイダは、プログラムでWKAメンバーを定義する方法を実現します。WKAアドレス・プロバイダはcom.tangosol.net.AddressProviderインタフェースを実装する必要があります。静的リストのような簡素な実装から、動的な検出プロトコルを使用するような複雑な実装まで可能です。このアドレス・プロバイダは、存在するすべてのアドレスを返したことを示す終端NULLアドレスを返す必要があります。クラスタ・メンバーが起動するときに、このアドレス・プロバイダ実装がコールされます。
|
注意: 返された例外や処理されない例外によって遅延が発生すると、検出の遅延の原因となり、その結果、メンバーに対するクラスタ・サービスが全面的にシャットダウンすることがあります。したがって、実装では細心の注意が必要です。負荷の大きい操作(ネットワーク・フェッチなど)が関わる実装では、 |
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>
単一サーバー・モードは、1台のコンピュータ上でのみ実行するように制限され、ネットワークにはアクセスしないクラスタです。単一サーバー・モードは開発やユニット・テストでクラスタを容易に起動および停止できます。
単一サーバー・モードを有効にするには、オペレーション・オーバーライド・ファイルを編集して、0に設定した<time-to-live>要素と、ループバックにルーティングするアドレスに設定したユニキャスト<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="tangosol.coherence.localhost">127.0.0.1
</address>
</unicast-listener>
<multicast-listener>
<time-to-live system-property="tangosol.coherence.ttl">0</time-to-live>
</multicast-listener>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、システム・プロパティであるtangosol.coherence.ttlとtangosol.coherence.localhostを使用して単一サーバー・モードを有効化できます。例:
-Dtangosol.coherence.ttl=0 -Dtangosol.coherence.localhost=127.0.0.1
UNIXオペレーティング・システムのいくつか(一部のバージョンのLinuxを含む)およびMac OS Xでは、TTLをゼロに設定するのみではクラスタを単独のコンピュータとして完全には分離できません。このような場合は、一意なクラスタ名も構成する必要があります。既存のクラスタ名と異なるクラスタ名を使用しているクラスタ・メンバーは、その既存のクラスタには参加できません。クラスタ名の構成の詳細は、「クラスタの名前の指定」を参照してください。
最後に、Mac OS XおよびLinuxのいくつかのバージョンでは、localhostのループバック・ルートが構成されておらず、クラスタの起動に失敗します。そのようなシナリオでは、WKA機能を使用して、クラスタ・メンバーの検出を確保します。例:
-Dtangosol.coherence.localhost=127.0.0.1 -Dtangosol.coherence.ttl=0 -Dtangosol.coherence.wka=127.0.0.1
WKAの構成の詳細は、「Well Knownアドレスの使用」を参照してください。
停止検出は、クラスタ・メンバーに発生した障害を迅速に検出するためのクラスタ・メカニズムです。障害が発生したクラスタ・メンバーはクラスタから除外され、他のすべてのクラスタ・メンバーには離脱したメンバーについての通知が送信されます。検出停止を使用することで、実際に障害が発生したメンバーと応答しなくなっているメンバーとを区別できます。たとえば、JVMが完全なガベージ・コレクションを実行しているときは、メンバーが応答しなくなります。
停止検出は、プロセス障害(TcpRingコンポーネント)とハードウェア障害(IpMonitorコンポーネント)の両方を特定します。プロセス障害は、クラスタUDP通信に使用されるものと同じポートで開いているTCP接続のリングを使用して検出されます。各クラスタ・メンバーはユニキャストのハートビートを発行し、最も上位のクラスタ・メンバーは、ブロードキャスト・メッセージとなるクラスタ・ハートビートを発行します。ハードウェア障害は、トレースICMP Pingまたは疑似Pingを発行してTCPポート7を使用するJava InetAddress.isReachableメソッドを使用して検出します。停止検出はデフォルトで有効になっていますが、<tcp-ring-listener>要素で構成できます。
この項には次のトピックが含まれます:
TCPリング・リスナーのデフォルトの動作を変更するために使用する設定がいくつかあります。これには、クラスタ・メンバーをホストしているコンピュータが到達不可能になっていると判断するまでの試行回数と時間の変更などがあります。これらのデフォルトの設定はそれぞれ3回と15秒です。TCP/IPソケットのバックログ・キューも設定可能で、デフォルトではオペレーティング・システムで使用する値が設定されています。
TCPリング設定を変更するには、オペレーション・オーバーライド・ファイルを編集して、次のTCPリング要素を追加します。
|
注意:
|
<?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="tangosol.coherence.ipmonitor.pingtimeout">
25s
</ip-timeout>
<ip-attempts>5</ip-attempts>
<listen-backlog>10</listen-backlog>
</tcp-ring-listener>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.ipmonitor.pingtimeoutシステム・プロパティを使用してタイムアウトを指定できます。例:
-Dtangosol.coherence.ipmonitor.pingtimeout=20s
停止検出のハートビート間隔を変更できます。この間隔を長くすると、最低限必要なネットワーク・トラフィックを小さく抑えることができますが、障害が発生したメンバーを検出できなくなることがあります。デフォルトのハートビート値は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>
停止検出はデフォルトで有効になっているので、無効にするには明示的な指定が必要です。停止検出を無効にしても、最低限必要なネットワーク・トラフィックを小さく抑えることができるのみであり、その一方で障害が発生したメンバーを検出できなくなることがあります。無効にすると、クラスタ・メンバーはパケット・パブリッシャの再送信タイムアウト間隔を使用して、他のメンバーがUDPパケットへの応答を停止していることを判断します。デフォルトでは、このタイムアウト間隔は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>
クラスタの優先度のメカニズムを使用すると、クラスタ・メンバーおよびメンバーの中で実行している様々なスレッドに優先度の値を割り当てることができます。
この項には次のトピックが含まれます:
クラスタ・メンバーの優先度は、同等の複数のメンバーに対する様々な処理の順番を指定するための基礎として使用します。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="tangosol.coherence.priority">1</priority>
</member-identity>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.priorityシステム・プロパティを使用してクラスタ・メンバーの優先度を指定できます。例:
-Dtangosol.coherence.priority=1
スレッドの優先度をサポートするクラスタ・コンポーネントがいくつかあります。この優先度は、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>
クラスタ・サービスではスレッドの優先度がサポートされています。この優先度は、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> ...
