ヘッダーをスキップ
Oracle® Fusion Middleware高可用性ガイド
11gリリース1（11.1.1）
B55898-02
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

15 Oracle Business Intelligenceの高可用性の構成

Oracle Business Intelligenceは、ビジネス・ユーザーに組織の全体像を提供する統合ビジネス・インテリジェンス（BI）ソリューションです。Oracle Business Intelligenceは、迅速かつ簡単に様々なデータソースを統合し、データベースの情報を検索し、データベース情報を共有して、企業およびその顧客に関する情報を得るためにデータを有効に利用することを目的として設計されています。

この章では、次のトピックによりこれらのOracle Business Intelligenceコンポーネントの高可用性について説明します。

この章では、Oracle Business Intelligenceについて理解していることを前提としています。そうでない場合は、Oracle Business Intelligenceのドキュメントを参照してください。

15.1 Oracle Business Intelligence Enterprise Editionの高可用性

この項では、Oracle Business Intelligence Enterprise Edition（Oracle BI EE）の概要について、およびOracle BI EEの高可用性環境を設計およびデプロイする方法について説明します。

Oracle BI EEは、Oracle Business Intelligence Applicationsなどのいくつかのアプリケーションが含まれたOracle Business Intelligenceの一部です。Oracle Business Intelligenceは、包括的なエンタープライズ・ビジネス・インテリジェンス機能の集合体であり、これらの機能としては、インタラクティブ・ダッシュボード、完全アドホック式の先行型インテリジェンスとアラート、企業レポートと財務レポート、リアルタイム予測インテリジェンスなどがあります。Oracle Business Intelligenceプラットフォームは、包括的なビジネス・インテリジェンス機能を提供するだけでなく、真の次世代ビジネス・インテリジェンス機能を提供する実績ある最新型のWebサービス指向アーキテクチャをベースとしています。

企業は、製品、顧客、価格、連絡先、業務活動、資産、商談、従業員などの様々なビジネス要素に関する大量のデータを追跡および保管しています。これらのデータは多くの場合、様々な場所に配置された複数のデータベースにまたがって分散されており、これらのデータベースでは異なるバージョンのデータベース・ソフトウェアが使用されています。Oracle BI EEは、各種データを収集および編成してから編成データをユーザーに表示できる堅牢なアプリケーションです。ユーザーは、これらのデータを分析および解釈して、その結果に基づいて対処できます。

Oracle BI EEに関するその他の概要情報は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイドを参照してください。

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

15.1.1 Oracle BI EEのコンポーネント・アーキテクチャ

図15-1では、単一インスタンス・アーキテクチャでのOracle BI EEコンポーネントを示しています。Javaコンポーネントとシステム・コンポーネント間のすべての通信は、HTTP経由のSOAPメッセージを介して行われます。

図15-1 Oracle BI EEの単一インスタンス・アーキテクチャ

図15-1の説明は次にあります。
「図15-1 Oracle BI EEの単一インスタンス・アーキテクチャ」の説明

Oracle BI EEには、システム・コンポーネントとJavaコンポーネントが含まれています。

図15-1に示しているポート番号は、単一マシン上に各コンポーネント・タイプのコンポーネントが1つだけ配置された単純なインストール環境用のデフォルト・ポート番号です。Oracle Enterprise Manager Fusion Middleware Controlを使用する場合、ポート番号の範囲を選択可能であり、Enterprise Managerによってポート番号が割り当てられます。

15.1.1.1 Oracle BI EEコンポーネントの特性

次に、Oracle BI EEシステム・コンポーネントの機能について概要を説明します。

  • Oracle BIプレゼンテーション・サービス（プレゼンテーション・サービス）: これは、Oracle BI SchedulerのかわりにUIページを生成して結果セットをレンダリングするC++プロセスです。負荷を共有する複数のプレゼンテーション・サービス・プロセスを構成できます。プレゼンテーション・サービス・プロセス間では、セッション・レプリケーションは行われません。

    プレゼンテーション・サービスはほぼステートレスです。唯一の重要な状態はクライアント認証です。シングル・サインオンを使用して認証するようにOracle Business Intelligenceが構成されている場合、ユーザーはフェイルオーバー後に再認証する必要はありません。他のすべての認証方式では、フェイルオーバーが発生すると、クライアントは再認証する必要があります。クライアントに対するサービスは中断され、クライアントはログイン・ページにリダイレクトされます。

  • Oracle Business Intelligence Server（BI Server）: これは、データ操作を実行したりデータソースからデータを収集するC++プロセスです。負荷を共有する複数のBI Serverプロセスを構成できます。BI Serverプロセス間では、セッション・レプリケーションは行われません。

    BI Serverでは、ユーザー・セッション状態は保持されません。高可用性デプロイメントの場合は、問合せ結果はグローバル・キャッシュに格納されます。

  • JavaHost: これは、大量のリソースを消費するグラフやPDFのレンダリングを含むJavaプロセスです。負荷を共有する複数のJavaHostプロセスを構成できます。JavaHostプロセス間では、セッション・レプリケーションは行われません。

    JavaHostはステートレス・プロセスです。

  • Cluster Controller: これは、BI ServerとOracle BI Schedulerの集合を管理するC++プロセスです。

  • Oracle Business Intelligence Scheduler（Oracle BI Scheduler）: これは、時刻が指定されたスケジュールに従ってジョブを実行するC++プロセスです。ジョブは、Oracle BIプレゼンテーション・カタログで作成されたエージェントの場合や、ジョブ・マネージャによって作成されたジョブの場合があります。

次に、Oracle BI EE Javaコンポーネントの機能について概要を説明します。

  • Oracle BIプレゼンテーション・サービスのプラグイン・サーブレット: プレゼンテーション・サービスはプレゼンテーション・サーバーですが、Webサーバーではないため、Webサーバー・プラグインAPIを認識しません。Oracle BIプレゼンテーション・サービスのプラグインは、HTTPリクエストをプレゼンテーション・サービスに転送します。HTTPリクエストは、ブラウザ・ベースのUIからのリクエストまたはSOAPリクエストです。

  • Webサービス:

    • アクション実行サービス: このWebサービスは、プレゼンテーション・サービスとOracle BI Schedulerのかわりにアクションを実行します。アクションは、サード・パーティWebサービスのコールである場合や、EJBとして実行されるユーザー提供Javaコードのコールである場合があります。

    • アクション・レジストリWebサービス: このWebサービスはアクションのリストを提供します。

    • アクション場所サービス: このWebサービスにより間接レベルが実現されるため、アクションを顧客のテスト環境で開発してから、すべてのアクション定義を本番ソースを指すように変更することなく、開発アクションを本番環境にデプロイできます。

    • SOA用Webサービス: これはサーブレットであるとともに、Oracle BIプレゼンテーション・カタログのコンテンツに対するWebサービス・インタフェースを提供する関連Webサービスです。Oracle BIプレゼンテーション・カタログ内のオブジェクトのツリーは、WSDLリーフを持つWSILツリーによって定義されたWebサービスのツリーとして公開されます。

    • セキュリティWebサービス: 標準に基づいた認証サービスと移入サービスを提供します。

15.1.1.1.1 プロセスのライフサイクル

Oracle BI EEの各システム・コンポーネントは、OPMNによって制御され、Oracle Enterprise Manager Fusion Middleware ControlのOracle BI EE管理ページを使用して起動および停止されます。

Oracle BI EEの各Javaコンポーネントは、管理対象のOracle WebLogic Serverによってホストされ、Oracle WebLogic Server管理コンソールを使用して制御されます。それぞれの管理対象Oracle WebLogic Serverは、ローカルのWebLogicノード・マネージャによって監視および（必要に応じて）再起動されます。

15.1.1.1.2 外部依存性

Oracle BI EEを使用するには次が必要です。

  • SMTPメール・サーバー

  • LDAPプロバイダ（Oracle Internet Directoryなど）

  • アクションをサポートするための外部Webサービス（ユーザーによって構成）

次のクライアントはOracle BI EEに依存します。

  • ADF統合: ADFでは、プレゼンテーション・サービスのWebサービスと、ODBC/JDBCポートを介したBI Serverの直接起動の両方が使用されます。これは、プレゼンテーション・サービスを経由することなくOracle BI Serverが直接起動される唯一のケースです。

  • BI Publisher: プレゼンテーション・サービスのWebサービスを使用します。

  • BPEL: WSILブラウジング・サーブレットおよびSOA WebサービスのWebサービスを使用します。

15.1.1.1.3 構成アーティファクト

Oracle BI EEでは、次の3種類の構成方法が用意されています。

  • 中央構成: Oracle Enterprise Manager Fusion Middleware ControlのBI EEページで行います。これらのページを使用して、追加のインスタンスをプロビジョニングして、高い可用性とスケーラビリティを提供できます。主要な構成値も中央で管理できるため、すべてのインスタンスに一貫した構成値を割り当てることができます。

  • ローカル・システム・コンポーネントの構成: ローカル構成が必要となるのは、詳細構成に変更を加える場合のみです。

  • ローカルJavaコンポーネントの構成: システム・コンポーネントの構成と同様に、ローカル構成は詳細オプションについてのみ必要です。

中央構成

Oracle BI EEでは、Enterprise Manager Fusion Middleware Controlで公開されている中央構成メカニズムが用意されています。

中央で管理される構成の対象は次のとおりです。

  • コンポーネント数の変更

  • リスニング・ポートの範囲: 各コンポーネントによって使用されるポートは、この範囲から自動的に割り当てられます。

  • 基本SSL構成: システムMBeanブラウザを使用して、BIコンポーネントに対してSSLを有効にできます。

  • メール・サーバー構成

  • プリンシパル・チューニング・オプション

  • 共有ファイルの場所

詳細構成はローカルでできますが、そのためにはローカル構成ファイルを直接編集します。中央構成がコミットされると、中央構成によって設定された構成オプションのみがローカル・マシンに配信されます。

ローカル・システム・コンポーネントの構成

実行中の各システム・コンポーネントは、共有構成ファイルとコンポーネント固有構成ファイルの両方を参照します。共有構成ファイル（NQClusterConfig.iniなど）は次のディレクトリに配置されます。

ORACLE_INSTANCE/config/OracleBIApplication/coreapplication

コンポーネント固有構成ファイルは次の場所に配置されます。

ORACLE_INSTANCE/config/ComponentType/ComponentInstanceName

次に例を示します。

ORACLE_INSTANCE/config/OracleBIPresentationServicesComponent/
coreapplication_obips1

各コンポーネントはローカル・ファイルを参照するため、中央の管理サーバー上に保持されているファイルにアクセスする必要はありません。中央構成がコミットされると、中央で管理されている構成値はこれらのローカル構成ファイルに配信されます。ローカル・ファイル内では、これらの中央で管理されている構成値をローカルで編集しないようにユーザーに警告するコメントが、これらの構成値に付加されます。残りの値はローカルで編集できます。

rpdファイルにはデータソースへの参照が含まれています。一般に開発では、本番データベースとは異なるデータベースがファクト表用に使用されます。rpdファイルが開発環境から本番環境に移動された場合は、BI管理ツールを使用してrpdファイルを編集することで、データソースへの参照を変更する必要があります。

ローカルJavaコンポーネントの構成

Javaコンポーネントは、次の場所のWebLogicディレクトリ・ツリーで構成されます。

DOMAIN_HOME/config/fmwconfig/biinstances/coreapplication
15.1.1.1.4 デプロイメント・アーティファクト

一般に、Oracle BI EEによってデプロイされるJavaアプリケーションは、nostageでデプロイされます。WebLogic Serverは.earファイルを展開して、プライベート一時ディレクトリに配置します。これに対する例外であるMap Viewerには、事前に展開されたデプロイメント・ディレクトリでのみ実行できる構成要件があります。

すべての管理対象サーバー・アプリケーションは（Enterprise Manager Fusion Middleware Controlや中央構成アプリケーションなどの管理アプリケーションは除く）、個別に指定されたシステムにデプロイされるのではなく、Oracle BI EEクラスタ全体にデプロイされます。

Oracle BI EEシステム・コンポーネントがデプロイされるときのログ・ファイルの場所については、第15.1.1.1.5項「ログ・ファイルの場所」を参照してください。

15.1.1.1.5 ログ・ファイルの場所

表15-1には、Oracle BI EEシステム・コンポーネントのログ・ファイルを示しています。これらのすべてのログ・ファイルには、Enterprise Manager Fusion Middleware Controlからアクセスできます。

表15-1 Oracle BI EEシステム・コンポーネントのログ・ファイル

BIコンポーネント ログ・ファイル ログ・ファイルのディレクトリ

OPMN

debug.log

ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn

OPMN

opmn.log

ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn

BI Server

NQServer.log

ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication_obis1

BI Cluster Controller

nqcluster.log

ORACLE_INSTANCE/diagnostics/logs/OracleBIClusterControllerComponent/coreapplication_obiccs1

Oracle BI Scheduler

nqscheduler.log

ORACLE_INSTANCE/diagnostics/logs/OracleBISchedulerComponent/coreapplication_obisch1

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

sawlog*.log（例: sawlog0.log）

ORACLE_INSTANCE/diagnostics/logs/OracleBIPresentationServicesComponent/coreapplication_obips1

BI JavaHost

jh.log

ORACLE_INSTANCE/diagnostics/logs/OracleBIJavaHostComponent/coreapplication_objh1

15.1.2 Oracle BI EEの高可用性の概要

この項では、Oracle BI EEを高可用性デプロイメントで使用する場合の概要について説明します。

Oracle BI EEの高可用性を確保するための要件

Oracle BI EEは、プロセス・レプリケーションと高可用性ストレージ（データベースと共有ファイル・システム）の組合せを通じて高可用性を実現します。

高可用性システムを実現するには、Oracle BI EEは次の外部サービスを必要とします。

  • フォルト・トレラントのHTTPロード・バランサ

  • 高可用性の共有ファイル・システム

  • Oracle BI Schedulerおよびファクト表用の高可用性データベース

次のシステム・コンポーネントをレプリケートする必要があります（2つ以上のインスタンスを確保）。

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

  • Cluster Controller

  • Oracle BI Scheduler

  • BI Server

  • JavaHost

これらのシステム・コンポーネントのインスタンスが2つ以上ない場合は、高可用性要件が満たされず、Enterprise Manager Fusion Middleware Controlの構成UIでは管理者に対して警告が表示されます。

次の永続データソースは、高可用性の共有ファイル・システムに配置される必要があります。

  • RPD公開ディレクトリ: サーバー・メタデータは、各BI Serverに対してローカルであるリポジトリ・ファイル（.rpdファイル）に含まれています。1台のBI Serverがマスターとして指定されます。rpdファイルへのオンライン変更はマスターBI Server上で行われ、これらの変更内容はクラスタの他のメンバーにレプリケートされます。

  • Oracle BIプレゼンテーション・カタログ

  • グローバル・キャッシュ（必須ではありませんが、高いパフォーマンスを得るためにお薦めします）: グローバル・キャッシュ機能は、クラスタ内のすべてのBI Serverで参照できる共通問合せキャッシュをサポートします。

  • スケジューラ・スクリプト

また、Oracle BIプレゼンテーション・サービス・プラグインや認証サービスなどのOracle BI EE Javaコンポーネントをホストするために、2つ以上のメンバーで構成されるWebLogicクラスタも必要です。

15.1.2.1 Oracle BI EEの高可用性アーキテクチャ

図15-2には、Oracle BI EEの高可用性デプロイメントを示しています。

図15-2 Oracle BI EEの高可用性デプロイメント

図15-2の説明は次にあります。
「表15-2 Oracle BI EEの高可用性デプロイメント」の説明

図15-2では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。

Oracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。APPHOST1が使用できなくなると、第3章「WebLogic Serverの高可用性」の説明に従って、管理サーバーをAPPHOST2でアクティブにできます。Oracle BI EEとOracle BI PublisherのJavaコンポーネントは、これらのホスト上のBI_SERVER1管理対象サーバーとBI_SERVER2管理対象サーバーにデプロイされます（この図で示しているOracle BI Publisherは、Oracle BI EEとは別個のコンポーネントであることに注目してください）。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。サーバー移行全体は、管理対象サーバー用に構成されます。

BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してVIPマッピングを有効にして（APPHOST1ではVIP1、APPHOST2ではVIP2）、トポロジで使用されるネットワーク・システムで仮想ホスト名を（DNSサーバーとhosts解決のいずれかで）正しく解決する必要があります。BIサーバーのサーバー移行を構成する方法の詳細は、第15.1.3.21項「BI_SERVERnサーバーのサーバー移行の構成」を参照してください。

Oracle BI Presentation Server、JavaHost、Oracle BI Cluster Controller、Oracle BI SchedulerおよびOracle BI Serverは、APPHOST1およびAPPHOST2にインストールされてクラスタとして構成されたシステム・コンポーネントです。APPHOST2上のCluster ControllerとSchedulerはパッシブであり（これらは起動されますがリクエストを処理しません）、APPHOST1のコンポーネントで障害が発生した場合にのみアクティブ化されます。

データ層では、カタログ、問合せキャッシュ、RPDおよびSchedulerのスクリプト・データを格納するために、共有外部記憶域が設定されます。Oracle RACデータベースは、BI EEスキーマ・メタデータとBI Publisherリポジトリ・データを格納するために使用され、エンタープライズ・データベース用としてもお薦めします。

次の各項では、いくつかのOracle BI EEコンポーネントの高可用性情報について説明します。

15.1.2.1.1 Webサーバーの高可用性の考慮事項

Oracle BIプレゼンテーション・サービス・プラグインは、ブラウザUIなどのすべてのHTTPクライアントにとっての最初の通信先です。この前方には、Oracle HTTP Serverが配置されることがあります。シングル・ポイント障害を回避するために、このHTTPスタックをレプリケートする必要があります。ユーザーに複数のHTTP URLが表示されることを防ぐには、HTTPロード・バランス機能を持つ外部の高可用性Webサーバーを設定する必要があります。このロード・バランサによってユーザーに単一のURLが提示され、このURLによって、レプリケートされたOracle BI EE URLのいずれかにリクエストがルーティングされます。

内部HTTPリクエストがローカルWebLogic管理対象サーバーに直接ルーティングされた場合は、高可用性は低下します。WebLogicインスタンスで障害が発生した場合は、ノード・マネージャによってそのインスタンスが再起動されます。WebLogicの再起動には数分間かかることがあります。この間は、ローカル・セキュリティ・サービスは使用不能になり、ログインできなくなります。これとは対照的に推奨の構成では、内部HTTPリクエストはロード・バランサを介してルーティングされます。代替のセキュリティ・サービスはすぐに使用可能になります。

15.1.2.1.2 Oracle BIプレゼンテーション・サービス・プラグインの高可用性の考慮事項

Oracle BIプレゼンテーション・サービス・プラグインは、分析.earアプリケーションとしてデプロイされます。このプラグインは、TCP経由のネイティブRPCプロトコルを使用して、リクエストをプレゼンテーション・サービス・インスタンスにルーティングします。またこのプラグインは、セッションCookieまたはURL引数を通じて全般的にセッション・アフィニティを維持しながら、複数のプレゼンテーション・サービス・インスタンス間のロード・バランシングも実行します。

それぞれのOracle BIプレゼンテーション・サービス・プラグイン・インスタンスは完全に独立しており、Oracle BIプレゼンテーション・サービス・プラグイン・インスタンス間の通信は行われません。それぞれは、過去におけるレスポンス時間と未処理リクエスト数に基づいて、ロード・バランシングについて独自に判断します。

ロード・バランサ上でセッション・アフィニティを構成することをお薦めします。

15.1.2.1.3 プレゼンテーション・サービスの高可用性の考慮事項

プレゼンテーション・サービスは、Oracle BIプレゼンテーション・サービス・プラグインからリクエストを受信します。初期ユーザー・セッション・リクエストは、クラスタ内の任意のプレゼンテーション・サービス・インスタンスに送信できますが、その後は各ユーザーは特定のBIプレゼンテーション・サービス・インスタンスにバインドされます。

エンドユーザー・リクエストの処理のために、プレゼンテーション・サービスはBI Serverと通信する必要があります。クラスタ環境では、BI Serverとの通信のためにはまずBI Cluster Controllerと通信します。プレゼンテーション・サービスは、クラスタ環境用に構成されたBI ODBCデータソースを介してCluster Controllerと通信して、プライマリCluster ControllerとセカンダリCluster Controllerを識別するとともに、これらがリッスンするポートを識別します。中央で管理されている構成が変更されるたびに、ODBCデータソース名（DSN）内の接続パラメータは、中央に配置されたBIドメイン構成ファイルに基づいて自動的に構成されます。このため、BI ODBC DSN接続パラメータをローカルで変更しないでください。

15.1.2.1.4 BI Cluster Controllerの高可用性の考慮事項

Cluster Controllerは、プレゼンテーション・サービスなどのクライアントからの新しいBI ServerセッションやOracle BI Schedulerセッションにとって最初の通信先です。Cluster Controllerは、次のようにアクティブ/パッシブ構成でデプロイされます。

  • プライマリCluster Controller: このコントローラはアクティブCluster Controllerです。

  • セカンダリCluster Controller: このコントローラはセカンダリCluster Controllerです。このコントローラは、プライマリCluster Controllerが使用不能になった場合にプライマリCluster Controllerの役割を担います。

両方のCluster Controllerがプライマリとして動作しようとするスプリット・ブレイン構成を回避することが重要です。この構成を回避するには、信頼性が低い可能性のあるWANを介して接続された別々のLAN上でCluster Controllerを構成しないでください。サイト障害に対するフォルト・トレランスでは、クラスタ化メカニズムではなく障害時リカバリ・メカニズムを使用する必要があります。

15.1.2.1.5 BI Serverの高可用性の考慮事項

複数のBI Serverをインストールおよび構成して、BI Serverクラスタを作成できます。Cluster Controllerは、Presentation Serverなどのクライアントからのリクエストをこのクラスタのアクティブ・メンバーにディスパッチします。


注意:

クラスタに参加している各サーバー上のクロックは同期している必要があります。クロックが同期していないと、レポートで時間のずれが生じることがあります。

マスターBI Serverは、BI管理ツールがRPDファイル内でオンライン・メタデータ変更を加えるために接続するサーバーです。これらのメタデータ変更内容は、他のサーバーが再起動されたときにこれらのサーバーに伝播されます。

BI Serverからデータベースへの通信

BI Serverは、Oracleデータベースを含む多くのデータベース・タイプとの通信をサポートしています。これらのBI Serverデータ・リポジトリには、未加工のファクト表が保持されています。Oracle BI EEはこれらにメタデータを保管しません。すべてのメタデータは、RPDファイルまたは（プレゼンテーション・サービスの場合は）Oracle BIプレゼンテーション・カタログに保管されます。

