Oracle® Fusion Middleware

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

リリース12.2.1

E70048-02(原本部品番号:E57383-04)

2016年2月

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

Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド, リリース12.2.1

E70048-02

Copyright © 2015, 2016, Oracle and/or its affiliates  All rights reserved.

原本著者: Susan Kornberg (MAAエンジニア)、Phil Stubbs (ライター)、Srinivasan Varadarajan (品質保証)

原本協力著者: Fermin Castro、Peter LaQuerre

協力者: Joe Paul、Michael Rhys、Allwarappan Sundararaj、Chakravarthy Tenneti、Bonnie Vaughan

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

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

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

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社およびその関連会社は一切の責任を負いかねます。

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の登録商標です。

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

目次

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

はじめに

- 対象読者

- 表記規則

第I部 エンタープライズ・デプロイメントの理解

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

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

- 1.2 エンタープライズ・デプロイメント・ガイドを使用するケース

2 標準的なエンタープライズ・デプロイメントの理解

- 2.1 標準的なエンタープライズ・デプロイメントのダイアグラム

- 2.2 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解

- 2.2.1 標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解

- 2.2.2 標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解

- 2.2.3 ハードウェア・ロード・バランサを介したリクエストの受信

- 2.2.3.1 ハードウェア・ロード・バランサ(LBR)の目的

- 2.2.3.1.1 インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト

- 2.2.3.1.2 アプリケーション層のコンポーネント間特有の内部専用通信

- 2.2.3.2 標準的なロード・バランサの仮想サーバー名のサマリー

- 2.2.3.3 外部仮想サーバー名に対するHTTPSリクエストとHTTPリクエストの対比

- 2.2.4 Web層の理解

- 2.2.4.1 リクエストのルーティングにOracle HTTP Serverを使用する利点

- 2.2.4.2 Web層でのOracle HTTP Serverの使用にかわる方法

- 2.2.4.3 Web層でのOracle HTTP Serverの構成

- 2.2.4.4 Mod_WL_OHSについて

- 2.2.5 アプリケーション層の理解

- 2.2.5.1 管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

- 2.2.5.2 アプリケーション層でのOracle Web Services Managerの使用

- 2.2.5.3 アプリケーション層におけるクラスタとホストの構成のベスト・プラクティスとバリエーション

- 2.2.5.4 標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

- 2.2.5.5 アプリケーション層内での通信のためのユニキャストの使用について

- 2.2.5.6 OPSSおよび認証ストアと認可ストアへのリクエストの理解

- 2.2.6 データ層について

3 Business Intelligenceエンタープライズ・デプロイメント・トポロジの理解

- 3.1 プライマリBusiness Intelligenceエンタープライズ・トポロジのダイアグラム

- 3.2 プライマリBusiness Intelligenceトポロジ・ダイアグラムの理解

- 3.2.1 Business Intelligenceのロード・バランサ仮想サーバー名のサマリー

- 3.2.2 Business Intelligenceアプリケーション層の管理対象サーバーとクラスタのサマリー

- 3.3 プライマリBusiness Intelligenceエンタープライズ・トポロジの実装のフロー・チャートとロードマップ

- 3.3.1 プライマリBusiness Intelligenceエンタープライズ・トポロジをインストールおよび構成する手順のフロー・チャート

- 3.3.2 エンタープライズ・デプロイメントの計画と準備のためのロードマップ表

- 3.3.3 Business Intelligenceエンタープライズ・トポロジの構成のためのロードマップ表

第II部 エンタープライズ・デプロイメントの準備

4 エンタープライズ・デプロイメント・ワークブックの使用

- 4.1 エンタープライズ・デプロイメント・ワークブックの概要

- 4.2 ワークブックの標準的なユース・ケース

- 4.3 Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの使用

- 4.3.1 Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの検索

- 4.3.2 Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの内容の理解

- 4.3.2.1 スタート・タブの使用

- 4.3.2.2 ハードウェア - ホスト・コンピュータ・タブの使用

- 4.3.2.3 ネットワーク - 仮想ホストとポート・タブの使用

- 4.3.2.4 ストレージ - ディレクトリ変数タブの使用

- 4.3.2.5 「データベース - 接続の詳細」タブの使用

- 4.4 エンタープライズ・デプロイメント・ワークブックの使用対象者

5 エンタープライズ・デプロイメント用のリソースの取得

- 5.1 エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件

- 5.1.1 ハードウェア・ロード・バランサの要件

- 5.1.2 ホスト・コンピュータのハードウェア要件

- 5.1.2.1 エンタープライズ・デプロイメントのホスト・コンピュータに関する一般的な考慮事項

- 5.1.2.2 Oracle Fusion Middlewareシステム要件の確認

- 5.1.2.3 エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタおよびプロセス数

- 5.1.2.4 エンタープライズ・デプロイメントの標準的なディスク領域要件

- 5.1.3 エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件

- 5.2 エンタープライズ・デプロイメント用の必須IPアドレスの予約

- 5.2.1 仮想IP (VIP)アドレスとは

- 5.2.2 仮想ホスト名と仮想IPアドレスを使用する理由

- 5.2.3 エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス

- 5.3 エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得

6 エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

- 6.1 ハードウェア・ロード・バランサでの仮想ホストの構成

- 6.1.1 ハードウェア・ロード・バランサ構成の概要

- 6.1.2 ハードウェア・ロード・バランサの構成の一般的な手順

- 6.1.3 エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー

- 6.1.4 admin.example.comに関する追加手順

- 6.2 エンタープライズ・デプロイメントのファイアウォールとポートの構成

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

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

- 7.2 エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項

- 7.3 エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解

- 7.4 このガイドで使用するファイル・システムとディレクトリ変数

- 7.5 エンタープライズ・デプロイメント用のディレクトリの作成およびマウントについて

- 7.6 エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー

8 エンタープライズ・デプロイメント用のホスト・コンピュータの準備

- 8.1 各ホストの最小ハードウェア要件の検証

- 8.2 Linuxオペレーティング・システムの要件の検証

- 8.2.1 Linuxのカーネル・パラメータの設定

- 8.2.2 UNIXシステムでのオープン・ファイル制限とプロセス数の設定

- 8.2.2.1 現在開いているファイル数の表示

- 8.2.2.2 オペレーティング・システムのオープン・ファイルおよびプロセス制限の設定

- 8.2.3 DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認

- 8.3 オペレーティング・システムのユーザーおよびグループの構成

- 8.4 Unicodeサポートの有効化

- 8.5 各ホストへの必要な共有ファイル・システムのマウント

- 8.6 各ホストでの必要な仮想IPアドレスの有効化

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

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

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

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

- 9.2.2 その他のデータベース・ソフトウェア要件

- 9.3 データベース・サービスの作成

- 9.4 Oracleデータベースでのラージ・オブジェクト(LOB)に対するSecureFilesの使用

- 9.5 データベース・バックアップ戦略について

第III部 エンタープライズ・デプロイメントの構成

10 エンタープライズ・デプロイメント用の初期BIドメインの作成

- 10.1 BIドメインの作成時に使用する変数

- 10.2 初期BIドメインの理解

- 10.2.1 インフラストラクチャ・ディストリビューションについて

- 10.2.2 初期BIドメインの特徴

- 10.3 エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール

- 10.3.1 サポートされているJDKのインストール

- 10.3.1.1 JDKソフトウェアの検索とダウンロード

- 10.3.1.2 JDKソフトウェアのインストール

- 10.3.2 BIHOST1でのInfrastructureインストーラの起動

- 10.3.3 Infrastructureインストール画面のナビゲート

- 10.3.4 ディレクトリ構造のチェック

- 10.4 エンタープライズ・デプロイメントの準備におけるOracle Business Intelligenceのインストール

- 10.4.1 インストール・プログラムの起動

- 10.4.2 インストール画面のナビゲート

- 10.4.3 ディレクトリ構造のチェック

- 10.5 データベース・スキーマの作成

- 10.5.1 動作保証されたデータベースのインストールと構成

- 10.5.2 リポジトリ作成ユーティリティ(RCU)の起動

- 10.5.3 スキーマ作成のためのRCU画面のナビゲート

- 10.6 BIドメインの構成

- 10.6.1 構成ウィザードの起動

- 10.6.2 BIドメインを構成するための構成ウィザード画面のナビゲート

- 10.7 BIHOST1でのシステム・コンポーネントの作成

- 10.8 BIサービス・インスタンスの作成

- 10.9 シングルトン・データ・ディレクトリ(SDD)の構成

- 10.10 Oracle Business IntelligenceでのEssbaseのセキュリティの構成

- 10.11 ドメイン・ディレクトリの構成とBIHOST1上のサーバーの起動

- 10.11.1 BIHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動

- 10.11.2 boot.propertiesファイルの作成

- 10.11.3 管理サーバーの起動

- 10.11.4 管理サーバーの検証

- 10.11.5 Derbyデータベースの無効化

- 10.11.6 BIHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成

- 10.11.7 BIHOST1上の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

- 10.11.8 BIHOST1でのWLS_BI1管理対象サーバーの起動

- 10.11.9 システム・コンポーネントの起動

- 10.12 グローバル・キャッシュの設定

- 10.13 BIHOST1でのOracle Business Intelligence URLの確認

- 10.14 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング

- 10.14.1 サポートされている認証プロバイダについて

- 10.14.2 エンタープライズ・デプロイメント・ユーザーおよびグループについて

- 10.14.2.1各ドメインで一意の管理ユーザーの使用について

- 10.14.2.2 ドメイン・コネクタ・ユーザーについて

- 10.14.2.3 中央LDAPディレクトリへのユーザーの追加について

- 10.14.2.4 Oracle Business Intelligenceの製品固有のロールとグループについて

- 10.14.2.5 このガイドで使用するサンプル・ユーザーとサンプル・ロール

- 10.14.3 新しい認証プロバイダの作成とユーザーおよびグループのプロビジョニングの前提条件

- 10.14.4 LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

- 10.14.5 新しい認証プロバイダの作成

- 10.14.6 エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

- 10.14.7 管理グループへの新しい管理ユーザーの追加

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

- 10.15 Oracle Business Intelligence構成のバックアップ

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

- 11.1 Web層の構成時に使用される変数

- 11.2 Web層ドメインについて

- 11.3 WEBHOST1へのOracle HTTP Serverのインストール

- 11.3.1 WEBHOST1でのインストーラの起動

- 11.3.2 Oracle HTTP Serverのインストール画面のナビゲート

- 11.3.3 Oracle HTTP Serverインストールの確認

- 11.4 WEBHOST1でのWeb層ドメインの作成

- 11.4.1 WEBHOST1での構成ウィザードの起動

- 11.4.2 Web層ドメイン用の構成ウィザード画面のナビゲート

- 11.5 WEBHOST2でのWeb層ドメインのインストールおよび構成

- 11.6 WEBHOST1およびWEBHOST2でのノード・マネージャおよびOracle HTTP Serverインスタンスの起動

- 11.6.1 WEBHOST1およびWEBHOST2でのノード・マネージャの起動

- 11.6.2 Oracle HTTP Serverインスタンスの起動

- 11.7 アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成

- 11.7.1 エンタープライズ・デプロイメント用のOracle HTTP Server構成について

- 11.7.1.1Oracle HTTP Server仮想ホストの目的

- 11.7.1.2 Oracle HTTP Server構成ファイルの推奨構造

- 11.7.2 仮想ホスト構成ファイルを追加するためのhttpd.confファイルの変更

- 11.7.3 Oracle Business Intelligenceの仮想ホスト構成ファイルの作成

- 11.7.4 ロード・バランサでの仮想サーバー構成の検証

- 11.7.5 管理コンソールおよび管理サーバーへのアクセスの検証

- 11.7.6 Business IntelligenceコンポーネントへのHTTPアクセスの検証

- 11.8 構成のバックアップ

12 Oracle Business Intelligenceのスケール・アウト

- 12.1 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

- 12.2 他のホスト・コンピュータへのOracle Business Intelligenceのインストール

- 12.3 BIHOST1のコンポーネントの停止

- 12.3.1 システム・コンポーネントの停止

- 12.3.2 WLS_BI1管理対象サーバーの停止

- 12.3.3 管理サーバーの停止

- 12.3.4 管理サーバー・ドメイン・ホームでのノード・マネージャの停止

- 12.3.5 管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの停止

- 12.4 BIHOST1のコンポーネントのクローニング

- 12.5 BIHOST1の初期ドメインの圧縮

- 12.6 BIHOST2でのドメインの解凍

- 12.7 スケール・アウト後のBIHOST1およびBIHOST2でのコンポーネントの起動

- 12.7.1 管理サーバー・ドメイン・ホームでのノード・マネージャの起動

- 12.7.2 管理サーバーの起動

- 12.7.3 管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

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

- 12.7.5 WebLogicプロキシ・プラグインの構成

- 12.7.6 管理対象サーバーの起動

- 12.7.7 システム・コンポーネントの起動

- 12.8 BIHOST2でのOracle Business Intelligence URLの確認

- 12.9 Oracle BI Publisherの構成

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

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

- 12.10 スケール・アウト後のOracle Business Intelligence構成のバックアップ

第IV部 エンタープライズ・デプロイメントの共通の構成および管理手順

13 エンタープライズ・デプロイメントの共通の構成および管理タスク

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

- 13.1.1 別のホストへの管理サーバーのフェイルオーバー

- 13.1.2 Oracle HTTP Serverを介したBIHOST2上の管理サーバーへのアクセスの検証

- 13.1.3 BIHOST1への管理サーバーのフェイルバック

- 13.2 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

- 13.2.1 中間層とロード・バランサ間のSSL通信が必要になるとき

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

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

- 13.2.4 Keytoolユーティリティを使用した信頼キーストアの作成

- 13.2.5 トラスト・ストアへのロード・バランサ証明書のインポート

- 13.2.6 Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

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

- 13.2.8 カスタム・キーストアを使用するためのWebLogic Serverの構成

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

14 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

- 14.1 エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について

- 14.1.1 サーバー全体の移行とサービスの移行の違いの理解

- 14.1.2 エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

- 14.1.3 サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

- 14.2 リース用のGridLinkデータ・ソースの作成

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

- 14.3.1 ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

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

- 14.3.2.1 wlsifconfig.shスクリプトのPATH環境変数の設定

- 14.3.2.2 wlsifconfig.shスクリプトに対する権限の付与

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

- 14.3.4 サーバー全体の移行のテスト

- 14.4 エンタープライズ・デプロイメント内での自動サービス移行の構成

- 14.4.1 エンタープライズ・デプロイメント・クラスタのリーシング・メカニズムとデータ・ソースの設定

- 14.4.2 クラスタ内の管理対象サーバーの移行設定の変更

- 14.4.3 サービス移行ポリシーの選択について

- 14.4.4 クラスタ内の各管理対象サーバーのサービス移行ポリシーの設定

- 14.4.5 管理対象サーバーの再起動と自動サービス移行の検証

- 14.4.6 自動サービス移行後のサービスのフェイルバック

15 エンタープライズ・デプロイメント用のシングル・サインオンの構成

- 15.1 Oracle HTTP Server WebGateについて

- 15.2 Oracle HTTP Server 12c Webgateの構成の一般的な前提条件

- 15.3 OHS 12c Webgateの構成に関するエンタープライズ・デプロイメントの前提条件

- 15.4 エンタープライズ・デプロイメント用のOracle HTTP Server 12c WebGateの構成

- 15.5 Oracle Access ManagerへのOracle HTTP Server 12c WebGateの登録

- 15.5.1 RREGツールの検索と準備

- 15.5.2 RREGインバンドおよびアウトオブバンド・モードについて

- 15.5.3 OAM11gRequest.xmlファイルの標準プロパティの更新

- 15.5.4 エンタープライズ・デプロイメントの保護リソース、パブリック・リソース、除外リソースの更新

- 15.5.5 RREGツールの実行

- 15.5.5.1 インバンド・モードでのRREGツールの実行

- 15.5.5.2 アウトオブバンド・モードでのRREGツールの実行

- 15.5.6 RREGによって生成されるファイルおよびアーティファクト

- 15.5.7 生成済のアーティファクトのOracle HTTP Server WebGateインスタンスの場所へのコピー

- 15.5.8 Oracle HTTP Serverインスタンスの再起動

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

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

- 15.6.2 Oracle Access Manager IDアサーション・プロバイダの設定

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

- 15.7 Oracle Access Managerを使用したOracle ADFおよびOPSSセキュリティの構成

- 15.8 アプリケーションのシングル・サインオンの構成

- 15.8.1 Oracle BI EEのためのシングル・サインオンおよびOracle Access Managerの有効化

- 15.8.2 Oracle BI Publisherのためのシングル・サインオンおよびOracle Access Managerの有効化

A Oracle RACでのマルチ・データ・ソースの使用

- A.1 マルチ・データ・ソースとOracle RACについて

- A.2 エンタープライズ・デプロイメントでマルチ・データ・ソースを構成するための標準的な手順

はじめに

このガイドでは、可用性の高いOracle Fusion Middlewareエンタープライズ・デプロイメントのインストール、構成および管理方法について説明します。詳細は、「エンタープライズ・デプロイメント・ガイドについて」を参照してください。

- 対象読者

- 表記規則

対象読者

一般に、このドキュメントは、本番デプロイメント用にOracle Fusion Middlewareソフトウェアをインストールして構成するタスクを割り当てられている、Oracle Fusion Middlewareの管理者を対象としています。

データベース管理者(DBA)やネットワーク管理者など、より専門的な管理者に特定のタスクを割り当てることも可能です(該当する場合)。

表記規則

このマニュアルでは次の表記規則を使用します。

表記規則

意味

太字

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

イタリック

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

固定幅フォント

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

注意:

このガイドでは、Oracle Linuxシステムにおけるエンタープライズ・デプロイメント参照用トポロジの実装を中心に取り上げています。

このトポロジは、動作保証済でサポートされている任意のオペレーティング・システムで実装可能ですが、このガイドの例には、多くの場合、Oracle Linux上でbashシェルを使用して実行する必要があるコマンドと構成手順が示されています。

第I部 エンタープライズ・デプロイメントの理解

エンタープライズ・デプロイメント・ガイドのこの部には、次のトピックが含まれています。

- エンタープライズ・デプロイメントの概要
この章ではOracle Fusion Middlewareエンタープライズ・デプロイメントの概念を説明します。

- 標準的なエンタープライズ・デプロイメントの理解
この章では、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントの全般的な特徴について説明します。ここで説明する概念は、どの製品固有のエンタープライズ・デプロイメントにも適用できます。

- Business Intelligenceエンタープライズ・デプロイメント・トポロジの理解
次のトピックでは、Oracle Business Intelligenceエンタープライズ・デプロイメント・トポロジについて説明します。

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

この章ではOracle Fusion Middlewareエンタープライズ・デプロイメントの概念を説明します。

また、エンタープライズ・デプロイメント・ガイドを使用する時期についても取り上げます。

- エンタープライズ・デプロイメント・ガイドについて
エンタープライズ・デプロイメント・ガイドは、選択したOracle Fusion Middleware製品のセキュアかつ高可用性の本番品質デプロイメントをインストール、構成および保守するための包括的でスケーラブルな例を提供します。この結果として作成される環境をエンタープライズ・デプロイメント・トポロジと呼びます。

- エンタープライズ・デプロイメント・ガイドを使用するケース
このガイドでは、Oracle Fusion Middlewareの主な3つのインストールおよび構成オプションのうち1つについて説明します。このガイドを使用すると、選択したOracle Fusion Middleware製品のマルチホスト型でセキュアかつ高可用性の本番トポロジを計画、準備、インストールおよび構成できます。

親トピック: エンタープライズ・デプロイメントの理解

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

エンタープライズ・デプロイメント・ガイドは、選択したOracle Fusion Middleware製品のセキュアかつ高可用性の本番品質デプロイメントをインストール、構成および保守するための包括的でスケーラブルな例を提供します。この結果として作成される環境をエンタープライズ・デプロイメント・トポロジと呼びます。

エンタープライズ・デプロイメント・トポロジは、類似のOracle Fusion Middleware環境を各組織に実装するときに使用できる主な概念やベスト・プラクティスを、例を通じて紹介します。

各エンタープライズ・デプロイメント・ガイドには、参照用トポロジを実装するための詳細な検証済手順が記載されています。また、Oracle Fusion Middlewareエンタープライズ・デプロイメントの概念、参考資料および追加オプションについて説明しているサポート・ドキュメントへのリンクも用意されています。

エンタープライズ・デプロイメント・ガイドに記述されているエンタープライズ・デプロイメント・トポロジは、Oracleをご使用のすべてのお客様の要件を完全に満たすものではありません。場合によっては、トポロジのバリエーションがオラクル社によって文書化されサポートされているどうかに応じて、このガイドで説明されている以外の代替手順も検討できます。

エンタープライズ・デプロイメント・ガイドをデプロイメントの第1選択肢として使用することをお薦めします。バリエーションが必要な場合は、関連するOracleドキュメントを確認するか、Oracleサポートと共同でそれらのバリエーションを検証する必要があります。

1.2 エンタープライズ・デプロイメント・ガイドを使用するケース

このガイドでは、Oracle Fusion Middlewareの主な3つのインストールおよび構成オプションのうち1つについて説明します。このガイドを使用すると、選択したOracle Fusion Middleware製品のマルチホスト型でセキュアかつ高可用性の本番トポロジを計画、準備、インストールおよび構成できます。

または次の方法を使用できます。

- 各製品のインストレーション・ガイドを使用して、選択した一連のOracle Fusion Middleware製品の標準インストール・トポロジをインストールおよび構成する。
標準インストール・トポロジは評価用として単一ホストにインストールできますが、より複雑な本番環境にスケール・アウトするための開始点にもなります。

Oracle Business Intelligenceの場合は、次を参照してください。

- Oracle Business Intelligenceのインストールと構成

- 『Oracle Fusion Middlewareのインストールのプランニング』を確認する。このドキュメントには、すべてのOracle Fusion Middlewareインストールの準備に役立つ追加情報が記載されています。

2 標準的なエンタープライズ・デプロイメントの理解

この章では、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントの全般的な特徴について説明します。ここで説明する概念は、どの製品固有のエンタープライズ・デプロイメントにも適用できます。

この章では、エンタープライズ・デプロイメント・トポロジのダイアグラムについて説明します。

- 標準的なエンタープライズ・デプロイメントのダイアグラム
この項では、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントを示します。

- 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解
この項では、標準的なエンタープライズ・トポロジ・ダイアグラムについて詳しく説明します。

親トピック: エンタープライズ・デプロイメントの理解

2.1 標準的なエンタープライズ・デプロイメントのダイアグラム

この項では、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントを示します。

すべてのOracle Fusion Middlewareエンタープライズ・デプロイメントは、Oracle Fusion Middleware本番環境のインストールと構成に関するベスト・プラクティスを示すように設計されています。

ベスト・プラクティス・アプローチは、複数層デプロイメントと、異なるソフトウェア層間の標準的通信の基本概念で始まります。

図2-1 に、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントを示します。すべてのエンタープライズ・デプロイメントは、これらの基本原則に基づいています。

標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで通信に使用される各層と標準プロトコルの説明は、「標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解」を参照してください。

図2-1 標準的なエンタープライズ・デプロイメント・トポロジのダイアグラム

2.2 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解

この項では、標準的なエンタープライズ・トポロジ・ダイアグラムについて詳しく説明します。

- 標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解

- 標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解

- ハードウェア・ロード・バランサを介したリクエストの受信

- Web層の理解

- アプリケーション層の理解

- データ層について

2.2.1 標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解

トポロジは、ファイアウォールによって隔てられている、次のようないくつかのセキュリティ・ゾーンに分かれています。

- Web層(またはDMZ)。ハードウェア・ロード・バランサとユーザーからの初期リクエストを受信するWebサーバー(ここではOracle HTTP Serverインスタンス)で使用されます。このゾーンには、ロード・バランサ上で定義されている単一の仮想サーバー名を介してのみアクセスできます。

- アプリケーション層。ビジネス・ロジックとアプリケーション・ロジックが配置されている場所です。

- データ層。インターネットからアクセスできず、可用性の高いデータベース・インスタンス用にこのトポロジで予約されます。

ファイアウォールは、特定の通信ポートを介した場合にのみデータ転送が許可されるように構成されています。これらのポート(または、場合によってはファイアウォール内の開いているポートを必要とするプロトコル)は、ダイアグラム内の各ファイアウォール・ライン上に示しています。

次に例を示します。

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

- アプリケーション層を保護するファイアウォール上では、HTTPポートとMBeanプロキシ・ポートが開いています。
外部HTTPアクセスが必要なアプリケーションは、プロキシとしてOracle HTTP Serverインスタンスを使用できます。このポートはアウトバウンド通信専用であり、Oracle HTTP Serverのプロキシ機能を有効にする必要があります。

- データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(通常は1521)が開かれている必要があります。
また、認可プロバイダとLDAPベースのアイデンティティ・ストア間の通信用に、LDAPポート(通常は389と636)も開いている必要があります。

アプリケーション層がOracle RACデータベース・ワークロードとイベントに関する通知を受信できるように、ONSポート(通常は6200)も必要です。これらのイベントは、Oracle RACデータベース・インスタンスの可用性とワークロードに応じて、Oracle WebLogic Server接続プールが迅速に調整(接続の作成または破棄)するために使用されます。

特定のOracle Fusion Middlewareエンタープライズ・デプロイメント・トポロジにおいて開いておく必要があるポートの全リストは、実装するトポロジについて説明している章を参照するか、実装するトポロジのエンタープライズ・デプロイメント・ワークブックを参照してください。詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください。

2.2.2 標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解

エンタープライズ・デプロイメント・トポロジは、大まかに次の要素で構成されます。

- ハードウェア・ロード・バランサ。インターネットからのリクエストをWeb層内のWebサーバーにルーティングします。また、社内ネットワーク内で内部呼出しを実行する内部クライアントや他のコンポーネントからのリクエストもルーティングします。

- Web層。ハードウェア・ロード・バランサとWebサーバー・インスタンスをホストする2つ以上の物理コンピュータで構成されています(高可用性のため)。
Webサーバー・インスタンスは、ユーザーを認証し(外部アイデンティティ・ストアおよびシングル・サインオン・サーバーを使用)、HTTPリクエストを、アプリケーション層内で実行されているOracle Fusion Middleware製品とコンポーネントにルーティングするように構成されています。

また、Webサーバー・インスタンスは、アプリケーション・ロジックの提供を必要としない静的Webコンテンツをホストします。このようなコンテンツをWeb層に配置することで、アプリケーション・サーバーのオーバーヘッドが低減され、不要なネットワーク・アクティビティが排除されます。

- アプリケーション層。Oracle WebLogic Server管理対象サーバーのクラスタとドメイン用の管理サーバーをホストする2つ以上の物理コンピュータで構成されています。管理対象サーバーは、エンタープライズ・デプロイメントでの製品の選択に応じて、Oracle SOA Suite、Oracle Service Bus、Oracle WebCenter Content、Oracle WebCenter Portalなどの様々なOracle Fusion Middleware製品を実行するように構成されています。

- データ層。Oracle RACデータベースをホストする2つ以上の物理ホストで構成されています。

2.2.3 ハードウェア・ロード・バランサを介したリクエストの受信

次のトピックでは、エンタープライズ・デプロイメントにおけるハードウェア・ロード・バランサとその役割について説明します。

- ハードウェア・ロード・バランサ(LBR)の目的

- 標準的なロード・バランサの仮想サーバー名のサマリー

- 外部仮想サーバー名に対するHTTPSリクエストとHTTPリクエストの対比

2.2.3.1 ハードウェア・ロード・バランサ(LBR)の目的

次のトピックでは、エンタープライズ・デプロイメントでハードウェア・ロード・バランサによって処理されるリクエストのタイプについて説明します。

- インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト

- アプリケーション層のコンポーネント間特有の内部専用通信

2.2.3.1.1 インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト

ハードウェア・ロード・バランサは、1つの仮想ホスト名へのリクエストを受信して各リクエストをロード・バランシング・アルゴリズムに基づいてWebサーバー・インスタンスの1つにルーティングすることで、Web層でのロードをバランシングします。このようにして、ロード・バランサは、特定のWebサーバーがHTTPリクエストによってオーバーロードにならないようにします。

ハードウェア・ロード・バランサの特定の仮想ホスト名の用途の詳細は、「標準的なロード・バランサの仮想サーバー名のサマリー」を参照してください。

参照用トポロジでは、HTTPリクエストのみがハードウェア・ロード・バランサからWeb層にルーティングされることに注意してください。Secure Socket Layer (SSL)リクエストはロード・バランサで終了され、HTTPリクエストのみがOracle HTTP Serverインスタンスに転送されます。このガイドでは、ロード・バランサとOracle HTTP Serverインスタンス間およびWeb層とアプリケーション層間のSSL構成について説明していません。

ロード・バランサは、Webサーバーの1つが停止した場合に残りの稼働中のWebサーバーにリクエストがルーティングされるようにすることで、高可用性を実現します。

また、標準的な高可用性構成では、メインのロード・バランシング装置で障害が発生した場合にホット・スタンバイ・デバイスがすぐにサービスを再開できるように、複数のハードウェア・ロード・バランサが構成されます。多種のサービスおよびシステムにとってハードウェア・ロード・バランサは呼出しを行う唯一のアクセス・ポイントとなり、保護されていない場合にはシステム全体の単一障害点(SPOF)となるため、このことは重要です。

2.2.3.1.2 アプリケーション層のコンポーネント間特有の内部専用通信

さらに、ハードウェア・ロード・バランサは、Oracle Fusion Middlewareコンポーネントとアプリケーション層のアプリケーション間に特有の通信をルーティングします。内部専用のリクエストも、ロード・バランサを介してルーティングされます(一意の仮想ホスト名を使用する)。

2.2.3.2 標準的なロード・バランサの仮想サーバー名のサマリー

サーバー上のロードのバランシングと高可用性の提供のために、ハードウェア・ロード・バランサは一連の仮想サーバー名を認識するように構成されています。ダイアグラムに示すように、このトポロジではハードウェア・ロード・バランサによって次の仮想サーバー名が認識されます。

- product.example.com: この仮想サーバー名はすべての受信トラフィックに使用されます。
ユーザーは、このURLを入力して、デプロイしたOracle Fusion Middleware製品およびこのサーバー上で使用可能なカスタム・アプリケーションにアクセスします。その後、ロード・バランサによってそれらのリクエストが(ロード・バランシング・アルゴリズムを使用して)Web層内のサーバーの1つにルーティングされます。このようにすることで、1つの仮想サーバー名を使用してトラフィックを複数のサーバーにルーティングすることが可能になり、Webサーバー・インスタンスのロード・バランシングと高可用性が実現されます。

- productinternal.example.com: この仮想サーバー名は、内部通信専用です。
ロード・バランサは、そのネットワーク・アドレス変換(NAT)機能を使用して、アプリケーション層コンポーネントからこのURLへの内部通信をすべてルーティングします。このURLは、インターネット上の外部顧客またはユーザーには公開されていません。各製品には、内部URLに固有の用途があるため、デプロイメント手順では、接頭辞に製品名を付加しています。

- admin.example.com: この仮想サーバー名は、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server管理コンソール・インタフェースにアクセスする必要がある管理者用です。
このURLは、内部管理者のみが知っています。また、ロード・バランサのNAT機能を使用することで、管理者はドメイン内のアクティブな管理サーバーにルーティングされます。

自身のトポロジに対して定義する必要がある仮想サーバー名の完全なセットについては、製品固有のトポロジが記載されている章を参照してください。

2.2.3.3 外部仮想サーバー名に対するHTTPSリクエストとHTTPリクエストの対比

