Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-01 |
|
前 |
次 |
この章では、Oracle Business Intelligence構成アシスタント、Oracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlを使用して、ドメインと最初のOracle Business Intelligence管理対象サーバーを作成する方法について説明します。その後、ドメインをスケール・アウトしてコンポーネントを追加します。これについては、このドキュメントの後続の章で説明します。
重要: セットアップのプロセスを開始する前に、『Oracle Fusion Middlewareリリース・ノート』に目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。 |
この章の内容は次のとおりです。
Oracleホーム・ディレクトリからOracle Business Intelligence構成アシスタントを実行し、Oracle Business Intelligenceコンポーネントが配置された管理サーバーおよび最初の管理対象サーバーを含むドメインを作成します。
Business Intelligenceプラットフォーム・スキーマをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスが実行されていることを確認することをお薦めします。
構成アシスタントの場所(第3章「ソフトウェアのインストール」で作成)にディレクトリを移動します。
APPHOST1> cd ORACLE_HOME/bin
構成アシスタントを起動します。
APPHOST1> ./config.sh
「ようこそ」画面で、「次へ」をクリックします。
「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。
作成、スケール・アウト、または拡張画面が表示されます。この画面で、新規BIシステムの作成を選択して、次を入力します。
ユーザー名: weblogic
ユーザー・パスワード: your_password
ドメイン名: bifoundation_domain
「次へ」をクリックします。
「インストール場所の指定」画面で、次を入力します。
ミドルウェア・ホーム: 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/aserver/domain_name
「ドメイン・ホーム」では末尾はドメイン名にする必要があります。
インスタンス・ホーム: ORACLE_BASE/admin/instance1
インスタンス名: instance1
「次へ」をクリックします。
「コンポーネントの構成」画面で次を選択します。
Oracle Business Intelligence
Business Intelligence Enterprise Edition
Business Intelligence Publisher
Real-Time Decisions
「次へ」をクリックします。
RPDパスワードの暗号化画面で次の情報を入力します。
RPDパスワード
RPDパスワードの確認
このパスワードは、インストール・ファイルに含まれるSampleAppLite.rpdと呼ばれるサンプル・リポジトリに使用されます。
「次へ」をクリックします。
BIPLATFORMスキーマ画面で次の情報を入力します。
データベース・タイプ: Oracle データベース
接続文字列: CUSTDBHOST1:1521:CUSTDB1^CUSTDBHOST2:1521:CUSTDB2@BIEDG.MYCOMPANY.COM
BIPLATFORMスキーマ・ユーザー名: prefix_BIPLATFORM
BIPLATFORMスキーマ・パスワード: your_password
「次へ」をクリックします。
MDSスキーマ画面で情報を確認します。例:
データベース・タイプ: Oracle データベース
接続文字列: CUSTDBHOST1:1521:CUSTDB1^CUSTDBHOST2:1521:CUSTDB2@BIEDG.MYCOMPANY.COM
MDSスキーマ・ユーザー名: prefix_MDS
MDSパスワード: your_password
「次へ」をクリックします。
「ポートの構成」画面で、次のいずれかを選択します。
自動でポートを構成
構成ファイルを使用してポートを指定
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。
「次へ」をクリックします。
「サマリー」画面で「構成」をクリックします。
「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。
完了画面で「終了」をクリックします。
通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、APPHOST1で次のコマンドを実行してノード・マネージャを起動します。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
両方のノードから参照できるディレクトリに、すべての永続ストアの場所を構成する必要があります。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「BipJmsStore」をクリックして、共有記憶域上のディレクトリを入力します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「保存」をクリックし、「変更のアクティブ化」をクリックします。
変更内容は、管理対象サーバーが再起動されるまでは有効になりません。管理対象サーバーを再起動します。
APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。このファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。
次のディレクトリに移動します。
ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security
このディレクトリに、テキスト・エディタを使用してboot.propertiesというファイルを作成し、ファイルに次の行を入力します。
username=Admin_Username password=Admin_Password
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。管理サーバーは、第5.4項「APPHOST1での管理サーバーの起動」で起動します。セキュリティ上の理由から、ファイルのエントリが暗号化されていない時間を可能なかぎり短くする必要があります。ファイルを編集した後、できるだけ速やかにサーバーを起動し、エントリを暗号化してください。 |
ファイルを保存してエディタを閉じます。
管理サーバーは、ノード・マネージャを使用して起動および停止します。ただし、初めてノード・マネージャで管理サーバーを起動するときに、構成アシスタントによってノード・マネージャに設定されたデフォルトのユーザー名とパスワードを変更する必要があります。ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。
管理コンソールを使用してノード・マネージャの資格証明を更新します。
Webブラウザを開き、http://APPHOST1:7001/consoleにアクセスします。
管理者としてログインします。
「チェンジ・センター」で、「ロックして編集」をクリックして構成の変更を有効にします。
「domain_name」→「セキュリティ」→「一般」をクリックして、一番下にある「詳細」オプションを開きます。
ノード・マネージャの新しいユーザー名を入力するか、既存のユーザー名を書き留めておいてノード・マネージャのパスワードを更新します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
次のいずれかの方法を使用して、管理サーバーのプロセスを停止します。
起動元のシェルから[Ctrl]キーを押しながら[C]キーを押します。
標準のプロセス特定を行い、オペレーティング・システムでkillコマンドを実行します。
管理コンソールにログインし、「環境」の下の「サーバー」→「制御」タブをクリックします。「AdminServer(admin)」を選択して、「停止」をクリックします。
次のようにノード・マネージャを停止および再起動し、動的登録を有効にします。
実行中のNodeManagerプロセスを停止します。
ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./setNMProps.sh
注意: クラスのロード障害が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。 |
ノード・マネージャを再起動し、次のコマンドを使用して動的登録を有効にします。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
APPHOST1> ./startNodeManager.sh
注意: 管理サーバーを管理するノード・マネージャの起動時には、-DDomainRegistrationEnabled=trueを設定することが重要です。コンピュータ上に管理サーバーがなく、このコンピュータが管理サーバーのフェイルオーバー・ノードでない場合、ノード・マネージャは次のように起動できます。APPHOST1> ./startNodeManager.sh |
Oracle WebLogic Scripting(WLST)を起動して、nmconnect
とステップ1で設定した資格証明によりノード・マネージャに接続し、nmstart
を使用して管理サーバーを起動します。
APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./wlst.sh
WLSTシェルで、次のコマンドを実行します。
wls:/offline>nmConnect('Admin_User','Admin_Pasword', 'APPHOST1','9556','domain_name','Domain_Home') wls:/nm/domain_name> nmStart('AdminServer')
例:
wls:/offline>nmConnect('weblogic', 'my_password', 'APPHOST1' , '9556', 'bifoundation_domain' ,'/u01/app/oracle/admin/bifoundation_domain/aserver/ bifoundation_domain') wls:/nm/bifoundation_domain> nmStart('AdminServer')
注意: APPHOST1とは、ドメインを作成したノードのアドレスで、管理サーバーのリスニング・アドレスではありません。また、ユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理者のIDおよびパスワードとは関係なく、ORACLE_BASE/admin/domain_name/aserver/domain_name/config/nodemanager/nm_password.propertiesファイルに格納されています。 |
Oracle WebLogic Server管理サーバーはシングルトン・アプリケーションなので、アクティブ/アクティブ構成にはデプロイできません。デフォルトでは、管理サーバーが使用できるのは、最初にインストールしたノードのみなので、このエンタープライズ・トポロジで使用できるのはAPPHOST1のみです。このノードを利用できなくなると、管理コンソールとFusion Middleware Controlも利用できなくなります。このシナリオを回避するには、管理サーバーおよびそこにデプロイしたアプリケーションの可用性を高める必要があります。このガイドのエンタープライズ・デプロイメント・アーキテクチャでは、APPHOST1とAPPHOST2で共有されるディスク上に管理サーバーをデプロイする必要があります。
このガイドで説明する手順では、最初にAPPHOST1にマウントされている共有ディスクに管理サーバーとbi_server1の管理対象サーバーをデプロイし、その後ローカル・ファイル・システムにbi_server1管理対象サーバーのドメイン情報を手動で移行します。この手順は、Oracle Universal Installerの設計上のある制約を克服するために必要です。
この項の内容は次のとおりです。
管理サーバーが1つのホストから別のホストにシームレスにフェイルオーバーできるよう、仮想IPアドレスをリスニングするよう構成する必要があります。障害時には、管理サーバーを仮想IPアドレスとともに1つのホストから別のホストに移行できます。
ただし、管理サーバーが仮想IPアドレスをリスニングするよう構成する前に、管理サーバーを実行しているホスト上のネットワーク・インタフェース・カードの1つが、この仮想IPアドレスをリスニングするよう構成されている必要があります。仮想IPアドレスを有効にする手順は、オペレーティング・システムによって完全に異なります。
この項の手順に従って、APPHOST1上の仮想IPアドレスを有効にします。UNIX環境では、rootユーザーとしてコマンドを実行する必要があります。
APPHOST1でifconfig
コマンドを実行し、ネットマスクの値を取得します。UNIX環境では、rootユーザーとしてコマンドを実行します。例:
[root@APPHOST1 ~] # /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:11:43:D7:5B:06 inet addr:139.185.140.51 Bcast:139.185.140.255 Mask:255.255.255.0 inet6 addr: fe80::211:43ff:fed7:5b06/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10626133 errors:0 dropped:0 overruns:0 frame:0 TX packets:10951629 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4036851474 (3.7 GiB) TX bytes:2770209798 (2.5 GiB) Base address:0xecc0 Memory:dfae0000-dfb00000
APPHOST1でifconfig
を使用し、仮想IPアドレスとネットワーク・インタフェース・カードをバインドします。UNIX環境ではこのコマンドをrootユーザーとして実行します。ステップ1で取得したネットマスク値を使用します。
ifconfig
コマンドの構文および用法は次のとおりです。
/sbin/ifconfig networkCardInterface Virtual_IP_Address netmask netMask
例:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
arping
を使用し、ルーティング表を更新します。UNIX環境では、このコマンドをrootユーザーとして実行します。
/sbin/arping -q -U -c 3 -I networkCardInterface Virtual_IP_Address
例:
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
APPHOST1およびAPPHOST2上の管理対象サーバーに対するVIP2およびVIP3の有効化の詳細は、第2.2.3.1項「管理対象サーバーの仮想IPの有効化」も参照してください。
管理コンソールを使用して、マシンを新規に作成し、新しいマシンを管理サーバーに割り当てます。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ホーム」ページの「環境」セクションで、「マシン」をクリックします。
「マシンのサマリー」ページの「マシン」表から、管理サーバーと関連付けられているマシンを選択し、「クローンの作成」をクリックします(例: APPHOST1.MYCOMPANY.COM)。
「マシンのクローンを作成」ページの「マシンID」セクションにマシンの名前を入力し、「OK」をクリックします。たとえば、マシン名としてADMINHOSTを入力します。
「マシンのサマリー」ページで、新規に作成されたマシンのリンクをクリックします。
ADMINHOSTマシンの「設定」ページで「サーバー」タブを選択します。
「サーバー」表の下の「追加」をクリックします。
「マシンにサーバーを追加」ページで「既存のサーバーを選択して、このマシンに関連付けます。」オプションを選択します。
ドロップダウン・メニューから「AdminServer」を選択します。
「終了」をクリックし、マシンと管理サーバーを関連付けます。
チェンジ・センターで、変更のアクティブ化をクリックします。
管理サーバーのリスニング・アドレスを設定する前に、第5.5.1項「APPHOST1上のADMINVHNの有効化」で説明されている手順が実行済であることを確認します。
次の手順を実行して、管理サーバーのリスニング・アドレスを設定します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「AdminServer(admin)」を選択します。AdminServer(admin)の「設定」ページが表示されます。
「リスニング・アドレス」をADMINVHNに設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
変更内容は、管理サーバーが再起動されるまでは有効になりません。管理対象サーバーを再起動するには、次の手順を実行します。
「サーバーのサマリー」画面で、「制御」タブを選択します。
表で「AdminServer(admin)」を選択して、「停止」をクリックします。
コマンドラインから次のように管理サーバーを再起動します。
APPHOST1> cd ORACLE_COMMON_HOME/common/bin APPHOST1> ./wlst.sh wls:/offline> nmConnect ('Admin_User','Admin_Password','APPHOST1','9556','domain_name','DOMAIN home') wls:/nm/domain_name> nmStart ('AdminServer')
packおよびunpackコマンドを使用し、管理サーバーが使用するドメイン・ディレクトリをAPPHOST1のbi_server1管理対象サーバーが使用するドメイン・ディレクトリから分離します。
APPHOST1でpackコマンドを実行し、次のコマンドを使用してテンプレート・パックを作成します。bi_server1の管理対象サーバーのドメイン情報のみがパックされるようmanaged=trueが渡されることを確認します。
APPHOST1> cd ORACLE_HOME/common/bin APPHOST1> ./pack.sh -managed=true -domain=path_to_installer_created_domain -template=templateName.jar -template_name=templateName
例:
APPHOST1> cd ORACLE_HOME/common/bin APPHOST1> ./pack.sh -managed=true -domain= ORACLE_BASE/admin/bifoundation_domain/aserver/bifoundation_domain -template=/tmp/managedServer.jar -template_name=ManagedServer_Template
次のようにAPPHOST1でunpackコマンドを実行し、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。
APPHOST1> cd ORACLE_HOME/common/bin APPHOST1> ./unpack.sh -domain=path_to_domain_on_LocalFileSystem -template=templateName.jar -app_dir=path_to_applications_dir_on_LocalFileSystem
例:
APPHOST1> cd ORACLE_HOME/common/bin APPHOST1>./unpack.sh -domain= ORACLE_BASE/admin/bifoundation_domain/mserver/bifoundation_domain -template=/tmp/managedServer.jar -app_dir= ORACLE_BASE/admin/bifoundation_domain/mserver/applications
次のようにAPPHOST1でbi_server1の管理対象サーバーを再起動します(ノード・マネージャが稼働していることを確認します)。
管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
「サーバーのサマリー」ページで、「制御」タブを選択します。
表で「bi_server1」を選択し、「起動」をクリックします。
Fusion Middleware Controlのフェイルオーバーを有効にするには、管理サーバーのHAが行われる可能性のあるすべてのノードの対応するディレクトリに、MW_HOME/user_projects/applications/bifoundation_domainディレクトリからem.earファイルをコピーします。場合によっては、他のノードにMW_HOME/user_projects/applications/bifoundation_domainディレクトリを作成する必要があります。
次の手順を実行して、管理サーバーが適切に構成されていることを確認します。
Webブラウザを開き、http://ADMINVHN:7001/consoleにアクセスします。
管理者としてログインします。
次のFusion Middleware Controlにアクセスできることを確認します。
http://ADMINVHN:7001/em
第5.3項「APPHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してFusion Middleware Controlにログインします。
管理サーバーのリスニング・アドレスを設定する前に、第2.2.3.1項「管理対象サーバーの仮想IPの有効化」で説明されている手順が実行済であることを確認します。
次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server1」を選択します。bi_server1の「設定」ページが表示されます。
「リスニング・アドレス」をAPPHOST1VHN1に設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
この変更内容は、bi_server1管理対象サーバーが再起動されるまでは適用されません(ノード・マネージャが稼働していることを確認します)。
「サーバーのサマリー」ページで、「制御」タブを選択します。
表で「bi_server1」を選択してから、「停止」をクリックします。
サーバーの停止後、表で「bi_server1」を選択し、「起動」をクリックします。
Oracle Business Intelligenceシステム・コンポーネントを次のように再起動します。
cd ORACLE_BASE/admin/instances/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
「JMSのテスト」をクリックします。
JMSのテストが成功したという確認メッセージが表示されることを確認します。
「適用」をクリックします。実行時に適用されるよう、変更内容がクラスタに送信されます。
スケジューラのステータスを「スケジューラ診断」タブでチェックします。
この手順は、管理サーバーで様々なノードを認証するための適切な証明書を設定していない場合に必要です(第7章「ノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、様々なOracle WebLogic Serverを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証を行う際にホスト名の検証を無効にし、EDGトポロジの構成完了後に第7章「ノード・マネージャの設定」の説明に従って再びホスト名の検証を有効にします。
ホスト名検証を無効にする手順は次のとおりです。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server1」を選択します。そのサーバーの設定ページが表示されます。
「 SSL 」タブを開きます。
表示されたページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
この変更内容は、bi_server1管理対象サーバーが再起動されるまでは適用されません(ノード・マネージャが稼働していることを確認します)。
「サーバーのサマリー」ページで、「制御」タブを選択します。
表で「bi_server1」を選択してから、「停止」をクリックします。
表で「bi_server1」を選択し、「起動」をクリックします。
Oracle Business Intelligenceシステム・コンポーネントを次のように再起動します。
cd ORACLE_BASE/admin/instance1/bin
./opmnctl stopall
./opmnctl startall
次のURLにアクセスします。
http://APPHOST1VHN1:9704/analytics
にアクセスして、bi_server1のステータスを確認します。
http://APPHOST1VHN1:9704/wsm-pm
にアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。
http://APPHOST1VHN1:9704/xmlpserver
にアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。
http://APPHOST1VHN1:9704/ui
にアクセスして、Oracle Real-Time Decisionsアプリケーションのステータスを確認します。
http://APPHOST1VHN1:9704/bioffice/about.jsp
にアクセスして、Oracle BI for Microsoft Officeアプリケーションのステータスを確認します。
この項では、Oracle HTTP Serverを管理サーバーおよびbi_server1管理対象サーバー用に構成する方法を説明します。
この項の内容は次のとおりです。
Oracle HTTP Serverから管理サーバーへのルーティングを有効にするには、HTTPサーバーの構成に対応するマウント・ポイントを設定する必要があります。
WEBHOST1とWEBHOST2の各Webサーバーの次のディレクトリに、admin.confというファイルを作成します。
ORACLE_INSTANCE/config/OHS/component/moduleconf
その後、このファイルに次の行を追加します。
NameVirtualHost *:80 <VirtualHost *:80> ServerName admin.mycompany.com:80 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit # Admin Server and EM <Location /console> SetHandler weblogic-handler WebLogicHost ADMINVHN WeblogicPort 7001 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /consolehelp> SetHandler weblogic-handler WebLogicHost ADMINVHN WeblogicPort 7001 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /em> SetHandler weblogic-handler WebLogicHost ADMINVHN WeblogicPort 7001 WLProxySSL ON WLProxySSLPassThrough ON </Location> </VirtualHost>
VirtualHostパラメータの値は、LBR仮想ホストの設定方法に依存します。7777など、表示されたものとは別の値を使用する必要がある場合があります。
WEBHOST1およびWEBHOST2の両方で、次のようにOracle HTTP Serverを再起動します。
WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
Oracle HTTP Serverがbi_servern管理対象サーバーを含むbi_clusterにルーティングできるようにするには、クラスタ内のノード・リストにWebLogicClusterパラメータを設定する必要があります。
WEBHOST1とWEBHOST2のORACLE_BASE/admin/instance_name/config/OHS/component_name/mod_wl_ohs.confファイルに次の行を追加します。
#redirect browser requests that omit document/dir RedirectMatch 301 /analytics$ /analytics/ RedirectMatch 301 /bimiddleware$ /bimiddleware/ RedirectMatch 301 /xmlpserver$ /xmlpserver/ RedirectMatch 301 /ui$ /ui/ # 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 /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> # MapViewer <Location /mapviewer> 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> # Oracle RTD <Location /ui> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /rtis> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /schema> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /ws> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # 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>
注意: (SampleApp.rpdの機能をサポートするanalyticsResやActionSamplesなど)必要に応じて他のリソースを追加します。 |
mod_wl_ohsファイルと同じディレクトリに格納されているhttpd.confファイルに、次の行が記述されていることを確認します。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName https://bi.mycompany.com:443 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit </VirtualHost> NameVirtualHost *:7777 <VirtualHost *:7777> ServerName admin.mycompany.com:80 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit </VirtualHost>
注意: ここであげているbi.mycompany.com:443、admin.mycompany.com:80、you@your.addressなどの値は、単なる例です。これらのかわりに、実際の環境に基づいた値を入力してください。 |
WEBHOST1およびWEBHOST2の両方で、次のようにOracle HTTP Serverを再起動します。
WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。
次に例を示します。
例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時に動的に検出されます。
例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのすべてのメンバーをリストした場合、Oracle HTTP Serverの起動時、少なくとも1つのメンバーが実行されているときは、クラスタへのルーティングは保証されます。WebLogic Serverプラグインの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方』を参照してください。
セキュリティのため、またロード・バランサがSSLリクエストを終了するため(Oracle HTTP ServerはリクエストをWebLogic Serverに非SSLとしてルーティングします)、ロード・バランサにSSLを構成した後、そのドメインでWebLogicプラグインの有効化のフラグをオンにします。これを実行する手順は、次のとおりです。
管理コンソールにログインします。
左側のナビゲーション・ツリーでドメイン名をクリックします。
「Webアプリケーション」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「WebLogicプラグインの有効化」を選択します。
「保存」をクリックし、「変更のアクティブ化」をクリックします。
管理サーバーおよび管理対象サーバーを再起動します。
Fusion Middleware ControlでOracle HTTP Serverインスタンスを管理および監視するには、これらをドメインに登録する必要があります。これを行うには、次のコマンドを使用してOracle WebLogic ServerへOracle HTTP Serverを登録する必要があります。
WEBHOST1> cd ORACLE_INSTANCE/bin
WEBHOST1> ./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic
このコマンドは、OHS2に対してWEBHOST2からも実行する必要があります。
注意: 登録したOracle HTTP ServerはFusion Middleware Controlで管理可能なターゲットとして表示されます。これを確認するには、Fusion Middleware Controlにログインします。ナビゲーション・ツリーのWeb層の項目にOracle HTTP Serverが登録されていることが示されます。 |
管理コンソール・アプリケーションでは、コンソールを使用して、ポート、チャネル、セキュリティに対する変更を追跡します。コンソールから行った変更がアクティブ化されると、コンソールでは現在のリスニング・アドレス、ポートおよびプロトコルを検証します。リスニング・アドレス、ポートおよびプロトコルがまだ有効である場合、コンソールではHTTPリクエストをリダイレクトし、ホストとポート情報を管理サーバーのリスニング・アドレスとポートと置換します。ロード・バランシング・ルーター(LBR)を使用し、管理コンソールにアクセスした場合、ユーザーのWebブラウザが適切なLBRアドレスにリダイレクトされるよう、管理サーバーのフロントエンドURLを変更する必要があります。これを実行する手順は、次のとおりです。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「AdminServer(admin)」を選択します。AdminServer(admin)の「設定」ページが表示されます。
「プロトコル」タブをクリックします。
「HTTP」タブをクリックします。
「フロントエンド・ホスト」フィールドをadmin.mycompany.com
(LBRアドレス)に設定します。
「フロントエンドHTTPポート」を80に設定します。
「保存」をクリックし、「変更のアクティブ化」をクリックします。
リダイレクトされないようにするには、管理コンソールの変更の追跡機能を無効にすることをお薦めします。そのためには、管理コンソールにログインし、「プリファレンス」→「共有プリファレンス」をクリックします。「構成変更の追跡」オプションの選択を解除して、「保存」をクリックします。
管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。
この項の内容は次のとおりです。
管理コンソールおよびFusion Middleware Controlを、両方のOracle HTTP Serverインスタンスから次のURLを使用して検証できます。
http://WEBHOSTn:7777/console
http://WEBHOSTn:7777/em
注意: フロントエンドURLをLBRアドレスに設定すると、WEBHOSTnアドレスを介したコンソールへのアクセスは、コンソールによってフロントエンドURLにリダイレクトされるので、Oracle HTTP ServerおよびLBRデバイスの両方の構成が正しいことか検証されます。 |
http://admin.mycompany.com/console
http://admin.mycompany.com/em
ロード・バランサを介したシステム・アクセスの構成は、第2.2.2項「ロード・バランサ」を参照してください。
(WEBHOST1およびWEBHOST2の両方に対して)次のURLを使用し、Oracle HTTP Serverからbi_clusterを検証します。
http://WEBHOSTn:7777/analytics
http://WEBHOSTn:7777/mapviewer
http://WEBHOSTn:7777/xmlpserver
http://WEBHOSTn:7777/ui
http://WEBHOSTn:7777/wsm-pm
http://WEBHOSTn:7777/bioffice/about.jsp
ロード・バランサを介したシステム・アクセスの構成は、第2.2.2項「ロード・バランサ」を参照してください。
ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをAPPHOST1からAPPHOST2にフェイルオーバーする方法を説明します。項目は次のとおりです。
次の前提条件があることに留意してください。
管理サーバーは、任意のアドレスではなくADMINVHNをリスニングするよう構成されています。
管理サーバーはAPPHOST1からAPPHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。
APPHOST1: 100.200.140.165
APPHOST2: 100.200.140.205
ADMINVHN: 100.200.140.206。これは管理サーバーを実行している場所のVIPであり、ethX:Yに割り当てられており、APPHOST1とAPPHOST2からアクセスできます。
APPHOST1の管理サーバーの実行場所であるドメイン・ディレクトリは共有記憶域にあり、APPHOST2からもマウントされています。
Oracle WebLogic ServerとOracle Fusion MiddlewareコンポーネントがAPPHOST2にインストールされています(つまり、APPHOST1に存在するORACLE_HOMEとMW_HOMEのパスと同じパスがAPPHOST2でも使用可能です)。
手順
次の手順は、管理サーバーを別のノード(APPHOST2)にフェイルオーバーさせる手順を示します。
管理サーバーが実行されている場合は停止します。
IPアドレスを第2ノードに移行します。
APPHOST1上で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。
APPHOST1> /sbin/ifconfig ethX:Y down
次のコマンドをAPPHOST2上で実行します。
APPHOST2> /sbin/ifconfig interface:index IP_address netmask netmask
例:
APPHOST2> /sbin/ifconfig eth0:1 10.200.140.206 netmask 255.255.255.0
注意: 使用するネットマスクとインタフェースは、APPHOST1で使用可能なネットワーク構成と一致している必要があります。 |
次の例のようにarping
を使用してルーティング表を更新します。
APPHOST2> /sbin/arping -b -A -c 3 -I eth0 100.200.140.206
第5.4項「APPHOST1での管理サーバーの起動」の手順3の説明に従って、APPHOST2上でノード・マネージャを起動します。
第5.4項「APPHOST1での管理サーバーの起動」の手順4の説明に従って、APPHOST2上で管理サーバーを起動します。
次の方法でAPPHOST2上の管理サーバーにアクセスできることをテストします。
http://ADMINVHN:7001/consoleの管理コンソールにアクセスできることを確認します。
http://ADMINVHN:7001/emのFusion Middleware Controlコンポーネントにアクセスしステータスを検証できることを確認します。
第5.13項「Oracle HTTP Serverを使用したアクセスの検証」で説明されている手順を実行します。この目的は、APPHOST2で実行している管理サーバーにもアクセスできることを確認することです。
この手順では、管理サーバーをフェイルバックできることを確認します。フェイルバックとは、APPHOST2で実行している管理サーバーを停止し、APPHOST1で再び管理サーバーを実行することです。このためには、次の手順に従ってADMINVHNを元のAPPHOST1ノードに移行します。
管理サーバーが起動されていないことを確認します。
次のコマンドをAPPHOST2上でrootとして実行します。
APPHOST2> /sbin/ifconfig ethX:Y down
次のコマンドをAPPHOST1上で実行します。
APPHOST1> /sbin/ifconfig interface:index IP_Address netmask netmask
例:
APPHOST1> /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
注意: 使用するネットマスクとインタフェースが、APPHOST1で使用可能なネットワーク構成と一致していることを確認します。 |
次の例のようにarping
を使用してルーティング表を更新します。
APPHOST1> /sbin/arping -b -A -c 3 -I ethZ 100.200.140.206
第5.4項「APPHOST1での管理サーバーの起動」の手順4の説明に従って、APPHOST1上で管理サーバーを再起動します。
http://ADMINVHN:7001/consoleの管理コンソールにアクセスできることをテストします。
http://ADMINVHN:7001/emのFusion Middleware Controlコンポーネントにアクセスしステータスを検証できることを確認します。
管理サーバーのフェイルオーバーで問題が発生する場合の追加情報は、第10.6.2項「手動フェイルオーバー後に管理サーバーの起動に失敗する」を参照してください。
拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、『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
opmnctl
を使用してインスタンスを起動します。
WEBHOSTn> cd ORACLE_BASE/admin/instance_name/bin WEBHOSTn> opmnctl startall
WEBHOST2についても、この手順を繰り返します。
データベースをバックアップします。これは、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