Oracle BI Schedulerは、Oracle BI Schedulerスキーマにデータを保管します。Oracle BI Schedulerのデータベース接続構成では、BI Serverと同じライブラリが使用されるため、フォルト・トレランス特性は同じです。唯一の違いは、Oracle BI Schedulerの操作の方がはるかに書込みが多いことです。BI Serverのデータソースは主に読取り専用です。

BI Serverのデータベース操作の主なポイントは次のとおりです。

  • ソース・データベース: ソース・データベースはOracle BI EEのレポート用に使用されます。これらは主に読取り専用です。ソース・データベースについては多くのオプションがサポートされています。

  • イベント・ポーリング: ファイル・システムからのキャッシュの削除や作成を常時チェックします。

  • 使用状況トラッキング

  • ライト・バック機能: ユーザー主導型の機能です。

実装では次の特性が実現されます。

  • すべてのデータベース読取り/書込み操作はC++コードによって実行されます。

  • Oracleデータベースの場合は、OCIが使用されます。他のデータベースやデータソースの場合は、ネイティブ・データベース機能が使用されます。

  • Oracleデータベースと非Oracleデータベースのサポートは、ソース・データベースについてだけでなく、Oracle BI Schedulerについても可能です。

15.1.2.1.6 管理ツールの高可用性の考慮事項

管理ツールでは、プレゼンテーション・サービスで使用されるのと同じBI ODBC DSNが使用されます。Cluster Controllerを介してマスターBI Serverに接続されます。マスターBI Serverが使用不能な場合は、管理ツールはRPDファイルへの書込みを実行できません。

15.1.2.1.7 Oracle BI Schedulerの高可用性の考慮事項

Oracle BI Schedulerインスタンスは、アクティブ/パッシブ・モデルに基づいて動作します。どの時点でも、1つのOracle BI Schedulerのみがアクティブになってリクエストを処理します。これにより、新しいジョブに一意のジョブIDが割り当てられます。非アクティブなOracle BI Schedulerはアイドル状態のまま待機し、アクティブなOracle BI Schedulerで障害が発生した場合に引継ぎを要請されるまで、ジョブを処理しません。インストールされた複数のOracle BIが同じスケジューラ表を使用するように構成しないでください。このように構成した場合は、複数のBI Schedulerがアクティブになり、一意のジョブIDが割り当てられなくなります。

Oracle BI Schedulerは、BI Serverと同じデータベース・テクノロジを使用します。

Oracle BI Schedulerの場合は、データベース操作の再試行は無制限に繰り返されます。Oracle BI Schedulerが稼働しており、データベースが停止している間、失敗したトランザクションはキューに格納されて、これらのトランザクションが正常に処理されるまで再試行されます。これらのトランザクションは、アクティブなOracle BI Schedulerインスタンスのメモリー内のキューに格納されます。したがって、バックエンド・データベース・ソースをメンテナンスのために停止でき、その再起動時には、Oracle BI EEのプロセスを再起動する必要はありません。これらは、Oracle BI Schedulerでの定期的パージと同じカウントで再試行されるため、同じ構成値を使用します。Oracle BI EEは、Oracle BI EEのメタデータに含まれている必要のある文のみを再試行します。つまり、問合せは再試行されず、挿入と削除のみが再試行されます（再実行される削除は除く）。このための構成値は、Oracle BI Schedulerのinstanceconfig.xmlファイルで確認できます（PurgeIntervalMinutes）。

15.1.2.1.8 BI JavaHostの高可用性の考慮事項

Oracle BI JavaHostコンポーネントは、リクエスト/レスポンスのモデルに基づいて、チャート、ゲージおよびPDFのプレゼンテーション・サービスにサービスを提供します。他のすべてのコンポーネントと同様に、管理者は中央のEnterprise Manager UIを使用して、デプロイされるインスタンスの数と場所を制御できます。JavaHostクライアントのデフォルト構成では、すべての使用可能なJavaHostが使用されます。これは、ローカルJavaHostのみを使用する以前の10gのデフォルト構成とは異なります。

15.1.2.2 共有されたファイルとディレクトリ

Oracle BI EEでは、プロセスの状態は、分散通信プロトコルを介してではなく、共有されたファイル・システムとデータベースを介して共有されます。特に、Oracle BI EEは、プロセス内やJavaコンポーネント内の状態を保管しません。したがってOracle BI EEは、コンポーネントの状態をシリアライズして、Javaクラスタ内で配信できるようにする必要はありません。

ファクト表とOracle BI Schedulerの表は、それぞれBI Serverインスタンス間とOracle BI Schedulerインスタンス間で共有されます。この共有と比べると、ファイル・システムの共有はあまり標準的ではないため、これについてはこの項の後半で詳しく説明します。NASやSANなどの共有ストレージ・デバイスを使用できます。

15.1.2.2.1 Oracle BIプレゼンテーション・カタログの共有ファイル

クラスタ内のプレゼンテーション・サービス・インスタンスは、共通のOracle BIプレゼンテーション・カタログを共有します。Oracle BIプレゼンテーション・カタログは、共有されたNASデバイスまたはSANデバイスに配置されている必要があります。プレゼンテーション・サービスのすべてのインスタンスは、この共有デバイスに対する読取りと書込みのアクセス権を持っている必要があります。同時アクセスは、ファイル・システムのロック・セマンティックによって管理されます。

Oracle BIプレゼンテーション・カタログは、頻繁にアクセスされる多数の小さいファイルで構成されているため、共有ファイル・システムに関する次の2つの重要な考慮事項に留意してください。

Oracle BIプレゼンテーション・カタログは、頻繁にアクセスされる多数の小さいファイルで構成されています。場合によっては、ファイル数が共有ファイル・システムのファイル制限を超えることがあるため注意してください。システムのファイル制限の設定については、お使いの共有ファイル・システムのドキュメントを参照してください。

15.1.2.2.2 リポジトリ公開ディレクトリの共有ファイル

このディレクトリは、クラスタに参加しているすべてのBI Serverによって共有されます。オンライン・モードで編集されるリポジトリのマスター・コピーが保持されます。マスターBI Serverは、このディレクトリに対する読取りと書込みのアクセス権を持っている必要があります。他のすべてのBI Serverは、読取りアクセス権を持っている必要があります。

クラスタ化されたBI Serverは、起動時にこのディレクトリを調べて、リポジトリの変更の有無を確認します。起動時に、BI Serverインスタンスは、公開ディレクトリ内のリポジトリをたとえば次のようなローカル・リポジトリ・ディレクトリにコピーします。

ORACLE_INSTANCE/bifoundation/OracleBIServerComponent/coreapplication_obis1/repository

このコピーは再起動時にしか実行されないため、すべてのBI Serverインスタンスが再起動されるまでは、書込み可能なrpdファイルが含まれたクラスタでは一貫性のない状況が発生することがあります（メタデータがAnswersのリクエストに一致しないなど）。実際には、メタデータの変更は、本番環境の読取り専用rpdファイルを使用して、通常は開発環境でオフラインで行われます。

15.1.2.2.3 グローバル・キャッシュの共有ファイル

グローバル・キャッシュは、クラスタに参加しているすべてのBI Serverによって共有されるキャッシュです。グローバル・キャッシュは、共有ファイル・システムのストレージ・デバイスに配置されており、パージ・イベント、シード・イベント（多くの場合はエージェントによって生成されます）、およびシード・イベントと関連付けられた結果セットを格納します。各Oracle BI Serverでは、通常の問合せ用に独自のローカル問合せキャッシュが引き続き保持されます。

グローバル・キャッシュの共有ファイル要件は次のとおりです。

  • すべてのBI Serverは、グローバル・キャッシュ・ディレクトリに対する読取りと書込みのアクセス権を持っている必要があります。

  • グローバル・キャッシュのパラメータは、クラスタに参加している各BI ServerノードのNQSConfig.INIファイルで構成します。グローバル・キャッシュは、Fusion Middleware Controlを使用して中央で管理されます。

  • BI Serverでは、問合せ結果セットのディスクベース・ローカル・キャッシュが保持されており、これは問合せキャッシュと呼ばれます。問合せキャッシュを使用すると、BI Serverは、バックエンド・データベースにアクセスすることなく多くの問合せリクエストを処理できます。これにより通信負荷が低減されるため、問合せのレスポンス時間を大幅に短縮できます。問合せキャッシュのエントリは、バックエンド・データベースで更新が行われるたびに古くなって無効になるため、定期的に消去される必要があります。問合せキャッシュの詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドを参照してください。

15.1.2.2.4 Oracle BI Schedulerスクリプトの共有ファイル

Oracle BI Schedulerスクリプトのネットワーク共有を作成する必要があります。このためには、Oracle BI Schedulerのinstanceconfig.xmlファイル（ORACLE_INSTANCE/config/OracleBISchedulerComponent/coreapplication_obischnにあります）のSchedulerScriptPath要素とDefaultScriptPath要素を更新します。Oracle BI Schedulerサーバーは、この共有に対する読取りと書込みのアクセス権を持っている必要があります。

15.1.2.3 クラスタの起動と停止

プロセス間には依存関係があるため、クラスタを特定の順序で起動する必要があります。起動手順は次のとおりです。

  1. すべてのWebLogic管理対象サーバーを起動します。システム・コンポーネントは、それぞれのローカル管理対象サーバーから認証サービスを受けます。

  2. Enterprise Manager Fusion Middleware Controlで、「すべてを起動」ボタンをクリックして、システム・アプリケーションに加えてJavaアプリケーションを正しい起動順序で起動します。これにより、確実に正しい順序で起動されます。

15.1.2.4 クラスタワイドの構成変更

構成の変更は高可用性にとって非常に重要であり、その中でもクラスタのメンバーに対する変更は特に重要です。クラスタに新しいメンバーを追加できないと、障害を修復できず、クラスタはその後の障害に対して脆弱になります（このため、高可用性システムでは平均修復時間は平均故障間隔と同じくらい重要です）。

Javaとシステムという2つのテクノロジ・スタックは別々に管理されます。

WebLogicの構成変更は、Oracle WebLogic管理コンソールで行います。標準のWebLogicメカニズムを使用して、変更中の構成をロックして、変更内容をすべての管理対象サーバーに伝播します。

システム・コンポーネントの構成変更は、Enterprise Manager Fusion Middleware Controlを使用して中央で行います。すべての構成変更が完了した後に、ユーザーが「保存」をクリックすると、構成の変更内容はすべてのローカル構成ファイルに配信されます。この構成配信は複数回実行しても同じ結果になります。すなわち、なんらかの理由により構成が破損するか配信に失敗した場合は、もう一度配信することによってローカル・ファイルが修正されます。ファイルの配信は、WebLogic構成ファイル配信と似たOracle JMX拡張によって実現されます。リモート・サイトでの配信は、JMX Meanコールによってアナウンスされます。MBeanはMBeanサーバーでホストされる必要があるため、これは、Oracle BI EEシステム・コンポーネントをホストしているすべてのマシンは、どのようなOracle BI EE Javaコンポーネントもホストしていない場合でも、WebLogic管理対象サーバーも備えている必要があることを意味します。

すべてのコンポーネントでは、そのコンポーネントが次回に再起動されたときに初めて構成変更が適用されます。コンポーネントの稼働中に構成変更は適用されません。

構成変更は次の場合にトリガーされます。

  • Fusion Middleware Controlで加えられた変更を管理者がコミットした場合。

  • MBean API（このAPIにはFusion Middleware Controlのユーザー・インタフェースが直接反映されます）によって加えられた変更を管理者がコミットした場合。

新しいインストールを登録するエンタープライズ・インストールによって構成の配信はトリガーされません。これによって、管理者がFusion Middleware Controlから選択できるマシンの集合が変更されます。新しいコンポーネント・インスタンスは構成に自動的に追加されません。

15.1.2.5 障害からの保護および予想される動作

この項では、発生する可能性のある様々な種類の障害と、各種類の障害が発生したときに予想される動作について説明します。

15.1.2.5.1 マシンの障害

マシンで一時的な障害が発生した場合は、そのマシンが再起動されると、クラスタは再起動されたコンポーネントを検知して、それらのコンポーネントを再び使用し始めます。マシンで永続的な障害が発生した場合は、そのマシンを交換する必要があります。既存のクラスタを拡張するエンタープライズ・インストールを使用して、新しいマシンにOracle BI EEをインストールしてください。

Oracle BI EEマシンの障害からのリカバリについては、『Oracle Fusion Middleware管理者ガイド』で、別のホストへのOracle BI EEのリカバリに関する項を参照してください。

15.1.2.5.2 WebLogic管理サーバーの障害

WebLogic管理サーバーはシングルトンであるため、同時に複数のインスタンスを稼働させることはできません。WebLogic管理サーバーの保護については、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。Oracle BI EEでは、WebLogic管理サーバーは管理タスクにのみ使用されます。

WebLogic管理サーバーが停止していると、Oracle BI EEを再構成することも、Enterprise Manager Fusion Middleware Controlを使用してログ・ファイルを参照することもできません。

15.1.2.5.3 WebLogic管理対象サーバーの障害

WebLogicノード・マネージャは、管理対象サーバーの障害を検知します。すべてのJavaコンポーネントはステートレスであるため、Oracle BI EEは、Javaクラスタの状態のメンテナンスについて配慮する必要はありません。

システム・コンポーネントから管理対象サーバーへのすべての通信では（例: プレゼンテーション・サービスからアクション・サービスへの通信）、ローカル管理対象サーバーに対するHTTPが使用されます。ローカル管理対象サーバーで障害が発生した場合は、ノード・マネージャによってそのサーバーが再起動されます。マシン全体にわたる障害は発生していないが、管理対象サーバーを再起動できない場合は、同じマシンで実行されているシステム・コンポーネントは次のような影響を受けます。

  • BI Server: ローカル管理対象サーバーが正常に稼働するまで使用不能になります。これにより、BI Serverを介したログインが影響を受けることが防止されます。ローカル管理対象サーバーが稼働していないことをBI Serverが検知すると、ログイン・リクエストをかわりに他のBI Serverに送信するようにCluster Controllerに指示します。

  • BIプレゼンテーション・サービス: アクションを実行できません。

  • BI Scheduler: アクティブ・スケジューラがこのマシン上で実行されている場合、スケジュール済アクションを実行できません。

    新しいScheduler接続（ジョブ・マネージャなどから）を確立できません。ローカル管理対象サーバーが稼働していないホスト上のBI Schedulerは、新しいユーザーを認証できません。

管理対象サーバーをオフラインにする必要がある場合は、まず該当するマシン上で実行されているすべてのシステム・コンポーネントを停止します。特定のマシン上の管理対象サーバーがなんらかの理由によって使用不能になった場合は、そのマシン上で実行されているすべてのシステム・コンポーネントを停止することをお薦めします。

15.1.2.5.4 Oracle BI Schedulerの障害

Oracle BI Schedulerは、Cluster Controllerによって監視および管理されます。Oracle BI Schedulerが使用不能な場合は、Cluster Controllerは、次のアクティブ化対象Oracle BI Schedulerインスタンスを決定します。元のプライマリOracle BI Schedulerが再び使用可能になった場合でも、プライマリ・ロールはそのOracle BI Schedulerには戻されません。

アクティブなOracle BI Schedulerで障害が発生しても、どの確立済クライアント接続でもエラーは受信されません。Oracle BI Schedulerプロトコルはステートレスであり、シームレスにフェイルオーバーするからです。

  • エージェント: エージェントの実行ではOracle BI Schedulerの表に状態が保持されます。次のOracle BI Schedulerインスタンスがアクティブになると、このインスタンスは、実行途中であったすべてのジョブ・インスタンスの状態を読み取って、これらのインスタンスを実行します。エージェントは、プライマリ・インスタンスの障害発生前に配信先とならなかった受信者に対してのみ配信します。

    エージェントのフェイルオーバーは、スケジュール済のエージェントについてのみサポートされます。たとえば、Answersのツールバーで「エージェントを今すぐ実行」をクリックした後に、プライマリOracle BI Schedulerで障害が発生した場合は、そのエージェントはセカンダリScheduler上で引き続き実行されることはなく、エラー・メッセージが「今すぐ実行」結果ダイアログ・ボックスに表示されます。

  • Java、コマンドラインまたはスクリプトのジョブ: これらのジョブは、新しいジョブ・インスタンスを使用して最初から再実行されます。


注意:

すべてのジョブ・インスタンスは、ジョブ・マネージャから手動で再実行できます。エージェントについては、正常に配信されなかったユーザーに対してのみ配信されます。たとえば、エージェントの実行途中でメール・サーバーが停止した場合、そのインスタンスの再実行では、メール・サーバーのクラッシュが原因で電子メールを受信できなかった受信者に対してのみ配信されます。

15.1.2.5.5 Cluster Controllerの障害

Cluster Controllerは、BI ServerまたはOracle BI Schedulerの障害の検知と、障害が発生したサーバーのクライアントのフェイルオーバーをサポートします。

Cluster Controllerは、アクティブ/パッシブのモデルに基づいて動作します。すべてのクライアントは、まずプライマリCluster Controllerへの接続を試行します。プライマリCluster Controllerが使用不能な場合は、クライアントはセカンダリCluster Controllerに接続します。セカンダリCluster Controllerは、負荷と可用性に基づいてリクエストをBI Serverに転送するとともに、アクティブなOracle BI Schedulerインスタンスにも転送します。プライマリが後で使用可能になった場合は、すべてのリクエストはプライマリに再び転送されます。

セカンダリCluster Controllerは、各BI Server上のセッション・カウントを監視しますが（プライマリと同様に）、プライマリCluster Controllerが停止している場合を除いて、どのOracle BI SchedulerがアクティブBI Schedulerであるかを決定しません。

プライマリとセカンダリのCluster Controllerは相互のライフ・サイクルを監視します。Cluster Controllerインスタンス間では通信不能になっているが、各インスタンスは稼働しており他のクライアントと通信できる場合は、スプリット・ブレイン障害が発生する可能性があります。このような場合は、BI Serverは影響を受けませんが、Oracle BI Schedulerの2つのインスタンスが同時にアクティブになる可能性があります。まれに、その結果としてジョブが二重実行されることがあります。通信が回復すると、プライマリCluster Controllerは、1つのOracle BI Schedulerのみがアクティブになる必要があることをクラスタに指示します。スプリット・ブレイン障害が発生する可能性を最小限に抑えるために、クラスタ・コンポーネントは同じLAN上に配置される必要があるとともに、クラスタ化デプロイメントではマルチNICはサポートされていません。

両方のCluster Controllerが使用不能な場合は、ログインしようとするすべての新しいユーザーにプレゼンテーション・サービスはエラーを返します。既存のセッションは影響を受けません。

Cluster Controllerは、各BI Serverインスタンス上のアクティブ・セッションの数を常時監視しています。新しいODBC接続が確立されると、Cluster Controllerは新しいセッションを割り当てることで、BI Server当たりのセッション数の均衡を保ちます。Oracle BI Serverインスタンスが一時的に停止してから回復した場合は、このインスタンスのセッション・カウントがクラスタ内の他のインスタンスのセッション・カウントと等しくなるまでは、すべての新しいODBCセッションはこのノードにルーティングされます。

Cluster Controllerで障害が発生すると、新しいセッションを最初に作成しようとしたユーザーに対しては、セカンダリCluster Controllerが稼働開始するまでに約6秒間の遅延が生じます。それ以降は、他のすべての接続はセカンダリにルーティングされます。

15.1.2.5.6 プレゼンテーション・サービスの障害

プレゼンテーション・サービスの障害は次に影響を与えます。

  • Webクライアント: 初期ユーザー・セッション・リクエストは、任意のプレゼンテーション・サービス・インスタンスに送信できますが、その後は各ユーザーは特定のBIプレゼンテーション・サービス・インスタンスにバインドされます。そのプレゼンテーション・サービス・インスタンスが失われると、セッションが切断されて、ブラウザにエラーが返されます。サーバーが使用不能になったときに進行途中であった作業のうち、ディスクに保存されていなかったものの内容はすべて失われます。ユーザーは再びログインして、使用可能なプレゼンテーション・サービス・インスタンスに対する新しい接続を確立する必要があります。ユーザーのログインがOracle Single Sign-Onなどのシングル・サインオン・システムを使用して行われている場合は、この再ログインは自動的に実行されます。新しいプレゼンテーション・サービス・セッションによって新しいBI Serverセッションが作成されます。


    注意:

    プレゼンテーション・サービス・インスタンスで障害が発生すると、少し間隔を置いてから、システムによってそのインスタンスで障害が発生したことが検知されて、ユーザーが新しいプレゼンテーション・サービス・インスタンスに移行されます。シングル・サインオン・ソリューションが使用されている場合は、ユーザーは再認証する必要はありません。シングル・サインオンが使用されていない場合は、ユーザーは再認証する必要があります。

  • エージェント: Oracle BI Schedulerにエラーが転送されます。Oracle BI Schedulerは障害をログに記録してから、ジョブを再試行します。この再試行によって、使用可能なプレゼンテーション・サービスに対する新しい接続が確立されます。

15.1.2.5.7 BI Serverの障害

BI Serverで障害が発生すると、ODBCエラーがクライアントに返されます。

  • プレゼンテーション・サービス: Oracle BIの各Webユーザーのリクエストは、単一のBI Serverによって処理されます。このBI Serverが使用不能になった場合は、エンド・ユーザーにはエラーが表示されることがありますが、ブラウザのリフレッシュによって、使用可能なBI Serverとの新しいセッションが確立されます。

  • 管理ツール: 管理ツールは、その接続先であるBI Serverが使用不能になると、ODBCエラーを転送してから接続を切断します。管理者は再接続する必要があります。

  • エージェント: BI Serverで障害が発生すると、Oracle BI Schedulerにエラーが転送されます。Oracle BI Schedulerは障害をログに記録してから、ジョブを再試行します。これにより、使用可能なBI Serverとの接続が確立されます。

  • サード・パーティ・クライアント: サード・パーティ・クライアントはODBCを使用してBI Serverに接続します。BI Serverで障害が発生すると、エラーが転送されて、ODBC標準に従ってセッションが切断されてから再確立されます。

  • マスターBI Serverの障害: マスターBI Serverが使用不能な場合は、オンライン・メタデータ変更を実行できません。これは管理操作であり、ランタイムの可用性には影響を与えません。マスターBI Serverが永続的に使用不能になった場合は、他のBI Serverのいずれかを新しいマスターとして指定する必要があります。このためには、すべてのサーバーを再構成する必要があります。すべての構成変更と同様に、再起動が必要になります。新しいマスターBI Serverの指定については、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドを参照してください。

