Oracle Business Intelligenceは、ビジネス・ユーザーに組織の全体像を提供する統合ビジネス・インテリジェンス(BI)ソリューションです。Oracle Business Intelligenceは、迅速かつ簡単に様々なデータ・ソースを統合し、データベースの情報を検索し、データベース情報を共有して、企業およびその顧客に関する情報を得るためにデータを有効に利用することを目的として設計されています。
この章では、次のトピックによりこれらのOracle Business Intelligenceコンポーネントの高可用性について説明します。
この章では、Oracle Business Intelligenceについて理解していることを前提としています。そうでない場合は、Oracle Business Intelligenceのドキュメントを参照してください。
この項では、Oracle Business Intelligence Enterprise Edition(Oracle BI EE)の概要について、およびOracle BI EEの高可用性環境を設計およびデプロイする方法について説明します。
Oracle BI EEは、Oracle Business Intelligence Applicationsなどのいくつかのアプリケーションが含まれたOracle Business Intelligenceの一部です。Oracle Business Intelligenceは、包括的なエンタープライズ・ビジネス・インテリジェンス機能の集合体であり、これらの機能としては、インタラクティブ・ダッシュボード、完全アドホック式の先行型インテリジェンスとアラート、企業レポートと財務レポート、リアルタイム予測インテリジェンスなどがあります。Oracle Business Intelligenceプラットフォームは、包括的なビジネス・インテリジェンス機能を提供するだけでなく、真の次世代ビジネス・インテリジェンス機能を提供する実績ある最新型のWebサービス指向アーキテクチャをベースとしています。
企業は、製品、顧客、価格、連絡先、業務活動、資産、商談、従業員などの様々なビジネス要素に関する大量のデータを追跡および保管しています。これらのデータは多くの場合、様々な場所に配置された複数のデータベースにまたがって分散されており、これらのデータベースでは異なるバージョンのデータベース・ソフトウェアが使用されています。Oracle BI EEは、各種データを収集および編成してから編成データをユーザーに表示できる堅牢なアプリケーションです。ユーザーは、これらのデータを分析および解釈して、その結果に基づいて対処できます。
Oracle BI EEに関するその他の概要は、『Oracle Fusion Middlewareユーザーズ・ガイドfor Oracle Business Intelligence Enterprise Edition』を参照してください。
この項の項目は次のとおりです。
図15-1では、単一インスタンス・アーキテクチャでのOracle BI EEコンポーネントを示しています。Javaコンポーネントとシステム・コンポーネント間のすべての通信は、HTTP経由のSOAPメッセージを介して行われます。
図15-1に示しているポート番号は、単一マシン上に各コンポーネント・タイプのコンポーネントが1つだけ配置された単純なインストール環境用のデフォルト・ポート番号です。Oracle Enterprise Manager Fusion Middleware Controlを使用する場合、ポート番号の範囲を選択可能であり、Enterprise Managerによってポート番号が割り当てられます。
次に、Oracle BI EEシステム・コンポーネントの機能について概要を説明します。
Oracle BIプレゼンテーション・サービス(プレゼンテーション・サービス): これは、ユーザー・インタフェース・ページを生成し、Oracle BI Schedulerにかわって結果セットをレンダリングするC++プロセスです。複数のプレゼンテーション・サービス・プロセスを構成でき、それらで負荷を共有できます。プレゼンテーション・サービス・プロセス間でセッション・レプリケーションは行われません。
プレゼンテーション・サービスはほぼステートレスです。唯一の重要な状態はクライアント認証です。シングル・サインオンを使用して認証するようにOracle Business Intelligenceが構成されている場合、ユーザーはフェイルオーバー後に再認証する必要はありません。他のすべての認証方式では、フェイルオーバーが発生すると、クライアントは再認証する必要があります。クライアントに対するサービスは中断され、クライアントはログイン・ページにリダイレクトされます。
Oracle Business Intelligence Server(BI Server): これは、データ操作を実行したりデータ・ソースからデータを収集するC++プロセスです。負荷を共有する複数のBI Serverプロセスを構成できます。BI Serverプロセス間では、セッション・レプリケーションは行われません。
BI Serverでは、ユーザー・セッション状態は保持されません。高可用性デプロイメントの場合は、問合せ結果はグローバル・キャッシュに格納されます。
JavaHost: これは、大量のリソースを消費するグラフやPDFのレンダリングを含むJavaプロセスです。負荷を共有する複数のJavaHostプロセスを構成できます。JavaHostプロセス間では、セッション・レプリケーションは行われません。
JavaHostはステートレス・プロセスです。
Cluster Controller: これは、BI ServerとOracle BI Schedulerの集合を管理するC++プロセスです。
Oracle Business Intelligence Scheduler(Oracle BI Scheduler): これは、時刻が指定されたスケジュールに従ってジョブを実行するC++プロセスです。ジョブは、Oracle BIプレゼンテーション・カタログで作成されたエージェントの場合や、ジョブ・マネージャによって作成されたジョブの場合があります。
次に、Oracle BI EE Javaコンポーネントの機能について概要を説明します。
Oracle BIプレゼンテーション・サービスのプラグイン・サーブレット: プレゼンテーション・サービスはプレゼンテーション・サーバーですが、Webサーバーではないため、Webサーバー・プラグインAPIを認識しません。Oracle BIプレゼンテーション・サービスのプラグインは、HTTPリクエストをプレゼンテーション・サービスに転送します。HTTPリクエストは、ブラウザ・ベースのユーザー・インタフェースからのリクエストまたはSOAPリクエストです。
Webサービス:
アクション実行サービス: このWebサービスは、プレゼンテーション・サービスとOracle BI Schedulerのかわりにアクションを実行します。アクションは、サード・パーティWebサービスのコールである場合や、EJBとして実行されるユーザー提供Javaコードのコールである場合があります。
アクション・レジストリWebサービス: このWebサービスはアクションのリストを提供します。
アクション場所サービス: このWebサービスにより間接レベルが実現されるため、アクションを顧客のテスト環境で開発してから、すべてのアクション定義を本番ソースを指すように変更することなく、開発アクションを本番環境にデプロイできます。
SOA用Webサービス: これはサーブレットであるとともに、Oracle BIプレゼンテーション・カタログのコンテンツに対するWebサービス・インタフェースを提供する関連Webサービスです。Oracle BIプレゼンテーション・カタログ内のオブジェクトのツリーは、WSDLリーフを持つWSILツリーによって定義されたWebサービスのツリーとして公開されます。
セキュリティWebサービス: 標準に基づいた認証サービスと移入サービスを提供します。
Oracle BI EEの各システム・コンポーネントは、OPMNによって制御され、Oracle Enterprise Manager Fusion Middleware ControlのOracle BI EE管理ページを使用して起動および停止されます。
Oracle BI EEの各Javaコンポーネントは、管理対象のOracle WebLogic Serverによってホストされ、Oracle WebLogic Server管理コンソールを使用して制御されます。それぞれの管理対象Oracle WebLogic Serverは、ローカルのWebLogicノード・マネージャによって監視および(必要に応じて)再起動されます。
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コンポーネントは、次の場所の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システム・コンポーネントがデプロイされるときのログ・ファイルの場所については、第15.1.1.1.5項「ログ・ファイルの場所」を参照してください。
表15-1には、Oracle BI EEシステム・コンポーネントのログ・ファイルを示しています。これらのすべてのログ・ファイルには、Enterprise Manager Fusion Middleware Controlからアクセスできます。
表15-1 Oracle BI EEシステム・コンポーネントのログ・ファイル
BIコンポーネント | ログ・ファイル | ログ・ファイルのディレクトリ |
---|---|---|
OPMN |
debug.log |
ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn |
OPMN |
opmn.log |
ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn |
BI Server |
nqserver.log |
ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication_obis1 |
BI Cluster Controller |
nqcluster.log |
ORACLE_INSTANCE/diagnostics/logs/OracleBIClusterControllerComponent/coreapplication_obiccs1 |
Oracle BI Scheduler |
nqscheduler.log |
ORACLE_INSTANCE/diagnostics/logs/OracleBISchedulerComponent/coreapplication_obisch1 |
プレゼンテーション・サービス |
sawlog*.log(例: sawlog0.log) |
ORACLE_INSTANCE/diagnostics/logs/OracleBIPresentationServicesComponent/coreapplication_obips1 |
BI JavaHost |
jh.log |
ORACLE_INSTANCE/diagnostics/logs/OracleBIJavaHostComponent/coreapplication_objh1 |
この項では、Oracle BI EEを高可用性デプロイメントで使用する場合の概要について説明します。
Oracle BI EEは、プロセス・レプリケーションと高可用性ストレージ(データベースと共有ファイル・システム)の組合せを通じて高可用性を実現します。
高可用性システムを実現するには、Oracle BI EEは次の外部サービスを必要とします。
フォルト・トレラントのHTTPロード・バランサ
高可用性の共有ファイル・システム
Oracle BI Schedulerおよびファクト表用の高可用性データベース
次のシステム・コンポーネントをレプリケートする必要があります(2つ以上のインスタンスを確保)。
プレゼンテーション・サービス
Cluster Controller
Oracle BI Scheduler
BI Server
JavaHost
これらのシステム・コンポーネントのインスタンスが2つ以上ない場合は、高可用性要件が満たされず、Enterprise Manager Fusion Middleware Controlの構成ユーザー・インタフェースでは管理者に対して警告が表示されます。
次の永続データ・ソースは、高可用性の共有ファイル・システムに配置される必要があります。
RPD公開ディレクトリ: サーバー・メタデータは、各BI Serverに対してローカルであるリポジトリ・ファイル(.rpdファイル)に含まれています。1台のBI Serverがマスターとして指定されます。rpdファイルへのオンライン変更はマスターBI Server上で行われ、これらの変更内容はクラスタの他のメンバーにレプリケートされます。
Oracle BIプレゼンテーション・カタログ
グローバル・キャッシュ(必須ではありませんが、高いパフォーマンスを得るためにお薦めします): グローバル・キャッシュ機能は、キャッシュ・シード・イベントおよびキャッシュ・パージ・イベントを格納する共通問合せキャッシュのサポートを提供します。グローバル・キャッシュ機能は、クラスタ内のすべてのBI Serverから参照できます。
スケジューラ・スクリプト
また、Oracle BIプレゼンテーション・サービス・プラグインや認証サービスなどのOracle BI EE Javaコンポーネントをホストするために、2つ以上のメンバーで構成されるWebLogicクラスタも必要です。
図15-2には、Oracle BI EEの高可用性デプロイメントを示しています。
図15-2では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。
Oracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。APPHOST1が使用できなくなると、第3章「WebLogic Serverの高可用性」の説明に従って、管理サーバーをAPPHOST2でアクティブにできます。Oracle BI EEとOracle BI PublisherのJavaコンポーネントは、これらのホスト上のBI_SERVER1管理対象サーバーとBI_SERVER2管理対象サーバーにデプロイされます(この図で示しているOracle BI Publisherは、Oracle BI EEとは別個のコンポーネントであることに注目してください)。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。サーバー移行全体は、管理対象サーバー用に構成されます。
BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してVIPマッピングを有効にして(APPHOST1ではVIP1、APPHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。BIサーバーのサーバー移行を構成する方法の詳細は、第15.1.3.21項「BI_SERVERnサーバーのサーバー移行の構成」を参照してください。
Oracle BIプレゼンテーション・サービス、JavaHost、Oracle BI Cluster Controller、Oracle BI SchedulerおよびOracle BI Serverは、APPHOST1およびAPPHOST2にインストールされてクラスタとして構成されたシステム・コンポーネントです。APPHOST2上のCluster ControllerとSchedulerはパッシブであり(これらは起動されますがリクエストを処理しません)、APPHOST1のコンポーネントで障害が発生した場合にのみアクティブ化されます。
データ層では、カタログ、問合せキャッシュ、RPDおよびSchedulerのスクリプト・データを格納するために、共有外部記憶域が設定されます。Oracle RACデータベースは、BI EEスキーマ・メタデータとBI Publisherリポジトリ・データを格納するために使用され、エンタープライズ・データベース用としてもお薦めします。
次の各項では、いくつかのOracle BI EEコンポーネントの高可用性情報について説明します。
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を識別するとともに、これらがリスニングするポートを識別します。中央で管理されている構成が変更されるたびに、ODBCデータ・ソース名(DSN)内の接続パラメータは、中央に配置されたBIドメイン構成ファイルに基づいて自動的に構成されます。このため、Oracle BI ODBC DSN接続パラメータをローカルで変更しないでください。
Cluster Controllerは、プレゼンテーション・サービスが接続するOracle BI Serverインスタンスを割り当てます。Oracle BI Serverへの接続はODBCを介して確立され、同じセッション内の後続のリクエストは、プレゼンテーション・サービスから、割り当てられたOracle BI Serverに直接送信されます。プレゼンテーション・サービスとOracle BI Serverとの間のODBCセッションは、ステートフルであり、セッション存続時間の間、アフィニティを保持する必要があります。
Oracle BI Schedulerと通信するために、プレゼンテーション・サービスはまずCluster Controllerと通信し、それからアクティブなOracle BI Schedulerインスタンスにリレーします。その後、プレゼンテーション・サービスは適切なOracle BI Schedulerインスタンスとのセッションを確立します。Cluster ControllerおよびOracle BI SchedulerインスタンスのホストとOracleインスタンス名は、Fusion Middleware Controlの「容量管理」ページの「可用性」タブで指定します。
Cluster Controllerは、プレゼンテーション・サービスなどのクライアントからの新しいBI ServerセッションやOracle BI Schedulerセッションにとって最初の通信先です。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 Schedulerインスタンスも含む)の動作も監視します。
Cluster Controllerでサポートされているものは、次のとおりです。
サーバーおよびOracle BI Schedulerの障害の検出。
サーバーに障害が発生した場合のODBCクライアントに対するフェイルオーバー。
Cluster Controllerは、実行時にアクティブOracle BI Schedulerインスタンスも判別します。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は、Oracleデータベースを含む多くのデータベース・タイプとの通信をサポートしています。これらのBI Serverデータ・リポジトリには、未加工のファクト表が保持されています。Oracle BI EEはBI Serverデータ・リポジトリにメタデータを保管しません。すべてのメタデータは、RPDファイルまたは(プレゼンテーション・サービスの場合は)Oracle BIプレゼンテーション・カタログに保管されます。
Oracle BI Schedulerは、Oracle BI Schedulerスキーマにデータを保管します。Oracle BI Schedulerのデータベース接続構成では、BI Serverと同じライブラリが使用されるため、フォルト・トレランス特性は同じです。唯一の違いは、Oracle BI Schedulerの操作の方がはるかに書込みが多いことです。BI Serverのデータ・ソースは主に読取り専用です。
BI Serverのデータベース操作の主なポイントは次のとおりです。
ソース・データベース: ソース・データベースはOracle BI EEのレポート用に使用されます。これらは主に読取り専用です。ソース・データベースについては多くのオプションがサポートされています。
イベント・ポーリング: ファイル・システムからのキャッシュの削除や作成を常時チェックします。
使用状況トラッキング
ライト・バック機能: ユーザー主導型の機能です。
実装では次の特性が実現されます。
すべてのデータベース読取り/書込み操作はC++コードによって実行されます。
Oracleデータベースの場合は、OCIが使用されます。他のデータベースやデータ・ソースの場合は、ネイティブ・データベース機能が使用されます。
Oracleデータベースと非Oracleデータベースのサポートは、ソース・データベースについてだけでなく、Oracle BI Schedulerについても可能です。
管理ツールでは、プレゼンテーション・サービスで使用されるのと同じOracle BI ODBC DSNが使用されます。それは、Cluster ControllerによってマスターBI Serverに接続されます。マスターBI Serverが使用不能な場合は、管理ツールはRPDファイルへの書込みを実行できません。
Oracle BI Schedulerインスタンスは、アクティブ/パッシブ・モデルに基づいて動作します。どの時点でも、1つのOracle BI Schedulerのみがアクティブになってリクエストを処理します。これにより、新しいジョブに一意のジョブIDが割り当てられます。非アクティブなOracle BI Schedulerインスタンスはアイドル状態のまま待機し、アクティブなOracle BI Schedulerで障害が発生した場合に引継ぎを要請されるまで、ジョブを処理しません。
インストールされた複数のOracle BIが同じスケジューラ表を使用するように構成しないでください。このように構成した場合は、複数のBI Schedulerがアクティブになり、一意のジョブIDが割り当てられなくなります。
Oracle BI Schedulerは、BI Serverと同じデータベース・テクノロジを使用します。
Oracle BI Schedulerは稼働しているが、データベースが停止している場合、失敗したトランザクションはOracle BI Schedulerによってそのメモリー内のキューに格納され、正常に処理されるまで再試行されます。したがって、バックエンド・データベース・ソースをメンテナンスのために停止した場合、そのデータベースの再起動時にOracle BI EEのプロセスを再起動する必要はありません。これらは、Oracle BI Schedulerでの定期的パージと同じカウントで再試行されるため、同じ構成値を使用します。Oracle BI EEは、Oracle BI EEのメタデータに含まれている必要のある文のみを再試行します。つまり、問合せは再試行されず、挿入と削除のみが再試行されます(再実行される削除は除く)。このための構成値は、Oracle BI Schedulerのinstanceconfig.xml
ファイルで確認できます(PurgeIntervalMinutes)。
Oracle BI Schedulerは、Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブで定義されたポート範囲から割り当てられたポート上で、Cluster Controller通信およびクライアント・リクエストをリスニングします。
Oracle BI JavaHostコンポーネントは、Oracle BIプレゼンテーション・サービスが、Oracle BI Scheduler、Oracle BI Publisherおよびグラフ生成のためのJavaタスクなど様々なコンポーネントをサポートできるようにするサービスを提供します。他のすべてのコンポーネントと同様に、管理者は、デプロイするインスタンスの数と場所をFusion Middleware Controlを使用して制御できます。JavaHostクライアントのデフォルト構成では、すべての使用可能なJavaHostが使用されます。これは、ローカルJavaHostのみを使用する以前の10gのデフォルト構成とは異なります。
JavaHostサービスは、Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブで定義されたポート範囲から割り当てられたポート上のプレゼンテーション・サービスおよびOracle BI Schedulerからリクエストを受信します。
Oracle BI EEでは、プロセスの状態は、分散通信プロトコルを介してではなく、共有ファイル・システムとデータベースを介して共有されます。特に、Oracle BI EEは、プロセス内やJavaコンポーネント内の状態を保管しません。したがってOracle BI EEは、コンポーネントの状態をシリアライズして、Javaクラスタ内で配信できるようにする必要はありません。
ファクト表とOracle BI Schedulerの表は、それぞれBI Serverインスタンス間とOracle BI Schedulerインスタンス間で共有されます。この共有と比べると、ファイル・システムの共有はあまり標準的ではないため、これについてはこの項の後半で詳しく説明します。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 Schedulerスクリプトのネットワーク共有を作成する必要があります。このためには、Oracle BI Schedulerのinstanceconfig.xml
ファイル(ORACLE_INSTANCE/config/OracleBISchedulerComponent/coreapplication_obischnにあります)のSchedulerScriptPath要素とDefaultScriptPath要素を更新します。Oracle BI Schedulerサーバーは、この共有に対する読取りと書込みのアクセス権を持っている必要があります。
プロセス間には依存関係があるため、クラスタを特定の順序で起動する必要があります。起動手順は次のとおりです。
すべてのWebLogic管理対象サーバーを起動します。システム・コンポーネントは、それぞれのローカル管理対象サーバーから認証サービスを受けます。
Fusion Middleware Controlの「すべて起動」ボタンを使用して他のプロセスを起動します。「すべて起動」ボタンを使用すると、Javaアプリケーションおよびシステム・コンポーネントが適切な起動順序で起動します。
構成の変更は高可用性にとって非常に重要であり、その中でもクラスタのメンバーに対する変更は特に重要です。クラスタに新しいメンバーを追加できないと、障害を修復できず、クラスタはその後の障害に対して脆弱になります(このため、高可用性システムでは平均修復時間は平均故障間隔と同じくらい重要です)。
Javaとシステムという2つのテクノロジ・スタックは別々に管理されます。
WebLogicの構成変更は、Oracle WebLogic管理コンソールで行います。標準のWebLogicメカニズムを使用して、変更中の構成をロックして、変更内容をすべての管理対象サーバーに伝播します。
システム・コンポーネントの構成変更は、Fusion Middleware Controlを使用して中央で行います。すべての構成変更を入力した後に、ユーザーが「保存」をクリックすると、構成の変更内容はすべてのローカル構成ファイルに伝播されます。この伝播は重要です。構成が破損するか伝播に失敗した場合は、次の伝播によってローカル・ファイルが修正されます。ファイルの配信は、WebLogic構成ファイル配信と似たOracle JMX拡張によって実現されます。リモート・サイトでの配信は、JMX Meanコールによってアナウンスされます。MBeanはMBeanサーバーでホストされる必要があるため、これは、Oracle BI EEシステム・コンポーネントをホストしているすべてのマシンは、どのようなOracle BI EE Javaコンポーネントもホストしていない場合でも、WebLogic管理対象サーバーも備えている必要があることを意味します。
すべてのコンポーネントは、そのコンポーネントが次回に再起動されたときに初めて構成変更にアクセスします。コンポーネントの稼働中に構成変更は適用されません。
構成変更は次の場合にトリガーされます。
Fusion Middleware Controlで加えられた変更を管理者がコミットした場合。
MBean API(このAPIにはFusion Middleware Controlのユーザー・インタフェースが直接反映されます)によって加えられた変更を管理者がコミットした場合。
新しいインストールを登録するエンタープライズ・インストールによって構成の配信はトリガーされません。これによって、管理者がFusion Middleware Controlから選択できるマシンの集合が変更されます。新しいコンポーネント・インスタンスは構成に自動的に追加されません。
この項では、発生する可能性のある様々な種類の障害と、各種類の障害が発生したときに予想される動作について説明します。
マシンで一時的な障害が発生した場合、クラスタは再起動されたコンポーネントを検知して、それらのコンポーネントを再び使用し始めます。マシンで永続的な障害が発生した場合は、そのマシンを交換する必要があります。既存のクラスタを拡張するエンタープライズ・インストールを使用して、新しいマシンに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クラスタの状態のメンテナンスについて配慮する必要はありません。
システム・コンポーネントから管理対象サーバーへのすべての通信では(例: プレゼンテーション・サービスからアクション・サービスへの通信)、ローカル管理対象サーバーに対するHTTPが使用されます。ローカル管理対象サーバーで障害が発生した場合は、ノード・マネージャによってそれが再起動されます。マシン全体にわたる障害は発生していないが、管理対象サーバーを再起動できない場合は、同じマシンで実行されているシステム・コンポーネントは次のような影響を受けます。
BI Server: ローカル管理対象サーバーが正常に稼働するまでサービスを停止し、これにより、BI Serverを介したログインが影響を受けることが防止されます。ローカル管理対象サーバーが稼働していないことをBI Serverが検知すると、ログイン・リクエストを他のBI Serverに送信するようにCluster Controllerに指示します。
プレゼンテーション・サービス: アクションを実行できません。
Oracle BI Scheduler: アクティブ・スケジューラがこのマシン上で実行されている場合、スケジュール済アクションを実行できません。
新しいScheduler接続(ジョブ・マネージャなどから)を確立できません。ローカル管理対象サーバーが稼働していないホスト上のOracle BI Schedulerは、新しいユーザーを認証できません。
管理対象サーバーをオフラインにする必要がある場合は、まず該当するマシン上で実行されているすべてのシステム・コンポーネントを停止します。特定のマシン上の管理対象サーバーがなんらかの理由によって使用不能になった場合は、そのマシン上で実行されているすべてのシステム・コンポーネントを停止することをお薦めします。
Oracle BI Schedulerは、Cluster Controllerによって監視および管理されます。Oracle BI Schedulerが使用不能な場合は、Cluster Controllerは、次のアクティブ化対象Oracle BI Schedulerインスタンスを決定します。元のプライマリOracle BI Schedulerが再び使用可能になった場合でも、プライマリ・ロールはそのOracle BI Schedulerには戻されません。
アクティブなOracle BI Schedulerで障害が発生しても、どの確立済クライアント接続でもエラーは受信されません。Oracle BI Schedulerプロトコルはステートレスであり、シームレスにフェイルオーバーするからです。
エージェント: エージェントの実行ではOracle BI Schedulerの表に状態が保持されます。次のOracle BI Schedulerインスタンスがアクティブになると、このインスタンスは、実行途中であったすべてのジョブ・インスタンスの状態を読み取って、これらのインスタンスを実行します。スケジュール済エージェントは、アクティブなインスタンスの障害発生前に配信されなかった受信者に対してのみ配信します。
正常に行われた配信は、配信の完了後にOracle BI Scheduler表に記録されます。配信は完了したがその事実が記録される前にOracle BI Schedulerがフェイルオーバーした場合、配信が繰り返されます。このため、繰返しの配信が数回実行されることがあります。
エージェントのフェイルオーバーは、スケジュール済のエージェントについてのみサポートされます。たとえば、Answersのツールバーで「エージェントを今すぐ実行」をクリックした後に、プライマリOracle BI Schedulerで障害が発生した場合は、そのエージェントはセカンダリScheduler上で引き続き実行されることはなく、エラー・メッセージが「今すぐ実行」結果ダイアログ・ボックスに表示されます。
Java、コマンドラインまたはスクリプトのジョブ: これらのジョブは、新しいジョブ・インスタンスを使用して最初から再実行されます。
注意: すべてのジョブ・インスタンスは、ジョブ・マネージャから手動で再実行できます。エージェントについては、正常に配信されなかったユーザーに対してのみ配信されます。たとえば、エージェントの実行途中でメール・サーバーが停止した場合、そのインスタンスの再実行では、メール・サーバーのクラッシュが原因で電子メールを受信できなかった受信者に対してのみ配信されます。 |
Cluster Controllerは、BI ServerまたはOracle BI Schedulerの障害の検知と、障害が発生したサーバーのクライアントのフェイルオーバーをサポートします。
Cluster Controllerは、アクティブ/パッシブのモデルに基づいて動作します。すべてのクライアントは、まずプライマリCluster Controllerへの接続を試行します。プライマリCluster Controllerが使用不能な場合は、クライアントはセカンダリCluster Controllerに接続します。セカンダリCluster Controllerは、負荷と可用性に基づいてリクエストをBI Serverに転送するとともに、アクティブなOracle BI Schedulerインスタンスにも転送します。プライマリが後で使用可能になった場合は、すべてのリクエストはプライマリに再び転送されます。
セカンダリCluster Controllerは、各BI Server上のセッション・カウントを監視しますが(プライマリと同様に)、プライマリCluster Controllerが停止している場合を除いて、どのOracle BI Schedulerがアクティブ・スケジューラであるかを決定しません。
プライマリとセカンダリのCluster Controllerは相互のライフ・サイクルを監視します。Cluster Controllerインスタンス間では通信不能になっているが、各インスタンスは稼働しており他のクライアントと通信できる場合は、スプリット・ブレイン障害が発生する可能性があります。このような場合は、BI Serverは影響を受けませんが、Oracle BI Schedulerの2つのインスタンスが同時にアクティブになる可能性があります。まれに、その結果としてジョブが二重実行されることがあります。通信が回復すると、プライマリCluster Controllerは、1つのOracle BI Schedulerのみがアクティブになる必要があることをクラスタに指示します。スプリット・ブレイン障害が発生する可能性を最小限に抑えるために、クラスタ・コンポーネントは同じ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 Schedulerにエラーが転送されます。Oracle BI Schedulerは障害をログに記録してから、ジョブを再試行します。この再試行によって、使用可能なプレゼンテーション・サービスに対する新しい接続が確立されます。
BI Serverで障害が発生すると、ODBCエラーが適切なクライアントに送信されます。
プレゼンテーション・サービス: 各Webユーザーのリクエストは、単一のBI Serverによって処理されます。このBI Serverが使用不能になった場合、ユーザーにはエラーが表示されることがありますが、ブラウザのリフレッシュによって、使用可能なBI Serverとの新しいセッションが確立されます。この調停は、そのユーザーにかわりプレゼンテーション・サービス・コンポーネント自体によって実行されることに注意してください。
管理ツール: 管理ツールは、その接続先であるBI Serverが使用不能になると、ODBCエラーを転送してから接続を切断します。その後、管理者が管理ツールを使用して再接続する必要があります。
エージェント: BI Serverで障害が発生すると、Oracle BI Schedulerにエラーが転送されます。Oracle BI Schedulerは障害をログに記録してから、ジョブを再試行します。これにより、使用可能なBI Serverとの接続が確立されます。
サード・パーティ・クライアント: サード・パーティ・クライアントはODBCを使用してBI Serverに接続します。BI Serverで障害が発生すると、ODBCによってエラーが転送され、ODBC標準に従ってセッションが切断されてから再確立されます。
マスターBI Serverの障害: マスターBI Serverが使用不能である場合、オンライン・メタデータの変更は実行できません。これは管理操作であり、ランタイムの可用性には影響を与えません。
マスターBI Serverが永続的に使用不能である場合、次のように、他のサーバーの1つを新しいマスターとして指定する必要があります。
Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブを使用して、マスターBI Serverをスケール・インします。
Oracle BI EEシステム・コンポーネントを再起動します。
新しいマスターBI Serverがシステムによって割り当てられます。
一般にリカバリの問題は、プロセスの起動失敗に関係しています。推奨されるトラブルシューティング手順は次のとおりです。
Fusion Middleware Controlをチェックして、どのプロセスが実行されているか確認します。これにはOPMNによって報告される状態が反映されます。
OPMNログ・ファイルをチェックします。これらは、Fusion Middleware Controlからアクセスできます。これらは、表15-1で明示している場所でもアクセスできます。
正常に実行されなかったプロセスを特定したら、そのログ・ファイルをチェックしてください。このログ・ファイルには、Fusion Middleware Controlから、または表15-1で明示している場所でアクセスできます。
特定のプロセスは、そのピアと通信できない場合に停止されます。この問題を診断する手順は次のとおりです。
正常に実行されなかったプロセスを特定します。ログ・ファイルで低レベル・ソケット・エラーを探します。これによりポートとサーバー・アドレスが特定されます。ローカル構成ファイルをチェックして、どのプロセスがそのポートでリスニングするように構成されているのかを確認します(単純なデプロイメントでは、第15.1.2.1項「Oracle BI EEの高可用性アーキテクチャ」においてコンポーネントに関する説明で示されているように、デフォルトのポート割当てが使用されます)。現在構成されているポートは、Fusion Middleware Controlの「容量管理」ページの「可用性」タブで確認できます。
ピアが動作しているかどうか確認します。ピアが動作している場合は、そのログ・ファイルをチェックして、通信を拒否するエントリがないか確認します。通信が拒否される可能性があるのは、SSL構成が矛盾している場合やプロトコル障害が発生している場合です。
Cluster Controllerの管理対象プロセスの構成がCluster Controllerと一致していない場合は、これらのプロセスは正常に実行されません。一部のフェイルオーバー・イベントはログに記録されませんが、Cluster Controllerのログ・ファイルには、すべてのOracle BI SchedulerインスタンスまたはBI Serverインスタンスのクラッシュが記録されます。
初回の起動後にログ・ファイルを確認してください。BI ServerまたはOracle BI Schedulerのインスタンスが、Cluster Controllerによる仕様どおりに正しく構成されていない場合は、そのインスタンスは、停止されない可能性がありますが、クラスタには追加されません。ログ・ファイルにはこのようなエラーが記録されます。
この項では、Oracle BI EEおよびBI Publisherにおいて2ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図15-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%';
図15-6で示すように、異なる仮想IPをリスニングするようにBI管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。各VIPが使用可能かつアクセス可能であることを、インストールの実行前に確認してください。
表15-2 BI EEの仮想ホスト
仮想IP | 仮想IPのマップ先 | 説明 |
---|---|---|
VIP1 |
APPHOST1VHN1 |
APPHOST1VHN1は、BI_SERVER1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、BI_SERVER1プロセスが実行されているノード(デフォルトはAPPHOST1)で有効化されます。 |
VIP2 |
APPHOST2VHN1 |
APPHOST2VHN1は、BI_SERVER2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、BI_SERVER2プロセスが実行されているノード(デフォルトはAPPHOST2)で有効化されます。 |
障害発生時に適切にリカバリできるようにするため、すべてのノードからアクセスできて、管理対象サーバーで障害が発生した後に操作を再開できる場所に、JMSとトランザクションの両方のログを格納します。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表15-3は、共有記憶域の内容を示しています。
表15-3 BI EEの共有記憶域の内容
サーバー | データの型 | 共有記憶域のボリューム | ディレクトリ | ファイル |
---|---|---|---|---|
BI_SERVER1とBI_SERVER2 |
トランザクション・ログ |
VOL2 |
ORACLE_BASE/admin/domain_name/cluster_name/tlogs |
共通の場所(WebLogicサーバーにより決められたストア) |
BI_SERVER1とBI_SERVER2 |
JMSストア |
VOL2 |
ORACLE_BASE/admin/domain_name/cluster_name/jms |
共通場所ですが、サーバーごとに個別のストアになります。たとえば、BI_SERVER1の場合、BipJmsStore_auto_1になります。BI_SERVER2の場合、BipJmsStore2_auto_2になります。 |
BI_SERVER1とBI_SERVER2 |
BI Serverリポジトリ |
VOL1 |
ORACLE_BASE/admin/domain_name/cluster_name/ClusterRPD |
共通の場所 |
BI_SERVER1とBI_SERVER2 |
BIグローバル・キャッシュ |
VOL1 |
ORACLE_BASE/admin/domain_name/cluster_name/GlobalCache |
共通の場所 |
BI_SERVER1とBI_SERVER2 |
BIプレゼンテーション・サービス・リポジトリ |
VOL1 |
ORACLE_BASE/admin/domain_name/cluster_name/catalog |
共通の場所 |
BI_SERVER1とBI_SERVER2 |
BI Publisher構成フォルダ |
VOL1 |
ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/config |
共通の場所 |
BI_SERVER1とBI_SERVER2 |
BI Publisherカタログ・リポジトリ |
VOL1 |
ORACLE_BASE/domain_name/config/bipublisher/catalog これが必要なのは、「BI Publisherカタログ」タイプで「Oracle BI Publisher - ファイル・システム」が選択されている場合のみです。 |
共通の場所 |
BI_SERVER1とBI_SERVER2 |
BI Publisher Scheduler一時ディレクトリ |
VOL1 |
ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/temp |
共通の場所 |
共有記憶域にはNASやSANなどのデバイスを使用できます。NAS over NFSデバイスに基づいたコマンド例を次に示します。この項で指定しているオプションは、実際のオプションと異なる場合があります。
APPHOST1> mount 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リポジトリを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名を指定するか、またはノード名のいずれかをホスト名として指定します。例:
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アドレスの両方を含むプールを使用してロード・バランサを構成します。
この項では、Oracle 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をインストールする手順は次のとおりです。
Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmw
と入力します。
注意: ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracle の値をお薦めします。 |
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3
ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.6
ディレクトリを受け入れます。そして「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
Oracle 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 WebLogic Server管理コンソールおよび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
「次へ」をクリックします。
RPD暗号化パスワード画面で、次の情報を入力します。
RPDパスワード
確認RPDパスワード
RPDパスワードは、インストールされるファイルとともに組み込まれるサンプル・リポジトリSampleAppLite.rpdに使用するパスワードです。
「次へ」をクリックします。
MDSスキーマ画面で、情報を確認します。例:
データベース・タイプ: Oracle Database
接続文字列: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM
MDSスキーマ・ユーザー名:: prefix_MDS
MDSパスワード:: your_password
「次へ」をクリックします。
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
次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server1」を選択します。
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の構成を更新する手順は次のとおりです。
次のURLにアクセスしてOracle BI Publisherにログインします。
http://APPHOST1VHN1:9704/xmlpserver
「管理」リンクをクリックします。
「スケジューラ構成」を「システム・メンテナンス」で選択します。「スケジューラ構成」画面が表示されます。
次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。
t3://APPHOST1VHN1:9704
「適用」をクリックします。
スケジューラのステータスを「スケジューラ診断」タブでチェックします。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle 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管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、次のように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コマンドラインを使用してBusiness Intelligence Enterprise Editionのシステム・コンポーネントを起動する手順は次のとおりです。
OPMNコマンドライン・ツールが格納されたディレクトリに移動します。
注意: OPMNコマンドライン・ツールは、ORACLE_INSTANCE/bin ディレクトリにあります。 |
opmnctlコマンドを実行して、BI Enterprise Editionのシステム・コンポーネントを起動します。
opmnctl startall
このコマンドは、OPMNとすべてのBI Enterprise Editionシステム・コンポーネントを起動します。
opmnctl start
このコマンドはOPMNのみを起動します。
opmnctl startproc ias-component=
componentName
このコマンドは、指定されたシステム・コンポーネントを起動します。次に、coreapplication_obips1がBI Presentation Serverである場合の実行例を示します。
opmnctl startproc ias-component=coreapplication_obips1
BI EEシステム・コンポーネントのステータスをチェックします。
opmnctl status
第15.1.3.2項「高可用性のためのOracle Business Intelligence Enterprise Editionのインストール」の手順に従って、APPHOST2でOracle WebLogic ServerとOracle Business Intelligenceのソフトウェアのみをインストールします。
次に、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
Fusion Middleware Controlで次の手順を実行します。
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 SchedulerとBI Cluster Controllerの「パッシブ・ホスト/インスタンス」を指定します。
「適用」をクリックします。
「潜在的単一点障害」で、「問題はありません。すべてのコンポーネントにバックアップがあります。」と報告されていることを確認します。
「変更のアクティブ化」をクリックします。
「再起動して最近の変更を適用」をクリックします。
次の手順を実行して、BI_SERVER2管理対象サーバーのリスニング・アドレスを設定します。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。
表の「名前」列で「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://APPHOST1VHN1:9704,APPHOST2VHN1:9704
「適用」をクリックします。
スケジューラのステータスを「スケジューラ診断」タブでチェックします。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server2」を選択します。サーバーの設定ページが表示されます。
「SSL」タブを開きます。
ページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
変更内容は、BI_SERVER2管理対象サーバーが再起動されるまでは有効になりません。
この項では、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 Schedulerでサーバー側スクリプトを使用する場合は、クラスタ内のすべてのOracle BI Schedulerコンポーネントで共有できるように、これらのスクリプトの共有ディレクトリを構成することをお薦めします。
次の手順は、サーバー側スクリプトを使用している場合にのみ実行してください。
Oracle BI Schedulerのスクリプトを共有する手順は次のとおりです。
デフォルトのOracle BI Schedulerスクリプト(例: ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/common)とカスタムのOracle BI Schedulerスクリプト(例: ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/scheduler)をBI Schedulerスクリプトの共有場所にコピーします。
Oracle BI Schedulerのinstanceconfig.xmlファイルのSchedulerScriptPath要素とDefaultScriptPath要素を更新します。
SchedulerScriptPath: Oracle BI Schedulerによって作成されたジョブ・スクリプトが格納されているパスを指します。共有BI Schedulerスクリプトの場所を指すパスにこれを変更します。
DefaultScriptPath: ユーザーによって作成されたジョブ・スクリプト(エージェントではなく)が格納されているパスを指定します。共有BI Schedulerスクリプトの場所を指すパスにこれを変更します。
デプロイメント環境内の各Oracle BI Schedulerコンポーネントについて、このファイルを更新する必要があります。
各プレゼンテーション・サービス・インスタンスは、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パス名を指定します。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
Oracle BI for Microsoft Officeの追加の構成タスクを実行する手順は、次のとおりです。
次のURLにアクセスして、Oracle BI EE Officeサーバーのセットアップを検証します。
http://APPHOST1VHN1:9704/bioffice/about.jsp
http://APPHOST2VHN1:9704/bioffice/about.jsp
Oracle BI EE Officeサーバーについてページが表示されます(図15-3を参照)。
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を編集のために開いて、表15-4のとおりにBI Officeのプロパティを変更します。
表15-4 bioffice.xml内のBI Officeのプロパティ
プロパティ名 | 有効な値 | 説明 |
---|---|---|
SawBaseURL |
https://bi.mydomain.com:443/analytics/saw.dll または https://bi.mydomain.com:443/analytics-ws/saw.dll |
Oracle BIプレゼンテーション・サービスのロード・バランサ仮想サーバー名URLです。 重要: SSOが有効になっている場合は、Oracle BI for Microsoft OfficeをSSO対応のOracle BI Serverと統合するように構成する際にデプロイした保護された分析サーブレットのURLを入力してください。このプロパティで指定されたURLは、BI Officeサーバーとプレゼンテーション・サービスの間のWebサービス・リクエスト用に使用されます。 |
SawUseSSO |
0: いいえ(デフォルト) 1: はい |
実装されたOracle Business IntelligenceがSSOに対応している場合は、このプロパティを1に設定します。 |
SawWebURLforSSO |
https://bi.mydomain.com:443/analytics/saw.dll |
SSOが有効になっている場合は、このプロパティを使用してパブリックURLを入力します。外部ユーザーはこのURLを使用して、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の構成を検証するには、次の手順を実行します。
次のURLにアクセスして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サーバーのポート番号を入力します。
図15-4は、「新規接続」ダイアログを示しています。
図15-4 Oracle BI for Microsoft Officeの「新規接続」ダイアログ
「接続のテスト」をクリックし、アドインとOracle BI for Microsoft Officeサーバーとの間の接続をテストします。
正常に接続されている場合は、図15-5に示すように「接続テストが成功しました。」というメッセージが表示されます。
管理者(例: weblogic)としてログインして、図15-6に示す「Oracle BIタスク・ペイン」にアクセスできることを確認します。
この項では、Oracle BI Publisherを構成する方法を説明します。
Oracle BI Publisherのサーバー構成オプションを設定するには、次の手順を実行します。
DOMAIN_HOME/config/bipublisher/repository
の内容を構成フォルダの共有場所にコピーします。
管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「サーバー構成」を選択します。
構成フォルダ用に次のフィールドを入力します。
パス: 構成フォルダの共有場所のパスを入力します。
変更を適用してから、BI Publisherアプリケーションを再起動します。
Oracle BIプレゼンテーション・サービスの統合のオプションを構成するには、次の手順を実行します。
管理者の資格証明を使用してOracle BI Publisherにログインして、「管理」タブを選択します。
「統合」で、「Oracle BIプレゼンテーション・サービス」を選択します。
「サーバー」と「ポート」を次のように更新します。
サーバー: bi.mycompany.com
ポート: 80
「適用」をクリックします。
Oracle BI Publisherアプリケーションを再起動します。
スケジューラ構成オプションを構成するには、次の手順を実行します。
管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「スケジューラ構成」を選択します。
「クォーツ・クラスタリング」を「スケジューラ選択」で選択します。
変更を適用してから、BI Publisherアプリケーションを再起動します。
Oracle BI EEのデータ・ソースは、Cluster Controllerを介してクラスタ化されたBI Serverを指している必要があります。このタスクは、Oracle BI Publisherアプリケーションで実行します。
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;
「システム・ユーザーの使用」を選択解除して、「ユーザー名」と「パスワード」に管理者の資格証明を指定します。たとえば、weblogicの資格証明を指定します。
「接続のテスト」をクリックします。「接続は正常に確立されました。」というメッセージが表示されることを確認します。
「適用」をクリックします。
両方のノードから参照できるディレクトリに、すべての永続ストアの場所を構成する必要があります。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BipJmsStore_auto_1」をクリックして、共有記憶域のあるディレクトリを入力します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「保存」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。
名前(例: BipJmsStore_auto_2)を入力し、BI_SERVER2をターゲットにします。APPHOST1とAPPHOST2の両方からアクセスできるように、共有記憶域にあるディレクトリを入力します。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「OK」をクリックして、変更をアクティブ化します。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSサーバー」ノードをクリックします。「JMSサーバーのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックします。
名前(例: BipJmsServer_auto_2)を入力してから「永続ストア」ドロップダウン・リストで「BipJmsStore_auto_2」を選択し、「次へ」をクリックします。
「BI_SERVER2」をターゲットとして選択します。
「終了」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BIPJmsResource」→「サブデプロイメント」タブをクリックします。
「新規」をクリックします。
「サブデプロイメント名」で名前(例: BipJmsServer2)を入力し、「次へ」をクリックします。
「BipJmsServer_auto_2」を「JMSサーバー」でターゲットとして選択します。
「終了」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BIPJmsResource」→「新規」をクリックし、新しいJMSシステム・モジュール・リソースを作成します。
新しいキューのBIP.Burst.Job.Q_auto_2を作成します。
「作成するリソースのタイプを選択してください。」ページで「キュー」を選択して「次へ」をクリックします。
「名前」と「JNDI名」で、BIP.Burst.Job.Q_auto_2と入力します。「次へ」をクリックします。
「サブデプロイメント」を「BipJmsServer2」に設定し、「ターゲット」を「BipJmsServer_auto_2」に設定します。
「終了」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「BIPJmsResource」をクリックします。
「BipJmsResourceの設定」ページで、「dist_BIP.Burst.Job.Q_auto」という分散キューを選択します。「dist_BIP.Burst.Job.Q_Autoの設定」ページが表示されます。
「一般」タブで「転送の遅延」を「0」に設定し、「保存」をクリックします。
「メンバー」タブ→「新規」をクリックします。
「BIP.Burst.Job.Q_auto_2」を「キュー」プルダウン・バーで選択して、新しい分散トピック・メンバーを作成します。「OK」をクリックします。
「変更のアクティブ化」をクリックします。
ステップ24から27を繰り返し、次に示すキューを作成します。
BIP.Burst.Report.Q_auto_2
BIP.Delivery.Email.Q_auto_2
BIP.Delivery.Fax.Q_auto_2
BIP.Delivery.FTP.Q_auto_2
BIP.Delivery.Print.Q_auto_2
BIP.Delivery.WebDAV.Q_auto_2
BIP.Delivery.Fax.Q_auto_2
たとえば、BIP.Burst.Report.Q_auto_2の場合、ステップ27.bにおいて「名前」と「JNDI名」で、BIP.Burst.Report.Q_auto_2と入力します。ステップ27.gでは、分散キューのdist_BIP.Burst.Report.Q_autoを選択します。ステップ27.jでは「キュー」で新しいメンバーのBIP.Burst.Report.Q_auto_2を追加します。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BIPJmsResource」→「新規」をクリックし、新しいJMSシステム・モジュール・リソースを作成します。
新しいトピックのBIP.System.T_auto_2を作成します。
「作成するリソースのタイプを選択してください。」ページで「トピック」を選択して「次へ」をクリックします。
「名前」と「JNDI名」で、BIP.System.T_auto_2と入力します。「次へ」をクリックします。
「サブデプロイメント」を「BipJmsServer2」に設定し、「ターゲット」を「BipJmsServer_auto_2」に設定します。
「終了」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「BIPJmsResource」をクリックします。
「BipJmsResourceの設定」ページで、「dist_BIP.System.T_auto」という分散トピックを選択します。「dist_BIP.System.T_autoの設定」ページが表示されます。
「メンバー」タブ→「新規」をクリックします。
「トピック」プルダウン・バーから「BIP.System.T_auto_2」を選択して、新しい分散トピック・メンバーを作成します。「OK」をクリックします。
「変更のアクティブ化」をクリックします。
Oracle BI Publisherに対して実行したJMS構成を検証するには、第15.2.3.13.4項「Oracle BI Publisher Schedulerの構成の更新」の手順を実行してください。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。 |
BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。
「BI_SERVER1」(ハイパーリンクとして表示されています)を表の「名前」列でクリックします。
BI_SERVER1サーバーの設定ページが開き、「構成」タブがアクティブに表示されます。
「サービス」タブをクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようになります。
ORACLE_BASE/admin/domain_name/bi_cluster/tlogs
「保存」→「変更のアクティブ化」をクリックします。
BI_SERVER2サーバーに対してこれらの手順を繰り返します。
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。 |
この項では、APPHOST2でシステムを起動する手順について説明します。
通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、第15.1.3.9.1項「APPHOST1でのノード・マネージャの起動」の手順に従ってAPPHOST2でノード・マネージャを起動してください。
BI_SERVER2管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、次のように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のシステム・コンポーネントを起動するには、第15.1.3.9.3項「APPHOST1でのBusiness Intelligence Enterprise Editionシステム・コンポーネントの起動と検証」の手順を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=ohs2
管理コンソールで、BI ServerのステータスがRunning
であることを確認します。ステータスがStarting
またはResuming
である場合は、サーバー・ステータスがStarted
に変更されるまで待機します。別のステータス(Admin
やFailed
など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
次の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の実行中に、Oracle WebLogic Server管理コンソールからBI_SERVER1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WEBHOST1:7777/wsm-pm
WEBHOST1:7777/analytics
WEBHOST1:7777/xmlpserver
WEBHOST1:7777/bioffice/about.jsp
Oracle WebLogic Server管理コンソールからBI_SERVER1を起動します。
BI_SERVER2を停止します。
前述のステップ2のURLにアクセスして、適切な機能を検証します。
Oracle WebLogic Serverクラスタに対して、フロントエンドHTTPのホストとポートを設定する必要があります。そのためには、次の手順に従ってください。
WebLogic Server管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
左側のペインで、「ドメイン構造」ウィンドウの「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
「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をリスニングします。
この項の項目は次のとおりです。
次の手順に従って、サーバー移行の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ユーザーとして接続します。
leasing.ddlスクリプトをSQL*Plusで実行します。
SQL> @Copy_Location/leasing.ddl;
この項では、Oracle WebLogic Server管理コンソールからleasing表のマルチ・データ・ソースを作成する方法について説明します。マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成する際は、次の考慮事項に留意してください。
このデータ・ソースが、XAデータ・ソースではないことを確認してください。
マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。
これらのデータ・ソースをI/PMクラスタにターゲット指定します。
データ・ソースの初期接続プール容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データ・ソース名」→「接続プール」タブをクリックし、「初期容量」フィールドに0を入力します。
マルチ・データ・ソースを作成するには、次の手順を実行します。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開き、「データ・ソース」をクリックします。「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)を指定します。
注意: サブ・インタフェース(eth0:1 、eth0:2 など)を指定しないでください。このインタフェースは、:0 または:1 なしに使用されます。ノード・マネージャのスクリプトは、別の:X 対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0 、eth1 、eth2 、eth3 、eth nとなります。 |
注意: Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例:Interface="Local Area Connection" |
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)を使用するには、インタフェース環境変数を「APPHOSTn> export JAVA_OPTIONS=-DInterface=eth3 」のように使用して、この変数がシェル内で設定された後にノード・マネージャを起動します。 |
この項では、wlsifconfig.sh
スクリプトの環境とスーパーユーザー権限を設定する方法について説明します。
注意: Windowsでは、そのスクリプトの名前はwlsifconfig.cmd であり、それを実行できるのは管理者権限を持つユーザーです。 |
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
に対しても付与しています。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
注意: この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。 |
この項では、サーバー移行ターゲットを構成する方法について説明します。まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成するには、次の手順を実行します。
Oracle WebLogic Server管理コンソール(http://Host:Admin_Port/console)にログインします。通常、Admin_Portは7001(デフォルト)です。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。
移行を構成する対象となるクラスタ(bi_cluster)を、表の「名前」列でクリックします。
「移行」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「APPHOST1」と「APPHOST2」を選択します。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
サーバー移行の候補マシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
ヒント: サーバーが実行されているマシンを表示するには、「サーバーのサマリー」ページで「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウに移動します。サーバーが自動的に移行される場合、これはこの構成とは異なります。 |
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。bi_server1については、「APPHOST2」を選択します。bi_server2については、「APPHOST1」を選択します。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理サーバー、ノード・マネージャ、およびサーバー移行が構成されたサーバーを再起動します。
最後の手順は、サーバー移行をテストすることです。サーバー移行が適切に機能していることを確認するには、次の手順を実行します。
APPHOST1から:
bi_server1管理対象サーバーを強制停止します。そのためには、次のコマンドを実行します。
APPHOST1> kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
APPHOST1> ps -ef | grep bi_server1
注意: Windowsの場合は、taskkill コマンドを使用して管理対象サーバーを終了できます。例:
taskkill /f /pid <pid> <pid>は、管理対象サーバーのプロセスIDを表します。 管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、bi_servern管理対象サーバーのpidを確認します。 MW_HOME\jrockit_160_20_D1.0.1-2124\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ホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、User_Home/bea/beahomelistファイルを編集します。次の手順を参照してください。
新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。
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/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
VIP3をAPPHOST3で有効にします。第15.1.3.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。
第15.1.3.10項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームからコンフィギュレーション・アシスタントを実行します。
第15.1.3.11項「システム・コンポーネントのスケール・アウト」の手順に従って、APPHOST3でシステム・コンポーネントをスケール・アウトします。
第15.1.3.13項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第15.1.3.14項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名の検証を無効にすることで、bi_server3管理対象サーバーを構成します。
第15.1.3.17.5項「Oracle BI Publisher用のJMSの構成」の説明に従って、Oracle BI Publisher用のJMSを構成します。
第15.1.3.16項「Oracle BI for Microsoft Officeプロパティの構成」の説明に従って、APPHOST3上のOracle BI for Microsoft Officeを構成します。
第15.1.3.17.6項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。
第15.1.3.19項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。
APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第15.1.3.9.2項「BI_SERVER1管理対象サーバーの起動と検証」および第15.1.3.9.3項「APPHOST1でのBusiness Intelligence Enterprise Editionシステム・コンポーネントの起動と検証」を参照してください。
第15.1.3.21.5項「サーバー移行ターゲットの構成」および第15.1.3.21.6項「サーバー移行のテスト」の説明に従って、サーバー移行を構成します。
構成を検証するには、次の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の高可用性環境を設計およびデプロイする方法を説明します。
この項の項目は次のとおりです。
図15-7では、単一インスタンス・アーキテクチャでのOracle BI Publisherコンポーネントを示しています。
Oracle BI Publisherは、サーブレットベースのアーキテクチャを使用するJava EEアプリケーションです。JMSを使用してスケジュール済ジョブを実行し、EJBクライアントを使用してESSと統合します。
Oracle BI Publisherレポートの実行中は、セッション情報がメモリーに保管されます。
複数のサーバーにまたがってレポートの実行を移行する複雑な操作のため、Oracle BI Publisherはステートレス・アプリケーションではありません。
Oracle BI Publisherは、Oracle WebLogic ServerにデプロイされるJava EEコンポーネントです。
Oracle BI Publisherのアーティファクトの処理(次のアーティファクトの作成、削除および編集を含む)
レポート
データ・モデル
レイアウト・テンプレート
スケジューラ・ジョブ
構成
スケジューラ・レポートの実行
オンライン・レポートの実行
Oracle BI Publisherは、Oracleインフラストラクチャに全面的に依存しています。Oracle BI Publisherをデプロイ、起動、停止および監視するには、WebLogic Server管理コンソールを使用します。
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を高可用性環境で使用する場合の概要について説明します。
図15-8は、Oracle BI Publisherの高可用性アーキテクチャを示しています。
図15-8では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。
Oracle BI Publisherが実行されるOracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。APPHOST2上の管理サーバーはパッシブです。APPHOST1が使用できなくなると、第3章「WebLogic Serverの高可用性」の説明に従って、管理サーバーをAPPHOST2でアクティブにできます。Oracle BI Publisherは、これらのホスト上のBI_SERVER1管理対象サーバーとBI_SERVER2管理対象サーバーにデプロイされます。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。サーバー移行全体は、管理対象サーバー用に構成されます。
BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してVIPマッピングを有効にして(APPHOST1ではVIP1、APPHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。BIサーバーのサーバー移行を構成する方法の詳細は、第15.1.3.21項「BI_SERVERnサーバーのサーバー移行の構成」を参照してください。
データ層では、レコード定義、レポート・レイアウト、データ・モデルなどのOracle BI Publisherリポジトリ・メタデータと、Oracle BI Publisher JMS永続ストアを格納するための共有外部記憶域が設定されます。
Oracle RACデータベースは、レポート・データ用に使用されますが、エンタープライズ・データベース用としてもお薦めします。
Oracle BI Publisherは、アクティブ/アクティブ形式の高可用性構成をサポートしています。各ノードは、他のOracle BI Publisherノードと共通のリポジトリおよびスケジューラ・データベースを共有する独立サーバーとして動作します。
Oracle BI Publisherリポジトリ(レポートやデータ・モデルなどのすべてのコンテンツを格納)は、BI PublisherがOracle BI EEと組み合せて構成されている場合はOracle BIプレゼンテーション・カタログに保管され、Oracle BI Publisherが単独でインストールされている場合は共有ファイル・システムに保管されます。
Oracle BI Publisherの構成フォルダは共有ファイル・システムに配置されている必要があります。
共有リポジトリには、次のOracle BI Publisherアーティファクトが保管されます。
レポート定義
レポート・テンプレート
データ・モデル
Oracle BI Publisherの構成
Schedulerデータベースは、次の情報が保管される共有データベースです。
レポートの詳細(パラメータ)
実行ステータス
実行履歴
過去のレポート実行のスナップショット
ハードウェアまたはソフトウェアのロード・バランサを、高可用性環境内のOracle BI Publisherノードに対するフロントエンドとして使用できます。
Oracle BI Publisherの高可用性デプロイメントでは次のことが当てはまります。
スティッキー・セッションをロード・バランサに対して有効にする必要があります。
Oracle BI Publisherは、WebLogic ServerのJMSフェイルオーバー・メカニズムに依存しています。
クラスタ内のすべてのOracle BI Publisherインスタンスは独立しています。
アーティファクトと構成は共有リポジトリに保管されており、各インスタンスは個別にこのリポジトリを読み取ります。
ノード・マネージャは、障害が発生した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ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図15-8に示しています。
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
この項では、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%';
図15-6で示すように、異なる仮想IPをリスニングするようにBI管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。各VIPが使用可能かつアクセス可能であることを、インストールの実行前に確認してください。
表15-6 BI Publisherの仮想ホスト
仮想IP | 仮想IPのマップ先 | 説明 |
---|---|---|
VIP1 |
APPHOST1VHN1 |
APPHOST1VHN1は、BI_SERVER1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、BI_SERVER1プロセスが実行されているノード(デフォルトはAPPHOST1)で有効化されます。 |
VIP2 |
APPHOST2VHN1 |
APPHOST2VHN1は、BI_SERVER2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、BI_SERVER2プロセスが実行されているノード(デフォルトはAPPHOST2)で有効化されます。 |
障害発生時に適切にリカバリできるようにするため、すべてのノードからアクセスできて、管理対象サーバーで障害が発生した後に操作を再開できる場所に、JMSとトランザクションの両方のログを格納します。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表15-7は、共有記憶域の内容を示しています。
表15-7 BI Publisherの共有記憶域の内容
サーバー | データの型 | 共有記憶域のボリューム | ディレクトリ | ファイル |
---|---|---|---|---|
BI_SERVER1とBI_SERVER2 |
トランザクション・ログ |
VOL2 |
ORACLE_BASE/admin/domain_name/bi_cluster_name/tlogs |
共通の場所(WebLogicサーバーにより決められたストア) |
BI_SERVER1とBI_SERVER2 |
JMSストア |
VOL2 |
ORACLE_BASE/admin/domain_name/bi_cluster_name/jms |
共通場所ですが、サーバーごとに個別のストアになります。たとえば、BI_SERVER1の場合、BipJmsStore_auto_1になります。BI_SERVER2の場合、BipJmsStore_auto_2になります。 |
BI_SERVER1とBI_SERVER2 |
BI Publisher構成フォルダ |
VOL1 |
ORACLE_BASE/domain_name/config/bipublisher/repository |
共通の場所 |
BI_SERVER1とBI_SERVER2 |
BI Publisherカタログ・リポジトリ |
VOL1 |
ORACLE_BASE/domain_name/config/bipublisher/catalog |
共通の場所 |
BI_SERVER1とBI_SERVER2 |
BI Publisher Scheduler一時ディレクトリ |
VOL1 |
ORACLE_BASE/domain_name/config/bipublisher/temp |
共通の場所 |
共有記憶域にはNASやSANなどのデバイスを使用できます。NASデバイス別のコマンド例を次に示します。この項で指定しているオプションは、実際のオプションと異なる場合があります。
APPHOST1> mount 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リポジトリを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名を指定するか、またはノード名のいずれかをホスト名として指定します。例:
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アドレスの両方を含むプールを使用してロード・バランサを構成します。
この項では、Oracle WebLogic ServerとOracle Fusion Middleware BI EEを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。WebLogic ServerとBI PublisherをAPPHOST2にインストールするために、これと同じ手順を繰り返します(次ではAPPHOST1を対象にして説明しています)。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。
Oracle Fusion Middlewareの、次のコンポーネントをインストールします。
Oracle WebLogic Server
Oracle Fusion Middleware BI EE
Oracle WebLogic Serverをインストールする手順は次のとおりです。
Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmw
と入力します。
注意: ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracle の値をお薦めします。 |
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3
ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.6
ディレクトリを受け入れます。そして「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
Oracle 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 WebLogic Server管理コンソールおよび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
「次へ」をクリックします。
「コンポーネントの構成」画面で、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
次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server1」を選択します。
bi_server1の「設定」ページが表示されます。
リスニング・アドレスをAPPHOST1VHN1に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
変更内容は、BI_SERVER1管理対象サーバーが再起動されるまでは有効になりません。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle 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管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」を選択します。
「サーバーのサマリー」ページが表示されます。
「制御」タブをクリックします。
「bi_server1」を選択してから、「起動」をクリックします。
管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
BI_SERVER1が起動すると、次のURLが使用できるようになります。
http://APPHOST1VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。 |
http://APPHOST1VHN1:9704/xmlpserverにアクセスして、BI Publisherアプリケーションのステータスを確認します。
コンフィギュレーション・アシスタントを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管理対象サーバーのリスニング・アドレスを設定します。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server2」を選択します。
bi_server2の「設定」ページが表示されます。
リスニング・アドレスをAPPHOST2VHN1に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
変更内容は、BI_SERVER2管理対象サーバーが再起動されるまでは有効になりません。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server2」を選択します。サーバーの設定ページが表示されます。
「SSL」タブを開きます。
ページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
この変更内容は、BI_SERVER2管理対象サーバーが再起動されるまでは有効になりません。
この項では、Oracle BI Publisherを構成する方法を説明します。
サーバー構成オプションを構成するには、次の手順を実行します。
DOMAIN_HOME/config/bipublisher/repository
の内容を構成フォルダの共有場所にコピーします。
管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「サーバー構成」を選択します。
構成フォルダ用に次のフィールドを入力します。
パス: 構成フォルダの共有場所のパスを入力します。
変更を適用してから、BI Publisherアプリケーションを再起動します。
スケジューラ構成オプションを構成するには、次の手順を実行します。
管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「スケジューラ構成」を選択します。
「クォーツ・クラスタリング」を「スケジューラ選択」で選択します。
変更を適用してから、BI Publisherアプリケーションを再起動します。
両方のノードから参照できるディレクトリに、すべての永続ストアの場所を構成する必要があります。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BipJmsStore_auto_1」をクリックして、共有記憶域のあるディレクトリを入力します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「保存」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。
名前(例: BipJmsStore_auto_2)を入力し、BI_SERVER2をターゲットにします。APPHOST1とAPPHOST2の両方からアクセスできるように、共有記憶域にあるディレクトリを入力します。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「OK」をクリックして、変更をアクティブ化します。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSサーバー」ノードをクリックします。「JMSサーバーのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックします。
名前(例: BipJmsServer_auto_2)を入力してから「永続ストア」ドロップダウン・リストで「BipJmsStore_auto_2」を選択し、「次へ」をクリックします。
「BI_SERVER2」をターゲットとして選択します。
「終了」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BIPJmsResource」→「サブデプロイメント」タブをクリックします。
「新規」をクリックします。
「サブデプロイメント名」で名前(例: BipJmsServer2)を入力し、「次へ」をクリックします。
「BipJmsServer_auto_2」を「JMSサーバー」でターゲットとして選択します。
「終了」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BIPJmsResource」→「新規」をクリックし、新しいJMSシステム・モジュール・リソースを作成します。
新しいキューのBIP.Burst.Job.Q_auto_2を作成します。
「作成するリソースのタイプを選択してください。」ページで「キュー」を選択して「次へ」をクリックします。
「名前」と「JNDI名」で、BIP.Burst.Job.Q_auto_2と入力します。「次へ」をクリックします。
「サブデプロイメント」を「BipJmsServer2」に設定し、「ターゲット」を「BipJmsServer_auto_2」に設定します。
「終了」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「BIPJmsResource」をクリックします。
「BipJmsResourceの設定」ページで、「dist_BIP.Burst.Job.Q_auto」という分散トピックを選択します。「dist_BIP.Burst.Job.Q_Autoの設定」ページが表示されます。
「一般」タブで「転送の遅延」を「0」に設定し、「保存」をクリックします。
「メンバー」タブ→「新規」をクリックします。
「BIP.Burst.Job.Q_auto_2」を「キュー」プルダウン・バーで選択して、新しい分散トピック・メンバーを作成します。「OK」をクリックします。
「変更のアクティブ化」をクリックします。
ステップ24から27を繰り返し、次に示すキューを作成します。
BIP.Burst.Report.Q_auto_2
BIP.Delivery.Email.Q_auto_2
BIP.Delivery.Fax.Q_auto_2
BIP.Delivery.FTP.Q_auto_2
BIP.Delivery.Print.Q_auto_2
BIP.Delivery.WebDAV.Q_auto_2
BIP.Delivery.Fax.Q_auto_2
たとえば、BIP.Burst.Report.Q_auto_2の場合、ステップ27.bにおいて「名前」と「JNDI名」で、BIP.Burst.Report.Q_auto_2と入力します。ステップ27.gでは、分散キューのdist_BIP.Burst.Report.Q_autoを選択します。ステップ27.jでは「キュー」で新しいメンバーのBIP.Burst.Report.Q_auto_2を追加します。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BIPJmsResource」→「新規」をクリックし、新しいJMSシステム・モジュール・リソースを作成します。
新しいトピックのBIP.System.T_auto_2を作成します。
「作成するリソースのタイプを選択してください。」ページで「トピック」を選択して「次へ」をクリックします。
「名前」と「JNDI名」で、BIP.System.T_auto_2と入力します。「次へ」をクリックします。
「サブデプロイメント」を「BipJmsServer2」に設定し、「ターゲット」を「BipJmsServer_auto_2」に設定します。
「終了」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「BIPJmsResource」をクリックします。
「BipJmsResourceの設定」ページで、「dist_BIP.System.T_auto」という分散トピックを選択します。「dist_BIP.System.T_autoの設定」ページが表示されます。
「メンバー」タブ→「新規」をクリックします。
「トピック」プルダウン・バーから「BIP.System.T_auto_2」を選択して、新しい分散トピックを作成します。「OK」をクリックします。
「変更のアクティブ化」をクリックします。
Oracle BI Publisherに対して実行したJMS構成を検証するには、第15.2.3.13.4項「Oracle BI Publisher Schedulerの構成の更新」の手順を実行してください。
この項の手順に従って、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://APPHOST1VHN1:9704,APPHOST2VHN1:9704
共有記憶域のあるディレクトリを入力して、「共有ディレクトリ」を更新します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。残りの手順を引き続き実行します。
「適用」をクリックします。
スケジューラのステータスを「スケジューラ診断」タブでチェックします。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。 |
BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。
「BI_SERVER1」(ハイパーリンクとして表示されています)を表の「名前」列でクリックします。
BI_SERVER1サーバーの設定ページが開き、「構成」タブがアクティブに表示されます。
「サービス」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようになります。
ORACLE_BASE/admin/domain_name/bi_cluster/tlogs
「保存」→「変更のアクティブ化」をクリックします。
BI_SERVER2サーバーに対してこれらの手順を繰り返します。
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。 |
この項では、APPHOST2でシステムを起動する手順について説明します。
通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、第15.2.3.9.1項「APPHOST1でのノード・マネージャの起動」の手順に従って、APPHOST2でノード・マネージャを起動してください。
BI_SERVER2管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」を選択します。
「サーバーのサマリー」ページが表示されます。
「制御」タブをクリックします。
「bi_server2」を選択してから、「起動」をクリックします。
管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
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=ohs2
管理コンソールでBIサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中」と表示される場合は、サーバーの状態が「起動済」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
次のURLにアクセスできることを確認します。
http://WEBHOST1:7777/wsm-pm
http://WEBHOST2:7777/wsm-pm
http://WEBHOST1:7777/xmlpserver
http://WEBHOST2:7777/xmlpserver
ロード・バランシング・ルーター・アドレスを使用して、次のURLにアクセスできることを確認します。
http://bi.mycompany.com:80/xmlpserver
http://bi.mycompany.com:80/wsm-pm
次の手順に従って、HTTP Serverからbi_clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。
BI_SERVER2の実行中に、Oracle WebLogic Server管理コンソールからBI_SERVER1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WEBHOST1:7777/wsm-pm
WEBHOST1:7777/xmlpserver
Oracle WebLogic Server管理コンソールからBI_SERVER1を起動します。
BI_SERVER2を停止します。
前述のステップ2のURLにアクセスして、適切な機能を検証します。
この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を構成する必要があります。これを行うには、第15.1.3.21項「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ホーム・リストを更新する場合は、User_Home/bea/beahomelistファイルを編集します。次の手順を参照してください。
新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。
APPHOST3でOracle 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/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
VIP3をAPPHOST3で有効にします。第15.2.3.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。
第15.2.3.10項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームからコンフィギュレーション・アシスタントを実行します。
第15.2.3.11項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第15.2.3.12項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名検証を無効にすることで、bi_server3管理対象サーバーを構成します。
第15.2.3.13.3項「BI Publisher用のJMS永続ストアの構成」の説明に従って、Oracle BI Publisher用のJMSを構成します。
第15.2.3.13.5項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。
第15.2.3.15項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。
APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第15.2.3.9.2項「BI_SERVER1管理対象サーバーの起動と検証」を参照してください。
第15.1.3.21.5項「サーバー移行ターゲットの構成」および第15.1.3.21.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の高可用性環境を設計およびデプロイする方法を説明します。
この項の項目は次のとおりです。
図15-9では、Oracle RTDの単一インスタンス・アーキテクチャでの主要なコンポーネントを示しています。
図15-9には、次のコンポーネントが示されています。
Decision Server: インライン・サービスと呼ばれるOracle RTDアプリケーションを実行するためのランタイム・サービスを提供します。
Decision Serverとインライン・サービスの詳細は、「Decision Server」を参照してください。
バッチ・サービス: バッチ・マネージャとバッチ・エージェントが含まれます。バッチ・サービスの役割は、バッチ・ジョブを実行するためのリクエストを処理することです。
バッチ・サービスの詳細は、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドの「Oracle RTDバッチ・フレームワーク」を参照してください。
Decision Center: このWebベースのユーザー・インタフェースを使用して、ビジネス・ユーザーは、自身の分析モデルの有効性に関するレポートを表示したり、自身のホストしているインライン・サービスをチューニングします。
Decision Centerの詳細は、「Decision Center」を参照してください。
学習サービス: Oracle RTDデータベースから学習レコードを読み取り、新しい予測モデルを定期的に生成します。
学習サービスの詳細は、「学習サービス」を参照してください。
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 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 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 WebLogic Server管理コンソールを使用して設定されます。
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を高可用性デプロイメントで使用する場合の概要について説明します。
図15-10は、Oracle RTDの高可用性アクティブ/アクティブ・アーキテクチャを示しています。
図15-10では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。
Oracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。APPHOST1が使用できなくなると、第3章「WebLogic Serverの高可用性」の説明に従って、管理サーバーをAPPHOST2でアクティブにできます。Oracle RTDは、これらのホスト上のBI_SERVER1管理対象サーバーとBI_SERVER2管理対象サーバーにデプロイされます。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。
データ層では、Oracle RACデータベースはOracle RTDリポジトリ用に使用されますが、エンタープライズ・データベース用としてもお薦めします。Oracle RTDリポジトリには、学習モデル、学習レコード、予測モデルおよびインライン・サービスのメタデータが保管されます。
注意: Web層のかわりにロード・バランサを直接のフロントエンドとして使用したOracle RTDインスタンスのクラスタもサポートされています。このタイプのデプロイメントでは、ロード・バランサは、HTTPヘッダーを使用したスティッキー・セッションのルーティングを実現できるように構成される必要があります。HTTPヘッダーを使用したスティッキー・セッションのルーティングを実現できるようにするための構成については、お使いのロード・バランサのドキュメントを参照してください。このタイプのデプロイメントのOracle RTDクラスタにアクセスするクライアントは、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドのJavaスマートクライアントに関する項に指定された要件を満たす必要があります。クライアントのセット・アップ例は、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドの「Javaスマート・クライアントの使用方法」を参照してください。 |
クラスタ化インストールでは、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を介して送信されます。
受信側のDecision Serverがリクエストを完了したら、コールはアンワインドされ、リクエストの転送元は、受信側のDecision Serverからレスポンスを受け取ります。このレスポンスはコール元に返送されます。
図15-10では、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ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図15-10に示しています。
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
この項では、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リポジトリを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名を指定するか、またはノード名のいずれかをホスト名として指定します。例:
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アドレスの両方を含むプールを使用してロード・バランサを構成します。
この項では、Oracle WebLogic ServerとOracle Fusion BI EEを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。WebLogic ServerとOracle RTDをAPPHOST2にインストールするために、これと同じ手順を繰り返します(次ではAPPHOST1を対象にして説明しています)。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。
Oracle Fusion Middlewareの、次のコンポーネントをインストールします。
Oracle WebLogic Server
Oracle Fusion BI EE
Oracle WebLogic Serverをインストールする手順は次のとおりです。
Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmw
と入力します。
注意: ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracle の値をお薦めします。 |
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。
「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3
ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.6
ディレクトリを受け入れます。そして「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
Oracle 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 WebLogic Server管理コンソールおよびOracle Enterprise Managerを使用して、ドメインと最初の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
次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server1」を選択します。
bi_server1の「設定」ページが表示されます。
リスニング・アドレスをAPPHOST1VHN1に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
変更内容は、BI_SERVER1管理対象サーバーが再起動されるまでは有効になりません。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle 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管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」を選択します。
「サーバーのサマリー」ページが表示されます。
「制御」タブをクリックします。
「bi_server1」を選択してから、「起動」をクリックします。
管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
BI_SERVER1が起動すると、次のURLが使用できるようになります。
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管理対象サーバーのリスニング・アドレスを設定します。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server2」を選択します。
bi_server2の「設定」ページが表示されます。
リスニング・アドレスをAPPHOST2VHN1に設定します。
「保存」をクリックします。
変更を保存およびアクティブ化します。
変更内容は、BI_SERVER2管理対象サーバーが再起動されるまでは有効になりません。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle 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.3.0)(bi_cluster)」をクリックします。
その下の任意のノードをクリックします。たとえば、「OracleRTD(11.1.1.3.0)(bi_server1)」をクリックします。
右側のペインで、「アプリケーション・デプロイメント」をクリックして、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ペインで、「アプリケーション定義のMBean」を開きます。
「Oracle RTD」の下のすべてのサーバーそれぞれについてMBeanに移動し、属性を表15-8のとおりに設定します。他のサーバーは、設定した値で自動的に更新されます。
表15-8 Oracle RTD MBeanに対して設定する属性値
MBean | 属性 | BI_SERVER1の値 |
---|---|---|
SDPropertyManager→Misc |
BatchAgentEnabled |
True |
SDPropertyManager→Misc |
BatchManagerEnabled |
True |
SDPropertyManager→Misc |
DecisionServiceEnabled |
True |
SDPropertyManager→Misc |
LearningServiceEnabled |
True |
SDClusterPropertyManager→Cluster |
RestrictDSClients |
False |
SDClusterPropertyManager→Misc |
DecisionServiceAddress |
http://bi.mycompany.com |
「適用」をクリックします。
この項では、APPHOST2でシステムを起動する手順について説明します。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。 |
BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。
「BI_SERVER1」(ハイパーリンクとして表示されています)を表の「名前」列でクリックします。
BI_SERVER1サーバーの設定ページが開き、「構成」タブがアクティブに表示されます。
「サービス」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようになります。
ORACLE_BASE/admin/domain_name/bi_cluster/tlogs
「保存」→「変更のアクティブ化」をクリックします。
BI_SERVER2サーバーに対してこれらの手順を繰り返します。
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。 |
通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、第15.3.3.9.1項「APPHOST1でのノード・マネージャの起動」の手順を繰り返して、APPHOST2でノード・マネージャを起動してください。
BI_SERVER2管理対象サーバーを起動して、正しく構成されていることをチェックする手順は、次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、次のように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=ohs2
管理コンソールで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の実行中に、Oracle WebLogic Server管理コンソールからBI_SERVER1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WEBHOST1:7777/wsm-pm
WEBHOST1:7777/ui
Oracle WebLogic Server管理コンソールからBI_SERVER1を起動します。
BI_SERVER2を停止します。
前述のステップ2のURLにアクセスして、適切な機能を検証します。
この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を構成する必要があります。これを行うには、第15.1.3.21項「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ホーム・リストを更新する場合は、User_Home/bea/beahomelistファイルを編集します。次の手順を参照してください。
新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。
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/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
VIP3をAPPHOST3で有効にします。第15.2.3.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。
第15.3.3.10項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームからコンフィギュレーション・アシスタントを実行します。
第15.3.3.11項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第15.3.3.12項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名検証を無効にすることで、bi_server3管理対象サーバーを構成します。
追加のOracle Real-Time Decisions構成手順を、第15.3.3.13項「Oracle RTDの構成」に記載されている手順をガイドとして使用してAPPHOST3上のbi_server3管理対象サーバーに対して実行します。
第15.3.3.14.1項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。
第15.3.3.15項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。
APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第15.3.3.9.2項「BI_SERVER1管理対象サーバーの起動と検証」を参照してください。
構成を検証するには、http://APPHOST3VHN1:9704/ui
というURLにアクセスして、Oracle RTDアプリケーションのステータスを確認します。
ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の「ノード・マネージャの設定」を参照してください。