12 Oracle Analytics Serverのスケール・アウト

この章では、初期Oracle Analytics ServerドメインをBIHOST2にスケール・アウトするステップについて説明します。

コンポーネントのスケール・アウトでは、別のホスト・コンピュータへのOracle Analytics Serverのインストール、BIHOST1でのコンポーネントの停止とクローニング、ドメインの圧縮と解凍、スケール・アウト後のコンポーネントの開始といった作業が必要になります。

• 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール
  
• 別のホスト・コンピュータへのOracle Analytics Serverのインストール
  BIHOST2用に個別の共有記憶域ボリュームまたはパーティションを構成している場合は、BIHOST2にソフトウェアをインストールすることも必要になります。
• BIHOST1のコンポーネントの停止
  スケール・アウトの前に、BIHOST1のドメインのすべてのコンポーネント・プロセスを停止する必要があります。
• BIHOST1のコンポーネントのクローニング
  すべてのコンポーネント・プロセスを停止した後に、BIHOST1のドメイン内のコンポーネントをクローニングする必要があります。これにより、作成した初期ドメインに基づく新しいコンポーネントがBIHOST2に作成されます。
• BIHOST1の初期ドメインの圧縮
  この項のステップを使用して、ドメイン構成情報(現在はOracle HTTP Serverインスタンスに関する構成情報が含まれる)を格納したテンプレートjarファイルを作成します。
• BIHOST2でのドメインの解凍
  この項のステップを使用して、ドメイン構成情報を格納したドメイン・テンプレートを解凍し、bidomaintemplate.jarファイルをBIHOST1からBIHOST2にコピーします。
• スケール・アウト後のBIHOST1およびBIHOST2でのコンポーネントの起動
  この項では、スケール・アウト後にBIHOST1およびBIHOST2でコンポーネント・プロセスを起動するステップについて説明します。コンポーネント・プロセスには、ノード・マネージャ、WebLogicドメインの管理サーバー、システム・コンポーネントおよび管理対象サーバーが含まれます。
• BIHOST2のOracle Analytics Server URLの検証
  BIHOST2でドメイン内のコンポーネントを起動したら、それらのURLにアクセスしてOracle Analytics Serverの構成を検証します。
• Oracle Analytics Publisherの構成
  次に示す手動タスクを実行して、Oracle Analytics Publisherを構成します。
• スケール・アウト後のOracle Analytics Server構成のバックアップ
  Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。

他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

2番目のホストに対して個別の共有記憶域ボリュームまたはパーティションを構成している場合は、Infrastructureをこれらのホストのいずれかにインストールする必要があります。

「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「BIHOST1でのInfrastructureインストーラの起動」と「Infrastructureインストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。

注意:

以前のリリースでは、推奨エンタープライズ・トポロジに、同じ場所に配置された一連のOracle HTTP Serverインスタンスが含まれていました。こうしたリリースでは、InfrastructureをWeb層ホストにインストールする必要がありました(WEBHOST1およびWEBHOST2)。しかし、このリリースの場合、エンタープライズ・デプロイメント・トポロジでは、Webサーバーがスタンドアロン・モードでインストールおよび構成されると想定しているため、これらがアプリケーション層ドメインに含まれるとは考えられていません。「エンタープライズ・デプロイメント用のOracle HTTP Serverの構成」を参照してください

別のホスト・コンピュータへのOracle Analytics Serverのインストール

BIHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、BIHOST2にもソフトウェアをインストールする必要があります。

「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「インストール・プログラムの起動」と「インストール画面のナビゲート」の手順に従います。

BIHOST1のコンポーネントの停止

スケール・アウトの前に、BIHOST1のドメインのすべてのコンポーネント・プロセスを停止する必要があります。

コンポーネント・プロセスには、ノード・マネージャ、WebLogicドメインの管理サーバー、システム・コンポーネントおよびノード・マネージャによって制御されるWLS_BI1管理対象サーバーが含まれます。

BIHOST1のドメインのすべてのコンポーネントを停止するには、次のタスクを実行します。

• システム・コンポーネントの停止
  
• WLS_BI1管理対象サーバーの停止
  
• 管理サーバーの停止
  
• 管理サーバー・ドメイン・ホームでのノード・マネージャの停止
  
• 管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの停止
  

システム・コンポーネントの停止

次のステップに従って、Fusion Middleware Controlを使用してシステム・コンポーネントを停止します。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

   http://ADMINVHN:7001/em
   