15.1.2.5.8 Oracle BI EEのトラブルシューティング

一般にリカバリの問題は、プロセスの起動失敗に関係しています。推奨されるトラブルシューティング手順は次のとおりです。

  1. Enterprise Manager Fusion Middleware Controlをチェックして、どのプロセスが実行されているか確認します。これにはOPMNによって報告される状態が反映されます。

  2. OPMNログ・ファイルをチェックします。これらは、Enterprise Manager Fusion Middleware Controlからアクセスできます。これらは、表15-1で明示している場所でもアクセスできます。

  3. 正常に実行されなかったプロセスを特定したら、そのログ・ファイルをチェックしてください。このログ・ファイルには、Enterprise Manager Fusion Middleware Controlから、または表15-1で明示している場所でアクセスできます。

特定のプロセスは、そのピアと通信できない場合に停止されます。この問題を診断する手順は次のとおりです。

  1. 正常に実行されなかったプロセスを特定します。ログ・ファイルで低レベル・ソケット・エラーを探します。これによりポートとサーバー・アドレスが特定されます。ローカル構成ファイルをチェックして、どのプロセスがそのポートでリッスンするように構成されているのかを確認します（単純なデプロイメントでは、第15.1.2.1項「Oracle BI EEの高可用性アーキテクチャ」においてコンポーネントに関する説明で示されているように、デフォルトのポート割当てが使用されます）。現在構成されているポートは、Fusion Middleware Controlの「可用性」ページで確認できます。

  2. ピアが動作しているかどうか確認します。ピアが動作している場合は、そのログ・ファイルをチェックして、通信を拒否するエントリがないか確認します。通信が拒否される可能性があるのは、SSL構成が矛盾している場合やプロトコル障害が発生している場合です。

Cluster Controllerの管理対象プロセスの構成がCluster Controllerと一致していない場合は、これらのプロセスは正常に実行されません。一部のフェイルオーバー・イベントはログに記録されませんが、Cluster Controllerのログ・ファイルには、すべてのOracle BI SchedulerインスタンスまたはBI Serverインスタンスのクラッシュが記録されます。

初回の起動後にログ・ファイルを確認してください。BI ServerまたはOracle BI Schedulerのインスタンスが、Cluster Controllerによる仕様どおりに正しく構成されていない場合は、そのインスタンスは、停止されない可能性がありますが、クラスタには追加されません。ログ・ファイルにはこのようなエラーが記録されます。

15.1.3 Oracle BI EEの高可用性の構成手順

この項では、Oracle BI EEおよびBI Publisherにおいて2ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図15-2に示しています。


注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

15.1.3.1 Oracle BI Enterprise EditionおよびBI Publisherの高可用性構成の設定前に必要な手順

次の項では、Oracle BI EEおよびOracle BI Publisherの高可用性構成を設定する前に必要となる手順を説明します。

15.1.3.1.1 データベースに関する前提条件

Oracle BI EEでサポートしているデータベースのバージョンは次のとおりです。

  • Oracle Database 10g（非XEデータベースについては10.2.0.4以上）

  • Oracle Database 11g（非XEデータベースについて11.1.0.7以上）

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.1.3.1.2 VIPとIPに関する前提条件

図15-6で示すように、異なる仮想IPをリスニングするようにBI管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。各VIPが使用可能かつアクセス可能であることを、インストールの実行前に確認してください。

表15-2 BI EEの仮想ホスト

仮想IP 仮想IPのマップ先 説明

VIP1

APPHOST1VHN1

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

VIP2

APPHOST2VHN1

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

15.1.3.1.3 共有記憶域に関する前提条件

障害発生時に適切にリカバリできるようにするため、すべてのノードからアクセスできて、管理対象サーバーで障害が発生した後に操作を再開できる場所に、JMSとトランザクションの両方のログを格納します。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表15-3は、共有記憶域の内容を示しています。

表15-3 BI EEの共有記憶域の内容

サーバー データの型 共有記憶域のボリューム ディレクトリ ファイル

BI_SERVER1とBI_SERVER2

トランザクション・ログ

VOL2

ORACLE_BASE/admin/domain_name/cluster_name/tlogs

共通の場所（WebLogicサーバーにより決められたストア）

BI_SERVER1とBI_SERVER2

JMSストア

VOL2

ORACLE_BASE/admin/domain_name/cluster_name/jms

共通場所ですが、サーバーごとに個別のストアになります。たとえば、BI_SERVER1の場合、BipJmsStore_auto_1になります。BI_SERVER2の場合、BipJmsStore_auto_2になります。

BI_SERVER1とBI_SERVER2

BI Serverリポジトリ

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/ClusterRPD

共通の場所

BI_SERVER1とBI_SERVER2

BIグローバル・キャッシュ

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/GlobalCache

共通の場所

BI_SERVER1とBI_SERVER2

BIプレゼンテーション・サービス・リポジトリ

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/catalog

共通の場所

BI_SERVER1とBI_SERVER2

BI Publisher構成フォルダ

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/config

共通の場所

BI_SERVER1とBI_SERVER2

BI Publisherカタログ・リポジトリ

VOL1

ORACLE_BASE/domain_name/config/bipublisher/catalog

これが必要なのは、「BI Publisherカタログ」タイプで「Oracle BI Publisher - ファイル・システム」が選択されている場合のみです。

共通の場所

BI_SERVER1とBI_SERVER2

BI Publisher Scheduler一時ディレクトリ

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/temp

共通の場所

共有記憶域にはNASやSANなどのデバイスを使用できます。NAS over NFSデバイスに基づいたコマンド例を次に示します。この項で指定しているオプションは、実際のオプションと異なる場合があります。

APPHOST1> mount naasfiler:/vol/volX/FMWshared MW_HOME-t nfs -o
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
15.1.3.1.4 クロックの同期

クラスタに参加しているすべてのサーバーにおけるクロックは、1秒以内の誤差で同期している必要があります。これを実現するには、単一のネットワーク・タイム・サーバーを使用して各サーバーはそのネットワーク・タイム・サーバーを指すようにします。ネットワーク・タイム・サーバーを指す実際の手順は、WindowsとLinuxとでは異なります。お使いのオペレーティング・システムのドキュメントを参照してください。

15.1.3.1.5 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Clusterwareインストレーション・ガイド』を参照してください。

自動ストレージ管理

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。

インストーラを実行するときは、構成の選択ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g（11.1.1）Oracle Fusion MiddlewareリポジトリをOracle Real Application Clusters（Oracle RAC）データベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ（RCU）が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g（11.1.1）Oracle Fusion MiddlewareリポジトリをOracle RACデータベースにインストールします。

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

15.1.3.1.6 RCUを使用したデータベースへのBusiness Intelligenceスキーマのロード

Oracle Business Intelligenceをインストールする前に、11g（11.1.1）Oracle Fusion Middlewareのメタデータ・ストアとOracle BIスキーマをOracle RACデータベースにインストールします。次の手順を実行します。

  1. リポジトリ作成ユーティリティ（RCU）のDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。

    prompt> cd RCU_HOME/bin
prompt> ./rcu

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

  3. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。

  4. 「データベース接続の詳細」画面で、データベースの接続情報を入力します。

    • データベース・タイプ: Oracle Databaseを選択します。

    • ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します。次に例を示します。

      BIDBHOST1-VIP

    • ポート: データベースのリスニング・ポート番号である1521を指定します。

    • サービス名: データベースのサービス名を指定します。

      biha.mycompany.com

    • ユーザー名: DBA権限またはSYSDBA権限のあるユーザーの名前（SYS）を指定します。

    • パスワード: SYSユーザーのパスワードを入力します。

    • ロール: データベース・ユーザーのロール（SYSDBA）をリストで選択します（SYSユーザーに必要）。

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

  5. 「コンポーネントの選択」画面で、次を行います。

    • 「接頭辞の新規作成」を選択し、BIHAのように、データベース・スキーマに使用する接頭辞を入力します。6文字まで接頭辞として指定できます。接頭辞を使用して、複数リポジトリの論理グルーピングをデータベースにおいて作成します。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。


      ヒント:

      このスキーマの名前をメモに記録してください。後述する手順でこの情報が必要になります。

    • 次のコンポーネントを選択します。

      o  AS Common Schemas: Metadata Services (automatically selected)
o  Oracle Business Intelligence: Business Intelligence Platform

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

  6. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。

    要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択できます。

    「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。


    ヒント:

    スキーマ・パスワードの名前をメモに記録してください。後述する手順でこの情報が必要になります。

  7. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

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

  9. 「完了サマリー」画面で「閉じる」をクリックします。

15.1.3.1.7 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle BI EEの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

Oracle BI EEは、2つのOracle HTTP ServerがWeb層コンポーネントとして使用された高可用性構成でデプロイされた場合は、ハードウェア・ロード・バランサを使用します。

仮想サーバー名

bi.mycompany.comは、Oracle BI PublisherなどのランタイムBIコンポーネント宛のすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、bi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

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

この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。

  1. サーバーが次の要件を満たしていることを確認します。

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

    • ポート7777がWEBHOST1上のサービスによって使用されていないことを確認するために、使用するオペレーティング・システムに応じて次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。

      UNIXの場合:

      netstat -an | grep "7777"

      Windowsの場合:

      netstat -an | findstr :7777

      ポートが使用されている（コマンドを実行するとポートを識別する戻り値が表示される）場合は、そのポートを解放する必要があります。

      UNIXの場合:

      ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

      Windowsの場合:

      ポートを使用しているコンポーネントを停止します。

    • staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

    • 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート（Oracle HTTP Serverのポート番号を指定する行は非コメント化）を割り当てます。

      # The port for Oracle HTTP server
Oracle HTTP Server port = 7777

  2. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。

    UNIXの場合:

    ./runinstallerコマンドを発行します。

    Windowsの場合:

    setup.exeをダブルクリックします。

    「インベントリ・ディレクトリの指定」画面が表示されます。

  3. 「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。次に例を示します。

    インベントリ・ディレクトリの指定: /u01/app/oraInventory

    オペレーティング・システムのグループ名: oinstall

    次のメッセージのダイアログ・ボックスが表示されます。

    インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください。

    rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。

    これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。


    注意:

    すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールでOracleインベントリ画面が表示されない場合は、次の内容を確認してください。

    • /etc/oraInst.locファイルが存在しているか。

    • このファイルが存在する場合は、表示されているインベントリ・ディレクトリが有効か。

    • インストールを実行しているユーザーがインベントリ・ディレクトリに対する書込み権限を持っているか。

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

  5. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

  6. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。

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

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

    • Oracle Middlewareホーム: ORACLE_BASE/product/fmw（グレーアウトされています）

    • Oracleホーム・ディレクトリ: Oracle_WT1

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

  8. 「コンポーネントの構成」画面で、次の操作を行います。

    • 「Oracle HTTP Server」を選択します。

    • 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

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

  9. 「コンポーネントの詳細の指定」画面で、WEBHOST1用に次の値を入力します。

    • インスタンス・ホームの場所: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1

    • インスタンス名: web1

    • OHSコンポーネント名: ohs1

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

  10. 「ポートの構成」画面で、次の操作を行います。

    • カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

    • Oracle HTTP Serverポートを入力します（例: 7777）。

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

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

  12. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「インストール」をクリックします。

  13. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

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

  14. 「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。「次へ」をクリックします。

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

WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランサを構成します。

15.1.3.1.9 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、Webブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

http://WEBHOST1:7777/
http://WEBHOST2:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザにOracle FMWの「ようこそ」画面が表示されます。

15.1.3.2 高可用性のためのOracle Business Intelligence Enterprise Editionのインストール

この項では、Oracle WebLogic ServerとOracle Fusion Middleware BI EEを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。WebLogic ServerとOracle BI EEをAPPHOST2にインストールするために、これと同じ手順を繰り返します（次ではAPPHOST1を対象にして説明しています）。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

  • Oracle WebLogic Server

  • Oracle Business Intelligence

この項では、ソフトウェアのみのインストールを実行してから、config.sh構成スクリプトを使用してOracle BIシステムを作成およびスケール・アウトします。

15.1.3.2.1 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールする手順は次のとおりです。

  1. Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。

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

  3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

    • 「新しいミドルウェア・ホームを作成する」を選択します。

    • 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します。


      注意:

      ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracleの値をお薦めします。

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

  4. 「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

  5. 「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。

  6. 「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.5ディレクトリを受け入れます。そして「次へ」をクリックします。

  7. 「インストールの概要」画面で「次へ」をクリックします。

    Oracle WebLogic Serverソフトウェアがインストールされます。

  8. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

15.1.3.2.2 Business Intelligence Enterprise EditionおよびOracle BI Publisher用のOracle Fusion Middlewareのインストール

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

  1. Oracle Fusion Middleware Business Intelligence 11gのインストーラを次のインストール・メディアから起動します。

    UNIXの場合:

    APPHOST1>./runInstaller

    Windowsの場合:

    APPHOST1> setup.exe

  2. 「インベントリ・ディレクトリの指定」画面で、次の操作を行います。

    • HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです（この場所をお薦めします）。

    • インストールを実行するユーザーのOSグループを入力します。

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

    • 画面の手順に従って、/createCentralnventory.shをrootとして実行します。

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

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

  4. 「インストール・タイプの選択」画面で、「ソフトウェアのみインストール」を選択して「次へ」をクリックします。

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

  6. 「インストール場所の指定」画面で、前にインストールしたMiddlewareホームをドロップダウン・リストで選択します。「Oracleホーム」ディレクトリには、ディレクトリ名（Oracle_BI1）を入力します。

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

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

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

    Oracle Fusion Middleware Business Intelligence 11gソフトウェアがインストールされます。

  9. 「インストールの進行状況」画面で「次へ」をクリックします。

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

15.1.3.3 APPHOST1のVIP1およびAPPHOST2のVIP2の有効化

BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してマッピングされているVIPを有効にして（APPHOST1ではVIP1、APPHOST2ではVIP2）、トポロジで使用されるネットワーク・システムで仮想ホスト名を（DNSサーバーとhosts解決のいずれかで）正しく解決する必要があります。

15.1.3.4 管理サーバーと1つ目のBI_SERVER1管理対象サーバーが含まれたドメインの作成

この項では、Oracle Business Intelligenceコンフィギュレーション・アシスタント、Oracle WebLogic Server管理コンソールおよびOracle Enterprise Managerを使用して、ドメインと最初のWebLogic Server BI管理対象サーバーを作成する方法について説明します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。


注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

Oracleホーム・ディレクトリからコンフィギュレーション・アシスタントを実行して、BI Publisherが配置された管理対象サーバーおよび管理サーバーが含まれたドメインを作成します。

  1. コンフィギュレーション・アシスタントの場所にディレクトリを移動します。

    APPHOST1> cd ORACLE_HOME/bin

  2. コンフィギュレーション・アシスタントを起動します。

    UNIXの場合:

    APPHOST1> ./config.sh

    Windowsの場合:

    APPHOST1> config.cmd

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

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

  5. BIシステムの作成またはスケールアウト画面が表示されます。新規BIシステムの作成を選択して、次の値を指定します。

    • ユーザー名: weblogic

    • ユーザー・パスワード: weblogicユーザーのパスワードを入力します。

    • ドメイン名: bifoundation_domain

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

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

    • MiddleWareホーム: ORACLE_BASE/product/fmw（グレーアウトされています）

    • Oracleホーム: ORACLE_BASE/product/fmw/Oracle_BI1（グレーアウトされています）

    • WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3（グレーアウトされています）

    • ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain


      注意:

      「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

    • インスタンス・ホーム: ORACLE_BASE/product/fmw/instance1

    • インスタンス名: instance1

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

  7. 「コンポーネントの構成」画面で、次を選択します。

    - Oracle Business Intelligence
       - Business Intelligence Enterprise Edition
       - Business Intelligence Publisher

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

  8. 「データベース詳細」画面で、次の値を入力します。

    • データベース・タイプ: Oracle Database

    • 接続文字列: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM

    • BIPLATFORMスキーマ・ユーザー名: BIHA_BIPLATFORM

    • BIPLATFORMスキーマ・パスワード: BIPLATFORMスキーマ・ユーザーのパスワードを入力します。

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

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

    • 自動でポートを構成

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

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

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

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

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

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

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

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。

  1. 次のディレクトリに移動します。

    ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/
AdminServer/security

  2. 次の行をファイルに入力し、ファイルを保存してからエディタを閉じます。

    username=Admin_username
password=Admin_password

    注意:

    管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

    セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

15.1.3.6 APPHOST1での管理サーバーの起動と検証

この項では、APPHOST1で管理サーバーを起動および検証する手順について説明します。

15.1.3.6.1 APPHOST1での管理サーバーの起動

APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin
APPHOST1> ./startWebLogic.sh
15.1.3.6.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

  1. ブラウザでhttp://APPHOST1:7001/consoleにアクセスします。

  2. 管理者としてログインします。

  3. BI_SERVER1管理対象サーバーが表示されていることを確認します。

  4. bi_clusterクラスタが表示されていることを確認します。

  5. Enterprise Manager（http://APPHOST1:7001/em）にアクセスできることを確認します。

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

次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。

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

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

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

  4. 「サーバー」をクリックします。

    「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で「bi_server1」を選択します。

    bi_server1の「設定」ページが表示されます。

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

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

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

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

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

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

  10. BIシステムのコンポーネントを再起動します。次に例を示します。

    cd ORACLE_BASE/admin/instance1/bin
./opmnctl restartproc
15.1.3.7.1 Oracle BI Publisher Schedulerの構成の更新

この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLを更新します。

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

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

    http://APPHOST1VHN1:9704/xmlpserver

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

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

  4. 次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。

    t3://APPHOST1VHN1:9704

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

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

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

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  12. BIシステムのコンポーネントを再起動します。次に例を示します。

    cd ORACLE_BASE/admin/instance1/bin
./opmnctl restartproc

15.1.3.9 APPHOST1でのシステムの起動

この項では、APPHOST1でノード・マネージャを起動する方法、およびAPPHOST1でBI_SERVER1管理対象サーバーを起動して検証する方法について説明します。

15.1.3.9.1 APPHOST1でのノード・マネージャの起動

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合、次のコマンドを使用してAPPHOST1で起動します。

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
15.1.3.9.2 BI_SERVER1管理対象サーバーの起動と検証

BI_SERVER1管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。

  1. Oracle WebLogic Server管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。

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

    2. 「サーバー」を選択します。

      「サーバーのサマリー」ページが表示されます。

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

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

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

  3. BI_SERVER1が起動すると、次のURLが使用できるようになります。

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


      注意:

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

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

15.1.3.9.3 APPHOST1でのBusiness Intelligence Enterprise Editionシステム・コンポーネントの起動と検証

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

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

  1. OPMNコマンドライン・ツールが格納されたディレクトリに移動します。


    注意:

    OPMNコマンドライン・ツールは、ORACLE_INSTANCE/binディレクトリにあります。

  2. opmnctlコマンドを実行して、BI Enterprise Editionのシステム・コンポーネントを起動します。

    • opmnctl startall

      このコマンドは、OPMNとすべてのBI Enterprise Editionシステム・コンポーネントを起動します。

    • opmnctl start

      このコマンドはOPMNのみを起動します。

    • opmnctl startproc ias-component=componentName

      このコマンドは、指定されたシステム・コンポーネントを起動します。次に、coreapplication_obips1がBI Presentation Serverである場合の実行例を示します。

      opmnctl startproc ias-component=coreapplication_obips1

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

    opmnctl status

15.1.3.10 APPHOST2でのBIシステムのスケール・アウト

第15.1.3.2項「高可用性のためのOracle Business Intelligence Enterprise Editionのインストール」の手順に従って、APPHOST2でOracle WebLogic ServerとOracle Business Intelligenceのソフトウェアのみをインストールします。

次に、ORACLE_HOMEディレクトリからコンフィギュレーション・アシスタントを実行して、BIシステムをスケール・アウトします。

  1. コンフィギュレーション・アシスタントの場所にディレクトリを移動します。

    APPHOST2> cd ORACLE_HOME/bin

  2. コンフィギュレーション・アシスタントを起動します。

    APPHOST2> ./config.sh

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

  4. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。

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

  5. BIシステムの作成またはスケールアウト画面が表示されます。BIシステムのスケールアウトを選択して、次の値を入力します。

    • ホスト名: ADMINHOST

    • ポート: 7001

    • ユーザー名: weblogic

    • ユーザー・パスワード: weblogicユーザーのパスワードを入力します。

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

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

    • MiddleWareホーム: ORACLE_BASE/product/fmw（グレーアウトされています）

    • Oracleホーム: Oracle_BI1（グレーアウトされています）

    • WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3（グレーアウトされています）

    • ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain

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

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

    • インスタンス名: instance2（グレーアウトされています）

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

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

    • 自動でポートを構成

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

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

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

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

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

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

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、APPHOST2で次のコマンドを実行してノード・マネージャを起動します。

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

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

Fusion Middleware Controlで次の手順を実行します。

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

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

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

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

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

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

    • BI Server

    • Presentation Server

    • JavaHost

  7. 「ポート範囲(開始)」と「ポート範囲(終了)」を、APPHOST1の「instance1」Oracleインスタンスと同じになるように変更します。

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

  9. 次のメッセージが表示されます。

    警告: 複数のPresentation Serverが構成されているため、共有の場所が指し示されるようにカタログの場所を調整する必要があります

    「OK」をクリックします。この構成は、後の手順で実行します。

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

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

15.1.3.12 シングルトン・コンポーネントのアクティブ/パッシブ化

Fusion Middleware Controlで次の手順を実行します。

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

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

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

  4. 「容量管理」をクリックしてから、「可用性」をクリックします。

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

  6. BI SchedulerとBI Cluster Controllerの「パッシブ・ホスト/インスタンス」を指定します。

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

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

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

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

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

次の手順を実行して、BI_SERVER2管理対象サーバーのリスニング・アドレスを設定します。

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

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

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

  4. 「サーバー」をクリックします。

    「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で「bi_server2」を選択します。

    bi_server2の「設定」ページが表示されます。

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

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

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

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

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

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

  10. BIシステムのコンポーネントを再起動します。次に例を示します。

    cd ORACLE_BASE/admin/instance2/bin
./opmnctl restartproc
15.1.3.13.1 APPHOST1およびAPPHOST2でのOracle BI Publisher Schedulerの構成の更新

