ヘッダーをスキップ
Oracle® Fusion Middleware高可用性ガイド
11g リリース1 (11.1.1)
B55898-07
  目次へ移動
目次

前
 
次
 

7 Oracle Data Integratorの高可用性

Oracle Data Integratorは、データ統合プロセスを設計、デプロイおよび管理するコンポーネントの完全なセットを提供します。データ統合プロセスでは、ELT(抽出、ロード、変換)アプローチを使用して、データをソース・データ・サーバーからターゲット・データ・サーバーに移行して変換します。ELTは、ソース・データ・サーバーとターゲット・データ・サーバーにすべての変換を委任することで、変換エンジンの必要性をなくすアプローチです。

この章では、Oracle Data Integratorコンポーネントについて高可用性の観点から説明します。この章の各項では、高可用性を備えたデプロイメントの設計に重要な単一インスタンスの概念について概要を説明します。

この章の内容は次のとおりです。

7.1 Oracle Data Integratorの概要

図7-1に示すように、Oracle Data Integratorは、データ統合プロセスを開発、デプロイおよび監視するための包括的な機能セットを提供します。Oracle Data Integratorは、Javaコンポーネントに基づく、統一されたランタイム・アーキテクチャを提供します。

ランタイム・アーキテクチャは、次のもので構成されています。

7.2 Oracle Data Integratorの単一インスタンスの特性

図7-1は、Oracle Data Integratorの単一インスタンスのアーキテクチャを示しています。

図7-1 Oracle Data Integratorの単一インスタンス・アーキテクチャ

図7-1の説明が続きます
「図7-1 Oracle Data Integratorの単一インスタンス・アーキテクチャ」の説明

Oracle Data Integratorのランタイム・エージェントは、統合プロセスを管理します。Oracle Data Integratorエージェントは、リポジトリに格納されているシナリオに従って統合ジョブを実行する、本番構成にデプロイされたコンポーネントです。

Oracle Data Integratorエージェントは、各シナリオ実行インスタンスをセッションとして処理します。各セッションは、エージェントのJavaプロセスの別のスレッドとしてエージェント内に存在します。

エージェントには、実行するセッションに関する非常に基本的な情報が格納されます。ほとんどのセッション・データは、リポジトリに格納されます。エージェントでシナリオが実行される際、エージェントは、リポジトリ内にこのシナリオのインスタンスに対応するセッションを作成します。エージェントは、リポジトリからこのセッションの各タスクを読み取り、それを処理して、リポジトリに結果(リターン・コード、メッセージ、および処理にかかった時間や処理された行の数などのタスク・メトリック)を書き込みます。

リポジトリは、2つのデータベース・スキーマで構成されています。1つはマスター・リポジトリを含み、もう1つは作業リポジトリを含みます。マスター・リポジトリには、トポロジとセキュリティに関連するすべての情報(ソース・データ・サーバー定義、ターゲット・データ・サーバー定義、ユーザーの資格証明など)が含まれます。作業リポジトリには、開発データおよびランタイム・データ(セッションやシナリオなど)が含まれます。マスター・リポジトリには、作業リポジトリへの接続情報も含まれます。作業リポジトリに接続するには、エージェントは、まずマスター・リポジトリに接続し、Oracle Data Integratorユーザーの資格証明をチェックして、作業リポジトリの接続情報を読み取ってから、作業リポジトリに接続します。通常のトポロジには、1つのマスター・リポジトリと、場合によっては複数の作業リポジトリ(テスト用と本番用など)が含まれます。

エージェントでセッションを開始する方法は次のとおりです。

エージェントは常に、マスター・リポジトリにアタッチされます。これは、起動時にこのマスター・リポジトリに接続し、このマスターにアタッチされた作業リポジトリのいずれかでセッションを開始できます。また、スケジューラとしても機能します。起動時、エージェントは、複数の作業リポジトリからそのエージェント用に定義されているスケジュールを読み取り、このスケジューリング情報を格納します。エージェントは、適切な作業リポジトリでこのメモリー内スケジュールからセッションを開始できます。

エージェントは、リモートのシナリオ起動(HTTP経由)を通じて、またはロード・バランシング機能によって相互に対話できます。ロード・バランシングでは、親/子エージェントの階層を定義できます。この階層内で、親エージェントは、自分のセッションの処理を各自の子エージェントに委任できます。

エージェントは、Java EEエージェントまたはスタンドアロン・エージェントとして提供されるJavaプログラムです。Java EEエージェントは、同じJVM内の他のWebアプリケーションとともに、Java EEアプリケーション・サーバーにデプロイ可能なWebアプリケーションです。このエージェントは、このサーバーのデータ・ソースを使用して、ソース、ターゲットおよびリポジトリ・データベースに接続できます。

スタンドアロン・エージェントは、コマンドライン・インタフェースから起動されるスタンドアロンJavaプロセスとして提供されます。このスタンドアロン・エージェントは、Java EEエージェントに似ていますが、軽量コンテナに組み込まれます。主な違いは、スタンドアロン・エージェントは、Java EEエージェントとは異なり、直接JDBC接続のみを使用してソース・データ・サーバーとターゲット・データ・サーバーに接続できるというところです。

7.2.1 Oracle Data Integratorセッションのライフサイクルとリカバリ

ランタイム・エージェントに実行リクエストが到着すると、エージェントは、マスター・リポジトリに接続してユーザーの資格証明をチェックしてから、作業リポジトリに接続してセッションとそのすべてのタスクを作成し、それらをwaitingとしてマークします。次に、このセッションで使用されるすべてのデータ・サーバーへの接続を作成します。

実行が開始されると、エージェントは、作業リポジトリ内の最初の実行対象タスクを読み取り、セッションとこのタスクの両方をrunningとしてマークします。このタスクは、データ・サーバーまたはオペレーティング・システムで操作を開始できます。タスクが完了すると、エージェントは、このタスクの実行結果を作業リポジトリに書き込み、それを終了済の状態(DoneWarningまたはError)に移動します。エラーについてはODIパッケージで処理でき、エラーが必ずしもセッションを停止させるわけではないことに注意してください。管理対象外のエラーまたは最終手順に達したためにセッションが完了すると、エージェントは、そのセッションを終了済の状態に移動し、すべての接続を解放します。この時点で、セッションは終了します。

7.2.1.1 セッションの中断

