その他のトピック その他のトピック その他のトピック その他のトピック

■ 第3.4.1項「JNDIネームスペースのレプリケーション」

■ 第3.4.2項「EJBクライアント・ルーティング」

■ 第3.4.3項「Java Object Cacheを使用したOC4Jの分散キャッシュ」

表 表 表

表3-5 Oracle HTTP ServerおよびおよびおよびおよびOC4Jにおける高可用性機能の要約における高可用性機能の要約における高可用性機能の要約における高可用性機能の要約 項目項目

項目項目 説明説明説明説明

ノード障害からの保護 Oracle HTTP Server: Oracle HTTP Serverインスタンスの前にデプロイされているロー ド・バランサは、ノードの障害からの保護を提供します。ロード・バランサには、外部 ロード・バランサまたはOracleAS Web Cache（リリース2（10.1.2）のOracleAS Web Cache）を使用できます。

OC4J: mod_oc4jは、動作中のOC4Jインスタンスのみにリクエストをルーティングしま す。OC4Jインスタンスは複数のノードにインストールして実行し、常に少なくとも1つ のノードでOC4Jが動作している確率を高めるようにします。

サービス障害からの保護 Oracle HTTP Server: Oracle HTTP Serverインスタンスの前にデプロイされているロー ド・バランサは、最初のOracle HTTP Serverからレスポンスがない場合や、URLのping の結果からOracle HTTP Serverに障害が発生したと思われる場合、別のOracle HTTP

Serverにリクエストを送信します。ロード・バランサには、外部ロード・バランサまたは

OracleAS Web Cacheを使用できます。

OC4J: OPMNはOC4Jプロセスを監視し、障害発生時にはそのプロセスを再起動します。

またOPMNは、この再起動が成功しなかった場合、動作しているOC4Jプロセスにのみ リクエストを送信するようmod_oc4jに通知します。

プロセス障害からの保護 Oracle HTTP Server: OPMNはOracle HTTP Serverプロセスを監視し、障害発生時にそ のプロセスを再起動します。さらに、トポロジ内の別のOracle HTTP Serverプロセスで 障害が発生した場合、OPMNはそれぞれのOracle HTTP Serverに障害を通知します。

OC4J: OPMNはOC4Jプロセスを監視し、障害発生時にはそのプロセスを再起動します。

またOPMNは、この再起動が成功しなかった場合、動作しているOC4Jプロセスにのみ リクエストを送信するようmod_oc4jに通知します。

自動再ルーティング Oracle HTTP Server: Oracle HTTP Serverインスタンスの前にデプロイされているロー ド・バランサは、最初のOracle HTTP Serverからレスポンスがない場合、別のOracle

HTTP Serverにリクエストを自動的に再ルーティングします。

OC4J: mod_oc4jは、最初のOC4Jプロセスからレスポンスがない場合、別のOC4Jプロセ スにリクエストを自動的に再ルーティングします。

関連項目関連項目 関連項目関連項目:

■ 第2.1項「OPMNでのプロセス管理」

3.4.1 JNDI ネームスペースのレプリケーション ネームスペースのレプリケーション ネームスペースのレプリケーション ネームスペースのレプリケーション

EJBクラスタリングを有効にすると、中間層OracleAS ClusterのOC4Jインスタンス間のJNDI ネームスペースのレプリケーションも有効になります。1つのOC4Jインスタンス内のJNDI ネームスペースへの新規バインドは、中間層OracleAS Cluster内の他のOC4Jインスタンスに 伝播されます。再バインドとアンバインドはレプリケートされません。

このレプリケーションは、各OracleAS Cluster（OC4J）の有効範囲外で行われます。つまり、

OC4Jインスタンス内の複数のOracleAS Cluster（OC4J）は、同じレプリケート済JNDIネーム スペースへの可視性を持ちます。

JNDIの詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。

3.4.2 EJB クライアント・ルーティング クライアント・ルーティング クライアント・ルーティング クライアント・ルーティング

EJBクライアント・ルーティングでは、Oracle HTTP ServerとサーブレットおよびJSP間で

mod_oc4jが提供するルーティング機能は、EJBクラスによって実行されます。クライアント

は、Remote Method Invocation（RMI）プロトコルを使用してEJBを起動します。RMIプロト

コル・リスナーは、RMI構成ファイルrmi.xmlによってOC4Jインスタンスごとに設定され ます。これはWebサイト構成とは別です。EJBクライアントとOC4Jツールは、構成された RMIポートを使用してOC4Jサーバーにアクセスします。OPMNによって、RMIリスナーが使 用できる一連のポートが指定されます。

EJBルックアップで「opmn:ormi://」接頭辞文字列を使用すると、クライアントは割り当て られたRMIポートを自動的に取得します。ロード・バランシングとクライアント・リクエス ト・ルーティングは、使用可能な様々なOC4Jプロセスを選択するOPMNによって提供されま す。このロード・バランシングに使用されるアルゴリズムは、ランダム・アルゴリズムです。

高可用性を確保するために、カンマで区切られた複数のOPMN URLを使用できます。

3.4.3 Java Object Cache を使用した を使用した を使用した を使用した OC4J の分散キャッシュ の分散キャッシュ の分散キャッシュ の分散キャッシュ

Oracle Application Server Java Object Cacheでは、OC4Jにデプロイされたアプリケーションに 対する高可用性ソリューションとして機能する分散キャッシュを提供します。Java Object

Cacheは、あらゆるJavaプラットフォーム上のあらゆるJavaアプリケーションで使用可能な

Javaオブジェクトのインプロセス・キャッシュです。これにより、アプリケーションで、複数 のリクエストおよびユーザー間でオブジェクトを共有し、複数のプロセス間でオブジェクトの ライフサイクルを調整することが可能になります。

Java Object Cacheは、同じOracleAS Cluster（OC4J）、Oracle Application Serverインスタンス または全般的なOracle Application Server Clusterに属していないプロセスも含めた、OC4Jプ ロセス間でのデータ・レプリケーションを可能にします。

Java Object Cacheを使用すると、オブジェクトの生成元のアプリケーションがどれであるかに

かかわらず、共有Javaオブジェクトがローカルにキャッシュされるため、パフォーマンスが向 上します。これにより、可用性も向上します。オブジェクトのソースが使用できなくなっても、

ローカルにキャッシュされたバージョンは引き続き使用できます。

Java Object Cacheの使用方法の詳細は、『Oracle Containers for J2EEサービス・ガイド』の

「Java Object Cache」を参照してください。

4

アクティブ アクティブ アクティブ

アクティブ / パッシブ・トポロジ パッシブ・トポロジ パッシブ・トポロジ パッシブ・トポロジ

この章では、アクティブ/パッシブ・トポロジの構成方法と管理方法について説明します。こ の章の項は次のとおりです。

■ 第4.1項「アクティブ/パッシブ・トポロジについて」

■ 第4.2項「アクティブ/パッシブ・トポロジの管理」

■ 第4.3項「アクティブ/パッシブ・トポロジにおけるOracle HTTP ServerおよびOC4Jの高 可用性機能の概要」