ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド
11g リリース1(11.1.1)
B63036-04
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

9 Oracle Business Intelligenceシステムのスケール・アウト

この章では、構成アシスタントを使用してOracle Business Intelligenceシステムをスケール・アウトする方法について説明します。Oracle Business Intelligence ORACLE_HOME(バイナリ)がすでにインストール済でAPPHOST1とAPPHOST2からアクセス可能であること、および管理サーバーが属するドメインが作成済であることを前提としています。この章では、Oracle Business Intelligenceコンポーネントをサポートするように、このドメインを拡張します。


重要:

セットアップのプロセスを開始する前に、『Oracle Fusion Middlewareリリース・ノート』に目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。

この章には次のトピックが含まれます:

9.1 Oracle Business Intelligenceシステムのスケール・アウトの概要

表9-1では、Oracle Business Intelligenceシステムをスケール・アウトし、構成後タスクを実行する手順をリストおよび説明しています。

表9-1 Oracle Business Intelligenceシステムのスケール・アウトの手順

手順 説明 詳細

共有ファイルの場所の設定

Oracle BI EEおよびOracle BI Publisherで共有ファイルの場所を設定します。

第9.2項「共有ファイルの場所の設定」

Oracle Business Intelligenceシステムのスケール・アウト

Oracle Business Intelligence構成アシスタントを使用してOracle Business Intelligenceシステムをスケール・アウトしてから、Fusion Middleware Controlを使用してシステム・コンポーネントをスケール・アウトし、シングルトン・システム・コンポーネントのセカンダリ・インスタンスを構成します。

第9.3項「APPHOST2でのOracle Business Intelligenceシステムのスケール・アウト」

bi_server2管理対象サーバーの構成

リスニング・アドレスを設定して、bi_server2管理対象サーバーのホスト名検証を無効化します。

第9.4項「bi_server2管理対象サーバーの構成」

Oracle Business Intelligenceの可用性の追加構成の実行

Oracle BI Scheduler、Oracle RTD、BI PublisherおよびOracle BI Composerに対して高可用性の構成タスクを追加で実行します。

第9.5項「Oracle Business Intelligenceの可用性の追加構成の実行」

その他の構成後タスクおよび検証タスクの実行

トランザクション・リカバリ用のデフォルトの永続ストアを構成し、APPHOST2でOracle Business Intelligenceの起動および検証を行い、ノード・マネージャの構成と管理対象サーバーのサーバー移行の構成を行います。

第9.6項「その他の構成後タスクおよび検証タスク」

インストールのバックアップ

インストールをローカル・ディスクにバックアップします。

第9.7項「インストールのバックアップ」

9.2 共有ファイルの場所の設定

この項では、Oracle BI EEおよびOracle BI Publisherでの共有ファイルの場所の設定方法について説明します。次の項目が含まれます。

9.2.1 Oracle BI EEの共有ファイルの設定

この項の構成は、次のとおりです。

9.2.1.1 RPD公開ディレクトリの指定

Oracle BIリポジトリに対するリポジトリ公開ディレクトリを指定します。この場所は、クラスタ内でリポジトリの変更をオンラインで伝播するために使用されます。

公開ディレクトリを指定する手順は次のとおりです。

  1. Fusion Middleware Controlにログインします。

  2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

  3. 「coreapplication」をクリックします。

  4. 「デプロイメント」をクリックしてから、「リポジトリ」をクリックします。

  5. 「構成をロックして編集」をクリックします。

  6. 「リポジトリの共有」を選択し、Oracle BI Repositoryの「RPD公開ディレクトリ」を指定します。

    Windows環境では、UNCパス名を指定する必要があります。

  7. 「適用」をクリックします。

  8. 「変更のアクティブ化」をクリックします。

9.2.1.2 共有Oracle BI Presentation Catalogの場所の設定

各プレゼンテーション・サービス・インスタンスでは、Fusion Middleware Controlで指定されたカタログの場所からOracle BIプレゼンテーション・カタログをロードします。

カタログの場所を指定する手順は次のとおりです。

  1. 既存の(ローカルに公開された)カタログを共有の場所にコピーします。次にローカルに公開されたカタログの例を示します。

    ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/
coreapplication_obipsn/catalog/SampleAppLite

    この手順は、Fusion Middleware Controlから「カタログの場所」を指定する前に実行する必要があります。

  2. Fusion Middleware Controlにログインします。

  3. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

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

  5. 「デプロイメント」をクリックしてから、「リポジトリ」をクリックします。

  6. 「構成をロックして編集」をクリックします。

  7. 共有Oracle BI Presentation Catalogの「カタログの場所」を指定します。

    Windows環境では、UNCパス名を指定する必要があります。

  8. 「適用」をクリックします。

  9. 「変更のアクティブ化」をクリックします。

9.2.1.3 グローバル・キャッシュの場所の設定

グローバル・キャッシュは、共有ファイル・システム(UNIXの場合はマウント・ファイル・システム、Windowsの場合はネットワーク共有ドライブ)上に存在し、パージ・イベント、シード・イベント(多くの場合はエージェントによって生成)、およびシード・イベントと関連付けられた結果セットを格納します。各Oracle BI Serverでは、通常の問合せ用に独自のローカル問合せキャッシュが引き続き保持されます。

