| Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B66703-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B66703-02 |
|
前 |
次 |
この章では、Oracle Fusion Middleware構成ウィザードを使用して、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成されたドメインを拡張し、Oracle SOA SuiteコンポーネントとOracle WSM Policy Managerを含める方法について説明します。次の章の説明に従うと、作成されたドメインを拡張し、他のFusion Middlewareコンポーネントを追加できます。SOA Oracleホーム(バイナリ)がインストール済でSOAHOST1とSOAHOST2からアクセス可能であること、および管理サーバーが属するドメインが作成済であることを前提としています。この章では、このドメインを拡張して、Oracle SOA Suiteコンポーネントをサポートします。
|
注意: セットアップ・プロセスを開始する前に、リリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。これらは、Oracle Fusion Middlewareドキュメント・ライブラリ( |
この章の項目は次のとおりです。
WebLogicドメインを拡張して、Oracle SOA Suiteコンポーネントを追加します。表9-1に、Oracle SOA Suiteの構成手順と、Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張に必要なタスクを示します。
表9-1 Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張の準備 |
各ホスト名でVIPマッピングを有効にし、SOA WebLogic Serverクラスタのシステム・クロックを同期します。 |
第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」 |
|
Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張 |
第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogicドメインを拡張します。 |
第9.3項「構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張」 |
|
コンポジットをデプロイするためのOracle Coherenceの構成 |
コンポジットのデプロイにユニキャスト通信を使用するためOracle Coherenceを構成します。 |
第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」 |
|
構成後タスクおよび検証タスクの実行 |
構成後タスクおよび検証タスクの手順に従います。 |
|
|
GridLinkデータ・ソースおよびOracle Notification Service (ONS)の構成の確認 |
GridLinkデータ・ソースおよびONSの構成が適切であることを確認する手順に従います。 |
|
|
SOAHOST2へのドメイン構成の伝播 |
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。 |
|
|
拡張したドメインでのOracle HTTP Serverの構成 |
管理対象サーバーとともにOracle HTTP Serverを構成し、アクセスの検証、フロントエンドHTTPのホストおよびポートの設定およびSOA_ClusterのWebLogic Serverクラスタ・アドレスの設定を行います。 |
第9.7項「WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成」 |
|
デフォルト永続ストアの構成 |
トランザクション・リカバリのためのデフォルトの永続ストアを構成します。 |
第9.10項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」 |
|
Oracleアダプタの構成 |
ファイル用のOracle JCAアダプタおよびFTP用のOracle JCAアダプタの高可用性を有効化し、JMS用のOracle JCAアダプタの高可用性を有効化し、データベース用のOracle JCAアダプタをスケーリングします。 |
第9.12項「Oracleデータベース・アダプタのスケーリング」 |
|
Oracle SOA Suite構成のバックアップ |
新しく拡張したドメイン構成をバックアップします。 |
|
この手順は、WLS_SOA1およびWLS_SOA2のサーバー移行に必要です。WLS_SOA1およびWLS_SOA2サーバーを仮想ホスト名(SOAHOST1VHN1およびSOAHOST2VHN1)に関連付けます。これらの仮想ホスト名がDNSまたはシステム内の/etc/hosts解決で有効になっていること、およびそれらが適切なVIP(VIP2およびVIP3)にマップされていることを確認します。
仮想IPを有効にするには、root権限で次のようにifconfigコマンドを実行します。
/sbin/ifconfig interface:index IP_address netmask netmask /sbin/arping -q -U -c 3 -I interface IP_address
次に例を示します。
/sbin/ifconfig ethX:Y 100.200.140.205 netmask 255.255.255.0
次の例のように、ネットワークで仮想IPの新しい場所を登録できるようにします。
/sbin/arping -q -U -c 3 -I ethX 100.200.140.205
別のノードからこのアドレスをpingして、このアドレスが使用可能であることを検証します。次の例を示します。
/bin/ping 100.200.140.205
|
注意: これらの例において、 |
Oracle Fusion Middleware構成ウィザードを使用して、Oracle Web Services ManagerおよびOracle SOA Suiteコンポーネントをサポートするために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成されたドメインを拡張します。
|
注意: 第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインをバックアップしていない場合は、Oracle SOA Suiteコンポーネントを使用するためのドメイン拡張を実行する前に、現在のドメインをバックアップします。ドメインの拡張時になんらかのエラーが発生した場合は、このバックアップを使用してリカバリできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。 |
構成ウィザードを使用してドメインを拡張する手順は次のとおりです。
リポジトリをインストールしたデータベースを実行していることを確認します。
Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。
ドメイン内のすべての管理対象サーバーを停止します。
SOAHOST1で、ディレクトリをOracle Fusion Middleware構成ウィザードの場所に変更します。これはOracle共通ホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行します)。
cd ORACLE_COMMON_HOME/common/bin
構成ウィザードを起動します。
./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリ(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ポリシーを格納するには、アイデンティティ管理用のデータベースを使用することをお薦めします(第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を選択します。
オーバーライドの警告が表示された場合、「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コンポーネントを追加します。
「ドメインの拡張」画面で、「完了」をクリックします。
加えた変更を有効にするために管理サーバーを再起動します。
コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、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 Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、Oracle SOA Suiteサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHN1とSOAHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図9-5)。
|
ヒント: Oracle SOA Suiteコンポジットのデプロイメント時の高可用性を保証するためには、十分なノードを指定して、いつでも最低1つのコンポジットが実行されているようにします。 |
|
注意: SOAHOST1VHN1は、SOAHOST1でWLS_SOA1がリスニングする仮想IPにマップされる仮想ホスト名です。SOAHOST2VHN1は、SOAHOST2でWLS_SOA2がリスニングする仮想IPにマップされる仮想ホスト名です。 |
図9-5 WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定
Oracle Coherenceで使用されるホスト名を指定する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページでサーバー名(WLS_SOA1またはWLS_SOA2)をクリックします。これらは、表の「名前」列にハイパーリンクで表示されています。
選択したサーバーの「設定」ページで、「ロックして編集」をクリックします。
「構成」タブを開いて、「サーバーの起動」タブを開きます。
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
|
注意: 前述のすべての引数を1行で入力します。つまり、管理コンソールのJava引数フィールドに改行を入れないでください。また、前述のテキストをコピーして管理コンソールの引数テキスト・フィールドに貼り付けないでください。これによって、余分な文字がJava引数に挿入されてしまう可能性があります。テキストには、前述のもの以外のテキストや文字を含めることはできません。 |
デプロイメントに使用されるCoherenceクラスタは、デフォルトでポート8088を使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。次に例を示します。
WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.localport=8089
WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.localport=8089
「保存」→「変更のアクティブ化」をクリックします。
|
注意: これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります(これらの変数はサーバーの出力ログに記録されます)。Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。 |
|
注意: このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。Oracle SOA Suiteでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。 |
構成ウィザードでドメインを拡張し、Oracle Coherenceを構成したら、次の手順に従って、構成後タスクと検証を行います。
この項の内容は次のとおりです。
このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。そのため、WLS_SOAn管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverを管理するときにエラーが出ないようにします。エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第13.3項「ノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。
ホスト名検証を無効化するには:
WebLogic Server管理コンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページで、表の「名前」列にあるWLS_SOA1を選択します。
サーバーの設定ページで「SSL」タブを開きます。
表示されたページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
変更を保存してアクティブ化します。
この変更内容を有効にするには、管理サーバーおよびノード・マネージャを再起動する必要があります。
管理サーバーを再起動する手順は、第8.4.4項「SOAHOST1での管理サーバーの起動」を参照してください。
SOAHOST1でノード・マネージャを再起動するには、第9.5.2項「SOAHOST1でのノード・マネージャの再起動」を参照してください。
startNodeManager.shスクリプトを使用してノード・マネージャを再起動します。
SOAHOST1でノード・マネージャを再起動する手順は次のとおりです。
ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。
シェルのフォアグラウンドで実行されている場合は、[Ctrl]キーを押しながら[C]を押します。
シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、killコマンドを使用して停止します。例:
ps -ef | grep NodeManager orcl 9139 9120 0 Mar03 pts/6 00:00:00 /bin/sh ./startNodeManager.sh kill -9 9139
ノード・マネージャを起動します。
./startNodeManager.sh
WLS_SOA1およびWLS_SOA2の構成が終了し、管理サーバーおよび管理対象サーバーを起動した後、作成したすべてのGridLinkデータ・ソースが適切に構成されており、各管理対象サーバーで各データ・ソースのOracle Notification Service (ONS)設定が適切であることを確認します。
Oracle SOA SuiteのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。
作成したGridLinkデータ・ソースの名前をクリックします。
「監視」タブをクリックし、いずれかのサーバーの名前をクリックします。
「テスト」タブ(図9-6)をクリックし、いずれかのサーバーを選択し、「データ・ソースのテスト」をクリックします。
構成が適切であればテストは成功します。
GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスでテストを繰り返します。
Oracle SOA SuiteのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。
作成した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テストを繰り返します。
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。
起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。
管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。
次の一連のコマンドを使用し、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
|
注意: unpackコマンドで |
WLS_SOA1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:
次の手順に従い、WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。
http://ADMINVHN:7001/consoleで管理コンソールにアクセスします。
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」を選択します。
「サーバーのサマリー」ページで、「制御」タブを開きます。
「WLS_SOA1」を選択して、「起動」をクリックします。
管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.11項「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に構成を伝播し、伝播した構成を検証します。
この項の内容は次のとおりです。
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管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」を選択します。
「サーバーのサマリー」ページで、「制御」タブを開きます。
「WLS_SOA2」を選択して、「起動」をクリックします。
管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.11項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。
次のURLにアクセスします。
http://SOAHOST2VHN1:8001/soa-infraにアクセスしてWLS_SOA2のステータスを確認します。
http://SOAHOST2VHN1:8001/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データ・ストアで使用できるポリシーとアサーション・テンプレートのリストが開きます。
|
注意: ポリシーやアサーション・テンプレートがまったく表示されない場合は、構成が正しくありません。 |
http://SOAHOST2VHN1:8001/integration/worklistapp/にアクセスしてワークリスト・アプリケーションのステータスを確認します。
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()
プロンプトが表示されたら、サーバーURL、Oracle WebLogicの管理ユーザー名およびパスワードを入力します。
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
また、『Oracle Fusion Middleware高可用性ガイド』の説明に従って、Oracle WebLogic管理コンソールで「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に設定されています。
WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。
WEBHOST1とWEBHOST2で、ORACLE_BASE/ admin/instance_name/config/OHS/component_name/mod_wl_ohs.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>
mod_wl_ohsファイルと同じディレクトリに格納されているhttpd.confファイルに、次の行が記述されていることを確認します。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName https://wcc.mycompany.com:443 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit </VirtualHost> NameVirtualHost *:7777 <VirtualHost *:7777> ServerName admin.mycompany.com:80 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit </VirtualHost> NameVirtualHost *:7777 <VirtualHost *:7777> ServerName soainternal.mycompany.com:80 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit</VirtualHost>
|
注意: ここで挙げているwcc.mycompany.com:443、admin.mycompany.com:80、you@youraddressなどの値は、単なる例です。これらのかわりに、実際の環境に基づいた値を入力してください。 |
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 Server管理コンソールにログインします。
「チェンジ・センター」セクションに移動して、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「クラスタ」をクリックします。
「サーバーのサマリー」ページで、「SOA_Cluster」を選択します。
「HTTP」タブを開きます。
次の値を設定します。
フロントエンド・ホスト: soainternal.mycompany.com
フロントエンドHTTPポート: 80
「保存」をクリックします。
管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効にします。
管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.11項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。
(WEBHOST1およびWEBHOST2の両方に対して)次のURLを使用し、Oracle HTTP ServerからWSM_Clusterを検証します。
http://WEBHOSTn:7777/soa-infra
http://WEBHOSTn:7777/integration/worklistapp
http://WEBHOSTn:7777/sdpmessaging/userprefs-ui
http://WEBHOSTn:7777/soa/composer
http://WEBHOSTn:7777/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サーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)サーバー名をクリックします。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
「構成」内の「サービス」タブを開きます(トップレベルの「サービス」タブではありません)。
「ロックして編集」をクリックします。
表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
変更を保存してアクティブ化します。
WLS_SOA1およびWLS_SOA2管理対象サーバーを再起動します。
|
注意: トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。 |
|
注意: この手順はオプションで、起動されるBPELプロセスのアダプタのサポートを必要とするデプロイメントにのみ適用されます。 |
OracleファイルとFTPアダプタを使用すると、BPELプロセスやOracle MediatorでFTP(ファイル転送プロトコル)を使用して、ローカルとリモートのファイル・システムにあるファイルの読取りと書込みができます。これらのアダプタは、インバウンドとアウトバウンドの両方の操作に対し、Oracle BPEL Process ManagerとOracle Mediatorサービス・エンジンを使用してアクティブ/アクティブ・トポロジの高可用性をサポートします。Oracle File AdapterとOracle FTP Adapterがアウトバウンド操作に対する高可用性を備えるようにするには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作での高可用性に関する項で説明されているデータベースのmutexロック操作を使用します。データベースのmutexロック操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。
|
注意: ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、Oracle RACバックエンドまたはOracle SOA Suite管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。 |
データベース表をコーディネータとして使用し、アウトバウンドのOracleファイルやFTPアダプタ・サービスの高可用性を実現するには、Oracle WebLogic Serverコンソールで、eis/HAFileAdapterに対応するconnection-instanceのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更する必要があります。
|
注意: データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトの値を大きくする必要があります。 |
データベースのmutexロック操作を使用する手順は次のとおりです。
Oracle WebLogic Serverコンソールにログインします。コンソールにアクセスするには、http://server_name:port_number/consoleに移動します。
「ドメイン構造」の左ペインで「デプロイメント」をクリックします。
右ペインの「デプロイメントの概要」で「FileAdapter」をクリックします。
「構成」タブを開きます。
「アウトバウンド接続プール」タブを開き、「javax.resource.cci.ConnectionFactory」を開いて、構成済接続ファクトリを表示します。
「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」画面が開きます。図9-8に示すように、接続ファクトリのプロパティが表示されます。
図9-8 Oracle WebLogic Serverコンソール - 「javax.resource.cci.ConnectionFactoryの設定」ページ
「ロックして編集」をクリックします。これにより、プロパティ値の列が編集可能になります(「プロパティ値」列で任意の行を選択してその値を変更できます)。
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
「保存してアクティブ化」をクリックします。
次の例のように、接続ファクトリが使用されるように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>
|
注意: location属性は、接続ファクトリの |
|
注意: この手順はオプションで、起動される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層のミドルウェア・ホームをバックアップします。
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
