10g リリース2（10.1.2）
B15817-04
 目次 |
 索引 |
| Oracle Application Server 高可用性ガイド 10g リリース2（10.1.2） B15817-04 |
|
この章では、次の中間層コンポーネントの高可用性に関する情報を提供します。
通常、ほとんどの中間層コンポーネントがアクティブ/パッシブ・トポロジであるOracleAS Cold Failover Clusterトポロジでサポートされます。ただし、OracleAS Cold Failover Clusterトポロジで実行する際にいくつかの条件を考慮する必要のある中間層コンポーネントがあります。これらのコンポーネントは、次のとおりです。
詳細は、各コンポーネントに関する項を参照してください。
OracleAS Portalは、OracleAS Portalを実行する2つ以上の中間層インスタンスのあるアクティブ/アクティブ・トポロジで実行できます。これらの中間層インスタンスの前面にはロード・バランサがあり、中間層にリクエストを分散します。
このトポロジには、次の2つのバージョンがあります。
| 項目 | タイトル |
|---|---|
|
マニュアル |
『Oracle Application Server Portal構成ガイド』 このマニュアルは、Oracle Application Serverのドキュメント・セットにあります。 |
|
章 |
第5章「拡張構成の実行」 |
|
項 |
「ロード・バランス・ルーターを使用する複数の中間層の構成」 |
Host:フィールドには、クライアントで使用される元のURL（www.myportal.com）が格納されたままです。
httpd.confファイルでは、ServerNameディレクティブが（中間層インスタンスを実行しているノードの物理名ではなく）www.myportal.comに設定されます。
OracleAS Web Cacheのセッション・バインディング機能を使用すると、ユーザー・セッションを特定のオリジナル・サーバーにバインドし、一定期間状態を保持できます。デフォルトのOracleAS Portal中間層で実行されているほとんどすべてのコンポーネントはステートレスですが、セッション・バインディングは次の2つの理由により必要です。
詳細は、『Oracle Application Server Portal構成ガイド』の「手順7: OracleAS Web Cacheでのセッション・バインドの有効化」を参照してください。
高可用性を実現するようにOracleAS Wirelessを構成する方法は、『Oracle Application Server Wireless管理者ガイド』の第14章「ロード・バランシングとフェイルオーバー」を参照してください。
OracleAS Cold Failover Cluster（中間層）トポロジでOracleAS Wirelessを実行するには、各ノードのローカル記憶域に中間層のOracleホームをインストールする必要があります。OracleAS Wirelessは、単一のOracleホーム・インストールではサポートされません（つまり、共有記憶域に中間層のOracleホームをインストールする場合はサポートされません）。
OracleAS Reports Servicesは、Oracle Application Serverのレポート公開コンポーネントです。これは、あらゆるフォーマットでどのような場所でも、あらゆるデータを動的に取得、フォーマットおよび配布する高品質レポートを作成するエンタープライズ・レポート作成サービスです。OracleAS Reports Servicesを使用すると、WebベースとWebベース以外の環境の両方で公開できます。
OracleAS Reports Servicesの詳細は、『Oracle Application Server Reports ServicesレポートWeb公開ガイド』を参照してください。
この項の内容は、次のとおりです。
OracleAS Reports Servicesは、Oracle Application Server中間層インスタンスのプロセスのセットとして実行されます。これらのプロセスでは、クライアントからのリクエストの処理、レポートの準備、データベースへのリクエストの発行およびクライアントへの結果の返信が行われます。OracleAS Reports Servicesの主なプロセスは、次のとおりです。
図5-1に、これらのプロセス間の相互作用を示します。
OracleAS Reports Servicesには、次の高可用性機能が備わっています。
プロセス内Reports Serverは、「urlping-parameters」を使用してOPMNによって管理されます。なんらかの理由によりoc4j_bi_formsインスタンスが再起動した場合は、Reports Serverも再起動して、oc4j_bi_formsインスタンスが有効になったときに使用可能になります。
スタンドアロンのReports Serverは、OPMNによってコンポーネントとして管理されます。Reports Serverに障害が発生するか、Reports Serverが予期せず停止した場合、OPMNはこれを自動的に再起動します。インストール時に、デフォルトのReports ServerはOPMNによって管理されるよう自動的に構成されます。新しく追加したReports Serverは、OPMNで管理できるように手動で構成する必要があります。これらの構成手順は、ドキュメントに記載されています。
Reports Bridgeを使用する場合も、OPMNで管理できるようにこれを構成する必要があります。Reports BridgeをOPMNで構成する手順は、ドキュメントに記載されています。
OracleAS Reports Servicesが接続しようとしているコンポーネントが使用不可の場合に、OracleAS Reports Servicesでは次の機能が使用されます。
Reports ServerからOracleAS Portalデータベース・スキーマへの接続がなんらかの理由により切断された場合、Reports Serverはエラーを生成する前に接続を再確立しようとします。Reports Serverは、OracleAS Metadata RepositoryからOracleAS Portal接続文字列を取得し、再接続を試行します。再接続が成功した場合は、Reports Serverの再起動は不要です。
Oracle Internet Directoryへの接続がなんらかの理由により失効した場合、Reports ServletおよびReports Serverは、エラーを生成する前に接続を再確立しようとします。再接続が成功した場合は、Reports Serverの再起動は不要です。
（セキュリティ・メタデータが格納されている）OracleAS Metadata Repositoryの停止によって、Reports Serverが停止することはありません。OracleAS Metadata Repositoryが使用不可の場合、Reports Serverはいずれかのコンポーネントが使用不可であることを理由に新しいリクエストを拒否します。OracleAS Metadata Repositoryがオンラインに戻ると、Reports Serverはリカバリし、新しいリクエストの受信と処理を始められます。
Oracle Identity Managementコンポーネントがなんらかの理由により使用できなくなった場合も、Reports Serverは新しいリクエストを拒否します。Reports Serverでは、OracleAS Metadata Repositoryの停止の場合と同様の対応が行われます。
Reports Serverでは、データベースからリクエストが返されるまで待機する際のタイムアウトを構成できます。このタイムアウトは、有効なレポートを実行できるだけ十分高い値に設定する必要がありますが、過度に長く待機するほど高くはならないようにします。タイムアウトは、ORACLE_HOME/reports/conf/<サーバー名>.confファイルのconnection要素のidleTimeOut属性で構成できます。
図5-2に示すように、OracleAS Reports Servicesをアクティブ/アクティブ構成で実行できます。この場合、Oracle Application Server中間層インスタンスが複数あり、各インスタンスで固有のReports ServletとReports Serverが実行されます。Oracle HTTP Serverの前面に配置されているロード・バランサによって、リクエストがインスタンスに分散されます。
すべてのReports Servletが、1つのデフォルトのReports Serverにバインドされます。個々のレポート・リクエストに対して特定のReports Serverを指定することができますが、デフォルトのReports Serverが使用不可の場合に代替のReports Serverを指定する方法はありません。
インスタンスに障害が発生した場合は、ロード・バランサが障害を検出し、残りのアクティブなインスタンスにすべてのリクエストをルーティングします。
アクティブ/アクティブ構成ではWebクライアントのみがサポートされます。コマンドライン・クライアントrwclientは、サポートされません。これは、rwclientは名前で特定のReports Serverに接続しますが、特定のReports Serverについて名前付きのインスタンスが1つしかない場合があるためです。高可用性環境でrwclientを実行するには、アクティブ/パッシブ構成を使用します。第5.4.4項「アクティブ/パッシブ構成のOracleAS Reports Services」を参照してください。
OracleAS Reports Servicesの場合、アクティブ/アクティブ構成ではインスタンスおよびコンポーネントをすべて同じサブネットで実行する必要があります。これは、Reports ServletでReports Serverの検出にマルチキャストが使用されるためです。異なるサブネット間でOracleAS Reports Servicesコンポーネントを実行する必要がある場合は、Reports Bridgeを使用して、異なるサブネットのReports Serverにアクセスできるようにする必要があります。この場合、Reports Bridgeは重要コンポーネントとなるため、OracleAS Cold Failover Clusterなどの高可用性の手法を使用して保護する必要があります。
このアクティブ/アクティブ構成を作成するには、次の手順を実行します。
ORACLE_HOME/reports/conf/cgicmd.dat）
ORACLE_HOME/reports/conf/rwservlet.properties）
ORACLE_HOME/reports/server/<server_name>.dat）永続ファイルには、完了ジョブとスケジュール済ジョブの一覧があります。Reports Serverには、それぞれ独自の永続ファイルがあるため、別のReports Serverでは、異なるセットの完了ジョブ・リクエストがあります。
永続ファイルにはスケジュール済ジョブも格納されているため、このファイルやインスタンスの損失によって、そのReports Serverのすべてのスケジュール済ジョブが失われることを意味します。これは、アクティブ/アクティブ構成であっても同様です。スケジュール済ジョブを実行する際は、このファイルがリストア可能である必要があります。
OracleAS Reports Servicesは、提供されているスクリプトを使用してアクティブ/パッシブ構成でインストールまたはデプロイできます。ただし、次の制限事項に注意してください。
OracleAS Forms Servicesを構成するランタイム・コンポーネントを表5-2に示します。
OracleAS Forms Servicesは、中間層の専用サーバー・プロセスとして存在しているわけではないため、Web上でのリクエストとFormsアプリケーションの実行には、Forms Servicesを実行するよう構成されているサーブレット・コンテナ（OC4J）の可用性のみが必要です。
OracleAS Forms Servicesでは、各ユーザーに対して専用のForms Runtimeプロセスが起動されるため、透過的なアプリケーション・フェイルオーバーはありません。ユーザー・セッションが中断された場合、ユーザーはForms Servletに新しいリクエストを発行することによってForms Webアプリケーションを再起動する必要があります。
中間層サーバーがクラッシュしたり、サーブレット・セッションが中断されたりした場合は、アプリケーションを再起動することによって障害からリカバリします。OracleAS Forms Servicesに高可用性を設定するには、次のコンポーネントを使用します。
mod_oc4j: OC4Jインスタンスの障害を扱います。異なるOC4Jインスタンス間でアプリケーション・リクエストをロード・バランシングするようOracleAS Forms Servicesを設定できます。これによって、現在のOC4Jインスタンスに障害が発生した場合に、アプリケーション・リクエストを次に使用可能なOC4Jインスタンスに必ずルーティングできるようになります。
OracleAS Web Cache: OracleAS Web CacheをHTTPロード・バランサとして使用することにより、同じInfrastructureインストールを共有しているかどうかにかかわらず、多数のOracle Application Serverインスタンス間でFormsリクエストを分散できるようになります。1つのインスタンスに障害が発生した場合、次のFormsアプリケーション・リクエストは次に使用可能なインスタンスにルーティングされます。また、各インスタンスでmod_oc4jを使用して、OC4Jインスタンス間でFormsセッションをロード・バランシングできます。
ハードウェア・ロード・バランサ: ハードウェア・ロード・バランサをOracleAS Web Cacheの前面に配置することができます。これにより、Formsリクエストのロード・バランシングにレイヤーを1つ追加できます。または、OracleAS Web Cacheをハードウェア・ロード・バランサに置き換えて、Oracle HTTP Serverに直接リクエストをロード・バランシングすることもできます。
Forms Servicesインストールで使用されるOracleAS Infrastructureの場合、Oracle Identity Managementを含めて、OracleAS Cold Failover Clusterトポロジを使用します。これについては、第9章「OracleAS Infrastructure: 高可用性トポロジ」で説明します。
Forms Serviceのアーキテクチャおよび設定の詳細は、『Oracle Application Server Forms Services利用ガイド』を参照してください。
OracleAS Integration B2Bは、実行時にOracle Application Serverスタックからいくつかのコンポーネントを使用します。これには、Oracle HTTP Server、OC4JおよびOracleAS Metadata Repositoryが含まれます。図5-3に、OracleAS Integration B2Bの高可用性構成を示します。
OracleAS Integration B2Bサービスで高可用性を実現するには、次のコンポーネントの高可用性を実現する必要があります。
説明のために、ランタイム・アーキテクチャを次の層にセグメント化できます。
これらの層のいずれかにアクティブ/アクティブの可用性がある場合は、OracleAS Integration B2Bにもアクティブ/アクティブの可用性があります。これらの層のいずれかがアクティブ/パッシブである場合は、OracleAS Integration B2Bサービスはアクティブ/パッシブになります。たとえば、OracleAS Infrastructure層でOracleAS Cold Failover Cluster（Infrastructure）構成が使用されている場合、OracleAS Integration B2Bサービスにはアクティブ/パッシブの可用性があります。
この層は、Oracle HTTP ServerとOC4Jトランスポート・サーブレット・インスタンスで構成されています。サーブレットは、OC4Jコンテナにデプロイされ、そのコンテナの高可用性プロパティを利用できます。これは、OracleAS Cluster（OC4J）にグループ化され、一貫した構成のためにDCMによって同期化できます。OC4Jインスタンスはmod_oc4jによってロード・バランシングされます。
アクティブ/アクティブの可用性のために、WebサーバーとOC4J層の前面にロード・バランシング・ルーター機器またはOracleAS Web Cache（あるいはその両方）を配置します。OracleAS Web Cacheを使用している場合、OracleAS Cluster（Web Cache）内に構成する必要があります。OracleAS Web Cache、Oracle HTTP ServerおよびOC4Jプロセスの監視および自動再起動は、OPMNによって実行されます。
トランスポート・サーブレットは、OracleAS Integration B2Bインスタンスにリクエストを転送し、インスタンスからレスポンスを受信するタスクを実行します。このサーブレットは、処理するリクエストごとの状態を保持しません。それらは、Java RMIを介してOracleAS Integration B2Bインスタンスと通信します。OracleAS Integration B2Bの各インスタンスは、トランスポート・サーブレットをホスティングする各OC4Jコンテナのweb.xmlファイルに登録されます。サーブレットは、ラウンドロビン・モデルを使用してOracleAS Integration B2Bインスタンスにリクエストを転送します。OracleAS Integration B2Bインスタンスのいずれかに障害が発生した場合、指定されたタイムアウトの期間が経過した後、サーブレットはラウンドロビン・キュー内の次のインスタンスにリクエストを再ルーティングします。
OracleAS Integration B2B層は、OracleAS Integration B2Bサーバー・ランタイムで構成されています。これはJavaアプリケーションですが、そのインスタンスはOC4Jコンテナ内では実行されません。これらはそれ自体のスタンドアロンJVMプロセス内で実行されます。
OracleAS Integration B2Bサーバーには、次の特徴があります。
サーバーがアクティブ/アクティブの可用性を持つようにするには、そのランタイムの（異なるノード上の）複数のインスタンスをインスタンス化する必要があります。理想的には、ノードの障害から保護するためにこれらのインスタンスを複数のノードに配置する必要があります。各インスタンスの障害の検出と自動再起動の管理はOPMNによって確保されます。
OracleAS Integration B2Bインスタンスへのインバウンド通信はOracle HTTP Serverの前面に配置されたロード・バランサによって受信されます。ロード・バランサは、Oracle HTTP Serverインスタンスにリクエストを分散し、Oracle HTTP Serverはmod_oc4jロード・バランシングを使用してリクエストをトランスポート・サーブレットに転送します。トランスポート・サーブレットは、RMIプロトコルを使用してリクエストをOracleAS Integration B2Bインスタンスに送信します。
OracleAS Integration B2Bインスタンスからのアウトバウンド通信は、次のように実行されます。インスタンスがレスポンスを、プロキシ・サーバーとして構成されているOracle HTTP Serverに送信します。この構成は、プロキシ・ホストとポート・プロパティをtip.propertiesファイルで指定することによって実現できます。
OracleAS Infrastructure層の高可用性は、第9章「OracleAS Infrastructure: 高可用性トポロジ」に記載されているOracleAS Infrastructureの高可用性構成のいずれによっても実現できます。これらの構成によって、Webサーバー、OC4JおよびOracleAS Integration B2B層に対するOracleAS Metadata RepositoryおよびOracle Identity Managementコンポーネントの高可用性が確保されます。アクティブ/アクティブの可用性には、第6.2.1項「アクティブ/アクティブ型の高可用性トポロジ」に記載されている構成の1つを使用する必要があります。これによって、OracleAS Integration B2Bサービス・スタック全体のアクティブ/アクティブの可用性を確保できます。
OracleAS Integration InterConnectには、ハブ・アンド・スポーク型のアーキテクチャがあります。図5-4に、例として2つのスポーク・アプリケーションを持つOracleAS Integration InterConnectコンポーネントを示します。
OracleAS Integration InterConnectコンポーネントは、次のとおりです。
OracleAS Integration InterConnectで高可用性を実現するには、そのコンポーネントの高可用性を実現する必要があります。また、アダプタに情報を提供するデータまたはメッセージ・ソースに高可用性があることも必要です。これらは、スポーク・アプリケーションです。これらのアプリケーションは、カスタマ依存で、Oracle Application Server製品の一部ではないため、このマニュアルではその高可用性について説明しません。
高可用性の説明のために、OracleAS Integration InterConnectコンポーネントを次の層にセグメント化できます。
次の項では、各層の高可用性の実現方法について説明します。
HTTPアダプタ以外の各アダプタは、スタンドアロンJVMプロセス（OC4Jではない）で稼動し、ステートレスです。このJVMプロセスは、プロセスの障害の検出と自動再起動を行うようにカスタムOPMNアプリケーションとして構成できます。カスタム・アプリケーションはopmn.xmlファイルで構成できます。これを行う手順は、『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。構成後、アダプタ・プロセスはOPMN（opmnctlコマンド）を使用して起動する必要があります。
OPMNは、個別のプロセスの監視および再起動のみを行います。アダプタ層を完全に冗長化するには、複数のアダプタ・プロセスが必要です。アダプタは、アクティブ/アクティブまたはアクティブ/パッシブの方法を使用して設定できます。
複数のアクティブ・アダプタ・プロセスを同じマシンまたは複数のマシンに配置できます。アダプタ・プロセスは、スポーク・アプリケーションからの受信メッセージを処理し、同時にハブ・データベースにメッセージを配信します。1つのアダプタ・プロセスに障害が発生した場合、メッセージは残りのプロセスに配信されます。アダプタは互いに調整して、スポーク・アプリケーションからのワークロードをロード・バランシングします。
コールド・フェイルオーバー・クラスタ構成では2つのアダプタ・プロセスを配置してアクティブ/パッシブの可用性を実現できます。
コールド・フェイルオーバー・クラスタでは、Sun ClusterやHP MC/Service Guardなどのクラスタウェアを使用して2つのマシンをまとめてクラスタリングできます。このタイプのクラスタリングは、アダプタの高可用性を確保するために一般的に使用されるソリューションです。クラスタの1つのノードはコールドで、障害の発生時に引き継ぐために受動的に待機し、もう1つのノードはホットで、アダプタ・ソフトウェアをアクティブに実行しています。ホットつまりアクティブなノードに障害が発生した場合、クラスタウェアがコールド・ノード上のソフトウェアを再起動してアダプタをオンラインに戻します。図5-4にアダプタのコールド・フェイルオーバー・クラスタを示します。
ハブ・データベースがReal Application Clustersデータベースである場合、アダプタはReal Application Clustersの複数のデータベース・インスタンスとともに動作できます。Real Application Clustersのテクノロジによって、データベース・インスタンスに障害が発生した場合でもアダプタを再起動することなく、中断されない一貫したサービスが提供されます。アダプタは、adapter.iniまたはhub.iniファイルにリストされた使用可能なノードの最初のノードに接続します。Real Application Clustersノードの1つに障害が発生した場合、データベースは、adapter.iniまたはhub.iniファイルの次の使用可能なノードに接続します。これは、正常に接続されるまで再帰的に行われます。フェイルオーバーは、スポーク・アプリケーションに対して透過的です。アダプタ・プロセスがReal Application Clustersのハブ・データベース・インスタンスを認識する方法の詳細は、次の「ハブ・データベース層」を参照してください。
各アダプタ・タイプ固有の高可用性は、次のように実現できます。
同じアプリケーションの処理を行う複数のデータベース・アダプタ・インスタンスを配置できます（図5-5に例を示します）。アダプタはステートレスなので、それらのスポーク・アプリケーションであるカスタマ・データベースから受け取ったタスクを共有できます。データベースに対する接続障害の処理は、終了していないトランザクションをロールバックし、他のデータソースを再試行することによって行われます。同じ接続障害の処理メカニズムを、ハブ・データベースのアドバンスト・キューへのJMS通信（JDBCを介したJMS）にも使用できます。
アプリケーションを設計した後、アダプタを最初に起動したときにそれをデータベース・アダプタにデプロイできます。最初の起動時に、アダプタはOracleAS Integration InterConnectリポジトリ・サーバーを使用してハブ・データベースからメタデータをフェッチします。これは、OracleAS Integration InterConnect iStudioが設計時にデータにアクセスする際の方法と類似しています。これらのメタデータは、アダプタによって取得された後、ファイルベースのキャッシュにローカルにキャッシュされます。これによって、後続のアダプタの起動時にリポジトリ・サーバーにアクセスする必要がなくなります。
実行時に、データベース・アダプタはJDBCを介してカスタマ・データベースにアクセスします。接続に障害が発生した場合に、アダプタが繰り返し処理する複数のJDBCデータソースがある場合もあります。カスタマ・データベースからのタスクは、1つのタスクが1回だけ処理されるように、すべてのデータベース・アダプタ・インスタンスによって調整されて処理されます。カスタマ・データベースからただちに使用可能なデータを取得するために、データベースはReal Application Clustersが有効化されているか、コールド・フェイルオーバー構成になっている必要があります（ハブ・データベースにも当てはまります）。アダプタは、実行時にリポジトリ・サーバーと通信し、Xref機能を実装します。
HTTPアダプタは、スタンドアロンJavaアプリケーション、OC4Jトランスポート・サーブレットおよびOracle HTTP Serverで構成されています。Javaアプリケーションは、HTTPアダプタ・ロジックを実装し、RMIプロトコルを使用してOC4Jのサーブレットと通信します。各Javaアプリケーション・プロセスは、1つのOC4Jプロセスのみと通信します。Oracle HTTP Serverでは、HTTPを介してスポーク・アプリケーションと通信する必要があります。
高可用性を確保するために、複数のセットのOracle HTTP Server、OC4JおよびJavaアプリケーション・プロセスを冗長ノードに配置する必要があります。mod_oc4jロード・バランシングを使用してOracle HTTP ServerとOC4Jインスタンスの間のリクエストをノード間で分散できます。ただし、OC4JインスタンスとJavaアプリケーション・プロセスの間の通信は1対1です。Oracle HTTP Serverインスタンスの前面にロード・バランシング・ルーターを配置して、これらのインスタンスにリクエストを分散できます。
HTTPアダプタJavaアプリケーションも、ハブ・データベースおよびリポジトリ・サーバーと通信します。Javaアプリケーションは、前述のデータベース・アダプタと同じ方法で、これらのコンポーネントとともに機能します。ハブ・データベースは、Real Application Clustersデータベースまたはコールド・フェイルオーバー・クラスタ構成を使用して高可用性を確保する必要があります。リポジトリ・サーバーは、コールド・フェイルオーバー・クラスタ構成を使用して高可用性を確保できます。
HTTPアダプタ・プロセスに障害が発生したとき、メッセージがトランスポートまたはRMIレイヤーにある場合、アダプタ・プロセスへの（サーブレットからアダプタへの）インバウンド・メッセージが失われることがあります。メッセージがアダプタ・エージェント・レイヤーに到達すると、メッセージは保持され、後でアダプタが再起動したときに処理されます。また、RMIサーバーではアダプタ・プロセスとともに障害が発生するので、そのアダプタ・プロセスへの他のメッセージをトランスポート・サーブレットがエンキューすることはできません。OC4Jプロセスのこれらのメッセージは処理されません。それは、トランスポート・サーブレットのdoPost()メソッドが、RMIサーバーが利用不能であることを示すエラー・メッセージを返すためです。
FTPおよびSMTPアダプタの高可用性を実現するには、複数のアダプタ・インスタンスを別個のマシンに配置し、ロード・バランサによってリクエストをルーティングするようにします。アダプタはメッセージを自動的に処理し、ステートレスであるため、アダプタ・インスタンスのいずれか1つに障害が発生した場合でも、冗長化された配置によってメッセージの送信側と受信側は障害を認識することはありません。
このアダプタ固有の高可用性は、データベース・アダプタの高可用性に類似しています。これは、MQおよびAQデータベースへのアクセスにもJDBC（JMS）を使用するためです。前述のデータベース・アダプタの説明を参照してください。
ファイル・アダプタの高可用性を実現するには、ネットワーク・ファイル・システムにアクセスする複数のアダプタ・インスタンスが必要です。1つのアダプタ・インスタンスに障害が発生した場合、障害が発生したインスタンスに対するリクエストを別のインスタンスが処理できます。
OEMアダプタ・モデルは、HTTPアダプタ・モデルに類似しています。つまり、OC4Jトランスポート・サーブレット、Oracle HTTP ServerおよびスタンドアロンJavaアプリケーションが含まれます。Javaアプリケーションは、アダプタ・ロジックを実装し、RMIプロトコルを使用してOC4Jのサーブレットと通信します。各Javaアプリケーション・プロセスは、1つのOC4Jプロセスのみと通信します。Oracle HTTP Serverでは、HTTPを介してスポーク・アプリケーションと通信する必要があります。
この層は、リポジトリ・サーバー・インスタンスで構成されています。一度にアクティブに稼動できるインスタンスは1つのみです。したがって、リポジトリ・サーバーは2つのノードを持つコールド・フェイルオーバー・クラスタ構成によって、ノードで共有記憶域を使用するように配置できます。この構成によって、ノードレベルのフェイルオーバーが可能になります。
リポジトリ・サーバー・プロセスの高可用性を確保するために、opmn.xmlファイルでOPMNのカスタム・アプリケーションとしてプロセスを構成できます。これにより、OPMNはリポジトリ・サーバー・プロセスを監視し、障害が発生した場合に自動的に再起動できます。変更した後、リポジトリ・サーバー・プロセスはOPMN（opmnctlコマンド）を使用して起動する必要があります。
リポジトリ・サーバーは、Xref機能のために実行時にのみ使用されます。それ以外の場合は、設計および配置の際に、アダプタが最初に起動してハブ・データベースからアプリケーション・メタデータをフェッチするときにのみ必要です。
ハブ・データベースは、OracleAS Metadata Repositoryデータベースを含む任意のデータベースにすることができます。これには、アプリケーション・ビューおよび一般的なビューの形式などOracleAS Integration InterConnectメタデータが格納されます。iStudioは、設計時にリポジトリ・サーバーを介してRMIを使用してハブ・データベースにアクセスします。それはJVMプロセスです。リポジトリ・サーバーは、複数のJDBCデータソースとして複数のハブ・データベース・インスタンスと通信できます。内部的には、リポジトリ・サーバーは、タイムアウトの際に各データソースを繰り返し再試行します。
OracleAS Integration InterConnect Hubデータベースは、Real Application Clustersを使用することによって高可用性を実現できます。次にいくつかのガイドラインを示します。
リポジトリ・サーバー・プロセスがReal Application Clustersデータベース・インスタンスを認識できるようにするには、そのデータベース・インスタンスをホスティングしている利用可能なノードのリストを指定します。具体的には、repository.iniまたはhub.iniファイルに、すべてのノードのホスト、ポートおよびインスタンス情報を入力します。リポジトリ・サーバー・プロセスに接続しているReal Application Clustersノードに障害が発生した場合、repository.iniおよびhub.iniファイルにある次のノードのエントリが使用されます。
アダプタ・プロセスがReal Application Clustersデータベース・インスタンスを認識できるようにするには、そのデータベース・インスタンスをホスティングしている利用可能なノードのリストを指定します。具体的には、adapter.iniファイルに、すべてのノードのホスト、ポートおよびインスタンス情報を入力します。アダプタ・プロセスに接続しているノードに障害が発生した場合、adapter.iniファイルにある次のノードのエントリが使用されます。
OracleAS Integration InterConnectのすべてのアダプタのハブ接続と、データベースとAQアダプタとのスポーク接続で、Real Application Clustersがサポートされています。
BPEL（ビジネス・プロセス実行言語）はXMLベースの言語であり、これを使用すると別個のサービスを1つのエンドツーエンド・プロセス・フローにアセンブルできます。Oracle BPEL Process Managerには、BPELビジネス・プロセスの設計、配置および管理を行うためのフレームワークが用意されています。
Oracle BPEL Process ManagerはJ2EEアプリケーションの1つであり、様々なアプリケーション・サーバーで実行できます。これはステートレス・アプリケーションですが、データベースを「デハイドレーション・ストア」として使用して、プロセスの状態に関する情報を格納します。
Oracle BPEL Process Managerのアーキテクチャもステートレスなため、高可用性の実現が簡単になります。図5-6に、Real Application Clustersデータベースをデハイドレーション・ストアとして使用した、アクティブ/アクティブ構成でのOracle BPEL Process Managerを示します。
アクティブ/アクティブ構成では、すべてのコンポーネントが同時に実行されます。ロード・バランサによって、該当するノードにリクエストが分散されます。該当するノードが使用不可の場合、リクエストは次に使用可能なノードに送信されます。
アクティブ/アクティブ構成でOracle BPEL Process Managerを実行するには、次の手順を実行します。
soapServerUrlおよびsoapCallbackUrlプロパティをロード・バランサのURLになるように設定します。
jndiProviderURL = "ormi://localhost/CustomerService"
かわりに次のように指定します。
jndiProviderURL = "opmn:ormi://host1:port1:oc4j/app, opmn:ormi://host2:port2:oc4j/app"
これによって、JVMレベルの高可用性を実現できます。1つのOC4Jインスタンスに対して複数のJVMプロセスを実行している場合、OPMNでは、使用可能なJVMの数に基づいて独立したJNDIオブジェクトにリクエストをルーティングできます。
BPELプロセスをアクティブ/アクティブ構成に配置するには、次の操作を行います。
この項では、SOAP/WSDLまたはOracle BPEL Process Manager Java APIを使用してBPELプロセスを起動する場合に必要な変更について説明します。
SOAP/WSDLを使用する場合は、ノードのホスト名ではなく、ロード・バランサの仮想サーバー名を使用する必要があります。
Oracle BPEL Process Manager Java APIを使用する場合は、アクティブ/アクティブ・トポロジで各ノードのホスト名をリストします。前述のjndiProviderURLの例を参照してください。
高可用性を実現するには、Real Application Clustersデータベースなどの高可用性データベースでデハイドレーション・ストアを実行する必要があります。Real Application Clustersデータベースを使用すると、すべてのコンポーネントで高可用性を実現できます。
デハイドレーション・ストアにReal Application Clustersデータベースを使用する場合、構成に対し、次の変更を行う必要があります。
data-sources.xmlファイルを変更します。
jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS_LIST=(LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=tcp)(HOST=hostname1)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=hostname2)(PORT=1521)) ) (CONNECT_DATA=(SERVICE_NAME=orcl)) )
hostname1およびhostname2は、Real Application Clustersデータベースを実行するノードの名前を指定します。
orclは、データベースのサービス名を指定します。
アドレスおよびロード・バランサのオプションは両方ともADDRESS_LIST要素内にあります。
Oracle BPEL Process Managerは、OracleAS Cold Failover Cluster構成、つまりアクティブ/パッシブ構成でも動作します。アクティブ/パッシブ構成は、ハードウェア・クラスタ内の、共有記憶域、および仮想ホスト名とIPの、2つのノードで構成されます。共有記憶域にファイルをインストールして、ハードウェア・クラスタ内のどちらかのノードからこれらのファイルにアクセスできるようにします。クライアントは、仮想ホスト名を使用して、ハードウェア・クラスタ内のアクティブ・ノードにアクセスします。そのアクティブ・ノードが使用不可になった場合は、フェイルオーバー・イベントが発生し、パッシブ・ノードがかわりにプロセスを実行します。
Oracle BPEL Process ManagerをOracle Application Serverアダプタとともに使用して、Oracle BPEL Process Managerプロセスを外部リソースと統合します。これらのアダプタは、JCA（J2EE Connector Architecture）に基づいています。
この項では、可用性の高い方法でOracle BPEL Process Managerをアダプタとともに実行する方法について説明します。この項の項目は次のとおりです。
表5-3に示すように、Oracle Application ServerのJCAベースのアダプタは、Oracle Application Serverを様々な外部リソースと統合します。
アダプタの詳細は、『Oracle Application Server Adapter概要』を参照してください。
同時実行性のサポートとは、複数のアダプタ・サービスがデータ破損を起こすことなく同時に同じリソースにアクセスできることです。同時実行性のサポートを、トランザクションのサポートと考えることができます。例として、データベース・アダプタの複数のアダプタ・サービスからデータベース内の同じ表に同時にアクセスできることが挙げられます。
アダプタは同時実行性をサポートするものとサポートしないものに分けられます。
表5-4に示すように、同時実行性のサポートまたは非サポートによって、アダプタの高可用性オプションが影響を受けます。
| アダプタ・タイプ | 高可用性オプション |
|---|---|
|
同時実行性のサポート |
|
|
同時実行性の非サポート（ファイルおよびFTPアダプタ） |
すべての高可用性オプションについて、すべてのノードにアダプタがインストールされていることが前提となっています。ただし、高可用性オプションによっては、1つのノードでのみOracle BPEL Process Managerを実行するものがあります。
このトポロジは、同時実行性をサポートするアダプタに使用できます。
図5-6に、アクティブ/アクティブ・トポロジを示します。このトポロジでは、1つ以上のノードの前面にロード・バランサを配置します。各ノードで、Oracle BPEL Process Managerおよびビジネス・プロセスを配置して実行します。これは、すべてのノードですべてのコンポーネントを使用できるため、高可用性の点で理想のモデルといえます。
同時実行性をサポートしないアダプタをアクティブ/アクティブ・トポロジに配置すると、外部データソースのデータが破損するおそれがあります（同時に同じファイルの読取りと書込みを行うなど）。
この変更済バージョンのアクティブ/アクティブ・トポロジは、次の相違点を除いて完全なアクティブ/アクティブ・トポロジと同様です。
最初のノードのアダプタ・サービスのみが受信リクエストを取得します。
このトポロジは、次のアダプタに使用できます。
図5-7に、変更済アクティブ/アクティブ・トポロジを示します。
アクティブ化エージェントを使用しているノードに障害が発生した場合は、次の手順を実行する必要があります。
アクティブ化エージェントを無効にするには、bpel.xmlファイルのactivationAgent要素をコメント・アウトします。次の例では、無効にするアクティブ化エージェントが含まれるコメント行を示します。
<activationAgents> <!-- start comment <activationAgent className="oracle.tip.adapter.fw.agent.jca.JCAActivationAgent" partnerLink="InboundPL"> <property name="InputFileDir">C:/ora_home/integration/bpm/samples/tutorials/ 121.FileAdapter/ComplexStructure/InputDir/</property> <property name="portType">Read_ptt</property> </activationAgent> end comment --> </activationAgents>
このトポロジは、すべてのアダプタに使用できます。アクティブ/パッシブ・トポロジは、OracleAS Cold Failover Clusterトポロジとも呼ばれます。
アクティブ/パッシブ・トポロジ（図5-8を参照）では、ハードウェア・クラスタに2つのノードがあります。そのうちの1つはアクティブ・ノード、もう1つはパッシブ・ノードです。共有記憶域もあり、これにOracleホーム・ディレクトリをインストールします。共有記憶域はアクティブ・ノードにのみマウントされます。
ハードウェア・クラスタのアクティブ・ノードは、仮想ホスト名およびIPに関連付けられています。クライアントは、仮想ホスト名を使用して、クラスタ内のアクティブ・ノードにアクセスします。
実行時に、アクティブ・ノードはプロセスを実行します。仮想ホスト名はアクティブ・ノードを指し示します。アクティブ・ノードが使用不可になると、フェイルオーバー・イベントが発生します。パッシブ・ノードが新しいアクティブ・ノードになり、プロセスを実行します。
次の相違点を除いて単一ノード配置の場合と同じように、Oracle BPEL Process Managerをインストールして管理します。
OracleBI Discoverer ServerへのWeb接続はDiscovererサーブレットを使用して管理されます。サーブレットは、クライアントとDiscovererセッション・コンポーネントとの間を仲介し、その後、Discovererセッション・コンポーネントが実際のトランザクションを管理します。Discovererセッション・コンポーネントは、Object Activation Daemon（OAD）によって起動および管理されます。各マシンには、それぞれのDiscovererセッションを管理するOADがあります。OADとセッション・コンポーネントは、どちらもOPMNによって監視および管理されます。
OracleBI Discovererを次のように構成して高可用性を実現できます。
それぞれの中間層ノードでOracleBI Discovererプロセスを監視および再起動するようにOPMNを構成します。『Oracle Business Intelligence Discoverer構成ガイド』の第4章を参照してください。
OracleAS Web Cacheは、OracleBI Discovererリクエストのロード・バランサとして実行するように設定できます。『Oracle Business Intelligence Discoverer構成ガイド』の第5章を参照してください。
OracleBI Discoverer Preferences Serverは、セッションにわたる個別のユーザー・プリファレンスを格納します。これは、セッション・サーバーのようにOADによって管理されます。複数マシンの環境では、中央に配置したOracleBI Discoverer Preferences Serverにアクセスするように分散セッション・サーバーを構成できます。Preferences ServerはOPMNによって監視および管理されます。
OracleBI Discoverer Preferences Serverの高可用性を実現するには、複数のインスタンスを配置し、その前面にロード・バランシング・ルーターまたはOracleAS Web Cache（あるいはその両方）を配置し、それによってインスタンスを処理します。このシナリオのセッション情報の管理について、いくつかの考慮事項があります。
ロード・バランサの背後に複数のOracleBI Discoverer中間層を配置する場合、ユーザー・プリファレンスの一貫性をセッション全体で保つように、OracleBI Discoverer Preferences Serverを構成するためのオプションは2つあります。
OracleBI Discoverer Preferences Serverをホスティングしているマシンまたはそのサーバー上に保存されている情報のいずれかを失ってもOracleBI Discovererの機能に影響はありません。ただし、保存されているユーザーのプリファレンス情報は失われます。
プリファレンス情報の損失を抑制するために、OracleBI Discoverer Preferences Server上のデータ、特にファイル<ORACLE_HOME>/discoverer/util/pref.txtを定期的にバックアップする必要があります。このファイルにプリファレンス情報が保存されています。
アクティブ/アクティブおよびアクティブ/パッシブの両方の環境で、ドメイン・コントローラがアクティブ・ノードで実行されていることを確認する必要があります。ドメイン・コントローラが実行されているノードが使用不可になった場合は、ドメイン・コントローラを別のノードに移行する必要があります。これは、ドメイン・コントローラは常に1つのノード上でのみ実行できるためです。
OracleAS Cold Failover Cluster（中間層）にOracle Content Management SDKがインストールされている場合に、フェイルオーバーまたはフェイルバック・イベントが発生したときは、ドメイン・コントローラを新しいアクティブ・ノードに移行する必要があります。
アクティブ/アクティブ環境で、ドメイン・コントローラが実行されているノードが使用不可になった場合は、これを別のノードに移行する必要があります。
ドメイン・コントローラの移行方法の詳細は、『Oracle Content Management SDK管理者ガイド』の第3章「Oracle CM SDKドメインの管理」、ドメイン・コントローラの移行に関する項を参照してください。このマニュアルは、Oracle Content Management SDKのCD-ROMに含まれています。
|
 Copyright © 2005, 2007 Oracle. All Rights Reserved. |
|