キャッシュの場所を指定する手順は次のとおりです。

  1. Fusion Middleware Controlにログインします。

  2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

  3. 「coreapplication」をクリックします。

  4. 「容量管理」をクリックしてから、「パフォーマンス」をクリックします。

  5. 「構成をロックして編集」をクリックします。

  6. 「グローバル・キャッシュ」セクションの「グローバル・キャッシュ・パス」フィールドに、パージおよびシードの各キャッシュ・エントリを格納するための共有場所を指定します。Windows環境では、UNCパス名を指定する必要があります。

  7. 「グローバル・キャッシュ・サイズ」に値を入力し、グローバル・キャッシュの最大サイズ(たとえば250MB)を指定します。

  8. 「適用」をクリックします。

  9. 「変更のアクティブ化」をクリックします。

  10. 「再起動して最近の変更を適用」をクリックします。

  11. 「システムの管理」で「再起動」をクリックします。

  12. 確認ダイアログで「はい」をクリックします。

9.2.2 共有BI Publisher構成フォルダの場所の設定

BI Publisherのサーバー構成オプションを設定する手順は次のとおりです。

  1. DOMAIN_HOME/config/bipublisher/repositoryディレクトリの内容を構成フォルダの共有場所にコピーします。

  2. APPHOST1で管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。

  3. 「システム・メンテナンス」で「サーバー構成」を選択します。

  4. 「構成フォルダ」の「パス」フィールドで、構成フォルダの共有場所を入力します。

  5. 「カタログ」の下の「BI Publisherリポジトリ」フィールドに、BI Publisherリポジトリの共有場所を入力します。

  6. 変更を適用してから、BI Publisherアプリケーションを次の手順を使用して再起動します。

    1. 管理コンソールにログインします。

    2. 「ドメイン構造」ウィンドウで、「デプロイメント」をクリックします。

    3. 「bipublisher(11.1.1)」を選択します。

    4. 「停止」をクリックしてから、「作業完了時」または「ただちに強制停止」を選択します。

    5. アプリケーションが停止している場合は、「起動」をクリックしてから「すべてのリクエストを処理」を選択します。

  7. 管理対象サーバーの再起動時、BI Publisherがその構成を読み取るのは、管理対象サーバーの構成ディレクトリからではなく、中央拠点である管理サーバーからなので、BI PublisherのXML構成ファイルを管理対象サーバーから管理サーバーの場所にコピーする必要があります。

    これを行うには、APPHOST1で、xmlp-server-config.xmlファイルをコピーします。コピー元:

    ORACLE_BASE/admin/domain_name/mserver/domain_name/config/bipublisher

    コピー先:

    ORACLE_BASE/admin/domain_name/aserver/domain_name/config/bipublisher

9.3 APPHOST2でのOracle Business Intelligenceシステムのスケール・アウト

この項では、APPHOST2でOracle Business Intelligenceをスケール・アウトする方法について説明します。次の各項の手順を実行します。

9.3.1 構成アシスタントを使用したOracle BIシステムのスケール・アウト

Oracle BIシステムをスケール・アウトするために、Oracleホーム・ディレクトリから構成アシスタントを実行する手順は次のとおりです。

  1. BI_Server1が稼働中であることを確認します。

  2. 次のように、構成アシスタントの場所にディレクトリを移動します。

    APPHOST2> cd ORACLE_HOME/bin

  3. 次のコマンドを使用して、Oracle Business Intelligence構成アシスタントを起動します。

    APPHOST2> ./config.sh

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

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

  6. 作成、スケール・アウト、または拡張画面でBIシステムのスケール・アウトを選択して、次の値を入力します。

    • ホスト名: ADMINVHN

    • ポート: 7001

    • ユーザー名: weblogic

    • ユーザー・パスワード: your_password

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

  7. BIシステムのスケール・アウトの詳細画面で、次の値を入力します。

    • ミドルウェア・ホーム: ORACLE_BASE/product/fmw(淡色表示)

    • Oracleホーム: ORACLE_BASE/product/fmw/Oracle_BI1(淡色表示)

    • WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3(淡色表示)

    • ドメイン・ホーム: ORACLE_BASE/admin/domain_name/mserver/domain_name

    • アプリケーション・ホーム: ORACLE_BASE/admin/domain_name/mserver/applications

    • インスタンス・ホーム: ORACLE_BASE/admin/instance2

    • インスタンス名: instance2(淡色表示)

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

  8. 「ポートの構成」画面で、次のいずれかを選択します。

    • 自動でポートを構成

    • 構成ファイルを使用してポートを指定

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

  9. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを指定します。受信する場合は、電子メール・アドレスを入力します。

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

  10. 「サマリー」画面で「構成」をクリックします。

  11. 「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。

  12. 完了画面で「終了」をクリックします。

通常はノード・マネージャは、config.shプロセスの完了時に自動的に起動されます。ノード・マネージャが実行されていない場合は、次の手順を実行して、APPHOST2でノード・マネージャを起動します。

  1. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

    APPHOST2> cd ORACLE_COMMON_HOME/common/bin
