14 Oracle Service Busを含めるドメインの拡張

この章で説明する手順では、Oracle Service Bus (OSB)を追加してエンタープライズ・デプロイメント・トポロジを拡張するプロセスを示します。

Oracle Service Busの独自のドメインでの構成について

Oracle Service Bus (OSB)をエンタープライズ・トポロジに追加する際、既存のSOAドメインに追加することも、Oracle SOA Suiteドメインとは別にOSB用の新たなドメインを作成することもできます。

OSBトポロジの詳細は、「Oracle Service Busのトポロジ・オプションについて」を参照してください。

Oracle Service Busを別個のドメイン内に構成すると決定した場合、トポロジにOracle Service Busを追加する手順を使用する際に、次の点に留意してください。

  • SOA管理対象サーバーまたはSOAクラスタへの参照はすべて無視してください。ドメインのこれらの要素が存在するのは、Oracle SOA Suiteを含めることですでに拡張されたドメインを拡張する場合のみです。

  • RCUを実行して、Oracle Service BusドメインのSOAINFRAスキーマを作成する必要があります。このスキーマは、Oracle Service Busで必要とされます。Oracle Service Busドメインには、一意のSOAINFRAスキーマとスキーマ接頭辞を使用する必要があります。

  • 「Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート」での説明に従って、構成ウィザードを実行すると、「高可用性のオプション」画面が開きます。

    この画面は、自動サービス移行またはJDBCストア、あるいはその両方を使用するクラスタを作成するときに初めて表示されます。クラスタのHAオプションを選択すると、構成ウィザードを使用してドメインに追加される以降のクラスタはすべて、自動的にHAオプションが適用されます(つまり、構成ウィザードによってJDBCストアが作成され、それにASMが構成される)。

    次のオプションを選択することをお薦めします:
    • 「データベース・リース」で「自動サービス移行の有効化」を選択します。

    • 「JTAトランザクション・ログ永続性」「JDBC TLogストア」に設定します。

    • 「JMSサーバー永続性」「JMS JDBCストア」に設定します。

Oracle Service Busの構成時に使用される変数

この章のタスクを実行する際には、この項にリストされているディレクトリ変数を参照します。

いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

  • ORACLE_HOME

  • ASERVER_HOME

  • MSERVER_HOME

  • JAVA_HOME

  • WEB_DOMAIN_HOME

さらに、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている、仮想IP (VIP)アドレスADMINVHNを参照します。

この項のアクションは、次のホスト・コンピュータで実行します。

  • SOAHOST1

  • SOAHOST2

  • WEBHOST1

  • WEBHOST2

Oracle Service Busでの動的クラスタのサポート

Oracle Service Busは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。

静的クラスタは、構成済クラスタとも言い、各サーバー・インスタンスを手動で構成して追加する従来型のクラスタです。動的クラスタには、新しい"server-template"オブジェクトが含まれています。このオブジェクトは、すべての生成された(動的)サーバー・インスタンスの一元的な構成を定義するために使用します。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。この機能により、追加のサーバー容量が必要になったときに、動的クラスタ内のサーバー・インスタンスの数をスケール・アップできます。動的サーバーは、最初に手動で構成してそれをクラスタに追加する必要はなく、単に起動するだけで使用できます。

この項に示すステップには、静的トポロジまたは動的トポロジの両方に対応するドメインの構成ステップが含まれています。この2種類の構成の相違点は次のとおりです。
  • 構成ウィザードのプロセスは、それぞれのケースに応じて異なることがあります。たとえば、サーバーではなく動的クラスタ用のサーバー・テンプレートの定義が必要になります。

  • 動的クラスタの場合は、サーバー固有の構成(リスニング・アドレスの設定、アップロードとステージングのディレクトリの構成、キーストアの構成など)をサーバーではなくサーバー・テンプレートで実行する必要があります。

  • 動的クラスタの場合は、サービス移行が異なる方法で構成されます。動的クラスタは移行可能ターゲットを使用しないかわりに、JMSリソースはクラスタにターゲット指定され、移行ポリシーが使用されます。動的クラスタおよび静的クラスタの場合、サービス移行に関連するすべての構成は構成ウィザードで自動的に実行でき、これはこのガイドで使用されているアプローチです。

複合クラスタ(動的サーバー・インスタンスと構成済サーバー・インスタンスの両方を備えたクラスタ)は、Oracle SOA Suiteエンタープライズ・デプロイメントではサポートされません。

トポロジへのOSBの追加の概要

OSBをトポロジに追加する前に、初期Infrastructureドメインの作成に必要なステップをすでに実行し、ドメインを拡張してOracle SOA Suiteを追加していることを確認する必要があります。

表14-1では、Oracle Service Busのために既存のSOAドメインまたは既存のInfrastructureドメインを拡張する、大まかなステップをリストして説明します。

表14-1 Oracle Service Busを追加するためのSOAドメインの拡張ステップ

ステップ 説明 詳細情報

Oracle Service Busソフトウェアのインストール

ターゲット・システムへのOSBソフトウェアのインストール

Oracle Service Busソフトウェアのインストール

オプションで、サポートされているデータベースにSOAINFRAスキーマをインストールします。

OSBでは、wlsbjmsrpDataSourceデータ・ソースにSOAINFRAスキーマが必要です。OSBを独自のドメインで実行する場合は、サポートされているデータベースでOSB用に別個のSOAINFRAスキーマがインストールされていることを確認する必要があります。

OSBドメインで使用されるSOAINFRAスキーマには、一意のスキーマを使用してください。

Oracle SOA Suiteデータベース・スキーマの作成

オプションで、新しいInfrastructureドメインを作成します。

OSBを独自のドメインで実行する場合は、まずInfrastuctureドメインを作成して、OSBを含めることでこのドメインを拡張できるようにする必要があります。

エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

ドメイン拡張のための構成ウィザードの実行

Oracle Service Busコンポーネントを追加するためにSOAまたはInfrastructureドメインを拡張します

Oracle Service Busを追加するためのSOAまたはInfrastructureドメインの拡張

SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播

Oracle Service Busでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

Oracle Service Busサーバーの起動

Oracle Service Busサーバーは既存のドメインを拡張します。そのため、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

WLS_OSB1管理対象サーバーの起動と検証

WLS_OSB管理対象サーバーの検証

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認し、URLにアクセスしてサーバーのステータスを確認します。

WLS_OSB2管理対象サーバーの起動と検証

WLS_OSBn管理対象サーバーについてのOracle HTTP Serverの構成

Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

Oracle Service Bus用のOracle HTTP Serverの構成

Oracle HTTP Serverを介したアクセスの検証

サーバーのステータスが「実行中」であることを確認します。

ロード・バランサを使用したOracle Service Bus URLの検証

OracleファイルとFTPアダプタの高可用性化

OracleファイルとFTPアダプタのアウトバウンド操作に対する高可用性を、データベースのmutexロック操作を使用して実現します。

Oracle DB、ファイルおよびFTPのアダプタの高可用性化

Oracle Service Bus構成のバックアップ

この後の手順でエラーが発生した場合の即座のリストアを目的として、ドメイン構成をバックアップします。

構成のバックアップ