この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLを更新します。

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

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

    http://APPHOST1VHN1:9704/xmlpserver
http://APPHOST2VHN1:9704/xmlpserver

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

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

  4. 次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。

    t3://APPHOST1VHN1:9704,APPHOST2VHN1:9704

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

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

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

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。

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

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

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

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

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

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

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

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

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

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

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

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

15.1.3.15 Oracle BI EEの構成

この項では、Oracle BI EEを構成する方法を説明します。

15.1.3.15.1 共有Oracle BIリポジトリの場所の設定

Fusion Middleware Controlで次の手順を実行します。

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

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

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

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

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

  6. 「リポジトリの共有」を選択して、Oracle BIリポジトリの「共有場所」を指定します。Windows環境では、Enterprise Manager Fusion Middleware Controlの要件として、UNCパスを使用してリポジトリの共有場所を定義する必要があります。

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

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

15.1.3.15.2 BI Serverの共有グローバル・キャッシュの設定

Fusion Middleware Controlで次の手順を実行します。

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

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

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

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

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

  6. 「グローバル・キャッシュ」セクションで、Oracle BI Serverグローバル・キャッシュの共有場所を指定して、グローバル・キャッシュ・サイズとして250MBを指定します。Windows環境では、Enterprise Manager Fusion Middleware Controlの要件として、UNCパスを使用してOracle BI Serverグローバル・キャッシュの共有場所を定義する必要があります。

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

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

15.1.3.15.3 Schedulerスクリプト・パスとデフォルト・スクリプト・パスの設定

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

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

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

  1. デフォルトのOracle BI Schedulerスクリプト（例: ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/common）とカスタムのOracle BI Schedulerスクリプト（例: ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/scheduler）をBI Schedulerスクリプトの共有場所にコピーします。

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

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

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

    デプロイメント環境内の各Oracle BI Schedulerコンポーネントについて、このファイルを更新する必要があります。

15.1.3.15.4 共有Oracle BIプレゼンテーション・カタログの場所の設定

Fusion Middleware Controlで次の手順を実行します。

  1. 既存の（ローカルに公開された）Oracle BIプレゼンテーション・カタログを共有場所にコピーします。次にローカルに公開されたカタログの例を示します。

    ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/
coreapplication_obipsn/catalog/SampleAppLite

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

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

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

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

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

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

  7. 共有Oracle BIプレゼンテーション・カタログの「カタログの場所」を指定します。Windows環境では、Enterprise Manager Fusion Middleware Controlの要件として、UNCパスを使用してプレゼンテーション・カタログの共有場所を定義する必要があります。

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

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

15.1.3.16 Oracle BI Officeの追加の構成タスク

Oracle BI Officeの追加の構成タスクを実行するには、次の手順を実行します。

  1. 次のURLにアクセスして、Oracle BI Enterprise Edition Officeサーバーのセットアップを検証します。

    • http://APPHOST1VHN1:9704/bioffice/about.jsp

    • http://APPHOST2VHN1:9704/bioffice/about.jsp

    Oracle BI EE Officeサーバーについてページが表示されます（図15-3を参照）。

    図15-3 Oracle BI EE Officeサーバーについてページ

    図15-3の説明は次にあります。
    「図15-3 Oracle BI EE Officeサーバーについてページ」の説明

  2. Oracle BI Enterprise Edition Officeサーバーのディレクトリに移動します。次に例を示します。

    DOMAIN_HOME/servers/managed_server/tmp/_WL_user/bioffice_11.1.1/b8z5dp/war/WEB-INF

    Oracle BI Enterprise Edition Officeサーバーのディレクトリの場所がわからない場合は、Oracle BI EE Officeサーバーについてページで「LogDir」パラメータを確認してください。Oracle BI Enterprise Edition Officeサーバーのディレクトリは、logディレクトリの親ディレクトリです。

  3. APPHOST1およびAPPHOST2の両方で、bioffice.xmlを編集のために開いて、表15-4のとおりにBI Officeのプロパティを変更します。

    表15-4 bioffice.xml内のBI Officeのプロパティ

    プロパティ名 有効な値 説明

    SawBaseURL

    https://bi.mydomain.com:443/analytics/saw.dll

    または

    https://bi.mydomain.com:443/analytics-ws/saw.dll

    Oracle BIプレゼンテーション・サービスのロード・バランサ仮想サーバー名URLです。

    重要: SSOが有効になっている場合は、BI OfficeをSSO対応のOracle BI Serverと統合するように構成する際にデプロイした保護された分析サーブレットのURLを入力してください。このプロパティで指定されたURLは、BI Officeサーバーとプレゼンテーション・サービスの間のWebサービス・リクエスト用に使用されます。

    SawUseSSO

    0: いいえ（デフォルト）

    1: はい

    実装されたOracle Business IntelligenceがSSOに対応している場合は、このプロパティを1に設定します。

    SawWebURLforSSO

    https://bi.mydomain.com:443/analytics/saw.dll

    SSOが有効になっている場合は、このプロパティを使用してパブリックURLを入力します。外部ユーザーはこのURLを使用して、Microsoft OfficeのOracle BIアドインからSSOを使用してOracle Business Intelligenceにアクセスできます。

  4. 次の手順に従ってBI Officeアプリケーションを再起動します。

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

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

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

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

    5. アプリケーションが停止したら、「起動」をクリックします。

  5. Oracle BI EE Officeサーバーについてページで、「SawBaseURL」パラメータが更新されていることを確認します。

15.1.3.16.1 Oracle BI Officeの検証手順

Oracle BI Officeの構成を検証するには、次の手順を実行します。

  1. 次のURLにアクセスしてOracle BIプレゼンテーション・サービスにログインします。

    https://bi.mydomain.com:443/analytics

  2. 左下ペインの「はじめに」見出しの下で、「BIデスクトップ・ツールのダウンロード」を選択してから、「Oracle BI for MS Office」を選択します。

  3. Oracle BI OfficeのInstallShieldウィザードを実行して、Oracle BI for Microsoftをインストールします。

  4. Microsoft ExcelまたはMicrosoft PowerPointを開きます。

  5. 「Oracle BI」メニューから「設定」を選択します。

  6. 「接続」タブで「新規」を選択します。

  7. 次のフィールドの値を入力します。

    • サーバー名: 接続の名前を指定します。

    • BI Officeサーバー: Oracle BI OfficeサーバーのURLを指定します。

    • アプリケーション名: Oracle BI Officeサーバー・アプリケーションをWLSにデプロイしたときにOracle BI Officeサーバーに対して定義したアプリケーション名を入力します。デフォルト名は「bioffice」です。

    • ポート: Oracle BI Officeサーバーのポート番号を入力します。

    図15-4は、「新規接続」ダイアログを示しています。

    図15-4 Oracle BI Officeの「新規接続」ダイアログ

    図15-4の説明は次にあります。
    「図15-4 Oracle BI Officeの「新規接続」ダイアログ」の説明

  8. 「接続のテスト」をクリックして、アドインとOracle BI Officeサーバー間の接続をテストします。

    正常に接続されている場合は、図15-5に示すように「接続テストが成功しました。」というメッセージが表示されます。

    図15-5 「接続テストが成功しました。」メッセージ

    図15-5の説明は次にあります。
    「図15-5 「接続テストが成功しました。」メッセージ」の説明

  9. 管理者（例: weblogic）としてログインして、図15-6に示す「Oracle BIタスク・ペイン」にアクセスできることを確認します。

    図15-6 Microsoft Excel内の「Oracle BIタスク・ペイン」

    図15-6の説明は次にあります。
    「図15-6 Microsoft Excel内の「Oracle BIタスク・ペイン」」の説明

15.1.3.17 Oracle BI Publisherの構成

この項では、Oracle BI Publisherを構成する方法を説明します。

15.1.3.17.1 サーバー構成オプションの設定

Oracle BI Publisherのサーバー構成オプションを設定するには、次の手順を実行します。

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

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

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

  4. 構成フォルダ用に次のフィールドを入力します。

    • パス: 構成フォルダの共有場所のパスを入力します。

  5. 変更を適用してから、BI Publisherアプリケーションを再起動します。

15.1.3.17.2 Oracle BIプレゼンテーション・サービスのオプションの設定

Oracle BIプレゼンテーション・サービスの統合のオプションを構成するには、次の手順を実行します。

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

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

  3. 「サーバー」と「ポート」を次のように更新します。

    • サーバー: bi.mycompany.com

    • ポート: 80

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

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

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

スケジューラ構成オプションを構成するには、次の手順を実行します。

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

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

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

  4. 変更を適用してから、BI Publisherアプリケーションを再起動します。

15.1.3.17.4 Oracle BI EEデータソースの設定

Oracle BI EEのデータソースは、Cluster Controllerを介してクラスタ化されたBI Serverを指している必要があります。このタスクは、Oracle BI Publisherアプリケーションで実行します。

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

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

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

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

    <Primary Cluster Controller Port>/PrimaryCCS=<Primary Cluster Controller Host>;PrimaryCCSPort=<Primary Cluster Controller Port>;SecondaryCCS=<Secondary Cluster Controller Host>;SecondaryCCSPort=<Secondary Cluster Controller Port>;

    次に例を示します。

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

  4. 「システム・ユーザーの使用」を選択解除して、「ユーザー名」と「パスワード」に管理者の資格証明を指定します。たとえば、weblogicの資格証明を指定します。

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

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

15.1.3.17.5 Oracle BI Publisher用のJMSの構成

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

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

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

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

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

    ORACLE_BASE/admin/domain_name/bi_cluster/jms

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

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

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

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

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

    ORACLE_BASE/admin/domain_name/bi_cluster/jms

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

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

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

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

  14. 名前（例: BipJmsServer_auto_2）を入力してから「永続ストア」ドロップダウン・リストで「BipJmsStore_auto_2」を選択し、「次へ」をクリックします。

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

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

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

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

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

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

  21. 「サブデプロイメント名」で名前（例: BipJmsServer2）を入力し、「次へ」をクリックします。

  22. 「BipJmsServer_auto_2」を「JMSサーバー」でターゲットとして選択します。

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

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

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

  26. 「BIPJmsResource」→「新規」をクリックし、新しいJMSシステム・モジュール・リソースを作成します。

  27. 新しいキューのBIP.Burst.Job.Q_auto_2を作成します。

    1. 「作成するリソースのタイプを選択してください。」ページで「キュー」を選択して「次へ」をクリックします。

    2. 「名前」と「JNDI名」で、BIP.Burst.Job.Q_auto_2と入力します。「次へ」をクリックします。

    3. 「サブデプロイメント」を「BipJmsServer2」に設定し、「ターゲット」を「BipJmsServer_auto_2」に設定します。

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

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

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

    7. 「BipJmsResourceの設定」ページで、「dist_BIP.Burst.Job.Q_auto」という分散キューを選択します。「dist_BIP.Burst.Job.Q_Autoの設定」ページが表示されます。

    8. 「一般」タブで「転送の遅延」を「0」に設定し、「保存」をクリックします。

    9. 「メンバー」タブ→「新規」をクリックします。

    10. 「BIP.Burst.Job.Q_auto_2」を「キュー」プルダウン・バーで選択して、新しい分散トピック・メンバーを作成します。「OK」をクリックします。

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

  28. 手順24〜27を繰り返し、次に示すキューを作成します。

    • BIP.Burst.Report.Q_auto_2

    • BIP.Delivery.Email.Q_auto_2

    • BIP.Delivery.File.Q_auto_2

    • BIP.Delivery.FTP.Q_auto_2

    • BIP.Delivery.Print.Q_auto_2

    • BIP.Delivery.WebDAV.Q_auto_2

    • BIP.Delivery.Fax.Q_auto_2

    たとえば、BIP.Burst.Report.Q_auto_2の場合、手順27.bにおいて「名前」と「JNDI名」で、BIP.Burst.Report.Q_auto_2と入力します。手順27.gでは、分散キューのdist_BIP.Burst.Report.Q_autoを選択します。手順27.jでは「キュー」で新しいメンバーのBIP.Burst.Report.Q_auto_2を追加します。

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

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

  31. 「BIPJmsResource」→「新規」をクリックし、新しいJMSシステム・モジュール・リソースを作成します。

  32. 新しいトピックのBIP.System.T_auto_2を作成します。

    1. 「作成するリソースのタイプを選択してください。」ページで「トピック」を選択して「次へ」をクリックします。

    2. 「名前」と「JNDI名」で、BIP.System.T_auto_2と入力します。「次へ」をクリックします。

    3. 「サブデプロイメント」を「BipJmsServer2」に設定し、「ターゲット」を「BipJmsServer_auto_2」に設定します。

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

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

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

    7. 「BipJmsResourceの設定」ページで、「dist_BIP.System.T_auto」という分散トピックを選択します。「dist_BIP.System.T_autoの設定」ページが表示されます。

    8. 「メンバー」タブ→「新規」をクリックします。

    9. 「トピック」プルダウン・バーから「BIP.System.T_auto_2」を選択して、新しい分散トピック・メンバーを作成します。「OK」をクリックします。

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

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

15.1.3.17.6 Oracle BI Publisher Schedulerの構成の更新

この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLとJMS共有一時ディレクトリを更新します。

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

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

    http://APPHOST1VHN1:9704/xmlpserver
http://APPHOST2VHN1:9704/xmlpserver

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

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

  4. 次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。

    t3://APPHOST1VHN1:9704,APPHOST2VHN1:9704

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

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

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

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

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。


注意:

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

BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。

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

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

  3. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

    「サーバーのサマリー」ページが表示されます。

  4. 「BI_SERVER1」（ハイパーリンクとして表示されています）を表の「名前」列でクリックします。

    BI_SERVER1サーバーの設定ページが開き、「構成」タブがアクティブに表示されます。

  5. 「サービス」タブをクリックします。

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

    ORACLE_BASE/admin/domain_name/bi_cluster/tlogs

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

  8. BI_SERVER2サーバーに対してこれらの手順を繰り返します。


    注意:

    トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。

15.1.3.18 APPHOST2でのシステムの起動

この項では、APPHOST2でシステムを起動する手順について説明します。

15.1.3.18.1 APPHOST2でのノード・マネージャの起動

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、第15.1.3.9.1項「APPHOST1でのノード・マネージャの起動」の手順に従ってAPPHOST2でノード・マネージャを起動してください。

15.1.3.18.2 BI_SERVER2管理対象サーバーの起動と検証

BI_SERVER2管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。

  1. Oracle WebLogic Server管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。

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

    2. 「サーバー」を選択します。

      「サーバーのサマリー」ページが表示されます。

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

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

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

  3. BI_SERVER2が起動すると、次のURLが使用できるようになります。

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


      注意:

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

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

15.1.3.18.3 Business Intelligence Enterprise Editionシステム・コンポーネントの起動と検証

APPHOST2でBI Enterprise Editionのシステム・コンポーネントを起動するには、第15.1.3.9.3項「APPHOST1でのBusiness Intelligence Enterprise Editionシステム・コンポーネントの起動と検証」の手順をAPPHOST2で繰り返します。

15.1.3.19 BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成

BI_SERVERn管理対象サーバーを含むbi_clusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

  1. WEBHOST1およびWEBHOST2で、ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。

    # BI Office
<Location /bioffice>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
</Location>
 
<Location /biofficeclient>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
</Location>

# WSM-PM
<Location /wsm-pm>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
</Location>

# BIEE Analytics
<Location /analytics>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704

<Location /analytics-ws>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
</Location>

<Location /bimiddleware>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
</Location>

# BI Publisher
<Location /xmlpserver>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
 </Location>

  2. WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。

  3. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

    WEBHOST1> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs2
15.1.3.19.1 Oracle HTTP Serverを使用したアクセスの検証

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

次のURLにアクセスできることを確認します。

  • http://WEBHOST1:7777/wsm-pm

  • http://WEBHOST2:7777/wsm-pm

  • http://WEBHOST1:7777/analytics

  • http://WEBHOST2:7777/analytics

  • http://WEBHOST1:7777/xmlpserver

  • http://WEBHOST2:7777/xmlpserver

  • http://WEBHOST1:7777/bioffice/about.jsp

  • http://WEBHOST2:7777/bioffice/about.jsp

ロード・バランシング・ルーター・アドレスを使用して、次のURLにアクセスできることを確認します。

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

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

  • http://bi.mycompany.com:80/wsm-pm

  • http://bi.mycompany.com:80/bioffice/about.jsp

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

  1. BI_SERVER2の実行中に、Oracle WebLogic Server管理コンソールからBI_SERVER1を停止します。

  2. 次のURLにアクセスして、適切な機能を検証します。

    • WEBHOST1:7777/wsm-pm

    • WEBHOST1:7777/analytics

    • WEBHOST1:7777/xmlpserver

    • WEBHOST1:7777/bioffice/about.jsp

  3. Oracle WebLogic Server管理コンソールからBI_SERVER1を起動します。

  4. BI_SERVER2を停止します。

  5. 前述の手順2のURLにアクセスして、適切な機能を検証します。

15.1.3.20 フロントエンドHTTPのホストおよびポートの設定

Oracle WebLogic Serverクラスタに対して、フロントエンドHTTPのホストとポートを設定する必要があります。そのためには、次の手順に従ってください。

  1. WebLogic Server管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

  2. 左側のペインで、「ドメイン構造」ウィンドウの「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

  3. 「bi_cluster」クラスタを選択します。

  4. 「HTTP」を選択します。

  5. 次の値を設定します。

    • フロントエンド・ホスト: bi.mycompany.com

    • フロントエンドHTTPポート: 80

    • フロントエンドHTTPSポート: このフィールドは空白のままにします。


      注意:

      このアドレスが正しくて使用可能である（ロード・バランサが稼働している）ことを確認してください。アドレスの「http://」やホスト名末尾の「/」など、値が間違っていると、仮想IPを使用してアクセスする場合でも、BIシステムにアクセスできない可能性があります。

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

  7. 変更内容をアクティブ化するには、「変更のアクティブ化」をクリックします。

  8. サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。

15.1.3.21 BI_SERVERnサーバーのサーバー移行の構成

この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を構成する必要があります。このためには、障害発生時にbi_server1管理対象サーバーがAPPHOST2上で再起動されるように構成し、障害発生時にbi_server2管理対象サーバーがAPPHOST1上で再起動されるように構成します。このような構成では、bi_server1サーバーおよびbi_server2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。

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

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

次の手順に従って、サーバー移行のleasing表のユーザーと表領域を設定します。

  1. leasingという表領域を作成します。たとえば、ユーザーsysdbaでSQL*Plusにログインし、次のコマンドを実行します。

    SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;

  2. leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

    SQL> create user leasing identified by welcome1;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

  3. leasing.ddlスクリプトを使用してleasing表を作成します。

    1. WL_HOME/server/db/oracle/817またはWL_HOME/server/db/oracle/920のいずれかのディレクトリにあるleasing.ddlファイルをデータベース・ノードにコピーします。

    2. データベースにleasingユーザーとして接続します。

    3. leasing.ddlスクリプトをSQL*Plusで実行します。

      SQL> @Copy_Location/leasing.ddl;
15.1.3.21.2 Oracle WebLogic Server管理コンソールを使用したマルチ・データソースの作成

この項では、Oracle WebLogic Server管理コンソールからleasing表のマルチ・データソースを作成する方法について説明します。マルチ・データソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータソースを、これらのデータソースとグローバルleasingマルチ・データソースの両方について作成します。データソースを作成する際は、次の考慮事項に留意してください。

  • このデータソースが、XAデータソースではないことを確認してください。

  • マルチ・データソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。

  • Oracleのドライバ（Thin）バージョン9.0.1、9.2.0、10、11を使用します。

  • データソースは、グローバル・トランザクションのサポートを必要としません。したがって、データソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない（「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない）で、データベースのサービス名を指定します。

  • これらのデータソースをI/PMクラスタにターゲット指定します。

  • データソースの初期接続プール容量が0（ゼロ）に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データ・ソース名」→「接続プール」タブをクリックし、「初期容量」フィールドに0を入力します。

マルチ・データソースの作成

マルチ・データソースを作成するには、次の手順を実行します。

  1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いてから、「JDBC」ノードを開きます。

  2. 「マルチ・データ・ソース」をクリックします。「JDBCマルチ・データ・ソースの概要」ページが表示されます。

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

  4. 「新規」をクリックします。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。

  5. 名前として、leasingと入力します。

  6. JNDI名として、jdbc/leasingと入力します。

  7. アルゴリズムとして、「フェイルオーバー」（デフォルト）を選択します。

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

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

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

  11. 「非XAドライバ」（デフォルト）を選択します。

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

  13. 「新しいデータ・ソースの作成」をクリックします。

  14. 名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。


    注意:

    leasing表のマルチ・データソースを作成するときに、名前を<MultiDS>-rac0、<MultiDS>-rac1などの形式で入力します。

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

  16. 「グローバル・トランザクションのサポート」の選択を解除します。

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

  18. leasingスキーマのサービス名、データベース名（これは実際には、racdb1、racdb2など、RACノードのインスタンス名です）、ホスト・ポートおよびパスワードを入力します。

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

  20. 「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。

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

  22. データソースのターゲットをbi_clusterに設定します。

  23. データソースを選択して、右の画面に追加します。

  24. Oracle RACデータベースの2つ目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをbi_clusterに設定してから、Oracle RACデータベースの2つ目のインスタンスについても同じ手順を繰り返します。

  25. 2つ目のデータソースをマルチ・データソースに追加します。

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

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

この項では、ノード・マネージャのプロパティ・ファイルnodemanager.propertiesの編集方法について説明します。これは、サーバーの移行を構成する両方のノードのノード・マネージャに対して実行する必要があります。

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

  • Interface: このプロパティは、浮動IPのインタフェース名（たとえば、eth0）を指定します。

    サブインタフェース（eth0:1、eth0:2など）を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

  • NetMask: このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります。このドキュメントの例では、255.255.255.0が使用されています。

  • UseMACBroadcast: このプロパティでは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、すなわち、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力（ノード・マネージャが起動されているシェル）で確認します。ノード・マネージャの出力は、次のように表示されます。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:

次の手順は、サーバー・プロパティ（起動プロパティ）が適切に設定されていて、ノード・マネージャがリモートでサーバーを起動できる場合には不要です。

  1. nodemanager.propertiesファイルで次のプロパティを設定します。

    • StartScriptEnabled: このプロパティをtrueに設定します。これは、ノード・マネージャが起動スクリプトを使用して管理対象サーバーを起動するために必要です。

  2. WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、APPHOST1とAPPHOST2でノード・マネージャを起動します。


注意:

共有記憶域インストールからノード・マネージャを実行する場合、同じnodemanager.propertiesファイルを使用して複数のノードが起動します。ただし、各ノードでは、別のNetMaskまたはInterfaceプロパティが必要なことがあります。この場合、環境変数を使用して、ノードごとに個々のパラメータを指定します。たとえば、APPHOSTnで異なるインタフェース（eth3）を使用するには、インタフェース環境変数を「APPHOSTn> export JAVA_OPTIONS=-DInterface=eth3」のように使用して、この変数がシェル内で設定された後にノード・マネージャを起動します。

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

この項では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する方法について説明します。

  1. PATH環境変数に次のファイルが含まれていることを確認します。

    表15-5 PATH環境変数に必要なファイル

    ファイル 格納されているディレクトリ

    wlsifconfig.sh

    ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration

    wlscontrol.sh

    WL_HOME/common/bin

    nodemanager.domains

    WL_HOME/common

  2. wlsifconfig.shスクリプトに対するsudo構成権限を付与します。

    • パスワード・プロンプトを使用しないで機能するsudoを構成します。

    • セキュリティ上の理由から、sudoをwlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。

      1. WebLogicユーザー（oracle）に、パスワードなしのsudo権限を付与し、/sbin/ifconfigと/sbin/arpingのバイナリの実行権限を付与します。

      2. スクリプトがWebLogicユーザー（oracle）によって実行可能であることを確認してください。/etc/sudoers内の次のエントリ例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。

        oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

    注意:

    この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。

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

この項では、サーバー移行ターゲットを構成する方法について説明します。まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを（適切な順に）指定します。クラスタ内の移行でクラスタ移行を構成するには、次の手順を実行します。

  1. Oracle WebLogic Server管理コンソール（http://Host:Admin_Port/console）にログインします。通常、Admin_Portは7001（デフォルト）です。

  2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

  3. 移行を構成する対象となるクラスタ（bi_cluster）を、表の「名前」列でクリックします。

  4. 「移行」タブをクリックします。

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

  6. 「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「APPHOST1」と「APPHOST2」を選択します。

  7. 自動移行に使用するデータソースを選択します。この場合は、leasingデータソースを選択します。

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

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

  10. サーバー移行の候補マシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。

    1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。


      ヒント:

      サーバーが実行されているマシンを表示するには、「サーバーのサマリー」ページで「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウに移動します。サーバーが自動的に移行される場合、これはこの構成とは異なります。

    2. 移行を構成するサーバーを選択します。

    3. 「移行」タブをクリックします。

    4. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。bi_server1については、「APPHOST2」を選択します。bi_server2については、「APPHOST1」を選択します。

    5. 「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

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

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

    8. 管理サーバー、ノード・マネージャ、およびサーバー移行が構成されたサーバーを再起動します。

15.1.3.21.6 サーバー移行のテスト

最後の手順は、サーバー移行をテストすることです。サーバー移行が適切に機能していることを確認するには、次の手順を実行します。

APPHOST1から:

  1. bi_server1管理対象サーバーを停止します。そのためには、次のコマンドを実行します。

    APPHOST1> kill -9 pid

    pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

    APPHOST1> ps -ef | grep bi_server1

  2. ノード・マネージャのコンソールを確認します。bi_server1の浮動IPが無効になっていることを示すメッセージが表示されます。

  3. ノード・マネージャがbi_server1の2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

  4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード･マネージャによってログに記録されるようになります。

APPHOST2から:

  1. ローカルのノード・マネージャのコンソールを確認します。APPHOST1でbi_server1の再起動が最後に試行されてから30秒経過した後、APPHOST2のノード・マネージャによって、bi_server1の浮動IPが有効化されようとしていること、およびこのノードでサーバーが再起動されようとしていることが示されます。

  2. 同じIPを使用していずれかのアプリケーション（BI Publisherなど）にアクセスします。

管理コンソールからの検証

管理コンソールで移行を検証することもできます。

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

  2. 左側のコンソールで、「ドメイン」をクリックします。

  3. 「監視」タブ→「移行」サブタイプをクリックします。

    「移行の状態」表に、移行の状態に関する情報が表示されます。


注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

15.1.3.22 Oracle BI EEトポロジのスケール・アップ

Oracle BI EEトポロジをスケール・アップする際は、Oracle BI EE高可用性トポロジ内のいずれかの既存ノードに新たなシステム・コンポーネントを追加します。

この項では、ノードが2つ以上あり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがある高可用性トポロジを前提にします。トポロジをスケール・アップするには、いずれかの既存ノードで実行されているシステム・コンポーネントの数を増やします。

特定のノードで複数の管理対象サーバーを実行する必要はありません。

Oracle BI EEトポロジをスケール・アップする手順は次のとおりです。

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

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

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

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

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

  6. 矢印キーを使用して、「BIサーバー」、「Presentation Server」または「JavaHost」の数を変更します。

  7. 「適用」をクリックしてから、「変更のアクティブ化」をクリックします。

  8. 「概要」をクリックしてから、「再起動」をクリックします。

15.1.3.23 新しいノード（APPHOST3）へのOracle BI EEトポロジのスケール・アウト

Oracle BI EEトポロジをスケール・アウトする際は、トポロジ内の新しいノード（APPHOST3）に、新しい管理対象サーバーとシステム・コンポーネント・セットを追加します。この項では、ノードが2つ以上あり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがある高可用性トポロジを前提にします。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

  • Oracle Business Intelligenceの管理対象サーバーが稼働している既存ノードがトポロジ内に存在していること。

  • 新しいノード（APPHOST3）が、Oracle WebLogic ServerとOracle Business Intelligence用の既存のホーム・ディレクトリにアクセスできます。

  • ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、User_Home/bea/beahomelistファイルを編集します。次の手順を参照してください。

  • 新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。

APPHOST3でOracle Business Intelligenceをスケール・アウトするには、次の手順を実行します。

  1. APPHOST3で、Oracle Business Intelligenceのインストールと（必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合）ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

  2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

    APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>

    Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し（別のWebLogicインストールがノード内に存在する場合はそれを編集）、それにORACLE_BASE/product/fmwを追加します。

  3. VIP3をAPPHOST3で有効にします。第15.1.3.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。

  4. 第15.1.3.10項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームからコンフィギュレーション・アシスタントを実行します。

  5. 第15.1.3.11項「システム・コンポーネントのスケール・アウト」の手順に従って、APPHOST3でシステム・コンポーネントをスケール・アウトします。

  6. 第15.1.3.13項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第15.1.3.14項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名の検証を無効にすることで、bi_server3管理対象サーバーを構成します。

  7. 第15.1.3.17.5項「Oracle BI Publisher用のJMSの構成」の説明に従って、Oracle BI Publisher用のJMSを構成します。

  8. 第15.1.3.16項「Oracle BI Officeの追加の構成タスク」の説明に従って、APPHOST3でOracle BI Officeを構成します。

  9. 第15.1.3.17.7項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。

  10. 第15.1.3.19項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。

  11. APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第15.1.3.9.2項「BI_SERVER1管理対象サーバーの起動と検証」および第15.1.3.9.3項「APPHOST1でのBusiness Intelligence Enterprise Editionシステム・コンポーネントの起動と検証」を参照してください。

  12. 第15.1.3.21.5項「サーバー移行ターゲットの構成」および第15.1.3.21.6項「サーバー移行のテスト」の説明に従って、サーバー移行を構成します。

  13. 構成を検証するには、次のURLにアクセスします。

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

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

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

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

  14. ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドでノード・マネージャの設定に関する章を参照してください。

15.2 Oracle Business Intelligence Publisherの高可用性

Oracle Business Intelligence Publisher（Oracle BI Publisher）は、複雑な分散環境に適用できる最も効率的でスケーラブルなレポート・ソリューションを提供します。セキュリティが高く適切なフォーマットで情報を生成して、従業員、顧客およびサプライヤに配信するための中央アーキテクチャを提供します。Oracle BI Publisherを使用すると、ビジネス・ドキュメントの作成、カスタマイズおよびメンテナンスにかかる高いコストを削減できる一方で、レポート管理の効率性が向上します。

この項では、Oracle BI Publisherの高可用性環境を設計およびデプロイする方法を説明します。

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

15.2.1 Oracle BI Publisherのコンポーネント・アーキテクチャ

図15-7では、単一インスタンス・アーキテクチャでのOracle BI Publisherコンポーネントを示しています。

図15-7 Oracle BI Publisherの単一インスタンス・アーキテクチャ

図15-7の説明は次にあります。
「図15-7 Oracle BI Publisherの単一インスタンス・アーキテクチャ」の説明

15.2.1.1 Oracle BI Publisherコンポーネントの特性

Oracle BI Publisherは、サーブレットベースのアーキテクチャを使用するJava EEアプリケーションです。JMSを使用してスケジュール済ジョブを実行し、EJBクライアントを使用してESSと統合します。

15.2.1.1.1 状態情報

Oracle BI Publisherレポートの実行中は、セッション情報がメモリーに保管されます。

複数のサーバーにまたがってレポートの実行を移行する複雑な操作のため、Oracle BI Publisherはステートレス・アプリケーションではありません。

15.2.1.1.2 ランタイム・プロセス

Oracle BI Publisherは、Oracle WebLogic ServerにデプロイされるJava EEコンポーネントです。

  • Oracle BI Publisherのアーティファクトの処理（次のアーティファクトの作成、削除および編集を含む）

    • レポート

    • データ・モデル

    • レイアウト・テンプレート

    • スケジューラ・ジョブ

    • 構成

  • スケジューラ・レポートの実行

  • オンライン・レポートの実行

15.2.1.1.3 プロセスのライフサイクル

Oracle BI Publisherは、Oracleインフラストラクチャに全面的に依存しています。Oracle BI Publisherをデプロイ、起動、停止および監視するには、WebLogic Server管理コンソールを使用します。

15.2.1.1.4 リクエスト・フロー

JMSは、Oracle BI Publisherのバッチ・レポート処理システムのバックボーンとして使用されます。JMSは、トランザクション方式でメッセージング・ボードとして使用されます。すべてのレポートは次の実行段階に分けられます。

  1. データの取得

  2. データのフォーマット設定

  3. レポートの配信

これらの各段階は、JMSキュー内のジョブ・リクエストとして表現されます。どのジョブ・リクエストの取得も、トランザクションベースで実行されます。したがって、ジョブを処理しているOracle BI Publisherノードで障害が発生した場合は、そのジョブはJMSキューに戻されて、別のノードがそのジョブを取得して再実行します。ジョブの再実行は、障害が発生した段階の最初から開始されます。

15.2.1.1.5 外部依存性

Oracle BI Publisherは次に依存しています。

  • データベース・リポジトリ: スケジュール済ジョブの情報用に使用されます。

  • Oracle BI Publisherアーティファクトの保管: これらのアーティファクトには、レポート、定義およびレイアウトが含まれます。この保管は次の2種類の方法で行われます。

    • Oracle Business Intelligence Enterprise Editionモード: Oracle BI Publisherは、Webサービス経由の短時間接続を介してOracle BIプレゼンテーション・カタログを使用します。

    • スタンドアロン・モード: Oracle BI Publisherは、共有ファイル・システムを使用します（SANやNASなど）。

  • レポート・データ用のDBMS: Oracle BI Publisherは、DBMSに問い合せて、処理する必要のあるレポート・データを取得します。

  • Webサービス: データを取得するために使用されます。

15.2.1.1.6 構成アーティファクト

Oracle BI Publisherは、標準のJava EEアプリケーションです。

15.2.1.1.7 デプロイメント・アーティファクト

Oracle BI Publisherには、特別なデプロイメント・アーティファクトはありません。

15.2.1.1.8 ログ・ファイル

Oracle BI Publisherは、Oracle WebLogic ServerにデプロイされるJava EEアプリケーションです。ログ・メッセージはすべて、アプリケーションがデプロイされるOracle WebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

15.2.2 Oracle BI Publisherの高可用性の概要

この項では、Oracle BI Publisherを高可用性環境で使用する場合の概要について説明します。

15.2.2.1 Oracle BI Publisherの高可用性アーキテクチャ

図15-8は、Oracle BI Publisherの高可用性アーキテクチャを示しています。

図15-8 Oracle BI Publisherの高可用性アーキテクチャ

図15-8の説明は次にあります。
「図15-8 Oracle BI Publisherの高可用性アーキテクチャ」の説明

図15-8では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。

Oracle BI Publisherが実行されるOracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。APPHOST2上の管理サーバーはパッシブです。APPHOST1が使用できなくなると、第3章「WebLogic Serverの高可用性」の説明に従って、管理サーバーをAPPHOST2でアクティブにできます。Oracle BI Publisherは、これらのホスト上のBI_SERVER1管理対象サーバーとBI_SERVER2管理対象サーバーにデプロイされます。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。サーバー移行全体は、管理対象サーバー用に構成されます。

BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してVIPマッピングを有効にして（APPHOST1ではVIP1、APPHOST2ではVIP2）、トポロジで使用されるネットワーク・システムで仮想ホスト名を（DNSサーバーとhosts解決のいずれかで）正しく解決する必要があります。BIサーバーのサーバー移行を構成する方法の詳細は、第15.1.3.21項「BI_SERVERnサーバーのサーバー移行の構成」を参照してください。

データ層では、レコード定義、レポート・レイアウト、データ・モデルなどのOracle BI Publisherリポジトリ・メタデータと、Oracle BI Publisher JMS永続ストアを格納するための共有外部記憶域が設定されます。

Oracle RACデータベースは、レポート・データ用に使用されますが、エンタープライズ・データベース用としてもお薦めします。

Oracle BI Publisherは、アクティブ/アクティブ形式の高可用性構成をサポートしています。各ノードは、他のOracle BI Publisherノードと共通のリポジトリおよびスケジューラ・データベースを共有する独立サーバーとして動作します。

Oracle BI Publisherリポジトリ（レポートやデータ・モデルなどのすべてのコンテンツを格納）は、BI PublisherがOracle BI EEと組み合せて構成されている場合はOracle BIプレゼンテーション・カタログに保管され、Oracle BI Publisherが単独でインストールされている場合は共有ファイル・システムに保管されます。

Oracle BI Publisherの構成フォルダは共有ファイル・システムに配置されている必要があります。

共有リポジトリには、次のOracle BI Publisherアーティファクトが保管されます。

  • レポート定義

  • レポート・テンプレート

  • データ・モデル

  • Oracle BI Publisherの構成

Schedulerデータベースは、次の情報が保管される共有データベースです。

  • レポートの詳細（パラメータ）

  • 実行ステータス

  • 実行履歴

  • 過去のレポート実行のスナップショット

ハードウェアまたはソフトウェアのロード・バランサを、高可用性環境内のOracle BI Publisherノードに対するフロントエンドとして使用できます。

Oracle BI Publisherの高可用性デプロイメントでは次のことが当てはまります。

  • スティッキー・セッションをロード・バランサに対して有効にする必要があります。

  • Oracle BI Publisherは、WebLogic ServerのJMSフェイルオーバー・メカニズムに依存しています。

  • クラスタ内のすべてのOracle BI Publisherインスタンスは独立しています。

  • アーティファクトと構成は共有リポジトリに保管されており、各インスタンスは個別にこのリポジトリを読み取ります。

15.2.2.1.1 共有されたファイルとディレクトリ

Oracle BI Publisherの共有ファイルは、前の項で説明した共有リポジトリとSchedulerデータベースです。

15.2.2.1.2 クラスタワイドの構成変更

構成フォルダには、BI Publisherを使用して設定したすべての構成、セキュリティおよびデータソースが格納されています。構成フォルダが共有記憶域にある場合は、加えられたすべての変更はクラスタ内のすべてのノードに適用されます。

15.2.2.2 障害からの保護および予想される動作

ノード・マネージャは、障害が発生したOracle BI Publisherインスタンスを再起動するように設定できます。

Oracle BI Publisherインスタンスが再起動されても、他の実行中インスタンスは影響を受けません。

ノードで障害が発生したときに生じる動作は次のとおりです。

  • シングル・サインオンが実装されていないデプロイメント環境では、ユーザーは再びログインするように求められます。

  • 編集内容が含まれていたトランザクションはすべて保存されます。

15.2.2.3 トラブルシューティング

Oracle BI Publisherのログは、次のデフォルト場所にあるWebLogic Serverのログに含まれています。

DOMAIN_HOME/servers/serverName/logs/serverName-diagnostic.log

また、次のファイルにはBI Publisher関連のメッセージが含まれています。

DOMAIN_HOME/servers/serverName/logs/bipublisher/bipublisher.log

構成情報は共有リポジトリに保管されています。構成ファイルは、共有リポジトリ内のAdminディレクトリに保管されています。

15.2.3 Oracle BI Publisherの高可用性の構成手順

この項では、Oracle BI Publisherの2ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図15-8に示しています。


注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

15.2.3.1 環境の準備: Oracle BI Publisherの高可用性構成の設定前に必要な手順

この項では、BI Publisherの高可用性構成を設定するための前提条件について説明します。

15.2.3.1.1 データベースに関する前提条件

Oracle BI Publisherでサポートしているデータベースのバージョンは次のとおりです。

  • Oracle Database 10g（非XEデータベースについては10.2.0.4以上）

  • Oracle Database 11g（非XEデータベースについて11.1.0.7以上）

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.2.3.1.2 VIPとIPに関する前提条件

図15-6で示すように、異なる仮想IPをリスニングするようにBI管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。各VIPが使用可能かつアクセス可能であることを、インストールの実行前に確認してください。

表15-6 BI Publisherの仮想ホスト

仮想IP 仮想IPのマップ先 説明

VIP1

APPHOST1VHN1

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

VIP2

APPHOST2VHN1

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

15.2.3.1.3 共有記憶域に関する前提条件

障害発生時に適切にリカバリできるようにするため、すべてのノードからアクセスできて、管理対象サーバーで障害が発生した後に操作を再開できる場所に、JMSとトランザクションの両方のログを格納します。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表15-7は、共有記憶域の内容を示しています。

表15-7 BI Publisherの共有記憶域の内容

サーバー データの型 共有記憶域のボリューム ディレクトリ ファイル

BI_SERVER1とBI_SERVER2

トランザクション・ログ

VOL2

ORACLE_BASE/admin/domain_name/bi_cluster_name/tlogs

共通の場所（WebLogicサーバーにより決められたストア）

BI_SERVER1とBI_SERVER2

JMSストア

VOL2

ORACLE_BASE/admin/domain_name/bi_cluster_name/jms

共通場所ですが、サーバーごとに個別のストアになります。たとえば、BI_SERVER1の場合、BipJmsStore_auto_1になります。BI_SERVER2の場合、BipJmsStore_auto_2になります。

BI_SERVER1とBI_SERVER2

BI Publisher構成フォルダ

VOL1

ORACLE_BASE/domain_name/config/bipublisher/repository

共通の場所

BI_SERVER1とBI_SERVER2

BI Publisherカタログ・リポジトリ

VOL1

ORACLE_BASE/domain_name/config/bipublisher/catalog

共通の場所

BI_SERVER1とBI_SERVER2

BI Publisher Scheduler一時ディレクトリ

VOL1

ORACLE_BASE/domain_name/config/bipublisher/temp

共通の場所

共有記憶域にはNASやSANなどのデバイスを使用できます。NASデバイス別のコマンド例を次に示します。この項で指定しているオプションは、実際のオプションと異なる場合があります。

APPHOST1> mount naasfiler:/vol/volX/FMWshared MW_HOME-t nfs -o
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
15.2.3.1.4 クロックの同期

クラスタに参加しているすべてのサーバーにおけるクロックは、1秒以内の誤差で同期している必要があります。これを実現するには、単一のネットワーク・タイム・サーバーを使用して各サーバーはそのネットワーク・タイム・サーバーを指すようにします。ネットワーク・タイム・サーバーを指す実際の手順は、WindowsとLinuxとでは異なります。お使いのオペレーティング・システムのドキュメントを参照してください。

15.2.3.1.5 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Clusterwareインストレーション・ガイド』を参照してください。

自動ストレージ管理

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。

インストーラを実行するときは、構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g（11.1.1）Oracle Fusion MiddlewareリポジトリをOracle Real Application Clusters（Oracle RAC）データベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ（RCU）が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g（11.1.1）Oracle Fusion MiddlewareリポジトリをOracle RACデータベースにインストールします。

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

15.2.3.1.6 RCUを使用したデータベースへのBusiness Intelligenceスキーマのロード

Oracle BI Publisherをインストールする前に、11g（11.1.1）Oracle Fusion Middlewareのメタデータ・ストアとOracle BIスキーマをOracle RACデータベースにインストールします。次の手順を実行します。

  1. リポジトリ作成ユーティリティ（RCU）のDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。

    prompt> cd RCU_HOME/bin
prompt> ./rcu

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

  3. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。

  4. 「データベース接続の詳細」画面で、データベースの接続情報を入力します。

    • データベース・タイプ: Oracle Databaseを選択します。

    • ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します。次に例を示します。

      BIDBHOST1-VIP

    • ポート: データベースのリスニング・ポート番号である1521を指定します。

    • サービス名: データベースのサービス名を指定します。

      biha.mycompany.com

    • ユーザー名: DBA権限またはSYSDBA権限のあるユーザーの名前（SYS）を指定します。

    • パスワード: SYSユーザーのパスワードを入力します。

    • ロール: データベース・ユーザーのロール（SYSDBA）をリストで選択します（SYSユーザーに必要）。

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

  5. 「コンポーネントの選択」画面で、次を行います。

    • 「接頭辞の新規作成」を選択し、BIHAのように、データベース・スキーマに使用する接頭辞を入力します。6文字まで接頭辞として指定できます。接頭辞を使用して、複数リポジトリの論理グルーピングをデータベースにおいて作成します。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。


      ヒント:

      このスキーマの名前をメモに記録してください。後述する手順でこの情報が必要になります。

    • 次のコンポーネントを選択します。

      o  AS Common Schemas: Metadata Services (automatically selected)
o  Oracle Business Intelligence: Business Intelligence Platform

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

  6. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。

    要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択できます。

    「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。


    ヒント:

    スキーマ・パスワードの名前をメモに記録してください。後述する手順でこの情報が必要になります。

  7. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

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

  9. 「完了サマリー」画面で「閉じる」をクリックします。

15.2.3.1.7 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle BI Publisherの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

BI Publisherは、2つのOracle HTTP ServerがWeb層コンポーネントとして使用された高可用性構成でデプロイされた場合は、ハードウェア・ロード・バランサを使用します。

仮想サーバー名