APPHOST2> ./setNMProps.sh

    注意:

    クラスのロード障害が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

  2. ノード・マネージャを起動します。

    APPHOST2> cd WL_HOME/server/bin
APPHOST2> ./startNodeManager.sh

9.3.2 システム・コンポーネントのスケール・アウト

システム・コンポーネントをスケール・アウトする手順は次のとおりです。

  1. Fusion Middleware Controlにログインします。

  2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

  3. 「coreapplication」をクリックします。

  4. 「容量管理」をクリックしてから、「スケーラビリティ」をクリックします。

  5. 「構成をロックして編集」をクリックします。

  6. APPHOST2の「instance2」Oracleインスタンスについて、次のOracle Business Intelligenceコンポーネントを1だけ増分します。

    • BIサーバー

    • プレゼンテーション・サービス

    • JavaHost

  7. 「適用」をクリックします。

  8. 「変更のアクティブ化」をクリックします。

この時点では何も再起動する必要はありません。なぜなら、第9.3.3項の手順を完了した後で再起動を実行するからです。

9.3.3 シングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成

Oracle BI Cluster Controller、Oracle BI SchedulerおよびEssbaseエージェントは、アクティブ/パッシブ・モードで動作するシングルトン・コンポーネントです。高可用性を実現するために、これらのコンポーネントのセカンダリ・インスタンスを構成して分散させます。

セカンダリ・インスタンスを構成する手順は次のとおりです。

  1. http://biinternal.mycompany.com/emでFusion Middleware Controlにログインします。

  2. 「Farm_BI_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

  3. 「coreapplication」をクリックします。

  4. 「可用性」をクリックし、「フェイルオーバー」をクリックします。

  5. 「構成をロックして編集」をクリックして、「可用性」タブの「プライマリ/セカンダリ構成」セクションをアクティブ化します。

  6. BI Scheduler、BI Cluster ControllerおよびEssbaseエージェントの「セカンダリ・ホスト / インスタンス」を指定します。

  7. 「Essbaseエージェント」セクションで、「共有フォルダ・パス」がORACLE_BASE/admin/domain_name/cluster_name/Essbase/essbaseserver1に設定されていることを確認します。

    注意: ORACLE_INSTANCE/Essbase/essbaseserver1ディレクトリの内容を、共有フォルダ・パスに手動でコピーする必要があります。

  8. 「適用」をクリックします。

    「潜在的単一点障害」に、「問題はありません。すべてのコンポーネントにバックアップがあります。」と報告されます。

  9. 「変更のアクティブ化」をクリックします。

  10. 「再起動して最近の変更を適用」をクリックします。

  11. 「システムの管理」で「再起動」をクリックします。

  12. 確認ダイアログで「はい」をクリックします。

9.3.4 高可用性環境でのOracle Essbase Studio Serverの使用

Oracle Essbase Studio Serverでは高可用性はサポートされていません。このため、フェイルオーバー中に問題が発生することがあります。たとえば、Essbase Studio ServerがAPPHOST1上で構成され、その後クラッシュするとします。システムはAPPHOST2にフェイルオーバーしますが、そこではEssbase Studio Serverは実行されていません。Essbase Studioカタログ・データベースを複数のEssbase Studio Serverインスタンスで同時に、または連続して使用することはできないため、単純にAPPHOST2でサーバーを起動するというわけにはいきません。各Essbase Studio Serverには専用のカタログ・データベースを参照させることを強くお薦めします。

キューブ・デプロイメントを実行したコンピュータとは異なるコンピュータでEssbase Studio Serverを起動すると、ドリルスルー・レポートが期待どおりには機能しません。この問題を回避するには、Essbase Studio Consoleから次の手順を実行して、Essbase Studio Server情報を手動で更新します。

  1. 「ツール」に移動し、キューブのリンクの更新を選択します。

  2. 適切なEssbase Studio Serverを反映するように、キューブ・リンクEssbase Studio Server列の情報を更新します。

Essbase Studio Serverの起動およびカタログ・データベースとともに使用する方法の詳細は、次の場所で提供されているEssbase Studio Serverのドキュメントを参照してください。

http://docs.oracle.com/cd/E17236_01/nav/portal_3.htm

9.4 bi_server2管理対象サーバーの構成

この項では、bi_server2管理対象サーバーを構成する方法について説明します。項目は次のとおりです。

9.4.1 bi_server2管理対象サーバーのリスニング・アドレスの設定

第3.4.2項「管理対象サーバーの仮想IPの有効化」で説明されている手順が実行済であることを確認してから、bi_server2のリスニング・アドレスを設定します。

管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソールにログインします。

  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

  4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で「bi_server2」を選択します。bi_server2の設定ページが表示されます。

  6. 「リスニング・アドレス」をAPPHOST2VHN1に設定します。

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

  8. 「変更のアクティブ化」をクリックします。

    変更内容は、bi_server2管理対象サーバーが再起動されるまでは有効になりません。

