Oracle® Fusion Middleware

Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド

11g リリース1(11.1.1)

B63036-05 (原本部品番号: E15722-07)

2014年12月

エンタープライズ・デプロイメントで、Oracle Business Intelligenceコンポーネントをインストールおよび構成する方法について説明します。

Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド, 11g リリース1(11.1.1)

B63036-05 (原本部品番号: E15722-07)

Copyright © 2010, 2014, Oracle and/or its affiliates.All rights reserved.

原本主著者: Kaye McArdell (ライター)、Susan Kornberg (協力エンジニア)

原本協力社: Edith Avot、Marla Azriel、Stuart Berry、Pradeep Bhat、Faouzia el-Idrissi、Jacek Laska、Yan Li、Srinivasan Varadarajan、Christine Jacobs

原本協力者: High Availability Systems and Maximum Availability Architecture (MAA) and Oracle Business Intelligence development, product management, and quality assurance teams

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、他社の商標の可能性があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 エンタープライズ・デプロイメントの概要

- 1.1 エンタープライズ・デプロイメント・ガイドについて

- 1.2 エンタープライズ・デプロイメントの用語

- 1.3 Oracle推奨事項のメリット

- 1.3.1 組込みセキュリティ

- 1.3.2 高可用性

2 エンタープライズ・デプロイメント参照用トポロジの紹介

- 2.1 エンタープライズ・デプロイメント参照用トポロジの概要

- 2.1.1 このガイドに記載されている参照用トポロジ

- 2.1.2 Oracle Identity Managementの統合について

- 2.1.3 Web層ノードについて

- 2.1.4 アプリケーション層について

- 2.1.5 データ層について

- 2.1.6 通信のユニキャスト要件について

- 2.2 Linuxでのエンタープライズ・デプロイメントのハードウェア要件

- 2.3 インストールするソフトウェア・コンポーネントの識別

- 2.4 資格証明ストアとポリシー・ストアとしてのLDAPについて

- 2.5 クロックの同期

- 2.6 参照用トポロジのインストールおよび構成のロード・マップ

3 エンタープライズ・デプロイメント用のネットワークの準備

- 3.1 エンタープライズ・デプロイメント用のネットワークの準備の概要

- 3.2 トポロジで使用する仮想サーバー名について

- 3.2.1 bi.mycompany.com

- 3.2.2 admin.mycompany.com

- 3.2.3 biinternal.mycompany.com

- 3.3 ロード・バランサの構成

- 3.3.1 ロード・バランサの要件

- 3.3.2 ロード・バランサの構成手順

- 3.4 IPおよび仮想IPについて

- 3.4.1 APPHOST1上のADMINVHNの有効化

- 3.4.2 管理対象サーバーの仮想IPの有効化

- 3.5 ファイアウォールとポートについて

4 エンタープライズ・デプロイメント用のファイル・システムの準備

- 4.1 エンタープライズ・デプロイメント用のファイル・システムの準備の概要

- 4.2 ディレクトリとディレクトリ変数の用語

- 4.3 各種ディレクトリの推奨場所について

- 4.3.1 バイナリ(Oracleホーム)・ディレクトリ用の共有記憶域に関する推奨事項

- 4.3.1.1 バイナリ(Oracleホーム)・ディレクトリについて

- 4.3.1.2 複数のドメインによる単一のOracleホームの共有について

- 4.3.1.3 冗長バイナリ(Oracleホーム)・ディレクトリの使用について

- 4.3.2 ドメイン構成ファイル用の共有記憶域に関する推奨事項

- 4.3.2.1 Oracle WebLogic Server管理サーバーおよび管理対象サーバーのドメイン構成ファイルについて

- 4.3.2.2 管理サーバーおよび管理対象サーバーのドメイン構成ファイル用の共有記憶域の要件

- 4.3.3 JMSファイル・ストアとJTAトランザクション・ログ用の共有記憶域に関する推奨事項

- 4.3.4 ディレクトリの推奨場所

- 4.3.5 ディレクトリ構造と構成

- 4.4共有記憶域の構成

- 4.4.1 共有ネットワーク・ファイルがWindows環境でアクセス可能であることの確認

5 エンタープライズ・デプロイメント用のデータベースの準備

- 5.1 エンタープライズ・デプロイメント用のデータベースの準備の概要

- 5.2 データベース要件について

- 5.2.1 データベース・ホストの要件

- 5.2.2 サポートされているデータベース・バージョン

- 5.2.3 推奨データベース・キャラクタ・セット

- 5.3 11.xおよび12cデータベース用のデータベース・サービスの作成

- 5.3.1 11gリリース1データベース用のデータベース・サービスの作成

- 5.3.2 11.2xおよび12cデータベース用のデータベース・サービスの作成

- 5.4 Oracle RACデータベースへのOracle Business Intelligenceスキーマのロード

- 5.5 データベースのバックアップ

6 エンタープライズ・デプロイメント用のソフトウェアのインストール

- 6.1 ソフトウェアのインストール・プロセスの概要

- 6.2 Oracle HTTP Serverのインストール

- 6.2.1 Oracle HTTP Serverのインストールの前提条件

- 6.2.2 Oracle HTTP ServerのWEBHOST1およびWEBHOST2へのインストール

- 6.2.3 Oracle HTTP Serverインストールのバックアップ

- 6.3 Oracle Fusion Middlewareのインストール

- 6.3.1 Oracle WebLogic Serverのインストールとミドルウェア・ホームの作成

- 6.3.2 Oracle Business Intelligenceのインストール

- 6.3.3 Oracle Fusion Middlewareインストールのバックアップ

7 エンタープライズ・デプロイメント用のWeb層の構成

- 7.1 Web層構成の概要

- 7.2 構成ウィザードによるOracle HTTP Serverの構成

- 7.3 構成の検証

- 7.4 HTTPリクエストをルーティングするためのロード・バランサの構成

- 7.5 仮想ホストの定義

- 7.5.1 httpd.confファイルでのIPアドレスとポートの定義

- 7.5.2 <VirtualHost>ディレクティブを定義する.confファイルの作成

- 7.5.3 構成の検証

8 管理サーバーと最初の管理対象サーバーが含まれたドメインの作成

- 8.1 ドメイン作成の概要

- 8.2 APPHOST1でのドメインおよびbi_server1管理対象サーバーの作成

- 8.3 構成後タスクおよび検証タスク

- 8.3.1 BI Publisher用のJMSの構成

- 8.3.2 APPHOST1上の管理サーバーのboot.propertiesの作成

- 8.3.3 APPHOST1での管理サーバーの起動

- 8.3.4 管理サーバーの高可用性の有効化

- 8.3.4.1 管理サーバー用のマシンの作成

- 8.3.4.2 管理サーバーの仮想IPアドレスのリスニングの有効化

- 8.3.4.3 bi_server1管理対象サーバーに対する別のドメイン・ディレクトリの作成

- 8.3.4.4 Fusion Middleware Controlのフェイルオーバーの有効化

- 8.3.5 管理サーバーの検証

- 8.3.6 bi_server1管理対象サーバーのリスニング・アドレスの設定

- 8.3.6.1 EPMレジストリ内の論理Webアプリケーションの更新

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

- 8.3.8 APPHOST1でのOracle Business Intelligenceの検証

- 8.4 WebLogicドメインのOracle HTTP Serverの構成

- 8.4.1 管理サーバーとbi_servern管理対象サーバーについてのOracle HTTP Serverの構成

- 8.4.2 WebLogicプラグイン有効化フラグのオン

- 8.4.3 Oracle WebLogic ServerへのOracle HTTP Serverの登録

- 8.4.4 管理コンソールのフロントエンドURLの設定

- 8.4.5 Oracle HTTP Serverを使用したアクセスの検証

- 8.4.5.1 管理コンソールおよびFusion Middleware Controlの検証

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

- 8.5 管理サーバーの手動フェイルオーバーの確認

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 9.5.3.1 BI Publisher Schedulerの構成の更新

- 9.5.3.1.1 Quartz構成の更新

- 9.5.3.1.2 BI Publisher SchedulerのWebLogic JNDI URLの更新

- 9.5.3.1.3 BI Publisher用のJMSの構成

- 9.5.3.1.4 JMS共有のTempディレクトリの更新

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

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

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

- 9.5.5 Essbaseの追加の構成タスク

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

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

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

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

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

- 9.6.2.3 Oracle Business IntelligenceのURLの検証

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

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

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

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

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

10 エンタープライズ・デプロイメント用のノード・マネージャの設定

- 10.1 ノード・マネージャの設定について

- 10.2 ノード・マネージャのログ・ファイルの場所の変更

- 10.3 ノード・マネージャのホスト名検証証明書の有効化

- 10.3.1 utils.CertGenユーティリティを使用した自己署名証明書の生成

- 10.3.2 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

- 10.3.3 Keytoolユーティリティを使用したトラスト・キーストアの作成

- 10.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

- 10.3.5 カスタム・キーストアを使用するための管理対象サーバーの構成

- 10.3.6 管理対象サーバーのホスト名検証設定の変更

- 10.4 ノード・マネージャの起動

11 エンタープライズ・デプロイメント用のサーバー移行の構成

- 11.1 エンタープライズ・デプロイメント用のサーバー移行の概要

- 11.2 サーバー移行leasing表のユーザーと表領域の設定

- 11.3 管理コンソールを使用したマルチ・データ・ソースの作成

- 11.4 ホスト名検証証明書の有効化

- 11.5 ノード・マネージャのプロパティ・ファイルの編集

- 11.6 wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定

- 11.7 サーバー移行ターゲットの構成

- 11.8 サーバー移行のテスト

12 エンタープライズ・デプロイメントとOracle Identity Managementの統合

- 12.1 資格証明ストアとポリシー・ストアの構成

- 12.1.1 資格証明ストアとポリシー・ストアの構成の概要

- 12.1.2 資格証明ストアの構成

- 12.1.2.1 ユーザーとグループの作成

- 12.1.2.2 構成ファイルのバックアップ

- 12.1.2.3 LDAPを使用するアイデンティティ・ストアの構成

- 12.1.2.4 プロバイダの順序の設定

- 12.1.2.5 WebLogic管理者のLDAPへの移行

- 12.1.2.5.1 boot.propertiesファイルの更新およびシステムの再起動

- 12.1.3 ポリシー・ストアの構成

- 12.1.4 資格証明とポリシーの再関連付け

- 12.1.5 アイデンティティ・ストアの再関連付けの後のユーザーGUIDのリフレッシュ

- 12.1.5.1 ユーザーGUIDについて

- 12.1.5.2 GUIDのリフレッシュについて

- 12.1.5.3 ユーザーGUIDのリフレッシュ

- 12.2 Oracle Access Manager 10gの統合

- 12.2.1 Oracle Access Managerの統合について

- 12.2.2 Oracle Access Manager構成ツールの使用

- 12.2.2.1 Oracle Access Manager構成ツールについて

- 12.2.2.2 Oracle Access Manager構成ツールで使用する情報の収集

- 12.2.2.3 Oracle Access Manager構成ツールの実行

- 12.2.2.4 ポリシー・ドメインおよびアクセス・ゲートが正常に作成されたことの確認

- 12.2.3 ホスト識別子の更新

- 12.2.4 Webゲート・プロファイルの更新

- 12.2.5 Webゲートのインストールと構成

- 12.2.6 WebゲートのIP検証の構成

- 12.2.7 WebLogic認証プロバイダの設定

- 12.2.7.1 Oracle Access Manager IDアサータの設定

- 12.2.7.2 プロバイダの順序の設定

- 12.2.8 アプリケーションの構成

- 12.2.8.1 Oracle BI EEでのSSO/Oracle Access Managerの有効化

- 12.2.8.2 BI PublisherでのSSO/Oracle Access Managerの有効化

- 12.2.8.3 Oracle BI SearchでのSSO/Oracle Access Managerの有効化

- 12.2.8.4 Oracle RTDでのSSO/Oracle Access Managerの有効化

- 12.2.8.4.1 Oracle RTDとOracle Access Manager 10gのログアウトのガイドライン

- 12.3 Oracle Access Manager 11g統合

- 12.3.1 Oracle Access Managerの統合の概要

- 12.3.2 Oracle Access Managerの前提条件

- 12.3.3 Webゲートのインストール

- 12.3.3.1 GCCライブラリのインストール

- 12.3.3.2 Webゲートのインストール

- 12.3.3.3 インストール後の手順

- 12.3.4 WebGateエージェントの登録

- 12.3.4.1 RREGツール

- 12.3.4.2 OAM11gRequestファイルの更新

- 12.3.4.3 oamregツールの実行

- 12.3.4.4 WEBHOSTへのアクセス・ファイルのコピー

- 12.3.5 WebゲートのIP検証の構成

- 12.3.6 WebLogic認証プロバイダの設定

- 12.3.6.1 構成ファイルのバックアップ

- 12.3.6.2 OAM IDアサータの設定

- 12.3.6.3 プロバイダの順序の設定

- 12.3.7 アプリケーションの構成

- 12.3.7.1 Oracle BI EEでのSSO/Oracle Access Managerの有効化

- 12.3.7.2 BI PublisherでのSSO/Oracle Access Managerの有効化

- 12.3.7.3 Oracle BI SearchでのSSO/Oracle Access Managerの有効化

- 12.3.7.4 Oracle RTDでのSSO/Oracle Access Managerの有効化

- 12.3.7.4.1 Decision Centerのログアウトのリダイレクトに関する問題の回避

- 12.4 アイデンティティ管理構成のバックアップ

13 エンタープライズ・デプロイメントの管理

- 13.1 エンタープライズ・デプロイメントの管理について

- 13.2 Oracle Business Intelligenceの起動と停止

- 13.2.1 Oracle Business Intelligence管理対象サーバーの起動と停止

- 13.2.2 Oracle Business Intelligenceシステム・コンポーネントの起動と停止

- 13.3 エンタープライズ・デプロイメントの監視

- 13.4 エンタープライズ・デプロイメントのスケーリング

- 13.4.1 Oracle Business Intelligenceトポロジのスケール・アップ

- 13.4.2 Oracle Business Intelligenceトポロジのスケール・アウト

- 13.4.2.1 Oracle Business Intelligenceのスケール・アウト手順

- 13.5 APPHOST2への管理サーバーの手動フェイルオーバー

- 13.5.1 前提条件および手順

- 13.5.2 Oracle HTTP Serverを介したAPPHOST2へのアクセスの検証

- 13.5.3 APPHOST1への管理サーバーのフェイルバック

- 13.6 エンタープライズ・デプロイメントのバックアップとリカバリの実行

- 13.7 エンタープライズ・デプロイメントのパッチ適用

- 13.8 SQLNet接続のタイムアウト防止

- 13.9 エンタープライズ・デプロイメントのトラブルシューティング

- 13.9.1 BIアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する

- 13.9.2 手動フェイルオーバー後に管理サーバーの起動に失敗する

- 13.9.3 管理コンソールで変更をアクティブ化するときにエラーが発生する

- 13.9.4 サーバー移行後にbi_server管理対象サーバーがフェイルオーバーしない

- 13.9.5 サーバー移行後にbi_server管理対象サーバーにブラウザからアクセスできない

- 13.9.6 OAM構成ツール実行時にURLが削除されない

- 13.9.7 変更をアクティブ化した後でユーザーがログイン画面にリダイレクトされる

- 13.9.8 変更をアクティブ化した後でユーザーがホーム・ページにリダイレクトされる

- 13.9.9 構成されたJOCポートがすでに使用中

- 13.9.10 管理対象サーバーのメモリー不足の問題

- 13.9.11 BI Publisherの「スケジューラ診断」ページでJMSインスタンスが欠落している

- 13.9.12 管理対象サーバーの停止後にBI Publisherのジョブが不整合な状態になる

- 13.9.13 BI Publisher SchedulerクラスタでのJMSインスタンスの失敗

- 13.9.14 管理者がカスタム・グループに属している場合のMapViewerの構成

索引

はじめに

ここでは、対象読者、コンテンツおよび『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』で使用する表記規則について説明します。

対象読者

このドキュメントは、Oracle Business Intelligenceエンタープライズ・デプロイメントのインストールや構成を担当するシステム管理者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleカスタマは、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs(聴覚障害者向け)を参照してください。

関連ドキュメント

関連するOracle Business Intelligenceドキュメントのリストについては、Oracle Business Intelligenceドキュメント・ライブラリを参照してください。

次の関連ドキュメントも参照してください。

- 使用しているプラットフォーム用のOracle Fusion Middlewareリリース・ノート

- 『Oracle Fusion Middleware High Availability Guide』

- Oracle Fusion Middleware管理者ガイド

- 『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』

さらに、次もあります。

- Oracle Business Intelligenceに関連するオンライン・トレーニングのリソースについては、Oracle Learning Libraryを参照してください。

