Oracle Containers for J2EE
構成および管理ガイド
10g(10.1.3.4.0) B50866-01 |
|
この章では、OC4J 10g(10.1.3.4.0)に付属するアプリケーションのクラスタリング・フレームワークについて説明します。この章の内容は次のとおりです。
OC4Jには、開発および本番用にクラスタ化された環境を作成するための柔軟性のあるフレームワークが用意されています。アプリケーション・クラスタは、2つ以上の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>要素の指定」を参照してください。
loadbalancer.jar
アーカイブは、旧リリースのOC4Jではロード・バランシング機能を提供していましたが推奨されず、現行リリースからは削除されています。
次のXML要素は、OC4J 10g(10.1.3.4.0)では推奨されていません。クラスタリングの構成に使用しないでください。
新しい<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
ファイルに定義されます。このファイルの設定は、グローバル構成にも親アプリケーションから継承される構成にも優先します。
単一のOC4Jインスタンスの特定アプリケーションのorion-application.xml
ファイルへの変更内容は、Oracle Application Serverクラスタ内のすべてのアプリケーションに対するその他のOC4Jインスタンスの対応するXMLファイルにレプリケートする必要があります。詳細は、「クラスタでの変更のレプリケート」を参照してください。
アプリケーション・レベルでは、OC4Jインスタンスにアプリケーションがデプロイされる際に、デプロイ・プラン・エディタを使用してアプリケーションのクラスタリングを構成できます。デプロイ・プラン・エディタにより、各アプリケーションのorion-application.xml
ファイルに値が設定されます。デプロイ・プラン・エディタの使用方法は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
レプリケーション・ポリシーは、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を参照してください。
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
に事実上設定できます。
<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>
サブ要素に次のいずれかを指定すると有効になります。
詳細は、「<cluster>要素の指定」を参照してください。
OC4Jでは、TCPを使用してOracle Application Serverクラスタ内のインスタンス間の接続を確立するpeer-to-peer(P2P)トポロジでのレプリケーションをサポートします。各アプリケーション・インスタンスに保持される状態データは、各OC4Jインスタンスにユニキャストされます。
次の2つのpeer-to-peerレプリケーションがサポートされます。
詳細は、「動的OPMN管理のpeer-to-peerレプリケーションの構成」を参照してください。
詳細は、「静的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レプリケーションが有効化されているアプリケーションのポート範囲に制限できます。明確に定義されたポート範囲を使用するファイアウォールまたはネットワークでのインストールには、ステート・レプリケーション用のポートを指定する必要があります。
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インスタンスの情報をシステム・コンソールに出力できます。
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インスタンスを指定するシステム・プロパティを説明します。
クラスタリングは、<cluster>
要素のブールのenabled
属性を使用して、グローバルにまたは特定のアプリケーションに対して無効にできます。アプリケーションのorion-application.xml
ファイルでこの属性をfalse
に設定すると、そのアプリケーションはクラスタから事実上削除されます。
<cluster>
要素は、アプリケーションのクラスタリングを管理するための単一の方法です。この要素は、グローバル・レベルのアプリケーションのクラスタリング構成ではORACLE_HOME
/j2ee/
instance
/config/application.xml
ファイルでのみ使用されます。また、アプリケーション・レベルのクラスタリング構成ではアプリケーション固有のorion-application.xml
ファイルで使用されます。
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>
タグが指定されている場合、この属性は無視されます。
JavaGroupsグループ通信プロトコルを使用して、クラスタ内のノード間でセッションの状態をレプリケートするために必要なデータが含まれます。
属性:
適用するレプリケーション・ポリシー。データをレプリケートするタイミングとレプリケート対象のデータを定義します。
属性:
データ・レプリケーションに使用する方式を定義します。指定できる方式は1つのみです。
サブ要素:
<multicast> <peer> <database>
レプリケーションにマルチキャスト通信を使用するために必要な構成が含まれます。これはデフォルトで使用されるプロトコルです。
属性:
ip
: 使用するマルチキャスト・アドレス。OC4Jのデフォルトは230.230.0.1
です。
port
: 使用するマルチキャスト・ポート。OC4Jのデフォルトはポート45566
です。
bind_addr
: バインドするネットワーク・インタフェース・カード(NIC)。この属性は、OC4Jホスト・マシンに複数のネットワーク・カードが装備されており、それぞれに固有のIPアドレスを保持している場合に使用すると便利です。
レプリケーションに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アドレスを保持している場合に使用すると便利です。
Oracle Application Server環境で動的peer-to-peerレプリケーションを使用するようにOC4Jを構成します。
静的peer-to-peer通信を使用する場合にポーリングするノードのホスト名およびポートが含まれます。この要素の1つ以上のインスタンスを<peer>
要素内に指定できます。
属性:
状態データをデータベースに保存するために必要な接続情報が含まれます。
属性:
レプリケーション時にクラスタリング・メッセージの処理に割り当てるメモリー量を制御します。この要素は、レプリケーション時にノード間で送信されるデータ量(バイト単位)をゲートして、メモリー不足エラーを防止することを目的としています。
属性:
enabled
: フロー制御が有効かどうかを指定します。デフォルトはtrue
です。
max-bytes
: 受信ノードが受け入れることができる最大バイト数。この値に達すると、追加メッセージを送信できるようになるまで、送信ノードは受信側からの確認応答を待機する必要があります。デフォルト値は、500000
です。
min-bytes
: 送信するバイト数を多くする必要があるという確認応答をトリガーせずに、受信ノードが受け入れることができる最小バイト数。受信済バイト数がこの値を下回る場合、送信側から受け入れることができるバイト数がさらに多いことを受信側は確認応答します。デフォルトは0
です。
threshold
: min-bytes
が指定されない場合に、その属性値を決定するために、この係数値が受信リクエストに適用されます。デフォルト値は、0.25
です。
指定した場合、アプリケーション・データをレプリケートするノードは、データ更新を受信したという他の1つ以上のピア・ノードからの確認応答を待機してから、レプリケーションを続行します。この要素は任意です。デフォルトの動作では、ノードは他のノードにデータを非同期的にレプリケートし続けます。
属性:
|
Copyright © 2006, 2008 Oracle Corporation. All Rights Reserved. |
|