9.4.2 bi_server2管理対象サーバーに対するホスト名検証の無効化

この手順は、管理サーバーでの様々なノードの認証に対して適切な証明書を、第10章「エンタープライズ・デプロイメント用のノード・マネージャの設定」に従って構成していない場合に必要となります。サーバー証明書を構成済でないと、複数のOracle WebLogic Serverの管理時にエラーが表示されます。このエラーを回避するには、トポロジの構成と検証を行う際にホスト名の検証を無効にし、第10章「エンタープライズ・デプロイメント用のノード・マネージャの設定」の説明に従って、EDGトポロジの構成を完了した後に再びホスト名の検証を有効にします。

ホスト名検証を無効にする手順は次のとおりです。

  1. 管理コンソールにログインします。

  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

  4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で「bi_server2」を選択します。そのサーバーの設定ページが表示されます。

  6. 「SSL」タブを開きます。

  7. 表示されたページの「詳細」セクションを開きます。

  8. 「ホスト名の検証」を「なし」に設定します。

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

  10. 「変更のアクティブ化」をクリックします。

  11. この変更内容は、次の手順を実行してbi_server2管理対象サーバーを再起動するまでは適用されません(ノード・マネージャが稼働していることを確認します)。

    1. 「サーバーの概要」画面で、「制御」タブを選択します。

    2. 表で「bi_server2」を選択してから、「停止」をクリックします。

    3. 表で「bi_server2」を選択してから、「起動」をクリックします。

  12. 次の手順を実行して、APPHOST2上でBIシステム・コンポーネントを再起動します。

    1. Fusion Middleware Controlにログインします。

    2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

    3. 「coreapplication」をクリックします。

    4. 「Business Intelligence概要」ページで、「再起動」をクリックします。

9.5 Oracle Business Intelligenceの可用性の追加構成の実行

この項では、Oracle BI Scheduler、Oracle RTD、BI PublisherおよびOracle BI Composerの高可用性の追加の構成タスクについて説明します。次の項目が含まれます。

9.5.1 Oracle BI Schedulerの追加の構成タスク

Oracle BI Schedulerでサーバー側スクリプトを使用する場合は、クラスタ内のすべてのOracle BI Schedulerコンポーネントで共有できるように、これらのスクリプトの共有ディレクトリを構成することをお薦めします。

次の手順は、サーバー側スクリプトを使用している場合にのみ実行してください。

Oracle BI Schedulerスクリプトを共有する手順は次のとおりです。

  1. APPHOST1からデフォルトのOracle BI Schedulerスクリプト(たとえば、ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/common)およびカスタムのOracle BI Schedulerスクリプト(たとえば、ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/scheduler)をコピーして、BI Schedulerスクリプトの共有場所に貼り付けます。

  2. Oracle BI Schedulerのinstanceconfig.xmlファイルのSchedulerScriptPath要素とDefaultScriptPath要素を次のように更新します。

    • SchedulerScriptPath: Oracle BI Schedulerによって作成されたジョブ・スクリプトが格納されているパスを指します。共有BI Schedulerスクリプトの場所を指すパスにこれを変更します。

    • DefaultScriptPath: ユーザーによって作成されたジョブ・スクリプト(エージェントではなく)が格納されているパスを指定します。共有BI Schedulerスクリプトの場所を指すパスにこれを変更します。

    Windows環境では、UNCパス名を指定する必要があります。

  3. Oracle BI Schedulerコンポーネントを次のように再起動します。

    opmnctl stopproc ias-component=coreapplication_obisch1
opmnctl startproc ias-component=coreapplication_obisch1

Oracle BI Schedulerのinstanceconfig.xmlファイルは、ORACLE_INSTANCE/config/OracleBISchedulerComponent/coreapplication_obischnにあります。デプロイメント内の各Oracle BI Schedulerコンポーネントに対して、このファイルを更新する必要があります。

9.5.2 Oracle RTDの追加の構成タスク

この項の構成は、次のとおりです。

9.5.2.1 Oracle RTDのクラスタ化プロパティの構成

Fusion Middleware Controlで次の手順を実行して、Oracle RTDのクラスタ固有の構成プロパティを指定します。

次の手順は、デプロイメントの最初のノードでのみ実行する必要があります。2番目以降のノードでOracle RTDのクラスタ固有の構成プロパティを設定する必要はありません。

  1. Fusion Middleware Controlにログインします。

  2. 「Farm_domain_name」ウィンドウで、「アプリケーション・デプロイメント」ノードを開きます。

  3. 「OracleRTD(11.1.1)(bi_cluster)」をクリックします。

  4. その下の任意のノードをクリックします。たとえば、「OracleRTD(11.1.1)(bi_server1)」をクリックします。

  5. 右側のペインで、「アプリケーション・デプロイメント」をクリックして、「システムMBeanブラウザ」を選択します。

  6. 「システムMBeanブラウザ」ペインで、「アプリケーション定義のMBean」を開きます。

  7. OracleRTDの下のいずれかのサーバーで、「SDClusterPropertyManager」→その他のMBeanに移動し、DecisionServiceAddress属性をhttp://biinternal.mycompany.comに設定します。他のサーバーは、設定した値で自動的に更新されます。

  8. 「適用」をクリックします。