セッションは、次の場合に中断することがあります。

  • ユーザーがエージェントにセッションの停止をリクエストしたとき。

  • 管理者によってエージェントが停止されたとき。選択されたエージェント停止モードに応じて、このエージェントのすべてのセッションは停止されます。

  • エージェントまたはリポジトリでクリティカル・イベントが発生したとき。

ユーザーまたは管理者のアクションによって停止されたすべてのセッションは、エラー状態に移動され、「停止済」としてマークされます。

エージェントまたはリポジトリで障害が発生した場合、正常に停止できなかったセッションは、リポジトリ内で実行状態として表示されます。これらのセッションは、実行中としてマークされてはいますが、どのエージェントによっても処理されないため、失効セッションです。エージェントが再起動され、失効セッションがリポジトリ内でこのエージェントによる実行状態を正しく反映していないことが検出されると、これらのセッションは自動的にエラー状態に移動されます。

7.2.1.2 セッションのリカバリ

Oracle Data Integratorは、ソース・データ・サーバーおよびターゲット・データ・サーバーとの対話時にJDBCトランザクションを使用し、セッションがエラー状態で終了した場合、オープン・トランザクションの状態は永続化されません。適切な再起動ポイントは、未完了のトランザクションを起動したタスクです。そのような再起動ポイントが特定できない場合、エラー状態にある既存のセッションを再開するのではなく、シナリオを実行することで新たなセッションを開始することをお薦めします。

デフォルトで、セッションは、実行に失敗した最後のタスク(通常は、エラー状態または待機状態のタスク)から再開されます。既存のステージング表での処理を続行し、長い時間のかかるロード・フェーズの再実行を回避するために、セッションを再開する必要がある場合もあります。その場合、ユーザーは、KM固有のトランザクション管理を考慮に入れる必要があります。一般的なガイドラインとしては、ロード・タスクで障害が発生した場合、失敗したロード・タスクから再起動できます。統合フェーズで障害が発生した場合、ターゲットへの統合はトランザクション内で行われるため、最初の統合タスクから再起動します。このガイドラインは、一度に1つのインタフェースにのみ適用されます。複数のインタフェースが連鎖しており、最後のインタフェースのみがコミットされている場合、トランザクションは複数のインタフェースにわたって実行されるため、それらの複数のインタフェースをすべて再起動する必要があります。

特定のタスクまたは手順から再起動する手順は次のとおりです。

  1. オペレータ・ナビゲータで、このタスクまたは手順に移動し、それを編集して、「待機中」状態に切り替えます。

  2. 「オペレータ」ツリー・ビューで、これ以降のすべてのタスクおよび手順を「待機中」状態に設定します。

  3. セッションを右クリックし、「再起動」をクリックします。

セッションが、待機状態の最初のタスクから再開されます。

7.2.2 エージェントの起動とシャットダウンのサイクル

図7-2は、エージェントの起動のサイクルを示しています。

図7-2 Oracle Data Integratorエージェントの起動のサイクル

図7-2の説明が続きます
「図7-2 Oracle Data Integratorエージェントの起動のサイクル」の説明

Oracle Data Integratorエージェントの起動時、まず、マスター・リポジトリの接続情報を含む構成を読み取ります。次に、エージェントは、このマスター・リポジトリにアタッチされたそれぞれの作業リポジトリに接続し、失効セッションを削除します。失効セッションは、この特定のエージェントで実行中であると、作業リポジトリで誤って示されているセッションです。失効セッションは、これらのセッションを正常に停止できずにエージェントが停止されたことで生じる場合があります。エージェントが再起動されると、そのセッションは、失効セッションとして識別され、エラー状態に移動されます。

その時点で、エージェントは、各作業リポジトリで使用可能なスケジュールを取得して計算できます。このフェーズが終了すると、エージェントは、受信セッション・リクエストを待機してそれらの処理を開始し、さらに、スケジュールに基づいてセッションを開始できます。

7.2.3 Oracle Data Integratorの外部依存性

Oracle Data Integratorは、Oracle Data Integratorのマスター・リポジトリおよび作業リポジトリ・データベース・スキーマに依存します。

拡張機能が使用されている場合、次のような他の依存性が存在する可能性があります。

  • 他のOracle Data Integratorエージェント: ロード・バランシング機能が構成されており、エージェントがセッションの実行をその子エージェントに委任する必要がある場合。

  • このエージェントのマスター・リポジトリに対して外部パスワード記憶域が有効な場合、エージェントは、セッションの実行時にソース・データ・サーバーとターゲット・データ・サーバーに接続するためのパスワードを取得する際、資格証明ストアに依存します。

  • このエージェントのマスター・リポジトリに対して外部認証が有効な場合、ラインタイム・エージェントとOracle Data Integratorコンソールは、Oracle Data Integratorのユーザー・アカウントを格納するアイデンティティ・ストア・サービスに依存します。

Oracle Data Integratorシステムが適切に起動し、実行されるためには、これらのコンポーネントが使用可能である必要があります。

7.2.4 Oracle Data Integratorの起動およびシャットダウン・プロセス

Oracle Data Integrator Java EEエージェントがデプロイされているOracle WebLogic管理対象サーバーが起動するたびに、Oracle Data Integrator Java EEエージェント・アプリケーションがデフォルトで起動します。通常は、Oracle Data Integratorやそのコンポーネント自体を停止する必要はありません。一部の操作では、Oracle Data Integratorが実行されているOracle WebLogic管理対象サーバーの再起動が必要な場合があります。アプリケーションの停止が必要なのは、一部のパッチを適用するときのみです。

管理コンソールを使用すると、ステータスを確認したり、Oracle WebLogic Serverを起動および停止したりできます。アプリケーションの制御に、WebLogic Server WLSTのコマンドラインも使用できます。Oracle Enterprise Manager Fusion Middleware Controlを使用すると、Oracle Data Integratorの多数の操作と構成を行えるだけでなく、ステータスを監視することもできます。

7.2.5 Oracle Data Integratorの構成アーティファクト

この項では、Oracle Data Integratorの構成アーティファクトについて説明します。

7.2.5.1 Java EEエージェントの構成

Java EEエージェントの構成パラメータは、エージェント・アプリケーションと、エージェントがアタッチされているマスター・リポジトリの両方に格納されます。