bi.mycompany.comは、Oracle BI PublisherなどのランタイムBIコンポーネント宛のすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、bi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

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

この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。

  1. サーバーが次の要件を満たしていることを確認します。

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

    • ポート7777がWEBHOST1上のサービスによって使用されていないことを確認するために、使用するオペレーティング・システムに応じて次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。

      UNIXの場合:

      netstat -an | grep "7777"

      Windowsの場合:

      netstat -an | findstr :7777

      ポートが使用されている（コマンドを実行するとポートを識別する戻り値が表示される）場合は、そのポートを解放する必要があります。

      UNIXの場合:

      ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

      Windowsの場合:

      ポートを使用しているコンポーネントを停止します。

    • staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

    • 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート（Oracle HTTP Serverのポート番号を指定する行は非コメント化）を割り当てます。

      # The port for Oracle HTTP server
Oracle HTTP Server port = 7777

  2. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。

    UNIXの場合:

    ./runinstallerコマンドを発行します。

    Windowsの場合:

    setup.exeをダブルクリックします。

    「インベントリ・ディレクトリの指定」画面が表示されます。

  3. 「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。次に例を示します。

    インベントリ・ディレクトリの指定: /u01/app/oraInventory

    オペレーティング・システムのグループ名: oinstall

    次のメッセージのダイアログ・ボックスが表示されます。

    インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください。

    rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。

    これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。


    注意:

    すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールでOracleインベントリ画面が表示されない場合は、次の内容を確認してください。

    • /etc/oraInst.locファイルが存在しているか。

    • このファイルが存在する場合は、表示されているインベントリ・ディレクトリが有効か。

    • インストールを実行しているユーザーがインベントリ・ディレクトリに対する書込み権限を持っているか。

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

  5. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

  6. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。

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

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

    • Oracle Middlewareホーム: ORACLE_BASE/product/fmw（グレーアウトされています）

    • Oracleホーム・ディレクトリ: Oracle_WT1

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

  8. 「コンポーネントの構成」画面で、次の操作を行います。

    • 「Oracle HTTP Server」を選択します。

    • 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

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

  9. 「コンポーネントの詳細の指定」画面で、WEBHOST1用に次の値を入力します。

    • インスタンス・ホームの場所: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1

    • インスタンス名: web1

    • OHSコンポーネント名: ohs1

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

  10. 「ポートの構成」画面で、次の操作を行います。

    • カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

    • Oracle HTTP Serverポートを入力します（例: 7777）。

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

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

  12. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「インストール」をクリックします。

  13. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

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

  14. 「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。「次へ」をクリックします。

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

WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランサを構成します。

15.2.3.1.9 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、Webブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

http://WEBHOST1:7777/
http://WEBHOST2:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザにOracle FMWの「ようこそ」画面が表示されます。

15.2.3.2 Oracle Fusion Middlewareホームのインストール

この項では、Oracle WebLogic ServerとOracle Fusion Middleware BI EEを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。WebLogic ServerとBI PublisherをAPPHOST2にインストールするために、これと同じ手順を繰り返します（次ではAPPHOST1を対象にして説明しています）。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

  • Oracle WebLogic Server

  • Oracle Fusion Middleware BI EE

15.2.3.2.1 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールする手順は次のとおりです。

  1. Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。

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

  3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

    • 「新しいミドルウェア・ホームを作成する」を選択します。

    • 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します。


      注意:

      ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracleの値をお薦めします。

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

  4. 「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

  5. 「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。

  6. 「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.5ディレクトリを受け入れます。そして「次へ」をクリックします。

  7. 「インストールの概要」画面で「次へ」をクリックします。

    Oracle WebLogic Serverソフトウェアがインストールされます。

  8. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

15.2.3.2.2 BI Publisher用のOracle Fusion Middlewareのインストール

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

  1. Oracle Fusion Middleware Business Intelligence 11gのインストーラを次のインストール・メディアから起動します。

    UNIXの場合:

    APPHOST1>./runInstaller

    Windowsの場合:

    APPHOST1> setup.exe

  2. 「インベントリ・ディレクトリの指定」画面で、次の操作を行います。

    • HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです（この場所をお薦めします）。

    • インストールを実行するユーザーのOSグループを入力します。

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

    • 画面の手順に従って、/createCentralnventory.shをrootとして実行します。

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

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

  4. 「インストール・タイプの選択」画面で、「ソフトウェアのみインストール」を選択して「次へ」をクリックします。

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

  6. 「インストール場所の指定」画面で、前にインストールしたMiddlewareホームをドロップダウン・リストで選択します。「Oracleホーム」ディレクトリには、ディレクトリ名（Oracle_BI1）を入力します。

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

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

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

    Oracle Fusion Middleware Business Intelligence 11gソフトウェアがインストールされます。

  9. 「インストールの進行状況」画面で「次へ」をクリックします。

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

15.2.3.3 APPHOST1のVIP1およびAPPHOST2のVIP2の有効化

BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してマッピングされているVIPを有効にして（APPHOST1ではVIP1、APPHOST2ではVIP2）、トポロジで使用されるネットワーク・システムで仮想ホスト名を（DNSサーバーとhosts解決のいずれかで）正しく解決する必要があります。

15.2.3.4 管理サーバーと1つ目のBI_SERVER1管理対象サーバーが含まれたドメインの作成

この項では、Oracle Business Intelligenceコンフィギュレーション・アシスタント、Oracle WebLogic Server管理コンソールおよびOracle Enterprise Managerを使用して、ドメインと最初のWebLogic Server BI管理対象サーバーを作成する方法について説明します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。


注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

Oracleホーム・ディレクトリからコンフィギュレーション・アシスタントを実行して、BI Publisherが配置された管理対象サーバーおよび管理サーバーが含まれたドメインを作成します。

  1. コンフィギュレーション・アシスタントの場所にディレクトリを移動します。

    APPHOST1> cd ORACLE_HOME/bin

  2. コンフィギュレーション・アシスタントを起動します。

    UNIXの場合:

    APPHOST1> ./config.sh

    Windowsの場合:

    APPHOST1> config.cmd

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

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

  5. BIシステムの作成またはスケールアウト画面が表示されます。新規BIシステムの作成を選択して、次の値を指定します。

    • ユーザー名: weblogic

    • ユーザー・パスワード: weblogicユーザーのパスワードを入力します。

    • ドメイン名: bifoundation_domain

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

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

    • MiddleWareホーム: ORACLE_BASE/product/fmw（グレーアウトされています）

    • Oracleホーム: ORACLE_BASE/product/fmw/Oracle_BI1（グレーアウトされています）

    • WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3（グレーアウトされています）

    • ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain


      注意:

      「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

    • インスタンス・ホーム: ORACLE_BASE/product/fmw/instance1

    • インスタンス名: instance1

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

  7. 「コンポーネントの構成」画面で、Business Intelligence Publisherを選択します。

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

  8. 「データベース詳細」画面で、次の値を入力します。

    • データベース・タイプ: Oracle Database

    • 接続文字列: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM

    • BIPLATFORMスキーマ・ユーザー名: BIHA_BIPLATFORM

    • BIPLATFORMスキーマ・パスワード: BIPLATFORMスキーマ・ユーザーのパスワードを入力します。

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

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

    • 自動でポートを構成

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

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

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

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

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

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

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

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。

  1. 次のディレクトリに移動します。

    ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/
AdminServer/security

  2. 次の行をファイルに入力し、ファイルを保存してからエディタを閉じます。

    username=Admin_username
password=Admin_password

    注意:

    管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

    セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

15.2.3.6 APPHOST1での管理サーバーの起動と検証

この項では、APPHOST1で管理サーバーを起動および検証する手順について説明します。

15.2.3.6.1 APPHOST1での管理サーバーの起動

APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin
APPHOST1> ./startWebLogic.sh
15.2.3.6.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

  1. ブラウザでhttp://APPHOST1:7001/consoleにアクセスします。

  2. 管理者としてログインします。

  3. BI_SERVER1管理対象サーバーが表示されていることを確認します。

  4. bi_clusterクラスタが表示されていることを確認します。

  5. Enterprise Manager（http://APPHOST1:7001/em）にアクセスできることを確認します。

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

次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。

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

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

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

  4. 「サーバー」をクリックします。

    「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で「bi_server1」を選択します。

    bi_server1の「設定」ページが表示されます。

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

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

  8. 変更を保存およびアクティブ化します。

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

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

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。

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

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

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

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

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

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

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

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

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

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

  10. 変更を保存およびアクティブ化します。

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

15.2.3.9 APPHOST1でのシステムの起動

この項では、APPHOST1でノード・マネージャを起動する方法、およびAPPHOST1でBI_SERVER1管理対象サーバーを起動して検証する方法について説明します。

15.2.3.9.1 APPHOST1でのノード・マネージャの起動

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合、次のコマンドを使用してAPPHOST1で起動します。

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
15.2.3.9.2 BI_SERVER1管理対象サーバーの起動と検証

BI_SERVER1管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。

  1. Oracle WebLogic Server管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。

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

    2. 「サーバー」を選択します。

      「サーバーのサマリー」ページが表示されます。

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

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

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

  3. BI_SERVER1が起動すると、次のURLが使用できるようになります。

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


      注意:

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

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

15.2.3.10 APPHOST2でのBIシステムのスケール・アウト

コンフィギュレーション・アシスタントをORACLE_HOMEディレクトリから実行して、BIシステムをスケール・アウトします。

  1. コンフィギュレーション・アシスタントの場所にディレクトリを移動します。

    APPHOST2> cd ORACLE_HOME/bin

  2. コンフィギュレーション・アシスタントを起動します。

    APPHOST2> ./config.sh

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

  4. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。

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

  5. BIシステムの作成またはスケールアウト画面が表示されます。BIシステムのスケールアウトを選択して、次の値を入力します。

    • ホスト名: ADMINHOST

    • ポート: 7001

    • ユーザー名: weblogic

    • ユーザー・パスワード: weblogicユーザーのパスワードを入力します。

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

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

    • MiddleWareホーム: ORACLE_BASE/product/fmw（グレーアウトされています）

    • Oracleホーム: Oracle_BI1（グレーアウトされています）

    • WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3（グレーアウトされています）

    • ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain


      注意:

      「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

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

    • インスタンス名: instance2（グレーアウトされています）

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

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

    • 自動でポートを構成

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

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

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

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

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

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

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

次の手順を実行して、BI_SERVER2管理対象サーバーのリスニング・アドレスを設定します。

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

  2. 「ロックして編集」をクリックします。

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

  4. 「サーバー」をクリックします。

    「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で「bi_server2」を選択します。

    bi_server2の「設定」ページが表示されます。

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

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

  8. 変更を保存およびアクティブ化します。

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

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

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。

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

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

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

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

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

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

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

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

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

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

  10. 変更を保存およびアクティブ化します。

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

15.2.3.13 Oracle BI Publisherの構成

この項では、Oracle BI Publisherを構成する方法を説明します。

15.2.3.13.1 サーバー構成オプションの設定

サーバー構成オプションを構成するには、次の手順を実行します。

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

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

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

  4. 構成フォルダ用に次のフィールドを入力します。

    • パス: 構成フォルダの共有場所のパスを入力します。

  5. 変更を適用してから、BI Publisherアプリケーションを再起動します。

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

スケジューラ構成オプションを構成するには、次の手順を実行します。

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

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

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

  4. 変更を適用してから、BI Publisherアプリケーションを再起動します。

15.2.3.13.3 BI Publisher用のJMS永続ストアの構成

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

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

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

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

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

    ORACLE_BASE/admin/domain_name/bi_cluster/jms

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

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

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

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

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

    ORACLE_BASE/admin/domain_name/bi_cluster/jms

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

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

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

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

  14. 名前（例: BipJmsServer_auto_2）を入力してから「永続ストア」ドロップダウン・リストで「BipJmsStore_auto_2」を選択し、「次へ」をクリックします。

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

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

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

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

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

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

  21. 「サブデプロイメント名」で名前（例: BipJmsServer2）を入力し、「次へ」をクリックします。

  22. 「BipJmsServer_auto_2」を「JMSサーバー」でターゲットとして選択します。

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

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

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

  26. 「BIPJmsResource」→「新規」をクリックし、新しいJMSシステム・モジュール・リソースを作成します。

  27. 新しいキューのBIP.Burst.Job.Q_auto_2を作成します。

    1. 「作成するリソースのタイプを選択してください。」ページで「キュー」を選択して「次へ」をクリックします。

    2. 「名前」と「JNDI名」で、BIP.Burst.Job.Q_auto_2と入力します。「次へ」をクリックします。

    3. 「サブデプロイメント」を「BipJmsServer2」に設定し、「ターゲット」を「BipJmsServer_auto_2」に設定します。

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

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

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

    7. 「BipJmsResourceの設定」ページで、「dist_BIP.Burst.Job.Q_auto」という分散トピックを選択します。「dist_BIP.Burst.Job.Q_Autoの設定」ページが表示されます。

    8. 「一般」タブで「転送の遅延」を「0」に設定し、「保存」をクリックします。

    9. 「メンバー」タブ→「新規」をクリックします。

    10. 「BIP.Burst.Job.Q_auto_2」を「キュー」プルダウン・バーで選択して、新しい分散トピック・メンバーを作成します。「OK」をクリックします。

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

  28. 手順24〜27を繰り返し、次に示すキューを作成します。

    • BIP.Burst.Report.Q_auto_2

    • BIP.Delivery.Email.Q_auto_2

    • BIP.Delivery.Fax.Q_auto_2

    • BIP.Delivery.FTP.Q_auto_2

    • BIP.Delivery.Print.Q_auto_2

    • BIP.Delivery.WebDAV.Q_auto_2

    • BIP.Delivery.Fax.Q_auto_2

    たとえば、BIP.Burst.Report.Q_auto_2の場合、手順27.bにおいて「名前」と「JNDI名」で、BIP.Burst.Report.Q_auto_2と入力します。手順27.gでは、分散キューのdist_BIP.Burst.Report.Q_autoを選択します。手順27.jでは「キュー」で新しいメンバーのBIP.Burst.Report.Q_auto_2を追加します。

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

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

  31. 「BIPJmsResource」→「新規」をクリックし、新しいJMSシステム・モジュール・リソースを作成します。

  32. 新しいトピックのBIP.System.T_auto_2を作成します。

    1. 「作成するリソースのタイプを選択してください。」ページで「トピック」を選択して「次へ」をクリックします。

    2. 「名前」と「JNDI名」で、BIP.System.T_auto_2と入力します。「次へ」をクリックします。

    3. 「サブデプロイメント」を「BipJmsServer2」に設定し、「ターゲット」を「BipJmsServer_auto_2」に設定します。

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

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

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

    7. 「BipJmsResourceの設定」ページで、「dist_BIP.System.T_auto」という分散トピックを選択します。「dist_BIP.System.T_autoの設定」ページが表示されます。

    8. 「メンバー」タブ→「新規」をクリックします。

    9. 「トピック」プルダウン・バーから「BIP.System.T_auto_2」を選択して、新しい分散トピックを作成します。「OK」をクリックします。

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

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

15.2.3.13.4 Oracle BI Publisher Schedulerの構成の更新

この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLとJMS共有一時ディレクトリを更新します。

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

  1. 次のURLにアクセスして、いずれかのOracle BI Publisherインスタンスにログインします。

    http://APPHOST1VHN1:9704/xmlpserver
http://APPHOST2VHN1:9704/xmlpserver

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

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

  4. 次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。

    t3://APPHOST1VHN1:9704,APPHOST2VHN1:9704

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

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

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

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

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。


注意:

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

BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。

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

  2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

    「サーバーのサマリー」ページが表示されます。

  3. 「BI_SERVER1」（ハイパーリンクとして表示されています）を表の「名前」列でクリックします。

    BI_SERVER1サーバーの設定ページが開き、「構成」タブがアクティブに表示されます。

  4. 「サービス」タブをクリックします。

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

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

    ORACLE_BASE/admin/domain_name/bi_cluster/tlogs

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

  8. BI_SERVER2サーバーに対してこれらの手順を繰り返します。


    注意:

    トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。

15.2.3.14 APPHOST2でのシステムの起動

この項では、APPHOST2でシステムを起動する手順について説明します。

15.2.3.14.1 APPHOST2でのノード・マネージャの起動

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、第15.2.3.9.1項「APPHOST1でのノード・マネージャの起動」の手順に従って、APPHOST2でノード・マネージャを起動してください。

15.2.3.14.2 BI_SERVER2管理対象サーバーの起動と検証

BI_SERVER2管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。

  1. Oracle WebLogic Server管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。

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

    2. 「サーバー」を選択します。

      「サーバーのサマリー」ページが表示されます。

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

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

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

  3. BI_SERVER2が起動すると、次のURLが使用できるようになります。

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


      注意:

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

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

15.2.3.15 BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成

BI_SERVERn管理対象サーバーを含むbi_clusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

  1. WEBHOST1およびWEBHOST2で、ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。

    # WSM-PM
<Location /wsm-pm>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
</Location>

# BI Publisher
<Location /xmlpserver>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
 </Location>

  2. WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。

  3. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

    WEBHOST1> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs2

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

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

次のURLにアクセスできることを確認します。

  • http://WEBHOST1:7777/wsm-pm

  • http://WEBHOST2:7777/wsm-pm

  • http://WEBHOST1:7777/xmlpserver

  • http://WEBHOST2:7777/xmlpserver

ロード・バランシング・ルーター・アドレスを使用して、次のURLにアクセスできることを確認します。

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

  • http://bi.mycompany.com:80/wsm-pm

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

  1. BI_SERVER2の実行中に、Oracle WebLogic Server管理コンソールからBI_SERVER1を停止します。

  2. 次のURLにアクセスして、適切な機能を検証します。

    • WEBHOST1:7777/wsm-pm

    • WEBHOST1:7777/xmlpserver

  3. Oracle WebLogic Server管理コンソールからBI_SERVER1を起動します。

  4. BI_SERVER2を停止します。

  5. 前述の手順2のURLにアクセスして、適切な機能を検証します。

15.2.3.17 BI_SERVERnサーバーのサーバー移行の構成

この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を構成する必要があります。これを行うには、第15.1.3.21項「BI_SERVERnサーバーのサーバー移行の構成」の指示に従ってください。

15.2.3.18 新しいノード（APPHOST3）へのOracle BI Publisherトポロジのスケール・アウト

Oracle BI Publisherトポロジをスケール・アウトする際は、トポロジ内の新しいノード（APPHOST3）に、新しい管理対象サーバーとシステム・コンポーネント・セットを追加します。この項では、ノードが2つ以上あり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがある高可用性トポロジを前提にします。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

  • Oracle BI Publisherの管理対象サーバーが稼働している既存ノードがトポロジ内に存在する必要があります。

  • 新しいノード（APPHOST3）が、Oracle WebLogic ServerとOracle Business Intelligence用の既存のホーム・ディレクトリにアクセスできます。

  • ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、User_Home/bea/beahomelistファイルを編集します。次の手順を参照してください。

  • 新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。

APPHOST3でOracle BI Publisherをスケール・アウトするには、次の手順を実行します。

  1. APPHOST3で、Oracle Business Intelligenceのインストールと（必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合）ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

  2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

    APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>

    Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し（別のWebLogicインストールがノード内に存在する場合はそれを編集）、それにORACLE_BASE/product/fmwを追加します。

  3. VIP3をAPPHOST3で有効にします。第15.2.3.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。

  4. 第15.2.3.10項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームからコンフィギュレーション・アシスタントを実行します。

  5. 第15.2.3.11項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第15.2.3.12項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名検証を無効にすることで、bi_server3管理対象サーバーを構成します。

  6. 第15.2.3.13.3項「BI Publisher用のJMS永続ストアの構成」の説明に従って、Oracle BI Publisher用のJMSを構成します。

  7. 第15.2.3.13.5項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。

  8. 第15.2.3.15項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。

  9. APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第15.2.3.9.2項「BI_SERVER1管理対象サーバーの起動と検証」を参照してください。

  10. 第15.1.3.21.5項「サーバー移行ターゲットの構成」および第15.1.3.21.6項「サーバー移行のテスト」の説明に従って、サーバー移行を構成します。

  11. 構成を検証するには、http://APPHOST3VHN1:9704/xmlpserverというURLにアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。

  12. ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドでノード・マネージャの設定に関する章を参照してください。

15.3 Oracle Real-Time Decisionsの高可用性

Oracle Real-Time Decisions（Oracle RTD）を使用すると、選択元となる最善の選択肢について意思決定するための十分なコンテキストに基づいて、リクエストのオファーまたは選択肢のランク付きリストを提供できます。Oracle RTDでは常にフロントエンド・アプリケーションが使用されます。このアプリケーションの役割は、プロセス・フローを定義し、ユーザー操作を取得し、この操作をOracle RTDによる意思決定のための入力情報として解釈することです。したがってOracle RTDは、従来のWebアプリケーションというよりはむしろ意思決定サービスと見なすことができます。

この項では、Oracle RTDの高可用性環境を設計およびデプロイする方法を説明します。

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

15.3.1 Oracle RTDのコンポーネント・アーキテクチャ

図15-9では、Oracle RTDの単一インスタンス・アーキテクチャでの主要なコンポーネントを示しています。

図15-9 Oracle RTDの単一インスタンス・アーキテクチャ

図15-9の説明は次にあります。
「図15-9 Oracle RTDの単一インスタンス・アーキテクチャ」の説明

図15-9には、次のコンポーネントが示されています。

  • Decision Server: インライン・サービスと呼ばれるOracle RTDアプリケーションを実行するためのランタイム・サービスを提供します。

    Decision Serverとインライン・サービスの詳細は、「Decision Server」を参照してください。

  • バッチ・サービス: バッチ・マネージャとバッチ・エージェントが含まれます。バッチ・サービスの役割は、バッチ・ジョブを実行するためのリクエストを処理することです。

    バッチ・サービスの詳細は、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドの「Oracle RTDのバッチ・フレームワーク」を参照してください。

  • Decision Center: このWebベースのUIを使用して、ビジネス・ユーザーは、自身の分析モデルの有効性に関するレポートを表示したり、自身のホストしているインライン・サービスをチューニングします。

    Decision Centerの詳細は、「Decision Center」を参照してください。

  • 学習サービス: Oracle RTDデータベースから学習レコードを読み取り、新しい予測モデルを定期的に生成します。

    学習サービスの詳細は、「学習サービス」を参照してください。

Decision Server