Oracle Service Busを追加するためのドメインの拡張の前提条件

現在のドメインを拡張する前に、既存のデプロイメントが必要な前提条件を満たしていることを確認します。

  • インストールをバックアップすること。既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。

    既存のFusion Middlewareホームとドメインをバックアップするには、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

  • 共有記憶域のOracleホームにInfrastructureおよびSOAソフトウェア・バイナリがインストールされ、SOAHOST1とSOAHOST2から使用できることを確認します。

  • Oracle Service BusがSOAと同じドメイン内に構成されている場合は、適切なSOAINFRAスキーマ(wlsbjmsrpDataSourceによって使用されるもの)がすでに使用可能になっていること。OSBが独自のドメイン内に構成されている場合、RCUを実行し、SOAドメインで使用されているSOAINFRAスキーマとは異なるスキーマ接頭辞を使用して、サポートされているデータベースにSOAINFRAスキーマをインストールする必要があります。

  • 前の章の説明どおりに、ノード・マネージャ、管理サーバー、(任意でSOAサーバー)、およびWSMサーバーをすでに構成していること。必要に応じて、サーバー移行、トランザクション・ログ、一貫性など、SOAシステムのその他のすべての構成ステップが完了していること。

  • 各ホスト・コンピュータのシステム・クロックが同期していることを確認します(まだ、確認していない場合)。これを行うには、各クラスタ内のホストでdateコマンドを同時に実行します。

    また、そのために使用できるサードパーティおよびオープンソースのユーティリティもあります。

Oracle Service Busソフトウェアのインストール

OSBインストーラを使用して、エンタープライズ・デプロイメントにOracle Service Busをインストールできます。

Oracle Service Busインストーラの起動

インストール・プログラムを起動するには、次のステップを実行します。

  1. ターゲット・システムSOAHOST1にログインします。
  2. インストール・プログラムをダウンロードしたディレクトリに移動します。
  3. 次のように、Java実行可能ファイルへのパス を入力します。
    export JAVA_HOME=JAVA_HOME
    export PATH=$JAVA_HOME/bin:$PATH
    

    この例では、このガイドで使用するファイル・システムとディレクトリ変数に記載され、エンタープライズ・デプロイメント・ワークブックに入力されている変数の値で、JAVA_HOMEを置き換えます。

  4. 次のコマンドを入力して、インストール・プログラムを起動します。
    java -d64 -jar fmw_12.2.1.4.0_osb.jar
    

    インストール・プログラムが表示されると、インストールを開始する準備ができています。

OSBインストール画面のナビゲート

表14-2は、インストール・プログラムの各画面の説明です。

表14-2 OSBのインストール画面

画面 説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索するか、組織のためにすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

既存のSOAドメインを拡張する場合は、OSBソフトウェアをSOAソフトウェアがすでにインストールされている既存のOracleホームにインストールします。

OSBを別のドメイン内に構成する場合は、OSBソフトウェアをInfrastructureのOracleホームにインストールします。

インストール・タイプ

この画面を使用して、インストールのタイプを選択し、インストールする製品および機能セットを選択します。

このトポロジの場合は、「Service Bus」を選択します。

前提条件チェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合、『Oracle Fusion Middleware Infrastructureのインストールと構成』システム環境の確認ロードマップに関する項で、次のドキュメントのいずれかを参照できます。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを検証できます。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールまたはコマンドライン・インストールの詳細は、『Oracle Universal Installerによるソフトウェアのインストール』「サイレント・モードでのOracle Universal Installerの使用」を参照してください。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

他のホスト・コンピュータへのソフトウェアのインストール

SOAHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、SOAHOST2にもソフトウェアをインストールする必要があります。詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

Oracleホーム(ソフトウェア・バイナリが含まれている)をインストールする場所は、ホストによって異なることに注意してください。ご使用のOracleホーム・ディレクトリの正しい場所を特定するには、「このガイドで使用するファイル・システムとディレクトリ変数」のガイドラインを参照してください。

OSBインストールの検証

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルとその場所の詳細は、『Oracle Universal Installerによるソフトウェアのインストール』インストール・ログ・ファイルの理解に関する項を参照してください。

ディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

Oracle Service Busを追加すると、次のディレクトリおよびサブディレクトリが追加されます。ls --format=single-columnコマンドを使用して、ディレクトリ構造を確認します。

ls --format=single-colum ORACLE_HOME/osb/
bin
common
config
doc
financial
L10N
lib
modules
osb
plugins
tools

インストール・プロセスの後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解Oracle Fusion Middlewareの主要なディレクトリに関する項を参照してください。

Oracleホームの内容の表示

viewInventoryスクリプトを使用して、Oracleホームの内容を表示することもできます。『Oracle Universal Installerによるソフトウェアのインストール』Oracleホームの内容の表示に関する項を参照してください。

Oracle Service Busを追加するためのSOAまたはInfrastructureドメインの拡張

構成ウィザードでは、Oracle Service Busを追加して、既存のエンタープライズ・デプロイメントのSOAドメインを拡張することができます。拡張を完了するには、一連の追加タスクを実行する必要があります。

ドメインの拡張には、次のタスクが含まれます。

構成ウィザードの起動

ノート:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverridesLate.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のJavaコマンド行オプションの指定、追加の環境変数の指定などを実施するように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。

ドメインの構成を開始するには:

  1. ドメインの構成中に、構成のロック、保存、アクティブ化が行われないように、管理サーバーを停止します。
  2. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。
    ORACLE_HOME/oracle_common/common/bin
    ./config.sh

Oracle Service Busを含めるドメイン拡張を行うための構成ウィザード画面への移動

このステップでは、「Oracle SOA Suiteを含めるドメインの拡張」で作成したドメインを拡張して、Oracle Service Busソフトウェア・コンポーネントと管理対象サーバーを追加します。

Oracle Service Busを追加して管理サーバーとWSM-PMクラスタのみを含むドメインを拡張する場合のステップは、この項で説明するステップとほぼ同じになりますが、画面に表示される一部のオプション、ライブラリ、コンポーネントは異なる場合があります。

次の各項に示す手順に従って、静的 または動的 クラスタを含むトポロジのドメインを作成および構成します。

静的クラスタを含めるドメインの拡張

この項に示す手順に従って、静的クラスタを含めてOracle Service Busのドメインを拡張します。

ノート:

この手順では、既存のドメインを拡張することを想定しています。手順に示された内容と要件が合わないときは、適切な内容を選択していることを確認し、その他の詳細について説明されているドキュメントを参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』構成タイプに関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

  • Oracle Service Bus参照構成[osb]

    初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

    • Oracle SOA Suite参照構成[soa] (SOAドメインを拡張する場合)

    • Oracle Enterprise Manager [em]

    • Oracle WSMポリシー・マネージャ[oracle_common]

    • Oracle JRF - [oracle_common]

    • WebLogic Coherenceクラスタ拡張[wlserver]

    Oracle Service Busテンプレートを選択すると、ODSI XQuery 2004コンポーネント[oracle_common]テンプレートも自動的に選択されます。

    ノート:

    ODSI用の12.2.1.4.0テンプレートはありません。12.1.3.0テンプレートは、12.2.1.4構成に役立ちます。

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』テンプレートに関する項を参照してください。