9.5.2.2 システム・プロパティの「サーバーの起動」タブへの追加

Oracle RTDをスケール・アウトした後、次の手順を実行して、各管理対象サーバーの「サーバーの起動」タブに3つのシステム・プロパティを追加します。

  1. 管理コンソールにログインします。

  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

  4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  5. 表のbi_server<1,2>を選択します。そのサーバーの設定ページが表示されます。

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

  7. 「引数」ボックスで次のプロパティを追加します。

    -Drtd.clusterRegistryJobIntervalMs=12000
-Drtd.clusterDepartureThresholdMs=50000
-Drtd.clusterDepartureThreshold2Ms=50000

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

  9. 「変更のアクティブ化」をクリックします。

  10. この変更内容は、bi_server<1,2>管理対象サーバーが再起動されるまでは適用されません(ノード・マネージャが稼働していることを確認します)。

    1. 「サーバーの概要」画面で、「制御」タブを選択します。

    2. 表のbi_server<1,2>を選択してから、「停止」をクリックします。

    3. bi_server<1,2>を再起動します。

  11. BIシステム・コンポーネントを次のように再起動します。

    cd /u02/local/oracle/config/BIInstancen/bin
./opmnctl stopall
./opmnctl startall

このタスクを実行することによって、管理対象サーバーに障害が発生した場合にOracle RTDのインスタンスをサーバー間で正常に移行できるようになります。

これらの変更を行ったとしても、サーバーの移行が50秒未満で完了した場合は、Oracle RTDバッチ・フレームワークは不整合な状態になります。

バッチ・ジョブの実装をホストするRTDインライン・サービスがデプロイされている場合、サーバー移行後にバッチ・コンソール・コマンドbatch-names(またはその短縮名bn)を実行しても登録されているバッチ・ジョブが1つも表示されないときは、Oracle RTDバッチ・マネージャ・サービスを停止してから再起動する必要があります。サービスを停止してから再起動する手順は次のとおりです。

  1. Fusion Middleware Controlの左側のペインで、「WebLogicドメイン」ノードを開きます。「bifoundation_domain」を右クリックして、「システムMBeanブラウザ」を選択します。

  2. 「アプリケーション定義のMBean」→「OracleRTD」→「サーバー:bi_servern」の下にある「SDPropertyManager」→その他のMBeanを見つけます。

    変更を行っているローカル・ノードに対応するその他のMBeanを選択してください。たとえば、APPHOST1に接続している場合は、bi_server1に関連付けられた属性を更新します。

  3. BatchManagerEnabled属性をfalseに設定し、「適用」をクリックします。

  4. BatchManagerEnabled属性をtrueに戻し、「適用」をクリックします。このタスクを実行すると、バッチ・マネージャが停止し、再起動されます。

    再起動後は、バッチ・マネージャは前と同じサーバーで実行されるか、異なるサーバーで実行されます。

  5. バッチ・マネージャの再起動後は、バッチ・マネージャが起動されたサーバーで、対応するMBeanが必ずしも即座にリフレッシュされるわけではないので、気にする必要はありません。かわりに、次の手順でバッチ・コンソール・ツールを使用して、バッチ・マネージャが現在実行されていることを確認します。

    1. 次の場所で、Oracle RTDクライアント・ツールのzipファイルを探します。

      ORACLE_HOME/clients/rtd/rtd_client_11.1.1.zip

    2. ほとんどのOracle RTDクライアント・ツールはUNIX上で動作しないので、このファイルはWindowsコンピュータ上で解凍してください。ここではRTD_HOMEで解凍します。この場合、次のバッチ・コンソールjarファイルを探します。

      RTD_HOME/client/Batch/batch-console.jar

    3. このディレクトリに移動し、管理対象サーバーまたはクラスタ・プロキシのどちらかのURLとポートを渡してjarを実行します。

      java -jar batch-console.jar -url http://SERVER:PORT

    4. プロンプトが表示されたら、管理者ロール、BI_AdministratorロールまたはOracle RTDバッチ・ジョブの管理権限を付与された他のロールのいずれかのメンバーであるユーザーのユーザー名とパスワードを入力します。

    5. コマンドの入力を求められたら、bnと入力します。

      Checking server connection...
command: bn
    CrossSellSelectOffers
command:quit

      バッチ・マネージャが正常に起動されている場合、bnコマンドによって、デプロイされているすべてのRTDインライン・サービスによってホストされているすべてのバッチ実装の名前がリストされます。

      一般的なデプロイ例であるCrossSellでは、上の例に示すCrossSellSelectOffersという名前のバッチ実装がホストされます。

9.5.3 BI Publisherの追加の構成タスク

この項の構成は、次のとおりです。

9.5.3.1 スケジューラ構成オプションの設定

Scheduler構成オプションを設定する手順は次のとおりです。

  1. APPHOST1で管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。

  2. 「システム・メンテナンス」で「スケジューラ構成」を選択します。

  3. 「スケジューラ選択」で「クォーツ・クラスタリング」を選択します。

  4. 「適用」をクリックします。

