Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-01 |
|
![]() 前 |
![]() 次 |
この章では、構成アシスタントを使用してOracle Business Intelligenceシステムをスケール・アウトする方法について説明します。Oracle Business Intelligence ORACLE_HOME(バイナリ)がすでにインストール済でAPPHOST1とAPPHOST2からアクセス可能であること、および管理サーバーが属するドメインが作成済であることを前提としています。この章では、このドメインを拡張して、Oracle Business Intelligenceコンポーネントをサポートします。
重要: セットアップのプロセスを開始する前に、『Oracle Fusion Middlewareリリース・ノート』に目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。 |
この章は、次の項で構成されています。
この項では、APPHOST2でOracle Business Intelligenceをスケール・アウトする方法について説明します。次の各項の手順を実行します。
この項の構成は、次のとおりです。
Oracle BIリポジトリのリポジトリ公開ディレクトリを指定すると、各Oracle BI Serverインスタンスによってネットワーク上の共有場所からリポジトリがロードされます。
Oracle Enterprise Manager Fusion Middleware Controlで次の手順を実行します。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「デプロイメント」をクリックしてから、「リポジトリ」をクリックします。
「構成をロックして編集」をクリックします。
「リポジトリの共有」を選択し、Oracle BIリポジトリの「共有場所」を指定します。
Windows環境では、UNCパス名を指定する必要があります。
すでにシステムにローカルにデプロイされているリポジトリがある場合は、それがコピーされるように共有の場所にアップロードします。そのようなリポジトリがない場合は、この手順をスキップできます。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
各Presentation Servicesインスタンスによって、Fusion Middleware Controlで指定されているカタログの場所からOracle BI Presentation Catalogがロードされます。
次のステップを実行します。
既存の(ローカルに公開された)Oracle BIプレゼンテーション・カタログを共有場所にコピーします。次にローカルに公開されたカタログの例を示します。
ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/ coreapplication_obipsn/catalog/SampleAppLite
この手順は、Fusion Middleware Controlから「カタログの場所」を指定する前に実行する必要があります。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「デプロイメント」をクリックしてから、「リポジトリ」をクリックします。
「構成をロックして編集」をクリックします。
共有Oracle BI Presentation Catalogの「カタログの場所」を指定します。
Windows環境では、UNCパス名を指定する必要があります。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
グローバル・キャッシュは、共有ファイル・システムのストレージ・デバイスに配置されており、パージ・イベント、シード・イベント(多くの場合はエージェントによって生成されます)、およびシード・イベントと関連付けられた結果セットを格納します。各Oracle BI Serverでは、通常の問合せ用に独自のローカル問合せキャッシュが引き続き保持されます。
Fusion Middleware Controlで次の手順を実行します。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「容量管理」をクリックしてから、「パフォーマンス」をクリックします。
「構成をロックして編集」をクリックします。
「グローバル・キャッシュ」セクションの「グローバル・キャッシュ・パス」フィールドに、パージおよびシードの各キャッシュ・エントリを格納するための共有場所を指定します。Windows環境では、UNCパス名を指定する必要があります。
「グローバル・キャッシュ・サイズ」に値を入力し、グローバル・キャッシュの最大サイズ(たとえば250MB)を指定します。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
「再起動して最近の変更を適用」をクリックします。
「システムの管理」で「再起動」をクリックします。
確認ダイアログで「はい」をクリックします。
ORACLE_HOMEディレクトリから構成アシスタントを実行して、次のようにBIシステムをスケール・アウトします。
次のように、構成アシスタントの場所にディレクトリを移動します。
APPHOST2> cd ORACLE_HOME/bin
Oracle Business Intelligence構成アシスタントを起動します。
APPHOST2> ./config.sh
「ようこそ」画面で、「次へ」をクリックします。
「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。
作成、スケール・アウト、または拡張画面でBIシステムのスケール・アウトを選択して、次の値を入力します。
ホスト名: ADMINVHN
ポート: 7001
ユーザー名: weblogic
ユーザー・パスワード: your_password
「次へ」をクリックします。
BIシステムのスケール・アウトの詳細画面で、次の値を入力します。
ミドルウェア・ホーム: ORACLE_BASE/product/fmw (淡色表示)
Oracleホーム: ORACLE_BASE/product/fmw/Oracle_BI1 (淡色表示)
WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3 (淡色表示)
ドメイン・ホーム: ORACLE_BASE/admin/domain_name/mserver/domain_name
アプリケーション・ホーム: ORACLE_BASE/admin/domain_name/mserver/applications
インスタンス・ホーム: ORACLE_BASE/admin/instance2
インスタンス名: instance2 (淡色表示)
「次へ」をクリックします。
「ポートの構成」画面で、次のいずれかを選択します。
自動でポートを構成
構成ファイルを使用してポートを指定
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。
「次へ」をクリックします。
「サマリー」画面で「構成」をクリックします。
「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。
完了画面で「終了」をクリックします。
通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、APPHOST2で次のコマンドを実行してノード・マネージャを起動します。
ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
APPHOST2> cd ORACLE_COMMON_HOME/common/bin
APPHOST2> ./setNMProps.sh
注意: クラスのロード障害が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。 |
ノード・マネージャを起動します。
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サーバー
Presentation Server
JavaHost
「ポート範囲(開始)」と「ポート範囲(終了)」を、APPHOST1の「instance1」Oracleインスタンスと同じになるように変更します。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
この時点では再起動する必要はありません。なぜなら、第6.3項の手順を完了した後で再起動を実行するからです。
Oracle BI Cluster ControllerとOracle BI Schedulerは、アクティブ/パッシブ・モードで動作するシングルトン・コンポーネントです。高可用性を実現するために、これらのコンポーネントのセカンダリ・インスタンスを構成して分散させます。
Fusion Middleware Controlで次の手順を実行します。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「容量管理」をクリックしてから、「可用性」をクリックします。
「構成をロックして編集」をクリックして、「可用性」タブの「プライマリ/セカンダリ構成」セクションをアクティブ化します。
BI SchedulerとBI Cluster Controllerの「セカンダリ・ホスト / インスタンス」を指定します。
「適用」をクリックします。
「潜在的単一点障害」で、「問題はありません。すべてのコンポーネントにバックアップがあります。」と報告されていることを確認します。
「変更のアクティブ化」をクリックします。
「再起動して最近の変更を適用」をクリックします。
「システムの管理」で「再起動」をクリックします。
確認ダイアログで「はい」をクリックします。
この項では、bi_server2管理対象サーバーを構成する方法について説明します。項目は次のとおりです。
bi_server2リスニング・アドレスを設定する前に、第2.2.3.1項、「管理対象サーバーの仮想IPの有効化」で説明している手順を実行済であることを確認してください。
次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server2」を選択します。bi_server2の設定ページが表示されます。
「リスニング・アドレス」をAPPHOST2VHN1に設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
変更内容は、bi_server2管理対象サーバーが再起動されるまでは有効になりません。
この手順は、管理サーバーで様々なノードを認証するための適切な証明書を設定していない場合に必要です(第7章「ノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、様々なOracle WebLogic Serverを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証を行う際にホスト名の検証を無効にし、EDGトポロジの構成完了後に第7章「ノード・マネージャの設定」の説明に従って再びホスト名の検証を有効にします。
ホスト名検証を無効にする手順は次のとおりです。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server2」を選択します。そのサーバーの設定ページが表示されます。
「 SSL 」タブを開きます。
表示されたページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
この変更内容は、bi_server2管理対象サーバーが再起動されるまでは適用されません(ノード・マネージャが稼働していることを確認します)。
「サーバーの概要」画面で、「制御」タブを選択します。
表で「bi_server2」を選択してから、「停止」をクリックします。
表で「bi_server2」を選択してから、「起動」をクリックします。
APPHOST2上のBIシステムのコンポーネントを次のように再起動します。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「Business Intelligence概要」ページで、「再起動」をクリックします。
この項では、Oracle BI Scheduler、Oracle Real-Time Decisions、Oracle BI PublisherおよびOracle BI for Microsoft Officeの高可用性の追加の構成タスクについて説明します。次の項目が含まれます。
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スクリプトの場所を指すパスにこれを変更します。
Windows環境では、UNCパス名を指定する必要があります。
Oracle BI Schedulerコンポーネントを次のように再起動します。
opmnctl stopproc ias-component=coreapplication_obisch1 opmnctl startproc ias-component=coreapplication_obisch1
Oracle BI Schedulerのinstanceconfig.xmlファイルは、ORACLE_INSTANCE/config/OracleBISchedulerComponent/coreapplication_obischnにあります。デプロイメント内の各Oracle BI Schedulerコンポーネントに対して、このファイルを更新する必要があります。
この項の構成は、次のとおりです。
Fusion Middleware Controlで次の手順を実行して、Oracle RTDのクラスタ固有の構成プロパティを設定します。
次の手順は、デプロイメントの最初のノードでのみ実行する必要があります。2番目以降のノードでOracle RTDのクラスタ固有の構成プロパティを設定する必要はありません。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「アプリケーション・デプロイメント」ノードを開きます。
「OracleRTD(11.1.1)(bi_cluster)」をクリックします。
その下の任意のノードをクリックします。たとえば、「OracleRTD(11.1.1)(bi_server1)」をクリックします。
右側のペインで、「アプリケーション・デプロイメント」をクリックして、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ペインで、「アプリケーション定義のMBean」を開きます。
「OracleRTD」の下のいずれかのサーバーで、「SDClusterPropertyManager」→その他のMBeanに移動し、DecisionServiceAddress属性をhttp://bi.mycompany.comに設定します。他のサーバーは、設定した値で自動的に更新されます。
「適用」をクリックします。
Oracle RTDをスケール・アウトした後、管理コンソールを使用して、各管理対象サーバーの「サーバーの起動」タブに3つのシステム・プロパティを追加します。
管理コンソールで、「環境」→「サーバー」→「bi_server<1,2>」→「サーバーの起動」→「引数」を選択し、次の3つのプロパティを追加します。
-Drtd.clusterRegistryJobIntervalMs=12000 -Drtd.clusterDepartureThresholdMs=50000 -Drtd.clusterDepartureThreshold2Ms=50000
このタスクを実行することによって、管理対象サーバーに障害が発生した場合にOracle RTDのインスタンスをサーバー間で正常に移行できるようになります。
これらの変更を行ったとしても、サーバーの移行が50秒未満で完了した場合は、Oracle RTDバッチ・フレームワークは不整合な状態になります。
バッチ・ジョブの実装をホストするRTDインライン・サービスがデプロイされている場合、サーバー移行後にバッチ・コンソール・コマンドbatch-names (またはその短縮名bn)を実行しても登録されているバッチ・ジョブが1つも表示されないときは、Oracle RTDバッチ・マネージャを停止してから再起動する必要があります。そのためには、次の手順に従ってください。
Fusion Middleware Controlの左側のペインで、「WebLogicドメイン」ノードを開きます。「bifoundation_domain」を右クリックして、「システムMBeanブラウザ」を選択します。
「アプリケーション定義のMBean」→「OracleRTD」→「Server:bi_server1」→「サーバー」または「アプリケーション定義のMBean」→「OracleRTD」→「Server:bi_server2」→「サーバー」のどちらかで、「BatchManager MBean」を探します。
これはどちらか一方にのみ存在し、両方に存在することはありません。
「BatchManager MBean」が存在する側で、「SDPropertyManager」→「その他」でMBean属性BatchManagerEnabledを探します。たとえば、BatchManager MBeanがbi_server1に存在する場合は、「アプリケーション定義のMBean」→「OracleRTD」→「Server:bi_server1」→「SDPropertyManager」→「その他 : BatchManagerEnabled」を選択します。
BatchManagerEnabled属性をfalseに設定し、「適用」をクリックします。
BatchManagerEnabled属性をtrueに戻し、「適用」をクリックします。このタスクを実行すると、バッチ・マネージャが停止し、再起動されます。
再起動後は、その前と同じサーバーまたは別のサーバーのどちらかで実行されます。
バッチ・マネージャの再起動後は、バッチ・マネージャが実行されているサーバーで、対応するMBeanが必ずしも即座にリフレッシュされるわけではないので、気にする必要はありません。かわりに、バッチ・コンソール・ツールを使用して、次のようにバッチ・マネージャが現在実行されていることを確認します。
次の場所で、Oracle RTDクライアント・ツールのzipファイルを探します。
ORACLE_HOME/clients/rtd/rtd_client_11.1.1.zip
ほとんどのOracle RTDクライアント・ツールはUNIX上で動作しないので、このファイルはWindowsコンピュータ上で解凍してください。ここではRTD_HOMEで解凍します。この場合、次のバッチ・コンソールjarファイルを探します。
RTD_HOME/client/Batch/batch-console.jar
このディレクトリに移動し、管理対象サーバーまたはクラスタ・プロキシのどちらかのURLとポートを渡してjarを実行します。
java -jar batch-console.jar -url http://SERVER:PORT
プロンプトが表示されたら、管理者ロール、BI_AdministratorロールまたはOracle RTDバッチ・ジョブの管理権限を付与された他のロールのいずれかのメンバーであるユーザーのユーザー名とパスワードを入力します。
コマンドの入力を求められたら、bn
と入力します。
Checking server connection... command: bn CrossSellSelectOffers command:quit
バッチ・マネージャが正常に起動されている場合、bnコマンドによって、デプロイされているすべてのRTDインライン・サービスによってホストされているすべてのバッチ実装の名前がリストされます。
一般的なデプロイ例であるCrossSellでは、上の例に示すCrossSellSelectOffersという名前のバッチ実装がホストされます。
この項の構成は、次のとおりです。
Oracle BI Publisherのサーバー構成オプションを設定するには、次の手順を実行します。
DOMAIN_HOME/config/bipublisher/repositoryディレクトリの内容を構成フォルダの共有場所にコピーします。
APPHOST1またはAPPHOST2のどちらかで管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「サーバー構成」を選択します。
「構成フォルダ」の「パス」フィールドで、構成フォルダの共有場所を入力します。
変更を適用してから、BI Publisherアプリケーションを次のように再起動します。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「デプロイメント」をクリックします。
「bipublisher(11.1.1)」を選択します。
「停止」をクリックします。
アプリケーションが停止したら、「起動」をクリックします。
管理対象サーバーの再起動時、Oracle BI Publisherがその構成を読み取るのは、管理対象サーバーの構成ディレクトリからではなく、中央拠点である管理サーバーからなので、Oracle BI PublisherのXML構成ファイルを管理対象サーバーから管理サーバーの場所にコピーする必要があります。
そのためには、APPHOST1上で次の場所からファイルxmlp-server-config.xmlをコピーします。
ORACLE_BASE/admin/domain_name/mserver/domain_name/config/bipublisher
コピー先:
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/bipublisher
次の手順に従って、スケジューラ構成オプションを設定します。
APPHOST1で管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「スケジューラ構成」を選択します。
「スケジューラ選択」で「クォーツ・クラスタリング」を選択します。
「適用」をクリックします。
次の手順に従って、Oracle BI PublisherでOracle BI Presentation Servicesとの統合を構成します。
管理者の資格証明を使用してOracle BI Publisherにログインして、「管理」タブを選択します。
「統合」で、「Oracle BIプレゼンテーション・サービス」を選択します。
次の設定を確認して更新します。
サーバー・プロトコル: HTTP
サーバー: biinternal.mycompany.com
ポート: 80
URL接頭辞: analytics-ws/saw.dll
「適用」をクリックします。
Oracle BI Publisherアプリケーションを再起動します。
Oracle BI EEのデータソースは、Cluster Controllerを介して、クラスタ化されたOracle BI Serverを参照する必要があります。このタスクは、Oracle BI Publisherで実行します。
Oracle BI PublisherでOracle BI EEのデータソースを設定する手順は次のとおりです。
管理者の資格証明を使用してOracle BI Publisherにログインして、「管理」タブを選択します。
「データソース」で、「JDBC接続」を選択します。
「接続文字列」パラメータを次のように変更して、Oracle BI EEのデータソース設定を更新します。
jdbc:oraclebi://primary_cluster_controller_host:primary_cluster_controller_ port/PrimaryCCS=primary_cluster_controller_host;PrimaryCCSPort=primary_cluster_ controller_port;SecondaryCCS=secondary_cluster_controller_host; SecondaryCCSPort=secondary_cluster_controller_port;
例:
jdbc:oraclebi://APPHOST1:9706/PrimaryCCS=APPHOST1;PrimaryCCSPort=9706; SecondaryCCS=APPHOST2;SecondaryCCSPort=9706;
「システム・ユーザーの使用」を選択解除して、「ユーザー名」と「パスワード」に管理者の資格証明(例: weblogic)を指定します。
「接続のテスト」をクリックします。「接続は正常に確立されました。」というメッセージが表示されることを確認します。
「適用」をクリックします。
両方のノードから参照できるディレクトリに、すべての永続ストアの場所を構成する必要があります。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。
名前(例: BipJmsStore2)を入力し、BI_SERVER2をターゲットにします。APPHOST1とAPPHOST2の両方からアクセスできるように、共有記憶域にあるディレクトリを入力します。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「OK」をクリックし、「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSサーバー」ノードをクリックします。「JMSサーバーのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックします。
名前(例: BipJmsServer2)を入力してから「永続ストア」ドロップダウン・リストで「BipJmsStore2」を選択し、「次へ」をクリックします。
「BI_SERVER2」をターゲットとして選択します。
「終了」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。「JMSモジュール」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BipJmsResource」→「サブデプロイメント」タブをクリックします。
「サブデプロイメント」で「BipJmsSubDeployment」を選択します。
サブデプロイメントの追加ターゲットとして、新しいOracle BI Publisher JMSサーバーBipJmsServer2を追加します。
「保存」→「変更のアクティブ化」をクリックします。
Oracle BI Publisherに対して実行したJMS構成を検証するには、第6.5.3.6項「Oracle BI Publisher Schedulerの構成の更新」の手順を実行してください。
この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLとJMS共有一時ディレクトリを更新します。この項の手順は、複数のAPPHOSTのいずれか1つ(APPHOST1またはAPPHOST2)でのみ実行する必要があります。
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の両方からアクセスできます。
「JMSのテスト」をクリックします。
JMSのテストが成功したという確認メッセージが表示されることを確認します。
「適用」をクリックします。
スケジューラのステータスを「スケジューラ診断」タブでチェックします。
この項の構成は、次のとおりです。
次の手順に従って、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サーバーについて」ページが表示されます(図6-1を参照)。
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 EE Officeサーバーのディレクトリは、logディレクトリの親ディレクトリです。
APPHOST1およびAPPHOST2の両方で、bioffice.xmlを編集のために開いて、表6-1のとおりにプロパティを変更します。
表6-1 bioffice.xmlのプロパティ
プロパティ名 | 有効な値 | 説明 |
---|---|---|
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サーバーとPresentation Servicesの間のWebサービス・リクエスト用に使用されます。 |
SawUseSSO |
0 = いいえ(デフォルト) 1 = はい |
実装されたOracle Business IntelligenceがSSOに対応している場合は、このプロパティを1に設定します。 |
SawWebURLforSSO |
https://bi.mydomain.com:443/analytics/saw.dll |
SSOが有効な場合、このプロパティを使用して、外部ユーザーがOracle BI for Microsoft OfficeからSSOを介してOracle Business Intelligenceにアクセスする際に使用するパブリックURLを入力します。 |
Oracle BI for Microsoft Officeアプリケーションを次のように再起動します。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「デプロイメント」をクリックします。
「bioffice(11.1.1)」を選択します。
「停止」をクリックします。
アプリケーションが停止したら、「起動」をクリックします。
Oracle BI EE Officeサーバーについてページで、「SawBaseURL」パラメータが更新されていることを確認します。
次の手順に従って、Oracle BI for Microsoft Officeの構成を検証します。
次の場所でOracle BIプレゼンテーション・サービスにログインします:
https://bi.mydomain.com:443/analytics
左下ペインの「はじめに」見出しの下で、「BIデスクトップ・ツールのダウンロード」を選択してから、「Oracle BI for MS Office」を選択します。
Oracle BI OfficeのInstallShieldウィザードを実行して、Oracle BI for Microsoft Officeをインストールします。
Microsoft ExcelまたはMicrosoft PowerPointを開きます。
「Oracle BI」メニューから「設定」を選択します。
「接続」タブで「新規」を選択します。
次のフィールドに値を入力します。
サーバー名: 接続の名前を指定します。
BI Officeサーバー: Oracle BI EE OfficeサーバーのURLを指定します。
アプリケーション名: Oracle BI EE Officeサーバー・アプリケーションをWLSにデプロイしたときにOracle BI EE Officeサーバーに対して定義したアプリケーション名を入力します。デフォルト名は「bioffice」です。
ポート: Oracle BI EE Officeサーバーのポート番号を入力します。
図6-2は、「新規接続」ダイアログを示しています。
図6-2 Oracle BI for Microsoft Officeの「新規接続」ダイアログ
「接続のテスト」をクリックして、アドインとOracle BI EE Officeサーバー間の接続をテストします。
正常に接続されている場合は、図6-3に示すように「接続テストが成功しました。」というメッセージが表示されます。
管理者(例: weblogic)としてログインして、図6-4に示す「Oracle BIタスク・ペイン」にアクセスできることを確認します。
各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。
注意: デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。 |
各管理対象サーバーで次の手順を実行して、デフォルト永続ストアの場所を設定します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの「設定」ページが開き、「構成」タブがデフォルトで表示されます。
「サービス」タブを開きます。
表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/bi_cluster_name/tlogs
各管理対象サーバーで同じパスを使用します。管理対象サーバーが再起動されると、それぞれにサブディレクトリが作成されます。
「保存」→「変更のアクティブ化」をクリックします。
注意: トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。bi_server1とbi_server2の両方からこのディレクトリにアクセスできる必要があります。 |
この項の構成は、次のとおりです。
次の手順を実行して、bi_server2管理対象サーバーを起動します。
管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
「制御」タブをクリックします。
「bi_server2」を選択してから、「起動」をクリックします。
管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
opmnctlコマンドを使用して、Oracle Business Intelligenceのシステム・コンポーネントを制御できます。
opmnctlコマンドライン・ツールを使用してOracle Business Intelligenceシステム・コンポーネントを起動する手順は次のとおりです。
OPMNコマンドライン・ツールがあるディレクトリに移動します。これは、ORACLE_INSTANCE/binにあります。
opmnctlコマンドを実行して、Oracle Business Intelligenceシステム・コンポーネントを起動します。
opmnctl startall
OPMNおよびすべてのOracle Business Intelligenceシステム・コンポーネントを起動します。
opmnctl start
OPMNのみ起動します。
opmnctl startproc ias-component=component_name
特定のシステム・コンポーネントを起動します。たとえば、coreapplication_obips2がPresentation Servicesコンポーネントの場合、次のように実行します。
opmnctl startproc ias-component=coreapplication_obips2
Oracle Business Intelligenceシステム・コンポーネントのステータスをチェックします。
opmnctl status
次のURLにアクセスします。
http://APPHOST2VHN1:9704/analytics
にアクセスして、bi_server1のステータスを確認します。
http://APPHOST2VHN1:9704/wsm-pm
にアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データに含まれる使用可能なポリシーとアサーション・テンプレートのリストが表示されます。
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。
http://APPHOST2VHN1:9704/xmlpserver
にアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。
http://APPHOST2VHN1:9704/ui
にアクセスして、Oracle Real-Time Decisionsアプリケーションのステータスを確認します。
http://APPHOST2VHN1:9704/mapviewer
にアクセスして、Oracle MapViewerのステータスを確認します。
URLを検証して、Oracle HTTP Serverからbi_clusterへのルーティングとフェイルオーバーが適切に機能することを確認する必要があります。URLを検証する手順は次のとおりです。
bi_server2の実行中に、管理コンソールを使用してbi_server1を停止します。
次のURLにアクセスして、ルーティングとフェイルオーバーが適切に機能することを確認します。
http://WEBHOST1:7777/analytics
http://WEBHOST1:7777/xmlpserver
http://WEBHOST1:7777/ui
管理コンソールからbi_server1を起動します。
管理コンソールからbi_server2を停止します。
次のURLにアクセスして、ルーティングとフェイルオーバーが適切に機能することを確認します。
http://WEBHOST1:7777/analytics
http://WEBHOST1:7777/xmlpserver
http://WEBHOST1:7777/ui
管理コンソールからbi_server2を起動します。
ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第7章「ノード・マネージャの設定」を参照してください。その章の手順は、表6-2に示す情報を使用して、2回実行する必要があります。
サーバー移行は、APPHOST1ノードとAPPHOST2ノードのどちらかで障害が発生した場合に、Oracle BI Publisherコンポーネントを正しくフェイルオーバーするために必要です。詳細は、第8章「サーバー移行の構成」を参照してください。
スケール・アウトしたドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、このガイドのOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法の詳細は、このガイドのコンポーネントのリカバリおよびコンポーネント・ホストが失われた後のリカバリの項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、このガイドの別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドも参照してください。
次の手順を実行して、この時点でのインストールをバックアップします。
Web層をバックアップする手順は次のとおりです。
opmnctl
を使用してインスタンスを停止します。
WEBHOSTn> ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。
WEBHOSTn> tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
次のコマンドを使用して、Web層のOracleインスタンスをバックアップします。
WEBHOSTn> tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE
WEBHOST2についても、この手順を繰り返します。
opmnctl
を使用してインスタンスを起動します。
WEBHOSTn> cd ORACLE_BASE/admin/instance_name/bin WEBHOSTn> opmnctl startall
データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。
次のように、アプリケーション層のBIインスタンスをバックアップします。
opmnctlを使用してインスタンスを停止します。
APPHOST1> ORACLE_INSTANCE/bin/opmnctl stopall
次のコマンドをroot権限で実行して、アプリケーション層のミドルウェア・ホームをバックアップします。
APPHOST1> tar -cvpf BACKUP_LOCATION/bi.tar MW_HOME
次のコマンドを使用して、アプリケーション層のOracleインスタンスをバックアップします。
APPHOST1> tar -cvpf BACKUP_LOCATION/bi_instance_name.tar ORACLE_INSTANCE
opmnctlを使用してインスタンスを起動します。
APPHOST1> ORACLE_INSTANCE/bin/opmnctl startall
ドメイン構成を保存するために、管理サーバーと管理対象サーバーのドメイン・ディレクトリをバックアップします。すべての構成ファイルはORACLE_BASE/admin/ domain_nameディレクトリにあります。次のコマンドを実行してバックアップを作成します。
APPHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
注意: このセクションに示す手順に従って、アプリケーション層内のすべてのコンピュータ上にバックアップを作成します。