ハードウェア・ロード・バランサを構成する場合は、メインの外部URL (たとえば、http://myapplication.example.com)をポート80およびポート443に割り当てることをお薦めします。

ポート80 (非SSLプロトコル)に対するリクエストはすべて、ポート443 (SSLプロトコル)にリダイレクトする必要があります。このルールの例外としては、パブリックWSDLからのリクエストがあります。詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

2.2.4 Web層の理解

参照トポロジのWeb層は、ロード・バランサからリクエストを受信するWebサーバーで構成されます。標準的なエンタープライズ・デプロイメントでは、Web層内に2つ以上のOracle HTTP Serverインスタンスが構成されています。次のトピックで、詳細を説明します。

- リクエストのルーティングにOracle HTTP Serverインスタンスを使用する利点

- Web層でのOracle HTTP Serverの使用にかわる方法

- Web層でのOracle HTTP Serverの構成

- Mod_WL_OHSについて

2.2.4.1 リクエストのルーティングにOracle HTTP Serverインスタンスを使用する利点

Oracle HTTP Serverを含むWeb層の使用は、多くのOracle Fusion Middleware製品の必要条件ではありません。アプリケーション層でハードウェア・ロード・バランサからWLSサーバーへ直接トラフィックをルーティングできます。ただし、Web層にはいくつかの利点があり、それが、参照用トポロジの一部としてお薦めする理由です。

- Web層はDMZパブリック・ゾーンを提供します。これはセキュリティ監査における一般的な必要条件です。ロード・バランサがWebLogic Serverに直接ルーティングを行うと、リクエストがロード・バランサからアプリケーション層に1回のHTTPジャンプで移動するため、セキュリティ上の問題を引き起こす可能性があります。

- Web層では、Webサーバー構成を変更することなく、WebLogic Serverクラスタ・メンバーシップを再構成(新規サーバーの追加とサーバーの削除)できます(構成したリスト内のサーバーのいくつかがアライブであることが条件)。

- Oracle HTTP ServerはWebLogic Serverより効率的かつ高速に静的コンテンツを提供します。また、一部のエンタープライズ・デプロイメントに必要なFTPサービス、およびOracle HTTP Server構成ファイルによる仮想ホストおよびプロキシの作成機能も提供します。

- Oracle HTTP Serverは、WebLogic Serverが提供する機能に加えてHTTPリダイレクションを提供します。Oracle HTTP Serverを多様なWebLogic Serverクラスタのフロント・エンドとして使用でき、場合によっては、コンテンツ・ベースのルーティングを実行してルーティングを制御できます。

- Oracle HTTP Serverは、エンタープライズ・デプロイメントにシングル・サインオン機能を統合する機能を提供します。たとえば、Oracle Identity and Access Management製品ファミリの一部であるOracle Access Managerを使用して、後からシングル・サインオンをエンタープライズ・デプロイメントに実装できます。

- Oracle HTTP Serverは、WebLogic Server内にデプロイされているWebSocket接続のサポートを提供します。

Oracle HTTP Serverの詳細は、『Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの概要に関する項を参照してください。

2.2.4.2 Web層でのOracle HTTP Serverの使用にかわる方法

Oracle HTTP Serverはエンタープライズ・トポロジに様々な利点をもたらしますが、中間層でハードウェア・ロード・バランサから管理対象サーバーへリクエストを直接ルーティングする方法もサポートされています。

この方法には、次の利点があります。

- フロントエンドOracle HTTP ServerのWeb層フロントエンドを使用するよりも構成と処理のオーバーヘッドが小さい。

- 管理対象サーバーごとに固有のURLを監視するようにLBRを構成できるので、アプリケーション・レベルでの監視が可能(OHSでは不可能)。
このロード・バランサ機能を使用して、SOAコンポジット・アプリケーションのURLを監視することもできます。この場合、すべてのコンポジットがデプロイされたときにのみ管理対象サーバーへのルーティングが可能になります。また、適切な監視ソフトウェアを使用する必要があります。

2.2.4.3 Web層でのOracle HTTP Serverの構成

Oracle Fusion Middleware 12c以降、Oracle HTTP Serverソフトウェアは既存のOracle WebLogic Serverドメインの一部として構成するか、または独自のスタンドアロン・ドメインで構成できるようになりました。各構成には、固有の利点があります。

Oracle HTTP Serverインスタンスを既存のWebLogic Serverドメインの一部として構成すると、Oracle Enterprise Manager Fusion Middleware Controlを使用して、WebサーバーとOracle WebLogic Server管理対象サーバー間の通信のワイヤリングなど、Oracle HTTP Serverインスタンスの管理を行うことができます。Oracle HTTP Serverをスタンドアロン構成で構成すると、Oracle HTTP Serverインスタンスをアプリケーション層のドメインとは別に構成および管理できます。

このエンタープライズ・デプロイメント・ガイドでは、Oracle HTTP Serverインスタンスは、各Web層ホストに1つずつ、別個のスタンドアロン・ドメインとして構成されます。Oracle HTTP Serverインスタンスをアプリケーション層ドメインの一部として構成することもできますが、このエンタープライズ・デプロイメント・ガイドでは、そのようにOracle HTTP Serverインスタンスを構成するための手順は示されません。

詳細は、『Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverのインストール・オプションの理解に関する項を参照してください。

2.2.4.4 Mod_WL_OHSについて

ダイアグラムに示すように、Oracle HTTP Serverインスタンスは、Oracle HTTP Serverからアプリケーション層のOracle WebLogic Server管理対象サーバーへのHTTPリクエストのプロキシに、WebLogicプロキシ・プラグイン(mod_wl_ohs)を使用します。

詳細は、Oracle WebLogic Serverプロキシ・プラグイン12.1.3の使用のWeb Serverプロキシ・プラグイン12.1.3の概要に関する項を参照してください。

2.2.5 アプリケーション層の理解

アプリケーション層は2つの物理ホスト・コンピュータで構成されており、そこにOracle WebLogic ServerおよびOracle Fusion Middleware製品がインストールされて構成されます。アプリケーション層のコンピュータは、ファイアウォール1とファイアウォール2の間のセキュリティ保護されたゾーンに配置されます。

次のトピックで詳細情報を提供します。

- 管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

- アプリケーション層でのOracle Web Services Managerの使用

- アプリケーション層におけるクラスタとホストの構成のベスト・プラクティスとバリエーション

- 標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

- アプリケーション層内での通信のためのユニキャストの使用について

- OPSSおよび認証ストアと認可ストアへのリクエストの理解

2.2.5.1 管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

ドメイン内の管理対象サーバーとは異なり、管理サーバーはアクティブ/パッシブ高可用性構成を使用します。これは、Oracle WebLogic Serverドメイン内で実行できる管理サーバーは1つのみであるためです。

トポロジ・ダイアグラムでは、HOST1上の管理サーバーがアクティブな状態で、HOST2上の管理サーバーがパッシブ(非アクティブ)の状態です。

システム障害時に管理サーバーの手動フェイル・オーバーをサポートする標準的なエンタープライズ・デプロイメント・トポロジには、次のものが含まれます。

- 管理サーバーのリクエストのルーティング用の仮想IPアドレス(VIP)

- 共有記憶域デバイス上の管理サーバー・ドメイン・ディレクトリの構成

システム障害(HOST1の障害など)が発生した場合、管理サーバーのVIPアドレスをドメイン内の別のホストに手動で再割当てし、管理サーバーのドメイン・ディレクトリをその新しいホストにマウントして、新しいホスト上で管理サーバーを起動できます。

ただし、管理サーバーと違い、管理対象サーバーを共有記憶域に格納するメリットはありません。実際に、管理対象サーバーの構成データをホスト・コンピュータのローカル・ディスクに格納しないと、パフォーマンスに影響するおそれがあります。

したがって、標準的なエンタープライズ・デプロイメントでは、管理サーバーのドメインを共有記憶域上で構成すると、ドメイン構成のコピーが各ホスト・コンピュータのローカル記憶域デバイスに配置され、このドメイン構成のコピーから管理対象サーバーが起動されます。このコピーの作成には、Oracle WebLogic Serverのpackおよびunpackユーティリティを使用します。

結果として、各ホストに別個のドメイン・ディレクトリを配置する構成となります。つまり、管理サーバー(共有記憶域上)と管理対象サーバー(ローカル記憶域上)に1つずつ配置します。必要なアクションに応じて、いずれかのドメイン・ディレクトリから構成タスクを実行する必要があります。

管理サーバーのドメイン・ディレクトリと管理対象サーバーのドメイン・ディレクトリの構造、およびこれらのディレクトリの参照に使用する変数の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。

複数ドメイン・ディレクトリ・モデルには追加の利点があります。管理サーバーを管理対象サーバーから切り離すことができます。デフォルトのプライマリ・エンタープライズ・デプロイメント・トポロジでは、アプリケーション層のホストの1つに管理サーバーのドメイン・ディレクトリが存在することを想定していますが、管理サーバーによるCPUまたはRAMの消費量が多いときなど、必要な場合に管理サーバーを独自のホストから実行することで、管理サーバーをさらに分離できます。別の専用ホストに管理サーバーを構成する管理者もいますが、複数ドメイン・ディレクトリ・モデルによってそれが可能となっています。

2.2.5.2 アプリケーション層でのOracle Web Services Managerの使用

Oracle Web Services Manager (Oracle WSM)は、エンタープライズ・デプロイメント・トポロジにおけるWebサービスの管理と保護を目的としたポリシー・フレームワークを提供します。

ほとんどのエンタープライズ・デプロイメント・トポロジでは、Oracle Web Services Manager Policy Managerは、アクティブ/アクティブの高可用性構成でデプロイできる、別のクラスタ内の管理対象サーバー上で実行されます。

その影響について認識している場合は、Oracle Web Services ManagerおよびFusion Middleware製品またはアプリケーションを同じクラスタにターゲット指定することができます。

Oracle Web Services Managerを専用の管理対象サーバーにデプロイする主な理由は、パフォーマンスと可用性の分離性を高めるためです。Oracle Web Services Managerは、多くの場合、ドメイン内のカスタムWebサービスやその他の製品およびコンポーネントにポリシーを提供します。このような場合に、Oracle Web Services Managerの追加アクティビティが、Oracle Web Services Managerと同じ管理対象サーバーまたはクラスタを共有するアプリケーションのパフォーマンスに影響を及ぼすことは望ましくありません。

スケール・アウトやスケール・アップのプロセスが発生した場合でも、コンポーネント同士が分離されていれば、より適切な対応が可能です。他の製品に影響を及ぼすことなく、独自の製品がデプロイされているFusion Middlewareアプリケーションの管理対象サーバーのみ、またはOracle Web Services Managerがデプロイされている管理対象サーバーのみをスケール・アウトしたりスケール・アップしたりできます。

2.2.5.3 アプリケーション層におけるクラスタとホストの構成のベスト・プラクティスとバリエーション

標準的なエンタープライズ・デプロイメントでは、アプリケーション層内の2つ以上のホスト上にあるクラスタで管理対象サーバーを構成します。特定のOracle Fusion Middleware製品について、エンタープライズ・デプロイメント参照トポロジは、管理対象サーバー数、クラスタ数および各クラスタをターゲットとするサービスに関するベスト・プラクティスを示しています。

これらのベスト・プラクティスは、各製品の標準的なパフォーマンス、メンテナンスおよびスケールアウトの各要件を考慮したものです。その結果、管理対象サーバーは、ドメイン内の適切なクラスタ・セットにグループ化されます。

エンタープライズ・デプロイメント・トポロジのバリエーションとして、特定の製品またはコンポーネントを追加のクラスタまたはホストにターゲット設定できます。これにより、パフォーマンスと独立性が向上します。

たとえば、管理サーバーを別個の比較的小規模なホスト・コンピュータにホストすることで、FMWコンポーネントおよび製品を管理サーバーから隔離することを考慮できます。

トポロジのこれらのバリエーションはサポートされていますが、エンタープライズ・デプロイメント参照トポロジでは、高可用性、スケーラビリティおよびセキュリティに留意しながら最小のハードウェア・リソースを使用します。各種サーバーのシステム要件と、システムが対応する必要のある負荷に応じて、適切なリソース・プランニングおよびサイジングを実施してください。これらの決定に基づいて、これらのバリエーションをインストールおよび構成する手順を、このガイドに記載の説明から適切に変更する必要があります。

2.2.5.4 標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

Oracle Fusion Middleware 12c以降では、ドメインごとのノード・マネージャまたはホストごとのノード・マネージャのいずれかを使用できます。次の項では、通常のエンタープライズ・デプロイメントに対するノード・マネージャ構成の影響に関して詳細に説明します。

注意:

これら2つのタイプのノード・マネージャの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』で概要に関する項を参照してください。

ドメインごとのノード・マネージャ構成の使用について

ドメインごとのノード・マネージャを構成では、ホストごとのノード・マネージャ構成とは異なり、実際に管理サーバー上で2つのノード・マネージャ・インスタンスを起動します。1つは管理サーバーのドメイン・ディレクトリから、もう1つは管理対象サーバーのドメイン・ディレクトリから起動します。また、トポロジ内の他のホストのそれぞれで別のノード・マネージャ・インスタンスが実行されます。

管理サーバーを制御するノード・マネージャでは、管理サーバー用に作成された仮想ホスト名のリスニング・アドレスが使用されます。管理対象サーバーを制御するノード・マネージャでは、物理ホストのリスニング・アドレスが使用されます。管理サーバーが別のホストにフェイルオーバーされると、ノード・マネージャの追加のインスタンスが開始され、フェイルオーバー・ホスト上の管理サーバーが制御されます。

ドメインごとの構成の主な利点は、ノード・マネージャの初期設定がより簡単かつ単純になることと、管理サーバーで一意のノード・マネージャ・プロパティを設定できることです。クラッシュ・リカバリなどの一部の機能が、管理対象サーバーではなく管理サーバーにのみ適用されていたため、この最後の機能は前のリリースで重要でした。現在のリリースでは、Oracle SOA Suite製品をサーバー全体の移行ではなく、サービスの自動移行用に構成できます。つまり、管理対象サーバーと管理サーバーでクラッシュ・リカバリを利用できるため、管理サーバーおよび管理対象サーバーのドメイン・ディレクトリに別のプロパティを適用する必要がありません。

別の利点は、ドメインごとのノード・マネージャでは、各ドメインに作成されたデモ・アイデンティティ・ストアに基づいて、ノード・マネージャからサーバーへの通信用のデフォルトSSLが提供されることです。

ホストごとのドメイン・マネージャ構成の使用について

ホストごとのノード・マネージャ構成では、単一のノード・マネージャ・インスタンスを起動して、ホスト上の管理サーバーおよびすべての管理対象サーバーを、別のドメインに存在するものも含めて制御します。これにより、特に同じマシンに複数のドメインが共存する場合に、管理サーバー・ホストでのフットプリントおよびリソース使用率が削減されます。

ホストごとのノード・マネージャ構成を使用すると、すべてのノード・マネージャでANYのリスニング・アドレスを使用できるため、ノード・マネージャでホスト上の使用可能なすべてのアドレスがリスンされます。つまり、管理サーバーが新しいホストにフェイルオーバーした場合に、追加の構成が必要ありません。ホストごとの構成を使用すると、複数のノード・マネージャ・プロパティ・ファイルではなく、単一のノード・マネージャ・プロパティ・ファイルを各ホストで更新および管理できるため、管理がより簡単になります。

ホストごとのノード・マネージャ構成には、追加の構成手順が必要です。ノード・マネージャからサーバーへの通信用のSSLが必要な場合は、追加のアイデンティティおよび信頼ストアを構成する必要があります。また、ノード・マネージャで複数のアドレスがリスンされるため、サブジェクト代替名(SAN)を使用する必要があります。SSL通信は2つのファイアウォールによって保護されているため、通常、アプリケーション層は必要ありません。

2.2.5.5 アプリケーション層内での通信のためのユニキャストの使用について

エンタープライズ・デプロイメントにおける管理対象サーバーとOracle WebLogic Serverクラスタ内のホストの間の通信にはユニキャスト通信プロトコルをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。

独自のデプロイメントでマルチキャストかユニキャストのどちらのプロトコルを使用するかを検討するときは、ネットワークの種類、クラスタ内のメンバー数、およびクラスタ・メンバーシップの信頼性要件を考慮してください。また、各プロトコルが持つ次の利点も考慮してください。

エンタープライズ・デプロイメントにおけるユニキャストの利点:

- グループ・リーダーを使用し、このリーダーにすべてのサーバーがメッセージを直接送信します。このリーダーは、他のすべてのグループ・メンバーと他のグループ・リーダー(該当する場合)にメッセージを再送信する役割を担います。

- ほとんどのネットワーク・トポロジでそのまま動作します。

- ネットワーク・トポロジに関係なく、追加の構成は不要です。

- 単一の欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。

エンタープライズ・デプロイメントにおけるマルチキャストの利点:

- マルチキャストは、より拡張性の高いピア・ツー・ピア・モデルを採用します。このモデルでは、サーバーが各メッセージを一度だけネットワークに直接送信し、各クラスタ・メンバーがネットワークからメッセージを直接受信することをネットワークが保証します。

- クラスタ・メンバーが単一のサブネット内にある最近のほとんどの環境でそのまま動作します。

- クラスタ・メンバーが複数のサブネットにまたがっている場合は、ルーターとWebLogic Server (マルチキャストTTL)で追加構成が必要です。

- 連続する3つの欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。

どちらのモデルの方がより適切に動作するかは、クラスタ内のサーバー数と、基礎となるアプリケーションにとってクラスタ・メンバーシップが不可欠かどうか(たとえば、セッション・レプリケーションを大量に行うアプリケーションやクラスタ全体でRMI呼出しが大量に発生するクラスタなど)によって異なります。

使用するトポロジがアクティブ/アクティブ型の障害時リカバリ・システムに参加するかどうか、またクラスタが複数のサブネットを横断するどうかを考慮してください。一般に、これらの場合にはユニキャストの方がより適切に動作します。

詳細は、次のリソースを参照してください。

- 『高可用性ガイド』のWebLogic Serverクラスタのマルチキャスト・メッセージングの構成に関する項

- 『Oracle WebLogic Serverクラスタの管理』のユニキャストを使用した1対多通信に関する項

2.2.5.6 OPSSおよび認証ストアと認可ストアへのリクエストの理解

Oracle Fusion Middleware製品およびコンポーネントの多くでは、認証プロバイダ(アイデンティティ・ストア)、ポリシー、資格証明、キーストアおよび監査データのためにOracle Platform Security Services (OPSS)セキュリティ・ストアが必要です。結果として、アプリケーション層とセキュリティ・プロバイダとの間でリクエストを送受信できるように通信を有効化する必要があります。

認証の場合、この通信は、一般的にポート389または636で通信するOracle Internet Directory (OID)、Oracle Unified Directory (OUD)などのLDAPディレクトリ宛てです。Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダを使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用する必要があります。

認可(およびポリシー・ストア)の場合、層によってセキュリティ・ストアの位置が異なります。

- アプリケーション層では、認可ストアはデータベース・ベースです。したがって、必要なOPSSデータを取得するために、Oracle WebLogic Server管理対象サーバーからデータベースへの頻繁な接続が必要になります。

- Web層では、認可ストアはファイル・ベースです。したがって、データベースへの接続は必要ありません。

OPSSセキュリティ・ストアの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の次の項を参照してください。

- 認証の基本

- OPSSポリシー・モデル

2.2.6 データ層について

データ層では、Oracle RACデータベースは2つのホスト(DBHOST1とDBHOST2)上で実行されます。データベースには、Oracle Business IntelligenceコンポーネントとOracle Platform Security Services (OPSS)ポリシー・ストアが必要とするスキーマが含まれています。

エンタープライズ・デプロイメントでは製品およびコンポーネントごとに複数のサービスを定義することで、スループットとパフォーマンスの分離および優先順位の決定ができます。このガイドでは、例として1つのデータベース・サービスを使用します。また、データベースを保護する他の高可用性データベース・ソリューションも使用できます。

- Oracle Data Guard: 詳細は、Oracle Data Guard概要および管理を参照してください。

- Oracle RAC One Node: 詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドのOracle RAC One Nodeの概要に関する項を参照してください。

これらのソリューションは、エンタープライズ・デプロイメントに一般に適用されるスケーラビリティと可用性の要件を満たす場合、Oracle RACデータベースの使用に重点を置いたこのガイドに記載されている情報以上のデータベース保護を実現します。

高可用性環境でのOracleデータベースの使用の詳細は、『高可用性ガイド』のデータベースの考慮事項に関する項を参照してください。

3 Business Intelligenceエンタープライズ・デプロイメント・トポロジの理解

次のトピックでは、Oracle Business Intelligenceエンタープライズ・デプロイメント・トポロジについて説明します。

これらのトポロジは、「標準的なエンタープライズ・デプロイメントの理解」で説明した概念の具体的な参照用実装です。

- プライマリBusiness Intelligenceエンタープライズ・トポロジのダイアグラム
このダイアグラムは、プライマリOracle Business Intelligenceエンタープライズ・デプロイメント・トポロジを示しています。

- プライマリBusiness Intelligenceトポロジ・ダイアグラムの理解
この項では、プライマリ・トポロジに特有の要素について説明します。

- プライマリBusiness Intelligenceエンタープライズ・トポロジの実装のフロー・チャートとロードマップ
この項では、この章で説明するエンタープライズ・トポロジをインストールおよび構成するために実行する必要がある大まかな手順を示します。

親トピック: エンタープライズ・デプロイメントの理解

3.1 プライマリBusiness Intelligenceエンタープライズ・トポロジのダイアグラム

このダイアグラムは、プライマリOracle Business Intelligenceエンタープライズ・デプロイメント・トポロジを示しています。

3.2 プライマリBusiness Intelligenceトポロジ・ダイアグラムの理解

この項では、プライマリ・トポロジに特有の要素について説明します。

Oracle Business Intelligenceトポロジのほとんどの要素は、オラクル社が推奨するベスト・プラクティスに準拠したエンタープライズ・トポロジの標準機能に相当します。これらの要素については、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

ここで説明する情報は、「標準的なエンタープライズ・デプロイメントの理解」の情報を確認したこと、およびエンタープライズ・デプロイメント・トポロジの一般的概念を理解していることを前提としています。

この章で説明するトポロジに特有の要素については、次の各項を参照してください。

- Business Intelligenceのロード・バランサ仮想サーバー名のサマリー

- Business Intelligenceアプリケーション層の管理対象サーバーとクラスタのサマリー

3.2.1 Business Intelligenceのロード・バランサ仮想サーバー名のサマリー

サーバー上のロードのバランシングと高可用性の提供のために、ハードウェア・ロード・バランサは一連の仮想サーバー名を認識するように構成されています。

これらの各サーバー名の用途については、「標準的なロード・バランサの仮想サーバー名のサマリー」を参照してください。

Oracle Business Intelligenceトポロジでは、ハードウェア・ロード・バランサによって次の仮想サーバー名が認識されます。

- bi.example.com: この仮想サーバー名はすべての受信トラフィックに使用されます。これは、ランタイムBusiness IntelligenceコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。

bi.example.com:443

- biinternal.example.com: この仮想サーバー名は、アプリケーション層のコンポーネント間の内部通信専用であり、インターネットには公開されません。
クライアントからこのURLへのトラフィックは、SSL対応ではありません。クライアントは次のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。

biinternal.example.com:80

- admin.example.com: この仮想サーバー名は、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server管理コンソール・インタフェースにアクセスする必要がある管理者用です。

このガイドで後ほど説明する手順に従って、次のタスクを実行します。

- リクエストを認識し、仮想ホスト名にルーティングするようにハードウェア・ロード・バランサを構成する

- これらの仮想ホスト名へのリクエストを認識し、正しいホスト・コンピュータに適切にルーティングできるように、Web層のOracle HTTP Serverインスタンスを構成する。

3.2.2 Business Intelligenceアプリケーション層の管理対象サーバーとクラスタのサマリー

アプリケーション層は、Oracle WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーをホストします。

選択したトポロジに応じて、ドメイン用のOracle WebLogic Serverドメインは、表3-1に示すクラスタで構成されています。このクラスタは、アクティブ/アクティブ高可用性構成として機能します。

表3-1 Oracle Business Intelligenceエンタープライズ・デプロイメント・トポロジのクラスタのサマリー

クラスタ

管理対象サーバー

Oracle Business Intelligence

WLS_BI1、WLS_BI2

3.3 プライマリBusiness Intelligenceエンタープライズ・トポロジの実装のフロー・チャートとロードマップ

この項では、この章で説明するエンタープライズ・トポロジをインストールおよび構成するために実行する必要がある大まかな手順を示します。

- プライマリBusiness Intelligenceエンタープライズ・トポロジをインストールおよび構成する手順のフロー・チャート

- エンタープライズ・デプロイメントの計画と準備のためのロードマップ表

- Business Intelligenceエンタープライズ・トポロジの構成のためのロードマップ表

3.3.1 プライマリBusiness Intelligenceエンタープライズ・トポロジをインストールおよび構成する手順のフロー・チャート

表3-1は、この章で説明するプライマリ・エンタープライズ・デプロイメント・トポロジをインストールおよび構成するために必要な手順のフロー・チャートです。フロー・チャートに続くセクションで、フロー・チャート内の各手順について説明します。

このガイドは、作業用のBusiness Intelligenceドメインから始めて、後でドメインをスケール・アウトして追加機能を加えられるように設計されています。

トポロジを構築するためのこのモジュラ・アプローチにより、ご使用のハードウェアおよびソフトウェア・リソース、さらに組織にとって最も重要なOracle Business Intelligence機能に基づいて、戦略的な決定を行えます。

また、個々の製品またはコンポーネントを構成する際、検証とトラブルシューティングを行うこともできます。

これは、1つの構成ウィザード・セッションで複数の製品を構成できないという意味ではありません。このガイドで示すような様々な拡張機能を1回の構成ウィザード実行でグループ化できます。ただし、このガイドで説明する手順では、主にモジュラ・アプローチを中心にエンタープライズ・デプロイメントを構築します。

図3-1 エンタープライズ・トポロジ構成手順のフロー・チャート

3.3.2 エンタープライズ・デプロイメントの計画と準備のためのロードマップ表

次の表は、エンタープライズ・トポロジ・フロー・チャートに示した計画と準備の各手順について説明したものです。

フロー・チャート手順

追加情報

標準的なエンタープライズ・デプロイメントの基礎の理解

標準的なエンタープライズ・デプロイメントの理解

デプロイする製品の特定の参照用トポロジの理解。

必要な仮想サーバー、クラスタのサマリー、製品に固有のデプロイメントに推奨される管理対象サーバーなど、製品に固有のトポロジおよびトポロジの説明を確認します。

Oracle Business Intelligence EDGワークブックの確認

エンタープライズ・デプロイメント・ワークブックの使用

ハードウェア、IPアドレスおよびソフトウェア・ダウンロードの入手

エンタープライズ・デプロイメント用のリソースの取得

ハードウェア・ロード・バランサとファイアウォールの準備

エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

ファイル・システムの準備

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

システム要件の確認、共有記憶域のマウントおよび仮想IPの有効化

エンタープライズ・デプロイメント用のホスト・コンピュータの準備

サポートされているOracle RACデータベースの特定またはインストール

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

3.3.3 Business Intelligenceエンタープライズ・トポロジの構成のためのロードマップ表

表3-2では、「プライマリBusiness Intelligenceエンタープライズ・トポロジのダイアグラム」で示されているトポロジの構成時に必要な各構成手順について説明します。

これらの手順は、図3-1のフロー・チャートに示された手順に対応しています。

表3-2 Business Intelligenceエンタープライズ・トポロジの構成のためのロードマップ表

フロー・チャート手順

追加情報

初期Business Intelligenceドメインの作成

エンタープライズ・デプロイメント用の初期BIドメインの作成

Web層を追加するドメインの拡張

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

初期Business Intelligenceドメインのスケール・アウト

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

第II部 エンタープライズ・デプロイメントの準備

エンタープライズ・デプロイメント・ガイドのこの部分には、次のトピックが含まれています。

- エンタープライズ・デプロイメント・ワークブックの使用
この章では、エンタープライズ・デプロイメント・ワークブックの概要を示します。ワークブックを使用して組織のエンタープライズ・デプロイメントを計画する方法について説明します。

- エンタープライズ・デプロイメント用のリソースの取得
Oracle Business Intelligence参照用トポロジの構成を開始する前に、次のトピックを使用して必要なハードウェア、ソフトウェアおよびネットワーク設定を取得します。

- エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備
この章では、エンタープライズ・デプロイメント用にネットワークを構成する方法について説明します。

- エンタープライズ・デプロイメント用のファイル・システムの準備
ローカルおよび共有記憶域の要件、およびエンタープライズ・トポロジのインストール時および構成時における重要なディレクトリとファイルの場所の参照に使用される用語の理解が含まれます。

- エンタープライズ・デプロイメント用のホスト・コンピュータの準備
必要な共有記憶域システムをホストにマウントする方法や、各ホストで必要な仮想IPアドレスを有効化する方法について説明します。

- エンタープライズ・デプロイメント用のデータベースの準備
この章では、Oracle Business Intelligenceエンタープライズ・デプロイメントのデータベースを準備する手順について説明します。

4 エンタープライズ・デプロイメント・ワークブックの使用

この章では、エンタープライズ・デプロイメント・ワークブックの概要を示します。ワークブックを使用して組織のエンタープライズ・デプロイメントを計画する方法について説明します。

この章では、エンタープライズ・デプロイメント・ワークブック、ユースケースおよびエンタープライズ・デプロイメント・ワークブックの対象ユーザーについて説明します。

- エンタープライズ・デプロイメント・ワークブックの概要
この項では、エンタープライズ・デプロイメント・ワークブックの概要について説明します。

- ワークブックの標準的なユース・ケース
この項では、エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースに関連するロールと作業を示します。

- Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの使用
この項では、エンタープライズ・デプロイメント・ワークブックの使用方法の詳細について説明します。

- エンタープライズ・デプロイメント・ワークブックの使用対象者
エンタープライズ・デプロイメント・ワークブックの情報はカテゴリごとに分かれています。組織構成およびチームで規定されているロールに応じて、ワークブックの詳細を記入する組織内の特定の個人を割り当てることができます。同様に、カテゴリごとの情報を、各カテゴリのリソースの計画、取得または設定を担当する個人またはチームに割り当てることができます。

親トピック: エンタープライズ・デプロイメントの準備

4.1 エンタープライズ・デプロイメント・ワークブックの概要

この項では、エンタープライズ・デプロイメント・ワークブックの概要について説明します。

Oracle Fusion Middlewareエンタープライズ・デプロイメント・ワークブックは、このガイドの付属ドキュメントです。アーキテクト、システム・エンジニア、データベース管理者などが環境インストールの詳細(サーバー名、URL、ポート番号、インストール・パス、その他のリソースなど)をすべて計画したり記録したりするために使用できるスプレッドシートです。

エンタープライズ・デプロイメント・ワークブックは、プロセス全体の入力変数の追跡に使用できる唯一のドキュメントとしての役割を果たします。これにより、次のことが可能になります。

- アーキテクト、システム・エンジニア、データベース管理者および組織上重要な他のロール間での作業の切り分け

- 実装前の包括的な計画

- 計画内容を実際の実装前に検証

- 実装時の一貫性

- 将来の使用に備えた環境の記録

4.2 ワークブックの標準的なユース・ケース

この項では、エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースに関連するロールと作業を示します。

Oracle Fusion Middlewareエンタープライズ・デプロイメントの準備として、エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースには次のロールと作業が関わります。

- アーキテクトがこのガイドの最初から第5章までを読み、ワークブックの対応する各項を記入します。

- ワークブックを他のアーキテクトとシステム・エンジニアが検証します。

- アーキテクトが検証済のワークブックを使用して、ネットワークとシステムの変更リクエストをシステム・エンジニアリング部門とともに開始します。

- ソフトウェアのインストールと構成を担当する管理者とシステム・インテグレータがワークブックとこのガイドの以降の章を参照して、インストールと構成の作業を行います。

4.3 Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの使用

この項では、エンタープライズ・デプロイメント・ワークブックの使用方法の詳細について説明します。

次の項では、Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの場所と内容について説明します。

- Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの検索

- Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの内容の理解

4.3.1 Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの検索

Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックは、Oracle Fusion Middlewareドキュメント・ライブラリにMicrosoft Excelスプレッドシートとして用意されています。ライブラリのインストール、パッチおよびアップグレード・ページのリンクから入手できます。

4.3.2 Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの内容の理解

次の項では、Oracle Business Intelligenceエンタープライズ・デプロイメント・ワークブックの内容について説明します。ワークブックは複数のタブに分かれており、各タブには、エンタープライズ・デプロイメント・トポロジのインストールと構成に必要な一連の関連する変数と値が含まれます。

- スタート・タブの使用

- ハードウェア - ホスト・コンピュータ・タブの使用

- ネットワーク - 仮想ホストとポート・タブの使用

- ストレージ - ディレクトリ変数タブの使用

- 「データベース - 接続の詳細」タブの使用

4.3.2.1 スタート・タブの使用

エンタープライズ・デプロイメント・ワークブックのスタート・タブは、このワークブックの目次の役割を果たします。また、スプレッドシートの記入者を特定する目的にも使用できます。

スタート・タブには、値が必要なワークブック・フィールドや情報提供を目的としたフィールドの識別に使用する色を指定するためのキーも用意されています。

次の図にスプレッドシートのスタート・タブを示します。

4.3.2.2 ハードウェア - ホスト・コンピュータ・タブの使用

ハードウェア - ホスト・コンピュータ・タブには、Oracle Business Intelligenceエンタープライズ・デプロイメント・トポロジのインストールと構成に必要なホスト・コンピュータの一覧が記載されています。

参照トポロジは、通常、少なくとも6台のホスト・コンピュータ(Web層に2台、アプリケーション層に2台、データ層のOracle RACデータベース用に2台)を必要とします。環境を拡張してシステムを追加する場合は、追加するホスト・コンピュータごとに行を追加してください。

抽象ホスト名は、このガイド全体を通してホスト名の記述に使用される名前です。各行のホスト・コンピュータを調達し、実際のホスト名を入力してください。これにより、このガイドで抽象名が記述されているときに実際のホスト名を参照できるようになります。

たとえば、このガイドの手順にBIHOST1と記述されている場合、このBIHOST1という変数を、ワークブックのハードウェア - ホスト・コンピュータ・タブに記載されている実際の名前に置き換えることができます。

簡単に参照できるように、各ホストのIPアドレス、オペレーティング・システム(バージョンを含む)、CPU数およびRAMの量も記入しておくことをお薦めします。この情報は、エンタープライズ・デプロイメントのインストール、構成および保守時に役立つことがあります。

詳細は、「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」を参照してください。

4.3.2.3 ネットワーク - 仮想ホストとポート・タブの使用

ネットワーク - 仮想ホストとポート・タブには、エンタープライズ・デプロイメント・トポロジのインストールと構成を行う前に、ネットワーク管理者が定義する必要のある仮想ホストの一覧が記載されています。

ポート番号は様々な理由から重要です。管理コンソールにアクセスするためには、ポート番号のクイック・リファレンスが必要です。また、特定のポート経由のネットワーク・トラフィックを許可するようにファイアウォールを構成する必要があります。

各仮想ホスト、仮想IPアドレスおよび各ネットワーク・ポートには、デプロイメントにおけるはっきりした目的があります。詳細は、「エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備」を参照してください。

ネットワーク - 仮想ホスト表で、抽象仮想ホストまたは仮想IP名列の項目を確認してください。これらは、このガイドの手順で使用される仮想ホストと仮想IP名です。それぞれの抽象名に対して、ネットワーク管理者が定義した実際の仮想ホスト名を入力します。このガイドで抽象仮想ホストまたは抽象仮想IP名が記述されている箇所では、このテーブル内の対応する実際値に置き換えてください。

また、多くの場合、このガイドでは、インストールおよび構成するコンポーネントまたは製品にデフォルトのポート番号を使用することを前提としています。しかし実際には、異なるポート番号を使用する可能性があります。ネットワーク - ポート番号表を使用すると、デフォルトのポート値を、特定のインストールで使用する実際の値にマッピングできます。

4.3.2.4 ストレージ - ディレクトリ変数タブの使用

エンタープライズ・デプロイメントの準備の一環として、Oracleエンタープライズ・デプロイメントで推奨される標準ディレクトリ構造を使用することが前提となっています。

また、このガイドの手順では、特定のディレクトリ場所が記述されています。手順内でディレクトリごとに一貫して割り当てられている変数を、インストールにおける実際のディレクトリの場所に置き換える必要があります。

このタブに掲載されている各ディレクトリ場所に、インストールにおける実際のディレクトリ・パスを入力してください。

また、アプリケーション層では、これらの標準ディレクトリの多くを共有記憶域デバイス上に作成することをお薦めします。このようなディレクトリのために、共有記憶域場所の名前と共有場所をマウントするときに使用したマウント・ポイントを入力できる欄もこの表に用意されています。

詳細は、「エンタープライズ・デプロイメント用のファイル・システムの準備」を参照してください。

4.3.2.5 「データベース - 接続の詳細」タブの使用

エンタープライズ・デプロイメント・トポロジのインストールおよび構成時には、多くの場合、高可用性のOracle Real Application Clusters (RAC)データベースに接続する必要があります。このガイドの手順では、構成ウィザードやリポジトリ作成ユーティリティなどのツールからデータベースに接続するために指定する必要がある情報を示す一連の変数が記述されています。

このタブを使用して、これらの変数の、データベース・インストールにおける実際の値を入力し、いつでも参照できるようにしておいてください。

詳細は、「エンタープライズ・デプロイメント用のデータベースの準備」を参照してください。

4.4 エンタープライズ・デプロイメント・ワークブックの使用対象者

エンタープライズ・デプロイメント・ワークブックの情報はカテゴリごとに分かれています。組織構成およびチームで規定されているロールに応じて、ワークブックの詳細を記入する組織内の特定の個人を割り当てることができます。同様に、カテゴリごとの情報を、各カテゴリのリソースの計画、取得または設定を担当する個人またはチームに割り当てることができます。

たとえば、ワークブックは組織内の次のロールを担う人物が記入、確認および使用できます。

- 情報テクノロジ(IT)担当責任者

- アーキテクト

- システム管理者

- ネットワーク・エンジニア

- データベース管理者

5 エンタープライズ・デプロイメント用のリソースの取得

Oracle Business Intelligence参照用トポロジの構成を開始する前に、次のトピックを使用して必要なハードウェア、ソフトウェアおよびネットワーク設定を取得します。

この章では、必須IPアドレスの予約およびエンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得について説明します。

- エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件
この項では、エンタープライズ・デプロイメント・トポロジのハードウェア・ロード・バランサの要件、ホスト・コンピュータのハードウェア要件およびオペレーティング・システム要件について説明します。

- エンタープライズ・デプロイメント用の必須IPアドレスの予約
この項では、インストールと構成の前に取得および予約する必要がある一連のIPアドレスを示します。

- エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得
エンタープライズ・トポロジのインストールおよび構成を開始する前に、トポロジの実装に必要なソフトウェア・ディストリビューションを見つけてダウンロードする必要があります。

親トピック: エンタープライズ・デプロイメントの準備

5.1 エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件

この項では、エンタープライズ・デプロイメント・トポロジのハードウェア・ロード・バランサの要件、ホスト・コンピュータのハードウェア要件およびオペレーティング・システム要件について説明します。

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

- ハードウェア・ロード・バランサの要件
この項では、外部ロード・バランサの適切な機能を示します。

- ホスト・コンピュータのハードウェア要件
この項では、エンタープライズ・デプロイメント・トポロジをサポートするように構成されるホスト・コンピュータの取得に役立つ情報を提供します。

- エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件
この項では、オペレーティング・システム要件の詳細について説明します。

5.1.1 ハードウェア・ロード・バランサの要件

この項では、外部ロード・バランサの適切な機能を示します。

このエンタープライズ・トポロジは外部のロード・バランサを使用します。この外部ロード・バランサには、次の機能が必要です。

- 仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。ロード・バランサは、リクエストをプールのサーバーにロード・バランスできるようになります。

- ポート変換構成が可能である必要があります。これによって、仮想ホスト名とポートにおける入力リクエストが、バックエンド・サーバーにある別のポートにリダイレクトされます。

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

- 仮想サーバーとポートの構成: 仮想サーバー名とポートを外部ロード・バランサ上で構成できる機能。仮想サーバー名とポートは次の要件を満たす必要があります。

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

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

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

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

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

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

- ロード・バランサはSSLリクエストをロード・バランサで終了して、同等の非SSLプロトコル(たとえば、HTTPSからHTTP)を使用してトラフィックを実際のバックエンド・サーバーに転送できる必要があります。

- SSLアクセラレーション(これは推奨する機能ですが、エンタープライズ・トポロジに必須ではありません)。

- TCP/IPリクエストをルーティングする機能: これは、TCP経由のMinimum Lower Layer Protocol (MLLP)を使用するOracle SOA Suite for healthcare integrationの要件です。

5.1.2 ホスト・コンピュータのハードウェア要件

この項では、エンタープライズ・デプロイメント・トポロジをサポートするように構成されるホスト・コンピュータの取得に役立つ情報を提供します。

内容は次のとおりです。

- エンタープライズ・デプロイメントのホスト・コンピュータに関する一般的な考慮事項
この項では、エンタープライズ・デプロイメントのホスト・コンピュータに必要とされる一般的な考慮事項について説明します。

- Oracle Fusion Middlewareシステム要件の確認
この項では、環境が必要な最小要件を満たしていることを確認するために役立つシステム要件の情報に対する参照を提供します。

- エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタおよびプロセス数
この項では、エンタープライズ・デプロイメントに必要とされる標準的なメモリー、ファイル・ディスクリプタの数、およびオペレーティング・システムのプロセスとタスクの数の詳細について説明します。

- エンタープライズ・デプロイメントの標準的なディスク領域要件
この項では、このエンタープライズ・デプロイメントに必要とされる標準的なディスク領域について説明します。

5.1.2.1 エンタープライズ・デプロイメントのホスト・コンピュータに関する一般的な考慮事項

この項では、エンタープライズ・デプロイメントのホスト・コンピュータに必要とされる一般的な考慮事項について説明します。

Oracle Fusion Middlewareエンタープライズ・デプロイメントを構成するプロセスを開始する前に、適切なキャパシティ・プランニングを実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。これらの要件は、使用するアプリケーションやカスタムOracle Business Intelligenceシステムごとに異なります。

この章で提供する情報は、ホスト・コンピュータ要件を判断するために役立つ一般的なガイドラインおよび情報です。これにより、個別の本番環境に対するキャパシティ・プランニングを実行する必要がなくなるわけではありません。

注意:

この項でホスト・コンピュータを取得し確保したら、ホスト名とシステム特性をエンタープライズ・デプロイメント・ワークブックに記録してください。これらのアドレスは、後で各ホスト・コンピュータでIPアドレスを有効化するときに使用します。

詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください

5.1.2.2 Oracle Fusion Middlewareシステム要件の確認

この項では、環境が必要な最小要件を満たしていることを確認するために役立つシステム要件の情報に対する参照を提供します。

Oracle Fusion Middlewareのシステム要件および仕様を参照し、環境がインストールする製品の最小インストール要件を満たしていることを確認します。

要件および仕様のドキュメントには、Oracle Fusion Middlewareの一般的なハードウェアとソフトウェアの要件、ディスク領域とメモリーの最小要件、データベース・スキーマの要件、および必要なシステム・ライブラリおよびパッケージに関する情報が記載されています。

また、Oracle Fusion Middlewareデプロイメントのメモリー要件を見積るための一般的なガイドラインも記載されています。

5.1.2.3 エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタおよびプロセス数

この項では、エンタープライズ・デプロイメントに必要とされる標準的なメモリー、ファイル・ディスクリプタの数、およびオペレーティング・システムのプロセスとタスクの数の詳細について説明します。

次の表は、標準的なOracle Business Intelligenceエンタープライズ・デプロイメントにおける管理サーバーおよび各管理対象サーバー・コンピュータに必要なメモリー、ファイル・ディスクリプタおよびプロセス数をまとめたものです。これらの値はあくまで例にすぎませんが、初期エンタープライズ・デプロイメントに最小限必要なメモリー量の見積りに使用できます。

このトピックの例には、参照用トポロジに示されている、BIHOST1で必要な管理対象サーバーおよびその他のサービスを構成するための最小要件が反映されています。

マシンの調達時には、各ホスト・コンピュータに搭載する必要がある物理メモリー量を判断するときの目安として、「概算最大メモリー」列の情報を使用してください。

ホスト・コンピュータ・ハードウェアを調達し、オペレーティング・システム要件を確認したら、ソフトウェア構成を調査して、オペレーティング・システムの設定が「ファイル・ディスクリプタ」列に記載されているオープン・ファイル数と「オペレーティング・システムのプロセスおよびタスク数」列に記載されているプロセス数に対応できるように構成されていることを確認します。

詳細は、「UNIXシステムでのオープン・ファイル制限とプロセス数の設定」を参照してください。

管理対象サーバー、ユーティリティまたはサービス

概算最大メモリー

ファイル・ディスクリプタ数

オペレーティング・システムのプロセスおよびタスク数

管理サーバー

3.5 GB

3500

165

WLS_BI

4.0 GB

31000

130

WLST (ノード・マネージャへの接続)

1.5 GB

910

20

構成ウィザード

1.5 GB

700

20

ノード・マネージャ

1.0 GB

720

15

システム・コンポーネント

TBD

TBD

TBD

合計

11.0 GB*

17000

1200

*オペレーティング・システムとその他の追加メモリー要件を考慮した概算合計です。

5.1.2.4 エンタープライズ・デプロイメントの標準的なディスク領域要件

この項では、このエンタープライズ・デプロイメントに必要とされる標準的なディスク領域について説明します。

Oracle Business Intelligence製品を含むOracle Fusion Middleware 12c (12.2.1)製品の最新のディスク領域要件は、Oracle Fusion Middlewareシステム要件と仕様を確認してください。

また、次の表は、Oracle Business Intelligenceエンタープライズ・デプロイメントに通常必要なディスク領域についてまとめたものです。

この情報と「エンタープライズ・デプロイメント用のファイル・システムの準備」の情報に基づいて、デプロイメントに必要なディスク領域を判断してください。

サーバー

ディスク

データベース

nXm

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

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

WEBHOSTn

10 GB

BIHOSTn

10 GB*

*共有記憶域Oracleホーム構成の場合、2つのインストールには合計20 GBあれば十分です。

5.1.3 エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件

この項では、オペレーティング・システム要件の詳細について説明します。

このガイドで説明するOracle Fusion Middlewareソフトウェア製品およびコンポーネントは、Oracle Fusion Middlewareシステム要件と仕様に記載されている様々なオペレーティング・システムおよびプラットフォームで動作保証されています。

注意:

このガイドでは、Oracle Linuxシステムにおけるエンタープライズ・デプロイメント参照用トポロジの実装を中心に取り上げています。

このトポロジは、動作保証済でサポートされている任意のオペレーティング・システムで実装可能ですが、このガイドの例には、多くの場合、Oracle Linux上でbashシェルを使用して実行する必要があるコマンドと構成手順が示されています。

5.2 エンタープライズ・デプロイメント用の必須IPアドレスの予約

この項では、インストールと構成の前に取得および予約する必要がある一連のIPアドレスを示します。

エンタープライズ・トポロジのインストールおよび構成を開始する前に、次の一連のIPアドレスを取得および予約する必要があります。

- トポロジのために取得した各ホスト・コンピュータの物理IP (IP)アドレス

- 管理サーバーの仮想IP (VIP)アドレス

- サーバー全体の移行に対して構成された各管理対象サーバーの追加VIPアドレス
自動サービス移行をサポートするFusion Middleware 12c製品の場合、管理対象サーバーのVIPは通常は必要ありません。

- 各VIPにマップされる一意の仮想ホスト名。

ネットワーク管理者と協力して、これらの必須VIPが、ご使用のDNSサーバーに定義されていることを確認できます。(非本番環境では、かわりに/etc/hostsファイルを使用してこれらの仮想ホストを定義できます)。

詳細な情報は、次のトピックを参照してください

- 仮想IP (VIP)アドレスとは
この項では、仮想IPアドレスを定義し、その用途について説明します。

- 仮想ホスト名と仮想IPアドレスを使用する理由
特にエンタープライズ・デプロイメントの場合、一連のVIPおよびそれらがマップされている仮想ホスト名を、社内ネットワーク上で予約して有効化することが重要です。

- エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス
この項では、標準的なOracle Business Intelligenceエンタープライズ・デプロイメント・トポロジの管理サーバーおよび各管理対象サーバーで必要とされる物理IP (IP)アドレスと仮想IP (VIP)アドレスについて説明します。

5.2.1 仮想IP (VIP)アドレスとは

この項では、仮想IPアドレスを定義し、その用途について説明します。

仮想IPアドレスは、ホストの主要IPアドレスと同じサブネットに属する、未使用のIPアドレスです。これは、ホストに手動で割り当てられます。コンピュータで障害が発生した場合は、仮想アドレスをトポロジ内の新しいホストに割り当てることができます。このガイドの用途では、仮想IPアドレスはホスト間で再割当て可能なアドレスとして、物理IPアドレスはハードウェア・ホスト・コンピュータに永続的に割り当てられるアドレスとして扱います。

5.2.2 仮想ホスト名と仮想IPアドレスを使用する理由

特にエンタープライズ・デプロイメントの場合、一連のVIPおよびそれらがマップされている仮想ホスト名を、社内ネットワーク上で予約して有効化することが重要です。

ホスト名は、様々なノードを通して伝播される適切な/etc/hostsファイルをかわりに使用して解決できます。

IPアドレスが割り当てられたホスト・コンピュータに障害が発生した場合は、割り当てられた管理対象サーバーの実行を新しいホストが引き継ぐことができるように、このIPアドレスは同じサブネット内の別のホスト・コンピュータに割り当てることができます。

管理サーバーの仮想IPアドレスの再割当ては手動で実行する必要がありますが、管理対象サーバーの仮想IPアドレスの再割当ては、Oracle WebLogic Serverのサーバー全体の移行機能を使用して自動的に実行できます。

サーバー全体の移行を使用する必要があるかどうかは、デプロイする製品およびその製品で自動サービス移行がサポートされているかどうかによって異なります。

5.2.3 エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス

この項では、標準的なOracle Business Intelligenceエンタープライズ・デプロイメント・トポロジの管理サーバーおよび各管理対象サーバーで必要とされる物理IP (IP)アドレスと仮想IP (VIP)アドレスについて説明します。

エンタープライズ・デプロイメントのインストールおよび構成を開始する前に、表5-1 のVIPに対応する一連のホスト名およびIPアドレスを予約します。

VIPには任意の一意のホスト名を割り当てることができますが、このガイドでは、この表の推奨ホスト名を使用して各VIPを参照します。

注意:

この項でIPアドレスおよび対応する仮想ホスト名を取得および予約したら、それらのIPアドレスとホスト名の値をエンタープライズ・デプロイメント・ワークブックに記録してください。これらのアドレスは、後で各ホスト・コンピュータでIPアドレスを有効化するときに使用します。

詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください

表5-1 エンタープライズ・デプロイメントに必要な仮想IPアドレスのサマリー

仮想IP

VIPのマップ先

説明

VIP1

ADMINVHN

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

VIP2

BIHOST1VHN

BIHOST1VHNは、WLS_BI1管理対象サーバーのリスニング・アドレスにマップする仮想ホスト名であり、このサーバーのサーバー全体の移行によりフェイルオーバーします。

これは、WLS_BI1プロセスが実行されているノード(BIHOST1)で有効化されます。

VIP3

BIHOST2VHN

BIHOST2VHNは、WLS_BI2管理対象サーバーのリスニング・アドレスにマップする仮想ホスト名であり、このサーバーのサーバー全体の移行によりフェイルオーバーします。

これは、WLS_BI2プロセスが実行されているノード(BIHOST2)で有効化されます。

5.3 エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得

エンタープライズ・トポロジのインストールおよび構成を開始する前に、トポロジの実装に必要なソフトウェア・ディストリビューションを見つけてダウンロードする必要があります。

次の表は、取得する必要のあるダウンロードを示しています。

Oracle Fusion Middlewareソフトウェアの入手方法の一般情報は、『Oracle Fusion Middlewareのインストールのプランニング』の製品のディストリビューションの理解と入手に関する項を参照してください。

特定のOracle Fusion Middleware製品の場所とダウンロードに固有の詳細は、OTNのOracle Fusion Middlewareダウンロード、インストール、構成のReadmeファイルを参照してください。

ディストリビューション

説明

Oracle Fusion Middleware 12c (12.2.1.0.0) Infrastructure

このディストリビューションをダウンロードしてOracle Fusion Middleware Infrastructureをインストールします。これには、Oracle WebLogic ServerおよびOracle Fusion Middleware製品に必要なJava Required Filesソフトウェアが含まれています。

このディストリビューションによってリポジトリ作成ユーティリティ(RCU)もインストールされます。これは、以前のOracle Fusion Middlewareリリースでは独自のディストリビューションにパッケージされていました。

Oracle HTTP Server 12c (12.2.1.0.0)

このディストリビューションをダウンロードして、Web層にOracle HTTP Serverソフトウェアをインストールします。

Oracle Fusion Middleware 12c (12.2.1.0.0) Business Intelligence

このディストリビューションをダウンロードして、Oracle Business Intelligenceソフトウェアをインストールします。

6 エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

この章では、エンタープライズ・デプロイメント用にネットワークを構成する方法について説明します。

- ハードウェア・ロード・バランサでの仮想ホストの構成
この項では、エンタープライズ・デプロイメントのハードウェア・ロード・バランサの構成方法について説明します。

- エンタープライズ・デプロイメントのファイアウォールとポートの構成
この項では、エンタープライズ・デプロイメントのファイアウォールで開いておく必要のあるポートを示します。

親トピック: エンタープライズ・デプロイメントの準備

6.1 ハードウェア・ロード・バランサでの仮想ホストの構成

この項では、エンタープライズ・デプロイメントのハードウェア・ロード・バランサの構成方法について説明します。

次のトピックでは、ハードウェア・ロード・バランサの構成方法について説明し、必要な仮想サーバーのサマリーを提供し、それらの仮想サーバーのための追加手順を示します。

- ハードウェア・ロード・バランサ構成の概要

- ハードウェア・ロード・バランサの構成の一般的な手順

- エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー

- admin.example.comに関する追加手順

6.1.1 ハードウェア・ロード・バランサ構成の概要

トポロジのダイアグラムに示すように、リクエストを認識し、様々な種類のネットワーク・トラフィックや監視に対応する複数の仮想サーバーと関連ポートにリクエストをルーティングできるように、ハードウェア・ロード・バランサを構成する必要があります。

ロード・バランシング・デバイスにおける仮想サーバーとは、ロード・バランシングのために複数の物理サーバーを1つのサーバーのように見せかけることができる構成です。仮想サーバーは通常、IPアドレスとサービスによって表され、受信したクライアント・リクエストをサーバー・プール内の各サーバーに配信するために使用されます。

仮想サーバーは、(エンタープライズ・デプロイメントで使用可能な各種サービス用の)適切なホスト・コンピュータおよびポートにトラフィックをルーティングするように構成しておく必要があります。

さらに、サービスが停止したときに特定のサーバーへのトラフィックをできるだけ早く停止できるように、ホスト・コンピュータとポートの可用性を監視するようにロード・バランサを構成する必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

ロード・バランサを構成した後で、同じ名前を持つ一連の仮想ホストを、ロード・バランサに定義した仮想サーバーとして認識するように、Web層のWebサーバー・インスタンスを構成することも可能です。Webサーバーは、ハードウェア・ロード・バランサから受信した各リクエストを、リクエストのヘッダーに記述されているサーバー名に基づいて適切にルーティングできます。詳細は、「管理およびOracle Web Services Manager用のOracle HTTP Serverの構成」を参照してください。

6.1.2 ハードウェア・ロード・バランサの構成の一般的な手順

次の手順では、エンタープライズ・デプロイメントのハードウェア・ロード・バランサを構成する標準的な手順の概要を示します。

特定のロード・バランサの実際の構成手順は、ロード・バランサの特定のタイプによって異なります。実際の手順は、ベンダーが提供するドキュメントを参照してください。

1. サーバーのプールを作成します。このプールには、ロード・バランシングの定義に含まれているサーバーとポートのリストが格納されます。
たとえば、Webホスト間のロード・バランシングの場合、ポート7777のWEBHOST1およびWEBHOST2の両ホストにリクエストを送信するサーバーのプールを作成します。

2. 特定のホストとサービスが使用可能かどうかを決定するルールを作成し、手順1で説明したサーバーのプールに割り当てます。

3. アプリケーションに対するリクエストを受信するアドレスおよびポートのロード・バランサで必要な仮想サーバーを作成します。
エンタープライズ・デプロイメントに必要な仮想サーバーの完全なリストは、「エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー」を参照してください。

ロード・バランサで各仮想サーバーを定義するときは、次のことを考慮します。

a. ロード・バランサでサポートされている場合は、仮想サーバーが内部から、外部から、またはその両方から利用できるのかどうかを指定します。内部アドレスはネットワーク内からのみ解決可能であることを確認します。

b. 適用可能な場合は、仮想サーバーに対するSSL終端を構成します。

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

6.1.3 エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー

この項では、エンタープライズ・デプロイメントに必要な仮想サーバーの詳細について説明します。

次の表は、Oracle Business Intelligenceエンタープライズ・トポロジのハードウェア・ロード・バランサで定義する必要がある仮想サーバーの一覧です。

仮想ホスト

サーバー・プール

プロトコル

SSL終端

外部

admin.example.com:80

WEBHOST1.example.com:7777 WEBHOST2.example.com:7777

HTTP

なし

なし

bi.example.com:443

WEBHOST1.example.com:7777 WEBHOST2.example.com:7777

HTTPS

あり

あり

biinternal.example.com:80

WEBHOST1.example.com:7777 WEBHOST2.example.com:7777

HTTP

なし

なし

6.1.4 admin.example.comに関する追加手順

この項では、仮想サーバーadmin.example.comに必要な追加手順を示します。

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

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

6.2 エンタープライズ・デプロイメントのファイアウォールとポートの構成

この項では、エンタープライズ・デプロイメントのファイアウォールで開いておく必要のあるポートを示します。

管理者は、様々なOracle Fusion Middleware製品およびサービスで使用されるポート番号を理解している必要があります。それにより、ホスト上の2つのサービスで同じポート番号が使用されないようにし、エンタープライズ・トポロジ内のファイアウォールで適切なポートを開くことができます。

次の表は、トポロジ内のファイアウォールで開く必要があるポートをリストしています。

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

- FW0は、最も外側のファイアウォールを表します。

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

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

すべてのFusion Middlewareエンタープライズ・デプロイメントに共通のファイアウォール・ポート

タイプ

ファイアウォール

ポートとポートの範囲

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

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

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

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

FW0

80

HTTP/ロード・バランサ

インバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

FW0

443

HTTPS/ロード・バランサ

インバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

FW1

80

HTTPS/ロード・バランサ

アウトバウンド(イントラネット・クライアント)

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

FW1

443

HTTPS/ロード・バランサ

アウトバウンド(イントラネット・クライアント)

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

コールバックおよびアウトバウンド呼出し

FW1

80

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

コールバックおよびアウトバウンド呼出し

FW1

443

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

該当なし

7777

HTTP

該当なし

該当なし

管理サーバーによるOHS登録

FW1

7001

HTTP/t3

インバウンド

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

管理サーバーによるOHS管理

FW1

OHS管理ポート(7779)

それぞれTCPとHTTP

アウトバウンド

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

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

該当なし

該当なし

該当なし

該当なし

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

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

FW1

7001

HTTP/管理サーバーとEnterprise Manager

t3

両方

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

データベース・アクセス

FW2

1521

SQL*Net

両方

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

デプロイメントの一貫性

該当なし

8088

範囲: 8000から8090

該当なし

該当なし

Oracle Unified Directoryアクセス

FW2

389

636 (SSL)

LDAPまたはLDAP/ssl

インバウンド

ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

Gridlinkに必要。ONSサーバーは各データベース・サーバー上で稼働します。

Oracle Business Intelligenceエンタープライズ・デプロイメントに固有のファイアウォール・ポート

タイプ

ファイアウォール

ポートとポートの範囲

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

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

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

WSM-PMのアクセス

FW1

7010

範囲: 7010から7999

HTTP/WLS_WSM-PMn

インバウンド

タイムアウトを60秒に設定します。

BIサーバーのアクセス

FW1

9704

HTTP / WLS_BIn

インバウンド

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

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

該当なし

9704

TCP/IPユニキャスト

該当なし

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

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

FW1

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

SQL*Net

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

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

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

ローカルおよび共有記憶域の要件、およびエンタープライズ・トポロジのインストール時および構成時における重要なディレクトリとファイルの場所の参照に使用される用語の理解が含まれます。

この章では、Oracle Fusion Middlewareエンタープライズ・デプロイメント用にファイル・システムを準備する方法について説明します。

- エンタープライズ・デプロイメント用のファイル・システムの準備の概要
この項では、エンタープライズ・デプロイメント用のファイル・システムを準備するプロセスの概要について説明します。

- エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項
この項では、エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項に対する参照を提供します。

- エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解
この項のダイアグラムは、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで推奨されるディレクトリ構造を示しています。

- このガイドで使用するファイル・システムとディレクトリ変数
この項では、このガイド全体で使用されているファイル・システムおよびディレクトリ変数をリストして説明します。

- エンタープライズ・デプロイメント用のディレクトリの作成およびマウントについて
この項では、エンタープライズ・デプロイメントで最上位ディレクトリを作成またはマウントする場合に従う必要のあるベスト・プラクティスを示します。

- エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー
この項では、エンタープライズ・デプロイメントに必要とされる共有記憶域ボリュームのサマリーを提供します。

親トピック: エンタープライズ・デプロイメントの準備

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

この項では、エンタープライズ・デプロイメント用のファイル・システムを準備するプロセスの概要について説明します。

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

この章を参照情報として使用すると、インストールおよび構成手順で使用されているディレクトリ変数について理解できます。

その他のディレクトリ・レイアウトも可能であり、サポートされていますが、このガイドで採用するモデルは、可用性を最大化するために設計されており、コンポーネントの最良の独立性と構成の対称性の両方を実現し、バックアップおよび障害時リカバリを容易にします。ドキュメントの残りの部分では、このディレクトリ構造およびディレクトリ用語を使用します。

7.2 エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項

この項では、エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項に対する参照を提供します。

この章で詳述する推奨事項を実行する前に、『高可用性ガイド』で共有記憶域の使用に関する推奨事項と一般情報を確認してください。

この章の推奨事項は、『高可用性ガイド』に記載されている概念とガイドラインに基づいています。

表7-1 に、確認しておく必要がある項の一覧と、それらの概念がエンタープライズ・デプロイメントにどのように適用されるかを示します。

表7-1 『高可用性ガイド』の共有記憶域に関するリソース

『高可用性ガイド』の項

エンタープライズ・デプロイメントにおける意義

共有記憶域に関する前提条件

共有記憶域向けに最適化された、ディスク形式のガイドラインとハードウェア・デバイス要件について説明します。

バイナリ(Oracleホーム)ディレクトリ用の共有記憶域の使用

複数のホストから使用可能な共有記憶域デバイスにOracleホームを格納する際のオプションについて説明しています。

エンタープライズ・デプロイメントの用途では、別々のストレージ・ボリューム上に格納した冗長Oracleホームを使用することをお薦めします。

別のボリュームがない場合は、共有ディスク上の別のパーティションを使用して、アプリケーション層のホストに冗長Oracleホームを用意してください。

ドメイン構成ファイル用の共有記憶域の使用

ドメイン内の管理サーバーと管理対象サーバーに別々のドメイン・ホームを作成する概念について説明しています。

エンタープライズ・デプロイメントでは、管理サーバーのドメイン・ホームの場所をASERVER_HOME変数で表します。

JMSストアおよびJTAログ用の共有記憶域の要件

エンタープライズ・デプロイメント用のトランザクション・ログとJMSストアの場所を設定する手順について説明しています。

注意:
Oracle Business Intelligenceには、特定のBusiness Intelligenceメタデータの場所を設定するための共有記憶域の追加要件があります。詳細は、「シングルトン・データ・ディレクトリ(SDD)の構成」を参照してください。

7.3 エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解

この項のダイアグラムは、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで推奨されるディレクトリ構造を示しています。

ダイアグラムに示す各ディレクトリには、Oracle Fusion Middlewareインストーラによってディスク上にインストールされるバイナリ・ファイル、ドメイン構成プロセスを通じて生成されるドメインごとのファイルの他に、Oracle WebLogic Serverのpackコマンドとunpackコマンドによって様々なホスト・コンピュータに伝播されるドメイン構成ファイルが格納されます。

- 図7-1 は、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で共有記憶域デバイスに作成されているディレクトリ構造を示しています。共有記憶域のディレクトリは、アプリケーション層のホスト・コンピュータからアクセス可能です。

- 図7-2 は、Oracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で、標準的なアプリケーション層のホスト用のローカル記憶域デバイスに作成されているディレクトリ構造を示しています。特に、管理対象サーバーはアプリケーション層のホスト・コンピュータ用のローカル記憶域デバイスに格納されます。

- 図7-3 は、Oracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で、標準的なWeb層のホスト用のローカル記憶域デバイスに作成されているディレクトリ構造を示しています。ソフトウェア・バイナリ(Oracleホーム内)は、Web層のホストごとのローカル記憶域デバイスにインストールされます。

該当する場合、ダイアグラムには、このガイドのインストールおよび構成手順でディレクトリ場所を表すために使用する標準変数も記載されています。

図7-1 エンタープライズ・デプロイメントで推奨される共有記憶域ディレクトリ構造

*詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

図7-2 エンタープライズ・デプロイメントで推奨されるアプリケーション層のホスト・コンピュータ向けローカル記憶域ディレクトリ構造

*詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

図7-3 エンタープライズ・デプロイメントで推奨されるWeb層のホスト・コンピュータ向けローカル記憶域ディレクトリ構造

7.4 このガイドで使用するファイル・システムとディレクトリ変数

この項では、このガイド全体で使用されているファイル・システムおよびディレクトリ変数をリストして説明します。

表7-2は、ファイル・システムのディレクトリとアプリケーション層でのそれらのディレクトリの参照に使用されるディレクトリ変数を示しています。表7-3は、ファイル・システムのディレクトリとWeb層でのそれらのディレクトリの参照に使用される変数を示しています。

共有記憶域を使用している場合のこれらのディレクトリのマウントの詳細は、「エンタープライズ・デプロイメント用のディレクトリの作成およびマウント」を参照してください。

このガイド全体を通して、トポロジのインストールおよび構成に関する手順では、ここに示す変数を使用してディレクトリの場所を参照します。

この項にリストされている各ディレクトリに対してオペレーティング・システム変数を定義することもできます。システム変数をご使用のUNIXシェルで定義しておけば、このドキュメントの記載どおりに変数を使用できるので、変数を実環境における実際の値と対応付ける必要がなくなります。

注意:

ストレージ・デバイスを構成して推奨ディレクトリ構造を作成したら、実際のディレクトリ・パスをエンタープライズ・デプロイメント・ワークブックに記録してください。これらのアドレスは、後で各ホスト・コンピュータでIPアドレスを有効化するときに使用します。

詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください。

表7-2 アプリケーション層の主要なディレクトリ変数のサンプル値

ディレクトリ変数

説明

アプリケーション層のサンプル値

ORACLE_BASE

Oracle製品のインストール先であるベース・ディレクトリ。

/u01/oracle

ORACLE_HOME

製品バイナリ用の読取り専用場所。アプリケーション層のホスト・コンピュータの場合は、共有ディスクに格納されます。

Oracleホームは、Oracle Fusion Middleware Infrastructureソフトウェアのインストール時に作成されます。

その後、その他のOracle Fusion Middleware製品を同じOracleホームにインストールできます。

/u01/oracle/products/fmw

ORACLE_COMMON_HOME

共通のユーティリティ、ライブラリおよび他の共有Oracle Fusion Middleware製品を格納する、Oracle Fusion MiddlewareのOracleホーム内のディレクトリ。

/u01/oracle/products/fmw/oracle_common

WL_HOME

Oracle WebLogic Serverソフトウェア・バイナリを格納するOracleホーム内のディレクトリ。

/u01/oracle/products/fmw/wlserver

PROD_DIR

インストールするOracle Fusion Middleware製品ごとの製品ディレクトリ。

/u01/oracle/products/fmw/prod_dir
製品は、エンタープライズ・デプロイメントに応じてsoa、wcc、biまたはその他の値にすることができます。

EM_DIR

Oracle Enterprise Manager Fusion Middleware Controlソフトウェア・バイナリの格納に使用される製品ディレクトリ。

/u01/oracle/products/fmw/em

JAVA_HOME

サポートされているJava Development Kit (JDK)のインストール先。

/u01/oracle/products/jdk

SHARED_CONFIG_DIR

ドメイン構成、キーストア、ランタイム・アーティファクト、アプリケーション・デプロイメントなど、共有環境構成ファイルのための共有親ディレクトリ

/u01/oracle/config

ASERVER_HOME

管理サーバーのドメイン・ホーム。共有ディスクにインストールされます。

/u01/oracle/config/domains/domain_name

この例では、domain_nameをWebLogic Serverドメイン名で置き換えます。

MSERVER_HOME

管理対象サーバーのドメイン・ホーム。unpackコマンドによってアプリケーション層のホストごとのローカル・ディスクに作成されます。

/u02/oracle/config/domains/domain_name

APPLICATION_HOME

アプリケーションのホーム・ディレクトリ。アプリケーション層のすべてのホスト・コンピュータからアクセスできるように、共有ディスクにインストールされます。

/u01/oracle/config/applications
/domain_name

ORACLE_RUNTIME

このディレクトリには、JMSログやTLogなどのOracleランタイム・アーティファクトが含まれます。

通常、このディレクトリは、ドメイン内のすべてのホストからアクセス可能な共有ファイル・システムとして個別にマウントします。

構成ウィザードを実行したり、構成後タスクを実行して、JMSストアまたはtlog永続ストアの場所を特定する場合は、このディレクトリをドメイン名、クラスタ名およびディレクトリの目的で修飾して使用できます。

次に例を示します。

ORACLE_RUNTIME/cluster_name/jms

/u01/oracle/runtime/

NM_HOME

マシン別ノード・マネージャの起動スクリプトおよび構成ファイルによって使用されるディレクトリ。

注意:

このディレクトリは、マシン別ノード・マネージャ構成を使用している場合にのみ必要となります。

詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

/u02/oracle/config/node_manager

DEPLOY_PLAN_HOME

デプロイメント・プランのディレクトリ。アプリケーション・デプロイメント・プラン用のデフォルトの場所として使用されます。

注意:

このディレクトリは、カスタム・アプリケーションをアプリケーション層にデプロイしている場合にのみ必要となります。

/u01/oracle/config/dp

KEYSTORE_HOME

カスタム証明書およびキーストアの共有場所。

/u01/oracle/config/keystores

表7-3 Web層の主要なディレクトリ変数のサンプル値

ディレクトリ変数

説明

Web層のサンプル値

OHS_ORACLE_HOME

Oracle HTTP Server製品バイナリ用の読取り専用場所。Web層のホスト・コンピュータの場合、このディレクトリはローカル・ディスクに格納されます。

Oracleホームは、Oracle HTTP Serverソフトウェアのインストール時に作成されます。

/u02/oracle/products/fmw

ORACLE_COMMON_HOME

共通のユーティリティ、ライブラリおよび他の共有Oracle Fusion Middleware製品を格納する、Oracle HTTP ServerのOracleホーム内のディレクトリ。

/u02/oracle/products/fmw
/oracle_common

WL_HOME

Oracle WebLogic Serverソフトウェア・バイナリを格納するOracleホーム内のディレクトリ。

/u02/oracle/products/fmw/wlserver

PROD_DIR

インストールするOracle Fusion Middleware製品ごとの製品ディレクトリ。

/u02/oracle/products/fmw/ohs

JAVA_HOME

サポートされているJava Development Kit (JDK)のインストール先。

/u02/oracle/products/jdk

OHS_DOMAIN_HOME

Web層の各ホストのローカル・ディスク上にOracle HTTP Serverをインストールする際に作成される、スタンドアロンOracle HTTP Serverドメインのドメイン・ホーム。

/u02/oracle/config/domains/domain_name

OHS_CONFIG_DIR

各Webホスト上にある、編集を行ったOracle HTTP Server構成ファイル(httpd.confやmoduleconf/*.confなど)の場所。

このディレクトリは、OHSステージング・ディレクトリと呼ばれることもあります。ここで行った変更は、後でOHSランタイム・ディレクトリに伝播されます。

詳細は、Oracle HTTP Server管理者ガイドのステージング・ディレクトリおよびランタイム構成ディレクトリに関する項を参照してください。

/u02/oracle/config/domains
/domain_name/config/fmwconfig
/components/OHS
/instance_name

7.5 エンタープライズ・デプロイメント用のディレクトリの作成およびマウントについて

この項では、エンタープライズ・デプロイメントで最上位ディレクトリを作成またはマウントする場合に従う必要のあるベスト・プラクティスを示します。

最上位ディレクトリを作成およびマウントするときには、次のベスト・プラクティスに注意してください。

- アプリケーション層については、BIHOST2にマウントされる別の共有記憶域ボリュームまたは別のパーティションにOracleホーム(ソフトウェア・バイナリの格納先)をインストールします。BIHOST2上のバイナリへのディレクトリ・パスが、BIHOST1上のディレクトリ・パスと同一であることを確認してください。
次に例を示します。

/u01/oracle/products/fmw/

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

- このエンタープライズ・デプロイメント・ガイドでは、Oracle Web Tierソフトウェアがローカル・ディスクにインストールされることを想定しています。
Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用している場合、共有ディスクでOracle Web Tierバイナリのインストール(およびOracle HTTP Serverインスタンスの作成)を行うことができます。ただし、これを行う場合、共有ディスクをアプリケーション層に使用する共有ディスクとは別にする必要があり、層を横断する記憶域デバイスへのアクセスに適切なセキュリティ制限を適用することを検討する必要があります。

アプリケーション層サーバー(BIHOST1およびBIHOST2)の場合と同様に、両方のコンピュータで同じディレクトリ・パスを使用します。

次に例を示します。

/u02/oracle/products/fmw/

7.6 エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー

この項では、エンタープライズ・デプロイメントに必要とされる共有記憶域ボリュームのサマリーを提供します。

次の表は、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントにおける共有ボリュームおよびその目的をまとめたものです。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

共有記憶域のボリューム

マウント先ホスト

マウント・ディレクトリ

説明および用途

NFSボリューム1

BIHOST1

/u01/oracle/products/

BIHOST1で使用される製品バイナリ用のローカル記憶域であり、この記憶域にはOracleホーム・ディレクトリと製品ディレクトリがインストールされます。

NFSボリューム2

BIHOST2

/u01/oracle/products/

BIHOST2で使用される製品バイナリ用のローカル記憶域であり、この記憶域にはOracleホーム・ディレクトリと製品ディレクトリがインストールされます。

NFSボリューム3

BIHOST1 BIHOST2

/u01/oracle/config/

すべてのホストにマウントされる管理サーバーのドメイン構成であり、最初はBIHOST1で使用されますが、任意のホストにフェイルオーバーできます。

NFSボリューム4

BIHOST1 BIHOST2

/u01/oracle/runtime/

すべてのホストにマウントされるランタイム・アーティファクト・ディレクトリであり、必要なJMSログ、ブログ、すべてのクラスタ依存共有ファイルなどのランタイム・アーティファクトが含まれます。

NFSボリューム5

BIHOST1

/u02/oracle/config/

プライベート管理対象サーバーのドメイン・ディレクトリが共有記憶域に配置されている場合の、BIHOST1で使用される管理対象サーバーのドメイン・ディレクトリ用のローカル記憶域。

NFSボリューム6

BIHOST2

/u02/oracle/config/

プライベート管理対象サーバーのドメイン・ディレクトリが共有記憶域に配置されている場合の、BIHOST2で使用される管理対象サーバーのドメイン・ディレクトリ用のローカル記憶域。

NFSボリューム7

WEBHOST1

/u02/oracle/

プライベート管理対象サーバーのドメイン・ディレクトリが共有記憶域に配置されている場合の、Oracle HTTP Serverソフトウェア・バイナリ(Oracleホーム)およびWEBHOST1で使用されるドメイン構成ファイル用のローカル記憶域。

NFSボリューム8

WEBHOST2

/u02/oracle/

プライベート管理対象サーバーのドメイン・ディレクトリが共有記憶域に配置されている場合の、Oracle HTTP Serverソフトウェア・バイナリ(Oracleホーム)およびWEBHOST2で使用されるドメイン構成ファイル用のローカル記憶域。

8 エンタープライズ・デプロイメント用のホスト・コンピュータの準備

必要な共有記憶域システムをホストにマウントする方法や、各ホストで必要な仮想IPアドレスを有効化する方法について説明します。

この章では、エンタープライズ・デプロイメントをホストする各コンピュータまたはサーバーから実行する必要があるタスクについて説明します。

- 各ホストの最小ハードウェア要件の検証
この項では、各ホストの最小ハードウェア要件について説明します。

- Linuxオペレーティング・システムの要件の検証
この項で、エンタープライズ・デプロイメント用の標準的なLinuxオペレーティング・システムの設定について確認してください。

- オペレーティング・システムのユーザーおよびグループの構成
この項のリストは、エンタープライズ・デプロイメントをホストする各コンピュータで定義するユーザーおよびグループを示しています。

- Unicodeサポートの有効化
この項では、Unicodeサポートの有効化について説明します。

- 各ホストへの必要な共有ファイル・システムのマウント
この項では、各ホストへの必要な共有ファイル・システムのマウントについて説明します。

- 各ホストでの必要な仮想IPアドレスの有効化
この項では、各ホストで必要な仮想IPアドレスを有効化する手順について説明します。

親トピック: エンタープライズ・デプロイメントの準備

8.1 各ホストの最小ハードウェア要件の検証

この項では、各ホストの最小ハードウェア要件について説明します。

エンタープライズ・デプロイメントに必要なハードウェアを取得したら、各ホスト・コンピュータにログインし、「エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件」に示すシステム要件を確認します。

Oracle Exalogicなどの仮想サーバー環境にデプロイしている場合、仮想サーバーそれぞれが最小要件を満たしていることを確認します。

十分なローカル・ディスク記憶域があり、共有記憶域が「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されているように構成されていることを確認します。

次のように十分なスワップ領域および一時領域を確保します。

- スワップ領域: システムに500MB以上ある必要があります。

- 一時領域: /tmpに500MB以上の空き領域がある必要があります。

8.2 Linuxオペレーティング・システムの要件の検証

この項で、エンタープライズ・デプロイメント用の標準的なLinuxオペレーティング・システムの設定について確認してください。

ホスト・コンピュータが最小オペレーティング・システム要件を満たしていることを確認するには、動作保証済のオペレーティング・システムがインストールされていることと、そのオペレーティング・システムに必要なパッチがすべて適用されていることを確認してください。

さらに、エンタープライズ・デプロイメント用の標準的なLinuxオペレーティング・システムの設定について、次の項を確認してください。

- Linuxのカーネル・パラメータの設定

- UNIXシステムでのオープン・ファイル制限とプロセス数の設定

- DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認

8.2.1 Linuxのカーネル・パラメータの設定

次に示すkernel-parameterとshell-limitの値は、推奨値のみです。これらの値をチューニングしてシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。

カーネル・パラメータは、トポロジのすべてのノードで表の最小値以上の値に設定する必要があります。

次の表の値は、現行のLinuxの推奨値です。Linuxおよびその他のオペレーティング・システムの最新の推奨値は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

データベースをホストにデプロイしている場合、追加のカーネル・パラメータを変更する必要がある場合があります。ご使用のプラットフォームの12c (12.2.1) Oracle Grid Infrastructureインストレーション・ガイドを参照してください。

表8-1 UNIXのカーネル・パラメータ

パラメータ

値

kernel.sem

256 32000 100 142

kernel.shmmax

4294967295

これらのパラメータを設定するには:

1. rootとしてログインし、ファイル/etc/sysctl.confのエントリを追加または修正します。

2. ファイルを保存します。

3. 次のコマンドを発行して変更をアクティブ化します。
/sbin/sysctl -p

8.2.2 UNIXシステムでのオープン・ファイル制限とプロセス数の設定

UNIXオペレーティング・システムでは、Open File Limitは重要なシステム設定です。ホスト・コンピュータ上で動作するソフトウェアのパフォーマンス全体に影響を及ぼす可能性があります。

Oracle Fusion Middlewareエンタープライズ・デプロイメントに適したOpen File Limitの設定のための指針として、「ホスト・コンピュータのハードウェア要件」を参照してください。

注意:

次の例はLinuxオペレーティング・システム用です。オペレーティング・システムのドキュメントを確認して、システムで使用するコマンドを判別します。

詳細は、次の項を参照してください。

- 現在開いているファイル数の表示

- オペレーティング・システムのオープン・ファイルおよびプロセス制限の設定

8.2.2.1 現在開いているファイル数の表示

次のコマンドでオープンになっているファイル数を確認できます。

/usr/sbin/lsof | wc -l

オープン・ファイル制限を確認するには、次のコマンドを使用します。

Cシェル:

limit descriptors

Bash:

ulimit -n

8.2.2.2 オペレーティング・システムのオープン・ファイルおよびプロセス制限の設定

オープン・ファイル制限値を変更する手順は次のとおりです。

1. rootとしてログインして、次のファイルを編集します。

/etc/security/limits.conf

2. limits.confファイルに次の行を追加します。(ここに示す値は例にすぎません):

* soft  nofile  4096
* hard  nofile  65536
* soft  nproc   2047
* hard  nproc   16384

nofilesの値はオープン・ファイル制限を表します。nproc値はプロセス制限を表します。

3. 変更内容を保存して、limits.confファイルを閉じます。

4. ホスト・コンピュータを再起動します。

8.2.3 DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認

Oracleソフトウェアのインストールを開始する前に、ホストのIPアドレス、完全修飾ホスト名および短縮名がすべてDNSサーバーに登録されていることを確認します。または、ローカルhostsファイルを使用して、次のようなエントリを追加することもできます。

IP_Address Fully_Qualified_Name Short_Name

次に例を示します。

10.229.188.205  host1.example.com  host1

8.3 オペレーティング・システムのユーザーおよびグループの構成

この項のリストは、エンタープライズ・デプロイメントをホストする各コンピュータで定義するユーザーおよびグループを示しています。

グループ

各ノードに次のグループを作成する必要があります。

- oinstall

- dba

ユーザー

各ノードに次のユーザーを作成する必要があります。

- nobody: 権限のないユーザー。

- oracle: Oracleソフトウェアの所有者。別の名前も使用できます。このアカウントのプライマリ・グループはoinstallにする必要があります。このアカウントは、dbaグループにも属している必要があります。

注意:

- グループoinstallは、Oracleソフトウェアが使用する共有記憶域およびローカル記憶域のすべてのファイル・システムに対する書込み権限を持っている必要があります。

- 各グループは、ノードごとに同じグループIDを持っている必要があります。

- 各ユーザーは、ノードごとに同じユーザーIDを持っている必要があります。

8.4 Unicodeサポートの有効化

この項では、Unicodeサポートの有効化について説明します。

オペレーティング・システムの構成がOracle Fusion Middleware製品でサポートされる文字の動作に影響を与えることがあります。

UNIXオペレーティング・システムでは、LANGとLC_ALLの各環境変数をUTF-8文字セットを使用したロケールに設定し、Unicodeサポートを有効化することを強くお薦めします。これにより、Unicodeのすべての文字が処理できるようになります。たとえば、Oracle Business IntelligenceテクノロジはUnicodeに基づいています。

オペレーティング・システムがUTF-8以外のエンコードを使用するように構成されている場合、Oracle Business Intelligenceコンポーネントが予期しない動作をする可能性があります。たとえば、ASCII以外のファイル名の場合は、ファイルにアクセスできず、エラーが発生する可能性があります。オペレーティング・システムの制約によって発生する問題はサポート対象外となります。

8.5 各ホストへの必要な共有ファイル・システムのマウント

この項では、各ホストへの必要な共有ファイル・システムのマウントについて説明します。

「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」の説明に従って構成された共有記憶域が、それを使用するホスト上で使用可能になっている必要があります。

エンタープライズ・デプロイメントでは、ハードウェア記憶域ファイラが存在することと、それがデプロイメント用に取得した各ホスト・コンピュータに接続されて使用可能になっていることが前提とされています。

共有記憶域を、アクセスが必要なすべてのサーバーにマウントする必要があります。

各ホストでは、適切な権限をNetwork Attached Storage (NAS)またはStorage Area Network (SAN)内で設定し、共有記憶域への書込みを可能にする必要があります。

共有記憶域のマウントについては、組織のベスト・プラクティスに従ってください。この項では、NFS記憶域を使用してLinuxでこれを行う方法の例を示します。

共有記憶域の場所を作成してマウントし、BIHOST1とBIHOST2が2つの別々のボリュームへのバイナリ・インストールである場合に、それらが同じ場所を参照できるようにする必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

次のコマンドを使用して、共有記憶域をNAS記憶域デバイスからLinuxホストにマウントします。別のタイプの記憶域デバイスまたはオペレーティング・システムを使用している場合、これを行う方法の詳細は製造元のドキュメントを参照してください。

注意:

共有記憶域のファイル・システムの作成に使用されるユーザー・アカウントは、これらのファイルに対する読取り、書込みおよび実行権限を持ちます。オペレーティング・システム・グループにおける他のユーザーは、ファイルの読取りや実行は可能ですが、書込み権限はありません。

インストールと構成の権限の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストレーション・ユーザーの選択に関する項を参照してください。

次の例では、nasfilerは共有記憶域ファイラを表します。これらは単なる例であることに注意してください。通常、これらの共有記憶域場所のマウントは、UNIXシステム上の/etc/fstabsファイルを使用して行う必要があります。これにより、再起動しても、これらのデバイスのマウントが維持されます。詳細は、オペレーティング・システムのドキュメントを参照してください。

1. 「エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー」の説明に従ってBIHOST1にマウント・ディレクトリを作成して、共有記憶域をマウントします。次に例を示します。

mount -t nfs nasfiler:VOL1/oracle/products/ /u01/oracle/products/

2. VOL2を使用して、BIHOST2でこの手順を繰り返します。

共有記憶域の構成の検証

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

次に例を示します。

$ cd newly mounted directory
$ touch testfile

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

$ ls -l testfile

ファイルを削除します。

$ rm testfile

注意:

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

mount -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768 nasfiler:VOL1/Oracle /u01/oracle

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

8.6 各ホストでの必要な仮想IPアドレスの有効化

この項では、各ホストで必要な仮想IPアドレスを有効化する手順について説明します。

エンタープライズ・デプロイメント用に各ホストを準備するには、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で説明されている仮想IP (VIP)アドレスを有効化する必要があります。

すでにVIPアドレスおよびホスト名を予約済であり、ネットワーク管理者がそれらを有効化していることを前提とします。その後、適切なホストでVIPを有効化できます。

エンタープライズ・トポロジで使用する仮想IPアドレスは、サーバー全体の移行(選択した管理対象サーバーおよびクラスタの場合)または手動フェイルオーバー(管理サーバーの場合)によって管理されるため、永続化されません。

各ホストでこのVIPアドレスを有効にするには、次のコマンドをrootとして実行します。

/sbin/ifconfig interface:index IPAddress netmask netmask
/sbin/arping -q -U -c 3 -I interface IPAddress

ここで、interfaceはeth0またはeth1、indexは0、1または2です。

次に例を示します。

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

ネットワークを有効化し、仮想IPアドレスの新しい場所を登録します。

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

別のノードからpingコマンドを使用して、アドレスが使用可能であることを確認します。次に例を示します。

/bin/ping 100.200.140.206

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

この章では、Oracle Business Intelligenceエンタープライズ・デプロイメントのデータベースを準備する手順について説明します。

この章では、データベース要件、データベース・サービスの作成およびデータベースのバックアップ計画に関する情報を提供します。

- エンタープライズ・デプロイメント用のデータベースの準備の概要
この項では、Oracle Fusion Middlewareエンタープライズ・デプロイメントの一環として、サポートされているデータベースを構成する方法について説明します。

- データベース要件について
データベースがこれらの項で説明されている要件を満たしていることを確認してください。

- データベース・サービスの作成
複数のOracle Fusion Middleware製品が同じデータベースを共有する場合は、個別の専用のデータベース・サービスに接続するように、各製品を構成する必要があります。

- Oracleデータベースでのラージ・オブジェクト(LOB)に対するSecureFilesの使用
Oracle Database 11gリリース1以降、新しいLOB記憶域アーキテクチャであるSecureFilesが導入されました。Oracle Fusion Middlewareスキーマ、特にOracle SOA SuiteスキーマにはSecureFilesの使用をお薦めします。

- データベース・バックアップ戦略について
この項では、データベース・バックアップ戦略の必要性について簡単に説明します。

親トピック: エンタープライズ・デプロイメントの準備

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

この項では、Oracle Fusion Middlewareエンタープライズ・デプロイメントの一環として、サポートされているデータベースを構成する方法について説明します。

ほとんどのOracle Fusion Middleware製品では、サポートされているデータベースに特定の一連のスキーマがインストールされている必要があります。これらのスキーマは、Oracle Fusion Middlewareのリポジトリ作成ユーティリティ(RCU)を使用してインストールします。

エンタープライズ・デプロイメントでは、Oracle Fusion Middleware製品スキーマに高可用性Real Application Clusters (Oracle RAC)データベースをお薦めします。

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

データベースがこれらの項で説明されている要件を満たしていることを確認してください。

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

- その他のデータベース・ソフトウェア要件

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

次の情報を利用して、Oracle Fusion Middlewareの各リリースでサポートされているデータベース、および現在稼働中のOracleデータベースのバージョンを確認してください。

- 動作保証済のデータベースの全リストは、Oracle Fusion Middlewareのサポートされるシステム構成のページを参照してください。

- データベースのリリースを確認するには、PRODUCT_COMPONENT_VERSIONビューに問い合せます。

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

Oracle Fusion Middlewareでは、データベースがAL32UTF8文字セットに対応している必要があります。データベースの文字セットの選択に関する情報は、データベースのドキュメントを確認してください。

エンタープライズ・デプロイメントでは、Oracle RACデータベースへの接続にGridLinkデータ・ソースを使用することをお薦めします。

注意:

GridLinkデータ・ソースおよびSCANの使用方法の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のアクティブなGridLinkデータ・ソースの使用に関する項を参照してください。

9.2.2 その他のデータベース・ソフトウェア要件

エンタープライズ・トポロジでは、RACデータベースの2つのインスタンスをホストする2つのデータベース・ホスト・コンピュータがデータ層にあります。これらのホストをDBHOST1、DBHOST2と呼びます。

エンタープライズ・トポロジをインストールまたは構成する前に、次のソフトウェアがDBHOST1とDBHOST2にインストール済であり使用可能であることを確認する必要があります。

- Oracle Clusterware
詳細は、Oracle Grid Infrastructureインストレーション・ガイド(Linux版)を参照してください。

- Oracle Real Application Cluster
詳細は、Oracle Real Application Clustersインストレーション・ガイド(LinuxおよびUNIX版)を参照してください。

- Oracle RACデータベース・インスタンス間の時間同期
サーバー移行で構成された、Fusion Middlewareクラスタ内のサーバーで使用されているデータベース・インスタンスのクロックは、同期化されている必要があります。

- 自動ストレージ管理(オプション)
詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

9.3 データベース・サービスの作成

複数のOracle Fusion Middleware製品が同じデータベースを共有する場合は、個別の専用のデータベース・サービスに接続するように、各製品を構成する必要があります。

注意:

この項に示す手順は、Oracle Database 12c (12.1)リリースを対象としています。これ以外のサポートされているデータベースをご使用の場合は、該当するドキュメント・ライブラリで最新のリリース別の情報を参照してください。

サービスを使用したOracle Databaseへの接続の詳細は、『Real Application Clusters管理およびデプロイメント・ガイド』の動的データベース・サービスを使用したOracle Databaseへの接続の概要に関する項を参照してください。

また、データベース・サービスはデフォルトのデータベース・サービスとは別のものにしてください。Oracle Database 12cデータベースのデータベース・サービスを作成および管理する完全な手順は、『Real Application Clusters管理およびデプロイメント・ガイド』の動的データベース・サービスによる自動ワークロード管理の概要に関する項を参照してください。

実行時接続ロード・バランシングでは、ロード・バランシングが有効になっている各サービスのサービス・レベルの目標を使用してOracle RACロード・バランシング・アドバイザを構成する必要があります。

SERVICE_TIMEまたはTHROUGHPUTについて、Oracle RACロード・バランシング・アドバイザを構成できます。接続ロード・バランシングの目標をSHORTに設定します。

srvctlユーティリティを使用してOracle Databaseサービスを作成および変更します。

データベース・サービスを作成および変更する手順は次のとおりです。

1. SQL*Plusにログインして、サービスを作成します。

sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'biedg.example.com',
NETWORK_NAME => 'biedg.example.com'
);

注意:

Oracle RACデータベースのサービス名には小文字を使用し、続けてドメイン名を指定します。次に例を示します。

biedg.example.com

注意:

EXECUTE DBMS_SERVICEコマンドを1行で入力します。

DBMS_SERVICEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプのリファレンスを参照してください。

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

srvctl add service -d bidb -s biedg.example.com -r bidb1,bidb2

3. サービスを開始します。

srvctl start service -d bidb -s biedg.example.com

注意:

SRVCTLを使用したデータベース・サービスの作成および管理の詳細な手順は、『Real Application Clusters管理およびデプロイメント・ガイド』のSRVCTLを使用したサービスの作成に関する項を参照してください。

4. ロード・バランシング・アドバイザおよびランタイム接続のロード・バランシングにおけるサービス・レベルの適切な目標値が使用されるようにサービスを変更します。

より具体的には、Oracle Database 12cの『Real Application Clusters管理およびデプロイメント・ガイド』のリソースを使用して、サービス・レベルの目標値SERVICE_TIMEおよびTHROUGHPUTを設定します。

- ロード・バランシング・アドバイザの概要

- ロード・バランシング・アドバイザを使用する環境の構成

9.4 Oracleデータベースでのラージ・オブジェクト(LOB)に対するSecureFilesの使用

Oracle Database 11gリリース1以降、新しいLOB記憶域アーキテクチャであるSecureFilesが導入されました。Oracle Fusion Middlewareスキーマ、特にOracle SOA SuiteスキーマにはSecureFilesの使用をお薦めします。

詳細は、Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイドのOracle SecureFiles LOBの使用に関する項を参照してください。

Oracle 12cデータベースでは、SecureFilesを使用するためのデフォルト設定はPREFERREDです。これは、LOBまたは親LOB (LOBがパーティションまたはサブパーティション内にある場合)でBasicFiles LOBが明示的に指定されていなければ、データベースがSecureFiles LOBの作成を試みることを意味します。Oracle Fusion MiddlewareスキーマではBasicFilesを明示的に指定しません。したがって、Oracle 12cデータベースがインストールされている場合、Oracle Fusion MiddlewareのLOBはデフォルトでSecureFilesになります。

Oracle 11gデータベースでは、db_securefileシステム・パラメータによってSecureFiles使用ポリシーが制御されます。このパラメータは動的に変更できます。SecureFilesを使用するには次のオプションがあります。

- PERMITTED: SecureFilesの作成を許可します(これがdb_securefileのデフォルト設定です。デフォルトの格納方式ではBasicFilesが使用されます)

- FORCE: すべての(新規) LOBをSecureFilesとして作成します

- ALWAYS: LOBをSecureFilesとして作成しようと試みますが、作成できない場合(ASSMが無効の場合)はBasicFilesに戻します

この他にも、db_securefileパラメータには次の値があります。

- IGNORE: SecureFilesを作成する試行を無視します

- NEVER: 新しいSecureFilesの作成を許可しません

Oracle 11gデータベースの場合、リポジトリ作成ユーティリティ(RCU)でOracle Fusion Middlewareスキーマを作成する前に、db_securefileパラメータをFORCEに設定することをお薦めします。

SecureFilesセグメントは、表領域を自動セグメント領域管理(ASSM)によって管理する必要があります。つまり、ASSMが無効になっていると、SecureFilesでのLOB作成が失敗します。ただし、Oracle Fusion Middlewareの表領域は、デフォルトではASSMが有効な状態で作成されます。したがって、デフォルトの構成では、Oracle Fusion Middlewareスキーマに対してSecureFilesを有効にするために何かを変更する必要はありません。

9.5 データベース・バックアップ戦略について

この項では、データベース・バックアップ戦略の必要性について簡単に説明します。

エンタープライズ・デプロイメントのインストールおよび構成の重要な点として、現在の環境をバックアップすることをお薦めします。たとえば、製品ソフトウェアをインストールし、特定のOracle Fusion Middleware製品のスキーマを作成した後で、データベース・バックアップを実行してください。バックアップを実行すれば、後の構成手順で何か問題が発生しても、すばやくリカバリを実行できます。

この目的のために独自のデータベース・バックアップ戦略を使用することも、オペレーティング・システムのツールやRMANを使用して単純にバックアップすることもできます。

特に、Oracle Automatic Storage Managementを使用してデータベースを作成した場合は、Oracle Recovery Managerの使用をお薦めします。可能な場合、オペレーティング・システムのツール(tarなど)を使用してコールド・バックアップも実行できます。

第III部 エンタープライズ・デプロイメントの構成

エンタープライズ・デプロイメント・ガイドのこの部には、次のトピックがあります。

- エンタープライズ・デプロイメント用の初期BIドメインの作成
この章では、エンタープライズ・デプロイメントの開始点として使用できるOracle Business Intelligence (BI)ドメインのインストールおよび構成方法について説明します。

- エンタープライズ・デプロイメント用のWeb層の構成
この章では、WEBHOST1とWEBHOST2に1つずつ、2つのOracle HTTP Serverインスタンスを含むスタンドアロンのOracle HTTP Serverドメインをインストールおよび構成する方法について説明します。

- Oracle Business Intelligenceのスケール・アウト
この章では、初期Oracle Business IntelligenceドメインをBIHOST2にスケール・アウトする手順について説明します。

10 エンタープライズ・デプロイメント用の初期BIドメインの作成

この章では、エンタープライズ・デプロイメントの開始点として使用できるOracle Business Intelligence (BI)ドメインのインストールおよび構成方法について説明します。

この章には、BIドメインの作成、データベース・スキーマの作成およびBIドメインの構成を行う際に使用される変数に関する情報が記載されています。

- BIドメインの作成時に使用する変数
この章の作業を実行する場合、この項にリストされているディレクトリ変数を参照します。

- 初期BIドメインの理解
初期Business Intelligence (BI)ドメインを作成する前に、次の重要な概念を確認してください。

- エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール
この項を使用して、エンタープライズ・デプロイメント用の新しいドメインを構成する準備として、Oracle Fusion Middleware Infrastructureソフトウェアをインストールします。

- エンタープライズ・デプロイメントの準備におけるOracle Business Intelligenceのインストール
この項を使用して、エンタープライズ・デプロイメント用の新しいドメインを構成する準備として、Oracle Business Intelligenceソフトウェアをインストールします。

- データベース・スキーマの作成
BIドメインを構成する前に、この項にリストされているスキーマを、このリリースのOracle Fusion Middlewareと組み合せて使用するために動作保証されたデータベースにインストールする必要があります。

- BIドメインの構成
この項では、構成ウィザードを使用してWebLogicドメインを作成するための指示について説明します。

- BIHOST1でのシステム・コンポーネントの作成
この項の手順を実行して、BIHOST1にBIクラスタ・コントローラ、BIスケジューラ、BIプレゼンテーション・サービスおよびBI JavaHostシステム・コンポーネントを作成します。

- BIサービス・インスタンスの作成
この項の手順を実行して、新しいBIサービス・インスタンスを作成します。

- シングルトン・データ・ディレクトリ(SDD)の構成
Oracle Business Intelligenceメタデータは、シングルトン・データ・ディレクトリ(SDD)に格納されています。メタデータは、プレゼンテーション・カタログ、メタデータ・リポジトリおよびセキュリティ認証に関する情報を含むOracle Business Intelligenceアーカイブ(BAR)ファイルで管理されます。

- Oracle Business IntelligenceでのEssbaseのセキュリティの構成
Oracle Business Intelligenceインストーラを使用してインストールされたEssbaseコンポーネントは、ネイティブEssbaseまたはHyperion Shared Services (HSS)セキュリティを使用できません。

- ドメイン・ディレクトリの構成とBIHOST1上のサーバーの起動
ドメインの作成後、BIHOST1で一連の追加構成タスクを実行する必要があります。たとえば、ノード・マネージャおよび管理サーバーを起動します。その後、管理対象サーバーの個別ドメイン・ディレクトリを作成します。この新しい個別の管理対象サーバー・ディレクトリで、2番目のノード・マネージャ・インスタンスを起動し、管理対象サーバーおよびBusiness Intelligenceシステム・コンポーネントを起動します。

- グローバル・キャッシュの設定
グローバル・キャッシュとは、クラスタに参加しているすべてのOracle BIサーバーが共有する問合せキャッシュです。クラスタに参加しているすべてのOracle BIサーバーでキャッシュのシーディング・イベントおよびパージ・イベントを共有するようにグローバル・キャッシュを構成することをお薦めします。

- BIHOST1でのOracle Business Intelligence URLの確認
BIHOST1でドメインのコンポーネントを起動した後、これらのURLにアクセスして、Oracle Business Intelligenceの構成を確認します。

- 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング
Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

- Oracle Business Intelligence構成のバックアップ
Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

親トピック: エンタープライズ・デプロイメントの構成

10.1 BIドメインの作成時に使用する変数

この章の作業を実行する場合、この項にリストされているディレクトリ変数を参照します。

ディレクトリ変数は、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- APPLICATION_HOME

- JAVA_HOME

さらに、「エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスとホスト名を参照することになります。

- ADMINVHN

- BIHOST1VHN1

- BIHOST1

- Oracle RACデータベースのSCANアドレス(DB-SCAN.example.com)

10.2 初期BIドメインの理解

初期Business Intelligence (BI)ドメインを作成する前に、次の重要な概念を確認してください。

- インフラストラクチャ・ディストリビューションについて

- 初期BIドメインの特徴

10.2.1 インフラストラクチャ・ディストリビューションについて

エンタープライズ・デプロイメントの初期Business Intelligenceドメインの作成には、Oracle Fusion Middleware Infrastructureディストリビューションを使用します。このディストリビューションには、Oracle WebLogic ServerソフトウェアとOracle JRFソフトウェアの両方が1つのディストリビューションとして含まれています。

Oracle JRFソフトウェアは、Oracle Web Services Manager、Oracle Application Development Framework (Oracle ADF)、Oracle Enterprise Manager Fusion Middleware Control、リポジトリ作成ユーティリティ(RCU)およびOracle Fusion Middleware製品のサポートに必要なその他のライブラリおよびテクノロジで構成されています。

詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middleware Infrastructureの理解に関する項を参照してください。

10.2.2 初期BIドメインの特徴

初期BIドメインのこれらの主な特徴を確認してください。これらの特徴を確認して理解することで、ドメインの構成手順の目的やコンテキストに対する理解が深まります。

これらの特徴の多くについては、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

表10-1 初期BIドメインの特徴

ドメインの特徴

追加情報

管理サーバーに別個の仮想IP (VIP)アドレスを使用。

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

ドメイン内の管理サーバーと管理対象サーバーに別個のドメイン・ディレクトリを使用。

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

各ホスト上の管理サーバーと管理対象サーバーにドメインごとのノード・マネージャと別個のノード・マネージャ・プロセスを使用。

標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

別途インストールされたLDAPベースの認証プロバイダが必要。

OPSSおよび認証ストアと認可ストアへのリクエストの理解

10.3 エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール

この項を使用して、エンタープライズ・デプロイメント用の新しいドメインを構成する準備として、Oracle Fusion Middleware Infrastructureソフトウェアをインストールします。

- サポートされているJDKのインストール

- BIHOST1でのInfrastructureインストーラの起動

- Infrastructureインストール画面のナビゲート

- ディレクトリ構造のチェック

10.3.1 サポートされているJDKのインストール

Oracle Fusion Middlewareでは、動作保証されたJava Development Kit (JDK)がシステムにインストールされている必要があります。詳細は、次の各項を参照してください。

- JDKソフトウェアの検索とダウンロード

- JDKソフトウェアのインストール

10.3.1.1 JDKソフトウェアの検索とダウンロード

動作保証されているJDKを調べるには、Oracle Fusion Middlewareのサポートされるシステム構成ページで、ご使用のリリース向けの動作保証ドキュメントを参照してください。

現在のOracle Fusion MiddlewareリリースのOracle JDKを特定したら、Oracle Technology Networkの次の場所からOracle JDKをダウンロードできます。

http://www.oracle.com/technetwork/java/index.html

Java SE JDKのダウンロードに必ず移動してください。

10.3.1.2 JDKソフトウェアのインストール

JDKを次の場所にインストールします。

- アプリケーション層の各ホスト・コンピュータからアクセスできる共有記憶域デバイス

- Web層の各ホスト・コンピュータのローカル記憶域デバイス
DMZに配置されるWeb層ホスト・コンピュータは、アプリケーション層の共有記憶域に必ずしもアクセスできるとはかぎりません。

JDKソフトウェアの推奨場所の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。

次の例では、JDK 1.8の最新バージョンをインストールする方法について説明します。

1. ディレクトリを、JDKアーカイブ・ファイルをダウンロードした場所に変更します。

2. JDKホーム・ディレクトリにアーカイブを解凍してから、次のコマンドを実行します。

cd download_dir
tar -xzvf jdk-8u51-linux-x64.tar.gz

ここに示されているJDKバージョンは、このドキュメントの発行時点のものです。サポートされている最新のJDKは、Oracle Fusion Middlewareシステム要件と仕様で現在のOracle Fusion Middlewareリリースを参照してください。

3. ディレクトリ構造内の推奨場所にJDKディレクトリを移動します。

次に例を示します。

mv ./jdk1.8.0_51 /u01/oracle/products/jdk

詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

4. ホスト・コンピュータでJavaを実行するためのJAVA_HOMEおよびPATH環境変数を定義します。

次に例を示します。

export JAVA_HOME=/u01/oracle/products/jdk
export PATH=$JAVA_HOME/bin:$PATH

5. 次のコマンドを実行して、適切なjava実行可能ファイルがそのパスにあり、環境変数が適切に設定されていることを確認します。

java -version
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

10.3.2 BIHOST1でのInfrastructureインストーラの起動

インストール・プログラムを起動するには、次の手順を実行します。

1. BIHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

JAVA_HOME/bin/java -d64 -jar distribution_file_name.jar

この例の説明は、次のとおりです。

- JAVA_HOMEを、ご使用のシステムの環境変数または実際のJDKの場所に置き換えます。

- distribution_file_nameを、ディストリビューションJARファイルの実際の名前に置き換えます。
ディストリビューションをOracle Technology Network (OTN)からダウンロードする場合、通常、JARファイルはダウンロード可能なZIPファイル内にパッケージされています。

初期Infrastructureドメインに必要なソフトウェアをインストールする場合は、インストールするディストリビューションはfmw_12.2.1.0.0_infrastructure.jarです。

各ディストリビューションの実際のファイル名の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明は、「インストール画面のナビゲート」を参照してください。

10.3.3 Infrastructureインストール画面のナビゲート

インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

インストール・インベントリの設定

この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。

中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解に関する項を参照してください。

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索したり、組織用にすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストール場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

エンタープライズ・デプロイメントのためには、表7-2 に示すORACLE_HOME変数の値を入力します。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

このトポロジの場合は、「Fusion Middleware Infrastructure」を選択します。

注意: このドキュメントのトポロジには、サーバー・サンプルは含まれていません。本番環境にサンプルをインストールしないことを強くお薦めします。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告またはエラー・メッセージが表示される場合、Oracle Technology Network (OTN)のOracle Fusion Middlewareシステム要件と仕様を参照してください。

セキュリティ更新

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所持していないときに、この手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、その選択を後続のダイアログ・ボックスで確認します。

自動更新 - パッチの選択

この画面は、次の両方に当てはまる場合に表示されます。

- 「自動更新」画面を使用して、インストール・セッションの前の方で使用可能なパッチを検索した場合。

- 自動更新機能により、このインストール・セッションで作成中のOracleホームに適用する必要がある1つ以上のアプリケーション・パッチが見つかった場合。

この画面には、自動更新機能で見つかったパッチがリストされます。1つ以上のパッチを選択し、「次へ」をクリックして、選択したパッチをOracleホームに適用します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

10.3.4 ディレクトリ構造のチェック

Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、次のディレクトリとサブディレクトリが表示されます。インストールの内容は、インストール中に選択したオプションによって異なります。

ディレクトリ構造を確認する手順は次のとおりです。

1. ディレクトリをORACLE_HOMEディレクトリに変更します。

2. 次のコマンドを入力します。
ls -l

ご使用のシステムのディレクトリ構造は、次の例に示す構造と一致している必要があります。

/u01/oracle/products/fmw/

cfgtoollogs
coherence
em
install
inventory
OPatch
oracle_common
oraInst.loc
oui
root.sh
wlserver

インストール完了後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要なディレクトリに関する項を参照してください。

10.4 エンタープライズ・デプロイメントの準備におけるOracle Business Intelligenceのインストール

この項を使用して、エンタープライズ・デプロイメント用の新しいドメインを構成する準備として、Oracle Business Intelligenceソフトウェアをインストールします。

- インストール・プログラムの起動

- インストール画面への移動

- ディレクトリ構造のチェック

10.4.1 インストール・プログラムの起動

次の手順を使用して、BIインストーラを起動します。

1. BIHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. 次の例に示すとおり、実行可能ファイルを実行し、インストール・プログラムを起動します。

./bi_platform-12.2.1.0.0_linux64.bin

各ディストリビューションの実際のファイル名の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明は、「インストール画面のナビゲート」を参照してください。

10.4.2 インストール画面への移動

インストール・プログラムでは、表10-2 に記載された順番で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

表10-2 Oracle Business Intelligenceのインストール画面

画面

説明

インストール・インベントリの設定

この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。

中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解に関する項を参照してください。

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索したり、組織用にすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します

インストール場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

エンタープライズ・デプロイメントのためには、表7-2 に示すORACLE_HOME変数の値を入力します。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

このトポロジについては、サンプル付きBIプラットフォーム・ディストリビューションを選択します。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告またはエラー・メッセージが表示される場合、Oracle Technology Network (OTN)のOracle Fusion Middlewareシステム要件と仕様を参照してください。

自動更新 - パッチの選択

この画面は、次の両方に当てはまる場合に表示されます:

- 「自動更新」画面を使用して、インストール・セッションの前の方で使用可能なパッチを検索した場合。

- 自動更新機能により、このインストール・セッションで作成中のOracleホームに適用する必要がある1つ以上のアプリケーション・パッチが見つかった場合。

この画面には、自動更新機能で見つかったパッチがリストされます。1つ以上のパッチを選択し、「次へ」をクリックして、選択したパッチをOracleホームに適用します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

10.4.3 ディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

Oracle Business Intelligenceをインストールすると、次のディレクトリとサブディレクトリが表示されます。

/u01/oracle/products/fmw1221/bi

bi-epm-registry
bifoundation
bin
clients
common
endpointmanager
file_templates
jlib
lib
migration-tool
modules
nls
oracore
plugins
products
schema
vcredist_x64.exe
vcredist_x86.exe
xsd

10.5 データベース・スキーマの作成

BIドメインを構成する前に、この項にリストされているスキーマを、このリリースのOracle Fusion Middlewareと組み合せて使用するために動作保証されたデータベースにインストールする必要があります。

- メタデータ・サービス(MDS)

- 監査サービス(IAU)

- 監査サービスへの追加(IAU_APPEND)

- 監査サービス・ビューア(IAU_VIEWER)

- OPSS (Oracle Platform Security Services)

- ユーザー・メッセージング・サービス(UMS)

- WebLogicサービス(WLS)

- WebLogicランタイム・サービス(WLS_RUNTIME)

- 共通インフラストラクチャ・サービス(STB)

- Business Intelligenceプラットフォーム(BIPLATFORM)

リポジトリ作成ユーティリティ(RCU)を使用して、スキーマを作成します。このユーティリティは各Oracle Fusion Middleware製品のOracleホームにインストールされています。RCUの詳細とスキーマを作成してデータベースに格納する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でスキーマ作成の準備に関する項を参照してください。

- 動作保証されたデータベースのインストールと構成

- リポジトリ作成ユーティリティ(RCU)の起動

- スキーマ作成のためのRCU画面のナビゲート

10.5.1 動作保証されたデータベースのインストールと構成

動作保証されたデータベースを適切にインストールして構成し、そのデータベースを起動して稼働させておく必要があります。

詳細は、次のリソースを参照してください。

- 「エンタープライズ・デプロイメント用のデータベースの準備」。データベース・サービスの作成、ラージ・オブジェクト(LOB)でのSecureFilesの使用、およびエンタープライズ・デプロイメントにおいて重要なその他のトピックに関する情報が含まれています。

- 『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のOracle Fusion Middlewareインストールのデータベース要件の理解に関する項。

10.5.2 リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

1. サポートされているJDKをインストールした場所を参照するようにJAVA_HOME環境変数を設定します。

詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

2. BIHOST1上の次のディレクトリに移動します。

ORACLE_HOME/oracle_common/bin

3. RCUを起動します。

./rcu

10.5.3 スキーマ作成のためのRCU画面のナビゲート

この項で説明する手順を実行して、Oracle Business Intelligenceドメインにスキーマを作成します。

タスク1    RCUの導入

「ようこそ」画面で、RCUのバージョン番号を確認します。「次へ」をクリックして開始します。

タスク2    スキーマ作成の方法の選択

データベースでDBAアクティビティを実行するために必要な権限を持っている場合は、「リポジトリの作成」画面で「システム・ロードおよび製品ロード」を選択します。このドキュメントの手順では、必要な権限があることを想定しています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。これによってSQLスクリプトが生成され、これをデータベース管理者が利用できます。リポジトリ作成ユーティリティを使用したスキーマの作成のシステム・ロードおよび製品ロードの理解に関する項を参照してください。

ヒント:

この画面の選択内容の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でリポジトリの作成に関する項を参照してください。

タスク3    データベース資格証明の指定

「データベース接続の詳細」画面に、データベースに接続するためのRCUに関するデータベース接続の詳細が表示されます。

「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

ヒント:

この画面の選択内容の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でデータベース接続の詳細に関する項を参照してください。

タスク4    カスタム接頭辞の指定とスキーマの選択

1. Oracle Fusion Middlewareスキーマの識別に使用するカスタム接頭辞を指定します。
カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。このガイドでは、FMW1221という接頭辞を使用します。

ヒント:

ここで入力したカスタム接頭辞を書き留めてください。これは後でドメインの作成時に必要になります。

2. 「AS共通スキーマ」を選択します。
「AS共通スキーマ」を選択すると、このセクションのすべてのスキーマが自動的に選択されます。

Common Infrastructure Servicesと呼ばれるスキーマも自動的に作成されます。このスキーマはグレー表示されており、選択も選択解除もできません。このスキーマ(STBスキーマ)を使用すると、ドメインの構成中にRCUから情報を取得できます。詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

3. Business Intelligenceプラットフォームを選択します。

ヒント:

カスタム接頭辞の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のカスタム接頭辞の理解に関する項を参照してください。

マルチドメイン環境でスキーマを編成する方法の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のスキーマ作成の計画に関する項を参照してください。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5    スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6    スキーマ作成の完了

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。

このガイドでは、残りの画面のデフォルト設定を受け入れるか、RCUでのOracle Fusion Middlewareスキーマの作成方法および必要な表領域の使用方法をカスタマイズします。

RCUおよびその機能と概念については、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

10.6 BIドメインの構成

この項では、構成ウィザードを使用してWebLogicドメインを作成するための指示について説明します。

ドメイン作成に使用可能なその他の方法の詳細は、構成ウィザードを使用したWebLogicドメインの作成のWebLogicドメインの作成、拡張および管理のための追加ツールに関する項を参照してください。

この項では、次のタスクについて説明します。

- 構成ウィザードの起動

- BIドメインを構成するための構成ウィザード画面のナビゲート

10.6.1 構成ウィザードの起動

ドメインの構成を開始するには、Oracle Fusion Middleware Oracleホームで次のコマンドを実行します。

ORACLE_HOME/oracle_common/common/bin/config.sh

10.6.2 BIドメインを構成するための構成ウィザード画面のナビゲート

この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。

タスク1    ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「新規ドメインの作成」を選択します。

「ドメインの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOME変数の値を指定します。

ヒント:

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

タスク2    構成テンプレートの選択

「テンプレート」画面では、「製品テンプレートを使用してドメインを作成」が選択されていることを確認し、次のテンプレートを選択します。

- Oracle BIEE Suite - 12.2.1.0 [bi]
このテンプレートを選択すると、次の依存性が自動的に選択されます。

- Oracle MapViewer -12.2.1 [oracle_common]

- Oracle Enterprise Manager - 12.2.1 [em]

- Oracle WSM Policy Manager - 12.2.1.0 [oracle_common]

- Oracle JRF - 12.2.1 [oracle_common]

- WebLogic Coherenceクラスタの拡張 - 12.2.1 [wlserver]

- Oracle BI Publisher Suite - 12.2.1.0 [bi]

- Oracle BI Essbase Suite - 12.2.1 [bi]

また、基本的なWebLogicサーバー・ドメイン - 12.2.1 [wlserver]テンプレートはすでに選択され、グレー表示されている必要があります。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「テンプレート」に関する項を参照してください。

タスク3    アプリケーション・ホームの場所の選択

「アプリケーションの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「アプリケーションの場所」に関する項を参照してください。

タスク4    管理者アカウントの構成

「管理者アカウント」画面では、ドメインに対するデフォルトのWebLogic管理者アカウントにユーザー名とパスワードを指定します。

この画面で指定したユーザー名およびパスワードを書き留めておいてください。これらの資格証明は後でドメインの管理サーバーを起動して接続する際に必要になります。

タスク5    ドメイン・モードとJDKの指定

「ドメイン・モードおよびJDK」画面では、次の操作を実行します。

- 「ドメイン・モード」フィールドで、「本番」を選択します。

- 「JDK」フィールドで「Oracle Hotspot JDK」を選択します。

「本番モード」をこの画面で選択すると、環境で高度なセキュリティが実現され、アプリケーションのデプロイと管理サーバーの起動でユーザー名とパスワードが必要になります。

ヒント:

開発モードと本番モードの違いなど、この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。

本番モードでは、起動アイデンティティ・ファイルを作成することで、管理サーバーの起動時に必要なユーザー名とパスワードの指定を省略できます。詳細は、「boot.propertiesファイルの作成」を参照してください。

タスク6    データベース構成タイプの指定

「RCUデータ」を選択して、この画面に示されるフィールドをアクティブ化します。

「RCUデータ」オプションによってデータベースおよびサービス表(STB)スキーマに接続し、ドメインの構成に必要なスキーマのスキーマ情報を自動的に受け取るように構成ウィザードで指定できます。

注意:

この画面の「手動構成」を選択した場合は、「JDBCコンポーネント・スキーマ」画面でスキーマのパラメータを手動で入力する必要があります。

「RCUデータ」を選択したら、次の表に示すフィールドに入力します。図10-1 のサンプルの「データベース構成タイプ」画面の部分的なスクリーン・ショットを参照してください。

フィールド

説明

DBMS/サービス

製品スキーマをインストールするOracle RACデータベースのサービス名を入力します。次に例を示します。

orcl.example.com

必ずOracle RACデータベース内のすべてのインスタンスの識別に使用される共通サービス名を指定してください。ホスト固有のサービス名は使用しないでください。

詳細は、「エンタープライズ・デプロイメント用のデータベースの準備」を参照してください。

ホスト名

Enterprise Deployment Workbookに入力したOracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

ポート

データベースがリスニングするポート番号を入力します。たとえば、1521などです。

スキーマ所有者

スキーマ・パスワード

データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。

これはRCUの「スキーマ・パスワード」画面でサービス表コンポーネントに指定されたスキーマのユーザー名およびパスワードです。

デフォルトのユーザー名はprefix_STBであり、この場合prefixはRCUで定義したカスタム接頭辞です。

図10-1 エンタープライズ・デプロイメントのデータベース構成タイプの設定

データベース接続情報の指定が完了したら、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示しています。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

データベースへの接続に成功したら、「次へ」をクリックします。

ヒント:

「RCUデータ」オプションの詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のサービス表スキーマの理解に関する項を参照してください。

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「データソース・デフォルト」に関する項を参照してください。

タスク7    JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面に示される値が、すべてのスキーマに対して適切であることを確認します。

前の画面でRCUデータの取得を選択しているため、スキーマ表は移入済のはずです。その結果、構成ウィザードにより、このドメインに必要なすべてのスキーマのデータベース接続値が検出されます。

この時点では、これらの値は単一インスタンスのデータベースに接続するように構成されています。ただし、エンタープライズ・デプロイメントの場合、「エンタープライズ・デプロイメント用のデータベースの準備」の説明のように、可用性の高いReal Application Clusters (RAC)データベースを使用する必要があります。

さらに、各コンポーネント・スキーマでアクティブなGridLinkデータ・ソースを使用することをお薦めします。GridLinkデータ・ソースを使用してRACデータベースに接続する利点の詳細は、高可用性ガイドのデータベースの考慮事項に関する項を参照してください。

データ・ソースをGridLinkに変換する手順は次のとおりです。

1. スキーマ表の最初のヘッダー行にあるチェック・ボックスを選択することですべてのスキーマを選択します。

2. 「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク8    GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、表10-3 と図10-2 に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

表10-3 「GridLink Oracle RACコンポーネント・スキーマ」画面で選択したフィールドの推奨値

要素

説明と推奨値

「SCAN」、「ホスト名」および「ポート」

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSポート」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

「FANの有効化」チェック・ボックスを選択して、FANイベントを受信および処理できるようにします。

図10-2 「GridLink Oracle RACコンポーネント・スキーマ」画面のサンプル値

この画面で情報を指定する方法の詳細および適切なSCANアドレスの特定方法については、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。

また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。

タスク9    JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「コンポーネント・スキーマのテスト」に関する項を参照してください。

タスク10    資格証明の指定

Business Intelligence system.userアカウントの一意の名前ユーザー名とパスワードを入力します。system.userアカウントは実際のユーザーではないことに注意してください。これは、異なるBusiness Intelligenceコンポーネント間での内部認証に使用されます。BIアプリケーションにログインして使用するために実際のシステム・ユーザーが使用していない、一意のランダムなユーザー名とパスワードを指定する必要があります。

jms.queue.authユーザー・アカウントのユーザー名とパスワードを入力します。このユーザーは、WebLogic管理者グループ内のユーザーである必要があります。

タスク11    拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

- 管理サーバー
これは、管理サーバーのリスニング・アドレスを適切に構成するために必要です。

- ノード・マネージャ
これは、ノード・マネージャを構成するために必要です。

- 管理対象サーバー、クラスタおよびCoherence
管理対象サーバーとクラスタを構成し、マシンを構成して管理対象サーバーをマシンにターゲット設定するために必要です。

- JMSファイル・ストア
これは、JMS永続ストア用に適切な共有記憶域を構成するために必要です。

注意:

構成ウィザードの「拡張構成」画面を使用するときは、次のようにします。

- この画面で前述のオプションのいずれかが使用可能でない場合は、「テンプレート」画面に戻り、このトポロジに必要なテンプレートが選択されていることを確認します。

- 「ドメイン・フロントエンド・ホストのキャプチャ」拡張構成オプションを選択しないでください。後で、ドメインに対してではなく特定のクラスタに対してフロントエンド・ホスト・プロパティを構成します。

タスク12    管理サーバーのリスニング・アドレスの構成

「管理サーバー」画面で、次の手順を実行します。

1. 「サーバー名」フィールドで、デフォルト値(「AdminServer」)を維持します。

2. 「リスニング・アドレス」フィールドに、「エンタープライズ・デプロイメント用のリソースの取得」で取得して「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で有効化したADMINVHNのVIPに対応する仮想ホスト名を入力します。
ADMINVHN仮想ホストを使用する理由の詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

3. 他のフィールドでは、デフォルト値をそのまま使用します。
特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。

タスク13    ノード・マネージャの構成

ノード・マネージャ・タイプとして「ドメインごとのデフォルトの場所」を選択し、ノード・マネージャへの接続に使用するノード・マネージャ資格証明を指定します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のノード・マネージャに関する項を参照してください。

ドメインごとおよびホストごとのノード・マネージャの実装の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の複数マシンでのノード・マネージャの構成に関する項を参照してください。

タスク14    管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストにOracle Business Intelligence用の新しい管理対象サーバーが表示されます。このサーバーは、「テンプレート」画面で選択したOracle BIEE Suite構成テンプレートによって自動的に作成されたものです。次のタスクを実行して、デフォルトのOracle Business Intelligence管理対象サーバー(bi_server1)を変更します。

1. デフォルトの管理対象サーバーの名前をWLS_BI1に変更します。

ヒント:

ここで推奨するサーバー名は、このドキュメント全体で使用するため、別の名前を選択する場合は、必要に応じてそれらの名前に置き換えてください。

2. 次の表の情報を使用して、Oracle Business Intelligence管理対象サーバーの残りの列を入力します。

ヒント:

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

表10-4 Oracle Business Intelligence管理対象サーバーに必要な値

サーバー名

リスニング・アドレス

リスニング・ポート

SSLの有効化

SSLリスニング・ポート

サーバー・グループ

WLS_BI1

BIHOST1

7003

不可

無効

BISUITE_MAN-SVR

タスク15    クラスタの構成

このタスクでは、Oracle BIソフトウェアのターゲットとすることができるクラスタを作成します。

また、クラスタの「フロントエンド・ホスト」プロパティも設定することにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上のbi.example.comにリダイレクトするようになります。

bi.example.com仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

「クラスタ」画面で、Oracle Business Intelligenceの新しいクラスタ(bi_cluster)がクラスタのリストに表示されます。次のタスクを実行して、デフォルトのOracle Business Intelligenceクラスタを変更します。

1. 「フロントエンド・ホスト」フィールドでbi.example.comを指定します。

2. 「フロントエンドHTTPポート」に80を指定し、「フロントエンドHTTPSポート」に443を指定します。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストまたはマルチキャストを選択する際の考慮事項に関する項を参照してください。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「クラスタ」に関する項を参照してください。

タスク16    クラスタへの管理対象サーバーの割当

「サーバーのクラスタへの割当」画面を使用して、WLS_BI1を新規クラスタbi_clusterに割り当てます。

1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではbi_cluster)を選択します。

2. 「サーバー」ペインで、次のいずれかの操作を実行してWLS_BI1をbi_clusterに割り当てます。

- WLS_BI1管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。

- WLS_BI1をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

タスク17    Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。

「クラスタ・リスニング・ポート」に9991と入力します。

注意:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報』のOracle Coherenceに関する項を参照してください。

タスク18    マシンの作成

「マシン」画面を使用して、ドメイン内に新しいマシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。

1. 「Unixマシン」タブを選択します。

2. 「追加」ボタンをクリックし、新しいUNIXマシンを作成します。
次の表の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。

3. 「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。
この例に示されているポート番号5556は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。

表10-5 Unixマシンの作成時に使用する値

名前

ノード・マネージャのリスニング・アドレス

ノード・マネージャのリスニング・ポート

BIHOST1

BIHOST1ホスト名変数の値。たとえば、BIHOST1.example.comなどです。

5556

ADMINHOST

ADMINVHN変数の値を入力します。

5556

図10-3 構成ウィザードの「Unixマシン」画面の値の例

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のマシンに関する項を参照してください。

タスク19    マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、管理サーバーとOracle BI EE Suite管理対象サーバーを適切なマシンに割り当てます。

「サーバーのマシンへの割当」画面は、管理対象サーバーのクラスタへの割当て画面に似ています。「マシン」列でターゲット・マシンを選択し、左の列で管理対象サーバーを選択した後、右矢印をクリックしてそのサーバーを適切なマシンに割り当てます。

次のように、サーバーを割り当てます。

- AdminServerをADMINHOSTマシンに割り当てます。

- WLS_BI1管理対象サーバーをBIHOST1マシンに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

タスク20 JMSファイル・ストアの構成

Oracle WSM Policy Manager構成テンプレートを使用してドメインを構成する場合、特にエンタープライズ・デプロイメントを構成しているときには、メタデータ・サービス(MDS)のJMSファイル・ストアの適切な場所を選択する必要があります。

「JMSファイル・ストア」画面で、各BI永続ストアに次のディレクトリを割り当てます。

ASERVER_HOME/bi_cluster

この例では、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOMEをASERVER_HOME変数の実際の値に置き換えます。bi_clusterをOracle BIクラスタに割り当てた名前に置き換えます。

タスク21    構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

ドメイン作成は、「作成」をクリックするまでは開始されません。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク22    ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、ノード・マネージャと管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

10.7 BIHOST1でのシステム・コンポーネントの作成

この項の手順を実行して、BIHOST1にBIクラスタ・コントローラ、BIスケジューラ、BIプレゼンテーション・サービスおよびBI JavaHostシステム・コンポーネントを作成します。

注意:

ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

1. WLSTを起動します。

cd ORACLE_HOME/oracle_common/common/bin/

./wlst.sh

2. 更新用のBI管理サーバー・ドメインを開きます。

wls:/offline>readDomain(‘ASERVER_HOME’)

3. 新しいBIクラスタ・コントローラ・システム・コンポーネントを作成します。

wls:/offline/bi_domain>createOBICCSComponent('ASERVER_HOME','BIHOST1',port='OBICCS__port',portMonitor='OBICCS_monitor_port')

次に例を示します。

wls:/offline/bi_domain>createOBICCSComponent('/u01/oracle/config/domains/bi_domain','BIHOST1',port='10006',portMonitor='10007')

4. 新しいBIスケジューラ・システム・コンポーネントを作成します。

wls:/offline/bi_domain>createOBISCHComponent(‘ASERVER_HOME’,'BIHOST1’,port='OBISCH_port',portMonitor='OBISCH_monitor_port')

次に例を示します。

wls:/offline/bi_domain>createOBISCHComponent(‘/u01/oracle/config/domains/bi_domain','BIHOST1’,port='10008',portMonitor='10009')

5. 新しいBIプレゼンテーション・サービス・システム・コンポーネントを作成します。

wls:/offline/bi_domain>createOBIPSComponent('ASERVER_HOME’,'BIHOST1',port='OBIPS_port')

次に例を示します。

wls:/offline/bi_domain>createOBIPSComponent('/u01/oracle/config/domains/bi_domain’,'BIHOST1',port='10010')

6. 新しいBI JavaHostシステム・コンポーネントを作成します。

wls:/offline/bi_domain>createOBIJHComponent('ASERVER_HOME','BIHOST1',port='OBIJH_port')

次に例を示します。

wls:/offline/bi_domain>createOBIJHComponent('/u01/oracle/config/domains/bi_domain','BIHOST1',port='10011')

7. ドメインを更新して保存します。

wls:/offline/bi_domain/SystemComponent/obijh1>updateDomain()

8. ドメインを閉じます。

wls:/offline/bi_domain/SystemComponent/obijh1>closeDomain()

9. 変更内容をWebLogic Server JDBC接続プールと同期します。これにより、WebLogic Serverの外部に格納された中間層スキーマ・エンドポイント(odbc.iniなど)が更新されます。

wls:/offline>syncMidtierDb(‘ASERVER_HOME’)

10. WLSTを終了します。

wls:/offline>exit()

10.8 BIサービス・インスタンスの作成

この項の手順を実行して、新しいBIサービス・インスタンスを作成します。

注意:

ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

1. WLSTを起動します。

cd ORACLE_HOME/oracle_common/common/bin/

./wlst.sh

2. 更新用のBI管理サーバー・ドメインを開きます。

wls:/offline>readDomain(‘ASERVER_HOME’)

3. 新しいBIサービス・インスタンスを作成するには、次のコマンドを実行します。

wls:/offline/bi_domain>createBIServiceInstance(‘ASERVER_HOME’,‘service1’,owner='weblogic',
description=’Default Service’, bar=’ORACLE_HOME/bi/bifoundation/samples/sampleapplite/SampleAppLite.bar’,
port='OBIS_port', portMonitor='OBIS_monitor_port',machine='BIHOST1')

次に例を示します。

wls:/offline/bi_domain>createBIServiceInstance(‘/u01/oracle/config/domains/bi_domain’,‘service1’,owner='weblogic',
description=’Default Service’, bar=’/u01/oracle/products/fmw/bi/bifoundation/samples/sampleapplite/SampleAppLite.bar’,
port='10020', portMonitor='10021',machine='BIHOST1')

4. ドメインを更新して保存します。

wls:/offline/bi_domain/SystemComponent/obis1>updateDomain()

5. 編集のためにドメインを閉じます。

wls:/offline/bi_domain/SystemComponent/obis1>closeDomain()

6. オプション: 標準URLをBIサービス・インスタンスに使用できるようにするために、デフォルトのキーを構成します。

wls:/offline>f = open('ASERVER_HOME/config/fmwconfig/biconfig/bi-security/config.properties', 'a')
wls:/offline>f.write ("defaultServiceInstanceKey=" + 'service1')
wls:/offline>f.close()

7. SampleAppLiteでXMLデータを使用するため、XMLデータを適切な場所に解凍する必要があります。

import os
import zipfile
def unzip(srcZip, destDir):
# no native unzip-to-dest in jython 2.2 :-(
z = zipfile.ZipFile(srcZip)
if not destDir.endswith('/'):
destDir += '/'
if not os.path.exists(destDir):
os.makedirs(destDir)
for f in z.namelist():
outpath = destDir + f
if f.endswith('/'):
os.makedirs(outpath)
else:
outfile = open(outpath, 'wb')
outfile.write(z.read(f))
outfile.close()

wls:/offline>srcZip='ORACLE_HOME/bi/bifoundation/samples/sampleapplite/SampleAppLite-datafiles.zip'
wls:/offline>destDir='ASERVER_HOME/bidata/service_instances/service1/data'
wls:/offline>unzip(srcZip,destDir)

8. WLSTを終了します。

exit()

10.9 シングルトン・データ・ディレクトリ(SDD)の構成

Oracle Business Intelligenceメタデータは、シングルトン・データ・ディレクトリ(SDD)に格納されています。メタデータは、プレゼンテーション・カタログ、メタデータ・リポジトリおよびセキュリティ認証に関する情報を含むOracle Business Intelligenceアーカイブ(BAR)ファイルで管理されます。

次の手順を実行して、シングルトン・データ・ディレクトリに共有ディレクトリを設定します。

注意:
シングルトン・データ・ディレクトリ(SDD)へのパスは、ASERVER_HOME/config/fmwconfig/bienv/core/bi-environment.xmlファイルに定義されています。

1. シングルトン・データ・ディレクトリ(SDD)の共有ディレクトリを作成します。

次に例を示します。

mkdir Shared_Storage_Location/biconfig

2. ASERVER_HOME/bidataディレクトリ内のデータを作成した共有ディレクトリに移動します。

mv ASERVER_HOME/bidata Shared_Storage_Location/biconfig

3. 次のようにして、bi-environment.xmlファイル内のシングルトン・データ・ディレクトリの場所を更新します。

a. 編集のために、ASERVER_HOME/config/fmwconfig/bienv/core/bi-environment.xmlファイルを開きます。

b. ファイルを編集して、シングルトン・データ・ディレクトリの場所をデフォルトの$DOMAIN_HOME/bidataディレクトリから共有bidataディレクトリの絶対パスに変更します。

次に例を示します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bi:environment xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bi="http://bi.oracle.com/lcm">
<bi:logoff-url></bi:logoff-url>
<bi:singleton-data-directory>Shared_Storage_Location/biconfig/bidata</bi:singleton-data-directory>
<bi:services-domain-name-suffix>bi.outsourcing.com</bi:services-domain-name-suffix>
</bi:environment>

4. ファイルを保存して閉じます。

10.10 Oracle Business IntelligenceでのEssbaseのセキュリティの構成

Oracle Business Intelligenceインストーラを使用してインストールされたEssbaseコンポーネントは、ネイティブEssbaseまたはHyperion Shared Services (HSS)セキュリティを使用できません。

ただし、EssbaseをOracle Business Intelligenceでインストールすると、Common Security Service (CSS)トークン・ベースのアイデンティティ・アサーションを引き続き使用でき、Oracle Business Intelligenceを使用して、エンド・ユーザーの資格証明でEssbaseデータ・ソースに(Oracle Business IntelligenceでインストールしたEssbaseにもEnterprise Performance Management (EPM)でインストールしたEssbaseにも)接続できます。このメカニズムをOracle Business Intelligenceのインストールの外部のEssbaseデータソースで使用するには、ドキュメントの指示に従う必要があります。また、Oracle Business IntelligenceでEssbaseの複数のデータソースを使用し、このメカニズムを使用する必要がある場合は、すべてのEssbaseデータソースで同じ共有シークレットを使用してCSSトークンを作成する必要があります。

詳細は、『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business IntelligenceでEssbase、Hyperion Financial ManagementおよびHyperion Planningとの通信時にHyperion SSOトークンを使用する構成に関する項を参照してください。

EssbaseコンポーネントについてCommon Security Service (CSS)セキュリティを構成するには、初期BIドメインを作成後、ドメインを起動する前に、次を実行する必要があります。

cd ASERVER_HOME/bitools/bin
./generate_css_secrets.sh

10.11 ドメイン・ディレクトリの構成とBIHOST1上のサーバーの起動

ドメインの作成後、BIHOST1で一連の追加構成タスクを実行する必要があります。たとえば、ノード・マネージャおよび管理サーバーを起動します。その後、管理対象サーバーの個別ドメイン・ディレクトリを作成します。この新しい個別の管理対象サーバー・ディレクトリで、2番目のノード・マネージャ・インスタンスを起動し、管理対象サーバーおよびBusiness Intelligenceシステム・コンポーネントを起動します。

- BIHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動
これらの手順を使用して、ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動します。

- boot.propertiesファイルの作成
ノード・マネージャ資格証明を入力せずにノード・マネージャを起動する場合、boot.propertiesを作成する必要があります。この手順は、エンタープライズ・デプロイメントでは必須です。このファイルに入力した資格証明は、管理サーバーを起動すると暗号化されます。

- 管理サーバーの起動
これらの手順を使用して、ノード・マネージャを通じて管理サーバーを起動します。

- 管理サーバーの検証
構成手順を続行する前に、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認して、管理サーバーが正常に起動されたことを検証します。

- Derbyデータベースの無効化

- BIHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成
最初にエンタープライズ・デプロイメント用のドメインを作成すると、そのドメイン・ディレクトリは共有ディスク上に配置されます。このデフォルトのドメイン・ディレクトリは、管理サーバーを実行するために使用されます。これで、BIHOST1とBIHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。

- BIHOST1上の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

- BIHOST1でのWLS_BI1管理対象サーバーの起動
Oracle Enterprise Manager Fusion Middleware Controlを使用して、BIHOST1上の管理対象サーバーを起動します。

- システム・コンポーネントの起動
Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Business Intelligenceのシステム・コンポーネントを起動します。

10.11.1 BIHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動

これらの手順を使用して、ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動します。

1. nodemanager.propertiesファイルでリスニング・アドレスが正しく設定されていることを確認します。

a. テキスト・エディタを使用して、次のファイルを開きます。

ASERVER_HOME/nodemanager/nodemanager.properties

b. ListenAddressプロパティが、ADMINVHN仮想IPアドレスの値に設定されていることを確認します。

2. 次のディレクトリに移動します。

ASERVER_HOME/bin

3. 次のコマンドを使用してノード・マネージャを起動します。

nohup ./startNodeManager.sh > ASERVER_HOME/nodemanager/nodemanager.out 2>&1 &

ノード・マネージャの追加の構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

10.11.2 boot.propertiesファイルの作成

ノード・マネージャ資格証明を入力せずにノード・マネージャを起動する場合、boot.propertiesを作成する必要があります。この手順は、エンタープライズ・デプロイメントでは必須です。このファイルに入力した資格証明は、管理サーバーを起動すると暗号化されます。

管理サーバーのboot.propertiesファイルを作成する手順は次のとおりです。

1. 次のようなディレクトリ構造を作成します。

mkdir -p ASERVER_HOME/servers/AdminServer/security

2. テキスト・エディタで、前述の手順で作成したsecurityディレクトリにboot.propertiesというファイルを作成し、構成ウィザードを実行してドメインを作成したときに定義した、次の管理サーバー資格証明を入力します。

username=adminuser
password=password

注意:

管理サーバーを起動すると、ファイル内のusernameとpasswordのエントリは暗号化されます。

セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を短くします。ファイルを編集した後、できるかぎり速やかにサーバーを起動し、エントリを暗号化してください。

3. ファイルを保存してエディタを閉じます。

10.11.3 管理サーバーの起動

これらの手順を使用して、ノード・マネージャを通じて管理サーバーを起動します。

1. WLSTを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

2. 構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します。

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'ASERVER_HOME')

注意:

このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

ASERVER_HOME/config/nodemanager

3. 管理サーバーを起動します。

nmStart('AdminServer')

4. WLSTを終了します。

exit()

10.11.4 管理サーバーの検証

構成手順を続行する前に、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認して、管理サーバーが正常に起動されたことを検証します。

Fusion Middleware Controlに移動するには、次のURLを入力し、Oracle WebLogic Server管理者の資格証明を使用してログインします。

ADMINVHN:7001/em

Oracle WebLogic Server管理コンソールに移動するには、次のURLを入力し、同じ管理者資格証明を使用してログインします。

ADMINVHN:7001/console

10.11.5 Derbyデータベースの無効化

管理対象サーバー・ディレクトリを作成して管理対象サーバーを起動する前に、埋込みのDerbyデータベース(Oracle WebLogic Serverにパッケージされているファイルベースのデータベース)を無効化してください。Derbyデータベースは、主に開発環境で使用します。そのため、本番対応のエンタープライズ・デプロイメント環境を構成する場合にはそれを無効化する必要があります(そうしないと、管理対象サーバーの起動時にDerbyデータベース・プロセスが自動的に起動されます)。

Derbyデータベースを無効化する手順は次のとおりです。

1. Oracleホームの次のディレクトリに移動します。
WL_HOME/common/derby/lib

2. Derberライブラリのjarファイル名を変更します。
mv derby.jar disable_derby.jar

10.11.6 BIHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成

最初にエンタープライズ・デプロイメント用のドメインを作成すると、そのドメイン・ディレクトリは共有ディスク上に配置されます。このデフォルトのドメイン・ディレクトリは、管理サーバーを実行するために使用されます。これで、BIHOST1とBIHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。

サーバーが共有記憶域にログを書き込むことによって発生する潜在的な競合とオーバーヘッドを排除するために、MSERVER_HOMEをローカル記憶域に配置することをお薦めします。また、必要なクラスおよびjarをドメイン・ディレクトリからロードするほうが高速であるため、管理対象サーバーがドメイン・ディレクトリから使用するtmpまたはキャッシュのデータのほうがより迅速に処理されます。

「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のように、管理サーバー・ドメイン・ホームのパスはASERVER_HOME変数によって表され、管理対象サーバー・ドメイン・ホームのパスはMSERVER_HOME変数によって表されます。

管理対象サーバーのドメイン・ディレクトリを作成する手順は次のとおりです。

1. BIHOST1にログインし、次のようにpackコマンドを実行してテンプレートを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=complete_path/bidomaintemplate.jar
-template_name=bi_domain_template

この例の説明は、次のとおりです。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- complete_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスで置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。

- bidomaintemplate.jarは作成するJARファイルのサンプル名であり、これにはドメイン構成ファイルが含まれます。

- bi_domain_templateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

2. packコマンドで作成したばかりのbidomaintemplate.jarファイルの場所を書き留めます。

packコマンドへの-template引数の一部として、テンプレートjarファイルのフルパスを指定する必要があります。

ORACLE_COMMON_HOME/common/bin/

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

3. まだ作成していない場合は、BIHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
-overwrite_domain=true \
-template=complete_path/bidomaintemplate.jar \
-log_priority=DEBUG \
-log=/tmp/unpack.log \
-app_dir=APPLICATION_HOME \

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

また、ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shというファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うよう構成できます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

この例の説明は、次のとおりです。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- complete_pathを、テンプレートjarファイルを作成またはコピーした場所の完全なパスで置き換えます。

- bidomaintemplate.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートjarファイルの名前です。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

5. ディレクトリを、新しく作成した管理対象サーバー・ディレクトリに変更して、ドメイン構成ファイルがBIHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

10.11.7 BIHOST1上の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

管理対象サーバーのドメイン・ディレクトリを作成した後は、BIHOST1に2つのドメイン・ホーム・ディレクトリとそれに対応する2つのノード・マネージャ・インスタンスが存在します。1つのノード・マネージャを使用して、管理サーバー・ドメイン・ホームから実行される管理サーバーを制御し、もう1つのノード・マネージャを使用して、管理対象サーバー・ドメイン・ホームから実行される管理対象サーバーを制御します。

2つのノード・マネージャを別々に起動する必要があります。

次の手順に従って、管理対象サーバー・ホームからノード・マネージャを起動します。

1. 次のディレクトリに移動します。
MSERVER_HOME/bin

2. 次のコマンドを使用してノード・マネージャを起動します。

nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &

追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

10.11.8 BIHOST1でのWLS_BI1管理対象サーバーの起動

Oracle Enterprise Manager Fusion Middleware Controlを使用して、BIHOST1上の管理対象サーバーを起動します。

前述の手順でノード・マネージャと管理サーバーをすでに起動しているため、Fusion Middleware Controlは使用可能な状態です。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

この例の説明は、次のとおりです。

- ADMINVHNをADMINVHN仮想IPアドレスに割り当てられているホスト名に置き換えます。

- ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

ヒント:

Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle Fusion Middlewareの管理の詳細は、『Oracle Fusion Middlewareの管理』のOracle Enterprise Manager Fusion Middleware Controlの使用の開始に関する項を参照してください。

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「サーバー」ペインを選択して、ドメイン内の管理対象サーバーを表示します。

4. WLS_BI1管理対象サーバーのみを選択して、ツールバーの「制御」をクリックします。次に、「制御」の下で「起動」を選択します。

10.11.9 システム・コンポーネントの起動

Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Business Intelligenceのシステム・コンポーネントを起動します。

前述の手順でノード・マネージャと管理サーバーをすでに起動しているため、Fusion Middleware Controlはすでに使用可能な状態です。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「ターゲット・ナビゲーション」ペインがまだ表示されていない場合は、ページの左上隅にある「ターゲット・ナビゲーション」アイコンをクリックして表示します。

4. 「ターゲット・ナビゲーション」ペインで「Business Intelligence」フォルダを展開し、「biinstance」を選択します。

Business Intelligenceの「概要」ページが表示されます。

5. 「可用性」、「プロセス」の順にクリックして、「可用性」ページの「プロセス」タブを表示します。

6. 「すべてを起動」をクリックして、すべてのコンポーネントを起動します。 to start all the components.

10.12 グローバル・キャッシュの設定

グローバル・キャッシュとは、クラスタに参加しているすべてのOracle BIサーバーが共有する問合せキャッシュです。クラスタに参加しているすべてのOracle BIサーバーでキャッシュのシーディング・イベントおよびパージ・イベントを共有するようにグローバル・キャッシュを構成することをお薦めします。

グローバル・キャッシュの詳細は、『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のグローバル・キャッシュに関する項を参照してください。

グローバル・キャッシュを設定するには:

1. グローバル・キャッシュの共有ディレクトリを作成します。

mkdir Shared_Storage_Location/global_cache

すべてのOracle BIサーバーには、このディレクトリに対する読取りおよび書込みアクセスが必要です。

2. Fusion Middleware Controlの「構成」ページの「パフォーマンス」タブを使用して、「グローバル・キャッシュ・パス」および「グローバル・キャッシュ・サイズ」を設定します。

a. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

b. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

c. 「ターゲット・ナビゲーション」ペインがまだ表示されていない場合は、ページの左上隅にある「ターゲット・ナビゲーション」アイコンをクリックして表示します。

d. 「ターゲット・ナビゲーション」ペインで「Business Intelligence」フォルダを展開し、「biinstance」を選択します。

Business Intelligenceの「概要」ページが表示されます。

e. 「構成」をクリックしてから「パフォーマンス」をクリックし、「構成」ページの「パフォーマンス」タブを表示します。

f. ページの右上隅にある「チェンジ・センター」メニューで「ロックして編集」をクリックします。

g. 「グローバル・キャッシュ・パス」フィールドに、パージおよびシーディングの各キャッシュ・エントリを格納するために作成した共有ディレクトリを指定します。「グローバル・キャッシュ・サイズ」に値を入力し、グローバル・キャッシュの最大サイズ(たとえば250MB)を指定します。

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

i. ページの右上隅にある「チェンジ・センター」メニューで、「変更のアクティブ化」をクリックします。

10.13 BIHOST1でのOracle Business Intelligence URLの確認

BIHOST1でドメインのコンポーネントを起動した後、これらのURLにアクセスして、Oracle Business Intelligenceの構成を確認します。

- 次のURLにアクセスして、WLS_BI1のステータスを確認します。

http://BIHOST1VHN1:7003/analytics

次にリダイレクトされます。

http://bi.example.com/analytics

- 次のURLにアクセスして、BI Publisherアプリケーションのステータスを確認します。

http://BIHOST1VHN1:7003/xmlpserver

次にリダイレクトされます。

http://bi.example.com/xmlpserver

- 次のURLにアクセスして、Oracle Essbaseアプリケーションのステータスを確認します。

http://BIHOST1VHN1:7003/aps/Essbase

10.14 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング

Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

次のトピックでは、Oracle WebLogic Server管理コンソールを使用してエンタープライズ・デプロイメント・ドメイン用の新しい認証プロバイダを作成する方法について説明します。この手順では、サポートされているLDAPディレクトリ(Oracle Unified DirectoryやOracle Internet Directoryなど)をすでにインストールおよび構成していることを想定しています。

- サポートされている認証プロバイダについて

- エンタープライズ・デプロイメント・ユーザーおよびグループについて

- 新しい認証プロバイダの作成とユーザーおよびグループのプロビジョニングの前提条件

- LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

- 新しい認証プロバイダの作成

- エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

- 管理グループへの新しい管理ユーザーの追加

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

10.14.1 サポートされている認証プロバイダについて

Oracle Fusion Middlewareでは、様々なLDAP認証プロバイダをサポートしています。詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・タイプおよびWebLogicオーセンティケータに関する項を参照してください。

このガイドの手順では、次のいずれかのプロバイダを使用していることを想定しています。

- Oracle Unified Directory

- Oracle Internet Directory

- Oracle Virtual Directory

注意:

ここに示す手順では、デフォルトで単一のLDAPアイデンティティ・ストアに対する問合せをサポートするようにアイデンティティ・サービス・インスタンスを構成する方法を説明します。

ただし、LibOVDを使用して、複数のLDAPアイデンティティ・ストアに問合せを行う仮想アイデンティティ・ストアをサポートするようにサービスを構成できます。

複数LDAP参照に関する詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・サービスの構成に関する項を参照してください。

10.14.2 エンタープライズ・デプロイメント・ユーザーおよびグループについて

次のトピックでは、エンタープライズ・デプロイメント管理ユーザーおよび管理グループの用途と特性に関する重要な情報を提供します。

- 各ドメインで一意の管理ユーザーの使用について

- ドメイン・コネクタ・ユーザーについて

- 中央LDAPディレクトリへのユーザーの追加について

- Oracle Business Intelligenceの製品固有のロールとグループについて

- このガイドで使用するサンプル・ユーザーとサンプル・ロール

10.14.2.1 各ドメインで一意の管理ユーザーの使用について

集中LDAPユーザー・ストアを使用すると、複数のOracle WebLogic Serverドメインで使用するユーザーおよびグループをプロビジョニングできます。その結果、あるWebLogic管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。

このようなアプローチはお薦めしません。かわりに、Oracle Fusion Middlewareドメインの管理用にプロビジョニングするユーザーおよびグループにディレクトリ・ツリー内で一意の識別名(DN)を割り当てる方法をお薦めします。

たとえば、Oracle Business Intelligenceエンタープライズ・デプロイメント・ドメインをインストールおよび構成する場合は、weblogic_biというユーザーとBI Administratorsという管理グループを作成します。

10.14.2.2 ドメイン・コネクタ・ユーザーについて

LDAPディレクトリに、個別のドメイン・コネクタ・ユーザー(biLDAPなど)を作成することをお薦めします。このユーザーを使用すると、ユーザー認証の目的でドメインからLDAPディレクトリに接続できます。これは管理ユーザー以外のユーザーにすることをお薦めします。

標準的なOracle Identity and Access Managementデプロイメントで、このユーザーをsystemidsコンテナに作成します。このコンテナは、通常はユーザーに表示されないシステム・ユーザーに使用されます。このユーザーをsystemidsコンテナに配置することで、Oracle Identity Managerを所有する顧客がこのユーザーをリコンサイルしないようにします。

10.14.2.3 中央LDAPディレクトリへのユーザーの追加について

中央LDAPディレクトリをエンタープライズ・ドメインのオーセンティケータとなるよう構成した後、すべての新しいユーザーをデフォルトのWebLogic Serverオーセンティケータではなく、新しいオーセンティケータに追加する必要があります。

中央LDAPディレクトリに新しいユーザーを追加する場合、WebLogic管理コンソールを使用することはできません。かわりに、ldapbrowserやJXplorerなどの適切なLDAP変更ツールを使用する必要があります。

複数のオーセンティケータ(エンタープライズ・デプロイメントの要件)を使用している場合、ログインおよび認証は機能しますが、ロールの取得は機能しません。ロールは第1オーセンティケータからのみ取得されます。その他のオーセンティケータを使用してロールを取得する場合は、ドメインの仮想化を有効にする必要があります。

仮想化の有効化には、次の手順が含まれます。

1. 次の構成ファイルを探してテキスト・エディタで開きます。

DOMAIN_HOME/config/fmwconfig/jps-config.xml

2. 次のように、プロパティを追加または更新します。

<property name="virtualize" value="true"/>

virtualizeプロパティの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のOPSSシステム・プロパティと構成プロパティに関する項を参照してください。

10.14.2.4 Oracle Business Intelligenceの製品固有のロールとグループについて

各Oracle Fusion Middleware製品では、管理および監視のために独自の事前定義済ロールおよびグループが実装されます。

その結果、ドメインを拡張して他の製品を追加するときに、これらの製品固有のロールをBI Administratorsグループに追加できます。これらがBI Administratorsグループに追加されると、各製品管理者ユーザーは管理タスクを実行するための同じ権限セットを使用してドメインを管理できます。

BI Administratorsグループに他のロールを追加する手順は、「エンタープライズ・デプロイメントの共通の構成および管理タスク」を参照してください。

10.14.2.5 このガイドで使用するサンプル・ユーザーとサンプル・ロール

このガイドで使用するサンプルでは、下に示すDNを持つ次の管理ユーザーおよび管理グループをプロビジョニングすることを想定しています。

- 管理ユーザーのDN:

cn=weblogic_bi,cn=users,dc=example,dc=com

- 管理グループのDN:

cn=BI Administrators,cn=groups,dc=example,dc=com

- 製品固有のLDAPコネクタ・ユーザー:

cn=biLDAP,cn=systemids,dc=example,dc=com
これは、WebLogic管理対象サーバーをLDAP認証プロバイダに接続する際に使用するユーザーです。このユーザーには、ディレクトリ・ツリーに対する読取りおよび書込み権限が必要です。

cn=users,dc=example,dc=com
cn=groups,dc=example,dc=com

注意:

Oracle Unified Directoryを使用する場合、読取りおよび書込みアクセスを提供するため、このユーザーに次のグループのメンバーシップを付与する必要があります。

cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAGroupWritePrivilegeGroup,cn=groups,dc=example,dc=com

10.14.3 新しい認証プロバイダの作成とユーザーおよびグループのプロビジョニングの前提条件

新しいLDAP認証プロバイダを作成する前に、関連する構成ファイルをバックアップします。

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

さらに、次のディレクトリにある管理サーバーのboot.propertiesファイルをバックアップする必要があります。

DOMAIN_HOME/servers/AdminServer/security

10.14.4 LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

この例では、biLDAPというユーザーを中央LDAPディレクトリに作成する方法を示します。

LDAPプロバイダでユーザーをプロビジョニングする手順は次のとおりです。

1. 次に示す内容のdomain_user.ldifという名前のldifファイルを作成して保存します。

dn: cn=biLDAP,cn=systemids,dc=example,dc=com
changetype: add
orclsamaccountname: biLDAP
userpassword: password
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: biLDAP@example.com
givenname: biLDAP
sn: biLDAP
cn: biLDAP
uid: biLDAP

注意:

Oracle Unified Directoryを使用する場合、適切な読取り/書込み権限を付与するため、LDIFファイルの最後に次の4つのグループ・メンバーシップを追加してください。

dn:
cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=us,dc=oracle,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=biLDAP,cn=systemids,dc=us,dc=oracle,dc=com

dn: cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=us,dc=oracle,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=biLDAP,cn=systemids,dc=us,dc=oracle,dc=com

dn: cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=biLDAP,cn=systemids,dc=example,dc=com

dn: cn=orclFAGroupWritePrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=biLDAP,cn=systemids,dc=example,dc=com

2. LDAPディレクトリでユーザーをプロビジョニングします。
たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。

OUD_INSTANCE_HOME/bin/ldapmodify -a \
-h oudhost.example.com
-D "cn=oudadmin" \
-w password \
-p 1389 \
-f domain_user.ldif

Oracle Internet Directoryの場合:

OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \
-p 3060 \
-D cn="orcladmin" \
-w password \
-c \
-v \
-f domain_user.ldif

10.14.5 新しい認証プロバイダの作成

新しいLDAPベースの認証プロバイダを構成する手順は次のとおりです。

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

2. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

3. myrealmというデフォルト・レルム・エントリをクリックします。

4. 「プロバイダ」タブをクリックします。
このレルムに対してDefaultAuthenticatorというプロバイダが構成されていることに注目してください。これは、デフォルトのWebLogic Server認証プロバイダです。

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

6. 「認証プロバイダ」表の下の「新規」ボタンをクリックします。

7. プロバイダの名前を入力します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかの名前を使用します。

- OUDAuthenticator (Oracle Unified Directoryの場合)

- OIDAuthenticator (Oracle Internet Directoryの場合)

- OVDAuthenticator (Oracle Virtual Directoryの場合)

8. 「タイプ」ドロップダウン・リストでオーセンティケータ・タイプを選択します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかのタイプを選択します。

- OracleUnifiedDirectoryAuthenticator (Oracle Unified Directoryの場合)

- OracleInternetDirectoryAuthenticator (Oracle Internet Directoryの場合)

- OracleVirtualDirectoryAuthenticator (Oracle Virtual Directoryの場合)

9. 「OK」をクリックして「プロバイダ」画面に戻ります。

10. 「プロバイダ」画面の表で、新しく作成したオーセンティケータをクリックします。

11. 「制御フラグ」ドロップダウン・メニューで「SUFFICIENT」を選択します。

制御フラグを「SUFFICIENT」に設定すると、そのオーセンティケータがユーザーを正常に認証できる場合はその認証を受け入れ、それ以上のオーセンティケータを起動しません。

認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。以降のすべてのオーセンティケータの制御フラグも「SUFFICIENT」に設定されていることを確認してください。特にDefaultAuthenticatorをチェックして、その制御フラグが「SUFFICIENT」に設定されていることを確認します。

12. 「保存」をクリックして制御フラグの設定を保存します。

13. 「プロバイダ固有」タブをクリックし、次の表に示すように、使用するLDAPサーバーに固有の詳細を入力します。
この手順では、必須フィールドのみを説明しています。このページのすべてのフィールドの詳細は、次のリソースを参照してください。

- 各フィールドの説明を表示するには、「プロバイダ固有」タブの「ヘルプ」をクリックします。

- 「ユーザー・ベースDN」、「名前指定によるユーザー・フィルタ」および「ユーザー属性」の各フィールドの設定の詳細は、『Oracle WebLogic Serverセキュリティの管理』のOracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成に関する項を参照してください。

パラメータ

サンプル値

値の説明

ホスト

例: oud.example.com

LDAPサーバーのサーバーID。

ポート

例: 1689

LDAPサーバーのポート番号。

プリンシパル

例: cn=biLDAP, cn=systemids,dc=example,dc=com

LDAPサーバーへの接続に使用されるLDAPユーザーのDN。

資格証明

LDAPパスワードを入力します。

LDAPサーバーへの接続に使用されるパスワード。

SSLの有効化

未チェック(クリア)

LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。

ユーザー・ベースDN

例: cn=users,dc=example,dc=com

ユーザーが開始時に使用するDNを指定します。

すべてのユーザーのフィルタ

(&(uid=*)(objectclass=person))

「すべてのユーザーのフィルタ」のデフォルトの検索基準のかわりに、uid値に基づいてすべてのユーザーを検索します。

LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がuid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」フィールドで、そのタイプを変更します。

たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。

(&(cn=*)(objectclass=person)))

名前指定によるユーザー・フィルタ

次に例を示します。

(&(uid=%u)(objectclass=person))

LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がuid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」の設定で、そのタイプを変更します。

たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。

(&(cn=%u)(objectclass=person)))

ユーザー名属性

例: uid

グループの名前を指定するLDAPユーザー・オブジェクトの属性。

グループ・ベースDN

例: cn=groups,dc=example,dc=com

グループ・ノードを指すDNを指定します。

取得したユーザー名をプリンシパルとして使用する

チェック済

オンにする必要があります。

GUID属性

entryuuid

OUDにOracleUnifiedDirectoryAuthenticatorが使用されている場合、この値にはentryuuidが事前に移入されています。認証プロバイダとしてOracle Unified Directoryを使用している場合は、この値を確認します。

14. 「保存」をクリックして変更を保存します。

15. 右のナビゲーション・ペインで「セキュリティ・レルム」をクリックして、デフォルトのレルム名(myrealm)をクリックし、「プロバイダ」をクリックして「プロバイダ」ページに戻ります。

16. 「並替え」をクリックし、表示されたページを使用して、作成したプロバイダを認証プロバイダのリストの先頭に配置します。

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

18. チェンジ・センターで、変更のアクティブ化 をクリックします。

19. 管理サーバーとすべての管理対象サーバーを再起動します。
管理対象サーバーを停止するには、Fusion Middleware Controlにログインし、ターゲットのナビゲータで管理対象サーバーを選択して、ツールバーで「停止」をクリックします。

ノード・マネージャを使用して管理サーバーを停止および起動する手順は次のとおりです。

a. WLSTを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

b. 構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します。

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'ASERVER_HOME')

c. 管理サーバーを停止します。

nmKill('AdminServer')

d. 管理サーバーを起動します。

nmStart('AdminServer')

e. WLSTを終了します。

exit()

管理対象サーバーを起動するには、Fusion Middleware Controlにログインし、管理対象サーバーを選択して、ツールバーで「起動」をクリックします。

20. 再起動後に、次のログ・ファイルの内容を確認します。

ASERVER_HOME/servers/AdminServer/logs/AdminServer.log

LDAP接続エラーが発生していないことを確認します。たとえば、次のようなエラーを探します。

The LDAP authentication provider named "OUDAuthenticator" failed to make connection to ldap server at ...

ログ・ファイルでこのようなエラーが見つかった場合は、認可プロバイダ接続の詳細をチェックして、それらが適切であることを確認し、管理サーバーの保存と再起動をもう一度試みます。

21. 再起動後、LDAP接続エラーがログ・ファイルに記述されていないことを確認し、LDAPプロバイダ内に存在するユーザーとグループの参照を試みます。
管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ユーザーとグループ」ページに移動します。LDAPプロバイダ構造内に存在するすべてのユーザーおよびグループを表示できるようになります。

10.14.6 エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

この例では、weblogic_biというユーザーとBI Administratorsというグループを作成する方法を示します。

LDAPプロバイダで管理ユーザーおよび管理グループをプロビジョニングする手順は次のとおりです。

1. 次に示す内容のadmin_user.ldifという名前のldifファイルを作成して保存します。

dn: cn=weblogic_bi,cn=users,dc=example,dc=com
changetype: add
orclsamaccountname: weblogic_bi
userpassword: password
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: weblogic_bi@example.com
givenname: weblogic_bi
sn: weblogic_bi
cn: weblogic_bi
uid: weblogic_bi

2. LDAPディレクトリでユーザーをプロビジョニングします。
たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。

OUD_INSTANCE_HOME/bin/ldapmodify -a \
-h oudhost.example.com
-D "cn=oudadmin" \
-w password \
-p 1389 \
-f admin_user.ldif

Oracle Internet Directoryの場合:

OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \
-p 3060 \
-D cn="orcladmin" \
-w password \
-c \
-v \
-f admin_user.ldif

3. admin_group.ldifという名前のldifファイルを作成して、次の内容を入力してからこのファイルを保存します。

dn: cn=WCCAdministrators,cn=Groups,dc=example,dc=com
displayname: WCCAdministrators
objectclass: top
objectclass: WCCAdministrators
objectclass: orclGroup
uniquemember: cn=weblogic_wcc,cn=users,dc=example,dc=com
cn: WCCAdministrators
description: Administrators Group for the Oracle WebCenter Content Domain

4. LDAPディレクトリでグループをプロビジョニングします。
Oracle Unified Directoryの場合:

OUD_INSTANCE_HOME/bin/ldapmodify -a \
-D "cn=oudadmin" \
-h oudhost.example.com \
-w password \
-p 3060 \
-f admin_group.ldif

Oracle Internet Directoryの場合:

OID_ORACLE_HOME/bin/ldapadd -h oid.example.com \
-p 3060 \
-D cn="orcladmin" \
-w password \
-c \
-v \
-f admin_group.ldif

5. 変更が正常に行われたことを確認します。

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

b. コンソールの左ペインで「セキュリティ・レルム」をクリックします。

c. デフォルト・セキュリティ・レルム(myrealm)をクリックします。

d. 「ユーザーとグループ」タブをクリックします。

e. プロビジョニングした管理者ユーザーおよびグループがページに表示されていることを確認します。

10.14.7 管理グループへの新しい管理ユーザーの追加

Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内でそのグループに管理ロールを割り当てる必要があります。これにより、このグループに属するすべてのユーザーがそのドメインの管理者になることができます。

管理ロールを新しいエンタープライズ・デプロイメント管理グループに割り当てる手順は次のとおりです。

1. 構成ウィザードで指定した管理資格証明を使用してWebLogic管理サーバー・コンソールにログインします。

作成して新しい認証プロバイダに提供した管理ユーザーの資格証明は使用しないでください。

2. 管理コンソールの左ペインで、「セキュリティ・レルム」をクリックします。

3. デフォルト・セキュリティ・レルム(myrealm)をクリックします。

4. 「ロールとポリシー」タブをクリックします。

5. 表の「グローバル・ロール」エントリを開き、「ロール」をクリックします。

6. 「管理」ロールをクリックします。

7. 「条件の追加」ボタンをクリックします。

8. 「述部リスト」ドロップダウン・メニューで「グループ」を選択し、「次へ」をクリックします。

9. 「グループ引数名」フィールドにBI Administratorsと入力して、「追加」をクリックします。

引数のリスト・ボックスにBI Administratorsが追加されます。

10. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。

これで、BI Administratorsグループがリストされるようになりました。

11. 「保存」をクリックすると、BI Administratorsグループに管理ロールを追加する処理が終了します。

12. 新しいweblogic_biユーザー資格証明を使用してWebLogic管理サーバー・コンソールにログインし、変更されたことを確認します。

新しい認証プロバイダでプロビジョニングした新しい管理ユーザーの資格証明を使用してOracle WebLogic Server管理コンソールとFusion Middleware Controlにログインできる場合は、プロバイダは正常に構成されています。

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

新しい管理ユーザーおよびグループを作成したら、LDAPディレクトリで作成した管理ユーザー資格証明を使用して管理サーバーのboot.propertiesファイルを更新する必要があります。

1. BIHOST1で、次のディレクトリに移動します。

ASERVER_HOME/servers/AdminServer/security

2. 既存のboot.propertiesファイルの名前を変更します。

mv boot.properties boot.properties.backup

3. テキスト・エディタを使用して、セキュリティ・ディレクトリにboot.propertiesというファイルを作成します。

4. 次の行をこのファイルに入力します。

username=weblogic_bi
password=password

5. ファイルを保存します。

6. 管理サーバーを再起動します。

10.15 Oracle Business Intelligence構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

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

この章では、WEBHOST1とWEBHOST2に1つずつ、2つのOracle HTTP Serverインスタンスを含むスタンドアロンのOracle HTTP Serverドメインをインストールおよび構成する方法について説明します。

この章では、Web層の構成およびWeb層ドメインのインストールと構成を行う際に使用される変数について説明します。

- Web層の構成時に使用される変数
この章の作業を実行する場合、この項にリストされているディレクトリ変数を参照します。

- Web層ドメインについて
エンタープライズ・デプロイメントでは、各Oracle HTTP Serverインスタンスは、個別のホストおよびその独自のスタンドアロン・ドメインに構成されます。これにより、実行および管理する必要のある構成とリソース量を最小限に抑えた単純な構成が可能となります。

- WEBHOST1へのOracle HTTP Serverのインストール
次の項では、Oracle HTTP ServerソフトウェアをWeb層にインストールする方法について説明します。

- WEBHOST1でのWeb層ドメインの作成
次の項では、最初のWeb層ホストで新しいOracle HTTP Serverスタンドアロン・ドメインを作成する方法について説明します。

- WEBHOST2でのWeb層ドメインのインストールおよび構成
WEBHOST1でOracle HTTP ServerをインストールしてWeb層ドメインを構成したら、WEBHOST2でも同じタスクを実行する必要があります。

- WEBHOST1およびWEBHOST2でのノード・マネージャおよびOracle HTTP Serverインスタンスの起動
次の項では、WEBHOST1およびWEBHOST2でOracle HTTP Serverインスタンスを起動する方法について説明します。

- アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成
次の項では、Oracle HTTP Server構成ファイルを更新して、Webサーバー・インスタンスによりリクエストがドメイン内のサーバーにルーティングされるようにする方法について説明します。

- 構成のバックアップ
Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

親トピック: エンタープライズ・デプロイメントの構成

11.1 Web層の構成時に使用される変数

この章の作業を実行する場合、この項にリストされているディレクトリ変数を参照します。

いくつかのディレクトリ変数の値は、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されています。

- OHS_ORACLE_HOME

- OHS_DOMAIN_HOME

さらに、次の仮想IP (VIP)アドレスおよびホスト名を参照することになります。

- ADMINVHN

- WEBHOST1

- WEBHOST2

11.2 Web層ドメインについて

エンタープライズ・デプロイメントでは、各Oracle HTTP Serverインスタンスは、個別のホストおよびその独自のスタンドアロン・ドメインに構成されます。これにより、実行および管理する必要のある構成とリソース量を最小限に抑えた単純な構成が可能となります。

Web層のOracle HTTP Serverインスタンスのロールおよび構成の詳細は、「Web層の理解」を参照してください。

11.3 WEBHOST1へのOracle HTTP Serverのインストール

次の項では、Oracle HTTP ServerソフトウェアをWeb層にインストールする方法について説明します。

- WEBHOST1でのインストーラの起動

- Oracle HTTP Serverのインストール画面のナビゲート

- Oracle HTTP Serverインストールの確認

11.3.1 WEBHOST1でのインストーラの起動

インストール・プログラムを起動するには、次の手順を実行します。

1. WEBHOST1にログインします。

2. インストール・プログラムをダウンロードしたディレクトリに移動します。

3. 次のコマンドを入力して、インストール・プログラムを起動します。

./fmw_12.2.1.0.0_ohs_linux64.bin

インストール・プログラムが表示されると、インストールを開始する準備ができています。

11.3.2 Oracle HTTP Serverのインストール画面のナビゲート

次の表は、インストール・プログラムで表示される順序に画面を示しています。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索したり、組織用にすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストール場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

エンタープライズ・デプロイメントのためには、表7-3に示すOHS_ORACLE_HOME変数の値を入力します。

インストール・タイプ

「スタンドアロンHTTPサーバー(WebLogic Serverとは切り離して管理)」を選択します。

このインストール・タイプを使用すると、既存のOracle WebLogic Serverドメインとは切り離してOracle HTTP Serverインスタンスを構成できます。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告またはエラー・メッセージが表示された場合、ホスト・コンピュータおよび必須ソフトウェアが「ホスト・コンピュータのハードウェア要件」および「エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件」に示すシステム要件および動作保証情報を満たしていることを確認してください。

セキュリティ更新

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所有していないか、またはこの手順をスキップする場合、チェック・ボックスの選択を解除し、フォローアップのダイアログ・ボックスで選択を確認します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

11.3.3 Oracle HTTP Serverインストールの確認

Oracle HTTP Serverインストールが正常に完了したことを確認するには、新しいOracleホーム・ディレクトリにインストールされたファイルをリストします。Oracle HTTP Server Oracleホームで、次のディレクトリを確認する必要があります。

bin
cfgtoollogs
crs
css
has
install
inventory
jlib
ldap
lib
network
nls
ohs
OPatch
oracle_common
oracore
oraInst.loc
oui
perl
plsql
plugins
precomp
rdbms
root.sh
slax
sqlplus
srvm
webgate
wlserver
xdk

11.4 WEBHOST1でのWeb層ドメインの作成

次の項では、最初のWeb層ホストで新しいOracle HTTP Serverスタンドアロン・ドメインを作成する方法について説明します。

- WEBHOST1での構成ウィザードの起動

- Web層ドメイン用の構成ウィザード画面のナビゲート

11.4.1 WEBHOST1での構成ウィザードの起動

構成ウィザードを起動するには、次のディレクトリに移動し、次のようにWebLogic Server構成ウィザードを起動します。

cd OHS_ORACLE_HOME/oracle_common/common/bin
./config.sh

11.4.2 Web層ドメイン用の構成ウィザード画面のナビゲート

Web層ホスト上にOracle HTTP Serverインスタンスのスタンドアロン・ドメインを作成することをお薦めします。

次のトピックでは、新しいスタンドアロンOracle HTTP Serverの作成方法について説明します。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「Web層ドメインのJDKの選択。」

- タスク4「システム・コンポーネントの追加」

- タスク5「OHSサーバー画面」

- タスク7「構成仕様の確認およびドメインの構成」

- タスク8「ドメイン・ホームのメモ」

タスク1    ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「新規ドメインの作成」を選択します。

「ドメインの場所」フィールドで、OHS_DOMAIN_HOME変数に割り当てられている値を入力します。

次の点に注意してください。

- 構成ウィザードにより、ここでの指定に従って新しいディレクトリが作成されます。

- WebサーバーにDMZ外部の記憶域デバイスに対する依存関係が発生しないよう、ローカル記憶域にディレクトリを作成します。

注意:

- ドメイン・ホーム・ディレクトリの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のドメイン・ホームの選択に関する項を参照してください。

- この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

- Web層およびDMZの詳細は、「標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解」を参照してください。

- OHS_DOMAIN_HOMEディレクトリ変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

タスク2    構成テンプレートの選択

「テンプレート」画面で、Oracle HTTP Server (スタンドアロン) - 12.2.1.0 [ohs]を選択します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。

タスク3    Web層ドメインのJDKの選択。

Oracle HTTP ServerソフトウェアをインストールしたときにWeb層Oracleホームにインストールされた、Oracle Hotspot JDKを選択します。

タスク4 システム・コンポーネントの追加

「システム・コンポーネント」画面で、1つのOracle HTTP Serverインスタンスを作成します。画面には、デフォルトで1つのインスタンスが定義されています。

1. 「システム・コンポーネント」フィールドに定義されたデフォルトのインスタンス名は、ohs1です。このデフォルト名を使用します。

2. 「コンポーネント・タイプ」フィールドで、「OHS」が選択されていることを確認します。

3. 「再起動間隔秒数」フィールドを使用して、アプリケーションが応答しない場合に、再起動を試行する前に待機する秒数を指定します。

4. 「再起動遅延秒数」フィールドを使用して、再起動を再度試行する前に待機する秒数を指定します。

タスク5    OHSサーバー画面

「OHSサーバー」画面を使用して、ドメイン内のOHSサーバーを構成します。

1. 「システム・コンポーネント」ドロップダウン・メニューから、ohs1を選択します。

2. 「リスニング・アドレス」フィールドにWEBHOST1と入力します。
残りのフィールドはすべて事前に移入されていますが、組織での必要に応じて値を変更できます。この画面のフィールドの詳細は、『構成ウィザードによるWebLogicドメインの作成』のOHSサーバーに関する項を参照してください。

3. 「サーバー名」フィールドで、リスニング・アドレスとリスニング・ポートの値を確認します。
正しくは次のようになります。

WEBHOST1:7777

タスク6    ノード・マネージャの構成

ノード・マネージャのタイプとして「ドメインごとのデフォルトの場所」を選択して、ノード・マネージャ資格証明を指定します。

注意:

この画面におけるオプションの詳細は、『構成ウィザードによるドメインの作成』のノード・マネージャに関する項を参照してください。

ノード・マネージャのタイプの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』でノード・マネージャの概要に関する項を参照してください。

タスク7    構成の仕様の確認とドメインの構成

「構成のサマリー」画面には、拡張しようとする構成情報の詳細が含まれます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

ドメイン作成は、「作成」をクリックするまでは開始されません。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成サマリー」に関する項を参照してください。

タスク8    ドメイン・ホームのメモ

「構成に成功しました」画面に、更新されたドメイン・ホームの場所が表示されます。

ここに表示される情報は、サーバーを起動して管理サーバーにアクセスする際に必要となるため、メモしておいてください。

「終了」をクリックして、構成ウィザードを閉じます。

11.5 WEBHOST2でのWeb層ドメインのインストールおよび構成

WEBHOST1でOracle HTTP ServerをインストールしてWeb層ドメインを構成したら、WEBHOST2でも同じタスクを実行する必要があります。

1. 「WEBHOST1へのOracle HTTP Serverのインストール」の手順を使用して、WEBHOST2にログインし、Oracle HTTP Serverをインストールします。

2. 「WEBHOST1でのWeb層ドメインの作成」の手順を使用して、WEBHOST2上に新しいスタンドアロン・ドメインを構成します。
WEBHOST2上のインスタンスにohs2という名前を使用して、各例におけるWEBHOST1の出現箇所をすべてWEBHOST2に置き換え、ohs1の出現箇所をすべてohs2に置き換えるようにしてください。

11.6 WEBHOST1およびWEBHOST2でのノード・マネージャおよびOracle HTTP Serverインスタンスの起動

次の項では、WEBHOST1およびWEBHOST2でOracle HTTP Serverインスタンスを起動する方法について説明します。

- WEBHOST1およびWEBHOST2でのノード・マネージャの起動

- Oracle HTTP Serverインスタンスの起動

11.6.1 WEBHOST1およびWEBHOST2でのノード・マネージャの起動

Oracle HTTP Serverインスタンスを起動する前に、WEBHOST1およびWEBHOST2でノード・マネージャを起動する必要があります。

1. WEBHOST1にログインし、次のディレクトリに移動します。

OHS_DOMAIN_HOME/bin

2. 出力ファイル例としてnohupおよびnodemanager.outを使用して、次のようにノード・マネージャを起動します。

nohup OHS_DOMAIN_HOME/bin/startNodeManager.sh > OHS_DOMAIN_HOME/nodemanager/nodemanager.out 2>&1 &

3. WEBHOST2にログインし、手順1および2を実行します。

ノード・マネージャの追加の構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

11.6.2 Oracle HTTP Serverインスタンスの起動

Oracle HTTP Serverインスタンスを起動する手順は次のとおりです。

1. WEBHOST1上の次のディレクトリに移動します。

OHS_DOMAIN_HOME/bin

OHS_DOMAIN_HOMEディレクトリの場所の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

2. 次のコマンドを入力します。

./startComponent.sh ohs1

3. プロンプトが表示されたら、ノード・マネージャのパスワードを入力します。

4. 手順1から3までを繰り返して、ohs2インスタンスをWEBHOST2上で起動します。

詳細は、『Oracle HTTP Serverの管理』のOracle HTTP Serverインスタンスの起動に関する項を参照してください。

11.7 アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成

次の項では、Oracle HTTP Server構成ファイルを更新して、Webサーバー・インスタンスによりリクエストがドメイン内のサーバーにルーティングされるようにする方法について説明します。

- エンタープライズ・デプロイメント用のOracle HTTP Server構成について

- 仮想ホスト構成ファイルを追加するためのhttpd.confファイルの変更

- Oracle Business Intelligenceの仮想ホスト構成ファイルの作成

- ロード・バランサでの仮想サーバー構成の検証

- 管理コンソールおよび管理サーバーへのアクセスの検証

- Business IntelligenceコンポーネントへのHTTPアクセスの検証

11.7.1 エンタープライズ・デプロイメント用のOracle HTTP Server構成について

次のトピックでは、エンタープライズ・デプロイメントのOracle HTTP Server構成に必要な変更に関する概要情報を提供します。

- Oracle HTTP Server仮想ホストの目的

- Oracle HTTP Server構成ファイルの推奨構造

11.7.1.1 Oracle HTTP Server仮想ホストの目的

このガイドの参照用トポロジでは、ハードウェア・ロード・バランサで一連の仮想サーバーを定義することが必要になります。Oracle HTTP Serverインスタンスの構成ファイルに<VirtualHost>ディレクティブを追加して、(ロード・バランサ仮想サーバーにマップされた)固有の仮想ホストへのリクエストを認識するようにOracle HTTP Serverを構成できます。

各Oracle HTTP Server仮想ホストについては、ロード・バランサからOracle HTTP Serverインスタンスを経由してOracle WebLogic Serverドメイン内の該当する管理サーバーまたは管理対象サーバーにリクエストをルーティングする特定のURL (またはコンテキスト文字列)のセットを定義します。

11.7.1.2 Oracle HTTP Server構成ファイルの推奨構造

httpd.confファイルに複数の仮想ホスト定義を追加するのではなく、デプロイする製品に必要な各仮想サーバーに対してより小さくより具体的な別個の構成ファイルを作成することをお薦めします。そうすることで、すでに大きなhttpd.confファイルに追加のコンテンツを移入するのを回避できます。また、構成の問題のトラブルシューティングが容易になることがあります。

たとえば、通常のOracle Fusion Middleware Infrastructureドメインでは、admin_vh.confという名前の特定の構成ファイルを追加できます。この構成ファイルには、管理サーバー仮想ホスト(ADMINVHN)の仮想ホスト定義が含まれています。

11.7.2 仮想ホスト構成ファイルを追加するためのhttpd.confファイルの変更

次のタスクを実行して、エンタープライズ・トポロジに必要な追加の仮想ホストのhttpd.confファイルを準備します。

1. WEBHOST1にログインします。

2. ドメイン・ディレクトリで最初のOracle HTTP Serverインスタンス(ohs1)のhttpd.confファイルを見つけます。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/

3. テキスト・エディタでhttpd.confファイルを開いて、次の変更を行います。

a. コメント# Use name-based virtual hostingのすぐ下およびコメント# VirtualHost exampleのすぐ前に、次のようなNameVirtualHostエントリを作成します。

NameVirtualHost WEBHOST1:7777

この例では、WEBHOST1をWEBHOST1変数の値で置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

b. httpd.confにmoduleconfサブディレクトリのすべての*.confファイルをインクルードするINCLUDE文があることを確認します。

IncludeOptional "moduleconf/*.conf"

この文により、各コンポーネントに対して個別に仮想ホスト・ファイルを作成することが可能になり、仮想ホスト定義の更新、維持およびスケール・アウトが容易になります。

4. httpd.confファイルを保存します。

5. WEBHOST2にログインして手順2から4までを実行し、ohs2インスタンスについてhttpd.confファイルを更新します。
WEBHOST2で、WEBHOST1のすべてのインスタンスをWEBHOST2で、ohs1のすべてのインスタンスをohs2で置き換えます。

11.7.3 Oracle Business Intelligenceの仮想ホスト構成ファイルの作成

次の手順を使用して、Oracle HTTP ServerでリクエストがOracle Business Intelligenceサーバーにルーティングされるよう必要な構成ファイルを作成します。

注意:
仮想ホスト構成ファイルを作成する前に、「Oracle HTTP Server仮想ホストの目的」の説明に従って、必ずロード・バランサで仮想サーバーを構成しておいてください。

仮想ホスト構成ファイルを作成する手順は次のとおりです。

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf

2. admin_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost *:7777>
ServerName admin.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</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>

3. biinternal_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost WEBHOST1:7777>
ServerName biinternal.example.com
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

#redirect browser requests that omit document/dir
RedirectMatch 301 /analytics$ /analytics/
RedirectMatch 301 /biservices$ /biservices/
RedirectMatch 301 /analytics-ws$ /analytics-ws/
RedirectMatch 301 /AdminService$ /AdminService/
RedirectMatch 301 /AsyncAdminService$ /AsyncAdminService/
RedirectMatch 301 /wsm-pm$ /wsm-pm/
RedirectMatch 301 /xmlpserver$ /xmlpserver/
RedirectMatch 301 /bisearch$ /bisearch/
RedirectMatch 301 /mapviewer$ /mapviewer/
RedirectMatch 301 /va$ /va/
RedirectMatch 301 /bicomposer$ /bicomposer/
RedirectMatch 301 /mobile$ /mobile/
RedirectMatch 301 /aps$ /aps/
RedirectMatch 301 /bi-security$ /bi-security/
RedirectMatch 301 /workspace$ /workspace/

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

# BIEE Analytics
<Location /analytics>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

<Location /bicontent>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

<Location /mobile>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

<Location /va>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

# MapViewer
<Location /mapviewer>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

# BI Publisher
<Location /xmlpserver>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

# BI Search
<Location /bisearch>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

# BI Composer
<Location /bicomposer>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

# EPM Provider Services
<Location /aps>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

# EPM Workspace
<Location /workspace>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

# BI SOA Services
<Location /biservices>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

# AdminService
<Location /AdminService>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

# AsyncAdminService
<Location /AsyncAdminService>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

#OWSM
<Location /wsm-pm>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

#BI Security
<Location /bi-security>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
</Location>

4. bi_vh.confファイルを作成し、次のディレクティブを追加します

<VirtualHost *:7777>
ServerName https://bi.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

#redirect browser requests that omit document/dir
RedirectMatch 301 /analytics$ /analytics/
RedirectMatch 301 /xmlpserver$ /xmlpserver/
RedirectMatch 301 /analytics/res$ /analytics/res/
RedirectMatch 301 /biofficeclient$ /biofficeclient/
RedirectMatch 301 /biservices$ /biservices/
RedirectMatch 301 /analytics-ws$ /analytics-ws/
RedirectMatch 301 /wsm-pm$ /wsm-pm/
RedirectMatch 301 /bisearch$ /bisearch/
RedirectMatch 301 /mapviewer$ /mapviewer/
RedirectMatch 301 /va$ /va/
RedirectMatch 301 /bicontent$ /bicontent/
RedirectMatch 301 /bicomposer$ /bicomposer/
RedirectMatch 301 /mobile$ /mobile/
RedirectMatch 301 /aps$ /aps/
RedirectMatch 301 /workspace$ /workspace/

# BIEE Analytics
<Location /analytics>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /analytics-ws>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /bicontent>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /mobile>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /va>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location

# MapViewer
<Location /mapviewer>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BI Publisher
<Location /xmlpserver>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BI Search
<Location /bisearch>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BI Composer

<Location /bicomposer>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# EPM Provider Services
<Location /aps>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# EPM Workspace
<Location /workspace>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# OWSM
<Location /wsm-pm>
SetHandler weblogic-handler
WeblogicCluster APPHOST1VHN1:7003,APPHOST2VHN1:7003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

5. ohs1インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力してインスタンスを停止および起動し、プロンプトが表示されたら、ノード・マネージャのパスワードを指定します。

./stopComponent.sh ohs1
./startComponent.sh ohs1

6. 3つの.confファイル(admin_vh.conf、biinternal_vh.confおよびbiinternal_vh.conf)をWEBHOST2上の2番目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/module_conf

7. .confファイルを編集して、<VirtualHost>ディレクティブ内のすべての参照をWEBHOST1からWEBHOST2に変更します。

8. ohs2インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止および起動します。

./stopComponent.sh ohs2
./startComponnet.sh ohs2

11.7.4 ロード・バランサでの仮想サーバー構成の検証

ロード・バランサから次のURLにアクセスして、ロード・バランサとOracle HTTP Serverが正しく構成されていることを確認します。これらのURLは、Oracle HTTP Server 12cの初期Webページを示しています。

- http://admin.example.com/index.html

- http://biinternal.example.com/index.html

- http://bi.example.com/index.html

11.7.5 管理コンソールおよび管理サーバーへのアクセスの検証

この章で行った変更を確認する手順は次のとおりです。

1. 次のハードウェア・ロード・バランサへのURLを使用してOracle WebLogic Server管理コンソールを表示し、Oracle WebLogic Server管理者資格証明を使用してログインします。

http://admin.example.com/console

これによって、ロード・バランサ上のadmin.example.com仮想ホストがWeb層のOracle HTTP Serverインスタンスにリクエストをルーティングでき、さらに、このOracle HTTP ServerインスタンスがOracle WebLogic Server管理コンソールのリクエストをアプリケーション層の管理サーバーにルーティングできることが検証されます。

2. 同様に、類似したURLを使用してFusion Middleware Controlにアクセスできます。

http://admin.example.com/em

11.7.6 Business IntelligenceコンポーネントへのHTTPアクセスの検証

Oracle HTTP Serverインスタンスを構成した後、主要なOracle Business Intelligence URLにアクセスして作業を検証できます。これらのURLにより適切なコンテンツが表示される場合、Web層コンポーネントが正しく構成されていることを示しています。

Oracle Business IntelligenceコンポーネントへのHTTPアクセスを検証するには、次の各URLをWebブラウザに入力して、適切なコンテンツが表示されることを確認します。

- http://bi.example.com/analytics

- http://bi.example.com/mapviewer

- http://bi.example.com/xmlpserver

- http://biinternal.example.com/wsm-pm

- http://bi.example.com/bicomposer

- http://bi.example.com/aps/Essbase

- http://bi.example.com/aps/SmartView

11.8 構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

12 Oracle Business Intelligenceのスケール・アウト

この章では、初期Oracle Business IntelligenceドメインをBIHOST2にスケール・アウトする手順について説明します。

コンポーネントのスケール・アウトでは、その他のホスト・コンピュータへのOracle Business Intelligenceのインストール、BIHOST1でのコンポーネントの停止とクローニング、ドメインの圧縮と解凍、スケール・アウト後のコンポーネントの開始を行います。

- 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

- 他のホスト・コンピュータへのOracle Business Intelligenceのインストール
BIHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、BIHOST2にもソフトウェアをインストールする必要があります。

- BIHOST1のコンポーネントの停止
スケール・アウトの前に、BIHOST1のドメインのすべてのコンポーネント・プロセスを停止する必要があります。

- BIHOST1のコンポーネントのクローニング
すべてのコンポーネント・プロセスを停止した後に、BIHOST1のドメイン内のコンポーネントをクローニングする必要があります。これにより、作成した初期ドメインに基づく新しいコンポーネントがBIHOST2に作成されます。

- BIHOST1の初期ドメインの圧縮
この項の手順を使用して、ドメイン構成情報(現在はOracle HTTP Serverインスタンスに関する構成情報が含まれる)を格納したテンプレートjarファイルを作成します。

- BIHOST2でのドメインの解凍
この項の手順を使用して、ドメイン構成情報を格納したドメイン・テンプレートを解凍し、bidomaintemplate.jarファイルをBIHOST1からBIHOST2にコピーします。

- スケール・アウト後のBIHOST1およびBIHOST2でのコンポーネントの起動
この項では、スケール・アウト後にBIHOST1およびBIHOST2でコンポーネント・プロセスを起動する手順について説明します。コンポーネント・プロセスには、ノード・マネージャ、WebLogicドメインの管理サーバー、システム・コンポーネントおよび管理対象サーバーが含まれます。

- BIHOST2でのOracle Business Intelligence URLの確認
BIHOST2でドメインのコンポーネントを起動した後、これらのURLにアクセスして、Oracle Business Intelligenceの構成を確認します。

- Oracle BI Publisherの構成
これらの手動タスクを実行して、Oracle BI Publisherを構成します。

- スケール・アウト後のOracle Business Intelligence構成のバックアップ
Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

親トピック: エンタープライズ・デプロイメントの構成

12.1 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

BIHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、BIHOST2にもInfrastructureをインストールする必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「BIHOST1でのInfrastructureインストーラの起動」と「Infrastructureインストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。

注意:

以前のリリースでは、推奨エンタープライズ・トポロジに、同じ場所に配置された一連のOracle HTTP Serverインスタンスが含まれていました。これらのリリースでは、Web層ホスト(WEBHOST1とWEBHOST2)でInfrastructureをインストールするための要件がありました。ただし、このリリースでは、エンタープライズ・デプロイメント・トポロジによって、Webサーバーがスタンドアロン・モードでインストールおよび構成されていることが想定されるため、Webサーバーはアプリケーション層ドメインの一部であるとはみなされません。詳細は、「エンタープライズ・デプロイメント用のWeb層の構成」を参照してください

12.2 他のホスト・コンピュータへのOracle Business Intelligenceのインストール

BIHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、BIHOST2にもソフトウェアをインストールする必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「インストール・プログラムの起動」と「インストール画面のナビゲート」の手順に従います。

12.3 BIHOST1のコンポーネントの停止

スケール・アウトの前に、BIHOST1のドメインのすべてのコンポーネント・プロセスを停止する必要があります。

コンポーネント・プロセスには、ノード・マネージャ、WebLogicドメインの管理サーバー、システム・コンポーネントおよびノード・マネージャによって制御されるWLS_BI1管理対象サーバーが含まれます。

BIHOST1のドメインのすべてのコンポーネントを停止するには、次のタスクを実行します。

- システム・コンポーネントの停止

- WLS_BI1管理対象サーバーの停止

- 管理サーバーの停止

- 管理サーバー・ドメイン・ホームでのノード・マネージャの停止

- 管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの停止

12.3.1 システム・コンポーネントの停止

次の手順に従って、Fusion Middleware Controlを使用してシステム・コンポーネントを停止します。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「ターゲット・ナビゲーション」ペインがまだ表示されていない場合は、ページの左上隅にある「ターゲット・ナビゲーション」アイコンをクリックして表示します。

4. 「ターゲット・ナビゲーション」ペインで「Business Intelligence」フォルダを展開し、「biinstance」を選択します。

Business Intelligenceの「概要」ページが表示されます。

5. 「可用性」、「プロセス」の順にクリックして、「可用性」ページの「プロセス」タブを表示します。

6. すべてのシステム・コンポーネントを停止するには、「すべて停止」をクリックします。

12.3.2 WLS_BI1管理対象サーバーの停止

次の手順に従って、Fusion Middleware Controlを使用してWLS_BI1管理対象サーバーを停止します。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「ターゲット・ナビゲーション」ペインがまだ表示されていない場合は、ページの左上隅にある「ターゲット・ナビゲーション」アイコンをクリックして表示します。

4. 「ターゲット・ナビゲーション」ペインで、「WebLogicドメイン」フォルダのドメインを開き、ドメイン内の管理対象サーバーを表示します。

5. WLS_BI1管理対象サーバーのみを選択します。

6. Oracle WebLogic Serverツールバーで「停止...」をクリックします。

7. 停止操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_BI1管理対象サーバーが停止していることを確認します。

12.3.3 管理サーバーの停止

これらの手順を使用して、ノード・マネージャを通じて管理サーバーを停止します。

1. WLSTを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

2. 構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します。

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'ASERVER_HOME')

注意:

このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

ASERVER_HOME/config/nodemanager

3. 管理サーバーを停止します。:

nmKill('AdminServer')

4. WLSTを終了します。

exit()

12.3.4 管理サーバー・ドメイン・ホームでのノード・マネージャの停止

これらの手順を使用して、ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを停止します。

1. 次のディレクトリに移動します。

ASERVER_HOME/bin

2. 次のコマンドを使用してノード・マネージャを停止します。

./stopNodeManager.sh

12.3.5 管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの停止

これらの手順を使用して、MSERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを停止します。

1. 次のディレクトリに移動します。

MSERVER_HOME/bin

2. 次のコマンドを使用してノード・マネージャを停止します。

./stopNodeManager.sh

12.4 BIHOST1のコンポーネントのクローニング

すべてのコンポーネント・プロセスを停止した後に、BIHOST1のドメイン内のコンポーネントをクローニングする必要があります。これにより、作成した初期ドメインに基づく新しいコンポーネントがBIHOST2に作成されます。

BIHOST1で次の手順を実行し、既存の管理対象サーバー、ノード・マネージャ、システム・コンポーネントおよびサービス・インスタンスをクローニングして、追加のコンポーネントを作成します。後で、BIHOST2の新しいコンポーネントを圧縮および解凍します。

1. WLSTを起動します。

cd ORACLE_HOME/oracle_common/common/bin
./wlst.sh

2. 更新用のBI管理サーバー・ドメインを開きます。

wls:/offline> readDomain(‘ASERVER_HOME’)

この例では、ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

3. CloneBIMachineコマンドを実行して、初期BIドメインの既存のコンポーネントに基づく追加のコンポーネントを作成します。

wls:/offline/bi_domain> cloneBIMachine('ASERVER_HOME','bihost2.example.com',baseMachine='BIHOST1',baseServer='WLS_BI1',machineName='BIHOST2')

この例の説明は、次のとおりです。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- bihost2.example.comを新しいマシンBIHOST2のリスニング・アドレスで置き換えます。

- WLS_BI1は、このドキュメント全体で使用されるBIHOST1のBI管理対象サーバーのサーバー名です。別の名前を選択した場合は、必要に応じて置き換えてください。

4. ドメインを更新して保存します。

wls:/offline/bi_domain/SystemComponent/obis2> updateDomain()

5. ドメインを閉じます。

wls:/offline/bi_domain/SystemComponent/obis2> closeDomain()

6. WLSTを終了します。

wls:/offline> exit()

12.5 BIHOST1の初期ドメインの圧縮

この項の手順を使用して、ドメイン構成情報(現在はOracle HTTP Serverインスタンスに関する構成情報が含まれる)を格納したテンプレートjarファイルを作成します。

1. BIHOST1にログインし、次のようにpackコマンドを実行してテンプレートJARファイルを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true \
-domain=ASERVER_HOME \
-template=complete_path/bidomaintemplate.jar \
-template_name=bi_domain_template

この例の説明は、次のとおりです。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- complete_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスで置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。

- bidomaintemplate.jarは、作成するJARファイルのサンプル名です。これには、Oracle HTTP Serverインスタンスの構成ファイルなどのドメイン構成ファイルが含まれます。

- bi_domain_templateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

2. packコマンドで作成したばかりのbidomaintemplate.jarファイルの場所を書き留めます。

デフォルトでは、パック・テンプレート・ファイルは、packコマンドを実行した現在のディレクトリに作成されます。この例では、ORACLE_COMMON_HOME/common/binディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

12.6 BIHOST2でのドメインの解凍

この項の手順を使用して、ドメイン構成情報を格納したドメイン・テンプレートを解凍し、bidomaintemplate.jarファイルをBIHOST1からBIHOST2にコピーします。

1. BIHOST2にログインします。

2. BIHOST1のドメイン・テンプレートjarファイルをBIHOST2にコピーします。

3. まだ作成していない場合は、BIHOST2のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
complete_path

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
-template=complete_path/bidomaintemplate.jar \
-app_dir=APPLICATION_HOME \
-overwrite_domain=true \
-nodemanager_type=PerDomainNodeManager

この例の説明は、次のとおりです。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- complete_pathを、テンプレートjarファイルを作成またはコピーした場所の完全なパスで置き換えます。

- bidomaintemplate.jarは、packコマンドを実行してドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。
BIHOST2に別の共有記憶域ボリュームまたはパーティション(および冗長Oracleホーム)を使用している場合は、BIHOST2にマウントされているボリュームまたはパーティションに、まずテンプレートをコピーする必要があります。

- APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがBIHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

12.7 スケール・アウト後のBIHOST1およびBIHOST2でのコンポーネントの起動

この項では、スケール・アウト後にBIHOST1およびBIHOST2でコンポーネントを起動する手順について説明します。コンポーネント・プロセスには、ノード・マネージャ、WebLogicドメインの管理サーバー、システム・コンポーネントおよび管理対象サーバーが含まれます。

スケール・アウト後にコンポーネントを起動するには、次のタスクを実行します。

- 管理サーバー・ドメイン・ホームでのノード・マネージャの起動

- 管理サーバーの起動

- 管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

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

- WebLogicプロキシ・プラグインの構成

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

- システム・コンポーネントの起動

12.7.1 管理サーバー・ドメイン・ホームでのノード・マネージャの起動

BIHOST1上のASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動するには、「BIHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動」の手順を使用します。

12.7.2 管理サーバーの起動

ノード・マネージャを使用して管理サーバーを起動するには、「管理サーバーの起動」の手順を使用します。

12.7.3 管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

BIHOST1およびBIHOST2上のMSERVER_HOMEディレクトリのドメインごとのノード・マネージャを起動するには、「BIHOST1上の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動」の手順を使用します。

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

WLS_BI2管理対象サーバーを起動するには、管理対象サーバーのリスニング・アドレスを、BIHOST2VHN仮想IPアドレスの値に設定されるように更新しておく必要があります。これを行うには、WebLogic Server管理コンソールを使用します。

1. WebLogic管理者の資格証明を使用してWebLogic Server管理コンソールにログインします。

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

3. 左側の「ドメイン構造」メニューの「環境」ノードを開き、「サーバー」をクリックします。

4. 「サーバー」表で、管理対象サーバー名(WLS_BI2)をクリックします。

5. 「構成」タブで「リスニング・アドレス」をBIHOST2VHNの値に設定し、「保存」をクリックして変更内容を保存します。

6. 「チェンジ・センター」の「変更のアクティブ化」をクリックします。

12.7.5 WebLogicプロキシ・プラグインの構成

Oracle HTTP Serverインスタンスを介してリクエストが適切にルーティングされたことを検証するには、構成したクラスタの「WebLogicプラグインの有効化」パラメータを設定しておく必要があります。

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

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「クラスタ」をクリックします。

4. Oracle HTTP Serverからのリクエストのプロキシ先とするクラスタを選択します。

「構成: 一般」タブが表示されます。

5. 「詳細」セクションまでスクロール・ダウンして、開きます。

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

7. 「WebLogicプラグインの有効化」を「はい」に設定します。

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

9. 「チェンジ・センター」の「変更のアクティブ化」をクリックします。

12.7.6 管理対象サーバーの起動

WLS_BI2管理対象サーバーを起動するには、WLS_BI2のリスニング・アドレスを、BIHOST2VHN仮想IPアドレスの値に設定されるようにしておく必要があります。詳細は、「WLS_BI2管理対象サーバーのリスニング・アドレスの設定」を参照してください。

WLS_BI1管理対象サーバーおよびWLS_BI2管理対象サーバーを起動するには、「BIHOST1でのWLS_BI1管理対象サーバーの起動」の手順を使用します。

12.7.7 システム・コンポーネントの起動

すべてのOracle Business Intelligenceシステム・コンポーネントを起動するには、「システム・コンポーネントの起動」の手順を使用します。

12.8 BIHOST2でのOracle Business Intelligence URLの確認

BIHOST2でドメインのコンポーネントを起動した後、これらのURLにアクセスして、Oracle Business Intelligenceの構成を確認します。

- 次のURLにアクセスして、WLS_BI2のステータスを確認します。

http://BIHOST2VHN1:7003/analytics

次にリダイレクトされます。

http://bi.example.com/analytics

- 次のURLにアクセスして、BI Publisherアプリケーションのステータスを確認します。

http://BIHOST2VHN1:7003/xmlpserver

次にリダイレクトされます。

http://bi.example.com/xmlpserver

- 次のURLにアクセスして、Oracle Essbaseアプリケーションのステータスを確認します。

http://BIHOST2VHN1:7003/aps/Essbase

12.9 Oracle BI Publisherの構成

これらの手動タスクを実行して、Oracle BI Publisherを構成します。

- JMS共有のTempディレクトリの更新
次の手順に従って、BI Publisher SchedulerのJMS共有のTempディレクトリを更新します。この項の手順は、BIホストのいずれか1つ(BIHOST1またはBIHOST2)でのみ実行する必要があります。

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

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

次の手順に従って、BI Publisher SchedulerのJMS共有のTempディレクトリを更新します。この項の手順は、BIホストのいずれか1つ(BIHOST1またはBIHOST2)でのみ実行する必要があります。

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

1. 次のどちらかのURLを使用してBI Publisherにログインします。

- http://BIHOST1VHN1:7003/xmlpserver

- http://BIHOST2VHN1:7003/xmlpserver

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

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

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

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

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

注意:

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

cluster:t3://bi_cluster

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

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

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

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

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

1. 管理者の資格証明を使用して次のURLでBI Publisherにログインします。

http://BIHOST1VHN1:7003/xmlpserver

2. 「管理」タブを選択します。

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

4. 「接続文字列」パラメータを次のように変更して、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://BIHOST1:9706/PrimaryCCS=BIHOST1;PrimaryCCSPort=9706;
SecondaryCCS=BIHOST2;SecondaryCCSPort=9706;

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

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

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

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

12.10 スケール・アウト後のOracle Business Intelligence構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

第IV部 エンタープライズ・デプロイメントの共通の構成および管理手順

次のトピックでは、一般的なエンタープライズ・デプロイメントに必須または推奨される構成および管理手順について説明します。

- エンタープライズ・デプロイメントの共通の構成および管理タスク
次のトピックでは、エンタープライズ・デプロイメント環境で実行する必要性が高い、構成および管理タスクについて説明します。

- エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用
次のトピックでは、Oracle WebLogic Serverのサーバー全体の移行およびOracle WebLogic Server自動サービス移行について説明します。Oracle Fusion Middlewareエンタープライズ・トポロジでのこれらの機能の使用方法についても説明します。

- エンタープライズ・デプロイメント用のシングル・サインオンの構成
この章では、Oracle HTTP Server WebGateを構成してOracle Access Managerでシングル・サインオンを有効化する方法について説明します。

13 エンタープライズ・デプロイメントの共通の構成および管理タスク

次のトピックでは、エンタープライズ・デプロイメント環境で実行する必要性が高い、構成および管理タスクについて説明します。

- 管理サーバーの手動フェイルオーバーの確認
ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次に、BIHOST1およびBIHOST2から管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。

- 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化
この項では、中間層とハードウェア・ロード・バランサ間のSSL通信を有効化する方法について説明します。

- エンタープライズ・デプロイメントのバックアップとリカバリの実行
この項では、Oracle Business Intelligenceエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするためのガイドラインを示します。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

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

ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次に、BIHOST1およびBIHOST2から管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。

前提条件:

- 管理サーバーを、localhostまたは任意のアドレスではなく、ADMINVHN上でリスニングするように構成します。
ADMINVHN仮想IPアドレスの詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

- この手順では、管理サーバーのドメイン・ホーム(ASERVER_HOME)が両方のホスト・コンピュータにマウントされていることを前提にしています。これにより、管理サーバーのドメイン構成ファイルと永続ストアが、共有記憶域デバイスに保存されるようになります。

- 管理サーバーはBIHOST1からBIHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。

- BIHOST1: 100.200.140.165

- BIHOST2: 100.200.140.205

- ADMINVHN : 100.200.140.206。これは管理サーバーを実行している場所の仮想IPであり、ethX:Yに割り当てられており、BIHOST1とBIHOST2からアクセスできます。

- Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、BIHOST2にインストールされています。
具体的には、両方のホスト・コンピュータは、まったく同じパスを使用してOracleホームのバイナリ・ファイルを参照します。

次のトピックでは、管理フェイルオーバー・プロシージャのテストを実行する詳細な方法について説明します。

- 別のホストへの管理サーバーのフェイルオーバー
次の手順は、管理サーバーを別のノード(BIHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。

- Oracle HTTP Serverを介したBIHOST2上の管理サーバーへのアクセスの検証
管理サーバーの手動フェイルオーバーを実行した後、標準の管理URLを使用して管理サーバーにアクセスできるかどうかを確認することが重要です。

- BIHOST1への管理サーバーのフェイルバック
管理サーバーの手動フェイルオーバーをテストして、フェイルオーバー後に管理URLにアクセスできることを検証した後、管理サーバーをその元のホストに移行できます。

13.1.1 別のホストへの管理サーバーのフェイルオーバー

次の手順は、管理サーバーを別のノード(BIHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。

この手順では、エンタープライズ・トポロジに対してドメインごとのノード・マネージャを構成していることが前提となります。詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください

管理サーバーを別のホストにフェイルオーバーするには:

1. 管理サーバーを停止します。

2. 管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)のノード・マネージャを停止します。

3. ADMINVHN仮想IPアドレスを第2ホストに移行します。

a. BIHOST1上で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。

/sbin/ifconfig ethX:Y down

b. BIHOST2で次のコマンドをルートとして実行します。

/sbin/ifconfig <interface:index> ADMINVHN netmask <netmask>

次に例を示します。

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、BIHOST2で使用可能なネットワーク構成と一致している必要があります。

4. 次の例のように、arpingを使用してルーティング表を更新します。

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

5. BIHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。

6. BIHOST2で管理サーバーを起動します。

7. 次の方法でBIHOST2上の管理サーバーにアクセスできることをテストします。

a. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。

http://ADMINVHN:7001/console

b. 次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。

http://ADMINVHN:7001/em

13.1.2 Oracle HTTP Serverを介したBIHOST2上の管理サーバーへのアクセスの検証

管理サーバーの手動フェイルオーバーを実行した後、標準の管理URLを使用して管理サーバーにアクセスできるかどうかを確認することが重要です。

ロード・バランサから次のURLにアクセスして、BIHOST2で実行している管理サーバーにアクセスできることを確認します。

- http://admin.example.com/console
このURLによって、WebLogic Server管理コンソールが表示されます。

- http://admin.example.com/em
このURLによって、Oracle Enterprise Manager Fusion Middleware Controlが表示されます。

13.1.3 BIHOST1への管理サーバーのフェイルバック

管理サーバーの手動フェイルオーバーをテストして、フェイルオーバー後に管理URLにアクセスできることを検証した後、管理サーバーをその元のホストに移行できます。

1. 管理サーバーを停止します。

2. BIHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを停止します。

3. BIHOST2で次のコマンドをルートとして実行します。

/sbin/ifconfig ethZ:N down

4. BIHOST1で次のコマンドをルートとして実行します。

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクおよびインタフェースがBIHOST1の使用可能なネットワーク構成と一致することを確認します

5. BIHOST1上でarpingを使用して、ルーティング表を更新します。

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

6. BIHOST1上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。

7. BIHOST1上で管理サーバーを起動します。

8. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。

http://ADMINVHN:7001/console

9. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。

http://ADMINVHN:7001/em

13.2 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

この項では、中間層とハードウェア・ロード・バランサ間のSSL通信を有効化する方法について説明します。

注意:

この手順は、ハードウェア・ロード・バランサにSSLが構成されており、その結果システムのフロント・エンド・アドレスが保護されている場合に使用できます。

- 中間層とロード・バランサ間のSSL通信が必要になるとき

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

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

- Keytoolユーティリティを使用した信頼キーストアの作成

- トラスト・ストアへのロード・バランサ証明書のインポート

- Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

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

- カスタム・キーストアを使用するためのWebLogic Serverの構成

13.2.1 中間層とロード・バランサ間のSSL通信が必要になるとき

エンタープライズ・デプロイメントには、中間層で実行されているソフトウェアが、ハードウェア・ロード・バランサのフロントエンドSSLアドレスにアクセスしなければならないシナリオがあります。このシナリオでは、ロード・バランサと起動サーバー間で、適切なSSLハンドシェイクが行われる必要があります。中間層の管理サーバーと管理対象サーバーが適切なSSL構成を使用して起動されていない場合は、このハンドシェイクを実行できません。

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

この項では、BIHOST1に自己署名証明書を作成する手順について説明します。これらの証明書は、ネットワーク名またはホストの別名を使用して作成します。

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、BIHOST2では、BIHOST1の証明書用に作成されたcertディレクトリを使用します。

かわりに信頼できるCA証明書を使用する方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する情報を参照してください。

パスワードについて

このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。

自己署名証明書を作成する手順は次のとおりです。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。

2. CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

3. 「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されているとおりに共有構成ディレクトリ・フォルダが作成され、共有記憶域に適切にマウントされていることを検証します。

たとえば、次のコマンドを使用して、共有構成ディレクトリが各ホストで使用可能であることを検証します。

df -h | grep -B1 SHARED_CONFIG_DIR

SHARED_CONFIG_DIRを、共有構成ディレクトリの実際のパスで置き換えます。

ディレクトリのリスト作成を実行し、ホストで使用可能かどうかを確認することもできます。

ls -al SHARED_CONFIG_DIR

4. キーストア・ホーム・フォルダ構造がまだない場合は、作成します。

次に例を示します。

cd SHARED_CONFIG_DIR
mkdir keystores
chown oracle:oinstall keystores
chmod 750 keystores

5. ディレクトリをキーストア・ホームに変更します。

cd KEYSTORE_HOME

6. utils.CertGenツールを実行して、ノード内のサーバーによって使用される物理ホスト名と仮想ホスト名の両方の証明書を作成します。

構文:

java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]

例:

java utils.CertGen password ADMINVHN.example.com_cert \
ADMINVHN.example.com_key domestic ADMINVHN.example.com

java utils.CertGen password BIHOST1.example.com_cert \
BIHOST1.example.com_key domestic BIHOST1.example.com

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

この項では、BIHOST1.example.comでアイデンティティ・キーストアを作成する方法について説明します。

前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、BIHOST1とADMINVHN両方の証明書と秘密鍵が新しいアイデンティティ・ストアにインポートされます。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

注意:

アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。

1. ADMINVHNおよびBIHOST1の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

構文:

java utils.ImportPrivateKey
-certfile cert_file
-keyfile private_key_file
[-keyfilepass private_key_password]
-keystore keystore
-storepass storepass
[-storetype storetype]
-alias alias
[-keypass keypass]

注意:

デフォルトのkeystore_typeはjksです。

例:

Java utils.ImportPrivateKey
-certfile KEYSTORE_HOME/ADMINVHN.example.com_cert.pem
-keyfile KEYSTORE_HOME/ADMINVHN.example.com_key.pem
-keyfilepass password
-keystore appIdentityKeyStore.jks
-storepass password
-alias ADMINVHN
-keypass password

java utils.ImportPrivateKey
-certfile KEYSTORE_HOME/BIHOST1.example.com_cert.pem
-keyfile KEYSTORE_HOME/BIHOST1.example.com_key.pem
-keyfilepass password
-keystore appIdentityKeyStore.jks
-storepass password
-alias BIHOST1
-keypass password

2. システムで使用されている残りのすべてのホスト(BIHOST2など)に対して前述の手順を繰り返します。

13.2.4 Keytoolユーティリティを使用した信頼キーストアの作成

BIHOST1.example.comに信頼キーストアを作成する手順は次のとおりです。

1. 新しい信頼キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。

標準のJava信頼キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアのCA証明書を、証明書のあるディレクトリにコピーします。次に例を示します。

cp WL_HOME/server/lib/cacerts KEYSTORE_HOME/appTrustKeyStore.jks

2. keytoolユーティリティを使用して、デフォルトのパスワードを変更します。

標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは、常に次のように変更することをお薦めします。

keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password

次に例を示します。

keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit

3. keytoolユーティリティを使用してCA証明書をappTrustKeyStoreにインポートします。

CA証明書CertGenCA.derは、utils.CertGenツールによって生成されるすべての証明書の署名に使用され、WL_HOME/server/libディレクトリに置かれています。

次の構文を使用して、証明書をインポートします。

keytool -import -v -noprompt -trustcacerts -alias AliasName -file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password

次に例を示します。

keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass password

13.2.5 トラスト・ストアへのロード・バランサ証明書のインポート

SSLハンドシェイクが適切に行われるには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。追加するには、次の手順を実行します。

1. ブラウザでSSLのサイトにアクセスします(これにより、サーバーの証明書がブラウザのリポジトリに追加されます)。

2. ブラウザの証明書管理ツールから、証明書を、サーバーのファイル・システムにある(bi.example.comのようなファイル名を持つ)ファイルにエクスポートします。

3. keytoolを使用して、ロード・バランサの証明書をトラスト・ストアにインポートします。

keytool -import -file bi.example.com -v -keystore appTrustKeyStore.jks

13.2.6 Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

各サーバーが更新済のトラスト・ストアにアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリのsetDomainEnv.shスクリプトを次のように編集します。

1. BIHOST1にログインして、テキスト・エディタで次のファイルを開きます。

ASERVER_HOME/bin/setDomainEnv.sh

2. 既存のDemoTrustStoreエントリへの参照を、appTrustKeyStore.jksファイルの場所で置き換えます。

EXTRA_JAVA_PROPERTIESのすべての値をファイル内に1行で記述し、その後の新規行にexportコマンドを記述する必要があります。次に例を示します。

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
-Djavax.net.ssl.trustStore=KEYSTORE_HOME/appTrustKeyStore.jks..."
export EXTRA_JAVA_PROPERTIES

3. BIHOST1およびBIHOST2のMSERVER_HOME/binディレクトリにあるsetDomainEnv.shファイルに、同じ変更を行います。

あるいは、setUserOverrides.shファイルを使用して、これらのオプションを配置できます。この方法では、ドメインのスクリプトが構成ウィザードによって拡張されたり、解凍操作によって更新されたりする場合にも、これらのオプションは上書きされません。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。

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

カスタム・キーストアを使用するようにノード・マネージャを構成するには、すべてのノード内のASERVER_HOME/nodemanagerディレクトリとMSERVER_HOME/nodemanagerディレクトリの両方にあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity KeyStore
CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd
CustomIdentityAlias=Identity Key Store Alias
CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate

ノード・マネージャのリスニング・アドレスのCustomIdentityAliasには必ず正しい値を使用してください。たとえば、BIHOST1では、「keytoolユーティリティを使用した信頼キーストアの作成」の手順に従って、appIdentity2を使用します

(appIdentity2 mapped to the BIHOST1 listen address).
Example for Node 1:
KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=KEYSTORE_HOME/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentity1
CustomIdentityPrivateKeyPassPhrase=password

「BIHOST1でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリは暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイルのエントリが暗号化されていない状態になる時間は最小限に抑えてください。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

13.2.8 カスタム・キーストアを使用するためのWebLogic Serverの構成

Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。SSL上のフロント・エンドLBRへのアクセスが必要な管理サーバーおよび管理対象サーバーに対して、この手順を実行します。

IDキーストアおよび信頼キーストアを構成するには:

1. 管理コンソールにログインして「ロックして編集」をクリックします。

2. 左ペインで「環境」を開き、「サーバー」を選択します。

3. IDキーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。

4. 「構成」を選択して、「キーストア」を選択します。

5. 「キーストア」フィールドで、「変更」をクリックし、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法を選択して、「保存」をクリックします。

6. 「ID」セクションで、アイデンティティ・キーストアの属性を定義します。

- カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。

KEYSTORE_HOME/appIdentityKeyStore.jks

- カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

- カスタム・アイデンティティ・キーストアのパスフレーズ: 「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します
この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアで、キーストアに書き込むためにはパスワードが必須です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

7. 「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。

- カスタム信頼キーストア: トラスト・キーストアの完全修飾パスを入力します。

KEYSTORE_HOME/appTrustKeyStore.jks

- カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

- カスタム信頼キーストアのパスフレーズ: 「keytoolユーティリティを使用した信頼キーストアの作成」で、新規パスワードとして指定したパスワード。
前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。

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

9. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

10. 「ロックして編集」をクリックします。

11. 「構成」をクリックし、「SSL」をクリックします。

12. 「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。

「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で作成したキーストアのパスワードを入力します

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

14. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

15. 変更を適用したサーバーを再起動します。管理コンソール/ノード・マネージャを使用してサーバーを再起動できるということは、ノード・マネージャ、管理サーバー、および管理対象サーバー間の通信が正常であるということです。

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

この項では、Oracle Business Intelligenceエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするためのガイドラインを示します。

注意:

ここで示されている一部の静的およびランタイム・アーティファクトは、Network Attached Storage (NAS)からホストされます。可能な場合は、これらのボリュームをアプリケーション・サーバーではなく直接NASファイラからバックアップおよびリカバリします。

Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。

- 「環境のバックアップ」

- 「環境のリカバリ」

表13-1は、一般的なOracle Business Intelligenceエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。

表13-1 Oracle Business Intelligenceエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト

タイプ

ホスト

層

データベースOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

BIHOST1およびBIHOST2

アプリケーション層

インストール関連ファイル

WEBHOST1、WEHOST2および共有記憶域

N/A

表13-2は、一般的なOracle Business Intelligenceエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。

表13-2 Oracle Business Intelligenceエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト

タイプ

ホスト

層

管理サーバーのドメイン・ホーム(ASERVER_HOME)

BIHOST1およびBIHOST2

アプリケーション層

アプリケーション・ホーム(APPLICATION_HOME)

BIHOST1およびBIHOST2

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

スクリプトとカスタマイズ

BIHOST1およびBIHOST2

アプリケーション層

デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME)

BIHOST1およびBIHOST2

アプリケーション層

シングルトン・データ・ディレクトリ(SDD)

BIHOST1およびBIHOST2

アプリケーション層

14 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

次のトピックでは、Oracle WebLogic Serverのサーバー全体の移行およびOracle WebLogic Server自動サービス移行について説明します。Oracle Fusion Middlewareエンタープライズ・トポロジでのこれらの機能の使用方法についても説明します。

- エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について
Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。

- リース用のGridLinkデータ・ソースの作成
サーバー全体の移行および自動サービス移行の両方で、リーシング表のデータ・ソースが必要です。リーシング表は、リポジトリ作成ユーティリティ(RCU)によって、Oracle WebLogic Serverスキーマの一部として自動的に作成される表領域です。

- エンタープライズ・デプロイメント用のサーバー全体の移行の構成
サーバー全体の移行または自動サービス移行のためのドメインを準備した後に、クラスタ内の特定の管理対象サーバーのサーバー全体の移行を構成できます。詳細は、次の各項を参照してください。

- エンタープライズ・デプロイメント内での自動サービス移行の構成
エンタープライズ・デプロイメントで特定のサービスの自動サービス移行を構成するには、この項のトピックを参照してください。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

14.1 エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について

Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。

- サーバー全体の移行とサービスの移行の違いの理解

- エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

- サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

14.1.1 サーバー全体の移行とサービスの移行の違いの理解

Oracle WebLogic Serverの移行フレームワークでは、次の2つの種類の自動移行をサポートしています。

- サーバー全体の移行。障害発生時に、管理対象サーバー・インスタンスが別の物理システムに移行されます。
サーバー全体の移行では、別の物理マシン上で、サーバー・インスタンスとそのすべてのサービスが自動的に再起動されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。

このためには、サーバーはリスニング・アドレスとして浮動IPを使用する必要があり、必要なリソース(トランザクション・ログとJMS永続ストア)が候補マシンで利用できなければなりません。

詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。

- サービスの移行。特定のサービスが、クラスタ内の別の管理対象サーバーに移行されます。
サービスの移行を理解するには、固定サービスを理解することが重要です。

WebLogic Serverクラスタでは、ほとんどのサブシステム・サービスがクラスタ内のすべてのサーバー・インスタンスで均一にホストされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMS関連サービスやJTAトランザクション・リカバリ・サービス、ユーザー定義のシングルトン・サービスなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにホストされます。WebLogic Serverの移行フレームワークは、これらのサービスに対して、フェイルオーバーではなく、サービスの移行による障害回復をサポートしています。

詳細は、『Oracle WebLogic Serverクラスタの管理』の「サービスの移行フレームワークの理解」を参照してください。

14.1.2 エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

サーバーまたはサービスが別のシステムで再起動されるときは、必要なリソース(サービス・データ、ログなど)が元のシステムとフェイルオーバー・システムの両方で利用できなければなりません。利用できなければ、サービスは、同じ操作をフェイルオーバー・システムで正常に再開できません。

このような理由から、サーバー全体の移行とサービスの移行の両方で、クラスタのすべてのメンバーが、同一のトランザクションとJMS永続ストア(ファイルベースかデータベースベースかを問わない)にアクセスできる必要があります。

これが、エンタープライズ・デプロイメントで共有記憶域が重要となる、もう1つの理由です。共有記憶域を適切に構成すると、手動フェイルオーバー(管理サーバーのフェイルオーバー)または自動フェイルオーバー(サーバー全体の移行またはサービスの移行)が発生したときに、元のマシンとフェイルオーバー・マシンの両方が、サービスを変更しなくても、確実に同一のファイル・ストアにアクセスできるようになります。

自動サービス移行の場合、固定サービスの再開が必要になったときは、フェイルオーバー前に固定サービスによって使用されていたJMSとJTAのログにアクセスできる必要があります。

サーバー全体の移行の場合、共有記憶域のほかに、仮想IPアドレス(VIP)の入手と割当ても必要になります。管理対象サーバーが別のマシンにフェイルオーバーされると、VIPは新しいマシンに自動的に再割り当てされます。

サービスの移行には、VIPは必要ありません。

14.1.3 サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

次の表は、サーバー全体の移行を構成する必要のある製品とコンポーネント、および自動サービス移行を構成する必要のある製品をまとめたものです。

この表は、推奨されるベスト・プラクティスを示していることに注意してください。サーバー全体の移行または自動サーバー移行をサポートするコンポーネントでこれらの機能を使用できなくなるわけではありません。

コンポーネント

サーバー全体の移行(WSM)

自動サービス移行(ASM)

Oracle Business Intelligence Publisher

はい

いいえ

14.2 リース用のGridLinkデータ・ソースの作成

サーバー全体の移行および自動サービス移行の両方で、リーシング表のデータ・ソースが必要です。リーシング表は、リポジトリ作成ユーティリティ(RCU)によって、Oracle WebLogic Serverスキーマの一部として自動的に作成される表領域です。

エンタープライズ・デプロイメントでは、GridLinkのデータ・ソースを作成する必要があります。

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

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

- 「名前」フィールドに、データ・ソースの論理名を入力します。たとえば、Leasingと入力します。

- JNDIの名前を入力します。たとえば、jdbc/leasingです。

- 「データベース・ドライバ」には、Oracle Driver (Thin) for GridLink Connections Versions: Anyを選択します。

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

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスを選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。次に例を示します。
biedg.example.com

- ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。次に例を示します。

db-scan.example.com:1521

「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。

SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せると、確認できます。

SQL>show parameter remote_listener;

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string      db-scan.example.com

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例:

dbhost1-vip.mycompany.com (port 1521)

および

dbhost2-vip.mycompany.com (1521)

Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- データベース・ユーザー名: 次のように入力します。

FMW1221_WLS_RUNTIME

この例では、FMW1221は、初期Enterprise Managerドメインを構成する準備をしたときに、スキーマの作成で使用した接頭辞です。

前のバージョンのOracle Fusion Middlewareでは、移行リース表のユーザーおよび表領域を手動で作成する必要がありました。Fusion Middleware 12c (12.2.1)では、リポジトリ作成ユーティリティ(RCU)でWLSスキーマを作成すると、リーシング表が自動的に作成されます。

- パスワード: RCUでWLSスキーマを作成したときに使用したパスワードを入力します。

- パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。

接続が成功したときに表示される通知の一例を示します。

Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.example.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=biedg.example.com))) succeeded.

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

9. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- 「ONSホストとポート」フィールドにSCANアドレスを入力して、「追加」、「追加」の順にクリックします。
この値は、RACデータベースのONSホストおよびONSリモート・ポートである必要があります。データベースのONSリモート・ポートを検索するために、データベース・ホストで次のコマンドを使用できます。

[orcl@db-scan1 ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

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

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.example.com (port 6200)

および

custdbhost2.example.com (6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

接続が成功したときに表示される通知の一例を示します。

Connection test for db-scan.example.com:6200 succeeded.

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

11. 「ターゲットの選択」ページで、サーバー全体の移行または自動サービス移行を構成するクラスタを選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

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

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

サーバー全体の移行または自動サービス移行のためのドメインを準備した後に、クラスタ内の特定の管理対象サーバーのサーバー全体の移行を構成できます。詳細は、次の各項を参照してください。

- ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

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

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

- サーバー全体の移行のテスト

14.3.1 ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

この項では、サーバーが実行されている2つのノード上のノード・マネージャのプロパティ・ファイルを編集します。

1. 次のファイルを探してテキスト・エディタで開きます。

MSERVER_HOME/nodemanager/nodmeanager.properties

2. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。

これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

3. 次のプロパティをnodemanager.propertiesファイルに追加して、サーバー移行が正常に動作するようにします。

- Interface

Interface=eth0

このプロパティは浮動IP (eth0など)のインタフェース名を指定します。

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。

ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

- NetMask

NetMask=255.255.255.0

このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。

- UseMACBroadcast

UseMACBroadcast=true

このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

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

5. これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力は次のようになります。

...
SecureListener=true
LogCount=1
eth0=*,NetMask=255.255.255.0
...

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

この項では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。このスクリプトは、移行中に、IPアドレスをマシンからマシンに転送するために使用します。通常スーパーユーザーのみが利用可能なifconfigの実行が可能でなければなりません。

wlsifconfig.shスクリプトの詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の自動移行の構成に関する項を参照してください。

wlsifconfig.shスクリプトを実行するためにシステムを準備する手順は、次の項を参照してください。

- wlsifconfig.shスクリプトのPATH環境変数の設定

- wlsifconfig.shスクリプトに対する権限の付与

14.3.2.1 wlsifconfig.shスクリプトのPATH環境変数の設定

次の表に記載されているコマンドは、各ホスト・コンピュータのPATH環境変数に必ず含めてください。

ファイル

ディレクトリの場所

wlsifconfig.sh

MSERVER_HOME/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

MSERVER_HOME/nodemanager

14.3.2.2 wlsifconfig.shスクリプトに対する権限の付与

パスワードによる制限を設けずにsudo権限をオペレーティング・システム・ユーザー(oracleなど)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

注意:

セキュリティ上の理由から、sudoを、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。

この必須の構成タスクを実行するためのsudo権限とsystem権限については、必要に応じてシステム管理者に問い合せてください。

/etc/sudoers内の次のエントリ例では、ifconfigとarpingを実行するために、oracleに対してsudo実行権限を付与しています。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

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

クラスタ内の移行を構成する手順は次のとおりです。

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

2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

3. 移行を構成するクラスタを、表の「名前」列でクリックします。

4. 「移行」タブをクリックします。

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

6. 「データベース」がリーシング・メカニズムとして選択されていることを確認します。
必要に応じて、リーシング・メカニズムとして「データベース」を選択します。

7. 「移行可能サーバーの候補マシン」の「使用可能」フィールドでクラスタ内の管理対象サーバーを選択し、右矢印をクリックして「選択済み」に移動します。

8. 「リース用のGridLinkデータ・ソースの作成」で作成したリーシング・データ・ソースを選択します。

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

10. サーバー移行の候補となるマシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。

a. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

b. 移行を構成するサーバーを選択します。

c. 「移行」タブをクリックします。

d. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

アプリケーションとリソースのターゲット設定の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

e. 「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。
この手順では、現在のホストを使用できない場合に管理対象サーバーのフェイルオーバー先となるホストを識別します。たとえば、HOST1の管理対象サーバーの場合はHOST2を選択し、HOST2の管理対象サーバーの場合はHOST1を選択します。

ヒント:

「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。

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

12. 管理サーバーと、サーバー移行が構成されたサーバーを再起動します。

14.3.4 サーバー全体の移行のテスト

この項の手順を実行して、サーバー全体の自動移行が適切に機能していることを確認します。

ノード1からテストする手順は次のとおりです。

1. 管理対象サーバーのプロセスを停止します。

kill -9 pid

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

ps -ef | grep WLS_BI1

2. ノード・マネージャのコンソール(killコマンドを実行したターミナル・ウィンドウ)を確認します。管理対象サーバーの浮動IPが無効になっていることを示すメッセージが表示されているはずです。

3. ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャがサーバーを再起動し、サーバーが「実行中」状態になる前に、関連するプロセスを再度強制終了します。
サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

必要な再起動回数は、次の構成ファイルのRestartMaxパラメータで設定されます。

MSERVER_HOME/servers/WLS_BI1/data/nodemanager/startup.properties

デフォルト値はRestartMax=2です。

ノード2からテストする手順は次のとおりです。

1. ローカルのノード・マネージャのコンソールを確認します。ノード1で最後に管理対象サーバーの再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、管理対象サーバーの浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。

2. 同じIPアドレスを使用して、製品URLにアクセスします。URLが正常な場合は、移行が成功したことを示します。

管理コンソールからの検証

Oracle WebLogic Server管理コンソールを使用して、移行を検証することもできます。

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

2. 左側のコンソールで、「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。

「移行の状態」の表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後、そのサーバーを元のマシンにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

14.4 エンタープライズ・デプロイメント内での自動サービス移行の構成

エンタープライズ・デプロイメントで特定のサービスの自動サービス移行を構成するには、この項のトピックを参照してください。

注意:

現在、Oracle Business Intelligenceは自動サービス移行をサポートしていません。ここに記載されている情報は、自動サービス移行をサポートするその他のFusion Middleware製品をデプロイしているユーザーを対象としています。

- エンタープライズ・デプロイメント・クラスタのリーシング・メカニズムとデータ・ソースの設定

- クラスタ内の管理対象サーバーの移行設定の変更

- サービス移行ポリシーの選択について

- クラスタ内の各管理対象サーバーのサービス移行ポリシーの設定

- 管理対象サーバーの再起動と自動サービス移行の検証

- 自動サービス移行後のサービスのフェイルバック

14.4.1 エンタープライズ・デプロイメント・クラスタのリーシング・メカニズムとデータ・ソースの設定

自動サービス移行を構成する前に、自動サービス移行機能によって使用されるリーシング・メカニズムおよびデータ・ソースを確認する必要があります。

注意:

次の手順は、「リース用のGridLinkデータ・ソースの作成」の説明に従ってリーシング・データ・ソースを作成していることを前提としています。

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

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
「クラスタのサマリー」ページが表示されます。

4. 表の「名前」列で、移行を構成するクラスタをクリックします。

5. 「移行」タブをクリックします。

6. 「移行基盤」ドロップダウン・メニューで「データベース」が選択されていることを確認します。

7. 「自動移行に使用するデータ・ソース」ドロップダウン・メニューから、「リース用のGridLinkデータ・ソースの作成」で作成したリーシング・データ・ソースを選択します。

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

9. 変更をアクティブ化します。

14.4.2 クラスタ内の管理対象サーバーの移行設定の変更

クラスタのリーシング・メカニズムとデータ・ソースを設定した後に、サービス移行に対して構成する管理対象サーバーのJTAの自動移行を有効にすることができます。このトピックは、エンタープライズ・デプロイメントの一部としてJTAサービスをデプロイしている場合にのみ適用されます。

クラスタ内の管理対象サーバーの移行設定を変更する手順は次のとおりです。

1. 管理コンソールにログインしていない場合は、ログインして、「ロックして編集」をクリックします。

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

3. 表の「名前」列で、変更するサーバーの名前をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

4. 「移行」タブをクリックします。

5. 「JTA移行ポリシー」ドロップダウン・メニューから「障害リカバリ」を選択します。

6. ページの「JTA候補サーバー」セクションで、「使用可能」リスト・ボックスの管理対象サーバーを選択し、「移動」ボタンをクリックして、「選択済み」リスト・ボックスに移動します。

7. ページのJMS候補サーバー・セクションで、「使用可能」リスト・ボックスの管理対象サーバーを選択し、「移動」ボタンをクリックして、「選択済み」リスト・ボックスに移動します。

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

14.4.3 サービス移行ポリシーの選択について

自動サービス移行を構成する場合は、クラスタごとにサービス移行ポリシーを選択します。このトピックでは、サービス移行ポリシーを選択する際のガイドラインと考慮事項を説明します。

たとえば、シングルトンを実行するか、またはパス・サービスを使用する製品やコンポーネントには、必ず1回の自動移行ポリシーが役立ちます。このポリシーでは、候補サーバーのリストにある管理対象サーバーが1つ以上動作している場合、この移行可能ターゲットでホストされるサービスは、サーバーが失敗するか管理者によって(正常または強制的に)シャットダウンされた場合に、クラスタ内のいずれかの場所でアクティブ化されます。これにより、起動時に複数の同種サービスが1つのサーバーに存在する場合があります。

このポリシーを使用する場合は、クラスタの起動を監視して、各サーバーで実行されているサーバーを識別する必要があります。その後、必要に応じて手動のフェイルバックを実行して、バランスの取れた構成にシステムを配置できます。

その他のFusion Middlewareコンポーネントには、障害回復サービスの自動移行ポリシーの方が適しています。このポリシーを使用すると、移行可能ターゲットのユーザーの優先サーバー(UPS)が起動している場合にのみ、移行可能ターゲットでホストされているサービスが起動します。

詳細は、『Oracle WebLogic Serverクラスタの管理』の手動および自動サービス移行のポリシーに関する項を参照してください。

14.4.4 クラスタ内の各管理対象サーバーのサービス移行ポリシーの設定

クラスタ内の各サーバーの移行設定を変更した後、WebLogic管理コンソールを使用して、サービスを識別し、クラスタ内の各管理対象サーバーの移行ポリシーを設定できます。

1. 管理コンソールにログインしていない場合は、ログインして、「ロックして編集」をクリックします。

2. 「ドメイン構造」ペインで、「環境」、「クラスタ」、「移行可能なターゲット」の順に展開します。

3. クラスタで最初の管理対象サーバーの名前をクリックします。

4. 「移行」タブをクリックします。

5. 「サービス移行ポリシー」ドロップダウン・メニューからクラスタ用の適切なポリシーを選択します。
詳細は、「サービス移行ポリシーの選択について」を参照してください。

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

7. クラスタ内の追加の管理対象サーバーごとに手順2から6を繰り返します。

8. 変更をアクティブ化します。

9. クラスタ内の管理対象サーバーを再起動します。

14.4.5 管理対象サーバーの再起動と自動サービス移行の検証

クラスタおよび管理対象サーバーの自動サービス移行を構成した後に、次のように構成を検証します。

1. 管理コンソールにログインしていない場合は、ログインします。

2. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に選択し、自動サービス移行用に構成したクラスタを再起動します。

3. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に開きます。

4. 「移行可能なターゲット」をクリックします。

5. 「制御」タブをクリックします。
コンソールに移行可能なターゲットおよびその現在のホスト・サーバーのリストが表示されます。

6. 「移行可能なターゲット」表で、移行可能なターゲットのいずれか1つの行を選択します。

7. 「現在のホスト・サーバー」列の値に注意してください。

8. オペレーティング・システムのコマンド行を使用して、最初の管理対象サーバーを停止します。

次のコマンドを使用して、管理対象サーバー・プロセスを強制終了し、クラッシュ・シナリオをシミュレートします。

kill -9 pid

この例では、pidを、管理対象サーバーのプロセスID (PID)に置き換えます。次のUNIXコマンドを実行すると、PIDを確認できます。

ps -ef | grep managed_server_name

プロセスを強制終了した後に、管理対象サーバーが、最初にプロセスを強制終了した後に自動的に起動するよう構成されている場合があります。この場合、再度kill –9コマンドを使用して、2番目のプロセスを強制終了する必要があります。

9. ノード・マネージャが動作しているターミナル・ウィンドウ(コンソール)を確認します。

選択した管理対象サーバーでエラーが発生したことを示すメッセージが表示されます。次のようなメッセージが表示されます。

<INFO> <domain_name> <server_name>
<The server 'server_name' with process id 4668 is no longer alive; waiting for the process to die.>
<INFO> <domain_name> <server_name>
<Server failed so attempting to restart (restart count = 1)>.

10. Oracle WebLogic Server管理コンソールに戻り、移行可能なターゲットの表をリフレッシュし、移行可能なターゲットがクラスタ内の残りの実行中の管理対象サーバーに転送されていることを確認します。

- 強制終了したプロセスの現在のホスト・サーバーが更新され、別のホストに移行されたことが表示されていることを確認します。

- プロセスの「最後の移行のステータス」列の値が「成功」であることを確認します。

11. 現在サービスをホストしている管理対象サーバーのログ・ファイルを開いて確認し、JTAエラーまたはJMSエラーを探します。

注意:

JMSテストの場合は、宛先からメッセージ数を取得し、移行可能ターゲットにスタック・メッセージがないことを確認することをお薦めします。

たとえば、共通分散宛先(UDD)の場合は、次のようにします。

a. 管理コンソールのJMSサブデプロイメント・モジュールにアクセスします。
「ドメイン構造」ペインで、「サービス」、「メッセージング」、「JMSモジュール」の順に選択します。

b. 「JMSモジュール」をクリックします。

c. 「リソースのサマリー」表で宛先をクリックし、「宛先」->「モニタリング」を選択して「メッセージ総数」と「保留メッセージ数」を取得します

d. 「モニタリング」タブを選択し、「宛先」表の「メッセージ総数」と「保留メッセージ数」の値を確認します。

14.4.6 自動サービス移行後のサービスのフェイルバック

自動サービス移行が発生した場合、Oracle WebLogic Serverでは、サーバーがオンラインに戻りクラスタに再度参加するときに、サービスが元のサーバーにフェイルバックすることはサポートされません。

そのため、フェイルオーバー中に、自動サービス移行によって特定のJMSサービスがバックアップ・サーバーに移行されたあとは、元のサーバーがオンラインに戻っても、サービスが元のサーバーに移行されることはありません。かわりに、サービスを元のサーバーに手動で移行する必要があります。

サービスを元のサーバーにフェイルバックするには、次の手順を実行します。

1. まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

2. 「ドメイン構造」ツリーで、「環境」、「クラスタ」の順に開き、「移行可能なターゲット」を選択します。

3. 1つ以上の移行可能なターゲットを一度に移行するには、「移行可能なターゲットのサマリー」ページで次を実行します。

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

b. チェック・ボックスを使用して、移行する1つまたは複数の移行可能なターゲットを選択します。

c. 「移行」をクリックします。

d. 「新しいホスト・サーバー」ドロップダウンを使用して、元の管理対象サーバーを選択します。

e. 「OK」をクリックします。
JMS関連サービスを移行するためのリクエストが発行され、構成編集ロックが解除されます。「移行可能なターゲット」表の「最後の移行のステータス」列に、リクエストされた移行が成功したのか、失敗したのかが示されます。

4. 特定の移行可能なターゲットを移行するには、「移行可能なターゲットの概要」ページで、次の手順を実行します。

a. 移行する移行可能なターゲットを選択します。

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

c. 再度、移行する移行可能なターゲットを選択します。

d. 「移行」をクリックします。

e. 「新しいホスト・サーバー」ドロップダウンを使用して、移行可能なターゲットのための新しいサーバーを選択します。

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

15 エンタープライズ・デプロイメント用のシングル・サインオンの構成

この章では、Oracle HTTP Server WebGateを構成してOracle Access Managerでシングル・サインオンを有効化する方法について説明します。

- Oracle HTTP Server WebGateについて
Oracle HTTP Server WebGateは、HTTPリクエストをインターセプトし、それを認証および認可のために既存のOracle Access Managerインスタンスに転送するWebサーバー・プラグインです。

- Oracle HTTP Server 12c Webgateの構成の一般的な前提条件
Oracle HTTP Server 12c WebGateを構成可能にするには、Oracle Access Managerの認定バージョンをインストールおよび構成しておく必要があります。

- OHS 12c Webgateの構成に関するエンタープライズ・デプロイメントの前提条件
Oracle HTTP Server Webgateを構成してエンタープライズ・デプロイメントでシングル・サインオンを有効化する場合、この項で説明されている前提条件を考慮してください。

- エンタープライズ・デプロイメント用のOracle HTTP Server 12c WebGateの構成
WEBHOST1とWEBHOST2の両方でOracle HTTP Server 12c WebGate for Oracle Access Managerを構成するには、次の手順を実行します。

- Oracle Access ManagerへのOracle HTTP Server 12c WebGateの登録
Oracle Access Manager管理コンソールを使用すると、Oracle Access ManagerにWebGateエージェントを登録できます。

- WebLogic Server認証プロバイダの設定
WebLogic Server認証プロバイダを設定するには、構成ファイルをバックアップし、Oracle Access Manager IDアサーション・プロバイダを設定し、プロバイダの順序を設定します。

- Oracle Access Managerを使用したOracle ADFおよびOPSSセキュリティの構成
一部のOracle Fusion Middleware管理コンソールでは、Oracle Access Managerシングル・サインオン(SSO)と統合可能なOracle Application Development Framework (Oracle ADF)セキュリティが使用されます。これらのアプリケーションでは、ユーザー認証にOracle Platform Security Services (OPSS) SSOを利用できますが、最初にドメインレベルのjps-config.xmlファイルを構成して、これらの機能を有効化する必要があります。

- アプリケーションのシングル・サインオンの構成
この項では、BIアプリケーションのシングル・サインオン(SSO)を有効化する方法について説明します。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

15.1 Oracle HTTP Server WebGateについて

Oracle HTTP Server WebGateは、HTTPリクエストをインターセプトし、それを認証および認可のために既存のOracle Access Managerインスタンスに転送するプラグインです。

Oracle Fusion Middleware 12cの場合、WebGateソフトウェアは、Oracle HTTP Server 12cソフトウェア・インストールの一部としてインストールされます。

WebGateの詳細は、『Oracle Access Management管理者ガイド』のOAM 11gエージェントの登録と管理に関する項を参照してください。

15.2 Oracle HTTP Server 12c Webgateの構成の一般的な前提条件

Oracle HTTP Server 12c WebGateを構成可能にするには、Oracle Access Managerの認定バージョンをインストールおよび構成しておく必要があります。

このドキュメントの公開時点では、Oracle Access Managerのサポート対象バージョンは、11gリリース2 (11.1.2.2)および11gリリース2 (11.1.2.3)でした。最新の情報は、Oracle Fusion Middlewareのサポートされるシステム構成ページで、ご使用のリリース向けの動作保証情報のドキュメントを参照してください。

注意:

本番環境の場合は、エンタープライズ・デプロイメントをホストしているマシンではなく、専用の環境にOracle Access Managerをインストールすることを強くお薦めします。

Oracle Access Managerの詳細は、Oracleヘルプ・センターのMiddlewareドキュメントにある最新のOracle Identity and Access Managementドキュメントを参照してください。

15.3 OHS 12c Webgateの構成に関するエンタープライズ・デプロイメントの前提条件

Oracle HTTP Server Webgateを構成してエンタープライズ・デプロイメントでシングル・サインオンを有効化する場合、この項で説明されている前提条件を考慮してください。

- Oracle Access Managerは、可用性の高いセキュアな本番環境の一部としてデプロイすることをお薦めします。エンタープライズ環境でのOracle Access Managerのデプロイの詳細は、ご使用のOracle Identity and Access Managementのバージョンのエンタープライズ・デプロイメント・ガイドを参照してください。

- WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlのシングル・サインオンを有効化するには、Oracle Access Managerで使用されているディレクトリ・サービス(Oracle Internet DirectoryやOracle Unified Directoryなど)に集中LDAPプロビジョニング済管理ユーザーを追加する必要があります。LDAPディレクトリに追加する必要なユーザーおよびグループの詳細は、「新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング」の指示に従ってください。

15.4 エンタープライズ・デプロイメント用のOracle HTTP Server 12c WebGateの構成

WEBHOST1とWEBHOST2の両方でOracle HTTP Server 12c WebGate for Oracle Access Managerを構成するには、次の手順を実行します。

次の手順では、OHS_ORACLE_HOMEやOHS_CONFIG_DIRなどのディレクトリ変数を、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されている値で置き換えます。

1. Web層ドメインに対して完全バックアップを実行します。

2. ディレクトリを、Oracle HTTP Server Oracleホームの次の場所に変更します。
cd OHS_ORACLE_HOME/webgate/ohs/tools/deployWebGate/

3. 次のコマンドを実行して、WebGateインスタンス・ディレクトリを作成し、OHSインスタンスでのWebGateロギングを有効にします。

./deployWebGateInstance.sh -w OHS_CONFIG_DIR -oh OHS_ORACLE_HOME

4. deployWebGateInstanceコマンドによってwebgateディレクトリとサブディレクトリが作成されたことを確認します。

ls -lart OHS_CONFIG_DIR/webgate/
total 6
drwxr-x---+ 8 orcl oinstall 20 Oct  2 07:14 ..
drwxr-xr-x+ 4 orcl oinstall  4 Oct  2 07:14 .
drwxr-xr-x+ 3 orcl oinstall  3 Oct  2 07:14 tools
drwxr-xr-x+ 3 orcl oinstall  4 Oct  2 07:14 config

5. 次のコマンドを実行し、LD_LIBRARY_PATH環境変数にOHS_ORACLE_HOME/libディレクトリ・パスが含まれるようにします。
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:OHS_ORACLE_HOME/lib

6. ディレクトリを次のディレクトリに変更します。
OHS_ORACLE_HOME/webgate/ohs/tools/setup/InstallTools

7. 次のコマンドをInstallToolsディレクトリから実行します。
./EditHttpConf -w OHS_CONFIG_DIR -oh OHS_ORACLE_HOME -o output_file_name

このコマンドは、次の内容を実行します。

- Oracle HTTP Server Oracleホームのapache_webgate.templateファイルをOracle HTTP Serverの構成ディレクトリの新しいwebgate.confファイルにコピーします。

- httpd.confファイルに1行追加して更新し、webgate.confが含まれるようにします。

- WebGate構成ファイルを生成します。このファイルのデフォルト名はwebgate.confですが、コマンドにoutput_file引数を使用して、カスタム名を使用できます。

15.5 Oracle Access ManagerへのOracle HTTP Server 12c WebGateの登録

Oracle Access Manager管理コンソールを使用すると、Oracle Access ManagerにWebGateエージェントを登録できます。

詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のコンソールを使用したOAMエージェントの登録に関する項を参照してください。

詳細は、以下のトピックを参照してください。

- RREGツールの検索と準備

- RREGインバンドおよびアウトオブバンド・モードについて

- OAM11gRequest.xmlファイルの標準プロパティの更新

- エンタープライズ・デプロイメントの保護リソース、パブリック・リソース、除外リソースの更新

- RREGツールの実行

- RREGによって生成されるファイルおよびアーティファクト

- 生成済のアーティファクトのOracle HTTP Server WebGateインスタンスの場所へのコピー

- Oracle HTTP Serverインスタンスの再起動

15.5.1 RREGツールの検索と準備

RREGツールを設定するには、次の手順を実行します。

1. アプリケーション層でいずれか1つのOracle Access Managerホストにログインします。

2. ディレクトリを、Oracle Access Manager Oracleホームの次のディレクトリに変更します。
OAM_ORACLE_HOME/oam/server/rreg/client

この例では、OAM_ORACLE_HOMEが、Oracle Access ManagerソフトウェアがインストールされているシステムのOracleホームを表しています。

注意:
Oracle Access Managerサーバーに対する権限またはアクセス権を持っていない場合は、アウトオブバンド・モードを使用して必要なファイルを生成し、Oracle Access ManagerにWebGateを登録できます。詳細は、「RREGインバンドおよびアウトオブバンド・モードについて」を参照してください。

3. oamreg.shファイルを開き、次のようにこのファイル内で次の環境変数を設定します。

- OAM_REG_HOMEを、RREGアーカイブの内容を展開したディレクトリへの絶対パスに設定します。
JDK_HOMEを、サポート対象のJDKがインストールされているマシン上のディレクトリへの絶対パスに設定します。

15.5.2 RREGインバンドおよびアウトオブバンド・モードについて

RREGツールは、インバンドとアウトオブバンドという2つのモードのいずれか1つで実行できます。

Oracle Access Managerサーバーにアクセスして、Oracle Access Manager Oracleホームから自分でRREGツールを実行する権限がある場合は、インバンド・モードを使用します。RREGツールの実行後に、生成されたアーティファクトとファイルをWebサーバーの構成ディレクトリにコピーできます。

Oracle Access Managerサーバーに対する権限またはアクセス権がない場合は、アウトオブバンド・モードを使用します。たとえば、一部の組織では、Oracle Access Managerサーバー管理者のみが、サーバー・ディレクトリにアクセスしてサーバーでの管理タスクを実行する権限を持ちます。アウトオブバンド・モードでは、プロセスは次のように機能します。

1. Oracle Access Managerサーバー管理者から、RREGアーカイブ・ファイル(RREG.tar.gz)のコピーが提供されます。このファイルは、「RREGツールの検索と準備」に説明されている場所で管理者が見つけることができます。

2. サーバー管理者によって提供されたRREG.tar.gzファイルを展開します。
次に例を示します。

gunzip RREG.tar.gz

tar -xvf RREG.tar

RREGアーカイブを解凍した後、次の場所にエージェントを登録するためのツールを見つけることができます。

RREG_HOME/bin/oamreg.sh

この例では、RREG_Homeは、RREGアーカイブの内容を展開したディレクトリです。

3. 「OAM11gRequest.xmlファイルの標準プロパティの更新」の手順を使用して、OAM11GRequest.xmlファイルを更新し、完了したOAM11GRequest.xmlファイルをOracle Access Managerサーバー管理者に送信します。

4. その後、Oracle Access Managerサーバー管理者は、「アウトオブバンド・モードでのRREGツールの実行」の手順を使用して、RREGツールを実行し、AgentID_response.xmlファイルを生成します。

5. Oracle Access Managerサーバー管理者から、AgentID_response.xmlファイルが送信されます。

6. 「アウトオブバンド・モードでのRREGツールの実行」の手順を使用して、クライアント・システムで、AgentID_response.xmlファイルでRREGツールを実行し、必要なアーティファクトとファイルを生成します。

15.5.3 OAM11gRequest.xmlファイルの標準プロパティの更新

WebGateエージェントをOracle Access Managerに登録するには、OAM11gRequest.xmlファイルで必要なプロパティを更新しておく必要があります。

注意:

提供されたXMLファイルのほとんどのパラメータにデフォルト値を使用する場合は、リストされていないすべてのフィールドにデフォルト値が使用される簡略バージョン(OAM11gRequest_short.xml)を使用できます。

このタスクを実行するには、次のようにします。

1. インバンド・モードを使用している場合は、ディレクトリを、ディレクトリ内の次の場所に変更します。

OAM_ORACLE_HOME/oam/server/rreg/client

アウトオブバンド・モードを使用している場合は、ディレクトリを、RREGアーカイブを解凍した場所に変更します。

2. OAM11gRequest.xmlファイル・テンプレートのコピーを作成します。

3. ファイルにリストされているプロパティを確認し、OAM11gRequest.xmlファイルのコピーを更新して、プロパティが環境に固有のホスト名およびその他の値を参照するようにします。

OAM11gRequest.xmlプロパティ

設定値

serverAddress

Oracle Access Managerドメイン内の管理サーバーのホストおよびポート。

agentName

エージェントのカスタム名。通常、シングル・サインオン用に構成しているFusion Middleware製品を識別する名前を使用します。

applicationDomain

シングル・サインオン用に構成しているWeb層ホストおよびFMWコンポーネントを識別する値。

security

Oracle Access Managerサーバーのセキュリティ・モード。オープン・モード、簡易モードまたは証明書モードを指定します。

エンタープライズ・デプロイメントでは、認証および認可トラフィックの暗号化にカスタム・セキュリティ証明書を実装する追加の要件が存在する場合を除き、簡易モードを使用することをお薦めします。

オープン・モードではOracle Access Managerサーバーとの間のトラフィックが暗号化されないため、ほとんどの場合でオープン・モードを使用しないでください。

証明書モードの使用方法やOracle Access Managerでサポートされるセキュリティ・モード全般については、『Oracle Access Management管理者ガイド』のOAMサーバーとWebGateの間のセキュア通信に関する項を参照してください。

cachePragmaHeader

private

cacheControlHeader

private

ipValidation

0

<ipValidation>0<ipValidation>

ipValidationExceptions

フロントエンドのロード・バランサのIPアドレス。次に例を示します。

<ipValidationExceptions>
<ipAddress>130.35.165.42</ipAddress>
</ipValidation>

agentBaseUrl

Oracle HTTP Server 12c WebGateがインストールされているマシンの、ホストとポート。

15.5.4 エンタープライズ・デプロイメントの保護リソース、パブリック・リソース、除外リソースの更新

シングル・サインオン用にOracle Fusion Middleware環境を設定する場合は、Oracle Access Managerでシングル・サインオンによって保護する一連のURLを識別します。これらは、OAM11gRequest.xmlファイルの特定のセクションを使用して識別します。URLを識別する手順は次のとおりです。

1. OAM11gRequest.xmlファイルを編集用に開いていない場合は、このファイルを検索して、テキスト・エディタで開きます。

詳細は、次を参照してください。

- RREGツールの検索と準備

- OAM11gRequest.xmlファイルの標準プロパティの更新

2. ファイルのサンプル・エントリを削除して、次の例に示されているようにファイルの適切なセクションに保護リソース、パブリック・リソースおよび除外リソースのリストを入力します。

注意:

Oracle Access Manager 11gリリース2 (11.1.2.2)以降を使用している場合は、以前のバージョンのOracle Access Managerとの下位互換性用にワイルドカード構文(.../*)を使用したエントリが含まれます。

<protectedResourcesList>
<resource>/analytics/saw.dll</resource>
<resource>/bicontent</resource>
<resource>/xmlpserver</resource>
<resource>/mapviewer</resource>
<resource>/bicomposer</resource>
<resource>/bisearch</resource>
<resource>/em</resource>
<resource>/em/…/*</resource>
<resource>/console</resource>
<resource>/console/…/*</resource>
<resource>/mobile</resource>
<resource>/mobile/.../*</resource>
<resource>/va</resource>
</protectedResourcesList>
<publicResourcesList>
<resource>/analytics</resource>
<resource>/analytics-ws/saw.dll</resource>
<resource>/aps</resource>
<resource>/aps/JAPI</resource>
<resource>/aps/Essbase</resource>
</publicResourcesList>
<excludedResourcesList>
<resource>/biservices</resource>
<resource>/analytics-bi-adf</resource>
<resource>/xmlpserver/Guest</resource>
<resource>/xmlpserver/ReportTemplateService.xls</resource>
<resource>/xmlpserver/report_service</resource>
<resource>/xmlpserver/services</resource>
<resource>/analytics/saw.dll/wsdl</resource>
<resource>/analytics-ws</resource>
<resource>/ws/.../*</resource>
<resource>/wsm-pm</resource>
<resource>/wsm-pm/.../*</resource>
</excludedResourcesList>

3. OAM11GRequest.xmlファイルを保存して閉じます。

15.5.5 RREGツールの実行

次のトピックでは、RREGツールを実行してOracle Access ManagerにOracle HTTP Server WebGateを登録する方法について説明します。

- インバンド・モードでのRREGツールの実行

- アウトオブバンド・モードでのRREGツールの実行

15.5.5.1 インバンド・モードでのRREGツールの実行

RREGツールをインバンド・モードで実行する手順は次のとおりです。

1. ディレクトリを、RREGホーム・ディレクトリに変更します。
インバンド・モードを使用している場合、RREGディレクトリはOracle Access Manager Oracleホーム内にあります。

OAM_ORACLE_HOME/oam/server/rreg/client

アウトオブバンド・モードを使用している場合、RREGホーム・ディレクトリは、RREGアーカイブを解凍した場所になります。

2. ディレクトリを、RREGホーム・ディレクトリ内のbinディレクトリに変更します。

cd RREG_HOME/bin/

3. ファイルを実行できるように、oamreg.shコマンドの権限を設定します。

chmod +x oamreg.sh

4. 次のコマンドを実行します。

./oamreg.sh inband input/OAM11GRequest.xml

この例の説明は、次のとおりです。

- 編集されたOAM11GRequest.xmlファイルがRREG_HOME/inputディレクトリに配置されていることが前提となります。

- このコマンドの出力は、次のディレクトリに保存されます。

RREG_HOME/output/

次の例はRREGセッションのサンプルです。

Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: /u01/oracle/products/fmw/iam_home/oam/server/rreg/client/rreg/input/OAM11GWCCDomainRequest.xml
Enter admin username:weblogic_idm
Username: weblogic_idm
Enter admin password:
Do you want to enter a Webgate password?(y/n):
n
Do you want to import an URIs file?(y/n):
n

----------------------------------------
Request summary:
OAM11G Agent Name:WCC1221_EDG_AGENT
URL String:null
Registering in Mode:inband
Your registration request is being sent to the Admin server at: http://host1.example.com:7001
----------------------------------------

Jul 08, 2015 7:18:13 PM oracle.security.jps.util.JpsUtil disableAudit
INFO: JpsUtil: isAuditDisabled set to true
Jul 08, 2015 7:18:14 PM oracle.security.jps.util.JpsUtil disableAudit
INFO: JpsUtil: isAuditDisabled set to true
Inband registration process completed successfully! Output artifacts are created in the output folder.

15.5.5.2 アウトオブバンド・モードでのRREGツールの実行

Oracle Access ManagerサーバーでRREGツールをアウトオブバンド・モードで実行する場合、Oracle Access Managerサーバー管理者は次のコマンドを使用します。

RREG_HOME/bin/oamreg.sh outofband input/OAM11GRequest.xml

この例の説明は、次のとおりです。

- RREG_HOMEを、サーバーでRREGアーカイブ・ファイルが解凍された場所で置き換えます。

- 編集されたOAM11GRequest.xmlファイルは、RREG_HOME/inputディレクトリに配置されています。

- RREGツールでは、このコマンドの出力(AgentID_response.xmlファイル)が次のディレクトリに保存されます。

RREG_HOME/output/

Oracle Access Managerサーバー管理者は、AgentID_response.xmlをOAM11GRequest.xmlファイルを提供したユーザーに送信できます。

Webサーバーのクライアント・マシンでRREGツールをアウトオブバンド・モードで実行するには、次のコマンドを使用します。

RREG_HOME/bin/oamreg.sh outofband input/AgentID_response.xml

この例の説明は、次のとおりです。

- RREG_HOMEを、クライアント・システムでRREGアーカイブ・ファイルを解凍した場所で置き換えます。

- Oracle Access Managerサーバー管理者から提供されたAgentID_response.xmlファイルは、RREG_HOME/inputディレクトリにあります。

- RREGツールでは、このコマンドの出力(WebGateソフトウェアの登録に必要なアーティファクトとファイル)がクライアント・マシンの次のディレクトリに保存されます。

RREG_HOME/output/

15.5.6 RREGによって生成されるファイルおよびアーティファクト

RREGツールによって生成されるファイルは、WebGateとOracle Access Managerサーバーの間の通信に使用しているセキュリティ・レベルによって異なります。サポートされるセキュリティ・レベルの詳細は、『Oracle Access Management管理者ガイド』のOAMサーバーとWebGateの間のセキュア通信に関する項を参照してください。

このトピックでは、RREG_HOMEへの参照を、RREGツールを実行したディレクトリのパスで置き換える必要があります。これは通常、Oracle Access Managerサーバーの次のディレクトリまたはRREGアーカイブを解凍したディレクトリになります(アウトオブバンド・モードを使用している場合)。

OAM_ORACLE_HOME/oam/server/rreg/client

次の表は、Oracle Access Managerのセキュリティ・レベルにかかわらず、RREGツールによって常に生成されるアーティファクトを示しています。

ファイル

場所

cwallet.sso

RREG_HOME/output/Agent_ID/

ObAccessClient.xml

RREG_HOME/output/Agent_ID/

次の表は、Oracle Access ManagerにSIMPLEまたはCERTセキュリティ・レベルを使用している場合に作成される追加ファイルを示しています。

ファイル

場所

aaa_key.pem

RREG_HOME/output/Agent_ID/

aaa_cert.pem

RREG_HOME/output/Agent_ID/

password.xml

RREG_HOME/output/Agent_ID/

password.xmlファイルには、SSLで使用される秘密鍵を暗号化するための不明瞭化されたグローバル・パスフレーズが含まれます。このパスフレーズは、サーバーで使用されているパスフレーズと異なるものを使用できます。

RREGによって生成されたファイルを使用して証明書リクエストを生成し、サードパーティの認証局に署名を求めることができます。既存の証明書をインストールするには、既存のaaa_cert.pemおよびaaa_chain.pemファイルをpassword.xmlおよびaaa_key.pemと合せて使用する必要があります。

15.5.7 生成済のアーティファクトのOracle HTTP Server WebGateインスタンスの場所へのコピー

RREGツールによって必要なアーティファクトが生成された後に、RREG_Home/output/agent_IDディレクトリのアーティファクトをWeb層ホストのOracle HTTP Serverの構成ディレクトリに手動でコピーします。

Oracle HTTP Serverの構成ディレクトリ内のファイルの場所は、Oracle Access Managerのセキュリティ・モード設定(OPEN、SIMPLEまたはCERT)によって異なります。

次の表は、Oracle Access Managerのセキュリティ・モード設定に基づいた、Oracle HTTPの構成ディレクトリ内の生成された各アーティファクトの必要な場所を示しています。存在しない場合はディレクトリの作成が必要になることがあります。たとえば、walletディレクトリが構成ディレクトリに存在しない場合があります。

注意:

エンタープライズ・デプロイメントでは、認証および認可トラフィックの暗号化にカスタム・セキュリティ証明書を実装する追加の要件が存在する場合を除き、簡易モードを使用することをお薦めします。オープン・モードまたは証明書モードの使用方法の詳細は、利便性のため、ここで説明します。

オープン・モードではOracle Access Managerサーバーとの間のトラフィックが暗号化されないため、オープン・モードを使用しないでください。

証明書モードの使用方法やOracle Access Managerでサポートされるセキュリティ・モード全般については、『Oracle Access Management管理者ガイド』のOAMサーバーとWebGateの間のセキュア通信に関する項を参照してください。

ファイル

OPENモードを使用する場合の場所

SIMPLEモードを使用する場合の場所

CERTモードを使用する場合の場所

wallet/cwallet.sso

OHS_CONFIG_DIR/webgate/config/wallet

OHS_CONFIG_DIR/webgate/config/wallet/

OHS_CONFIG_DIR/webgate/config/wallet/

ObAccessClient.xml

OHS_CONFIG_DIR/webgate/config

OHS_CONFIG_DIR/webgate/config/

OHS_CONFIG_DIR/webgate/config/

password.xml

N/A

OHS_CONFIG_DIR/webgate/config/

OHS_CONFIG_DIR/webgate/config/

aaa_key.pem

N/A

OHS_CONFIG_DIR/webgate/config/simple/

OHS_CONFIG_DIR/webgate/config/

aaa_cert.pem

N/A

OHS_CONFIG_DIR/webgate/config/simple/

OHS_CONFIG_DIR/webgate/config/

注意:
ObAccessClient.xmlを新しいディレクトリにコピーする場合は、WEBHOST1の最初のOracle HTTP Serverの場所のキャッシュの場所から古いObAccessClient.xmlファイルを削除する必要があります。

OHS_DOMAIN_HOME/servers/ohs1/cache/config/

WEBHOST2の2番目のOracle HTTP Serverインスタンスに対しても同様の手順を実行する必要があります。

OHS_DOMAIN_HOME/servers/ohs2/cache/config/

15.5.8 Oracle HTTP Serverインスタンスの再起動

Oracle HTTP Serverインスタンスの再起動の詳細は、『Oracle HTTP Serverの管理』のWLSTを使用したOracle HTTP Serverインスタンスの再起動に関する項を参照してください。

WebLogic ServerドメインにOracle HTTP Serverを構成した場合、Oracle Fusion Middleware Controlを使用してOracle HTTP Serverインスタンスを再起動することもできます。詳細は、Oracle HTTP Server管理者ガイドのFusion Middleware Controlを使用したOracle HTTP Serverインスタンスの再起動に関する項を参照してください。

15.6 WebLogic Server認証プロバイダの設定

WebLogic Server認証プロバイダを設定するには、構成ファイルをバックアップし、Oracle Access Manager IDアサーション・プロバイダを設定し、プロバイダの順序を設定します。

次のトピックでは、「新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング」の手順に従って、LDAPオーセンティケータを構成済であることが前提となります。LDAP認証プロバイダをまだ作成していない場合は、作成してからこの項を読み進めてください。

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

- Oracle Access Manager IDアサーション・プロバイダの設定

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

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

まず、次の関連する構成ファイルをバックアップする必要があります。

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

管理サーバーのboot.propertiesファイルもバックアップします。

ASERVER_HOME/servers/AdminServer/security/boot.properties

15.6.2 Oracle Access Manager IDアサーション・プロバイダの設定

Oracle WebLogic Server管理コンソールを使用してOracle Access Manager IDアサーション・プロバイダを設定します。

Oracle Access Manager IDアサーション・プロバイダを設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

4. myrealmというデフォルト・レルム・エントリをクリックします。

5. 「プロバイダ」タブをクリックします。

6. 「新規」をクリックし、ドロップダウン・メニューからアサータ・タイプ「OAMIdentityAsserter」を選択します。

7. アサータに名前(OAM ID Asserterなど)を付け、「OK」をクリックします。

8. 新しく追加したアサータをクリックし、Oracle Access Manager IDアサーション・プロバイダの構成画面を確認します。

9. 制御フラグを「必須」に設定します。

10. 「選択済み」タイプで「ObSSOCookie」および「OAM_REMOTE_USER」の2つのオプションを選択します。

11. 「保存」をクリックして設定を保存します。

12. 「変更のアクティブ化」をクリックして変更を伝播します。

13. 管理サーバーおよび管理対象サーバーを再起動します。

15.6.3 プロバイダの順序の設定

WebLogic Server管理コンソールを使用してIDアサーション・プロバイダと認証プロバイダを設定します。

プロバイダの順序を設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

4. myrealmというデフォルト・レルム・エントリをクリックします。

5. 「プロバイダ」タブをクリックします。

6. 各認証プロバイダの制御フラグが次のように設定されていることを確認することによって、Oracle Access Manager IDアサーション・プロバイダ、LDAP認証プロバイダおよびデフォルト認証プロバイダを並べ替えます。

- Oracle Access Manager IDアサーション・プロバイダ: REQUIRED

- LDAP認証プロバイダ: SUFFICIENT

- デフォルト認証プロバイダ(DefaultAuthenticator): SUFFICIENT

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

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

9. 管理サーバー、管理対象サーバーおよびシステム・コンポーネントを再起動します。

15.7 Oracle Access Managerを使用したOracle ADFおよびOPSSセキュリティの構成

一部のOracle Fusion Middleware管理コンソールでは、Oracle Access Managerシングル・サインオン(SSO)と統合可能なOracle Application Development Framework (Oracle ADF)セキュリティが使用されます。これらのアプリケーションでは、ユーザー認証にOracle Platform Security Services (OPSS) SSOを利用できますが、最初にドメインレベルのjps-config.xmlファイルを構成して、これらの機能を有効化する必要があります。

ドメインレベルのjps-config.xmlファイルは、Oracle Fusion Middlewareドメインの作成後に次の場所に配置されます。

DOMAIN_HOME/config/fmwconfig/jps-config.xml

注意:

ドメインレベルのjps-config.xmlを、カスタム・アプリケーションとともにデプロイされるjps-config.xmlと混同しないでください。

OPSSの構成を更新して、Oracle Access ManagerのSSOアクションで委任するには、次の手順を実行します。

1. ディレクトリを次のディレクトリに変更します。

cd ORACLE_COMMON_HOME/common/bin

2. WebLogic Server Scripting Tool (WLST)を起動します。

./wlst.sh

3. 次のWLSTコマンドを使用して管理サーバーに接続します。

connect(‘admin_user’,’admin_password’,’admin_url’)

次に例を示します。

connect(‘weblogic’,’mypassword’,’t3://ADMINVHN:7001’)

4. 次のように、addOAMSSOProviderコマンドを実行します。

addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", logouturi="/oamsso/logout.html")

次の表は、addOAMSSOProviderコマンドにおける各引数の予想される値を定義しています。

引数

定義

loginuri

ログイン・ページのURIを指定します

注意: ADFセキュリティが有効なアプリケーションの場合、"<context-root/adfAuthentication"をloginuriパラメータに指定する必要があります。

次に例を示します。

/${app.context}/adfAuthentication

手順を示します。

a. たとえば、ユーザーがOPSSの認証ポリシーで保護されているリソースにアクセスします。

b. ユーザーがまだ認証されていない場合、ADFはユーザーを'loginuri'で設定したURIにリダイレクトします。

c. Access Managerには'loginuri'の値を保護するポリシー、たとえば、"/<context-root/adfAuthenticationが存在する必要があります。

d. ADFがこのURIにリダイレクトすると、Access Managerにより「ログイン」ページが表示されます(このURI用のAccess Managerで構成された認証スキームにより異なる)。

logouturi

ログアウト・ページのURIを指定します

注意:

- ADFセキュリティが有効なアプリケーションの場合、『Oracle Access Management管理者ガイド』の11g WebGateが関連するセッションの集中ログアウトの構成に関する項にあるログアウト・ガイドラインに基づいてlogouturiを構成する必要があります。

- WebGate 11gを使用している場合、logouturiの値は11g WebGateの管理者から検索される必要があります。

- WebGate 10gを使用している場合、logouturiの値は/oamsso/logout.htmlである必要があります。

autologinuri

自動ログイン・ページのURIを指定します。これはオプションのパラメータです。

5. 管理サーバーから切断します。

disconnect()

6. 管理サーバーとすべての管理対象サーバーを再起動します。

15.8 アプリケーションのシングル・サインオンの構成

この項では、BIアプリケーションのシングル・サインオン(SSO)を有効化する方法について説明します。

次のトピックが含まれています

- Oracle BI EEのためのシングル・サインオンおよびOracle Access Managerの有効化

- Oracle BI Publisherのためのシングル・サインオンおよびOracle Access Managerの有効化

15.8.1 Oracle BI EEのためのシングル・サインオンおよびOracle Access Managerの有効化

次の手順を実行して、Oracle Business Intelligence Enterprise Edition (BI EE)でシングル・サインオン(SSO)とOracle Access Managerを有効化します。

1. WLSTを起動します。

cd ORACLE_HOME/oracle_common/common/bin
./wlst.sh

2. 更新用のBI管理サーバー・ドメインを開きます。

wls:/offline> readDomain(‘ASERVER_HOME’)

この例では、ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

3. 次のコマンドを実行して、Oracle BI EEでSSOを有効化し、Oracle BIプレゼンテーション・サービス・プロセスのログアウト情報を構成します。

wls:/offline/bi_domain> enableBISingleSignOn('ASERVER_HOME','http://oam_host:oam_port/oamsso/logout.html')

この例の説明は、次のとおりです。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- http://oam_host:oam_port/oamsso/logout.htmlは、SSOプロバイダ(Oracle Access Manager)のログオフURLです。

4. ドメインを更新して保存します。

wls:/offline/bi_domain> updateDomain()

5. ドメインを閉じます。

wls:/offline/bi_domain> closeDomain()

6. WLSTを終了します。

wls:/offline> exit()

7. 管理サーバー、管理対象サーバーおよびシステム・コンポーネントを再起動します。

15.8.2 Oracle BI Publisherのためのシングル・サインオンおよびOracle Access Managerの有効化

次の手順を実行して、Oracle BI Publisherでシングル・サインオン(SSO)とOracle Access Managerを有効化します。

1. 次のどちらかのURLを使用してBI Publisherにログインします。

- http://BIHOST1VHN1:7003/xmlpserver

- http://BIHOST2VHN1:7003/xmlpserver

次にリダイレクトされます。

http://bi.example.com/xmlpserver

2. BI Publisherで、「管理」 > 「セキュリティ構成」ページに移動し、SSOを有効にします。

3. 「セキュリティ構成」ページのシングル・サインオン・セクションで次の情報を入力します。

a. 「シングル・サインオンの使用」を選択します。

b. 「シングル・サインオン・タイプ」で「Oracle Access Manager」を選択します。

c. 「シングル・サインオフURL」で、次の形式でURLを入力します。

http://oam_host:oam_port/oamsso/logout.html

d. 「ユーザー名パラメータ」にOAM_REMOTE_USERと入力します。

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

5. WebLogic管理コンソールからbipublisherアプリケーションを再起動します。
bipublisherアプリケーションの再起動の詳細は、『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle WebLogic Server管理コンソールを使用した、Javaコンポーネントの起動と停止に関する項を参照してください。

A Oracle RACでのマルチ・データ・ソースの使用

新しいOracle RACアプリケーションを構築する際には、GridLinkデータ・ソースを使用することをお薦めします。ただし、GridLinkデータ・ソースをサポートしないレガシー・アプリケーションとデータベースを使用している場合、この付録の次の情報を参照します。

この付録では、マルチ・データ・ソースとOracle RACについて説明し、エンタープライズ・デプロイメント用にマルチ・データ・ソースを構成する手順について説明します。

- マルチ・データ・ソースとOracle RACについて
マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。

- エンタープライズ・デプロイメントでマルチ・データ・ソースを構成するための標準的な手順
ドメインを構成するときにデータ・ソースを構成します。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLink用の説明を、この項で説明されている指示に置き換えてください。

A.1 マルチ・データ・ソースとOracle RACについて

マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。

通常、このようなマルチ・データ・ソースへの接続リクエストはすべて、リストの先頭のデータ・ソースによって処理されます。データベース接続テストが失敗して接続を置き換えられなかった場合、またはデータ・ソースが中断された場合は、リストの次のデータ・ソースから順番に接続が検索されます。

Oracle RACを使用したマルチ・データ・ソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のOracle RACを使用したマルチ・データ・ソースの使用に関する項を参照してください。

A.2 エンタープライズ・デプロイメントでマルチ・データ・ソースを構成するための標準的な手順

ドメインを構成するときにデータ・ソースを構成します。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLink用の説明を、この項で説明されている指示に置き換えてください。

たとえば、エンタープライズ・デプロイメント参照トポロジに最初の管理ドメインを構成する場合、構成ウィザードを使用してドメインの特性およびデータ・ソースを定義します。

このエンタープライズ・デプロイメント・ガイド内のトポロジの構成手順には、Oracle RACでGridLinkデータ・ソースを定義するための具体的な手順が含まれています。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLink用の説明を次のように置き換えてください。

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

a. 適切なスキーマを選択します。

b. コンポーネント・スキーマのRAC構成については、「RACマルチ・データ・ソースへ変換」を選択します。

c. リポジトリ作成ユーティリティを実行した際、次のデータ・ソースがスキーマの接頭辞とともに表示されることを確認してください。

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

2. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面が表示されます(図A-1 )。

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

この画面で、次の手順を実行します。

a. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。

- サービス名: データベースのサービス名を入力します。

- ユーザー名: スキーマの完全なユーザー名(接頭辞を含む)を入力します。

- パスワード: スキーマへのアクセスに使用するパスワードを入力します。

b. ホスト名、インスタンス名およびポートを入力します。

c. 「追加」をクリックします。

d. この手順をOracle RACインスタンスごとに実行します。

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

3. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

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 Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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を参照してください。