- 製品情報センターに関するサポート・ノート(記事ID: 1267009.1)をMy Oracle Support(https://support.oracle.com)でアクセスしてください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 エンタープライズ・デプロイメントの概要

この章では、Oracle Business Intelligenceのエンタープライズ・トポロジの概要について説明します。

重要:

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

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

- 第1.1項「エンタープライズ・デプロイメント・ガイドについて」

- 第1.2項「エンタープライズ・デプロイメントの用語」

- 第1.3項「Oracle推奨事項のメリット」

1.1 エンタープライズ・デプロイメント・ガイドについて

このエンタープライズ・デプロイメント・ガイドでは、可用性が高く、セキュアなOracle Business Intelligenceデプロイメントのために推奨されるベスト・プラクティスを示す構造計画を定義します。この青写真に示すベスト・プラクティスは、Oracle Database、Oracle Fusion MiddlewareおよびOracle Enterprise Manager Fusion Middleware Controlなど、あらゆる技術スタックのOracle製品を対象にしています。その結果実現するエンタープライズ・デプロイメントは、すぐにスケール・アウトして容量の拡張要求に対応できます。

特にOracle Business Intelligenceエンタープライズ・デプロイメントでは、次のとおりです。

- 様々な業務のサービス・レベル合意(SLA)を考慮して、高可用性ベスト・プラクティスをできるだけ広範囲に適用できるようにします。

- データベース・グリッド・サーバーと低コストのストレージを使用したストレージ・グリッドを活用し、回復力に優れ低コストのインフラストラクチャを提供します。

- 様々な構成を対象として広範囲なパフォーマンス影響調査の結果を利用し、ビジネス・ニーズに応じて実行およびスケールできるように高可用性アーキテクチャが最適に構成されます。

- 停止状態からのリカバリ時間と自然災害時に許容可能なデータ損失量を制御できます。

- ベスト・プラクティスと推奨アーキテクチャが使用されます。それらは、ハードウェアとオペレーティング・システムには依存していません。

高可用性の実現に関する追加情報は、次のOracle Technology Networkで、Oracle Maximum Availability Architectureのページを参照してください。

http://www.oracle.com/technetwork/database/features/availability/maa-best-practices-155366.html

注意:

Oracle Business Intelligenceのエンタープライズ・デプロイメント・ガイドは、Linux環境におけるエンタープライズ・デプロイメントを中心に説明しています。しかしながら、UNIX環境やWindows環境を使用したエンタープライズ・デプロイメントの実装も可能です。

1.2エンタープライズ・デプロイメントの用語

この項では、このガイドで使用されているエンタープライズ・デプロイメント用語について説明します。

- Oracleホーム: 特定の製品をホストするために必要なファイルがインストールされて格納されています。たとえば、Oracle Business IntelligenceのOracleホームには、Oracle Business Intelligenceのバイナリとライブラリ・ファイルが格納されているディレクトリがあります。Oracleホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。各Oracleホームは、複数のOracleインスタンスやOracle WebLogic Serverドメインと関連付けることができます。

- WebLogic Serverホーム: Oracle WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。WebLogic Serverホームのディレクトリは、Oracleホームのディレクトリのピアであり、ミドルウェア・ホームのディレクトリ構造の内部にあります。

- ミドルウェア・ホーム: WebLogic Serverホームと、オプションとして1つまたは複数のOracleホームで構成されます。ミドルウェア・ホームは、ローカル・ファイル・システムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。

- Oracleインスタンス: Oracle BI Server、Oracle BI Presentation Services、Oracle HTTP Server、Oracle Internet Directoryなどの、1つ以上のアクティブなミドルウェア・システム・コンポーネントが含まれます。インストール時かその後でインスタンスの作成と構成を行うときに、インスタンスにどのコンポーネントを含めるかを決定します。Oracleインスタンスには、更新可能なファイルがあります。それらのファイルの例には、構成ファイル、ログ・ファイル、一時ファイルなどがあります。

- フェイルオーバー: 高可用性システムのメンバーに不測の障害が発生した場合(計画外停止)、サービスの提供をコンシューマに対して続行するため発生する手順です。アクティブ/パッシブ・システムの場合、フェイルオーバー操作によってパッシブ・メンバーがアクティブになり、コンシューマは障害が発生したメンバーからそのメンバーにリダイレクトされます。フェイルオーバー操作は、手動でも実行できます。また、障害を検出した場合にクラスタのリソースを障害ノードからスタンバイ・ノードに移動するように、ハードウェア・クラスタ・サービスを構成することで、フェイルオーバー操作を自動化することもできます。アクティブ/アクティブ・システムの場合、フェイルオーバーはロード・バランサのエンティティが、アクティブ・メンバーにリクエストを配信することにより実現されます。アクティブ・メンバーに障害が発生すると、ロード・バランサにより障害が検出され、障害メンバーへのリクエストが、正常に動作しているアクティブ・メンバーに自動的にリダイレクトされます。アクティブ/アクティブ型システムとアクティブ/パッシブ型システムの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

- フェイルバック: システムのフェイルオーバー操作が正常に終了した後、発生するプロセスです。このフェイルバック・プロセスでは、最初に障害を起こしたメンバーは修復され、スタンバイ・メンバーとしてシステムに再導入されます。必要に応じて、フェイルバック・プロセスを開始して、このメンバーをアクティブにし、別のメンバーを非アクティブにすることができます。このプロセスにより、システムは障害発生前の構成に戻ります。

- ハードウェア・クラスタ: ハードウェア・クラスタは、ネットワーク・サービス(たとえば、IPアドレス)やアプリケーション・サービス(たとえば、データベース、Webサーバー)を単一のビューでサービスのクライアントに提供するコンピュータのコレクションです。ハードウェア・クラスタの各ノードは、それぞれ固有のプロセスを実行するスタンドアロン・サーバーです。これらのプロセスは互いに通信して、単一のシステムであるかのように動作して、アプリケーション、システム・リソースおよびデータを連携してユーザーに提供できます。
ハードウェア・クラスタは、専用のハードウェア(クラスタ・インターコネクト、共有記憶域)とソフトウェア(ヘルス・モニター、リソース・モニター)を使用して、高可用性とスケーラビリティを実現します(クラスタ・インターコネクトは、ハートビート情報がノードの停止を検出する際にハードウェア・クラスタで使用されるプライベート・リンクです)。専用のハードウェアとソフトウェアが必要であるため、通常、ハードウェア・クラスタはSun社、HP社、IBM社、Dell社などのハードウェア・ベンダーによって提供されます。1つのハードウェア・クラスタ内で構成可能なノード数は、ベンダーによって異なりますが、Oracle Fusion Middlewareの高可用性では2つのノードのみを必要とします。そのため、このドキュメントでは、2つのノードを持つハードウェア・クラスタを高可用性ソリューションで使用することを前提とします。

- クラスタ・エージェント: ハードウェア・クラスタのノード・メンバー上で実行されるソフトウェアであり、可用性とパフォーマンスの操作を他のノードと連携して調整します。クラスタウェアによりリソースのグループ化と監視を行い、サービスを移行できます。クラスタ・エージェントではサービスのフェイルオーバーを自動化できます。

- クラスタウェア: クラスタ・メンバーの処理を、1つのシステムとして管理するソフトウェアです。これにより、クラスタ・メンバー間のハートビート・メカニズムを使用して、監視対象のリソースとサービスのセットを定義したり、これらのリソースとサービスをクラスタ内の別のメンバーにできるだけ効率的かつ透過的な方法で移動することができます。

- 共有記憶域: エンタープライズ・デプロイメント内のすべてのコンピュータがアクセスできる記憶域のサブシステムです。共有ディスクには特に次のものが配置されています。

- ミドルウェア・ホームのソフトウェア

- 管理サーバーのドメイン・ホーム

- JMS

- Tlogs(該当する場合)

必要に応じて、管理対象サーバーのホームを共有ディスクに配置できます。共有記憶域は、Network Attached Storage(NAS)またはStorage Area Network(SAN)にすることができます。また、複数のノードが同時にアクセスして読込みと書込みができる他のストレージ・システムにすることもできます。

- プライマリ・ノード: Oracle Fusion Middlewareインスタンスを常にアクティブに実行しているノードであり、バックアップ/セカンダリ・ノードを持つように構成されているノードです。プライマリ・ノードに障害が発生すると、Oracle Fusion Middlewareコンポーネントはセカンダリ・ノードにフェイルオーバーされます。このフェイルオーバーは、管理サーバー用のクラスタウェアを使用して、手動または自動で実行できます。サーバー移行機能に基づいたシナリオでは、WebLogic Whole Server移行機能が自動化フェイルオーバーに使用されています。

- セカンダリ・ノード: Oracle Fusion Middlewareインスタンス用のバックアップ・ノードであるノードです。プライマリ・ノードが使用できなくなると、アクティブなインスタンスでフェイルオーバーが実行されます。この項で、プライマリ・ノードに関する定義を参照してください。

- ネットワーク・ホスト名: /etc/hostsファイルやDNS解決によりIPアドレスに割り当てられる名前です。この名前は、参照先コンピュータに接続する際にネットワークで参照可能です。ネットワーク・ホスト名と物理ホスト名が同一である場合があります。ただし、各コンピュータには物理ホスト名は1つのみ付与されますが、ネットワーク・ホスト名は複数付与される場合があります。そのため、コンピュータのネットワーク・ホスト名はその物理ホスト名であるとはかぎりません。

- 物理ホスト名: 現在のコンピュータの内部名です。UNIXでは、hostnameコマンドにより返される名前です。このドキュメントでは、物理ホスト名とネットワーク・ホスト名という用語を区別しています。
Oracle Fusion Middlewareではローカル・ホストを参照するために物理ホスト名を使用します。インストール中に、インストーラでは物理ホスト名が現在のコンピュータから自動的に取得され、ディスク上のOracle Fusion Middleware構成メタデータに格納されます。

- 物理IP: ネットワーク上のコンピュータのIPアドレスです。ほとんどの場合、コンピュータの物理ホスト名と関連付けられます(物理ホスト名に関する定義を参照)。仮想IPと対照的に、コンピュータがネットワークに接続されると、必ず同じコンピュータと関連付けられます。

- スイッチオーバー: 通常の運用時、システムのアクティブ・メンバーがメンテナンスやアップグレードが必要になるとき発生するプロセスです。スイッチオーバー・プロセスを開始して、メンテナンスやアップグレード(計画停止中に実施)が必要なメンバーが処理していたワークロードを、代替メンバーが引き継ぐことができます。スイッチオーバー操作により、システムのコンシューマに対してサービスが続行できるようになります。

- スイッチバック: システムのメンバーがメンテナンスまたはアップグレードのために非アクティブ化されるスイッチオーバー操作が正常に終了した後、発生するプロセスです。メンテナンスやアップグレードが完了すると、システムでスイッチバック操作を実行して、アップグレードしたメンバーをアクティブ化し、スイッチオーバー前のシステム構成に戻すことができます。

- 仮想ホスト名: ネットワーク・アドレスを指定可能なホスト名で、ロード・バランサやハードウェア・クラスタにより1台以上の物理コンピュータにマップされます。ロード・バランサの場合、このドキュメントでは仮想サーバー名の名前は仮想ホスト名と同じ意味で使用されます。複数のサーバーのセットを代表する仮想ホスト名をロード・バランサに付与でき、クライアントは仮想ホスト名を使用して、間接的にマシンと通信します。ハードウェア・クラスタの仮想ホスト名は、クラスタの仮想IPに割り当てられるネットワーク・ホスト名です。クラスタにある特定ノードにクラスタの仮想IPが永続的に付与されないため、仮想ホスト名も特定ノードに永続的に付与されません。

注意:

このドキュメントで「仮想ホスト名」という用語を使用する場合、それが仮想IPアドレスに関連付けられることを前提とします。単にIPアドレスを必要とする場合または使用する場合には、その旨を明示的に記載します。

- 仮想IP: ハードウェア・クラスタまたはロード・バランサに割り当てることができる仮想IPアドレスです。クラスタにおいて単一のシステム・ビューをネットワーク・クライアントに対して実現するために、クラスタのメンバーであるサーバー・グループに対して仮想IPはエントリ・ポイントのIPアドレスとして機能します。仮想IPは、サーバーのロード・バランサまたはハードウェア・クラスタに割り当てることができます。仮想IPはクラスタ仮想IPおよびロード・バランサ仮想IPとも呼ばれます。
ハードウェア・クラスタではクラスタの仮想IPが使用され、外部の世界に対してクラスタ(スタンドアロンのコンピュータにも構成可能)へのエントリ・ポイントを実現します。ハードウェア・クラスタのソフトウェアにより、クラスタにある2台の物理ノード間においてこのIPアドレスの変更が管理されますが、クライアントはこのIPアドレスに接続します。その際、このIPアドレスが現在アクティブである物理ノードを判別する必要はありません。2台のノードによる標準的ハードウェア・クラスタ構成では、各コンピュータは固有の物理IPアドレスと物理ホスト名を持ちながら、複数のクラスタIPアドレスを持つこともできます。これらのクラスタIPアドレスは、2台のノードにおいて切り替わります。クラスタIPアドレスを現在所有しているノードは、そのアドレスでアクティブになります。

また、ロード・バランサでも、複数のサーバーのセットのエントリ・ポイントとして仮想IPが使用されます。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーには割り当てられませんが、サーバーとクライアントとの間においてプロキシとして動作するロード・バランサに割り当てられます。

このエンタープライズ・デプロイメント・ガイドでは、この項で定義する用語以外に、Oracle Fusion MiddlewareおよびOracle WebLogic Serverの一般的な概念およびアーキテクチャを理解していることを前提としています。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

1.3 Oracle推奨事項のメリット

このガイドで説明するOracle Fusion Middleware構成は、すべての起動でセキュリティが確保され、ハードウェア・リソースが最大化され、信頼性が高く、標準に準拠したシステムをOracle Business Intelligenceに提供するために設計されています。

Oracle Fusion Middleware構成のセキュリティと高可用性のメリットは、ファイアウォール・ゾーンの分離とソフトウェア・コンポーネントのレプリケーションを通じて実現されます。

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

- 第1.3.1項「組込みセキュリティ」

- 第1.3.2項「高可用性」

1.3.1 組込みセキュリティ

エンタープライズ・デプロイメント・アーキテクチャでは、ソフトウェア・コンポーネントのすべての機能グループが独自の非武装地帯(DMZ)に隔離されており、またプロトコルおよびポートによってすべてのトラフィックに制限がかけられているためセキュアです。DMZとは、外部サービスをより大規模な信頼されないネットワークに公開する境界ネットワークです。

次の特徴により、必要なすべてのレベルにおけるセキュリティの確保と、標準に対する高いレベルでの準拠が保証されています。

- 外部のロード・バランサは、ポート80で受信した外部通信をすべてポート443にリダイレクトするように構成されています。

注意:

検証済ロード・バランサおよびその構成のリストは、Oracle Technology Networkの次の場所を参照してください。

http://www.oracle.com/technetwork/middleware/ias/tested-lbr-fw-sslaccel-100648.html

- 外部のクライアントからの通信はロード・バランシング・ルーターを超えたレベルでは発生しません。

- ロード・バランシング・ルーターからデータ層への直接的な通信は許可されません。

- コンポーネントは、Web層、アプリケーション層およびデータ層の異なる保護ゾーンで分離されます。

- 一度に2つのファイアウォールをまたがる直接的な通信は禁止されています。

- 1つのファイアウォール・ゾーンで通信が開始された場合、その通信は次のファイアウォール・ゾーンで終了する必要があります。

- Oracle Internet Directoryはデータ層内で独立しています。

- アイデンティティ管理コンポーネントは別のサブネットにあります。

- 複数の保護ゾーンにおいて複数のコンポーネント間の通信はすべて、ファイアウォールのルールに従いポートとプロトコルによって制限されます。

1.3.2 高可用性

各コンポーネントまたはソフトウェア・コンポーネントの機能グループが別のコンピュータにレプリケートされており、コンポーネント・レベルでの高可用性を実現するように構成されます。このため、エンタープライズ・デプロイメント・アーキテクチャでは高い可用性が実現されます。

また、Oracle Fusion Middlewareの高可用性の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

2 エンタープライズ・デプロイメント参照用トポロジの紹介

この章では、このガイドで使用するエンタープライズ・デプロイメントの参照用トポロジについて具体的に説明します。Oracle Business Intelligenceエンタープライズ・デプロイメントの計画を立てる場合は、この章を使用します。

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

- 第2.1項「エンタープライズ・デプロイメント参照用トポロジの概要」

- 第2.2項「Linuxにおけるエンタープライズ・デプロイメントのハードウェア要件」

- 第2.3項「インストールするソフトウェア・コンポーネントの特定」

- 第2.4項「資格証明ストアとポリシー・ストアとしてのLDAPについて」

- 第2.5項「クロックの同期」

- 第2.6項「参照用トポロジのインストールおよび構成のロード・マップ」

2.1 エンタープライズ・デプロイメント参照用トポロジの概要

このドキュメントに記載されている手順および図は参照用トポロジを示しており、いくつかの変更が適用可能です。この項を使用してエンタープライズ・デプロイメント・トポロジを計画してください。

この項の項目は次のとおりです。

- 第2.1.1項「このガイドに記載されている参照用トポロジ」

- 第2.1.2項「Oracle Identity Managementの統合について」

- 第2.1.3項「Web層ノードについて」

- 第2.1.4項「アプリケーション層について」

- 第2.1.5項「データ層について」

- 第2.1.6項「通信のユニキャスト要件について」

2.1.1 このガイドに記載されている参照用トポロジ

このドキュメントでは、図2-1に示すとおり、Oracle Business IntelligenceでOracle Access Managerを使用する参照用エンタープライズ・トポロジの構成手順について説明します。

図2-1 Oracle Access Managerを使用したMyBICompanyトポロジ

2.1.2 Oracle Identity Managementの統合について

Oracle Identity Managementシステムとの統合は、エンタープライズ・デプロイメント・アーキテクチャの重要な側面です。この統合により、シングル・サインオン、Oracle Platform Security Servicesとの統合、一元化されたアイデンティティおよび資格証明ストア、WebLogicドメインにおける認証などの機能が実現されます。IDM(Identity Management)エンタープライズ・デプロイメントは、このエンタープライズ・デプロイメントとは別であり、それ自体で別のドメイン内に存在します。エンタープライズ・デプロイメントにおけるOracle Identity Managementの詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

Oracle Identity Managementエンタープライズ・デプロイメントへの主要インタフェースは、LDAPサーバーへのLDAPトラフィック、OAMアクセス・サーバーへのOAP(Oracle Access Protocol)および認証リクエストのHTTPリダイレクトです。

2.1.3 Web層ノードについて

Web層のノードはDMZパブリック・ゾーンにあります。

この層では、WEBHOST1とWEBHOST2という2つのノードが、Webゲートおよびmod_wl_ohsとともに構成されているOracle HTTP Serverを実行します。

Oracle HTTP Serverを、ロード・バランサと複数のWebLogic Server間の仲介ポイントとして使用した場合、次のようなメリットが得られます。

- これは犠牲エリア/DMZを提供します。これはセキュリティ監査で求められる一般的な要件であり、ロード・バランサ/WebLogicシステムにおける大きな問題でもあります。ロード・バランサがWebLogic Serverに直接ルーティングされると、リクエストがロード・バランサからアプリケーション層に1回のHTTPジャンプで移動するため、セキュリティ上問題があります。

- Webサーバー構成を変更することなく、WebLogic Serverクラスタ・メンバーシップを再構成(新規サーバーの追加とサーバーの削除)できます(構成したリスト内のサーバーのいくつかがアライブであることが条件)。プラグインはクラスタ・メンバーシップを学習し、それに応じて作業を振り分けます。

- WebLogic Serverインスタンスで障害が発生した場合に、すぐにフェイルオーバーできます。プラグインは、障害が発生したWebLogic Serverインスタンスについて、ピアから得た情報を利用してアクティブに学習します。プラグインでは、障害の発生したサーバーについて、再び利用可能である旨の通知をピアから受けるまで回避を継続します。一般的にロード・バランサにはこれよりも多くの制限があります。

- Oracle HTTP Serverは、WebLogic Serverよりも速く効率的に静的コンテンツを配信します。

- WebLogic Serverで提供されているものを超えるHTTPリダイレクション。Oracle HTTP Serverは、多数の様々なWebLogic Serverクラスタのフロント・エンドとして使用できるほか、コンテンツ・ベースのルーティングも実現可能です。

- SSOが必要な場合、Oracle Identity ManagementをサポートできるのはOracle HTTP Server (WebLogic Serverではなく)のみです。

Oracle HTTP ServerからWebLogic Serverへのリクエストのプロキシを許可するmod_wl_ohsを通じて、Oracle HTTP Serverはアプリケーション層で実行されているWebLogic Serverにリクエストを転送します。

Oracle HTTP ServerにあるWebゲート(Oracle Access Managerコンポーネント)はOracle Access Protocol(OAP)を使用して、アイデンティティ管理DMZ内のOAMHOST2で実行されているOracle Access Managerと通信します。WebゲートとOracle Access Managerは、ユーザー認証などの操作を実行するために使用されます。

Web層には外部リクエストを処理するロード・バランサ・ルータも含まれています。外部リクエストは、ロード・バランサで構成されている仮想ホスト名に送信されます。ロード・バランサは、このリクエストをOracle HTTP Serverに転送します。

Oracle HTTP Server内のWebGateモジュールは、Oracle Access Protocol(OAP)を使用してOracle Access Managerと通信し、ユーザー・グループへの問合せなどの操作を実行します。

Web層を保護しているファイアウォールでは、HTTPポート、つまりHTTPS用のポート443とHTTP用のポート80のみが開いています。

2.1.4 アプリケーション層について

アプリケーション層のノードはDMZセキュア・ゾーンにあります。

この層で、APPHOST1とAPPHOST2では、Oracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlが実行されますが、構成はアクティブ/パッシブです。管理サーバーは手動でフェイルオーバーできます(第13.5項「APPHOST2への管理サーバーの手動フェイルオーバー」を参照)。その一方で、管理コンソールをCFC/CRSで構成し、別のハードウェア・クラスタで自動フェイルオーバーすることもできます(このアーキテクチャでは示されていません)。

Oracle Business Intelligence Cluster Controller、Oracle BI SchedulerおよびOracle Essbase Serverシステム・コンポーネントはアクティブ/パッシブ構成でAPPHOST1およびAPPHOST2上で実行されます。その他のOracle Business Intelligenceシステム・コンポーネントであるOracle BI Server、Oracle BI JavaHost、およびOracle BI Presentation Servicesはアクティブ/アクティブ構成でAPPHOST1およびAPPHOST2で実行されます。すべてのシステム・コンポーネントはOPMNによって管理されており、管理対象サーバーでは実行されません。

Oracle Real-Time Decisions、Oracle BI PublisherおよびOracle BI Presentation Services Plug-in(Oracle BI Enterprise Edition Analyticsアプリケーションとも呼ばれる)などのOracle Business Intelligence Javaコンポーネントは、APPHOST1およびAPPHOST2上の2つの管理対象サーバーで実行されます。Oracle Web Services Manager(Oracle WSM)は、EDGトポロジでWebサービスを管理し、保護するためのポリシー・フレームワークを提供するもう1つのJavaコンポーネントです。WSMポリシー・マネージャはAPPHOST1およびAPPHOST2の2つの管理対象サーバーでアクティブ/アクティブ構成で実行されます。

リリース11.1.1.7から、Oracle Hyperion Smart View for Office(Smart View)は、Microsoft Office製品からOracle Business IntelligenceおよびEnterprise Performance Managementコンテンツにアクセスして統合するための包括的ツールとして、Oracle BI Add-in for Microsoft Officeを置き換えます。Smart Viewは、Oracle Business IntelligenceおよびOracle Enterprise Performance Management用に設計された共通のMicrosoft Officeインタフェースを提供します。

2.1.5 データ層について

データ層のノードは、最もセキュアなネットワーク・ゾーン(イントラネット)に配置されます。

この層では、Oracle RACデータベースは、CUSTDBHOST1とCUSTDBHOST2のノードで実行されます。このデータベースには、Oracle Business Intelligenceコンポーネントが必要とするスキーマが含まれます。アプリケーション層で実行されるOracle Business Intelligenceコンポーネントはこのデータベースにアクセスします。

データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(一般的には1521)が開かれている必要があります。また、IDM EDGのLDAP記憶域にアクセスするトラフィックに対して、LDAPポート(一般的に、389と636)が開いている必要があります。

2.1.6 通信のユニキャスト要件について

MyBICompanyトポロジにあるノードはユニキャストを使用して通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。

ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。

クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。

ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。

ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。

- WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。

- 個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプの上書きはできません。

- メッセージ・モードを変更(マルチキャストとユニキャストとの間における切替え)するには、クラスタ全体を停止してから再起動する必要があります。

- マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。これは、クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。

- クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。

- JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。

2.2 Linuxでのエンタープライズ・デプロイメントのハードウェア要件

エンタープライズ・デプロイメントをインストールして構成する前に、Oracle Technology Network (OTN)でOracle Fusion Middlewareのシステム要件と仕様に関するドキュメントを確認し、インストールする製品の最小インストール要件を満たす環境であることを確認します。

さらに、表2-1では、このガイドで説明されているエンタープライズ・デプロイメントの標準的なハードウェア要件でLinuxオペレーティング・システムに関するものを示しています。

適切な容量計画を実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。

表2-1 標準ハードウェア要件

サーバー

ディスク

メモリー

TMPディレクトリ

スワップ

データベース

nXm

n: ディスクの台数(台数は4台以上で、1台のディスクはストライプ)

m: ディスクの容量(30GB以上)

6～8GB

デフォルト

デフォルト

WEBHOSTn

10GB

4GB

デフォルト

デフォルト

APPHOSTn

20GBまたはそれを超える値

8GB

デフォルト

デフォルト

2.3 インストールするソフトウェア・コンポーネントの識別

表2-2に、このガイドの手順を開始する前に入手しておく必要のあるOracleソフトウェアを示します。

Oracle Fusion Middlewareソフトウェアのダウンロードの詳細は、Oracle Technology Network (OTN)のOracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルを参照してください。

表2-2 コンポーネントおよびインストール・ソース

コンポーネント

詳細

Oracle Database 11gまたは12c

Oracle Database(11gシリーズの場合は11.1.0.7以降)

Repository Creation Utility(RCU)

Oracle Fusion Middleware Repository Creation Utility 11g(11.1.1.9.0)

Oracle WebLogic Server(WLS)

Oracle WebLogic Server (10.3.6)

Oracle HTTP Server

Oracle Fusion Middleware WebTier and Utilities 11g(11.1.1.9.0)

Oracle Business Intelligence

Oracle Business Intelligence Enterprise Edition 11gパッチ(11.1.1.9.0)

Oracle Access Manager 10g Webゲート

または

Oracle Access Manager 11g Webゲート

Oracle Access Manager 10g Webゲート(10.1.4.3.0)、使用するプラットフォームに対応したOAM OHS 11g Webゲート

Oracle Access Manager 11g Webゲート(11.1.1.5.0)、使用するプラットフォームに対応したOAM OHS 11g Webゲート

Oracle Virtual Directory(OVD)

Oracle Identity Management 11g(11.1.1.5.0)

2.4 資格証明ストアとポリシー・ストアとしてのLDAPについて

Oracle Fusion Middlewareでは、WebLogicドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、XMLファイルまたは様々なタイプのLDAPプロバイダに基づいてストアを使用できます。ドメインでLDAPストアを使用する場合は、すべてのポリシー・データと資格証明データが、一元化されたストアで保持および管理されます。ただし、XMLポリシー・ストアを使用すると、管理対象サーバー上で行われる変更は、管理サーバーに伝播されません(両方のサーバーが同じドメイン・ホームを使用していない場合)。

Oracle Business Intelligenceエンタープライズ・デプロイメント・トポロジでは、第4.3項「各種ディレクトリの推奨場所について」の記載のとおり、管理サーバーおよび管理対象サーバー用に異なるドメイン・ホームが使用されています。その結果、整合性と一貫性を保持するために、Oracle Business Intelligenceエンタープライズ・デプロイメント環境では、資格証明ストアとポリシー・ストアとしてLDAPストアを使用する必要があります。LDAPストアを資格証明ストアおよびポリシー・ストアとして使用するようにOracle Business Intelligenceエンタープライズ・デプロイメントを構成するには、第12.1項「資格証明ストアとポリシー・ストアの構成」の手順に従います。

2.5 クロックの同期

クラスタに参加しているすべてのサーバーのクロックは、ジョブやアダプタが適切に機能できるように1秒以内の誤差で同期される必要があります。これを実現するには、ネットワーク・タイム・サーバーを1つ使用して、各サーバーがそのネットワーク・タイム・サーバーを参照するようにします。

ネットワーク・タイム・サーバーを参照させる手順は、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムのドキュメントを参照してください。

2.6 参照用トポロジのインストールおよび構成のロード・マップ

図2-3では、Oracle Business Intelligenceエンタープライズ・デプロイメント・プロセスの各手順が説明されています。この表では、処理における各ステップの詳細について、その参照先も示します。

図2-3 Oracle Business Intelligenceエンタープライズ・デプロイメント・プロセスの手順

手順

説明

詳細

エンタープライズ・デプロイメント用のネットワークの準備

仮想サーバー名、IP、仮想IPSなどの概念を理解し、仮想ホスト名を定義してロード・バランサを構成します。

第3章「エンタープライズ・デプロイメント用のネットワークの準備」

エンタープライズ・デプロイメント用のファイル・システムの準備

ディレクトリとディレクトリ環境変数の用語を確認し、共有記憶域を構成します。

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」

エンタープライズ・デプロイメント用のデータベースの準備

データベース要件の確認、データベース・サービスの作成、Oracle RACデータベースへのOracle Business Intelligenceスキーマのロードおよびデータベースのバックアップを行います。

第5章「エンタープライズ・デプロイメント用のデータベースの準備」

エンタープライズ・デプロイメント用のソフトウェアのインストール

Oracle HTTP Server、Oracle WebLogic ServerおよびOracle Fusion Middlewareをインストールします。

第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」

エンタープライズ・デプロイメント用のWeb層の構成

Oracle Web層とOracle WebLogic Domainとの関連付け、ロード・バランサの構成および仮想ホスト名の構成を行います。

第7章「エンタープライズ・デプロイメント用のWeb層の構成」

管理サーバーと最初の管理対象サーバーが含まれたドメインの作成

Oracle Business Intelligence Configuration Assistantを実行し、ドメインを作成して、構成後タスクと検証タスクを実行します。

第8章「管理サーバーと最初の管理対象サーバーが含まれたドメインの作成」

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

BIシステムのスケーリングやシステム・コンポーネントのスケーリング、シングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成、さらに高可用性の追加構成の実行など、APPHOST2でOracle Business Intelligenceをスケール・アウトしてドメインを拡張します。

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

ノード・マネージャの設定

ホスト名検証を有効化し、ノード・マネージャを起動し、カスタム・キーストアを使用してWebLogic Serverを構成することで、ノード・マネージャを設定します。

第10章「エンタープライズ・デプロイメント用のノード・マネージャの設定」

サーバー移行の構成

bi_server1とbi_server2の管理対象サーバーにサーバー移行を構成します。bi_server1管理対象サーバーは障害発生時にAPPHOST2で再起動するように構成されます。bi_server2管理対象サーバーは障害発生時にAPPHOST1で再起動するように構成されます。

第11章「エンタープライズ・デプロイメント用のサーバー移行の構成」

Oracle Identity Managementとの統合

資格証明ストアおよびポリシー・ストアを構成し、Oracle Access Manager 10gまたは11gと統合して、Identity Managementの構成をバックアップします。

第12章「エンタープライズ・デプロイメントとOracle Identity Managementの統合」

エンタープライズ・デプロイメントの管理

Oracle Business Intelligenceの起動と停止、エンタープライズ・デプロイメントの監視、スケーリングおよびパッチ適用、バックアップとリカバリの実行、さらにトラブルシューティング情報の確認について学習します。

第13章「エンタープライズ・デプロイメントの管理」

3 エンタープライズ・デプロイメント用のネットワークの準備

この章では、Oracle Business Intelligenceエンタープライズ・トポロジで必要なネットワーク環境の事前構成について説明します。この章を使用して、仮想サーバー名、ロード・バランサ、IPと仮想IP、ファイアウォールおよびポートの構成を計画してください。

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

- 第3.1項「エンタープライズ・デプロイメント用のネットワークの準備の概要」

- 第3.2項「トポロジで使用する仮想サーバー名について」

- 第3.3項「ロード・バランサの構成」

- 第3.4項「IPおよび仮想IPについて」

- 第3.5項「ファイアウォールとポートについて」

3.1 エンタープライズ・デプロイメント用のネットワークの準備の概要

様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらの仮想サーバーは、実行されているサービスに適切な実際のホストおよびポートに対して構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

Oracle Business Intelligenceを実行する計画のあるすべてのコンピュータで、完全修飾ドメイン名を使用してクラスタのプライマリ・ホスト・コンピュータにアクセス(ping)できることを確認する必要があります。インストールが成功するには、インストールをスケール・アウトするすべてのコンピュータが、クラスタのプライマリ・ホスト上の管理サーバーとの双方向通信をサポートできる必要があります。

3.2 トポロジで使用する仮想サーバー名について

BIエンタープライズ・トポロジでは、次の仮想サーバー名を使用します。

- bi.mycompany.com

- admin.mycompany.com

- biinternal.mycompany.com

仮想サーバー名がIPアドレスと関連付けられており、DNSの一部になっていることを確認してください。Oracle Fusion Middlewareを実行するノードは、これらの仮想サーバー名を解決できる必要があります。

さらに、仮想IPアドレスは、物理ホストのIPアドレスと同じサブネット上に存在する必要があります。

第3.3項「ロード・バランサの構成」の手順に従って、ロード・バランサで仮想サーバー名を定義します。

3.2.1 bi.mycompany.com

bi.mycompany.comは、ランタイムOracle Business IntelligenceコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。SSLへのトラフィックが構成されます。クライアントは、bi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

3.2.2 admin.mycompany.com

admin.mycompany.comは、Oracle WebLogic Server管理サーバー・コンソールやOracle Enterprise Managerなどの管理サービスに転送されるすべての内部HTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。

クライアントからの入力トラフィックは、SSL対応ではありません。クライアントはadmin.mycompany.com:80のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。この仮想サーバーは、ロード・バランサ上に定義されます。

3.2.3 biinternal.mycompany.com

biinternal.mycompany.comは、BIサービスの内部起動に使用される仮想サーバー名です。このURLはインターネットに公開されずに、イントラネットからのみアクセスできます。

クライアントからの入力トラフィックは、SSL対応ではありません。クライアントは、biinternal.mycompany.com:80のアドレスを使用してこのサービスにアクセスし、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。この仮想サーバーは、ロード・バランサ上に定義されます。

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

ロード・バランサ上には、各種のネットワーク・トラフィックおよび監視用に、いくつかの仮想サーバーおよびそれらに関連付けられたポートを構成する必要があります。これらは、実行されているサービスに対する実際のホストおよびポートに対して適切に構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

このエンタープライズ・トポロジは外部のロード・バランサを使用します。第3.2項「トポロジで使用する仮想サーバー名について」で説明する仮想サーバー名を定義して、ロード・バランサを構成します。

第7.5項「仮想ホストの定義」のとおりに仮想ホストを構成すると、仮想ホスト名アドレスへのアクセスが可能になります。アクセスできない場合は、その手順が正しく完了していることを確認します。

ロード・バランサの詳細は、第2.1.3項「Web層ノードについて」を参照してください。

3.3.1 ロード・バランサの要件

このエンタープライズ・トポロジは外部のロード・バランサを使用します。この外部ロード・バランサは次の機能を備えている必要があります。

- 仮想ホスト名を介した実サーバー・プールへのトラフィックのロード・バランシング機能
クライアントは、仮想ホスト名を使用して(実ホスト名を使用するかわりに)、サービスにアクセスします。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。

- ポート変換の構成
仮想ホスト名とポートにおける受信リクエストが、バックエンド・サーバーにある別のポートにダイレクトされるためには、この機能が必要です。

- プールにあるサーバーのポートを監視してサービスの可用性を判定する機能

- 仮想サーバー名とポートを構成する機能
次の要件に注意してください。

- ロード・バランサには複数の仮想サーバーを構成できる必要があります。ロード・バランサでは、仮想サーバーごとに複数のポートにおいてトラフィック管理の構成が可能である必要があります。たとえば、Web層のOracle HTTP Serverの場合、ロード・バランサは、HTTPとHTTPSのトラフィック用の仮想サーバーとポートで構成されている必要があります。

- 仮想サーバー名がIPアドレスと関連付けられており、DNSの一部である必要があります。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。

- ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能

- リソースの監視、ポートの監視、プロセス障害検出
ロード・バランサは、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへの非Oracle Netトラフィックの送信を停止できる必要があります。外部ロード・バランサに障害の自動検出機能がある場合は、それを使用する必要があります。

- フォルト・トレラント・モード
ロード・バランサをフォルト・トレラント・モードに構成することを強くお薦めします。

- 仮想サーバーがコール元のクライアントに即座に戻るよう構成する機能
トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようにロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。この構成は、クライアント・コンピュータのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりもお薦めされます。

- スティッキーなルーティング機能
スティッキーなルーティング機能とは、コンポーネントに対してスティッキーな接続を維持できる機能です。この例には、Cookieベースの永続性やIPベースの永続性などが含まれています。

- SSLアクセラレーション
ロード・バランサには、SSLリクエストをロード・バランサで終了して、同等の非SSLプロトコル(たとえば、HTTPSからHTTP)を使用してトラフィックを実際のバックエンド・サーバーに転送する機能が必要です。一般的にこの機能はSSLアクセラレーションと呼ばれ、このEDGで必要になります。

- TCP接続の接続タイムアウト
TCP接続の接続タイムアウトに大きい値を使用したディレクトリ層に対するロード・バランサの仮想サーバーの構成。この値は、Oracle Access Managerとディレクトリ層の間でトラフィックがない場合に、その予想される最大時間より大きい必要があります。

- クライアントIPアドレスを保持する機能
ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能が必要です。

3.3.2 ロード・バランサの構成手順

この章で説明する手順には概要が含まれています。実行する必要がある実際の手順は、使用するロード・バランサのタイプによって異なります。詳細は、使用するロード・バランサのドキュメントを参照してください。

仮想サーバー名を定義してロード・バランサを構成する手順は次のとおりです。

1. サーバーのプールを作成します。このプールを仮想サーバーに割り当てます。

2. Oracle HTTP Serverホストのアドレスをプールに追加します。次に例を示します。

- WEBHOST1:7777

- WEBHOST2:7777

3. ロード・バランサにbi.mycompany.com:443の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

- この仮想サーバーでは、システムのフロントエンド・アドレスを仮想サーバーのアドレス(たとえば、bi.mycompany.com)として使用します。フロントエンド・アドレスは外部に公開されているホスト名で、システムで使用されるほか、インターネットに公開されます。

- ポート80とポート443でこの仮想サーバーを構成します。ポート80(非SSLプロトコル)へのリクエストはすべてポート443(SSLプロトコル)に転送される必要があります。

- HTTPをプロトコルとして指定します。

- アドレスとポートの変換を有効にします。

- サービスやノードが停止した場合に接続のリセットを有効にします。

- 手順1で作成したプールを仮想サーバーに割り当てます。

- この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

4. ロード・バランサにadmin.mycompany.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

- この仮想サーバーでは、内部管理アドレスを仮想サーバーのアドレス(たとえば、admin.mycompany.com)として使用します。このアドレスは一般的に外部化されません。

- HTTPをプロトコルとして指定します。

- アドレスとポートの変換を有効にします。

- サービスやノードが停止した場合に接続のリセットを有効にします。

- 必要に応じて、この仮想サーバーの/consoleと/emのみへのアクセスを許可するルールを作成します。

- ステップ1で作成したプールを仮想サーバーに割り当てます。

5. ロード・バランサにbiinternal.mycompany.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

- この仮想サーバーでは、内部管理アドレスを仮想サーバーのアドレス(たとえば、biinternal.mycompany.com)として使用します。このアドレスは一般的に外部化されません。

- HTTPをプロトコルとして指定します。

- アドレスとポートの変換を有効にします。

- サービスやノードが停止した場合に接続のリセットを有効にします。

- 手順1で作成したプールを仮想サーバーに割り当てます。

- 必要に応じて、この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

6. Oracle HTTP Serverノードに監視を構成してノードの障害を検出します。

- 「/」のURLコンテキストに定期的にpingを実行するように監視を構成します。

ヒント:

Oracle HTTP Serverのドキュメント・ルートにindex.htmが存在せずにOracle WebLogic Serverで「/」の404エラーが返される場合は、かわりにGET /\n\nを使用してください。

- ping実行間隔については、システムに負荷を与えないように値を指定します。とりあえず5秒で試してみることができます。

- タイムアウト時間については、Oracle Business Intelligenceシステムで予測できる最長レスポンス時間に相当する値を指定します。つまり、HTTPサーバーへのリクエストに必要な最長所要時間より大きな値を指定します。

3.4 IPおよび仮想IPについて

表3-1では、様々な仮想ホストについて説明します。

表3-1 仮想ホスト

仮想IP

VIPのマップ先

説明

VIP1

ADMINVHN

ADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名であり、管理サーバーの手動フェイルオーバーによりフェイルオーバーします。管理サーバーのプロセスが実行されているノード(デフォルトはAPPHOST1)で有効にされます。

VIP2

APPHOST1VHN1

APPHOST1VHN1は、bi_server1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、bi_server1プロセスが実行されているノード(デフォルトはAPPHOST1)で有効化されます。

VIP3

APPHOST2VHN1

APPHOST2VHN1は、bi_server2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、bi_server2プロセスが実行されているノード(デフォルトはAPPHOST2)で有効化されます。

3.4.1 APPHOST1上のADMINVHNの有効化

管理サーバーが1つのホストから別のホストにシームレスにフェイルオーバーできるよう、仮想IPアドレスをリスニングするよう構成する必要があります。障害時には、管理サーバーを仮想IPアドレスとともに1つのホストから別のホストに移行できます。

ただし、管理サーバーが仮想IPアドレスをリスニングするよう構成する前に、管理サーバーを実行しているホスト上のネットワーク・インタフェース・カードの1つが、この仮想IPアドレスをリスニングするよう構成されている必要があります。仮想IPアドレスを有効にする手順は、オペレーティング・システムによって完全に異なります。

APPHOST1上で仮想IPアドレスを有効にする手順は次のとおりです。UNIX環境では、rootユーザーとしてコマンドを実行する必要があります。

1. APPHOST1でifconfigコマンドを実行し、ネットマスクの値を取得します。UNIX環境では、このコマンドをrootユーザーとして実行します。次に例を示します。

[root@APPHOST1 ~] # /sbin/ifconfig
eth0     Link encap:Ethernet  HWaddr 00:11:43:D7:5B:06
inet addr:139.185.140.51  Bcast:139.185.140.255  Mask:255.255.255.0
inet6 addr: fe80::211:43ff:fed7:5b06/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:10626133 errors:0 dropped:0 overruns:0 frame:0
TX packets:10951629 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4036851474 (3.7 GiB)  TX bytes:2770209798 (2.5 GiB)
Base address:0xecc0 Memory:dfae0000-dfb00000

2. APPHOST1でifconfigを使用し、仮想IPアドレスとネットワーク・インタフェース・カードをバインドします。UNIX環境では、このコマンドをrootユーザーとして実行します。ステップ1で取得したネットマスク値を使用します。
ifconfigコマンドの構文および用法は次のとおりです。

/sbin/ifconfig networkCardInterface Virtual_IP_Address netmask netMask

次に例を示します。

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

3. arpingを使用し、ルーティング表を更新します。UNIX環境では、このコマンドをrootユーザーとして実行します。

/sbin/arping -q -U -c 3 -I networkCardInterface Virtual_IP_Address

次に例を示します。

/sbin/arping -q -U -c 3 -I eth0 100.200.140.206

また、APPHOST1およびAPPHOST2上の管理対象サーバーにおけるVIP2およびVIP3の有効化の詳細は、次の項を参照してください。

3.4.2 管理対象サーバーの仮想IPの有効化

BIドメインでは、Oracle Business Intelligenceの管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。これらのホスト名を2つのOracle BIコンピュータ(APPHOST1のVIP2とAPPHOST2のVIP3)にマップしてVIPを有効にする必要があります。またこれらのVIPが、トポロジで使用するネットワーク・システムの仮想ホスト名に(DNSサーバーまたはホスト解決によって)正しく解決されなければなりません。

管理対象サーバーで仮想IPアドレスをリスニングするよう構成する前に、管理対象サーバーを実行しているホスト上のネットワーク・インタフェース・カードのいずれかを、この仮想IPアドレスをリスニングするように構成する必要があります。

適切な仮想IPアドレス(APPHOST1のVIP2およびAPPHOST2のVIP3)が有効になるよう、各ホストで1回ずつ次の手順を実行します。UNIX環境では、rootユーザーとしてコマンドを実行する必要があります。

1. 適切なホスト(APPHOST1でまたはAPPHOST2)でifconfigコマンドを実行し、ネットマスクの値を取得します。UNIX環境では、このコマンドをrootユーザーとして実行します。たとえば、APPHOST1で次を行います:

[root@APPHOST1 ~] # /sbin/ifconfig
eth0     Link encap:Ethernet  HWaddr 00:11:43:D7:5B:06
inet addr:139.185.140.51  Bcast:139.185.140.255  Mask:255.255.255.0
inet6 addr: fe80::211:43ff:fed7:5b06/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:10626133 errors:0 dropped:0 overruns:0 frame:0
TX packets:10951629 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4036851474 (3.7 GiB)  TX bytes:2770209798 (2.5 GiB)
Base address:0xecc0 Memory:dfae0000-dfb00000

2. ifconfigを使用し、仮想IPアドレスをネットワーク・インタフェース・カードにバインドします。UNIX環境では、このコマンドをrootユーザーとして実行します。ステップ1で取得したネットマスク値を使用します。
ifconfigコマンドの構文および用法は次のとおりです。

/sbin/ifconfig networkCardInterface Virtual_IP_Address netmask netMask

次に例を示します。

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

3. arpingを使用し、ルーティング表を更新します。UNIX環境では、このコマンドをrootユーザーとして実行します。

/sbin/arping -q -U -c 3 -I networkCardInterface Virtual_IP_Address

次に例を示します。

/sbin/arping -q -U -c 3 -I eth0 100.200.140.206

APPHOST1の管理サーバーでのVIP1の有効化の詳細は、第3.4.1項「APPHOST1上のADMINVHNの有効化」を参照してください。

3.5 ファイアウォールとポートについて

多くのOracle Fusion Middlewareコンポーネントおよびサービスはポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにする必要があります。

ほとんどのポート番号はインストール中に割り当てられます。

表3-2には、Oracle Business Intelligenceトポロジで使用されるポートの一覧が記載されているほか、トポロジのファイアウォール上で開く必要のあるポートも記載されています。

ファイアウォール表記法:

- FW0は外側のファイアウォールを示します。

- FW1は、Web層とアプリケーション層との間におけるファイアウォールを示します。

- FW2は、アプリケーション層とデータ層との間におけるファイアウォールを示します。

表3-2 使用されるポート

タイプ

ファイアウォール

ポートとポート範囲

プロトコル/アプリケーション

インバウンド/アウトバウンド

その他の考慮事項とタイムアウトのガイドライン

ブラウザによるリクエスト

FW0

80

HTTP/ロード・バランサ

インバウンド

タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

ブラウザによるリクエスト

FW0

443

HTTPS/ロード・バランサ

インバウンド

タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

Oracle HTTP Serverへのロード・バランサ

なし

7777

HTTP

なし

第3.3項「ロード・バランサの構成」を参照してください。

管理サーバーへのOracle HTTP Serverの登録

FW1

7001

HTTP/t3

インバウンド

タイムアウトを短い時間(5から10秒)に設定します。

管理サーバーによるOracle HTTP Serverの管理

FW1

OPMNポート(6701)およびOracle HTTP Server管理ポート(7779)

それぞれTCPとHTTP

アウトバウンド

タイムアウトを短い時間(5から10秒)に設定します。

BI Serverのアクセス

FW1

9704

HTTP/bi_servern

インバウンド

タイムアウトは、BIによって使用されるプロセス・モデルのタイプによって異なります。

BIクラスタ・メンバー間の通信

なし

9704

TCP/IPユニキャスト

なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

WebLogic Serverクラスタ内におけるセッション・レプリケーション

なし

なし

なし

なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

Oracle WebLogic Server管理コンソールのアクセス

FW1

7001

HTTP/管理サーバーとEnterprise Manager

両方

管理コンソールへのアクセスのタイプ(アプリケーション層のクライアントから管理コンソールを使用する予定があるか、またはアプリケーション層の外部のクライアントから使用する予定があるか)に基づいてこのタイムアウト時間をチューニングしてください。

ノード・マネージャ

なし

5556

TCP/IP

なし

なし

実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールとポートの構成に関する項を参照してください。

アクセス・サーバーのアクセス

FW1

6021

OAP

インバウンド

実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールとポートの構成に関する項を参照してください。

アイデンティティ・サーバーのアクセス

FW1

6022

OAP

インバウンド

なし

BI ServerおよびBI PublisherのJDBCデータ・ソース用のデータベース・アクセス

FW1

クライアントがリスナーに接続するためのリスニング・ポート

SQL*Net

両方

タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのデータベース・コンテキストによって異なります。

データベースのアクセス

FW2

1521

SQL*Net

両方

タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのデータベース・コンテキストによって異なります。

Oracle Internet Directoryのアクセス

FW2

389

LDAP

インバウンド

ロード・バランサに基づいてディレクトリ・サーバーのパラメータを調整します。その逆は行わないでください。

Oracle Internet Directoryのアクセス

FW2

636

LDAP SSL

インバウンド

ロード・バランサに基づいてディレクトリ・サーバーのパラメータを調整します。その逆は行わないでください。

OWSM用JOC

なし

9991

TCP/IP

なし

なし

注意:

ファイアウォール・ポートはTCP/IPポートの定義によって異なります。

4 エンタープライズ・デプロイメント用のファイル・システムの準備

この章では、Oracle Business Intelligenceエンタープライズ・デプロイメント用のファイル・システムを準備する方法について説明します。推奨されるディレクトリ構造とその場所に関する情報を示し、共有記憶域の構成手順も説明します。

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

- 第4.1項「エンタープライズ・デプロイメント用のファイル・システムの準備の概要」

- 第4.2項「ディレクトリとディレクトリ変数の用語」

- 第4.3項「各種ディレクトリの推奨場所について」

- 第4.4項「共有記憶域の構成」

4.1 エンタープライズ・デプロイメント用のファイル・システムの準備の概要

ファイル・システムは、エンタープライズ・デプロイメントがわかりやすくなり、構成および管理が容易になるように設定することが重要です。この章の情報に従ってファイル・システムを設定することをお薦めします。この章で定義されている用語は、このガイド内のダイアグラムおよび手順で使用されます。

この章を参照情報として使用すると、インストールおよび構成手順で使用されているディレクトリ変数について理解できます。その他のディレクトリ・レイアウトも可能であり、サポートされていますが、このマニュアルで採用するモデルは、可用性を最大化するために選択されており、コンポーネントの最良の独立性と構成の対称性の両方を実現し、バックアップおよび災害からのリカバリを容易にします。ドキュメントの残りの部分では、このディレクトリ構造およびディレクトリ用語を使用します。

4.2 ディレクトリとディレクトリ変数の用語

この項では、Oracle Business Intelligenceエンタープライズ・デプロイメントを構成するためにこのガイドで使用するディレクトリ変数について説明します。このガイドでは、インストールして構成するディレクトリを次のディレクトリ変数を使用して説明しています。

- ORACLE_BASE: この環境変数と関連ディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指しています。

- MW_HOME: この変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが配置されている場所を指しています。

- WL_HOME: この変数および関連ディレクトリ・パスには、Oracle WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。

- ORACLE_HOME: この環境変数および関連ディレクトリ・パスは、Oracle Business Intelligenceを実行するために必要なバイナリがインストールされているディレクトリを指しています。

- ORACLE_COMMON_HOME: この変数および関連ディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが含まれるOracleホームを指しています。

- DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指しています。同じノードに存在している場合でも、異なるWebLogic Serverでは異なるドメイン・ディレクトリを使用できます。

- ORACLE_INSTANCE: Oracleインスタンス・ディレクトリには、1つ以上のOracleシステム・コンポーネントの構成ファイル、ログ・ファイル、一時ファイルがあります。コンポーネントの例には、Oracle BI Server、Oracle BI Presentation Services、Oracle HTTP Serverなどがあります。

- JAVA_HOME: この環境変数および関連するディレクトリ・パスは、JRockitがインストールされている場所を指しています。

- ASERVER_HOME: この変数および関連するディレクトリ・パスは、ドメイン構成の主要な場所を指しています。

- MSERVER_HOME: この変数および関連ディレクトリ・パスは、管理対象サーバーの起動と停止に使用されるドメイン構成を指しています。

- WEBGATE_ORACLE_HOME: この変数および関連するディレクトリ・パスは、Webゲート・インストールの場所を指しています。

ヒント:

この項で説明している場所には、ショートカットとして環境変数を使用し、ディレクトリに簡単に移動できます。たとえば、Linuxでは$ORACLE_BASEという環境変数を使用して、/u01/app/oracle(つまり、推奨されるORACLE_BASEの場所)を参照できます。Windowsでは、%ORACLE_BASE%とWindowsに固有のコマンドを使用できます。

4.3 各種ディレクトリの推奨場所について

次の各項では、エンタープライズ・デプロイメント・トポロジで共有記憶域を使用するための基本的な推奨事項について説明します。

- 第4.3.1項「バイナリ(Oracleホーム)・ディレクトリ用の共有記憶域に関する推奨事項」

- 第4.3.2項「ドメイン構成ファイル用の共有記憶域に関する推奨事項」

- 第4.3.3項「JMSファイル・ストアとJTAトランザクション・ログ用の共有記憶域に関する推奨事項」

- 第4.3.4項「ディレクトリの推奨場所」

- 第4.3.5項「ディレクトリ構造と構成」

4.3.1 バイナリ(Oracleホーム)ディレクトリに対する共有記憶域の推奨事項

次の各項では、Oracle Fusion Middleware Oracleホーム・ディレクトリで共有記憶域を使用するためのガイドラインについて説明します。

- 第4.3.1.1項「バイナリ(Oracleホーム)・ディレクトリについて」

- 第4.3.1.2項「複数のドメインによる単一のOracleホームの共有について」

- 第4.3.1.3項「冗長バイナリ(Oracleホーム)・ディレクトリの使用について」

4.3.1.1 バイナリ(Oracleホーム)ディレクトリについて

Oracle Fusion Middleware製品をインストールするときには、製品をOracleホームにインストールします。Oracleホームにインストールされたバイナリ・ファイルは読取り専用であり、Oracleホームにパッチが適用されるか、新しいバージョンにアップグレードされるまで変更されません。

通常の本番環境では、Oracleホームはドメイン構成ファイルとは別の場所に保存されます。その場所は、Oracle Fusion Middleware構成アシスタントを使用して作成します。

Oracle Fusion MiddlewareインストールのMiddlewareホームには、Oracle WebLogic Serverのバイナリ・ファイル、Oracle Fusion Middlewareインフラストラクチャ・ファイルおよびOracle Fusion Middleware製品固有のディレクトリが含まれます。

Oracle Fusion Middleware Oracleホームの構造と内容の詳細は、Oracle Fusion Middlewareコンセプトを参照してください。

4.3.1.2 複数ドメインでの単一Oracleホームの共有について

Oracle Fusion Middlewareでは、1つのOracleホームから複数のOracle WebLogic Serverドメインを構成できます。この機能により、共有ボリューム上の1つの場所にOracleホームをインストールしたり、複数のホストをインストールするためにOracleホストを再利用したりすることもできます。

Oracleホームが異なるホスト上の複数のサーバーで共有されている場合、いくつかの実施するべきベスト・プラクティスがあります。特に、各ホスト上のOracleインベントリ(oraInventory)が一貫性とパッチの適用のために更新されていることを確認してください。

ホストのoraInventoryを更新して、共有記憶域内のOracleホームに追加するには、次のコマンドを入力します。

ORACLE_HOME/oui/bin/attachHome.sh

oraInventoryの詳細は、Oracle Universal Installerコンセプト・ガイドのOracle Universal Installerインベントリに関する項を参照してください。

Middlewareホームの一覧を更新してMW_HOMEを追加または削除するには、user_home/bea/beahomelistファイルを編集します。

4.3.1.3 冗長なバイナリ(Oracleホーム)ディレクトリの使用について

可用性が最大になるように、共有記憶域上でバイナリの冗長インストールを使用することをお薦めします。

このモデルでは、2つの異なる共有ボリューム上に、Oracle Fusion Middlewareソフトウェアに対する2つの同じOracleホームをインストールします。まず、Oracleホームの1つをサーバーの1セットにマウントし、もう一方を残りのサーバーにマウントします。いずれのOracleホームも同じマウント・ポイントを持つため、サーバーがどのOracleホームを使用しているかにかかわらず、Oracleホームは常に同じパスを持ちます。

1つのOracleホームが壊れたり使用できなくなった場合は、サーバーの半分のみが影響を受けます。さらに保護を強化するために、これらのボリュームでディスクをミラー化することをお薦めします。

共有記憶域上で別個のボリュームが使用できない場合は、同じボリューム内の異なるディレクトリを使用して別個のボリュームをシミュレートし、これらをホスト側の同じマウント位置にマウントすることをお薦めします。この方法によって複数ボリュームが提供するような保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護は可能になります。

4.3.2 ドメイン構成ファイルに対する共有記憶域の推奨事項

次の各項では、エンタープライズ・デプロイメントでOracle Fusion Middleware製品を構成するときに作成したOracle WebLogic Serverドメイン構成ファイルに対して共有記憶域を使用する際のガイドラインについて説明します。

- 第4.3.2.1項「Oracle WebLogic Server管理サーバーおよび管理対象サーバーのドメイン構成ファイルについて」

- 第4.3.2.2項「管理サーバーおよび管理対象サーバーのドメイン構成ファイル用の共有記憶域の要件」

4.3.2.1 Oracle WebLogic Server管理および管理対象サーバー・ドメイン構成ファイルについて

Oracle Fusion Middleware製品を構成すると、Oracle WebLogic Serverドメインが作成または拡張されます。各Oracle WebLogic Serverドメインは、1つの管理サーバーおよび1つ以上の管理対象サーバーで構成されます。

ドメインの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解』を参照してください。

エンタープライズ・デプロイメントでは、ドメインの管理対象サーバーがアクティブ/アクティブ型の高可用性のために構成される場合があることを理解してください。ただし、管理サーバーではできません。管理サーバーはシングルトン・サービスです。つまり、一度に1つのホストでのみアクティブにできます。

4.3.2.2 管理サーバーと管理対象サーバーのドメイン構成ファイルの共有記憶域要件

ドメイン構成ファイルのコピーを2つ作成することをお薦めします。

- 1つは管理サーバーの構成ファイル用のコピーです。
このディレクトリは共有記憶域上にインストールし、管理サーバーを実行しているホストに排他的にマウントします。

ホストで障害が発生した場合に、このディレクトリを別のホストにマウントし、そのホストで管理サーバーを起動できます。

- もう一方のコピーは管理対象サーバーの構成ファイル用です。
管理対象サーバーのドメイン・ディレクトリは、ローカルの記憶域にも共有記憶域にも配置できます。管理対象サーバーがドメイン・ディレクトリを共有すると、スケール・アウト手順が容易になります。ただし、管理対象サーバーの構成ファイルを共有すると、パフォーマンスに影響する可能性もあります。

よって、使用するデプロイメントは、ストレージ・システムの要件があればそれに適合させる必要があります。ストレージ・システムには、複数のマシンで同じ共有ボリュームのマウントが容易になるような構成オプションを提供するものもあります。

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとに各ノードのローカル・ドメイン・ディレクトリが使用されると想定しています。

4.3.3 JMSファイル・ストアとJTAトランザクション・ログ用の共有記憶域に関する推奨事項

サーバーの障害や移行の場合にリカバリで複数のホストを利用可能にするには、JMSファイル・ストアとJTAトランザクション・ログは共有記憶域に配置する必要があります。

ファイル・ストア内のJMSおよびJTA情報の使用方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成のWebLogic永続ストアの使用方法に関する項を参照してください。

4.3.4 ディレクトリの推奨場所

この項では、推奨されるディレクトリについて説明します。共有記憶域の場所が直接指定されている場合は必ず、そのディレクトリでは共有記憶域が必要とされることを意味します。ローカル・ディスクが使用されたり共有記憶域がオプションの場合、マウント指定では「共有記憶域を使用している場合」の語句で修飾されます。共有記憶域の場所は例であり、指定のマウント・ポイントが使用されるかぎり、これを変更できます。ただし、共有記憶域デバイスでは整合性と単純化のためこの構造をお薦めします。

ORACLE_BASE:

推奨ディレクトリ= /u01/app/oracle

管理サーバー・ドメイン・ディレクトリのドメイン・ディレクトリ:

ORACLE_BASE/admin/domain_name/aserver/domain_name

- システムのマウント・ポイント: ORACLE_BASE/admin/domain_name/aserver

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/aserver

- マウント元: このディレクトリをマウントする必要があるのは、管理サーバーが稼働しているノードのみです。管理サーバーが別のノードに再配置(フェイルオーバー)されたら、そのノードが同じマウント・ポイントで同じ共有記憶域をマウントします。トポロジ内の残りのノードがこの場所をマウントする必要はありません。

管理対象サーバー・ドメイン・ディレクトリのドメイン・ディレクトリ:

ORACLE_BASE/admin/domain_name/mserver/domain_name

- 共有ディスクを使用している場合、システムのマウント・ポイントは、ORACLE_BASE/admin/domain_name/Noden/mserver/にマウントされたORACLE_BASE/admin/domain_name/mserverになります(各ノードで、管理対象サーバー用に異なるドメイン・ディレクトリが使用されます)。

注意:

この手順は共有記憶域によって異なります。前述の箇条書きの例はNASに特有ですが、他の記憶域タイプでは別のタイプのマッピングによりこの冗長性が実現される場合があります。

JMSファイルベース・ストアとTlogs用の場所:

ORACLE_BASE/admin/domain_name/cluster_name/jms

ORACLE_BASE/admin/domain_name/cluster_name/tlogs

- マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name

- マウント元: Oracle BIコンポーネントが稼働するすべてのノードでは、別のノードへのサーバー移行が発生したときにトランザクション・ログおよびJMSストアを使用できるように、この共有記憶域の場所をマウントする必要があります。

管理サーバーのアプリケーション・ディレクトリの場所:

ORACLE_BASE/admin/domain_name/aserver/applications

- マウント・ポイント: ORACLE_BASE/admin/domain_name/aserver

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/aserver

- マウント元: このディレクトリをマウントする必要があるのは、管理サーバーが稼働しているノードのみです。管理サーバーが別のノードに再配置(フェイルオーバー)されたら、そのノードが同じマウント・ポイントで同じ共有記憶域をマウントします。トポロジ内の残りのノードがこの場所をマウントする必要はありません。

管理対象サーバーのアプリケーション・ディレクトリの場所:

ORACLE_BASE/admin/domain_name/mserver/applications

注意:

このディレクトリは、Oracle Business Intelligenceのエンタープライズ・デプロイメントのコンテキストではローカルになります。

MW_HOME(アプリケーション層):

推奨ディレクトリ = ORACLE_BASE/product/fmw

- マウント・ポイント: ORACLE_BASE/product/fmw

- 共有記憶域の場所: ORACLE_BASE/product/fmw(VOL1およびVOL2)

- マウント元: 少なくとも半分のノードで1つのインストールを使用し、残りの半分で他方のインストールを使用するように、ノードではVOL1とVOL2を互換的にマウントします。Oracle Business Intelligenceのエンタープライズ・デプロイメントでは、APPHOST1はVOL1をマウントし、APPHOST2はVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域の2つの異なるディレクトリをかわりにマウントします(つまり、たとえばAPPHOST1ではORACLE_BASE/product/fmw1、APPHOST2ではORACLE_BASE/product/fmw2を、それぞれ共有記憶域の場所として使用します)。

注意:

共有記憶域に利用できるボリュームが1つしかない場合に、誤ってファイルを削除しないように、あるいはパッチを適用できるように、別のディレクトリを使用して冗長に構成することができます。2つのMW_HOMEを使用可能にする場合は、少なくとも1つはORACLE_BASE/product/fmw1、もう一方はORACLE_BASE/product/fmw2とします。これらのMW_HOMEは、すべてのノードで同じマウント・ポイントにマウントされます。

MW_HOME(Web層):

推奨ディレクトリ = ORACLE_BASE/product/fmw/web

- マウント・ポイント: ORACLE_BASE/product/fmw

- 共有記憶域の場所: ORACLE_BASE/product/fmw(VOL1およびVOL2)

- マウント元: 共有記憶域へのインストールの場合、少なくとも半分のノードで1つのインストールを使用し、残りの半分で他方のインストールを使用するように、ノードではVOL1とVOL2を互換的にマウントします。BIのEDGでは、WEBHOST1はVOL1をマウントし、WEBHOST2はVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域の2つの推奨ディレクトリをかわりにマウントします(つまり、たとえば共有記憶域の場所としてWEBHOST1ではORACLE_BASE/product/fmw1/、WEBHOST2ではORACLE_BASE/product/fmw2/が使用されます)。

注意:

Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用する場合は、層を横断する記憶域デバイスへのアクセスには、適切なセキュリティ制限をかけることを検討してください。

WL_HOME:

推奨ディレクトリ = MW_HOME/wlserver_10.3

ORACLE_HOME:

推奨ディレクトリ = MW_HOME/Oracle_BI1

ORACLE_COMMON_HOME:

推奨ディレクトリ = MW_HOME/oracle_common

ORACLE_INSTANCE:

推奨ディレクトリ = ORACLE_BASE/admin/instance_name

- 共有ディスクを使用している場合、システムのマウント・ポイントは、ORACLE_BASE/admin/instance_name (VOL1)にマウントされたORACLE_BASE/admin/instance_nameになります。

注意:

(VOL1)はオプションです。また、(VOL2)も使用できます。

Oracle BI Presentation Catalogの場所:

推奨ディレクトリ = ORACLE_BASE/admin/domain_name/cluster_name/catalog/customCatalog(customCatalogはカテゴリ名の例)

- マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name

- マウント元: クラスタ内のプレゼンテーション・サービスのインスタンスを含むすべてのノードではこの場所をマウントします(すべてのノードには読取りと書込みの権限が必要です)。

Oracle BI Presentation Catalogは、Fusion Middleware Controlではプレゼンテーション・サービス・リポジトリということを留意してください。

リポジトリ公開ディレクトリの場所:

推奨ディレクトリ = ORACLE_BASE/admin/domain_name/cluster_name/ClusterRPD

- マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name

- マウント元: クラスタ内のBIサーバーのインスタンスを含むすべてのノードではこの場所をマウントします。マスターBIサーバーは、このディレクトリに対する読取りおよび書込み権限が必要です。その他のすべてのBIサーバーには読取り権限が必要です。

リポジトリ公開ディレクトリは、Fusion Middleware ControlではBIサーバー・リポジトリの共有の場所であることを留意してください。

Essbaseエージェント共有フォルダ・パスの場所:

推奨ディレクトリ = ORACLE_BASE/admin/domain_name/cluster_name/Essbase/essbaseserver1

- マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name

- マウント元: クラスタ内のEssbaseエージェントのインスタンスを含むすべてのノードではこの場所をマウントします(すべてのノードには読取りと書込みの権限が必要です)。

BIサーバーのグローバル・キャッシュの場所:

推奨ディレクトリ = ORACLE_BASE/admin/domain_name/cluster_name/GlobalCache

- マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name
共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name

マウント元: クラスタ内のBIサーバーのインスタンスを含むすべてのノードではこの場所をマウントします。マスターBIサーバーは、このディレクトリに対する読取りおよび書込み権限が必要です。その他のすべてのBIサーバーには読取り権限が必要です。

BI Publisher構成フォルダの場所:

推奨ディレクトリ = ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/config

- マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name

- マウント元: クラスタ内のBI Publisherのインスタンスを含むすべてのノードでは、この場所を読取りと書込みの権限付きでマウントします。

BI Publisherスケジューラの一時ディレクトリの場所:

推奨ディレクトリ = ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/temp

- マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name

- マウント元: クラスタ内のBI Publisherのインスタンスを含むすべてのノードでは、この場所を読取りと書込みの権限付きでマウントします。

4.3.5 ディレクトリ構造と構成

この項では、推奨されるディレクトリ構造および共有記憶域についてわかりやすく説明するダイアグラムを示します。

図4-1 は推奨ディレクトリ構造について説明しています。

図4-1 Oracle Business IntelligenceのEDGのディレクトリ構造

図4-1のディレクトリ構造には、oracle_commonなど他の必要な内部ディレクトリが示されてないことに注意してください。この構造には、RPD公開ディレクトリ、共有Oracle BI Presentation Catalog、グローバル・キャッシュおよびEssbase共有フォルダのパスなどのアプリケーション構成ファイルに対するディレクトリが示されています。共有ディレクトリの詳細は、第4.4項「共有記憶域の構成」を参照してください。

表4-1は、図4-1で色分けされた様々な要素の意味を説明します。

表4-1 ディレクトリ構造の要素

要素

説明

管理サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体は共有ディスク上に配置されます。

管理対象サーバー・ドメインのディレクトリは、ローカル・ディスクまたは共有ディレクトリに配置できます。管理対象サーバーのドメイン・ディレクトリを複数のコンピュータで共有する場合、それらのコンピュータ全体において同じ共有ディスクの場所をマウントする必要があります。Web層のinstance_nameディレクトリは、ローカル・ディスクまたは共有ディスクに配置できます。

固定名です。

インストール依存名です。

4.4 共有記憶域の構成

次のコマンドを使用して共有記憶域の場所を作成およびマウントすることで、APPHOST1とAPPHOST2では、2つの別のボリュームにあるバイナリ・インストールが同じ場所で参照できるようになります。

注意:

共有記憶域のファイル・システムの作成に使用されるユーザーIDは、これらのファイルに対する読取り、書込みおよび実行権限を持ちます。オペレーティング・システム・グループにおける他のユーザーは、ファイルの読取りや実行は可能ですが、書込み権限はありません。インストールと構成の権限に関する詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストールと構成の権限およびユーザーに関する項を参照してください。

nasfilerは共有記憶域ファイラです。

APPHOST1から:

APPHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/product/fmw
/u01/app/oracle/product/fmw -t nfs

APPHOST2から:

APPHOST2> mount nasfiler:/vol/vol2/u01/app/oracle/product/fmw
/u01/app/oracle/product/fmw -t nfs

使用可能なボリュームが1つのみの場合は、共有記憶域の2つの異なるディレクトリを使用してAPPHOSTサーバーの同じディレクトリにマウントすることで、バイナリ・ファイルの冗長性を実現できます。

APPHOST1から:

APPHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/product/fmw1
/u01/app/oracle/product/fmw -t nfs

APPHOST2から:

APPHOST2> mount nasfiler:/vol/vol2/u01/app/oracle/product/fmw2
/u01/app/oracle/product/fmw -t nfs

次のコマンドは、異なるノード間においてJTAトランザクション・ログを共有する方法を示します。

APPHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/stores/bifoundation_domain/
bi_cluster/tlogs /u01/app/oracle/admin/bifoundation_domain/
bi_cluster/tlogs -t nfs

APHOST2> mount nasfiler:/vol/vol1/u01/app/oracle/stores/bifoundatin_domain/
bi_cluster/tlogs /u01/app/oracle/admin/bifoundation_domain/
bi_cluster/tlogs -t nfs

注意:

共有記憶域には、NASデバイスまたはSANデバイスを使用できます。次は、NASデバイスの記憶域をAPPHOST1から作成する例を示しています。オプションは、具体的な記憶域デバイスに応じて異なる場合があります。

APPHOST1> mount nasfiler:/vol/vol1/fmw11shared ORACLE_BASE/wls -t
nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

使用する環境に適切なオプションについては、ストレージ・ベンダーとコンピュータ管理者と相談してください。

共有ストレージの構成の検証

構成した共有記憶域にテスト・ファイルを作成し、新しくマウントしたディレクトリでファイルの読取りおよび書込みができることを確認します。

例:

$ cd newly mounted directory
$ touch testfile

所有者と権限が正しいことを確認します。

$ ls -l testfile

ファイルを削除します。

$ rm testfile

4.4.1 共有ネットワーク・ファイルがWindows環境でアクセス可能であることの確認

通常Windows環境では、共有記憶域は汎用命名規則(UNC)を使用して指定します。UNCは、Local Area Network(LAN)上のリソースの場所を指定するためのPCにおける形式です。UNCでは、次の形式を使用します。

\\server_name\shared_resource_path_name

また、共有ネットワーク・ファイルにアクセスできるように、Windows環境では名前付きユーザーを使用してOPMNプロセスを実行する必要があります。

名前付きユーザーを使用してOPMNプロセスを実行する手順は次のとおりです。

1. 「サービス」ダイアログを開きます。たとえば、「スタート」→「プログラム」→「管理ツール」→「サービス」の順に選択します。

2. 「OracleProcessManager_instancen」を右クリックし、「プロパティ」を選択します。

3. 「ログオン」タブを選択します。

4. 「アカウント」を選択し、ユーザー名とパスワードを入力します。

5. 「OK」をクリックします。

5 エンタープライズ・デプロイメント用のデータベースの準備

この章では、Oracle Business Intelligenceエンタープライズ・デプロイメントのデータベースを準備する手順について説明します。この手順には、データベースの初期設定、Oracle Business Intelligenceスキーマのロードおよびデータベースのバックアップが含まれます。

重要:

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

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

- 第5.1項「エンタープライズ・デプロイメント用のデータベースの準備の概要」

- 第5.2項「データベース要件について」

- 第5.3項「11.xおよび12cデータベース用のデータベース・サービスの作成」

- 第5.4項「Oracle RACデータベースへのOracle Business Intelligenceスキーマのロード」

- 第5.5項「データベースのバックアップ」

5.1 エンタープライズ・デプロイメント用のデータベースの準備の概要

Oracle Fusion Middlewareコンポーネントを構成する前に、データベースをインストールしてからそこにOracle Business Intelligenceスキーマをロードする必要があります。Oracle Business Intelligenceスキーマは、リポジトリ作成ユーティリティ(RCU)を使用してロードします。

エンタープライズ・トポロジでのデータ層の可用性の向上には、Oracle Real Application Clusters(Oracle RAC)データベースを強くお薦めします。Oracle Business Intelligenceをインストールすると、インストーラによって必要なスキーマを含むデータベースに接続するための情報の入力が求められます。

5.2 データベース要件について

データベースにOracle Business Intelligenceスキーマをロードする前に、そのデータベースが次の各項で説明する要件を満たしていることを確認してください。

- 第5.2.1項「データベース・ホストの要件」

- 第5.2.2項「サポートされているデータベース・バージョン」

- 第5.3項「11.xおよび12cデータベース用のデータベース・サービスの作成」

- 第5.2.3項「推奨データベース・キャラクタ・セット」

5.2.1 データベース・ホストの要件

データ層内のCUSTDBHOST1およびCUSTDBHOST2には、次の要件があります。

- Oracle Clusterware
Linux用11gリリース2 (11.2)については、『Oracle Grid Infrastructureインストレーション・ガイドfor Linux』を参照してください。Linux用12cリリース1 (12.1)については、『Oracle Grid Infrastructureインストレーション・ガイドfor Linux』を参照してください。

- Oracle Real Application Cluster
Linux用11g リリース2(11.2)については、『Oracle Real Application Clustersインストレーション・ガイドfor Linux and UNIX Systems』を参照してください。12c リリース1(12.1)については、『Oracle Real Application Clustersインストレーション・ガイドfor Linux and UNIX』を参照してください。

- 自動ストレージ管理 (オプション)
ASMでは、ノードが全体としてインストールされます。OracleデータベースのOracleホームとは別のOracleホームにインストールすることをお薦めします。このオプションは、runInstallerの実行時に選択できます。「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択し、ASM用に個別のOracleホームを作成します。

5.2.2 サポートされているデータベース・バージョン

Oracle Business Intelligenceには、サポートされているデータベースとスキーマが存在する必要があります。

使用しているデータベースが認証済かどうかの確認、または認証済のすべてのデータベースの確認を行うには、Oracle Technology NetworkのOracle Fusion Middlewareのサポートされているシステム構成のページにあるOracle Fusion Middleware 11gリリース1(11.1.1.x)の製品領域を参照してください。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

データベースのリリースをチェックするには、次のようにPRODUCT_COMPONENT_VERSIONビューに問い合せます。

SQL> SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE PRODUCT LIKE '%Oracle%';

5.2.3 推奨データベース・キャラクタ・セット

データベース・キャラクタ・セットとしてAL32UTF8を備えたデータベースを使用することを強くお薦めします。データベースをインストールする場合は、AL32UTF8キャラクタ・セットを選択する必要があります。データベースでAL32UTF8をサポートしていない場合は、リポジトリ作成ユーティリティ(RCU)を実行すると、警告が表示されます。データベースの文字セットの選択に関する情報は、データベースのドキュメントを確認してください。

5.3 11.xおよび12cデータベース用のデータベース・サービスの作成

複数の製品スイートが同じデータベースを共有する場合でも、製品スイートに固有のデータベース・サービスを使用することをお薦めします。また、使用されるデータベース・サービスはデフォルトのデータベース・サービスとは別のものをお薦めします。データベース・サービス作成の詳細な手順は、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clusters管理およびデプロイメント・ガイド』のワークロード管理に関する章を参照してください。

ランタイム接続のロード・バランシングでは、ロード・バランシングを有効にする各サービスのサービス・レベルの目標を使用してOracle RACロード・バランシング・アドバイザを構成する必要があります。Oracle RACロード・バランシング・アドバイザは、SERVICE_TIMEまたはTHROUGHPUTに対して構成できます。接続ロード・バランシングの目標をSHORTに設定します。11gリリース1のデータベースについては、この変更にDBMS_SERVICEパッケージを使用します。11gのリリース2のデータベースでは、かわりにsrvctlコマンド・ユーティリティを使用します。

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

- 第5.3.1項「11gリリース1データベース用のデータベース・サービスの作成」

- 第5.3.2項「11.2xおよび12cデータベース用のデータベース・サービスの作成」

5.3.1 11gリリース1データベース用のデータベース・サービスの作成

次の手順では、DBMS_SERVICEパッケージを使用したサービスの作成および変更の例を示します。

1. 次のようにSQL*Plusにログオンし、サービスを作成します。

prompt> sqlplus "sys/password as sysdba"
SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'biedg.mycompany.com',
NETWORK_NAME => 'biedg.mycompany.com'
);