図7-3に示すように、マスター・リポジトリに格納されたエージェント構成は、Oracle Data Integrator Studioから編集でき、次の主要なパラメータを含みます。

  • ホスト

  • ポート

  • Webアプリケーション・コンテキスト

図7-3 Oracle Data Integrator Studioに表示されるマスター・リポジトリのエージェント構成

図7-3の説明が続きます
「図7-3 Oracle Data Integrator Studioに表示されるマスター・リポジトリのエージェント構成」の説明

この情報と有効な資格証明を使用して、リポジトリに接続するコンポーネントは、<host>:<port>/<web_application_context> URL上のこのエージェントから実行をリクエストできます。「Webアプリケーション・コンテキスト」に別の値を指定することで、同じホストとポートのペアで複数のエージェントを起動できます。

この情報に加えて、マスター・リポジトリには次の情報も含まれます。

  • ソース、ターゲットおよびリポジトリ・データベース・ホストに接続するための、このエージェントによって使用されるデータ・ソース名。

  • ロード・バランシング機能のためのエージェントの階層。

Oracle Data Integrator Studioは、特定のエージェントのOracle WebLogicテンプレートを生成する機能を提供します。このテンプレートには、エージェントのバイナリ、構成およびデータ・ソース定義が含まれます。Oracle WebLogic管理者は、これらのテンプレートを使用して、クラスタに事前構成されたエージェントをデプロイできます。

データ・ソースの作成や変更など、コンテナ・レベルの他の構成オプションは、WebLogic Serverのドメイン構成として使用可能であり、Oracle WebLogic Serverのコア・インフラストラクチャにより、Oracle WebLogic Serverのクラスタ上で同期化されます。

Java EEエージェントのデプロイメント・オプションの詳細は、『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の「トポロジの設定」を参照してください。

7.2.5.2 スタンドアロン・エージェント構成

スタンドアロン・エージェントの構成パラメータは、スタンドアロン・エージェント構成ファイルと、このエージェントがアタッチされているマスター・リポジトリの両方に格納されます。エージェント構成のリポジトリの部分は、Java EEエージェントに似ています。

エージェント構成は、構成ファイルに格納されているか、インストール・フォルダに格納されているかに応じて異なります。

  • UNIXの場合: ODI_HOME/oracledi/agent/bin/odiparams.sh

  • Windowsの場合: ODI_HOME/oracledi/agent/bin/odiparams.bat

この構成ファイルには、スタンドアロン・エージェント構成の一部として手動で編集する必要のある次のパラメータが含まれます。

  • マスター・リポジトリに接続するためのJDBC接続情報

  • ODIスーパーバイザ・ユーザーおよび暗号化されたパスワード

スタンドアロン・モードで起動されたエージェントは、その起動に使用されたコマンドラインでも構成されます。このコマンドラインには次のパラメータが含まれます。

  • リスニング・ポート

  • エージェント名

  • トレース・レベル

このエージェントに実行リクエストを送信するコンポーネントは、<host>:<port>/oraclediagentというURLで送信することになります。デプロイ済のスタンドアロン・アプリケーション名はoraclediagentに設定されることに注意してください。結果として、単一のホスト上で複数のスタンドアロン・エージェントを起動するには、別々のポートを使用する必要があります。

エージェントの構成の詳細は、『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の「トポロジの設定」を参照してください。

7.2.5.3 Oracle Data Integratorコンソールの構成

Oracle Data Integratorコンソールの構成は、このWebアプリケーションを使用して参照可能なマスター・リポジトリと作業リポジトリへの接続定義で構成されます。

接続のリストは、次のディレクトリにあるrepositories.xmlファイルに格納されます。

user_projects/domains/domainName/config/oracledi

接続は、Oracle Data Integratorコンソールの管理ページで追加、編集または削除できます。


注意:

Oracle Data Integratorコンソールは、ドメイン内のOracle Data Integratorターゲットを検出するためのEnterprise Managerのエントリ・ポイントとして使用されます。検出プロセスは、次のような方法で動作します。Enterprise ManagerがOracle Data Integratorコンソールを識別します。Oracle Data Integratorコンソールの構成を使用して、Enterprise Managerは、マスター・リポジトリと作業リポジトリ、ドメイン内のおよびランタイム・エージェントを識別します。


7.2.5.4 Oracle Data Integratorのログの場所と構成

この項では、Oracle Data Integratorのログの場所と構成について説明します。

7.2.5.4.1 Oracle Data Integratorのセッション・ログ

Oracle Data Integratorのセッション実行ログは、セッションが起動される対象となった作業リポジトリに格納されます。このセッションには、処理された行の数や実行済コードなど、Oracle Data Integratorのセッションの詳細が表示されます。Oracle Data Integrator Studioのオペレータ・ナビゲータ(「セッション・リスト」アコーディオン)、またはOracle Data Integratorコンソールの「参照」タブ(「ランタイム」>「セッション」)からログを表示します。

7.2.5.4.2 Java EEエージェントのログ・ファイル

Oracle Data Integrator Java EEエージェントにより実行される操作は、エージェント・アプリケーションが実行されているOracle WebLogic管理対象サーバーによってログに記録されます。これらのログは、次の場所にあります。

DOMAIN_HOME/servers/WLS_ServerName/logs/oracledi/odiagent.log

別のOracle WebLogic Server管理対象サーバーのログ・ファイルも、管理コンソールで使用できます。ログを確認するには、URL: admin_server_host:port/consoleを使用して管理コンソールにアクセスします。「診断-ログ・ファイル」をクリックします。

Oracle Data Integratorが実行されているOracle WebLogic管理対象サーバーの出力を確認することも重要です。この情報は次の場所に格納されています。

DOMAIN_HOME/servers/WLS_ServerName/logs/WLS_ServerName.out

さらに、管理対象サーバーのログ・ディレクトリに診断ログが作成されます。このログの粒度とロギング・プロパティは、次のファイルで変更できます。

DOMAIN_HOME/config/fmwconfig/logging/oraclediagent-logging.xml
7.2.5.4.3 スタンドアロン・エージェントのログ・ファイル

Oracle Data Integratorスタンドアロン・エージェントにより実行される操作は、スタンドアロン・エージェントを実行している軽量コンテナによってログに記録されます。デフォルトでは、ログは、コンソールおよびODI_HOME/oracledi/log/フォルダでトレースされます。