ノート:

ドメインを拡張してBPMやBAMなど、参照構成をサポートしないコンポーネントを追加する場合(参照構成はSOA、OSB、B2BおよびESSでのみサポートされます)、またはOSBでクラシックSOAドメインを拡張する場合、OSBクラシック・ドメイン・テンプレートを使用する必要があります。

参照構成に含まれる最適化を実装していないクラシックSOAテンプレートは、構成ウィザードには表示されませんが、次の場所にあります:
  • $ORACLE_HOME/soa/common/templates/wls (SOAおよびB2Bクラシック・テンプレート)
  • $ORACLE_HOME/osb/common/templates/wls (OSBクラシック・テンプレート)
クラシック・ドメインを拡張してOSBを追加するためのクラシックOSB拡張テンプレートを選択するには、構成ウィザードの「テンプレート」画面で:
  1. 「カスタム・テンプレートを使用してドメインを更新」を選択します。
  2. $ORACLE_HOME/osb/common/templates/wlsを参照します。
  3. oracle.osb_template.jarを選択します。

    重要:

    インフラまたはSOAクラシック・ドメインの拡張にoracle.osb.classic.domain_template.jarを使用しないでください。OSBクラシック・テンプレートは、ゼロからドメインを作成する場合にのみ使用でき、既存のインフラまたはSOAクラシック・ドメインでの拡張には使用できません。インフラまたはSOAクラシック・ドメインを拡張してOSBクラシックを追加するには、次に示すようにoracle.osb_template.jarを使用します。

B2BまたはOSBのクラシックSOAドメインでの後続の拡張は、参照構成テンプレートではなくクラシック・テンプレートで行う必要があります。

参照構成をサポートしないコンポーネントを追加する予定がない場合、Oracle OSB参照構成テンプレートを使用することをお薦めします。

タスク3   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。

  • 「ベンダー」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ドメインの作成』データ・ソース・デフォルトに関する項を参照してください。

タスク4   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、コンポーネント・スキーマとしてOSB JMSレポート・プロバイダを選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」「次へ」の順にクリックします。

タスク5   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素 説明と推奨値

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

ONSリストはデータベースからドライバに自動的に提供されるため、Oracle 12cデータベース以上のバージョンを使用している場合、これらの値は必要ありません。

Oracle 11gデータベースを使用している場合のみ、次の値を入力します:
  • 「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。
  • 「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

タスク6   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータ・ソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』コンポーネント・スキーマのテスト関する項を参照してください。

タスク7   拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で「トポロジ」を選択します。

ノート:

推奨はJDBCストアで、タスク3「高可用性オプションの選択」でも選択されるので、「ファイル・ストア」を構成する必要はありません。

タスク3「高可用性オプションの選択」で「ファイル・ストア」を選択した場合は、ここで「ファイル・ストア」オプションを選択し、ORACLE_RUNTIME/domain_name/OSB_Cluster/jmsの共有場所でそれを構成する必要があります。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。

タスク8   管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストにOracle SOA Suite用の新しい管理対象サーバーが表示されます。このサーバーは、タスク2「構成テンプレートの選択」で選択したOracle SOA Suite構成テンプレートによって自動的に作成されました。

次のタスクを実行して、デフォルトのOracle SOA Suite管理対象サーバーを変更して2つ目のOracle SOA Suite管理対象サーバーを作成します。

  1. デフォルトのOracle SOA Suite管理対象サーバーの名前をWLS_OSB1に変更します。

  2. 「追加」をクリックして新しい管理対象サーバーを作成し、そのサーバーにWLS_OSB2と名前を付けます。

    ヒント:

    ここで推奨するサーバー名は、このドキュメント全体で使用します。別の名前を選択する場合は、必要に応じてそれらの名前に置き換えてください。
  3. 表14-3の情報を使用して、各管理対象サーバーの残りの列を入力します。

  4. OSBサーバーのサーバー・グループとして「OSB-MGD-SVRS-ONLY」を選択します。デフォルトで選択されているOSB-MGD-SVRS-COMBINEDの選択を解除します。

  5. 「次」をクリックします。

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』管理対象サーバーに関する項を参照してください。

表14-3 構成ウィザードでのOracle Service Bus管理対象サーバーの構成

名前 リスニング・アドレス リスニング・ポート SSLリスニング・ポート SSL有効 サーバー・グループ

WLS_SOA1

SOAHOST1

8001

n/a

いいえ

SOA-MGD-SVRS-ONLY

WLS_SOA2

SOAHOST2

8001

n/a

いいえ

SOA-MGD-SVRS-ONLY

WLS_WSM1

SOAHOST1

7010

n/a

いいえ

JRF-MAN-SVR

WSMPM-MAN-SVR

WLS_WSM2

SOAHOST2

7010

n/a

いいえ

JRF-MAN-SVR

WSMPM-MAN-SVR

WLS_OSB1

SOAHOST1

8011

n/a

いいえ

OSB-MGD-SVRS-ONLY

WLS_OSB2

SOAHOST2

8011

n/a

いいえ

OSB-MGD-SVRS-ONLY

WLS_SOA管理対象サーバーは、Oracle Service Busを含めて既存のOracle SOA Suiteドメインを拡張する場合に表示されます。

タスク9   クラスタの構成

このタスクでは、Oracle SOA Suiteソフトウェアのターゲットとすることができる管理対象サーバーのクラスタを作成します。

クラスタの「フロントエンド・ホスト」プロパティも設定します。これにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上のsoa.example.comにリダイレクトするようになります。

soa.example.com仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

「クラスタ」画面を使用して、新しいクラスタを作成します。

  1. 「追加」ボタンをクリックします。

  2. 「クラスタ名」フィールドで、OSB_Clusterを指定します。

  3. 「フロントエンド・ホスト」フィールドでosb.example.comを指定します。

  4. 「フロントエンドHTTPポート」80を指定し、「フロントエンドHTTPSポート」443を指定します。

ノート:

デフォルトでは、クラスタのサーバー・インスタンスはユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』ユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』クラスタに関する項を参照してください。

タスク10   サーバー・テンプレートの割当て

「次へ」をクリックして続行します。

タスク11 動的サーバーの構成

「次へ」をクリックして続行します。

タスク12   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

WLS_SOA管理対象サーバーはOracle Service Busを含めて既存のOracle SOA Suiteドメインを拡張する場合のみ表示されるということに注意してください。

  • SOA_Cluster (SOAドメインを拡張する場合):

    • WLS_SOA1

    • WLS_SOA2

  • WSM-PM_Cluster:

    • WLS_WSM1

    • WLS_WSM2

  • OSB_Cluster:

    • WLS_OSB1

    • WLS_OSB2

「次」をクリックします。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』サーバーのクラスタへの割当てに関する項を参照してください。

タスク13   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。

Coherenceライセンス情報については、Oracle Fusion Middlewareライセンス情報ユーザー・マニュアルOracle Coherence製品に関する項を参照してください。

タスク14 既存のマシンの検証

次のエントリが表示されることを確認します。

名前 ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

ADMINVHN

