| Oracle® Fusion Middleware高可用性ガイド 11gリリース2(11.1.2) B69538-02 |
|
 前 |
 次 |
Oracle Business Intelligenceは、ビジネス・ユーザーに組織の全体像を提供する統合ビジネス・インテリジェンス(BI)ソリューションです。Oracle Business Intelligenceは、迅速かつ簡単に様々なデータ・ソースを統合し、データベースの情報を検索し、データベース情報を共有して、企業およびその顧客に関する情報を得るためにデータを有効に利用することを目的として設計されています。
OracleのEnterprise Performance Management(EPM)システムは、モジュール方式のパフォーマンス管理アプリケーションのスイートと、包括的なビジネス・インテリジェンス機能をレポート作成および分析のために統合します。これにより、ユーザーの生産性は向上し、所有にかかる経費は抑えられ、ビジネス・リスクは低減します。
この章では、次の項目に関する高可用性について説明します。
この章は、Oracle Business IntelligenceおよびEPMを理解している読者を対象にしています。そうでない場合は、Oracle Business IntelligenceおよびEPMのドキュメントを参照してください。
この項では、Oracle Business Intelligence Enterprise Edition(Oracle BI EE)およびEnterprise Performance Management(EPM)の概要について説明します。また、この項では、Oracle BI EEおよびEPMのための高可用性環境の設計方法とデプロイ方法についても説明します。
Oracle BI EEは、包括的なエンタープライズBI機能の集合体であるOracle Business Intelligenceの一部です。Oracle Business Intelligenceは、インタラクティブ・ダッシュボード、完全にアドホックな事前対応インテリジェンスとアラート、エンタープライズおよび財務のレポート作成機能、リアルタイムの予測インテリジェンスなど、あらゆるBI機能を提供します。Oracle BI EEプラットフォームは、本当の次世代BI機能を提供する、実証済の最新型Webサービス指向アーキテクチャを基盤にしています。Oracle BI EEは、各種データを収集および編成してから編成データをユーザーに表示できる堅牢なアプリケーションで、ユーザーは、これらのデータを分析および解釈して、その結果に基づいて対処できます。Oracle BI EEに関するその他の概要は、『Oracle Fusion Middlewareユーザーズ・ガイドfor Oracle Business Intelligence Enterprise Edition』を参照してください。
Enterprise Performance Managementアプリケーションは、戦略、計画および実行をシームレスなプロセスに統合します。OracleのEPMアプリケーションは、Oracleのトランザクション・システムとOracle以外のトランザクション・システムの両方を統合する、モジュール方式の統合化アプリケーションのスイートです。各アプリケーションは高度な有用性を実現するために個別にデプロイすることもできますが、それらのアプリケーションを合せて使用すると、デプロイメントと所有に掛かる費用を抑えながら、戦略、財務および運用管理のプロセスを統合できるようになります。
この項の項目は次のとおりです。
図16-1では、単一インスタンス・アーキテクチャでのOracle BI EEコンポーネントを示しています。Javaコンポーネントとシステム・コンポーネント間のすべての通信は、HTTP経由のSOAPメッセージを介して行われます。
図16-1に示しているポート番号は、単一マシン上に各コンポーネント・タイプのコンポーネントが1つだけ配置された単純なインストール環境用のデフォルト・ポート番号です。Oracle Enterprise Manager Fusion Middleware Controlを使用してスケール・アウトするときには、ボート番号の範囲を選択できます。「システム・コンポーネントをスケーリングするためのFusion Middleware Controlの使用」を参照してください。
次のセクションでは、Oracle BI EEコンポーネントの特性について詳しく説明します。ここで説明する情報は、Oracle BI EEの高可用性の要件について詳しく理解するために役立ちます。
次に、Oracle BI EEシステム・コンポーネントの機能について概要を説明します。
Oracle BIプレゼンテーション・サービス(プレゼンテーション・サービス): これは、ユーザー・インタフェース・ページを生成し、Oracle BIスケジューラにかわって結果セットをレンダリングする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スケジューラの集合を管理するC++プロセスです。
Oracle Business Intelligence Scheduler(Oracle BIスケジューラ): これは、時刻が指定されたスケジュールに従ってジョブを実行するC++プロセスです。ジョブは、Oracle BIプレゼンテーション・カタログで作成されたエージェントの場合や、ジョブ・マネージャによって作成されたジョブの場合があります。
次に、Oracle BI EE Javaコンポーネントの機能について概要を説明します。
Oracle BIプレゼンテーション・サービスのプラグイン・サーブレット: プレゼンテーション・サービスは、Webサーバーとしてではなくプロセスとして実行するため、Webサーバー・プラグインAPIを使用して通信することはありません。Oracle BIプレゼンテーション・サービスのプラグインは、HTTPリクエストをPresentation Servicesに転送します。HTTPリクエストは、ブラウザ・ベースのユーザー・インタフェースからのリクエストまたはSOAPリクエストです。
Webサービス:
アクション実行サービス:プレゼンテーション・サービスとOracle BIスケジューラのかわりにアクションを実行します。アクションは、サード・パーティWebサービスのコールである場合や、EJBとして実行されるユーザー提供Javaコードのコールである場合があります。
アクション・レジストリWebサービス: アクションのリストを提供します。
アクション場所サービス: 間接レベルを提供することで、アクションを顧客のテスト環境で開発してから、すべてのアクション定義を本番ソースを指すように変更することなく、開発したアクションを本番環境にデプロイできます。
SOA用Webサービス:Oracle BIプレゼンテーション・カタログのコンテンツに対するWebサービス・インタフェースを提供します。Oracle BIプレゼンテーション・カタログ内のオブジェクトのツリーは、WSDLリーフを持つWSILツリーによって定義されたWebサービスのツリーとして公開されます。
セキュリティWebサービス: 標準に基づいた認証サービスと移入サービスを提供します。
OPMNは、各Oracle BI EEシステム・コンポーネントを制御します。開始および停止するには、Oracle Enterprise Manager Fusion Middleware ControlのOracle BI EE管理用ページを使用します。
各Oracle BI EEのJavaコンポーネントは、管理対象WebLogic Serverによってホストされ、管理コンソールを使用して制御されます。それぞれの管理対象WebLogic Serverは、ローカルのWebLogicノード・マネージャによって監視され、必要に応じて再起動されます。
|
注意: 名前付きユーザーを使用してOPMNプロセスを実行する場合は、Windows環境で共有ネットワーク・ファイルにアクセスできることを確認する方法に関する項を参照してください。 |
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サービスを使用します。
Oracle BI EEでは、次の3種類の構成方法が用意されています。
中央構成: Oracle Enterprise Manager Fusion Middleware ControlのBI EEページで行います。これらのページを使用して、追加のインスタンスをプロビジョニングして、高い可用性とスケーラビリティを提供できます。主要な構成値も中央で管理できるため、すべてのインスタンスに一貫した構成値を割り当てることができます。
ローカル・システム・コンポーネントの構成:ローカル構成が必要となるのは、詳細構成に変更を加える場合のみです。
ローカルJavaコンポーネントの構成:システム・コンポーネントの構成と同様に、ローカル構成は詳細オプションについてのみ必要です。
中央構成
Oracle BI EEでは、Enterprise Manager Fusion Middleware Controlで公開されている中央構成メカニズムが用意されています。
中央で管理される構成の対象は次のとおりです。
コンポーネント数の変更
リスニング・ポートの範囲。各コンポーネントによって使用されるポートは、この範囲から自動的に割り当てられます。
基本SSL構成: システムMBeanブラウザを使用して、BI EEコンポーネントに対してSSLを有効にできます。
メール・サーバー構成
プリンシパル・チューニング・オプション
共有ファイルの場所
詳細構成はローカルでできますが、そのためにはローカル構成ファイルを直接編集します。中央構成がコミットされると、中央構成によって設定された構成オプションのみがローカル・マシンに配信されます。
ローカル・システム・コンポーネントの構成
実行中の各システム・コンポーネントは、共有構成ファイルとコンポーネント固有構成ファイルの両方を参照します。共有構成ファイル(ClusterConfig.xmlなど)は次のディレクトリに配置されます。
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
一般に、Oracle BI EEはJavaアプリケーションをnostageモードでデプロイします。WebLogic Serverは.earファイルを展開して、それをプライベート一時ディレクトリに配置します。これに対する例外であるMapViewerには、事前に展開されたデプロイメント・ディレクトリでのみ実行できる構成要件があります。
すべての管理対象サーバー・アプリケーションは(Enterprise Manager Fusion Middleware Controlや中央構成アプリケーションなどの管理アプリケーションは除く)、個別に指定されたシステムにデプロイするのではなく、Oracle BI EEクラスタ全体にデプロイします。
Oracle BI EEシステム・コンポーネントがデプロイされるときのログ・ファイルの場所については、第16.1.1.1.5項「ログ・ファイルの場所」を参照してください。
表16-1には、Oracle BI EEシステム・コンポーネントのログ・ファイルを示しています。これらすべてのログ・ファイルは、Enterprise Manager Fusion Middleware Controlからアクセスできます。
表16-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スケジューラ |
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 |
この項では、Oracle BI EEを高可用性デプロイメントで使用する場合の概要について説明します。
Oracle BI EEの高可用性を確保するための要件
Oracle BI EEは、プロセス・レプリケーションと高可用性ストレージ(データベースと共有ファイル・システム)の組合せを通じて高可用性を実現します。
高可用性システムを実現するには、Oracle BI EEは次の外部サービスを必要とします。
フォルト・トレラントのHTTPロード・バランサ
高可用性の共有ファイル・システム
Oracle BIスケジューラおよびファクト表用の高可用性データベース
次のシステム・コンポーネントをレプリケートする必要があります(2つ以上のインスタンスを確保)。
プレゼンテーション・サービス
Cluster Controller
Oracle BIスケジューラ
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クラスタも必要です。
図16-2は、Oracle BI EEおよびEPMの高可用性デプロイメントを示しています。
図16-2では、ハードウェアのロード・バランサがハードウェアのリクエストを受信し、それらをWeb層のWEBHOST1またはWEBHOST2にルーティングしています。これらのホストにはOracle HTTP Serverがインストールされています。
Oracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。第3章「WebLogic Serverの高可用性」で説明されているように、APPHOST1が使用できなくなった場合、APPHOST2で管理サーバーをアクティブにできます。Oracle BI EE、Oracle EPMおよびOracle BI Publisher Javaコンポーネントは、これらのホストのBI_SERVER1およびBI_SERVER2管理対象サーバーにデプロイされます(Financial Reporting、Provider ServicesおよびWorkspaceはOracle EPMコンポーネントです)。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。サーバー移行全体は、管理対象サーバー用に構成されます。
BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシンに対するこれらのホスト名それぞれに、APPHOST1はVIP1、APPHOST2はVIP2というVIPマッピングを有効にして、このトポロジが使用するネットワーク・システム内の仮想ホスト名を(DNSサーバーまたはhosts解決で)正しく解決する必要があります。BIサーバーのサーバー移行を構成する方法の詳細は、第16.1.13.22項「BI_SERVERnサーバーのサーバー移行の構成」を参照してください。
Oracle BIプレゼンテーション・サービス、JavaHost、Oracle BI Cluster Controller、Oracle BIスケジューラおよびOracle BI Serverは、APPHOST1およびAPPHOST2にインストールされてクラスタとして構成されたシステム・コンポーネントです。APPHOST2上のCluster ControllerとSchedulerはパッシブであり(これらは起動されますがリクエストを処理しません)、APPHOST1のコンポーネントで障害が発生した場合にのみアクティブ化されます。
データ層では、カタログ、問合せキャッシュ、RPDおよびSchedulerのスクリプト・データを格納するために、共有外部記憶域が設定されます。Oracle RACデータベースは、BI EEスキーマ・メタデータとBI Publisherリポジトリ・データを格納するために使用され、エンタープライズ・データベース用としてもお薦めします。
次の各項では、いくつかのOracle BI EEコンポーネントの高可用性情報について説明します。
Oracle BIプレゼンテーション・サービス・プラグインは、ブラウザ・ユーザー・インタフェースなどのすべてのHTTPクライアントにとっての最初の通信先です。この前方には、Oracle HTTP Serverまたは他のサポートされているWebサーバーが配置されることがあります。シングル・ポイント障害を回避するために、このHTTPスタックをレプリケートする必要があります。ユーザーに複数のHTTP URLが表示されることを防ぐには、外部ロード・バランサをセットアップします。これにより、ユーザー・リクエストは、レプリケートされたOracle BI EE URLのいずれかにルーティングされます。
内部HTTPリクエストをローカルWebLogic管理対象サーバーに直接ルーティングすると、高可用性は低下します。WebLogicインスタンスで障害が発生した場合は、ノード・マネージャによってそのインスタンスが再起動されます。WebLogicの再起動には数分間かかることがあります。この間は、ローカル・セキュリティ・サービスは使用不能になり、ログインできなくなります。これとは対照的に推奨の構成では、内部HTTPリクエストはロード・バランサを介してルーティングされます。代替のセキュリティ・サービスはすぐに使用可能になります。
Oracle BIプレゼンテーション・サービス・プラグインは、分析.earアプリケーションとしてデプロイされます。それは、TCP経由のネイティブRPCプロトコルを使用して、セッション・リクエストをプレゼンテーション・サービス・インスタンスにルーティングします。また、セッションCookieまたはURL引数を通じて全般的にセッション・アフィニティを維持しながら、複数のプレゼンテーション・サービス・インスタンス間のロード・バランシングも実行します。プレゼンテーション・サービスとプラグインは個別のプロセスとして実行されます。
それぞれのOracle BIプレゼンテーション・サービス・プラグイン・インスタンスは完全に独立しており、Oracle BIプレゼンテーション・サービス・プラグイン・インスタンス間の通信は行われません。それぞれは、過去におけるレスポンス時間と未処理リクエスト数に基づいて、ロード・バランシングについて独自に判断します。
ロード・バランサ上でセッション・アフィニティを構成することをお薦めします。
Oracle BIプレゼンテーション・サービス・プラグインは、Oracle Business Intelligence Javaコンポーネントの1つであり、追加の管理対象サーバーをデプロイメントに追加する場合、高可用性のためのスケーラビリティを持っています。
プレゼンテーション・サービスは、Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブで定義されたポート範囲から割り当てられたポート上のOracle BIプレゼンテーション・サービス・プラグインからリクエストを受信します。初期ユーザー・セッション・リクエストは、クラスタ内の任意のプレゼンテーション・サービス・インスタンスに送信できますが、その後は各ユーザーは特定のプレゼンテーション・サービス・インスタンスにバインドされます。
ユーザー・リクエストの処理のために、プレゼンテーション・サービスはBI Serverと通信する必要があります。クラスタ環境では、BI Serverとの通信のためにはまずCluster Controllerと通信します。プレゼンテーション・サービスは、クラスタ環境用に構成されたOracle BI ODBCデータ・ソースを使用してプライマリCluster ControllerとセカンダリCluster Controllerを識別するとともに、これらがリスニングするポートを識別します。中央管理の構成が変更されたときには、中央に配置されたBIドメイン構成ファイルによって、ODBCデータ・ソース名(DSN)内の接続パラメータが自動的に構成されます。Oracle BI ODBC DSNの接続パラメータは、ローカルに変更しないでください。
Cluster Controllerは、プレゼンテーション・サービスが接続するOracle BI Serverインスタンスを割り当てます。Oracle BI Serverへの接続はODBCを介して確立され、同じセッション内の後続のリクエストは、プレゼンテーション・サービスから、割り当てられたOracle BI Serverに直接送信されます。プレゼンテーション・サービスとOracle BI Serverとの間のODBCセッションは、ステートフルであり、セッション存続時間の間、アフィニティを保持する必要があります。
Oracle BIスケジューラと通信するために、プレゼンテーション・サービスはまずCluster Controllerと通信し、それからアクティブなOracle BIスケジューラ・インスタンスにリレーします。その後、Presentation Servicesは該当するOracle BIスケジューラ・インスタンスとのセッションを確立します。Fusion Middleware Controlの「容量管理」ページの「可用性」タブで、ホストおよびOracleインスタンスの名前をCluster ControllerおよびOracle BIスケジューラに指定します。
Cluster Controllerは、プレゼンテーション・サービスなどのクライアントからの新しいBI ServerセッションやOracle BIスケジューラ・セッションにとって最初の通信先です。Cluster Controllerは、次のようにアクティブ/パッシブ構成でデプロイします。
プライマリCluster Controller: アクティブCluster Controllerです。
セカンダリCluster Controller: プライマリCluster Controllerが使用不能になった場合にアクティブCluster Controllerの役割を担います。
デフォルトでは、Oracle Business Intelligenceインストールで最初に構成したCluster ControllerがプライマリCluster Controllerになります。
Cluster Controllerは、Oracle BI Serverの可用性と負荷に基づいて、クラスタ内のどのOracle BI Serverが着信リクエストを受信するのかを決定します。また、Oracle BIスケジューラ・インスタンスなどのクラスタ内のサーバー処理の監視もします。
Cluster Controllerでサポートされているものは、次のとおりです。
サーバーおよびOracle BIスケジューラの障害の検出。
サーバーに障害が発生した場合のODBCクライアントに対するフェイルオーバー。
Cluster Controllerは、実行時にアクティブOracle BIスケジューラ・インスタンスも判別します。Cluster Controllerはプレゼンテーション・サービス・インスタンスを制御しないことに注意してください。
両方のCluster Controllerのどちらもがアクティブであると認識するスプリット・ブレイン構成を回避することが重要です。スプリット・ブレイン構成を回避するために、潜在的に信頼性が低いWANを介して接続された別々のLAN上でCluster Controllerを構成しないでください。サイト障害に対するフォルト・トレランスでは、クラスタ化メカニズムではなく障害時リカバリ・メカニズムを使用する必要があります。
複数のBI Serverをインストールして構成することで、BI Serverクラスタを作成できます。Cluster Controllerは、プレゼンテーション・サービスなどのクライアントからのリクエストをこのクラスタのアクティブ・メンバーにディスパッチします。BI Serverは、Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブで定義されたポート範囲から割り当てられたポート上でクライアント・リクエストをリスニングします。
|
注意: クラスタに参加している各サーバーのクロックを同期する必要があります。クロックが同期していないと、レポートで時間のずれが生じることがあります。 |
マスターBI Serverは、Oracle BI管理ツールがRPDファイル内でオンライン・メタデータ変更を加えるために接続するサーバーです。このメタデータ変更内容は、他のサーバーの再起動時にそれぞれのサーバーに伝播されます。管理ツールのクラスタ・マネージャを使用して、どのOracle BI Serverがマスターであるかを表示できます。
BI Serverからデータベースへの通信
BI Serverは、Oracle Databaseを含む多くのデータベース・タイプとの通信をサポートしています。BI Serverのデータ・リポジトリは、未加工のファクト表を保持します。Oracle BI EEはBI Serverデータ・リポジトリにメタデータを保管しません。すべてのメタデータは、RPDファイルまたは(プレゼンテーション・サービスの場合は)Oracle BIプレゼンテーション・カタログに保管されます。
Oracle BIスケジューラは、Oracle BIスケジューラ・スキーマにデータを保管します。Oracle BIスケジューラのデータベース接続構成では、BI Serverと同じライブラリが使用されるため、フォルト・トレランス特性は同じです。唯一の違いは、Oracle BIスケジューラの操作の方がはるかに書込みが多いことです。BI Serverのデータ・ソースは主に読取り専用です。
BI Serverのデータベース操作の主なポイントは次のとおりです。
ソース・データベース: ソース・データベースはOracle BI EEのレポート用に使用されます。これらは主に読取り専用です。ソース・データベースについては多くのオプションがサポートされています。
イベント・ポーリング: ファイル・システムからのキャッシュの削除や作成を常時チェックします。
使用状況トラッキング
ライト・バック機能: ユーザー主導型の機能です。
実装では次の特性が実現されます。
すべてのデータベース読取り/書込み操作はC++コードによって実行されます。
Oracle Databaseの場合は、OCIが使用されます。他のデータベースやデータ・ソースの場合は、ネイティブ・データベース機能が使用されます。
Oracle Databaseと非Oracle Databaseのサポートは、ソース・データベースについてだけでなく、Oracle BIスケジューラについても可能です。
管理ツールでは、Presentation Servicesが使用するのと同じOracle BI ODBC DSNを使用します。それは、Cluster ControllerによってマスターBI Serverに接続されます。マスターBI Serverが使用できない場合、管理ツールはRPDファイルへの書込みを実行できません。
Oracle BIスケジューラ・インスタンスは、アクティブ/パッシブ・モデルに基づいて動作します。どの時点でも、1つのOracle BIスケジューラのみがアクティブになってリクエストを処理することで、新しいジョブに一意のジョブIDが割り当てられることを保証します。非アクティブなOracle BIスケジューラ・インスタンスはアイドル状態を維持し、アクティブなOracle BIスケジューラで障害が発生した場合に引継ぎを要請されるまで、ジョブを処理しません。
インストールされた複数のOracle BIが同じスケジューラ表を使用するように構成しないでください。そのようにすると、アクティブなOracle BIスケジューラが複数存在することになり、一意のジョブIDという制約が破綻します。
Oracle BIスケジューラは、BI Serverと同じデータベース・テクノロジを使用します。
Oracle BIスケジューラは稼働しているが、データベースが停止している場合、失敗したトランザクションはOracle BIスケジューラによってそのメモリー内のキューに格納され、正常に処理されるまで再試行されます。したがって、バックエンド・データベース・ソースをメンテナンスのために停止した場合、そのデータベースの再起動時にOracle BI EEのプロセスを再起動する必要はありません。このプロセスは、Oracle BIスケジューラでの定期的パージと同じカウントで再試行されるため、同じ構成値を使用します。Oracle BI EEは、Oracle BI EEのメタデータに含まれている必要のある文のみを再試行します。Oracle BI EEは、問合せを再試行せずに、挿入と削除のみを再試行します(再実行される削除は除く)。構成値は、Oracle BIスケジューラのinstanceconfig.xmlファイルにあります(PurgeIntervalMinutes)。
Oracle BIスケジューラは、Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブで定義されたポート範囲から割り当てられたポート上で、Cluster Controller通信およびクライアント・リクエストをリスニングします。
Oracle BI JavaHostコンポーネントは、Oracle BIプレゼンテーション・サービスが、Oracle BIスケジューラ、Oracle BI Publisherおよびグラフ生成のためのJavaタスクなど様々なコンポーネントをサポートできるようにするサービスを提供します。他のすべてのコンポーネントと同様に、管理者はFusion Middleware Controlを使用して、デプロイされるインスタンス数と場所を制御できます。JavaHostクライアントのデフォルト構成では、すべての使用可能なJavaHostが使用されます。これは、ローカルJavaHostのみを使用する以前の10gのデフォルト構成とは異なります。
JavaHostサービスは、Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブで定義されたポート範囲から割り当てられたポート上のプレゼンテーション・サービスおよびOracle BIスケジューラからリクエストを受信します。
Oracle BI EEでは、プロセスの状態は、分散通信プロトコルを介してではなく、共有ファイル・システムとデータベースを介して共有されます。特に、Oracle BI EEは、プロセス内やJavaコンポーネント内の状態を保管しません。したがってOracle BI EEは、コンポーネントの状態をシリアライズして、Javaクラスタ内で配信できるようにする必要はありません。
ファクト表とOracle BIスケジューラの表は、それぞれBI Serverインスタンス間とOracle BIスケジューラ・インスタンス間で共有されます。ファイル・システムの共有はあまり標準的ではないため、これについてはこの項の後半で説明します。NASやSANなどの共有ストレージ・デバイスを使用できます。
クラスタ内のプレゼンテーション・サービス・インスタンスは、共通のOracle BIプレゼンテーション・カタログを共有します。Oracle BIプレゼンテーション・カタログは、共有されたNASデバイスまたはSANデバイスに配置されている必要があります。プレゼンテーション・サービスのすべてのインスタンスは、この共有デバイスに対する読取りと書込みのアクセス権を持っている必要があります。同時アクセスは、ファイル・システムのロック・セマンティックによって管理されます。
Oracle BIプレゼンテーション・カタログは、頻繁にアクセスされる多数の小さいファイルで構成されているため、場合によっては、ファイル数が共有ファイル・システムのファイル制限を超えることに注意してください。システムのファイル制限の設定については、お使いの共有ファイル・システムのドキュメントを参照してください。
クラスタに参加しているすべてのBI Serverが、リポジトリ公開ディレクトリを共有し、それによってオンライン・モードで編集されるリポジトリのマスター・コピーが保持されます。マスターBI Serverには、このディレクトリに対する読取り権限および書込み権限が付与されている必要があります。その他のすべてのBI Serverには、読取り権限が付与されている必要があります。
クラスタ化されたBI Serverは、起動時にこのディレクトリを調べて、リポジトリの変更の有無を確認します。起動時に、BI Serverインスタンスは、公開ディレクトリ内のリポジトリをたとえば次のようなローカル・リポジトリ・ディレクトリにコピーします。
ORACLE_INSTANCE/bifoundation/OracleBIServerComponent/coreapplication_obis1/repository
このコピーは再起動時にしか実行されないため、すべてのBI Serverインスタンスが再起動されるまでは、書込み可能なrpdファイルを含むクラスタでは一貫性のない動作が発生することがあります(メタデータが分析からのリクエストに一致しないなど)。メタデータの変更は、本番環境の読取り専用rpdファイルを使用して、通常は開発環境でオフラインで行われます。
Fusion Middleware Controlでは「デプロイメント」ページにある「リポジトリ」タブの「共有場所」パラメータで、リポジトリ公開ディレクトリの場所を指定します。
グローバル・キャッシュは、クラスタに参加しているすべての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システム管理者ガイド』を参照してください。
Oracle BIスケジューラ・スクリプトのネットワーク共有を作成する必要があります。ネットワーク共有を作成するには、Oracle BIスケジューラのinstanceconfig.xmlファイルのSchedulerScriptPath要素およびDefaultScriptPath要素を更新します(このファイルは、ORACLE_INSTANCE/config/OracleBISchedulerComponent/coreapplication_obischnにあります)。Oracle BIスケジューラ・サーバーは、この共有に対する読取りと書込みのアクセス権を持っている必要があります。
プロセス間には依存関係が存在するため、特定の順序でクラスタを起動する必要があります。起動手順は次のとおりです。
すべてのWebLogic管理対象サーバーを起動します。システム・コンポーネントは、それぞれのローカル管理対象サーバーから認証サービスを受けます。
Fusion Middleware Controlの「すべて起動」ボタンを使用して他のプロセスを起動します。「すべて起動」ボタンを使用すると、Javaアプリケーションおよびシステム・コンポーネントが確実に適切な起動順序で起動されます。
構成の変更は高可用性にとって非常に重要であり、その中でもクラスタのメンバーに対する変更は特に重要です。クラスタに新しいメンバーを追加できないと、障害を修復できず、クラスタはその後の障害に対して脆弱になります(このため、高可用性システムでは平均修復時間は平均故障間隔と同じくらい重要です)。
Javaとシステムという2つのテクノロジ・スタックは別々に管理されます。
WebLogicの構成変更は、WebLogic管理コンソールで行います。標準のWebLogicメカニズムを使用して、変更中の構成をロックして、変更内容をすべての管理対象サーバーに伝播します。
システム・コンポーネントの構成変更は、Fusion Middleware Controlを使用して中央で行います。構成の変更を入力したら、「保存」をクリックして、構成の変更内容をすべてのローカルの構成ファイルに伝播します。この伝播は重要です。構成が破損していたり伝播に失敗した場合は、次の伝播によってローカル・ファイルが修正されます。Oracle JMX拡張機能によって、WebLogic構成ファイルの配布と同じようにファイル配布が実行されます。リモート・サイトでの配信は、JMX MBeanコールによって通知されます。MBeanはMBeanサーバーでホストされる必要があるため、これは、Oracle BI EEシステム・コンポーネントをホストしているすべてのマシンは、どのようなOracle BI EE Javaコンポーネントもホストしていない場合でも、WebLogic管理対象サーバーも備えている必要があることを意味します。
すべてのコンポーネントは、そのコンポーネントが次回に再起動されたときに初めて構成変更にアクセスします。コンポーネントの稼働中に構成変更は適用されません。
構成変更は次の場合にトリガーされます。
Fusion Middleware Controlで加えられた変更を管理者がコミットした場合。
MBean API(このAPIにはFusion Middleware Controlのユーザー・インタフェースが直接反映されます)によって加えられた変更を管理者がコミットした場合。
新しいインストールを登録するエンタープライズ・インストールによって構成の配信はトリガーされません。これによって、管理者がFusion Middleware Controlから選択できるマシンの集合が変更されます。新しいコンポーネント・インスタンスは構成に自動的に追加されません。
この項では、発生する可能性のある様々な種類の障害と、各種類の障害が発生したときに予想される動作について説明します。
マシンで一時的な障害が発生した場合、クラスタは再起動されたコンポーネントを検知して、それらのコンポーネントを再び使用し始めます。マシンの障害が永続的ならば、そのマシンは交換する必要があります。既存のクラスタを拡張するには、エンタープライズ・インストールを使用して、新しいマシンにOracle BI EEをインストールします。
Oracle BI EEマシンの障害からのリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の別のホストへのOracle BI EEのリカバリに関する項を参照してください。
WebLogic管理サーバーはシングルトンであるため、同時に複数のインスタンスを稼働させることはできません。WebLogic管理サーバーの保護の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。Oracle BI EEでは、WebLogic管理サーバーは管理タスクにのみ使用されます。
WebLogic管理サーバーが停止していると、Oracle BI EEを再構成することも、Fusion Middleware Controlを使用してログ・ファイルを参照することもできません。
WebLogicノード・マネージャは、管理対象サーバーの障害を検知します。すべてのJavaコンポーネントはステートレスであるため、Oracle BI EEは、Javaクラスタの状態のメンテナンスについては考慮に入れていません。
システム・コンポーネントから管理対象サーバーへのすべての通信(Presentation Servicesからアクション・サービスへの通信など)では、ローカル管理対象サーバーへのHTTPを使用します。ローカル管理対象サーバーで障害が発生した場合は、ノード・マネージャによってそれが再起動されます。
管理対象サーバーが再起動できないときに、マシンに障害がない場合、同一のマシン上で実行しているシステム・コンポーネントには、次のような影響があります。
BI Server: ローカル管理対象サーバーが正常に稼働するまでサービスを停止し、これにより、BI Serverを介したログインが影響を受けることが防止されます。ローカル管理対象サーバーが稼働していないことをBI Serverが検知すると、ログイン・リクエストを他のBI Serverに送信するようにCluster Controllerに指示します。
プレゼンテーション・サービス: アクションを実行できません。
Oracle BIスケジューラ: アクティブ・スケジューラがこのマシン上で実行されている場合、スケジュール済アクションを実行できません。
新しいScheduler接続(ジョブ・マネージャなどから)を確立できません。ローカルの管理対象サーバーを実行していないホスト上のOracle BIスケジューラは、新しいユーザーを認証できません。
管理対象サーバーをオフラインにする必要がある場合は、最初に、そのマシン上で実行しているすべてのシステム・コンポーネントを停止します。特定のマシン上の管理対象サーバーが使用できなくなる場合は、そのマシン上で実行しているすべてのシステム・コンポーネントを停止します。
Cluster Controllerは、Oracle BIスケジューラを監視および管理します。Oracle BIスケジューラが使用不能な場合は、Cluster Controllerは、次にアクティブ化するOracle BIスケジューラ・インスタンスを決定します。元のプライマリOracle BIスケジューラが再び使用可能になった場合でも、そのOracle BIスケジューラにプライマリ・ロールが戻されることはありません。
アクティブなOracle BIスケジューラで障害が発生したときに、確立済のクライアント接続がエラーを受信することはありません。これは、Oracle BIスケジューラ・プロトコルがステートレスであり、シームレスにフェイルオーバーするからです。
エージェント: エージェントの実行ではOracle BIスケジューラの表に状態が保持されます。次のOracle BIスケジューラ・インスタンスがアクティブになると、このインスタンスは、実行途中であったすべてのジョブ・インスタンスの状態を読み取って、これらのインスタンスを実行します。スケジュール済エージェントは、アクティブなインスタンスの障害発生前に配信されなかった受信者に対してのみ配信します。
正常に行われた配信は、配信の完了後にOracle BIスケジューラ表に記録されます。配信は完了したがその事実が記録される前にOracle BIスケジューラがフェイルオーバーした場合、配信が繰り返されます。このため、繰返しの配信が数回実行されることがあります。
エージェントのフェイルオーバーは、スケジュール済のエージェントについてのみサポートされます。たとえば、Answersのツールバーで「エージェントを今すぐ実行」をクリックした後に、プライマリOracle BIスケジューラで障害が発生した場合は、そのエージェントはセカンダリScheduler上で引き続き実行されることはなく、エラー・メッセージが「今すぐ実行」結果ダイアログ・ボックスに表示されます。
Java、コマンドラインまたはスクリプトのジョブ: これらのジョブは、新しいジョブ・インスタンスを使用して最初から再実行されます。
|
注意: すべてのジョブ・インスタンスは、ジョブ・マネージャから手動で再実行できます。エージェントについては、正常に配信されなかったユーザーに対してのみ配信されます。たとえば、エージェントの実行途中でメール・サーバーが停止した場合、そのインスタンスの再実行では、メール・サーバーの障害が原因で電子メールを受信できなかった受信者に対してのみ配信されます。 |
Cluster Controllerは、BI ServerまたはOracle BIスケジューラの障害の検知と、障害が発生したサーバーのクライアントのフェイルオーバーをサポートします。
Cluster Controllerは、アクティブ/パッシブのモデルに基づいて動作します。すべてのクライアントは、まずプライマリCluster Controllerへの接続を試行します。プライマリCluster Controllerが使用不能な場合は、クライアントはセカンダリCluster Controllerに接続します。セカンダリCluster Controllerは、負荷と可用性に基づいてリクエストをBI Serverに転送するとともに、アクティブなOracle BIスケジューラ・インスタンスにも転送します。プライマリが後で使用可能になった場合は、すべてのリクエストはプライマリに再び転送されます。
セカンダリCluster Controllerは、各BI Server上のセッション・カウントを監視しますが(プライマリと同様に)、プライマリCluster Controllerが停止している場合を除いて、どのOracle BIスケジューラがアクティブ・スケジューラであるかを決定しません。
プライマリとセカンダリのCluster Controllerは相互のライフ・サイクルを監視します。Cluster Controllerインスタンス間では通信不能になっているが、各インスタンスは稼働しており他のクライアントと通信できる場合は、スプリット・ブレイン障害が発生する可能性があります。このような場合は、BI Serverは影響を受けませんが、Oracle BIスケジューラの2つのインスタンスが同時にアクティブになる可能性があります。まれに、この状況が原因となって、ジョブが二重に実行される場合があります。通信が回復すると、プライマリCluster Controllerは、1つのOracle BIスケジューラのみがアクティブになる必要があることをクラスタに指示します。クラスタ・コンポーネントは同一のLAN上に配置して、スプリット・ブレイン障害の可能性を最小限に抑える必要があります。
両方のCluster Controllerが使用不能な場合は、プレゼンテーション・サービスは、ログインしようとするすべての新しいユーザーにエラーを返します。既存のセッションは影響を受けません。
Cluster Controllerは、各BI Serverインスタンス上のアクティブ・セッションの数を常時監視しています。新しいODBC接続が確立されると、Cluster Controllerは新しいセッションを割り当てることで、BI Server当たりのセッション数の均衡を保ちます。BI Serverインスタンスが一時的に停止してから回復した場合は、このインスタンスのセッション・カウントがクラスタ内の他のインスタンスのセッション・カウントと等しくなるまでは、すべての新しいODBCセッションはこのノードにルーティングされます。
Cluster Controllerで障害が発生すると、新しいセッションを最初に作成しようとしたユーザーに対しては、セカンダリCluster Controllerがそのセッションを開始するために約6秒間の遅延が生じます。それ以降は、他のすべての接続はセカンダリCluster Controllerにルーティングされます。
プレゼンテーション・サービスの障害は次に影響を与えます。
Webクライアント: 初期ユーザー・セッション・リクエストは、任意のプレゼンテーション・サービス・インスタンスに送信できますが、その後は各ユーザーは特定のプレゼンテーション・サービス・インスタンスにバインドされます。そのプレゼンテーション・サービス・インスタンスが失われると、セッションが切断されて、ブラウザにエラーが返されます。サーバーが使用不能になったときに進行途中であった作業のうち、ディスクに保存されていなかったものの内容はすべて失われます。ユーザーは再びログインして、使用可能なプレゼンテーション・サービス・インスタンスに対する新しい接続を確立する必要があります。ユーザーのログインがOracle Single Sign-Onなどのシングル・サインオン・システムを使用して行われている場合は、この再ログインは自動的に実行されます。新しいプレゼンテーション・サービス・セッションによって新しいBI Serverセッションが作成されます。
|
注意: プレゼンテーション・サービス・インスタンスで障害が発生すると、少し間隔を置いてから、システムによってそのインスタンスで障害が発生したことが検知されて、ユーザーが新しいプレゼンテーション・サービス・インスタンスに移行されます。シングル・サインオン・ソリューションが使用されている場合は、ユーザーは再認証する必要はありません。シングル・サインオンが使用されていない場合は、ユーザーは再認証する必要があります。 |
エージェント: Oracle BIスケジューラにエラーが転送されます。Oracle BIスケジューラは障害をログに記録してから、ジョブを再試行します。この再試行によって、使用可能なプレゼンテーション・サービスに対する新しい接続が確立されます。
BI Serverで障害が発生すると、ODBCエラーが適切なクライアントに送信されます。
Presentation Services: 各Webユーザーのリクエストは、単一のBI Serverによって処理されます。BI Serverが使用不可能な場合、ユーザーにはエラーが表示されます。ただし、ブラウザを更新することで、使用可能なBI Serverとの新しいセッションが確立されます。この調停は、そのユーザーのかわりプレゼンテーション・サービス・コンポーネントが実行することに注意してください。
管理ツール: 管理ツールは、その接続先であるBI Serverが使用不能になると、ODBCエラーを転送してから接続を切断します。管理者は、管理ツールを使用して再接続する必要があります。
エージェント: BI Serverで障害が発生すると、Oracle BIスケジューラにエラーが転送されます。Oracle BIスケジューラは障害をログに記録してから、ジョブを再試行します。その後で、使用可能なBI Serverとの接続が確立されます。
サード・パーティ・クライアント: サード・パーティ・クライアントはODBCを使用してBI Serverに接続します。BI Serverで障害が発生すると、ODBCによってエラーが転送され、ODBC標準に従ってセッションが切断されてから再確立されます。
マスターBI Serverの障害: マスターBI Serverが使用不能である場合、オンライン・メタデータの変更は実行できません。これは管理操作であり、ランタイムの可用性には影響がありません。
マスターBI Serverが永続的に使用不能になった場合は、他のサーバーのいずれかを新しいマスターとして指定する必要があります。
Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブを使用して、マスターBI Serverをスケール・インします。
Oracle BI EEシステム・コンポーネントを再起動します。
システムによって、新しいマスターBI Serverが割り当てられます。
一般にリカバリの問題は、プロセスの起動失敗に関係しています。推奨されるトラブルシューティング手順は次のとおりです。
Fusion Middleware Controlをチェックして、どのプロセスが実行されているか確認します。これにはOPMNによって報告される状態が反映されます。
OPMNログ・ファイルをチェックします。これらは、Fusion Middleware Controlからアクセスできます。これらは、表16-1で明示している場所でもアクセスできます。
正常に実行されなかったプロセスを特定したら、そのログ・ファイルをチェックしてください。このログ・ファイルには、Fusion Middleware Controlから、または表16-1で明示している場所でアクセスできます。
特定のプロセスは、そのピアと通信できない場合に停止されます。この問題を診断する手順は次のとおりです。
正常に実行されなかったプロセスを特定します。ログ・ファイルで低レベル・ソケット・エラーを探します。これによりポートとサーバー・アドレスが特定されます。ローカル構成ファイルを調べて、そのポートをリスニングするように構成されたプロセスを確認します。単純なデプロイメントでは、第16.1.2.1項「Oracle BI EEの高可用性アーキテクチャ」のコンポーネントに関する説明で示されているように、デフォルトのポート割当てが使用されます。現在構成されているポートは、Fusion Middleware Controlの「容量管理」ページの「可用性」タブで確認できます。
ピアが動作しているかどうか確認します。ピアが動作している場合は、そのログ・ファイルをチェックして、通信を拒否するエントリがないか確認します。通信が拒否される可能性があるのは、SSL構成が矛盾している場合やプロトコル障害が発生している場合です。
Cluster Controllerの管理対象プロセスの構成がCluster Controllerと一致していない場合は、これらのプロセスは正常に実行されません。一部のフェイルオーバー・イベントはログに記録されませんが、Cluster Controllerのログ・ファイルには、すべてのOracle BIスケジューラ・インスタンスまたはBI Serverインスタンスの障害が記録されます。
初回の起動後にログ・ファイルを確認してください。BI ServerまたはOracle BIスケジューラのインスタンスが、Cluster Controllerによる仕様どおりに正しく構成されていない場合は、そのインスタンスは、停止されない可能性がありますが、クラスタには追加されません。ログ・ファイルにはこのようなエラーが記録されます。
図16-3は、Oracle Essbaseの単一インスタンス・アーキテクチャを示しています。
Essbaseコンポーネントのアーキテクチャは、次の4つの層で構成されています。
Web: Oracle HTTP Server。
アプリケーション: Oracle Hyperion Provider Services。これは、WebLogicアプリケーション・サーバーにデプロイされた中間層エンタープライズ・アプリケーションです。
Provider Servicesは、TCP/IPを使用してEssbaseエージェントおよびEssbaseサーバーと通信します。
Essbaseサービス: Essbase Analytical Services。これは、OPMN、EssbaseエージェントおよびEssbaseアプリケーション・サーバーで構成されます。
OPMNは、Oracle Net Servicesを使用してEssbaseエージェントと通信します。Essbaseエージェントは、クライアントとEssbaseアプリケーション・サーバー間のコーディネータとして機能します。Essbaseエージェントには、そのサーバーとのパイプ通信チャネルがあります。また、TCP/IPを使用した通信も行います。
記憶域: Hyperion Registry。これは、構成情報を格納するリレーショナル・データベース内のリポジトリです。EssbaseエージェントとEssbaseアプリケーション・サーバーは、バックエンド・データベースとの通信にJDBCまたはODBCを使用します。
Oracle Essbaseセッションの状態は、メモリー内に保持され、セッション・フェイルオーバーはありません。クライアント・セッションが失われたときには、そのクライアントは再度ログオンする必要があります。
Essbase Analytical Servicesは、ランタイムに次のプロセスで構成されます。
Oracle Process Manager and Notification Server(OPMN): Oracle Fusion Middlewareコンポーネント(Essbaseなど)を監視するデーモン。
OPMN管理コンポーネントは、opmn.xmlで指定されます。
Essbaseエージェントの起動、停止、再起動および監視には、OPMNのコマンドライン・インタフェースを使用します。第16.1.1.1.1項「プロセスのライフサイクル」を参照してください。Essbaseアプリケーション・サーバー・プロセスを直接開始または停止することはありません。OPMNは、Oracle Net Servicesを使用してEssbaseエージェントと通信します。
Essbaseエージェント(ESSBASE): アプリケーションに対するユーザーのリクエストをコーディネイトする役割を果たすプロセス。
Essbaseエージェントは、OPMNによって直接管理されます。Essbaseエージェントは、アプリケーション・サーバーを管理します。
Essbase Application Server(ESSSVR): すべてのデータ記憶域、キャッシュ操作、計算およびデータ・セキュリティを処理するEssbase Application Serverプロセス。
OPMNコマンドのopmnctlを使用して、Essbaseエージェントの起動、停止および監視を実行します。
起動
OPMNと、そのOPMNの管理対象コンポーネントをすべて起動するには、$ORACLE_INSTANCE/bin/opmnctl startallを使用します。
OPMNを実行している状態でEssbaseエージェントのみを起動するには、$ORACLE_INSTANCE/bin/opmnctl startproc ias-component=essbaseserver1を使用します。essbaseserver1は、opmn.xmlで指定された管理対象Essbaseインスタンスの名前になります。
停止
OPMNと、そのOPMNの管理対象コンポーネントをすべて停止するには、$ORACLE_INSTANCE/bin/opmnctl stopallを使用します。
Essbaseがフェイルオーバー・クラスタ・モードで構成されていて、OPMNを実行している状態で、Essbaseエージェントのみを停止するには、$ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=essbaseserver1 process-type=Essbaseを使用します。essbaseserver1は、opmn.xmlで指定された管理対象Oracle Essbaseインスタンスの名前になります。
監視
管理対象プロセスのステータス情報を取得するには、$ORACLE_INSTANCE/bin/opmnctl statusを使用します。
Essbaseとの通信には、クラスタ名(Provider Servicesによって解決されます)、URL(アプリケーションによって解決されます)、または物理的なホストおよびポートを使用できます。
Essbaseは、データベース・リポジトリであるHyperion Registryを使用して、構成情報を格納および取得します。
Essbaseは、Oracle Internet Directory(OID)などの外部ディレクトリ・サービスと連動するように構成できます。Essbaseは、LDAPプロトコルを使用してOIDと通信します。
デプロイメント・アーティファクトは、JDBCおよびODBC、reg.properties、セキュリティ・アーティファクトなどを含むEssbaseを適切に設定するために必要になります。デプロイメント・アーティファクトは、EssbaseをプロビジョニングするOPMNに渡す必要があります。
診断ログ・ファイルは、デフォルトでは、$ORACLE_INSTANCE/diagnostics内に配置されます。
Essbaseエージェントは、メッセージをEssbase.logに書き込みます。
デフォルトの場所: $ORACLE_INSTANCE/diagnostics/logs/Essbase/<Essbaseインスタンスの名前>/essbase
構成される場所: $HYPERION_LOGHOME/essbase
Essbaseアプリケーション・サーバーは、メッセージをアプリケーション・サーバーのログ・ファイルに書き込みます。
デフォルトの場所: $ORACLE_INSTANCE/diagnostics/logs/Essbase/<Essbaseインスタンスの名前>
構成される場所: $HYPERION_LOGHOME/essbase/app
OPMNは、Essbaseコンソール・ログを作成します。このログは、デフォルトでは、$ORACLE_INSTANCE/diagnostics/logs/Essbase/<Essbaseインスタンスの名前>内にあります。
Essbase転送PingログEssbasePing.logは、デフォルトでは、$ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn内にあります。
リース管理ログは、フェイルオーバー構成でのみ作成されます(第16.1.4.2項「障害からの保護および予想される動作」を参照してください)。EssbaseエージェントとEssbaseサーバー内のリース管理モジュールは、それぞれに固有のログにメッセージを書き込みます。
デフォルトの場所: $ORACLE_INSTANCE/diagnostics/logs/Essbase/<iasコンポーネント名>/essbase
構成される場所: $HYPERION_LOGHOME/essbase
この項では、Essbaseを高可用性環境で使用する場合の概要について説明します。
図16-2は、Oracle BI EEの高可用性デプロイメントにおけるEssbaseを示しています。
ARBORPATH(構成ファイル、セキュリティ・ファイル、およびすべてのアプリケーションとそれに対応するデータベースを含む)は、共有ディスクに配置されています。インスタンス固有のファイル、バイナリおよびログ・ファイルは、デフォルトではローカル・ディスクに配置されますが、共有することもできます。たとえば、opmn.xmlの構成設定を変更して、ログ・ファイルを共有ディスクに配置できます。
フェイルオーバーに向けて、2ノード・クラスタでEssbaseを構成できます。
フェイルオーバー・クラスタの設定に含まれる項目は、次のとおりです。
2つのノード
常に一方のノードがアクティブであり、もう一方はパッシブになります。
ノード間の共有ディスク
共有ディスクには、アプリケーション、データベース、製品構成、および$ARBORPATH以下に配置されるすべてのものを格納します。
$ESSBASEPATH内の製品のバイナリなど
各ノードは直接接続されたストレージ・ディスクにバイナリを保持できます。
レジストリ・データベースおよびリース・データベース
これらの必須データベースは、冗長ストレージ・デバイスに配置する必要があります。
リース・メカニズムは、唯一のEssbaseエージェントと、そのエージェントのアプリケーション・サーバーのセットのみがアクティブになることを保証します。常に、1つのリソースに対して必ず唯一のリースがアクティブになります。アクティブなリースの所有者は、そのリソースに対する所有権を持ちます。このリース・スキームは、データベース内のリース表を使用することで実装されます。リース表は、Repository Configuration Utility(RCU)によってシードされます。
フェイルオーバーの機能を利用するには、Java APIクライアントはAPSサーブレットのエンドポイントURLを使用してログオンする必要があります。このURLはフェイルオーバー・クラスタのクラスタ名を指定することになります(例: http://WEBHOST1:7777/aps/Essbase?clusterName=cludemo)。
Provider Servicesは、クラスタ名をクラスタ内でアクティブなノードのホスト名とポートに解決します。
セッションのフェイルオーバーはサポートされません。サービスのフェイルオーバーが発生すると、クライアントはエラーメッセージを受信します。そのクライアントは、再度ログオンする必要があります。
この項では、高可用性環境でのEssbaseのクラスタリングの設定方法について説明します。
単一EssbaseエージェントのローカルARBORPATHの内容を共有ARBORPATHにコピーします。
プロビジョニング・フレームワークにより、1つのEssbaseエージェント(essbaseserver1)が自動的に作成され、ARBORPATHが/u02/local/oracle/config/BIInstance/Essbase/essbaseserver1を指すよう設定されます。ローカルARBORPATHの下には3つのディレクトリがあり、これらのディレクトリを共有ARBORPATHの場所にコピーする必要があります。
$ ls /u02/local/oracle/config/BIInstance/Essbase/essbaseserver1 app bin java
共有ARBORPATHを構成する手順は次のとおりです。
Fusion Middleware Controlにログインします。
「Farm_BIDomain」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックしてから、「可用性」の次に「フェイルオーバー」をクリックします。
「構成をロックして編集」をクリックして、「可用性」タブの「Essbaseエージェント」セクションをアクティブ化します。
Essbaseエージェントの「共有フォルダ・パス」を指定します。
指定しておかない場合は、ローカルのOracleインスタンス・ホームの下にある構成フォルダを共有場所にアップロードします。
「適用」をクリックしてから、「変更のアクティブ化」をクリックします。
高可用性を実現するために、Essbaseエージェントのセカンダリ・インスタンスを構成して分散させる手順は次のとおりです。
Fusion Middleware Controlにログインします。
「Farm_BIDomain」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックしてから、「可用性」の次に「フェイルオーバー」をクリックします。
「構成をロックして編集」をクリックして、「可用性」タブの「Essbaseエージェント」セクションをアクティブ化します。
Essbaseエージェントの「セカンダリ・ホスト / インスタンス」を指定します。「適用」をクリックします。
「潜在的単一点障害」で、Essbaseエージェントに対して「問題はありません」と報告されている必要があります。
「変更のアクティブ化」をクリックします。
「システムの管理」の下の「再起動」をクリックしてから、「はい」をクリックします。
Oracle Hyperion Provider Services(Provider Services)は、中間層データ・ソース・プロバイダです。これは、Oracle Essbase for Java API、Oracle Hyperion Smart View for Office、Fusion EditionおよびXMLAの各クライアントと、Oracle Business Intelligence Enterprise Editionを対象にしています。Provider Servicesは、高度同時並列分析シナリオをサポートし、Web対応のエンタープライズ分散環境にスケーラビリティと信頼性を提供します。
図16-4は、Provider Servicesの単一インスタンス・アーキテクチャを示しています。
Provider Servicesには、Essbase Java API、SmartViewプロバイダ、およびXMLA(XML for Analysis)プロバイダという3つのサブコンポーネントが含まれています。これらのサブコンポーネントは、それぞれJava APIクライアント、SmartViewクライアントおよびXMLAクライアントにサービスを提供します。Provider Servicesは、サブコンポーネントごとに異なる3つのサーブレットに合せて設計されています。
これらのクライアントとProvider Services間の通信には、HTTP(S)プロトコルを使用します。JAPIクライアントとXMLAクライアントは、Essbase通信用に設計されています。Smart Viewクライアントを使用すると、ユーザーはEssbase、Oracle Hyperion Planning、Fusion EditionやOracle BI EEサーバーなどのデータ・ソースに接続できます。
次の項では、Prover Servicesコンポーネントの特性について説明します。
Provider Servicesは、WebLogicサーバーのアプリケーション・コンテナにデプロイされたJavaベースのエンタープライズ・アプリケーションです。実行時には、単一のJavaプロセスが存在し、これがコンテナになります。Provider Servicesは、その他の外部プロセスを実行しません。
Provider Servicesプロセスのライフサイクルは、WebLogicサーバーにデプロイされた標準のJavaベースのエンタープライズ・アプリケーションのライフサイクルと同じです。
Oracle HTTP Web Serverなどのディスパッチャは、ゲートウェイとして機能し、リクエストをクラスタの一部であるProvider Servicesインスタンスに配信します。Provider Servicesは、スティッキー・セッションをサポートしています。そのため、Provider Servicesインスタンスとのユーザー・セッションを確立すると、ユーザーが切断するまで、同一のインスタンスがクライアントからの後続のリクエストをすべて処理します。Provider Servicesインスタンスに障害が発生したときには、ユーザーは既存の無効なセッションを切断してから、失敗したセッションと同じURL(ディスパッチャURL)を使用して再度ログオンする必要があります。
Provider Servicesは、Hyperion Registryに依存します。SmartViewプロバイダ・コンポーネントは、Registry Java APIを使用して、データ・ソース(datasources.xml)とSmart Slicesをレジストリ・データベースに格納します。また、Essbase Java APIコンポーネントは、ドメイン関連(domain.dbファイル)情報を保持するためにHyperion Registryを使用します。この情報のすべては、Provider ServicesのRegistryのLOGICAL_WEB_APPコンポーネントに格納されます。
Provider Servicesは、構成ファイルessbase.propertiesを保持します。このファイルは、$ORACLE_HOME/products/Essbase/aps/binに配置されています。Provider Servicesの起動スクリプトには、次のESS_ES_HOMEのJVM設定が必要です。この設定によって、起動スクリプトは実行時に構成ファイルを識別できるようになります。この設定では、PROVIDER_SERVICES_HOMEフォルダを指定します。このフォルダにbin/essbase.propertiesファイルが配置されています。
Provider Servicesのデプロイメント・アーティファクトに含まれるファイルは、次のとおりです。
logging.xml: Provider Servicesのログを管理するための構成ファイル
essbase.properties: Provider Services構成ファイル
aps.ear: Provider Servicesエンタープライズ・アプリケーション・アーカイブ
Provider Servicesのロギングは、ODLログ出力に基づいています。Provider Services起動スクリプトには、次のロギングに関連するJVM設定が必要です。
oracle.core.ojdl.logging.config.file: Provider ServicesのODL logging.xmlファイル・パスを指定します。
logging.folder: Provider Servicesサーバー・ログ・ファイルを格納する場所です。
|
注意: クラスタ内に複数のProvider Servicesインスタンスがある場合は、それぞれのインスタンスに対して固有のログの場所が定義されています。インスタンスの場所がProvider Servicesのホーム内にある場合、管理者はすべてのProvider Servicesインスタンスに対して、そのフォルダへの読取り権限と書込み権限を付与する必要があります。 |
Provider Servicesは、WebLogic Serverなどのアプリケーション・サーバー環境にデプロイされ、この環境で実行します。Provider Servicesの高可用性をサポートするには、WebLogic Serverのクラスタ化機能とロード・バランシング機能を使用して、複数のProvider Servicesインスタンスをデプロイします。Provider Servicesなどのエンタープライズ・アプリケーションのクラスタ化の詳細は、WebLogic Serverのドキュメントを参照してください。
図16-2は、Oracle BI EE高可用性デプロイメントにおけるOracle Hyperion Provider Servicesを示しています。
前述の図のLOGICAL_WEB_APPは、Provider Servicesのインスタンスで構成されているクラスタを表します。各PROVIDER_SERVICES_WEB_APPコンポーネントには、実際のサーバーと、そのサーバーのProvider Servicesインスタンスのポートを格納します。次に、その例を示します。
LOGICAL_WEB_APPCluster_URL
|
----- PROVIDER_SERVICES_WEB_APP 1 server1:port
|
----- PROVIDER_SERVICES_WEB_APP 2
|
----- PROVIDER_SERVICES_WEB_APP 2 server2:port_y
LOGICAL_WEB_APPコンポーネント情報では、Provider Servicesクラスタの一意のURLを指定します。
Provider Servicesは、起動時にのみessbase.propertiesファイルを読み取ります。このファイルをProvider Servicesの管理者が変更するときには、その管理者はProvider Servicesクラスタを再起動する必要があります。そうすることで、クラスタ内のすべてのProvider Servicesインスタンスは、構成の設定値で同期されます。
Essbaseのクラスタをサポートする場合、クライアントはProvider Servicesと通信することで、クラスタ内でアクティブなEssbaseノードをフェッチします。APIクライアント(CAPI/JAPI)は、アクティブなEssbaseホスト・インスタンスの詳細を取得するために、Provider ServicesのURL(OPMN Essbaseクラスタの名前を含む)を指定する必要があります。それにより、Provider Servicesは、アクティブなEssbaseノードの詳細をHyperion Registryから取得します。この項の残りの部分では、Provider ServicesとC/JAPIクライアントを使用した場合の動作について説明します。
Provider Servicesは、アクティブ/アクティブのクラスタ化によってEssbaseデータベースの高可用性をサポートします。Essbaseキューブ(データベース)をクラスタ化することで、ロード・バランシングとフェイルオーバーのサポートが可能になります。Provider Servicesは、一連のアクティブな複製データベースを管理し、このデータベースがユーザーのリクエストに応答します。ユーザーは、Essbaseクラスタを指定することでデータベースに接続します。ユーザーはアクセス対象のデータベースを意識する必要はありません。Provider Servicesによって、クラスタ内のデータベース間での可用性と優先順位のルールに基づいたルーティングが容易になります(これには、ラウンドロビン技法を使用します)。Essbaseクラスタは、Essbaseデータベースに対する読取り専用操作をサポートしています。データのロードやアウトラインの編集などのライトバック操作はサポートされていません。
Provider Servicesは、スティッキー・セッションをサポートしています。Provider Servicesインスタンスとのユーザー・セッションが確立されると、ユーザーが切断するまで、同一のProvider Servicesインスタンスがクライアントからの後続のリクエストをすべて処理します。Provider Servicesインスタンスに障害が発生したときには(無効なセッション・エラーによって示されます)、ユーザーは既存の(無効な)セッションを切断してから再度ログオンする必要があります。新しいProvider Servicesインスタンスへのフェイルオーバーは透過的であるため、ユーザーは前に使用したAPS URL(ディスパッチャのURL)と同じURLに接続できます。ディスパッチャは、ゲートウェイとして機能するOracle HTTP Serverなどになります。このゲートウェイによって、リクエストはクラスタに属するProvider Servicesインスタンスに配信されます。
Oracle Enterprise Performance Management(EPM)Workspace、Fusion Edition(Workspace)は、すべてのOracle HyperionコンテンツとOracle Hyperion以外のコンテンツにアクセスするために使用するWebユーザー・インタフェースです。Oracle Hyperionコンテンツには、レポート作成および分析フレームワークと、OracleのHyperion財務管理アプリケーションが含まれます。
図16-5は、Workspaceの単一インスタンス・アーキテクチャを示しています。
EPM Workspaceは、単一のJ2EE Webアプリケーションで構成されます。通常、このアプリケーションの前面にはOracle HTTP ServerなどのHTTPプロキシが配置されています。HTTPプロキシは、静的コンテンツを提供します。また、EPM Workspaceに統合された他の製品のプロキシになります。通常、コンテンツの集約はクライアント側で行われます。EPM Workspaceは、それ自体のプロセスでコンテンツを集約することはありません。つまり、EPM Workspaceは、ポータルとしては機能しないということです。
EPM Workspaceのセッションは、通常のJ2EEセッションであり、メモリーにのみ保持されます。EPM Workspaceは、それが使用するセッションにおいてステートフルであり、そのセッションはどのDBに対してもシリアライズできません。
EPM Workspaceは、通常のJ2EEランタイムを保持します。通常、ユーザーはEPM Workspaceに接続してからシステムにログオンし、Oracle Hyperion Financial Reportingなどの別の製品にアクセスします。バックグラウンド・スレッドや、その他の形式のサーバー側のサービスまたはジョブは存在しません。すべてのプロセスは、HTTPリクエストとして処理されます。
EPM Workspaceは、直接またはJSPとして実装された一連のサーブレットと、サーブレット・フィルタを使用します。EJBやJMSを使用することはありません。データベース・アクセスは、JDBCデータ・ソースについての標準のJNDIルックアップによって行われます。
EPM Workspaceは、WebLogicアプリケーション・サーバーにデプロイされた標準のJ2EE Webアプリケーションとして管理されます。そのアプリケーション・サーバーによって、これが管理、開始および終了されます。
EPM Workspaceに対するリクエストは、HTTPプロキシを通じて行われます。エンドユーザーがEPM Workspaceにアクセスするには、このHTTPプロキシを使用する以外に手段はありません。EPM Workspaceが、その他のWebアプリケーションやデータベースに対してリクエストを行うことはありません(ただし、そのEPM Workspaceのリポジトリ・データベースとEPM Registryデータベースを除きます)。
EPM Workspaceは、そのEPM Workspaceのリポジトリ・データベースと、Hyperion Registryに依存します。これらは、どちらも同一のスキーマになります。
多くのEPM製品は、初期認証とそれに含まれるユーザー・インタフェースを提供するためにEPM Workspaceに依存します。
EPM Workspace全体の構成は、Hyperion Registryに格納されます。個別のユーザー・プリファレンスは、EPM Workspaceリポジトリに格納されます。
この項では、高可用性環境でEPM Workspaceを使用する場合の概要について説明します。
EPM WorkspaceのHTTPプロキシとJ2EEデプロイメントの両方を、WebLogic Serverのクラスタ化メカニズムと、アプリケーション・サーバー・デプロイメントおよびデータ・ソースの標準的な使用によってクラスタ化できます。EPM Workspaceの高可用性には、スティッキー・セッションが必要になります。セッションのレプリケーションとフェイルオーバーはサポートされていません。
クラスタ化されたバージョンはすべて、同一にする必要があります。クラスタのメンバーに対するすべての更新は、同時に行う必要があります。
ロード・バランサ・ハードウェアまたはHTTPプロキシは、ラウンドロビン・ローテーションでリクエストを割り当てます。リポジトリ・データベースまたはHyperion Registryが失われると、リクエストは失敗します。リクエストが失敗すると、後続のリクエストによってEPM Workspaceの初期化と、そのEPM Workspaceのデータベース接続のリストアが試行されます。
EPM Workspaceインスタンスが開始および初期化されるときには、データベースの使用が大幅に増加します。多数のデプロイメントがある場合は、インスタンスの起動を重ならないようにすることで、クラスタの起動時間を短縮できることがあります。
EPM Workspaceには、共有ファイルまたは共有ディレクトリがありません。ただし、Oracle JRFおよびEPMの共通ファイルを除きます。
製品のバイナリとWebLogic Serverによって生成されたデプロイメント情報は、ファイル・システムに格納されます。構成はHyperion Registryに格納されます。Workspaceのすべてのインスタンスは、Hyperion Registryを介して同一の構成を共有します。構成は、EPM Workspace管理ユーザー・インタフェースから変更できます。また、EPM Workspace外のレジストリに明示的な更新を行うことでも変更できます。
通常、ファイル・システム・アーティファクトは、WebLogic Serverのファイル変更が必要になるような、パッチまたはデプロイメントやクラスタ化の再構成に際してのみ変更します。構成の変更に、ファイル・システムの更新は必要ありません。クラスタのメンバーは、更新された構成を次回の再初期化時に認識します。各クラスタ・メンバーに対して、そのメンバーの再初期化を指示する必要があります。Hyperion Registryはポーリングされません。
障害が発生したノード上で未完了のリクエストおよびセッションは失われます。別のノードにルーティングされるブラウザからの後続のリクエストはインターセプトされるため、Workspaceへの再認証が必要になります。単一ノード障害に対してセッションを移行するプロビジョニングはありません。管理者がWorkspaceユーザーに対して停止時間などの情報をログオン時に通知できる機能があります。
|
注意: データベースの停止は、BI Workspaceのセッションに影響を与えます。RACデータベース・バックエンドでは、データベース・インスタンスが停止すると、そのデータベースに接続したBI workspaceのセッションはエラーを生成し、再起動が必要になることがあります。 |
Oracle Hyperion Financial Reporting(Financial Reporting)は、分析データをグラフィカルにデザインして表現するための強力なツールです。資金管理レポートや損益計算書、貸借対照表などの従来型の財務レポート形式をデザインできます。さらに、従来型の形式ではないテキストやグラフを含む財務データや分析データを設計することもできます。
Financial Reportingを使用すると、財務レポートを作成して、それをGeneral Ledgerシステムに配信できます。Reporting管理者は、財務レポートにEPM Workspaceを使用して、レポート、ブックおよびバッチ定義の作成や変更を実行します。また、EPM Workspaceにあるレポート作成スケジューラのユーザー・インタフェースからバッチ・ジョブをスケジュールします。Reportingユーザーは、General Ledgerユーザー・インタフェースを使用してレポートの実行や表示を行います。このユーザーは、General Ledgerブラウザ・ウィンドウのIFrame内でレポートを起動できます。
図16-6は、Financial Reportingの単一インスタンス・アーキテクチャを示しています。
Financial Reportingには、サーブレットと、UIおよびXML生成用のJSPが含まれています。また、FR用のESSスケジューラ実装(FREssClient.ear)から使用するためのWebサービスAPI(JRFベース)も提供しています。FRWebAppには、HTTPコールを通じて検出および配信されるRMIオブジェクトも含まれています。このオブジェクトは、通常のRMIレジストリを置換することで、マシンごとに複数のインスタンスをプロキシ・リクエストでルックアップしてインスタンス全体に負荷を分散できるようになります。
PrintServerは、Webアプリケーションに登録されるスタンドアロンのRMIサーバー(デフォルト・ポートは8297)であるため、PDFについてのWebリクエストでプリント・サーバーの検出と、結果としてのPDFの生成が可能になります。
EPM Workspaceブラウザは、ステートレスまたはセッション単位のどちらかになります。Oracle BIプレゼンテーション・サービスへの接続はキャッシュされ、タイムアウトが発生した場合にはリストアされます。WebLogicのポーリングはRDBMSを処理して、SQLコールが行われたときに障害が発生した場合には再接続を試行します。デフォルトでは、Essbaseの接続は5分間キャッシュされます(構成可能)。
プロトコル:
RDBMS – WebLogicで構成されたJNDI接続によって管理されます。
Oracle BIプレゼンテーション・サービスのWebサービスURL – Hyperion Registry内で構成されます。
EPM Workspace – Financial Reporting用のWebユーザー・インタフェース・コンテナです(Financial Reportingとのすべての相互作用は、JavaScriptを使用したブラウザ内で行われます)。
Essbase/Provider Services – Financial Reportingは、ソケットによってEssbaseに直接接続します。ルックアップは、直接またはProvider ServicesのHTTPコールによって実行します。
この項では、実行時のFinancial Reportingプロセスについて説明します。
ユーザーは、利用可能なレポートのリストからレポートまたはブックを起動します。ユーザーは、HTMLやPDF、Microsoft Officeドキュメントなどの形式を選択できます。
Financial Reportingは、使用されるレポート・インスタンスを識別するトラッキング・フレームをロードし、サーバー・インスタンスをクリーンアップするためにIFrameのアンロード・イベントを捕捉します。このフレームは、レポートまたはブックを実行および表示するための別のフレームがロードします。
Financial Reporting Webアプリケーションは、レポートまたはブックのデザインをロードし、それをEssbaseに向けて実行して必要な形式での出力を生成します。
Financial Reportingは、Oracle BIプレゼンテーション・サービスコールを通じてカタログからデザインをロードします。
Financial Reportingは、Essbaseに直接またはProvider ServicesのURLを通じて接続します。
Financial Reportingは、レポートまたはブックのデザインに基づいてEssbaseに問合せを行い、必要な形式での出力を生成します。
HTMLおよびMicrosoft Office形式の場合、Financial ReportingはHTMLを生成してから関連付けられたMIMEタイプをクライアントに配信し、必要に応じてMicrosoft Officeを起動できるようにします。
PDF形式の場合、Financial Reportingアプリケーション・サーバーは利用可能なプリント・サーバーに向けたRMIコールを実行し、PDFコンテンツを生成してからブラウザ・クライアントにPDFファイルを戻します。
|
注意: 複数のプリント・サーバーを構成して登録してください。プリント・サーバーに障害が発生した場合やオフラインになった場合、Financial Reportingは別のプリント・サーバーに移ります。 |
EPM Workspaceで起動されるレポートまたはブックの実行および表示(HTML、PDF、Microsoft Office)
ブラウザから開始します。
XML、HTML、JavaScriptおよびBindows – EPM Workspace、Financial ReportingおよびOracle BI EEによって表示されるユーザー・インタフェース・コンポーネントです。
フェイルオーバーはサポートされません。ユーザーはブラウザを再起動する必要があります。
Smart Viewによるレポートのインポート
Microsoft Officeから起動します。
XML、HTML、JavaScript。
フェイルオーバーがサポートされています。
レポートのプレビューがInternet Explorerベースのコントロールに表示されます。このコントロールには、Microsoft Office形式のHTMLによる結果が返される前に、HTML形式でレポートが表示されます。
ブックおよびバッチのデザインと変更(EPM Workspaceからのみ利用可能)
ブラウザから開始します。
XML、HTML、JavaScriptおよびBindows。
フェイルオーバーはサポートされません。ユーザーはブラウザを再起動する必要があります。
ブックおよびバッチのデザインの編集にはBindowsコンポーネントの複合ユーザー・インタフェースを使用します。これは、ブックおよびバッチのコンテンツを表示および操作するためのものです。
Financial Reportingは、WebサービスAPIを通じてOracle BIプレゼンテーション・サービスリポジトリからデザイン・オブジェクトを開き、このリポジトリにデザイン・オブジェクトを保存します。
Financial Reportingは、Essbaseへの直接接続またはProvider ServicesのURL(フェイルオーバー可能)を通じてデザイン固有のEssbaseキューブに接続します。
Financial Reportingは、Bindowsユーザー・インタフェース・コンポーネントとJavaScriptを使用して、Reports Designerにデザインを提出し、これによって、ブックまたはバッチのデザインを変更できます。
レポートのデザインと変更(Financial Reporting Studioから実行可能)
Financial Reporting Studio(Windows 32ビット実行可能ファイル)から開始します。
Visual Basic/Visual C++/Javaアプリケーション。
フェイルオーバーはサポートされていません。ユーザーはFinancial Reporting Studioを再起動する必要があります。
接続およびユーザー認証: Report DesignerによってFinancial Reportingサーバーの資格証明とURL(通常は、Oracle HTTP Serverプロキシのアドレス)が入力されます。Financial Reporting Studioは、Webアプリケーションに向けたHTTPコールを実行して、RMIスタブ・オブジェクトを取得します。その後の通信はすべてRMIを通じて行われます。
リポジトリおよびデータ・ソースに対するすべてのアクセスは、Financial Reporting WebアプリケーションRMIオブジェクトに向けたリモートRMIコールを通じて行われます。このオブジェクトは、リポジトリとデータ・ソースに向けたコールを実行します。Financial Reporting Studioから、リポジトリまたはEssbaseへの直接接続が確立されることはありません。
RDBMSに対するすべてのアクセスは、Financial Reporting WebアプリケーションRMIオブジェクトに向けたリモート・コールを通じて行われます。このオブジェクトは、JDBCコールを実行します。FRStudioからJDBCデータ・ソースへの直接接続が確立されることはありません。
バッチ・スケジュール(EPM Workspaceから使用可能。スケジュールは、ESS EMからアクセスおよび変更可能)
ブラウザから開始します。
HTML、JavaScriptおよびBindows。
フェイルオーバーはサポートされません。ユーザーはブラウザを再起動する必要があります。
ユーザーはウィザードを起動して、スケジュールするバッチを選択します。また、観点や実行時間/実行頻度、出力形式などのジョブ属性も選択します。
Financial Reporting Webアプリケーションは、ESS EJB APIを使用して、ユーザーの指示に応じたジョブの作成とスケジュールを実行します。ESS RDBMSの表には、ジョブとリクエストが格納されます。
バッチ実行(ESSおよびFinancial Reportingバックエンド・コード)
ESSによって開始されます。
Financial Reportingに向けたWebserviceコールを呼び出します。
フェイルオーバーがサポートされています(コール時にWebserviceに障害が発生するとバッチ結果の状態はエラーになります)。
ESSはFinancial Reportingのスケジュール済ジョブを取得して、Financial Reporting EssClientをコールします。このEssClientは、FSCMドメインにESS専用サーバーとともにデプロイされます。
FREssClientは、ターゲットのFinancial Reportingアプリケーション・サーバーのURLを抽出し、Financial Reportingアプリケーション・サーバーに向けたWebserviceコールを実行して、ジョブ定義として定義されたXMLを渡すことでジョブを実行します。
Financial Reporting Webアプリケーションは、ユーザーがジョブをスケジュールしたときに定義したパラメータに応じてジョブを実行し、FREssClientにステータス・コードを返します。
FREssClientは、成功または失敗のステータスをESSのコール元に返します。
|
注意: Financial Reportingは、ジョブの結果をRDBMSの表に保持します。ただし、ジョブの実行時期はESSが決定し、FREssClientが接続するFinancial Reporting Webアプリケーションは1つに限定されています。これにより、複数のFinancial Reportingサーバーが同一のジョブを処理するという問題を防止します。ESSは、複数のESSサーバーによる同一ジョブの処理を防止する方法を管理します。 |
バッチ結果のビューア(EPM Workspaceから使用可能)
ブラウザから開始します。
HTML、JavaScriptおよびBindows。
フェイルオーバーはサポートされません。ユーザーはブラウザを再起動する必要があります。
ユーザーは実行済のジョブと保留中のジョブのリストを取得します。Financial Reporting Webアプリケーションは、このリストをESSのインプロセスEJBから取得します。
ユーザーは、ジョブのリストから結果コンテンツを取得できます。Financial Reporting Webアプリケーションは、Financial Reporting Scheduler RDBMSの表から結果を取得します。
ユーザーは、ジョブの作成やスケジュールのプロセスと同じ手順を実行することで、ジョブを削除またはレプリケートできます。
RDBMS: Hyperion Registry、注釈の表(Financial Reporting)、Financial Reportingスケジューラの表(Financial Reporting)、ESSジョブの表(ESS)。
Oracle BIプレゼンテーション・サービスリポジトリ(Web ServicesおよびEPM Workspaceからアクセスされます)
EPM Workspace (Reporting管理者用)
Essbase/Provider Services
Essbaseによって生成されたキューブ
インストールと構成が完了しているESS
Hyperion Registryには、システム全体の構成に含まれない部分の構成情報を格納します。Webアプリケーションのすべてのインスタンスは、Hyperion Registryを共有します。MBean(Fusion Middleware Controlで表示や変更が可能)は、構成情報を公開します。Fusion Middleware Controlで、com.hyperion.FinancialReportingと、com.hyperion.Annotationsを参照してください。
Financial Reportingのデプロイメント・アーティファクトは、次のとおりです。
FREssClient.ear – Financial Reportingのジョブ用のEnterprise Scheduler Serviceサーバーの実装が含まれています。これは、FinDomain Enterprise Scheduler Serviceにデプロイされます。
HReports.ear – BIDomainにデプロイされるプライマリFinancial Reporting Webアプリケーションです。
Financial Reporting Webアプリケーションに必要なBIDomainにデプロイされる共有ライブラリには、epm-shared-libraries、epm-fr-libraries、epm-annotation-libraries、epm-frweb-libraries、epm-misc-librariesがあります。
Oracle Hyperion Financial Reportingは、次の機能についての高可用性をサポートしています。
レポートの実行と、HTMLまたはPDF形式での表示:
プロンプト
POVの変更
ページ・ディメンションのドロップダウン(HTMLのみ)
注釈の作成と表示
拡張
ドリルスルー(PDFでは使用不可)
ブックの実行と、HTMLまたはPDF形式での表示
Microsoft Office形式へのエクスポート
図16-2は、Oracle BI EEの高可用性デプロイメントにおけるEssbaseを示しています。
共有されるファイルまたはディレクトリはありません。共通のすべてのプロパティとドキュメントは、リレーショナル・データベースまたはOracle BIプレゼンテーション・サービスリポジトリのどちらかに格納されます。
Financial Reportingは、次のコンポーネントも併せてデプロイされている場合に、フェイルオーバーとセッションのシリアライズをサポートします。
Oracle Business Intelligence Enterprise Edition/Oracle BIプレゼンテーション・サービス: Financial Reportingは、Oracle BIプレゼンテーション・サービスへのWebサービス接続を使用します。この接続は、現在のOracle BIプレゼンテーション・サービス接続に障害が発生すると他のカタログ・ノードに移行するフェイルオーバーを備えています。このフェイルオーバーは、次の条件を想定しています:
カタログ・アプリケーション・サーバー、Presentation Servicesおよびファイル記憶域が、クラスタ化またはレプリケートされている。
アプリケーションのプロビジョニング時に構成されたカタログの場所は、カタログWebアプリケーション・サーバーを直接参照するのではなく、プロキシ・サーバーを参照する。
Essbase: Financial Reportingのレポートは、Provider ServicesのURLを使用してEssbaseをターゲットにする必要があります。また、Provider Servicesは、アクティブおよびパッシブのEssbaseサーバーで構成されている必要があります。Essbaseに障害が発生すると、Financial ReportingはOracle Hyperion Provider ServicesのURLを通じてバックアップ・サーバーに接続します。Essbaseの問合せは再発行されますが、このときユーザーのリクエストが中断されることはありません。
RDBMS: このデータベースはフェイルオーバーをサポートしている必要があります。接続は、WebLogic JDBC構成と接続プールによって処理されます。
Oracle Internet Directory/OAM。
Oracle HTTP Serverは、フェイルオーバーを提供することに加え、すべてのコンポーネントの統合ポイントを提供することが期待されます。Financial Reporting構成は、Oracle HTTP Serverまたはロード・バランシングされたURLを通じてOracle BIプレゼンテーション・サービスをターゲットにする必要があります。カタログ・サーバーを直接ターゲットにはしません。
Oracle Hyperion Financial Reporting、Fusion Edition PrintServer – 少なくとも2つのPrintServerホストをWindowsマシン上にデプロイして、そのシステムによって構成する必要があります。
Allocation Managerを使用すると、Oracle Hyperion Financial Management、Fusion Edition、Oracle Hyperion Planning、Fusion EditionおよびOracle Essbaseのビジネス問題を解決する洗練された計算を作成、検証、デプロイおよび管理できます。Oracle Enterprise Performance Management Workspace, Fusion Edition内のAllocation Managerにアクセスします。
Allocation Managerは、アクティブ/アクティブ・モードで実行する複数のインスタンスとともにWebLogicにデプロイされるJava Webアプリケーションです。Allocation Managerのインスタンスは、すべて同等であり、あらゆるリクエストを処理できます。Allocation Managerはステートフルなアプリケーションであり、スティッキーなルーティングが必要です。セッションのフェイルオーバーはサポートされません。編集は単一インスタンス内でのみ行われ、そのインスタンスに障害が発生すると保存されません。
Allocation Managerによる外部コンポーネントの管理と検出は、Hyperion Registryを通じて行われます。
この項では、Oracle BI EEおよびBI Publisherにおいて2ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図16-2に示しています。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
次の項では、Oracle BI EEおよびOracle BI Publisherの高可用性構成を設定する前に必要となる手順を説明します。
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%';
図16-7で示すように、異なる仮想IPをリスニングするようにBI管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。インストールを実行する前に、各VIPが使用可能であり、アクセスできることを確認します。
表16-3 BI EEの仮想ホスト
| 仮想IP | 仮想IPのマップ先 | 説明 |
|---|---|---|
|
VIP1 |
APPHOST1VHN1 |
APPHOST1VHN1は、BI_SERVER1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、BI_SERVER1プロセスが実行されているノード(デフォルトはAPPHOST1)で有効化されます。 |
|
VIP2 |
APPHOST2VHN1 |
APPHOST2VHN1は、BI_SERVER2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、BI_SERVER2プロセスが実行されているノード(デフォルトはAPPHOST2)で有効化されます。 |
障害発生時に適切にリカバリできるようにするには、すべてのノードからアクセスできる場所にJMSとトランザクションの両方のログを格納して、管理対象サーバーで障害が発生した後にすべてのノードが操作を再開できるようにします。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表16-4は、共有記憶域の内容を示しています。
表16-4 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、BI_SERVER2にはBipJmsStore2。 |
|
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 nasfiler:/vol/volX/FMWshared MW_HOME-t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
クラスタに参加しているすべてのサーバーのクロックを、1秒以内の差異に収まるように同期する必要があります。クロックを同期するには、単一のネットワーク・タイム・サーバーを使用して各サーバーがそのネットワーク・タイム・サーバーを指すようにします。ネットワーク・タイム・サーバーを指すように設定する手順は、WindowsとLinuxでは異なります。使用するオペレーティング・システムのドキュメントを参照してください。
次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。
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 RepositoryをOracle RACデータベースにインストールしてください。
最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
Oracle Business Intelligenceをインストールする前に、11g (11.1.1) Oracle Fusion Middlewareのメタデータ・ストアおよびOracle BIスキーマをOracle RACデータベースにインストールします。次の手順を実行します。
RCUのDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。
prompt> cd RCU_HOME/bin
prompt> ./rcu
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
データベース・タイプ: Oracle Databaseを選択します。
ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを次のように指定します:
BIDBHOST1-VIP
ポート: データベースのリスニング・ポート番号である1521を指定します。
サービス名: データベースのサービス名を指定します。
biha.mycompany.com
ユーザー名: DBA権限またはSYSDBA権限のあるユーザーの名前(SYS)を指定します。
パスワード: SYSユーザーのパスワードを入力します。
ロール: データベース・ユーザーのロール(SYSDBA)をリストで選択します(SYSユーザーに必要)。
「次へ」をクリックします。
「コンポーネントの選択」画面で、次を行います。
「接頭辞の新規作成」を選択し、BIHAのように、データベース・スキーマに使用する接頭辞を入力します。6文字まで接頭辞として指定できます。接頭辞を使用して、複数リポジトリの論理グルーピングをデータベースにおいて作成します。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
|
ヒント: このスキーマの名前をメモに記録してください。後述する手順でこの情報が必要になります。 |
次のコンポーネントを選択します。
o AS Common Schemas: Metadata Services (automatically selected) o Oracle Business Intelligence: Business Intelligence Platform
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択します。
「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。
|
ヒント: スキーマ・パスワードの名前をメモに記録してください。後述する手順でこの情報が必要になります。 |
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
この項では、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のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。
この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。
サーバーが次の要件を満たしていることを確認します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンの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
Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXの場合:
./runinstallerコマンドを発行します。
Windowsの場合:
setup.exeをダブルクリックします。
「インベントリ・ディレクトリの指定」画面が表示されます。
「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /u01/app/oraInventory
オペレーティング・システムのグループ名: oinstall
次のメッセージのダイアログ・ボックスが表示されます。
「インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください」
rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。
これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。
|
注意: すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールで「Oracleインベントリ」画面が表示されない場合は、次の内容を確認してください。
|
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
「インストール場所の指定」画面で、次を指定します。
Oracle Middlewareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)
Oracleホーム・ディレクトリ: Oracle_WT1
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。
「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、WEBHOST1用に次の値を入力します。
インスタンス・ホームの場所: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1
インスタンス名: web1
OHSコンポーネント名: ohs1
「次へ」をクリックします。
「ポートの構成」画面で、次の操作を行います。
カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
Oracle HTTP Serverポートを入力します(例: 7777)。
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。
「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。「次へ」をクリックします。
「インストール完了」画面で「終了」をクリックして終了します。
WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランサを構成します。
この項では、WebLogic ServerとOracle 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システムを作成およびスケール・アウトします。
Oracle WebLogic Serverをインストールするには:
WebLogic Serverのインストーラをインストール・メディアから起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します。
|
注意: ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。 |
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.6ディレクトリを受け入れます。そして「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
WebLogic Serverソフトウェアがインストールされます。
「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。
Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。
Oracle Fusion Middleware Business Intelligence 11gのインストーラを次のインストール・メディアから起動します。
UNIXの場合:
APPHOST1>./runInstaller
Windowsの場合:
APPHOST1> setup.exe
「インベントリ・ディレクトリの指定」画面で、次の操作を行います。
HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。
インストールを実行するユーザーのOSグループを入力します。
「次へ」をクリックします。
画面の手順に従って、/createCentralnventory.shをrootとして実行します。
「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「ソフトウェアのみインストール」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、前にインストールしたMiddlewareホームをドロップダウン・リストで選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(Oracle_BI1)を入力します。
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。
「サマリー」画面で「インストール」をクリックします。
Oracle Fusion Middleware Business Intelligence 11gソフトウェアがインストールされます。
「インストールの進行状況」画面で「次へ」をクリックします。
完了画面で「終了」をクリックします。
BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してマッピングされているVIPを有効にして(APPHOST1ではVIP1、APPHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。
この項では、Oracle Business Intelligence構成アシスタント、管理コンソールおよびOracle Enterprise Managerを使用して、ドメインと最初のWebLogic Server BI管理対象サーバーを作成する方法について説明します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
Oracleホーム・ディレクトリから構成アシスタントを実行して、BI Publisherが配置された管理対象サーバーおよび管理サーバーが含まれたドメインを作成します。
構成アシスタントの場所にディレクトリを移動します。
APPHOST1> cd ORACLE_HOME/bin
構成アシスタントを起動します。
UNIXの場合:
APPHOST1> ./config.sh
Windowsの場合:
APPHOST1> config.cmd
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。
BIシステムの作成またはスケールアウト画面で、「新規BIシステムの作成」を選択し、次を指定します。
ユーザー名: weblogic
ユーザー・パスワード: weblogicユーザーのパスワードを入力します。
ドメイン名: bifoundation_domain
「次へ」をクリックします。
「インストール場所の指定」画面で、次を入力します。
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
「次へ」をクリックします。
「コンポーネントの構成」画面で、次を選択します。
- Oracle Business Intelligence
- Business Intelligence Enterprise Edition
- Business Intelligence Publisher
「次へ」をクリックします。
BIPLATFORMスキーマ画面で、次のように入力します。
データベース・タイプ: Oracle Database
接続文字列: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM
BIPLATFORMスキーマ・ユーザー名: BIHA_BIPLATFORM
BIPLATFORMスキーマ・パスワード: BIPLATFORMスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。
MDSスキーマ画面で情報を確認し、「次へ」をクリックします。
「ポートの構成」画面で、次のいずれかを選択します。
自動でポートを構成
構成ファイルを使用してポートを指定
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「サマリー」画面で「構成」をクリックします。
「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。
完了画面で「終了」をクリックします。
この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。
APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成する手順は、次のとおりです。
次のディレクトリに移動します。
ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/ AdminServer/security
次の行をファイルに入力し、ファイルを保存してからエディタを閉じます。
username=Admin_username password=Admin_password
|
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
この項では、APPHOST1で管理サーバーを起動および検証する手順について説明します。
APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。
APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin APPHOST1> ./startWebLogic.sh
管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「bi_server1」を選択します。
リスニング・アドレスをAPPHOST1VHN1に設定します。「保存」をクリックします。
「変更のアクティブ化」をクリックします。
BI_SERVER1管理対象サーバーを再起動して変更を有効にします。
「サーバーのサマリー」画面で、「制御」タブを選択します。
表で「bi_server1」を選択してから、「停止」をクリックします。
BIシステムのコンポーネントを再起動します。例:
cd ORACLE_BASE/admin/instance1/bin
./opmnctl restartproc
この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLを更新します。
|
注意: Oracle BI Publisher Schedulerのクロックの同期を維持する方法については、「Oracle BI Publisherの「スケジューラ診断」ページでJMSインスタンスが欠落している」を参照してください。 |
Oracle BI Publisher Schedulerの構成を更新する手順は次のとおりです。
次のURLにアクセスしてOracle BI Publisherにログインします。
http://APPHOST1VHN1:9704/xmlpserver
「管理」リンクをクリックします。
「スケジューラ構成」を「システム・メンテナンス」で選択します。
次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。
t3://bi_cluster
「適用」をクリックします。
スケジューラのステータスを「スケジューラ診断」タブでチェックします。
管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合、ホスト名の検証を無効化する必要があります。サーバー証明書を構成しないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。
ホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。「サーバー」をクリックします。
表の「名前」列で「bi_server1」を選択します。
「SSL」タブを開きます。ページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
「変更のアクティブ化」をクリックします。
この変更は、BI_SERVER1管理対象サーバーを再起動するまで有効になりません。
「サーバーのサマリー」画面で、「制御」タブを選択します。
表で「bi_server1」を選択してから、「停止」をクリックします。
BIシステムのコンポーネントを再起動します。例:
cd ORACLE_BASE/admin/instance1/bin
./opmnctl restartproc
この項では、APPHOST1でノード・マネージャを起動する方法、およびAPPHOST1でBI_SERVER1管理対象サーバーを起動して検証する方法について説明します。
通常、ノード・マネージャはconfig.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合、次のコマンドを使用してAPPHOST1で起動します。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
BI_SERVER1管理対象サーバーを起動して、このサーバーが適切に構成されていることを確認する手順は次のとおりです。
管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」を選択します。
「制御」タブをクリックします。
「bi_server1」を選択してから、「起動」をクリックします。
管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
BI_SERVER1が起動すると、次のURLが使用できるようになります。
http://APPHOST1VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。
|
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。 |
http://APPHOST1VHN1:9704/xmlpserverにアクセスして、BI Publisherアプリケーションのステータスを確認します。
opmnctlコマンドを使用して、Oracle Business Intelligenceのシステム・コンポーネントを制御できます。
OPMNCTLコマンドラインを使用してBI EEシステム・コンポーネントを起動する手順は次のとおりです。
OPMNコマンドライン・ツールが格納されたディレクトリに移動します。
|
注意: OPMNコマンドライン・ツールは、ORACLE_INSTANCE |
opmnctlコマンドを実行して、BI EEシステム・コンポーネントを起動します。
opmnctl startall
このコマンドは、OPMNとすべてのBI EEシステム・コンポーネントを起動します。
opmnctl start
このコマンドはOPMNのみを起動します。
opmnctl startproc ias-component=componentName
このコマンドは、指定されたシステム・コンポーネントを起動します。たとえば、coreapplication_obips1がBIプレゼンテーション・サービスである場合、コマンドは次のようになります。
opmnctl startproc ias-component=coreapplication_obips1
BI EEシステム・コンポーネントのステータスをチェックします。
opmnctl status
この項では、Oracle BI EEを構成する方法を説明します。
Fusion Middleware Controlで次の手順を実行します。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「デプロイメント」をクリックしてから、「リポジトリ」をクリックします。
「構成をロックして編集」をクリックします。
「リポジトリの共有」を選択して、Oracle BIリポジトリの「共有場所」を指定します。Windows環境では、Enterprise Manager Fusion Middleware Controlの要件として、UNCパスを使用してリポジトリの共有場所を定義する必要があります。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
Fusion Middleware Controlで次の手順を実行します。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「容量管理」をクリックしてから、「パフォーマンス」をクリックします。
「構成をロックして編集」をクリックします。
「グローバル・キャッシュ」セクションで、Oracle BI Serverグローバル・キャッシュの共有場所を指定して、グローバル・キャッシュ・サイズとして250MBを指定します。Windows環境では、Enterprise Manager Fusion Middleware Controlの要件として、UNCパスを使用してOracle BI Serverグローバル・キャッシュの共有場所を定義する必要があります。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
Oracle BIスケジューラでサーバー側スクリプトを使用する場合は、クラスタ内のすべてのOracle BIスケジューラ・コンポーネントで共有できるように、これらのスクリプトの共有ディレクトリを構成することをお薦めします。
次の手順は、サーバー側スクリプトを使用している場合にのみ実行してください。
Oracle BIスケジューラのスクリプトを共有する手順は次のとおりです。
デフォルトのOracle BIスケジューラ・スクリプト(例: ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/common)とカスタムのOracle BIスケジューラ・スクリプト(例: ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/scheduler)をBIスケジューラ・スクリプトの共有場所にコピーします。
Oracle BIスケジューラのinstanceconfig.xmlファイルのSchedulerScriptPath要素とDefaultScriptPath要素を更新します。
SchedulerScriptPath: Oracle BIスケジューラによって作成されたジョブ・スクリプトが格納されているパスを指します。共有BIスケジューラ・スクリプトの場所を指すパスにこれを変更します。
DefaultScriptPath: ユーザーによって作成されたジョブ・スクリプト(エージェントではなく)が格納されているパスを指定します。共有BIスケジューラ・スクリプトの場所を指すパスにこれを変更します。
デプロイメント環境内の各Oracle BIスケジューラ・コンポーネントについて、このファイルを更新する必要があります。
各プレゼンテーション・サービス・インスタンスは、Fusion Middleware Controlで指定されたカタログの場所からOracle BIプレゼンテーション・カタログをロードします。
次の手順を実行します。
既存の(ローカルに公開された)Oracle BIプレゼンテーション・カタログを共有場所にコピーします。次にローカルに公開されたカタログの例を示します。
ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/ coreapplication_obipsn/catalog/SampleAppLite
この手順は、Fusion Middleware Controlで「カタログの場所」を指定する前に実行する必要があります。
この項の例で述べたSampleAppLiteカタログを共有カタログとして使用する予定である場合は、それをAPPHOST1からコピーしてください。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「デプロイメント」をクリックしてから、「リポジトリ」をクリックします。
「構成をロックして編集」をクリックします。
共有Oracle BIプレゼンテーション・カタログの「カタログの場所」を指定します。
Windows環境では、UNCパス名を指定します。
|
注意: Windows環境では、共有記憶域の指定に汎用命名規則(UNC)を使用する必要があります。UNCは、ローカル・エリア・ネットワーク上のリソースの場所を指定するためのPCの書式です。UNCでは、 |
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
Oracle BI Publisherのサーバー構成オプションを設定するには、次の手順を実行します。
DOMAIN_HOME/config/bipublisher/repositoryの内容を構成フォルダの共有場所にコピーします。
管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「サーバー構成」を選択します。
「パス」で、構成フォルダの共有場所のパスを入力します。
変更を適用してから、BI Publisherアプリケーションを再起動します。
APPHOST2でOracle WebLogic ServerおよびOracle Business Intelligenceのソフトウェアのみのインストールを実行するには、第16.1.13.2項「高可用性のためのOracle Business Intelligence Enterprise Editionのインストール」を参照してください。
次に、ORACLE_HOMEディレクトリから構成アシスタントを実行して、BIシステムをスケール・アウトします。
構成アシスタントの場所にディレクトリを移動します。
APPHOST2> cd ORACLE_HOME/bin
構成アシスタントを起動します。
APPHOST2> ./config.sh
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
BIシステムの作成またはスケールアウト画面が表示されます。BIシステムのスケールアウトを選択して、次の値を入力します。
ホスト名: ADMINHOST
ポート: 7001
ユーザー名: weblogic
ユーザー・パスワード: weblogicユーザーのパスワードを入力します。
「次へ」をクリックします。
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(グレーアウトされています)
「次へ」をクリックします。
「ポートの構成」画面で、次のいずれかを選択します。
自動でポートを構成
構成ファイルを使用してポートを指定
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「サマリー」画面で「構成」をクリックします。
「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。
完了画面で「終了」をクリックします。
通常、ノード・マネージャはconfig.shの完了時に自動的に起動されます。ノード・マネージャが実行されていない場合は、APPHOST2で次のコマンドを実行してノード・マネージャを起動します。
APPHOST2> cd WL_HOME/server/bin
APPHOST2> ./startNodeManager.sh
BIシステム・コンポーネントをスケール・アウトする手順は次のとおりです。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「容量管理」をクリックしてから、「スケーラビリティ」をクリックします。
「構成をロックして編集」をクリックします。
APPHOST2の「instance2」Oracleインスタンスについて、次のOracle Business Intelligenceコンポーネントを1だけ増分します。
BI Server
プレゼンテーション・サービス
JavaHost
「ポート範囲(開始)」と「ポート範囲(終了)」を、APPHOST1の「instance1」Oracleインスタンスと同じになるように変更します。
「適用」をクリックします。次のメッセージが表示されます。
警告: 複数のプレゼンテーション・サービスが構成されています。共有の場所が指し示されるようにカタログの場所を調整してください。
「OK」をクリックします。共有場所は後で構成します。
「変更のアクティブ化」をクリックします。「再起動」をクリックして最近の変更を適用します。
Fusion Middleware Controlで次の手順を実行します。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「容量管理」をクリックしてから、「可用性」をクリックします。
「構成をロックして編集」をクリックして、「可用性」タブの「アクティブ/パッシブ構成」セクションをアクティブ化します。
BIスケジューラとBI Cluster Controllerの「パッシブ・ホスト/インスタンス」を指定します。
「適用」をクリックします。
「潜在的単一点障害」で、「問題はありません。すべてのコンポーネントにバックアップがあります。」と報告されていることを確認します。
「変更のアクティブ化」をクリックします。
「再起動して最近の変更を適用」をクリックします。
BI_SERVER2管理対象サーバー・リスニング・アドレスを設定する手順は次のとおりです。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「bi_server2」を選択します。
bi_server2の「設定」ページが表示されます。
リスニング・アドレスをAPPHOST2VHN1に設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
この変更は、BI_SERVER2管理対象サーバーを再起動するまで有効になりません。
「サーバーのサマリー」画面で、「制御」タブを選択します。
表で「bi_server2」を選択してから、「停止」をクリックします。
BIシステムのコンポーネントを再起動します。例:
cd ORACLE_BASE/admin/instance2/bin
./opmnctl restartproc
この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLを更新します。
Oracle BI Publisher Schedulerの構成を更新する手順は次のとおりです。
次のURLにアクセスしてOracle BI Publisherにログインします。
http://APPHOST1VHN1:9704/xmlpserver http://APPHOST2VHN1:9704/xmlpserver
「管理」リンクをクリックします。
「スケジューラ構成」を「システム・メンテナンス」で選択します。
次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。
t3://bi_cluster
「適用」をクリックします。
スケジューラのステータスを「スケジューラ診断」タブでチェックします。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。
ホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「bi_server2」を選択します。
「SSL」タブを開きます。
ページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
この変更は、BI_SERVER2管理対象サーバーを再起動するまで有効になりません。
Oracle BI for Microsoft Officeのシングル・サインオン(SSO)プロパティを構成する手順は次のとおりです。
次のURLにアクセスして、Oracle BI EE Officeサーバーのセットアップを検証します。
http://APPHOST1VHN1:9704/bioffice/about.jsp
http://APPHOST2VHN1:9704/bioffice/about.jsp
図16-7に示すように、「Oracle BI EE Officeサーバーについて」ページが開きます。
Oracle BI EE Officeサーバー・ディレクトリに移動します。例:
DOMAIN_HOME/servers/managed_server/tmp/_WL_user/bioffice_11.1.1/cvsibb/war/WEB-INF
Oracle BI EE Officeサーバーのディレクトリの場所がわからない場合は、「Oracle BI EE Officeサーバーについて」ページで「LogDir」パラメータを確認してください。Oracle BI Enterprise Edition Officeサーバーのディレクトリは、logディレクトリの親ディレクトリです。
APPHOST1およびAPPHOST2の両方で、bioffice.xmlを編集のために開いて、表16-5のとおりにBI Officeのプロパティを変更します。
表16-5 bioffice.xmlに含まれるOracle BI for Microsoft Officeのプロパティ
| プロパティ名 | 有効な値 | 説明 |
|---|---|---|
|
SawBaseURL |
https://bi.mydomain.com:443/analytics/saw.dll または https://bi.mydomain.com:443/analytics-ws/saw.dll |
Oracle BIプレゼンテーション・サービスのロード・バランサ仮想サーバー名URLです。 重要: SSOが有効になっている場合は、Oracle BI for Microsoft OfficeをSSO対応のOracle BI Serverと統合するように構成する際にデプロイした保護された分析サーブレットのURLを入力してください。Oracle BI for Microsoft OfficeサーバーとPresentation Services間のWebサービスのリクエストは、ここで指定したURLを使用します。 |
|
SawUseSSO |
0: いいえ(デフォルト) 1: はい |
実装されたOracle Business IntelligenceがSSOに対応している場合は、このプロパティを1に設定します。 |
|
SawWebURLforSSO |
https://bi.mydomain.com:443/analytics/saw.dll |
SSOが有効になっている場合は、このプロパティを使用してパブリックURLを入力し、外部ユーザーはこのURLを使用して、Oracle BI for Microsoft OfficeからSSOを使用してOracle Business Intelligenceにアクセスできます。 |
次の手順に従ってOracle BI for Microsoft Officeアプリケーションを再起動します。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「デプロイメント」をクリックします。
「bioffice(11.1.1)」を選択します。
「停止」をクリックします。
アプリケーションの停止後に、「開始」をクリックします。
「Oracle BI EE Officeサーバーについて」ページで、「SawBaseURL」パラメータが更新されていることを確認します。
Oracle BI for Microsoft Officeの構成を検証するには、次の手順を実行します。
次の場所でOracle BIプレゼンテーション・サービスにログインします:
https://bi.mydomain.com:443/analytics
左下ペインの「はじめに」見出しの下で、「BIデスクトップ・ツールのダウンロード」を選択してから、「Oracle BI for MS Office」を選択します。
Oracle BI for Microsoft OfficeのInstallShieldウィザードを実行して、Oracle BI for Microsoft Officeをインストールします。
Microsoft ExcelまたはMicrosoft PowerPointを開きます。
「Oracle BI」メニューから「設定」を選択します。
「接続」タブで「新規」を選択します。
次のフィールドに値を入力します。
サーバー名: 接続名を入力します。
BI Officeサーバー: Oracle BI for Microsoft OfficeサーバーのURLを入力します。
アプリケーション名: Oracle BI for Microsoft Officeサーバー・アプリケーションをWLSにデプロイしたときにOracle BI for Microsoft Officeに対して定義したアプリケーション名を入力します。デフォルト名は、biofficeです。
ポート: Oracle BI for Microsoft Officeサーバーのポート番号を入力します。
図16-8は、「新規接続」ダイアログを示しています。
図16-8 Oracle BI for Microsoft Officeの「新規接続」ダイアログ
「接続のテスト」をクリックし、アドインとOracle BI for Microsoft Officeサーバーとの間の接続をテストします。
管理者(例: weblogic)としてログインして、図16-9に示す「Oracle BIタスク・ペイン」にアクセスできることを確認します。
この項では、Oracle BI Publisherを構成する方法を説明します。
Oracle BIプレゼンテーション・サービスの統合のオプションを構成するには、次の手順を実行します。
管理者の資格証明を使用してOracle BI Publisherにログインして、「管理」タブを選択します。
「統合」で、「Oracle BIプレゼンテーション・サービス」を選択します。
次の項目を検証して更新します。
サーバー・プロトコル: http
サーバー: bi.mycompany.com
ポートのURL接尾辞: analytics-ws/saw.dl: 80
「適用」をクリックします。
Oracle BI Publisherアプリケーションを再起動します。
スケジューラ構成オプションを構成するには、次の手順を実行します。
管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「スケジューラ構成」を選択します。
「クォーツ・クラスタリング」を「スケジューラ選択」で選択します。
変更を適用してから、BI Publisherアプリケーションを再起動します。
Oracle BI EEのデータ・ソースは、Cluster Controllerを介してクラスタ化されたBI Serverを指している必要があります。
BI PublisherでOracle BI EEのデータ・ソースを設定する手順は次のとおりです。
管理者の資格証明でBI Publisherにログインします。「管理」タブを選択します。
「データ・ソース」で、「JDBC接続」を選択します。
「接続文字列」パラメータを次のように変更して、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;
「システム・ユーザーの使用」を選択します。
接続にシステム・ユーザーを使用しない場合は、「システム・ユーザーの使用」を選択解除して、「ユーザー名」と「パスワード」に対してBIImpersonateUserの資格証明を指定します。このコンテキストでのBIImpersonateUserユーザーの詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Edition開発者ガイドのOracle BI EE プレゼンテーション・カタログへの接続の資格証明に関する説明を参照してください。
「接続のテスト」をクリックします。「接続は正常に確立されました。」というメッセージが表示されることを確認します。「適用」をクリックします。
両方のノードから参照できるディレクトリに、すべての永続ストアの場所を構成する必要があります。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BipJmsStore」をクリックして、共有記憶域にあるディレクトリを入力します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「保存」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。
名前(例: BipJmsStore2)を入力し、BI_SERVER2をターゲットにします。APPHOST1とAPPHOST2の両方からアクセスできるように、共有記憶域にあるディレクトリを入力します。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「OK」をクリックして、変更をアクティブ化します。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSサーバー」ノードをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
新規をクリックします。
名前(例: BipJmsServer2)を入力してから「永続ストア」ドロップダウン・リストで「BipJmsStore2」を選択し、「次へ」をクリックします。
「BI_SERVER2」をターゲットとして選択します。
「終了」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BIPJmsResource」→「サブデプロイメント」タブをクリックします。
「サブデプロイメント」の「BipJmsSubDeployment」のターゲットを、BipJmsServer1とBipJmsServer2の両方にします。
「終了」→「変更のアクティブ化」をクリックします。
Oracle BI Publisherに対して実行したJMS構成を検証するには、第16.1.13.7.1項「Oracle BI Publisher Schedulerの構成の更新」の手順を実行してください。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。
|
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。 |
BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「BI_SERVER1」(ハイパーリンクとして表示されています)を表の「名前」列でクリックします。
BI_SERVER1の設定ページが開き、「構成」タブがアクティブに表示されます。
「サービス」タブをクリックします。
「デフォルト・ストア」セクションで、デフォルトの永続ストアでデータ・ファイルを格納するフォルダのパスを入力します。そのパス・ディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/bi_cluster/tlogs
「保存」→「変更のアクティブ化」をクリックします。
BI_SERVER2サーバーに対してこれらの手順を繰り返します。
|
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方からこのディレクトリにアクセスできる必要があり、サーバーの再起動前に、このディレクトが存在している必要があります。 |
この項では、APPHOST2でシステムを起動する手順について説明します。
通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、第16.1.13.9.1項「APPHOST1でのノード・マネージャの起動」の手順に従って、APPHOST2でノード・マネージャを起動してください。
BI_SERVER2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は、次のとおりです。
管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」を選択します。
「制御」タブをクリックします。
「bi_server2」を選択してから、「起動」をクリックします。
管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
BI_SERVER2が起動すると、次のURLが使用できるようになります。
http://APPHOST2VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。
|
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。 |
http://APPHOST2VHN1:9704/xmlpserverにアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。
APPHOST2でBI Enterprise Editionシステム・コンポーネントを起動するには、第16.1.13.9.3項「APPHOST1でのBI EEシステム・コンポーネントの起動と検証」の手順をAPPHOST2で繰り返します。
BI_SERVERn管理対象サーバーを含むbi_clusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。
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 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /biofficeclient> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # WSM-PM <Location /wsm-pm> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # BIEE Analytics <Location /analytics> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /mapviewer> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /analytics-ws> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /bimiddleware> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # BI Publisher <Location /xmlpserver> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location>
WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。
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=ohs1
管理コンソールで、BI ServerのステータスがRunningであることを確認します。ステータスがStartingまたはResumingである場合は、サーバー・ステータスがStartedに変更されるまで待機します。コンソールに別のステータス(Adminなど)が表示された場合は、サーバー出力のログ・ファイルでエラーを調べてください。
次の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
http://WEBHOST1:7777/mapviewer
http://WEBHOST2:7777/mapviewer
ロード・バランシング・ルーター・アドレスを使用して、次の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://bi.mycompany.com:80/mapviewer
次の手順に従って、HTTP Serverからbi_clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。
BI_SERVER2の実行中に、管理コンソールからBI_SERVER1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WEBHOST1:7777/wsm-pm
WEBHOST1:7777/analytics
WEBHOST1:7777/xmlpserver
WEBHOST1:7777/bioffice/about.jsp
管理コンソールから、BI_SERVER1を開始します。
BI_SERVER2を停止します。
前述のステップ2のURLにアクセスして、適切な機能を検証します。
Oracle WebLogic Serverクラスタに対して、フロントエンドHTTPのホストとポートを設定する必要があります。そのためには、次の手順に従ってください。
管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
左側のペインで、「ドメイン構造」ウィンドウの「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
「bi_cluster」クラスタを選択します。
「HTTP」を選択します。
次の値を設定します。
フロントエンド・ホスト: bi.mycompany.com
フロントエンドHTTPポート: 80
フロントエンドHTTPSポート: このフィールドは空白のままにします。
|
注意: このアドレスが正しくて使用可能である(ロード・バランサが稼働している)ことを確認してください。アドレスの「http://」やホスト名末尾の「/」など、値が間違っていると、仮想IPを使用してアクセスする場合でも、BIシステムにアクセスできない可能性があります。 |
「保存」をクリックします。
変更内容をアクティブ化するには、「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。
この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を次のように構成する必要があります。
障害発生時に、bi_server1管理対象サーバーがAPPHOST2で再起動するよう構成します。
障害発生時に、bi_server2管理対象サーバーがAPPHOST1で再起動するよう構成します。
このような構成では、bi_server1サーバーおよびbi_server2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。
この項の項目は次のとおりです。
ステップ1: サーバー移行leasing表のユーザーと表領域を設定する
ステップ3: ノード・マネージャのプロパティ・ファイルを編集する
ステップ5: サーバー移行ターゲットを構成する
ステップ6: サーバー移行をテストする
サーバー移行leasing表のユーザーと表領域を設定する手順は次のとおりです。
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;
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;
leasing.ddlスクリプトを使用してleasing表を作成します。
WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。
データベースにleasingユーザーとして接続します。
SQL*Plusでleasing.ddlスクリプトを実行します。
SQL> @Copy_Location/leasing.ddl;
この項では、マルチ・データ・ソースの作成方法およびGridLinkデータ・ソースの作成手順について説明します。
GridLinkデータソースの作成
GridLinkデータ・ソースには、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」で説明されているように、汎用データ・ソースの機能に加え、Oracle RACに対する追加サポートが含まれています。
GridLinkデータ・ソースを作成する手順は次のとおりです。
既存のマルチ・データ・ソースをすべて削除します。JDBCマルチ・データ・ソースの削除に関する説明を参照してください。
対応するデータ・ソースを削除します。
GridLinkデータ・ソースを作成します。管理コンソール・オンライン・ヘルプのJDBC汎用データ・ソースの作成に関する説明を参照してください。
GridLinkデータ・ソースの構成方法の包括的な概要は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのGridLinkデータ・ソースの作成に関する説明を参照してください。
マルチ・データ・ソースの作成
マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データソースを作成する際は、次の点に注意してください。
このデータ・ソースが非XAデータ・ソースであることを確認します。
マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。
これらのデータ・ソースをOracle WebCenter Content: Imagingクラスタのターゲットに設定します。
データ・ソースの初期接続プール容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データ・ソース名」→「接続プール」タブをクリックし、「初期容量」フィールドに0を入力します。
マルチ・データ・ソースを作成する手順は、次のとおりです。
管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「データ・ソース」をクリックします。「JDBCデータ・ソースのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」→「マルチ・データ・ソース」をクリックします。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。
名前として、leasingと入力します。
JNDI名として、jdbc/leasingと入力します。
アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。
「次へ」をクリックします。
「bi_cluster」をターゲットとして選択します。
「次へ」をクリックします。
「非XAドライバ」(デフォルト)を選択します。
「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。
|
注意: leasing表のマルチ・データ・ソースを作成するときに、名前を<MultiDS>-rac0、<MultiDS>-rac1などの形式で入力します。 |
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。
「次へ」をクリックします。
leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。
データ・ソースのターゲットをbi_clusterに設定します。
データ・ソースを選択して、右の画面に追加します。
Oracle RACデータベースの2つ目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをbi_clusterに設定してから、Oracle RACデータベースの2つ目のインスタンスについても同じ手順を繰り返します。
2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
「変更のアクティブ化」をクリックします。
この項では、ノード・マネージャのプロパティ・ファイルnodemanager.propertiesの編集方法について説明します。これは、サーバーの移行を構成する両方のノードのノード・マネージャに対して実行する必要があります。
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
Interface: このプロパティは、浮動IPのインタフェース名(たとえば、Linuxではeth0)を指定します。
|
注意: サブ・インタフェース( |
|
注意: Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: |
NetMask: このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります。このドキュメントの例では、255.255.255.0が使用されています。
UseMACBroadcast: このプロパティでは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、すなわち、arpingコマンドで-bフラグを使用するかどうかを指定します。
これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力は、次のように表示されます。
... StateCheckInterval=500 Interface=eth0 (Linux) or Interface="Local Area Connection" (Windows) NetMask=255.255.255.0 ...
|
注意: 次の手順は、サーバー・プロパティ(起動プロパティ)が適切に設定されていて、ノード・マネージャがリモートでサーバーを起動できる場合には不要です。 |
nodemanager.propertiesファイルで次のプロパティを設定します。
StartScriptEnabled: このプロパティをtrueに設定します。これは、ノード・マネージャが起動スクリプトを使用して管理対象サーバーを起動するために必要です。
WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、APPHOST1とAPPHOST2でノード・マネージャを起動します。
|
注意: 共有記憶域インストールからノード・マネージャを実行する場合、同じnodemanager.propertiesファイルを使用して複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個々のパラメータを指定します。たとえば、APPHOSTnで異なるインタフェース(eth3)を使用するには、インタフェース環境変数を「 |
この項では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する方法について説明します。
|
注意: Windowsでは、このスクリプトの名前は |
PATH環境変数に次のファイルが含まれていることを確認します。
wlsifconfig.shスクリプトに対するsudo構成権限を付与します。
パスワード・プロンプトを使用しないで機能するsudoを構成します。
セキュリティ上の理由から、sudoをwlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。
WebLogicユーザー(oracle)に、パスワードなしのsudo権限を付与し、/sbin/ifconfigと/sbin/arpingのバイナリの実行権限を付与します。
WebLogicユーザー(oracle)がスクリプトを実行できることを確認します。/etc/sudoers内の次のエントリ例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。
Defaults:oracle !requiretty oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
|
注意: この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。 |
この項では、サーバー移行ターゲットを構成する方法について説明します。まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成するには、次の手順を実行します。
管理コンソール(http://Host:Admin_Port/console)にログインします。通常、Admin_Portは7001(デフォルト)です。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
移行を構成する対象となるクラスタ(bi_cluster)を、表の「名前」列でクリックします。
「移行」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「APPHOST1」と「APPHOST2」を選択します。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。「変更のアクティブ化」をクリックします。
サーバー移行の候補マシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。
管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
|
ヒント: サーバーが実行されているマシンを表示するには、「サーバーのサマリー」ページで「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウに移動します。サーバーが自動的に移行される場合、これはこの構成とは異なります。 |
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。bi_server1については、「APPHOST2」を選択します。bi_server2については、「APPHOST1」を選択します。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。「変更のアクティブ化」をクリックします。
管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。
最後の手順は、サーバー移行をテストすることです。サーバー移行が適切に機能していることを確認する手順は次のとおりです。
APPHOST1から:
bi_server1管理対象サーバーを強制停止します。次のコマンドを実行します。
APPHOST1> kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
APPHOST1> ps -ef | grep bi_server1
|
注意: Windowsの場合は、 taskkill /f /pid <pid> <pid>は、管理対象サーバーのプロセスIDを表します。 管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、bi_servern管理対象サーバーのpidを確認します。
MW_HOME\jrockit_160_<version>\bin\jps -l -v
|
ノード・マネージャのコンソールを確認します。bi_server1の浮動IPが無効になっていることを示すメッセージが表示されます。
ノード・マネージャがbi_server1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
APPHOST2から:
ローカルのノード・マネージャのコンソールを確認します。APPHOST1でbi_server1の再起動が最後に試行されてから30秒経過した後、APPHOST2のノード・マネージャによって、bi_server1の浮動IPが有効化されようとしていること、およびこのノードでサーバーが再起動されようとしていることが示されます。
同じIPを使用していずれかのアプリケーション(BI Publisherなど)にアクセスします。
管理コンソールからの検証
管理コンソールで移行を検証することもできます。
管理コンソールにログインします。
左側のコンソールで、「ドメイン」をクリックします。
「監視」タブ→「移行」サブタイプをクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。
|
注意: サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。 |
Oracle BI EEトポロジをスケール・アップする際は、Oracle BI EE高可用性トポロジ内のいずれかの既存ノードに新たなシステム・コンポーネントを追加します。
この項では、ノードが2つ以上あり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがある高可用性トポロジを前提にします。トポロジをスケール・アップするには、いずれかの既存ノードで実行されているシステム・コンポーネントの数を増やします。
特定のノードで複数の管理対象サーバーを実行する必要はありません。
Oracle BI EEトポロジをスケール・アップする手順は次のとおりです。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「容量管理」をクリックしてから、「スケーラビリティ」をクリックします。
「構成をロックして編集」をクリックします。
矢印キーを使用して、「BIサーバー」、プレゼンテーション・サービスまたは「JavaHost」の数を変更します。
「適用」をクリックしてから、「変更のアクティブ化」をクリックします。
「概要」をクリックしてから、「再起動」をクリックします。
Oracle BI EEトポロジをスケール・アウトする際は、トポロジ内の新しいノード(APPHOST3)に、新しい管理対象サーバーとシステム・コンポーネント・セットを追加します。この項では、ノードが2つ以上あり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがある高可用性トポロジを前提にします。
この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。
Oracle Business Intelligenceの管理対象サーバーが稼働している既存ノードがトポロジ内に存在していること。
新しいノード(APPHOST3)が、Oracle WebLogic ServerとOracle Business Intelligence用の既存のホーム・ディレクトリにアクセスできます。
ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。新しいノードをインストールするときにバイナリ・ファイルとドメインに使用するディレクトリ・パスは、最初のノードに使用したものと同一にする必要があります。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、MW_HOME/.homeファイルを編集します。次の手順を参照してください。
新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。
APPHOST3でOracle Business Intelligenceをスケール・アウトする手順は次のとおりです。
APPHOST3で、Oracle Business Intelligenceのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。
APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/ APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>
Middlewareホーム・リストを更新するには、MW_HOME/.homeファイルを作成して(別のWebLogicインストールがノード内に存在する場合はそれを編集して)、それにORACLE_BASE/product/fmwを追加します。
VIP3をAPPHOST3で有効にします。第16.1.13.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。
第16.1.13.12項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームから構成アシスタントを実行します。
第16.1.13.13項「BIシステム・コンポーネントのスケール・アウト」の手順に従って、APPHOST3でシステム・コンポーネントをスケール・アウトします。
第16.1.13.15項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第16.1.13.16項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名検証を無効にすることで、bi_server3管理対象サーバーを構成します。
第16.1.13.18.4項「Oracle BI Publisher用のJMSの構成」の説明に従って、Oracle BI Publisher用のJMSを構成します。
第16.1.13.17項「Oracle BI for Microsoft OfficeのSSOプロパティの構成」の説明に従って、APPHOST3上のOracle BI for Microsoft Officeを構成します。
第16.1.13.18.5項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。
第16.1.13.20項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。
APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第16.1.13.9.2項「BI_SERVER1管理対象サーバーの起動と検証」および第16.1.13.9.3項「APPHOST1でのBI EEシステム・コンポーネントの起動と検証」を参照してください。
サーバー移行を構成します。
構成を検証するには、次のURLにアクセスします。
http://APPHOST3VHN1:9704/analyticsにアクセスして、bi_server3のステータスを確認します。
http://APPHOST3VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。
http://APPHOST3VHN1:9704/xmlpserverにアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。
ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信には、それぞれのアドレス用の証明書を使用する必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のノード・マネージャの設定に関する章を参照してください。
Oracle Business Intelligence Publisher(Oracle BI Publisher)は、複雑な分散環境に適用できる最も効率的でスケーラブルなレポート・ソリューションを提供します。セキュリティが高く適切なフォーマットで情報を生成して、従業員、顧客およびサプライヤに配信するための中央アーキテクチャを提供します。Oracle BI Publisherを使用すれば、ビジネス文書の開発、カスタマイズおよびメンテナンスにかかる高額なコストを削減しながら、レポート管理の効率性を向上させることができます。
この項では、Oracle BI Publisherの高可用性環境を設計およびデプロイする方法を説明します。
この項の項目は次のとおりです。
図16-10では、単一インスタンス・アーキテクチャでのOracle BI Publisherコンポーネントを示しています。
Oracle BI Publisherは、サーブレットベースのアーキテクチャを使用するJava EEアプリケーションです。JMSは、スケジュール済のジョブを実行するために使用されます。Fusion ESSは、Webサービスを通じてBI Publisherと統合します。
Oracle BI Publisherレポートの実行中は、セッション情報がメモリーに保管されます。
複数のサーバーにまたがってレポートの実行を移行する複雑性があるため、BI Publisherはステートレス・アプリケーションではありません。
Oracle BI Publisherは、WebLogic ServerにデプロイされるJava EEコンポーネントです。
Oracle BI Publisherのアーティファクトの処理(次のアーティファクトの作成、削除および編集を含む)
レポート
データ・モデル
レイアウト・テンプレート
スケジューラ・ジョブ
構成
スケジューラ・レポートの実行
オンライン・レポートの実行
Oracle BI Publisherは、Oracleインフラストラクチャに全面的に依存しています。Oracle BI Publisherをデプロイ、起動、停止および監視するには、管理コンソールを使用します。
JMSは、Oracle BI Publisherのバッチ・レポート処理システムのバックボーンとして使用されます。JMSは、トランザクション方式でメッセージング・ボードとして使用されます。すべてのレポートは次の実行段階に分けられます。
データの取得
データのフォーマット設定
レポートの配信
これらの各段階は、JMSキュー内のジョブ・リクエストとして表現されます。1つのノードが停止した場合、他のノードがそのキューへのサービス提供を続行します。ただし、レポート・ジョブが、これらの実行の段階(データ取得、データの書式設定またはレポートの配信)の1つにある場合、そのジョブは失敗としてマークされ、それを手動で再送信する必要があります。
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サービス: データを取得するために使用されます。
この項では、Oracle BI Publisherを高可用性環境で使用する場合の概要について説明します。
図16-11は、Oracle BI Publisherの高可用性アーキテクチャを示しています。
図16-11では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。
Oracle BI Publisherが実行されるWebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。APPHOST2上の管理サーバーはパッシブです。第3章「WebLogic Serverの高可用性」で説明されているように、APPHOST1が使用できなくなった場合、APPHOST2で管理サーバーをアクティブにできます。Oracle BI Publisherは、これらのホストのBI_SERVER1およびBI_SERVER2管理サーバーでデプロイされます。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。サーバー移行全体は、管理対象サーバー用に構成されます。
BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してVIPマッピングを有効にして(APPHOST1ではVIP1、APPHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。BIサーバーのサーバー移行を構成する方法の詳細は、第16.1.13.22項「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インスタンスは独立しています。
アーティファクトと構成は共有リポジトリに保管されており、各インスタンスは個別にこのリポジトリを読み取ります。
ノード・マネージャは、障害が発生したOracle BI Publisherインスタンスを再起動するように設定できます。
Oracle BI Publisherインスタンスが再起動されても、他の実行中インスタンスは影響を受けません。
ノードで障害が発生したときに生じる動作は次のとおりです。
シングル・サインオンが実装されていないデプロイメント環境では、ユーザーは再びログインするように求められます。
編集内容が含まれていたトランザクションはすべて保存されます。
Oracle BI Publisherのログは、次のデフォルト場所にあるWebLogic Serverのログに含まれています。
DOMAIN_HOME/servers/serverName/logs/serverName-diagnostic.log
また、次のファイルにはBI Publisher関連のメッセージが含まれています。
DOMAIN_HOME/servers/serverName/logs/bipublisher/bipublisher.log
構成情報は共有リポジトリに保管されています。構成ファイルは、共有リポジトリ内のAdminディレクトリに保管されています。
この項では、Oracle BI Publisherの2ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図16-11に示しています。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
この項では、BI Publisherの高可用性構成を設定するための前提条件について説明します。
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%';
図16-7で示すように、異なる仮想IPをリスニングするようにBI管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。インストールを実行する前に、各VIPが使用可能であり、アクセスできることを確認します。
表16-7 BI Publisherの仮想ホスト
| 仮想IP | 仮想IPのマップ先 | 説明 |
|---|---|---|
|
VIP1 |
APPHOST1VHN1 |
APPHOST1VHN1は、BI_SERVER1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、BI_SERVER1プロセスが実行されているノード(デフォルトはAPPHOST1)で有効化されます。 |
|
VIP2 |
APPHOST2VHN1 |
APPHOST2VHN1は、BI_SERVER2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、BI_SERVER2プロセスが実行されているノード(デフォルトはAPPHOST2)で有効化されます。 |
障害発生時に適切にリカバリできるようにするには、すべてのノードからアクセスできる場所にJMSとトランザクションの両方のログを格納して、管理対象サーバーで障害が発生した後にすべてのノードが操作を再開できるようにします。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表16-8は、共有記憶域の内容を示しています。
表16-8 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、BI_SERVER2にはBipJmsStore2。 |
|
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 nasfiler:/vol/volX/FMWshared MW_HOME-t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
クラスタに参加しているすべてのサーバーのクロックを、1秒以内の差異に収まるように同期する必要があります。クロックを同期するには、単一のネットワーク・タイム・サーバーを使用して各サーバーがそのネットワーク・タイム・サーバーを指すようにします。ネットワーク・タイム・サーバーを指すように設定する手順は、WindowsとLinuxでは異なります。使用するオペレーティング・システムのドキュメントを参照してください。
次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。
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 RepositoryをOracle RACデータベースにインストールしてください。
最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
Oracle BI Publisherをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとOracle BIスキーマをOracle RACデータベースにインストールします。次の手順を実行します。
リポジトリ作成ユーティリティ(RCU)のDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。
prompt> cd RCU_HOME/bin
prompt> ./rcu
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
データベース・タイプ: Oracle Databaseを選択します。
ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを次のように指定します:
BIDBHOST1-VIP
ポート: データベースのリスニング・ポート番号である1521を指定します。
サービス名: データベースのサービス名を指定します。
biha.mycompany.com
ユーザー名: DBA権限またはSYSDBA権限のあるユーザーの名前(SYS)を指定します。
パスワード: SYSユーザーのパスワードを入力します。
ロール: データベース・ユーザーのロール(SYSDBA)をリストで選択します(SYSユーザーに必要)。
「次へ」をクリックします。
「コンポーネントの選択」画面で、次を行います。
「接頭辞の新規作成」を選択し、BIHAのように、データベース・スキーマに使用する接頭辞を入力します。6文字まで接頭辞として指定できます。接頭辞を使用して、複数リポジトリの論理グルーピングをデータベースにおいて作成します。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
|
ヒント: このスキーマの名前をメモに記録してください。後述する手順でこの情報が必要になります。 |
次のコンポーネントを選択します。
o AS Common Schemas: Metadata Services (automatically selected) o Oracle Business Intelligence: Business Intelligence Platform
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択できます。
「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。
|
ヒント: スキーマ・パスワードの名前をメモに記録してください。後述する手順でこの情報が必要になります。 |
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
この項では、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のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。
この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。
サーバーが次の要件を満たしていることを確認します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンの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
Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXの場合:
./runinstallerコマンドを発行します。
Windowsの場合:
setup.exeをダブルクリックします。
「インベントリ・ディレクトリの指定」画面が表示されます。
「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /u01/app/oraInventory
オペレーティング・システムのグループ名: oinstall
次のメッセージのダイアログ・ボックスが表示されます。
「インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください」
rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。
これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。
|
注意: すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールで「Oracleインベントリ」画面が表示されない場合は、次の内容を確認してください。
|
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
「インストール場所の指定」画面で、次を指定します。
Oracle Middlewareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)
Oracleホーム・ディレクトリ: Oracle_WT1
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。
「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、WEBHOST1用に次の値を入力します。
インスタンス・ホームの場所: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1
インスタンス名: web1
OHSコンポーネント名: ohs1
「次へ」をクリックします。
「ポートの構成」画面で、次の操作を行います。
カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
Oracle HTTP Serverポートを入力します(例: 7777)。
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。
「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。「次へ」をクリックします。
「インストール完了」画面で「終了」をクリックして終了します。
WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランサを構成します。
この項では、WebLogic ServerとOracle Fusion Middleware BI EEを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。WebLogic ServerとBI PublisherをAPPHOST2にインストールするために、これと同じ手順を繰り返します(次ではAPPHOST1を対象にして説明しています)。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。
Oracle Fusion Middlewareの、次のコンポーネントをインストールします。
WebLogic Server
Oracle Fusion Middleware BI EE
WebLogic Serverをインストールする手順は次のとおりです。
WebLogic Serverのインストーラをインストール・メディアから起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します。
|
注意: ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。 |
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.6ディレクトリを受け入れます。そして「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
WebLogic Serverソフトウェアがインストールされます。
「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。
Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。
Oracle Fusion Middleware Business Intelligence 11gのインストーラを次のインストール・メディアから起動します。
UNIXの場合:
APPHOST1>./runInstaller
Windowsの場合:
APPHOST1> setup.exe
「インベントリ・ディレクトリの指定」画面で、次の操作を行います。
HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。
インストールを実行するユーザーのOSグループを入力します。
「次へ」をクリックします。
画面の手順に従って、/createCentralnventory.shをrootとして実行します。
「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「ソフトウェアのみインストール」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、前にインストールしたMiddlewareホームをドロップダウン・リストで選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(Oracle_BI1)を入力します。
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。
「サマリー」画面で「インストール」をクリックします。
「インストールの進行状況」画面で「次へ」をクリックします。
完了画面で「終了」をクリックします。
BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してマッピングされているVIPを有効にして(APPHOST1ではVIP1、APPHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。
この項では、Oracle Business Intelligence構成アシスタント、管理コンソールおよびOracle Enterprise Managerを使用して、ドメインと1つ目のWebLogic Server BI管理対象サーバーを作成する方法について説明します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
Oracleホーム・ディレクトリから構成アシスタントを実行して、BI Publisherが配置された管理対象サーバーおよび管理サーバーが含まれたドメインを作成します。
構成アシスタントの場所にディレクトリを移動します。
APPHOST1> cd ORACLE_HOME/bin
構成アシスタントを起動します。
UNIXの場合:
APPHOST1> ./config.sh
Windowsの場合:
APPHOST1> config.cmd
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。
BIシステムの作成またはスケールアウト画面が表示されます。新規BIシステムの作成を選択して、次の値を指定します。
ユーザー名: weblogic
ユーザー・パスワード: weblogicユーザーのパスワードを入力します。
ドメイン名: bifoundation_domain
「次へ」をクリックします。
「インストール場所の指定」画面で、次を入力します。
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
「次へ」をクリックします。
「コンポーネントの構成」画面で、Business Intelligence Publisherを選択します。
「次へ」をクリックします。
BIPLATFORMスキーマ画面で、次のように入力します。
データベース・タイプ: Oracle Database
接続文字列: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM
BIPLATFORMスキーマ・ユーザー名: BIHA_BIPLATFORM
BIPLATFORMスキーマ・パスワード: BIPLATFORMスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。
「ポートの構成」画面で、次のいずれかを選択します。
自動でポートを構成
構成ファイルを使用してポートを指定
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「サマリー」画面で「構成」をクリックします。
「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。
完了画面で「終了」をクリックします。
この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。
次のディレクトリに移動します。
ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/ AdminServer/security
次の行をファイルに入力し、ファイルを保存してからエディタを閉じます。
username=Admin_username password=Admin_password
|
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
この項では、APPHOST1で管理サーバーを起動および検証する手順について説明します。
APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。
APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin APPHOST1> ./startWebLogic.sh
管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「bi_server1」を選択します。
リスニング・アドレスをAPPHOST1VHN1に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
変更内容は、BI_SERVER1管理対象サーバーが再起動されるまでは有効になりません。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。
ホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「bi_server1」を選択します。設定ページが開きます。
「SSL」タブを開きます。
ページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
変更内容は、BI_SERVER1管理対象サーバーが再起動されるまでは有効になりません。
この項では、APPHOST1でノード・マネージャを起動する方法、およびAPPHOST1でBI_SERVER1管理対象サーバーを起動して検証する方法について説明します。
通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合、次のコマンドを使用してAPPHOST1で起動します。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
BI_SERVER1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は、次のとおりです。
管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」を選択します。
「制御」タブをクリックします。
「bi_server1」を選択してから、「起動」をクリックします。
管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
BI_SERVER1が起動すると、次のURLが使用できるようになります。
http://APPHOST1VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。
|
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。 |
http://APPHOST1VHN1:9704/xmlpserverにアクセスして、BI Publisherアプリケーションのステータスを確認します。
この項では、APPHOST2でBIシステムをスケール・アウトする前に、前提条件として実行するタスクについて説明します。
サーバー構成オプションを構成するには、次の手順を実行します。
DOMAIN_HOME/config/bipublisher/repositoryの内容を構成フォルダの共有場所にコピーします。
管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「サーバー構成」を選択します。
構成フォルダ用に次のフィールドを入力します。
パス: 構成フォルダの共有場所のパスを入力します。
変更を適用してから、BI Publisherアプリケーションを再起動します。
スケジューラ構成オプションを構成するには、次の手順を実行します。
管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「スケジューラ構成」を選択します。
「クォーツ・クラスタリング」を「スケジューラ選択」で選択します。
変更を適用してから、BI Publisherアプリケーションを再起動します。
この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLとJMS共有一時ディレクトリを更新します。
Oracle BI Publisher Schedulerの構成を更新する手順は次のとおりです。
次のURLにアクセスして、いずれかのOracle BI Publisherインスタンスにログインします。
http://APPHOST1VHN1:9704/xmlpserver http://APPHOST2VHN1:9704/xmlpserver
「管理」リンクをクリックします。
「スケジューラ構成」を「システム・メンテナンス」で選択します。
次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。
t3://bi_cluster
共有記憶域のあるディレクトリを入力して、「共有ディレクトリ」を更新します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。残りの手順を引き続き実行します。「適用」をクリックします。
スケジューラのステータスを「スケジューラ診断」タブでチェックします。
BIシステムをスケールアウトするには
構成アシスタントの場所にディレクトリを移動します。
APPHOST2> cd ORACLE_HOME/bin
構成アシスタントを起動します。
APPHOST2> ./config.sh
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
BIシステムのスケールアウトを選択して、次の値を入力します。
ホスト名: ADMINHOST
ポート: 7001
ユーザー名: weblogic
ユーザー・パスワード: weblogicユーザーのパスワードを入力します。
「次へ」をクリックします。
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(グレーアウトされています)
「次へ」をクリックします。
「ポートの構成」画面で、次のいずれかを選択します。
自動でポートを構成
構成ファイルを使用してポートを指定
「次へ」をクリックします。
「セキュリティ更新の指定」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。「次へ」をクリックします。
「サマリー」画面で「構成」をクリックします。
すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。
完了画面で「終了」をクリックします。
BI_SERVER2管理対象サーバー・リスニング・アドレスを設定する手順は次のとおりです。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「bi_server2」を選択します。
リスニング・アドレスをAPPHOST2VHN1に設定します。「保存」をクリックします。
変更を保存およびアクティブ化します。
この変更は、BI_SERVER2管理対象サーバーを再起動したときに有効になります。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。
ホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。「サーバー」をクリックします。
表の「名前」列で「bi_server2」を選択します。「SSL」タブを開きます。
ページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
変更を保存およびアクティブ化します。
この変更は、BI_SERVER2管理対象サーバーを再起動すると有効になります。
この項では、Oracle BI Publisherを構成する方法を説明します。
両方のノードから参照できるディレクトリに、すべての永続ストアの場所を構成する必要があります。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BipJmsStore」をクリックして、共有記憶域にあるディレクトリを入力します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「保存」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。
名前(例: BipJmsStore2)を入力し、BI_SERVER2をターゲットにします。APPHOST1とAPPHOST2の両方からアクセスできるように、共有記憶域にあるディレクトリを入力します。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「OK」をクリックして、変更をアクティブ化します。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSサーバー」ノードをクリックします。「JMSサーバーのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
新規をクリックします。
名前(例: BipJmsServer2)を入力してから「永続ストア」ドロップダウン・リストで「BipJmsStore2」を選択し、「次へ」をクリックします。
「BI_SERVER2」をターゲットとして選択します。
「終了」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BIPJmsResource」→「サブデプロイメント」タブをクリックします。
「サブデプロイメント」の「BipJmsSubDeployment」のターゲットを、BipJmsServer1とBipJmsServer2の両方にします。
「終了」→「変更のアクティブ化」をクリックします。
Oracle BI Publisherに対して実行したJMS構成を検証するには、第16.2.3.10.3項「Oracle BI Publisher Schedulerの構成の更新」の手順を実行してください。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。
|
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。 |
BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
表の「名前」列で、BI_SERVER1をクリックします。
「サービス」タブをクリックします。「チェンジ・センター」で、「ロックして編集」をクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。そのパス・ディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/bi_cluster/tlogs
「保存」→「変更のアクティブ化」をクリックします。
BI_SERVER2サーバーに対してこれらの手順を繰り返します。
|
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。 |
この項では、APPHOST2でシステムを起動する手順について説明します。
通常、ノード・マネージャはconfig.shの完了時に自動的に起動されます。ノード・マネージャが実行されていない場合、これをAPPHOST2で起動します。第16.2.3.9.1項「APPHOST1でのノード・マネージャの起動」にある手順を参照してください。
BI_SERVER2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は、次のとおりです。
管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」を選択します。「制御」タブをクリックします。
「bi_server2」を選択してから、「起動」をクリックします。
サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。その他のもの(AdminやFailedなど)が表示されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
BI_SERVER2が起動すると、次のURLが使用できるようになります。
http://APPHOST2VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。
|
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。 |
http://APPHOST2VHN1:9704/xmlpserverにアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。
BI_SERVERn管理対象サーバーを含むbi_clusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。
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 WLProxySSL ON WLProxySSLPassThrough ON </Location> # BI Publisher <Location /xmlpserver> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location>
WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。
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=ohs1
BI Serverのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。その他のもの(AdminやFailedなど)が表示されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
次の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へのルーティングとフェイルオーバーが適切に機能していることを確認する手順は、次のとおりです。
BI_SERVER2の実行中に、管理コンソールからBI_SERVER1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WEBHOST1:7777/wsm-pm
WEBHOST1:7777/xmlpserver
管理コンソールから、BI_SERVER1を開始します。
BI_SERVER2を停止します。
前述のステップ2のURLにアクセスして、適切な機能を検証します。
この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を構成する必要があります。これを行うには、第16.1.13.22項「BI_SERVERnサーバーのサーバー移行の構成」の指示に従ってください。
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ホーム・リストを更新する場合は、MW_HOME/.homeファイルを編集します。次の手順を参照してください。
新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。
APPHOST3でBI Publisherをスケール・アウトする手順は次のとおりです。
APPHOST3で、Oracle Business Intelligenceのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。
APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/ APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>
Middlewareホーム・リストを更新するには、MW_HOME/.homeファイルを作成して(別のWebLogicインストールがノード内に存在する場合はそれを編集して)、それにORACLE_BASE/product/fmwを追加します。
VIP3をAPPHOST3で有効にします。第16.2.3.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。
第16.2.3.11項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームから構成アシスタントを実行します。
第16.2.3.12項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第16.2.3.13項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名検証を無効にすることで、bi_server3管理対象サーバーを構成します。
第16.2.3.14.1項「BI Publisher用のJMS永続ストアの構成」の説明に従って、Oracle BI Publisher用のJMSを構成します。
第16.2.3.14.2項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。
第16.2.3.16項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。
APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第16.2.3.9.2項「BI_SERVER1管理対象サーバーの起動と検証」を参照してください。
第16.1.13.22.5項「サーバー移行ターゲットの構成」および第16.1.13.22.6項「サーバー移行のテスト」の説明に従って、サーバー移行を構成します。
構成を検証するには、http://APPHOST3VHN1:9704/xmlpserverというURLにアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。
ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信には、それぞれのアドレス用の証明書が必要です。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の「ノード・マネージャの設定」を参照してください。
Oracle Real-Time Decisions(Oracle RTD)を使用すると、選択元となる最善の選択肢について意思決定するための十分なコンテキストに基づいて、リクエストのオファーまたは選択肢のランク付きリストを提供できます。Oracle RTDでは常にフロントエンド・アプリケーションが使用されます。このアプリケーションの役割は、プロセス・フローを定義し、ユーザー操作を取得し、この操作をOracle RTDによる意思決定のための入力情報として解釈することです。したがってOracle RTDは、従来のWebアプリケーションというよりはむしろ意思決定サービスと見なすことができます。
この項では、Oracle RTDの高可用性環境を設計およびデプロイする方法を説明します。
この項の項目は次のとおりです。
図16-12では、Oracle RTDの単一インスタンス・アーキテクチャでの主要なコンポーネントを示しています。
図16-12には、次のコンポーネントが示されています。
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の外部のリソースにアクセスすることで)。
選択肢: 選択肢は、インライン・サービスを通じて提示されるオファー、またはOracle RTDの自己学習モデルによって追跡される調査ターゲットを表します。選択肢には、静的と動的という2つの形式があります。静的選択肢は、Decision Studioを使用してハードコーディングされます。動的選択肢は、外部データ・ソースで定義されて、インライン・サービスの実行時にロードされます。
ルール: ルールを使用して、移入のセグメントのターゲットを設定したり、選択肢が適格であるかどうか判断したり、特定の選択肢を評価したりします。ルールは、グラフィカルなルール・エディタを使用して作成されます。ルールは、インライン・サービスの実行時にDecision Serverによってロードされます。Oracle RTDには、外部ルールと呼ばれるルールのタイプがあります。これらのルールは、Oracle RTDの外部のデータ・ソースに保管されます。
エンティティ: エンティティは、Oracle RTDのモデリングと意思決定に使用されるデータの論理表現です。エンティティの属性は、統合点からの受信パラメータとしてデータ・ソースを介して入力することも、カスタム・ロジックを通じてリアルタイムに導出することもできます。
データ・ソース: データ・ソースは、表やストアード・プロシージャからデータを取得します。
統合点: 統合点は、Oracle RTDと連携動作する外部システムとの接点の役割を果たします。統合点には、インフォーマントとアドバイザという2種類があります。インフォーマントは外部システムからデータを受信するのに対して、アドバイザはデータを受信して外部システムに推奨情報を送信します。
モデル: 予測と報告という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の単一インスタンスとクラスタ全体の属性を構成するために使用されます。
この項では、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は可能性を計算するためにセッション情報を使用するのであり、ビジネス・トランザクションの状態を保管するためではありません(後者はトランザクション/運用システムに委ねられています)。したがって、セッション情報が失われてもビジネス・プロセスに悪影響は及ぼされません。
Oracle RTDは、Oracle Enterprise Manager Fusion Middleware Controlを介して管理されます。Fusion Middleware Controlを使用して、Oracle RTDのサービスを起動、停止、アンデプロイ、デプロイおよび監視します。
Oracle RTDのプロセス・フローは次のとおりです。
外部アプリケーションからOracle RTDの統合点に対してコールが発行されます。
このリクエストは、Oracle RTDの意思決定サービスのWebサービスに送信されます。このサービスはOracle Web Services Managerによって認証されてから、このリクエストを処理します。
このリクエストは、ターゲットとして設定されたインライン・サービスと、そのインライン・サービス内のターゲット・インフォーマントまたはターゲット・アドバイザに転送されます。
インフォーマントの処理に含まれるのは、ルールの実行、関数の実行、エンティティへのアクセスおよび学習レコードの作成です。
アドバイザの処理に含まれるのは、意思決定の実行、ルールの実行、適格性に関する関数の実行(フィルタリング)、エンティティへのアクセスおよび適格な選択肢のリストの返送です。
Oracle RTDの構成情報は自己完結型で、固有のデータベース・スキーマに格納されます。ただしインライン・サービスは、そのエンティティや外部ルールを外部データ・ソースからロードできます。
構成情報はOracle RTDデータベースに保管され、Fusion Middleware Controlを使用して更新されます。
データ・ソースの構成情報は、管理コンソールを使用して設定されます。
Oracle RTDのインライン・サービス は、Decision Studioで作成されます。開発者は、Decision Studioのデプロイメント機能を使用してインライン・サービスをデプロイします。インライン・サービスはOracle RTD Studioによってパッケージ化されて、Decision Serverのインスタンスにアップロードされます。Decision Serverは、すべてのアップロードされたインライン・サービスをOracle RTDの運用表に保管します。
Oracle RTDログ・ファイルは、Oracle Enterprise Manager Fusion Middleware Controlを使用して表示できます。Oracle RTDホーム・ページからログ・ファイルを表示するには、ナビゲータ・ペインでデプロイ済Oracle RTDアプリケーションを右クリックし、「ログ」→「ログ・ファイルの表示」を選択します。これにより、「ログ・メッセージ」画面が表示され、そこでログ・ファイルを表示できます。Oracle RTDログ・ファイルの表示の詳細は、Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイドを参照してください。
この項では、Oracle RTDを高可用性デプロイメントで使用する場合の概要について説明します。
図16-13は、Oracle RTDの高可用性アクティブ/アクティブ・アーキテクチャを示しています。
図16-13では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。
Oracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。第3章「WebLogic Serverの高可用性」で説明されているように、APPHOST1が使用できなくなった場合、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クラスタの考慮事項
クラスタ化インストールでは、RTDコンポーネントのインスタンスは、同じホスト上またはリモート・ホスト上にある他のRTDコンポーネントと通信する必要があります。それらのコンポーネントが同じホスト上にない場合は、内部リモート・プロシージャ・コール(RPC)メカニズムを使用してクラスタ・ホスト間で通信し、レスポンスを伝達します。
クラスタ内では、Decision Centerは、学習サービスと通信する必要があるため、通常は学習サービスと同じOracle RTDインスタンスにデプロイされます。ただし、Decision Centerはシングルトンではないため、アクティブな学習サービスとは異なる場所に配置されたインスタンスは、RPCを使用してアクティブな学習サービスと通信します。
クラスタ内では、Decision Centerは通常は意思決定サービスとは異なるOracle RTDインスタンスにデプロイされることで、Decision Centerがパフォーマンスとメモリーの面で意思決定サービスに与える影響が最小限に抑えられます。
クラスタ内では、非クラスタ化インストールで使用されるのと同じ内部WorkBench 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インスタンス間のクラスタ・メンバー内通信は、その内部のクラスタ内RPCテクノロジを通じて行われます。JMSの公開/サブスクライブ・モデルは、Oracle RTDデプロイメントで作成される「RTDTopic」という単一トピックとともに使用されます(Oracle RTDのWebLogicテンプレートで定義されます)。各Oracle RTDインスタンスは、この単一トピックにサブスクライブして、各インスタンスに該当するメッセージを読み取ります(フィルタリングを介して)。
Oracle RTD Serverは、セッション状態が不明なリクエストを受信することがあります。この場合は、リクエストを受信したDecision Serverは検索を実行して、このリクエストの本来の宛先であるDecision Serverを探します。その後、このリクエストは正しいDecision Serverに転送されます。転送側のDecision Serverは、このリクエストが受信側のDecision Serverによって完了されるのを待ちます。
転送されるリクエストは、RPCを介して送信されます。各Oracle RTD Serverは、各自に該当するすべてのメッセージをOracle RTD JMSトピックから取得します。
受信側のDecision Serverがリクエストを完了したら、コールはアンワインドされ、リクエストの転送元は、受信側のDecision Serverからレスポンスを受け取ります。このレスポンスはコール元に返送されます。
シングルトン・サービス
図16-13では、Oracle RTDの学習サービスとバッチ・マネージャはシングルトンです。学習サービスの役割は、1つ以上のOracle RTD意思決定サービス・インスタンスによって書き込まれたデータ・レコードから分析モデルを構築することです。分析モデルは、一連の入力値に基づいて、特定の結果が生じる可能性を提示します。たとえば分析モデルは、過去に購入された製品の履歴に基づいて、顧客が特定の製品を購入する可能性がどれだけあるのかを算定できます。学習モデルはメモリー内で構築されます。モデルの構築中にアクティブな学習サービスで障害が発生した場合は、新しい学習サービスがアクティブ化されて、データが失われることなくモデルを最初から構築します。バッチ・マネージャの役割は、バッチ管理クライアントのかわりにバッチ・ジョブを開始および管理することです。これは、他のOracle RTDインスタンス上のバッチ・エージェント・インスタンスと通信して、作業をクラスタ全体にわたって分散します。学習サービスとバッチ・マネージャはどちらも、アクティブ/スペア・シングルトンと見なされます。
クラスタ・コーディネータ
Oracle RTDには、次のタスクを実行する独自のクラスタ・コーディネータがあります。
学習サービス・シングルトンとバッチ・マネージャ・シングルトンという各タイプについて、ちょうど1つのシングルトンがアクティブになるようにします。クラスタ・シングルトンを起動または停止するのは、クラスタ・コーディネータだけです。
クラスタ・コーディネータは、クラスタを離れるメンバーによって開いた状態のまま放置されたリソースをクリーンアップします(このクリーンアップ・ロジックは、制御された手順に従ってノードが停止されるときに、そのノードが自身に対して通常実行するものと同じです)。コーディネータがこのクリーンアップを実行するのは、クラスタを離れようとしているノードが突然動作しなくなったために、そのノード自体のリソースを閉じることができなかった場合です。たとえば、クラスタ・メンバーによってホストされているすべてのDecision Centerセッションは、そのクラスタ・メンバーがクラスタを離れるときにコーディネータによって閉じられます。
各Oracle RTDクラスタ・メンバーは、その起動時に、クラスタ・コーディネータになろうとして競合します。そのために、データベースをトランザクション方式でテストして、別のインスタンスがすでにコーディネータになっているかどうかを確認し、他のコーディネータが存在しない場合は自身をコーディネータとしてデータベースに挿入します。コーディネータになるための権限は、そのコーディネータ自身によって定期的に更新されないと失効するため、コーディネータが動作不能になると、他のいずれかのクラスタ・メンバーがコーディネータになります。
各クラスタ・メンバーで動作しているOracle RTDトポロジ管理レイヤーは、データベース内の自身のハートビート・レコードを更新しなくなったクラスタ・メンバーを検知します。管理対象サーバー内の個別サービスの障害が発生しているかどうかは確認しません。このため、この項で説明する障害シナリオは、個別サービスの障害ではなく管理対象サーバーの障害を対象にしています。
Decision Serverで障害が発生した場合は、次のようになります。
Decision Serverと関連付けられたOracle RTDセッションは、それらのステートフル情報とともに失われます。
ロード・バランサは、障害が発生したサーバーを本来の宛先としていたリクエストを別のサーバーに転送します。
これらのリクエストを受信したサーバーは、新しいOracle RTDセッションを作成して、セッション・レベル・エンティティを適切なデータ・ソースからハイドレートして、そのリクエストに対応します。
学習レコードは、データベースに頻繁に書き込まれます。学習レコードは統計目的に使用されます。Decision Serverで障害が発生した場合は、次のようになります。
永続化されていない学習レコードはすべて失われます。
Oracle RTDは、特定の顧客の情報やアカウント情報などのトランザクション・データを一切保管しません。したがって、多数の学習レコードがすでに学習元として使用済であり、予測モデルが収束済の場合は、一部のデータが失われても重大な問題にはならず、可能性の計算は大きな影響を受けないため、Oracle RTDインフォーマントによって返されるオファーも大きな影響を受けません。
障害が発生したサーバーがクラスタ・コーディネータである場合は、次のようになります。
Oracle RTDデータベース内のタイムスタンプを更新しなくなります。
データベース表をポーリングしている他のサーバーは、タイムスタンプが無効になったこと、およびクラスタ・コーディネータで問題が発生している可能性があることを検知します。
すべてのアクティブなOracle RTDインスタンスは、新しいクラスタ・コーディネータになろうとして競合します。
学習モデルはメモリー内で構築されます。
モデルの構築中にアクティブな学習サービスで障害が発生した場合は、新しい学習サービスがアクティブ化されて、データが失われることなくモデルを最初から構築します。
アクティブな学習サービスが配置されたノードで障害が発生した場合は、クラスタ・コーディネータは、残りのクラスタ・ノード(学習サービスがデプロイおよび有効化されているノード)のいずれかで学習サービスをアクティブ化します。そのために、クラスタ・コーディネータは、クラスタ内RPCを介してOracle RTDインスタンスにコマンドを送信します。
Decision Centerで障害が発生した場合は、進行途中のユーザー作業のうち、保存されていなかった作業の内容はすべて失われます。たとえば、保存されていなかったルールの更新内容やパフォーマンス目標の変更内容が失われます。
1つのクラスタ内で複数のDecision Centerが実行されているため、ユーザーはアクティブなDecision Centerに接続されます。
アクティブなバッチ・マネージャが配置されたノードで障害が発生した場合は、クラスタ・コーディネータは、残りのノード(バッチ・マネージャがデプロイおよび有効化されているノード)のいずれかでバッチ・マネージャをアクティブ化します。
クラスタのバッチ・マネージャ・シングルトンで障害が発生した場合は、クラスタ・コーディネータはその障害を検知して、異なるホストで別のバッチ・マネージャを起動します。すべてのバッチ・エージェントには新しいバッチ・マネージャの存在が通知され、これらのバッチ・エージェントは自身をその新しいバッチ・マネージャに登録します。
バッチ・ジョブを実行しているノードで障害が発生した場合は、次のようになります。
障害が発生したサーバー上のバッチ・ジョブのみが処理を停止します。
障害が発生したノード上で実行されていたバッチ・ジョブはすべて中断状態になります。これらのバッチ・ジョブを手動で再開するには、バッチ・コンソールまたは他のバッチ管理クライアントを使用してバッチ・マネージャに対して再開コマンドを発行します。
中断されたジョブが再開されるときは、その状態がバッチ・マネージャと最後に同期された箇所から再開されます。バッチ・マネージャがジョブの再開を要求されると、バッチ・マネージャによって選択された使用可能なバッチ・エージェント上で、そのジョブが再開されます。
この項では、Oracle Real-Time Decisionsの2ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図16-13に示しています。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
この項では、Oracle RTDの高可用性構成を設定するための前提条件について説明します。
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%';
次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。
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 RepositoryをOracle RACデータベースにインストールしてください。
最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
Oracle RTDをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとOracle BIスキーマをOracle RACデータベースにインストールします。次の手順を実行します。
リポジトリ作成ユーティリティ(RCU)のDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。
prompt> cd RCU_HOME/bin
prompt> ./rcu
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
データベース・タイプ: Oracle Databaseを選択します。
ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを次のように指定します:
BIDBHOST1-VIP
ポート: データベースのリスニング・ポート番号である1521を指定します。
サービス名: データベースのサービス名を指定します。
biha.mycompany.com
ユーザー名: DBA権限またはSYSDBA権限のあるユーザーの名前(SYS)を指定します。
パスワード: SYSユーザーのパスワードを入力します。
ロール: データベース・ユーザーのロール(SYSDBA)をリストで選択します(SYSユーザーに必要)。
「次へ」をクリックします。
「コンポーネントの選択」画面で、次を行います。
「接頭辞の新規作成」を選択し、BIHAのように、データベース・スキーマに使用する接頭辞を入力します。6文字まで接頭辞として指定できます。接頭辞を使用して、複数リポジトリの論理グルーピングをデータベースにおいて作成します。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
|
ヒント: このスキーマの名前をメモに記録してください。後述する手順でこの情報が必要になります。 |
次のコンポーネントを選択します。
o AS Common Schemas: Metadata Services (automatically selected) o Oracle Business Intelligence: Business Intelligence Platform
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択できます。
「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。
|
ヒント: スキーマ・パスワードの名前をメモに記録してください。後述する手順でこの情報が必要になります。 |
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
この項では、Oracle RTDの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。
ロード・バランサ
Oracle RTDは、2つのOracle HTTP ServerがWeb層コンポーネントとして使用された高可用性構成でデプロイされた場合は、ハードウェア・ロード・バランサを使用します。
仮想サーバー名
bi.mycompany.comは、Oracle RTDなどのランタイムBIコンポーネント宛てのすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、bi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。
この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。
サーバーが次の要件を満たしていることを確認します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンの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
Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXの場合:
./runinstallerコマンドを発行します。
Windowsの場合:
setup.exeをダブルクリックします。
「インベントリ・ディレクトリの指定」画面が表示されます。
「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /u01/app/oraInventory
オペレーティング・システムのグループ名: oinstall
次のメッセージのダイアログ・ボックスが表示されます。
「インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください」
rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。
これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。
|
注意: Oracle製品がすでにホスト上でインストールされている場合、「Oracleインベントリ」画面は表示されません。「Oracleインベントリ」画面が開かない場合は、次のことを確認してください:
|
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
「インストール場所の指定」画面で、次を指定します。
Oracle Middlewareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)
Oracleホーム・ディレクトリ: Oracle_WT1
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。
「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、WEBHOST1用に次の値を入力します。
インスタンス・ホームの場所: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1
インスタンス名: web1
OHSコンポーネント名: ohs1
「次へ」をクリックします。
「ポートの構成」画面で、次の操作を行います。
カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
Oracle HTTP Serverポートを入力します(例: 7777)。
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。
「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。「次へ」をクリックします。
「インストール完了」画面で「終了」をクリックして終了します。
WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランサを構成します。
この項では、WebLogic ServerとOracle Fusion Middleware BI EEを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする方法について説明します。WebLogic ServerとOracle RTDをAPPHOST2にインストールするために、これと同じ手順を繰り返します(次ではAPPHOST1を対象にして説明しています)。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。
Oracle Fusion Middlewareの、次のコンポーネントをインストールします。
WebLogic Server
Oracle Fusion Middleware BI EE
Oracle WebLogic Serverをインストールするには:
WebLogic Serverのインストーラをインストール・メディアから起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します。
|
注意: ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。 |
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.6ディレクトリを受け入れます。そして「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
WebLogic Serverソフトウェアがインストールされます。
「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。
Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。
Oracle Fusion Middleware Business Intelligence 11gのインストーラを次のインストール・メディアから起動します。
UNIXの場合:
APPHOST1>./runInstaller
Windowsの場合:
APPHOST1> setup.exe
「インベントリ・ディレクトリの指定」画面で、次の操作を行います。
HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。
インストールを実行するユーザーのOSグループを入力します。
「次へ」をクリックします。
画面の手順に従って、/createCentralnventory.shをrootとして実行します。
「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「ソフトウェアのみインストール」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、前にインストールしたMiddlewareホームをドロップダウン・リストで選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(Oracle_BI1)を入力します。
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。
「サマリー」画面で「インストール」をクリックします。
Oracle Fusion Middleware Business Intelligence 11gソフトウェアがインストールされます。
「インストールの進行状況」画面で「次へ」をクリックします。
完了画面で「終了」をクリックします。
BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してマッピングされているVIPを有効にして(APPHOST1ではVIP1、APPHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。
この項では、Oracle Business Intelligence構成アシスタント、管理コンソールおよびOracle Enterprise Managerを使用して、ドメインと1つ目のWebLogic Server BI管理対象サーバーを作成する方法について説明します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
Oracleホーム・ディレクトリから構成アシスタントを実行して、Oracle RTDが配置された管理対象サーバーおよび管理サーバーが含まれたドメインを作成します。
構成アシスタントの場所にディレクトリを移動します。
APPHOST1> cd ORACLE_HOME/bin
構成アシスタントを起動します。
UNIXの場合:
APPHOST1> ./config.sh
Windowsの場合:
APPHOST1> config.bat
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。
BIシステムの作成またはスケールアウト画面が表示されます。新規BIシステムの作成を選択して、次の値を指定します。
ユーザー名: weblogic
ユーザー・パスワード: weblogicユーザーのパスワードを入力します。
ドメイン名: bifoundation_domain
「次へ」をクリックします。
「インストール場所の指定」画面で、次を入力します。
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
「次へ」をクリックします。
「コンポーネントの構成」画面で、Oracle Real-Time Decisionsを選択します。
「次へ」をクリックします。
BIPLATFORMスキーマ画面で、次のように入力します。
データベース・タイプ: Oracle Database
接続文字列: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM
BIPLATFORMスキーマ・ユーザー名: BIHA_BIPLATFORM
BIPLATFORMスキーマ・パスワード: BIPLATFORMスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。
「ポートの構成」画面で、次のいずれかを選択します。
自動でポートを構成
構成ファイルを使用してポートを指定
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「サマリー」画面で「構成」をクリックします。
「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。
完了画面で「終了」をクリックします。
この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。
次のディレクトリに移動します。
ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/ AdminServer/security
次の行をファイルに入力し、ファイルを保存してからエディタを閉じます。
username=Admin_username password=Admin_password
|
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
この項では、APPHOST1で管理サーバーを起動および検証する手順について説明します。
APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。
APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin APPHOST1> ./startWebLogic.sh
次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「bi_server1」を選択します。
リスニング・アドレスをAPPHOST1VHN1に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
変更内容は、BI_SERVER1管理対象サーバーが再起動されるまでは有効になりません。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。
ホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「bi_server1」を選択します。
「SSL」タブを開きます。
ページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
変更内容は、BI_SERVER1管理対象サーバーが再起動されるまでは有効になりません。
この項では、APPHOST1でノード・マネージャを起動する方法、およびAPPHOST1でBI_SERVER1管理対象サーバーを起動して検証する方法について説明します。
通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合、次のコマンドを使用してAPPHOST1で起動します。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
BI_SERVER1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は、次のとおりです。
管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」を選択します。
「制御」タブをクリックします。
「bi_server1」を選択してから、「起動」をクリックします。
管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
BI_SERVER1が起動してから、次の操作を実行します。
http://APPHOST1:9704/wsm-pmに移動して、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックして、データで使用できるポリシーとアサーション・テンプレートのリストを表示します。
|
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。 |
http://APPHOST1:9704/uiに移動して、Oracle RTD Decision Centerアプリケーションのステータスを確認します。
構成アシスタントをORACLE_HOMEディレクトリから実行して、BIシステムをスケール・アウトします。
構成アシスタントの場所にディレクトリを移動します。
APPHOST2> cd ORACLE_HOME/bin
構成アシスタントを起動します。
APPHOST2> ./config.sh
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
BIシステムの作成またはスケールアウト画面が表示されます。BIシステムのスケールアウトを選択して、次の値を入力します。
ホスト名: ADMINHOST
ポート: 7001
ユーザー名: weblogic
ユーザー・パスワード: weblogicユーザーのパスワードを入力します。
「次へ」をクリックします。
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(グレーアウトされています)
「次へ」をクリックします。
「ポートの構成」画面で、次のいずれかを選択します。
自動でポートを構成
構成ファイルを使用してポートを指定
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「サマリー」画面で「構成」をクリックします。
「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。
完了画面で「終了」をクリックします。
BI_SERVER2管理対象サーバー・リスニング・アドレスを設定する手順は次のとおりです。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「bi_server2」を選択します。
リスニング・アドレスをAPPHOST2VHN1に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
この変更は、BI_SERVER2管理対象サーバーを再起動するまで有効になりません。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。
ホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「bi_server2」を選択します。
「SSL」タブを開きます。
ページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
この変更内容は、管理サーバーが再起動されるまでは有効になりません(ノード・マネージャが実行中であることを確認してください)。
「サーバーのサマリー」画面で、「制御」タブを選択します。
表で「AdminServer(管理サーバー)」(ハイパーリンクとして表示)を選択してから、「停止」をクリックします。
コマンドラインから次のコマンドを実行して管理サーバーを再び起動します。
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')
この項では、Oracle RTDの構成について説明します。
Oracle Enterprise Manager Fusion Middleware Controlで次の手順を実行します。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「アプリケーション・デプロイメント」ノードを開きます。
「OracleRTD(11.1.1)(bi_cluster)」をクリックします。
その下の任意のノードをクリックします。たとえば、「 OracleRTD(11.1.1)(bi_server1) 」をクリックします。
右側のペインで、「アプリケーション・デプロイメント」をクリックして、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ペインで、「アプリケーション定義のMBean」を開きます。
Oracle RTDにあるサーバーごとに、MBeanに移動して、表16-9に示した属性を設定します。
「適用」をクリックします。
この項では、APPHOST2でシステムを起動する手順について説明します。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。
|
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。 |
BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「BI_SERVER1」(ハイパーリンクとして表示されています)を表の「名前」列でクリックします。
BI_SERVER1サーバーの設定ページが開き、「構成」タブがアクティブに表示されます。
「サービス」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようになります。
ORACLE_BASE/admin/domain_name/bi_cluster/tlogs
「保存」→「変更のアクティブ化」をクリックします。
BI_SERVER2サーバーに対してこれらの手順を繰り返します。
|
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。 |
通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、第16.3.3.9.1項「APPHOST1でのノード・マネージャの起動」の手順を繰り返して、APPHOST2でノード・マネージャを起動します。
BI_SERVER2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は、次のとおりです。
管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」を選択します。
「制御」タブをクリックします。
「bi_server2」を選択してから、「起動」をクリックします。
管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
BI_SERVER2が起動すると、次のURLが使用できるようになります。
http://APPHOST2:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックして、データで使用できるポリシーとアサーション・テンプレートのリストを表示します。
|
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。 |
http://APPHOST2:9704/uiにアクセスして、Oracle RTD Decision Centerアプリケーションのステータスを確認します。
BI_SERVERn管理対象サーバーを含むbi_clusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。
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 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /schema> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /ws> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # WSM-PM <Location /wsm-pm> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # RTD <Location /ui> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location>
WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。
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=ohs1
管理コンソールで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へのルーティングとフェイルオーバーが適切に機能していることを確認します。
BI_SERVER2の実行中に、管理コンソールからBI_SERVER1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WEBHOST1:7777/wsm-pm
WEBHOST1:7777/ui
管理コンソールからBI_SERVER1を起動します。
BI_SERVER2を停止します。
前述のステップ2のURLにアクセスして、適切な機能を検証します。
この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を構成する必要があります。これを行うには、第16.1.13.22項「BI_SERVERnサーバーのサーバー移行の構成」の指示に従ってください。
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ホーム・リストを更新する場合は、MW_HOME/.homeファイルを編集します。次の手順を参照してください。
新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。
APPHOST3でOracle RTDをスケール・アウトする手順は次のとおりです。
APPHOST3で、Oracle Business Intelligenceのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。
APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/ APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>
Middlewareホーム・リストを更新するには、MW_HOME/.homeファイルを作成して(別のWebLogicインストールがノード内に存在する場合はそれを編集して)、それにORACLE_BASE/product/fmwを追加します。
VIP3をAPPHOST3で有効にします。第16.2.3.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。
第16.3.3.10項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームから構成アシスタントを実行します。
第16.3.3.11項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第16.3.3.12項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名検証を無効にすることで、bi_server3管理対象サーバーを構成します。
第16.3.3.13項「Oracle RTDの構成」の手順に従って、APPHOST3上のbi_server3管理対象サーバーに対して追加のOracle Real-Time Decisions構成手順を実行します。
第16.3.3.14.1項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。
第16.3.3.15,項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。
APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第16.3.3.9.2項「BI_SERVER1管理対象サーバーの起動と検証」を参照してください。
構成を検証するには、http://APPHOST3VHN1:9704/uiというURLにアクセスして、Oracle RTDアプリケーションのステータスを確認します。
ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の「ノード・マネージャの設定」を参照してください。