ロギング方法およびロギング・レベルは、ODI_HOME/oracledi/agent/bin/ODI-logging-config.xmlファイルを編集することで構成できます。

7.2.5.4.4 Oracle Data Integratorコンソールのログ・ファイル

Oracle Data Integratorコンソールのロギング操作は、第7.2.5.4.2項「Java EEエージェントのログ・ファイル」で説明されているJava EEエージェントのログ・ファイルと同様に、エージェント・アプリケーションが実行されているOracle WebLogic管理対象サーバーによってログに記録されます。

7.3 Oracle Data Integratorの高可用性とフェイルオーバーに関する考慮事項

この項では、Oracle Data Integratorの高可用性とフェイルオーバーに関する考慮事項について説明します。

7.3.1 Oracle Data Integratorのクラスタ・デプロイメント

図7-4は、2つのOracle WebLogicサーバーで2ノードのOracle Data Integratorクラスタが実行されている様子を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。

図7-4 Oracle Data Integratorの高可用性アーキテクチャ

図7-4の説明が続きます
「図7-4 Oracle Data Integratorの高可用性アーキテクチャ」の説明

この構成の主要な特性は、次のとおりです。

  • Oracle Data Integratorアプリケーションは、クラスタ化された2つのWebLogic Serverの管理対象サーバー上で実行されます。WebLogic Serverクラスタは、データ・ソースなど、Oracle Data Integratorで使用されるWebLogic Serverの共通アーティファクトの構成を同期化します。

  • スケジュールが重複して処理されることを回避するため、これらのエージェントのうち1つのみがスケジューラとして動作します。Coherenceキャッシュは、スケジューラ・サービスの一意性と移行を処理するために使用されます。

    エージェントは、フェイルオーバー・スケジュール機能を提供します。たとえば、スケジューラが午前9時に起動し、4時間ごとの毎正時にジョブXが実行されるサイクルが設定されており、午前9時55分にエージェントに障害が発生したとします。この場合、サイクル内にあったジョブXは計算を実行し、続行されます。ただし、単一のジョブが午前9時に開始されるようにスケジュールされている場合、午前8時59分にエージェントに障害が発生し、午前9時1分にリカバリされると、午前9時にスケジュールされていたジョブは実行されません。

  • クラスタ内のOracle Data Integratorエージェントへのリクエストは、ロード・バランサまたはHTTPプロキシ・サーバー経由でルーティングされる必要があります。クライアントは、このフロント・サーバーのアドレスを使用して、クラスタ内の任意のOracle Data Integratorサーバーに透過的に接続します。このアドレスは、マスター・リポジトリ内のエージェント定義で指定されている必要があります。スケジューラ・シングルトンは、スケジュール済のすべてのセッション起動リクエストをこのアドレスにルーティングし、リクエストはクラスタにロード・バランシングされるようになります。

  • Oracle Data Integratorのマスター・リポジトリおよび作業リポジトリのデータベースは、データベースの障害から保護するために、Oracle Real Application Cluster(Oracle RAC)で構成されます。データベース・インスタンスの障害が発生すると、Oracle Data Integratorコンポーネントは、再接続と操作の再試行を適切に実行します。

7.3.2 OPMNを使用したスタンドアロン・エージェントの高可用性

スタンドアロン・エージェントは、コマンドライン・インタフェースから起動されるスタンドアロンJavaプロセスです。このエージェントは通常、最適な統合フロー・パフォーマンスを実現するために、ソース・マシンまたはターゲット・マシン上にローカルにデプロイされます。OPMNを使用して、この状況でスタンドアロン・エージェントを起動、停止および保護できます。

スタンドアロン・エージェントをOPMNに追加するには、次の手順を実行します。

  1. ODI_HOME/oracledi/agent/bin/ディレクトリにあるagentcreate.propertiesファイルを、エージェントおよびOPMN構成に一致するように編集します。

  2. このエージェントをOPMN構成に追加するスクリプトを実行します。

    • UNIXの場合: ODI_HOME/oracledi/agent/bin/opmn_addagent.sh

    • Windowsの場合: ODI_HOME/oracledi/agent/bin/opmn_addagent.bat

opmnctlを使用して、次のようにOracle HTTP Serverのステータスを確認できます。

opmnctl status

opmnctlを使用して、Oracleインスタンスのすべてのエージェント・コンポーネントを起動するには、次を実行します。

opmnctl startproc process-type=odiagent

opmnctlを使用して、odiagent1など、特定のエージェント・コンポーネントを起動するには、次を実行します。

opmnctl startproc ias-component=odiagent1

opmnctlを使用して、Oracleインスタンスのすべてのエージェント・コンポーネントを停止するには、次を実行します。

opmnctl stopproc process-type=odiagent

opmnctlを使用して、odiagent1など、特定のエージェント・コンポーネントを停止するには、次を実行します。

opmnctl stopproc ias-component=odiagent1

7.3.3 障害からのOracle Data Integratorの保護および必要な対応

この項では、Oracle Data Integratorの高可用性クラスタのデプロイメントおよびOPMNでコンポーネントがどのようにして障害から保護されるかを説明します。また、この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。

7.3.3.1 WebLogic Serverまたはスタンドアロン・エージェントのクラッシュ

WebLogicサーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへのサーバーの移行を試行します。フェイルオーバーの発生時、他のWebLogicインスタンスは、スケジューラになり、すべての作業リポジトリのスケジュールの読取り、計算および実行を行えるようになります。Coherenceキャッシュは、スケジューラ・ライフサイクルを処理するために使用されます。ロックにより、スケジューラの一意性が保証され、イベント通知はスケジューラの移行を知らせます。エージェントが再起動され、そのスケジュールを計算する場合、進行中のスケジュール(実行サイクルの途中にあるスケジュール)が考慮されることに注意してください。これらのスケジュールは自動的に、サーバーの起動時間を過ぎても実行サイクル内で続行されます。新しいセッションが、スケジューラが停止しなかったかのようにトリガーされます。

失効セッションは、エラー状態に移動され、再起動時にはエラー状態のセッションとして扱われます。このセッションのリカバリ/再起動の説明は、第7.2.1.1項「セッションの中断」および第7.2.1.2項「セッションのリカバリ」にあります。

スタンドアロン・エージェントで障害が発生すると、OPMNはそのエージェントをローカルに再起動します。障害のあるエージェントで実行されている既存のセッションは、失効セッションとなります。失効セッションは、エージェントの再起動時に削除されます。

