| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 12c (12.1.3) E53006-03 |
|
 前 |
 次 |
この章では、Oracle Business Activity Monitoringを追加するためのドメイン拡張の手順を説明します。
この章には次の項が含まれます:
この章のタスクを実行する際には、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」で定義されているいくつかのディレクトリ変数に次の値を入力するように求められます。
ORACLE_HOME
ASERVER_HOME
MSERVER_HOME
さらに、第5.2.3項「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスを参照することになります。
ADMINVHN
この章のアクションは、次のホスト・コンピュータで実行します。
SOAHOST1
SOAHOST2
WEBHOST1
WEBHOST2
Oracle BAMを既存のOracle SOA Suiteドメインに追加する前に、次の情報と前提条件を検討してください。
|
注意: Oracle BAMを個別のホスト・コンピュータにインストールする場合は、ここに記載されている前提条件のほかに、第16.3項「個別のホスト上でOracle BAMを構成する場合の特別な指示」を参照してください。 |
この章では、図3-2「 Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジのダイアグラム」で示すように、Oracle SOA Suiteと同じホスト・コンピュータ上にOracle Business Activity Monitoringを構成することを前提にしています。
デフォルトのOracle SOA SuiteとOracle Business Activity Monitoringのトポロジでは、Oracle BAMを独自の管理対象サーバーとクラスタにターゲット指定しますが、Oracle BAMでは、SOAHOST1およびSOAHOST2上の他のOracle SOA Suite製品とシステム・リソースを共有します。このようなシステム・リソースには、Oracle SOA Suiteソフトウェアが既存のOracleホーム・ディレクトリにインストールされている共有記憶域デバイスが含まれます。
Oracle BAMは、Oracle SOA SuiteおよびOracle Business Process Managementのディストリビューションに含まれ、 第3章「SOAエンタープライズ・デプロイメント・トポロジの理解」でOracle SOA SuiteをインストールするときにOracleホーム・ディレクトリにインストールされるため、デフォルトのトポロジでは、Oracle BAMをインストールする必要はありません。
リポジトリ作成ユーティリティ(RCU)を実行して、必要なOracle SOA Suiteスキーマを作成したときに、Oracle BAMに必要なスキーマがデータベースに作成されます。
そのため、Oracle BAMを対象にRCUを実行する必要はありません。
BAMシステムが他のOracle SOA Suite製品を含めずに作成され、SOAスキーマの作成がまだ実行されていない場合は、第12章「Oracle SOA Suiteを含めるドメインの拡張」で説明したRCUインストール手順を実行する必要があります。
既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップします。
既存のFusion Middlewareホームとドメインをバックアップするには、第18.2.6項「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。
組織によっては、Oracle BAMソフトウェアが専用のハードウェア・リソースを使用でき、他のOracle SOA Suite製品から独立できるように、Oracle BAMを個別のホスト・コンピュータにインストールして構成するとよい場合があります。
Oracle BAMを独自のハードウェアで構成する場合は、次の項の情報も考慮しながら、この章の手順を実行します。
独自のホスト・コンピュータにOracle BAMを構成する場合は、追加のハードウェアを入手し、そのハードウェアが第5.1.2項「ホスト・コンピュータのハードウェア要件」と第5.1.3項「エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件」に記載されているシステム要件を満たしていることを確認する必要があります。
また、第4章「エンタープライズ・デプロイメント・ワークブックの使用」で説明しているように、必要なエントリをエンタープライズ・デプロイメント・ワークブックに追加する必要があります。このガイドでは、これらのホスト・コンピュータをBAMHOST1およびBAMHOST2と呼びます。
独自のホスト・コンピュータでOracle BAMを構成する場合は、他のOracle SOA Suite製品がインストールされているホスト・コンピュータで従っているものと同じ共有記憶域戦略に従う必要があります。
|
注意: BAMHOST1とBAMHOST2で使用するOracleホームには、ドメイン内のSOAHOST1ホストとSOAHOST2ホストで使用するソフトウェア・バイナリの正確なセットが含まれている必要があります。 含まれていない場合は、バイナリの実行時に予測できない動作が発生する可能性があります。 |
Oracle BAMソフトウェア用に個別のホスト・ハードウェアを使用する場合は、従っている共有記憶域戦略に応じて、次の項のいずれかが該当します。
BAMHOST1およびBAMHOST2で個別の共有記憶域のボリュームまたはパーティションを使用する場合は、そのホストに、Infrastructureと、必要に応じてOracle SOA Suiteをインストールする必要があります。詳細は、第7.2項「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。
Oracleホーム(ソフトウェア・バイナリが含まれている)をインストールする場所は、ホストによって異なることに注意してください。ご使用のOracleホーム・ディレクトリの正しい場所を特定するには、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」のガイドラインを参照してください。
BAMHOST1とBAMHOST2にソフトウェアをインストールするには、各ホストにログインして、次のタスクを実行します。
BAMHOST1とBAMHOST2で、Oracle Fusion Middleware InfrastructureまたはOracle SOA Suiteがすでにインストールされている既存のボリュームまたはパーティションを使用する場合は、ボリュームをBAMHOST1とBAMHOST2に適切にマウントする必要があります。詳細は、第8.5項「各ホストへの必要な共有ファイル・システムのマウント」を参照してください。BAMHOST1とBAMHOST2が、ドメイン内の他のホストと同様に、このOracleホームにアクセスできることを確認します。
これは、エンタープライズ・デプロイメントで共有記憶域を使用するための推奨方法です。詳細は、第7.2項「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。
既存のOracleホームを含む既存のボリュームまたはパーティションをマウントしたら、Oracleホームを、BAMHOST1またはBAMHOST2にあるローカルのOracleインベントリに追加する必要があります。
共有記憶域内のOracleホームをローカルのOracleインベントリに追加するには、BAMHOSTで次のコマンドを実行します。
cd ORACLE_HOME/oui/bin/attachHome.sh
./attachHome.sh -jreLoc JAVA_HOME
packユーティリティおよびunpackユーティリティを使用して、WLS_BAM1サーバーおよびWLS_BAM2サーバーのドメイン構成をブートストラップします。そのため、必要なソフトウェアがすでにインストールされている既存のOracleホームをマウントした場合は、これらの2つのホストにソフトウェアをインストールする必要はありません。
個別のホスト・コンピュータでOracle BAMを構成する場合は、この章に記載されている、構成ウィザードを使用したドメインの構成方法が少し変更されます。
具体的には、必ず、BAMHOST1とBAMHOST2に対して追加のOracle WebLogic Serverマシンを作成し、WLS_BAM1およびWLS_BAM2管理対象サーバーを、SOAHOST1およびSOAHOST2ではなく、これらのマシンにターゲット指定するようにします。
詳細は、タスク12「既存のマシンの検証」とタスク13「サーバーのマシンへの割当て」を参照してください。
個別のホスト・コンピュータでOracle BAMを構成する場合は、この章に記載されている、他のドメイン・ディレクトリにドメインを伝播する方法を変更する必要があります。
具体的には、SOAHOST1およびSOAHOST2上の管理対象サーバーのドメイン・ディレクトリにドメインを伝播することに加え、BAMHOST1およびBAMHOST2のローカルな管理対象サーバー・ディレクトリでドメインを解凍する必要があります。
つまり、各BAMHOSTコンピュータでノード・マネージャ・ソフトウェアを起動しなければ、これらのホスト上でWLS_BAM管理対象サーバーをリモートで起動することはできません。
表16-1は、Oracle Business Activity MonitoringのためにSOAドメインを拡張する、大まかな手順を示します。
表16-1 Oracle BAMを追加するためのSOAドメインの拡張手順
| 手順 | 説明 | 詳細情報 |
|---|---|---|
|
構成ウィザードによる、管理サーバー・ドメイン・ホーム内のドメインの拡張 |
Oracle BAMコンポーネントを追加するために、SOAドメイン拡張します。 |
第16.5項「Oracle Business Activity Monitoringを追加するためのSOAドメインの拡張」 |
|
トランザクション・リカバリのためのデフォルトの永続ストアの構成 |
クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。 |
第16.6項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」 |
|
管理対象サーバーのドメイン・ディレクトリへのドメイン構成の伝播 |
Oracle BAMでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。 |
第16.7項「ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播」 |
|
Oracle BAMサーバーの自動サービス移行の構成 |
管理対象サーバーまたはホスト・コンピュータのいずれかで障害が発生した場合に、サービスの移行により、主要な固定サービスがクラスタ内の別の管理対象サーバーに自動的に移行されます。サービスの移行に関する詳細は、第19章を参照してください。 |
第16.8項「Oracle BAMサーバーの自動サービス移行の構成」 |
|
Oracle BAM管理グループへのSOA管理者ロールの追加 |
この手順により、一連の資格証明を使用して、様々な製品固有の管理ユーティリティにアクセスできます。 |
第16.9項「Oracle BAM管理グループへのエンタープライズ・デプロイメント管理ユーザーの追加」 |
|
Oracle BAMサーバーの起動 |
Oracle BAMサーバーにより、既存のドメインが拡張されます。そのため、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。 |
|
|
WLS_BAM管理対象サーバーの検証 |
管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認し、URLにアクセスしてサーバーのステータスを確認します。 |
第16.11項「WLS_BAM2管理対象サーバーの起動と検証」 |
|
WLS_BAMn管理対象サーバーに対するOracle HTTP Serverの構成 |
Oracle HTTP ServerがOracle BAMにルーティングできるようにするには、必要なディレクティブをOracle HTTP Serverの構成ファイルに追加して、 WebLogicClusterパラメータをクラスタ内のノードの一覧に設定します。 |
第16.12項「WLS_BAM管理対象サーバーに対するOracle HTTP Serverの構成」 |
|
WebLogic Serverプロキシ・プラグインの構成 |
Oracle BAMに対してWebLogic Serverプロキシ・プラグインを有効にします。 |
第16.13項「WebLogicプロキシ・プラグインの構成」 |
|
Oracle HTTP Serverを介したアクセスの検証 |
サーバーのステータスが「実行中」であることを確認します。 |
第16.14項「ハードウェア・ロード・バランサを介したOracle BAMへのアクセスの検証」 |
|
Oracle BAM構成のバックアップ |
この後の手順でエラーが発生した場合の即座のリストアを目的として、ドメイン構成をバックアップします。 |
|
この項では、Oracle Business Activity Monitoringを追加して、既存のエンタープライズ・デプロイメントのSOAドメインを拡張する手順について説明します。
ドメインの拡張には、次の操作が含まれます。
|
注意: ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらのカスタマイズは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。 |
ドメインの構成を開始するには:
ドメインの構成中に、構成のロック、保存、アクティブ化が行われないように、管理サーバーを停止します。
詳細は、第11.3.1項に記載されている、ノード・マネージャで管理サーバーを停止する手順を参照してください。
次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。
ORACLE_HOME/oracle_common/common/bin./config.sh
この手順では、第12章「Oracle SOA Suiteを含めるドメインの拡張」で作成したドメインを拡張して、Oracle Business Activity Monitoringコンポーネントを追加します。
Oracle Business Activity Monitoringを追加して、管理サーバーとWSM-PMクラスタのみを含むドメインを拡張する場合の手順は、この項で説明する手順とほぼ同じになりますが、画面に表示される一部のオプション、ライブラリ、コンポーネントは異なる場合があります。
ドメイン作成および構成には次のタスクが含まれます。
「構成タイプ」画面で、「既存ドメインの更新」を選択します。
「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、第10章で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。
ディレクトリの場所の変数の詳細は、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。
|
ヒント: この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。 |
「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。
Oracle Business Activity Monitoring- 12.1.3.0 [soa]
「次へ」をクリックします。
|
注意: 拡張前に作成されたカスタム・データ・ソース(LEASINGデータ・ソースなど)が、この画面の前に表示されます。「データソース」行を確認し、「次へ」をクリックします。データ・ソースのテスト画面で、その有効性が検証されます。「次へ」をクリックします。 |
Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。
データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示しています。
Connecting to the database server...OK Retrieving schema data from database server...OK Binding local schema components with retrieved data...OK Successfully Done.
「JDBCコンポーネント・スキーマ」ページで、BAMスキーマ、BAM Job Schedスキーマ、およびBAM MDSスキーマを選択します。
「GridLinkへ変換」を選択して、「次へ」をクリックします。
「GridLink Oracle RACコンポーネント・スキーマ」画面で、表10-3と図10-2に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。
「サービス・リスナー」フィールドと「ONSホスト」フィールドには、必ずデータベースのSCANアドレスを使用してください。
「JDBCデータ・ソースのテスト」画面で、すべての接続が正常であることを確認します。
接続のテストは自動的に行われます。「ステータス」列に結果が表示されます。正常でない接続がある場合は、「前へ」をクリックして前の画面に戻り、入力を訂正します。
すべての接続に成功したら「次へ」をクリックします。
拡張構成の選択画面で、次を選択します。
管理対象サーバー、クラスタおよびCoherence
JMSファイル・ストア
「次へ」をクリックします。
「管理対象サーバー」画面で、Oracle BAMに必要な管理対象サーバーを追加します。
自動的に作成されたサーバーを選択して、その名前をWLS_BAM1に変更します。
「追加」をクリックし他の新規サーバーを追加して、サーバー名としてWLS_BAM2と入力します。
WLS_BAM1およびWLS_BAM2サーバーに、表16-2内の属性を指定します。
BAMサーバーのサーバー・グループとして「BAM12-MGD-SVRS-ONLY」を選択します。リストから、「BAM12-MGD-SVRS」を選択解除します。
最後に、追加されたサーバーの構成が表16-2に一致している必要があります。
「次へ」をクリックします。
表16-2 Oracle BAM用のドメインを拡張するときの「管理対象サーバー」画面の項目
| 名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSLの有効化 | サーバー・グループ |
|---|---|---|---|---|---|
|
WLS_SOA1脚注 1 |
SOAHOST1VHN1 |
8001 |
該当なし |
いいえ |
SOA-MGD-SVRS-ONLY |
|
WLS_SOA2 |
SOAHOST2VHN1 |
8001 |
該当なし |
いいえ |
SOA-MGD-SVRS-ONLY |
|
WLS_WSM1 |
SOAHOST1 |
7010 |
該当なし |
いいえ |
JRF-MAN-SVR WSMPM-MAN-SVR WSM-CACHE-SVR |
|
WLS_WSM2 |
SOAHOST2 |
7010 |
該当なし |
いいえ |
JRF-MAN-SVR WSMPM-MAN-SVR WSM-CACHE-SVR |
|
WLS_BAM1 |
SOAHOST1脚注 2 |
9001 |
該当なし |
いいえ |
BAM12-MGD-SVRS-ONLY |
|
WLS_BAM2 |
SOAHOST2 |
9001 |
該当なし |
いいえ |
BAM12-MGD-SVRS-ONLY |
脚注 1 Oracle SOA Suiteがすでに構成されているドメインを拡張する場合は、WLS_SOA1およびWLS_SOA2管理対象サーバーが表示されます。
脚注 2 WLS_BAM1およびWLS_BAM2のリスニング・アドレスを指定するときは、それぞれSOAHOST1およびSOAHOST2のIPアドレスを入力します。ただし、個別のホスト・コンピュータ(BAMHOST1およびBAMHOST2)でOracle BAMを構成する場合は、このかぎりではありません。個別のホストでOracle BAMを構成する場合は、BAMHOST1およびBAMHOST2のリスニング・アドレスを入力します。
「クラスタの構成」画面で、「追加」をクリックして、BAM_Clusterを追加します(既存のクラスタはそのままにしておきます)。
表16-3 Oracle BAM用にドメインを拡張するときのクラスタのリスト
| 名前 | クラスタ・アドレス |
|---|---|
|
SOA_Cluster脚注 1 |
空白のままにします |
|
WSM-PM_Cluster |
空白のままにします |
|
BAM_Cluster |
空白のままにします |
脚注 1 ドメインにすでにOracle SOA Suiteを構成している場合にかぎり、SOAクラスタが表示されます。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。
BAM_Cluster:
WLS_BAM1
WLS_BAM2
「次へ」をクリックします。
「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。
ドメインに作成されているマシンを検証します。デフォルトでは、新しいOracle BAM管理対象サーバーを、それぞれSOAHOST1マシンとSOAHOST2マシンにターゲット指定することになります。
ただし、個別のホスト・コンピュータでOracle BAMを構成する場合は、対応するBAMHOST1およびBAMHOST2ホスト・コンピュータ用に2台のマシンを新しく作成する必要があります。
「Unixマシン」タブを選択します。
「追加」ボタンを使用して、BAMHOST1およびBAMHOST2用に2台のUnixマシンを新しく作成します。
BAMHOST1およびBAMHOST2の物理IPアドレスに対するノード・マネージャ・リスニング・アドレス。
「ノード・マネージャ・リスニング・ポート」フィールドのポートを確認します。
この例に示されているポート番号5556は、このドキュメントの他の例にも使用されています。必要に応じて、このポート番号をご使用の独自ポート番号で置換します。
その他のすべてのフィールドはデフォルト値のままにします。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、新しいWLS_BAM1およびWLS_BAM2サーバーを、それぞれSOAHOST1およびSOAHOST2マシンに割り当てます。
ただし個別のホスト・コンピュータでOracle BAMを構成する場合は、新しいOracle BAMサーバーを、新しく作成されたBAMHOST1およびBAMHOST2マシンにそれぞれ割り当てます。
「次へ」をクリックします。
「JMSファイル・ストア」画面で、次のディレクトリをOracle BAMの各永続ストア(このセッションで作成された2つのUMS JMSファイル・ストアを含む)に割り当てます。
ASERVER_HOME/BAM_Cluster/jms
既存のJMSファイル・ストアに割り当てられている値は変更しないでください。これらの値は、事前に構成されている製品に対して作成したクラスタに対応しています。
「構成サマリー」画面には、これから作成するドメインの構成情報の詳細が含まれています。画面上で各項目の詳細をチェックし、情報が正しいことを確認します。
「更新」をクリックします。
「ドメインの拡張」画面で、「完了」をクリックします。
管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。
|
注意: お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。 |
デフォルトの永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。
表の「名前」列で、WLS_BAM1などのサーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
「サービス」タブをクリックします。
ロックして編集をクリックして、変更を開始します。
ページの「デフォルト・ストア」セクションに、データファイルが格納されるデフォルト永続ストアのあるフォルダのパスを入力して、「保存」をクリックします。
このパスのディレクトリ構造は次のとおりです。
ASERVER_HOME/BAM_Cluster/tlogs
WLS_BAM2サーバーに対して、手順2から6を繰り返します。
SOA、OSB、ESSおよびWSMを実行しているサーバーを停止します。
「変更のアクティブ化」をクリックします。
停止した管理対象サーバーを起動します。まず、WLS_WSMサーバーから起動します。
|
注意: トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。WLS_BAM1とWLS_BAM2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。 |
BAMインスタンスを追加してドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびマシンに伝播する必要があります。
表16-4は、変更をすべてのドメイン・ディレクトリとマシンに伝播するために必要な手順をまとめたものです。
更新済ドメインをWEBHOST1およびWEBHOST2マシンに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。
表16-4 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー
| タスク | 説明 | 詳細情報 |
|---|---|---|
|
SOAHOST1での拡張済ドメインの圧縮 |
Packコマンドを使用して、新しいBAMサーバー構成が含まれる新しいテンプレートJARファイルを作成します。 ドメインを圧縮する場合は、soadomaintemplateExtBAM.jarというテンプレートJARファイルを作成します。 |
第11.4.1項「SOAHOST1での拡張済ドメインの圧縮」 |
|
SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍脚注 1 |
SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。 |
第12.7.1項「SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍」 |
|
SOAHOST2でのドメインの解凍 |
SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。 |
|
脚注 1 個別のホストでOracle BAMを構成する場合は、SOAHOST1およびSOAHOST2ではなく、BAMHOST1およびBAMHOST2でドメインを解凍します。
Oracle BAM管理対象サーバーでは、サーバー固有のJMSサービスを使用します。このようなサーバー固有のキューは、クラスタではなく特定の管理対象サーバーに固定されるため、「固定」サービスとも呼ばれます。これらのサーバー固有のキューの可用性を高め、キューが別の管理対象サーバーにフェイルオーバーできるようにするには、サーバーで自動サービス移行を構成する必要があります。
自動サーバー移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサービス移行に関する項を参照してください。
Oracle BAMサーバーの構成中にデータ・ソースとリース構成が作成されますが、次のように、特定のOracle BAMサービスに対して自動移行を手動で有効にする必要があります。
例:
ADMVHN:7001/console
「ドメイン構造」ペインで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーWLS_BAM1の名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
「移行」タブをクリックします。
ロックして編集をクリックして、変更を開始します。
ページの「JMSサービス移行の構成」セクションの「使用可能」リスト・ボックスで、WLS_BAM1およびWLS_BAM2の管理対象サーバーを選択し、移動ボタン
をクリックして、それらを「選択済み」リスト・ボックスに移動します。
「保存」をクリックします。
Oracle User Messaging Service (UMS) 12c (12.1.3)では、サービス移行はサポートされません。そのため、UMS JMSサーバーと永続ストアを非移行可能ターゲットに再度手動でターゲット指定する必要があります。ターゲット指定しない場合は、Oracle BAMのサービス移行が失敗します。
UMSサービスを非移行可能ターゲットにターゲット指定するには:
「ドメイン構造」ウィンドウで、「環境」、「サービス」の順に開いて、「永続ストア」をクリックします。
コンソールに、永続ストアのリストが表示されます。UMSJMSFileStore_auto_の後ろに管理対象サーバーごとに1つの番号が付加された名前を持つ一連のUMS永続ストアが、リストに表示されます。
「WLS_BAM1 (移行可能)」にターゲット指定された、最初のUMSファイル・ストアをクリックします。
選択した永続ストアの設定ページで、「ターゲット」ドロップダウン・メニューで選択した値を、「WLS_BAM1 (移行可能)」から「WLS_BAM1」に変更します。
「保存」をクリックします。
JMSサーバーが永続ストアと同じターゲットにターゲット指定されていないというエラーが発生した場合は、そのエラーは無視できます。
「WLS_BAM2 (移行可能)」にターゲット指定されている残りのUMSファイル・ストア・エントリに対して、手順2から4を繰り返します。
「ドメイン構造」ウィンドウで、「環境」、「サービス」、「メッセージング」の順に開いて、「JMSサーバー」をクリックします。
コンソールに、JMSサーバーのリストが表示されます。UMSJMSServer_auto_の後ろに管理対象サーバーごとに1つの番号が付加された名前を持つ一連のUMS永続ストアが、リストに表示されます。
現在「WLS_BAM1 (移行可能)」にターゲット指定されている、最初のJMSストアをクリックします。
選択したJMSサーバーの設定ページで、「ターゲット」タブをクリックします。
「ターゲット」ドロップダウン・メニューの値を、「WLS_BAM1 (移行可能)」から「WLS_BAM1」に変更します。
「保存」をクリックします。
「WLS_BAM2 (移行可能)」にターゲット指定されている残りのUMS JMSサーバーに対して、手順7から10を繰り返します。
「変更のアクティブ化」をクリックします。
次の手順を使用して、Oracle BAMに対してサービス移行が正しく構成されていることを確認します。
現在のホスト・サーバーの確認:
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ペインで、「環境」、「クラスタ」の順に開きます。
「移行可能なターゲット」をクリックします。
「制御」タブをクリックします。
「移行可能なターゲット」表で、「WLS_BAM1 (移行可能)」ターゲットの行を探します。
「現在のホスト・サーバー」列の値に注目してください。WLS_BAM1管理対象サーバーが、WLS_BAM1 (移行可能)ターゲットの現在のホスト・サーバーであることを確認します。
WLS_BAM1管理対象サーバーを停止します。
次のコマンドを使用します。
kill -9 pid
この例では、pidを、WLS_BAM1管理対象サーバーのプロセスID (PID)に置き換えます。次のUNIXコマンドを実行すると、PIDを確認できます。
ps -ef | grep WLS_BAM1
ノード・マネージャが動作しているターミナル・ウィンドウ(コンソール)を確認します。
WLS_BAM1管理対象サーバーでエラーが発生したことを示すメッセージが表示されます。次のようなメッセージが表示されます。
<INFO> <soaedg_domain> <WLS_BAM1> <The server 'WLS_BAM1' with process id 4668 is no longer alive; waiting for the process to die.> <INFO> <soaedg_domain> <WLS_BAM1> <Server failed so attempting to restart (restart count = 1)>.
Oracle WebLogic Server管理コンソールに戻り、WLS_BAM1 (移行可能)ターゲットの現在のホスト・サーバーがWLS_BAM2であることを確認します。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ペインで、「環境」、「クラスタ」の順に開きます。
「移行可能なターゲット」をクリックします。
「制御」タブをクリックします。
「移行可能なターゲット」表で、「WLS_BAM1 (移行可能)」ターゲットの行を探します。
「現在のホスト・サーバー」列の値に注目してください。WLS_BAM2管理対象サーバーが、WLS_BAM1(移行可能)ターゲットの現在のホスト・サーバーであることを確認します。
|
注意: 自動サービス移行が行われ、必要なOracle BAMサービスが自動的に別の管理対象サーバーに移行された場合、元の管理対象サーバーがオンラインに戻り、クラスタに再度参加しても、これらのサービスは、フェイルオーバー・サーバーにターゲット指定されたままになります。サービスを元のサーバーに手動でフェイルバックすることをお薦めします。詳細は、第18.2.3項「自動サービス移行後のOracle BAMサービスのフェイルバック」を参照してください。 |
管理対象サーバーのOracle BAM構成を検証する前に、エンタープライズ・デプロイメント管理ユーザー(weblogic_soa)をBAMAdministratorsグループに追加します。
このタスクを実行するには、第18.2.1項「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。
ドメインの拡張、管理サーバーの再起動、およびドメインの他のホストへの伝播を完了したら、新しく構成したBAMサーバーを起動します。
ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
http://ADMINVHN:7001/em
管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。
WLS_BAM1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。
|
注意: BAMサーバーは、ポリシー・アクセス・サービスに依存して機能するため、BAMサーバーが起動する前に、ドメイン内のWSM-PM管理対象サーバーが稼働し、アクセス可能な状態になっている必要があります。 |
起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_BAM1管理対象サーバーが稼働中であることを確認します。
BAMソフトウェアが適切に構成されていることを確認するには:
ブラウザに次のURLを入力します。
http://SOAHOST1:9001/bam/composer
BAMのコンポーザのログイン画面が表示されます。
個別のホスト・コンピュータでOracle BAMを構成した場合は、SOAHOST1ではなく、BAMHOST1をURLに入力します。
weblogic_soaログイン資格証明を入力します。
図16-1に示すように、BAM Composerの画面が表示されます。
次のURLを入力します。
http://SOAHOST1:9001/inspection.wsil/
次のリンクのリストが含まれるレスポンスが表示されます。
個別のホスト・コンピュータでOracle BAMを構成した場合は、SOAHOST1ではなく、BAMHOST1をURLに入力します。
ブラウザに次のURLを入力します。
http://SOAHOST1:9001/bam/cqservice/
個別のホスト・コンピュータでOracle BAMを構成した場合は、SOAHOST1ではなく、BAMHOST1をURLに入力します。
BAM CQServiceが稼働中であることを示すメッセージが、ブラウザに表示されます。
WLS_BAM2でも、前の項と同様の手順を実行します。
管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。
WLS_BAM2管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。
起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_BAM2管理対象サーバーが稼働中であることを確認し、次のようにWLS_BAM2用の同等のURLにアクセスします。
http://SOAHOST2:9001/bam/composer
BAMのコンポーザのログイン画面が表示されます。ログイン資格証明を入力します。BAM Composerのメニューが表示されます。
次のURLを入力します。
http://SOAHOST2:9001/inspection.wsil/
リンクのリストが含まれるレスポンスが表示されます。
ブラウザに次のURLを入力します。
http://SOAHOST2:9001/bam/cqservice/
BAM Serviceが稼働中であることを示すメッセージが、ブラウザに表示されます。
Oracle HTTP Serverインスタンスの構成ファイルに対して次の変更を行い、Web層のOracle HTTP Serverインスタンスが、 Oracle SOA Suiteクラスタ上のOracle B2BソフトウェアにOracle B2Bリクエストを正しくルーティングできるようにします。
この手順は、Oracle SOA Suiteと同じホストでOracle BAMを構成することを前提にしています。Oracle BAM用に個別のホストを使用する場合は、SOAHOSTコンピュータではなくBAMHOSTコンピュータを参照するように、Oracle HTTP Server構成ファイルのWebLogicClusterパラメータを変更する必要があります。
Oracle HTTP Serverが、Oracle B2BコンソールとOracle B2Bサービスにリクエストをルーティングできるようにするには:
SOAHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(OHS_1)の構成ディレクトリに変更します。
cd ASERVER_HOME/config/fmwconfig/components/OHS/OHS_1/
次のディレクティブを、soa_vh.confファイルの<VirtualHost>タグ内に追加します。
<Location /bam/composer > SetHandler weblogic-handler WebLogicCluster SOAHOST1:9001,SOAHOST2:9001 </Location> <Location /OracleBAMWS> SetHandler weblogic-handler WebLogicCluster SOAHOST1:9001,SOAHOST2:9001 </Location>
ディレクトリを次の場所に変更して、2番目のOracle HTTP Serverインスタンス(OHS_2)の構成ファイルを更新できるようにします。
cd ASERVER_HOME/config/fmwconfig/components/OHS/OHS_2/
soa_vh.confファイルを開き、B2Bディレクティブを<VirualHost>タグに追加します。
管理サーバーを再起動します。
管理サーバーの起動後に、WEBHOST1とWEBHOST2の両方で次のディレクトリのファイルを調べて、それらのファイルにAdministration Server管理サーバー・ドメイン・ディレクトリで行った変更が含まれていることを確認します。
MSERVER_HOME/config/fmwconfig/components/OHS/instances/OHS_1/
MSERVER_HOME/config/fmwconfig/components/OHS/instances/OHS_2/
WEBHOST1とWEBHOST2上のOracle HTTP Serverインスタンスを再起動します。
BAMクラスタの「WebLogicプラグインの有効化」パラメータを設定します。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ペインで、「環境」ノードを開きます。
「クラスタ」をクリックします。
Oracle HTTP Serverからのリクエストをプロキシ設定する、BAM_Clusterクラスタを選択します。
「構成: 一般」タブが表示されます。
「詳細」セクションまでスクロール・ダウンして、開きます。
「ロックして編集」をクリックします。
「WebLogicプラグインの有効化」を「はい」に設定します。
変更を保存してアクティブ化をクリックします。BAMサーバーを再起動して、変更を有効にします。
Oracle BAM URLが、ハードウェア・ロード・バランサからのリクエストを、Oracle HTTP Serverインスタンスを経て中間層のOracle BAMソフトウェアに、正常にルーティングしていることを確認します。
この手順では、Oracle BAMが構成されている管理対象サーバーのフェイルオーバーをテストすることもできます。
URLを検証する手順は次のとおりです。
WLS_BAM1管理対象サーバーが稼働中は、Oracle WebLogic Server管理コンソールを使用して、WLS_BAM2管理対象サーバーを停止します。
次のURLにアクセスし、第16.10項「WLS_BAM1管理対象サーバーの起動」で示すように、HTTPレスポンスを検証します。
http://soa.example.com/bam/composer
Oracle WebLogic Server管理コンソールでWLS_BAM2を起動します。
Oracle WebLogic Server管理コンソールでWLS_BAM1を停止します。
URLに再度アクセスし、第16.11項「WLS_BAM2管理対象サーバーの起動と検証」に示すように、HTTPレスポンスが有効であることを確認します。
Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。
バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
構成をバックアップする方法の詳細は、第18.2.6項「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。
