13 Oracle SOA Suiteを含めるドメインの拡張
- Oracle SOA Suiteの構成時に使用される変数
Oracle SOA Suiteを追加してドメインを拡張する際には、この項にリストされているディレクトリ変数を参照します。 - Oracle SOA Suiteでの動的クラスタのサポート
SOAは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。 - システム・クロックの同期
Oracle SOA Suiteを含むようにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。 - エンタープライズ・デプロイメント用のソフトウェアのインストール
この項では、エンタープライズ・デプロイメント用のソフトウェアをインストールする手順について説明します。 - Oracle SOA Suiteデータベース・スキーマの作成
Oracle SOA Suiteドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。 - Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張
次のタスクを実行して、Oracle SOA Suiteソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張します。 - ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
Oracle SOA Suiteインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリとマシンに伝播する必要があります。 - WLS_SOA1管理対象サーバーの起動および検証
これでドメインの拡張、管理サーバーの起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle SOA Suite管理対象サーバーを起動できます。 - 管理対象サーバーWLS_SOA2の起動と検証
WLS_SOA1管理対象サーバーが正常に構成され起動されたことを確認したら、WLS_SOA2管理対象サーバーを起動して検証できます。 - uploadおよびstageディレクトリの絶対パスへの変更
- 動的クラスタを使用する際のリスニング・アドレスの構成
- 拡張したドメイン用のWeb層の構成
Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをインスタンスでルーティングできるようにします。 - Oracle SOA Suiteの構成後ステップ
Oracle SOA Suiteをインストールして構成した後、次のような構成後タスクを検討します。 - Oracle SOA SuiteのJDBC永続ストアの有効化
Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。 - Oracle SOA Suiteに対する自動サービス移行の有効化
この章でインストールした製品の高可用性を実現するには、適切にサービス移行を構成する必要があります。 - 構成のバックアップ
Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。
上位トピック: 「エンタープライズ・ドメインの構成」
Oracle SOA Suiteの構成時に使用される変数
Oracle SOA Suiteを追加してドメインを拡張する際、この項にリストするディレクトリ変数を使用します。
いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。
-
ORACLE_HOME
-
ASERVER_HOME
-
MSERVER_HOME
-
APPLICATION_HOME
-
DEPLOY_PLAN_HOME
-
WEB_DOMAIN_HOME
-
JAVA_HOME
-
ORACLE_RUNTIME
さらに、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で定義されている、次の仮想IP (VIP)アドレスを参照します。
-
ADMINVHN
この章のアクションは、次のホスト・コンピュータで実行します。
-
SOAHOST1
-
SOAHOST2
-
WEBHOST1
-
WEBHOST2
親トピック: Oracle SOA Suiteを含めるドメインの拡張
Oracle SOA Suiteでの動的クラスタのサポート
SOAは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。
静的クラスタは、構成済クラスタとも言い、各サーバー・インスタンスを手動で構成して追加する従来型のクラスタです。動的クラスタには、新しい"server-template"オブジェクトが含まれています。このオブジェクトは、すべての生成された(動的)サーバー・インスタンスの一元的な構成を定義するために使用します。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。この機能により、追加のサーバー容量が必要になったときに、動的クラスタ内のサーバー・インスタンスの数をスケール・アップできます。動的サーバーは、最初に手動で構成してそれをクラスタに追加する必要はなく、単に起動するだけで使用できます。
-
構成ウィザードのプロセスは、それぞれのケースに応じて異なることがあります。たとえば、サーバーではなく動的クラスタ用のサーバー・テンプレートの定義が必要になります。
-
動的クラスタの場合は、サーバー固有の構成(リスニング・アドレスの設定、アップロードとステージングのディレクトリの構成、キーストアの構成など)をサーバーではなくサーバー・テンプレートで実行する必要があります。
-
動的クラスタの場合は、サービス移行が異なる方法で構成されます。動的クラスタは移行可能ターゲットを使用しないかわりに、JMSリソースがクラスタをターゲットにします。動的クラスタのサービス移行を構成する際の具体的な手順は、このガイドに記載されています。
複合クラスタ(動的サーバー・インスタンスと構成済サーバー・インスタンスの両方を備えたクラスタ)は、Oracle SOA Suiteエンタープライズ・デプロイメントではサポートされません。
親トピック: Oracle SOA Suiteを含めるドメインの拡張
システム・クロックの同期
Oracle SOA Suiteを含むようにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。
ネットワーク・タイム・プロトコル(NTP)の使用をお薦めします。「NTP (時間)サーバーを使用するためのホストの構成」を参照してください。
時刻同期を確認するには、それぞれのホストでntpstat
コマンドを実行してNTPサービスに問合せを実行します。
出力例:
$ ntpstat
synchronised to NTP server (10.132.0.121) at stratum 3
time correct to within 42 ms
polling server every 16 s
親トピック: Oracle SOA Suiteを含めるドメインの拡張
エンタープライズ・デプロイメント用のソフトウェアのインストール
この項では、エンタープライズ・デプロイメント用のソフトウェアをインストールする手順について説明します。
- SOAHOST1でのOracle SOA Suiteインストーラの起動
- インストール画面への移動
- 他のホスト・コンピュータへのOracle SOA Suiteのインストール
- インストールの確認
親トピック: Oracle SOA Suiteを含めるドメインの拡張
SOAHOST1でのOracle SOA Suiteインストーラの起動
インストール・プログラムを起動する手順は次のとおりです。
インストール・プログラムが表示されると、インストールを開始する準備ができています。
インストール画面への移動
インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。
インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。
画面 | 説明 |
---|---|
製品のインストーラの紹介画面です。 |
|
この画面を使用して、使用可能なパッチを「My Oracle Support」で自動的に検索するかユーザーの組織のためにすでにダウンロードされているパッチを、ローカル・ディレクトリで自動的に検索します。 |
|
この画面を使用してOracleホーム・ディレクトリの位置を指定します。 Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成用のディレクトリの選択に関する項を参照してください。 |
|
この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。
|
|
この画面では、ご使用のシステムが最小要件を満たしていることを検証します。 警告メッセージまたはエラー・メッセージが表示された場合は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のシステム環境の検証ロードマップに関する項に記載されているドキュメントのいずれかを参照してください。 |
|
この画面を使用して、選択したインストール・オプションを検証できます。 「インストール」をクリックしてインストールを開始します。 |
|
この画面では、インストールの進行状況を参照できます。 進捗バーが100%完了になった後で、「次へ」をクリックします。 |
|
この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。 |
他のホスト・コンピュータへのOracle SOA Suiteのインストール
SOAHOST2で製品マウント・ポイントおよびORACLE_HOME用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、SOAHOST2でも製品インストールを実行する必要があります。
「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。
トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「SOAHOST1でのInfrastructureインストーラの起動」と「Infrastructureインストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。
インストールの確認
インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。
インストール・ログ・ファイルの確認
インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルとその場所の詳細は、『Oracle Universal Installerによるソフトウェアのインストール』のインストール・ログ・ファイルの理解に関する項を参照してください。
親トピック: インストールの確認
ディレクトリ構造のチェック
インストールの内容は、インストール中に選択するオプションによって異なります。
Oracle SOA Suiteを追加すると、次のディレクトリおよびサブディレクトリが追加されます。ls --format=single-column
コマンドを使用して、ディレクトリ構造を確認します。
ls --format=single-column /u01/oracle/products/fmw/soa bam bin bpm common integration jlib modules plugins readme.txt reports soa
インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要ディレクトリに関する項を参照してください。
親トピック: インストールの確認
Oracleホームの内容の表示
viewInventory
スクリプトを使用して、Oracleホームの内容を表示することもできます。『Oracle Universal Installerによるソフトウェアのインストール』のOracleホームの内容の表示に関する項を参照してください。
親トピック: インストールの確認
Oracle SOA Suiteデータベース・スキーマの作成
Oracle SOA Suiteドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。
親トピック: Oracle SOA Suiteを含めるドメインの拡張
スキーマ作成のためのRCU画面のナビゲート
スキーマ作成に必要なタスクは、次のとおりです。
- タスク1 RCUの導入
-
「次」をクリックします。
- タスク2 スキーマ作成の方法の選択
-
対象のデータベースに対するDBAアクティビティの実行に必要なパーミッションと権限が付与されている場合は、「システム・ロードおよび製品ロード」を選択します。この手順は、必要な権限が付与されていることを前提としています。
データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。このオプションによってSQLスクリプトが生成され、必要なスキーマを作成するためにデータベース管理者が利用できます。『リポジトリ作成ユーティリティによるスキーマの作成』のシステム・ロードと製品ロードの理解に関する項を参照してください。
「次」をクリックします。
- タスク3 データベース接続の詳細の指定
-
RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。
-
「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。
-
RACデータベースのスキャン・リスナーの「ポート」番号、たとえば1521を入力します。
-
データベースのRAC「サービス名」を入力します。
-
スキーマとスキーマ・オブジェクトを作成する権限を持つユーザーの「ユーザー名」、たとえば「SYS」などを入力します。
-
ステップ4で指定した名前のユーザーの「パスワード」を入力します。
-
SYSユーザーを選択した場合は、ロールを必ずSYSDBAに設定してください。
-
「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。
-
- タスク4 カスタム接頭辞の指定とスキーマの選択
-
「既存の接頭辞の選択」を選択し、初期ドメインを作成したときに使用した接頭辞を選択します。
スキーマのリストから「SOA Suite」スキーマを選択します。これにより、「SOAインフラストラクチャ」が自動的に選択されます。また、次の依存スキーマがInfrastructureとともにすでにインストールされて灰色表示されています。
-
共通インフラストラクチャ・サービス
-
Oracle Platform Security Services
-
ユーザー・メッセージング・サービス
-
監査サービス
-
監査サービスへの追加
-
監査サービス・ビューア
-
メタデータ・サービス
-
WebLogicサービス
カスタム接頭辞は、これらのスキーマを論理的にグループ化して、このドメイン内でのみ使用することを目的としています。複数のドメイン間でのスキーマの共有はサポートされていないため、ドメインごとに固有のスキーマのセットを作成する必要があります。
ヒント:
カスタム接頭辞の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のカスタム接頭辞の理解に関する項を参照してください。
マルチドメイン環境のスキーマを構成する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のスキーマの作成計画に関する項を参照してください。
「次へ」をクリックして続行し、スキーマ作成の前提条件チェックが成功したことを通知するダイアログ・ウィンドウで「OK」をクリックします。
-
- タスク5 スキーマのパスワードの指定
-
スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。パスワードが、データベースのセキュリティ要件を満たすくらい複雑であることを確認してから続行します。パスワード・ポリシーを満たしていない場合でも、この時点でRCUでは処理が続行されます。したがって、次のチェックはRCU以外で実行します。
ヒント:
この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。
「次」をクリックします。
- タスク6 カスタム変数の指定
-
SOAインフラストラクチャ・スキーマのカスタム変数を指定します。
エンタープライズ・デプロイメント・トポロジの場合、Database Profileのカスタム変数として
LARGE
を入力し、Oracle Healthcareの使用を予定している場合は、Healthcare Integrationの変数としてYES
を入力します。『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』のSOA Suiteスキーマに必要なカスタム変数に関する項を参照してください。「次」をクリックします。
- タスク7 必須スキーマの表領域の検証
-
「表領域のマップ」画面で情報を確認し、「次へ」をクリックして、デフォルト値を受け入れます。
確認ダイアログ・ボックスで「OK 」をクリックします。
「次」をクリックします。
- タスク8 スキーマの作成
-
ロードするスキーマのサマリーを確認し、「作成」をクリックするとスキーマの作成が完了します。
注意:
エラーが発生した場合は、リストされているログ・ファイルを確認して根本原因を特定し、問題を解決し、RCUを使用してスキーマを削除してから再作成します。
- タスク9 レビュー完了のサマリーとRCU実行の完了
-
「完了サマリー」画面まで進んだら、スキーマ作成がすべて正常に完了していることを確認し、「閉じる」をクリックしてRCUを閉じます。
スキーマ・アクセスの確認
RCUで作成した新しいスキーマ・ユーザーとしてデータベースに接続し、スキーマ・アクセスを確認します。接続にはSQL*Plusなどのユーティリティを使用し、RCUで入力した適切なスキーマ名とパスワードを指定します。
例:
./sqlplus
SQL*Plus: Release 12.1.0.2.0 Production on Wed Aug 31 05:41:31 2016
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Enter user-name: FMW1221_SOAINFRA
Enter password: soainfra_password
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Advanced Analytics and Real Application Testing options
SQL>
トランザクション・リカバリ用のSOAスキーマの構成
Oracle SOA Suiteスキーマを正常にインストールしたら、この項の手順に従ってトランザクション・リカバリのスキーマを構成します。
この手順では、WebLogic Serverが予期せずに使用不可になった後、進行中のトランザクションをリカバリする際に、Oracle WebLogic Serverトランザクション・マネージャでトランザクション状態の情報を問い合せて該当するコマンド(commitやrollbackなど)を発行できるように適切なデータベース権限を設定します。
これらの権限は、RCUでスキーマを作成したときに定義した、SOAINFRAスキーマの所有者に付与する必要があります。
トランザクション・リカバリ権限のSOAスキーマを構成する手順は次のとおりです。
Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張
次のタスクを実行して、Oracle SOA Suiteソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張します。
注意:
フットプリントを改善し起動を最適化するために、構成ウィザードのセッション後にコア・アダプタのみをSOAクラスタ(MFTを構成する場合はMFTクラスタ)にターゲット指定します。二義的なアダプタを手動でターゲット指定する必要があります(このアダプタが必要な場合)。「手動でのアダプタのターゲット指定」を参照してください。
ドメインを拡張するには、次のタスクを実行する必要があります。
- 構成ウィザードの起動
既存のエンタープライズ・デプロイメント・ドメインを拡張する最初のステップとして、構成ウィザードを起動します。 - Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート
次の各項に示す手順に従って、静的Oracle SOA Suiteまたは動的クラスタを含むOracle SOA Suiteのドメインを拡張します。 - 手動でのアダプタのターゲット指定
構成ウィザードの実行後は、コア・アダプタのみがSOAクラスタにターゲット指定されます。必要ベースで、二義的なアダプタも手動でターゲット指定する必要があります。
親トピック: Oracle SOA Suiteを含めるドメインの拡張
構成ウィザードの起動
既存のエンタープライズ・デプロイメント・ドメインを拡張する最初のステップとして、構成ウィザードを起動します。
注意:
ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverridesLate.sh
という名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のJavaコマンド行オプションの指定、追加の環境変数の指定などを実施するように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、pack
コマンドとunpack
コマンドの使用時にリモート・サーバーに継承されます。
構成ウィザードを起動する手順は次のとおりです。
Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート
次の各項に示す手順に従って、静的または動的クラスタを含むOracle SOA Suiteのドメインを拡張します。
静的クラスタを含めるドメインの拡張
この項に示す手順に従って、静的クラスタを含めてOracle SOA Suiteのドメインを拡張します。
注意:
この手順では、既存のドメインを拡張することを想定しています。手順に示された内容と要件が合わないときは、適切な内容を選択していることを確認し、その他の詳細について説明されているドキュメントを参照してください。
ドメインを作成して構成するためのタスクは次のとおりです。
- タスク1 ドメイン・タイプとドメイン・ホームの場所の選択
-
「構成タイプ」画面で、「既存ドメインの更新」を選択します。
「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。
ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください
この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。
- タスク2 構成テンプレートの選択
-
「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。
-
Oracle SOA Suite - 12.2.1.3.0 [soa]
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。
-
- タスク3 高可用性オプションの選択
-
この画面は、自動サービス移行またはJDBCストア、あるいはその両方を使用するクラスタを作成するときに初めて表示されます。クラスタのHAオプションを選択すると、構成ウィザードを使用してドメインに追加される以降のクラスタはすべて、自動的にHAオプションが適用されます(つまり、構成ウィザードによってJDBCストアが作成され、それにASMが構成される)。
「高可用性のオプション」画面で、次の手順を実行します。
-
「データベース・ベース」で、「自動サービス移行の有効化」を選択します。
-
「JTAトランザクション・ログ永続性」を「JDBC TLogストア」に設定します。
-
「JMSサーバー永続性」を「JMS JDBCストア」に設定します。
注意:
JDBCストアは、Oracleデータベースの一貫性、データ保護および高可用性の機能を活用して、クラスタのすべてのサーバーでリソースを利用できるようにすることをお薦めします。そのため、構成ウィザードの各ステップでは、JDBC永続ストアと自動サービス移行を一緒に使用すると想定しています。
JDBC永続ストアを選択すると、余分な未使用のファイル・ストアが自動的に作成されますが、クラスタをターゲットとしたものではありません。こうしたファイル・ストアは無視してください。
なんらかの理由でファイル・ストアを使用する場合、この画面ではTLOGおよびJMS永続ストアのオプションをデフォルト値のままにしておき、後から共有の場所で構成することができます。「タスク9「詳細構成の選択」」を参照してください。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。
後のステップでは、TLOGおよびJMS永続ストアを手動で構成することもできます。JDBCストアとファイル・ストアの違いや、手動で構成する具体的な手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」を参照してください。
「次」をクリックします。
-
- タスク4 データベース構成タイプの指定
-
「データベース構成タイプ」画面で、「RCUデータ」を選択します。
Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。「RCUデータ」画面で、次のことを行います。
-
「ベンダー」がOracle、「ドライバ」が*Oracle's Driver (Thin) for Service Connections; Versions: Anyであることを確認します。
-
「接続パラメータ」が選択されていることを確認します。
-
すべてのフィールドにおける資格証明が、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ドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。
-
- タスク5 JDBCコンポーネント・スキーマ情報の指定
-
「JDBCコンポーネント・スキーマ」画面で、表にあるSOAスキーマをすべて選択します。
スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。
「GridLinkへ変換」、「次へ」の順にクリックします。
- タスク6 GridLink Oracle RACデータベース接続の詳細情報の指定
-
「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。
要素 説明と推奨値 SCAN、ホスト名とポート
「SCAN」チェック・ボックスを選択します。
「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。
「ポート」フィールドには、データベースのリスニング・ポートを入力します(
1521
など)「ONSホスト」と「ポート」
「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。
「ポート」フィールドには、ONSリモート・ポートを入力します(通常は
6200
)。これらの値は、Oracle 11gデータベースに接続する際には必須で、Oracleデータベース・リリース12c以上に接続する場合はオプションです。Oracle 12cデータベースを使用している場合、ONSリストはデータベースからドライバに自動的に提供されます。
FANの有効化
データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。
- タスク7 JDBC接続のテスト
-
「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータ・ソース接続をテストします。
「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。
この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテスト関する項を参照してください。
- タスク8 キーストア
-
この画面を使用して、ドメインで使用されるキーストアの詳細を指定します。
標準的なエンタープライズ・デプロイメントの場合は、デフォルト値を残すことができます。
詳細は、構成ウィザードによるWebLogicドメインの作成のキーストアを参照してください。
- タスク9 拡張構成の選択
-
トポロジのドメイン構成を完了するには、「拡張構成」画面で「トポロジ」を選択します。
注意:
推奨はJDBCストアで、タスク3「高可用性オプションの選択」でも選択されるので、「ファイル・ストア」を構成する必要はありません。
タスク3「高可用性オプションの選択」で「ファイル・ストア」を選択した場合は、ここで「ファイル・ストア」オプションを選択し、
ORACLE_RUNTIME/domain_name/SOA_Cluster/jms
の共有場所でそれを構成する必要があります。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。 - タスク10 管理対象サーバーの構成
-
「管理対象サーバー」画面で、サーバーのリストにOracle SOA Suite用の新しい管理対象サーバーが表示されます。このサーバーは、タスク2「構成テンプレートの選択」で選択したOracle SOA Suite構成テンプレートによって自動的に作成されました。
次のタスクを実行して、デフォルトのOracle SOA Suite管理対象サーバーを変更して2つ目のOracle SOA Suite管理対象サーバーを作成します。
-
デフォルトのOracle SOA Suite管理対象サーバーの名前を
WLS_SOA1
に変更します。 -
「追加」をクリックして新しいOracle SOA Suite管理対象サーバーを作成し、それに
WLS_SOA2
という名前を付けます。ヒント:
ここで推奨するサーバー名は、このドキュメント全体で使用します。別の名前を選択する場合は、必要に応じてそれらの名前に置き換えてください。
-
次の表の情報を使用して、各Oracle SOA Suite管理対象サーバーの残りの列を入力します。
「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。
表13-1に、構成ウィザードの「管理対象サーバー」画面で各SOA管理対象サーバーに対して指定する情報を示します
サーバー名 リスニング・アドレス リスニング・ポート SSLの有効化 SSLリスニング・ポート サーバー・グループ WLS_WSM1
SOAHOST1
7010
いいえ
無効
WSMPM-MAN-SVRおよびJRF-MAN-SVR
WLS_WSM2
SOAHOST2
7010
いいえ
無効
WSMPM-MAN-SVRおよびJRF-MAN-SVR
WLS_SOA1
SOAHOST1
8001
いいえ
無効
SOA-MGD-SVRS-ONLY
WLS_SOA2
SOAHOST2
8001
いいえ
無効
SOA-MGD-SVRS-ONLY
-
- タスク11 クラスタの構成
-
このタスクでは、Oracle SOA Suiteソフトウェアのターゲットとすることができる管理対象サーバーのクラスタを作成します。
クラスタの「フロントエンド・ホスト」プロパティも設定します。これにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上の
にリダイレクトするようになります。soa.example.com
soa.example.com
仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。「クラスタ」画面を使用して、新しいクラスタを作成します。
-
「追加」ボタンをクリックします。
-
「クラスタ名」フィールドで
SOA_Cluster
を指定します。 -
「フロントエンド・ホスト」フィールドで
soa.example.com
を指定します。 -
「フロントエンドHTTPポート」に
80
を指定し、「フロントエンドHTTPSポート」に443
を指定します。 -
「動的サーバー・グループ」ドロップダウン・リストで、
未指定
を選択します。
注意:
デフォルトでは、クラスタのサーバー・インスタンスはユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。
-
- タスク12 サーバー・テンプレートの割当て
-
「次へ」をクリックして続行します。
- タスク13 動的サーバーの構成
-
静的クラスタとして残そうとするクラスタに対して、動的サーバーのすべてのオプションが無効になっていることを確認します。動的サーバーを構成するには:
-
この画面で、「動的クラスタ」、「計算済リスニング・ポート」、「計算済マシン名」の各チェック・ボックスが選択解除されていることを確認します。
-
「サーバー・テンプレート」で「未指定」が選択されていることを確認します。
-
「次」をクリックします。
-
- タスク14 クラスタへの管理対象サーバーの割当て
-
「サーバーのクラスタへの割当」画面を使用して、
WLS_SOA1
およびWLS_SOA2
を新規クラスタSOA_Cluster
に割り当てます。-
「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここでは
SOA_Cluster
)を選択します。 -
「サーバー」ペインで、次のいずれかの操作を実行して、
WLS_SOA1
をSOA_Cluster
に割り当てます。-
WLS_SOA1
管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。 -
WLS_SOA1
をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。
-
-
同じ手順を繰り返して、
WLS_SOA2
をSOA_Cluster
に割り当てます。
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のサーバーのクラスタへの割当てに関する項を参照してください。
-
- タスク15 Coherenceクラスタの構成
-
「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、
9991
のままにします。Coherenceライセンス情報については、Oracle Fusion Middlewareライセンス情報ユーザー・マニュアルのOracle Coherence製品に関する項を参照してください。
- タスク16 既存のマシンの検証
-
「次へ」をクリックします。
- タスク17 マシンへのサーバーの割当て
-
「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle SOA Suite管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。
WLS_SOA1
をSOAHOST1
に割り当て、WLS_SOA2
をSOAHOST2に割り当てます。この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のサーバーのマシンへの割当てに関する項を参照してください。
- タスク18 仮想ターゲットの構成
-
「次」をクリックします。
- タスク19 パーティションの構成
-
「次」をクリックします。
- タスク20 構成の仕様の確認とドメインの構成
-
「構成サマリー」画面には、これから拡張するドメインの構成情報の詳細が含まれています。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。
変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで、任意の画面に戻れます。
「更新」をクリックして、ドメインの拡張を実行します。
終了したら、「構成の進行状況」画面で「次へ」をクリックします。
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成のサマリーに関する項を参照してください。
- タスク21 ドメイン・ホームと管理サーバーURLのメモ
-
「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。
-
ドメインの場所
-
管理サーバーURL
どちらの項目も後で必要になるためメモしてください。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、管理サーバーのURLはWebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlへのアクセスで必要になります。
「終了」をクリックして、構成ウィザードを閉じます。
ドメイン拡張プロセスの間に管理サーバーを実行していた場合は、続行する前にサーバーを再起動します。
-
- タスク22 管理サーバーの起動
-
管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。
静的クラスタを含めるドメインの拡張を完了したら、「手動でのアダプタのターゲット指定」に進みます。
動的クラスタを含めるドメインの拡張
この項に示す手順に従って、動的クラスタを含めてOracle SOA Suiteのドメインを拡張します。
注意:
この手順では、既存のドメインを拡張することを想定しています。手順に示された内容と要件が合わないときは、適切な内容を選択していることを確認し、その他の詳細について説明されているドキュメントを参照してください。
ドメインを作成して構成するためのタスクは次のとおりです。
- タスク1 ドメイン・タイプとドメイン・ホームの場所の選択
-
「構成タイプ」画面で、「既存ドメインの更新」を選択します。
「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、初期ドメイン作成時に作成した管理サーバー・ドメイン・ホームの完全なパスを表します。
MSERVER_HOME変数の値は入力しないでください。これは、管理対象サーバー・ドメイン・ディレクトリの場所を表します。
ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください
ヒント:
この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。
- タスク2 構成テンプレートの選択
-
「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。
-
Oracle SOA Suite - 12.2.1.3.0 [soa]
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。
-
- タスク3 高可用性オプションの選択
-
この画面は、自動サービス移行またはJDBCストア、あるいはその両方を使用するクラスタを作成するときに初めて表示されます。クラスタのHAオプションを選択すると、構成ウィザードを使用してドメインに追加される以降のクラスタはすべて、自動的にこれらのHAオプションが適用されます。
「高可用性のオプション」画面で、次のステップを実行します。
-
「自動サービス移行の有効化」が選択されていないことを確認します。
-
「デフォルトの永続ストア」が「JTAトランザクション・ログ永続性」オプションに設定されていることを確認します。
-
「JMSサーバー永続性」オプションとして、「JDBCストア」を選択します。
構成ウィザードを使用して動的クラスタに構成できるのは、JMSサーバー永続性のみです。この構成ウィザードを使用して、動的クラスタのサービス移行およびJTAトランザクション・ログ永続性を構成することはできません。これらは手動で構成する必要があります。手順は、このガイドで後述します。
注意:
JDBCストアは、Oracleデータベースの一貫性、データ保護および高可用性の機能を活用して、クラスタのすべてのサーバーでリソースを利用できるようにすることをお薦めします。そのため、構成ウィザードの各ステップでは、JDBC永続ストアと自動サービス移行を一緒に使用すると想定しています。
JDBC永続ストアを選択すると、余分な未使用のファイル・ストアが自動的に作成されますが、クラスタをターゲットとしたものではありません。こうしたファイル・ストアは無視してください。
なんらかの理由でファイル・ストアを使用する場合、この画面ではTLOGおよびJMS永続ストアのオプションをデフォルト値のままにしておき、後から共有の場所で構成することができます。「タスク9「詳細構成の選択」」を参照してください。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。
後のステップでは、TLOGおよびJMS永続ストアを手動で構成することもできます。JDBCストアとファイル・ストアの違いや、手動で構成する具体的な手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」を参照してください。
「次」をクリックします。
-
- タスク4 データベース構成タイプの指定
-
「データベース構成タイプ」画面で、「RCUデータ」を選択します。
Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。「RCUデータ」画面で、次のことを行います。
-
「ベンダー」がOracle、「ドライバ」が*Oracle's Driver (Thin) for Service Connections; Versions: Anyであることを確認します。
-
「接続パラメータ」が選択されていることを確認します。
-
すべてのフィールドにおける資格証明が、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ドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。
-
- タスク5 JDBCコンポーネント・スキーマ情報の指定
-
「JDBCコンポーネント・スキーマ」画面で、表にあるSOAスキーマをすべて選択します。
スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。
「GridLinkへ変換」をクリックし、「次へ」をクリックします。
- タスク6 GridLink Oracle RACデータベース接続の詳細情報の指定
-
「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。
要素 説明と推奨値 SCAN、ホスト名とポート
「SCAN」チェック・ボックスを選択します。
「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。
「ポート」フィールドには、データベースのリスニング・ポートを入力します(
1521
など)「ONSホスト」と「ポート」
「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。
「ポート」フィールドには、ONSリモート・ポートを入力します(通常は
6200
)。これらの値は、Oracle 11gデータベースに接続する際には必須で、Oracleデータベース・リリース12c以上に接続する場合はオプションです。Oracle 12cデータベースを使用している場合、ONSリストはデータベースからドライバに自動的に提供されます。
FANの有効化
データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。
- タスク7 JDBC接続のテスト
-
「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。
「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。
ヒント:
この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテスト関する項を参照してください。
- タスク8 キーストア
-
この画面を使用して、ドメインで使用されるキーストアの詳細を指定します。
標準的なエンタープライズ・デプロイメントの場合は、デフォルト値を残すことができます。
詳細は、構成ウィザードによるWebLogicドメインの作成のキーストアを参照してください。
- タスク9 拡張構成の選択
-
トポロジのドメイン構成を完了するには、「拡張構成」画面で「トポロジ」を選択します。
注意:
推奨はJMS JDBCストアで、タスク3「高可用性オプションの選択」でも選択されるので、「ファイル・ストア」を構成する必要はありません。
タスク3「高可用性オプションの選択」で「JMSファイル・ストア」を選択した場合は、「ファイル・ストア」オプションを選択し、
ORACLE_RUNTIME/domain_name/SOA_Cluster/jms
の共有場所でそれを構成する必要があります。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。 - タスク10 管理対象サーバーの構成
-
「管理対象サーバー」画面で、サーバーのリストにOracle SOA Suite用の新しい管理対象サーバーが表示されます。このサーバーは、タスク2「構成テンプレートの選択」で選択したOracle SOA Suite構成テンプレートによって自動的に作成されました。
動的クラスタ構成には、SOA静的管理対象サーバーの定義は必要ありません。デフォルトの管理対象サーバーを削除するには、次のステップを実行します。
-
「管理対象サーバー」をクリックして、「削除」をクリックします。
-
「次」をクリックします。
-
- タスク11 クラスタの構成
-
このタスクでは、Oracle SOA Suiteソフトウェアのターゲットとすることができる管理対象サーバーのクラスタを作成します。
クラスタの「フロントエンド・ホスト」プロパティも設定します。これにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上の
にリダイレクトするようになります。soa.example.com
soa.example.com
仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。「クラスタ」画面を使用して、新しいクラスタを作成します。
-
「追加」ボタンをクリックします。
-
「クラスタ名」フィールドで
SOA_Cluster
を指定します。 -
「フロントエンド・ホスト」フィールドで
soa.example.com
を指定します。 -
「フロントエンドHTTPポート」に
80
を指定し、「フロントエンドHTTPSポート」に443
を指定します。 -
「動的サーバー・グループ」ドロップダウン・リストで、
SOA-DYN-CLUSTER-ONLY
を選択します。
注意:
デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。
-
- タスク12 サーバー・テンプレートの割当て
-
テンプレートを構成するには、次のステップを実行します。
-
「名前」フィールドで
soa-server-template
が選択されていることを確認します。 -
「リスニング・ポート」フィールドで、
8000
を指定します。 -
「SSLの有効化」オプションは未選択のままにしておきます。
-
「次」をクリックします。
-
- タスク13 動的サーバーの構成
-
「動的クラスタ」画面を使用して、必要なクラスタを構成します。
-
「クラスタ名」フィールドに
SOA_Cluster
がリストされていることを確認します。 -
「サーバー名の接頭辞」フィールドで、
WLS_SOA
を指定します。 -
「サーバー・テンプレート」ドロップダウン・リストで、
soa-server-template
を選択します。 -
「動的クラスタ・サイズ」フィールドに
2
を指定します。 -
「マシン名マッチング式」フィールドで
SOAHOST*
を指定し、「計算済マシン名」を選択します。注意:
動的クラスタの「計算済マシン名」および「マシン名マッチング式」属性は、動的クラスタ内のサーバー・インスタンスをマシンに割り当てる方法を制御します。「計算済マシン名」属性がFalseに設定されている場合、動的サーバーはマシンに割り当てられません。「計算済マシン名」属性が「true」に設定されている場合は、「マシン名マッチング式」属性を使用して、動的クラスタに使用される一連のマシンが選択されます。「マシン名マッチング式」属性が設定されていない場合、ドメイン内のすべてのマシンが選択されます。割当は、ラウンド・ロビン・アルゴリズムを使用して行われます。
作業が簡単になるように、実際の物理的なホスト名とは関係なくWebLogicのマシン名としてSOAHOSTnを使用することをお薦めします。このnは連番です。これについては、インフラストラクチャ・ドメインの構成に関するタスク18「マシンの作成」で説明しています。この規則によって、動的クラスタは各クラスタ・メンバーをどこで起動するかを決定しやすくなっています。この規則に従う場合は、「マシン・マッチング式」フィールドに「
SOAHOST*
」と入力します。この規則に従わない場合、クラスタ・メンバーはタスク18「マシンの作成」で定義する各マシンで起動します。これには、ADMINHOSTも含まれます。この状況は、2つのクラスタ・メンバーが同じ物理サーバー上で動作するが2つの異なるドメイン・ホームにアタッチされる結果となるため、望ましくありません。
-
「計算済リスニング・ポート」 フィールドと「動的クラスタ」フィールドを選択します。
注意:
「計算済リスニング・ポート」オプションが選択された動的クラスタの場合、自動的に作成される動的管理対象サーバーごとに増分でポート番号が割り当てられます。つまり、動的サーバー1にはリスニング・ポート+1、動的サーバー2にはリスニング・ポート+2が使用されます。
構成済のリスニング・ポートは8000で、計算済のポートがチェックされるので、SOA動的サーバーは次のポート番号を使用します。
-
WLS_SOA1サーバーは、ポート8001でリスニングします
-
WLS_SOA2サーバーは、ポート8002でリスニングします
-
-
「次」をクリックします。
注意:
構成ウィザードで、動的サーバーに対して特定のリスニング・アドレスを指定することはできません。動的クラスタのメンバーであるWebLogicサーバーへの特定リスニング・アドレスの設定については、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。
-
- タスク14 Coherenceクラスタの構成
-
「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、
9991
のままにします。注意:
Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle Coherence製品に関する項を参照してください。
- タスク15 既存のマシンの検証
-
「次」をクリックします。
- タスク16 マシンへのサーバーの割当て
-
「次」をクリックします。
- タスク17 仮想ターゲット
-
「次」をクリックします。
- タスク18 パーティション
-
「次」をクリックします。
- タスク19 構成の仕様の確認とドメインの構成
-
「構成サマリー」画面には、これから拡張するドメインの構成情報の詳細が含まれています。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。
変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで、任意の画面に戻れます。
「更新」をクリックして、ドメインの拡張を実行します。
終了したら、「構成の進行状況」画面で「次へ」をクリックします。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。
- タスク20 ドメイン・ホームと管理サーバーURLのメモ
-
「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。
-
ドメインの場所
-
管理サーバーURL
どちらの項目も後で必要になるためメモしてください。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、管理サーバーのURLはWebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlへのアクセスで必要になります。
「終了」をクリックして、構成ウィザードを閉じます。
ドメイン拡張プロセスの間に管理サーバーを実行していた場合は、続行する前にサーバーを再起動します。
-
- タスク21 管理サーバーの起動
-
管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。
手動でのアダプタのターゲット指定
構成ウィザードの実行後は、コア・アダプタのみがSOAクラスタにターゲット指定されます。必要ベースで、二義的なアダプタも手動でターゲット指定する必要があります。
注意:
これらのアダプタの一部は、デフォルトのインストールでは使用できないことがあります。使用可能なアダプタについてはOracle Technology Networkを参照してください。-
MSMQAdapter
-
SocketAdapter
-
OracleBamAdapter
-
CoherenceAdapter
-
SAPAdapter
-
SiebelAdapter
-
ERPAdapter
-
Oracle SalesCloudAdapter
-
RightNowAdapter
-
EloquaAdapter
-
NetSuiteAdapter
-
LdapAdapter
-
JDEWorldAdapter
二義的なアダプタを手動でターゲット指定するには:
ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
Oracle SOA Suiteインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリとマシンに伝播する必要があります。
表13-2は、変更をすべてのドメイン・ディレクトリとマシンに伝播するために必要なステップをまとめたものです。
更新済ドメインをWEBHOST1およびWEBHOST2マシンに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。
表13-2 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー
タスク | 説明 | 詳細情報 |
---|---|---|
SOAHOST1での拡張済ドメインの圧縮 |
ドメインを圧縮する際には、 |
|
SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍 |
SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。 |
|
SOAHOST2でのドメインの解凍 |
SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。 |
- SOAHOST1での拡張済ドメインの圧縮
- SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍
- SOAHOST2でのドメインの解凍
親トピック: Oracle SOA Suiteを含めるドメインの拡張
SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍
更新したドメイン構成情報を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播する手順は次のとおりです。
SOAHOST2でのドメインの解凍
この手順では、以前に作成したファイルを、SOAHOST1とSOAHOST2の両方からアクセスできる場所(たとえば、共有記憶域ファイラ上のASERVER_HOMEディレクトリなど)にコピー済であることを想定しています。
-
SOAHOST2にログインします
-
まだ作成していない場合は、SOAHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。
「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。
-
SOAHOST2から
soadomaintemplate.jar
にアクセスできることを確認します。たとえば、SOAHOST2に別の共有記憶域ボリュームまたはパーティションを使用している場合は、SOAHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。
-
次のように
unpack
コマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=MSERVER_HOME \ -overwrite_domain=true \ -template=/full_path/
soadomaintemplate.jar
\ -log_priority=DEBUG \ -log=/tmp/unpack.log \ -app_dir=APPLICATION_HOME注意:
unpackコマンドで
-overwrite_domain
オプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。また、ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、
setUserOverridesLate.sh
というファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のJAVAコマンドライン・オプションの指定、追加の環境変数の指定などを行うよう構成できます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。この例では、次のようになります。
-
MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。
-
/full_path/
を、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。soadomaintemplate.jar
-
APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。
ヒント:
packおよびunpackコマンドの詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』の「PackおよびUnpackコマンドの概要」を参照してください。
-
-
ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがSOAHOST2のローカル記憶域デバイス上の適切な場所にコピーされていることを確認します。
WLS_SOA1管理対象サーバーの起動と検証
これでドメインの拡張、管理サーバーの起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle SOA Suite管理対象サーバーを起動できます。
このプロセスには、次の各項で説明する3つのタスクが含まれます。
親トピック: Oracle SOA Suiteを含めるドメインの拡張
AdministratorsグループへのSOAAdminロールの追加
WLS _SOA1管理対象サーバーのOracle SOA Suite構成を検証する前に、SOAAdmin
管理ロールをエンタープライズ・デプロイメント管理グループ(SOA Administrators
)に追加します。
このタスクを実行するには、「エンタープライズ・デプロイメントの管理用のロールの構成」を参照してください。
親トピック: WLS_SOA1管理対象サーバーの起動と検証
SOAインフラストラクチャへのログインによる管理対象サーバーの検証
SOAAdmin
ロールをSOA Administratorsグループに追加した後、次のようにWLS_SOA1管理対象サーバーのOracle SOA Suiteソフトウェアの構成を検証できます。
親トピック: WLS_SOA1管理対象サーバーの起動と検証
WLS_SOA2管理対象サーバーの起動と検証
WLS_SOA1管理対象サーバーが正常に構成され起動されたことを確認したら、WLS_SOA2管理対象サーバーを起動して検証できます。
WLS_SOA2管理対象サーバーを起動して検証するには、WLS_SOA2管理対象サーバーに対して「WLS_SOA1管理対象サーバーの起動および検証」の手順を使用します。
URLの検証のために、Webブラウザに次のURLを入力し、エンタープライズ・デプロイメント管理者ユーザー資格証明(weblogic_soa
)を使用してログインします。
http://SOAHOST2:8001/soa-infra/
http://SOAHOST2:8002/soa-infra/
親トピック: Oracle SOA Suiteを含めるドメインの拡張
uploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。「エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更」を参照してください。
親トピック: Oracle SOA Suiteを含めるドメインの拡張
動的クラスタを使用する際のリスニング・アドレスの構成
動的クラスタにおける動的な管理対象サーバーのデフォルト構成では、使用可能なネットワーク・インタフェースすべてでリスニングするようになっています。ほとんどの場合、デフォルトの構成では不適切です。動的クラスタを使用する際に、リスニング・アドレスを特定のアドレスに限定するには、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。前の項でリスニング・アドレスを変更したときに指定されたテストURLを再確認し、クラスタ化された管理対象サーバーを再起動します。
親トピック: Oracle SOA Suiteを含めるドメインの拡張
拡張したドメイン用のWeb層の構成
Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをインスタンスでルーティングできるようにします。
考えられるスケールアウト・シナリオの準備での追加のステップは、クロス・コンポーネント・ワイヤリング情報の更新を参照してください。
- 拡張したドメイン用のOracle Traffic Directorの構成
- WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成
- WebLogicプロキシ・プラグインの構成
- ロード・バランサを使用したOracle SOA Suite URLの検証
親トピック: Oracle SOA Suiteを含めるドメインの拡張
拡張したドメイン用のOracle Traffic Directorの構成
このドメインでOracle Traffic Directorを構成した場合、状況によっては、Oracle Traffic Director構成に別のオリジン・サーバー・プール、仮想サーバーまたはルートを追加する必要があります。各Oracle Fusion Middleware製品のOracle Traffic Directorの要件を理解するための情報と、オリジン・サーバー・プール、仮想サーバーおよびルートを追加する手順は、エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義を参照してください。
親トピック: 拡張したドメイン用のWeb層の構成
WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成
Oracle SOA Suiteクラスタにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、soa.example.com
仮想サーバーのパラメータを作成して定義するOracle HTTP Server構成ファイルを追加作成します。
この手順では、「リクエストをアプリケーション層にルーティングするようにOracle HTTP Serverを構成」で説明されているOracle HTTP Server構成タスクが実行済であることを想定しています。
リクエストがOracle SOA Suiteクラスタに正しくルーティングされるように仮想ホスト構成ファイルを作成する手順は、次のとおりです。
例13-1 soa_vh.conf
ファイル
<VirtualHost WEBHOST1:7777>
ServerName https://soa.example.com
:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
<Location /soa-infra>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# SOA inspection.wsil
<Location /inspection.wsil>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Worklist
<Location /integration>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# UMS prefs
<Location /sdpmessaging/userprefs-ui>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
WLSRequest ON
WebLogicCluster SSOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Workflow
<Location /workflow>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# SOA composer application
<Location /soa/composer>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>
注意:
システムで内部呼出しを使用する場合は、soainternal仮想ホストに適切なロケーションを追加してください。
親トピック: 拡張したドメイン用のWeb層の構成
WebLogicプロキシ・プラグインの構成
リクエストがOracle HTTP ServerまたはOracle Traffic Directorインスタンスを介して正しくルーティングされたことを検証するには、先ほど構成したクラスタに対して「WebLogicプラグインの有効化」
パラメータを設定しておく必要があります。WebLogicプロキシ・プラグインを構成する手順は、次のとおりです。
親トピック: 拡張したドメイン用のWeb層の構成
ロード・バランサを使用したOracle SOA Suite URLの検証
Oracle HTTP Server仮想ホストの構成を検証し、ハードウェア・ロード・バランサがOracle HTTP Serverインスタンスを経由してアプリケーション層にリクエストをルーティングできることを確認する手順は次のとおりです。
親トピック: 拡張したドメイン用のWeb層の構成
Oracle SOA Suiteの構成後ステップ
Oracle SOA Suiteをインストールして構成した後、次のような構成後タスクを検討します。
- Oracle SOA Suite用のOracleアダプタの構成
- SOAサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化
- SOAクラスタ内の同期/非同期相互作用に関する考慮事項
- FusionAppsFrontendHostUrlの更新
親トピック: Oracle SOA Suiteを含めるドメインの拡張
Oracle SOA Suite用のOracleアダプタの構成
開発しているOracle SOA Suiteアプリケーションで、Oracle SOA Suite用のOracleアダプタのいずれかを利用する場合、それらのアダプタがエンタープライズ・トポロジで効率的かつセキュアに機能するように構成されていることを確認します。
詳細は、次の各項を参照してください。
親トピック: Oracle SOA Suiteの構成後ステップ
OracleファイルとFTPアダプタの高可用性化
開発またはデプロイするOracle SOA Suiteアプリケーションで、OracleファイルおよびFTPアダプタを必要とする場合、エンタープライズ・デプロイメント・トポロジで高可用性が得られるようにそれらのアダプタを構成する必要があります。
次の各項を使用してこのタスクを完了します。
OracleファイルおよびFTPアダプタ構成の理解
OracleファイルおよびFTPアダプタを使用すると、プライベート・ファイル・システムやリモート・ファイル・システム上のファイルをFTP(ファイル転送プロトコル)を使用してBPELプロセスまたはOracle Mediatorで読取りまたは書込みできるようになります。
適切に構成した場合、これらのアダプタは、Oracle BPEL Process ManagerおよびOracle Mediatorサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能を、インバウンドおよびアウトバウンドの両方の操作でサポートします。
このタスクの一般情報は、テクノロジ・アダプタの理解のOracleファイルおよびFTPアダプタの構成に関する項を参照してください。ここで説明する手順は、Oracle SOA Suiteエンタープライズ・デプロイメントに固有のものです。
注意:
ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。
親トピック: OracleファイルとFTPアダプタの高可用性化
管理コンソールでのOracleファイル・アダプタの構成
Oracleファイル・アダプタの高可用性を実現するには、最初に、eis/HAFileAdapter
に対応するconnection-instanceのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。
このタスクは、Oracle WebLogic Serverコンソールから実行できます。
-
Oracle WebLogic Server管理コンソールに移動してログインします。
例:
http://ADMINVHN:7001/console
注意:
Web層がすでに構成されている場合は、
http://admin.example.com/console
を使用します。 -
管理コンソールの左ペインで、「デプロイメント」をクリックします。
-
「デプロイメントのサマリー」表でFileAdapterリソース・アダプタを見つけます。
-
「FileAdapter」をクリックし、「FileAdapterの設定」ページを表示します。
-
「構成」をクリックします。
-
「アウトバウンド接続プール」をクリックします。
-
javax.resource.cci.ConnectionFactoryを開き、構成済の接続ファクトリを表示します。
-
「eis/HAFileAdapter」をクリックします。
接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。
-
「ロックして編集」をクリックします。
プロパティ値の列が編集可能になります(「プロパティ値」列の任意の行をクリックしてその値を変更できます)。
-
表13-3に示されている値を入力します。
注意:
controlDirを更新し、その他の値を、表13-3に示されているデフォルト値と照合します。
表13-3 javax.resource.cci.Connectionfactoryに入力する値
パラメータ 説明 controlDir
制御ファイルを格納するディレクトリを入力します。1つのクラスタ内で複数のWebLogic Serverインスタンスを実行する場合は、共有の場所に設定する必要があります。この共有記憶域のディレクトリは次のような構造にします。
ORACLE_RUNTIME/domain_name/cluster_name/fadapter
inboundDataSource
値を
jdbc/SOADataSource
に設定します。outboundDataSource
値を
jdbc/SOADataSource
に設定します。outboundDataSourceLocal
値を
jdbc/SOALocalTxDataSource
に設定します。これは、高可用性に対応するスキーマが事前作成されるデータ・ソースです。outboundLockTypeForWrite
Oracle Databaseを使用している場合は、この値を
oracle
に設定します。デフォルトでは、OracleファイルとFTPアダプタはインメモリーmutexを使用してアウトバウンドの書込み操作をロックします。書込み操作を同期化するには、次の値のいずれかを選択する必要があります。-
memory
: OracleファイルとFTPアダプタはメモリー内mutexを使用してファイル・システムへのアクセスを同期化します。 -
oracle
: アダプタは、Oracle Databaseシーケンスを使用します。 -
db
: アダプタは事前作成されたデータベース表(FILEADAPTER_MUTEX
)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用している場合にのみ使用します。 -
user-defined
: アダプタはユーザー定義のmutexを使用します。ユーザー定義mutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutex
を実装し、アウトバウンド参照のmutexの完全修飾クラス名として名前oracle.tip.adapter.file.mutex
および値を指定して新規バインディング・プロパティを構成する必要があります。
workingDirectory
このデフォルト値を保持します。
-
-
これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。
-
DEPLOY_PLAN_HOMEディレクトリを作成します。
mkdir -p DEPLOY_PLAN_HOME/
soaedg_domain
この例では、DEPLOY_PLAN_HOMEを、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されているデプロイメント・プラン・ディレクトリの実際のパスに置き換えます。
-
デプロイメント・プランのパス値に共有記憶域の場所を入力します。そのディレクトリ構造は次のとおりです。
DEPLOY_PLAN_HOME/
soaedg_domain
/FileAdapterPlan.xml -
「OK」をクリックして、記憶域の場所を削除します。
-
「保存」をクリックしてファイル・アダプタへの変更を保存して、「変更のアクティブ化」をクリックしてファイル・アダプタに変更を適用します。
-
コンソールでデプロイメントを更新します。
-
「デプロイメント」をクリックします。
-
「ロックして編集」.をクリックします
-
ファイル・アダプタのデプロイメントに対応するチェック・ボックスを選択します。
-
「更新」をクリックします。
-
オプションの「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します(このオプションには、デプロイメント・プランを指定する必要があります)。」を選択します。
-
「パスの変更」ボタンをクリックして、共有記憶域の場所へのパスからFileAdapterPlan.xmlファイルを選択します。
-
「終了」をクリックします。
-
変更をアクティブ化します。
-
-
FileAdapterデプロイメントがアクティブ化されて稼働中であることを確認します。
-
管理コンソールの左ペインで、「デプロイメント」をクリックします。
-
「デプロイメント」表のFileAdapterデプロイメントを見つけます。
-
アクティブな状態でない場合には、「デプロイメントのサマリー」で「制御」タブをクリックし、「デプロイメント」で「FileAdapter」を選択します。「開始」→「すべてのリクエストを処理」を選択します。
-
「はい」をクリックします。
-
親トピック: OracleファイルとFTPアダプタの高可用性化
コンポジット・アプリケーション内でのJCAファイルの編集
管理コンソールでFileAdapterデプロイメントを構成したら、例13-2に示すように、デプロイするコンポジット・アプリケーションに含まれている.jcaファイルを編集し、それらが前のステップで構成した接続ファクトリを使用できるようにすることができます。
注意:
接続ファクトリの位置属性は、eis/HAFileAdapter
に設定されています。
例13-2 エンタープライズ・デプロイメント用のファイル・アダプタ.JCAファイルの変更の例
<adapter-config name="FlatStructureOut" adapter="File Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata"> <connection-factory location="eis/HAFileAdapter" adapterRef=""/> <endpoint-interaction portType="Write_ptt" operation="Write"> <interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec"> <property../> <property../> </interaction-spec> </endpoint-interaction> </adapter-config>
親トピック: OracleファイルとFTPアダプタの高可用性化
Oracle FTPアダプタの構成
アプリケーションでFTPアダプタが必要な場合、「管理コンソールでのOracle File Adapterの構成」および「コンポジット・アプリケーション内でのJCAファイルの編集」の各手順を繰り返します(ただし、次の点が異なります)。
-
管理コンソールのデプロイメントのリストで「FtpAdapter」デプロイメントを探します。
-
「FtpAdapter」をクリックすると、FtpAdapterページの「設定」が表示されます。
-
「構成」をクリックします。
-
「アウトバウンド接続プール」をクリックします。
-
javax.resource.cci.ConnectionFactoryを開き、構成済の接続ファクトリを表示します。
-
eis/Ftp/HAFtpAdapterをクリックします。
接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。
-
「ロックして編集」をクリックします。
-
アダプタのプロパティを高可用性用に変更します。表13-3を参照してください。
-
次の場所を指すように、ControlDirプロパティを更新します。
ORACLE_RUNTIME/domain_name/cluster_name/ftpadapter
-
デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。
DEPLOY_PLAN_HOME/
soaedg_domain
/FtpAdapterPlan.xml
親トピック: OracleファイルとFTPアダプタの高可用性化
Oracle JMSアダプタの高可用性化
Oracle JMSアダプタがクラスタ内の複数のサーバーと通信する場合、アダプタの通信ファクトリのプロパティFactoryProperties
に使用可能なサーバーがリストされている必要があります。サーバーがリストされない場合、ランダムな1台のサーバーのみと接続が確立されます。そのサーバーが停止しても、追加のメッセージは処理されません。
この問題を回避するために、メンバーの静的リストを使用するかわりに、アダプタのFactoryProperties
でクラスタ名構文を使用できます。クラスタ名構文は、次のとおりです。
cluster:t3://cluster_name
cluster:t3://cluster_name
を使用すると、この呼び出しによって任意の時点でクラスタに存在するメンバーの完全なリストがフェッチされるため、初期サーバーへの依存性が回避され、その時点でクラスタ内の有効なすべてのメンバーが判明します。このクラスタ構文は、クラスタが同じドメイン内に存在する場合にのみ使用できる点に注意してください。
アダプタのJCA接続ファクトリを変更するには:
-
次のURLを使用して、Oracle WebLogic Server管理コンソールにログインします。
http://ADMINVHN:7001/console
注意:
Web層がすでに構成されている場合は、
http://admin.example.com/console
を使用します。 -
「ドメイン構造」の左ペインで「デプロイメント」をクリックします。
-
右ペインの「デプロイメントのサマリー」でJmsAdapterをクリックします。
-
「構成」タブをクリックします。
-
「アウトバウンド接続プール」タブをクリックして
oracle.tip.adapter.jms.IJmsConnectionFactory
を開き、構成済の接続ファクトリを表示します。 -
「ロックして編集」をクリックします。
-
使用中の特定のインスタンス(例:
eis/wls/Queue
)をクリックします。接続ファクトリの「アウトバウンド接続のプロパティ」が開きます。 -
「FactoryProperties」フィールドで(「プロパティ」値の下の対応するセルをクリック)、次のように入力します。セミコロンで区切ってすべてを1行に入力してください。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory; java.naming.provider.url=cluster:t3://SOA_Cluster; java.naming.security.principal=weblogic; java.naming.security.credentials=<password>
-
これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。
-
(初回のみ)デプロイメント・プランの共有記憶域の場所を入力します。そのディレクトリ構造は次のとおりです。
DEPLOY_PLAN_HOME/
soaedg_domain
/JMSAdapterPlan.xml -
「OK」をクリックして、更新した記憶域パスをコミットします。
-
「保存」をクリックします。
-
「変更のアクティブ化」をクリックします。
-
コンソールでデプロイメントを更新します。
-
「デプロイメント」をクリックします。
-
「ロックして編集」をクリックします。
-
JMSアダプタに対応するチェック・ボックスを選択します。
-
「更新」をクリックします。
-
「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します(このオプションには、デプロイメント・プランを指定する必要があります)。」を選択し、共有記憶域の場所に保存されたデプロイメント・プランを選択します。クラスタ内のすべてのサーバーは、このプランにアクセスできる必要があります。
-
「終了」をクリックします。
-
変更をアクティブ化します。
-
Oracle Databaseアダプタの高可用性の有効化
Oracle Databaseアダプタを利用しながら高可用性を確保するために、通常は、物理削除より高速な論理削除ポーリング方式が使用されます。しかし、複数のノードが同じデータをポーリングするクラスタ化環境では、1つのレコードが複数回処理されることがあります。この問題を回避するために、Oracle Databaseアダプタでは、「ロックのスキップ」と呼ばれるOracle Database機能を使用する分散ポーリング技術を使用します。
以前に論理削除ポーリング方式のアプローチを使用していた場合は、MarkReservedValue
を(db.jca
内で)削除するか、(ウィザードの「論理削除」ページで)消去できます。それによってロックが自動的にスキップされるようになります。
予約された値に対してロックのスキップを使用することには、次のような利点があります。
-
ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。
-
(更新/予約の次にコミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。
-
一意のMarkReservedValueを指定する必要がありません。以前は、そのようにするためには、
R${weblogic.Name-2}-${IP-2}-${instance}
のように、複雑な変数を構成することが必要でした。
論理削除ポーリングを使用していて、MarkReservedValue
を設定している場合は、ロックのスキップは使用されません。
詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティとポーリング戦略に関する項を参照してください。
SOAサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化
Oracle SOA Suiteを含めてドメインを拡張した後、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認する必要もあります。
これにより、SOAコンポジット・アプリケーションとWebサービスが、フロントエンドのセキュアURLとのコールバックやその他の通信を開始できるようになります。「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」を参照してください。
親トピック: Oracle SOA Suiteの構成後ステップ
SOAクラスタ内の同期/非同期相互作用に関する考慮事項
SOAクラスタでは、次のシナリオはサポートされていません。
-
mid-process receiveを持つ同期BPELプロセス
-
非同期サービスをコールする同期BPELプロセス。
-
同期プロセスからのコールバック。
親トピック: Oracle SOA Suiteの構成後ステップ
FusionAppsFrontendHostUrlの更新
適切なURLを構成する手順は次のとおりです。
親トピック: Oracle SOA Suiteの構成後ステップ
Oracle SOA Suiteに対するJDBC永続ストアの有効化
JDBCストアは、Oracleデータベースの一貫性、データ保護および高可用性の機能を活用して、クラスタのすべてのサーバーでリソースを利用できるようにすることをお薦めします。
静的クラスタまたは動的クラスタを使用するときには、次のガイドラインに従って確実にJDBCストアを使用してください。
-
静的クラスタの場合
このガイドで静的クラスタに対してお薦めしたように、「高可用性のオプション」画面で、次のとおりに選択した場合は、すでにJMSとTLOGSの両方のJDBC永続ストアが構成されています。
-
「JTAトランザクション・ログ永続性」を「JDBC TLogストア」に設定します。
-
「JMSサーバー永続性」を「JMS JDBCストア」に設定します。
-
-
動的クラスタの場合
構成ウィザードを使用して動的クラスタに構成できるのは、JMSサーバー永続性のみです。JTAトランザクション・ログ永続性は手動で構成する必要があります(この永続性が必要な場合)。このガイドで動的クラスタに対してお薦めしたように、「高可用性のオプション」画面で、次のとおりに選択した場合は、すでにJMSのJDBC永続ストアが構成されています。
-
「JMSサーバー永続性」を「JMS JDBCストア」に設定します。
-
「JTAトランザクション・ログ永続性」が「デフォルトの永続ストア」に設定されていることを確認します。
JDBCストアにJTAトランザクション・ログを構成するには追加のステップが必要になります。「TLOG用のJDBC永続ストア構成のロードマップ」を参照してください。
-
「高可用性のオプション」画面でJMSとTLOGSの永続のためにJDBCを選択していなかった場合は、その後のステップでJDBCストアを手動で構成することもできます。手動で構成する際の具体的な手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。
注意:
「高可用性のオプション」画面は、自動サービス移行とJDBCストアの両方またはどちらかを使用するクラスタを初めて作成するときに、構成ウィザードのセッション中に表示されます。それ以降、構成ウィザードを使用してドメインに追加されるクラスタには、選択済のHAオプションが自動的に適用されます。
親トピック: Oracle SOA Suiteを含めるドメインの拡張
Oracle SOA Suiteに対する自動サービス移行の有効化
この章でインストールした製品の高可用性を実現するには、適切にサービス移行を構成する必要があります。
静的クラスタまたは動的クラスタを使用する際には、次のガイドラインに従ってWebLogicサービスに必要な高可用性が指定されていることを確認してください。
-
静的クラスタの場合
「高可用性のオプション」画面の「データベース・ベース」で「自動サービス移行の有効化」選択した場合、自動サービス移行はすでに構成されています。
データベース・リースはすでに構成されていて、移行可能ターゲットはクラスタの適切なポリシーで作成されます。この設定が実施済の場合は、構成を検証します。検証の詳細は、「静的クラスタでの自動サービス移行の検証」を参照してください。
構成ウィザードのセッション中に、このオプションを選択していない場合でも、その後のステップで自動移行を手動で構成できます。静的クラスタの場合の完全なステップについては、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。
-
動的クラスタの場合
この構成ウィザードを使用して動的クラスタのサービス移行を構成することはできません。手動で構成する必要があります。次のステップを実行する必要があります。
-
クラスタのデータベース・リースを構成します。
-
JTAサービスとJMS永続ストアに適切な移行ポリシーを設定します。
動的クラスタの場合の完全なステップについては、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。
-
注意:
「高可用性のオプション」画面は、自動サービス移行とJDBCストアの両方またはどちらかを使用するクラスタを初めて作成するときに、構成ウィザードのセッション中に表示されます。それ以降、構成ウィザードを使用してドメインに追加されるクラスタには、選択済のHAオプションが自動的に適用されます。
親トピック: Oracle SOA Suiteを含めるドメインの拡張
構成のバックアップ
Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。
バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。
親トピック: Oracle SOA Suiteを含めるドメインの拡張