Oracle Data Integratorエージェントは、リソースへのアクセスの失敗、または管理対象サーバーが実行されているかどうかには関係なく発生する問題が原因で停止する場合があります。そのため、管理者がアプリケーションによって引き起こされるクラスタ・エラーを管理対象サーバーのログで監視することをお薦めします。ログ・ファイルの場所の詳細は、第7.2.5.4項「Oracle Data Integratorのログの場所と構成」を参照してください。

Oracle Data Integratorコンソールは、HTTPセッションのフェイルオーバーをサポートしていません。ユーザーは、障害の発生後、Oracle Data Integratorコンソールに再度ログインする必要があります。

7.3.3.2 リポジトリ・データベースの障害

Oracle Data Integratorリポジトリは、マルチ・データ・ソースの使用によりデータベースの障害から保護されます。通常、これらのマルチ・データ・ソースは、システムの初期設定時に構成され(Oracle Fusion Middleware構成ウィザードで、インストール時にマルチプールを直接定義できます)、これらのソースによって、リポジトリをホストするOracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。

Java EEエージェントは、初期設定時に構成されるWebLogicマルチ・データ・ソースを使用します。スタンドアロン・エージェントは、odiparams.shで指定されたOracle RAC JDBC接続を使用します。

Oracle RACでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

Oracle Data Integratorは、リポジトリ・インスタンスが使用できなくなり、後でリストアされる場合に、進行中のセッションの続行を可能にする再試行ロジックを実装します。Oracle RACが有効な構成では、Oracle RACノードが使用可能であれば、進行中のセッション実行リクエストと受信するセッション実行リクエストの両方が処理されます。これは、接続再試行および接続再試行の遅延時間パラメータを使用して、スタンドアロン・エージェントとJava EEエージェントの両方でサポートされます。ユーザーは、Java EEエージェントのWebLogic Serverテンプレートの生成時に、スタンドアロン・エージェントのodiparams.shまたはodiparams.batを編集することで、これらのパラメータを構成できます。

Oracle Data Integrator StudioでOracle RACデータベースへの接続が失われた場合、最後の保存操作以降に実行されたOracle Data Integrator Studioの作業はすべて失われます。一般に、Oracle Data Integrator Studioの使用時には定期的に作業を保存することをお薦めします。

7.3.3.3 スケジューラ・ノードの障害

Oracle Data Integratorエージェント・クラスタで、スケジューラ・ノードであるエージェント・ノードで障害が発生すると、WebLogic Serverクラスタ内の別のノードがスケジューラ・ノードとしての役割を引き継ぎます。新しいスケジューラ・ノードは、その時点からのすべてのスケジュールを再初期化し、その時点以降のスケジュール済シナリオの実行を続行します。

ただし、元のスケジュール・ノードのクラッシュ時に、そのノードで、繰り返し可能な実行サイクルでのスケジュール済シナリオが実行されていた場合は、この状況で問題が生じます。新しいスケジューラ・ノードが引き継いだとき、元のスケジューラ・ノードで実行されていたスケジュール済シナリオは、元のスケジューラ・ノードがクラッシュした時点以降、新しいスケジューラ・ノードでその反復を続行しません。

たとえば、スケジュール済シナリオが2分間隔で10回実行を繰り返すように構成されている場合に、3回目の実行の途中で元のスケジューラ・ノードで障害が発生すると、新しいスケジューラ・ノードは、引き続きシナリオの実行を8回繰り返す必要があります。しかし、新しいスケジューラ・ノードでは、残りの分のシナリオの実行が継続されません。

7.4 Oracle Data Integratorの高可用性の構成

この項では、Oracle Data Integratorの高可用性の構成を設定するためのインストールおよび構成手順について説明します。

7.4.1 マスター・リポジトリと作業リポジトリを作成するためのRCUの実行

リポジトリ作成ユーティリティ(RCU)の最新バージョンを作成して、Oracle RACデータベース・リポジトリでOracle Data Integrator用の必要なスキーマを作成します。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

次のコマンドを実行してRCUを起動します。

RCU_HOME/bin/rcu

次の手順を実行します。

  1. 「リポジトリの作成」ページで、新規スキーマの作成およびロードを選択します。

  2. 「データベース接続の詳細」ページで、データベースの詳細を入力します。Oracle RACでは、1つのモードのみが必要です。

  3. 「コンポーネントの選択」ページで、「Oracle Data Integrator」を選択します。これにより、「マスターおよび作業リポジトリ」が自動的に作成されます。

  4. 「スキーマ・パスワード」ページで、スキーマのパスワードを指定します。

  5. 「カスタム変数」ページで、少なくとも「スーパーバイザ・パスワード」と「作業リポジトリ・パスワード」を指定します。他のすべてのフィールドはデフォルトのままでかまいません。

  6. 「表領域のマップ」画面で、「OK」をクリックします。

  7. 「サマリー」画面で、「OK」をクリックし、リポジトリのインストールを終了します。

7.4.2 最初のOracle Data Integratorホストのインストールと構成

この項では、最初のOracle Data Integratorホスト(APPHOST1など)のインストールおよび構成手順について説明します。

7.4.2.1 APPHOST1へのOracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

Oracle WebLogic Serverインストーラを起動します。

インストーラが起動したら、次の手順に従ってOracle WebLogic Serverをコンピュータにインストールします。

  1. 「ようこそ」画面で「次へ」をクリックします。

  2. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。次に、Oracle WebLogicソフトウェアのインストール先となるコンピュータ上のディレクトリを選択します。

    「次へ」をクリックします。

  3. 「セキュリティ更新のための登録」画面で、「My Oracle Support」のユーザー名とパスワードを入力して、セキュリティ・アップデートが通知されるようにします。

  4. 「インストール・タイプの選択」画面では、完全インストールとカスタム・インストールのどちらを実行するかを指示するように求めるプロンプトが、インストール・プログラムによって表示されます。

    標準」を選択します。

    「次へ」をクリックします。

  5. 「製品インストール・ディレクトリの選択」画面で、WebLogic ServerおよびCoherenceのデフォルトの場所を受け入れます。

    「次へ」をクリックします。

  6. 「インストール・サマリー」画面に、インストール対象として選択したコンポーネントの一覧と、それらをインストールするために使用されるディスク領域の概算値が表示されます。

    「次へ」をクリックします。

  7. 完了」をクリックしてインストーラを終了します。