その他のすべてのフィールドはデフォルト値のままにします。

「次」をクリックします。

タスク15   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

  • ADMINHOST:

    • AdminServer

  • SOAHOST1

    • WLS_SOA1 (SOAドメインを拡張する場合)

    • WLS_WSM1

    • WLS_OSB1

  • SOAHOST2:

    • WLS_SOA2 (SOAドメインを拡張する場合)

    • WLS_WSM2

    • WLS_OSB2

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』サーバーのマシンへの割当てに関する項を参照してください。

タスク16   仮想ターゲットの構成

「次」をクリックします。

タスク17   パーティションの構成

「次」をクリックします。

タスク18   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから拡張するドメインの構成情報の詳細が含まれています。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで、任意の画面に戻れます。

「更新」をクリックして、ドメインの拡張を実行します。

終了したら、「構成の進行状況」画面で「次へ」をクリックします。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』構成のサマリーに関する項を参照してください。

タスク19   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

  • ドメインの場所

  • 管理サーバーURL

どちらの項目も後で必要になるためノートにとってください。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、管理サーバーのURLはWebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク20   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

静的クラスタを含めるドメインの拡張を完了したら、「ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播」に進みます。

動的クラスタを含めるドメインの拡張

この項に示す手順に従って、動的クラスタを含めてOracle Service Busのドメインを拡張します。

ノート:

この手順では、既存のドメインを拡張することを想定しています。手順に示された内容と要件が合わないときは、適切な内容を選択していることを確認し、その他の詳細について説明されているドキュメントを参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』構成タイプに関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

  • Oracle Service Bus参照構成[osb]

    初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

    • Oracle SOA Suite参照構成[soa] (SOAドメインを拡張する場合)

    • Oracle Enterprise Manager [em]

    • Oracle JRF - [oracle_common]

    • Oracle WSMポリシー・マネージャ[oracle_common]

    • WebLogic Coherenceクラスタ拡張[wlserver]

    Oracle Service Busテンプレートを選択すると、ODSI XQuery 2004コンポーネント[oracle_common]テンプレートも自動的に選択されます。

    ノート:

    ODSI用の12.2.1.4.0テンプレートはありません。12.1.3.0テンプレートは、12.2.1構成に役立ちます。

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』テンプレートに関する項を参照してください。

ノート:

ドメインを拡張してBPMやBAMなど、参照構成をサポートしないコンポーネントを追加する場合(参照構成はSOA、OSB、B2BおよびESSでのみサポートされます)、またはOSBでクラシックSOAドメインを拡張する場合、OSBクラシック・ドメイン・テンプレートを使用する必要があります。

参照構成に含まれる最適化を実装していないクラシックSOAテンプレートは、構成ウィザードには表示されませんが、次の場所にあります:
  • $ORACLE_HOME/soa/common/templates/wls (SOAおよびB2Bクラシック・テンプレート)
  • $ORACLE_HOME/osb/common/templates/wls (OSBクラシック・テンプレート)
クラシック・ドメインを拡張してOSBを追加するためのクラシックOSB拡張テンプレートを選択するには、構成ウィザードの「テンプレート」画面で:
  1. 「カスタム・テンプレートを使用してドメインを更新」を選択します。
  2. $ORACLE_HOME/osb/common/templates/wlsを参照します。
  3. oracle.osb_template.jarを選択します。

    重要:

    インフラまたはSOAクラシック・ドメインの拡張にoracle.osb.classic.domain_template.jarを使用しないでください。OSBクラシック・テンプレートは、ゼロからドメインを作成する場合にのみ使用でき、既存のインフラまたはSOAクラシック・ドメインでの拡張には使用できません。インフラまたはSOAクラシック・ドメインを拡張してOSBクラシックを追加するには、次に示すようにoracle.osb_template.jarを使用します。

B2BまたはOSBのクラシックSOAドメインでの後続の拡張は、参照構成テンプレートではなくクラシック・テンプレートで行う必要があります。

参照構成をサポートしないコンポーネントを追加する予定がない場合、Oracle OSB参照構成テンプレートを使用することをお薦めします。

タスク3   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。

  • 「ベンダー」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ドメインの作成』データ・ソース・デフォルトに関する項を参照してください。

タスク4   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、コンポーネント・スキーマとしてOSB JMSレポート・プロバイダを選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」「次へ」の順にクリックします。

タスク5   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素 説明と推奨値

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

ONSリストはデータベースからドライバに自動的に提供されるため、Oracle 12cデータベース以上のバージョンを使用している場合、これらの値は必要ありません。

Oracle 11gデータベースを使用している場合のみ、次の値を入力します:
  • 「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。
  • 「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

タスク6   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータ・ソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』コンポーネント・スキーマのテスト関する項を参照してください。

タスク7   拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で「トポロジ」を選択します。

ノート:

推奨はJMS JDBCストアで、タスク3「高可用性オプションの選択」でも選択されるので、「ファイル・ストア」を構成する必要はありません。タスク3「高可用性オプションの選択」で「JMSファイル・ストア」を選択した場合は、「ファイル・ストア」オプションを選択し、ORACLE_RUNTIME/domain_name/SOA_Cluster/jmsの共有場所でそれを構成する必要があります。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。

タスク8   管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストにOracle SOA Suite用の新しい管理対象サーバーが表示されます。このサーバーは、タスク2「構成テンプレートの選択」で選択したOracle SOA Suite構成テンプレートによって自動的に作成されました。

動的クラスタ構成に静的管理対象サーバー定義は必要ありません。デフォルトの管理対象サーバーを削除するには、次のステップを実行します。
  1. デフォルトの管理対象サーバーを削除します。

  2. 「次へ」をクリックして次の画面に進みます。

タスク9   クラスタの構成

このタスクでは、Oracle SOA Suiteソフトウェアのターゲットとすることができる管理対象サーバーのクラスタを作成します。

クラスタの「フロントエンド・ホスト」プロパティも設定します。これにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上のsoa.example.comにリダイレクトするようになります。

soa.example.com仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

「クラスタ」画面を使用して、新しいクラスタを作成します。

  1. 「追加」ボタンをクリックします。

  2. 「クラスタ名」フィールドで、OSB_Clusterを指定します。

  3. 「フロントエンド・ホスト」フィールドでosb.example.comを指定します。

  4. 「フロントエンドHTTPポート」80を指定し、「フロントエンドHTTPSポート」443を指定します。

ノート:

デフォルトでは、クラスタのサーバー・インスタンスはユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』ユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』クラスタに関する項を参照してください。

タスク10   サーバー・テンプレートの割当て

「サーバー・テンプレート」画面を使用して、テンプレートを構成します。

  1. 「名前」フィールドでosb-server-templateが選択されていることを確認します。

  2. 「リスニング・ポート」フィールドで、8010を指定します。

  3. 「SSLの有効化」オプションは未選択のままにしておきます。

  4. 「次」をクリックします。

タスク11 動的サーバーの構成