Decision Serverは、インライン・サービスと呼ばれるOracle RTDアプリケーションを実行するために必要なランタイム・サービスを提供します。インライン・サービスは、Decision Studio開発環境を使用して開発され、Oracle RTD Decision Serverにデプロイされて実行されます。Decision Studioの詳細は、「Decision Studio、RTDクライアントおよびツール」を参照してください。

インライン・サービスは、リアルタイムかつ継続的に、エンタープライズ・ビジネス・プロセスのデータを収集して、これらのプロセスの特性を分析できます。また、これらのデータと分析結果を利用して、意思決定機能と、主要なビジネス・プロセスに対するフィードバックも提供できます。

Decision Serverのすべてのメタデータは、Oracle RTDデータベースに保管されます。

インライン・サービスの次の要素は、高可用性トポロジで特定の役割を果たすとともに、高可用性トポロジによる影響を受けます（主にOracle RTDの外部のリソースにアクセスすることで）。

  1. 選択肢: 選択肢は、インライン・サービスを通じて提示されるオファー、またはOracle RTDの自己学習モデルによって追跡される調査ターゲットを表します。選択肢には、静的と動的という2つの形式があります。静的選択肢は、Decision Studioを使用してハードコーディングされます。動的選択肢は、外部データソースで定義されて、インライン・サービスの実行時にロードされます。

  2. ルール: ルールを使用して、移入のセグメントのターゲットを設定したり、選択肢が適格であるかどうか判断したり、特定の選択肢を評価したりします。ルールは、グラフィカルなルール・エディタを使用して作成されます。ルールは、インライン・サービスの実行時にDecision Serverによってロードされます。Oracle RTDには、外部ルールと呼ばれるルールのタイプがあります。これらのルールは、Oracle RTDの外部のデータソースに保管されます。

  3. エンティティ: エンティティは、Oracle RTDのモデリングと意思決定に使用されるデータの論理表現です。エンティティの属性は、統合点からの受信パラメータとしてデータソースを介して入力することも、カスタム・ロジックを通じてリアルタイムに導出することもできます。

  4. データソース: データソースは、表やストアード・プロシージャからデータを取得します。

  5. 統合点: 統合点は、Oracle RTDと連携動作する外部システムとの接点の役割を果たします。統合点には、インフォーマントとアドバイザという2種類があります。インフォーマントは外部システムからデータを受信するのに対して、アドバイザはデータを受信して外部システムに推奨情報を送信します。

  6. モデル: 予測と報告という2つの主な役割を果たします。モデルは、次を目的として定義されます。

    • 選択肢に付随する特定のイベントが発生する可能性を予測します。

    • これらのイベントと相関付けられたデータを分析します。

    統計コレクタは、エンティティに関する統計を追跡する特別なモデルです。

    モデルは、設計時に選択肢グループと関連付けられます。これにより、予測とレポートが適用される選択肢のリストが定義されます。

Decision Center

ワークベンチ・サービスは、Decision Serverによるインライン・サービスのデプロイメントをサポートするとともに、Decision CenterのWebインタフェースを提供します。Decision Centerでは、インライン・サービスの構造と意思決定履歴が表示されます。ビジネス・ユーザーはDecision Centerを使用して、自身の分析モデルの有効性に関するレポートを表示したり、自身のホストしているインライン・サービスをチューニングできます。

Decision CenterはLearning Serverと連携して、学習モデルのコンテンツについて問い合せます。

学習サービス

インライン・サービス・セッションの終了時に、学習レコードが作成されます。学習レコードは、メモリー（構成可能）内でバッチ処理されて、Oracle RTDデータベースに保管されるためにキューに格納されます。これはパフォーマンス上の理由のために実行されます。これにより、学習レコードをOracle RTDデータベースに保管するために必要なデータベース・トランザクションの数が最小限に抑えられます。デフォルトでは、Oracle RTDは、50個のバッファ用の1つのキューを使用して、100件のレコードをバッファに格納します。ワーカー・スレッドによって、学習レコードがOracle RTDデータベースに書き込まれます。

学習サービスは休止状態から定期的に復帰して、次の操作を実行します。

  • 学習レコードをデータベースから読み取ります。

  • 新しい予測モデルを生成します。

各予測モデルは、特定のインライン・サービスと関連付けられています。したがって、インライン・サービスが影響を受けるのは、そのインライン・サービスが新しい予測モデルを持つときのみです。すべてのインライン・サービスは、別のインライン・サービスのモデルに対する更新から分離されています。

予測モデルは、Decision Serverに伝播されます。各Decision Serverは、Oracle RTDデータベースを頻繁にポーリングして、新しい予測モデルの有無を確認します。新しい予測モデルが見つかると、その予測モデルはメモリーにロードされます。

Decision Studio、RTDクライアントおよびツール

Decision Studioは、Oracle RTDのインライン・サービスを開発するためのEclipseベースの開発環境です。

Decision Studioを使用すると、Oracle RTDワークベンチ・サービスのWebサービスを介して、Oracle RTD Serverからインライン・サービスをダウンロードしてデプロイすることもできます。

Oracle RTDは、Oracle RTD Decision Serverとの簡単な統合を可能にするいくつかのクライアント・コンポーネントを提供します。たとえば、Oracle RTDが提供するJavaクライアントは、Oracle RTDのWebサービス・コールのラッパーを提供したり、デフォルトの結果セットをクライアント側のキャッシュに格納したり、Oracle RTD Serverが応答しないときにデフォルトのレスポンスを提供したりします。

Oracle RTDクライアント・ツールの詳細は、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドを参照してください。

Oracle RTDの管理

Oracle Enterprise Manager Fusion Middleware Controlは、Oracle RTDの単一インスタンスとクラスタ全体の属性を構成するために使用されます。

15.3.1.1 Oracle RTDコンポーネントの特性

この項では、Oracle RTDのコンポーネントの特性を説明します。

Oracle RTD Serverとそのコンポーネントは、JavaまたはWebベースのコンポーネントです。これらは、JavaコンテナまたはWebコンテナ内で実行されます。Oracle RTD Serverに接続されたOracle RTDクライアントとDecision Studioの間の通信は、いくつかのWebサービスを介して行われます。

Oracle RTDはセッション情報をローカルで管理するため、Webサーバーにセッション管理に依存しません。その理由は、Oracle RTDは、Webアプリケーションに関連付けられた一般的なセッションではなく、ビジネス・プロセスを完了するために長時間のセッションを必要とするからです。単一のDecision Serverセッションは、それぞれ異なるクライアント・サーバーを起点とする複数のHTTPセッションからリクエストを受信することがあります。Oracle RTDのセッションは短時間で終了する場合も、数時間、数日または数週間にわたって継続する場合もあります。

サーバーで障害が発生した場合は、リクエストは別のサーバーに転送されて、新しいセッションが作成されます。ほとんどの場合、セッション情報は外部データソースから読み取られるか計算されます。これらの値は、新しいセッションで再び読み取られるか再び計算されます。Oracle RTDは可能性を計算するためにセッション情報を使用するのであり、ビジネス・トランザクションの状態を保管するためではありません（後者はトランザクション/運用システムに委ねられています）。したがって、セッション情報が失われてもビジネス・プロセスに悪影響は及ぼされません。

15.3.1.1.1 コンポーネントのライフサイクル

Oracle RTDは、Oracle Enterprise Manager Fusion Middleware Controlを介して管理されます。Fusion Middleware Controlを使用して、Oracle RTDのサービスを起動、停止、アンデプロイ、デプロイおよび監視します。

15.3.1.1.2 プロセス・フロー

Oracle RTDのプロセス・フローは次のとおりです。

  1. 外部アプリケーションからOracle RTDの統合点に対してコールが発行されます。

  2. このリクエストは、Oracle RTDの意思決定サービスのWebサービスに送信されます。このサービスはOracle Web Services Managerによって認証されてから、このリクエストを処理します。

  3. このリクエストは、ターゲットとして設定されたインライン・サービスと、そのインライン・サービス内のターゲット・インフォーマントまたはターゲット・アドバイザに転送されます。

  4. インフォーマントの処理に含まれるのは、ルールの実行、関数の実行、エンティティへのアクセスおよび学習レコードの作成です。

  5. アドバイザの処理に含まれるのは、意思決定の実行、ルールの実行、適格性に関する関数の実行（フィルタリング）、エンティティへのアクセスおよび適格な選択肢のリストの返送です。

15.3.1.1.3 外部依存性

Oracle RTDの構成情報は自己完結型で、固有のデータベース・スキーマに格納されます。ただしインライン・サービスは、そのエンティティや外部ルールを外部データソースからロードできます。

15.3.1.1.4 構成アーティファクト

構成情報はOracle RTDデータベースに保管され、Fusion Middleware Controlを使用して更新されます。

データソースの構成情報は、Oracle WebLogic Server管理コンソールを使用して設定されます。

15.3.1.1.5 デプロイメント・アーティファクト

Oracle RTDのインライン・サービスは、Decision Studioで作成されます。開発者は、Decision Studioのデプロイメント機能を使用してインライン・サービスをデプロイします。インライン・サービスはOracle RTD Studioによってパッケージ化されて、Decision Serverのインスタンスにアップロードされます。Decision Serverは、すべてのアップロードされたインライン・サービスをOracle RTDの運用表に保管します。

15.3.1.1.6 ログ・ファイルの場所

Oracle RTDのログ・ファイルは、Oracle Enterprise Manager Fusion Middleware Controlを使用して表示できます。Oracle RTDのホーム・ページからログ・ファイルを表示するには、デプロイされたOracle RTDアプリケーションをナビゲーション・ペインで右クリックして、「ログ」→「ログ・ファイルの表示」を選択します。これにより、「ログ・メッセージ」画面が開いて、ログ・ファイルを表示できます。Oracle RTDログ・ファイルの表示の詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』を参照してください。

15.3.2 Oracle RTDの高可用性の概要

この項では、Oracle RTDを高可用性デプロイメントで使用する場合の概要について説明します。

15.3.2.1 Oracle RTDの高可用性アーキテクチャ

図15-10は、Oracle RTDの高可用性アクティブ/アクティブ・アーキテクチャを示しています。

図15-10 Oracle RTDの高可用性アーキテクチャ

図15-10の説明は次にあります。
「図15-10 Oracle RTDの高可用性アーキテクチャ」の説明

図15-10では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。

Oracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。APPHOST1が使用できなくなると、第3章「WebLogic Serverの高可用性」の説明に従って、管理サーバーをAPPHOST2でアクティブにできます。Oracle RTDは、これらのホスト上のBI_SERVER1管理対象サーバーとBI_SERVER2管理対象サーバーにデプロイされます。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。

データ層では、Oracle RACデータベースはOracle RTDリポジトリ用に使用されますが、エンタープライズ・データベース用としてもお薦めします。Oracle RTDリポジトリには、学習モデル、学習レコード、予測モデルおよびインライン・サービスのメタデータが保管されます。


注意:

Web層のかわりにロード・バランサを直接のフロントエンドとして使用したOracle RTDインスタンスのクラスタもサポートされています。このタイプのデプロイメントでは、ロード・バランサは、HTTPヘッダーを使用したスティッキー・セッションのルーティングを実現できるように構成される必要があります。HTTPヘッダーを使用したスティッキー・セッションのルーティングを実現できるようにするための構成については、お使いのロード・バランサのドキュメントを参照してください。

このタイプのデプロイメント環境内のOracle RTDクラスタにアクセスするクライアントは、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドのJavaスマート・クライアントに関する項に記載されている要件を満たしている必要があります。このクライアントの設定例については、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドの「Javaスマート・クライアントの使用」を参照してください。

Oracle RTDクラスタの考慮事項

クラスタ内では、Decision Centerは、学習サービスと通信する必要があるため、通常は学習サービスと同じOracle RTDインスタンスにデプロイされます。ただし、Decision Centerはシングルトンではないため、アクティブな学習サービスとは異なる場所に配置されたインスタンスは、JMSを使用してアクティブな学習サービスと通信します。

クラスタ内では、Decision Centerは通常は意思決定サービスとは異なるOracle RTDインスタンスにデプロイされることで、Decision Centerがパフォーマンスとメモリーの面で意思決定サービスに与える影響が最小限に抑えられます。

クラスタ内では、非クラスタ化インストールで使用されるのと同じ内部Webサービスを使用して、インライン・サービスがDecision Studioによって任意のクラスタ・メンバーにデプロイされます。Decision Studioが接続されているインスタンスは、インライン・サービスをメモリーにロードして、データベースに保存します。他のクラスタ・メンバーは、データベース内の新しいインライン・サービスを検知して、このインライン・サービスを各自のメモリーにロードします。

パフォーマンス上の理由から、HTTPセッション・アフィニティが有効になっているクラスタにOracle RTDをデプロイすることが最適です。その理由は、正確な学習レコードの作成と予測のためには、Oracle RTDセッションのコンテキストが必要だからです。セッション内には、学習に寄与できる動的状態が存在しますが（このDecision Serverセッションでアクセスされる一連のWebページの順序など）、この動的状態はデータベースからは取得されません。この状態は学習に寄与しますが、それは集約された形のみになります。個人の状態や、複数のサーバーにまたがって複製されるほど重要な状態は存在しません（その状態がシリアライズ可能であった場合でも同様です）。サーバーの障害が原因でいくつかのセッションが失われた場合でも、集約された情報に基づいているOracle RTDの学習モデルの整合性は目立った影響を受けません。

クラスタ内の各Decision Serverインスタンスは、Oracle RTDの運用表をポーリングして、新しいインライン・サービスや更新されたインライン・サービスの有無を確認します。新しいインライン・サービスや更新されたインライン・サービスが見つかった場合は、そのインライン・サービスはクラスタのすべてのメンバーによってメモリーにロードされます。

Oracle RTDでは、ハードウェアまたはソフトウェアのロード・バランサが使用されます。

開発者は、Webサービス・リクエストにセッション鍵を挿入できます。セッション鍵はユーザーによって定義され、パラメータとしてOracle RTD Javaクライアント（Oracle RTD Webサービスに対するラッパー）に渡されます。ロード・バランサは、セッション・アフィニティを有効にするように構成される必要があるとともに、セッション鍵をHTTPヘッダーから取得するように構成される必要があります。

Oracle RTDインスタンス間のクラスタ・メンバー内通信は、JMSを通じて行われます。JMSの公開/サブスクライブ・モデルは、Oracle RTDデプロイメントで作成される「RTDTopic」という単一トピックとともに使用されます（Oracle RTDのWebLogicテンプレートで定義されます）。各Oracle RTDインスタンスは、この単一トピックにサブスクライブして、各インスタンスに該当するメッセージを読み取ります（フィルタリングを介して）。

Oracle RTD Serverは、セッション状態が不明なリクエストを受信することがあります。この場合は、リクエストを受信したDecision Serverは検索を実行して、このリクエストの本来の宛先であるDecision Serverを探します。その後、このリクエストは正しいDecision Serverに転送されます。転送側のDecision Serverは、このリクエストが受信側のDecision Serverによって完了されるのを待ちます。

転送されるリクエストはJMSを介して送信されます。各Oracle RTD Serverは、各自に該当するすべてのメッセージをOracle RTD JMSトピックから取得します。このリクエストは、標準の意思決定サービスWebサービスを通じて処理されることはありません。かわりに、このリクエストはターゲットのインライン・サービス宛に直接マーシャリングされます。

受信側のDecision Serverがリクエストを完了したら、コールはアンワインドされ、リクエストの転送元は、受信側のDecision Serverからレスポンスを受け取ります。このレスポンスはコール元に返送されます。

シングルトン・サービス

図15-10では、Oracle RTDの学習サービスとバッチ・マネージャはシングルトンです。学習サービスの役割は、1つ以上のOracle RTD意思決定サービス・インスタンスによって書き込まれたデータ・レコードから分析モデルを構築することです。分析モデルは、一連の入力値に基づいて、特定の結果が生じる可能性を提示します。たとえば分析モデルは、過去に購入された製品の履歴に基づいて、顧客が特定の製品を購入する可能性がどれだけあるのかを算定できます。学習モデルはメモリー内で構築されます。モデルの構築中にアクティブな学習サービスで障害が発生した場合は、新しい学習サービスがアクティブ化されて、データが失われることなくモデルを最初から構築します。バッチ・マネージャの役割は、バッチ管理クライアントのかわりにバッチ・ジョブを開始および管理することです。バッチ・マネージャは、他のOracle RTDインスタンス上のバッチ・エージェント・インスタンスと通信して、作業をクラスタ全体にわたって分散します。学習サービスとバッチ・マネージャはどちらも、アクティブ/スペア・シングルトンと見なされます。

クラスタ・コーディネータ

Oracle RTDには、次のタスクを実行する独自のクラスタ・コーディネータがあります。

  • 学習サービス・シングルトンとバッチ・マネージャ・シングルトンという各タイプについて、ちょうど1つのシングルトンがアクティブになるようにします。クラスタ・シングルトンを起動または停止するのは、クラスタ・コーディネータだけです。

  • クラスタ・コーディネータは、クラスタを離れるメンバーによって開いた状態のまま放置されたリソースをクリーンアップします（このクリーンアップ・ロジックは、制御された手順に従ってノードが停止されるときに、そのノードが自身に対して通常実行するものと同じです）。コーディネータがこのクリーンアップを実行するのは、クラスタを離れようとしているノードが突然動作しなくなったために、そのノード自体のリソースを閉じることができなかった場合です。たとえば、クラスタ・メンバーによってホストされているすべてのDecision Centerセッションは、そのクラスタ・メンバーがクラスタを離れるときにコーディネータによって閉じられます。

各Oracle RTDクラスタ・メンバーは、その起動時に、クラスタ・コーディネータになろうとして競合します。そのために、データベースをトランザクション方式でテストして、別のインスタンスがすでにコーディネータになっているかどうかを確認し、他のコーディネータが存在しない場合は自身をコーディネータとしてデータベースに挿入します。コーディネータになるための権限は、そのコーディネータ自身によって定期的に更新されないと失効するため、コーディネータが動作不能になると、他のいずれかのクラスタ・メンバーがコーディネータになります。

15.3.2.1.1 クラスタの起動と停止

Oracle WebLogic Server管理コンソールを使用して、Oracle RTDクラスタ内の単一インスタンスを起動および停止できます。

15.3.2.1.2 クラスタワイドの構成変更

Oracle RTDの構成情報は自己完結型で、固有のデータベース・スキーマに格納されます。この構成情報は、Oracle Enterprise Manager Fusion Middleware Controlを使用して更新できます。

Oracle RTDクラスタ内の1つのインスタンスの構成を変更した場合は、Oracle Enterprise Manager Fusion Middleware Controlで「適用」ボタンをクリックした後に、他のインスタンスがそれらの構成変更内容を取得します。

15.3.2.2 障害からの保護および予想される動作

各クラスタ・メンバーで動作しているOracle RTDトポロジ管理レイヤーは、データベース内の自身のハートビート・レコードを更新しなくなったクラスタ・メンバーを検知します。管理対象サーバー内の個別サービスの障害が発生しているかどうかは確認しません。このため、この項で説明する障害シナリオは、個別サービスの障害ではなく管理対象サーバーの障害を対象にしています。

15.3.2.2.1 Decision Serverの障害

Decision Serverで障害が発生した場合は、次のようになります。

  • Decision Serverと関連付けられたOracle RTDセッションは、それらのステートフル情報とともに失われます。

  • ロード・バランサは、障害が発生したサーバーを本来の宛先としていたリクエストを別のサーバーに転送します。

  • これらのリクエストを受信したサーバーは、新しいOracle RTDセッションを作成して、セッション・レベル・エンティティを適切なデータソースからハイドレートして、そのリクエストに対応します。

学習レコードは、データベースに頻繁に書き込まれます。学習レコードは統計目的に使用されます。Decision Serverで障害が発生した場合は、次のようになります。

  • 永続化されていない学習レコードはすべて失われます。

  • Oracle RTDは、特定の顧客の情報やアカウント情報などのトランザクション・データを一切保管しません。したがって、多数の学習レコードがすでに学習元として使用済であり、予測モデルが収束済の場合は、一部のデータが失われても重大な問題にはならず、可能性の計算は大きな影響を受けないため、Oracle RTDインフォーマントによって返されるオファーも大きな影響を受けません。

15.3.2.2.2 クラスタ・コーディネータの障害

障害が発生したサーバーがクラスタ・コーディネータである場合は、次のようになります。

  • Oracle RTDデータベース内のタイムスタンプを更新しなくなります。

  • データベース表をポーリングしている他のサーバーは、タイムスタンプが無効になったこと、およびクラスタ・コーディネータで問題が発生している可能性があることを検知します。

  • すべてのアクティブなOracle RTDインスタンスは、新しいクラスタ・コーディネータになろうとして競合します。

15.3.2.2.3 学習サービスの障害

学習モデルはメモリー内で構築されます。

モデルの構築中にアクティブな学習サービスで障害が発生した場合は、新しい学習サービスがアクティブ化されて、データが失われることなくモデルを最初から構築します。

アクティブな学習サービスが配置されたノードで障害が発生した場合は、クラスタ・コーディネータは、残りのクラスタ・ノード（学習サービスがデプロイおよび有効化されているノード）のいずれかで学習サービスをアクティブ化します。そのために、クラスタ・コーディネータは、JMSを使用したクラスタ内RPCを介してOracle RTDインスタンスにコマンドを送信します。

15.3.2.2.4 Decision Centerの障害

Decision Centerで障害が発生した場合は、進行途中のユーザー作業のうち、保存されていなかった作業の内容はすべて失われます。たとえば、保存されていなかったルールの更新内容やパフォーマンス目標の変更内容が失われます。

1つのクラスタ内で複数のDecision Centerが実行されているため、ユーザーはアクティブなDecision Centerに接続されます。

15.3.2.2.5 バッチ・マネージャの障害

アクティブなバッチ・マネージャが配置されたノードで障害が発生した場合は、クラスタ・コーディネータは、残りのノード（バッチ・マネージャがデプロイおよび有効化されているノード）のいずれかでバッチ・マネージャをアクティブ化します。

クラスタのバッチ・マネージャ・シングルトンで障害が発生した場合は、クラスタ・コーディネータはその障害を検知して、異なるホストで別のバッチ・マネージャを起動します。すべてのバッチ・エージェントには新しいバッチ・マネージャの存在が通知され、これらのバッチ・エージェントは自身をその新しいバッチ・マネージャに登録します。