7.4.2.2 APPHOST1へのOracle Data Integratorのインストール

Oracle Data Integratorインストーラを起動します。

./runInstaller

インストーラからJDKの場所の指定を求められたら、Middlewareホームの下のSDKへのフルパスを入力します。

次のインストール手順を実行します。

  1. 「インベントリ・ディレクトリの指定」画面が表示されたら、Oracleのインベントリの場所およびOSグループ名を入力し、「OK」をクリックします。

  2. 「インストール・タイプの選択」画面で、次の操作を行います。

    • J2EEインストール」を選択します。

    • オプションで、Oracle Data Integrator Studioが必要な場合は、「開発者」インストールを選択します。

  3. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

  4. 「インストール場所の指定」画面で、リストからMiddlewareホームを選択します。

    「次へ」をクリックします。

  5. リポジトリ構成画面で、リポジトリ構成をスキップを選択し、「次へ」を選択します。

  6. 「インストール・サマリー」画面で、「インストール」をクリックしてインストールを開始します。

  7. 「インストール完了」画面で「終了」をクリックします。

7.4.2.3 高可用性ドメインの作成

構成ウィザードを起動するには、ODI_HOME/common/binディレクトリでconfig.shを実行します。次の手順を実行します。

  1. 「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択します。

  2. 「ドメイン・ソースの選択」画面で、次のコンポーネントを選択します。

    • Oracle Data Integrator SDK Webサービス - 11.1.1.0

    • Oracle Data Integrator - コンソール - 11.1.1.0

    • Oracle Data Integrator - エージェント - 11.1.1.0

    Oracle Enterprise ManagerおよびODI用のOracle Enterprise Managerプラグインもオプションで選択します。

  3. 「ドメイン名と場所の指定」画面で、ドメイン名を入力し、「次へ」をクリックします。

  4. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの優先ユーザー名とパスワードを入力します。

  5. 「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」モードを選択します。「次へ」をクリックします。

  6. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

    1. 下部にある表に表示されるコンポーネント・スキーマ(ODIマスター・スキーマおよびODI作業スキーマ)をすべて選択します。

    2. 「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択します。単一のデータベース構成の場合は、「変換しない」を選択します。

    3. 画面に次のデータ・ソースが表示されていることを確認します。表7-1に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にDEVが使用されていることを想定しています。

      Oracle RACでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照してください。

      Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

      表7-1 データ・ソースの値の構成

      コンポーネント・スキーマ スキーマ所有者

      ODIマスター・スキーマ

      DEV_ODI_REPO

      ODI作業スキーマ

      DEV_ODI_REPO


    4. 「次へ」をクリックします。

  7. 「JDBCコンポーネント・スキーマの構成」画面で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

    マルチ・データ・ソースの場合は、次のフィールドに値を入力します。

    図7-5 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

    図7-5の説明が続きます
    「図7-5 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

    GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。

    図7-6 GridLink RACコンポーネント・スキーマの構成

    図7-6の説明が続きます
    「図7-6 GridLink RACコンポーネント・スキーマの構成」の説明

    1. ドライバ: RACの場合にはOracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合はOracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

    2. サービス名 : データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。


      注意:

      Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(例: example.com)を含むRACサービス名を登録または追加することをお薦めします。


    3. ユーザー名接頭辞: スキーマの接頭辞を入力します。表7-1に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にDEVが使用されていることを想定しています。

    4. 「パスワード」と「パスワードの確認」: スキーマにアクセスするときのパスワードを入力します。

    5. GridLinkデータ・ソースの場合は、SCANアドレスをリスナー・アドレス・フィールドに入力し、「ポート」フィールドにSCANポートを入力します。「ONSホスト」と「ポート」の各フィールドに、ONSホストおよびポート情報を入力します。


      注意:

      WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、SCANアドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、ネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。


      マルチ・データ・ソースの場合は「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。

    6. 一度に1つのデータ・ソースを選択し、適切な詳細を追加することにより、各スキーマを更新します。

      すべてのスキーマ(ODIマスターおよびODI作業)に情報が入力されていることを確認します。

    7. 「次へ」をクリックします。

  8. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックしてエントリを修正します。

    すべての接続が正常になったら「次へ」をクリックします。

  9. 「オプションの構成を選択」画面で、次を選択します。

    • 管理サーバー

    • 管理対象サーバー、クラスタ、およびマシン

    • デプロイメントとサービス

    「次へ」をクリックします。

  10. アプリケーション・サーバーの構成画面で、管理サーバーのリスニング・アドレスとリスニング・ポートを設定します。

  11. 「管理対象サーバーの構成」ページで、次の操作を行います。

    • クリックして、新しいサーバーodi_server2を追加します。

    • 各サーバーのリスニング・アドレスを、各サーバーが実行されるホスト名に設定します。

    • 両方のサーバーのリスニング・ポートが同じであることを確認します。

  12. 「クラスタの構成」ページで、odi_clusterという名前のクラスタを作成し、ユニキャストのデフォルトを受け入れます。

  13. 「サーバーのクラスタへの割当」ページで、両方のサーバーをクラスタに追加します。

  14. 「マシンの構成」ページで、2つのマシンを作成します。

  15. 「マシンの割当て」ページで、次の操作を行います。

    • マシン1に管理サーバーとodi_server1を追加します。

    • マシン2にodi_server2を追加します。

  16. 「構成のサマリー」ページで、「作成」をクリックしてドメインを作成します。

7.4.2.4 管理サーバーの起動

次のコマンドを使用して、APPHOST1上のWebLogic管理サーバーを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

7.4.2.5 資格証明ストアの構成

WLSTまたはEnterprise Managerを使用して、資格証明ストアを構成できます。

7.4.2.5.1 WLSTを使用した資格証明の構成

次のスクリプトを実行します。

MW_HOME/oracle_common/common/bin/wlst.sh

次に、次のコマンドを発行します。

connect('weblogic','welcome1','t3://localhost:7001')
createCred(map="oracle.odi.credmap", key="SUPERVISOR", user="SUPERVISOR",
password="SUNOPSIS", desc="ODI SUPERVISOR Credential")
exit()