「動的クラスタ」画面を使用して、必要なクラスタを構成します。

  1. 「クラスタ名」フィールドで、OSB_Clusterを指定します。

  2. 「サーバー・テンプレート」ドロップダウン・リストで、osb-server-templateを選択します。

  3. 「サーバー名の接頭辞」フィールドで、WLS_OSBを指定します。

  4. 「動的クラスタ・サイズ」フィールドに2を指定します。

  5. 「マシン名マッチング式」フィールドでSOAHOST*を指定し、「計算済マシン名」を選択します。

    ノート:

    動的クラスタの「計算済マシン名」および「マシン名マッチング式」属性は、動的クラスタ内のサーバー・インスタンスをマシンに割り当てる方法を制御します。「計算済マシン名」属性がFalseに設定されている場合、動的サーバーはマシンに割り当てられません。「計算済マシン名」属性が「true」に設定されている場合は、「マシン名マッチング式」属性を使用して、動的クラスタに使用される一連のマシンが選択されます。「マシン名マッチング式」属性が設定されていない場合、ドメイン内のすべてのマシンが選択されます。割当は、ラウンド・ロビン・アルゴリズムを使用して行われます。

    実際の物理的なホスト名にかかわらず処理を簡単にするために、WebLogicマシン名としてはSOAHOSTnを使用することをお薦めします。nは連番です。これについては、インフラストラクチャ・ドメインの構成に関するタスク18「マシンの作成」で説明しています。この規則によって、動的クラスタは各クラスタ・メンバーをどこで起動するかを決定しやすくなっています。この規則に従う場合は、「マシン・マッチング式」フィールドに「SOAHOST*」と入力します。

    この規則に従わない場合、クラスタ・メンバーはタスク18「マシンの作成」で定義する各マシンで起動します。これには、ADMINHOSTも含まれます。この状況は、2つのクラスタ・メンバーが同じ物理サーバー上で動作するが2つの異なるドメイン・ホームにアタッチされる結果となるため、望ましくありません。

  6. 「計算済リスニング・ポート」を選択します。

    ノート:

    「計算済リスニング・ポート」オプションが選択された動的クラスタの場合、自動的に作成される動的管理対象サーバーごとに増分でポート番号が割り当てられます。つまり、動的サーバー1にはリスニング・ポート+1、動的サーバー2にはリスニング・ポート+2が使用されます。

    構成済のリスニング・ポートは8010で、計算済のポートがチェックされるので、OSB動的サーバーは次のポート番号を使用します。

    • WLS_OSB1サーバーは、ポート8011でリスニングします

    • WLS_OSB2サーバーは、ポート8012でリスニングします

  7. 「動的サーバー・グループ」「OSB-DYN-CLUSTER-ONLY」を選択します。

  8. 「次」をクリックします。

タスク12   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。

Coherenceライセンス情報については、Oracle Fusion Middlewareライセンス情報ユーザー・マニュアルOracle Coherence製品に関する項を参照してください。

タスク13 既存のマシンの検証

次のエントリが表示されることを確認します。

名前 ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

ADMINVHN

その他のすべてのフィールドはデフォルト値のままにします。

「次」をクリックします。

タスク14   マシンへのサーバーの割当て

「次」をクリックします。

タスク15   仮想ターゲットの構成

「次」をクリックします。

タスク16   パーティションの構成

「次」をクリックします。

タスク17   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから拡張するドメインの構成情報の詳細が含まれています。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで、任意の画面に戻れます。

「更新」をクリックして、ドメインの拡張を実行します。

終了したら、「構成の進行状況」画面で「次へ」をクリックします。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』構成のサマリーに関する項を参照してください。

タスク18   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

  • ドメインの場所

  • 管理サーバーURL

どちらの項目も後で必要になるためノートにとってください。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、管理サーバーのURLはWebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク19   管理サーバーの起動

ドメイン拡張プロセスの間に管理サーバーを実行していた場合は、続行する前にサーバーを再起動し、ドメインに行った変更が適用されたことを確認します。

ノート:

OSBを動的クラスタとして構成する場合は、OSBシングルトン・アプリケーション(つまり、アグリゲータ)に必要なクラスタ・リースを適切にアクティブ化する必要があります。デフォルトでは、動的クラスタに対するリース構成は構成ウィザードでは実行されません。したがって、OSB_Clusterのリースを構成する前にOSB管理対象サーバーを起動した場合、ログに次のようなメッセージが表示されます。

<Warning> <oracle.osb.statistics.statistics> <OSB-473015> <As Automatic Service Migration enabled in Domain, selection of Aggregation Server delayed till Aggregator Singleton is activated. This may happen either during start of all managed servers or migration of Aggregator Singleton due to failure of managed server where it is activated. If this message did not stop after sometime, check managed servers are running. If not, contact Oracle Support.>
<Error> <oracle.osb.statistics.statistics> <OSB-473003> <Aggregation Server Not Available. Aggregator stub was null>
<Error> <oracle.osb.statistics.statistics> <OSB-473003> <Aggregation Server Not Available. Failed to get remote aggregator

クラスタのリース構成を完了すると、このメッセージはなくなります。リースの構成は、後で実行します。「OSBシングルトン・サービスのターゲット指定が適切であるかどうかの確認」を参照してください。

ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

OSBインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびシステムに伝播する必要があります。

更新済ドメインをWEBHOST1およびWEBHOST2システムに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。

詳細は、次の項を参照してください。

変更を他のドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

表14-4は、変更をすべてのドメイン・ディレクトリとシステムに伝播するために必要なステップをまとめたものです。

表14-4 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

タスク 説明 詳細情報

SOAHOST1での拡張済ドメインの圧縮

packコマンドを使用して、新しいOSBサーバー構成が含まれる新しいテンプレートJARファイルを作成します。

ドメインを圧縮する場合は、soadomaintemplateExtOSB.jarというテンプレートJARファイルを作成します。

SOAHOST1での拡張済ドメインの圧縮

SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍

SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

SOAHOST2でのドメインの解凍

SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST2でのドメインの解凍

WLS_OSB1管理対象サーバーの起動と検証

ドメインの拡張、管理サーバーの再起動、および他のホストへのドメインの伝播を完了したら、次の手順を使用して、WLS_OSB1サーバーを起動し、そのサーバーが正常に構成されているかどうかを検証します。

WLS_OSB1管理対象サーバーの起動
  1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
    http://ADMINVHN:7001/em
    

    ノート:

    Web層がすでに構成されている場合は、http://admin.example.com/consoleを使用します。
  2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
  3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。
  4. WLS_OSB1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

    ノート:

    OSBサーバーは、ポリシー・アクセス・サービスに依存して機能します。これは、OSBサーバーが起動する前に、ドメイン内のWSM-PM管理対象サーバーが稼働していてアクセス可能になっている必要があることを意味します。
  5. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_OSB1管理対象サーバーが稼働中であることを確認します。
エンタープライズ・デプロイメント管理グループへのMiddlewareAdministratorsロールの追加

WLS_OSB1管理対象サーバーのOracle Service Bus構成を検証する前に、Oracle Service BusのMiddlewareAdministrators管理ロールをエンタープライズ・デプロイメント管理グループ(SOA Administrators)に追加して、外部LDAPディレクトリにIntegrationAdministratorsグループを追加します。

このタスクを実行するには、「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。

管理対象サーバーの検証

