この章では、Oracle Enterprise Schedulerソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。
この章には次の項が含まれます:
この章のタスクを実行する際には、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」で定義されているいくつかのディレクトリ変数に次の値を入力するように求められます。
ORACLE_HOME
ASERVER_HOME
MSERVER_HOME
さらに、第5.2.3項「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスを参照することになります。
ADMINVHN
この章のアクションは、次のホスト・コンピュータで実行します。
SOAHOST1
SOAHOST2
WEBHOST1
WEBHOST2
この項では、SOAドメインへのOracle Enterprise Schedulerの追加について概説します。表15-1は、Oracle Enterprise Schedulerを追加するためのSOAドメイン拡張の大まかな手順と説明を示しています。
表15-1 Oracle Enterprise Schedulerを追加するためのSOAドメインの拡張手順
手順 | 説明 | 詳細情報 |
---|---|---|
ESS用のデータベース・スキーマの作成 |
RCU画面に移動し、データベース・スキーマを作成します。 |
|
ドメイン拡張のための構成ウィザードの実行 |
Oracle Enterprise Schedulerコンポーネントを追加するために、SOA/OSBドメイン拡張します。 |
第15.4項「Oracle Enterprise Schedulerを追加するためのSOAドメインの拡張」 |
トランザクション・リカバリのためのデフォルトの永続ストアの構成 |
クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。 |
第15.5項「トランザクション・リカバリ用のデフォルト永続ストアの構成」 |
SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播 |
Oracle Enterprise Schedulerは、WebLogic Server起動スクリプトに対するいくつかの更新を必要とします。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。 |
第15.6項「ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播」 |
Oracle Enterprise Schedulerサーバーの起動 |
Oracle Enterprise Schedulerサーバーは、既存のドメインを拡張します。そのため、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。 |
|
WLS_ESS管理対象サーバーの検証 |
管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認し、URLにアクセスしてサーバーのステータスを確認します。 |
第15.9項「WLS_ESS2管理対象サーバーの起動と検証」 |
WLS_ESSn管理対象サーバーに対するOracle HTTP Serverの構成 |
Oracle HTTP ServerがOracle Enterprise Schedulerコンソールおよびサービスにルーティングできるようにするには、WebLogicClusterパラメータを、クラスタ内のノードのリストに設定します。 |
第15.11項「WLS_ESS管理対象サーバーに対するOracle HTTP Serverの構成」 |
Oracle HTTP Serverを介したアクセスの検証 |
サーバーのステータスが「実行中」であることを確認します。 |
第15.13項「ハードウェア・ロード・バランサを介したOracle Enterprise Schedulerへのアクセスの検証」 |
Oracle Enterprise Schedulerのバックアップ |
この後の手順でエラーが発生した場合の即座のリストアを目的として、ドメイン構成をバックアップします。 |
第15.14項「Oracle Enterprise Scheduler構成のバックアップ」 |
Oracle ESSサーバーを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。
これらのスキーマを、次の項の手順に従ってインストールします。
リポジトリ作成ユーティリティ(RCU)を起動するには:
システムのORACLE_HOME
/oracle_common/bin
ディレクトリに移動します。
JAVA_HOME
環境変数が、ご使用のシステム上の動作保証されたJDKの場所に設定されていることを確認します。この場所は、bin
より上のディレクトリにする必要があります。たとえば、JDKが/u01/oracle/products/jdk1.7.0_55
に存在する場合は、次のようになります。
UNIXオペレーティング・システムの場合:
export JAVA_HOME=/u01/oracle/products/jdk1.7.0_55
次のようにRCUを起動します。
UNIXオペレーティング・システムの場合:
./rcu
スキーマの作成には、次のタスクが含まれています。
「次へ」をクリックします。
データベースでDBAアクティビティを実行するために必要な権限を持っている場合は、「システム・ロードおよび製品ロードの同時実行」を選択します。この手順では、必要な権限があることを想定しています。
データベースでDBAアクティビティを実行するために必要な権限を持っていない場合は、この画面で「システム・ロードに対するスクリプトの準備」を選択します。これによってSQLスクリプトが生成され、これをデータベース管理者が利用できます。『リポジトリ作成ユーティリティによるスキーマの作成』でシステム・ロードと製品ロードの理解に関する項を参照してください。
RCUがデータベースに接続するためのデータベース接続の詳細を提供します。「ホスト名」に、ご使用のRAC DBのSCANアドレスを入力します。
「次へ」をクリックして続行し、データベースへの接続が成功したことを通知するダイアログ・ウィンドウで「OK」をクリックします。
「既存の接頭辞の選択」を選択して、元のドメイン作成スキーマで使用した接頭辞を指定します。
Oracle AS共通スキーマを開き、コンポーネント・リストで「Oracle Enterprise Scheduler」を選択します。
カスタム接頭辞は、これらのスキーマをこのドメイン専用に論理的にグループ化するために使用します。ドメイン間でのスキーマ共有はサポートされていないため各ドメイン用のスキーマの一意のセットを作成する必要があります。
ヒント: カスタム接頭辞の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のカスタム接頭辞の理解に関する項を参照してください。マルチドメイン環境のスキーマを編成する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のスキーマの作成計画に関する項を参照してください。 |
ヒント: ここで入力したカスタム接頭辞を書き留めておく必要があります。これは後でドメインの作成時に必要になります。 |
「次へ」をクリックして続行し、スキーマ作成の前提条件チェックが成功したことを通知するダイアログ・ウィンドウで「OK」をクリックします。
データベースでのスキーマ・パスワードの設定方法を指定した後、パスワードを指定して確認します。
ヒント: この画面で設定したパスワードを書き留めておく必要があります。これは後でドメインの作成時に必要になります。 |
デフォルトおよび一時表領域の選択で「次へ」をクリックし(デフォルトを受け入れ)、作成する表領域に関する警告を表示する「確認」ポップアップ・ウィンドウをクリックします。
残りのRCU画面を最後までナビゲートし、スキーマ作成を完了します。「完了サマリー」画面が表示されたら、「閉じる」をクリックしてRCUを終了します。
この項では、Oracle Enterprise Schedulerを含める既存のエンタープライズ・デプロイメントの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 Enterprise Schedulerコンポーネントを含めます。
この項の手順は、Oracle Fusion Middleware Infrastructureドメインを直接拡張するために必要な手順とほぼ同じになりますが、画面に表示される一部のオプション、ライブラリ、コンポーネントは異なります。
ドメイン作成および構成には次のタスクが含まれます。
「構成タイプ」画面で、「既存ドメインの更新」を選択します。
「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、第10章で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。
ディレクトリの場所の変数の詳細は、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。
ヒント: この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。 |
「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。
Oracle Enterprise Scheduler Service Basic - 12.1.3.0 [oracle_common]
Oracle Enterprise Manager Plugin for ESS - 12.1.3.0 [em]
「次へ」をクリックします。
注意: 拡張前に作成されたカスタム・データソース(リース・データソースなど)は、この画面の前に表示されます。「データソース」行を確認し、「次へ」をクリックします。テスト・データソース画面で、その妥当性が確認されます。「次へ」をクリックします。 |
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.
ヒント: RCUデータのオプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。 |
ESSスキーマおよびESS MDSスキーマ・コンポーネント・スキーマを選択し、「GridLinkへ変換」オプションを選択して「次へ」をクリックします。
次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
ドライバ: 「OracleのGridLinkConnections用ドライバ(Thin)、バージョン: 10以降」を選択します。
サービス名:データベースのサービス名を、小文字で入力します。例:
soaedg.mycompany.com
「スキーマ所有者」および「スキーマ・パスワード」はRCU情報によって事前に移入されています。
FANオプションが選択されていることと、「SSLの有効化」が選択解除されていることを確認します(または、ONS通知に対してSSLが選択されて暗号化されている場合、適切なウォレットとウォレット・パスワードを入力します)。
SQL>show parameter remote_listener; NAME TYPE VALUE ------------------------------------------------------------- remote_listener string db-scan.mycompany.com:1521
ONSホスト:データベースからの通知のとおり、Oracle RACデータベースのSCANアドレスとONSリモート・ポートを入力します。
[orcl@db-scan1 ~]$ srvctl config nodeapps -sONS exists: Local port 6100, remote port 6200, EM port 2016
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、すべての接続が正常であることを確認します。
接続のテストは自動的に行われます。「ステータス」列に結果が表示されます。正常でない接続がある場合は、「前へ」をクリックして前の画面に戻り、入力を訂正します。
すべての接続に成功したら「次へ」をクリックします。
拡張構成の選択画面で、次を選択します。
管理対象サーバー、クラスタおよびCoherence
「次へ」をクリックします。
「管理対象サーバー」画面で、エンタープライズ・スケジューラに必要な管理対象サーバーを追加します。
自動的に作成されたサーバーを選択し、「名前の変更」をクリックして、名前をWLS_ESS1に変更します。
「追加」をクリックして別の新規サーバーを追加し、サーバー名としてWLS_ESS2と入力します。
WLS_ESS1およびWLS_ESS2サーバーに、表15-2内の属性を指定します。
「次へ」をクリックします。
表15-2 管理対象サーバー
名前 | リスニング・アドレス | リスニング・ポート | 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_OSB1脚注 2 |
SOAHOST1VHN2 |
8011 |
該当なし |
いいえ |
OSB-MGD-SVRS-ONLY |
WLS_OSB2 |
SOAHOST2VHN2 |
8011 |
該当なし |
いいえ |
OSB-MGD-SVRS-ONLY |
WLS_ESS1 |
SOAHOST1 |
8021 |
該当なし |
いいえ |
ESS-MGD-SVRS |
WLS_ESS2 |
SOAHOST2 |
8021 |
該当なし |
いいえ |
ESS-MGD-SVRS |
脚注 1 Oracle SOA Suiteが構成されているドメインを拡張する場合にかぎり、WLS_SOA管理対象サーバーが表示されます。
脚注 2 Oracle Service Busが構成されているドメインを拡張する場合にかぎり、WLS_OSB管理対象サーバーが表示されます。
「クラスタの構成」画面で、表15-3に示される各プロパティの値を使用して、エンタープライズ・スケジューラ・クラスタを追加します。
「次へ」をクリックします。
表15-3 ESS_Clusterの追加時の「クラスタの構成」画面上のクラスタ
名前 | クラスタ・アドレス | フロント・エンド・ホスト | フロントエンドHTTPポート | フロントエンドHTTPS |
---|---|---|---|---|
SOA_Cluster脚注 1 |
空白のままにします |
soa.example.com |
80 |
443 |
WSM-PM_Cluster |
空白のままにします |
空白のままにします |
空白のままにします |
空白のままにします |
OSB_Cluster脚注 2 |
空白のままにします |
osb.example.com |
80 |
443 |
ESS_Cluster |
空白のままにします |
soa.example.com |
80 |
443 |
脚注 1 Oracle SOA Suiteが構成されているドメインを拡張する場合にかぎり、SOA_Clusterクラスタが表示されます。
脚注 2 Oracle Service Busが構成されているドメインを拡張する場合にかぎり、OSB_Clusterクラスタが表示されます。
「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。
SOA_Cluster - SOAドメインを拡張する場合
WLS_SOA1
WLS_SOA2
WSM-PM_Cluster:
WLS_WSM1
WLS_WSM2
OSB_Cluster - OSBドメインを拡張する場合:
WLS_OSB1
WLS_OSB2
ESS_Cluster:
WLS_ESS1
WLS_ESS2
「次へ」をクリックします。
「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。
「Unixマシン」タブで、次のエントリが表示されることを確認します。
表15-4 マシン
名前 | ノード・マネージャのリスニング・アドレス |
---|---|
SOAHOST1 |
SOAHOST1 |
SOAHOST2 |
SOAHOST2 |
ADMINHOST |
ADMINVHN |
WEBHOST1 |
WEBHOST1 |
WEBHOST2 |
WEBHOST2 |
その他のすべてのフィールドはデフォルト値のままにします。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。
ADMINHOST:
AdminServer
SOAHOST1
WLS_SOA1 (SOAドメインを拡張する場合)
WLS_WSM1
WLS_OSB1 (OSBドメインを拡張する場合)
WLS_ESS1
SOAHOST2
WLS_SOA2 (SOAドメインを拡張する場合)
WLS_WSM2
WLS_OSB2 (OSBドメインを拡張する場合)
WLS_ESS2
「次へ」をクリックします。
「構成サマリー」画面には、これから作成するドメインの構成情報の詳細が含まれています。画面上で各項目の詳細をチェックし、情報が正しいことを確認します。
「更新」をクリックします。
「ドメインの拡張」画面で、「完了」をクリックします。
管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。
各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。
Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーでトランザクション回復サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。
注意: トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、このディレクトリは、サーバーを再起動する前にも存在している必要があります。お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。 |
デフォルトの永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
ADMINVHN:7001/console
「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
WLS_ESS管理対象サーバーごとに、次を実行します。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
「構成」タブで、「サービス」タブをクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
エンタープライズ・デプロイメントでは、ESS_Cluster
という管理サーバー・ドメイン・ホームに、新しいサブディレクトリを作成することをお薦めします。このサブディレクトリは、トランザクション・ログの中央の共有場所の役割を果たすことができます。
例:
ASERVER_HOME/ESS_Cluster/tlogs
「保存」をクリックします。
ドメイン内(必要に応じて、WLS_SOAドメインおよびWLS_OSBドメイン内)のWLS_WSM管理対象サーバーを停止します。
「サーバーのサマリー」ページで、停止する管理対象サーバーを選択します。管理サーバー(AdminServer)は選択しないでください。
「停止」をクリックして、影響を受ける管理対象サーバーがアクティブにリクエストを処理しているかどうかに応じて、「作業完了時」または「強制停止」を選択します。
「保存」をクリックして、「変更のアクティブ化」をクリックします。
停止した管理対象サーバーを起動します。
ESSインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびマシンに伝播する必要があります。
表15-5は、変更をすべてのドメイン・ディレクトリおよびマシンに伝播するために必要な手順の概要を示しています。
更新済ドメインをWEBHOST1およびWEBHOST2マシンに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。
表15-5 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー
タスク | 説明 | 詳細情報 |
---|---|---|
SOAHOST1での拡張済ドメインの圧縮 |
Packコマンドを使用して、新しいESSサーバー構成が含まれる新しいテンプレートJARファイルを作成します。 ドメインを圧縮する場合は、 |
第11.4.1項「SOAHOST1での拡張済ドメインの圧縮」 |
SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍 |
SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。 |
第12.7.1項「SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍」 |
SOAHOST2でのドメインの解凍 |
SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。 |
|
WLS_ESS1管理対象サーバーのOracle Enterprise Scheduler構成を検証する前に、ESSAdmin
ロールをエンタープライズ・デプロイメントの管理グループ(SOA Administrators
)に追加します。
このタスクを実行するには、第18.2.1項「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。
これでドメインの拡張、管理サーバーの再起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したESSサーバーを起動できます。
ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
http://ADMINVHN:7001/em
この例では、次のようになります。
ADMINVHNを、第5.3項「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。
ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。
管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。
WLS_ESS1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。
注意: SOAサーバーは、ポリシー・アクセス・サービスに依存して機能します。つまり、SOAサーバーが起動される前に、ドメイン内のWSM-PMサーバーがアクセス可能な状態になっている必要があります。 |
起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_ESS1管理対象サーバーが稼働中であることを確認します。
ESSソフトウェアが構成されていることを検証するには、ブラウザに次のURLを入力します。
http://SOAHOST1:8021/EssHealthCheck
デフォルトのインストールでは、図15-1に示すように、これはHTTPレスポンスです。
図15-3 Oracle Enterprise Schedulerのヘルス・チェックのレスポンス画面
ヘルス・チェック・ボタンをクリックし、welogic_soa
管理資格証明を使用してログインします。
図15-4、第15.8項「ESSが稼働中であるというレスポンス」で示すように、返信で、Oracle Enterprise Schedule (ESS)が稼働中であることが報告されます。
WLS_ESS2でも、前の項と同様の手順を実行します。
管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。
WLS_ESS2管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。
起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_ESS2管理対象サーバーが稼働中であることを確認し、次のようにWLS_ESS2用の同等のURLにアクセスします。
http://SOAHOST2:8021/EssHealthCheck
ヘルス・チェック・ボタンをクリックし、welogic_soa
管理資格証明を使用してログインします。
図15-4に示すように、 返信で、Oracle Enterprise Schedulerが稼働中であることが報告されます。
WLS_ESS1およびWLS_ESS2が稼働したら、第15.5項「トランザクション・リカバリ用のデフォルト永続ストアの構成」で実行した手順に基づいて、トランザクション・ログ・ディレクトリとトランザクション・ログが期待どおりに作成されたことを確認します。
ASERVER_HOME/ESS_Cluster/tlogs
_WLS_WLS_ESS1000000.DAT
_WLS_WLS_ESS2000000.DAT
Oracle HTTP Serverインスタンスの構成ファイルに対して次の変更を行い、Web層のOracle HTTP Serverインスタンスが、SOAHOST1およびSOAHOST2上のWLS_ESS管理対象サーバーにOracle Enterprise Schedulerのリクエストを正しくルーティングできるようにします。
Oracle HTTP Serverが、アプリケーション層にOracle Enterprise Schedulerのリクエストをルーティングできるようにするには:
SOAHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(OHS_1)の構成ディレクトリに変更します。
cd ASERVER_HOME/config/fmwconfig/components/OHS/OHS_1/
次のディレクティブを、soa_vh.conf
ファイルの<VirtualHost>
タグ内に追加します。
<Location /ess > SetHandler weblogic-handler WebLogicCluster SOAHOST1:8021,SOAHOST2:8021 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /EssHealthCheck > SetHandler weblogic-handler WebLogicCluster SOAHOST1:8021,SOAHOST2:8021 WLProxySSL ON WLProxySSLPassThrough ON </Location>
ディレクトリを次の場所に変更して、2番目のOracle HTTP Serverインスタンス(OHS_2)の構成ファイルを更新できるようにします。
cd ASERVER_HOME/config/fmwconfig/components/OHS/OHS_2/
soa_vh.conf
ファイルを開き、<VirualHost>
タグにOracle Business Process Managementディレクティブを追加します。
管理サーバーを再起動します。
管理サーバーの起動後に、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を再起動します。
ESSクラスタの「WebLogicプラグインの有効化」パラメータを設定するには:
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ペインで、「環境」ノードを開きます。
「クラスタ」をクリックします。
Oracle HTTP Serverからのリクエストをプロキシ設定する、ESS_Clusterクラスタを選択します。
「構成: 一般」タブが表示されます。
「詳細」セクションまでスクロール・ダウンして、開きます。
「ロックして編集」をクリックします。
「WebLogicプラグインの有効化」を「はい」に設定します。
変更を保存してアクティブ化をクリックします。
ESSサーバーを再起動して、変更内容を有効にします。
URLを検証して、HTTP ServerからOracle ESSコンポーネントへのルーティングとフェイルオーバーが適切に機能することを確認します。
ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。
URLを検証する手順は次のとおりです。
WLS_ESS1が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_ESS2を停止します。
第15.9項「WLS_ESS2管理対象サーバーの起動と検証」で示すように、Webブラウザから次のURLにアクセスして、HTTPレスポンスを確認します。
http://soa.example.com/EssHealthCheck
Oracle WebLogic Server管理コンソールでWLS_ESS2を起動します。
Oracle WebLogic Server管理コンソールでWLS_ESS1を停止します。
ロード・バランサのアドレスを使用して、これらのURLを検証します。
https://soa.example.com:443/EssHealthCheck
Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。
バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
構成をバックアップする方法の詳細は、第18.2.6項「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。