プライマリ・コンテンツに移動
Oracle® Fusion Middleware高可用性ガイド
12c (12.2.1.1)
E77258-01
目次へ移動
目次

前
前へ
次
次へ

12 その他のコンポーネントの高可用性の構成

この項では、その他のコンポーネント製品に固有の情報について説明します。

このリリースでの、この項の内容は次のとおりです。

12.1 Oracle Data Integratorのデプロイ

この項では、Oracle Real Application ClustersへのOracle Data Integratorリポジトリ接続を構成する際の考慮事項について説明します。

12.1.1 ソース接続およびターゲット接続に対するOracle RACの再試行の接続

Oracle Data Integrator (ODI) Oracle Real Application Clusters (RAC)接続を構成する場合、ODIマスターまたはODI作業リポジトリに対してOracle RAC再試行がサポートされます。

ODIは、ODIシナリオの実行中に、ソース接続およびターゲット接続へのトランザクション接続を使用します。これらのソース接続およびターゲット接続については、ODIはRAC再試行の接続をサポートしていません。これらのトランザクションをOracle RACの別のノードに移行することはできません。

12.1.2 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の管理の作業リポジトリの作成を参照してください。

12.1.3 Oracle Data Integratorスケジューラ・ノードの障害

WebLogic Serverのフェイルオーバーが発生した場合は、他のWebLogic Serverインスタンスがスケジューラになります。Coherenceキャッシュによって、スケジューラ・ライフサイクルが処理されます。ロックにより、スケジューラの一意性が保証され、イベント通知はスケジューラの移行を知らせます。

エージェントが再起動され、そのスケジュールが計算された場合は、進行中のスケジュールが考慮され、それらの実行サイクルは、サーバーの起動時間を過ぎても自動的に継続されます。新しいセッションは、スケジューラが停止しなかったかのようにトリガーされます。失効セッションは、エラー状態に移動され、再起動時にはその状態が保持されます。

Oracle Data Integratorエージェント・クラスタで、スケジューラ・ノードであるエージェント・ノードに障害が発生すると、クラスタ内の別のノードがスケジューラ・ノードとしての役割を引き継ぎます。新しいスケジューラ・ノードにより、すべてのスケジュールが再初期化され、その時点から実行されます。

ノードで障害が発生した際に反復可能な実行サイクルを持つスケジュール済シナリオが実行中の場合、スケジューラ・ノードがクラッシュした時点以降、そのシナリオは新しいスケジューラ・ノードでは反復が続行されません。たとえば、スケジュール済シナリオが2分間隔で10回実行を繰り返すように構成されている場合、3回目の実行中にスケジューラ・ノードで障害が発生すると、新しいスケジューラ・ノードでは、シナリオの残りの8回は実行されません。

12.2 Formsのデプロイ

Formsをデプロイする際には、次の点を考慮します。

12.2.1 Forms HTTPセッションのフェイルオーバーからのリカバリについて

Forms HTTPセッションに障害が発生した場合、セッションをFormsアプリケーションに再接続し、再起動する必要があります。

12.3 Reportsのデプロイ

Reportsには、高可用性設定のために確認する必要のある特定の考慮事項があります。

12.3.1 Reportsでのスケール・アップについて

Reportsコンポーネントをスケール・アップする場合、構成が完了したら、すべてのノードを停止し、再び開始することをお薦めします。

Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイドのOracle Reports Serverの開始と停止を参照してください。

12.3.2 Reportsのマルチキャスト通信について

Reportsクラスタのメンバーまたは個別のクライアントは、他のノードを検出するためにマルチキャストを使用します。マルチキャスト使用の回避方法はありません。

12.3.3 Reportsの共有ファイル・ベース・キャッシュについて

Reportsには、シングルトンとして共有ファイル・ベース・キャッシュがあります。キャッシュが失敗すると、高可用性も失敗します。

回避策はありません。共有ファイル・ベースのキャッシュで障害が発生したら、Reportsサーバーを再起動する必要があります。

12.3.4 Reportsのデータベース・サービス障害について

Reportsコンポーネントは、データベース障害を容認します。Reportsは、データベース接続を3回試行します。データベースが起動してから、Reportsを再実行する必要があります。

12.3.5 ReportsのOID/共有キャッシュ・ファイル・システムの障害について

Reportsは、OID/共有キャッシュ・ファイル・システム障害が発生しても、再試行しません。回避策はありません。外部システムが起動してから、Reportsを再実行する必要があります。

12.4 Oracle Business Process Managementのデプロイ

Oracle Business Process Managementを高可用性環境でデプロイするには、次の点を考慮します。

12.4.1 BP Composerと高可用性について

BP Composerでは、高可用性が確実にはサポートされません。