MiddlewareAdministratorロールをSOA Administratorsグループに追加した後、次のようにWLS_OSB1管理対象サーバー上のOracle Service Busソフトウェアの構成を検証できます。

  1. Webブラウザを使用して次のURLに移動します。
    http://SOAHOST1:8011/sbinspection.wsil

    SOAHOST1を、Enterprise Deployment Workbookに入力されているこの変数の値に置き換えます。管理サーバーと各管理対象サーバーに必要な物理IP (IP)と仮想IP (VIP)アドレスの詳細は、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」を参照してください。

  2. エンタープライズ・デプロイメント管理ユーザー(SOA Administrators)を使用してログインします。

    デフォルトのインストールでは、これにより、Webサービス・コールに対して次のHTTPレスポンスが返されます。

    <ins:inspection xmlns:ins="http://schemas.xmlsoap.org/ws/2001/10/inspection/"/>
    

WLS_OSB2管理対象サーバーの起動と検証

WLS_OSB2でも、前の項と同様のステップを実行します。

  1. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
  2. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。
  3. WLS_OSB2管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。
  4. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_OSB2管理対象サーバーが稼働中であることを確認します。WLS_OSB2用の同等のURLにアクセスします。

    静的クラスタの場合

    http://SOAHOST2:8011/sbinspection.wsil

    動的クラスタの場合

    http://SOAHOST2:8012/sbinspection.wsil
  5. 次のURLにアクセスし、管理サーバーへのOracle Service Busコンソールのデプロイメントが適切であることを確認します。
    http://ADMINVHN:7001/servicebus/

OSBシングルトン・サービスのターゲット指定が適切であるかどうかの確認

Oracle Service Busは、OSB_Cluster内のいずれか1つのWLSサーバー上でのみ稼働するシングルトン・サービスをいくつか使用します。シングルトン・サービスは次のとおりです。
  • アグリゲータ

  • SLAアラート・マネージャ

  • ポーラー・トランスポート(メール、ファイル、FTPおよびSFTPポーラー)

これは、「Service Bus」構成の「グローバル設定」オプションにある「OSBシングルトン・コンポーネント自動移行」というグローバル・プロパティで制御し、Enterprise Managerで公開されます。アクティブ化すると、WebLogic Singleton Frameworkを使用して、OSBシングルトン・サービスのシングルトン動作と自動移行が保証されます。

サーバーまたはサービスの移行と同じように、データベース・リースも「OSBシングルトン・コンポーネント自動移行」が正しく動作するための要件です。「OSBシングルトン・コンポーネント自動移行」チェックボックスで、リース・データソースが自動的に定義されるわけではありません。アプリケーションをシングルトンとしてマークするだけです。

このガイドで推奨されているように、構成ウィザードで「自動サービス移行の有効化」が選択されているかぎり、このOSBグローバル・プロパティとデータベース・リースは、動的クラスタと静的クラスタの両方のSOAエンタープライズ・デプロイメント・トポロジでデフォルトで選択されます。

構成ウィザードを使用して自動サービス移行が有効化されておらず、後で手動で定義する場合は、「OSBシングルトン・コンポーネント自動移行」も手動で選択する必要があります。

OSBで適切なシングルトン動作を保証するには:

「OSBシングルトン・コンポーネント自動移行」オプションが選択されていることを確認します。

  1. Oracle Fusion Middleware Enterprise Managerにログインします。ブラウザで、次のURLにアクセスします。
    http://ADMINVHN:7001/em
    
  2. 「SOA」「service-bus (AdminServer)」「グローバル設定」に移動します。

    SOA EDGトポロジの場合は、「OSBシングルトン・コンポーネント自動移行」のプロパティがデフォルトで選択されている必要があります。

次のステップに従って、適切なターゲットが存在していることを確認します。

  1. ブラウザで、次のURLにアクセスします。
    http://ADMINVHN:7001/console
    
  2. 管理者としてログインします。

  3. 左側にある「ドメイン構造」ツリーで、「デプロイメント」をクリックします。

  4. アグリゲータ・シングルトン・マーカー・アプリケーションを探します。表の「ターゲット」列の値がOSB_Clusterであることを確認します。

リース・データソースがOSB_Clusterに定義されていることを確認します。

  1. ブラウザで、次のURLにアクセスします。
    http://ADMINVHN:7001/console
  2. 管理者としてログインします。

  3. 「ドメイン構造」で、「環境」を開き、「クラスタ」をクリックします。

  4. 「OSB_Cluster」をクリックします。

  5. 「移行」タブをクリックします。

  6. 「移行基盤」ドロップダウン・メニューで「データベース」が選択されており、リース・データソース「自動移行に使用するデータ・ソース」が定義されていることを確認します。

    データベース・リースが定義されていない場合は、構成する手順は「エンタープライズ・デプロイメント・クラスタに対するリース・メカニズムおよびデータ・ソースの設定」を参照してください。

ノート:

構成ウィザードで、静的クラスタに対してドメインを構成する時点では、「高可用性のオプション」画面で「自動サービス移行の有効化」オプションが選択されていると想定しています。このオプションが選択されていない場合、Service Bus Domain Singleton Marker Applicationは直接、クラスタWLS_OSB1の最初のサーバーにターゲット指定され、このサーバーでシングルトン・サービスがホストされます。障害が発生した場合にOSBシングルトン・サービスの自動移行が実行されないため、この方法を推奨されません。

uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。「エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更」を参照してください。

動的クラスタを使用する際のリスニング・アドレスの構成

動的クラスタにおける動的な管理対象サーバーのデフォルト構成では、使用可能なネットワーク・インタフェースすべてでリスニングするようになっています。ほとんどの場合、デフォルトの構成では不適切です。

動的クラスタを使用する際に、リスニング・アドレスを特定のアドレスに限定するには、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。前の項でリスニング・アドレスを変更したときに指定されたテストURLを再確認し、クラスタ化された管理対象サーバーを再起動します。

拡張したドメイン用のWeb層の構成

拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングするように、Web層のWebサーバー・インスタンスを構成する方法を理解することが重要です。

ノート:

OSBでカスタム・エンドポイントを追加する場合は、必ずOHSまたはOTD構成に適切なURLを追加してください。たとえば、RNOWOSB/などのプロキシ・サービスを追加する場合は、サービスのosb_vh.confに次のURLを追加し、OHS/OTDを通じて使用できるようにする必要があります。
<Location /RNOWOSB>
 	WLSRequest ON
	WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
	WLProxySSL ON
	WLProxySSLPassThrough ON
</Location>
あるいは、Web層で一意のルート・コンテキストを作成し、それをすべてのプロキシ・サービスのベース・パスとして使用することをお薦めします。たとえば、ルート・コンテキストが/endpointの場合、構成後のエンドポイントURLは、osb.example.com/endpoint/RNOWOSB/となります。こうすると、新しいエンドポイントごとにWeb層の構成ファイルを変更する必要がなくなり、OAMを使用している場合には、SSOにリソース構成が1つで済むという利点もあります。
<Location /endpoint>
	WLSRequest ON
	WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
	WLProxySSL ON
	WLProxySSLPassThrough ON
</Location>

Oracle Service Bus用のOracle HTTP Serverの構成

