16 その他のコンポーネントの高可用性の構成
このリリースでの、この項の内容は次のとおりです。
- Oracle Data Integratorのデプロイ
この項では、Oracle Real Application ClustersへのOracle Data Integratorリポジトリ接続を構成する際の考慮事項について説明します。 - Oracle Application Development Frameworkのデプロイ
この項を参照して、Oracle Application Development Framework (ADF)をデプロイするための特別な考慮事項を確認します。 - BIのデプロイ
Oracle Business Intelligence (BI)をデプロイする際には、次の点を考慮します。 - Formsのデプロイ
Formsをデプロイする際には、次の点を考慮します。 - Reportsのデプロイ
Reportsには、高可用性設定のために確認する必要のある特定の考慮事項があります。 - Oracle Business Process Managementのデプロイ
Oracle Business Process Managementを高可用性環境でデプロイするには、次の点を考慮します。
親トピック: コンポーネントの手順
Oracle Data Integratorのデプロイ
この項では、Oracle Real Application ClustersへのOracle Data Integratorリポジトリ接続を構成する際の考慮事項について説明します。
- ソース接続およびターゲット接続に対するOracle RACの再試行の接続
Oracle Data Integrator (ODI) Oracle Real Application Clusters (RAC)接続を構成する場合、ODIマスターまたはODI作業リポジトリに対してOracle RAC再試行がサポートされます。 - Oracle RACへのODIリポジトリ接続の構成
リポジトリ作成ユーティリティ(RCU)を使用してODIリポジトリを作成する際、作業リポジトリ接続のJDBC URLを指定します。RCUは、このURLをマスター・リポジトリ・コンテンツに格納します。作業リポジトリのJDBC URLが単一ノードURLの場合、Oracle Real Application Clusters (Oracle RAC)のフェイルオーバー・アドレスを含むようにURLを変更することをお薦めします。 - Oracle Data Integratorスケジューラ・ノードの障害
WebLogic Serverのフェイルオーバーが発生した場合は、他のWebLogic Serverインスタンスがスケジューラになります。Coherenceキャッシュによって、スケジューラ・ライフサイクルが処理されます。ロックにより、スケジューラの一意性が保証され、イベント通知はスケジューラの移行を知らせます。
親トピック: その他のコンポーネントの高可用性の構成
ソース接続およびターゲット接続に対するOracle RACの再試行の接続
Oracle Data Integrator (ODI) Oracle Real Application Clusters (RAC)接続を構成する場合、ODIマスターまたはODI作業リポジトリに対してOracle RAC再試行がサポートされます。
ODIは、ODIシナリオの実行中に、ソース接続およびターゲット接続へのトランザクション接続を使用します。これらのソース接続およびターゲット接続については、ODIはRAC再試行の接続をサポートしていません。これらのトランザクションをOracle RACの別のノードに移行することはできません。
親トピック: Oracle Data Integratorのデプロイ
Oracle RACへのODIリポジトリ接続の構成
リポジトリ作成ユーティリティ(RCU)を使用してODIリポジトリを作成する際、作業リポジトリ接続のJDBC URLを指定します。RCUは、このURLをマスター・リポジトリ・コンテンツに格納します。作業リポジトリのJDBC URLが単一ノードURLの場合、Oracle Real Application Clusters (Oracle RAC)のフェイルオーバー・アドレスを含むようにURLを変更することをお薦めします。
-
Oracle RACが単一クライアント・アクセス名(SCAN)で構成されていない場合は、Oracle RACインスタンスの詳細を提供できます。作業リポジトリのJDBC URLフィールドで、Oracle RAC接続アドレスをhost:portの形式で入力します。次の例を参照してください。
-
Oracle RACをSCANで構成している場合、Oracle RACインスタンスの詳細にSCANアドレスを提供します。
次の例に、SCANを使用しない場合に、2つのホストを持つOracle RACに接続するためのJDBC URL書式を示します。
jdbc:oracle:thin:(DESCRIPTION =(LOAD_BALANCE=ON) (ADDRESS =(PROTOCOL =tcp) (HOST =host1)(PORT =port1)) (ADDRESS =(PROTOCOL =tcp)(HOST =host2) (PORT =port2)) (CONNECT_DATA =(SERVER=dedicated) (SERVICE_NAME=service_name)))
『Oracle Data Integratorの管理』の作業リポジトリの作成に関する項を参照してください。
親トピック: Oracle Data Integratorのデプロイ
Oracle Data Integratorスケジューラ・ノードの障害
WebLogic Serverのフェイルオーバーが発生した場合は、他のWebLogic Serverインスタンスがスケジューラになります。Coherenceキャッシュによって、スケジューラ・ライフサイクルが処理されます。ロックにより、スケジューラの一意性が保証され、イベント通知はスケジューラの移行を知らせます。
エージェントが再起動され、そのスケジュールが計算された場合は、進行中のスケジュールが考慮され、それらの実行サイクルは、サーバーの起動時間を過ぎても自動的に継続されます。新しいセッションは、スケジューラが停止しなかったかのようにトリガーされます。失効セッションは、エラー状態に移動され、再起動時にはその状態が保持されます。
Oracle Data Integratorエージェント・クラスタで、スケジューラ・ノードであるエージェント・ノードに障害が発生すると、クラスタ内の別のノードがスケジューラ・ノードとしての役割を引き継ぎます。新しいスケジューラ・ノードにより、すべてのスケジュールが再初期化され、その時点から実行されます。
ノードで障害が発生した際に反復可能な実行サイクルを持つスケジュール済シナリオが実行中の場合、スケジューラ・ノードがクラッシュした時点以降、そのシナリオは新しいスケジューラ・ノードでは反復が続行されません。たとえば、スケジュール済シナリオが2分間隔で10回実行を繰り返すように構成されている場合、3回目の実行中にスケジューラ・ノードで障害が発生すると、新しいスケジューラ・ノードでは、シナリオの残りの8回は実行されません。
親トピック: Oracle Data Integratorのデプロイ
Oracle Application Development Frameworkのデプロイ
この項を参照して、Oracle Application Development Framework (ADF)をデプロイするための特別な考慮事項を確認します。
注意:
ADFの詳細は、次を参照してください。
-
「Oracle Application Development Frameworkの理解」の「Oracle ADFの主要概要」
-
Oracle Fusion MiddlewareでのOracle ADFアプリケーションの管理
Oracle JRF非同期Webサービス(固定サービスの動作)
Oracle JRF非同期Webサービスを使用している場合は、非同期Webサービスがサービスに固定されるため、フェイルオーバーは実行されません。WS-RMなどの信頼性の高いプロトコルを使用している場合は、障害の発生後に、より上位レベルのプロトコルによって新しいサーバーへの再接続が実行されます。
Oracle JRF非同期Webサービスの詳細は、『ドメイン・テンプレート・リファレンス』のOracle JRFおよびADFテンプレートに関する項を参照してください。
BIのデプロイ
Oracle Business Intelligence (BI)をデプロイする際には、次の点を考慮します。
- BIセッションのフェイルオーバーについて
BI管理対象サーバーまたはホスト(あるいはその両方)がクラッシュすると、再びログインが必要な場合があります。これは、クラッシュの発生時にどのアプリケーションを使用していたか、およびSSOを使用していたかどうかにより、異なります。 - BI Essbaseについて
Essbaseは、高可用性構成をサポートしていません。サーバーで障害が発生した場合、Essbase Cubeをデプロイして障害をリカバリできます。 - BI Studioについて
Studioは、高可用性構成をサポートしていません。xmlインポート/エクスポートを定期的に実行することを、お薦めします。これは、Studioのカタログ障害からリカバリするためのベスト・プラクティスです。 - 複数のノード・マネージャへのポートの指定について
1台のマシンに複数のノード・マネージャがある場合は、ポートを指定したことを確認します。 - RACデータベースのインストール後の構成について
Oracle BIでは、インストール後にサーバー全体を移行するための追加の構成ステップが必要です。 - BI Publisherのスケール・アウトについて
BIのスケール・アウトを完了するには、通常のスケール・アウト・ステップの他に、追加のタスクが必要になります。
親トピック: その他のコンポーネントの高可用性の構成
BIセッションのフェイルオーバーについて
BI管理対象サーバーまたはホスト(あるいはその両方)がクラッシュすると、再びログインが必要な場合があります。これは、クラッシュの発生時にどのアプリケーションを使用していたか、およびSSOを使用していたかどうかにより、異なります。
親トピック: BIのデプロイ
BI Essbaseについて
Essbaseは、高可用性構成をサポートしていません。サーバーで障害が発生した場合、Essbase Cubeをデプロイして障害をリカバリできます。
親トピック: BIのデプロイ
BI Studioについて
Studioは、高可用性構成をサポートしていません。xmlインポート/エクスポートを定期的に実行することを、お薦めします。これは、Studioのカタログ障害からリカバリするためのベスト・プラクティスです。
親トピック: BIのデプロイ
複数のノード・マネージャへのポートの指定について
マシンごとに1つ以上のノード・マネージャがある場合、ポートが指定されていることを確認してください。
『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の一般的なエンタープライズ・デプロイメントでのノード・マネージャの構成に関する項を参照してください。
親トピック: BIのデプロイ
RACデータベースのインストール後の構成について
Oracle BIでは、インストール後にサーバー全体を移行するための追加の構成ステップが必要です。
これらのステップの詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のエンタープライズ・デプロイメントでのサーバー全体の移行およびサービスの移行の使用に関する項を参照してください。
親トピック: BIのデプロイ
BI Publisherのスケール・アウトについて
BIのスケール・アウトを完了するには、通常のスケール・アウト・ステップの他に、追加のタスクが必要になります。
Oracle BIでは、トポロジのスケール・アウト(マシンのスケール・アウト)で説明するスケール・アウトのステップに従った後、追加の構成ステップが必要です。Oracle BIでは、setDomainEnv.sh
を更新されたsingleton-data-directory設定(SDD)に変更する必要があります。
Oracle BIのスケール・アウトを完了するには、次のようにします。
親トピック: BIのデプロイ
Formsのデプロイ
Formsをデプロイする際には、次の点を考慮します。
Forms HTTPセッションのフェイルオーバーからのリカバリについて
Forms HTTPセッションに障害が発生した場合、セッションをFormsアプリケーションに再接続し、再起動する必要があります。
親トピック: Formsのデプロイ
Reportsのデプロイ
Reportsには、高可用性設定のために確認する必要のある特定の考慮事項があります。
- Reportsでのスケール・アップについて
Reportsコンポーネントをスケール・アップする場合、構成が完了したら、すべてのノードを停止し、再び開始することをお薦めします。 - Reportsのマルチキャスト通信について
Reportsクラスタのメンバーまたは個別のクライアントは、他のノードを検出するためにマルチキャストを使用します。マルチキャスト使用の回避方法はありません。 - Reportsの共有ファイル・ベース・キャッシュについて
Reportsには、シングルトンとして共有ファイル・ベース・キャッシュがあります。キャッシュが失敗すると、高可用性も失敗します。 - Reportsのデータベース・サービス障害について
Reportsコンポーネントは、データベース障害を容認します。Reportsは、データベース接続を3回試行します。データベースが起動してから、Reportsを再実行する必要があります。 - ReportsのOID/共有キャッシュ・ファイル・システムの障害について
Reportsは、OID/共有キャッシュ・ファイル・システム障害が発生しても、再試行しません。回避策はありません。外部システムが起動してから、Reportsを再実行する必要があります。
親トピック: その他のコンポーネントの高可用性の構成
Reportsでのスケール・アップについて
Reportsコンポーネントをスケール・アップする場合、構成が完了したら、すべてのノードを停止し、再び開始することをお薦めします。
Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイドのOracle Reports Serverの開始と停止を参照してください。
親トピック: Reportsのデプロイ
Reportsのマルチキャスト通信について
Reportsクラスタのメンバーまたは個別のクライアントは、他のノードを検出するためにマルチキャストを使用します。マルチキャスト使用の回避方法はありません。
親トピック: Reportsのデプロイ
Reportsの共有ファイル・ベース・キャッシュについて
Reportsには、シングルトンとして共有ファイル・ベース・キャッシュがあります。キャッシュが失敗すると、高可用性も失敗します。
回避策はありません。共有ファイル・ベースのキャッシュで障害が発生したら、Reportsサーバーを再起動する必要があります。
親トピック: Reportsのデプロイ
Reportsのデータベース・サービス障害について
Reportsコンポーネントは、データベース障害を容認します。Reportsは、データベース接続を3回試行します。データベースが起動してから、Reportsを再実行する必要があります。
親トピック: Reportsのデプロイ
ReportsのOID/共有キャッシュ・ファイル・システムの障害について
Reportsは、OID/共有キャッシュ・ファイル・システム障害が発生しても、再試行しません。回避策はありません。外部システムが起動してから、Reportsを再実行する必要があります。
親トピック: Reportsのデプロイ