9.5.3.2 Oracle BI Presentation Servicesとの統合の構成

BI PublisherとOracle BI Presentation Servicesとの統合を構成する手順は次のとおりです。

  1. 管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。

  2. 「統合」で、「Oracle BIプレゼンテーション・サービス」を選択します。

  3. 次の設定を確認して更新します。

    • サーバー・プロトコル: HTTP

    • サーバー: biinternal.mycompany.com

    • ポート: 80

    • URL接頭辞: analytics-ws/saw.dll

  4. 「適用」をクリックします。

  5. BI Publisherアプリケーションを再起動します。

9.5.3.3 Oracle BI EEのデータ・ソースの設定

Oracle BI EEのデータ・ソースは、Cluster Controllerを介して、クラスタ化されたOracle BI Serverを参照する必要があります。このタスクは、BI Publisherで実行します。

BI PublisherでOracle BI EEデータ・ソースを設定する手順は次のとおりです。

  1. 管理者資格証明を使用してBI Publisherにログインし、「管理」タブを選択します。

  2. 「データ・ソース」で、「JDBC接続」を選択します。

  3. 「接続文字列」パラメータを次のように変更して、Oracle BI EEのデータ・ソース設定を更新します。

    jdbc:oraclebi://primary_cluster_controller_host:primary_cluster_controller_
port/PrimaryCCS=primary_cluster_controller_host;PrimaryCCSPort=primary_cluster_
controller_port;SecondaryCCS=secondary_cluster_controller_host;
SecondaryCCSPort=secondary_cluster_controller_port;

    例:

    jdbc:oraclebi://APPHOST1:9706/PrimaryCCS=APPHOST1;PrimaryCCSPort=9706;
SecondaryCCS=APPHOST2;SecondaryCCSPort=9706;

  4. 「システム・ユーザーの使用」を選択します。

    接続にシステム・ユーザーを使用しない場合は、「システム・ユーザーの使用」を選択解除して、「ユーザー名」と「パスワード」に対してBIImpersonateUserの資格証明を指定します。このコンテキストのBIImpersonateUserユーザーの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Edition開発者ガイド』のOracle BIプレゼンテーション・カタログに接続するための資格証明に関する項を参照してください。

  5. 「接続のテスト」をクリックします。「接続は正常に確立されました。」というメッセージが表示されます。

  6. 「適用」をクリックします。

9.5.3.4 BI Publisher用のJMSの構成

すべての永続ストアの場所を、両方のノードから参照できるディレクトリに構成する必要があります。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。JMSを構成する手順は次のとおりです。

  1. 管理コンソールにログインします。

  2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアのサマリー」ページが表示されます。

  3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  4. 「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。

  5. 名前(例: BipJmsStore2)を入力し、BI_SERVER2をターゲットにします。APPHOST1とAPPHOST2の両方からアクセスできるように、共有記憶域にあるディレクトリを入力します。

    ORACLE_BASE/admin/domain_name/bi_cluster/jms

  6. 「OK」をクリックし、「変更のアクティブ化」をクリックします。

  7. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSサーバー」ノードをクリックします。「JMSサーバーのサマリー」ページが表示されます。

  8. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  9. 「新規」をクリックします。

  10. 名前(例: BipJmsServer2)を入力してから「永続ストア」ドロップダウン・リストで「BipJmsStore2」を選択し、「次へ」をクリックします。

  11. 「BI_SERVER2」をターゲットとして選択します。

  12. 「終了」→「変更のアクティブ化」をクリックします。

  13. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。

  14. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  15. 「BipJmsResource」→「サブデプロイメント」タブをクリックします。

  16. 「サブデプロイメント」で「BipJmsSubDeployment」を選択します。

  17. サブデプロイメントの追加ターゲットとして、新しいBI Publisher JMSサーバーBipJmsServer2を追加します。

  18. 「保存」→「変更のアクティブ化」をクリックします。

BI Publisherに対して実行したJMS構成を検証するには、第9.5.3.5項「BI Publisher Schedulerの構成の更新」の手順を実行してください。

9.5.3.5 BI Publisher Schedulerの構成の更新

この項の手順に従い、BI Publisher SchedulerのJMS共有一時ディレクトリを更新します。この項の手順は、APPHOSTのいずれか1つ(APPHOST1またはAPPHOST2)でのみ実行する必要があります。

BI Publisher Schedulerの構成を更新する手順は次のとおりです。

  1. 次のどちらかのURLにアクセスしてBI Publisherにログインします。

    • http://APPHOST1VHN1:9704/xmlpserver

    • http://APPHOST2VHN1:9704/xmlpserver

  2. 「管理」リンクをクリックします。

  3. 「スケジューラ構成」を「システム・メンテナンス」で選択します。「スケジューラ構成」画面が表示されます。

  4. 共有記憶域にあるディレクトリを入力して、「共有ディレクトリ」を更新します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。

  5. 「JMSのテスト」をクリックします。

    JMSのテストが成功したという確認メッセージが表示されます。


    注意:

    テストの成功を示す確認メッセージが表示されない場合は、JNDI URLが次のとおりに設定されていることを確認します。

    cluster:t3://bi_cluster

  6. 「適用」をクリックします。

  7. スケジューラのステータスを「スケジューラ診断」タブでチェックします。

