| Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B66703-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B66703-04 |
|
前 |
次 |
この章では、Oracle Fusion Middleware構成ウィザードを使用して、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成されたドメインを拡張し、Oracle SOA SuiteコンポーネントとOracle WSM Policy Managerを含める方法について説明します。次の章の説明に従うと、作成されたドメインを拡張し、他のFusion Middlewareコンポーネントを追加できます。SOA Oracleホーム(バイナリ)がインストール済でSOAHOST1とSOAHOST2からアクセス可能であること、および管理サーバーが属するドメインが作成済であることを前提としています。この章では、このドメインを拡張して、Oracle SOA Suiteコンポーネントをサポートします。
|
注意: セットアップのプロセスを開始する前に、各プラットフォームのOracle Fusion Middlewareリリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。 |
この章の項目は次のとおりです。
Oracle WebLogic Serverドメインを拡張して、Oracle SOA Suiteコンポーネントを追加します。表9-1に、Oracle SOA Suiteの構成手順と、Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張に必要なタスクを示します。
表9-1 Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張の準備 |
各ホスト名でVIPマッピングを有効にし、Oracle SOA Suite WebLogic Serverクラスタのシステム・クロックを同期します。 |
第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」 |
|
Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張 |
第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogic Serverドメインを拡張します。 |
第9.3項「Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張」 |
|
コンポジットをデプロイするためのOracle Coherenceの構成 |
コンポジットのデプロイにユニキャスト通信を使用するためOracle Coherenceを構成します。 |
第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」 |
|
構成後タスクおよび検証タスクの実行 |
ホスト名の検証の無効化、ノード・マネージャの再起動、ドメイン構成の伝播、管理対象サーバーの起動と検証、GridLinkデータ・ソースの検証の手順に従います。 |
|
|
Oracle Web Services Manager (Oracle WSM)を実行しているすべてのサーバー間の、Javaオブジェクト・キャッシュ(JOC)の構成 |
Oracle WSMのパフォーマンスを向上させるためにローカル・キャッシュを構成します。 |
第9.6項「Oracle Web Services Manager用のJavaオブジェクト・キャッシュの構成」 |
|
拡張したドメインでのOracle HTTP Serverの構成 |
管理対象サーバーとともにOracle HTTP Serverを構成し、アクセスの検証、フロントエンドHTTPのホストおよびポートの設定およびSOA_ClusterのWebLogic Serverクラスタ・アドレスの設定を行います。 |
第9.7項「拡張したドメインでのOracle HTTP Serverの構成」 |
|
デフォルト永続ストアの構成 |
トランザクション・リカバリのためのデフォルトの永続ストアを構成します。 |
第9.8項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」 |
|
Oracleアダプタの構成 |
Oracleファイル・アダプタとFTPアダプタの高可用性を有効化し、Oracleデータベース・アダプタを構成します。 |
|
|
ドメインの管理対象サーバーとノード・マネージャ間通信に対するホスト名検証の構成 |
管理サーバーや他のサーバーとの通信には、それぞれのアドレス用の証明書を使用します。 |
第9.10項「WLS_SOA管理対象サーバー用のノード・マネージャの構成」 |
|
Oracle SOA Suite管理対象サーバー用のサーバー移行の構成 |
移行のためのOracle SOA Suite管理対象サーバー名、ホスト名およびクラスタ名を指定します。 |
第9.11項「WLS_SOA管理対象サーバー用のサーバー移行の構成」 |
|
Oracle SOA Suite構成のバックアップ |
新しく拡張したドメイン構成をバックアップします。 |
|
Oracle WebCenter Contentドメインでは、Oracle SOA Suiteの管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。まだ対応していない場合は、これらのホスト名を2つのSOAHOSTマシン(SOAHOST1のVIP2とSOAHOST2のVIP3)にマップして仮想IPを有効化し、トポロジで使用するネットワーク・システムの仮想ホスト名を(DNSサーバーまたは/etc/hosts解決によって)正しく解決する必要があります。
まだ仮想IPを有効化していない場合には、第3.5項「エンタープライズ・デプロイメント用の仮想IPアドレスの有効化」で説明している手順に従ってください。これらの仮想IPおよび仮想ホスト名は、Oracle SOA Suiteサーバーでサーバー移行を有効にするときに必要となります。この後、高可用性を実現するために、Oracle SOA Suiteサーバーのサーバー移行を構成できます。サーバー移行の構成の詳細は、第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。
構成ウィザードを使用して、Oracle Web Services ManagerおよびOracle SOA Suiteコンポーネントをサポートするために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成されたドメインを拡張します。
|
注意: 第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインをバックアップしていない場合は、Oracle SOA Suiteコンポーネントを使用するためのドメイン拡張を実行する前に、現在のドメインをバックアップします。ドメインの拡張時になんらかのエラーが発生した場合は、このバックアップを使用してリカバリできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。 |
Oracle SOA Suiteコンポーネントを使用するためにドメインを拡張する手順は次のとおりです。
リポジトリをインストールしたデータベースを実行していることを確認します。
Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。
ドメイン内のすべての管理対象サーバーを停止します。
SOAHOST1で、ディレクトリをOracle Fusion Middleware構成ウィザードの場所に変更します。これはOracle共通ホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行します)。
cd ORACLE_COMMON_HOME/common/bin
構成ウィザードを起動します。
./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
「WebLogicドメイン・ディレクトリの選択」画面で、WebLogic Serverドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name)を選択し、「次へ」をクリックします。
「拡張ソースの選択」画面(図9-1)で、次の手順を実行します。
「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。
次の製品を選択します。
Oracle SOA Suite - 11.1.1.0 [soa]
Oracle WSM Policy Manager - 11.1.1.0 [oracle_common] (Oracle SOA Suiteとともに自動的に選択)
次の製品はすでに選択されてグレー表示されています。これらはドメインを作成した際に選択されました(第8.3項)。
WebLogic Serverの基本ドメイン - 10.3.6.0 [wlserver_10.3]
Oracle Enterprise Manager - 11.1.1.0 [oracle_common]
Oracle JRF - 11.1.1.0 [oracle_common]
「次へ」をクリックします。
このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面(図9-2)で、次の手順を実行します。
「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」、OWSM MDSスキーマおよびSOA MDSスキーマの各行を選択します。
RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます(付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照)。ここでの説明に合せて、「GridLinkへ変換」を選択します。
RAC構成を選択すると、選択されたすべてのスキーマがグレー表示されます。
「次へ」をクリックします。
「GridLink RACコンポーネント・スキーマの構成」画面(図9-3)で、次の手順を実行します。
「SOAインフラストラクチャ」行のみを選択します。
図9-3 Oracle SOA Suiteの「GridLink RACコンポーネント・スキーマの構成」画面
次の各フィールドに値を入力して、RCUでシードされたGridLink RACデータベースの接続情報を指定します。
ドライバ: OracleのGridLink接続用のドライバ(Thin)、バージョン:10以降を選択します。
サービス名: Oracle RACデータベースのサービス名は小文字で入力し、ドメイン名を続けます(例: wccedg.mycompany.com)。
ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてDEVを使用しています。
パスワード: データベース・スキーマの所有者のパスワードを入力します。
「FANの有効化」を選択します。
SSLの有効化: このオプションは選択解除したままにします。
SSLを選択してOracle Notification Service (ONS)の通知暗号化を有効にする場合は、「ウォレット・ファイル」および「ウォレット・パスワード」の詳細を適切に指定します。
サービス・リスナー: 使用するOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。プロトコルはTCPである必要があります。
SCANアドレスを使用してサービス・リスナー(およびOSNホスト)を指定することをお薦めします。これにより、Oracle RACノードを追加または削除しても、SCANアドレスを含むGridLinkデータ・ソースを更新する必要がありません。SCANアドレスを特定するには、データベース内のremote_listenerパラメータを問い合せます。
SQL>show parameter remote_listener; NAME TYPE VALUE ----- ------ ------- remote_listener string db-scan.mycompany.com:1521
|
注意: Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。次に例を示します。 custdbhost1-vip.mycompany.com (port 1521) および custdbhost2-vip.mycompany.com (1521) Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データソースの使用」を参照してください。 |
ONSホスト: データベースによって報告されるRACデータベースのSCANアドレスとONSリモート・ポートも入力します。
[orcl@CUSTDBHOST2 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016
|
注意: Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。 custdbhost1.mycompany.com (port 6200) および custdbhost2.mycompany.com (6200) |
各データ・ソースを1つずつ選択し、適切な値のユーザー名とパスワードを入力します。
すべてのスキーマ(SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマ)で、すべての値が正しいことを確認し、「次へ」をクリックします。
|
注意: Oracle WSMポリシーを格納するには、Oracle Identity Management用のデータベースを使用することをお薦めします(第15章「Oracle Identity Managementとの統合」を参照)。そのため、(第3章「エンタープライズ・デプロイメント用のネットワークの準備」で推奨されるように)RCUでシードされたOracle Identity Managementデータベース情報を使用してWSMメタデータを格納し、この画面ではOWSM MDSスキーマ用にOracle Identity Managementデータベース情報が使用されることが予想されます。このデータベース接続情報は、その他のOracle SOA Suiteスキーマで使用されるものとは異なります。 |
「JDBCコンポーネント・スキーマのテスト」画面(図9-4)で、各スキーマを選択し、「接続のテスト」をクリックします。
結果は「接続結果ログ」に表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正してテストを再試行します。
すべての接続に成功したら「次へ」をクリックします。
「オプションの構成を選択」画面で、次のオプションを選択します。
JMS分散宛先
管理対象サーバー、クラスタ、およびマシン
デプロイメントとサービス
JMSファイル・ストア
「次へ」をクリックします。
「JMS分散宛先タイプの選択」画面で次の操作を行います。
UMSJMSystemResourceのドロップダウン・リストからUDDを選択します。
SOAJMSModuleのドロップダウン・リストからUDDを選択します。
BPMJMSModuleのドロップダウン・リストからUDDを選択します。
オーバーライドの警告が表示された場合、「OK」をクリックして、このメッセージを確認します。
「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
soa_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_SOA1に変更し、WLS_SOA2という新しいサーバーを追加します。表9-2に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは変更せず、そのままにしておきます。
表9-2 管理対象サーバー
| 名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
|
WLS_SOA1 |
SOAHOST1VHN1 |
8001 |
なし |
いいえ |
|
WLS_SOA2 |
SOAHOST2VHN1 |
8001 |
なし |
いいえ |
「次へ」をクリックします。
「クラスタの構成」画面で、表9-3に示すクラスタを追加します。
表9-3 クラスタ
| 名前 | クラスタ・メッセージング・モード | マルチキャスト・アドレス | マルチキャスト・ポート | クラスタ・アドレス |
|---|---|---|---|---|
|
SOA_Cluster |
ユニキャスト |
なし |
なし |
SOAHOST1VHN1:8001、SOAHOST2VHN1:8001 |
「次へ」をクリックします。
|
注意: 直接バインディングを介してリクエスト/レスポンスが非同期でやり取りされるようにするため、SOAコンポジットでは、JNDIプロバイダURLを提供して、呼び出されたサービスが、コールバックするBeanを検索できるようにする必要があります。 soa-infraの構成プロパティは指定されていないがWebLogic Serverクラスタ・アドレスが指定されている場合は、JNDIプロバイダURLのクラスタ・アドレスが使用されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名、または |
「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。
SOA_Cluster:
WLS_SOA1
WLS_SOA2
「次へ」をクリックします。
「マシンの構成」画面で、デフォルトで表示される「LocalMachine」を削除し、「Unixマシン」タブを開きます。マシンSOAHOST1およびSOAHOST2を追加して、最終的に次のような入力内容にします。
この画面に表示されている他の割当ては変更せず、そのままにしておきます。マシン名は有効なホスト名またはリスニング・アドレスである必要がない点に留意してください。これらはノード・マネージャの場所を示す一意の識別子です。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。
ADMINVHN
AdminServer
SOAHOST1:
WLS_SOA1
SOAHOST2:
WLS_SOA2
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定する必要があります(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。
WSM-PMはSOA_Clusterにのみターゲット設定する必要があります。
oracle.rules#*、oracle.sdp.*およびoracle.soa.*の各デプロイメントは、SOA_Clusterにのみターゲット設定する必要があります。
「次へ」をクリックします。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。
「JMSファイル・ストアの構成」画面で、第4.3項「各種ディレクトリの推奨場所について」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
「次へ」をクリックします。
「構成のサマリ」画面で、「拡張」をクリックします。
このドメインを拡張して、Oracle SOA Suiteコンポーネントを追加します。
「ドメインの拡張」画面で、「完了」をクリックします。
加えた変更を有効にするために管理サーバーを再起動します。
管理サーバーを再起動するには、最初に管理コンソールを使用してサーバーを停止し、第8.4.3項「SOAHOST1での管理サーバーの起動」の説明に従って再起動します。
コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、Oracle SOA Suiteエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。
ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるOracle SOA Suiteエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。
|
注意: デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、Oracle SOA Suiteシステムを起動できないことがあります。Oracle SOA Suiteシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。 |
tangosol.coherence.wkanシステム・プロパティを使用してノードを指定します(nは1から9の範囲の番号)。「Well Knownアドレス」として指定できるのは9ノードまでですが、クラスタには9ノードを超えるノードを含めることができます。番号は、1から開始します。この番号付けは、連続的で間隙を含まないようにする必要があります。
|
ヒント: Oracle SOA Suiteコンポジットのデプロイメント時の高可用性を保証するためには、十分なノードを指定して、いつでも最低1つのコンポジットが実行されているようにします。 |
また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、Oracle SOA Suiteサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHN1とSOAHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図9-5)。
|
注意: SOAHOST1VHN1は、SOAHOST1でWLS_SOA1がリスニングする仮想IPにマップされる仮想ホスト名です。SOAHOST2VHN1は、SOAHOST2でWLS_SOA2がリスニングする仮想IPにマップされる仮想ホスト名です。 |
図9-5 WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定
管理コンソールを使用して、Oracle Coherenceで使用するホスト名を追加します。
Oracle Coherenceで使用されるホスト名を指定する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
左側の「ドメイン構造」ツリーで「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページでサーバー名(WLS_SOA1またはWLS_SOA2)をクリックします。これらは、表の「名前」列にハイパーリンクで表示されています。
選択したサーバーの「設定」ページで、「ロックして編集」をクリックします。
「構成」タブで、「サーバーの起動」タブをクリックします(図9-5を参照)。
WLS_SOA1とWLS_SOA2について、「引数」フィールドに次のパラメータを入力します。
|
注意: 異なる |
WLS_SOA1について、改行を入れず、1行で次のように入力します。
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1
WLS_SOA2について、改行を入れず、1行で次のように入力します。
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1
|
注意: デプロイメントに使用されるCoherenceクラスタは、デフォルトでポート8088を使用します。このポートは、起動パラメータ
Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。 |
「保存」→「変更のアクティブ化」をクリックします。
|
注意:
|
構成ウィザードでドメインを拡張し、Oracle Coherenceを構成したら、次の手順に従って、構成後タスクと検証を行います。
この項の内容は次のとおりです。
このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_SOA1およびWLS_SOA2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.5項「ホスト名検証の無効化」を参照してください。
エンタープライズ・デプロイメントのトポロジ構成が完了したら、ホスト名検証を再び有効化します。詳細は、第13.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。
起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。
管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。
次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateSOA.jar -template_name=soa_domain_templateExtSOA
次のようにunpackコマンドをSOAHOST1上で実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -overwrite_domain=true -template=edgdomaintemplateSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
|
注意:
|
管理コンソールを介してWLS_SOA1管理対象サーバーを起動して、検証できます。
SOAHOST1でWLS_SOA1管理対象サーバーを起動する手順は次のとおりです。
次の手順に従い、WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。
管理コンソール(http://ADMINVHN:7001/console)にアクセスします。
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。
左側の「ドメイン構造」ツリーの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページで、「制御」タブを開きます。
「WLS_SOA1」を選択して、「起動」をクリックします。
管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.12項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。
次のURLにアクセスします。
http://SOAHOST1VHN1:8001/soa-infraにアクセスしてWLS_SOA1のステータスを確認します。
http://SOAHOST1VHN1:8001/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データ・ストアで使用できるポリシーとアサーション・テンプレートのリストが開きます。ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。
http://SOAHOST1VHN1:8001/integration/worklistappにアクセスしてワークリスト・アプリケーションのステータスを確認します。
SOAHOST1の構成が完了したら、unpackユーティリティを使用してSOAHOST2に構成を伝播し、伝播した構成を検証します。
ドメイン構成を伝播する手順は次のとおりです。
次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします
cd ORACLE_BASE/product/fmw/oracle_common/common/bin scp edgdomaintemplateSOA.jar oracle@SOAHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin
unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。
|
注意:
|
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
|
注意:
|
WLS_SOA2管理対象サーバーを起動すると、WebLogic Server管理コンソールおよびURLを介して管理対象サーバーのステータスを確認することにより、検証できます。
|
注意: WebLogic Server管理コンソールを使用してWLS_SOA2管理対象サーバーを起動する前に、ノード・マネージャが稼働していることを確認します。第16.8.1項「前提条件および手順」の手順3で、「SOAHOST2でノード・マネージャを起動」と説明しています。 ノード・マネージャが実行されていない場合は、第8.4.2項「SOAHOST1でのノード・マネージャの起動」の説明に従ってSOAHOST2で再起動します。 |
WLS_SOA2管理対象サーバーの起動と検証の手順は次のとおりです。
次の手順に従い、WebLogic Server管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。
左側の「ドメイン構造」ツリーの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページで、「制御」タブを開きます。
「WLS_SOA2」を選択して、「起動」をクリックします。
管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.12項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。
次のURLにアクセスします。
http://SOAHOST2VHN1:8001/soa-infraにアクセスしてWLS_SOA2のステータスを確認します。
http://SOAHOST2VHN1:8001/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データ・ストアで使用できるポリシーとアサーション・テンプレートのリストが開きます。
|
注意: ポリシーやアサーション・テンプレートがまったく表示されない場合は、構成が正しくありません。 |
http://SOAHOST2VHN1:8001/integration/worklistappにアクセスしてワークリスト・アプリケーションのステータスを確認します。
サーバーを起動したら、GridLinkデータ・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。
Oracle SOA SuiteのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。
作成したGridLinkデータ・ソースの名前をクリックします。
「監視」タブをクリックします。
「テスト」タブ(図9-6)をクリックし、いずれかのサーバーを選択し、「データ・ソースのテスト」をクリックします。
構成が適切であればテストは成功します。
GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスでテストを繰り返します。
Oracle SOA SuiteのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。
作成したGridLinkデータ・ソースの名前をクリックします。
「監視」タブをクリックします。
「ONS」タブをクリックし、「テスト」タブ(図9-7)をクリックします。
サーバーを選択し、「ONSのテスト」をクリックします。
構成が適切であればテストは成功します。ONSテストが失敗する場合は、Oracle RACデータベース・ノード内でONSサービスが稼動していることを確認します。
[orcl@CUSTDBHOST1 ~]$ srvctl status scan_listener SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node CUSTDBHOST1 SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node CUSTDBHOST2 SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node CUSTDBHOST2 [orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016 [orcl@CUSTDBHOST1 ~]$ srvctl status nodeapps | grep ONS ONS is enabled ONS daemon is running on node: CUSTDBHOST1 ONS daemon is running on node: CUSTDBHOST2
GridLinkデータ・ソースを使用するすべてのWebLogic ServerインスタンスでONSテストを繰り返します。
Oracle Web Services Manager (Oracle WSM)を実行しているすべてのサーバー間に、Javaオブジェクト・キャッシュ(JOC)を構成する必要があります。このローカル・キャッシュは、Oracle WSMのパフォーマンスを向上させるために用意されています。Javaオブジェクト・キャッシュは、MW_HOME/oracle_common/bin/configure-joc.pyスクリプトを使用して構成できます。これはPythonスクリプトであり、管理対象サーバーでJOCを構成するために使用できます。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが稼働中であることが求められます。
Oracle製品のJOCポートを構成する場合は、9988から9998の範囲のポートを使用することをお薦めします。
|
注意: WLSTコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成した後で、構成を有効にするために、影響を受ける管理対象サーバーをすべて再起動する必要があります。 |
Oracle WSMのJavaオブジェクト・キャッシュを構成する手順は次のとおりです。
コマンドラインのOracle WebLogic Scripting Tool (WLST)を次のように使用して、管理サーバーに接続します。
MW_HOME/oracle_common/common/bin/wlst.sh
$ connect()
プロンプトが表示されたら、WebLogic Server管理者のユーザー名、パスワード、サーバーURL (t3://ADMINVHN:7001)を入力します。
WLSTを使用して管理サーバーに接続後、execfileコマンドを使用してスクリプトを開始します。たとえば、次のようにします。
wls:/domain_name/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")
特に、エンタープライズ・デプロイメント環境では、手順2で1つ目のクラスタ・オプションを使用する必要があります。EDG環境でconfigure-joc.pyを使用するための処理手順を示します(次のスクリプト入力パラメータのテキストを参照)。
Execfile("MW_HOME/oracle_common/bin/configure-joc.py").
Enter Hostnames (eg host1,host2) : SOAHOST1VHN1,SOAHOST2VHN1
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : SOA_Cluster
.
Enter Discover Port : 9991
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n
WLSTコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成した後で、構成を有効にするために、影響を受ける管理対象サーバーをすべて再起動します。
また、『Oracle Fusion Middleware高可用性ガイド』の説明に従って、WebLogic Server管理コンソールで「HAパワー・ツール」タブを使用してJavaオブジェクト・キャッシュ(JOC)を構成することもできます。
スクリプト入力パラメータ
入力パラメータは、スクリプトによって求められます。このスクリプトを使用すると、次のようなJOC構成を実行できます。
特定のクラスタで指定したすべての管理対象サーバーに対してJOCを構成します。クラスタ名を指定するかどうかを尋ねるスクリプト・プロンプトが表示されたらyを入力し、プロンプトに従ってクラスタ名および検出ポートを指定します。これによって、指定したクラスタの管理対象サーバーがすべて検出され、JOCが構成されます。検出ポートはクラスタのJOC構成全体で共通です。次に例を示します。
Do you want to specify a cluster name (y/n) <y> Enter Cluster Name : SOA_Cluster Enter Discover Port : 9991
指定されたすべての管理対象サーバーに対してJOCを構成します。クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたらnを入力し、プロンプトが表示されたら管理対象サーバーと検出ポートを指定します。次に例を示します。
Do you want to specify a cluster name (y/n) <y>n Enter Managed Server and Discover Port (eg WLS_SOA1:9991, WLS_SOA21:9991) : WLS_SOA1:9999,WLS_SOA2:9999
この例では、指定した管理対象のサーバー(WLS_SOA1およびWLS_SOA2)用のJOCのみが構成されます。検出ポートは管理対象サーバーとともに指定します(WLS_SOA1:2222など)。
特定の管理対象サーバーのJOC構成を除外します。スクリプトでは、JOC構成のDistributeModeがfalseに設定される管理対象サーバーのリストを指定できます。一部のサーバーをJOC構成から除外するかどうかを尋ねられたらyを入力し、プロンプトが表示されたら除外する管理対象サーバーの名前を入力します。次に例を示します。
Do you want to exclude any server(s) from JOC configuration (y/n) <n>y Exclude Managed Server List (eg Server1,Server2) : WLS_SOA1,WLS_SOA2
すべての管理対象サーバーに対して分散モードを無効にします。スクリプトにより、指定されたクラスタのすべての管理対象サーバーに対して分散を無効化できます。分散モードを指定するように求められたら、falseを指定します。デフォルトでは、分散モードはtrueに設定されています。
ドメイン構成をSOAHOST2に伝播した後、拡張したドメインでOracle HTTP Serverを構成します。
この項の内容は次のとおりです。
WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。
WEBHOST1およびWEBHOST2上の各Webサーバーで、ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/soainternal_vh.confファイルおよびORACLE_INSTANCE/config/OHS/ohs2/moduleconf/soainternal_vh.confファイルに次の行を追加します。
# WSM-PM
<Location /wsm-pm>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
# SOA soa-infra app
<Location /soa-infra>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
# SOA inspection.wsil
<Location /inspection.wsil>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
# Worklist
<Location /integration/>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
# UMS prefs
<Location /sdpmessaging/userprefs-ui>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
# Default to-do taskflow
<Location /DefaultToDoTaskFlow/>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
# Workflow
<Location /workflow>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
#SOA Composer
<Location /soa/composer>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。
ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohsX
ias-componentに対して、WEBHOST1ではohs1を使用し、WEBHOST2ではohs2を使用します。
WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このノードのリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。
次に例を示します。
例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時にその場で検出されます。
例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのメンバーをすべてリストに記述した場合は、Oracle HTTP Serverの起動時にそのうちの1つ以上を実行しておくことで、クラスタに確実に到達できます。
WebLogic Serverプラグインの構成の詳細は、『Oracle WebLogic ServerでWeb Serverプラグインを使用するOracle Fusion Middlewareのガイド』を参照してください。
Oracle SOA SuiteサーバーをホスティングするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。
WebLogicサーバーの管理コンソールにログインします。
「チェンジ・センター」セクションに移動して、「ロックして編集」をクリックします。
左側の「ドメイン構造」ツリーの「環境」ノードを開きます。
「クラスタ」をクリックします。
「サーバーのサマリー」ページで、「SOA_Cluster」を選択します。
「HTTP」タブを開きます。
次の値を設定します。
フロントエンド・ホスト: soainternal.mycompany.com
フロントエンドHTTPポート: 80
「保存」をクリックします。
管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
WLS_SOA1およびWLS_SOA2の管理対象サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効にします。
管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.12項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」を参照してください。
次のURLを使用し、SOA_clusterにアクセスできることを検証します。
http://soainternal.mycompany.com/soa-infra
http://soainternal.mycompany.com/integration/worklistapp
http://soainternal.mycompany.com/sdpmessaging/userprefs-ui
http://soainternal.mycompany.com/soa/composer
http://soainternal.mycompany.com/wsm-pm
ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。
|
注意: 第8.5.3項「WebLogic ServerへのOracle HTTP Serverの登録」の説明に従ってOracle HTTP Serverを登録すると、そのOracle HTTP Serverは管理可能なターゲットとしてOracle Enterprise Managerコンソールに表示されます。これを確認するには、Oracle Enterprise Managerコンソールにログインします。ナビゲーション・ツリーのWeb層の項目にOracle HTTP Serverが登録されていることが示されます。 |
各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。
|
注意: デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。 |
デフォルトの永続ストアの場所を設定する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
このページの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
左側の「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)サーバー名WLS_SOA1をクリックします。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
「構成」タブ、「サービス」タブ(トップレベルの「サービス」タブではありません)を順にクリックします。
表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs/
WLS_SOA2サーバーについて手順4、5、6を繰り返します。
「保存」→「変更のアクティブ化」をクリックします。
WLS_SOA1およびWLS_SOA2管理対象サーバーを再起動します。
WLS_SOA1とWLS_SOA2を再起動した後、次のディレクトリに次のDATファイルが作成されていることを確認します。
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs/
_WLS_WLS_SOA1000000.DAT
_WLS_WLS_SOA2000000.DAT
|
注意: トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリは存在する必要があります。 |
Oracleファイル、FTPおよびデータベース・アダプタを、拡張したOracle SOA Suiteドメイン用に構成します。
この項の内容は次のとおりです。
|
注意: この手順はオプションで、起動されるBPELプロセスのアダプタのサポートを必要とするデプロイメントにのみ適用されます。 |
OracleファイルおよびFTPアダプタを使用すると、ローカル・ファイル・システムやリモート・ファイル・システムのファイルをFTP(ファイル転送プロトコル)を使用してBPELプロセスまたはOracle Mediatorで読取りまたは書込みできるようになります。これらのアダプタは、Oracle BPEL Process ManagerおよびOracle Mediatorサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能を、インバウンドおよびアウトバウンドの両方の操作でサポートしています。Oracleファイル・アダプタとFTPアダプタがアウトバウンド操作に対する高可用性を備えるようにするには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作での高可用性に関する項で説明されているデータベースのmutexロック操作を使用します。データベースのmutexロック操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。
|
注意: ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、Oracle RACバックエンドまたはOracle SOA Suite管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。 |
データベース表をコーディネータとして使用し、アウトバウンドのOracleファイルやFTPアダプタのサービスに高可用性を実現するには、WebLogic Server管理コンソールで、eis/HAFileAdapterに対応するconnection-instanceのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更する必要があります。
|
注意: データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトの値を大きくする必要があります。 |
データベースのmutexロック操作を使用する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。コンソールにアクセスするには、http://server_name:port_number/consoleに移動します。
左側の「ドメイン構造」ツリーの「デプロイメント」をクリックします。
右ペインの「デプロイメントの概要」で「FileAdapter」をクリックします。
「構成」タブを開きます。
「アウトバウンド接続プール」タブを開き、「javax.resource.cci.ConnectionFactory」を開いて、構成済接続ファクトリを表示します。
「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」画面が開きます。図9-8に示すように、接続ファクトリのプロパティが表示されます。
図9-8 WebLogic Server管理コンソール - 「javax.resource.cci.ConnectionFactoryの設定」ページ
「ロックして編集」をクリックします。これにより、プロパティ値の列が編集可能になります(「プロパティ値」列で任意の行を選択してその値を変更できます)。
変更した値を反映させるには、変更した「プロパティ値」列に対応する行をクリックし、キーボードの[Enter]キーを押します。[Enter]キーを押さなければ、値は保存されません。
Oracleファイル・アダプタとFTPアダプタの接続ファクトリの新しいパラメータは次のとおりです。
controlDir: 制御ファイルを格納するディレクトリ構造に設定します。1つのクラスタの中で複数のWebLogic Serverインスタンスを実行する場合は、この値を共有場所に設定する必要があります。この共有記憶域のディレクトリは次のような構造にします。
ORACLE_BASE/admin/domain_name/cluster_name/fadapter/
inboundDataSource: jdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。事前に作成されたスキーマは、ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。別のスキーマを選択した場合は、それに応じてinboundDataSourceプロパティを設定する必要があります。
outboundDataSource: 値をjdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。事前に作成されたスキーマは、ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。その場合は、outboundDataSourceプロパティを設定する必要があります。
outboundLockTypeForWrite: Oracle Databaseを使用している場合は、この値をoracleに設定します。デフォルトでは、Oracleファイル/FTPアダプタは、メモリー内mutexを使用してアウトバウンドの書込み操作をロックします。書込み操作を同期化するには、次の値のいずれかを選択する必要があります。
memory: OracleファイルとFTPアダプタはメモリー内mutexを使用してファイル・システムへのアクセスを同期化します。
oracle: アダプタは、Oracleデータベース・シーケンスを使用します。
db: アダプタは事前作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用している場合にのみ使用します。
user-defined: アダプタはユーザー定義のmutexを使用します。ユーザー定義mutexを構成するには、mutexインタフェース(oracle.tip.adapter.file.Mutex)を実装し、名前がoracle.tip.adapter.file.mutexで、アウトバウンド参照のmutexの完全修飾クラス名の値を指定した新規バインディング・プロパティを構成する必要があります。
|
注意: FTPアダプタで使用可能なパラメータは、接続ファクトリの場合とは少し異なりますが、高可用性の観点からすると、重要なのは、共有記憶域の場所への制御ディレクトリの設定のみです。 |
これらのプロパティを更新した後、「保存」をクリックします。
「デプロイメント・プランの保存」ページで、デプロイメント・プランの共有記憶域の場所を入力します。そのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/cluster_name/dp/Plan.xml
「保存してアクティブ化」をクリックします。
一度新しいデプロイメント・プランを保存してアクティブ化すると、FileAdapterデプロイメントをアクティブ化します(まだ開始されていないデプロイメントのステータスは「準備完了」です)。FileAdapterデプロイメント・プランをアクティブ化する手順は次のとおりです。
管理コンソールで、左側の「ドメイン構造」ツリーの「デプロイメント」をクリックします。
右ペインの「デプロイメントのサマリー」でFileAdapterを選択し、「起動」→「すべてのリクエストを処理」を選択します。
次の例のように、接続ファクトリが使用されるようにBPELプロセスまたはMediatorシナリオを構成します。
<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>
|
注意:
|
|
注意: この手順はオプションで、BPELプロセスのアダプタのサポートを必要とするデプロイメントにのみ適用されます。 |
論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。以前は、複数のOracle BPEL Process ManagerまたはOracle Mediatorノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするための基本的なベスト・プラクティスは、ポーリング・ノードごとに一意のMarkReservedValueを指定してLogicalDeletePollingStrategyまたはDeletePollingStrategyを使用し、MaxTransactionSizeを設定することでした。ただし、Oracle Fusion Middleware 11gリリース1 (11.1.2.0)でロックのスキップが導入されたため、そのアプローチは破棄されました。以前にこのアプローチを使用していた場合は、単にMarkReservedValue属性を(db.jca内で)削除するか、または(「論理削除」ウィザードページで)クリアすることによって、自動的にロッキングのスキップを使用できるようになります。
予約された値に対してロックのスキップを使用することには、次のような利点があります。
ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。
(更新/予約の次にコミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。
一意のMarkReservedValueを指定する必要はありません。以前は、そのようにするためには、R${weblogic.Name-2}-${IP-2}-${instance}のように、複雑な変数を構成することが必要でした。
詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティとポーリング計画に関する項を参照してください。
ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第13章「ノード・マネージャの設定」を参照してください。その章の手順は、次に示す情報を使用して、2回実行する必要があります。
| 実行 | ホスト名(HOST) | 仮想IP(VIP) | サーバー名(WLS_SERVER) |
|---|---|---|---|
|
Run 1: |
SOAHOST1 |
SOAHOST1VHN1 |
WLS_SOA1 |
|
Run 2: |
SOAHOST2 |
SOAHOST2VHN1 |
WLS_SOA2 |
サーバー移行は、SOAHOST1ノードとSOAHOST2ノードのどちらかで障害が発生した場合に、Oracle SOA Suiteコンポーネントを正しくフェイルオーバーするために必要です。詳細は、第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。Oracle SOA Suiteに関しては、その章で次の変数の値を使用します。
サーバー名:
WLS_SERVER1: WLS_SOA1
WLS_SERVER2: WLS_SOA2
ホスト名:
HOST1: SOAHOST1
HOST2: SOAHOST2
クラスタ名:
CLUSTER: SOA_Cluster
拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。
この時点でインストールをバックアップする手順は次のとおりです。
WEBHOST1でWeb層をバックアップする手順は次のとおりです。
opmnctlを使用してインスタンスを停止します。
ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
次のコマンドをroot権限で実行して、Web層のMiddlewareホームをバックアップします。
tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
次のコマンドを使用して、Web層のOracleインスタンスをバックアップします。
tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE
opmnctlを使用してインスタンスを起動します。
cd ORACLE_BASE/admin/instance_name/bin opmnctl startall
データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。
ドメイン構成を保存するために、管理サーバーと管理対象サーバーのドメイン・ディレクトリをバックアップします。構成ファイルはすべて、ORACLE_BASE/admin/domain_nameディレクトリにあります。SOAHOST1で次のコマンドを実行して、バックアップを作成します。
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
