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 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スケジューラ・ノードの障害

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

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

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

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

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サービス(固定サービスの動作)

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 Essbaseについて

Essbaseは、高可用性構成をサポートしていません。サーバーで障害が発生した場合、Essbase Cubeをデプロイして障害をリカバリできます。

BI Studioについて

Studioは、高可用性構成をサポートしていません。xmlインポート/エクスポートを定期的に実行することを、お薦めします。これは、Studioのカタログ障害からリカバリするためのベスト・プラクティスです。

複数のノード・マネージャへのポートの指定について

マシンごとに1つ以上のノード・マネージャがある場合、ポートが指定されていることを確認してください。

『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の一般的なエンタープライズ・デプロイメントでのノード・マネージャの構成に関する項を参照してください。

RACデータベースのインストール後の構成について

Oracle BIでは、インストール後にサーバー全体を移行するための追加の構成ステップが必要です。

これらのステップの詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のエンタープライズ・デプロイメントでのサーバー全体の移行およびサービスの移行の使用に関する項を参照してください。

BI Publisherのスケール・アウトについて

BIのスケール・アウトを完了するには、通常のスケール・アウト・ステップの他に、追加のタスクが必要になります。

Oracle BIでは、トポロジのスケール・アウト(マシンのスケール・アウト)で説明するスケール・アウトのステップに従った後、追加の構成ステップが必要です。Oracle BIでは、setDomainEnv.shを更新されたsingleton-data-directory設定(SDD)に変更する必要があります。

Oracle BIのスケール・アウトを完了するには、次のようにします。

1. SDDをローカルから共有記憶域に移動し、すべてのホストが同一のパスを使用してSDDにアクセスできるようにします。たとえば、次のように移動します。

   DOMAIN_HOME/bidata/net/yoursystem/scratch/sdd

2. DOMAIN_HOME/config/fmwconfig/bienv/core/bi-environment.xml (要素 bi:singleton-data-directory)を開きます。
3. xdo.server.config.dirパスを変更して、新しく作成したSDDパスを参照します。
4. サーバーを再起動します。

Formsのデプロイ

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

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

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

Forms HTTPセッションに障害が発生した場合、セッションを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は、データベース接続を3回試行します。データベースが起動してから、Reportsを再実行する必要があります。

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

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

Oracle Business Process Managementのデプロイ

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

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

BP Composerと高可用性について

高可用性環境では、フェイルオーバーが発生すると、BPMコンポーザのセッション状態は失われます。これが原因で作業内容が失われ、作業中の編集内容が失われます。BPMコンポーザにはセカンダリ・サーバーでアクセスできますが、ログインしなおしてセッションを新たに作成する必要があります。