バッチ・ジョブを実行しているノードで障害が発生した場合は、次のようになります。

  • 障害が発生したサーバー上のバッチ・ジョブのみが処理を停止します。

  • 障害が発生したノード上で実行されていたバッチ・ジョブはすべて中断状態になります。これらのバッチ・ジョブを手動で再開するには、バッチ・コンソールまたは他のバッチ管理クライアントを使用してバッチ・マネージャに対して再開コマンドを発行します。

  • 中断されたジョブが再開されるときは、その状態がバッチ・マネージャと最後に同期された箇所から再開されます。バッチ・マネージャがジョブの再開を要求されると、バッチ・マネージャによって選択された使用可能なバッチ・エージェント上で、そのジョブが再開されます。

15.3.3 Oracle RTDの高可用性の構成手順

この項では、Oracle Real-Time Decisionsの2ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図15-10に示しています。


注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

15.3.3.1 Oracle RTDの高可用性構成の設定前に必要な手順

この項では、Oracle RTDの高可用性構成を設定するための前提条件について説明します。

15.3.3.1.1 データベースに関する前提条件

Oracle RTDでサポートしているデータベースのバージョンは次のとおりです。

  • Oracle Database 10g（非XEデータベースについては10.2.0.4以上）

  • Oracle Database 11g（非XEデータベースについて11.1.0.7以上）

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.3.3.1.2 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Clusterwareインストレーション・ガイド』を参照してください。

自動ストレージ管理

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。

インストーラを実行するときは、構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g（11.1.1）Oracle Fusion MiddlewareリポジトリをOracle Real Application Clusters（Oracle RAC）データベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ（RCU）が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g（11.1.1）Oracle Fusion MiddlewareリポジトリをOracle RACデータベースにインストールします。

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

15.3.3.1.3 RCUを使用したデータベースへのBusiness Intelligenceスキーマのロード

Oracle RTDをインストールする前に、11g（11.1.1）Oracle Fusion Middlewareのメタデータ・ストアとOracle BIスキーマをOracle RACデータベースにインストールします。次の手順を実行します。

  1. リポジトリ作成ユーティリティ（RCU）のDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。

    prompt> cd RCU_HOME/bin
prompt> ./rcu

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

  3. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。

  4. 「データベース接続の詳細」画面で、データベースの接続情報を入力します。

    • データベース・タイプ: Oracle Databaseを選択します。

    • ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します。次に例を示します。

      BIDBHOST1-VIP

    • ポート: データベースのリスニング・ポート番号である1521を指定します。

    • サービス名: データベースのサービス名を指定します。

      biha.mycompany.com

    • ユーザー名: DBA権限またはSYSDBA権限のあるユーザーの名前（SYS）を指定します。

    • パスワード: SYSユーザーのパスワードを入力します。

    • ロール: データベース・ユーザーのロール（SYSDBA）をリストで選択します（SYSユーザーに必要）。

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

  5. 「コンポーネントの選択」画面で、次を行います。

    • 「接頭辞の新規作成」を選択し、BIHAのように、データベース・スキーマに使用する接頭辞を入力します。6文字まで接頭辞として指定できます。接頭辞を使用して、複数リポジトリの論理グルーピングをデータベースにおいて作成します。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。


      ヒント:

      このスキーマの名前をメモに記録してください。後述する手順でこの情報が必要になります。

    • 次のコンポーネントを選択します。

      o  AS Common Schemas: Metadata Services (automatically selected)
o  Oracle Business Intelligence: Business Intelligence Platform

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

  6. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。

    要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択できます。

    「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。


    ヒント:

    スキーマ・パスワードの名前をメモに記録してください。後述する手順でこの情報が必要になります。

  7. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

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

  9. 「完了サマリー」画面で「閉じる」をクリックします。

15.3.3.1.4 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle RTDの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

Oracle RTDは、2つのOracle HTTP ServerがWeb層コンポーネントとして使用された高可用性構成でデプロイされた場合は、ハードウェア・ロード・バランサを使用します。

仮想サーバー名

bi.mycompany.comは、Oracle RTDなどのランタイムBIコンポーネント宛のすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、bi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

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

この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。

  1. サーバーが次の要件を満たしていることを確認します。

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

    • ポート7777がWEBHOST1上のサービスによって使用されていないことを確認するために、使用するオペレーティング・システムに応じて次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。

      UNIXの場合:

      netstat -an | grep "7777"

      Windowsの場合:

      netstat -an | findstr :7777

      ポートが使用されている（コマンドを実行するとポートを識別する戻り値が表示される）場合は、そのポートを解放する必要があります。

      UNIXの場合:

      ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

      Windowsの場合:

      ポートを使用しているコンポーネントを停止します。

    • staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

    • 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート（Oracle HTTP Serverのポート番号を指定する行は非コメント化）を割り当てます。

      # The port for Oracle HTTP server
Oracle HTTP Server port = 7777

  2. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。

    UNIXの場合:

    ./runinstallerコマンドを発行します。

    Windowsの場合:

    setup.exeをダブルクリックします。

    「インベントリ・ディレクトリの指定」画面が表示されます。

  3. 「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。次に例を示します。

    インベントリ・ディレクトリの指定: /u01/app/oraInventory

    オペレーティング・システムのグループ名: oinstall

    次のメッセージのダイアログ・ボックスが表示されます。

    インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください。

    rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。

    これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。


    注意:

    すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールでOracleインベントリ画面が表示されない場合は、次の内容を確認してください。

    • /etc/oraInst.locファイルが存在しているか。

    • このファイルが存在する場合は、表示されているインベントリ・ディレクトリが有効か。

    • インストールを実行しているユーザーがインベントリ・ディレクトリに対する書込み権限を持っているか。

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

  5. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

  6. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。

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

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

    • Oracle Middlewareホーム: ORACLE_BASE/product/fmw（グレーアウトされています）

    • Oracleホーム・ディレクトリ: Oracle_WT1

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

  8. 「コンポーネントの構成」画面で、次の操作を行います。

    • 「Oracle HTTP Server」を選択します。

    • 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

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

  9. 「コンポーネントの詳細の指定」画面で、WEBHOST1用に次の値を入力します。

    • インスタンス・ホームの場所: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1

    • インスタンス名: web1

    • OHSコンポーネント名: ohs1

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

  10. 「ポートの構成」画面で、次の操作を行います。

    • カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

    • Oracle HTTP Serverポートを入力します（例: 7777）。

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

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

  12. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「インストール」をクリックします。

  13. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

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

  14. 「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。「次へ」をクリックします。

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

WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランサを構成します。

15.3.3.1.6 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、Webブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

http://WEBHOST1:7777/
http://WEBHOST2:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザにOracle FMWの「ようこそ」画面が表示されます。

15.3.3.2 Oracle Fusion Middlewareホームのインストール

この項では、Oracle WebLogic ServerとOracle Fusion Middleware BI EEを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。WebLogic ServerとOracle RTDをAPPHOST2にインストールするために、これと同じ手順を繰り返します（次ではAPPHOST1を対象にして説明しています）。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

  • Oracle WebLogic Server

  • Oracle Fusion Middleware BI EE

15.3.3.2.1 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールする手順は次のとおりです。

  1. Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。

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

  3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

    • 「新しいミドルウェア・ホームを作成する」を選択します。

    • 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します。


      注意:

      ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracleの値をお薦めします。

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

  4. 「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

  5. 「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。

  6. 「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.5ディレクトリを受け入れます。そして「次へ」をクリックします。

  7. 「インストールの概要」画面で「次へ」をクリックします。

    Oracle WebLogic Serverソフトウェアがインストールされます。

  8. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

15.3.3.2.2 Oracle RTDのインストール

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

  1. Oracle Fusion Middleware Business Intelligence 11gのインストーラを次のインストール・メディアから起動します。

    UNIXの場合:

    APPHOST1>./runInstaller

    Windowsの場合:

    APPHOST1> setup.exe

  2. 「インベントリ・ディレクトリの指定」画面で、次の操作を行います。

    • HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです（この場所をお薦めします）。

    • インストールを実行するユーザーのOSグループを入力します。

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

    • 画面の手順に従って、/createCentralnventory.shをrootとして実行します。

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

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

  4. 「インストール・タイプの選択」画面で、「ソフトウェアのみインストール」を選択して「次へ」をクリックします。

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

  6. 「インストール場所の指定」画面で、前にインストールしたMiddlewareホームをドロップダウン・リストで選択します。「Oracleホーム」ディレクトリには、ディレクトリ名（Oracle_BI1）を入力します。

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

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

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

    Oracle Fusion Middleware Business Intelligence 11gソフトウェアがインストールされます。

  9. 「インストールの進行状況」画面で「次へ」をクリックします。

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

15.3.3.3 APPHOST1のVIP1およびAPPHOST2のVIP2の有効化

BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してマッピングされているVIPを有効にして（APPHOST1ではVIP1、APPHOST2ではVIP2）、トポロジで使用されるネットワーク・システムで仮想ホスト名を（DNSサーバーとhosts解決のいずれかで）正しく解決する必要があります。

15.3.3.4 管理サーバーと1つ目のBI_SERVER1管理対象サーバーが含まれたドメインの作成

この項では、Oracle Business Intelligenceコンフィギュレーション・アシスタント、Oracle WebLogic Server管理コンソールおよびOracle Enterprise Managerを使用して、ドメインと最初のWebLogic Server BI管理対象サーバーを作成する方法について説明します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。


注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

Oracleホーム・ディレクトリからコンフィギュレーション・アシスタントを実行して、Oracle RTDが配置された管理対象サーバーおよび管理サーバーが含まれたドメインを作成します。

  1. コンフィギュレーション・アシスタントの場所にディレクトリを移動します。

    APPHOST1> cd ORACLE_HOME/bin

  2. コンフィギュレーション・アシスタントを起動します。

    UNIXの場合:

    APPHOST1> ./config.sh

    Windowsの場合:

    APPHOST1> config.bat

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

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

  5. BIシステムの作成またはスケールアウト画面が表示されます。新規BIシステムの作成を選択して、次の値を指定します。

    • ユーザー名: weblogic

    • ユーザー・パスワード: weblogicユーザーのパスワードを入力します。

    • ドメイン名: bifoundation_domain

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

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

    • MiddleWareホーム: ORACLE_BASE/product/fmw（グレーアウトされています）

    • Oracleホーム: ORACLE_BASE/product/fmw/Oracle_BI1（グレーアウトされています）

    • WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3（グレーアウトされています）

    • ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain


      注意:

      「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

    • インスタンス・ホーム: ORACLE_BASE/product/fmw/instance1

    • インスタンス名: instance1

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

  7. 「コンポーネントの構成」画面で、Oracle Real-Time Decisionsを選択します。

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

  8. 「データベース詳細」画面で、次の値を入力します。

    • データベース・タイプ: Oracle Database

    • 接続文字列: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM

    • BIPLATFORMスキーマ・ユーザー名: BIHA_BIPLATFORM

    • BIPLATFORMスキーマ・パスワード: BIPLATFORMスキーマ・ユーザーのパスワードを入力します。

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

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

    • 自動でポートを構成

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

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

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

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

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

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

15.3.3.5 APPHOST1での管理サーバーのboot.propertiesの作成

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。

  1. 次のディレクトリに移動します。

    ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/
AdminServer/security

  2. 次の行をファイルに入力し、ファイルを保存してからエディタを閉じます。

    username=Admin_username
password=Admin_password

    注意:

    管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

    セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

15.3.3.6 APPHOST1での管理サーバーの起動と検証

この項では、APPHOST1で管理サーバーを起動および検証する手順について説明します。

15.3.3.6.1 APPHOST1での管理サーバーの起動

APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin
APPHOST1> ./startWebLogic.sh
15.3.3.6.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

  1. ブラウザでhttp://APPHOST1:7001/consoleにアクセスします。

  2. 管理者としてログインします。

  3. BI_SERVER1管理対象サーバーが表示されていることを確認します。

  4. bi_clusterクラスタが表示されていることを確認します。

  5. Enterprise Manager（http://APPHOST1:7001/em）にアクセスできることを確認します。

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

次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。

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

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

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

  4. 「サーバー」をクリックします。

    「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で「bi_server1」を選択します。

    bi_server1の「設定」ページが表示されます。

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

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

  8. 変更を保存およびアクティブ化します。

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

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

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。

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

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

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

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

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

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

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

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

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

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

  10. 変更を保存およびアクティブ化します。

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

15.3.3.9 APPHOST1でのシステムの起動

この項では、APPHOST1でノード・マネージャを起動する方法、およびAPPHOST1でBI_SERVER1管理対象サーバーを起動して検証する方法について説明します。

15.3.3.9.1 APPHOST1でのノード・マネージャの起動

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合、次のコマンドを使用してAPPHOST1で起動します。

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
15.3.3.9.2 BI_SERVER1管理対象サーバーの起動と検証

BI_SERVER1管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。

  1. Oracle WebLogic Server管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。

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

    2. 「サーバー」を選択します。

      「サーバーのサマリー」ページが表示されます。

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

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

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

  3. BI_SERVER1が起動すると、次のURLが使用できるようになります。

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


      注意:

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

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

15.3.3.10 APPHOST2でのBIシステムのスケール・アウト

コンフィギュレーション・アシスタントをORACLE_HOMEディレクトリから実行して、BIシステムをスケール・アウトします。

  1. コンフィギュレーション・アシスタントの場所にディレクトリを移動します。

    APPHOST2> cd ORACLE_HOME/bin

  2. コンフィギュレーション・アシスタントを起動します。

    APPHOST2> ./config.sh

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

  4. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。

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

  5. BIシステムの作成またはスケールアウト画面が表示されます。BIシステムのスケールアウトを選択して、次の値を入力します。

    • ホスト名: ADMINHOST

    • ポート: 7001

    • ユーザー名: weblogic

    • ユーザー・パスワード: weblogicユーザーのパスワードを入力します。

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

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

    • MiddleWareホーム: ORACLE_BASE/product/fmw（グレーアウトされています）

    • Oracleホーム: Oracle_BI1（グレーアウトされています）

    • WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3（グレーアウトされています）

    • ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain


      注意:

      「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

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

    • インスタンス名: instance2（グレーアウトされています）

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

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

    • 自動でポートを構成

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

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

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

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

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

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

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

次の手順を実行して、BI_SERVER2管理対象サーバーのリスニング・アドレスを設定します。

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

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

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

  4. 「サーバー」をクリックします。

    「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で「bi_server2」を選択します。

    bi_server2の「設定」ページが表示されます。

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

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

  8. 変更を保存およびアクティブ化します。

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

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

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。

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

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

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

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

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

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

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

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

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

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

  10. 変更を保存およびアクティブ化します。

  11. この変更内容は、管理サーバーが再起動されるまでは適用されません（ノード・マネージャが稼働していることを確認します）。

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

    2. 表で「AdminServer(管理サーバー)」（ハイパーリンクとして表示）を選択してから、「停止」をクリックします。

    3. コマンドラインから次のコマンドを実行して管理サーバーを再び起動します。

      APPHOST1> cd ORACLE_COMMON_HOME/bin
APPHOST1> ./wlst.sh

      WLSTシェル内で、次のコマンドを実行します（ノード・マネージャが稼働していることを確認します）。

      wls:/offline> nmConnect ('Admin_User','Admin_Password', 'APPHOST1', '9556',
'domain_name', 'ORACLE_BASE/product/fmw/user_projects/domain/
bifoundation_domain')

wls:/nm/domain_name> nmStart ('AdminServer')

15.3.3.13 Oracle RTDの構成

この項では、Oracle RTDの構成について説明します。

15.3.3.13.1 RTDクラスタ固有プロパティの構成

Oracle Enterprise Manager Fusion Middleware Controlで次の手順を実行します。

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

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

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

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

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

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

  7. 「Oracle RTD」の下の各サーバーについて、MBeanにナビゲートして、表15-8に示す属性を設定します。

    表15-8 Oracle RTD MBeanに対して設定する属性値

    MBean 属性 BI_SERVER1の値 BI_SERVER2の値

    SDPropertyManager-> Misc

    BatchAgentEnabled

    True

    True

    SDPropertyManager-> Misc

    BatchManagerEnabled

    True

    True

    SDPropertyManager-> Misc

    DecisionServiceEnabled

    True

    True

    SDPropertyManager-> Misc

    LearningServiceEnabled

    True

    True

    SDClusterPropertyManager-> Cluster

    RestrictDSClients

    False

    False

    SDClusterPropertyManager-> Misc

    DecisionServiceAddress

    http://bi.mycompany.com

    http://bi.mycompany.com

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

15.3.3.13.2 Oracle RTD JMS用のWebLogic Server JMSの構成

APPHOST2用のJMSサーバーを構成するには、次の手順をAPPHOST2で実行します。

  1. bi_server2管理対象サーバー用のJMSサーバーを作成します。

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

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

    3. 「ドメイン構造」ウィンドウで、「サービス」ノードを開きます。

    4. 「メッセージング」ノードを開きます。

    5. 「JMSサーバー」をクリックします。

    6. 「新規」をクリックします。「新しいJMSサーバーの作成」ページが表示されます。

    7. 新しいJMSサーバーを指定します（例: RTDJmsServer_2）。

    8. 「bi_server2」をターゲットとして選択します。「終了」をクリックします。

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

    10. bi_server2を再起動して、変更内容をRTDに適用します。

  2. Oracle RTD JMSモジュールのSubDeploymentターゲットを更新します。

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

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

    3. 「ドメイン構造」ウィンドウで、「サービス」ノードを開きます。

    4. 「メッセージング」ノードを開きます。

    5. 「JMSモジュール」をクリックします。「JMSモジュール」ページが表示されます。

    6. 「RTDJMSMODULE」をクリックします。RTDJMSMODULEの「設定」ページが表示されます。

    7. 「サブデプロイメント」タブを開きます。

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

    9. サブデプロイメントの追加ターゲットとして、新しいRTD JMSサーバー（RTDJmsServer_2）を追加します。

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

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

15.3.3.14 APPHOST2でのシステムの起動

この項では、APPHOST2でシステムを起動する手順について説明します。

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

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。


注意:

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

BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。

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

  2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

    「サーバーのサマリー」ページが表示されます。

  3. 「BI_SERVER1」（ハイパーリンクとして表示されています）を表の「名前」列でクリックします。

    BI_SERVER1サーバーの設定ページが開き、「構成」タブがアクティブに表示されます。

  4. 「サービス」タブをクリックします。

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

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

    ORACLE_BASE/admin/domain_name/bi_cluster/tlogs

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

  8. BI_SERVER2サーバーに対してこれらの手順を繰り返します。


    注意:

    トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。

15.3.3.14.2 APPHOST2でのノード・マネージャの起動

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、第15.3.3.9.1項「APPHOST1でのノード・マネージャの起動」の手順を繰り返して、APPHOST2でノード・マネージャを起動してください。

15.3.3.14.3 BI_SERVER2管理対象サーバーの起動と検証

BI_SERVER2管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。

  1. Oracle WebLogic Server管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。

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

    2. 「サーバー」を選択します。

      「サーバーのサマリー」ページが表示されます。

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

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

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

  3. BI_SERVER2が起動すると、次のURLが使用できるようになります。

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


      注意:

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

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

15.3.3.15 BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成

BI_SERVERn管理対象サーバーを含むbi_clusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

  1. WEBHOST1およびWEBHOST2で、ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。

    <Location /rtis>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1:9704, APPHOST2:9704
</Location>
 
<Location /schema>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1:9704, APPHOST2:9704
</Location>
 
<Location /ws>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
</Location>

# WSM-PM
<Location /wsm-pm>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1:9704, APPHOST2:9704
</Location>

# RTD
<Location /ui>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1:9704, APPHOST2:9704
 </Location>

  2. WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。

  3. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

    WEBHOST1> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs2

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

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

次のURLにアクセスできることを確認します。

  • http://WEBHOST1:7777/wsm-pm

  • http://WEBHOST2:7777/wsm-pm

  • http://WEBHOST1:7777/ui

  • http://WEBHOST2:7777/ui

ロード・バランシング・ルーター・アドレスを使用して、次のURLにアクセスできることを確認します。

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

  • http://bi.mycompany.com:80/wsm-pm

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

  1. BI_SERVER2の実行中に、Oracle WebLogic Server管理コンソールからBI_SERVER1を停止します。

  2. 次のURLにアクセスして、適切な機能を検証します。

    • WEBHOST1:7777/wsm-pm

    • WEBHOST1:7777/ui

  3. Oracle WebLogic Server管理コンソールからBI_SERVER1を起動します。

  4. BI_SERVER2を停止します。

  5. 前述の手順2のURLにアクセスして、適切な機能を検証します。

15.3.3.17 BI_SERVERnサーバーのサーバー移行の構成

この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を構成する必要があります。これを行うには、第15.1.3.21項「BI_SERVERnサーバーのサーバー移行の構成」の指示に従ってください。

15.3.3.18 新しいノード（APPHOST3）へのOracle RTDトポロジのスケール・アウト

Oracle RTDトポロジをスケール・アウトする際は、トポロジ内の新しいノード（APPHOST3）に、新しい管理対象サーバーとシステム・コンポーネント・セットを追加します。この項では、ノードが2つ以上あり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがある高可用性トポロジを前提にします。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

  • Oracle RTDの管理対象サーバーが稼働している既存ノードがトポロジ内に存在していること。

  • 新しいノード（APPHOST3）が、Oracle WebLogic ServerとOracle Business Intelligence用の既存のホーム・ディレクトリにアクセスできます。

  • ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、User_Home/bea/beahomelistファイルを編集します。次の手順を参照してください。

  • 新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。

APPHOST3でOracle RTDをスケール・アウトするには、次の手順を実行します。

  1. APPHOST3で、Oracle Business Intelligenceのインストールと（必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合）ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

  2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

    APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>

    Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し（別のWebLogicインストールがノード内に存在する場合はそれを編集）、それにORACLE_BASE/product/fmwを追加します。

  3. VIP3をAPPHOST3で有効にします。第15.2.3.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。

  4. 第15.3.3.10項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームからコンフィギュレーション・アシスタントを実行します。

  5. 第15.3.3.11項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第15.3.3.12項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名検証を無効にすることで、bi_server3管理対象サーバーを構成します。

  6. 第15.3.3.14.1項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。

  7. 第15.3.3.15項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。

  8. APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第15.3.3.9.2項「BI_SERVER1管理対象サーバーの起動と検証」を参照してください。

  9. 第15.1.3.21.5項「サーバー移行ターゲットの構成」および第15.1.3.21.6項「サーバー移行のテスト」の説明に従って、サーバー移行を構成します。

  10. 構成を検証するには、http://APPHOST3VHN1:9704/uiというURLにアクセスして、Oracle RTDアプリケーションのステータスを確認します。

  11. ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドでノード・マネージャの設定に関する章を参照してください。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引