2. 管理サーバー資格証明を使用してFusion Middleware Controlにサインインします。
3. 「ターゲット・ナビゲーション」ペインがまだ表示されていない場合は、ページの左上隅にある「ターゲット・ナビゲーション」アイコンをクリックして表示します。
4. 「ターゲット・ナビゲーション」ペインで「Business Intelligence」フォルダを展開し、「biinstance」を選択します。
   Business Intelligenceの「概要」ページが表示されます。
5. 「可用性」、「プロセス」の順にクリックして、「可用性」ページの「プロセス」タブを表示します。
6. すべてのシステム・コンポーネントを停止するには、「すべて停止」をクリックします。

WLS_BI1管理対象サーバーの停止

次のステップに従って、Fusion Middleware Controlを使用してWLS_BI1管理対象サーバーを停止します。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

   http://ADMINVHN:7001/em
   

2. 管理サーバー資格証明を使用してFusion Middleware Controlにサインインします。
3. 「ターゲット・ナビゲーション」ペインがまだ表示されていない場合は、ページの左上隅にある「ターゲット・ナビゲーション」アイコンをクリックして表示します。
4. 「ターゲット・ナビゲーション」ペインで、「WebLogicドメイン」フォルダのドメインを開き、ドメイン内の管理対象サーバーを表示します。
5. WLS_BI1管理対象サーバーのみを選択します。
6. Oracle WebLogic Serverツールバーで「停止...」をクリックします。
7. 停止操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_BI1管理対象サーバーが停止していることを確認します。

管理サーバーの停止

これらのステップを使用して、ノード・マネージャを通じて管理サーバーを停止します。

1. WLSTを起動します。

   cd ORACLE_COMMON_HOME/common/bin
   ./wlst.sh
   

2. 構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します。

   wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
               'ADMINVHN','5556','domain_name',
               'ASERVER_HOME')

   注意:

   このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

   ASERVER_HOME/config/nodemanager

3. 管理サーバーを停止します。:

   nmKill('AdminServer')
   

4. WLSTを終了します。

   exit()

管理サーバー・ドメイン・ホームでのノード・マネージャの停止

これらのステップを使用して、ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを停止します。

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

   ASERVER_HOME/bin
   

2. 次のコマンドを使用してノード・マネージャを停止します。

   ./stopNodeManager.sh 

管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの停止

これらのステップを使用して、MSERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを停止します。

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

   MSERVER_HOME/bin
   

2. 次のコマンドを使用してノード・マネージャを停止します。

   ./stopNodeManager.sh 

BIHOST1のコンポーネントのクローニング

すべてのコンポーネント・プロセスを停止した後に、BIHOST1のドメイン内のコンポーネントをクローニングする必要があります。これにより、作成した初期ドメインに基づく新しいコンポーネントがBIHOST2に作成されます。

BIHOST1で次のステップを実行し、既存の管理対象サーバー、ノード・マネージャ、システム・コンポーネントおよびサービス・インスタンスをクローニングして、追加のコンポーネントを作成します。後で、BIHOST2の新しいコンポーネントを圧縮および解凍します。

1. WLSTを起動します。

   cd ORACLE_HOME/oracle_common/common/bin
   ./wlst.sh

2. 更新用のOracle Analytics Server管理サーバー・ドメインを開きます。

   wls:/offline> readDomain(‘ASERVER_HOME’)

   この例では、ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

3. CloneBIMachineコマンドを実行して、初期Oracle Analytics Serverドメインに既存のコンポーネントに基づいた追加のコンポーネントを作成します。

   wls:/offline/bi_domain> cloneBIMachine('ASERVER_HOME','bihost2vhn.example.com',baseMachine='BIHOST1',baseServer='WLS_BI1',machineName='BIHOST2')

   この例では、次のとおりです。

   • ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

   • bihost2vhn.example.comを新しいマシンBIHOST2VHNのリスニング・アドレスで置き換えます。

   • WLS_BI1は、このドキュメント全体で使用されるBIHOST1のOracle Analytics Server管理対象サーバーのサーバー名です。別の名前を選択した場合は、必要に応じて置き換えてください。

4. ドメインを更新して保存します。

   wls:/offline/bi_domain/SystemComponent/obis2> updateDomain()

5. ドメインを閉じます。

   wls:/offline/bi_domain/SystemComponent/obis2> closeDomain()

6. WLSTを終了します。

   wls:/offline> exit()

BIHOST1の初期ドメインの圧縮

この項のステップを使用して、ドメイン構成情報(現在はOracle HTTP Serverインスタンスに関する構成情報が含まれる)を格納したテンプレートjarファイルを作成します。

