| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 12c (12.2.1.4.0) E96110-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 12c (12.2.1.4.0) E96110-02 |
|
|
前 |
次 |
この章では、エンタープライズ・デプロイメントの開始点として使用できるOracle Business Intelligence (BI)ドメインのインストールおよび構成方法について説明します。
この章には、Oracle BIドメインの作成、データベース・スキーマの作成およびOracle BIドメインの構成を行う際に使用される変数に関する情報が記載されています。
DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。親トピック: エンタープライズ・デプロイメントの構成
この章の作業を実行する場合、この項にリストされているディレクトリ変数を参照します。
ディレクトリ変数は、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されています。
ORACLE_HOME
ASERVER_HOME
MSERVER_HOME
APPLICATION_HOME
JAVA_HOME
さらに、「エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスとホスト名を参照することになります。
ADMINVHN
DBHOST1
DBHOST2
BIHOST1
Oracle RACデータベースのSCANアドレス(DB-SCAN.example.com)
BIHOST1VHN
BIHOST2VHN
初期Business Intelligence (BI)ドメインを作成する前に、次の重要な概念を確認してください。
エンタープライズ・デプロイメントの初期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に関する項を参照してください。
親トピック: 初期BIドメインの理解
初期BIドメインのこれらの主な特徴を確認してください。これらの特徴を確認して理解することで、ドメインの構成手順の目的やコンテキストに対する理解が深まります。
これらの特徴の多くについては、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。
表10-1 初期BIドメインの特徴
| ドメインの特徴 | 追加情報 |
|---|---|
管理サーバーに別個の仮想IP (VIP)アドレスを使用。 |
|
ドメイン内の管理サーバーと管理対象サーバーに別個のドメイン・ディレクトリを使用。 |
|
各ホスト上の管理サーバーと管理対象サーバーにドメインごとのノード・マネージャと別個のノード・マネージャ・プロセスを使用。 |
|
別途インストールされたLDAPベースの認証プロバイダが必要。 |
親トピック: 初期BIドメインの理解
この項を使用して、エンタープライズ・デプロイメント用の新しいドメインを構成する準備として、Oracle Fusion Middleware Infrastructureソフトウェアをインストールします。
Oracle Fusion Middlewareでは、動作保証されたJava Development Kit (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のダウンロードに必ず移動してください。
親トピック: サポートされているJDKのインストール
Oracle Fusion Middlewareでは、動作保証されたJava Development Kit (JDK)がシステムにインストールされている必要があります。
JDKを次の場所にインストールする必要があります。
共有ストレージ・デバイスで、JDKを/u01/oracle/products/jdkディレクトリにインストールします。各アプリケーション層のホスト・コンピュータからJDKにアクセスできます。
Web層の各ホスト・コンピュータのローカル記憶域デバイスDMZに配置されるWeb層ホスト・コンピュータは、アプリケーション層の共有記憶域に必ずしもアクセスできるとはかぎりません。
JDKソフトウェアの推奨場所の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。
親トピック: サポートされているJDKのインストール
インストール・プログラムを起動するには、次の手順を実行します。
インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明は、「インストール画面のナビゲート」を参照してください。
インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。
インストール画面についての詳細情報が必要な場合は、画面の名前をクリックするか、画面上で「ヘルプ」ボタンをクリックします。
表10-2 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 Universal Installerによるソフトウェアのインストール』の「サイレント・モードでのOracle Universal Installerの使用」を参照してください。 |
インストールの進行状況 |
この画面では、インストールの進行状況を参照できます。 |
インストール完了 |
インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。 |
この項を使用して、エンタープライズ・デプロイメント用の新しいドメインを構成する準備として、Oracle Business Intelligenceソフトウェアをインストールします。
次の手順を使用して、BIインストーラを起動します。
各ディストリビューションの実際のファイル名の詳細は、エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得を参照してください。
インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明は、「インストール画面のナビゲート」を参照してください。
インストール・プログラムでは、表10-3に記載された順番で一連の画面が表示されます。
インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。
表10-3 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システム要件と仕様を参照してください。 |
自動更新 - パッチの選択 |
この画面は、次の両方に当てはまる場合に表示されます:
この画面には、自動更新機能で見つかったパッチがリストされます。1つ以上のパッチを選択し、「次へ」をクリックして、選択したパッチをOracleホームに適用します。 |
インストール・サマリー |
この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。 サイレント・インストールまたはコマンドライン・インストールの詳細は、『Oracle Universal Installerによるソフトウェアのインストール』の「サイレント・モードでのOracle Universal Installerの使用」を参照してください。 |
インストールの進行状況 |
この画面では、インストールの進行状況を参照できます。 |
インストール完了 |
インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを閉じます。 |
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の詳細とスキーマを作成してデータベースに格納する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のスキーマ作成の準備に関する項を参照してください。
動作保証されたデータベースを適切にインストールして構成し、そのデータベースを起動して稼働させておく必要があります。
詳細は、次のリソースを参照してください。
「エンタープライズ・デプロイメント用のデータベースの準備」。データベース・サービスの作成、ラージ・オブジェクト(LOB)でのSecureFilesの使用、およびエンタープライズ・デプロイメントにおいて重要なその他のトピックに関する情報が含まれています。
『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のOracle Fusion Middlewareインストールのデータベース要件の理解に関する項。
親トピック: データベース・スキーマの作成
この項で説明する手順を実行して、Oracle Business Intelligenceドメインにスキーマを作成します。
「ようこそ」画面で、RCUのバージョン番号を確認します。「次へ」をクリックして開始します。
データベースでDBAアクティビティを実行するために必要な権限を持っている場合は、「リポジトリの作成」画面で「システム・ロードおよび製品ロード」を選択します。このドキュメントの手順では、必要な権限があることを想定しています。
データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。このオプションによって生成されるSQLスクリプトをデータベース管理者に提出できます。『リポジトリ作成ユーティリティによるスキーマの作成』のシステム・ロードと製品ロードの理解に関する項を参照してください。
ヒント:
この画面の選択内容の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のリポジトリの作成に関する項を参照してください。
「データベース接続の詳細」画面に、データベースに接続するためのRCUに関するデータベース接続の詳細が表示されます。
「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。
「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。
ヒント:
この画面の選択内容の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でデータベース接続の詳細に関する項を参照してください。
Oracle Fusion Middlewareスキーマの識別に使用するカスタム接頭辞を指定します。
カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。このガイドでは、FMW1221という接頭辞を使用します。
ヒント:
ここで入力したカスタム接頭辞を書き留めてください。これは後でドメインの作成時に必要になります。
「AS共通スキーマ」を選択します。
「AS共通スキーマ」を選択すると、このセクションのすべてのスキーマが自動的に選択されます。
Common Infrastructure Servicesと呼ばれるスキーマも自動的に作成されます。このスキーマはグレー表示されており、選択も選択解除もできません。このスキーマ(STBスキーマ)を使用すると、ドメインの構成中にRCUから情報を取得できます。詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。
Business Intelligenceプラットフォームを選択します。
ヒント:
カスタム接頭辞の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のカスタム接頭辞の理解に関する項を参照してください。
マルチドメイン環境のスキーマを構成する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のスキーマの作成計画に関する項を参照してください。
「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。
スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。
ヒント:
この画面で設定したパスワードを書き留めてください。これは後でドメインの作成時に必要になります。
RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。
このガイドでは、残りの画面のデフォルト設定を受け入れるか、RCUでのOracle Fusion Middlewareスキーマの作成方法および必要な表領域の使用方法をカスタマイズします。
『Oracle Fusion Middlewareリポジトリ作成ユーティリティによるスキーマの作成』のリポジトリ作成ユーティリティに関する項を参照してください。
「完了サマリー」画面が表示されたら、「閉じる」をクリックしてRCUを閉じます。
親トピック: データベース・スキーマの作成
この項では、構成ウィザードを使用してWebLogicドメインを作成するための指示について説明します。
ドメイン作成に使用可能なその他の方法の詳細は、『構成ウィザードによるWebLogicドメインの作成』のWebLogicドメインの作成、拡張および管理のための追加ツールに関する項を参照してください。
この項では、次のタスクについて説明します。
ドメインの構成を開始するには、BIHOST1上のOracle Fusion Middleware Oracleホームで次のコマンドを実行します。
ORACLE_HOME/oracle_common/common/bin/config.sh
親トピック: BIドメインの構成
「構成タイプ」画面で、「新規ドメインの作成」を選択します。
「ドメインの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOME変数の値を指定します。
ヒント:
この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。
「テンプレート」画面では、「製品テンプレートを使用してドメインを作成」が選択されていることを確認し、次のテンプレートを選択します。
Oracle BIEE Suite - 12.2.1.4.0 [bi]
このテンプレートを選択すると、次の依存性が自動的に選択されます。
Oracle MapViewer – 12.2.1.4.0 [oracle_common]
Oracle Enterprise Manager - 12.2.1.4.0 [em]
Oracle WSM Policy Manager - 12.2.1.4.0 [oracle_common]
Oracle JRF - 12.2.1.4.0 [oracle_common]
WebLogic Coherenceクラスタの拡張 - 12.2.1.4.0 [wlserver]
Oracle BI Publisher Suite - 12.2.1.4.0 [bi]
Oracle BI Essbase Suite - 12.2.1.4.0 [bi]
また、基本的なWebLogicサーバー・ドメイン - 12.2.1.4.0 [wlserver]テンプレートはすでに選択され、グレー表示されている必要があります。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。
「高可用性のオプション」画面を使用して、高可用性に反映されるサービス移行および永続性の設定を構成できます。
「自動サービス移行の有効化」オプションを選択すると、フェイルオーバーのために、固定されたサービスが正常な管理対象サーバーに自動的に移行されます。ただし、Oracle BIは自動サービス移行をサポートしていません。「自動サービス移行の有効化」オプションが選択されていないことを確認します。
「JTAトランザクション・ログ永続性」セクションには、「デフォルトの永続ストア」および「JDBC TLogストア」の2つのオプションがあります。「JDBC TLogストア」を選択することをお薦めします。このオプションを使用して、コンポーネントでそのすべてのJMSサーバーにJDBCストアが使用されるように構成します。構成を完了すると、クラスタおよびJDBC永続ストアがトランザクション・ログに対して設定されます。
「JMSサーバー永続性」を「JMS JDBCストア」に設定します。
永続的なJMSストアは、永続メッセージ・データと恒久サブスクライバを格納するための物理的なリポジトリです。ディスクベースのファイル・ストアにも、JDBC対応データベースにもなります。「JMSファイル・ストア」は、メモリーを使い果した場合のメッセージのディスクのページングに使用できます。
JMSファイル・ストア — JMSファイル・ストアを使用するようにコンポーネントを構成します。
JMS JDBCストア — すべてのJMSサーバーに対してJDBCストアを使用するようにコンポーネントを構成します。構成を完了すると、クラスタおよびJDBC永続ストアがJMSサーバーに対して構成されます。
「ファイル・ストア」の「設定の変更」オプションを「拡張構成」画面で選択し、設定を変更します。「ファイル・ストア」画面で、ファイル・ストア名、ディレクトリ、および同期書込みポリシーを設定できます。
「アプリケーションの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。
ヒント:
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のアプリケーションの場所に関する項を参照してください。
「管理者アカウント」画面では、ドメインに対するデフォルトのWebLogic管理者アカウントにユーザー名とパスワードを指定します。
この画面で指定したユーザー名およびパスワードを書き留めておいてください。これらの資格証明は後でドメインの管理サーバーを起動して接続する際に必要になります。
「ドメイン・モードおよびJDK」画面では、次の操作を実行します。
「ドメイン・モード」フィールドで、「本番」を選択します。
「JDK」フィールドで「Oracle Hotspot JDK」を選択します。
「本番モード」をこの画面で選択すると、環境で高度なセキュリティが実現され、アプリケーションのデプロイと管理サーバーの起動でユーザー名とパスワードが必要になります。
ヒント:
開発モードと本番モードの違いなど、この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。
本番モードでは、起動アイデンティティ・ファイルを作成することで、管理サーバーの起動時に必要なユーザー名とパスワードの指定を省略できます。「boot.propertiesファイルの作成」を参照してください。
「RCUデータ」を選択して、この画面に示されるフィールドをアクティブ化します。
「RCUデータ」オプションによってデータベースおよびサービス表(STB)スキーマに接続し、ドメインの構成に必要なスキーマのスキーマ情報を自動的に受け取るように構成ウィザードで指定できます。
注意:
この画面の「手動構成」を選択した場合は、「JDBCコンポーネント・スキーマ」画面でスキーマのパラメータを手動で入力する必要があります。
「RCUデータ」を選択したら、次の表に示すフィールドに入力します。
| フィールド | 説明 |
|---|---|
DBMS/サービス |
製品スキーマをインストールするOracle RACデータベースのサービス名を入力します。次に例を示します。 orcl.example.com 必ずOracle RACデータベース内のすべてのインスタンスの識別に使用される共通サービス名を指定してください。ホスト固有のサービス名は使用しないでください。 「エンタープライズ・デプロイメント用のデータベースの準備」を参照してください。 |
ホスト名 |
Enterprise Deployment Workbookに入力したOracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。 |
ポート |
データベースがリスニングするポート番号を入力します。たとえば、 |
スキーマ所有者 スキーマ・パスワード |
データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。 これはRCUの「スキーマ・パスワード」画面でサービス表コンポーネントに指定されたスキーマのユーザー名およびパスワードです。 デフォルトのユーザー名は |
データベース接続情報の指定が完了したら、「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ドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください
「JDBCコンポーネント・スキーマ」画面に示される値が、すべてのスキーマに対して適切であることを確認します。
前の画面でRCUデータの取得を選択しているため、スキーマ表は移入済のはずです。その結果、構成ウィザードにより、このドメインに必要なすべてのスキーマのデータベース接続値が検出されます。
この時点では、これらの値は単一インスタンスのデータベースに接続するように構成されています。ただし、エンタープライズ・デプロイメントの場合、「エンタープライズ・デプロイメント用のデータベースの準備」の説明のように、可用性の高いReal Application Clusters (RAC)データベースを使用する必要があります。
さらに、各コンポーネント・スキーマでアクティブなGridLinkデータ・ソースを使用することをお薦めします。GridLinkデータ・ソースを使用してRACデータベースに接続する利点の詳細は、 『高可用性ガイド』の「データベースに関する考慮事項」を参照してください。
データ・ソースをGridLinkに変換する手順は次のとおりです。
スキーマ表の最初のヘッダー行にあるチェック・ボックスを選択することですべてのスキーマを選択します。
「GridLinkへ変換」をクリックし、「次へ」をクリックします。
「GridLink Oracle RACコンポーネント・スキーマ」画面で、表10-4に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。
表10-4 「GridLink Oracle RACコンポーネント・スキーマ」画面で選択したフィールドの推奨値
| 要素 | 説明と推奨値 |
|---|---|
「SCAN」、「ホスト名」および「ポート」 |
「SCAN」チェック・ボックスを選択します。 「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。 「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します( |
「ONSホスト」と「ポート」 |
「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。 「ポート」フィールドには、ONSリモート・ポートを入力します(通常は Oracle RACデータベースでのGridLinkに関するONS情報を取得するには、RACマシンのいずれかのノードでons.configファイルを確認します。ons.configファイルは、 |
FANの有効化 |
「FANの有効化」チェック・ボックスを選択して、FANイベントを受信および処理できるようにします。 |
この画面で情報を指定する方法および適切なSCANアドレスの特定方法の詳細は、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。
また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。
「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。
「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。
ヒント:
この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテストに関する項を参照してください
Business Intelligence system.userアカウントの一意の名前ユーザー名とパスワードを入力します。system.userアカウントは実際のユーザーではないことに注意してください。これは、異なるBusiness Intelligenceコンポーネント間での内部認証に使用されます。BIアプリケーションにログインして使用するために実際のシステム・ユーザーが使用していない、一意のランダムなユーザー名とパスワードを指定する必要があります。
jms.queue.authユーザー・アカウントのユーザー名とパスワードを入力します。このユーザーは、WebLogic管理者グループ内のユーザーである必要があります。
注意:
管理サーバーの起動後、および管理対象サーバー/システム・コンポーネントの起動前にデフォルト・オーセンティケータでjms.queue.authユーザーを作成する必要があります。 目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。
管理サーバー
これは、管理サーバーのリスニング・アドレスを適切に構成するために必要です。
ノード・マネージャ
これは、ノード・マネージャを構成するために必要です。
トポロジ
管理対象サーバーとクラスタを構成し、マシンを構成して管理対象サーバーをマシンにターゲット設定するために必要です。
ファイル・ストア
これは、JMS永続ストア用に適切な共有記憶域を構成するために必要です。
JDBC永続ストアを選択している場合は、このオプションを選択しないでください。
注意:
構成ウィザードの「拡張構成」画面を使用するときは、次のようにします。
この画面で前述のオプションのいずれかが使用可能でない場合は、「テンプレート」画面に戻り、このトポロジに必要なテンプレートが選択されていることを確認します。
「ドメイン・フロントエンド・ホストのキャプチャ」拡張構成オプションを選択しないでください。後で、ドメインに対してではなく特定のクラスタに対してフロントエンド・ホスト・プロパティを構成します。
「管理サーバー」画面で、次の手順を実行します。
「サーバー名」フィールドで、デフォルト値(「AdminServer」)を維持します。
「リスニング・アドレス」フィールドに、「エンタープライズ・デプロイメント用のリソースの取得」で取得して「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で有効化したADMINVHNのVIPに対応する仮想ホスト名を入力します。
ADMINVHN仮想ホストを使用する理由の詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。
他のフィールドでは、デフォルト値をそのまま使用します。
特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。
ノード・マネージャのタイプとして、「ドメインごとのデフォルトの場所」を選択します。
「ノード・マネージャ資格証明」で、管理ユーザーと同じユーザー名とパスワードを指定します。
ヒント:
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のノード・マネージャに関する項を参照してください。
ドメインごとおよびホストごとのノード・マネージャの実装の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。
詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の複数マシンでのノード・マネージャの構成に関する項を参照してください。
「管理対象サーバー」画面で、サーバーのリストにOracle Business Intelligence用の新しい管理対象サーバーが表示されます。このサーバーは、「テンプレート」画面で選択したOracle BIEE Suite構成テンプレートによって自動的に作成されたものです。次のタスクを実行して、デフォルトのOracle Business Intelligence管理対象サーバー(bi_server1)を変更します。
デフォルトの管理対象サーバーの名前をWLS_BI1に変更します。
ヒント:
ここで推奨するサーバー名は、このドキュメント全体で使用するため、別の名前を選択する場合は、必要に応じてそれらの名前に置き換えてください。
次の表の情報を使用して、Oracle Business Intelligence管理対象サーバーの残りの列を入力します。
ヒント:
「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。
表10-5 Oracle Business Intelligence管理対象サーバーに必要な値
| サーバー名 | リスニング・アドレス | リスニング・ポート | SSLの有効化 | SSLリスニング・ポート | サーバー・グループ |
|---|---|---|---|---|---|
WLS_BI1 |
BIHOST1VHN |
7003 |
不可 |
無効 |
BISUITE-MAN-SVR |
このタスクでは、Oracle BIソフトウェアのターゲットとすることができるクラスタを作成します。
また、クラスタの「フロントエンド・ホスト」プロパティも設定することにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上のbi.example.comにリダイレクトするようになります。
bi.example.com仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。
「クラスタ」画面で、Oracle Business Intelligenceの新しいクラスタ(bi_cluster)がクラスタのリストに表示されます。次のタスクを実行して、デフォルトのOracle Business Intelligenceクラスタを変更します。
「フロントエンド・ホスト」フィールドでbi.example.comを指定します。
「フロントエンドHTTPポート」に80を指定し、「フロントエンドHTTPSポート」に443を指定します。
「動的サーバー・グループ」ドロップダウン・リストで、「未指定」を選択します。
注意:
デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。
「次へ」をクリックして、続行します。
静的なクラスタとして維持するクラスタに対して、すべての動的サーバー・オプションが無効になっていることを確認します。
この画面の「動的クラスタ」、「計算済リスニング・ポート」および「計算済マシン名」チェック・ボックスの選択が解除されていることを確認します。
「サーバー・テンプレート」セクションが「未指定」であることを確認します。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面を使用して、WLS_BI1を新規クラスタbi_clusterに割り当てます。
「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではbi_cluster)を選択します。
「サーバー」ペインで、次のいずれかの操作を実行してWLS_BI1をbi_clusterに割り当てます。
WLS_BI1管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。
WLS_BI1をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタへのサーバーの割当に関する項を参照してください。
「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。
「クラスタ・リスニング・ポート」に9991と入力します。
注意:
Coherenceのライセンス情報については、Oracle Fusion Middlewareライセンス情報のOracle Coherence製品に関する項を参照してください。
「マシン」画面を使用して、ドメイン内に新しいマシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。
「Unixマシン」タブを選択します。
「追加」ボタンをクリックし、新しいUNIXマシンを作成します。
次の表に記載されている値を指定して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。
注意:
「ノード・マネージャ・リスニング・アドレス」フィールドにはlocalhostを指定しないでください。「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。
この例に示されているポート番号5556は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。
表10-6 Unixマシンの作成時に使用する値
| 名前 | ノード・マネージャのリスニング・アドレス | ノード・マネージャのリスニング・ポート |
|---|---|---|
BIHOST1 |
BIHOST1ホスト名変数の値。たとえば、 |
この例に示されているポート番号5556は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。 BIHOST1の場合はポート5556を使用します。 注意: BIHOST1とADMINHOSTが同一サーバー上で稼働している場合は、各ノード・マネージャが異なるポートで稼働している必要があります(ポート5556をBIHOST1で使用し、ポート5557をADMINHOSTで使用するなど)。 |
ADMINHOST |
ADMINVHN変数の値を入力します。 |
5556 |
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のマシンに関する項を参照してください。
「サーバーのマシンへの割当」画面を使用して、管理サーバーとOracle BI EE Suite管理対象サーバーを適切なマシンに割り当てます。
「サーバーのマシンへの割当」画面は、管理対象サーバーのクラスタへの割当て画面に似ています。「マシン」列でターゲット・マシンを選択し、左の列で管理対象サーバーを選択した後、右矢印をクリックしてそのサーバーを適切なマシンに割り当てます。
次のように、サーバーを割り当てます。
AdminServerをADMINHOSTマシンに割り当てます。
WLS_BI1管理対象サーバーをBIHOST1マシンに割り当てます。
ヒント:
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のサーバーのマシンへの割当てに関する項を参照してください。
「次へ」をクリックして次の画面に進みます。
「次へ」をクリックして次の画面に進みます。
注意:
JMSファイル・ストアの構成画面は、「JMSファイル・ストア」で「JDBC」を選択している場合は表示されません。BI構成テンプレートを使用してドメインを構成する場合(特にエンタープライズ・デプロイメントを構成する場合)、メタデータ・サービス(MDS)のJMSファイル・ストアの適切な場所を選択する必要があります。
「JMSファイル・ストア」画面で、各BI永続ストアに次のディレクトリを割り当てます。
ASERVER_HOME/bi_cluster
この例では、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOMEをASERVER_HOME変数の実際の値に置き換えます。bi_clusterをOracle BIクラスタに割り当てた名前に置き換えます。
「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。
変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。
ドメイン作成は、「作成」をクリックするまでは開始されません。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。
「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。
ドメインの場所
管理サーバーURL
どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、ノード・マネージャと管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。
「終了」をクリックして、構成ウィザードを閉じます。
親トピック: BIドメインの構成
この項の手順を実行して、BIHOST1にBIクラスタ・コントローラ、BIスケジューラ、BIプレゼンテーション・サービスおよびBI JavaHostシステム・コンポーネントを作成します。
注意:
ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。
この項の手順を実行して、新しいBIサービス・インスタンスを作成します。
注意:
ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。
Oracle Business Intelligenceメタデータは、シングルトン・データ・ディレクトリ(SDD)に格納されています。メタデータは、プレゼンテーション・カタログ、メタデータ・リポジトリおよびセキュリティ認証に関する情報を含むOracle Business Intelligenceアーカイブ(BAR)ファイルで管理されます。
次の手順を実行して、シングルトン・データ・ディレクトリに共有ディレクトリを設定します。
注意:
シングルトン・データ・ディレクトリ(SDD)へのパスは、ASERVER_HOME/config/fmwconfig/bienv/core/bi-environment.xmlファイルに定義されています。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
CSSを構成した後に、次の場所にあるjps-config.xmlファイルを更新する必要があります。
プライマリ・ホスト - BIHOST1:
/u01/oracle/config/domains/biedg_domain/config/fmwconfig/jps-config.xml
/u02/oracle/config/domains/biedg_domain/config/fmwconfig/jps-config.xml
セカンダリ・ホスト - BIHOST2:
/u01/oracle/config/domains/biedg_domain/config/fmwconfig/jps-config.xml
/u02/oracle/config/domains/biedg_domain/config/fmwconfig/jps-config.xml
jps-config.xmlファイルに次を追加します(記述されていない場合)。
<property name="odbc.dsn" value="opss_datasource"/>
jps-config.xmlファイルは次のようになります。
<propertySet name="props.db.1"> <property name="server.type" value="DB_ORACLE"/> <property name="oracle.security.jps.farm.name" value="cn=opssSecurityStore"/> <property name="datasource.jndi.name" value="jdbc/OpssDataSource"/> <property name="oracle.security.jps.db.useDSAdminMapKey" value="true"/> <property name="oracle.security.jps.ldap.root.name" value="cn=opssRoot"/> . . . <property name="odbc.dsn" value="opss_datasource"/> </propertySet>
jps-config.xmlファイルを更新した後、stop.shおよびstart.shコマンドを使用してBIHOST1とBIHOST2を再起動します。
ドメインの作成後、BIHOST1で一連の追加構成タスクを実行する必要があります。たとえば、ノード・マネージャおよび管理サーバーを起動します。その後、管理対象サーバーの個別ドメイン・ディレクトリを作成します。この新しい個別の管理対象サーバー・ディレクトリで、2番目のノード・マネージャ・インスタンスを起動し、管理対象サーバーおよびBusiness Intelligenceシステム・コンポーネントを起動します。
boot.propertiesを作成する必要があります。この手順は、エンタープライズ・デプロイメントでは必須です。このファイルに入力した資格証明は、管理サーバーを起動すると暗号化されます。これらの手順を使用して、ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動します。
管理サーバー資格証明を求められることなく管理サーバーを起動する場合は、boot.propertiesを作成する必要があります。この手順は、エンタープライズ・デプロイメントでは必須です。このファイルに入力した資格証明は、管理サーバーを起動すると暗号化されます。
管理サーバーのboot.propertiesファイルを作成する手順は次のとおりです。
構成手順に進む前に、管理サーバーにインストールおよび構成されている、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
最初にエンタープライズ・デプロイメント用のドメインを作成すると、そのドメイン・ディレクトリは共有ディスク上に配置されます。このデフォルトのドメイン・ディレクトリは、管理サーバーを実行するために使用されます。これで、BIHOST1とBIHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。
サーバーが共有記憶域にログを書き込むことによって発生する潜在的な競合とオーバーヘッドを排除するために、MSERVER_HOMEをローカル記憶域に配置することをお薦めします。また、必要なクラスおよびjarをドメイン・ディレクトリからロードするほうが高速であるため、管理対象サーバーがドメイン・ディレクトリから使用する一時データまたはキャッシュのデータのほうがより迅速に処理されます。
「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のように、管理サーバー・ドメイン・ホームのパスはASERVER_HOME変数によって表され、管理対象サーバー・ドメイン・ホームのパスはMSERVER_HOME変数によって表されます。
管理対象サーバーのドメイン・ディレクトリを作成する手順は次のとおりです。
管理対象サーバーのドメイン・ディレクトリを作成した後は、BIHOST1に2つのドメイン・ホーム・ディレクトリとそれに対応する2つのノード・マネージャ・インスタンスが存在します。1つのノード・マネージャを使用して、管理サーバー・ドメイン・ホームから実行される管理サーバーを制御し、もう1つのノード・マネージャを使用して、管理対象サーバー・ドメイン・ホームから実行される管理対象サーバーを制御します。
2つのノード・マネージャを別々に起動する必要があります。
注意:
ドメイン構成が解凍されるたびに、管理対象サーバーのMSERVER_HOMEのノード・マネージャがリセットされます。ListenAddressは、正しいホスト名ではなくADMINVHNに変更されます。これは、解凍が実行された後、ノード・マネージャ・サービスを開始する前に正しい値に変更する必要があります。次の手順に従って、管理対象サーバー・ホームからノード・マネージャを更新および起動します。
追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、BIHOST1上の管理対象サーバーを起動します。
前述の手順でノード・マネージャと管理サーバーをすでに起動しているため、Fusion Middleware Controlは使用可能な状態です。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Business Intelligenceのシステム・コンポーネントを起動します。
をクリックして表示します。グローバル・キャッシュとは、クラスタに参加しているすべてのOracle BIサーバーが共有する問合せキャッシュです。クラスタに参加しているすべてのOracle BIサーバーでキャッシュのシーディング・イベントおよびパージ・イベントを共有するようにグローバル・キャッシュを構成することをお薦めします。
『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のグローバル・キャッシュに関する項を参照してください。
グローバル・キャッシュを設定するには:
をクリックして表示します。BIHOST1でドメインのコンポーネントを起動した後、これらのURLにアクセスして、Oracle Business Intelligenceの構成を確認します。
Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。
次のトピックでは、Oracle WebLogic Server管理コンソールを使用してエンタープライズ・デプロイメント・ドメイン用の新しい認証プロバイダを作成する方法について説明します。この手順では、サポートされているLDAPディレクトリ(Oracle Unified DirectoryやOracle Internet Directoryなど)をすでにインストールおよび構成していることを想定しています。
BIAdministrators)をメンバーとしてwsm-pmアプリケーション・ストライプのpolicy.Updaterロールに追加します。Oracle Fusion Middlewareでは、様々なLDAP認証プロバイダをサポートしています。『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・タイプおよびWebLogicオーセンティケータに関する項を参照してください。
このガイドの手順では、次のいずれかのプロバイダを使用していることを想定しています。
Oracle Unified Directory
Oracle Internet Directory
Microsoft Active Directory
注意:
ここに示す手順では、デフォルトで、暗号化されていない接続を使用した単一のLDAPアイデンティティ・ストアに対する問合せをサポートするためにアイデンティティ・サービス・インスタンスを構成する方法を説明します。
アイデンティティ・プロバイダへの接続をSSLで保護する必要がある場合は、Enterprise Manager Fusion Middleware Controlでのロール管理が正しく機能するように、追加のキーストア構成が必要になります。追加の構成情報については、support.oracle.comでDoc ID 1670789.1を参照してください。
また、LibOVDを使用して、複数のLDAPアイデンティティ・ストアに問合せを行う仮想アイデンティティ・ストアをサポートするようにサービスを構成できます。
複数LDAP参照の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・サービスの構成に関する項を参照してください。
次のトピックでは、エンタープライズ・デプロイメント管理ユーザーおよび管理グループの用途と特性に関する重要な情報を提供します。
集中LDAPユーザー・ストアを使用すると、複数のOracle WebLogic Serverドメインで使用するユーザーおよびグループをプロビジョニングできます。その結果、あるWebLogic管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。
Oracle Fusion Middlewareドメインの管理用にプロビジョニングするユーザーおよびグループにディレクトリ・ツリー内で一意の識別名(DN)を作成して割り当てる方法をお薦めします。
たとえば、Oracle Business Intelligenceエンタープライズ・デプロイメント・ドメインをインストールおよび構成する場合は、weblogic_biというユーザーとBIAdministratorsという管理グループを作成します。
LDAPディレクトリに、個別のドメイン・コネクタ・ユーザー(biLDAPなど)を作成することをお薦めします。このユーザーを使用すると、ユーザー認証の目的でドメインからLDAPディレクトリに接続できます。これは管理ユーザー以外のユーザーにすることをお薦めします。
標準的なOracle Identity and Access Managementデプロイメントで、このユーザーをsystemidsコンテナに作成します。このコンテナは、通常はユーザーに表示されないシステム・ユーザーに使用されます。このユーザーをsystemidsコンテナに配置することで、Oracle Identity Governanceを持つユーザーがこのユーザーを調整しないようにできます。
中央LDAPディレクトリをエンタープライズ・ドメインのオーセンティケータとなるよう構成した後、すべての新しいユーザーをデフォルトのWebLogic Serverオーセンティケータではなく、新しいオーセンティケータに追加する必要があります。
中央LDAPディレクトリに新しいユーザーを追加する場合、WebLogic管理コンソールを使用することはできません。かわりに、ldapbrowserやJXplorerなどの適切なLDAP変更ツールを使用する必要があります。
各Oracle Fusion Middleware製品では、管理および監視のために独自の事前定義済ロールおよびグループが実装されます。
その結果、ドメインを拡張して他の製品を追加するときに、これらの製品固有のロールをBIAdministratorsグループに割り当てることができます。ロールがBIAdministratorsグループに追加されると、各製品管理者ユーザーは管理タスクを実行するための同じ権限セットを使用してドメインを管理できます。
BIAdministratorsグループに他のロールを追加する手順については、「エンタープライズ・デプロイメントの共通の構成および管理タスク」を参照してください。
このガイドで使用するサンプルでは、次のDNを持つ次の管理ユーザーおよび管理グループをプロビジョニングすることを想定しています。
管理ユーザーのDN:
cn=weblogic_bi,cn=users,dc=example,dc=com
管理グループのDN:
cn=BIAdministrators,cn=groups,dc=example,dc=com
cn=biLDAP,cn=systemids,dc=example,dc=com
これは、WebLogic管理対象サーバーをLDAP認証プロバイダに接続する際に使用するユーザーです。このユーザーには、ディレクトリ・ツリーに対する読取りおよび書込み権限が必要です。cn=users,dc=example,dc=com cn=groups,dc=example,dc=com
注意:
読取りおよび書込みアクセスを提供するために、このユーザーに次のグループのメンバーシップを付与する必要があります。
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
認証プロバイダの作成とユーザーおよびグループのプロビジョニングに必要な前提条件をすべて満たします。関連するバックアップ・ファイルをバックアップし、認証プロバイダを有効にします。
新しいLDAP認証プロバイダを作成する前に、関連する構成ファイルをバックアップします。
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
複数のオーセンティケータ(エンタープライズ・デプロイメントの要件)を使用している場合、ログインおよび認証は機能しますが、ロールの取得は機能しません。ロールは第1オーセンティケータからのみ取得されます。その他のオーセンティケータを使用してロールを取得する場合は、ドメインの仮想化を有効にする必要があります。
仮想化を有効にする手順は次のとおりです。
管理者のアカウントを使用して、Fusion Middleware Controlにサインインします。たとえば、weblogicです。
http://adminvhn:7001/em
「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。
「セキュリティ・ストア・プロバイダ」を開きます。
「アイデンティティ・ストア・プロバイダ」を展開します。
「構成」をクリックします。
カスタム・プロパティを追加します。
プロパティvirtualizeを値trueで選択し、「OK」をクリックします。
「OK」を再度クリックし、変更を永続化します。
管理サーバーとすべての管理対象サーバーを再起動します。
仮想化プロパティの詳細は、Oracle Platform Security Servicesによるアプリケーションの保護のOPSSシステムおよび構成プロパティに関する項を参照してください。
この例では、biLDAPというユーザーを中央LDAPディレクトリに作成する方法を示します。
LDAPプロバイダでユーザーをプロビジョニングする手順は次のとおりです。
次に示す内容を指定してdomain_user.ldifという名前のLDIFファイルを作成し、保存します。
dn: cn=biLDAP,cn=systemids,dc=example,dc=com changetype: add orclsamaccountname:biLDAPuserpassword: password objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgperson objectclass: orcluser objectclass: orcluserV2 mail:biLDAP@example.com givenname:biLDAPsn:biLDAPcn:biLDAPuid:biLDAP
注意:
Oracle Unified Directoryを使用する場合、適切な読取り/書込み権限を付与するため、LDIFファイルの最後に次の4つのグループ・メンバーシップを追加してください。
dn: cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=example,dc=com changetype: modify add: uniquemember uniquemember: cn=biLDAP,cn=systemids,dc=example,dc=com dn: cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=example,dc=com changetype: modify add: uniquemember uniquemember: cn=biLDAP,cn=systemids,dc=example,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
LDAPディレクトリでユーザーをプロビジョニングします。
たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。
OUD_INSTANCE_HOME/bin/ldapmodify -a \ -h idstore.example.com -D "cn=oudadmin" \ -w password \ -p 1389 \ -f domain_user.ldif
Oracle Internet Directoryの場合:
OID_ORACLE_HOME/bin/ldapadd -h idstore.example.com \ -p 3060 \ -D cn="orcladmin" \ -w password \ -c \ -v \ -f domain_user.ldif
新しいLDAPベースの認証プロバイダを構成する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。
myrealmというデフォルト・レルム・エントリをクリックします。
「プロバイダ」タブをクリックします。
このレルムに対してDefaultAuthenticatorというプロバイダが構成されていることに注目してください。これは、デフォルトのWebLogic Server認証プロバイダです。
「チェンジ・センター」で「ロックして編集」をクリックします。
「認証プロバイダ」表の下の「新規」ボタンをクリックします。
プロバイダの名前を入力します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかの名前を使用します。
OUDAuthenticator (Oracle Unified Directoryの場合)
OIDAuthenticator (Oracle Internet Directoryの場合)
OVDAuthenticator (Oracle Virtual Directoryの場合)
「タイプ」ドロップダウン・リストでオーセンティケータ・タイプを選択します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかのタイプを選択します。
OracleUnifiedDirectoryAuthenticator (Oracle Unified Directoryの場合)
OracleInternetDirectoryAuthenticator (Oracle Internet Directoryの場合)
OracleVirtualDirectoryAuthenticator (Oracle Virtual Directoryの場合)
「OK」をクリックして「プロバイダ」画面に戻ります。
「プロバイダ」画面の表で、新しく作成したオーセンティケータをクリックします。
「制御フラグ」ドロップダウン・メニューで「SUFFICIENT」を選択します。
制御フラグを「SUFFICIENT」に設定すると、そのオーセンティケータがユーザーを正常に認証できる場合はその認証を受け入れ、それ以上のオーセンティケータを起動しません。
認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。以降のすべてのオーセンティケータの制御フラグも「SUFFICIENT」に設定されていることを確認してください。特にDefaultAuthenticatorをチェックして、その制御フラグが「SUFFICIENT」に設定されていることを確認します。
「保存」をクリックして、制御フラグ設定の変更を確定します。
「プロバイダ固有」タブをクリックし、次の表に示すように、使用するLDAPサーバーに固有の詳細を入力します。
この手順では、必須フィールドのみを説明しています。このページのすべてのフィールドの詳細は、次のリソースを参照してください。
各フィールドの説明を表示するには、「プロバイダ固有」タブの「ヘルプ」をクリックします。
「ユーザー・ベースDN」、「名前指定によるユーザー・フィルタ」および「ユーザー属性」の各フィールドの設定の詳細は、『Oracle WebLogic Serverセキュリティの管理』のOracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成に関する項を参照してください。
| パラメータ | サンプル値 | 値の説明 |
|---|---|---|
ホスト |
例: |
LDAPサーバーのサーバーID。 |
ポート |
例: |
LDAPサーバーのポート番号。 |
プリンシパル |
例: |
LDAPサーバーへの接続に使用されるLDAPユーザーのDN。 |
資格証明 |
LDAPパスワードを入力します。 |
LDAPサーバーへの接続に使用されるパスワード。 |
SSLの有効化 |
未チェック(クリア) |
LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。 |
ユーザー・ベースDN |
例: |
ユーザーが開始時に使用するDNを指定します。 |
すべてのユーザーのフィルタ |
|
「すべてのユーザーのフィルタ」のデフォルトの検索基準のかわりに、 LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」が たとえば、「ユーザー名属性」のタイプが (&(cn=*)(objectclass=person))) |
名前指定によるユーザー・フィルタ |
次に例を示します。 (&(uid=%u)(objectclass=person)) |
LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」が たとえば、「ユーザー名属性」のタイプが |
ユーザー名属性 |
例: |
グループの名前を指定するLDAPユーザー・オブジェクトの属性。 |
取得したユーザー名をプリンシパルとして使用する |
チェック済 |
オンにする必要があります。 |
グループ・ベースDN |
例: |
グループ・ノードを指すDNを指定します。 |
GUID属性 |
|
OUDに |
「保存」をクリックして変更を保存します。
右のナビゲーション・ペインで「セキュリティ・レルム」をクリックして、デフォルトのレルム名(myrealm)をクリックし、「プロバイダ」をクリックして「プロバイダ」ページに戻ります。
「並替え」をクリックし、表示されたページを使用して、作成したプロバイダを認証プロバイダのリストの先頭に配置します。
「OK」をクリックします。
「プロバイダ」ページで、DefaultAuthenticatorをクリックします。
「制御フラグ」ドロップダウンから、SUFFICIENTを選択します。
「保存」をクリックしてDefaultAuthenticatorの設定を更新します。
チェンジ・センターで、変更のアクティブ化をクリックします。
管理サーバーとすべての管理対象サーバーを再起動します。
管理対象サーバーを停止するには、Fusion Middleware Controlにログインし、ターゲットのナビゲータで管理対象サーバーを選択して、ツールバーで「停止」をクリックします。
ノード・マネージャを使用して管理サーバーを停止および起動する手順は次のとおりです。
WLSTを起動します。
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します。
wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'ASERVER_HOME')
管理サーバーを停止します。
nmKill('AdminServer')
管理サーバーを起動します。
nmStart('AdminServer')
WLSTを終了します。
exit()
管理対象サーバーを起動するには、Fusion Middleware Controlにログインし、管理対象サーバーを選択して、ツールバーで「起動」をクリックします。
再起動後に、次のログ・ファイルの内容を確認します。
ASERVER_HOME/servers/AdminServer/logs/AdminServer.log
LDAP接続エラーが発生していないことを確認します。たとえば、次のようなエラーを探します。
The LDAP authentication provider named "OUDAuthenticator" failed to make connection to ldap server at ...
ログ・ファイルでこのようなエラーが見つかった場合は、認可プロバイダ接続の詳細をチェックして、それらが適切であることを確認し、管理サーバーの保存と再起動をもう一度試みます。
再起動後、LDAP接続エラーがログ・ファイルに記述されていないことを確認し、LDAPプロバイダ内に存在するユーザーとグループの参照を試みます。
管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ユーザーとグループ」ページに移動します。LDAPプロバイダ構造内に存在するすべてのユーザーおよびグループを表示できるようになります。
この例では、weblogic_biというユーザーとBIAdministratorsというグループを作成する方法を示します。
LDAPプロバイダで管理ユーザーおよび管理グループをプロビジョニングする手順は次のとおりです。
次に示す内容を指定してadmin_user.ldifという名前のLDIFファイルを作成し、保存します。
dn: cn=weblogic_bi,cn=users,dc=example,dc=com changetype: add orclsamaccountname:weblogic_biuserpassword: password objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgperson objectclass: orcluser objectclass: orcluserV2 mail:weblogic_bi@example.com givenname:weblogic_bisn:weblogic_bicn:weblogic_biuid:weblogic_bi
LDAPディレクトリでユーザーをプロビジョニングします。
たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。
OUD_INSTANCE_HOME/bin/ldapmodify -a \ -h idstore.example.com -D "cn=oudadmin" \ -w password \ -p 1389 \ -f admin_user.ldif
Oracle Internet Directoryの場合:
OID_ORACLE_HOME/bin/ldapadd -h idstore.example.com \ -p 3060 \ -D cn="orcladmin" \ -w password \ -c \ -v \ -f admin_user.ldif
次に示す内容を指定してadmin_group.ldifという名前のLDIFファイルを作成し、保存します。
dn: cn=BIAdministrators,cn=Groups,dc=example,dc=com displayname:BIAdministratorsobjectclass: top objectclass: groupOfUniqueNames objectclass: orclGroup uniquemember: cn=weblogic_bi,cn=users,dc=example,dc=com cn:BIAdministratorsdescription: Administrators Group for the Oracle Business Intelligence Domain
LDAPディレクトリでグループをプロビジョニングします。
Oracle Unified Directoryの場合:
OUD_INSTANCE_HOME/bin/ldapmodify -a \ -D "cn=oudadmin" \ -h oudhost.example.com \ -w password \ -p 1380 \ -f admin_group.ldif
Oracle Internet Directoryの場合:
OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \ -p 3060 \ -D cn="orcladmin" \ -w password \ -c \ -v \ -f admin_group.ldif
変更が正常に行われたことを確認します。
Oracle WebLogic Server管理コンソールにログインします。
コンソールの左ペインで「セキュリティ・レルム」をクリックします。
デフォルト・セキュリティ・レルム(myrealm)をクリックします。
「ユーザーとグループ」タブをクリックします。
プロビジョニングした管理者ユーザーおよびグループがページに表示されていることを確認します。
Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内でそのグループに管理ロールを割り当てる必要があります。これにより、このグループに属するすべてのユーザーがそのドメインの管理者になることができます。
管理ロールを新しいエンタープライズ・デプロイメント管理グループに割り当てる手順は次のとおりです。
新しい管理ユーザーおよびグループを作成したら、LDAPディレクトリで作成した管理ユーザー資格証明を使用して管理サーバーのboot.propertiesファイルを更新する必要があります。
Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。
バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。