前述のユーザーは、RCUを使用してリポジトリが作成されたときに作成されたスーパーバイザ・ユーザーです。指定するパスワードは、そのスーパーバイザ・ユーザーのパスワードです。

7.4.2.5.2 Enterprise Managerを使用した資格証明の構成

Enterprise Managerを使用して資格証明を構成する手順は、次のとおりです。

  1. Oracle Enterprise Managerにログインし、「ドメイン」→「セキュリティ」→「資格証明」に移動して、「資格証明」ページを表示します。

  2. マップの作成」をクリックして、「マップの作成」ダイアログを表示します。

  3. 「マップの作成」ダイアログで、資格証明の作成対象のマップ名(oracle.odi.credmap)を入力します。

  4. OK」をクリックして、「資格証明」ページに戻ります。表に、新しい資格証明マップ名がマップ・アイコンとともに表示されます。

  5. キーの作成」をクリックして、「キーの作成」ダイアログを表示します。

  6. このダイアログで、oracle.odi.credmapのマップを選択し、「SUPERVISOR」のキーのテキスト・ボックスにキーを入力し、「タイプ」メニューからタイプを選択して、必要なデータを入力します(ダイアログの外観は、選択したタイプに応じて異なります)。

    user="SUPERVISOR", password="your_password"
    
  7. 終了したら「OK」をクリックして、「資格証明」ページに戻ります。選択したマップに対応するマップ・アイコンの下に新しいキーが表示されます。

7.4.2.6 デフォルト・エージェントの構成

Oracle Data Integrator管理対象サーバーを起動する前に、Oracle Data Integratorエージェントのエージェント定義を作成する必要があります。次の手順を実行します。

  1. ODI_HOME/oracledi/client/odi.shでOracle Data Integrator Studioを起動します。

  2. Oracle Data Integrator Studioが起動したら、左側のペインで「リポジトリへの接続...」をクリックします。

  3. ログイン・ウィンドウが表示されます。鉛筆アイコンをクリックして、マスター・リポジトリのログオン情報を編集します。

  4. 「リポジトリ接続情報」画面で、次のものを入力します。

    ODI接続:

    • ログイン名: マスター・リポジトリ

    • ユーザー: SUPERVISOR

    • パスワード: (資格証明ストアの作成時に使用されたパスワード)

    DB接続:

    • ユーザー: (DEV_ODI_REPOなどのODIスキーマ・ユーザー)

    • パスワード: (ODIスキーマ・パスワード)

    • ドライブ名: oracle.jdbc.driver.OracleDriver

    • URL: (jdbc:oracle:thin:@host:port:sidという形式の接続URL)

  5. テスト」をクリックして、接続をテストします。

  6. OK」をクリックして、ログオン画面に戻ります。

  7. ユーザー/パスワードが正しいことを確認し、「OK」をクリックしてマスター・リポジトリに接続します。

  8. 接続されたら、左側のペインで「物理アーキテクチャ」セクションを開きます。

  9. エージェント」を選択し、右クリックして新しいエージェントを作成します。

  10. 次のプロパティを指定して新しいエージェントを作成します。

    • 名前: OracleDI Agent

    • ホスト: (odi_server1が実行されるホスト)

    • ポート: (odi_server1管理対象サーバーが実行されているポート)

    • Webアプリケーション・コンテキスト: oraclediagent

  11. 「データソース」タブを開きます。左側のペインで、「リポジトリ」セクションを開き、そこからエージェントの「データソース」領域に「作業リポジトリ」をドラッグします。

  12. 作業リポジトリ・データ・ソースを編集して、WebLogic Serverインストーラのデータ・ソースによって使用されるJNDI名を追加します。これはjdbc/odiWorkRepositoryです。

  13. 変更内容を保存して、Oracle Data Integrator Studioを終了します。

7.4.2.7 クラスタのCoherenceの構成

Coherenceは、クラスタ・メンバー間で通信が有効になるように構成する必要があります。Coherenceを構成するには、次の手順を実行します。

  1. 管理コンソールの左側のタブから、「環境」→「サーバー」を選択します。

  2. 「odi_server1」を選択します。

  3. 「サーバー起動」タブをクリックします。

  4. 「引数」ボックスで、次のように入力します(すべてを1行で入力します)。

    -Doracle.odi.coherence.wka1=machine1 -Doracle.odi.coherence.wka1.port=9088
    -Doracle.odi.coherence.wka2=machine2 -Doracle.odi.coherence.wka2.port=9088
    -Dtangosol.coherence.localport=9088
    

    machine1とmachine2は、クラスタ内の2つのマシンのホスト名です。


    注意:

    ポート9088がマシン上で使用されていない場合は、それをCoherenceポートとして使用します。それ以外の場合は、別のポートを選択してCoherenceポートとして構成してください。


  5. 保存」をクリックします。

  6. odi_server2に対しても前述の手順を繰り返します。

7.4.2.8 ノード・マネージャの構成とodi_server1の起動

次のコマンドを使用して、ノード・マネージャを構成および起動します。

$ MW_HOME/oracle_common/common/bin/setNMProps.sh
$ MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

odi_server1を起動する手順は次のとおりです。

  1. 管理コンソールで、「環境」→「サーバー」→「制御」タブを選択します。

  2. odi_server1を選択し、「起動」をクリックします。

7.4.2.9 Oracle Data Integratorエージェントが実行されていることの確認

Webブラウザに次のURLを入力して、Oracle Data Integratorエージェントが実行されていることを確認します。

http://APPHOST1:PORT/oraclediagent

7.4.3 2つ目のOracle Data Integratorホストのインストールと構成

この項では、2つ目のOracle Data Integratorホスト(APPHOST2など)のインストールおよび構成手順について説明します。

7.4.3.1 APPHOST2へのOracle WebLogic Serverのインストール

第7.4.2.1項「APPHOST1へのOracle WebLogic Serverのインストール」の手順に従います。

APPHOST1で使用したものと同じディレクトリ・パスを使用します。

7.4.3.2 APPHOST1からAPPHOST2へのドメインのパックと解凍

次のコマンドを使用して、最初のホスト(APPHOST1)に作成されたドメインをパックします。

$ cd MW_HOME/oracle_common/common/bin
$ ./pack.sh -domain=<full path to the domain> -template=mytemplate.jar 
-template_name=<descriptive template name> -managed=true