Oracle Service Busクラスタにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、soa.example.com仮想サーバーのパラメータを作成して定義するOracle HTTP Server構成ファイルを追加作成します。

この手順では、「管理およびOracle Web Services Manager用のOracle HTTP Serverの構成」で説明されているOracle HTTP Server構成タスクが実行済であることを想定しています。

パラメータを設定するには:

  1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。
    cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf
    
  2. 新しい構成ファイル(osb_vh.confという名前のファイル)を作成し、次の<VirtualHost>ディレクティブをそのファイルに追加します。
    <VirtualHost WEBHOST1:7777>
        ServerName https://osb.example.com:443
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    </VirtualHost>
    
  3. <VirtualHost>タグ内に、次のディレクティブを追加します。

    ノート:

    静的または動的クラスタへの割当てに従って、適切なポート番号を構成します。「計算済リスニング・ポート」オプションが選択された動的クラスタの場合、作成する動的管理対象サーバーごとに増分でポート番号が割り当てられます。

    部分的に停止した場合の初期接続を保証するためにWebLogicClusterディレクトリで必要なのは、十分な数の冗長なserver:portの組合せだけです。クラスタ・メンバーの実際の総リストは、指定された任意のノードとの最初の接続時に自動的に取得されます。

    <Location /sbinspection.wsil>
      WLSRequest ON
      WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
      WLProxySSL ON
      WLProxySSLPassThrough ON
    </Location>
    
    <Location /sbresource>
      WLSRequest ON
      WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
      WLProxySSL ON
      WLProxySSLPassThrough ON
    </Location>
    
    <Location /osb>
      WLSRequest ON
      WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
      WLProxySSL ON
      WLProxySSLPassThrough ON
    </Location>
    
    <Location /alsb>
      WLSRequest ON
      WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
      WLProxySSL ON
      WLProxySSLPassThrough ON
    </Location>
    
    <Location /default>
      WLSRequest ON
      WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
      WLProxySSL ON
      WLProxySSLPassThrough ON
    </Location>

    osb_vh.confファイルは、例14-1のように表示されます。

  4. 次のエントリをadmin_vh.confファイルの<VirtualHost>タグ内に追加します。
    <Location /sbconsole >
      WLSRequest ON
      WebLogicHost ADMINVHN
      WeblogicPort 7001
    </Location>
    
    <Location /servicebus>
      WLSRequest ON
      WebLogicHost ADMINVHN
      WeblogicPort 7001
    </Location>
    
    <Location /lwpfconsole >
      WLSRequest ON
      WebLogicHost ADMINVHN
      WeblogicPort 7001
    </Location>
    

    admin_vh.confファイルは、例14-2のように表示されます。

  5. WEBHOST2にログインして、osb_vh.confファイルとadmin_vh.confファイルを、2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。
    WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf
    
  6. osb_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。
  7. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

例14-1 osb_vh.confファイル

<VirtualHost WEBHOST1:7777>
  ServerName https://osb.example.com:443
  ServerAdmin you@your.address
  RewriteEngine On
  RewriteOptions inherit

<Location /sbinspection.wsil >
  WLSRequest ON
  WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
  WLProxySSL ON
  WLProxySSLPassThrough ON
</Location>

<Location /sbresource >
  WLSRequest ON
  WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
  WLProxySSL ON
  WLProxySSLPassThrough ON
</Location>

<Location /osb >
  WLSRequest ON
  WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
  WLProxySSL ON
  WLProxySSLPassThrough ON
</Location>

<Location /alsb >
  WLSRequest ON
  WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
  WLProxySSL ON
  WLProxySSLPassThrough ON
</Location>

<Location /default>
 WLSRequest ON
 WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
 WLProxySSL ON
 WLProxySSLPassThrough ON
 </Location>
 </VirtualHost>

例14-2 admin_vh.confファイル

# The admin URLs should only be accessible via the admin virtual host 

<VirtualHost WEBHOST1:7777>
    ServerName admin.example.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

# Admin Server and EM
<Location /console>
    WLSRequest ON
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /consolehelp>
    WLSRequest ON
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /em>
    WLSRequest ON
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /sbconsole >
    WLSRequest ON
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /servicebus>
    WLSRequest ON
    WebLogicHost ADMINVHN
    WeblogicPort 7001
   </Location>

<Location /lwpfconsole >
  WLSRequest ON
  WebLogicHost ADMINVHN
  WeblogicPort 7001
</Location>
</VirtualHost>

WebLogicプロキシ・プラグインの構成

OSBクラスタの「WebLogicプラグインの有効化」パラメータを設定します。

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「ドメイン構造」ペインで「環境」ノードを開きます。
  3. 「クラスタ」をクリックします。
  4. Oracle HTTP Serverからのリクエストのプロキシ先とするOSB_Clusterクラスタを選択します。

    「構成: 一般」タブが表示されます。

  5. 「詳細」セクションまでスクロール・ダウンして、開きます。
  6. 「ロックして編集」をクリックします。
  7. 「WebLogicプラグインの有効化」を「はい」に設定します。
  8. 「保存」をクリックし、「変更のアクティブ化」をクリックします。OSBサーバーを再起動して変更内容を有効にします。

ロード・バランサを使用したOracle Service Bus URLの検証

Oracle Service Bus URLを検証して、ハードウェア・ロード・バランサからHTTP Serverインスタンスを経由してOracle Service Busコンポーネントに至るルーティングとフェイルオーバーが適切に機能することを確認します。

URLを検証するには:

  1. WLS_OSB1が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_OSB2を停止します。
  2. 次のURLにアクセスし、HTTPレスポンスが「WLS_OSB2管理対象サーバーの起動と検証」のとおりであることを確認します。
    https://osb.example.com/sbinspection.wsil
  3. Oracle WebLogic Server管理コンソールでWLS_OSB2を起動します。
  4. Oracle WebLogic Server管理コンソールでWLS_OSB1を停止します。
  5. 同じURLにアクセスし、HTTPレスポンスが「WLS_OSB2管理対象サーバーの起動と検証」のとおりであることを確認します。

    ノート:

    OSB_ClusterにフロントエンドURLが設定されているため、URLへのリクエストはLBRへの再ルーティングになりますが、どのようなケースでも、Oracle HTTP Server内のマウント・ポイントおよびフェイルオーバーの検証には十分です。

  6. ロード・バランサのアドレスを使用してこのURLを検証します。
    https://osb.example.com:443/sbinspection.wsil
    

    http://admin.example.com:80/servicebusも検証できます。

Oracle Service Busの構成後タスク

ドメインにOracle Service Busをインストールして構成した後、次のような構成後タスクを検討します。

Oracle DB、ファイルおよびFTPのアダプタの高可用性化

Oracle SOA SuiteとOracle Service Busは、同じデータベース、ファイルおよびFTP JCAアダプタを使用します。

Oracle SOA Suiteを構成する前に、Oracleリポジトリ作成ユーティリティを使用するときに、これらのアダプタに必要なデータベース・スキーマを作成します。データベース・アダプタの構成は、WebLogic Serverのリソース・レベルでは必要ありません。

その他のアダプタに必要な構成は、「OracleファイルとFTPアダプタの高可用性化」に記載されています。