1. BIHOST1にサインインし、次のようにpackコマンドを実行してテンプレートJARファイルを作成します。

   cd ORACLE_COMMON_HOME/common/bin
    
   ./pack.sh -managed=true \ 
             -domain=ASERVER_HOME \ 
             -template=complete_path/bidomaintemplate.jar \ 
             -template_name=bi_domain_template

   この例では、次のとおりです。

   • ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

   • complete_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスで置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。

   • bidomaintemplate.jarは、作成するJARファイルのサンプル名です。これには、Oracle HTTP Serverインスタンスの構成ファイルなどのドメイン構成ファイルが含まれます。

   • bi_domain_templateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

2. packコマンドで作成したばかりのbidomaintemplate.jarファイルの場所を書き留めます。

   デフォルトでは、パック・テンプレート・ファイルは、packコマンドを実行した現在のディレクトリに作成されます。この例では、ORACLE_COMMON_HOME/common/binディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。

   ヒント:

   packおよびunpackコマンドの詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』の「PackおよびUnpackコマンドの概要」を参照してください。

BIHOST2でのドメインの解凍

この項のステップを使用して、ドメイン構成情報を格納したドメイン・テンプレートを解凍し、bidomaintemplate.jarファイルをBIHOST1からBIHOST2にコピーします。

1. BIHOST2にログインします。
2. BIHOST1のドメイン・テンプレートjarファイルをBIHOST2にコピーします。
3. まだ作成していない場合は、BIHOST2のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

   「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
   complete_path

   cd ORACLE_COMMON_HOME/common/bin
   
   ./unpack.sh -domain=MSERVER_HOME \
       -template=complete_path/bidomaintemplate.jar \
       -app_dir=APPLICATION_HOME \
       -overwrite_domain=true \
       -nodemanager_type=PerDomainNodeManager	

   この例では、次のとおりです。

   • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

   • complete_pathを、テンプレートjarファイルを作成またはコピーした場所の完全なパスで置き換えます。

   • bidomaintemplate.jarは、packコマンドを実行してドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

     BIHOST2に別の共有記憶域ボリュームまたはパーティション(および冗長Oracleホーム)を使用している場合は、BIHOST2にマウントされているボリュームまたはパーティションに、まずテンプレートをコピーする必要があります。

   • APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

   ヒント:

   packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがBIHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

スケール・アウト後のBIHOST1およびBIHOST2でのコンポーネントの起動

この項では、スケール・アウト後にBIHOST1およびBIHOST2でコンポーネントを起動するステップについて説明します。コンポーネント・プロセスには、ノード・マネージャ、WebLogicドメインの管理サーバー、システム・コンポーネントおよび管理対象サーバーが含まれます。

BIHOST1およびBIHOST2でコンポーネントを起動する前に、BIHOST2でDerbyデータベースを無効にします。「Derbyデータベースの無効化」を参照してください。

スケール・アウト後にコンポーネントを起動するには、次のタスクを実行します。

• 管理サーバー・ドメイン・ホームでのノード・マネージャの起動
  
• 管理サーバーの起動
  
• 管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動
  
• 管理対象サーバーの起動
  
• システム・コンポーネントの起動
  

管理サーバー・ドメイン・ホームでのノード・マネージャの起動

BIHOST1上のASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動するには、「BIHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動」の手順を使用します。

管理サーバーの起動

ノード・マネージャを使用して管理サーバーを起動するには、ノード・マネージャを使用した管理サーバーの起動の手順を使用します。

管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

BIHOST1およびBIHOST2上のMSERVER_HOMEディレクトリのドメインごとのノード・マネージャを起動するには、「BIHOST1上の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動」の手順を使用します。「BIHOST1上の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動」のステップに従うとき、BIHOST1が使用されるところでBIHOST2の値を置き換えます。

管理対象サーバーの起動

新しいWLS_BI2管理対象サーバーを起動する前に、この新しい管理対象サーバーに関連付けられたマシンのノード・マネージャのリスニング・アドレスがBIHOST2の値に設定されていることを確認します。これを行うには、次のステップを実行します:

1. 管理サーバー資格証明を使用してFusion Middleware Controlにサインインします。
2. WebLogicドメインのドロップダウンを選択します。「環境」、「マシン」の順に選択します。
3. マシンBIHOST2を選択します。
4. 「構成」タブをクリックして、「ノード・マネージャ」タブをクリックします。
5. ページの右上隅にある「チェンジ・センター」メニューで「ロックして編集」をクリックします。
6. リスニング・アドレスを、BIHOST2の値になるように変更します。
7. 「保存」をクリックします。
8. ページの右上隅にある「チェンジ・センター」メニューで、「変更のアクティブ化」をクリックします。

