| Oracle® Fusion Middleware高可用性ガイド 12c (12.2.1.0.0) E69925-01 |
|
 前 |
この項では、その他のコンポーネント製品に固有の情報について説明します。
このリリースでの、この項の内容は次のとおりです。
このトピックでは、Oracle Real Application ClustersへのOracle Data Integratorリポジトリ接続を構成する際の考慮事項について説明します。
Oracle Data Integrator (ODI) Oracle Real Application Clusters (RAC)接続を構成する場合、ODIマスターまたはODI作業リポジトリに対してOracle RAC再試行がサポートされます。ODIは、ODIシナリオの実行中に、ソース接続およびターゲット接続へのトランザクション接続を使用します。これらのソース接続およびターゲット接続については、ODIはRAC再試行の接続をサポートしていません。これらのトランザクションをOracle RACの別のノードに移行することはできません。
リポジトリ作成ユーティリティ(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の管理』の作業リポジトリの作成に関する項を参照してください。
WebLogic Serverのフェイルオーバーが発生した場合は、他のWebLogic Serverインスタンスがスケジューラになります。Coherenceキャッシュによって、スケジューラ・ライフサイクルが処理されます。ロックにより、スケジューラの一意性が保証され、イベント通知はスケジューラの移行を知らせます。エージェントが再起動され、そのスケジュールが計算された場合は、進行中のスケジュールが考慮され、それらの実行サイクルは、サーバーの起動時間を過ぎても自動的に継続されます。新しいセッションは、スケジューラが停止しなかったかのようにトリガーされます。失効セッションは、エラー状態に移動され、再起動時にはその状態が保持されます。
Oracle Data Integratorエージェント・クラスタで、スケジューラ・ノードであるエージェント・ノードに障害が発生すると、クラスタ内の別のノードがスケジューラ・ノードとしての役割を引き継ぎます。新しいスケジューラ・ノードにより、すべてのスケジュールが再初期化され、その時点から実行されます。
ノードで障害が発生した際に反復可能な実行サイクルを持つスケジュール済シナリオが実行中の場合、スケジューラ・ノードがクラッシュした時点以降、そのシナリオは新しいスケジューラ・ノードでは反復が続行されません。たとえば、スケジュール済シナリオが2分間隔で10回実行を繰り返すように構成されている場合、3回目の実行中にスケジューラ・ノードで障害が発生すると、新しいスケジューラ・ノードでは、シナリオの残りの8回は実行されません。
この項には次のトピックが含まれます:
|
関連項目: Oracle Application Development Framework (ADF)の詳細は、次を参照してください。
|
Oracle JRF非同期Webサービスを使用している場合は、非同期Webサービスがサービスに固定されるため、フェイルオーバーは実行されません。WS-RMなどの信頼性の高いプロトコルを使用している場合は、障害の発生後に、より上位レベルのプロトコルによって新しいサーバーへの再接続が実行されます。
Oracle JRF非同期Webサービスの詳細は、『ドメイン・テンプレート・リファレンス』を参照してください。
この項では、次の項目について説明します。
BI管理対象サーバーまたはホスト(あるいはその両方)がクラッシュすると、再びログインが必要な場合があります。これは、クラッシュの発生時にどのアプリケーションを使用していたか、およびSSOを使用していたかどうかにより、異なります。
Essbaseは、高可用性構成をサポートしていません。サーバーで障害が発生した場合、Essbase Cubeをデプロイして障害をリカバリできます。
Studioは、高可用性構成をサポートしていません。xmlインポート/エクスポートを定期的に実行することを、お薦めします。これは、Studioのカタログ障害からリカバリするためのベスト・プラクティスです。
マシンごとに1つ以上のノード・マネージャがある場合、ポートが指定されていることを確認してください。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』を参照してください。
Oracle Business Intelligenceでは、インストール後にサーバー全体を移行するための追加の構成手順が必要です。これらの手順の詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のエンタープライズ・デプロイメントでのサーバー全体の移行およびサービスの移行の使用に関する項を参照してください。
Oracle Business Intelligenceでは、第6章「トポロジのスケール・アウト(マシンのスケール・アウト)」で説明するスケール・アウトの手順に従った後、追加の構成手順が必要です。Oracle BIでは、setDomainEnv.shを更新されたsingleton-data-directory設定(SDD)に変更する必要があります。
Oracle BIのスケール・アウトを完了するには、次のようにします。
SDDをローカルから共有記憶域に移動し、すべてのホストが同一のパスを使用してSDDにアクセスできるようにします。たとえば、次のように移動します。
DOMAIN_HOME/bidata/net/yoursystem/scratch/sdd
DOMAIN_HOME/config/fmwconfig/bienv/core/bi-environment.xml (要素 bi:singleton-data-directory)を開きます。
xdo.server.config.dirパスを変更して、新しく作成したSDDパスを参照します。
サーバーを再起動します。
この項では、次の項目について説明します。
Forms HTTPセッションに障害が発生した場合、セッションをFormsアプリケーションに再接続し、再起動する必要があります。
高可用性設定でのReportsには、次の考慮事項があります。
Reportsコンポーネントをスケール・アップする場合、構成が完了したら、すべてのノードを停止し、再び開始することをお薦めします。
『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』のOracle Reports Serverの開始と停止に関する項を参照してください。
Reportsクラスタのメンバーまたは個別のクライアントは、他のノードを検出するためにマルチキャストを使用します。マルチキャスト使用の回避方法はありません。
Reportsには、シングルトンとして共有ファイル・ベース・キャッシュがあります。キャッシュが失敗すると、高可用性も失敗します。
回避策はありません。共有ファイル・ベースのキャッシュで障害が発生したら、Reportsサーバーを再起動する必要があります。
Reportsコンポーネントは、データベース障害を容認します。Reportsは、データベース接続を3回試行します。データベースが起動してから、Reportsを再実行する必要があります。
Reportsは、OID/共有キャッシュ・ファイル・システム障害が発生しても、再試行しません。回避策はありません。外部システムが起動してから、Reportsを再実行する必要があります。
