10g リリース2（10.1.2）
B15817-04
 目次 |
 索引 |
| Oracle Application Server 高可用性ガイド 10g リリース2（10.1.2） B15817-04 |
|
この章では、Oracle Application Server中間層を障害から保護するソリューションについて説明します。この章の項は次のとおりです。
Oracle Application Server中間層は、次の2種類の冗長性を提供するように構成できます。
Oracle Application Server中間層では、OracleAS Cluster（中間層）を使用してアクティブ/アクティブ構成で冗長性を実現できます。OracleAS Cluster（中間層）は、アクティブ/アクティブ構成で動作し、シングル・インスタンスよりも高いスケーラビリティと可用性を実現するように構成された中間層インスタンスのセットです。OracleAS Cluster（中間層）を使用すると、シングル・インスタンスで発生するシングル・ポイント障害を回避できます。単一のOracle Application Serverインスタンスでは、単一ホストのリソースを利用しますが、クラスタでは複数のホストにわたって、多数のCPUにアプリケーションの実行を分散できます。単一のOracle Application Serverインスタンスは、ホストおよびオペレーティング・システムの障害に対して脆弱ですが、クラスタではオペレーティング・システムまたはホストの損失が発生しても引き続き機能します。クライアントがこれらの障害の影響を受けることはありません。
図3-1は、冗長アクティブ/アクティブ構成でのOracle Application Server中間層の様々なサブ層を示しています。各サブ層は冗長プロセスで構成され、これらのどのプロセスで障害が発生しても、これがプロセス上のサブ層で処理され、クライアントからのリクエストがその障害の影響を受けないようになっています。
次の項目では、各サブ層のアクティブ/アクティブ構成の特徴となる機能について説明します。
OracleAS Web Cacheの複数のインスタンスが、互いに影響を与えることなく、それぞれ独立したキャッシュとして実行されるように構成することができます。ただし、Webキャッシュの可用性とスケーラビリティを向上させるには、OracleAS Web Cacheの複数のインスタンスが1つのキャッシュ・クラスタ（OracleAS Cluster（Web Cache）と呼ばれます）のメンバーとして実行されるように構成します。キャッシュ・クラスタとは、1つの論理キャッシュを提供するために、協調して動作するように疎結合されたOracleAS Web Cacheのインスタンスの集まりです。
このキャッシュは、物理的に複数のノード間に分散できます。あるノードで障害が発生しても、障害が発生したノードが処理していたリクエストを、同じクラスタ内の残りのノードで処理できます。ノードの障害はクラスタ内の残りのノードによって検出されます。これらのノードによって、障害が発生したメンバーのキャッシュ可能なコンテンツの所有権が引き継がれます。OracleAS Web Cacheクラスタの前面に配置されたロード・バランシング・メカニズム（ハードウェアのロード・バランサ機器など）によって、動作中のOracleAS Web Cacheノードにリクエストがリダイレクトされます。
さらに、OracleAS Web Cacheクラスタは、Oracle Application Serverインスタンスの可用性を向上させます。Oracle Application Serverインスタンスの前で静的および動的コンテンツをキャッシュすることにより、OracleAS Web Cacheによるリクエスト処理が可能になります。これにより、特にOracle HTTP Serverに対して、Oracle Application Serverインスタンスでリクエストを処理する必要性を軽減できます。Oracle Application Serverインスタンスの負荷とストレスが減少し、インスタンス内のコンポーネントの可用性が向上します。
OracleAS Web Cacheは、Oracle HTTP Serverに対してステートレスまたはステートフルなロード・バランシング機能を果たすこともできます。ロード・バランシングは、各Oracle HTTP Serverの利用可能容量の割合、つまり、各Oracle HTTP Serverの重み付けされた利用可能容量に基づいて実行されます。重み付けされた利用可能容量が複数のOracle HTTP Server間で等しい場合、OracleAS Web Cacheはラウンドロビンを使用して負荷を分散します。重み付けされた利用可能容量を計算する式については、『Oracle Application Server Web Cache管理者ガイド』を参照してください。
表3-1は、OracleAS Web Cacheの高可用性の特徴を要約したものです。
Oracle HTTP Serverインスタンスで障害が発生すると、OracleAS Web Cacheは残りのOracle HTTP Serverに負荷を再分散し、障害が発生したサーバーがオンラインに復帰するまでこのサーバーを断続的にポーリングします。その後、OracleAS Web Cacheは、スコープ内の回復したOracle HTTP Serverで負荷分散を再計算します。
Oracle HTTP ServerおよびOracleAS Web Cacheでは、HTTPリクエストおよびHTTPSリクエストが処理されます。リクエストされたコンテンツがキャッシュされている場合は、Oracle HTTP ServerまたはOracleAS Web Cacheからのレスポンスによって各HTTPリクエストを処理することが可能です。
Oracle HTTP Serverでは、受信したリクエストのタイプに応じて、異なるプラングイン・モジュールにリクエストがルーティングされます。その後、そのリクエストはこれらのモジュールから様々なタイプのプロセスに委譲されます。最も一般的なモジュールは、J2EEアプリケーションのmod_oc4jとPL/SQLアプリケーションのmod_plsqlです。mod_oc4jではOC4Jプロセスにリクエストが委譲されます。mod_plsqlではデータベース・プロセスにリクエストが委譲されます。これらすべてのタイプのリクエストについて、Oracle HTTP Serverプロセスで保持する必要のある状態はありません。
この項の項目は次のとおりです。
表3-2は、Oracle HTTP Serverに対するOracle Application Serverの高可用性機能の要約を示しています。
Oracle HTTP Serverのモジュールmod_oc4jは、OC4Jにより処理されるHTTPリクエストに対してルーティングを提供します。mod_oc4j.confで指定されたマウント・ポイントの1つに一致するURLに対するリクエストを受信した場合、リクエストはそのURLに対して指定された使用可能な宛先の1つにルーティングされます。宛先は、単一のOC4Jプロセスの場合もあれば、一連のOC4Jインスタンスの場合もあります。OC4Jプロセスで障害が発生すると、OPMNはその障害を検出し、mod_oc4jは、障害の発生したOC4Jプロセスが再起動されるまでそのOC4Jプロセスにリクエストを送信しません。
mod_oc4jの構成オプションを使用すると、必要なルーティングのタイプと複雑さに応じて、異なるロード・バランシング・ルーティング・アルゴリズムを指定できます。ステートレス・リクエストは、mod_oc4j.confで指定されたアルゴリズムに基づいて使用可能な宛先にルーティングされます。ステートフルHTTPリクエストは、セッションIDを使用して前回のリクエストを処理したOC4Jプロセスに転送されます。ただし、mod_oc4jがOPMNとの通信によってそのプロセスが使用不可であると判断した場合を除きます。その場合、mod_oc4jは、指定されたロード・バランシング・プロトコルに従って使用可能なOC4Jプロセスにそのリクエストを転送します。
表3-3は、mod_oc4jが提供するルーティング・スタイルの要約を示しています。表3-3には、ルーティング・スタイルごとに各種のアルゴリズムが記載されています。これらのアルゴリズムを構成することにより、ルーティングの動作を変更できます。これらのmod_oc4j構成オプションによって、mod_oc4jが処理対象の受信したHTTPリクエストを送信するOC4Jプロセスが決まります。
|
関連項目
|
mod_oc4jオプションを使用すると、OC4Jリクエストをルーティングするためのルーティング方法を選択できます。ラウンドロビンまたはランダム・ルーティングを選択した場合、ローカル・アフィニティまたは重み付けされたルーティング・オプションも使用できます。メトリックベース・ルーティングを選択した場合は、ローカル・アフィニティ・オプションも使用できます。
重み付けされたルーティング・オプションを使用すると、mod_oc4jのノード別の構成に基づいて、ノード上のOC4Jプロセスに重みが関連付けられます。リクエストのルーティング時、mod_oc4jは、ルーティングの重みを使用してリクエストの割当て先となるOC4Jプロセスを決定します。このように、異なるノードで実行されているOC4Jプロセスに異なる重みを割り当てることができます。
ローカル・アフィニティ・オプションを使用すると、リクエスト処理に使用できるOC4Jプロセスの2つのリスト（ローカル・リストとリモート・リスト）がmod_oc4jによって保持されます。ローカル・リストのプロセスが使用可能な場合、リクエストはランダム・ルーティング法によってローカルに割り当てられます。メトリックベース・ルーティングでは、メトリックベース・ルーティングが使用されます。ローカル・リストに使用可能なプロセスがない場合、mod_oc4jは、ランダム法ではリモート・リストから無作為にプロセスを選択します。ラウンドロビン・ルーティングではラウンドロビン法、メトリックベース・ルーティングではメトリックベース法が使用されます。
表3-3に、使用可能なルーティング・オプションの要約を示しています。mod_oc4jで構成するルーティング・アルゴリズムを選択するには、Oracle HTTP Serverの実行環境のタイプについて考慮する必要があります。mod_oc4jで使用する構成オプションを決定する際、次のガイドラインが役に立ちます。
関連項目
mod_plsqlはデータベースへの接続プールを保持し、確立されたデータベース接続を後続のリクエストに再使用します。接続プールのデータベース接続からレスポンスがない場合、mod_plsqlはそれを検出し、そのデッド接続を破棄し、後続のリクエストのために新しいデータベース接続を作成します。
mod_plsqlによるデータベースへのデッド接続の検出機能によって、データベース・ノードまたはインスタンスが停止した場合のエラーの発生が防止されます。この機能は、Real Application Clustersのような高可用性構成で特に便利です。Real Application Clustersデータベースのノードに障害が発生した場合、mod_plsqlがそれを検出し、ただちに他のReal Application Clustersノードを使用してリクエストの処理が開始されます。mod_plsqlには、保護やパフォーマンスのニーズを最大限に満たすための様々な構成オプションが用意されています。デフォルトでは、mod_plsqlは、障害を検出する前に確立され、プールされたデータベース接続をすべてテストしますが、リクエストの発行前にプールされたデータベース接続のすべてを定期的に検証することもできます。
OC4J層は、J2EEコンテナのOracle Application Serverの実装で構成されています。この項では、各種OC4Jコンポーネントの可用性を高める方法について説明します。この項の項目は次のとおりです。
Oracle Application Serverでは、複数の方法でOC4Jインスタンスの高可用性を実現できます。高可用性は、アプリケーション・サーバー・インスタンス内と、複数のアプリケーション・サーバー・インスタンスで構成されるクラスタ全体の両方で提供されます。
この項で説明する高可用性機能に加えて、Oracle Application Serverの他の機能でOC4Jプロセスの高可用性を実現することもできます。これらの機能には、Oracle HTTP Serverのロード・バランシング機能や、プロセスの監視と再起動を自動的に行うOracle Process Manager and Notification Serverシステムなどがあります。
次の項では、OC4Jインスタンスでステートフル・アプリケーションに対する高可用性を確保するための方法について説明します。全部で2つの方法があります。
ステートフルWebアプリケーションをOC4Jにデプロイすると、場合によっては、同じクライアントからの複数のHTTPリクエストがこのアプリケーションにアクセスする必要が生じます。一方、OC4Jサーバーで実行中のアプリケーションでOC4Jプロセスの障害が発生すると、クライアント・リクエストに関連付けられている状態が失われる恐れがあります。こうした障害から保護する方法が2つあります。
OC4Jインスタンスは、J2EEアプリケーションがデプロイおよび構成される実体です。OC4Jインスタンスは、特定のセットのバイナリおよび構成ファイルによって特徴付けられます。いくつかのOC4Jプロセスは、OC4Jインスタンスごとに起動できます。OC4Jプロセスとは、OC4JインスタンスのJ2EEアプリケーションを実行するものです。アプリケーション・サーバー・インスタンス内で、複数のOC4Jインスタンスを、それぞれが固有の数のOC4Jプロセスを持つように構成できます。クラスタ内の各OC4Jプロセスに対して構成を管理したり、アプリケーションをデプロイする際にこれは有利です。
OC4JプロセスをOracleAS Cluster（OC4J）にグループ化すると、セッション状態レプリケーションがサポートされ、Webアプリケーションの高可用性を実現できます。OracleAS Cluster（OC4J）をmod_oc4jリクエスト・ルーティングとともに使用すると、ソフトウェアまたはハードウェアに問題が発生したときにステートフル・フェイルオーバーを利用できます。たとえば、OracleAS Cluster（OC4J）の一部であるOC4Jプロセスで障害が発生すると、OPMNによってこの障害がmod_oc4jに通知され、リクエストはmod_oc4jによって同じクラスタ内の別のOC4Jプロセスにルーティングされます。
クラスタ内の各OC4Jインスタンスには、次の特徴があります。
OC4Jプロセスの障害やハングなどのソフトウェアの問題から保護するには、同じOracleAS Cluster（OC4J）内で複数のOC4Jプロセスを実行するようにOC4Jインスタンスを構成します。OracleAS Cluster（OC4J）内のプロセスは、それぞれのセッション状態を相互に伝達します。この構成を使用すると、アプリケーション・サーバー・インスタンスで実行している複数のOC4Jプロセス間で状態をレプリケートすることにより、フェイルオーバーと高可用性が実現します。
障害が発生した場合、Oracle HTTP Serverは、OracleAS Cluster（OC4J）内のアクティブな（動作中の）OC4Jプロセスにリクエストを転送します。この場合、クライアントのWebアプリケーション状態は維持されます。サービスの損失はクライアントからは見えません。
図3-2は、アプリケーション・サーバー・インスタンス内で発生するこのタイプのソフトウェア障害と、障害が発生していない残りのプロセスへのフェイルオーバーを示しています。
アプリケーション・サーバー・インスタンスを実行しているノードの障害など、ハードウェアの問題から保護するには、OracleAS Cluster内の複数ノードにあるアプリケーション・サーバー・インスタンス間でOracleAS Cluster（OC4J）を構成します。複数のアプリケーション・サーバー・インスタンスで同じ名前を使用するようにOracleAS Cluster（OC4J）を構成すれば、OC4Jプロセスは、OracleAS Cluster（OC4J）全体でセッション状態の情報を共有できます。アプリケーション・サーバー・インスタンスを実行しているノードの停止など、アプリケーション・サーバー・インスタンスに障害が発生したか、または使用できなくなったときは、Oracle HTTP Serverが、使用可能なアプリケーション・サーバー・インスタンスのOC4Jプロセスにリクエストを転送します。このように、Oracle HTTP Serverでは、クラスタ内のアクティブな（動作中の）OC4Jプロセスにのみリクエストが転送されます。
この場合、クライアントのWebアプリケーション状態は維持されます。クライアントが異常に気付くことはありません。
図3-3は、2つのOracle Application Serverインスタンスにわたって構成されたOracleAS Cluster（OC4J）を示しています。この構成により、OracleAS Cluster（OC4J）におけるWebアプリケーションのセッション状態レプリケーションのフェイルオーバーが可能になります。
最小のOC4Jプロセス数を維持しつつ、ソフトウェアまたはハードウェア障害から保護するには、同じクラスタ内に少なくとも2つのOC4Jプロセスを構成する必要があります。たとえば、インスタンス1とインスタンス2の2つのアプリケーション・サーバー・インスタンスがある場合は、それぞれのアプリケーション・サーバー・インスタンスのdefault_island内に2つのOC4Jプロセスを構成できます。この構成では、ステートフル・セッションのアプリケーションがハードウェアおよびソフトウェア障害から保護され、次のいずれかのタイプの障害が発生しても、クライアントの状態は維持されます。
default_island内の他方のOC4Jプロセスにクライアント・リクエストがリダイクレクトされます。状態は維持され、クライアントが異常に気付くことはありません。
default_island内のOC4Jプロセスにクライアントがリダイクレクトされます。状態は維持され、クライアントが異常に気付くことはありません。ステートフル・セッションEJBを構成して、アプリケーション・サーバー・インスタンスに関連付けられたOC4Jプロセス間またはOracleAS Cluster間で状態をレプリケートできます。このEJBレプリケーション構成では、複数のOC4Jプロセスで同じステートフル・セッションEJBのインスタンスを実行することにより、ステートフル・セッションEJBの高可用性が実現します。
OracleAS Cluster（OC4J-EJB）では、ステートフル・セッションEJBの高可用性が実現します。EJBクラスタでは、同じマルチキャスト・アドレス経由で通信する複数のOC4Jプロセス間でこれらのEJBをフェイルオーバーできます。このように、ステートフル・セッションEJBでレプリケーションを使用すると、プロセスとノードの障害から保護し、Oracle Application Serverで実行されているステートフル・セッションEJBの高可用性を実現できます。
|
関連項目
|
EJBクラスタリングを有効にすると、中間層OracleAS ClusterのOC4Jインスタンス間のJNDIネームスペースのレプリケーションも有効になります。1つのOC4Jインスタンス内のJNDIネームスペースへの新規バインドは、中間層OracleAS Cluster内の他のOC4Jインスタンスに伝播されます。再バインドとアンバインドはレプリケートされません。
このレプリケーションは、各OracleAS Cluster（OC4J）の有効範囲外で行われます。つまり、OC4Jインスタンス内の複数のOracleAS Cluster（OC4J）は、同じレプリケート済JNDIネームスペースへの可視性を持ちます。
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ポートを自動的に取得します。ロード・バランシングとクライアント・リクエスト・ルーティングは、OPMNで使用可能な異なるOC4Jプロセスを選択することによって提供されます。このロード・バランシングには、ランダム・アルゴリズムが使用されます。高可用性を確保するために、複数のOPMN URLをカンマで区切って使用できます。
Oracle Application Server Java Object Cacheでは、OC4Jにデプロイされたアプリケーションに対する高可用性ソリューションとして機能する分散キャッシュが提供されます。Java Object Cacheは、あらゆるJavaプラットフォーム上のあらゆるJavaアプリケーションで使用可能なJavaオブジェクトのインプロセス・キャッシュです。これにより、アプリケーションで、複数のリクエストおよびユーザー間でオブジェクトを共有し、複数のプロセス間でオブジェクトのライフサイクルを調整することが可能になります。
Java Object Cacheは、同じOracleAS Cluster（OC4J）、アプリケーション・サーバー・インスタンスまたは全般的なOracle Application Server Clusterに属していないプロセスも含めた、OC4Jプロセス間でのデータ・レプリケーションを可能にします。
Java Object Cacheを使用すると、オブジェクトの生成元のアプリケーションがどれであるかにかかわらず、共有Javaオブジェクトがローカルにキャッシュされるため、パフォーマンスが向上します。これにより、可用性も向上します。オブジェクトのソースが使用できなくなっても、ローカルにキャッシュされたバージョンは引き続き使用できます。
Oracle Application Serverでは、2つのJMSプロバイダを使用できます。実装が異なるため、それぞれのプロバイダが高可用性を実現する方法は異なります。したがって、それらについては次の2つの項で説明します。
Oracle Application Server JMS（OracleAS JMS）は、OC4Jで実装されます。したがって、OPMNを利用してプロセスの監視および再起動を行います。
Oracle JMS（OJMS）は、Oracle Streams Advanced Queuing（AQ）を使用して実装されています。これには、Oracleデータベースが必要で、Real Application Clustersデータベースおよび透過的アプリケーション・フェイルオーバー（TAF）機能を使用してアクティブ/アクティブの可用性を実現できます。
表3-4は、2つのJMSプロバイダの高可用性と構成の特徴の概要を示しています。この表に続く各項では、各プロバイダについて詳しく説明します。
次の項では、各JMSプロバイダによる高可用性の実現方法について説明します。
OracleAS JMSの高可用性は、OC4Jの複数のインスタンスを1つのクラスタにグループ化することによって実現できます。このクラスタをOracleAS Cluster（OC4J-JMS）と呼びます。OPMNを使用して、OC4Jプロセスを監視し、プロセスに障害が発生したときに再起動することができます。
OracleAS Cluster（OC4J-JMS）によって提供される環境では、その環境にデプロイされたJMSアプリケーションは、複数のOC4Jインスタンスまたはプロセス間でJMSリクエストをロード・バランシングできます。冗長性も確保でき、1つのOC4Jインスタンスに障害が発生しても、JMSサーバーで使用可能な他のOC4Jインスタンスが少なくとも1つあるため、JMSサービスの可用性に影響を与えることはありません。
JMSクライアントとJMSサーバーの両方が、互いの状態を保持します。これには接続、セッションおよび永続サブスクリプションに関する情報も含まれます。アプリケーション開発者は、環境を構成して、アプリケーションを記述するときにいくつかの簡単な手法を使用することで、それらをクラスタフレンドリーにすることができます。
OracleAS Cluster（OC4J-JMS）では、次の2つの構成が可能です。
この構成では、複数のOC4Jインスタンスが必要です。各インスタンスにはJMSサーバー、キュー宛先およびアプリケーションが含まれています。他のOC4Jインスタンス内のJMSサーバー、キューおよびアプリケーションの間にはプロセス間通信はありません。各アプリケーションの送信側と受信側は、1つのOC4Jインスタンスにともにデプロイされている必要があります。1つのOC4JプロセスのJMSサーバーにエンキューされたメッセージは、そのOC4Jプロセスからのみデキューできます。
この構成には、次の長所があります。
この構成の短所は、1つのJMSサーバーから別のサーバーへのフェイルオーバーがないことです。
この構成では、1つのOracleAS Cluster（OC4J-JMS）で1つのOC4Jインスタンスのみが専用JMSサーバーを持ちます。JMSサーバーを持つOC4Jインスタンスがすべてのメッセージを処理します。単一JMSサーバーによって、メッセージの順序付けが常に保持されます。すべてのJMSアプリケーションがこの専用サーバーを使用して、それらの接続ファクトリと宛先をホスティングし、エンキューおよびデキューのリクエストを処理します。
OracleAS Cluster（OC4J-JMS）内のすべてのJMSアプリケーションに対して、専用JMSサーバーとして機能するOC4J JVMは1つのみです。単一JVMによって、他のJVMが同じセットの永続ファイルを使用しないことが保証されます。他のOC4Jは、アプリケーションの実行のみを行います。単一JMSサーバーは、opmn.xmlファイルのJMSポート範囲を専用OC4Jインスタンスの1つのポートにのみ制限することによって構成できます。単一のポート値によって、OPMNが常に同じポート値を専用JMSサーバーに割り当てることが保証されます。このポート値は、OracleAS Cluster（OC4J-JMS）の他のOC4Jインスタンスが専用JMSサーバーへの接続に使用するjms.xmlファイルの接続ファクトリを定義するために使用されます。
この専用JMSサーバー構成のためのopmn.xmlファイルの変更方法の詳細は、『Oracle Application Server Containers for J2EEサービス・ガイド』の「JMS」を参照してください。
Oracle JMS（OJMS）の高可用性は、Real Application Clustersデータベースを使用して実現できます。AQキューおよびトピックが、Real Application Clusters環境で使用可能である必要があります。
Oracle Application Serverの各JMSアプリケーションは、OC4Jリソース・プロバイダを使用して、バックエンドのReal Application Clustersデータベースを指定します。これらのリソース・プロバイダから導出されたオブジェクト上で起動されたJMS操作は、そのデータベースに送られます。
Real Application Clustersデータベースを使用するOJMSアプリケーションは、データベース・フェイルオーバー・シナリオを処理できる必要があります。次の2つのフェイルオーバー・シナリオが考えられます。
データベース・インスタンスに障害が発生した場合、Real Application Clustersデータベースに対して実行されているスタンドアロンのOJMSアプリケーションには、再度接続を取得し、接続オブジェクトが無効であるかどうかを判断するためのコードが必要です。そのコードでは、必要に応じて接続を再確立する必要があります。接続オブジェクトが無効かどうかを判断するには、APIメソッドcom.evermind.sql.DbUtil.oracleFatalError()を使用します。無効な場合の適切な対処方法は、トランザクションをロールバックし、接続、セッション、メッセージなど失われたJMS状態を再作成することです。コードの例については、『Oracle Application Server Containers for J2EEサービス・ガイド』の「JMS」を参照してください。
透過的アプリケーション・フェイルオーバー（TAF）が構成されていると、多くの場合、OJMSアプリケーションがその接続先のデータベース・インスタンスの障害を感知することはありません。したがって、アプリケーション・コードで障害を処理するタスクを実行する必要はありません。
ただし、場合によっては障害が発生したときにOC4JがORAエラーをスローすることがあります。OJMSは、これらのエラーを、リンクされたSQL例外とともにJMSExceptionとしてアプリケーションに渡します。これらの例外は、次のように処理できます。
com.evermind.sql.DbUtil.oracleFatalError()を使用するコードを記述します。その場合、前述の項目で示した方法に従ってください。それ以外の場合は、クライアントは、短期間のスリープ後に起動し、最後の操作を再試行することによってリカバリできます。
次に、クラスタリングされたJMSサーバーを操作するためのベスト・プラクティスのガイドラインを示します。
JMSExceptionで失敗します。
中間層のアクティブ/パッシブ型の高可用性は、コールド・フェイルオーバー・クラスタによって実現されます。これについては、次の項で説明します。
2つのノードを持つOracleAS Cold Failover Cluster（中間層）を使用して、Oracle Application Serverの中間層コンポーネントのアクティブ/パッシブ型の可用性を実現できます。OracleAS Cold Failover Cluster（中間層）では、1つのノードはアクティブで、もう1つのノードはパッシブ（スタンバイ）になります。アクティブ・ノードで障害が発生した場合、スタンバイ・ノードがアクティブになり、中間層コンポーネントは引き続きそのノードからクライアントのリクエストを処理できます。すべての中間層コンポーネントは、新しいアクティブ・ノードにフェイルオーバーされます。フェイルオーバー後は、障害が発生したノードで中間層コンポーネントは実行されません。
OracleAS Cold Failover Cluster（中間層）ソリューションでは、仮想ホスト名と仮想IPが2つのノード間で共有されます（仮想ホスト名はサブネットの仮想IPにマッピングされます）。ただし、これらの仮想設定を使用するノードは、常に1つのアクティブ・ノードのみです。アクティブ・ノードに障害が発生し、スタンバイ・ノードがアクティブになると、仮想IPが新しいアクティブ・ノードに移行します。仮想IPへのすべてのリクエストは、新しいアクティブ・ノードで処理されるようになります。
OracleAS Cold Failover Cluster（中間層）は、OracleAS Cold Failover Cluster（Infrastructure）ソリューションと同じマシンを使用できます。このシナリオでは、仮想ホスト名と仮想IPの2つのペアが使用されます。1つのペアは中間層のコールド・フェイルオーバー・クラスタ用、もう1つのペアはOracleAS Cold Failover Cluster（Infrastructure）ソリューション用です。図9-10に、このような使用例を示します。この設定では、中間層コンポーネントはOracleAS Infrastructureに依存せずにフェイルオーバーできます。
中間層のOracleホームは、共有記憶域（1つのOracleホームができる）または各ノードのローカル記憶域（2つの個別のOracleホームができる）にインストールできます。次に、いくつかのガイドラインを示します。
中間層のコールド・フェイルオーバー・クラスタの場合、OracleAS JMSのファイルベースの永続性を使用していないかぎり、共有記憶域は必要ありません。ただし、操作上の理由により、共有記憶域を使用することを強くお薦めします。使用しないと、管理上の変更を行うたびに、変更内容を各Oracleホームに1回ずつ、計2回適用することが必要になります。
各ノードには、中間層ソフトウェアに対する同一のマウント・ポイントが必要です。中間層ソフトウェアの1つのインストールを各ノードで実行し、両方のインストールで同じローカルのOracleホームへのパスを指定する必要があります。
|
注意 OracleAS Cold Failover Cluster（中間層）のインストール手順は、Oracle Application Serverのインストレーション・ガイドを参照してください。その管理手順は、第4.5項「OracleAS Cold Failover Cluster（中間層）の管理」を参照してください。 |
このソリューションに対する一般的な配置は、1つのノードでOracleAS Infrastructureを実行し、もう1つのノードでOracle Application Server中間層を実行する2つのノードを持つハードウェア・クラスタです。ハードウェアまたはソフトウェアのメンテナンスまたはクラッシュのためにいずれかのノードを停止する必要がある場合、残りのノードをオンラインにし、OracleAS InfrastructureまたはOracle Application Server中間層サービスをそのノードで起動できます。
ただし、一般的な中間層のコールド・フェイルオーバーの配置では共有記憶域が必要ないので（OracleAS JMSファイルの永続性が使用されている場合を除く）、代替の配置として、サブネットに2つのスタンドアロン・マシンを用意し、それぞれに中間層ソフトウェアをローカルでインストールし、それらの間でフェイルオーバーできる仮想IPを持たせることができます。
スタンバイ・ノードにフェイルオーバーするための全体的な手順は、次のとおりです。
フェイルオーバー管理のために、次の2つの方法を使用できます。
Cluster Managerが提供するサービスにより、サービスの状態を監視するパッケージの開発が可能になります。サービスまたはノードが停止していることが検出された場合、もう1つのノードへ自動的にサービスがフェイルオーバーされます。特定のノードでフェイルオーバーする前にサービスの再起動を試みるパッケージを開発できます。
この方法では、前述のフェイルオーバー手順を手動で実行します。この方法では障害の検出とフェイルオーバー自体を両方手動で行うので、サービスを利用できない期間が長くなることがあります。
OracleAS JMSは、2つのノードを持つOracleAS Cold Failover Cluster（中間層）環境を利用することによってアクティブ/パッシブ構成で配置できます。そのような環境では、アクティブ・ノードのOC4JインスタンスがOracleAS JMSサービスを提供し、その間、パッシブ・ノードのOC4Jインスタンスは非アクティブになっています。OracleAS JMSのファイルベースの永続性データは共有ディスクに保存されます。
アクティブ・ノードに障害が発生すると、OracleAS JMSサービスとメッセージの保持に使用される共有ディスクを含めて中間層環境全体がパッシブ・ノードにフェイルオーバーされます。パッシブ・ノードのOC4Jインスタンスは、中間層環境で実行される他のプロセスとともに起動されます。この時点で、このノードが新しいアクティブ・ノードになります。OracleAS JMSリクエストは、これ以降このノードによって処理されます。
この項では、構成管理によって中間層の高可用性を向上させる方法について説明します。この項の項目は次のとおりです。
Distributed Configuration Management（DCM）は、複数のOracle Application Serverインスタンスの構成管理を可能にする管理フレームワークです。DCMを使用して管理されるOracleAS Clusterを管理するには、Application Server Controlコンソールまたはdcmctlコマンドのいずれかを使用して、1つのOracle Application Serverインスタンスの共通の構成情報を管理および構成します。DCMでは、OracleAS Cluster内のすべてのOracle Application Serverインスタンスで共通の構成情報がレプリケートされます。そのクラスタで共通の構成情報はクラスタレベルの構成といいます。
この項の項目は次のとおりです。
DCM-Managed OracleAS Clusterでは、構成情報の分散が可能であるため、複数のOracle Application Serverインスタンスを一度に構成できます。
DCM-Managed OracleAS Clusterの特徴は次のとおりです。
web.xmlファイルで「distributable」とマークする必要があり、マルチキャスト・レプリケーションをOC4Jインスタンスのレプリケーション・プロパティで有効にする必要があります。
opmnctlが有効になります。
DCM-Managed OracleAS Cluster内の各アプリケーション・サーバー・インスタンスの基本構成は同じです。基本構成には、クラスタレベルの構成は含まれていますが、インスタンス固有のパラメータは含まれていません。
Oracle Application Serverの高可用性では、Oracle Application Server Cluster内のシステムが停止しても、DCMのシングル・ポイント障害は発生しません。DCMは、クラスタ内の使用可能な全ノードで引き続き使用できます。
DCMを使用すると、クラスタ内のデプロイおよび構成エラーを減らすことができます。DCMを使用しない場合、これらのエラーはシステムの停止をもたらす大きな原因になることがあります。
Application Server Controlコンソールでは、DCMコマンドを使用して構成と配置を行います。dcmctlコマンドを使用して、DCMコマンドを発行することもできます。
DCMでは、次の構成コマンドを使用できます。
クラスタの構成変更またはクラスタへのアプリケーションのデプロイを行う際は、次の点に留意してください。
dcmctlを実行します。Oracle Application Serverでは、データベースベースとファイルベースの2つのタイプのDCM構成リポジトリがサポートされます。DCM構成リポジトリには、OracleAS Farmのインスタンスに関連する構成情報とメタデータが格納され、OracleAS FarmにDCM-Managed OracleAS Clusterが含まれている場合、クラスタ全体の構成情報と、DCM-Managed OracleAS Cluster内にあるインスタンスのインスタンス固有のパラメータが両方格納されます。
Manually-Managed OracleAS Clusterでは、OracleAS Cluster内のOracle Application Serverインスタンスの構成の同期化は、管理者が担当することになります。詳細は、付録B「Manually-Managed OracleAS Cluster」を参照してください。
システムで障害が発生した場合、その障害からのリカバリをできるだけ迅速に行うことが重要です。障害のタイプに応じて、次のタスクのいずれかまたは両方を実行し、中間層インストールをリカバリします。
中間層ファイルのリストアは、『Oracle Application Server管理者ガイド』の「バックアップ計画と手順」に記載されている手順を使用して作成されたバックアップから実行できます。バックアップには、中間層インストールとOracleAS Infrastructureインストールの両方が含まれ、Oracleホームごとに実行されます。したがって、中間層のリストアもOracleホームごとに実行されます。各リストアは、バックアップが作成されたノードで行うことも、新しいノードで行うこともできます。リカバリ用のバックアップの使用の詳細は、『Oracle Application Server管理者ガイド』の「リカバリ計画と手順」に記載されています。
同じノード上の中間層インストールのリストアによって、Oracleホーム、Oracle Application Server構成ファイルおよびDCMリポジトリがリストアされます。Oracleホームと構成ファイルのバックアップは、Oracle Application Serverシステム全体のバックアップである完全なOracle Application Server環境のバックアップを実行した場合に行われます。さらに、必要に応じて、構成ファイルのタイムスタンプ付きバックアップをすべてリストアする必要があります。
新しいノード上の中間層インストールのリストアには、Oracleシステム・ファイル、中間層のOracleホームおよび構成ファイルのリストアが必要です。ホストが新しいので、DCMで管理されているコンポーネントとDCMで管理されていないコンポーネントをホスト情報で更新する必要があります。
|
 Copyright © 2005, 2007 Oracle. All Rights Reserved. |
|