WLS_BI1管理対象サーバーおよびWLS_BI2管理対象サーバーを起動するには、「BIHOST1でのWLS_BI1管理対象サーバーの起動」の手順を使用します。

システム・コンポーネントの起動

すべてのOracle Analytics Serverシステム・コンポーネントを起動するには、「システム・コンポーネントの起動」の手順を使用します。

BIHOST2のOracle Analytics Server URLの検証

BIHOST2でドメイン内のコンポーネントを起動したら、それらのURLにアクセスしてOracle Analytics Serverの構成を検証します。

• 次のURLにアクセスして、WLS_BI2のステータスを確認します。

  http://BIHOST2VHN:7003/analytics

  次にリダイレクトされます。

  http://bi.example.com/analytics

• 次のURLにアクセスして、Oracle Analytics Publisherアプリケーションのステータスを確認します。

  http://BIHOST2VHN:7003/xmlpserver

  次にリダイレクトされます。

  http://bi.example.com/xmlpserver

Oracle Analytics Publisherの構成

次に示す手動のタスクを実行して、Oracle Analytics Publisherを構成します。

• Oracle Analytics Publisher構成のシングルトン・データ・ディレクトリへのコピー
  スケール・アウトしたPublisherアプリケーションでは、それぞれのインスタンスが、特定の構成をクラスタ全体に設定するための共通の場所を必要とします。
• JMS共有のTempディレクトリの更新
  次のステップに従って、Oracle Analytics Publisher SchedulerのJMS共有のTempディレクトリを更新します。この項のステップは、Oracle Analytics Serverホストのいずれか1つ(BIHOST1またはBIHOST2)でのみ実行する必要があります。
• BI Presentation Servicesとの統合の構成
  
• Oracle Analytics Serverのデータ・ソースの設定
  Oracle Analytics Serverのデータ・ソースは、クラスタ化されたOracle Analytics Serverのサーバーをクラスタ・コントローラ経由で参照する必要があります。このタスクは、Oracle Analytics Publisherで実行する必要があります。
• Oracle Analytics Server Cluster用のBIPJmsResourceの構成
  BIPJMSResource JMSモジュールを構成するには、このトピックにリストされているモジュールの一部のデフォルト値を変更する必要があります。

Oracle Analytics Publisher構成のシングルトン・データ・ディレクトリへのコピー

スケール・アウトしたPublisherアプリケーションでは、それぞれのインスタンスが、特定の構成をクラスタ全体に設定するための共通の場所を必要とします。

次のステップを最後まで実行して、デフォルトのPublisher構成ファイルをシングルトン・データ・ディレクトリ(SDD)にコピーします。

1. 「シングルトン・データ・ディレクトリ(SDD)の構成」の「ステップ1」からSSDの場所を取得します。
   次に例を示します。

   ORACLE_RUNTIME/biconfig

2. BI_ASERVER_HOME/config/fmwconfig/biconfig/bipublisher/Adminディレクトリ全体をSDDサブディレクトリbidata/components/bipublisher/repositoryに再帰的にコピーします。
   次に例を示します。

   cp -R BI_ASERVER_HOME/config/fmwconfig/biconfig/bipublisher/Admin ORACLE_RUNTIME/biconfig/bidata/components/bipublisher/repository

3. 現在のディレクトリの内容を検証します。
   次に例を示します。

   ls -1 ORACLE_RUNTIME/biconfig/bidata/components/bipublisher/repository/Admin

   結果は、次の例のようになります。

   Configuration
   DataSource
   Delivery
   Map
   Plugins
   Scheduler
   Security

4. 管理対象サーバーのWLS_BI1とWLS_BI2を再起動します。

JMS共有のTempディレクトリの更新

次のステップを実行して、Oracle Analytics Publisher SchedulerのJMS共有のTempディレクトリを更新します。この項のステップは、Oracle Analytics Serverホストのいずれか1つ(BIHOST1またはBIHOST2)でのみ実行する必要があります。

次のステップを実行して、Oracle Analytics Publisher Scheduler構成を更新します。

1. 次のいずれかのURLを使用して、Oracle Analytics Publisherにサインインします。
   • http://BIHOST1VHN:7003/xmlpserver
   • http://BIHOST2VHN:7003/xmlpserver
2. 「管理」タブをクリックします。
3. 「スケジューラ構成」を「システム・メンテナンス」で選択します。
   「スケジューラ構成」画面が表示されます。
