| Oracle Containers for J2EE構成および管理ガイド 10g（10.1.3.5.0） B56030-01 |
|
 戻る |
 次へ |
この章では、OC4J 10g（10.1.3.5.0）に付属するアプリケーションのクラスタリング・フレームワークについて説明します。この章の内容は次のとおりです。
OC4Jには、開発および本番用にクラスタ化された環境を作成するための柔軟性のあるフレームワークが用意されています。アプリケーション・クラスタは、2つ以上のOC4Jインスタンスがホストとなる同じアプリケーション・セットです。OC4Jアプリケーションのクラスタリング・フレームワークでは、次のことをサポートします。
HTTPセッションまたはステートフル・セッションEnterprise JavaBean（SFSB）インスタンスに含まれるオブジェクトおよび値のレプリケーション。
マルチキャストまたはpeer-to-peer通信を使用したメモリー内レプリケーション、あるいはデータベースに対する状態データの永続性。
OC4Jインスタンス間での受信リクエストのロード・バランシング。
アプリケーション・クラスタ内のアプリケーション間での透過的フェイルオーバー。
グローバル・サーバー・レベルまたはアプリケーション・レベルでのOC4Jインスタンス内の構成。
様々な新しいサブ要素を持つ新しい<cluster>要素が、アプリケーションのクラスタリングを管理するための単一の方法となるように、XMLスキーマ定義に追加されています。この要素とそのサブ要素の説明は、「<cluster>要素の指定」を参照してください。
OC4J 10g（10.1.3）のアプリケーションのクラスタリング・フレームワークに含まれなくなった機能を次に示します。
アイランドという概念は、旧リリースのOC4Jにおけるクラスタリング・フレームワークの一部でしたが、現行OC4Jではサポートされていません。
旧リリースでは、アイランドとは基本的に、HTTPセッション・データがレプリケートされるOracle Application Serverクラスタ内のOC4Jインスタンスのグループでした。アイランドは、クラスタ全体でデータをレプリケートしないことでオーバーヘッドを削減しましたが、構成および管理のオーバーヘッドを増加させました。また、アイランドはWebアプリケーションにのみ適用でき、EJBアプリケーションではアイランド構成を使用できませんでした。
OC4J 10g（10.1.3）では、<cluster>要素のwrite-quota属性を使用して、データをレプリケートするノードの数を事実上制限できます。この属性を使用すると、状態レプリケーションの範囲を制御できるようになります。
write-quota属性の詳細は、「アプリケーションの状態データをレプリケートするJVMの数の管理」および「<cluster>要素の指定」を参照してください。
アプリケーションのクラスタリングは、OC4Jインスタンス内でクラスタ化される各アプリケーションのorion-application.xmlファイルに<cluster>要素を追加すると有効になります。デプロイ済アプリケーションの場合、このファイルは、ORACLE_HOME/j2ee/instance/application-deployments/applicationNameディレクトリにあります。この要素とそのサブ要素の説明は、「<cluster>要素の指定」を参照してください。
この項の内容は次のとおりです。
アプリケーションのクラスタリングは、OC4Jインスタンス内で稼働しているすべてのアプリケーションに対してグローバルにもアプリケーション単位でも有効にできます。
すべてのアプリケーションに対するクラスタリングの有効化
アプリケーションのクラスタリングは、defaultアプリケーションの構成ファイルであるORACLE_HOME/j2ee/instance/config/application.xmlを使用して、OC4Jインスタンスにデプロイされたすべてのアプリケーションに対してデフォルトで有効にできます。OC4Jインスタンスにデプロイされたその他のすべてのアプリケーションは、アプリケーションのクラスタリングの構成を含めデフォルトのプロパティをこのアプリケーションから継承します。
特定のアプリケーションに対するクラスタリングの有効化
アプリケーションのクラスタリングは、アプリケーション固有のORACLE_HOME/j2ee/instance/application-deployments/app_name/orion-application.xmlファイルに定義されます。このファイルの設定は、グローバル構成にも親アプリケーションから継承される構成にも優先します。
|
注意: アプリケーションのクラスタリングは、Oracle Enterprise Manager 10g Application Server Controlを使用してアプリケーションをデプロイする際に、デプロイ・タスクまたはデプロイ・プラン・エディタのいずれかを使用して構成することもできます。詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。 |
単一のOC4Jインスタンスの特定アプリケーションのorion-application.xmlファイルへの変更内容は、Oracle Application Serverクラスタ内のすべてのアプリケーションに対するその他のOC4Jインスタンスの対応するXMLファイルにレプリケートする必要があります。詳細は、「クラスタでの変更のレプリケート」を参照してください。
アプリケーション・レベルでは、OC4Jインスタンスにアプリケーションがデプロイされる際に、デプロイ・プラン・エディタを使用してアプリケーションのクラスタリングを構成できます。デプロイ・プラン・エディタにより、各アプリケーションのorion-application.xmlファイルに値が設定されます。デプロイ・プラン・エディタの使用方法は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
|
重要: 空の<distributable />タグを、アプリケーションのクラスタリングを使用するように構成されたアプリケーションの一部であるすべてのWebモジュールのweb.xmlファイルに追加する必要があります。デプロイ後、このJ2EE標準Webモジュールのディスクリプタは、OC4J内のORACLE_HOME/j2ee/instance/applications/app_name/web_module/WEB-INFディレクトリにあります。 |
レプリケーション・ポリシーは、HttpSessionまたはステートフル・セッションBeanの状態をレプリケートするタイミングと、レプリケート対象がすべての属性および変数の値か、変更された値のみかを定義します。レプリケーションは負荷の高いプロセスとなる可能性があり、データを頻繁にレプリケートしすぎると、サーバーのパフォーマンスに影響を与えることがあります。ただし、データをレプリケートする頻度が低すぎると、サーバーが停止した場合にデータが失われる可能性があります。
アプリケーション内のすべてのWebモジュールおよびEJBモジュールに適用されるレプリケーション・ポリシーは、アプリケーションのorion-application.xml構成ファイルの<replication-policy>要素に指定されます。この要素の構文は次のとおりです。
<replication-policy trigger="onSetAttribute|onRequestEnd|onShutdown" scope="modifiedAttributes|allAttributes" />
trigger属性は、レプリケートするタイミングを指定します。JVMが突然終了した場合にデータが失われないようにデータを頻繁にレプリケートするため、デフォルトではonRequestEndポリシーが適用されます。
trigger属性の値の概要は、表9-1を参照してください。
scope属性はレプリケート対象のデータ（すべての属性や変数の値、または変更された値のみのいずれか）を定義します。デフォルトでは、変更されたHTTPセッション属性のみがレプリケートされます。ステートフル・セッションBeanの場合は、すべてのメンバー変数がレプリケートされます。
scope属性の値の概要は、表9-2を参照してください。
表9-1 <replication-policy>のtrigger属性の値
| triggerの値 | HttpSession | ステートフル・セッションBean |
|---|---|---|
|
|
値の変更時に、HTTPセッション属性に加えられた各変更をレプリケートします。プログラム的な面から見ると、 このオプションは、セッションが頻繁に変更されている場合、リソースが集中する可能性があります。 |
該当なし。 |
|
|
HTTPセッション属性に加えられたすべての変更をキューに入れ、HTTPレスポンスが送信される直前にすべての変更をレプリケートします。 |
EJBメソッド・コールのたびに、Beanの現在の状態をレプリケートします。状態は頻繁にレプリケートされますが、信頼性は向上します。 |
|
|
JVMが（[Ctrl]+[C]などで）正常に終了するたびに、HTTPセッションの現在の状態をレプリケートします。状態は、ホストが突然終了した場合（システム・クラッシュなど）にはレプリケートされません。 セッションの状態はまだレプリケートされていないため、JVMの終了と同時にすべてのセッション・データが一度にネットワーク上に送信され、ネットワーク・パフォーマンスに影響を与える可能性があります。このオプションは、JVMの停止に必要な時間を著しく増加させる可能性もあります。 |
JVMが正常に終了するたびに、Beanの現在の状態をレプリケートします。状態は、ホストが突然終了した場合（システム・クラッシュなど）にはレプリケートされません。 Beanの状態はまだレプリケートされていないため、JVMの終了と同時にすべての状態データが一度にネットワーク上に送信され、ネットワーク・パフォーマンスに影響を与える可能性があります。このオプションは、JVMの停止に必要な時間を著しく増加させる可能性もあります。 |
表9-2 <replication-policy>のscope属性の値
| scopeの値 | HttpSession | ステートフル・セッションBean |
|---|---|---|
|
|
変更されたHTTPセッション属性、すなわち |
該当なし。 |
|
|
HTTPセッションに設定されたすべての属性の値をレプリケートします。 |
ステートフル・セッションBeanに設定されたすべてのメンバー変数の値をレプリケートします。 |
orion-application.xmlの<replication-policy>要素は、アプリケーション内のWebモジュールとEJBモジュールを区別できません。しかし、EJBモジュール用に別のレプリケーション・ポリシーをコンポーネント固有のorion-ejb-jar.xml構成ファイルの<session-deployment>要素のreplication属性に指定できます。
replication属性の有効な値は、表9-3を参照してください。次に例を示します。
<session-deployment name="MyStatefulVM" replication="onShutdown" /> <session-deployment name="MyEntity2" replication="onRequestEnd" />
このファイルの値は、orion-application.xmlの対応する設定に優先するため、EJBモジュール用のレプリケーション・ポリシーをorion-ejb-jar.xmlに、Webコンポーネント用のポリシーをorion-application.xmlに事実上設定できます。
表9-3 ステートフル・セッションEJBのレプリケーション・ポリシーの構成
| replicationの値 | 説明 |
|---|---|
|
|
EJBメソッド・コールのたびに、Beanの現在の状態をレプリケートします。状態のレプリケーション頻度は高くなりますが、ホスト障害時における信頼性は向上します。これはデフォルト値です。 |
|
|
JVMが正常に終了するたびに、Beanの現在の状態をレプリケートします。状態は、ホストが突然終了した場合（システム・クラッシュやLinuxまたはUNIX環境での |
|
|
データをレプリケートしません。 |
<cluster>要素のwrite-quota属性を使用すると、状態データがレプリケートされるJVMの数を事実上制限できます。この機能を使用すると、状態レプリケーションの範囲を制御して、ネットワーク・トラフィックおよび関連するオーバーヘッドを削減できます。
write-quotaのデフォルト値は1で、状態をOracle Application Serverクラスタ内のもう1つのJVMにレプリケートします。
アプリケーション・グループのメンバーは、実際はOracle Application ServerノードではなくJVMで実行されます。クラスタのコンポーネントとして、複数のJVMがノードごとに稼働するアーキテクチャおよび構成を作成できます。
ハードウェアが停止した場合はフェイルオーバーによって保護される別の物理ノードに状態レプリケーションを格納するには、allow-colocation属性をfalseに設定します。これを実行するには、状態レプリケーション・マネージャで、状態レプリケーションを格納するために別の物理ノードで稼働されているピア（write-quotaが1よりも大きい場合は複数のピア）を選択する必要があります。
Oracle Application Serverクラスタ内のすべてのJVMに状態をレプリケートするには、クラスタ内のJVMの合計数をwrite-quotaの値として指定する必要があります。
デフォルトでは、OC4Jインスタンスはデータを他のインスタンスに非同期的にレプリケートします。しかし、<cluster>要素内に<synchronous-replication>サブ要素を指定して、同期レプリケーションを有効にできます。これにより、レプリケーションを続行する前に、レプリケートするOC4Jインスタンスは、データを受信したという他の1つ以上のピア・インスタンスからの確認応答を待機するように強制されます。
マルチキャストIPレプリケーションは、スタンドアロンOC4Jインストールで使用されるデフォルトのレプリケーション・プロトコルです。このモードでは、OC4Jはマルチキャスト・パッケージを使用して、HTTPセッションおよびステートフル・セッションBeanの状態の変更を送受信します。これらのパッケージは、同じマルチキャスト・アドレスおよびポートを使用して他のOC4Jプロセスによって取得されるネットワーク上で送信されます。失われたメッセージは特定されて再送信されるため、信頼性のある送信サービスが提供されます。
この構成は、同じマルチキャスト・アドレスおよびポートをすべてのOC4Jインスタンスに指定する必要があります。OC4Jマルチキャストで使用されるデフォルト値は、アドレスは230.230.0.1、ポートは45566です。これらの値は、必要に応じて、該当するXML構成ファイルで変更できます。
空の<cluster>要素を各インスタンスのorion-application.xmlファイルに追加するだけで、複数のアプリケーション・インスタンス間でマルチキャスト・レプリケーションを有効にできます。
<orion-application ...> ... <cluster/> </orion-application>
次の例では、ipおよびport属性を使用して新しいマルチキャスト・アドレスおよびポートを指定しています。オプションのbind_addr属性は、バインドするネットワーク・インタフェース・カード（NIC）の指定に使用できます。この属性は、OC4Jホスト・マシンに複数のネットワーク・カードが装備されており、それぞれに固有のIPアドレスを保持し、マルチキャスト・メッセージの送受信に使用するNICを定義する場合に使用すると便利です。
<orion-application ...>
...
<cluster allow-colocation="false">
<replication-policy trigger="onShutdown" scope="allAttributes" />
<protocol>
<multicast ip="225.130.0.0" port="45577" bind_addr="226.83.24.10" />
</protocol>
</cluster>
</orion-application>
OC4Jによって提供されるマルチキャスト・ベースおよびpeer-to-peerベースのレプリケーション方式は、JavaGroups通信プロトコル・スタックに基づいて構築されています。OC4Jのこれらの方式はOC4J固有の構成を使用するため、そのいずれかを使用して、状態データのメモリー内レプリケーションを行うことをお薦めします。
しかし、OC4Jのクラスタリング・フレームワーク内で独自のJavaGroups構成を使用することもできます。この機能は、<cluster>要素内の<property-config>サブ要素に次のいずれかを指定すると有効になります。
JavaGroups構成プロパティが含まれる文字列
その情報が含まれるXML構成ファイルへのURL
詳細は、「<cluster>要素の指定」を参照してください。
OC4Jでは、TCPを使用してOracle Application Serverクラスタ内のインスタンス間の接続を確立するpeer-to-peer（P2P）トポロジでのレプリケーションをサポートします。各アプリケーション・インスタンスに保持される状態データは、各OC4Jインスタンスにユニキャストされます。
次の2つのpeer-to-peerレプリケーションがサポートされます。
動的peer-to-peer。Oracle Process Manager and Notification Server（OPMN）を使用して、ピア・ノードが相互に動的に検出して通信できるようにします。この構成は、各種コンポーネント（OC4Jを含む）の管理にOPMNを使用するOracle Application Server環境で、デフォルトで使用されます。
詳細は、「動的OPMN管理のpeer-to-peerレプリケーションの構成」を参照してください。
静的peer-to-peer。クラスタ内の各ノードは、他の1つ以上のピア・ノードを認識するように明示的に構成されます。この構成は、比較的少ない数のスタンドアロンOC4Jインスタンスがまとめてクラスタ化されているスタンドアロンOC4J環境でのみサポートされます。
詳細は、「静的peer-to-peerレプリケーションの構成」を参照してください。
Oracle Application Server環境では、Oracle Process Manager and Notification Server（OPMN）を使用して動的peer-to-peerレプリケーションを提供します。このレプリケーション・モデルでは、各Oracle Application ServerノードはOPMNに自己登録します。次に、ノードはOPMNに使用可能なノードのリストを問い合せて、クラスタ内の他のノードを動的に検出して通信できるようにします。
|
注意: この機能を使用するには、まず、OPMNの動的マルチキャスト検出方式または静的検出サーバー方式のいずれかを使用して、アプリケーションのホストとなるすべてのノードをクラスタのメンバーにする必要があります。詳細は、「サポートされるクラスタリング・モデル」を参照してください。 |
各ノードは、OPMNにONS（ハートビート）メッセージを定期的に送信して現行のステータスをOPMNに通知し、OPMNが使用可能なピア・ノードのリアルタイムなリストを保持し、障害が発生したときにノードに通知できるようにします。ノードが失われた場合は、別のノードがリクエストを処理できます。
<orion-application ...>
...
<cluster>
<protocol>
<peer>
<opmn-discovery />
</peer>
</protocol>
</cluster>
</orion-application>
この構成では、他の1つ以上のピア・ノードのホスト・アドレスおよびポートを指定して、peer-to-peer通信に使用できるようにします。ノードは各ピアを認識するようになるため、各ピアのピアも認識するようになり、最終的には、クラスタ内のすべてのノードが相互に認識するようになります。
この構成の主な課題は、ホストおよびポート定義が最新の状態で維持されるようにすることです。これには、多大な管理労力が必要となる可能性があります。次の要素および属性は、この構成に影響を及ぼします。
<peer>要素のstart-port属性: ローカルのOC4Jプロセスがピア通信のためにバインドしようとするホストに開始ポートを指定します。このポートが使用できない場合、OC4Jは、このポートの値を増やながら使用可能なポートを見つけます。
<node>要素: ピア・ノードを指定します。この要素のhostおよびport属性は、ピア通信に使用されるノード・アドレスおよびポートの名前を定義します。
<peer>要素のrange属性: start-port属性の値ではなく、各<node>要素に指定されたポートに適用されます。range属性は、指定されたポートがノードで使用できない場合に、portの値を増やす回数を定義します。
次の例は、sampleアプリケーションとともに3つのクラスタ・ノードにデプロイされたアプリケーション・デプロイメント・ディスクリプタorion-application.xmlに指定されている静的peer-to-peer構成を示しています。
この構成では、各ノードはもう1つのノードをそのピアとして指定しています。その結果、クラスタ内のすべてのノードは相互に接続を確立できます。この例は、各ノードが連続して起動された場合にのみ機能します。つまり、www3.company.comはwww2.company.comより前に起動する必要があります。起動しないと、www2.company.comはwww3.company.comを認識できません。
最初に、www1.company.comがそのピアとしてwww2.company.comを指定します。
<orion-application ...>
...
<cluster>
<protocol>
<peer start-port="7900" range="10" timeout="6000">
<node host="www2.company.com" port="7900" />
</peer>
</protocol>
</cluster>
</orion-application>
次に、www2.company.comがそのピアとしてwww3.company.comを指定します。
<orion-application ...>
...
<cluster>
<protocol>
<peer start-port="7900" range="10" timeout="6000">
<node host="www3.company.com" port="7900" />
</peer>
</protocol>
</cluster>
</orion-application>
最後に、www3.company.comがそのピアとしてwww1.company.com を指定します。
<orion-application ...>
...
<cluster>
<protocol>
<peer start-port="7900" range="10" timeout="6000">
<node host="www1.company.com" port="7900" />
</peer>
</protocol>
</cluster>
</orion-application>
代替構成では、すべてのノードが同じノードをピアとして指定します。たとえば、www1.company.comノードとwww3.company.comノードはどちらも、www2.company.comをピアとして指定します。この構成では、www2.company.comは最初に起動されるノードである必要があり、他のノードはこのノードに接続して相互に接続を確立します。
OPMN管理のOracle Application Server環境でステート・レプリケーションを使用してアプリケーションをデプロイすると、OPMNにより、クラスタ全体への状態の伝播に使用されるポートが動的に割り当てられます。この割当ては、peer-to-peerレプリケーションが有効化されているアプリケーションのポート範囲に制限できます。明確に定義されたポート範囲を使用するファイアウォールまたはネットワークでのインストールには、ステート・レプリケーション用のポートを指定する必要があります。
peer-to-peerのステート・レプリケーションのポート範囲を指定する手順:
opmn.xmlファイルのOC4Jインスタンス構成に<port>要素を追加します。
<port>要素のid属性の値として、peer-to-peerレプリケーションが有効化されているアプリケーションの名前を指定します。
<port>要素のrange属性にポート範囲を指定します。
たとえば、peer-to-peerレプリケーション用に設定されたrac-webという名前のアプリケーションのデプロイの場合、次のOC4Jインスタンス構成で<port id=rac-web .../>というラベルの行は、ステート・レプリケーションに15213〜15214のポートを使用するようOPMNに指示しています。
<port id="default-web-site" range="80-100" protocol="http"/> <port id="rmi" range="12401-12500"/> <port id="rmis" range="12701-12800"/> <port id="jms" range="12601-12700"/> <port id="rac-web" range="15213-15214"/>
新しいクラスタリング・フレームワークでは、HTTPセッションおよびステートフル・セッションBeanの状態をデータベースにレプリケートできます。クラスタ化されたOC4Jフレームワークの外側にデータを保存して、クラスタ内のすべてのOC4Jインスタンスで致命的な障害が発生した場合にセッション全体をリカバリできるようにします。完全HTTPセッションまたはステートフル・セッションBeanのオブジェクトは、データベースにレプリケートされます。
データベースへの接続は、<protocol>の<database>サブ要素のdata-source属性に指定されるデータソースを使用して作成されます。data-source属性の値を、data-sources.xmlに指定されているデータソースのjndi-nameに設定します。
指定するデータソースは、あらかじめOC4Jインスタンス内に存在している必要があります。データソースを作成および使用する方法は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
次の例では、MyOracleDSデータソースを介してアクセスされるデータベースにデータをレプリケートするようにアプリケーションを構成しています。
<orion-application ...>
...
<cluster>
<protocol>
<database data-source="jdbc/MyOracleDS"/>
</protocol>
</cluster>
</orion-application>
セッション・データは、データベースの次の表に保存されます。
OC4J_HTTP_SESSION: HTTPセッションのメタデータが格納されます。
OC4J_HTTP_SESSION_VALUE: HTTPセッションでアプリケーション・ユーザーによって設定される値が格納されます。
OC4J_EJB_SESSION: ステートフル・セッションBeanの現在の状態が格納されます。
これらの表は、データベース・レプリケーションの初回起動時に、OC4Jによって作成されます。表スキーマの詳細は、付録C「セッション状態表の概要」を参照してください。
セッション・データがデータベースに格納される時間の長さは、セッションの有効時間（TTL）に基づいています。現在のデータベースの時間とセッションが最後にアクセスされた時間の差がセッション・タイムアウト値より大きくなると、セッションは期限切れになったとみなされます。セッションのTTLを決定する実際の式は次のとおりです。
(Current Database Time - Last Accessed Time) > Max Inactive Time
期限切れになったセッションは、OC4Jタスク・マネージャの次回実行時にデータベースから削除されます。タスク・マネージャの間隔の設定手順は、「OC4Jタスク・マネージャの構成」を参照してください。
セッションが正常終了せずにOC4Jサーバーが終了した場合は、孤立したレコードがデータベースに作成されます。これらのレコードも、タスク・マネージャの次回実行時に削除されます。
システム・プロパティを使用して、クラスタ内でアプリケーション・インスタンスが稼働しているJVM、OC4JインスタンスおよびApplication Serverインスタンスを確認できます。この情報は、Oracle Application Server上に管理ユーティリティを作成する場合のみでなく、デバッグを実行する場合にも便利です。
クラスタ内で稼働しているアプリケーション・インスタンスの環境に関する情報を取得するには、System.getProperty()コールを使用して複数のプロパティにアクセスします。OC4Jで実行されているJavaプロセスでは、例9-1に示すように、システム・プロパティを使用して、JVM、OC4JインスタンスおよびApplication Serverインスタンスの情報をシステム・コンソールに出力できます。
例9-1 システム・プロパティ値を出力するためのSystem.getProperty()コール
System.out.println("Oracle home name: " + System.getProperty("oracle.home"));
System.out.println("OC4J instance name: " +
System.getProperty("oracle.oc4j.instancename"));
System.out.println("AS instance name: " +
System.getProperty("oracle.ons.instancename"));
System.out.println("Instance:Group:JVM PID: " +
System.getProperty("oracle.ons.indexid"));
表9-4に、アプリケーションのJVM、グループ、OC4Jインスタンス、OracleホームおよびOracle Application Serverインスタンスを指定するシステム・プロパティを説明します。
表9-4 JVM、OC4JインスタンスおよびApplication Serverインスタンスのシステム・プロパティ
| プロパティ | 値 |
|---|---|
|
|
Oracle Application Serverがインストールされている物理ディレクトリの名前を含む文字列 |
|
|
Oracle Application Serverインスタンスの名前を含む文字列 |
|
|
OC4Jインスタンスの名前を含む文字列 |
|
|
OC4Jインスタンス名、インスタンスが属するグループ、およびアプリケーション・インスタンスを実行しているJVMの組合せを含む、次の書式の文字列 OC4J_INSTANCE.oc4j_groupname.jvm_number 例: |
クラスタリングは、<cluster>要素のブールのenabled属性を使用して、グローバルにまたは特定のアプリケーションに対して無効にできます。アプリケーションのorion-application.xmlファイルでこの属性をfalseに設定すると、そのアプリケーションはクラスタから事実上削除されます。
<cluster>要素は、アプリケーションのクラスタリングを管理するための単一の方法です。この要素は、グローバル・レベルのアプリケーションのクラスタリング構成ではORACLE_HOME/j2ee/instance/config/application.xmlファイルでのみ使用されます。また、アプリケーション・レベルのクラスタリング構成ではアプリケーション固有のorion-application.xmlファイルで使用されます。
<cluster>
OC4Jインスタンス内で稼働しているエンタープライズ・アプリケーションのアプリケーション・クラスタリング構成が含まれます。
<cluster>のサブ要素:
<property-config> <flow-control-policy> <replication-policy> <protocol> <synchronous-replication>
属性:
enabled: アプリケーションに対してクラスタリングが有効かどうかを指定します。デフォルトはtrueです。この値をアプリケーション・レベルで設定すると、親アプリケーション（defaultアプリケーションを含む）から継承された値は上書きされます。
group-name: レプリケーション・グループ・チャネルを確立する際に使用する名前。指定しないと、OC4Jサーバー構成ファイルserver.xmlに定義されているアプリケーション名がデフォルトで使用され、新しいグループ・チャネルがエンタープライズ・アプリケーションごとに作成されます。
値を指定すると、アプリケーションとすべての子アプリケーションは、このグループ名に関連付けられたチャネルを使用します。
<database>タグが指定されている場合、この属性は無視されます。
allow-colocation: アプリケーションの状態を同じホスト・マシンに存在するノードにレプリケートできるかどうかを指定します。デフォルトはtrueです。しかし、複数のホストが使用可能である場合は、この属性をfalseに設定する必要があります。
複数のOC4Jインスタンスが同じマシン上でインスタンス化されている場合、インスタンスごとに異なるリスナー・ポートをdefault-web-site.xml、jms.xmlおよびrmi.xmlの各構成ファイルに指定する必要があります。
write-quota: アプリケーションの状態をレプリケートする必要がある他のアプリケーション・グループ・メンバー（JVM）の数。この属性は、旧OC4Jリリースで使用されたアイランドの概念と同様に、状態が書き込まれるJVMの数を制限することによってオーバーヘッドの削減を可能にします。
デフォルトのJVMの数は1です。
<database>タグが指定されている場合、この属性は無視されます。
cache-miss-delay: セッションがローカルに見つからない場合に、別のグループ・メンバーがセッションで応答するのをプロセス内で待機する時間（ミリ秒単位）。セッションが見つからない場合、リクエストは指定された時間にわたって一時停止します。
デフォルトは1000ミリ秒です。リクエストの負荷が重いと予想されるインストールでは、この値を5000などに増やす必要があります。この値を高くすると、allow-colocationがtrueに設定されている場合、OC4Jインスタンスの内部でセッション・データのレプリカが作成されることも防ぎます。
<database>タグが指定されている場合、この属性は無視されます。
<property-config>
JavaGroupsグループ通信プロトコルを使用して、クラスタ内のノード間でセッションの状態をレプリケートするために必要なデータが含まれます。
属性:
url: JavaGroupsのXML構成ファイルへのリンク。
property-string: JavaGroups JChannelの作成方法を定義するプロパティが含まれる文字列。
<replication-policy>
適用するレプリケーション・ポリシー。データをレプリケートするタイミングとレプリケート対象のデータを定義します。
属性:
<protocol>
データ・レプリケーションに使用する方式を定義します。指定できる方式は1つのみです。
サブ要素:
<multicast> <peer> <database>
<multicast>
レプリケーションにマルチキャスト通信を使用するために必要な構成が含まれます。これはデフォルトで使用されるプロトコルです。
属性:
ip: 使用するマルチキャスト・アドレス。OC4Jのデフォルトは230.230.0.1です。
port: 使用するマルチキャスト・ポート。OC4Jのデフォルトはポート45566です。
bind_addr: バインドするネットワーク・インタフェース・カード（NIC）。この属性は、OC4Jホスト・マシンに複数のネットワーク・カードが装備されており、それぞれに固有のIPアドレスを保持している場合に使用すると便利です。
<peer>
レプリケーションにpeer-to-peer（P2P）通信を使用するために必要な構成が含まれます。
サブ要素:
<opmn-discovery> <node>
属性:
start-port: ピア通信用に割当てを試みるためのノード上の内部ポート。OC4Jは、この値を増やしながら使用可能なポートが見つけます。デフォルトはポート7800です。スタンドアロンOC4Jインストールでの静的peer-to-peerレプリケーションの構成に対してのみ有効です。
range: 使用可能なピア・ノードの検索中に、各<node>サブ要素に指定されたportの値を増やす回数。デフォルトは5回の増分です。スタンドアロンOC4Jインストールでの静的peer-to-peerレプリケーションの構成に対してのみ有効です。
timeout: 使用可能なピア・ノードの検索中に、ピアからのレスポンスを待機する時間（ミリ秒単位）。デフォルトは3000ミリ秒です。スタンドアロンOC4Jインストールでの静的peer-to-peerレプリケーションの構成に対してのみ有効です。
bind_addr: バインドするネットワーク・インタフェース・カード（NIC）。この属性は、OC4Jホスト・マシンに複数のネットワーク・カードが装備されており、それぞれに固有のIPアドレスを保持している場合に使用すると便利です。
<opmn-discovery>
Oracle Application Server環境で動的peer-to-peerレプリケーションを使用するようにOC4Jを構成します。
<node>
静的peer-to-peer通信を使用する場合にポーリングするノードのホスト名およびポートが含まれます。この要素の1つ以上のインスタンスを<peer>要素内に指定できます。
属性:
host: ピア・ノードのホスト名（URL）。
port: peer-to-peer通信に使用されるノード上のポート。デフォルトはポート7800です。
<database>
状態データをデータベースに保存するために必要な接続情報が含まれます。
属性:
data-source: データベース接続情報を格納するデータソースの名前。この値は、data-sources.xmlに指定されているデータソースのjndi-name属性の値である必要があります。
<flow-control-policy>
レプリケーション時にクラスタリング・メッセージの処理に割り当てるメモリー量を制御します。この要素は、レプリケーション時にノード間で送信されるデータ量（バイト単位）をゲートして、メモリー不足エラーを防止することを目的としています。
属性:
enabled: フロー制御が有効かどうかを指定します。デフォルトはtrueです。
max-bytes: 受信ノードが受け入れることができる最大バイト数。この値に達すると、追加メッセージを送信できるようになるまで、送信ノードは受信側からの確認応答を待機する必要があります。デフォルト値は、500000です。
min-bytes: 送信するバイト数を多くする必要があるという確認応答をトリガーせずに、受信ノードが受け入れることができる最小バイト数。受信済バイト数がこの値を下回る場合、送信側から受け入れることができるバイト数がさらに多いことを受信側は確認応答します。デフォルトは0です。
threshold: min-bytesが指定されない場合に、その属性値を決定するために、この係数値が受信リクエストに適用されます。デフォルト値は、0.25です。
<synchronous-replication>
指定した場合、アプリケーション・データをレプリケートするノードは、データ更新を受信したという他の1つ以上のピア・ノードからの確認応答を待機してから、レプリケーションを続行します。この要素は任意です。デフォルトの動作では、ノードは他のノードにデータを非同期的にレプリケートし続けます。
属性:
timeout: ピア・ノードからのレスポンスを待機する時間（ミリ秒単位）。この値を超えると、確認応答を受信しなくてもレプリケーションは続行されます。デフォルト値は、10000ミリ秒（10秒）です。