SOAドメインの拡張としてOracle Service Busを構成する場合は、アダプタに対する構成はすでに行われているため構成に加える必要はありません。

Oracle Service BusをOracle Fusion Middleware Infrastructureドメインの拡張としてデプロイする(Oracle SOA Suiteを含まない)場合は、「OracleファイルとFTPアダプタの高可用性化」で説明されているステップを実行する必要があります。

ポーラー・トランスポートに関する考慮事項

OSBは、本質的にはトランザクションでないネイティブ・ポーラー・トランスポートを提供します。これらのトランスポートは、ソース・ディレクトリ、FTPサーバーまたは電子メール・サーバーで新しいメッセージをポーリングし、処理ペイロードを必要なJMS宛先にプッシュします。電子メール、ファイル、FTPおよびSFTPは、このカテゴリに含まれます。

ポーリングベースのトランスポートでは、管理対象サーバーに固定されたトランスポート・ポーラー・スレッドが使用されます。クラスタ内のすべての管理対象サーバーが関連ペイロードを処理できますが、メッセージをポーリングできるのは1つのサーバーのみです。システムを停止から保護するには、ポーラー・スレッドをアプリケーション・スコープのシングルトンとして構成し、関係するJMS宛先に高い可用性があることが必要です。

ポーラー・トランスポートのシングルトン動作は、他のOSBシングルトン・サービスと同じように、「OSBシングルトン・コンポーネント自動移行」のプロパティによって制御されます。

選択すると、ポーラー用のアプリケーション・スコープのシングルトンがクラスタにデプロイされます。サーバーまたはサービスの移行と同じように、リースも「OSBシングルトン・コンポーネント自動移行」が正しく動作するための要件です。

ノート:

このチェックボックスで、リース・データソースが自動的に定義されるわけではありません。アプリケーションをシングルトンとしてマークするだけです。

このガイドで推奨されているように、構成ウィザードで「自動サービス移行の有効化」が選択されている場合、動的クラスタと静的クラスタの両方について、SOAエンタープライズ・デプロイメント・トポロジのプロパティ「OSBシングルトン・コンポーネント自動移行」および「データベース・リース」がデフォルトで選択されます。

リース・データソースがまだ構成されていないときに、このチェックボックスを選択する場合は、必ずリース・データソースを構成してください。「OSBシングルトン・サービスのターゲット指定が適切であるかどうかの確認」を参照してください。

ポーラー・トランスポートが、「OSBシングルトン・コンポーネント自動移行」でアプリケーション・スコープのシングルトンとして構成されているかどうかは、次のステップで確認できます。

  1. ブラウザで、次のURLにアクセスします。
    http://ADMINVHN:7001/console
  2. 管理者としてログインします。

  3. 左側にある「ドメイン構造」ツリーで、「デプロイメント」をクリックします。

  4. トランスポート・ポーラーにシングルトン・アプリケーションがデプロイされていることを確認します。例: SB_FILE_Proxy_*

  5. 表の「ターゲット」列の値がOSB_Clusterであることを確認します。

このトランスポート・サービスを高可用性で利用するには、永続化するJMS宛先(ペイロード処理のために使用される)を障害が保護する必要があります。SOAエンタープライズ・デプロイメント・トポロジ(動的クラスタと静的クラスタの両方)では、この保護は自動サービス移行によって提供されます。

エンタープライズ・デプロイメント用の個別のOracle Service Busサービスの構成

IBM WebSphereのMQ接続リソースとMQトランスポートをOracle Service Bus内で使用するには、MQクライアント・ライブラリをクラスパスに追加する必要があります。

必要なMQライブラリをドメイン・ホーム・ディレクトリの次の場所にコピーするのも1つの方法です。

DOMAIN_HOME/lib

これは、カスタム・アサーションおよびJBoss統合サービスの場合にもあてはまります。

  • JBoss初期コンテキスト・ファクトリ・クラスを使用している場合は、クラスおよび依存クラスをDOMAIN_HOME/libディレクトリに含めてください。

  • 同様に、カスタム・アサーションの場合は、アサーションに必要なJARファイルを作成し、DOMAIN_HOME/libディレクトリにそのJARファイルを追加します。

さらに、エンタープライズ・デプロイメントでこれらのサービスを使用するには、必要なライブラリを管理サーバー・ドメイン・ホーム(ASERVER_HOME/lib)と管理対象サーバー・ドメイン・ホーム(MSERVER_HOME/lib)に追加する必要があります。

Oracle Service Busのサービスの構成およびデプロイの詳細は、『Oracle Fusion Middleware Oracle Service Busでのサービスの開発』Oracle Service Busコンソールのスタート・ガイドを参照してください。

Oracle Service Busサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

Oracle Service Busを含めてドメインを拡張した後、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認する必要もあります。

これにより、Oracle Service BusのWebサービスとその他のサービスが、フロントエンドのセキュアURLとのコールバックやその他の通信を起動できるようになります。「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」を参照してください。

Oracle Service BusのJDBC永続ストアの有効化

Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。

このガイドで静的クラスタと静的クラスタの両方について推奨されているように、「高可用性のオプション」画面で次の選択を行った場合、JDBC永続ストアはすでにJMSとTLOGSの両方に対して構成されています:

  • 「JTAトランザクション・ログ永続性」「JDBC TLogストア」に設定します。

  • 「JMSサーバー永続性」「JMS JDBCストア」に設定します。

「高可用性のオプション」画面でJMSとTLOGSの永続のためにJDBCを選択していなかった場合は、その後のステップでJDBCストアを手動で構成することもできます。手動で構成する際の具体的な手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

ノート:

「高可用性のオプション」画面は、自動サービス移行とJDBCストアの両方またはどちらかを使用するクラスタを初めて作成するときに、構成ウィザードのセッション中に表示されます。それ以降、構成ウィザードを使用してドメインに追加されるクラスタには、選択済のHAオプションが自動的に適用されます。

Oracle Service Busに対する自動サービス移行の有効化

Oracle Service Bus (OSB)が高可用性を実現するように構成するには、サービス移行に対応するようにOSBサーバーを構成する必要があります。

このガイドで静的クラスタと動的クラスタの両方に推奨されているように、「高可用性のオプション」画面で「データベース・リース」による「自動サービス移行の有効化」を選択した場合、自動サービス移行はすでに構成されています。このオプションを選択すると、データベース・リースが構成され、移行可能ターゲット(静的クラスタを使用している場合)または永続ストア(動的クラスタを使用している場合)がクラスタの適切な移行ポリシーで作成されます。

この設定を実装している場合は、「静的クラスタでの自動サービス移行の検証」の説明に従って構成を検証します。

構成ウィザードのセッション中に、このオプションを選択していない場合でも、その後のステップで自動移行を手動で構成できます。手順は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

ノート:

「高可用性のオプション」画面は、自動サービス移行とJDBCストアの両方またはどちらかを使用するクラスタを初めて作成するときに、構成ウィザードのセッション中に表示されます。それ以降、構成ウィザードを使用してドメインに追加されるクラスタには、選択済のHAオプションが自動的に適用されます。

構成のバックアップ

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

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

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。