注意:

Oracle RACデータベースのサービス名は、小文字の文字列を使用し、その後にドメイン名が続きます。たとえば、biedg.mycompany.comのようになります。

また、ここに示したEXECUTE DBMS_SERVICEコマンドを正しく実行するには1行で入力する必要があります。DBMS_SERVICEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプのリファレンスを参照してください。

2. サービスをデータベースに追加し、srvctlを使用してインスタンスに割り当てます。

prompt> srvctl add service -d custdb -s biedg.mycompany.com -r custdb1,custdb2

3. srvctlを使用してサービスを開始します。

prompt> srvctl start service -d custdb -s biedg.mycompany.com

注意:

SRVCTLコマンドの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

4. 該当するサービス目標に応じてサービスを変更します。

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'biedg.mycompany.com',
goal => DBMS_SERVICE.GOAL_THROUGHPUT, clb_goal =>DBMS_SERVICE.CLB_GOAL_SHORT);

または

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'biedg.mycompany.com',
goal => DBMS_SERVICE.GOAL_SERVICE_TIME, clb_goal =>DBMS_SERVICE.CLB_GOAL_SHORT);

5.3.2 11.2xおよび12cデータベース用のデータベース・サービスの作成

次の手順では、srvctlユーティリティを使用したサービスの作成および変更の例を示します。

1. 次のようにSQL*Plusにログオンし、サービスを作成します。

prompt> sqlplus "sys/password as sysdba"
SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'biedg.mycompany.com',
NETWORK_NAME => 'biedg.mycompany.com'
);

注意:

Oracle RACデータベースのサービス名は、小文字の文字列を使用し、その後にドメイン名が続きます。たとえば、biedg.mycompany.comのようになります。

また、ここに示したEXECUTE DBMS_SERVICEコマンドを正しく実行するには1行で入力する必要があります。DBMS_SERVICEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプのリファレンスを参照してください。

2. サービスをデータベースに追加し、srvctlを使用してインスタンスに割り当てます。

prompt> srvctl add service -d custdb -s biedg.mycompany.com -r custdb1,custdb2

3. srvctlを使用してサービスを開始します。

prompt> srvctl start service -d custdb -s biedg.mycompany.com

注意:

SRVCTLコマンドの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

4. 該当するサービス目標に応じてサービスを変更します。

prompt> srvctl modify service -d biedg -s biedg.mycompany.com -B
SERVICE_TIME -j SHORT

または

prompt> srvctl modify service -d biedg -s biedg.mycompany.com -B
THROUGHPUT -j SHORT

5.4 Oracle RACデータベースへのOracle Business Intelligenceスキーマのロード

リポジトリ作成ユーティリティ(RCU)はRCU DVDから入手できます。データベースのシードに使用するRCUのバージョンは、Oracle Business Intelligenceインストールのパッチ・セット・レベルと一致している必要があります。つまり、このエンタープライズ・デプロイメントにOracle Business Intelligence 11g(11.1.1.9.0)をインストールする場合は、RCU 11g(11.1.1.9.0)を使用する必要があります。

Oracle Business Intelligenceスキーマをデータベースにロードする手順は次のとおりです。

1. リポジトリ作成ユーティリティ(RCU)のDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。

prompt> cd RCU_HOME/bin
prompt> ./rcu

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

3. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。

4. 「データベース接続の詳細」画面で、データベースに対する接続情報を入力します。

- データベース・タイプ: 「Oracle Database」を選択します。

- ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合は、VIP名またはノード名のいずれかをホスト名(CUSTDBHOST1-VIP.MYCOMPANY.COM)として指定します。SCANが有効化されたRACデータベースでは、SCANホストをホスト名に指定します。

- ポート: データベースに対するリスニング・ポート番号を指定します(例: 1521)。

- サービス名: データベースのサービス名を指定します(biedg.mycompany.com)。

- ユーザー名: DBA権限またはSYSDBA権限のあるユーザーの名前(SYS)を指定します。

- パスワード: SYSユーザーのパスワードを入力します。

- ロール: データベース・ユーザーのロール(SYSDBA)をリストで選択します(SYSユーザーに必要)。

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

5. 「コンポーネントの選択」画面で、次の手順を実行します。

- 「接頭辞の新規作成」を選択し、データベース・スキーマに使用する接頭辞を入力します(DEV、PRODなど)。6文字まで接頭辞として指定できます。接頭辞は、データベースで複数のリポジトリの論理グループを作成するために使用されます。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

ヒント:

スキーマ名を書き留めておきます。この情報は後続の手順で必要になります。

- 次のコンポーネントを選択します。

- 「AS共通スキーマ」: 「Metadata Services」 (Oracle Business Intelligence: Business Intelligence Platformが選択されている場合、自動的に選択されます)

- Oracle Business Intelligence: Business Intelligenceプラットフォーム

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

「コンポーネントの選択」画面が次のように表示されます。

6. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択できます。

「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。

ヒント:

スキーマ・パスワードの名前を書き留めておきます。この情報は後続の手順で必要になります。

7. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

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

9. 「完了サマリー」画面で「閉じる」をクリックします。

Oracle WSMポリシーとOWSM MDSスキーマについて

Oracle WSMポリシーを格納するには、アイデンティティ管理用のデータベースを使用することをお薦めします。そのため、OWSM MDSスキーマのアイデンティティ管理データベース情報が使用されることが予想されます。これは、その他のOracle BIスキーマで使用されるものとは異なります。アイデンティティ管理データベースで必要なスキーマを作成するには、アイデンティティ管理データベース情報を使用して前述の手順を繰り返します。ただし、(ステップ5の)「コンポーネントの選択」画面では「AS共通スキーマ」: 「Metadata Services」のみを選択します。Oracle WSMポリシーの格納にアイデンティティ管理データベースを使用する方法の詳細は、第12章「エンタープライズ・デプロイメントとOracle Identity Managementの統合」を参照してください。

5.5 データベースのバックアップ

データベースにOracle Business Intelligenceスキーマをロードした後、バックアップを作成してからエンタープライズ・デプロイメントのソフトウェアをインストールします。

データベースをバックアップすると、今後の手順で問題が発生した場合に迅速にリカバリできます。この目的のためにデータベースのバックアップ計画を使用することも、オペレーティング・システムのツールやOracle Recovery Manager(RMAN)を使用して単純にバックアップすることもできます。データベースにはRMANを使用することをお薦めします(特に、Oracle ASMを使用してデータベースを作成した場合)。可能な場合、オペレーティング・システムのツール(tarなど)を使用してコールド・バックアップも実行できます。

6 エンタープライズ・デプロイメント用のソフトウェアのインストール

この章では、Oracle Business Intelligenceエンタープライズ・デプロイメントの参照用トポロジに必要なソフトウェアをインストールする手順を説明します。Oracle HTTP ServerとOracle Fusion Middlewareをインストールします。

重要:

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

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

- 第6.1項「ソフトウェアのインストール・プロセスの概要」

- 第6.2項「Oracle HTTP Serverのインストール」

- 第6.3項「Oracle Fusion Middlewareのインストール」

6.1 ソフトウェアのインストール・プロセスの概要

エンタープライズ・デプロイメントのソフトウェアのインストールは、2つの部分に分割できます。最初のパートでは必要なWeb層のインストールについて説明し、2番目のパートでは必要なOracle Fusion Middlewareコンポーネントについて説明します。以降の章では、Oracle Business Intelligenceの参照用トポロジを作成するために必要な構成手順を説明します。

インストールするソフトウェア

表6-1に、各ホストにインストールするソフトウェアまたは各ホストからアクセス可能にするソフトウェアを示します。

表6-1 各ホストにインストールするソフトウェアまたは各ホストからアクセスできる必要があるソフトウェア

ホスト

Oracle HTTP Server

Oracle WebLogic Server

Oracle Business Intelligence

WEBHOST1

可

不要

不要

WEBHOST2

可

不要

不要

APPHOST1

不要

可

可

APPHOST2

不要

可

可

ソフトウェアのバージョンについては、第2.3項「インストールするソフトウェア・コンポーネントの特定」を参照してください。

6.2 Oracle HTTP Serverのインストール

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

- 第6.2.1項「Oracle HTTP Serverのインストールの前提条件」

- 第6.2.2項「Oracle HTTP ServerのWEBHOST1およびWEBHOST2へのインストール」

- 第6.2.3項「Oracle HTTP Serverインストールのバックアップ」

6.2.1 Oracle HTTP Serverのインストールの前提条件

Oracle HTTP Serverをインストールする前に、コンピュータが次の要件を満たしていることを確認してください。

- 『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』で指定されているように、システム、パッチ、カーネルの要件、およびその他の要件が満たされていることを確認します。

- Oracle HTTP Serverはデフォルトではポート7777にインストールされるので、ノード上のどのサービスでもポート7777を使用していないことを確認する必要があります。このポートが使用中かどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。

netstat -an | grep 7777

ポート7777が使用されている場合は解放する必要があります。

- Linuxプラットフォームで、/etc/oraInst.locファイルが存在する場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合には、この手順をスキップできます。

- インストールを開始する前に、次の環境変数が設定されていないことを確認します。

- LD_ASSUME_KERNEL

- ORACLE_INSTANCE

6.2.2 Oracle HTTP ServerのWEBHOST1およびWEBHOST2へのインストール

Oracle HTTP Serverのインストール時には、Web層をインストールし、ドメインとは関連付けません。ただし、Web層をドメインに関連付けなくても、Web層用のMW_HOMEディレクトリを作成する必要があります。

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

1. Oracle HTTP Serverのインストーラを次のインストール・メディアから起動します。

./runInstaller

2. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

2. インストールを実行しているユーザーのOSグループを入力します。

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

4. 画面上の指示に従い、HOME/orainventory/createCentralInventory.shをrootとして実行してから「OK」をクリックします。

「インベントリ・ディレクトリの指定」画面は、UNIXオペレーティング・システムで、Oracle Universal Installerによる初めてのインストール時のみ表示されます。インストーラは、インベントリ・ディレクトリを使用して、マシンにインストールしたすべてのOracle製品を追跡します。

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

4. 「インストール・タイプの選択」画面で「ソフトウェアのインストール - 構成なし」を選択し、「次へ」をクリックします。

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

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

- Oracle Middleware Home: ORACLE_BASE/product/fmw

- Oracle Home Directory: Oracle_WT1

ディレクトリ名が同じでも、これらはWEBHOST1とWEBHOST2上にある2つの別個のボリュームであることに注意してください。

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

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

8. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。適切でない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。問題がなければ、「インストール」をクリックします。
UNIXシステムでoracleRoot.shスクリプトの実行を要求された場合は、必ずrootユーザーとしてスクリプトを実行します。

Oracle HTTP Serverソフトウェアがインストールされます。

9. 「インストールの進行状況」画面で「次へ」をクリックします。

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

6.2.3 Oracle HTTP Serverインストールのバックアップ

Oracle HTTP Server用のMiddlewareホームをバックアップします。必ず先にサーバーを停止します。

WEBHOSTn> tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw HOME/oraInventory

6.3 Oracle Fusion Middlewareのインストール

この項では、Oracle Business Intelligenceのエンタープライズ・デプロイメントの参照用トポロジに必要なOracle Fusion Middlewareソフトウェアをインストールする手順を説明します。インストールするソフトウェア・コンポーネントは、WebLogic Serverホーム(WL_HOME)およびOracleホーム(ORACLE_HOME)です。第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

重要:

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

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

- 第6.3.1項「Oracle WebLogic Serverのインストールとミドルウェア・ホームの作成」

- 第6.3.2項「Oracle Business Intelligenceのインストール」

- 第6.3.3項「Oracle Fusion Middlewareインストールのバックアップ」

6.3.1 Oracle WebLogic Serverのインストールとミドルウェア・ホームの作成

Oracle WebLogic Serverを、64ビットJDKを使用して64ビット・プラットフォームにインストールする場合は、この項の手順ではなく、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の64ビットJDKを使用した64ビット・プラットフォームへのWebLogic Serverのインストールに関する項を参照してください。

次の手順を実行して、Oracle WebLogic ServerをAPPHOST1とAPPHOST2にインストールします。

1. Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。

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

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、次の手順を実行します。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します

注意:

ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。このディレクトリは/u01/app/oracleとすることをお薦めします。詳細は、第4.3項「各種ディレクトリの推奨場所について」を参照してください。

ディレクトリ名が同じでも、これらはAPPHOST1とAPPHOST2上にある2つの別個のボリュームであることに注意してください。

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

4. 「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを指定します。受信する場合は、電子メール・アドレスを入力します。
「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。

6. 「製品インストール・ディレクトリの選択」画面で、ORACLE_BASE/product/fmw/wlserver_10.3ディレクトリを受け入れます。Oracle Coherenceの場合もデフォルトのディレクトリ(ORACLE_BASE/product/fmw/coherence_3.7)を受け入れます。

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

8. 「インストールの概要」画面で「次へ」をクリックします。
Oracle WebLogic Serverソフトウェアがインストールされます。

9. 「インストール完了」画面で、「Quickstartの実行」オプションの選択を解除して「完了」をクリックします。

10. Oracle WebLogic Serverのインストール後、ORACLE_HOMEディレクトリに次のディレクトリおよびファイルが存在することを確認し、インストールが成功したことを確認します。

- coherence_version

- modules

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- wlserver_10.3

6.3.2 Oracle Business Intelligenceのインストール

次の手順を実行して、Oracle BI EE 11g (11.1.1.9.0)をAPPHOST1およびAPPHOST2にインストールします。インストールは共有記憶域で実行するので、MW_HOMEはAPPHOST1およびAPPHOST2のOracle BI Serverからアクセスされ、使用されます。

1. Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合には、この手順をスキップできます。

2. Oracle Business Intelligenceのインストーラを次のインストール・メディアから起動します。

./runInstaller

3. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. HOME/oraInventoryと入力します。ここで、HOMEはインストールを実行するユーザーのホーム・ディレクトリです(これが推奨場所です)。

2. インストールを実行しているユーザーのOSグループを入力します。

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

画面上の指示に従い、HOME/orainventory/createCentralInventory.shをrootとして実行してから「OK」をクリックします。

「インベントリ・ディレクトリの指定」画面は、UNIXオペレーティング・システムで、Oracle Universal Installerによる初めてのインストール時のみ表示されます。インストーラは、インベントリ・ディレクトリを使用して、コンピュータにインストールしたすべてのOracle製品を追跡します。

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

5. 「ソフトウェア更新のインストール」画面で、ソフトウェアの更新をスキップするか、ソフトウェアの更新をMy Oracle Supportから検索するか、更新をローカル・ディレクトリから検索するかを指定します。決定したら、「次へ」をクリックします。

6. 「インストール・タイプの選択」画面で、「ソフトウェアのみインストール」を選択して「次へ」をクリックします。

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

8. 「インストール場所の指定」画面で、前にインストールしたミドルウェア・ホームをドロップダウン・リストで選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(Oracle_BI1)を入力します。
「次へ」をクリックします。

9. 「アプリケーション・サーバー」画面で、「WebLogic Server」が選択されていることを確認してから「次へ」をクリックします。

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

11. 「サマリー」画面で「インストール」をクリックします。
Oracle Business Intelligenceソフトウェアがインストールされます。

12. 「インストールの進行状況」画面で「次へ」をクリックします。

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

14. Oracle WebLogic ServerおよびOracle Business Intelligenceの両方のインストール後、ORACLE_HOMEディレクトリに次のディレクトリおよびファイルが存在することを確認し、インストールが成功したことを確認します。

- coherence_X.X

- jrockit-jdkY.Y

- modules

- oracle_common

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- Oracle_BI1

- wlserver_10.3

6.3.3 Oracle Fusion Middlewareインストールのバックアップ

この時点でミドルウェア・ホームをバックアップします。最初にサーバーが停止していることを確認します。

ミドルウェア・ホームをバックアップするには、次のコマンドを実行します。

APPHOSTn> tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw HOME/oraInventory

このコマンドでは、Oracle WebLogic ServerおよびOracle Business Intelligenceを含むOracle Fusion Middlewareコンポーネントの両方のインストール・ファイルのバックアップが作成されます。

7 エンタープライズ・デプロイメント用のWeb層の構成

この章では、Oracle Business Intelligenceエンタープライズ・デプロイメントをサポートするようにOracle Web層を構成する方法を説明します。

重要:

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

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

- 第7.1項「Web層構成の概要」

- 第7.2項「構成ウィザードによるOracle HTTP Serverの構成」

- 第7.3項「構成の検証」

- 第7.4項「HTTPリクエストをルーティングするためのロード・バランサの構成」

- 第7.5項「仮想ホストの定義」

7.1 Web層構成の概要

この章では、Oracle Web層をWebLogic Serverドメインに関連付ける方法を説明します。Web層とWebLogic Serverを関連付けると、Oracle Enterprise Manager Fusion Middleware Controlを使用してWeb層を監視できます。

その後、すべてのHTTPリクエストをWEBHOST1およびWEBHOST2にルーティングするようロード・バランサを構成します。

最後の項では、両方のOHSサーバーで、httpd.confファイルの<VirtualHost>セクションのディレクティブを定義する方法を説明します。これらの仮想ホスト名は、第3.3項「ロード・バランサの構成」でロード・バランサを構成したときに作成したものです。

7.2 構成ウィザードによるOracle HTTP Serverの構成

Oracle Web層の構成手順は、WEBHOST1とWEBHOST2で同じです。

注意:

構成を開始する前に、第6.2項「Oracle HTTP Serverのインストール」のとおり、Oracle Web層ソフトウェアをWEBHOST1およびWEBHOST2にインストールする必要があります。

Oracle Web層を構成する手順は次のとおりです。

1. Oracle Fusion Middlewareの構成ウィザードの場所に、ディレクトリを変更します。

WEBHOSTn> cd ORACLE_BASE/product/fmw/Oracle_WT1/bin

2. 構成ウィザードを起動します。

WEBHOSTn> ./config.sh

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

4. 「コンポーネントの構成」画面で「Oracle HTTP Server」を選択し、「選択されたコンポーネントとWebLogicドメインの関連付け」の選択を解除します。「Oracle Web Cache」は選択されていないことを確認します。
「次へ」をクリックします。

5. 「コンポーネントの詳細の指定」画面で、次の値を指定します。

- インスタンス・ホームの場所: ORACLE_BASE/admin/webn

- インスタンス名: webn

- OHSコンポーネント名: ohsn

(ここでnは、インストール上の連番を示します。たとえば、WEBHOST1には1、WEBHOST2には2などです。)

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

注意: WEBHOST1およびWEBHOST2上でのOracle HTTP Serverのインスタンス名は、異なっている必要があります。

6. 高可用性の実装では、様々なコンポーネントで使用されるポートのすべてを複数のホスト間で同期すると、より簡単になります(必須ではありません)。使用するポートをファイルに指定することで、自動ポート構成をバイパスできます。
「ポートの構成」画面でファイル名を選択し、「表示/編集」をクリックします。ファイルは次のようになります。

[OHS]
#Listen port for OHS component
OHS Port = 7777

[OPMN]
#Process Manager Local port no
OPMN Local Port = 1880

サンプルのstaticports.iniファイルは/Disk1/stage/Response/ディレクトリにあります。

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

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

8. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。適切でない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。問題がなければ、「構成」をクリックします。

9. 複数の構成アシスタントが連続して起動されます。このプロセスには時間がかかる可能性があります。プロセスが終了したら、「次へ」をクリックすると、「インストール完了」画面が表示されます。

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

7.3 構成の検証

構成が完了した場合は、次のURLを使用してOracle HTTP Serverのホーム・ページにアクセス可能なことを確認します。

http://webhost1.mycompany.com:7777/

http://webhost2.mycompany.com:7777/

7.4 HTTPリクエストをルーティングするためのロード・バランサの構成

Oracle HTTP Serverを実行するホスト(WEBHOST1、WEBHOST2)へすべてのHTTPリクエストをルーティングするようロード・バランサを構成します。Oracle HTTP ServerがフロントエンドのOracle WebLogic Serverである場合は、ロード・バランサでスティッキー・セッション(Cookieの挿入)を有効にする必要はありません。このドキュメントで説明するトポロジには該当しませんが、ロード・バランサからOracle WebLogic Serverにリクエストが直接ルーティングされる場合にはスティッキー・セッションが必要です。HTTPの監視も設定します。

使用するロード・バランサによって、構成手順は異なります。具体的な手順は、ロード・バランサのドキュメントを参照してください。

7.5 仮想ホストの定義

このガイドの参照トポロジでは、Oracle HTTPサーバーに対する仮想ホスト・セットを定義する必要があります。各仮想ホストについて、後でWebLogic Serverドメイン内の適切な管理サーバーまたは管理対象サーバーにリクエストをルーティングするための特定のURLセットを定義する必要があります。

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

- 第7.5.1項「httpd.confファイルでのIPアドレスとポートの定義」

- 第7.5.2項「<VirtualHost>ディレクティブを定義する.confファイルの作成」

- 第7.5.3項「構成の検証」

7.5.1 httpd.confファイルでのIPアドレスとポートの定義

名前ベースの仮想サーバーを定義します。定義する個々の仮想ホストに対して使用するIPアドレスとポートを定義する必要があるという意味です。一度、httpd.confファイルにIPアドレスとポートを定義すれば、実際の仮想ホスト名(および各々の特定URL)を仮想ホスト専用の.confファイルに定義できます。

httpd.confファイルは、次のディレクトリにあります。

ORACLE_INSTANCE/config/OHS/ohsn

IPアドレスおよびポートを定義するには、両方のOracle HTTP Serverについて、httpd.confファイルに次のエントリを追加します。

NameVirtualHost *:7777

NameVirtualHostパラメータの値は、ロード・バランサに対する仮想ホストがどのように構成されているかによって異なります。80など、表示されたものとは別の値を使用する必要がある場合があります。

7.5.2 <VirtualHost>ディレクティブを定義する.confファイルの作成

個々の仮想ホストをホスト自身の.confファイルで定義します。この定義により、定義する個々の仮想ホストのURLの管理が容易になります。

<VirtualHost>のディレクティブを定義するために、次のファイルを新規作成します。

- bi_vh.conf

- biinternal_vh.conf

- admin_vh.conf

次のディレクトリに新規ファイルを作成します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

注意:

WEBHOST1およびWEBHOST2の両方に対して、次の手順を実行します。

個々の仮想ホストをホスト自身の.confファイルで定義する手順は次のとおりです。

1. bi_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost *:7777>
ServerName https://bi.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

2. biinternal_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost *:7777>
ServerName biinternal.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

3. admin_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost *:7777>
ServerName admin.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end_url=/console" [R]
</VirtualHost>

第12章「エンタープライズ・デプロイメントとのOracle Identity Managementとの統合」の手順が完了していない場合は、統合が完了するまで、RewriteRuleの行をコメント・アウトします。

4. 次の手順で、両方のOracle HTTP Serverを再起動します。

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

7.5.3 構成の検証

次のURLにアクセスして、ロード・バランサとOracle HTTP Serverが正しく構成されていることを確認します。

- https://bi.mycompany.com/index.html

- http://admin.mycompany.com/index.html

- http://biinternal.mycompany.com/index.html

これらのURLにアクセスできない場合は、第3.3項「ロード・バランサの構成」の手順を正しく実行していることを確認してください。

8 管理サーバーと最初の管理対象サーバーが含まれたドメインの作成

この章では、Oracle Business Intelligence構成アシスタント、Oracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlを使用して、管理サーバーと最初のOracle Business Intelligence管理対象サーバーのドメインを作成する方法について説明します。後で、ドメインをスケール・アウトしてコンポーネントを追加します。これについては、このガイドの後続の章で説明します。

重要:

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

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

- 第8.1項「ドメイン作成の概要」

- 第8.2項「APPHOST1でのドメインおよびbi_server1管理対象サーバーの作成」

- 第8.3項「構成後タスクおよび検証タスク」

- 第8.4項「WebLogicドメインのOracle HTTP Serverの構成」

- 第8.5項「管理サーバーの手動フェイルオーバーの検証」

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

8.1 ドメイン作成の概要

表8-1には、管理サーバーおよび最初の管理対象サーバーを含むOracle Business IntelligenceのWebLogicドメインを作成する手順がリストされており、構成後タスクについても記載されています。

表8-1 Oracle Business Intelligenceのドメインの作成手順

手順

説明

詳細

WebLogicドメインの作成

Oracle Business Intelligence構成アシスタントを実行し、管理サーバーおよび最初の管理対象サーバーを含むWebLogicドメインを作成します。

第8.2項「APPHOST1でのドメインおよびbi_server1管理対象サーバーの作成」

構成後タスクおよび検証タスク

構成後タスクおよび検証タスクの手順に従います。

第8.3項「構成後タスクおよび検証タスク」

WebLogic DomainのOracle HTTP Serverの構成

WebLogicドメインの管理サーバーと管理対象サーバーにOracle HTTP Serverを構成し、その構成を検証します。

第8.4項「WebLogicドメインのOracle HTTP Serverの構成」

管理サーバーのフェイルオーバーのテスト

説明に従い、管理サーバーをAPPHOST1からAPPHOST2に手動でフェイルオーバーします。

第8.5項「管理サーバーの手動フェイルオーバーの検証」

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

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

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

8.2 APPHOST1でのドメインおよびbi_server1管理対象サーバーの作成

Oracleホーム・ディレクトリからOracle Business Intelligence構成アシスタントを実行し、Oracle Business Intelligenceコンポーネントが配置された管理サーバーおよび最初の管理対象サーバーを含むドメインを作成する手順は次のとおりです。

1. Business Intelligenceプラットフォーム・スキーマをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスが実行されていることを確認することをお薦めします。

2. ディレクトリを構成アシスタントの場所に変更します(これは、第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」で作成しています)。

APPHOST1> cd ORACLE_HOME/bin

3. 構成アシスタントを起動します。

APPHOST1> ./config.sh

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

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

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

- ユーザー名: weblogic

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

- ドメイン名: bifoundation_domain

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

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

- ミドルウェア・ホーム: 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/aserver/domain_name
「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

- インスタンス・ホーム: ORACLE_BASE/admin/instance1

- インスタンス名: instance1

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

8. 「コンポーネントの構成」画面で次を選択します。

- Oracle Business Intelligence

- Business Intelligence Enterprise Edition

- Business Intelligence Publisher

- Real-Time Decisions

- Essbase Suite

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

9. BIPLATFORMスキーマ画面で次の情報を入力します。

- データベース・タイプ: Oracle Database

- 接続文字列: CUSTDBHOST1-VIP.MYCOMPANY.COM:port-num:CUSTDB1^CUSTDBHOST2-VIP.MYCOMPANY.COM:port-num:CUSTDB2@BIEDG.MYCOMPANY.COM
ここで、port-numに1521を指定することもできます。

注意:

Oracle Real Application Cluster(RAC)11g リリース2以降については、Single Client Access Name(SCAN)を指定します。それ以前のリリースについては、仮想IPアドレスを指定します。SCANに対しては、次のような接続文字列を使用します。

CUSTDB-SCAN.MYCOMPANY.COM:port-num:CUSTDB1^CUSTDB-SCAN.MYCOMPANY.COM:port-num:CUSTDB2@BIEDG.MYCOMPANY.COM

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

- BIPLATFORMスキーマ・ユーザー名: prefix_BIPLATFORM

- BIPLATFORMスキーマ・パスワード: your_password

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

10. MDSスキーマ画面で情報を確認します。例:

- データベース・タイプ: Oracle Database

- 接続文字列: CUSTDBHOST1-VIP.MYCOMPANY.COM:port-num:CUSTDB1^CUSTDBHOST2-VIP.MYCOMPANY.COM:port-num:CUSTDB2@BIEDG.MYCOMPANY.COM
ここで、port-numに1521を指定することもできます。

注意:

Oracle Real Application Cluster(RAC)11g リリース2以降については、Single Client Access Name(SCAN)を指定します。それ以前のリリースについては、仮想IPアドレスを指定します。SCANに対しては、次のような接続文字列を使用します。

CUSTDB-SCAN.MYCOMPANY.COM:port-num:CUSTDB1^CUSTDB-SCAN.MYCOMPANY.COM:port-num:CUSTDB2@BIEDG.MYCOMPANY.COM

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

- MDSスキーマ・ユーザー名: prefix_MDS

- MDSパスワード: your_password

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

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

- 自動でポートを構成

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

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

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

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

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

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

通常はノード・マネージャは、config.shプロセスの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、APPHOST1で次のコマンドを実行してノード・マネージャを起動します。

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

8.3 構成後タスクおよび検証タスク

Oracle Business Intelligence構成アシスタントでドメインを構成した場合は、構成後および検証に関する次の手順に従います。

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

- 第8.3.1項「BI Publisher用のJMSの構成」

- 第8.3.2項「APPHOST1での管理サーバー用boot.propertiesの作成」

- 第8.3.3項「APPHOST1での管理サーバーの起動」

- 第8.3.4項「管理サーバーの高可用性の有効化」

- 第8.3.5項「管理サーバーの検証」

- 第8.3.6項「bi_server1管理対象サーバーのリスニング・アドレスの設定」

- 第8.3.7項「bi_server1管理対象サーバーに対するホスト名検証の無効化」

- 第8.3.8項「APPHOST1でのOracle Business Intelligenceの検証」

8.3.1 BI Publisher用のJMSの構成

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

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

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

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

4. 「BipJmsStore」をクリックして、共有記憶域上のディレクトリを入力します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。
ORACLE_BASE/admin/domain_name/bi_cluster/jms

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

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

8.3.2 APPHOST1での管理サーバー用boot.propertiesの作成

次の手順を実行して、APPHOST1上で管理サーバーに対するboot.propertiesファイルを作成します。このファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。

1. 次のディレクトリに移動します。

ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security

2. このディレクトリに、テキスト・エディタを使用してboot.propertiesというファイルを作成し、ファイルに次の行を入力します。

username=Admin_Username
password=Admin_Password

注意:

管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。第8.3.3項「APPHOST1での管理サーバーの起動」で管理サーバーを起動します。セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、エントリが暗号化されるように、できるだけ速やかにサーバーを起動してください。

3. ファイルを保存してエディタを閉じます。

8.3.3 APPHOST1での管理サーバーの起動

ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。

1. 次の手順を実行してノード・マネージャを停止してから再起動し、動的登録を有効にします。

1. 実行中のNodeManagerプロセスを停止します。

2. ノード・マネージャを再起動し、次のコマンドを使用して動的登録を有効にします。

APPHOST1> cd WL_HOME/server/bin
APPHOST1> export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
APPHOST1> ./startNodeManager.sh

注意:

管理サーバーを管理するノード・マネージャの起動時には、-DDomainRegistrationEnabled=trueパラメータを設定することが重要です。このコンピュータ上に管理サーバーがなく、このコンピュータが管理サーバーのフェイルオーバー・ノードでない場合、ノード・マネージャは次のように起動できます。

APPHOST1> ./startNodeManager.sh

管理サーバーが実行されているコンピュータが外部から使用可能な場合は、-DDomainRegistrationEnabled=trueパラメータを設定しなことも選択できます。-DDomainRegistrationEnabledパラメータがtrueに設定されていないと、ノード・マネージャを使用して管理サーバーを起動または停止できません。

2. Oracle WebLogic Scripting(WLST)を起動して、nmconnectとステップ1で設定した資格証明によりノード・マネージャに接続し、次のようにnmstartコマンドを使用して管理サーバーを起動します。

APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./wlst.sh

WLSTシェルで、次のコマンドを実行します。

wls:/offline>nmConnect('Admin_User','Admin_Pasword', 'APPHOST1',
'node_manager_port','domain_name','Domain_Home')

wls:/nm/domain_name> nmStart('AdminServer')

例:

wls:/offline>nmConnect('weblogic', 'my_password', 'APPHOST1' , '9556',
'bifoundation_domain' ,'/u01/app/oracle/admin/bifoundation_domain/aserver/
bifoundation_domain')

wls:/nm/bifoundation_domain> nmStart('AdminServer')

注意:

APPHOST1とは、ドメインを作成したノードのアドレスで、管理サーバーのリスニング・アドレスではありません。また、ユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理者のIDおよびパスワードとは関係なく、ORACLE_BASE/admin/domain_name/aserver/domain_name/config/nodemanager/nm_password.propertiesファイルに格納されています。

8.3.4 管理サーバーの高可用性の有効化

Oracle WebLogic Server管理サーバーはシングルトン・アプリケーションなので、アクティブ/アクティブ構成にはデプロイできません。デフォルトでは、管理サーバーが使用できるのは、最初にインストールしたノードのみなので、このエンタープライズ・トポロジで使用できるのはAPPHOST1のみです。このノードを利用できなくなると、管理コンソールとFusion Middleware Controlも利用できなくなります。このシナリオを回避するには、管理サーバーおよびそこにデプロイしたアプリケーションの可用性を高める必要があります。このガイドのエンタープライズ・デプロイメント・アーキテクチャでは、APPHOST1とAPPHOST2で共有されるディスク上に管理サーバーをデプロイする必要があります。

このガイドで説明する手順では、最初にAPPHOST1にマウントされている共有ディスクに管理サーバーとbi_server1管理対象サーバーをデプロイし、その後ローカル・ファイル・システムにbi_server1管理対象サーバーのドメイン情報を手動で移行します。この手順は、Oracle Universal Installerの設計上のある制約を克服するために必要です。

注意:

次の各項の手順を実行する前に、管理サーバーを実行しているホストでいずれかのネットワーク・インタフェース・カードを、仮想IPアドレスをリスニングするように構成したことを確認してください。詳細は、第3.4.1項「APPHOST1上のADMINVHNの有効化」を参照してください。

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

- 第8.3.4.1項 「管理サーバー用のマシンの作成」

- 第8.3.4.2項「管理サーバーの仮想IPアドレスのリスニングの有効化」

- 第8.3.4.3項「bi_server1管理対象サーバーに対する別のドメイン・ディレクトリの作成」

- 第8.3.4.4項「Fusion Middleware Controlのフェイルオーバーの有効化」

8.3.4.1 管理サーバー用のマシンの作成

次の手順を実行して、管理コンソールを使用して、マシンを新規に作成し、新しいマシンを管理サーバーに割り当てます。

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

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

3. 「ホーム」ページの「環境」セクションで、「マシン」をクリックします。

4. 「マシンのサマリー」ページの「マシン」表から、管理サーバーに関連付けられているマシンを選択し、「クローン」をクリックします。たとえば、APPHOST1.MYCOMPANY.COMです。

5. 「マシンのクローンを作成」ページの「マシンID」セクションにマシンの名前を入力し、「OK」をクリックします。たとえば、マシン名としてADMINHOSTを入力します。

6. 「マシンのサマリー」ページで、新規に作成されたマシンのリンクをクリックします。

7. ADMINHOSTマシンの「設定」ページで「サーバー」タブを選択します。

8. 「サーバー」表の下の「追加」をクリックします。

9. 「マシンにサーバーを追加」ページで「既存のサーバーを選択して、このマシンに関連付けます。」オプションを選択します。

10. ドロップダウン・メニューから「AdminServer」を選択します。

11. 「終了」をクリックし、マシンと管理サーバーを関連付けます。

12. チェンジ・センターで、変更のアクティブ化をクリックします。

8.3.4.2 管理サーバーの仮想IPアドレスのリスニングの有効化

管理サーバーのリスニング・アドレスを設定する前に、第3.4.1項「APPHOST1上のADMINVHNの有効化」で説明されている手順が実行済であることを確認します。

次の手順を実行して、管理サーバーのリスニング・アドレスを設定します。

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

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

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

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

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

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

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

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

9. 変更内容は、管理サーバーが再起動されるまでは有効になりません。次の手順を実行して、管理サーバーを再起動します。

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

2. 表で「AdminServer(admin)」を選択して、「停止」をクリックします。

3. コマンドラインから次のように管理サーバーを再起動します。

APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./wlst.sh
wls:/offline> nmConnect
('Admin_User','Admin_Password','APPHOST1','node_mgr_port','domain_name','Domain_home')
wls:/nm/domain_name> nmStart ('AdminServer')

8.3.4.3 bi_server1管理対象サーバーに対する別のドメイン・ディレクトリの作成

次の手順を実行して、packおよびunpackコマンドを使用し、管理サーバーが使用するドメイン・ディレクトリを、APPHOST1のbi_server1管理対象サーバーが使用するドメイン・ディレクトリから分離します。

1. 次の手順を実行して、管理サーバーとbi_server1管理対象サーバーを停止します。

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

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

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

4. 「サーバーのサマリー」ページで、「制御」タブを選択します。

5. 表で「AdminServer(admin)」と「bi_server1」を選択し、「停止」をクリックします。

2. APPHOST1でpackコマンドを実行し、次のコマンドを使用してテンプレート・パックを作成します。bi_server1管理対象サーバーのドメイン情報のみをpackするために、managed=trueを渡します。

APPHOST1> cd ORACLE_HOME/common/bin
APPHOST1> ./pack.sh -managed=true -domain=path_to_installer_created_domain
-template=templateName.jar -template_name=templateName

例:

APPHOST1> cd ORACLE_HOME/common/bin
APPHOST1> ./pack.sh -managed=true -domain=
ORACLE_BASE/admin/bifoundation_domain/aserver/bifoundation_domain
-template=/tmp/managedServer.jar -template_name=ManagedServer_Template

3. 次のようにAPPHOST1でunpackコマンドを実行し、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。

APPHOST1> cd ORACLE_HOME/common/bin
APPHOST1> ./unpack.sh -domain=path_to_domain_on_LocalFileSystem
-template=templateName.jar -app_dir=path_to_applications_dir_on_LocalFileSystem

例:

APPHOST1> cd ORACLE_HOME/common/bin
APPHOST1>./unpack.sh -domain=
ORACLE_BASE/admin/bifoundation_domain/mserver/bifoundation_domain
-template=/tmp/managedServer.jar -app_dir=
ORACLE_BASE/admin/bifoundation_domain/mserver/applications

4. Oracle WebLogic Scripting Tool(WLST)を起動し、nmconnectとステップ2で設定した資格証明によりノード・マネージャに接続し、nmstartを使用して管理サーバーを起動します。

APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./wlst.sh

WLSTシェルで、次のコマンドを実行します。

wls:/offline>nmConnect('Admin_User','Admin_Pasword','APPHOST1',
'node_manager_port','domain_name','Domain_Home')

wls:/nm/domain_name> nmStart('AdminServer')

例:

wls:/offline>nmConnect('weblogic', 'my_password', 'APPHOST1' , '9556',
'bifoundation_domain' ,'/u01/app/oracle/admin/bifoundation_domain/
aserver/bifoundation_domain')

wls:/nm/bifoundation_domain> nmStart('AdminServer')

5. 次の手順を実行して、APPHOST1でbi_server1管理対象サーバーを起動します(ノード・マネージャが稼働していることを確認します)。

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

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

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

4. 「サーバーのサマリー」ページで、「制御」タブを選択します。

5. 表で「bi_server1」を選択し、「起動」をクリックします。

8.3.4.4 Fusion Middleware Controlのフェイルオーバーの有効化

Fusion Middleware Controlのフェイルオーバーを有効化するには、MW_HOME/user_projects/applications/bifoundation_domainディレクトリから、管理サーバーの高可用性機能が実行される可能性のあるすべてのノードの対応するディレクトリにem.earファイルをコピーします。一部のケースでは、MW_HOME/user_projects/applications/bifoundation_domainディレクトリを他のノードに作成する必要があります。

8.3.5 管理サーバーの検証

次の手順を実行して、管理サーバーが適切に構成されていることを確認します。

1. Webブラウザを開き、http://ADMINVHN:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. 次のFusion Middleware Controlにアクセスできることを確認します。
http://ADMINVHN:7001/em

4. 第8.3.2項「APPHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してFusion Middleware Controlにログインします。

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

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

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

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

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

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

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

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

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

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

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

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

1. 「サーバーのサマリー」ページで、「制御」タブを選択します。

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

3. サーバーの停止後、表で「bi_server1」を選択し、「起動」をクリックします。

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

cd ORACLE_BASE/admin/instance1/bin
./opmnctl stopall
./opmnctl startall

8.3.6.1 EPMレジストリ内の論理Webアプリケーションの更新

次の手順を実行して、EPMレジストリ内にあるEPMアプリケーションの論理Webアプリケーション・エンドポイントのホスト情報を更新します。

1. 次のコマンドを入力して、Oracle Business Intelligenceで使用する論理WebアプリケーションのGUIDを取得します。
/u01/app/oracle/admin/instance1/config/foundation/11.1.2.0/epmsys_registry.sh view LOGICAL_WEB_APP

コマンドにより、複数のコンポーネントが戻されます。

2. すべてのHOST値を、各コンポーネントで内部ロード・バランサの仮想ホストに変更します。次のようにして、ポートを80に更新します。
/u01/app/oracle/admin/instance1/config/foundation/11.1.2.0/epmsys_registry.sh updateproperty \#<Component_GUID>/@host biinternal.mycompany.com

/u01/app/oracle/admin/instance1/config/foundation/11.1.2.0/epmsys_registry.sh updateproperty \#<Component_GUID>/@port 80

ここで、GUIDはEPMレジストリ内のEPMアプリケーションのIDです。

3. 次のプロパティに正しい値が設定されていることを確認します。

- HOST = 内部LBR vip。たとえば、biinternal.mycompany.comなど。

- isSSL = False。

- port = 80。

4. 管理対象サーバーおよびBIシステム・コンポーネントを再起動します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 「サーバーのサマリー」ページで、「制御」タブを選択します。

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

3. 表で「bi_server1」を選択し、「起動」をクリックします。

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

cd ORACLE_BASE/admin/instance1/bin
./opmnctl stopall
./opmnctl startall

8.3.8 APPHOST1でのOracle Business Intelligenceの検証

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

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

- http://APPHOST1VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データに含まれる使用可能なポリシーとアサーション・テンプレートのリストが表示されます。
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

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

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

- http://APPHOST1VHN1:9704/bicomposerにアクセスして、Oracle BI Composerアプリケーションのステータスを確認します。

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

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

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

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

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

8.4 WebLogicドメインのOracle HTTP Serverの構成

この項では、管理サーバーおよびbi_server1管理対象サーバーを含むWebLogicドメインに対してOracle HTTP Serverを構成する方法について説明します。

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

- 第8.4.1項「管理サーバーとbi_servern管理対象サーバーについてのOracle HTTP Serverの構成」

- 第8.4.2項「WebLogicプラグイン有効化フラグのオン」を参照してください。

- 第8.4.3項「Oracle WebLogic ServerへのOracle HTTP Serverの登録」

- 第8.4.4項「管理コンソールのフロントエンドURLの設定」

- 第8.4.5項「Oracle HTTP Serverを使用したアクセスの検証」

8.4.1 管理サーバーとbi_servern管理対象サーバーについてのOracle HTTP Serverの構成

管理サーバーおよびbi_servern管理対象サーバーを含むbi_clusterへのOracle HTTP Serverによるルーティングを有効にするには、WebLogicClusterパラメータに対してクラスタ内のノードのリストを設定する必要があります。

WebLogicClusterパラメータを設定する手順は次のとおりです。

1. WEBHOST1とWEBHOST2上で、次のディレクトリにあるadmin_vh.confおよびbiinternal_vh.confファイルにディレクティブを追加します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

この手順では、第7.5項「仮想ホストの定義」の指示に従って、admin_vh.confおよびbiinternal_vh.confファイルが作成済であることを前提としています。

次のディレクティブをadmin_vh.confファイルの<VirtualHost>タグ内に追加します。

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

2. 次のディレクティブをbiinternal_vh.confファイルの<VirtualHost>タグ内に追加します。

#redirect browser requests that omit document/dir
RedirectMatch 301 /analytics$ /analytics/
RedirectMatch 301 /bimiddleware$ /bimiddleware/
RedirectMatch 301 /analytics/res$ /analytics/res/
RedirectMatch 301 /bioffice$ /bioffice/
RedirectMatch 301 /biofficeclient$ /biofficeclient/
RedirectMatch 301 /biservices$ /biservices/
RedirectMatch 301 /analytics-ws$ /analytics-ws/
RedirectMatch 301 /AdminService$ /AdminSErvice/
RedirectMatch 301 /AsyncAdminService$ /AsyncAdminService/
RedirectMatch 301 /rtis$ /rtis/
RedirectMatch 301 /wsm-pm$ /wsm-pm/
RedirectMatch 301 /xmlpserver$ /xmlpserver/
RedirectMatch 301 /ui$ /ui/
RedirectMatch 301 /bisearch$ /bisearch/
RedirectMatch 301 /mapviewer$ /mapviewer/
RedirectMatch 301 /bicontent$ /bicontent/
RedirectMatch 301 /bicomposer$ /bicomposer/
RedirectMatch 301 /mobile$ /mobile/
RedirectMatch 301 /rtis$ /rtis/
RedirectMatch 301 /aps$ /aps/
RedirectMatch 301 /calcmgr$ /calcmgr/
RedirectMatch 301 /hr$ /hr/
RedirectMatch 301 /workspace$ /workspace/

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# BIEE Analytics
<Location /analytics>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

<Location /analytics-ws>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

<Location /bimiddleware>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

<Location /bicontent>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

<Location /mobile>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# MapViewer
<Location /mapviewer>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# BI Publisher
<Location /xmlpserver>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# Oracle RTD
<Location /ui>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

<Location /rtis>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

<Location /schema>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

<Location /ws>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# BI Search
<Location /bisearch>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# BI Composer

<Location /bicomposer>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# EPM Provider Services
<Location /aps>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# EPM Calc Manager
<Location /calcmgr>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# EPM Financial Reporting
<Location /hr>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# EPM Workspace
<Location /workspace>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# BI Office
<Location /bioffice>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# BI Office Client
<Location /biofficeclient>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# BI SOA Services
<Location /biservices>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# AdminService
<Location /AdminService>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

# AsyncAdminService
<Location /AsyncAdminService>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

#OWSM
<Location /wsm-pm>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>

3. 次のディレクティブをbi_vh.confファイルの<VirtualHost>タグ内に追加します。

#redirect browser requests that omit document/dir
RedirectMatch 301 /analytics$ /analytics/
RedirectMatch 301 /bimiddleware$ /bimiddleware/
RedirectMatch 301 /xmlpserver$ /xmlpserver/
RedirectMatch 301 /ui$ /ui/
RedirectMatch 301 /analytics/res$ /analytics/res/
RedirectMatch 301 /biofficeclient$ /biofficeclient/
RedirectMatch 301 /biservices$ /biservices/
RedirectMatch 301 /analytics-ws$ /analytics-ws/
RedirectMatch 301 /ws$ /ws/
RedirectMatch 301 /wsm-pm$ /wsm-pm/
RedirectMatch 301 /bisearch$ /bisearch/
RedirectMatch 301 /mapviewer$ /mapviewer/
RedirectMatch 301 /bicontent$ /bicontent/
RedirectMatch 301 /bicomposer$ /bicomposer/
RedirectMatch 301 /mobile$ /mobile/
RedirectMatch 301 /rtis$ /rtis/
RedirectMatch 301 /aps$ /aps/
RedirectMatch 301 /calcmgr$ /calcmgr/
RedirectMatch 301 /hr$ /hr/
RedirectMatch 301 /workspace$ /workspace/

# BIEE Analytics
<Location /analytics>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /analytics-ws>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /bimiddleware>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /bicontent>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /mobile>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# MapViewer
<Location /mapviewer>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BI Publisher
<Location /xmlpserver>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Oracle RTD
<Location /ui>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /rtis>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /schema>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /ws>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BI Search
<Location /bisearch>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BI Composer

<Location /bicomposer>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# EPM Provider Services
<Location /aps>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# EPM Calc Manager
<Location /calcmgr>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# EPM Financial Reporting
<Location /hr>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# EPM Workspace
<Location /workspace>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BI Office
<Location /bioffice>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BI Office Client
<Location /biofficeclient>

SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# OWSM
<Location /wsm-pm>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

注意:

必要に応じて他のリソース(SampleApp.rpdファイルの機能をサポートするanalyticsResやActionSamplesなど)を追加します。

4. WEBHOST1およびWEBHOST2の両方で、次のようにOracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

WebLogicClusterパラメータで指定したサーバーは、起動時にプラグインに対してのみ重要な役割を持ちます。このリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。

次に例を示します。

- 例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時に動的に検出されます。

- 例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。ただし、Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタにルーティングできません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのすべてのメンバーをリストした場合、Oracle HTTP Serverの起動時に少なくとも1つのメンバーが実行されていれば、クラスタへのルーティングが保証されます。

WebLogic Serverプラグインの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』を参照してください。

8.4.2 WebLogicプラグイン有効化フラグのオン

セキュリティのため、またロード・バランサがSSLリクエストを終了するため(Oracle HTTP ServerはリクエストをWebLogic Serverに非SSLとしてルーティングします)、ロード・バランサにSSLを構成した後、そのドメインでWebLogicプラグインの有効化のフラグをオンにします。フラグをオンにする手順は次のとおりです。

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

2. 左側のナビゲーション・ツリーでドメイン名をクリックします。

3. 「Webアプリケーション」タブをクリックします。

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

5. 「WebLogicプラグインの有効化」を選択します。

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

8.4.3 Oracle WebLogic ServerへのOracle HTTP Serverの登録

Fusion Middleware ControlでOracle HTTP Serverインスタンスを管理および監視するには、これらのインスタンスをドメインに登録する必要があります。これを行うには、次のコマンドを使用してOracle WebLogic ServerへOracle HTTP Serverを登録する必要があります。

WEBHOST1> cd ORACLE_INSTANCE/bin
WEBHOST1> ./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic

このコマンドは、OHS2に対してWEBHOST2からも実行する必要があります。

注意:

登録したOracle HTTP ServerはFusion Middleware Controlで管理可能なターゲットとして表示されます。これを確認するには、Fusion Middleware Controlにログインします。ナビゲーション・ツリーのWeb層の項目にOracle HTTP Serverが登録されていることが示されます。

8.4.4 管理コンソールのフロントエンドURLの設定

管理コンソール・アプリケーションでは、コンソールを使用して、ポート、チャネル、セキュリティに対する変更を追跡します。コンソールから行った変更がアクティブ化されると、コンソールでは現在のリスニング・アドレス、ポートおよびプロトコルを検証します。このリスニング・アドレス、ポートおよびプロトコルがまだ有効の場合、コンソールはHTTPリクエストをリダイレクトし、ホストとポートの情報を管理サーバーのリスニング・アドレスとポートに置き換えます。ロード・バランシング・ルーター(LBR)を使用して管理コンソールにアクセスする場合、ユーザーのWebブラウザが適切なLBRアドレスにリダイレクトされるよう、管理サーバーのフロントエンドURLを変更する必要があります。フロントエンドURLを変更する手順は次のとおりです。

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

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

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

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

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

6. 「プロトコル」タブをクリックします。

7. 「HTTP」タブをクリックします。

8. 「フロントエンド・ホスト」フィールドをadmin.mycompany.com(LBRアドレス)に設定します。

9. 「フロントエンドHTTPポート」を80に設定します。

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

注意:

リダイレクトされないようにするには、管理コンソールの変更の追跡機能を無効にすることをお薦めします。「プリファレンス」メニューの「共有プリファレンス」ダイアログで、「構成変更の追跡」オプションの選択が解除されていることを確認してください。

8.4.5 Oracle HTTP Serverを使用したアクセスの検証

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

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

- 第8.4.5.1項「管理コンソールおよびFusion Middleware Controlの検証」

- 第8.4.5.2項「ロード・バランサを介したアクセスの検証」

8.4.5.1 管理コンソールおよびFusion Middleware Controlの検証

管理コンソールおよびFusion Middleware Controlを、両方のOracle HTTP Serverインスタンスから次のURLを使用して検証できます。

- http://WEBHOSTn:7777/console

- http://WEBHOSTn:7777/em

注意:

フロントエンドURLをLBRアドレスに設定すると、WEBHOSTnアドレスを介したコンソールへのアクセスは、コンソールによってフロントエンドURLにリダイレクトされるので、Oracle HTTP ServerおよびLBRデバイスの両方の構成が正しいことを検証できます。

- http://admin.mycompany.com/console

- http://admin.mycompany.com/em

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

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

次のURLを使用し、ロード・バランサを介してbi_clusterを検証します。

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

- http://bi.mycompany.com/mapviewer

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

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

- http://biinternal.mycompany.com/wsm-pm

- http://bi.mycompany.com/bicomposer

- http://bi.mycompany.com/hr

- http://bi.mycompany.com/calcmgr/index.htm

- http://bi.mycompany.com/aps/Essbase

- http://bi.mycompany.com/aps/SmartView

- http://bi.mycompany.com/workspace

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

8.5 管理サーバーの手動フェイルオーバーの確認

ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。この時点で、第13.5項「APPHOST2への管理サーバーの手動フェイルオーバー」の手順に従って、管理サーバーのフェイルオーバーをテストします。

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

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、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層のミドルウェア・ホームをバックアップします。

WEBHOSTn> tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

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

WEBHOSTn> tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

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

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

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

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

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

APPHOST1> ORACLE_INSTANCE/bin/opmnctl stopall

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

APPHOST1> tar -cvpf BACKUP_LOCATION/bi.tar MW_HOME

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

APPHOST1> tar -cvpf BACKUP_LOCATION/bi_instance_name.tar ORACLE_INSTANCE

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

APPHOST1> ORACLE_INSTANCE/bin/opmnctl startall

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

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

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.2項「共有ファイルの場所の設定」

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

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

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

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

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

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.2項「共有BI Publisher構成フォルダの場所の設定」

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

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

- 第9.2.1.1項「RPD公開ディレクトリの指定」

- 第9.2.1.2項「共有Oracle BI Presentation Catalogの場所の設定」

- 第9.2.1.3項「グローバル・キャッシュの場所の設定」

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システムのスケール・アウト」

- 第9.3.2項「システム・コンポーネントのスケール・アウト」

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

- 第9.3.4項「高可用性環境でのOracle Essbase Studio Serverの使用」

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

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

1. Oracle BIシステムがAPPHOST1上で稼働していることを確認します。

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://admin.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管理対象サーバーのリスニング・アドレスの設定」

- 第9.4.2項「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の追加の構成タスク」

- 第9.5.2項「Oracle RTDの追加の構成タスク」

- 第9.5.3項「BI Publisherの追加の構成タスク」

- 第9.5.4項「Oracle BI Composerの追加の構成タスク」

- 第9.5.5項「Essbaseの追加の構成タスク」

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のクラスタ化プロパティの構成」

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

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 /u01/app/oracle/admin/instancen/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項「BI Publisher Schedulerの構成の更新」

- 第9.5.3.2項「Oracle BI Presentation Servicesとの統合の構成」

- 第9.5.3.3項「Oracle BI EEのデータ・ソースの設定」

9.5.3.1 BI Publisher Schedulerの構成の更新

BI Publisher Schedulerの構成を更新するタスクは次のとおりです。

- 第9.5.3.1.1項「Quartz構成の更新」

- 第9.5.3.1.2項「BI Publisher SchedulerのWebLogic JNDI URLの更新」

- 第9.5.3.1.3項「BI Publisher用のJMSの構成」

- 第9.5.3.1.1項「JMS共有のTempディレクトリの更新」

9.5.3.1.1 Quartz構成の更新

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

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

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

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

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

9.5.3.1.2 BI Publisher SchedulerのWebLogic JNDI URLの更新

次の手順を実行して、BI Publisher Schedulerに対するWebLogic JNDI URLを更新します。

1. 次のURLにアクセスしてBI Publisherにログインします。
http://APPHOST1VHN1:9704/xmlpserver

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

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

4. 次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。
cluster:t3://bi_cluster

5. 「JMSのテスト」をクリックします。
JMSのテストが成功したという確認メッセージが表示されます。

6. 「適用」をクリックします。実行時に適用されるよう、変更内容がクラスタに送信されます。

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

9.5.3.1.3 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.1.4項「JMS共有のTempディレクトリの更新」の手順を実行してください。

9.5.3.1.4 JMS共有のTempディレクトリの更新

この項の手順に従い、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.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.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.5.5 Essbaseの追加の構成タスク

次の手順をEssbaseで実行して、リポジトリ・データベースがOracle 12cの場合、Merant (DataDirect)ドライバのバージョンを7.xに変更します。

APPHOST1およびAPPHOST2の場合:

1. DataDirectスクリプトを実行して、インストール済のMerant (DataDirect)ドライバのバージョンの一覧を表示します。

$ORACLE_HOME/bin/datadirect_version.sh -l
5.3
6.0
6.1
7.0
7.0.1
7.1.2

2. 使用するMerant (DataDirect)ドライバ・バージョンを、7.xに設定します。
$ORACLE_HOME/bin/datadirect_version.sh -i <Oracle BI Instance Directory> -s <Driver Version>.

3. システムのコンポーネントを再起動します。

$ cd /u01/app/oracle/admin/instancen/bin
$ ./opmnctl stopall
$ ./opmnctl startall

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

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

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

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

- 第9.6.2項「APPHOST2でのOracle Business Intelligenceの起動と検証」

- 第9.6.3項「管理対象サーバーのノード・マネージャの構成」

- 第9.6.4項「管理対象サーバーのサーバー移行の構成」

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

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

注意:

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

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

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

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

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

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

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

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

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

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

8. 両方の管理対象サーバーを再起動します。

注意:

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

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

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

- 第9.6.2.1項「bi_server2管理対象サーバーの起動」

- 第9.6.2.2項「Oracle Business Intelligenceシステム・コンポーネントの起動」

- 第9.6.2.3項「Oracle Business IntelligenceのURLの検証」

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

- 第9.6.2.5項「Essbaseのクラスタリングの検証」

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

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

10 エンタープライズ・デプロイメント用のノード・マネージャの設定

この章では、エンタープライズ・デプロイメントの推奨事項に従ってノード・マネージャを構成する方法を説明します。

重要:

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

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

- 第10.1項「ノード・マネージャの設定について」

- 第10.2項「ノード・マネージャのログ・ファイルの場所の変更」

- 第10.3項「ノード・マネージャのホスト名検証証明書の有効化」

- 第10.4項「ノード・マネージャの起動」

10.1 ノード・マネージャの設定について

ノード・マネージャを使用すると、管理サーバーおよび各管理対象サーバーの起動と停止が可能です。

エンタープライズ・デプロイメント・トポロジのノード・マネージャの構成に関して、次の2つの推奨事項があります。

1. ノード・マネージャのログ・ファイルは、デフォルト(ノード・マネージャが存在するMiddlewareホーム内)以外の場所に置くことをお薦めします。詳細は、第10.2項「ノード・マネージャのログ・ファイルの場所の変更」を参照してください。

2. また、ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。この検証では、ドメイン内で使用される複数のアドレスの証明書を使用する必要があります。この章では、ホスト名検証のために各ホストで証明書を構成する手順について説明します。詳細は、第10.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

注意:

このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字をランダムな順序で並べたパスワードを使用します。

10.2 ノード・マネージャのログ・ファイルの場所の変更

BIドメインのすべてのノード上のノード・マネージャ・ログ・ファイルの場所を変更します。場所を変更するには、nodemanager.propertiesファイルを編集します。これは、MW_HOME/wlserver_10.3/common/nodemanagerディレクトリにあります。ログ・ファイルの新しい場所を指定する次の行を追加します。

LogFile=ORACLE_BASE/admin/nodemanager.log

この場所には、MW_HOMEディレクトリの外部にあり、EDGのadminディレクトリの内部にある場所を使用することをお薦めします。

ノード・マネージャを再起動して、変更を有効にします。

10.3 ノード・マネージャのホスト名検証証明書の有効化

ノード・マネージャと管理サーバー間の通信にホスト名検証証明書を構成する手順は次のとおりです。

- ステップ1: utils.CertGenユーティリティを使用した自己署名証明書の生成

- ステップ2: utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

- ステップ3: Keytoolユーティリティを使用したトラスト・キーストアの作成

- ステップ4: カスタム・キーストアを使用するためのノード・マネージャの構成

- ステップ5: カスタム・キーストアを使用するための管理対象サーバーの構成

- ステップ6: 管理対象サーバーのホスト名検証設定の変更

10.3.1 utils.CertGenユーティリティを使用した自己署名証明書の生成

この章で(例として)追加する証明書は、ノード・マネージャが物理ホスト名(APPHOSTn.mycompany.com)でリスニングし、管理対象サーバーが仮想ホスト名(APPHOSTnVHN1.mycompany.com)でリスニングする構成に対応します。管理対象サーバーが仮想ホスト名を使用しているときはいつでも、管理対象サーバーがあるノードから別のノードに移行する可能性があることを意味します。したがって、キーストアおよびトラスト・キーストアを保持するディレクトリは、理想としては、フェイルオーバーが発生してもアクセス可能な共有記憶域に配置する必要があります。同じノードまたは別のノードで別のホスト名を使用する場合は、この例の手順を次のように拡張する必要があります。

- 必要なホスト名(APPHOSTn.mycompany.comおよびAPPHOSTnVHN1.mycompany.com以外のホスト名の場合)を証明書ストアに追加します。

- アイデンティティ・ストアおよびトラスト・ストアの場所に関する情報を、ノード・マネージャ(ノード・マネージャで別のホスト名を使用する場合)またはサーバー(管理対象サーバーで別のホスト名を使用する場合)で変更します。

次の手順に従って、APPHOSTnに自己署名証明書を作成します。これらの証明書はネットワーク名または別名を使用して作成します。自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。

次の例では、APPHOSTn.mycompany.comとAPPHOSTnVHN1.mycompany.comの証明書を構成します。つまり、APPHOSTnで、物理ホスト名(APPHOSTn)と仮想ホスト名(APPHOSTnVHN1)の両方を使用することを前提としています。また、ノード・マネージャが使用するアドレスはAPPHOSTn.mycompany.comであり、管理対象サーバーまたは管理サーバーが使用するアドレスはAPPHOSTnVHN1.mycompany.comであることも前提としています。これは、管理サーバーとOracle Fusion Middlewareコンポーネントをホストするノードや、共存する2つの管理対象サーバーの一方が物理ホスト名をリスニングし、もう一方が仮想ホスト名を使用(移行サーバーを使用するサーバーの場合)するノードで、よく見られる状況です。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を構成します。Bourneシェルの場合、次のコマンドを実行します。

APPHOSTn> cd WL_HOME/server/bin
APPHOSTn> . ./setWLSEnv.sh

次のコマンドを使用して、CLASSPATH環境変数が設定されていることを確認します。

APPHOSTn> echo $CLASSPATH

2. 証明書用のユーザー定義ディレクトリを作成します。たとえば、ORACLE_BASE/admin/domain_name/cluster_nameディレクトリの下にcertsというディレクトリを作成します。証明書はWLSドメイン間で共有できることに注意してください。

APPHOSTn> cd ORACLE_BASE/admin/domain_name/cluster_name
APPHOSTn> mkdir certs

注意:

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSLの構成など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。

3. 前の手順で作成したディレクトリに移動します。

APPHOSTn> cd certs

4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、APPHOSTn.mycompany.comとAPPHOSTnVHN1.mycompany.comの両方の証明書を作成します。
構文(すべてを1行で入力します):

java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name
[export | domestic] [Host_Name]

例:

APPHOSTn> java utils.CertGen password APPHOSTn.mycompany.com_cert
APPHOSTn.mycompany.com_key domestic APPHOSTn.mycompany.com

APPHOSTn> java utils.CertGen password APPHOSTnVHN1.mycompany.com_cert
APPHOSTnVHN1.mycompany.com_key domestic APPHOSTnVHN1.mycompany.com

最初のコマンドの出力例を次に示します。

...... Will generate certificate signed by CA from CertGenCA.der file
...... With Domestic Key Strength
...... Common Name will have Hostname APPHOSTn.mycompany.com
...... Issuer CA name is CN=CertGenCAB,OU=FOR TESTING ONLY,O=MyOrganization,
L=MyTown,ST=MyState,C=US

10.3.2 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

次の手順に従って、APPHOSTnにアイデンティティ・キーストアを作成します。

1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreという名前で新しいアイデンティティ・キーストアを作成します。このキーストアは、証明書と同じディレクトリ(つまり、ORACLE_BASE/admin/domain_name/cluster_name/certs)に作成します。

注意:

utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートする際、アイデンティティ・ストアが1つも存在しない場合は、新しく作成されます。

2. APPHOSTn.mycompany.comとAPPHOSTnVHN1.mycompany.comの両方の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
構文(すべてを1行で入力します):

java utils.ImportPrivateKey Keystore_File Keystore_Password
Certificate_Alias_to_Use Private_Key_Passphrase
Certificate_File Private_Key_File [Keystore_Type]

例:

APPHOSTn> java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity1 password ORACLE_BASE/admin/domain_name/cluster_name/
certs/APPHOSTn.mycompany.com_cert.pem ORACLE_BASE/admin/domain_name/
cluster_name/certs/APPHOSTn.mycompany.com_key.pem

APPHOSTn> java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity1 password ORACLE_BASE/admin/domain_name/
cluster_name/certs/APPHOSTnVHN1.mycompany.com_cert.pem ORACLE_BASE/admin/
domain_name/cluster_name/certs/APPHOSTnVHN1.mycompany.com_key.pem

10.3.3 Keytoolユーティリティを使用したトラスト・キーストアの作成

この項の手順は、最初の管理対象サーバーでのみ実行する必要があります。

APPHOST1上にトラスト・キーストアを作成する手順は次のとおりです。

1. 新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアCA証明書をその証明書と同じディレクトリにコピーします。例:

APPHOST1> cp WL_HOME/server/lib/cacerts ORACLE_BASE/admin/domain_name/cluster_name/certs/appTrustKeyStore.jks

2. 標準のJavaキーストアのデフォルトのパスワードは「changeit」です。デフォルトのパスワードは常に変更することをお薦めします。パスワードを変更するにはkeytoolユーティリティを使用します。構文は、次のとおりです(すべてを1行で入力します)。

APPHOST1> keytool -storepasswd -new New_Password -keystore Trust_Keystore
-storepass Original_Password

例:

APPHOST1> keytool -storepasswd -new password -keystore appTrustKeyStore.jks
-storepass changeit

3. このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用します。これは、WL_HOME/server/libディレクトリにあります。また、このCA証明書は、keytoolユーティリティを使用して、appTrustKeyStoreにインポートする必要があります。構文は、次のとおりです(すべてを1行で入力します)。

APPHOST1> keytool -import -v -noprompt -trustcacerts -alias Alias_Name
-file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password

例:

APPHOST1> keytool -import -v -noprompt -trustcacerts -alias clientCACert -file
WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass
password

10.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成するには、WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity_Keystore
CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password
CustomIdentityAlias=Identity_Keystore_Alias
CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate

各ノードでCustomIdentityAliasの正しい値を使用してください。たとえば、APPHOST1ではappIdentity1を使用します。

たとえば、APPHOST1で次を行います:

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/cluster_name/
certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentity1
CustomIdentityPrivateKeyPassPhrase=password

第10.4項「ノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。このファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

10.3.5 カスタム・キーストアを使用するための管理対象サーバーの構成

この項の手順は、管理サーバーとすべての管理対象サーバーで実行する必要があります。

アイデンティティ・キーストアおよびトラスト・キーストアを構成する手順は次のとおりです。

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

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

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

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

5. アイデンティティ・キーストアとトラスト・キーストアを構成するサーバーの名前(bi_servern)をクリックします。選択したサーバーの設定ページが表示されます。

6. 「構成」→「キーストア」を選択します。

7. 「キーストア」フィールドを、秘密鍵/デジタル証明書の組合せおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法に変更します。

8. 次の手順を使用して、「ID」セクションでアイデンティティ・キーストアの属性を定義します。

1. カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。

ORACLE_BASE/admin/domain_name/aserver/cluster_name/certs/
appIdentityKeyStore.jks

2. カスタムIDキーストアのタイプ: このフィールドは必ず空白にします。デフォルト値はJKSです。

3. カスタムIDキーストアのパスフレーズ: 第10.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」でKeystore_Passwordに指定したパスワードを入力します。
この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。Oracle WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義する必要があるかどうかは、キーストアの要件によって決まります。

9. 次の手順を使用して、「信頼」セクションでトラスト・キーストアのプロパティを定義します。

1. カスタム信頼キーストア: トラスト・キーストアの完全修飾パスを入力します。

ORACLE_BASE/admin/domain_name/cluster_name/certs/
appTrustKeyStore.jks

2. カスタム信頼キーストアのタイプ: このフィールドは必ず空白にします。デフォルト値はJKSです。

3. カスタム信頼キーストアのパスフレーズ: 第10.3.3項「keytoolユーティリティを使用したトラスト・キーストアの作成」でNew_Passwordに指定したパスワードを入力します。
この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。Oracle WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

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

11. チェンジ・センターで、変更のアクティブ化をクリックします。

12. 「構成」→「SSL」を選択します。

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

14. 「秘密鍵の別名」フィールドに、管理対象サーバーがリスニングするホスト名として使用した別名を入力します。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドに、第10.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で作成したキーストアのパスワードを入力します。

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

16. チェンジ・センターで、変更のアクティブ化をクリックします。

10.3.6 管理対象サーバーのホスト名検証設定の変更

前項までの手順を実行した後、影響を受ける管理対象サーバーのホスト名検証を「BEAホスト名の検証」に設定します。すべての管理対象サーバーに対するホスト名検証設定を変更する手順は次のとおりです。

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

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

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

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

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

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

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

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

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

10. チェンジ・センターで、変更のアクティブ化をクリックします。

11. 変更を適用した管理対象サーバーを再起動します。

10.4 ノード・マネージャの起動

MW_HOMEに共通記憶域または共有記憶域のインストールを使用している場合は、同じ基本構成(nodemanager.properties)を使用する別のノードからノード・マネージャを起動します。この場合、バイナリを共有するすべてのノード用の証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加する必要があります。これを行うには、新しいノードの証明書を作成し、第10.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」に従って、appIdentityKeyStore.jksにインポートします。ストア内で証明書が利用可能になった場合、各ノードマネージャでは別のアイデンティティの別名が指定され、正しい証明書が管理サーバーに送信される必要があります。そのためには、各ノードで、ノード・マネージャを起動する前に次のように適切な環境変数を設定します。

APPHOSTn> cd WL_HOME/server/bin
APPHOSTn> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityn

各ホストに明確に割り当てられているカスタムID別名を指定してください。たとえば、APPHOST1の場合はappIdentity1、APPHOST2の場合はappIdentity2を指定します。

注意:

ノード・マネージャの出力から、ノード・マネージャが適切なストアおよび別名を使用していることを確認します。ノード・マネージャ出力は次のように表示されます。

CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/cluster_name/certs/appIdentityKeyStore.jks
CustomIdentityAlias=appIdentityn

ここでnは1、2、...です。

MW_HOMEに共通記憶域または共有記憶域のインストールを使用していない場合、次の手順を実行して、APPHOSTnでノード・マネージャを再起動するためのコマンドを実行します。

1. ノード・マネージャのプロセスを起動したシェルで[Ctrl]キーを押しながら[C]キーを押すか、オペレーティング・システムでプロセスを確認してkillコマンドを使用し、ノード・マネージャを停止します。

2. ノード・マネージャを次のように起動します。

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

注意:

ノード・マネージャが未構成で、1回も起動していない場合は、ORACLE_COMMON_HOME/common/bin/setNMProps.shスクリプトを実行します。このスクリプトにより、Oracle Business Intelligenceに必要な起動スクリプトを使用できるようになります。

11 エンタープライズ・デプロイメント用のサーバー移行の構成

この章では、Oracle Business Intelligenceエンタープライズ・デプロイメントのサーバー移行を構成する手順について説明します。

重要:

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

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

- 第11.1項「エンタープライズ・デプロイメント用のサーバー移行の概要」

- 第11.2項「サーバー移行leasing表のユーザーと表領域の設定」

- 第11.3項「管理コンソールを使用したマルチ・データ・ソースの作成」

- 第11.4項「ホスト名検証証明書の有効化」

- 第11.5項「ノード・マネージャのプロパティ・ファイルの編集」

- 第11.6項「wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定」

- 第11.7項「サーバー移行ターゲットの構成」

- 第11.8項「サーバー移行のテスト」

11.1 エンタープライズ・デプロイメント用のサーバー移行の概要

bi_server1とbi_server2の管理対象サーバーにサーバー移行を構成します。サーバー移行を構成しておくことで、障害が発生した場合でも、bi_server1管理対象サーバーはAPPHOST2で再起動し、bi_server2管理対象サーバーはAPPHOST1で再起動します。このような構成では、bi_server1サーバーおよびbi_server2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。

次の項の手順を実行し、管理対象サーバーのサーバー移行を構成します。

11.2 サーバー移行leasing表のユーザーと表領域の設定

create tablespace leasingコマンドを使用して、サーバー移行リース・テーブルのユーザーおよび表領域を設定します。

サーバー移行leasing表のユーザーと表領域を設定する手順は次のとおりです。

1. leasingという表領域を作成します。たとえば、ユーザーsysdbaでSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by password;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

3. 次の手順を実行して、leasing.ddlスクリプトを使用してleasing表を作成します。

1. 次のディレクトリにあるデータベース・バージョンに対応したleasing.ddlファイルをコピーします。

WL_HOME/server/db/oracle/db_version

2. leasingユーザーとしてデータベースに接続します。

3. leasing.ddlスクリプトをSQL*Plusで実行します。

SQL> @copy_location/leasing.ddl;

11.3 管理コンソールを使用したマルチ・データ・ソースの作成

Oracle WebLogic Server管理コンソールでリース・テーブルのマルチデータ・ソースを作成します。

マルチデータ・ソースの設定プロセス中に、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバル・リース・マルチデータ・ソースの両方に対して作成します。データ・ソースを作成する前に、次の準備が必要です。

- 非XAデータ・ソースであることを確認します。

- マルチ・データ・ソースの名前は、<MultiDS>-rac0や<MultiDS>-rac1という形式にします。

- Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。

- データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」サブオプションを選択しない)で、データベースのサービス名を指定します。

- これらのデータ・ソースをbi_clusterにターゲット指定します。

- データ・ソースの初期接続プール容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」を選択し、「データ・ソース」を選択します。「データ・ソース」リストでデータ・ソースの名前をクリックし、「接続プール」タブをクリックして「初期容量」フィールドに0(ゼロ)を入力します。

Oracle RACのマルチデータ・ソースの設定に関するその他の推奨事項は、『Oracle Fusion Middleware高可用性ガイド』の高可用性Oracle Databaseアクセスの考慮事項に関する項を参照してください。

マルチ・データ・ソースを作成する手順は次のとおりです。

1. 管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「データ・ソース」をクリックします。「JDBCデータ・ソースのサマリー」ページが表示されます。

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

3. 「新規」をクリックし、「マルチ・データ・ソース」を選択します。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。

4. 「名前」には、leasingと入力します。

5. 「JNDI名」には、jdbc/leasingと入力します。

6. 「アルゴリズムのタイプ」では、「フェイルオーバー」(デフォルト)を選択します。

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

8. 「ターゲットの選択」ページで、ターゲットとして「bi_cluster」を選択します。

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

10. 「データ・ソースのタイプを選択」ページで、「非XAドライバ」(デフォルト)を選択します。

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

12. 「新しいデータ・ソースの作成」をクリックします。

13. 「名前」には、leasing-rac0と入力します。「JNDI名」には、jdbc/leasing-rac0と入力します。「データベース・タイプ」では、「Oracle」を選択します。

注意:

leasing表のマルチ・データ・ソースを作成する場合、名前は<MultiDS>-rac0、<MultiDS>-rac1という形式で入力します。

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

15. 「データベース・ドライバ」では、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10以降を選択します。

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

17. 「グローバル・トランザクションのサポート」の選択を解除します。

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

19. leasingスキーマの詳細を次のように入力します。

- サービス名: データベースのサービス名を入力します。

- データベース名: Oracle RACデータベースの最初のインスタンスのインスタンス名を入力します。

- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、最初のインスタンスのVIP名またはノード名をホスト名として指定します。

- ポート: データベースのポート番号(1521)を入力します。

- データベース・ユーザー名: leasingと入力します。

- パスワード: leasingのパスワードを入力します。

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

21. 「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。

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

23. 「ターゲットの選択」ページで、ターゲットとして「bi_cluster」を選択します。

24. 「終了」をクリックします。

25. Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをbi_clusterに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。

26. 「データ・ソースの追加」ページで、leasing-rac0とleasing-rac1を「選択済み」リストに移動することによって、それらをデータ・ソースに追加します。

27. 「終了」をクリックします。

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

11.4 ホスト名検証証明書の有効化

ノード・マネージャと管理サーバー間のホスト名検証用に適切な証明書を作成します。この手順は、第10.3項「ノード・マネージャでのホスト名検証証明書の有効化」で説明されています。まだこれらの証明書を作成していない場合は、この項の手順を実行して、ノード・マネージャと管理サーバー間でホスト名を検証するための証明書を作成します。

11.5 ノード・マネージャのプロパティ・ファイルの編集

ノード・マネージャのプロパティ・ファイルを、サーバー移行を構成する両方のノードで編集します。nodemanager.propertiesファイルは次のディレクトリにあります。

WL_HOME/common/nodemanager

次のプロパティを追加してサーバー移行が正常に動作するようにします。

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

- Interface: このプロパティは、浮動IPのインタフェース名(たとえば、eth0)を指定します。
サブインタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

- NetMask: このプロパティは浮動IP用インタフェースのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じです。このドキュメントの例では、255.255.255.0が使用されています。

- UseMACBroadcast: このプロパティは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、言い換えれば、arpingコマンドで-bフラグを使用するかどうかを指定します。

ノード・マネージャの出力(ノード・マネージャが起動するシェル)で、これらのプロパティが適用されていることを確認します。適用されていないと、移行中に問題が発生する可能性があります。出力は、次のようなものです。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:

サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

1. nodemanager.propertiesファイルで次のプロパティを設定します。

- StartScriptEnabled: このプロパティをtrueに設定します。この設定は、ノード・マネージャが起動スクリプトを使用して管理対象サーバーを起動するために必要です。

2. APPHOST1とAPPHOST2でノード・マネージャを起動するには、WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行します。

注意:

共有記憶域インストールからノード・マネージャを実行する場合、同じnodemanager.propertiesファイルを使用して複数のノードが起動されます。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個別にパラメータを指定します。たとえば、HOSTnで別のインタフェース(eth3)を使用するには、Interface環境変数を次のように使用します。

HOSTn> export JAVA_OPTIONS=-DInterface=eth3

この変数がシェル内で設定された後、ノード・マネージャを起動します。

11.6 wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定

wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。

1. 表11-1に示すファイルをPATH環境変数で指定していることを確認します。

表11-1 PATH環境変数に必要なファイル

ファイル

ディレクトリの場所

wlsifconfig.sh

ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

WL_HOME/common/nodemanager

2. wlsifconfig.shスクリプトに対するsudo構成権限の付与

- パスワードの要求がなくても動作するようにsudoを構成します。

- セキュリティ上の理由から、sudo権限の付与はwlsifconfig.shスクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。

1. パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

2. WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。/etc/sudoers内の次のエントリ例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

注意:

この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。

3. ノード・マネージャを再起動して、変更を有効にします。

11.7 サーバー移行ターゲットの構成

この項では、サーバー移行ターゲットを構成します。「クラスタの移行の構成」では、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。

クラスタ内の移行を構成する手順は次のとおりです。

1. 管理コンソール(http://Host:Admin_Port/console)にログインします。通常、Admin_Portは7001(デフォルト)です。

2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

3. 移行を構成する対象となるクラスタ(bi_cluster)を、表の「名前」列でクリックします。

4. 「移行」タブをクリックします。

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

6. 「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「APPHOST1」と「APPHOST2」を選択します。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。

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

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

10. サーバー移行の候補となるマシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

2. 移行を構成するサーバーを選択します。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。bi_server1の場合は、APPHOST2を選択します。bi_server2の場合は、APPHOST1を選択します。

5. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
このアクションにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

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

11. 管理サーバー、ノード・マネージャ、管理対象サーバーおよびサーバー移行が構成されているシステム・コンポーネントを再起動します。

ヒント:

サーバーが実行されているマシンを表示するには、「サーバーのサマリー」ページで「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウに移動します。この手順は、サーバーが自動的に移行される構成と、内容が異なります。

11.8 サーバー移行のテスト

サーバー移行が適切に機能していることを確認する手順は次のとおりです。

APPHOST1から:

1. bi_server1管理対象サーバーを停止します。そのためには、次のコマンドを実行します。

APPHOST1> kill -9 pid

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

APPHOST1> ps -ef | grep bi_server1

2. ノード・マネージャのコンソールを確認します。bi_server1の浮動IPが無効になっていることを示すメッセージが表示されます。

3. ノード・マネージャがbi_server1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャによってログに記録されます。

APPHOST2から:

1. ローカルのノード・マネージャのコンソールを確認します。ノード1でbi_server1の再起動が最後に試行されてから30秒経過した後、ノード2のノード・マネージャによって、bi_server1の浮動IPが有効化されようとしていること、およびこのノードでサーバーが再起動されようとしていることが示されます。

2. 同じIPを使用していずれかのアプリケーション(BI Publisherなど)にアクセスします。

管理コンソールからの検証

管理コンソールで移行を検証する手順は次のとおりです。

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

2. 左側のコンソールで、「ドメイン」をクリックします。

3. 「監視」タブ→「移行」タブをクリックします。
次の図に示すとおり、「移行ステータス」表には、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後、そのサーバーを元のノード/コンピュータにフェイルバックさせるには、管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたコンピュータ上の管理対象サーバーを起動します。

12 エンタープライズ・デプロイメントとOracle Identity Managementの統合

この章では、Oracle Business IntelligenceをOracle Identity Managementと統合する方法について説明します。

この章の手順を実行する前に、次の両方で説明されているインストールと構成の手順が正常に完了している必要があります。

- Oracle Fusion Middleware Oracle Identity Managementのエンタープライズ・デプロイメント・ガイド

- このガイドの前章までの各章

重要:

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

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

- 第12.1項「資格証明ストアとポリシー・ストアの構成」

- 第12.2項「Oracle Access Manager 10gの統合」

- 第12.3項「Oracle Access Manager 11gの統合」

- 第12.4項「アイデンティティ管理構成のバックアップ」

12.1 資格証明ストアとポリシー・ストアの構成

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

- 第12.1.1項「資格証明ストアとポリシー・ストアの構成の概要」

- 第12.1.2項「資格証明ストアの構成」

- 第12.1.3項「ポリシー・ストアの構成」

- 第12.1.4項「資格証明とポリシーの再関連付け」

- 第12.1.5項「アイデンティティ・ストアの再関連付けの後のユーザーGUIDのリフレッシュ」

12.1.1 資格証明ストアとポリシー・ストアの構成の概要

Oracle Fusion Middlewareでは、WebLogicドメインで様々なタイプの資格証明ストアとポリシー・ストアを使用できます。ドメインでは、XMLファイルに基づくストアまたは様々なタイプのLDAPプロバイダに基づくストアを使用できます。ドメインでLDAPストアを使用する場合は、すべてのポリシー・データと資格証明データが、一元化されたストアで保持および管理されます。ただし、XMLポリシー・ストアを使用している場合、管理対象サーバーへの変更は、同じドメイン・ホームを使用していなければ管理サーバーには伝播されません。Oracle Business IntelligenceのEDGトポロジでは、管理サーバーと管理対象サーバーに異なるドメイン・ホームを使用します。したがって、整合性および一貫性を保持するため、LDAPストアをポリシー・ストアおよび資格証明ストアとして使用する必要があります。

デフォルトでは、Oracle WebLogic Serverドメインは、ポリシー・ストアにXMLファイルを使用します。次の各項では、資格証明およびポリシーのデフォルトのストアをOracle Internet Directory LDAPに変更するために必要な手順について説明します。

注意:

ポリシー・ストアおよび資格証明ストアのバックエンド・リポジトリは、同じ種類のLDAPサーバーを使用する必要があります。こうした一貫性を保持するために、一方のストアを再関連付けすると、他方のストアも再関連付けされることに注意してください。すなわち、Oracle Enterprise ManagerのFusion Middleware ControlまたはWLSTコマンドのreassociateSecurityStoreを使用して、資格証明ストアとポリシー・ストアの再関連付けが1つの単位として実行されます。

12.1.2 資格証明ストアの構成

この項では、資格証明ストアを構成する方法について説明します。項目は次のとおりです。

- 第12.1.2.1項「ユーザーとグループの作成」

- 第12.1.2.2項「構成ファイルのバックアップ」

- 第12.1.2.3項「LDAPを使用するアイデンティティ・ストアの構成」

- 第12.1.2.4項「プロバイダの順序の設定」

- 第12.1.2.5「WebLogic管理者のLDAPへの移行」

12.1.2.1 ユーザーとグループの作成

Oracle Internet Directoryで、必要なユーザーとグループがまだ作成されていない場合、それらを作成します。詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』および『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』の第3章「代替認証プロバイダの使用」を参照してください。

12.1.2.2 構成ファイルのバックアップ

ファイルの最新バージョンのコピーを常に保持するように、まず次の関連する構成ファイルをバックアップします。

- ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml

- ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/
jps-config.xml

- ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/
system-jazn-data.xml

管理サーバーの boot.properties ファイルもバックアップします。

12.1.2.3 LDAPを使用するアイデンティティ・ストアの構成

Oracle WebLogic Server管理コンソールを使用して適切な認証プロバイダを設定することにより、LDAPを使用するように資格証明ストアを構成する手順は次のとおりです。

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

2. 左のナビゲーション・バーにある「セキュリティ・レルム」リンクをクリックします。

3. myrealmデフォルト・レルム・エントリをクリックして構成します。

4. レルム内で「プロバイダ」タブを開きます。レルムにはDefaultAuthenticatorプロバイダが構成されていることに注意してください。

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

6. 「新規」をクリックして、新しいプロバイダを追加します。

7. OIDAuthenticatorなどのプロバイダ名を入力します。

8. 認証プロバイダのリストから「OracleInternetDirectoryAuthenticator」タイプを選択します。

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

10. 「プロバイダ」画面で、新しく作成した認証プロバイダをクリックします。

11. 制御フラグをSUFFICIENTに設定します。これは、この認証プロバイダによってユーザーを正常に認証できる場合、その認証は受け入れられ、他の認証プロバイダは呼び出されないことを示します。認証が失敗した場合、チェーン内の次の認証プロバイダに渡されます。
後続のすべての認証プロバイダでも、制御フラグがSUFFICIENTに設定されていることを確認してください。特に、DefaultAuthenticatorをチェックして、必要であればSUFFICIENTに設定します。

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

13. 「プロバイダ固有」タブを開き、表12-1に示すように、LDAPサーバーに固有の詳細を入力します。

表12-1 LDAPサーバーの詳細

パラメータ

値

説明

ホスト

例: oid.mycompany.com

LDAPサーバーのホスト名。

ポート

例: 636

LDAPサーバーのポート番号。

プリンシパル

例: cn=orcladmin

LDAPサーバーに接続するために使用されるLDAPユーザーDN。

資格証明

your_password

LDAPサーバーへの接続に使用されるパスワード。

SSLの有効化

選択

LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。

ユーザー・ベースDN

例:

cn=Users、dc=mycompany、
dc=com

ユーザーが開始時に使用するDNを指定します。

グループ・ベースDN

例: cn=Groups、dc=mycompany、
dc=com

グループ・ノードを指すDNを指定します。

ユーザー名属性

cn

ユーザー名属性。

取得したユーザー名をプリンシパルとして使用する

選択

このオプションは有効にする必要があります。

14. 完了したら「保存」をクリックします。

15. 「変更のアクティブ化」をクリックして変更を伝播します。

16. 管理サーバーおよび管理対象サーバーを再起動します。

12.1.2.4 プロバイダの順序の設定

OID認証プロバイダおよびデフォルト認証プロバイダを並べ替えて、各認証プロバイダの制御フラグが次のように設定されていることを確認します。

- OID LDAP認証プロバイダ: SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

管理サーバー、管理対象サーバーおよびOracle Business Intelligenceシステム・コンポーネントを再起動します。

12.1.2.5 WebLogic管理者のLDAPへの移行

LDAPの構成後は、すべてのユーザー(管理ユーザーも含む)がLDAPユーザーである必要があります。この構成は、LDAP管理者が実行する必要があります。必要なユーザーで管理グループを作成します。必要な手順の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のOracle Identity Managerのユーザーおよびグループの作成に関する項を参照してください。グループ名には、BIAdministratorsを使用します。

このグループが作成されたら、Oracle WebLogic Serverで次の手順を実行して、WLSグローバル管理ロールに対するロール定義を更新します。

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

2. 管理ロールを定義するには、「セキュリティ・レルム」を選択してレルム名を選択し、「ロールとポリシー」→「グローバル・ロール」→「ロール」→「管理」を選択します。「ロール条件の表示」リンクをクリックします。
デフォルトでは、Oracle Internet DirectoryのAdministratorsグループにより、Oracle WebLogic Serverでどのユーザーが管理ロールを付与されるかが定義されます。

3. 「条件の追加」をクリックして、別のグループ名(BIAdministrators)を追加します。次に、Administratorsグループを削除し、新しく追加したグループは残します。

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

5. この変更を行った後は、指定した新しいグループのメンバーに、Oracle WebLogic Serverを管理する権限が付与されます。

12.1.2.5.1 boot.propertiesファイルの更新およびシステムの再起動

管理サーバーのboot.propertiesファイルを、Oracle Internet Directoryで作成されたWebLogic管理ユーザーで更新する必要があります。boot.propertiesファイルを更新する手順は次のとおりです。

1. APPHOST1で、次のディレクトリに変更します。

APPHOST1> cd ORACLE_BASE/admin/domain_name/aserver/
domain_name/servers/AdminServer/security

2. 既存の boot.properties ファイルの名前を変更します。

APPHOST1> mv boot.properties boot.properties.backup

3. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

username=admin_user
password=admin_user_password

4. ファイルを保存します。

5. 管理サーバーを停止し、再起動します。

12.1.3 ポリシー・ストアの構成

ドメイン・ポリシー・ストアは、システム固有のポリシーおよびアプリケーション固有のポリシーのリポジトリです。特定のドメインには、そのドメインにデプロイされるすべてのアプリケーションが使用可能なすべてのポリシーを格納する1つのストアが存在します。この項では、Oracle Internet Directory LDAPをOracle Business Intelligence EDGトポロジのポリシー・ストアとして構成する手順について説明します。

ポリシー・ストアとして使用されるOracle Internet Directory LDAPサーバー・ディレクトリへの適切なアクセスを確保するには、サーバー・ディレクトリ内にノードを設定する必要があります。

Oracle Internet Directory管理者として、次の手順に従って、Oracle Internet Directoryサーバーに適切なノードを作成します。

1. 次のDNエントリおよびCNエントリを指定して、LDIFファイル(この例ではjpstestnode.ldif)を作成します。

dn: cn=jpsroot_bi,dc=mycompany,dc=com
cn: jpsroot_bi
objectclass: top
objectclass: OrclContainer

ルート・ノードのDN(前の手順のjpsroot_bi)は、他のDNと異なっている必要があります。1つのルート・ノードを複数のWebLogicドメインが共有できます。サブツリーに対する読取りアクセス権および書込みアクセス権がOracle Internet Directory管理者に付与されていれば、このノードを最上位レベルに作成する必要はありません。

2. 次の例に示すように、コマンドldapaddを使用してこのデータをOracle Internet Directoryサーバーにインポートします。

OIDHOST1> ORACLE_HOME/bin/ldapadd -h ldap_host -p ldap_port -D cn=orcladmin
-w password -c -v -f jpstestnode.ldif

3. 次の例に示すように、コマンドldapsearchを使用してノードが正常に挿入されたことを確認します。

OIDHOST1> ORACLE_HOME/bin/ldapsearch -h ldap_host -p ldap_port -D cn=orcladmin
-w password -b "cn=jpsroot_bi,dc=mycompany,dc=com" objectclass="orclContainer"

4. Oracle Internet DirectoryをLDAPベースのポリシー・ストアとして使用する場合は、oidstats.sqlユーティリティをINFRADBHOSTで実行し、最適なデータベース・パフォーマンスを実現するためにデータベース統計を生成します。

OIDHOST1> connect ods/password
OIDHOST1> @ORACLE_HOME/ldap/admin/oidstats.sql

注意: oidstats.sqlユーティリティを実行する必要があるのは、初期プロビジョニング後の1回のみです。

12.1.4 資格証明とポリシーの再関連付け

WLSTのreassociateSecurityStoreコマンドを使用して、ポリシー・ストアおよび資格証明ストアをOracle Internet Directoryに再関連付けする手順は次のとおりです。

1. APPHOST1から、wlstシェルを起動します。

APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./wlst.sh

2. wlstのconnectコマンドを次のように使用して、WebLogic管理サーバーに接続します。

connect ("AdminUser", "AdminPassword", "t3://hostname:port")

例:

connect ("weblogic", "password", "t3://ADMINVHN:7001")

3. reassociateSecurityStoreコマンドを次のように実行します。

reassociateSecurityStore(domain="domainName", admin="cn=admin_user_name",
password="orclPassword", ldapurl="ldap://LDAPHOST:LDAPPORT", servertype="OID",
jpsroot="cn=jpsroot_bi")

例:

wls:/bifoundation_domain/serverConfig>
reassociateSecurityStore(domain="bifoundation_domain", admin="cn=orcladmin",
password="password", ldapurl="ldap://oid.mycompany.com:389", servertype="OID",
jpsroot="cn=jpsroot_bi,dc=mycompany,dc=com")

4. コマンドが正常に完了した後に、管理サーバーを再起動します。

注意:

資格証明とポリシーの変更を有効にするには、ドメイン内のサーバーを再起動する必要があります。

12.1.5 アイデンティティ・ストアの再関連付けの後のユーザーGUIDのリフレッシュ

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

- 第12.1.5.1項「ユーザーGUIDについて」

- 第12.1.5.2項「GUIDのリフレッシュについて」

- 第12.1.5.3項「ユーザーGUIDのリフレッシュ」

12.1.5.1 ユーザーGUIDについて

Oracle Business Intelligence 11g リリース1(11.1.1)では、ユーザーは、その名前ではなく、グローバル一意識別子(GUID)によって認識されます。GUIDは、特定のユーザーに対する完全に一意な識別子です。GUIDを使用してユーザーを識別することにより、特定のユーザーのデータとメタデータが、ユーザー名に関係なく一意に保護されるので、セキュリティ・レベルが向上します。

次の2つのベスト・プラクティスを実践して、開発から本番までのライフサイクルの各フェーズでGUIDが一貫して適用されることを保証することをお薦めします。

- 開発システム、テスト・システムおよび本番システムの間でアイデンティティ・ストアのファンアウト・レプリカを使用するようにして、開発から本番までのライフサイクル全体を通じてユーザーGUIDを一貫して同一にします。ファンアウト・レプリカの作成の詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのレプリケーションの設定に関する項を参照してください。

- 可能なかぎり、個々のユーザーではなくアプリケーション・ロールを使用して、データとメタデータへのアクセスを保護します。

12.1.5.2 GUIDのリフレッシュについて

GUIDのリフレッシュ(GUIDの同期またはGUIDの再生成とも呼ばれる)とは、Oracle BIリポジトリおよびOracle BIプレゼンテーション・カタログ内のユーザーGUIDに対するメタデータ参照を更新するプロセスです。GUIDリフレッシュ・プロセスにおいて、各ユーザー名がアイデンティティ・ストアで検索されます。次に、そのユーザー名に関連付けられているGUIDに対するすべてのメタデータ参照が、アイデンティティ・ストア内のGUIDで置き換えられます。

GUIDのリフレッシュは、Oracle Business Intelligenceが同一ユーザーに対して異なるGUIDを持つアイデンティティ・ストアに再度関連付けられる場合に必要となります。この状況は、Oracle Business Intelligenceを別のタイプのアイデンティティ・ストアに再関連付けする場合に発生する可能性がありますが、通常はほとんど発生することはありません。

Oracleのベスト・プラクティスが実施されず、Oracle Business Intelligenceリポジトリ・データが、同一ユーザーに対して異なるGUIDを持つシステム間で移行される場合、システムを機能させるには、GUIDのリフレッシュが必要です。この実践は、特定のユーザー(たとえば2週間前に退職したJohn Smith)のみがアクセスできるように保護されているデータとメタデータに、別のユーザー(たとえば先週入社したJohn Smith)がアクセスできるようになるというリスクが生じるので、お薦めできません。可能なかぎりアプリケーション・ロールを使用して、開発から本番までのライフサイクル全体を通じて一貫してGUIDを使用することにより、この問題の発生を防ぐことができます。

12.1.5.3 ユーザーGUIDのリフレッシュ

ユーザーGUIDをリフレッシュするには、APPHOST1およびAPPHOST2上で次の手順を実行します。GUIDのリフレッシュは、一度に1つのノードのみが動作している状態で行う必要があることに注意してください。

1. ユーザーGUIDをリフレッシュしているノード以外のすべてのノード上でOracle BI ServerおよびPresentation Servicesを停止します。例:

cd ORACLE_BASE/admin/instancen/bin
./opmnctl stopproc ias-component=coreapplication_obips1
./opmnctl stopproc ias-component=coreapplication_obis1

2. 次の手順を使用して、NQSConfig.INIファイル内でFMW_UPDATE_ROLE_AND_USER_REF_GUIDSパラメータを更新します。

1. 次のディレクトリで、NQSConfig.INIファイルを編集用に開きます。

ORACLE_INSTANCE/config/OracleBIServerComponent/coreapplication_obisn

2. FMW_UPDATE_ROLE_AND_USER_REF_GUIDSパラメータを探して、次のようにYESに設定します。

FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = YES;

3. ファイルを保存して閉じます。

3. 次の手順を使用して、instanceconfig.xmlファイルにあるCatalog要素を更新します。

1. 次のディレクトリで、instanceconfig.xmlファイルを編集用に開きます。

ORACLE_INSTANCE/config/OracleBIPresentationServicesComponent/
coreapplication_obipsn

2. Catalog要素を探して、次のように更新します。

<Catalog>
<UpgradeAndExit>false</UpgradeAndExit>
<UpdateAccountGUIDs>UpdateAndExit</UpdateAccountGUIDs>
</Catalog>

3. ファイルを保存して閉じます。

4. GUIDをリフレッシュしているノードで、opmnctlコマンドを使用してOracle BI ServerおよびPresentation Servicesを停止してから再起動します。

cd ORACLE_BASE/admin/instancen/bin
./opmnctl stopproc ias-component=coreapplication_obips1
./opmnctl stopproc ias-component=coreapplication_obis1
./opmnctl startproc ias-component=coreapplication_obis1

Oracle BI Serverが実行されていることを確認したら、Presentation Servicesを起動します。

./opmnctl startproc ias-component=coreapplication_obips1

5. NQSConfig.INIファイルで、FMW_UPDATE_ROLE_AND_USER_REF_GUIDSパラメータをNOに戻します。
重要: システムを確実に保護するために、この手順を実行する必要があります。

6. instanceconfig.xmlのCatalog要素を更新して、UpdateAccountのGUIDエントリを削除します。

7. opmnctlコマンドを使用して、Oracle Business Intelligenceシステム・コンポーネントを再起動します。

cd ORACLE_BASE/admin/instancen/bin
./opmnctl stopall
./opmnctl startall

12.2 Oracle Access Manager 10gの統合

この項では、Oracle Access Manager 10gをOracle Business Intelligenceトポロジに対するシングル・サインオン・ソリューションとして構成する方法について説明します。

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

- 第12.2.1項「Oracle Access Managerの統合について」

- 第12.2.2項「Oracle Access Manager構成ツールの使用」

- 第12.2.3項「ホスト識別子の更新」

- 第12.2.4項「Webゲート・プロファイルの更新」

- 第12.2.5項「Webゲートのインストールと構成」

- 第12.2.6項「WebゲートのIP検証の構成」

- 第12.2.7項「WebLogic認証プロバイダの設定」

- 第12.2.8項「アプリケーションの構成」

12.2.1 Oracle Access Managerの統合について

Oracle Access Manager 10gの場合の手順では、Access Managerおよびポリシー・マネージャを保護するポリシーを備えたOracle Access Managerインストールが存在することを前提としています。Oracle Access Managerインストールのインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

この章で説明する構成には、Oracle Internet Directoryなどのディレクトリ・サービスがスタンドアロン・コンポーネントとして、またはOracle Virtual Directory構成の一部として、含まれています。この項では、Oracle Internet Directoryを使用するようにOracle Business Intelligenceインストールを構成するために必要な手順について説明します。

また、Oracle Access Managerインストールには、Webゲートを使用するように構成された独自のWebサーバーが必要です。この項では、Oracle Access Manager Webサーバーを委任認証サーバーとして使用するための手順も説明します。

12.2.2 Oracle Access Manager構成ツールの使用

この項では、Oracle Access Manager構成ツールを使用する方法について説明します。項目は次のとおりです。

- 第12.2.2.1項「Oracle Access Manager構成ツールについて」

- 第12.2.2.2項「Oracle Access Manager構成ツールで使用する情報の収集」

- 第12.2.2.3項「Oracle Access Manager構成ツールの実行」

- 第12.2.2.4項「ポリシー・ドメインおよびアクセス・ゲートを正常に作成したことの確認」

12.2.2.1 Oracle Access Manager構成ツールについて

Oracle Access Manager構成ツール(oamcfgtool)は、一連のスクリプトを起動して必要なポリシーを設定します。そのためには、入力情報として様々なパラメータが必要となります。具体的には、このツールにより次の項目が作成されます。

- Oracle Access Managerのフォーム認証スキーム

- Oracle WebLogic Serverでの認証を可能にするポリシー

- Oracle HTTP ServerのWebゲートが(Web層から)構成済アプリケーションを保護できるようにするOracle Access ManagerのWebゲート・エントリ

- 選択したシナリオに応じたホスト識別子(指定しない場合はデフォルトのホスト識別子が使用されます)

- アプリケーション固有のURLを保護するポリシーおよび保護対象としないポリシー

12.2.2.2 Oracle Access Manager構成ツールで使用する情報の収集

Oracle Access Manager構成ツールを実行する前に、次の情報を収集または準備します。

- パスワード: セキュアなパスワードを作成します。このパスワードは、後で実行するWebゲート・インストールのパスワードとして使用します。

- LDAPホスト: HA/EDG構成の場合のディレクトリ・サーバーのホスト名またはロード・バランサ・アドレス。

- LDAPポート: ディレクトリ・サーバーのポート番号。

- LDAPユーザーDN: LDAP管理者ユーザーのDN(例: cn=orcladmin)。

- LDAPパスワード: LDAP管理者ユーザーのパスワード。

- OAM_AA_HOST: Oracle Access Managerインスタンスのホスト名。

- OAM_AA_PORT: Oracle Access Managerのポート番号。

12.2.2.3 Oracle Access Manager構成ツールの実行

Oracle Access Manager構成ツールは、次のディレクトリにあります。

MW_HOME/oracle_common/modules/oracle.oamprovider_11.1.1

このツールは、必要なインストール・ファイルが存在する任意のコンピュータから実行できます。ここでは、APPHOST1から実行します。

注意:

Oracle Identity Managementと統合する場合は、Oracle Identity Managementサーバーで現在使用中のトランスポート・モードを使用します。たとえば、オープン、簡易または証明書モードなどです。

次のコマンドを使用して、ツールを実行する前にJAVA_HOME値を設定します。

export JAVA_HOME=$MW_HOME/jrockit_160_05_R27.6.2-20

Oracle Access Manager構成ツールを次のように実行します(すべてを1行で入力します)。

$JAVA_HOME/bin/java -jar oamcfgtool.jar mode=CREATE
app_domain="bifoundation_domain" protected_uris="$PROTECTED_URI_LIST"
public_uris="$PUBLIC_URI_LIST" ldap_host="oid.mycompany.com" ldap_port=389
ldap_userdn="cn=LDAP_admin_user_name"
ldap_userpassword=LDAP_admin_user_password oam_aaa_host=OAMHOST1
oam_aaa_port=OAMPORT1 oam_aaa_mode=simple

$PROTECTED_URI_LISTには、次の値を使用します。

"/bicontent,/mapviewer,/em/.../*,/console/.../*,/aps,/calcmgr,/hr, /workspace,/analytics/saw.dll,/xmlpserver,/ui,/em,/console,/ui/adfAuthentication,/mobile,/mobile/.../*"

$PUBLIC_URI_LISTには、次の値を使用します。

"/analytics,/analytics/saw.dll/wsdl,/analytics-ws/saw.dll,/xmlpserver/services,
/xmlpserver/report_service,/xmlpserver/ReportTemplateService.xls,
/xmlpserver/Guest,/ui/do/logout,/ui/images,/biservices"

app_agent_passwordを入力するように求められます。

注意:

後で別のURLの保護が必要になった場合は、同じapp_domainを使用して、再度Oracle Access Manager構成ツールを実行します。新しいURLのみではなく、保護する必要があるすべてのURLを指定してください。

12.2.2.4 ポリシー・ドメインおよびアクセス・ゲートが正常に作成されたことの確認

この項では、ポリシー・ドメインとアクセス・ゲートが正常に作成されたことを確認する方法について説明します。

ポリシー・ドメインの確認

ポリシー・ドメインを確認する手順は次のとおりです。

1. 次の場所でOracle Access Managerにログオンします:
http://OAMADMINHOST:port/access/oblix

2. 「ポリシー・マネージャ」をクリックします。

3. 左側のパネルで「ポリシー・ドメイン」リンクをクリックします。作成したドメインを含む、すべてのポリシー・ドメインのリストが表示されます。

4. 作成したポリシー・ドメインへのリンクをクリックします。このドメインの「一般」領域が表示されます。

5. 「リソース」タブをクリックします。指定したURIが表示されます。他のタブをクリックし、他の設定を表示することもできます。

アクセス・ゲート構成の確認

アクセス・ゲート構成を確認する手順は次のとおりです。

1. 右上にある「アクセス・システム・コンソール」リンクをクリックします。このリンクは、クリックするたびに「アクセス・システム・コンソール」と「ポリシー・マネージャ」が切り替わります。

2. 「アクセス・システム構成」タブをクリックします。

3. 左側のペインで、「アクセス・ゲート構成」リンクをクリックします。

4. 検索条件としてbifoundation_domain(またはapp_domain内の別のサブストリング)と入力し、「実行」をクリックします。
作成したドメインのアクセス・ゲートが表示されます。この結果には、接尾辞_AG(例: bifoundation_domain_AG)が付加されています。

5. ドメインのアクセス・ゲートをクリックして、詳細を表示します。

12.2.3 ホスト識別子の更新

Oracle Access Manager構成ツールは、app_domainパラメータの値を使用してポリシー・ドメインのホスト識別子を作成します。構成が正常に機能するためには、ホストに対するすべてのホスト名バリエーションを反映してホスト識別子を更新する必要があります。

Oracle Access Manager構成ツールで作成したホスト識別子を更新する手順は次のとおりです。

1. Webブラウザで次のURLを入力し、アクセス・システム・コンソールに移動します。
http://hostname:port/access/oblix

hostnameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. ユーザー名とパスワードの入力が要求されたら、管理者としてログインします。「OK」をクリックします。

3. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックします。

4. 「アクセス・システム・コンソール」ページで、「アクセス・システム構成」タブをクリックします。

5. 「アクセス・システム構成」ページで、左下にある「ホスト識別子」をクリックします。

6. 「すべてのホスト識別子をリスト」ページで、Oracle Access Manager構成ツールで作成したホスト識別子をクリックします。たとえば、bifoundation_domainを選択します。

7. 「ホスト識別子詳細」ページで「変更」をクリックします。

8. 「ホスト識別子の変更」ページで、ホストに対するすべてのホスト名バリエーションを追加します。必要に応じてプラス記号またはマイナス記号をクリックして、フィールドを追加または削除してください。
「アクセス・システム構成」で使用する「優先HTTPホスト」の値を、ホスト名バリエーションの1つとして追加する必要があります。例:

bifoundation_domain, webhost1.mycompany.com:7777, webhost2.mycompany.com:7777,
APPHOST1VHN1.mycompany.com:9704, APPHOST2VHN1.mycompany.com:9704,
ADMIN.mycompany.com:80, ADMINVHN.mycompany.com:7001, APPHOST1VHN1:9704,
APPHOST2VHN1:9704, ADMINVHN:7001

9. 「キャッシュの更新」を選択し、「保存」をクリックします。
次のメッセージが表示されます: 「現時点でキャッシュを更新すると、システム内のすべてのキャッシュがフラッシュされます。よろしいですか。」

「OK」をクリックして、構成変更の保存を終了します。

10. 「ホスト識別子詳細」ページで変更内容を確認します。

12.2.4 Webゲート・プロファイルの更新

Oracle Access Manager構成ツールは、app_domainパラメータの値で作成したWebゲート・プロファイルのPreferred_HTTP_Host属性とhostname属性に値を設定します。構成が正しく機能するようにするには、この2つの属性の両方を適切な値で更新する必要があります。

Oracle Access Manager構成ツールで作成したWebゲート・プロファイルを更新する手順は次のとおりです。

1. Webブラウザで次のURLを入力し、アクセス・システム・コンソールに移動します。
http://hostname:port/access/oblix

hostnameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. ユーザー名とパスワードの入力が要求されたら、管理者としてログインします。「OK」をクリックします。

3. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックします。

4. 「アクセス・システム・コンソール」ページで、「アクセス・システム構成」タブをクリックし、「アクセス・ゲート検索」ページを表示します。

5. 適切な検索条件を入力し、「実行」をクリックして、アクセス・ゲートのリストを表示します。

6. Oracle Access Manager構成ツールで作成したアクセス・ゲートを選択します。例: bifoundation_domain_AG

7. 「アクセス・ゲート詳細」ページで、「変更」を選択し、「アクセス・ゲートの変更」ページを表示します。

8. 「アクセス・ゲートの変更」ページで、次を更新します。

- ホスト名: Webゲートを実行しているコンピュータの名前でホスト名を更新します。例: webhost1.mycompany.com

- 優先HTTPホスト: 前の項で指定したホスト名バリエーションの1つでPreferred_HTTP_Hostを更新します。例: webhost1.mycompany.com:7777

- プライマリHTTP Cookieドメイン: ドメインの接尾辞またはホスト識別子でプライマリHTTP Cookieドメインを更新します。例: mycompany.com

- ポート: Webゲートを実行しているポート番号でポートを更新します。たとえば、7777のようになります。

- 最大接続数: 4に設定します。

9. 「保存」をクリックし、「OK」をクリックして確認します。

10. 「アクセス・ゲートの詳細」ページに表示される値を確認し、正常に更新されたことを確認します。

12.2.5 Webゲートのインストールと構成

Webゲートを各WEBHOSTnコンピュータにインストールして、Web層を保護する必要があります。Webゲートをインストールして構成する手順は次のとおりです。

1. 次のコマンドを使用してWebゲート・インストーラを起動します。

./Oracle_Access_Manager10_1_4_3_0_linux_OHS11g_WebGate -gui

2. 「ようこそ」画面が表示されます。「次へ」をクリックします。

3. 「顧客情報」画面で、Webサーバーを実行しているユーザー名とユーザー・グループを入力します。「次へ」をクリックして続行します。

4. インストール先画面で、Webゲートをインストールするディレクトリを指定します。「次へ」をクリックして続行します。

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

6. Webゲート構成画面の説明に従って、Webゲートに必要なGCCランタイム・ライブラリをダウンロードし、「参照」を使用して、このGCCランタイム・ライブラリのローカル・コンピュータ上の場所を指定します。「次へ」をクリックして続行します。

7. この段階で、インストーラにより必要なアーティファクトが作成されます。このプロセスが完了したら、「次へ」をクリックして続行します。

8. 「トランスポート・セキュリティ・モード」画面で、BIアクセス・ゲートに構成されているモードと同じモード(例: 「簡易」)を選択し、「次へ」をクリックして続行します。

注意:

Oracle Identity Managementと統合する場合は、Oracle Identity Managementサーバーで現在使用中のトランスポート・モードを使用します。たとえば、オープン、簡易または証明書モードなどです。

9. Webゲート構成画面で、使用するアクセス・サーバーの詳細を入力します。入力する情報は次のとおりです。

- WebゲートID: Oracle Access Manager構成ツールの実行時に指定されたもの

- Webゲートのパスワード

- アクセス・サーバーID: Oracle Access Managerアクセス・サーバー構成から報告されたもの

- アクセス・サーバー・ホスト名: Oracle Access Managerアクセス・サーバー構成から報告されたもの

- アクセス・サーバー・ポート番号: Oracle Access Managerアクセス・サーバー構成から報告されたもの

- グローバル・アクセス・プロトコル・パスフレーズ

これらの詳細は、Oracle Access Manager管理者から取得できます。「次へ」をクリックして続行します。

10. 「Webサーバーの構成」画面で「はい」をクリックすると、自動的にWebサーバーが更新されます。「次へ」をクリックして続行します。

11. 次の「Webサーバーの構成」画面で、httpd.confファイルを含むディレクトリのフルパスを指定します。「次へ」をクリックして続行します。

12. 次の「Webサーバーの構成」ページに、Webサーバー構成がWebゲート向けに変更されたことを示すメッセージが示されます。「はい」をクリックして確認します。

13. Webサーバーをいったん停止してから再起動し、構成の更新を有効にします。「次へ」をクリックして続行します。

14. 表示された「Webサーバーの構成」画面に、SSLに関するメッセージが表示されます。「次へ」をクリックして続行します。

15. 次の「Webサーバーの構成」画面に、製品設定とWebサーバーの構成の残りの部分に関する情報が記載されているドキュメントの場所を示すメッセージが表示されます。「いいえ」を選択し、「次へ」をクリックして続行します。

16. 最後の「Webサーバーの構成」画面には、ブラウザを手動で起動し、Webサーバーの構成に関する追加情報が記載されているHTMLドキュメントを開くように求めるメッセージが表示されます。「次へ」をクリックして続行します。

17. Oracle COREidのREADME画面が表示されます。画面の情報を確認し、「次へ」をクリックして続行します。

18. インストールの詳細およびインストールの正常終了を示すメッセージが表示されます。

12.2.6 WebゲートのIP検証の構成

IP検証では、クライアントのIPアドレスが、シングル・サインオンで生成されるObSSOCookieに格納されているIPアドレスと同じであるかどうかを確認します。IPターミネーションを実行するように構成されたロード・バランサ・デバイスを使用しているシステムにおいては、また認証するWebゲートのフロントエンドのロード・バランサがエンタープライズ・デプロイメントのフロントエンドのロード・バランサと異なる場合は、IP検証で問題が発生することがあります。このような場合に検証が行われないようにロード・バランサを構成する手順は次のとおりです。

1. 次のURLを使用してアクセス・システム・コンソールに移動します。

http://hostname:port/access/oblix

hostnameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。

3. 「アクセス・システム・コンソール」メイン・ページで、「アクセス・システム構成」をクリックし、左ペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

4. 適切な検索条件を入力し、「実行」をクリックして、アクセス・ゲートのリストを表示します。

5. Oracle Access Manager構成ツールで作成したアクセス・ゲートを選択します。

6. 「変更」をページの下部でクリックします。

7. 「IPValidationException」フィールドに、デプロイメントのフロントエンドに位置するロード・バランサのアドレスを入力します。

8. ページの下部にある「保存」をクリックします。

12.2.7 WebLogic認証プロバイダの設定

この項の手順では、LDAP認証プロバイダが構成済であると想定しています。

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

- 第12.2.7.1項「Oracle Access Manager IDアサータの設定」

- 第12.2.7.2項「プロバイダの順序の設定」

12.2.7.1 Oracle Access Manager IDアサータの設定

Oracle Access Manager IDアサータを設定する手順は次のとおりです。

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

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

3. SecurityRealms\myrealm\Providersに移動します。

4. 「新規」をクリックし、ドロップダウン・メニューから「OAM Identity Asserter」を選択します。

5. アサータの名前(OAM ID Asserterなど)を入力し、「OK」をクリックします。

6. 新しく追加したアサータをクリックし、OAMアイデンティティ・アサータの構成画面を確認します。

7. 「制御フラグ」を「REQUIRED」に設定して、「保存」をクリックします。

8. 「 プロバイダ固有 」タブを開き、必要な設定を次のように構成します。

- プライマリ・アクセス・サーバー: Oracle Access Managerサーバーのエンドポイント情報をHOST:PORT形式で指定します。

- AccessGate名: アクセス・ゲートの名前を入力します(例: bifoundation_domain_AG)。

- AccessGateパスワード: アクセス・ゲートのパスワードを入力します。

9. 完了したら「保存」をクリックします。

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

11. 管理サーバーおよび管理対象サーバーを再起動します。

12.2.7.2 プロバイダの順序の設定

各認証プロバイダの制御フラグが次のように設定されていることを確認することによって、Oracle Access Managerアイデンティティ・アサータ、Oracle Internet Directory認証プロバイダおよびデフォルト認証プロバイダを並べ替えます。

- OAMアイデンティティ・アサータ: REQUIRED

- OID LDAP認証プロバイダ: SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

次に、管理サーバー、管理対象サーバーおよびOracle Business Intelligenceシステム・コンポーネントを再起動します。

12.2.8 アプリケーションの構成

この項では、アプリケーションを構成する方法について説明します。項目は次のとおりです。

- 第12.2.8.1項「Oracle BI EEでのSSO/Oracle Access Managerの有効化」

- 第12.2.8.2項「BI PublisherでのSSO/Oracle Access Managerの有効化」

- 第12.2.8.3項「Oracle BI SearchでのSSO/Oracle Access Managerの有効化」

- 第12.2.8.4項「Oracle RTDでのSSO/Oracle Access Managerの有効化」

12.2.8.1 Oracle BI EEでのSSO/Oracle Access Managerの有効化

Oracle BI EEに対してSSOとOracle Access Managerを有効にする手順は次のとおりです。

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

2. 「Business Intelligence」→「coreapplication」→「セキュリティ」に移動します。

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

4. 「SSOの有効化」を選択し、「SSOプロバイダ」で「Oracle Access Manager」を選択します。

5. 次の各フィールドにログオンURLとログオフURLを入力し、Oracle BI Presentation Servicesのログイン/ログアウト情報を構成します。

- SSOプロバイダのログオンURL: http://OAM_host:OAM_port/oamsso/login.html

- SSOプロバイダのログオフURL: http://OAM_host:OAM_port/access/oblix/lang/en-us/logout.html

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

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

8. opmnctlまたはFusion Middleware Controlを使用して、すべてのOracle Business Intelligenceシステム・コンポーネントを再起動します。

12.2.8.2 BI PublisherでのSSO/Oracle Access Managerの有効化

BI Publisherに対してSSOとOracle Access Managerを有効にする手順は次のとおりです。

1. BI Publisherで、「管理」→「セキュリティ構成」ページに移動し、SSOを有効にします。

2. 「セキュリティ構成」ページの「シングル・サインオン」セクションで次の情報を入力します。

1. 「シングル・サインオンの使用」を選択します。

2. 「シングル・サインオン・タイプ」で「Oracle Access Manager」を選択します。

3. 「シングル・サインオフURL」で、次の形式でURLを入力します。

http://OAM_host:OAM_port/access/oblix/lang/en-us/logout.html

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

4. 管理コンソールからbipublisherアプリケーションを再起動します。

12.2.8.3 Oracle BI SearchでのSSO/Oracle Access Managerの有効化

Oracle BI Searchに対してSSOとOracle Access Managerを有効にする手順は次のとおりです。

1. 次のディレクトリで、BISearchConfig.propertiesファイルを編集用に開きます。

DOMAIN_HOME/config/fmwconfig/biinstances/coreapplication/

2. BIServerSSOUrlを次の値に設定します。
https://bi.mycompany.com/analytics

3. ファイルを保存して閉じます。

12.2.8.4 Oracle RTDでのSSO/Oracle Access Managerの有効化

この項では、Oracle RTDをOracle Access Managerとともに使用する場合の構成について説明します。

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

- 第12.2.8.4.1項「Oracle RTDとOracle Access Manager 10gのログアウトのガイドライン」

12.2.8.4.1 Oracle RTDとOracle Access Manager 10gのログアウトのガイドライン

Oracle RTDでOracle Access Managerのログアウトのガイドラインに準拠するには(特に/adfAuthentication?logout=true&end_url=/ui/do/logoutからログアウトを起動する場合)、Oracle Access Manager 10gとの統合で、end_urlを処理するようにWebゲートを構成する必要があります。この構成を追加しない場合、ログアウトしても、Oracle Access Manager 10gのWebゲートでend_urlが処理されないので、終了URLへのリダイレクトが行われません。

構成手順の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

12.3 Oracle Access Manager 11g統合

この項では、Oracle Access Manager 11gをOracle Business Intelligenceエンタープライズ・デプロイメント・トポロジに対するシングル・サインオン・ソリューションとして構成する方法について説明します。

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

- 第12.3.1項「Oracle Access Managerの統合の概要」

- 第12.3.2項「Oracle Access Managerの前提条件」

- 第12.3.3項「Webゲートのインストール」

- 第12.3.4項「Webゲート・エージェントの登録」

- 第12.3.5項「WebゲートのIP検証の構成」

- 第12.3.6項「WebLogicオーセンティケータのセットアップ」

- 第12.3.7項「アプリケーションの構成」

12.3.1 Oracle Access Managerの統合の概要

Oracle Fusion Middleware 11g リリース1の推奨シングル・サインオン・ソリューションはOracle Access Managerです。Oracle Access Managerインストールのインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。この項では、既存のOracle Access Manager 11gインストレールと基礎となるディレクトリ・サービスを使用して、Oracle Business Intelligenceインストールを構成する手順について説明します。Oracle Internet Directory、Oracle Virtual Directory、またはその両方のディレクトリ・サービスを使用することをお薦めします。

注意:

このガイドで説明されているOracle Business Intelligenceトポロジではシングル・サインオン構成を使用します。この構成では、Oracle Business Intelligenceシステムとシングル・サインオン・システムの両方が同じネットワーク・ドメイン(mycompany.com)に存在します。マルチドメイン構成については、Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイドの第11章「Oracle Access Manager 11gのシングル・サインオンの概要」の必要な構成手順を参照してください。

12.3.2 Oracle Access Managerの前提条件

Oracle Access Managerの設定では、Access Managerおよびポリシー・マネージャを保護するポリシーを完備した、Oracle Access Managerインストールが存在することを前提としています。Oracle Access Managerのインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。この設定には、スタンドアロンまたはOracle Virtual Directory構成の一部としてのOracle Internet Directoryなどのディレクトリ・サービスがあります。この章では、Oracle Internet DirectoryまたはOracle Virtual Directoryのいずれかを使用するようにOracle Business Intelligenceインストールを構成するために必要な手順について説明します。

また、Oracle Access Managerインストールには、Webゲートを使用するように構成された独自のWebサーバーが必要です。この項では、Oracle Access Manager Webサーバーを委任認証サーバーとして使用するための手順も説明します。

12.3.3 Webゲートのインストール

HTTPサーバーがすでにインストールされている各WEBHOSTコンピュータにWebゲートをインストールする必要があります。デプロイメント環境の各WEBHOSTに対して、第12.3.3項および第12.3.4項を繰り返します。

12.3.3.1 GCCライブラリのインストール

Webゲートをインストールする前に、サードパーティのGCCライブラリをダウンロードし、コンピュータにインストールする必要があります。

次のサード・パーティのWebサイトから適切なGCCライブラリをダウンロードできます。

http://gcc.gnu.org/

32ビットのLinuxの場合、必要なライブラリはバージョン番号3.3.2のlibgcc_s.so.1およびlibstdc++.so.5です。表12-2は、LinuxおよびSolarisのGCCサード・パーティ・ライブラリのバージョンを示しています。

表12-2 LinuxおよびSolarisのGCCサード・パーティ・ライブラリのバージョン

オペレーティング・システム

アーキテクチャ

GCCライブラリ

必要なライブラリのバージョン

Linux 32ビット

x86

libgcc_s.so.1

libstdc++.so.5

3.3.2

Linux 64ビット

x64

libgcc_s.so.1

libstdc++.so.6

3.4.6

Solaris 64ビット

SPARC

libgcc_s.so.1

libstdc++.so.5

3.3.2

12.3.3.2 Webゲートのインストール

この項では、WebGateのインストール手順について説明します。

インストーラの起動

Oracle HTTP Server 11g WebGate for Oracle Access Managerのインストーラ・プログラムはwebgate.zipファイルに含まれています。

インストール・ウィザードを起動するには、次の手順を実行します。

1. webgate.zipファイルのコンテンツを、ディレクトリに解凍します。デフォルトでは、このディレクトリの名前はwebgateです。

2. webgateフォルダの下のDisk1ディレクトリに移動します。

3. 次のコマンドを使用してインストーラを起動します。

$ ./runInstaller -jreLoc WebTier_Home/jdk

インストーラが起動すると、「ようこそ」画面が表示されます。

インストールの流れと手順

インストール画面に関して詳細な情報が必要な場合は、「ヘルプ」をクリックしてオンライン・ヘルプを参照してください。

Oracle HTTP Server 11g WebGate for Oracle Access Managerをインストールする手順は次のとおりです。

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

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

3. 「インストール場所の指定」画面で、ミドルウェア・ホームおよびOracleホームの場所を指定します。デフォルトの場所を使用するか、別の場所を選択できます。

注意:

MiddleWareホームには、Oracle Web層のOracleホームがあります。

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

4. GCCライブラリの指定画面で、GCCライブラリが含まれているディレクトリを指定し、「次へ」をクリックします。

5. 「インストール・サマリー」画面で、画面に表示される情報を確認し、「インストール」をクリックしてインストールを開始します。

6. 「インストールの進行状況」画面で、ファイルおよびディレクトリに適切な権限を構成するために、ORACLE_HOME/oracleRoot.shスクリプトを実行するように求められる場合があります。
「次へ」をクリックして続行します。

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

12.3.3.3 インストール後の手順

Oracle HTTP Server 11g WebGate for Oracle Access Managerのインストール後に実行する手順は次のとおりです。

1. WebゲートのOracleホーム内の次のディレクトリに移動します。

$ cd Webgate_Home/webgate/ohs/tools/deployWebGate

2. コマンドラインで次のコマンドを実行し、エージェントの必要な部分をWebgate_HomeディレクトリからWebゲート・インスタンスの場所にコピーします。

$ ./deployWebGateInstance.sh -w Webgate_Instance_Directory
-oh Webgate_Oracle_Home

ここでWebgate_Oracle_Homeは、Oracle HTTP Server WebGateをインストールし、WebゲートのOracleホームとして作成したディレクトリです。次に例を示します。

MW_HOME/Oracle_OAMWebGate1

Webgate_Instance_DirectoryはWebゲート・インスタンス・ホームの場所です。これは、Oracle HTTP Serverのインスタンス・ホームと同じです。次に例を示します。

MW_HOME/ORACLE_BASE/admin/webn/config/OHS/ohsn

注意:

Oracle HTTP Serverのインスタンス・ホームはOracle HTTP Serverの構成後に作成されます。

3. 次のコマンドを実行し、LD_LIBRARY_PATH変数にOracle_Home_for_Oracle_HTTP_Server/libが含まれるようにします。

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:Oracle_Home_for_Oracle_HTTP_Server/lib

4. 現在の作業ディレクトリから、1つ上のディレクトリに移動します。

$ cd Webgate_Home/webgate/ohs/tools/setup/InstallTools

5. コマンド・ラインで次のコマンドを実行して、Webgate_HomeディレクトリからWebゲート・インスタンスの場所にapache_webgate.templateをコピーし(名前がwebgate.confに変更されます)、httpd.confファイルを更新してwebgate.confの名前が含まれる1つの行を追加します。

$ ./EditHttpConf -w Webgate_Instance_Directory [-oh Webgate_Oracle_Home]
[-o output_file]

注意:

-oh WebGate_Oracle_Homeおよび-o output_fileパラメータはオプションです。

ここでWebGate_Oracle_Homeは、Oracle HTTP Server Webgate for Oracle Access Managerをインストールし、WebゲートのOracleホームとして作成したディレクトリです。次に例を示します。

MW_HOME/Oracle_OAMWebGate1

Webgate_Instance_DirectoryはWebゲートのインスタンス・ホームの場所です。これは、Oracle HTTP Serverのインスタンス・ホームと同じです。次に例を示します。

MW_HOME/ORACLE_BASE/admin/webn/config/OHS/ohsn

output_fileはツールによって使用される一時出力ファイルの名前です。次に例を示します。

Edithttpconf.log

12.3.4 WebGateエージェントの登録

この項では、Webゲート・エージェントを登録する手順を説明します。内容は次のとおりです。

- 第12.3.4.1項「RREGツール」

- 第12.3.4.2項「OAM11gRequestファイルの更新」

- 第12.3.4.3項「oamregツールの実行」

- 第12.3.4.4項「WEBHOSTへのアクセス・ファイルのコピー」

12.3.4.1 RREGツール

RREGツールは、Oracle Access Manager 11gインストールに付属しています。まだ利用可能でない場合は、次の手順を実行して抽出します。

1. Oracle Access Managerのインストールおよび構成が終わった後、次の場所に移動します。

IDM_Home/oam/server/rreg/client

2. コマンドラインから、次の例のとおり、gunzipを使用してRREG.tar.gzファイルを解凍します。

gunzip RREG.tar.gz

tar -xvf RREG.tar

エージェントを登録するためのツールは次の場所にあります。

RREG_Home/bin/oamreg.sh

RREG_Homeは、RREG.tar.gz/rregの内容を展開したディレクトリです。

RREG構成ツールは、保護されているリソースやパブリック・リソースをOAMシステムに登録する手段を提供します。OAMシステムに追加される、保護されているリソースのリストは次のとおりです。

/analytics/saw.dll
/bicontent
/xmlpserver
/ui
/mapviewer
/bicomposer
/bisearch
/em
/em/…/*
/console
/console/…/*
/calcmgr
/hr
/workspace
/ui/adfAuthentication
/mobile
/mobile/.../*
/bioffice

「/…/*」は、ベースurlコンテキストの下のすべてのリソースを表します。

パブリック・リソースのリストは次のとおりです。

/analytics
/analytics/saw.dll/wsdl
/analytics-ws/saw.dll
/ui/do/logout
/xmlpserver/services
/xmlpserver/report_service
/xmlpserver/ReportTemplateService.xls
/xmlpserver/Guest
/biservices
/bioffice/services/saw?WSDL
/hr/services
/aps
/aps/JAPI
/aps/Essbase
/hr/modules/com/hyperion/reporting/web/repository/HRRepositoryXML.jsp
/hr/modules/com/hyperion/reporting/web/images
/ui/images/*

除外されるリソースのリストは次のとおりです。

/rtis
/rtis/.../*
/schema
/schema/.../*
/ws
/ws/.../*
/wsm-pm
/wsm-pm/.../*

12.3.4.2 OAM11gRequestファイルの更新

RREG_Home/inputディレクトリには、OAM11GRequest.xmlという名前のテンプレート・ファイルがあります。そのテンプレートをBIOAM11GRequest.xmlという新しいファイルにコピーして編集を行い、Oracle Business Intelligenceインストールのポリシーを作成します。編集後のファイルは次のようになります。

注意:

$$webtierhost$$、$$oamadminserverport$$、$$oamhost$$およびload_balancer_source_IPをインストールのそれぞれの値で置き換えます。

<?xml version="1.0" encoding="UTF-8"?>

<!-- Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.

NAME: OAM11GRequest_short.xml - Template for OAM 11G Agent Registration request
file (Shorter version - Only mandatory values - Default values will be used for
all other fields)
DESCRIPTION: Modify with specific values and pass file as input to the tool.

-->
<OAM11GRegRequest>
<serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress>
<hostIdentifier>$$webtierhost$$_bi</hostIdentifier>
<agentName>$$webtierhost$$_bi</agentName>
<applicationDomain>$$webtierhost$$_bi</applicationDomain>
<cachePragmaHeader>private</cachePragmaHeader>
<cacheControlHeader>private</cacheControlHeader>
<ipValidation>1</ipValidation>
<logOutUrls>
<url>/oamsso/logout.html</url>
</logOutUrls>
<protectedResourcesList>
<resource>/analytics/saw.dll</resource>
<resource>/bicontent</resource>
<resource>/xmlpserver</resource>
<resource>/ui</resource>
<resource>/mapviewer</resource>
<resource>/bicomposer</resource>
<resource>/bisearch</resource>
<resource>/em</resource>
<resource>/em/…/*</resource>
<resource>/bioffice</resource>
<resource>/console</resource>
<resource>/console/…/*</resource>
<resource>/mobile</resource>
<resource>/mobile/.../*</resource>
<resource>/calcmgr</resource>
<resource>/hr</resource>
<resource>/workspace</resource>
<resource>/ui/adfAuthentication</resource>
</protectedResourcesList>
<publicResourcesList>
<resource>/analytics</resource>
<resource>/analytics/saw.dll/wsdl</resource>
<resource>/aps</resource>
<resource>/ui/do/logout</resource>
<resource>/xmlpserver/services</resource>
<resource>/xmlpserver/report_service</resource>
<resource>/bioffice/services/saw?WSDL</resource>
<resource>/hr/services</resource>
<resource>/aps/JAPI</resource>
<resource>/aps/Essbase</resource>
<resource>/hr/modules/com/hyperion/reporting/web/repository/HRRepositoryXML.jsp</resource>
<resource>/hr/modules/com/hyperion/reporting/web/images</resource>
<resource>/xmlpserver/ReportTemplateService.xls</resource>
<resource>/xmlpserver/Guest</resource>
<resource>/biservices</resource>
<resource>/ui/images/*</resource>
<resource>/analytics-ws/saw.dll</resource>
</publicResourcesList>
<excludedResourcesList>
<resource>/rtis</resource>
<resource>/rtis/.../*</resource>
<resource>/schema</resource>
<resource>/schema/.../*</resource>
<resource>/ws</resource>
<resource>/ws/.../*</resource>
<resource>/wsm-pm</resource>
<resource>/wsm-pm/.../*</resource>
</excludedResourcesList>
</OAM11GRegRequest>

12.3.4.3 oamregツールの実行

次のコマンドを使用してoamregツールを実行します。

$ RREG_Home/bin/oamreg.sh inband RREG_Home/input/BIOAM11gRequest.xml

JAVA_HOMEオペレーティング・システムの環境変数は、このコマンドが機能するためにjdk6に設定する必要があります。

出力は、次のようになります。

------------------------------------------------
Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: /u01/oim/oim_home/oam/server/rreg/client/rreg/input/BIOAM11GRequest.xml
Enter admin username: oamadmin_user
Username: oamadmin_user
Enter admin password: my_password
Do you want to enter a Webgate password?(y/n):
y
Enter webgate password: my_password
Enter webgate password again: my_password
Password accepted. Proceeding to register..
Nov 9, 2011 6:48:44 PM
oracle.security.am.engines.rreg.client.handlers.request.OAM11GRequestHandler
getWebgatePassword
INFO: Passwords matched and accepted.
Do you want to import an URIs file?(y/n):
n
----------------------------------------
Request summary:
OAM11G Agent Name:WEBHOST_bi
URL String:WEBHOST_bi
Registering in Mode:inband
Your registration request is being been sent to the Admin server at:
http://oamserver.mycompany.com:OAM_ADMINSERVER_PORT
----------------------------------------
Inband registration process completed successfully! Output artifacts are created
in the output folder.

12.3.4.4 WEBHOSTへのアクセス・ファイルのコピー

オープン・モードでは、次の2つのファイルがOAM_REG_HOME/output/$$webtierhost$$_biディレクトリに生成されます。

- ObAccessClient.xml

- cwallet.sso

これらのファイルをWEBHOST1およびWEBHOST2のwebgateインスタンス(Webgate_Instance_Home/config/OHS/ohsN/webgate/config/)の場所にコピーします。

簡易モードでは、次のファイルをOAM_REG_HOME/output/$$webtierhost$$_biディレクトリから、WEBHOST1およびWEBHOST2のWebgate_Instance_Home/webgate/configディレクトリにコピーします。

- ObAccessClient.xml

- cwallet.sso

- password.xml

さらに、次のファイルを OAM_REG_HOME/output/$$webtierhost$$_biディレクトリから、WEBHOST1およびWEBHOST2のWebgate_Instance_Home/config/OHS/ohsN/webgate/config/simpleディレクトリにコピーします。

- aaa_key.pem

- aaa_cert.pem

注意:

Oracle Identity Managementと統合する場合は、Oracle Identity Managementサーバーで現在使用中のトランスポート・モードを使用します。たとえば、オープン、簡易または証明書モードなどです。

アクセス・ファイルをWEBHOST1およびWEBHOST2にコピーしたら、変更を有効にするために、Oracle HTTP Serverインスタンスを再起動する必要があります。

12.3.5 WebゲートのIP検証の構成

IP検証では、クライアントのIPアドレスが、シングル・サインオンで生成されるObSSOCookieに格納されているIPアドレスと同じであるかどうかを確認します。IPターミネーションを実行するように構成されたロード・バランサ・デバイスを使用しているシステムにおいては、また認証するWebゲートのフロントエンドのロード・バランサがエンタープライズ・デプロイメントのフロントエンドのロード・バランサと異なる場合は、IP検証で問題が発生することがあります。このような場合に検証が行われないようにロード・バランサを構成する手順は次のとおりです。

1. 次のURLを使用して、Oracle Access Manager 11gコンソールにアクセスします。

http://hostname:port/oamconsole

2. Oracle Access Manager 11gの管理者としてログインします。

3. 「ようこそ」ページで、「システム構成」タブをクリックします。

4. 「Access Managerの設定」セクションで、「SSOエージェント」ノードを開きます。「OAMエージェント」をダブルクリックし、「OAMエージェント検索」ページを表示します。

5. 適切な検索条件を入力し、「検索」をクリックして、OAMエージェントのリストを表示します。

6. Oracle Access Manager構成ツールで作成されたOAMエージェントを選択します。

7. 「IPの検証例外」フィールドに、デプロイメントのフロントエンドに位置するロード・バランサのアドレスを入力します。

8. ページの上部の「適用」をクリックします。

12.3.6 WebLogic認証プロバイダの設定

この項では、第12.1.2.3項「LDAPを使用するアイデンティティ・ストアの構成」の手順に従ってLDAP認証プロバイダをすでに構成していることを想定しています。LDAP認証プロバイダをまだ作成していない場合は、それを作成してからこの項の続きを実行します。

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

- 第12.3.6.1項「構成ファイルのバックアップ」

- 第12.3.6.2項「OAM IDアサータの設定」

- 第12.3.6.3項「プロバイダの順序の設定」

12.3.6.1 構成ファイルのバックアップ

まず、次の関連する構成ファイルをバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fwmconfig/system-jazn-data.xml

また、管理サーバーのboot.propertiesファイルもバックアップします。

12.3.6.2 OAM IDアサータの設定

OAM IDアサータを設定する手順は次のとおりです。

1. 次のURLを使用してWebLogicコンソールにログインします。

http://ADMINVHN.mycompany.com:7001/console

2. 「ロックして編集」をクリックします。

3. 「セキュリティ・レルム」→「<デフォルト・レルム名>」→「プロバイダ」に移動します。

4. 「新規」をクリックし、ドロップダウン・メニューから「OAMアイデンティティ・アサータ」を選択します。

5. アサータの名前(OAM ID Asserterなど)を入力し、「保存」をクリックします。

6. 新しく追加したアサータをクリックし、OAMアイデンティティ・アサータの構成画面を確認します。

7. 制御フラグを「必須」に設定します。

8. ObSSOCookieおよびOAM_REMOTE_USERの両方のオプションがアクティブ・タイプで選択されていることを確認します。

9. 完了したら「保存」をクリックします。

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

11. 管理サーバーおよび管理対象サーバーを再起動します。

最後に、次の場所にあるWLSTコンソールに管理者としてログインします。

ORACLE_COMMON_HOME/common/bin/wlst.sh

続けて、次のコマンドを実行します。

addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",logouturi="/oamsso/logout.html")

例:

wls:/offline> connect('weblogic','my_password','t3://ADMINVHN:7001')
Connecting to t3:ADMINVHN:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain
'bifoundation_domain'.

wls:/bifoundation_domain/serverConfig>
addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",logouturi="/oamsso/logout.html")

12.3.6.3 プロバイダの順序の設定

OAMアイデンティティ・アサータ、OID認証プロバイダおよびデフォルト認証プロバイダの制御フラグが次のように設定されていることを確認し、これらの認証プロバイダを並べ替えます。

- OAMアイデンティティ・アサータ: REQUIRED

- OID LDAP認証プロバイダ(またはOVD LDAP認証プロバイダ): SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

次に、管理サーバー、管理対象サーバーおよびOracle Business Intelligenceシステム・コンポーネントを再起動します。

12.3.7 アプリケーションの構成

この項では、アプリケーションを構成する方法について説明します。項目は次のとおりです。

- 第12.3.7.1項「Oracle BI EEでのSSO/Oracle Access Managerの有効化」

- 第12.3.7.2項「BI PublisherでのSSO/Oracle Access Managerの有効化」

- 第12.3.7.3項「Oracle BI SearchでのSSO/Oracle Access Managerの有効化」

- 第12.3.7.4項「Oracle RTDでのSSO/Oracle Access Managerの有効化」

12.3.7.1 Oracle BI EEでのSSO/Oracle Access Managerの有効化

Oracle BI EEに対してSSOとOracle Access Managerを有効にする手順は次のとおりです。

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

2. 「Business Intelligence」→「coreapplication」→「セキュリティ」→「シングル・サインオン」に移動します。

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

4. 「SSOの有効化」を選択し、「SSOプロバイダ」で「Oracle Access Manager」を選択します。

5. 次の各フィールドにログオンURLとログオフURLを入力し、Oracle BI Presentation Servicesプロセスのログインおよびログアウト情報を構成します。

- SSOプロバイダのログオンURL: http://OAM_host:OAM_port/oamsso/login.html

- SSOプロバイダのログオフURL: http://OAM_host:OAM_port/oamsso/logout.html

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

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

8. opmnctlまたはFusion Middleware Controlを使用して、すべてのOracle Business Intelligenceシステム・コンポーネントを再起動します。

12.3.7.2 BI PublisherでのSSO/Oracle Access Managerの有効化

BI Publisherに対してSSOとOracle Access Managerを有効にする手順は次のとおりです。

1. BI Publisherで、「管理」→「セキュリティ構成」ページに移動し、SSOを有効にします。

2. 「セキュリティ構成」ページの「シングル・サインオン」セクションで次の情報を入力します。

1. 「シングル・サインオンの使用」を選択します。

2. 「シングル・サインオン・タイプ」で「Oracle Access Manager」を選択します。

3. 「シングル・サインオフURL」で、次の形式でURLを入力します。

http://OAM_host:OAM_port/oamsso/logout.html

4. ユーザー名パラメータに対して、OAM_REMOTE_USERと指定します。

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

4. 管理コンソールからbipublisherアプリケーションを再起動します。

12.3.7.3 Oracle BI SearchでのSSO/Oracle Access Managerの有効化

Oracle BI Searchに対してSSOとOracle Access Managerを有効にする手順は次のとおりです。

1. 次のディレクトリで、BISearchConfig.propertiesファイルを編集用に開きます。

DOMAIN_HOME/config/fmwconfig/biinstances/coreapplication/

2. BIServerSSOUrlを次の値に設定します。
https://bi.mycompany.com/analytics

3. ファイルを保存して閉じます。

12.3.7.4 Oracle RTDでのSSO/Oracle Access Managerの有効化

この項では、Oracle RTDをOracle Access Managerとともに使用する場合の構成について説明します。

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

- 第12.3.7.4.1項「Decision Centerのログアウトのリダイレクトに関する問題の回避」

12.3.7.4.1 Decision Centerのログアウトのリダイレクトに関する問題の回避

Webゲート10gがOracle Access Manager (OAM) 11gでOracle Real-Time Decisions Decision CenterへのアクセスのSSOプロバイダとして構成されている場合、ログアウトしてからOracle RTD Decision Centerに戻って再ログインするユーザーに対して、ユーザー名とパスワードの資格証明の入力が要求されます。この動作が正常に行われるようにするには、OAM/Webゲートで次のOracle RTD Decision Centerリソースをパブリック(保護対象外または匿名のアクセス)として構成する必要があります。

1. Decision CenterのログアウトURI /ui/do/logout

2. Decision Centerの画像 /ui/images/*

12.4 アイデンティティ管理構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、その構成内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、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層のミドルウェア・ホームをバックアップします。

WEBHOSTn> tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME

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

WEBHOSTn> tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE

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

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

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

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

13 エンタープライズ・デプロイメントの管理

この章では、Oracle Business Intelligenceトポロジの構成後に実行可能なオペレーションについて説明します。これには、エンタープライズ・デプロイメントの監視、スケーリングおよびバックアップが含まれます。

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

- 第13.1項「エンタープライズ・デプロイメントの管理について」

- 第13.2項「Oracle Business Intelligenceの起動と停止」

- 第13.3項「エンタープライズ・デプロイメントの監視」

- 第13.4項「エンタープライズ・デプロイメントのスケーリング」

- 第13.5項「APPHOST2への管理サーバーの手動フェイルオーバー」

- 第13.6項「エンタープライズ・デプロイメントのバックアップとリカバリの実行」

- 第13.7項「エンタープライズ・デプロイメントのパッチ適用」

- 第13.8項「SQLNet接続のタイムアウト防止」

- 第13.9項「エンタープライズ・デプロイメントのトラブルシューティング」

13.1 エンタープライズ・デプロイメントの管理について

Oracle Business Intelligenceエンタープライズ・デプロイメントの構成後に、この章の情報を使用してこのデプロイメントを管理します。この章には、デプロイメントの起動、停止、監視およびパッチ適用など、通常のオペレーションに関する項目が含まれています。

ある時点で、トポロジをスケール・アップまたはスケール・アウトして拡張することが必要になる場合もあります。この作業の詳細は、第13.4項「エンタープライズ・デプロイメントのスケーリング」を参照してください。

構成の変更前後にはトポロジをバックアップします。詳細は、第13.6項「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

また、この章の第13.9項「エンタープライズ・デプロイメントのトラブルシューティング」では、トポロジの構成後に発生する可能性がある既知の問題に対する解決方法も紹介しています。

13.2 Oracle Business Intelligenceの起動と停止

Oracle Business Intelligenceを起動するには、常に管理対象サーバー、システム・コンポーネントの順に起動する必要があります。また、管理対象サーバーを再起動したときは、システム・コンポーネントも再起動する必要があります。

詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceの起動と停止に関する項を参照してください。

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

- 第13.2.1項「Oracle Business Intelligence管理対象サーバーの起動と停止」

- 第13.2.2項「Oracle Business Intelligenceシステム・コンポーネントの起動と停止」

13.2.1 Oracle Business Intelligence管理対象サーバーの起動と停止

Oracle Business Intelligence管理対象サーバーを停止、起動または再起動する手順は次のとおりです。

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

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

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

4. 管理するOracle Business Intelligence管理対象サーバーを選択します(たとえば、bi_server1、bi_server2など)。

5. 次のいずれかの処理を実行します。

- 管理対象サーバーを停止するには、「停止」をクリックします。

- 管理対象サーバーを起動するには、「起動」をクリックします。

- 管理対象サーバーを再起動するには、まず「停止」をクリックし、サーバーが完全に停止するまで待機します。サーバーが完全に停止したら、管理対象サーバーをもう一度選択し、「起動」をクリックします。

13.2.2 Oracle Business Intelligenceシステム・コンポーネントの起動と停止

Oracle Business Intelligenceのシステム・コンポーネントを停止、起動または再起動する手順は次のとおりです。

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

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

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

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

13.3 エンタープライズ・デプロイメントの監視

Oracle Business Intelligenceトポロジの監視の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のサービス・レベルの監視に関する項を参照してください。

また、ログのローテーションおよび管理など、Oracle Business Intelligenceのログ・ファイルの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceでの問題の診断と解決に関する項を参照してください。

13.4 エンタープライズ・デプロイメントのスケーリング

Oracle Business Intelligenceエンタープライズ・トポロジを、次のようにスケール・アップまたはスケール・アウトできます。

- トポロジをスケール・アップする際は、エンタープライズ・トポロジ内のいずれかの既存ノードに新たなシステム・コンポーネントを追加します。

- トポロジをスケール・アウトするには、管理対象サーバーおよびシステム・コンポーネントのセットとともに新しいノードをトポロジに追加します。

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

- 第13.4.1項「Oracle Business Intelligenceトポロジのスケール・アップ」

- 第13.4.2項「Oracle Business Intelligenceトポロジのスケール・アウト」

13.4.1 Oracle Business Intelligenceトポロジのスケール・アップ

この手順では、ノードが2つあり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがあるエンタープライズ・トポロジを前提にします。トポロジをスケール・アップするには、いずれかの既存ノードで実行されているシステム・コンポーネントの数を増やします。

特定のノードで複数の管理対象サーバーを実行する必要はありません。

Oracle Business Intelligenceエンタープライズ・トポロジをスケール・アップする手順は次のとおりです。

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

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

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

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

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

6. 矢印キーを使用して、「BIサーバー」、プレゼンテーション・サービスまたは「JavaHost」の数を変更します。

7. 「適用」をクリックしてから、「変更のアクティブ化」をクリックします。

8. 「概要」をクリックしてから、「再起動」をクリックします。

13.4.2 Oracle Business Intelligenceトポロジのスケール・アウト

トポロジをスケール・アウトする場合、トポロジの新しいノード(APPHOST3)に新しい管理対象サーバーとシステム・コンポーネントのセットを追加します。この手順では、ノードが2つあり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがあるエンタープライズ・トポロジを前提にします。

前提条件

この項の手順を実行する前に、次の要件が満たされていることを確認してください。

- Oracle Business Intelligenceの管理対象サーバーが稼働している既存ノードがトポロジ内に存在していることが必要です。

- 新しいノード(APPHOST3)が、Oracle WebLogic ServerとOracle Business Intelligence用の既存のホーム・ディレクトリにアクセスできます。

- ORACLE_HOMEまたはWL_HOMEが各種ノードの複数のサーバーで共有されている場合は、パッチのインストールと適用の一貫性を維持するために、これらのノードのOracleインベントリおよびMiddlewareホーム・リストを常に最新にしておくことをお薦めします。ノード内で更新したoraInventoryに対して共有記憶域にあるインストールを追加するには、ORACLE_HOME/oui/bin/attachHome.shを使用します。Middlewareホーム・リストを更新し、WL_HOMEの追加と削除を行うには、MW_HOME/.homeファイルを編集します。第13.4.2.1項「Oracle Business Intelligenceのスケール・アウト手順」を参照してください。

- 新しいノードから共有記憶域のすべてのディレクトリにアクセス可能であることを保証する必要があります。第4.3.4項「推奨ディレクトリの場所」にリストされているすべての共有ディレクトリがすべてのノードで利用可能なことを確認します。ただし、ORACLE_INSTANCEディレクトリとスケール・アウトされた管理対象サーバーのドメイン・ディレクトリは対象外とします。
また、ホスト名検証証明書が保持されているアイデンティティ・キーストアとトラスト・キーストアに共有記憶域を使用している場合、共有記憶域ディレクトリがスケール・アウトされたノード(APPHOST3)からアクセスできることを確認します。キーストアにローカル・ディレクトリを使用している場合、第10.3項「ノード・マネージャのホスト名検証証明書の有効化」の手順に従って、スケール・アウトされたノードにローカルのアイデンティティ・キーストアを作成および構成します。

たとえば、次の各ディレクトリをマウントします。

- トランザクション・ログ・ディレクトリ

- JMS永続ストア

- グローバル・キャッシュ

- BI Presentation Catalog

- BIリポジトリの公開ディレクトリ

- BI Publisherカタログ

- BI Publisher構成キーストア(certs)

- MW_HOME

13.4.2.1 Oracle Business Intelligenceのスケール・アウト手順

APPHOST3上でOracle Business Intelligenceをスケール・アウトする手順は次のとおりです。

1. APPHOST3で、Oracle Business Intelligenceのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc MW_HOME/jdk

Middlewareホーム・リストを更新するには、MW_HOME/.homeファイルを作成(または別のWebLogicインストールがノード内に存在する場合は、編集)して、そのファイルにORACLE_BASE/product/fmwを追加します。

3. 第9.3項「APPHOST2でのOracle Business Intelligenceシステムのスケール・アウト」の手順に従い、共有Oracleホームの1つから構成アシスタントを実行します。

注意:

構成アシスタントを実行する前に、最初の2つのノードと同じディレクトリに、適切なバージョンのJDKがインストールされていることを確認します。適切なJDKがインストールされていないと、構成アシスタントは起動しない可能性があります。

4. 第9.3.2項「システム・コンポーネントのスケール・アウト」の手順に従い、APPHOST3でシステム・コンポーネントをスケール・アウトします。

5. 第9.4項「bi_server2管理対象サーバーの構成」の手順に従い、リスニング・アドレスの設定とホスト名検証の無効化を行うことによって、bi_server3管理対象サーバーを構成します。

6. 第9.5.3.1.3項「BI Publisher用のJMSの構成」の説明に従って、BI Publisher用のJMSを構成します。

7. 第 9.6.1項「トランザクション・リカバリ用デフォルト永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。

8. 第8.4.1項「管理サーバーとbi_servern管理対象サーバーについてのOracle HTTP Serverの構成」の手順を使用して、APPHOST3VHN1に対してOracle HTTP Serverを構成します。

9. APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第13.2項「Oracle Business Intelligenceの起動と停止」を参照してください。

10. 第9.5.2.2項「システム・プロパティの「サーバーの起動」タブへの追加」の説明に従って、Oracle RTDの「サーバーの起動」タブにシステム・プロパティを追加します。

11. 次の各項の説明に従って、新しいノードでサーバーの移行を構成します。

- 第11.4項「ホスト名検証証明書の有効化」

- 第11.5項「ノード・マネージャのプロパティ・ファイルの編集」

- 第11.6項「wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定」

- 第11.7項「サーバー移行ターゲットの構成」

- 第11.8項「サーバー移行のテスト」

12. 構成を検証するには、次のURLにアクセスします。

- http://APPHOST3VHN1:9704/analyticsにアクセスして、bi_server3のステータスを確認します。

- http://APPHOST3VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

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

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

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

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

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

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

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

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

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

13.5 APPHOST2への管理サーバーの手動フェイルオーバー

ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをAPPHOST1からAPPHOST2にフェイルオーバーする方法を説明します。項目は次のとおりです。

- 第13.5.1項「前提条件および手順」

- 第13.5.2項「Oracle HTTP Serverを介したAPPHOST2へのアクセスの検証」

- 第13.5.3項「APPHOST1への管理サーバーのフェイルバック」

13.5.1 前提条件および手順

次の前提条件があることに留意してください。

- 管理サーバーを、任意のアドレスではなくADMINVHN上でリスニングするように構成します。

- 管理サーバーはAPPHOST1からAPPHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。

- APPHOST1: 100.200.140.165

- APPHOST2: 100.200.140.205

- ADMINVHN: 100.200.140.206。これは管理サーバーを実行している場所のVIPであり、ethX:Yに割り当てられており、APPHOST1とAPPHOST2からアクセスできます。

- APPHOST1の管理サーバーの実行場所であるドメイン・ディレクトリは共有記憶域にあり、APPHOST2からもマウントされています。

- Oracle WebLogic ServerとOracle Fusion MiddlewareコンポーネントがAPPHOST2にインストールされています(つまり、APPHOST1に存在するORACLE_HOMEとMW_HOMEのパスと同じパスがAPPHOST2でも使用可能です)。

手順

管理サーバーを別のノード(APPHOST2)にフェイルオーバーする手順は次のとおりです。

1. 管理サーバーが実行されている場合は停止します。

2. 次の手順を使用して、IPアドレスを2番目のノードに移行します。

1. APPHOST1上で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。

APPHOST1> /sbin/ifconfig ethX:Y down

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

APPHOST2> /sbin/ifconfig interface:index IP_address netmask netmask

例:

APPHOST2> /sbin/ifconfig eth0:1 10.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、APPHOST2で使用可能なネットワーク構成と一致している必要があります。

3. arpingを使用し、ルーティング表を更新します。例:

APPHOST2> /sbin/arping -b -A -c 3 -I eth0 100.200.140.206

3. 第8.3.3項「APPHOST1での管理サーバーの起動」の手順1の説明に従って、APPHOST2上でノード・マネージャを起動します。

4. 第8.3.3項「APPHOST1での管理サーバーの起動」の手順2の説明に従って、APPHOST2上で管理サーバーを起動します。

5. 次の方法でAPPHOST2上の管理サーバーにアクセスできることをテストします。

1. http://ADMINVHN:7001/consoleの管理コンソールにアクセスできることを確認します。

2. http://ADMINVHN:7001/emのFusion Middleware Controlコンポーネントにアクセスしステータスを検証できることを確認します。

13.5.2 Oracle HTTP Serverを介したAPPHOST2へのアクセスの検証

第8.4.5項「Oracle HTTP Serverを使用したアクセスの検証」で説明されている手順を実行します。この目的は、APPHOST2で実行している管理サーバーにもアクセスできることを確認することです。

13.5.3 APPHOST1への管理サーバーのフェイルバック

この手順では、管理サーバーをフェイルバックできることを確認します。フェイルバックとは、APPHOST2で実行している管理サーバーを停止し、APPHOST1で再び管理サーバーを実行することです。ADMINVHNをAPPHOST1ノードにフェイルバックする手順は次のとおりです。

1. 管理サーバーが実行されていないことを確認してください。

2. 次のコマンドをAPPHOST2上でrootとして実行します。

APPHOST2> /sbin/ifconfig ethX:Y down

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

APPHOST1> /sbin/ifconfig interface:index IP_Address netmask netmask

例:

APPHOST1> /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、APPHOST1で使用可能なネットワーク構成と一致している必要があります。

4. arpingを使用し、ルーティング表を更新します。例:

APPHOST1> /sbin/arping -b -A -c 3 -I ethZ 100.200.140.206

5. 第8.3.3項「APPHOST1での管理サーバーの起動」の手順2の説明に従って、APPHOST1上で管理サーバーを再び起動します。

6. http://ADMINVHN:7001/consoleの管理コンソールにアクセスできることをテストします。

7. http://ADMINVHN:7001/emのFusion Middleware Controlコンポーネントにアクセスしステータスを検証できることを確認します。

管理サーバーのフェイルオーバーで問題が発生する場合の追加情報は、第13.9.2項「手動フェイルオーバー後に管理サーバーの起動に失敗する」を参照してください。

13.6 エンタープライズ・デプロイメントのバックアップとリカバリの実行

Oracle Business Intelligenceのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Business Intelligenceのバックアップおよびリカバリに関する推奨事項に関する項を参照してください。

13.7 エンタープライズ・デプロイメントのパッチ適用

Oracle Business Intelligenceのパッチ適用の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceシステムのパッチ適用に関する項を参照してください。

13.8 SQLNet接続のタイムアウト防止

EDG本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters(RAC)の場合、データベース接続はOracle RACのVIPとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。そのような構成が不可能な場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルにある*SQLNET.EXPIRE_TIME=n*というパラメータを設定します(nは分単位の時間)。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定してください。

13.9 エンタープライズ・デプロイメントのトラブルシューティング

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

- 第13.9.1項「BIアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する」

- 第13.9.2項「手動フェイルオーバー後に管理サーバーの起動に失敗する」

- 第13.9.3項「管理コンソールで変更をアクティブ化するときにエラーが発生する」

- 第13.9.4項「サーバー移行後にbi_server管理対象サーバーがフェイルオーバーしない」

- 第13.9.5項「サーバー移行後にbi_server管理対象サーバーにブラウザからアクセスできない」

- 第13.9.6項「OAM構成ツール実行時にURLが削除されない」

- 第13.9.7項「変更をアクティブ化した後でユーザーがログイン画面にリダイレクトされる」

- 第13.9.8項「変更をアクティブ化した後でユーザーがホーム・ページにリダイレクトされる」

- 第13.9.9項「構成されたJOCポートがすでに使用中」

- 第13.9.10項「管理対象サーバーのメモリー不足の問題」

- 第13.9.11項「BI Publisherの「スケジューラ診断」ページでJMSインスタンスが欠落している」

- 第13.9.12項「管理対象サーバーの停止後にBI Publisherのジョブが不整合な状態になる」

- 第13.9.13項「BI Publisher SchedulerクラスタでのJMSインスタンスの失敗」

- 第13.9.14項「管理者がカスタム・グループに属している場合のMapViewerの構成」

13.9.1 BIアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する

問題: ロード・バランサ・アドレスを使用して、Oracle Business Intelligenceアプリケーション(Oracle BI Presentation Services、Oracle BI Publisher、Oracle RTDなど)にアクセスしようとすると、Webブラウザで「ページが見つかりません」という404エラー・メッセージが表示されます。エラーは断続的に発生し、管理コンソールではOracle Business Intelligenceの管理対象サーバーのステータスは「実行中」と表示されます。

解決方法: Oracle Business Intelligenceの管理対象サーバーが実行中であっても、そのサーバー内のアプリケーションの状態が「アクティブ」ではなく、「管理」や「準備完了」である場合があります。管理対象サーバーが実行中でも、アプリケーションが使用不可になることもあります。管理コンソールの「デプロイメント」ページで、影響を受けるアプリケーションの状態を調べてください。状態は「アクティブ」になっている必要があります。管理対象サーバーの出力ログにそのアプリケーションに関するエラーがないことを確認し、管理コンソールの「デプロイメント」ページでアプリケーションを起動してください。

13.9.2 手動フェイルオーバー後に管理サーバーの起動に失敗する

問題: 管理サーバー・ノードに障害が発生して別のノードへの手動フェイルオーバーが実行された後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。

<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/edg_domain/aserver/edg_domain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

解決方法: ノードの障害発生後にノードを復旧させるときに、ドメイン・ディレクトリに共有記憶域が使用されている場合、ロック・クリーンアップの失敗が原因で、管理サーバーのログにこのエラーが記録されることがあります。このエラーを解決するには、ファイルORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lokを削除します。

13.9.3 管理コンソールで変更をアクティブ化するときにエラーが発生する

問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。

An error occurred during activation of changes, please see the log for details.
[Management:141190]The commit phase of the configuration update failed with an exception:
In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean

解決方法: これは、管理コンソールでサーバーの起動パラメータが変更された場合に発生する可能性があります。この場合、管理コンソールで、構成を変更した特定のサーバーのサーバー起動構成でユーザー名とパスワードの情報を指定します。

13.9.4 サーバー移行後にbi_server管理対象サーバーがフェイルオーバーしない

問題: ローカルのノード・マネージャによる再起動試行回数が最大数に達した後で、フェイルオーバー・ノードのノード・マネージャが再起動を試行しますが、サーバーは起動しません。ノード・マネージャの出力情報には、サーバーがフェイルオーバーしたことが報告されます。ノード・マネージャがbi_server管理対象サーバーの移行を試行した後でも、このサーバーが使用するVIPがフェイルオーバー・ノード内で有効化されていません(フェイルオーバー・ノードでifconfigを実行しても、どのインタフェースのVIPも報告されません)。コマンド「sudo ifconfig $INTERFACE $ADDRESS $NETMASK」を実行しても、そのIPはフェイルオーバー・ノード内で有効化されません。

解決方法: sudo実行の権限と構成により、パスワード入力は要求されません。パスワード入力を要求しなくてもsudoが動作するようにsudoが構成されていることを、システム管理者に確認してください。

13.9.5 サーバー移行後にbi_server管理対象サーバーにブラウザからアクセスできない

問題: サーバー移行は正常に実行されますが(bi_server管理対象サーバーがフェイルオーバー・ノード内で再起動される)、Virtual_Hostname:9704/analytics URLにWebブラウザからアクセスできません。元のホストではすでにサーバーが強制終了(kill)されており、フェイルオーバー・ノードのノード・マネージャでは、VIPが移行済でサーバーが起動していることが報告されます。bi_server管理対象サーバーが使用するVIPに対して、クライアントのノード(ブラウザが使用されているノード)からpingを実行しても応答がありません。

解決方法: ARPキャッシュを更新するためにarpingコマンドがノード・マネージャによって実行されましたが、この更新が適切にブロードキャストされませんでした。この場合、そのノードが外部ノードからは到達不能になります。nodemanager.propertiesファイルを更新してMACBroadcastを追加するか、次のように手動でarpingを実行してください。

/sbin/arping -b -q -c 3 -A -I INTERFACE ADDRESS > $NullDevice 2>&1

ここで、INTERFACEは、仮想IPが有効化されているネットワーク・インタフェース、ADDRESSは仮想IPアドレスです。

13.9.6 OAM構成ツール実行時にURLが削除されない

問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しました。しかし、そのURLの1つに誤記がありました。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。

解決方法: 同じapp_domain名を指定して実行した場合にのみ、OAM構成ツールにより既存のポリシーに新しいURLが追加されます。特定のURLを削除するには、OAMのポリシー・マネージャ・コンソールを使用してください。OAMのアクセス管理サイトにログオンして、「ポリシー・ドメイン」をクリックし、作成済のポリシー・ドメイン(bifoundation_domain)をクリックします。「リソース」タブをクリックし、誤ったURLを削除します。

13.9.7 変更をアクティブ化した後でユーザーがログイン画面にリダイレクトされる

問題: 管理コンソールにアクセスするためにOracle HTTP ServerおよびLBRを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。

解決方法: これは、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、コンソールがその変更を反映しようとすると発生します。変更内容によっては、コンソールが管理サーバーのリスニング・アドレスにリダイレクトされることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、URLをadmin.mycompany.com/console/console.portalに変更すれば、管理コンソールのホーム・ページに直接アクセスできます。

注意:

この項で説明されている変更の追跡を無効にしてある場合は、この問題は発生しません。

13.9.8 変更をアクティブ化した後でユーザーがホーム・ページにリダイレクトされる

問題: OAMを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻りません)。

解決方法: これは、OAM SSOが構成され、管理コンソールが構成の変更を反映するように設定されている場合に発生することが予想されます(リダイレクトはなんらかの変更をアクティブ化する際に管理コンソールによって実行されます)。このリダイレクトにかかわらず、アクティブ化は完了します。連続して変更を行ってもリダイレクトされないようにするには、管理コンソールにアクセスして、「プリファレンス」→「共有プリファレンス」を選択し、「構成変更の追跡」チェック・ボックスの選択を解除します。

13.9.9 構成されたJOCポートがすでに使用中

問題: Javaオブジェクト・キャッシュ(OWSM管理対象サーバーなど)を使用している管理対象サーバーの起動に失敗します。次のエラーがログに表示されます。

J2EE JOC-058 distributed cache initialization failure
J2EE JOC-043 base exception:
J2EE JOC-803 unexpected EOF during read.

解決方法: JOCが取得しようとしているポートを別のプロセスが使用しています。そのプロセスを停止するか、このクラスタのJOCを再構成して、推奨されるポート範囲内で別のポートを使用するようにします。

13.9.10 管理対象サーバーのメモリー不足の問題

問題: 管理対象サーバーでメモリー不足が発生します。

解決方法: Java仮想マシンに割り当てられているメモリー・ヒープのサイズを少なくとも1GBに増やします。

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

2. 「環境」をクリックし、「サーバー」をクリックします。

3. 管理対象サーバー名をクリックします。

4. 「構成」タブを開きます。

5. 2列目にある「サーバーの起動」タブを開きます。

6. 「引数」ボックスでメモリー・パラメータを追加します。例:

-Xms256m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m

注意:

メモリー・パラメータ要件は、各種のJVM(Sun、JRockitなど)ごとに異なる可能性があります。

7. 構成の変更を保存します。

8. 実行されているすべての管理対象サーバーを再起動します。

13.9.11 BI Publisherの「スケジューラ診断」ページでJMSインスタンスが欠落している

BI Publisherの「スケジューラ診断」ページに、クラスタ内のすべてのインスタンスではなく、1つのJMSインスタンスのみが表示される場合があります。この問題はおそらくクロックが同期していないことが原因です。クラスタ内のすべてのノードでクロックを同期させることの重要性の詳細は、第2.5項「クロックの同期」を参照してください。

13.9.12 管理対象サーバーの停止後にBI Publisherのジョブが不整合な状態になる

BI Publisherが実行されている管理対象サーバーを停止する前に、実行中のすべてのBI Publisherジョブの完了を待機するか、または「レポート・ジョブ履歴」ページを使用して未完了のジョブを取り消すことがベスト・プラクティスです(必須ではありません)。それ以外の場合は、停止により一部のジョブが誤って実行状態のまま残る可能性があります。

13.9.13 BI Publisher SchedulerクラスタでのJMSインスタンスの失敗

JMSインスタンスがBI Publisherスケジューラ・クラスタにないことがまれにあります。この問題を解決するには、Oracle WebLogic Server管理コンソールからBI Publisherアプリケーションを再起動します。

BI Publisherアプリケーションを再起動する手順は次のとおりです。

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

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

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

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

5. アプリケーションが停止したら、「開始」をクリックします。

13.9.14 管理者がカスタム・グループに属している場合のMapViewerの構成

WebLogicドメインの管理アカウントでAdministrators(デフォルト)以外のグループ名を使用している場合は、すべてのノードでMapViewer weblogic.xmlファイルを更新し、実際のグループ名が含まれるようにする必要があります。

MapViewerのweblogic.xmlファイルをカスタム・グループ名で更新する手順は次のとおりです。

1. 次のディレクトリで、MapViewerのweblogic.xmlファイルを編集用に開きます。

ORACLE_HOME/bifoundation/jee/mapviewer.ear/web.war/WEB-INF

2. このweblogic.xmlファイルで次の行を検索します。

<security-role-assignment>
<role-name>map_admin_role</role-name>
<principal-name>Administrators</principal-name>
</security-role-assignment>

<security-role-assignment>
<role-name>secure_maps_role</role-name>
<principal-name>Administrators</principal-name>
</security-role-assignment>

3. 表示されている2つのAdministratorsを実際の管理者グループ名で置き換えます(たとえば、BIAdministratorsなど)。例:

<security-role-assignment>
<role-name>map_admin_role</role-name>
<principal-name>BIAdministrators</principal-name>
</security-role-assignment>

<security-role-assignment>
<role-name>secure_maps_role</role-name>
<principal-name>BIAdministrators</principal-name>
</security-role-assignment>

4. ファイルを保存して閉じます。

5. MapViewerアプリケーションを次のように再起動します。

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

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

3. mapviewer(11.1.1)を選択します。

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

5. アプリケーションが停止したら、「起動」をクリックします。

6. この手順をすべてのノードで繰り返します。

索引
A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  R  S  T  U  V  W

記号

.confファイルの<VirtualHost>エントリ, 7.5.2

A

アクセス・ゲート, 12.2.2.4

アクティブ/パッシブ・コンポーネント

概要, 2.1.4

セカンダリ・インスタンスの構成, 9.3.3

admin_vh.conf, 8.4.1 管理コンソール

変更をアクティブ化するときのエラー, 13.9.3

ホーム・ページへのリダイレクト, 13.9.8

ログイン画面へのリダイレクト, 13.9.7

管理サーバー

アプリケーション・ディレクトリの場所, 4.3.4

ドメインのバックアップ, 8.6

APPHOST1のboot.properties, 8.3.2

Oracle HTTP Serverの構成, 8.4.1

カスタム・キーストアを使用するための構成, 10.3.5

ドメインの作成, 8

マシンの作成, 8.3.4.1

高可用性の有効化, 8.3.4

APPHOST1へのフェイルオーバー, 13.5.3

APPHOST2へのフェイルオーバー, 13.5

ポート, 3.5

管理対象サーバー・ドメイン・ディレクトリからのドメイン・ディレクトリの分離, 8.3.4.3

フロントエンドURLの設定, 8.4.4

リスニング・アドレスの設定, 8.3.4.2

起動の失敗, 13.9.2

APPHOST1での起動, 8.3.3

検証, 8.3.5

admin.mycompany.com仮想サーバー名, 3.2.2 ADMINVHN

概要, 3.4

APPHOST1での有効化, 3.4.1

APPHOST

管理サーバーのboot.properties, 8.3.2

ドメインの作成, 8.2

ミドルウェア・ホームの作成, 6.3.1

管理サーバーのフェイルオーバー, 13.5, 13.5.3

Oracle Business Intelligenceのインストール, 6.3.2

Oracle WebLogic Serverのインストール, 6.3.1

共有記憶域の場所のマウント, 4.4

スケール・アウト, 9.3

管理サーバーの起動, 8.3.3

Oracle Business Intelligenceの起動, 9.6.2

APPHOST1VHN1, 3.4 APPHOST2VHN1, 3.4 アプリケーション層

エンタープライズ・デプロイメント・トポロジ, 2.1.4

MW_HOMEディレクトリ, 4.3.4

認証プロバイダ, 12.2.7, 12.3.6

B

バックアップ

管理サーバーを含むドメインの作成後, 8.6

Oracle Business Intelligenceのインストール後, 6.3.3

APPHOST2へのスケール・アウト後, 9.7

Oracle HTTP Serverの設定後, 6.2.3

構成ファイル, 12.1.2.2

エンタープライズ・デプロイメント, 13.6

バックアップ

構成ファイル, 12.3.6.1

インストール, 12.4

ベスト・プラクティス

SQLNet接続のタイムアウト, 13.8

bi_cluster

ルーティング, 8.4.1

Oracle HTTP Serverを使用したアクセスの検証, 8.4.5.2, 9.6.2.4

bi_server1

作成, 8.2

ホスト名検証の無効化, 8.3.7

リスニング・アドレスの設定, 8.3.6

bi_server2

ホスト名検証の無効化, 9.4.2

リスニング・アドレスの設定, 9.4.1

起動, 9.6.2.1

bi_vh.conf, 8.4.1 biinernal_vh.conf, 8.4.1 biinternal.mycompany.com仮想サーバー名, 3.2.3 bi.mycompany.com仮想サーバー名, 3.2.1 管理サーバーのboot.properties, 8.3.2

C

カタログの場所、設定, 9.2.1.2

証明書

ホスト名検証, 10.3

自己署名, 10.3.1

クロックの同期, 2.5 クラスタ・エージェント、概要, 1.2 Cluster Controller、セカンダリ・インスタンスの構成, 9.3.3 クラスタウェア、概要, 1.2 構成

管理サーバーを含むドメインの作成, 8

資格証明ストア, 12.1, 12.1.2

ノード・マネージャのカスタム・キーストア, 10.3.4

デフォルトの永続ストア, 9.6.1

Oracle BI Enterprise Edition, 9.2.1

Oracle BI Publisher, 9.5.3

Oracle Real-Time Decisions, 9.5.2

シングルトン・システム・コンポーネント, 9.3.3

管理コンソールのフロントエンドURL, 8.4.4

使用JOCポート, 13.9.9

ロード・バランサ, 3.3

ノード・マネージャ, 10

Oracle HTTP Server, 7.4

管理サーバー用のOracle HTTP Server, 8.4.1

ポリシー・ストア, 12.1, 12.1.3

ユーザーGUIDの再生成, 12.1.5

サーバーの移行

共有記憶域, 4.4

サーバー移行のターゲット, 11.7

変数, 4.2

仮想ホスト, 7.5

Web層, 7

Webゲート, 12.2.5

構成アシスタント

ドメイン作成のための使用, 8.2

システムのスケール・アウトのための使用, 9.3.1

createCentralInventory.shスクリプト, 6.2.2, 6.3.2 作成

管理サーバーを含むドメイン, 8

ミドルウェア・ホーム, 6.3.1

資格証明ストア

構成, 12.1, 12.1.2

再関連付け, 12.1.4

カスタム・キーストア, 10.3.4

D

データ・ソース, 11.3

データ層

データベース・サービスの構成, 5.3

データベースの要件, 5.2.1

エンタープライズ・デプロイメント・トポロジ, 2.1.5

サポートされているデータベース・バージョン, 5.2.2

データベース

バックアップ, 5.5

コンポーネント、5.4

ポート, 3.5

スキーマの接頭辞, 5.4

要件, 5.2.1

サービス, 5.3

サポートされているバージョン, 5.2.2

デフォルトの永続ストア、構成, 9.6.1 ディレクトリ構造, 4.3

概要, 4

アプリケーション・ディレクトリ(管理サーバー), 4.3.4

アプリケーション・ディレクトリ(管理対象サーバー), 4.3.4

BI Publisher構成フォルダ, 4.3.4

BI Publisher Scheduler一時ディレクトリ, 4.3.4

図, 4.3.5

ドメイン・ディレクトリ, 4.3.4

Essbaseエージェント共有フォルダ・パス, 4.3.4

グローバル・キャッシュの場所, 4.3.4

JMSファイル・ストア, 4.3.4

MW_HOME, 4.3.4, 4.3.4

Oracle BI Presentation Catalog, 4.3.4

ORACLE_BASE, 4.3.4

ORACLE_COMMON_HOME, 4.3.4

ORACLE_HOME, 4.3.4

ORACLE_INSTANCE, 4.3.4

リポジトリ公開ディレクトリ, 4.3.4

Tlogs, 4.3.4

WL_HOME, 4.3.4

ディレクトリ変数, 4.2 ホスト名検証の無効化

bi_server1, 8.3.7

bi_server2, 9.4.2

ドメイン・ディレクトリ

概要, 4.2

管理サーバー・ディレクトリの場所, 4.3.4

管理対象サーバー・ディレクトリの場所, 4.3.4

ドメイン、管理サーバーを含む作成, 8

E

エンタープライズ・デプロイメント

概要, 1.1

アプリケーション層, 2.1.4

バックアップとリカバリ, 13.6

データ層, 2.1.5

ディレクトリ構造, 4, 4.3

ハードウェア要件, 2.2

インストール・サマリー, 2.3

Oracle Identity Management, 2.1.2

パッチ適用, 13.7

共有記憶域, 4

推奨事項のサマリー, 1.3

用語, 1.2

トポロジ, 2.1

トラブルシューティング, 13.9

ユニキャストの要件, 2.1.6

変数, 4.2

Web層, 2.1.3

環境権限, 11.6 Essbaseエージェント共有フォルダ・パス, 4.3.4

F

フェイルバック、概要, 1.2

フェイルオーバー

概要, 1.2

APPHOST1への管理サーバー, 13.5.3

APPHOST2への管理サーバー, 13.5

トラブルシューティング, 13.9.2

ファイアウォール, 3.5 FMW

「Oracle Fusion Middleware」を参照

フロントエンドURL

管理コンソールに対する設定, 8.4.4

G

グローバル・キャッシュ, 4.3.4, 9.2.1.3

グローバル・キャッシュ・パス、設定, 9.2.1.3

GUID、再生成, 12.1.5

H

ハードウェア・クラスタ、概要, 1.2

ハードウェア要件, 2.2

高可用性

追加構成, 9.5

管理サーバーに対する有効化, 8.3.4

ホーム・ページ、リダイレクト, 13.9.8 ホスト識別子, 12.2.3 ホスト名の検証

ノード・マネージャの証明書, 10.3

bi_server1に対する無効化, 8.3.7

bi_server2に対する無効化, 9.4.2

管理対象サーバーに対する設定, 10.3.6

httpd.conf, 7.5.2

I

IDアサータ, 12.2.7.1, 12.3.6.2

アイデンティティ・キーストア, 10.3.2

アイデンティティ・ストア、構成, 12.1.2.3

誤ったURL, 13.9.6

インストール

管理サーバーを含むドメインの作成, 8

ミドルウェア・ホーム, 6.3.1

Oracle Business Intelligence, 6.3.2

Oracle Fusion Middleware, 6.3

Oracle HTTP Server, 6.2

Oracle WebLogic Server, 6.3.1

ソフトウェア, 6.1

概要, 2.3

Webゲート, 12.2.5

instanceconfig.xml, 12.1.5.3

J

Javaオブジェクト・キャッシュ, 13.9.9

Java VM、メモリー・ヒープ, 13.9.10

JMS

Oracle BI Publisher用の構成, 9.5.3.1.3

ファイル・ストアの場所, 4.3.4

JOCポート, 13.9.9

K

キーストア

管理サーバーの構成, 10.3.5

管理対象サーバーの構成, 10.3.5

カスタム, 10.3.4

アイデンティティ, 10.3.2

トラスト, 10.3.3

Keytoolユーティリティ, 10.3.3

L

LDAP

概要, 12.1.1

WebLogic管理者の移動, 12.1.2.5

LDIFファイル, 12.1.3 サーバー移行用のリース表, 11.2 leasing.ddlスクリプト, 11.2 リスニング・アドレス

管理サーバーに対する設定, 8.3.4.2

管理対象サーバーに対する設定, 8.3.6, 9.4.1

ロード・バランサ

構成, 3.3

Oracle HTTP Serverを使用した構成, 7.4

ポート, 3.5

要件, 3.3.1

仮想サーバー, 3.3.2

ログイン画面、リダイレクト, 13.9.7 ログ

Oracle Business Intelligence, 13.3

ノード・マネージャ, 10.2

ローテーション, 13.3

M

マシン、管理サーバーに対する作成, 8.3.4.1

管理対象サーバー

新しいノードへの追加, 13.4.2.1

アプリケーション・ディレクトリの場所, 4.3.4

ドメインのバックアップ, 9.7

カスタム・キーストアを使用するための構成, 10.3.5

bi_server1の作成, 8.2

仮想IP(VIP)の有効化, 3.4.2

Java VMのメモリー・ヒープ, 13.9.10

メモリー不足の問題, 13.9.10

管理サーバー・ドメイン・ディレクトリからのドメイン・ディレクトリの分離, 8.3.4.3

ホスト名検証の設定, 10.3.6

リスニング・アドレスの設定, 8.3.6, 9.4.1

起動, 13.2.1

トポロジの管理, 13 手動フェイルオーバー, 13.9.2 仮想IPのマッピング, 3.4 Java VMのメモリー・ヒープ, 13.9.10 ミドルウェア・ホーム、概要, 1.2 サーバーの移行

「サーバー移行」を参照

トポロジの監視, 13.3 共有記憶域の場所のマウント, 4.4 マルチ・データ・ソース, 11.3 MW_HOME

概要, 4.2

場所, 4.3.4, 4.3.4

N

ネットワーク

ファイアウォール, 3.5

ホスト名, 1.2

ポート, 3.5

クロックの同期化, 2.5

ノード・マネージャ

概要、10.1

ログの場所の変更, 10.2

カスタム・キーストア, 10.3.4

自己署名証明書の生成, 10.3.1

ホスト名検証証明書, 10.3

アイデンティティ・キーストア, 10.3.2

ポート, 3.5

プロパティ・ファイル, 11.5

推奨事項, 10.1

設定, 10

起動, 10.4

トラスト・キーストア, 10.3.3

ノード、サーバーの追加, 13.4.2.1 NQSConfig.INI, 12.1.5.3

O

OAM

「Oracle Access Manager」を参照

OAM、「Oracle Access Manager (OAM)」を参照 oamcfgtool

概要, 12.2.2.1

情報の収集, 12.2.2.2

実行, 12.2.2.3

Oracle Access Manager, 2.1.1

概要, 12.2.1

Oracle BI Publisherでの有効化, 12.2.8.2, 12.3.7.2

Oracle Business Intelligenceでの有効化, 12.2.8.1, 12.3.7.1

IDアサータ, 12.2.7.1

oamcfgtool, 12.2.2

プロバイダの順序, 12.2.7.2

ホスト識別子の更新, 12.2.3

Webゲート・プロファイルの更新, 12.2.4

アクセス・ゲートの確認, 12.2.2.4

ポリシー・ドメインの検証, 12.2.2.4

Webゲート, 12.2.5

WebLogic認証プロバイダ, 12.2.7

Oracle Access Manager(OAM)

IDアサータ, 12.3.6.2

プロバイダの順序, 12.3.6.3

概要,12.3.1

前提条件, 12.3.2

WebLogic認証プロバイダ, 12.3.6

Oracle BIプレゼンテーション・カタログ

ファイルの場所, 4.3.4

場所の設定, 9.2.1.2

Oracle BI Publisher

構成フォルダ, 4.3.4

Presentation Servicesとの統合の構成, 9.5.3.2

JMSの構成, 9.5.3.1.3

SSOの構成, 12.2.8.2, 12.3.7.2

Scheduler一時ディレクトリ, 4.3.4

構成フォルダの場所の設定, 9.2.2

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

Scheduler構成オプションの設定, 9.5.3.1.1

Schedulerに対するWebLogic JNDI URLの設定, 9.5.3.1.2

Scheduler構成の更新, 9.5.3.1.4

Oracle BIリポジトリ、共有場所の設定, 9.2.1.1 Oracle BI Scheduler

セカンダリ・インスタンスの構成, 9.3.3

スクリプト・パスの設定, 9.5.1

Oracle BI Serverポート, 3.5 Oracle Business Intelligence

SSOの構成, 12.2.8.1, 12.3.7.1

ディレクトリ構造, 4.3.5

インストール, 6.3.2

APPHOST2でのスケール・アウト, 9.3

スケール・アップ, 13.4.1

スキーマ、データベースへのロード, 5.4

APPHOST2での起動, 9.6.2

URLの検証, 8.3.8, 9.6.2.3

Oracle Fusion Middleware

バックアップ, 6.3.3

ミドルウェア・ホームの作成, 6.3.1

Oracle Business Intelligenceのインストール, 6.3.2

Oracle WebLogic Serverのインストール, 6.3.1

ソフトウェアのインストール, 6.3

Oracleホーム、概要, 1.2 Oracle HTTP Server

バックアップ, 6.2.3

構成, 7.4

管理サーバーに対する構成, 8.4.1

インストール, 6.2

ロード・バランサ, 3.3.2, 7.4

場所, 6.2.2

ポート, 3.5, 6.2.1

Oracle WebLogic Serverへの登録, 8.4.3

要件, 6.2.1

管理サーバー・アクセスの検証, 8.4.5.1, 13.5.2

bi_clusterアクセスの検証, 8.4.5.2, 9.6.2.4

Oracle Identity Management

エンタープライズ・デプロイメント・トポロジ, 2.1.2

統合, 12

Oracleインスタンス、概要, 1.2 Oracle Real-Time Decisions

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

Oracle WebLogic Scripting Tool(WLST), 使用して管理サーバーを起動, 8.3.3 Oracle WebLogic Server

カスタム・キーストアを使用するための構成, 10.3.5

インストール, 6.3.1

Oracle HTTP Serverの登録, 8.4.3

ORACLE_BASE

概要, 4.2

場所, 4.3.4

ORACLE_COMMON_HOME

概要, 4.2

場所, 4.3.4

ORACLE_HOME

概要, 4.2

場所, 4.3.4

ORACLE_INSTANCE

概要, 4.2

場所, 4.3.4

oracleRoot.shスクリプト, 6.2.2 メモリー不足の問題, 13.9.10

P

pack/unpack、ドメイン・ディレクトリの分離に使用, 8.3.4.3

エンタープライズ・デプロイメントのパッチ適用, 13.7

物理ホスト名、概要, 1.2

物理IP、概要, 1.2

ポリシー・ドメイン, 12.2.2.4

ポリシー・ストア

構成, 12.1, 12.1.3

再関連付け, 12.1.4

ポート, 3.5

管理サーバー, 3.5

データベース, 3.5

使用JOCポート, 13.9.9

ロード・バランサ, 3.5

ノード・マネージャ, 3.5

Oracle BI Server, 3.5

Oracle HTTP Server, 3.5, 6.2.1

データベース・スキーマの接頭辞, 5.4 プライマリ・ノード、概要, 1.2 ノード・マネージャのプロパティ・ファイル, 11.5 OAMのプロバイダの順序, 12.3.6.3 Oracle Access Managerのプロバイダの順序, 12.2.7.2

R

資格証明とポリシーの再関連付け, 12.1.4

推奨事項

エンタープライズ・トポロジ, 1.3

ノード・マネージャ, 10.1

エンタープライズ・デプロイメントのリカバリ, 13.6 ホーム・ページへのリダイレクト, 13.9.8 ログイン画面へのリダイレクト, 13.9.7 WebLogic ServerへのOracle HTTP Serverの登録, 8.4.3 リポジトリ作成ユーティリティ、スキーマのロードに使用, 5.4 リポジトリ公開ディレクトリ, 4.3.4, 9.2.1.1 要件

データベース, 5.2.1

ハードウェア, 2.2

ロード・バランサ, 3.3.1

Oracle HTTP Server, 6.2.1

共有記憶域, 4

ソフトウェア, 6.1

ユニキャスト, 2.1.6

S

スケール・アウト

Oracle Business Intelligence, 9.3, 13.4.2.1

前提条件, 13.4.2

システム・コンポーネント, 9.3.2, 13.4.1

トポロジ, 13.4

スクリプト

createCentralInventory.sh, 6.2.2, 6.3.2

leasing.ddl, 11.2

oracleRoot.sh, 6.2.2

wlsifconfig.sh, 11.6

セカンダリ・ノード、概要, 1.2 自己署名証明書, 10.3.1 サーバー移行, 11

ターゲットの構成, 11.7

マルチ・データ・ソースの作成, 11.3

ノード・マネージャのプロパティ・ファイルの編集, 11.5

リース・テーブル, 11.2

マルチ・データ・ソース, 11.3

環境とスーパー・ユーザー権限の設定, 11.6

ユーザーと表領域の設定, 11.2

テスト, 11.8

トラブルシューティング, 13.9.4, 13.9.5

設定

ノード・マネージャ, 10

WebLogic認証プロバイダ, 12.2.7

WebLogic認証プロバイダの設定, 12.3.6 共有ストレージ

概要, 1.2

構成, 4.4

BI Publisher構成フォルダ, 9.2.2

グローバル・キャッシュ, 9.2.1.3

Oracle BI Presentation Catalog, 9.2.1.2

Oracle BIリポジトリ, 9.2.1.1

Oracle BI Schedulerスクリプト, 9.5.1

マウント場所, 4.4

推奨事項, 4

シングルトン・システム・コンポーネント、セカンダリ・インスタンスの構成, 9.3.3 ソフトウェア

インストール, 6.1

Oracle Fusion Middleware, 6.3

Oracle HTTP Server, 6.2

Oracle WebLogic Server, 6.3.1

要件, 6.1

バージョン, 6.1

SQLNet接続, タイムアウト, 13.8 SSLアクセラレーション要件, 3.3.1 SSO

Oracle BI Publisherでの有効化, 12.2.8.2, 12.3.7.2

Oracle Business Intelligenceでの有効化, 12.2.8.1, 12.3.7.1

起動

APPHOST1の管理サーバー, 8.3.3

管理対象サーバー, 13.2.1

ノード・マネージャ, 10.4

Oracle Business Intelligence, 13.2

システム・コンポーネント, 13.2.2

スティッキーなルーティング機能, 3.3.1 Oracle Business Intelligenceの停止, 13.2 ストレージ

「共有記憶域」を参照

スーパーユーザー権限, 11.6 スイッチバック、概要, 1.2 スイッチオーバー、概要, 1.2 システム・コンポーネント

スケール・アウト, 9.3.2

スケール・アップ, 13.4.1

起動, 9.6.2.2, 13.2.2

T

サーバー移行の表領域, 11.2

サーバー移行のターゲット, 11.7

用語、エンタープライズ・デプロイメント, 1.2

サーバー移行のテスト, 11.8

SQLNet接続のタイムアウト, 13.8

Tlogs, 場所, 4.3.4

トポロジ

ディレクトリ構造, 4, 4.3

エンタープライズ・デプロイメント, 2.1

管理, 13

監視, 13.3

Oracle Access Manager, 2.1.1

スケール・アウト, 13.4.2.1

共有記憶域, 4

変数, 4.2

トラブルシューティング, 13.9

管理サーバーでの変更のアクティブ化, 13.9.3

誤ったURL, 13.9.6

手動フェイルオーバー, 13.9.2

Java VMのメモリー・ヒープ, 13.9.10

ロード・バランサを使用したアプリケーションへのアクセスなし, 13.9.1

メモリー不足の問題, 13.9.10

ホーム・ページへのリダイレクト, 13.9.8

ログイン画面へのリダイレクト, 13.9.7

サーバー移行, 13.9.4, 13.9.5

トラスト・キーストア, 10.3.3

U

ユニキャストの要件, 2.1.6

ホスト識別子の更新, 12.2.3

Webゲート・プロファイルの更新, 12.2.4

URL、Oracle Business Intelligenceに対する検証, 8.3.8, 9.6.2.3

utils.CertGenユーティリティ, 10.3.1

utils.ImportPrivateKeyユーティリティ, 10.3.2

V

検証

アクセス・ゲート, 12.2.2.4

管理サーバー, 8.3.5

Oracle HTTP Serverを使用した管理サーバー・アクセス, 8.4.5.1, 13.5.2

Oracle HTTP Serverを使用したbi_clusterアクセス, 8.4.5.2, 9.6.2.4

Oracle Business IntelligenceのURL, 8.3.8, 9.6.2.3

ポリシー・ドメイン, 12.2.2.4

サーバー移行, 11.8

Web層のインストール, 7.3

変数, 4.2 ソフトウェアのバージョン, 6.1 仮想ホスト名、概要, 1.2 仮想ホスト

ADMINVHN, 3.4

APPHOST1VHN1, 3.4

APPHOST2VHN1, 3.4

構成, 7.5

仮想IP(VIP)

概要, 1.2

説明, 3.4

管理対象サーバーに対する有効化, 3.4.2

マッピング, 3.4

仮想サーバー名, 3.2

W

Web層

構成, 7

エンタープライズ・デプロイメント・トポロジ, 2.1.3

ロード・バランサ要件, 3.3.1

MW_HOMEの場所, 4.3.4

インストールの検証, 7.3

Webゲート

インストールと構成, 12.2.5

プロファイル, 12.2.4

WEBHOST

admin_vh.conf, 8.4.1

bi_vh.conf, 8.4.1

biinternal_vh.conf, 8.4.1

管理サーバーに対するOracle HTTP Serverの構成, 8.4.1

ロード・バランサを使用したOracle HTTP Serverの構成, 7.4

Web層の構成, 7.2

Oracle HTTP Serverのインストール, 6.2.2

ロード・バランサ, 3.3.2

WebLogic ServerへのOracle HTTP Serverの登録, 8.4.3

Oracle HTTP Serverを使用した管理サーバー・アクセスの検証, 8.4.5.1, 13.5.2

Oracle HTTP Serverを使用したbi_clusterアクセスの検証, 8.4.5.2, 9.6.2.4

WebLogic管理者、LDAPへの移動, 12.1.2.5 WebLogic認証プロバイダ, 12.2.7, 12.3.6 WebLogic JNDI URL、Oracle BI Publisher Schedulerに対する設定, 9.5.3.1.2 WebLogic Serverホーム、概要, 1.2 WL_HOME

概要, 4.2

場所, 4.3.4

wlsifconfig.shスクリプト, 11.6

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。