9.5.4 Oracle BI Composerの追加の構成タスク

Oracle BI Composerでロード・バランサ・ポートに対するポート値を変更する手順は次のとおりです。

  1. Fusion Middleware Control Consoleにログインします。

  2. 左側のナビゲーション・ペインで、「アプリケーション・デプロイメント」を展開します。

  3. bicomposer(11.1.1) (bi_cluster)の下で、bicomposer(11.1.1) (bi_server1)を右クリックし、「システムMBeanブラウザ」を選択します。

  4. 次のMBeanに移動します。

    「アプリケーション定義のMBean」 > oracle.adf.share.connections > Server: bi_server1 > Application: bicomposer > ADFConnections > BISoapConnection > bi-default

  5. Protocol属性をhttpに設定します。

  6. Port属性をロード・バランサのHTTPポート(80)に設定します。

  7. 次のように、Host属性を内部ロード・バランサのURLに設定します。

    biinternal.mycompany.com

  8. 「適用」をクリックします。

  9. ADFConnectionsのMBeanに移動して、「操作」タブを選択します。

  10. 「保存」をクリックしてから、「呼出し」をクリックします。

  11. Fusion Middleware Controlまたは管理コンソールを使用して、BIコンポーザ・アプリケーションを再起動します。

9.6 その他の構成後タスクおよび検証タスク

Oracle BI Scheduler、Oracle RTD、BI PublisherおよびOracle BI Composerにおいて高可用性の構成タスクを実行した後、さらに構成後および検証に関する次の手順に従います。

この項の構成は、次のとおりです。

9.6.1 トランザクション・リカバリ用デフォルト永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。


注意:

可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。

各管理対象サーバーで次の手順を実行して、デフォルト永続ストアの場所を設定します。

  1. 管理コンソールにログインします。

  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  3. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。

  4. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの「設定」ページが表示され、「構成」タブにデフォルト設定されます。

  5. 「サービス」タブを開きます。

  6. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。

    ORACLE_BASE/admin/domain_name/bi_cluster_name/tlogs

    各管理対象サーバーで同じパスを使用します。管理対象サーバーが再起動されると、それぞれにサブディレクトリが作成されます。

  7. 「保存」→「変更のアクティブ化」をクリックします。


    注意:

    トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。bi_server1とbi_server2の両方からこのディレクトリにアクセスできる必要があります。

9.6.2 APPHOST2でのOracle Business Intelligenceの起動と検証

この項の構成は、次のとおりです。

9.6.2.1 bi_server2管理対象サーバーの起動

bi_server2管理対象サーバーを起動する手順は次のとおりです。

  1. 管理コンソールを使用して次の手順に従い、bi_server2管理対象サーバーを起動します。

    1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

    2. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

    3. 「制御」タブをクリックします。

    4. 「bi_server2」を選択してから、「起動」をクリックします。

  2. 管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動しました」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

9.6.2.2 Oracle Business Intelligenceシステム・コンポーネントの起動

opmnctlコマンドを使用して、Oracle Business Intelligenceのシステム・コンポーネントを制御できます。

opmnctlコマンドライン・ツールを使用してOracle Business Intelligenceシステム・コンポーネントを起動する手順は次のとおりです。

  1. ORACLE_INSTANCE/binにあるOPMNコマンドライン・ツールに含まれているディレクトリに移動します。

  2. opmnctlコマンドを実行して、Oracle Business Intelligenceシステム・コンポーネントを起動します。

    • opmnctl startall

      OPMNおよびすべてのOracle Business Intelligenceシステム・コンポーネントを起動します。

    • opmnctl start

      OPMNのみ起動します。

    • opmnctl startproc ias-component=component_name

      特定のシステム・コンポーネントを起動します。たとえば、coreapplication_obips2がPresentation Servicesコンポーネントの場合、次のように実行します。

      opmnctl startproc ias-component=coreapplication_obips2

  3. Oracle Business Intelligenceシステム・コンポーネントのステータスをチェックします。

    opmnctl status

9.6.2.3 Oracle Business IntelligenceのURLの検証

次のURLにアクセスします。

  • http://APPHOST2VHN1:9704/analyticsにアクセスして、bi_server1のステータスを確認します。

  • http://APPHOST2VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データに含まれる使用可能なポリシーとアサーション・テンプレートのリストが表示されます。

    注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

  • http://APPHOST2VHN1:9704/xmlpserverにアクセスして、BI Publisherアプリケーションのステータスを確認します。

  • http://APPHOST2VHN1:9704/uiにアクセスして、Oracle RTDアプリケーションのステータスを確認します。

  • http://APPHOST2VHN1:9704/mapviewerにアクセスして、Oracle MapViewerのステータスを確認します。

  • http://APPHOST2VHN1:9704/aps/Essbaseにアクセスして、Oracle Essbaseアプリケーションのステータスを確認します。

  • http://APPHOST2VHN1:9704/aps/SmartViewにアクセスして、Smart Viewアプリケーションのステータスを確認します。

  • http://APPHOST2VHN1:9704/workspaceにアクセスして、Workspaceアプリケーションのステータスを確認します。

  • http://APPHOST2VHN1:9704/hrにアクセスして、Financial Reportingアプリケーションのステータスを確認します。

  • http://APPHOST2VHN1:9704/calcmgr/index.htmにアクセスして、Calculation Managerアプリケーションのステータスを確認します。