4. 共有記憶域にあるディレクトリを入力して、「共有ディレクトリ」を更新します。この共有記憶域には、BIHOST1およびBIHOST2の両方からアクセスできます。
5. 「JMSのテスト」をクリックします。

   JMSのテストが成功したという確認メッセージが表示されます。

   注意:

   テストの成功を示す確認メッセージが表示されない場合は、JNDI URLが次のとおりに設定されていることを確認します。

   cluster:t3://bi_cluster

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

BI Presentation Servicesとの統合の構成

Oracle Analytics PublisherのBI Publisherとの統合を構成するには:

1. 管理者の資格証明を使用してOracle Analytics Publisherにログインし、「管理」タブを選択します。
2. 「統合」で、「Oracle BIプレゼンテーション・サービス」を選択します。
3. 「手動構成」オプションを選択します。選択後、次のものを検証および更新します。

   • サーバー・プロトコル: HTTP

   • サーバー: biinternal.mycompany.com

   • ポート: 80

   • URL接頭辞: analytics-ws/saw.dll

4. 「適用」をクリックします。
5. Oracle Analytics Publisherアプリケーションを再起動します。

Oracle Analytics Serverのデータ・ソースの設定

Oracle Analytics Serverのデータ・ソースは、クラスタ化されたOracle Analytics Serverのサーバーをクラスタ・コントローラ経由で参照する必要があります。このタスクは、Oracle Analytics Publisherで実行する必要があります。

次のステップを実行して、Oracle Analytics PublisherでOracle Analytics Serverのデータ・ソースを設定します。

1. 管理者の資格証明を使用して次のURLでOracle Analytics Publisherにサインインします。

   http://BIHOST1VHN:7003/xmlpserver

2. 「管理」タブを選択します。
3. 「データ・ソース」で、「JDBC接続」を選択します。
4. 次のように「接続文字列」パラメータを変更して、Oracle Analytics Serverのデータ・ソース設定を更新します。

   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://BIHOST1:10006/PrimaryCCS=BIHOST1;PrimaryCCSPort=10006;
   SecondaryCCS=BIHOST2;SecondaryCCSPort=10006;

   クラスタ・コントローラのポート番号を見つけるには:
   1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
      http://ADMINVHN:7001/em
   2. 管理サーバー資格証明を使用してFusion Middleware Controlにサインインします。
   3. 「ターゲット・ナビゲーション」ペインがまだ表示されていない場合は、ページの左上隅にある「ターゲット・ナビゲーション」アイコンをクリックして表示します。
   4. 「ターゲット・ナビゲーション」ペインで「Business Intelligence」フォルダを展開し、「biinstance」を選択します。
      Business Intelligenceの「概要」ページが表示されます。
   5. 「可用性」、「プロセス」の順にクリックして、「可用性」ページの「プロセス」タブを表示します。
   6. 「ポート」列のポート番号をメモします。
5. 「システム・ユーザーの使用」を選択します。
6. 「接続のテスト」をクリックします。
   「接続は正常に確立されました。」というメッセージが表示されます。
7. 「適用」をクリックします。

Oracle Analytics Server Cluster用のBIPJmsResourceの構成

BIPJMSResource JMSモジュールを構成するには、モジュール内の一部のデフォルト値をこのトピックで示すように変更する必要があります。

BIPJMSResource JMSモジュールは、Oracle WebLogic ServerドメインでOracle Analytics Publisherを構成すると自動的にデプロイされます。ただし、クラスタ構成の分散トピック向け転送ポリシーのデフォルト値を変更する必要があります。

表12-1 転送ポリシー設定のためのカスタム値の指定

プロパティ名	説明
JMSリソース	クラスタ構成のBIP分散トピック - dist_BIP.System.T_auto
プロパティ	転送ポリシー
説明	クラスタインストールの分散BIPトピックは、デフォルトで転送ポリシーを「パーティション化」に設定して構成されています。
推奨設定	転送ポリシーを「レプリケート」に変更します。

BIPJMSResourceリソースの設定を変更するには:

1. Oracle WebLogic Server管理コンソールにサインインします。
2. 「サービス」で、「メッセージング」をクリックし、左のナビゲーション・ペインから「JMSモジュール」を選択します。
3. JMSモジュールのリストで「BIPJMSResource」をクリックします。
4. 「リソースのサマリー」表で「dist_BIP.System.T_auto」を選択します。
5. 「一般」タブをクリックします。
6. 「チェンジ・センター」で「ロックして編集」をクリックします。
7. 「転送ポリシー」メニューで「レプリケート」を選択します。
8. 「保存」をクリックします。
9. 「変更のアクティブ化」をクリックします。

スケール・アウト後のOracle Analytics Server構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。