最初のホストに作成したjarファイルを2つ目のホスト(APPHOST2)にコピーし、解凍します。

$ cd MW_HOME/oracle_common/common/bin
$ ./unpack.sh -domain=<full path to the domain> -template=mytemplate.jar

7.4.3.3 ノード・マネージャの構成とodi_server2の起動

次のコマンドを使用して、APPHOST2でノード・マネージャを構成および起動します。

$ MW_HOME/oracle_common/common/bin/setNMProps.sh
$ MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

odi_server2を起動する手順は次のとおりです。

  1. 管理コンソールで、「環境」→「サーバー」→「制御」タブを選択します。

  2. odi_server2を選択し、「起動」をクリックします。

7.4.3.4 Oracle Data Integratorエージェントが実行されていることの確認

Webブラウザに次のURLを入力して、Oracle Data Integratorエージェントが実行されていることを確認します。

http://APPHOST2:PORT/oraclediagent

7.4.4 Oracle HTTP Serverのインストール

Oracle HTTP Serverを別のホスト(WEBHOST1)にインストールします。

システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。

Oracle Web Tierコンポーネントのインストーラを起動します。

HOST> ./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、/u01/app/product/fmw/jrockit_160_<バージョン>のように入力します。

次のインストール手順を実行します。

  1. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

  2. 「インストール場所の指定」画面で、次の値を入力します。

    MW_HOME: MW_HOMEの値を入力します。例:

    /u01/app/product/fmw
    

    ドロップダウン・リストから、すでにインストールされているMiddlewareホームを選択します。Oracle HTTP Server Oracleホーム(OHS_ORACLE_HOME)ディレクトリには、ディレクトリ名WEBを入力します。

    「次」をクリックします。

  3. 「サマリー」画面で「インストール」をクリックします。

    プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。

  4. 「インストール完了」画面で「終了」をクリックします。

この手順を繰り返して、Oracle HTTP Serverを別のWeb層ホスト(WEBHOST2)にインストールします。

7.4.4.1 Oracle HTTP Server Oracleホームのアップグレード

この項では、Oracle HTTP Serverソフトウェアをアップグレードする手順について説明します。詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』のOracle Fusion Middlewareの最新パッチ・セットの適用に関する項を参照してください。

OHS_ORACLE_HOMEをアップグレードするには、次の手順を実行します。

  1. ./runinstallerを実行して、Web Tierアップグレード・インストーラを起動します。

  2. 「ようこそ」画面で「次へ」をクリックします。

  3. 「前提条件のチェック」画面で、「次へ」をクリックします。

  4. 「インストール場所の指定」画面で、Oracle MiddlewareホームへのパスおよびOracle HTTP Server Oracleホーム・ディレクトリの名前を指定します。

  5. 「インストール・サマリー」画面で、選択内容を確認して「インストール」をクリックします。

  6. 「インストールの進行状況」画面に、インストールの進行状況が示されます。

    インストールが終了すると、oracleRoot.shの確認ダイアログ・ボックスが表示されます。このダイアログ・ボックスは、インストールを続行する前に構成スクリプトをrootユーザーとして実行する必要があることを示しています。確認ダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootユーザーとしてログインして、スクリプト・ファイル/u01/app/oracle/product/fmw/id/oracleRoot.shを実行します。スクリプトが完了したら、確認ダイアログ・ボックスの「OK」をクリックします。

  7. 「インストール完了」画面で「終了」をクリックして終了します。

この手順は、Oracle HTTP ServerがインストールされているWeb層ホスト(WEBHOST1やWEBHOST2など)ごとに実行する必要があります。

7.4.4.2 Oracle HTTP Serverの構成

インストール後、次の行を、Oracle HTTP Serverにインストールしたホスト(複数可)上のOHS_HOME/instances/ohs_instance1/config/OHS/ohs11/mod_wl_ohs.confファイルに追加します。

# ODI Agent
<Location /oraclediagent> 
    WebLogicCluster host1:8002,host2:8002 
    SetHandler weblogic-handler 
</Location> 
 
#ODI Explorere
<Location /odirepex> 
    WebLogicCluster host1:8002,host2:8002 
    SetHandler weblogic-handler 
</Location> 
 
#ODI Webservices
<Location /oracledisdkws> 
    WebLogicCluster host1:8002,host2:8002 
    SetHandler weblogic-handler 
</Location>

この手順は、Oracle HTTP ServerがインストールされているWeb層ホスト(WEBHOST1やWEBHOST2など)ごとに実行する必要があります。

7.4.4.3 ロード・バランサの構成

ロード・バランサは、リクエストがWEBHOST1上とWEBHOST2上の2つのHTTP Server間でラウンドロビン処理されるように構成する必要があります。

さらに、次のロード・バランサの構成に関する推奨事項に従います。

  • ロード・バランサに対して永続性を有効にしないでください。これはHTTP Serverによって提供されます。

  • HTTP Serverポートを監視するように構成して、ロード・バランサがフェイルオーバーを提供できるようにする必要があります。

7.4.4.4 Oracle Data Integratorエージェントが実行されていることの確認

Webブラウザに次のURLを入力して、Oracle Data Integratorエージェントが実行されていることを確認します。

http://LBRHOST:PORT/oraclediagent

7.4.4.5 エージェントの再構成

エージェント定義は、個々のサーバーのアドレスではなく、ロード・バランサのアドレスを指す必要があります。

新しいエージェントを作成する際は、このことを覚えておいてください。

デフォルトのエージェントでは、Oracle Data Integrator Studioに再度接続します。

  1. ODI_HOME/oracledi/client/odi.shでOracle Data Integrator Studioを起動します。

  2. Oracle Data Integrator Studioが起動したら、左側のペインで「リポジトリへの接続...」をクリックします。

  3. ログイン・ウィンドウが表示されたら、「OK」をクリックしてログオンします。

  4. 接続されたら、左側のペインで「物理アーキテクチャ」セクションを開きます。

  5. エージェント」を選択し、「OracleDIAgent」を選択します。

  6. 次のプロパティを編集します。

    • ホスト: ロード・バランサの仮想サーバー・アドレス

    • ポート: ロード・バランサの仮想アドレスのリスニング・ポート

  7. テスト」をクリックして、エージェントの接続をテストします。

  8. 変更内容を保存して、Oracle Data Integrator Studioを終了します。