9.6.2.4 ロード・バランサを介したアクセスの検証

URLを検証して、Oracle HTTP Serverからbi_clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。URLを検証する手順は次のとおりです。

  1. bi_server2の実行中に、管理コンソールを使用してbi_server1を停止します。

  2. 次のURLにアクセスして、ルーティングとフェイルオーバーが適切に機能することを確認します。

    • http://bi.mycompany.com/analytics

    • http://bi.mycompany.com/xmlpserver

    • http://bi.mycompany.com/ui

  3. 管理コンソールからbi_server1を起動します。

  4. 管理コンソールからbi_server2を停止します。

  5. 次のURLにアクセスして、ルーティングとフェイルオーバーが適切に機能することを確認します。

    • http://bi.mycompany.com/analytics

    • http://bi.mycompany.com/xmlpserver

    • http://bi.mycompany.com/ui

  6. 管理コンソールからbi_server2を起動します。

9.6.2.5 Essbaseのクラスタリングの検証

Essbaseのクラスタリングを検証する手順は次のとおりです。

  1. APS(Hyperion Provider Services)のテストURLを確認します。

    https://bi.mycompany.com/aps/Essbase?ClusterName=EssbaseCluster-1

  2. 次のコマンドをAPPHOST1上で実行します。

    ORACLE_BASE/admin/instance1/bin/opmnctl stopproc
ias-component=essbaseserver1

  3. EssbaseがAPPHOST2上で起動することを確認します。

    ORACLE_BASE/admin/instance2/bin/opmnctl status

    ステータスは最初はinitであり、その後、Aliveに変わります。

  4. APSのテストURLを再度確認します。

    https://bi.mycompany.com/aps/Essbase?ClusterName=EssbaseCluster-1

9.6.3 管理対象サーバーのノード・マネージャの構成

ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。この検証では、管理サーバーおよびその他のサーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。詳細は、第10章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照してください。その章の手順は、表9-3に示す情報を使用して、2回実行する必要があります。

表9-2 ノード・マネージャとサーバーのホスト名検証の詳細

実行 ホスト名(HOST) サーバー名(WLS_SERVER)

Run1:

APPHOST1

bi_server1

Run2:

APPHOST2

bi_server2

9.6.4 管理対象サーバーのサーバー移行の構成

サーバー移行は、APPHOST1ノードとAPPHOST2ノードのどちらかで障害が発生した場合に、BI Publisherコンポーネントを正しくフェイルオーバーするために必要です。詳細は、第11章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。

9.7 インストールのバックアップ

スケール・アウトしたドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法の詳細は、このガイドのコンポーネントのリカバリおよびコンポーネント・ホストが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドの別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドも参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

  1. 次の手順を実行して、Web層をバックアップします。

    1. opmnctlを使用してインスタンスを停止します。

      WEBHOSTn> ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

    2. 次のコマンドをroot権限で実行して、Web層のMiddlewareホームをバックアップします。

      WEBHOSTn> tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

    3. 次のコマンドを使用して、Web層のOracleインスタンスをバックアップします。

      WEBHOSTn> tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

      WEBHOST2についても、この手順を繰り返します。

    4. opmnctlを使用してインスタンスを起動します。

      WEBHOSTn> cd ORACLE_BASE/admin/instance_name/bin
WEBHOSTn> opmnctl startall

  2. データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。

  3. 次の手順を使用して、アプリケーション層のBIインスタンスをバックアップします。

    1. opmnctlを使用してインスタンスを停止します。

      APPHOSTn> ORACLE_INSTANCE/bin/opmnctl stopall

    2. 次のコマンドを実行して、アプリケーション層のミドルウェア・ホームをバックアップします。

      APPHOSTn> tar -cvpf BACKUP_LOCATION/bi.tar MW_HOME

    3. 次のコマンドを使用して、アプリケーション層のOracleインスタンスをバックアップします。

      APPHOSTn> tar -cvpf BACKUP_LOCATION/bi_instance_name.tar ORACLE_INSTANCE

    4. opmnctlを使用してインスタンスを起動します。

      APPHOSTn> ORACLE_INSTANCE/bin/opmnctl startall

  4. ドメイン構成を保存するために、管理サーバーと管理対象サーバーのドメイン・ディレクトリをバックアップします。構成ファイルはすべて、ORACLE_BASE/admin/domain_nameディレクトリにあります。次のコマンドを実行してバックアップを作成します。

    APPHOSTn> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

    注意: この項で説明した手順に従って、アプリケーション層内のすべてのコンピュータ上にバックアップを作成します。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引