| Oracle® Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1.8.3) B55900-10 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1.8.3) B55900-10 |
|
前 |
次 |
この章では、構成ウィザードを使用して、SOAコンポーネントを扱うことができるようにドメインを拡張する方法を説明します。ドメインは第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成しました。
|
注意: SOAHOST1とSOAHOST2でSOAコンポーネントを実行する場合にのみ、この章の手順に従ってください。WebCenter PortalトポロジでSOAコンポーネントを実行しない場合は、この章は省略できます。 |
この章には次のトピックが含まれます:
Oracle SOAコンポーネントを追加するためのWebLogicドメインを拡張します。表9-1に、Oracle SOAの構成手順と、Oracle SOAコンポーネントを使用するためのドメインの拡張に必要なタスクを示します。
表9-1 SOAコンポーネントを使用するためのドメインの拡張の手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
SOAコンポーネントを使用するためのドメインの拡張の準備 |
各ホスト名のVIPマッピングを有効化します。 |
第9.2.1項「SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化」 |
|
SOAコンポーネントを使用するためのドメインの拡張 |
第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogicドメインを拡張します。 |
第9.3項「構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張」 |
|
コンポジットをデプロイするためのOracle Coherenceの構成 |
コンポジットのデプロイにユニキャスト通信を使用するためOracle Coherenceを構成します。 |
第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」 |
|
構成後タスクおよび検証タスク |
構成後タスクおよび検証タスクの手順に従います。 |
|
|
SOAHOST1へのドメイン構成の伝播 |
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。 |
第9.5.3項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」 |
|
拡張したドメインでのOracle HTTP Serverの構成 |
管理対象サーバーとともにOracle HTTP Serverを構成し、アクセスの検証、フロントエンドHTTPのホストおよびポートの設定およびSOA_ClusterのWLSクラスタ・アドレスを設定します。 |
第9.6項「拡張したドメインでのOracle HTTP Serverの構成」 |
|
デフォルト永続ストアの構成 |
トランザクション・リカバリのためのデフォルトの永続ストアを構成します。 |
第9.7項「トランザクション・リカバリ用デフォルト永続ストアの構成」 |
|
Oracleアダプタの構成 |
OracleファイルおよびFTPアダプタの高可用性およびOracle JMSアダプタの高可用性を有効化し、Oracle Databaseアダプタをスケーリングします。 |
|
|
SOA構成のバックアップ |
新しく拡張したドメイン構成をバックアップします。 |
|
構成ウィザードを実行し、ドメインを拡張する前に、2つのSOAマシン上で各ホスト名のVIPマッピングを有効化します。
この項には次のトピックが含まれます:
Oracle WebCenter Portalドメインでは、Oracle SOA Suite管理対象サーバー用リスニング・アドレスに仮想ホスト名を使用します。2つのSOAマシンでそれぞれのホスト名の仮想IPマッピングを有効にして(SOAHOST1上のVIP2およびSOAHOST2上のVIP3)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーまたは/etc/hosts/解決のいずれかで)正しく解決する必要があります(まだこの作業を行っていない場合)。
仮想IPを有効にするには(まだこの作業を行っていない場合)、第3.5項「エンタープライズ・デプロイメント用の仮想IPアドレスの有効化」に記載されている手順を実行します。これらの仮想IPおよびVHNは、Oracle SOA Suiteサーバーからのサーバーの移行を有効にするために必要です。高可用性を実現するために、後からSOAシステムに対するサーバーの移行を構成できます。サーバーの移行の構成の詳細は、第14章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。
構成ウィザードを使用して、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを、SOAコンポーネントを使用できるように拡張します。
この項では、SOAデプロイメントが、WebCenter Portalデプロイメントと同じデータベース・サービス(wcpedg.mycompany.com)を使用することを前提としています。ただし、デプロイメントではSOA専用の別のデータベース・サービス(soaedg.mycompany.comなど)の使用を選択することもできます。
|
注意: 第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインをバックアップしていない場合は、SOAコンポーネントを使用するためにドメインを拡張する前に、現在のドメインをバックアップします。ドメインの拡張時になんらかのエラーが発生した場合は、このバックアップを使用してリカバリできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。 |
構成ウィザードを使用してドメインを拡張する手順は次のとおりです。
構成ウィザードの場所にディレクトリを変更します。これはSOAHOST1上のSOAホーム・ディレクトリ内にあります。
すべてのデータベース・インスタンスを起動しておくことをお薦めします。
cd ORACLE_BASE/product/fmw/soa/common/bin
構成ウィザードを開始します。
./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
「WebLogicドメイン・ディレクトリ」画面で、次のWebLogicドメイン・ディレクトリを選択します。
ORACLE_BASE/admin/domain_name/aserver/domain_name
「次へ」をクリックします。
「拡張ソースの選択」画面で、次の手順を実行します。
「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。
次の製品を選択します。
Oracle SOA Suite 11.1.1.0
次の製品はすでに選択されてグレー表示されています。これらは、第8.3項「SOAHOST1での構成ウィザードによるドメインの作成」の手順でドメインを作成したときに選択されたものです。
WebLogic Serverの基本ドメイン
Oracle Enterprise Manager
Oracle WSM Policy Manager
Oracle JRF
「次へ」をクリックします。
このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。
「SOAインフラストラクチャ」→「ユーザー・メッセージング・サービス」→SOA MDSスキーマを選択します。
コンポーネント・スキーマのRAC構成については、「GridLinkへ変換」を選択します。
RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます。後者のオプションについては、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
「次へ」をクリックします。
「GridLink RACコンポーネント・スキーマの構成」画面で(図9-1)、次の手順を実行します。
表で「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」および「SOA MDSスキーマ」を選択します。
次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 10以上を選択します。
サービス名: データベースのサービス名と、続けてドメイン名を小文字で入力します。たとえば、wcpedg.mycompany.comです。
FANの有効化: このオプションを選択します。
SSLの有効化: このオプションを選択解除します。
Oracle Notification Service (ONS)の通知の暗号化するためにSSLが選択されている場合は、「ウォレット・ファイル」と「ウォレット・パスワード」に適切な詳細を入力します。
サービス・リスナー: 使用しているOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。このプロトコルは、TCPである必要があります。
Oracle RACノードの追加または削除時にSCANアドレスを含むGridLinkデータ・ソースを更新する必要がないよう、サービス・リスナー(とOSNホスト)の指定にはSCANアドレスを使用することをお薦めします。SCANアドレスを判断するには、データベースに対してremote_listenerパラメータを問い合せます。
SQL>show parameter remote_listener; NAME TYPE VALUE ----- ------ ------- remote_listener string db-scan.mycompany.com:1521
|
注意: データベース・バージョンがSCANをサポートしない場合は次を実行します。
|
ONSホスト: データベースからの通知のとおり、Oracle RACデータベースのSCANアドレスとONSリモート・ポートを入力します。
[orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016
|
注意: Oracle Database 11gリリース1 (11.1)の場合、データベースのONSサービスのホスト名とポートを入力します。例:
および
|
「SOAインフラストラクチャ」のみを選択し、このデータベース・スキーマのユーザー名とパスワードを入力します。
ユーザー名: 対応するコンポーネントのデータベースのスキーマ所有者の完全な名前(接頭辞を含む)を入力します。接頭辞は第5.4項「Oracle RACデータベースへのOracle Fusionメタデータ・リポジトリのロード」で作成したものと一致する必要があります。
パスワード: データベース・スキーマ所有者のパスワードを入力します。
「ユーザー・メッセージング・サービス」、「SOA MDSスキーマ」には、手順cを繰り返します。
すべてのSOAスキーマの値が正しい場合、(「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」および「SOA MDSスキーマ」)、「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、すべての接続が正常であることを確認します。
接続のテストは自動的に行われます。「ステータス」列に結果が表示されます。正常でない接続がある場合は、「前へ」をクリックして前の画面に戻り、入力を訂正します。
すべての接続に成功したら「次へ」をクリックします。
「オプションの構成を選択」画面で、次の項目を選択します。
JMS分散宛先
管理対象サーバー、クラスタ、およびマシン
デプロイメントとサービス
JMSファイル・ストア
「次へ」をクリックします。
「JMS分散宛先タイプの選択」画面で、すべてのJMSシステム・リソースがUDDとして構成されていることを確認します。これがデフォルトです。
「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
soa_server1というサーバーが自動的に作成されます。
自動的に作成されたサーバーを選択し、「名前の変更」をクリックして、名前を「WLS_SOA1」に変更します。
「追加」をクリックし他の新規サーバーを追加して、サーバー名として「WLS_SOA2」と入力します。
WLS_SOA1およびWLS_SOA2サーバーに、表9-2内の属性を指定します。この画面に表示されている他のサーバーは変更せず、そのままにしておきます。
表9-2 管理対象サーバー
| 名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
|
WLS_SOA1 |
SOAHOST1VHN1 |
8001 |
該当なし |
いいえ |
|
WLS_SOA2 |
SOAHOST2VHN1 |
8001 |
該当なし |
いいえ |
|
WLS_WSM1 |
SOAHOST1 |
7010 |
該当なし |
いいえ |
|
WLS_WSM2 |
SOAHOST2 |
7010 |
該当なし |
いいえ |
「次へ」をクリックします。
「クラスタの構成」画面で、次のクラスタを追加します。
表9-3 クラスタ
| 名前 | クラスタ・メッセージング・モード | マルチキャスト・アドレス | マルチキャスト・ポート | クラスタ・アドレス |
|---|---|---|---|---|
|
SOA_Cluster |
ユニキャスト |
該当なし |
該当なし |
SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 |
|
WSM-PM_Cluster |
ユニキャスト |
該当なし |
該当なし |
空白のままにします。 |
「次へ」をクリックします。
|
注意: 直接バインディングを介してリクエスト/レスポンスが非同期でやり取りされるようにするため、SOAコンポジットでは、JNDIプロバイダURLを提供して、呼び出されたサービスが、コールバックするBeanを検索できるようにする必要があります。 soa-infraの構成プロパティは指定されていないがWebLogic Serverクラスタ・アドレスが指定されている場合は、JNDIプロバイダURLのクラスタ・アドレスが使用されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名を指定することも、サーバーip:portのカンマ区切りリストを指定することもできます。また、ユーザーが明示的に設定していれば、soa-infraの構成プロパティ |
「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。
SOA_Cluster:
WLS_SOA1
WLS_SOA2
WSM-PM_Cluster:
WLS_WSM1
WLS_WSM2
「次へ」をクリックします。
「マシンの構成」画面で、デフォルトで表示されるLocalMachineを削除し、「Unixマシン」タブをクリックします。
次のエントリが表示されます(表9-4)。
その他すべてのフィールドはデフォルト値のままにします。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。
ADMINHOST:
AdminServer
SOAHOST1:
WLS_SOA1
WLS_WSM1
SOAHOST2:
WLS_SOA2
WLS_WSM2
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定します。(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです。)
oracle.sdp.*およびoracle.soa.*ライブラリは、SOA_Clusterにのみターゲット設定します。
oracle.rules.*ライブラリは、管理サーバーおよびSOA_Clusterにのみターゲット設定します。
wsm-pmアプリケーションは、WSM-PM_Clusterにターゲット設定します。
(Oracle Web Services ManagerをSOA_Clusterにデプロイする予定である場合は、wsm-pmアプリケーションをSOA_Clusterにもターゲット設定します。)
「次へ」をクリックします。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
mds-owsmをWSM-PM_ClusterとAdminServerの両方のターゲットとします。
(手順17でOracle Web Services ManagerをSOA_Clusterにデプロイした場合は、mds-owsmもSOA_Clusterにターゲット設定します。)
「次へ」をクリックします。
「JMSファイル・ストアの構成」画面で、第4.3項「各種ディレクトリの推奨場所」での推奨に従ってJMSストアに指定した共有ディレクトリの場所を入力します。例:
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
「次へ」をクリックします。
「構成のサマリー」画面で「拡張」をクリックします。
|
注意: ドメイン構成ポートがホスト・ポートと競合していることを警告するダイアログが表示されますが、「OK」をクリックして閉じてください。この警告は、すでにインストールされているWSM-PMが原因で表示されます。 |
「ドメインの拡張」画面で、「完了」をクリックします。
管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で再起動します。
コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。
ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。
|
注意: デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムを実行するネットワーク環境に応じて、デプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。 |
tangosol.coherence.wka<n>システム・プロパティを使用してノードを指定します。<n>は、1から9の数字です。Well Knownアドレスとして最大9ノードまで指定できますが、クラスタには10以上のノードを作成できます。番号は、1から開始します。この番号付けは、連続的で間隙を含まないようにする必要があります。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHN1とSOAHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図9-2)。
|
ヒント: SOAコンポジットのデプロイ時に高可用性を確保するには、適切な数のノードを指定して、どの時点でもそのうちのいずれかが必ず稼働しているようにします。 |
|
注意: SOAHOST1VHN1は、SOAHOST1でWLS_SOA1がリッスンする仮想IPにマップされる仮想ホスト名です。SOAHOST2VHN1は、SOAHOST2でWLS_SOA2がリッスンする仮想IPにマップされる仮想ホスト名です。 |
図9-2 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定
管理コンソールを使用して、Oracle Coherenceで使用するホスト名を指定します。
Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列にハイパーリンクで表示されているサーバーの名前(WLS_SOA1またはWLS_SOA2)をクリックします。選択したサーバーの「設定」ページが表示されます。
「ロックして編集」をクリックします。
「サーバーの起動」タブをクリックします(図9-2を参照)。
WLS_SOA1とWLS_SOA2について、「引数」フィールドに次の値を入力します。
|
注意: 異なる-Dパラメータの間には、空白の行を入れないでください。テキストは、前述の場所からコピーして管理コンソールの引数テキスト・フィールドに貼り付けないでください。貼り付けると、Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。 |
|
注意: デプロイメントに使用される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.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力): -Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 Coherenceクラスタの詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のCoherenceクラスタの使用に関する説明を参照してください。 |
WLS_SOA1については次の値を入力します。
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1
WLS_SOA2については次の値を入力します。
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1
「保存」→「変更のアクティブ化」をクリックします。
|
注意: これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります。(これらの変数はサーバーの出力ログに記録されます。)Oracle Coherenceフレームワークに問題があると、 |
|
注意: このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。 |
構成ウィザードでドメインを拡張し、Oracle Coherenceを構成したら、次の手順に従って、構成後タスクと検証を行います。
この項には次のトピックが含まれます:
このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。様々なWebLogicサーバーを管理するときにエラーが発生しないように、WLS_SOAn管理対象サーバーのホスト名検証を無効化する必要があります。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。
エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第11.5項「SOAHOST2およびWCPHOST2でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。
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
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。
起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。
管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。
次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=soadomaintemplateExtSOA.jar -template_name=soadomaintemplateExtSOA
|
注意: 前回のpack/unpack処理からの指定されたテンプレート・パック |
次のようにunpackコマンドをSOAHOST1上で実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -overwrite_domain=true -template=soadomaintemplateExtSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
|
注意:
|
|
注意: WLS_WSMサーバーが実行されている場合、ポートの競合を示すメッセージが表示されることがあります。この警告を無視して続行できます。 |
管理コンソールを使用してWLS_SOA1管理対象サーバーを起動して、検証します。
SOAHOST1でWLS_SOA1管理対象サーバーを起動する手順は次のとおりです。
次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。
次のURLの管理コンソールにアクセスします。
http://ADMINVHN:7001/console
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」画面が表示されます。
「制御」タブをクリックします。
「WLS_SOA1」を選択して、「起動」をクリックします。
サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。
次のURLにアクセスして、WLS_SOA1のステータスを確認します。
http://SOAHOST1VHN1:8001/soa-infra/
次のURLにアクセスして、ワークリスト・アプリケーションのステータスを確認します。
http://SOAHOST1VHN1:8001/integration/worklistapp/
次のURLにアクセスして、コンポーザ・アプリケーションのステータスを確認します。
http://SOAHOST1VHN1:8001/soa/composer/
アクセスが許可されていることを確認する前に、少なくとも1つの管理対象サーバー(WLS_WSM1またはWLS_WSM2)が稼働していることを確認します。
unpackユーティリティを使用して、構成したドメインをSOAHOST2に伝播します。
ドメイン構成を伝播する手順は次のとおりです。
次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします。
cd ORACLE_COMMON_HOME/common/bin scp soadomaintemplateExtSOA.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin
unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/ -template=soadomaintemplateExtSOA.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
|
注意:
|
|
注意: このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。 |
uploadおよびstageディレクトリを更新します。詳細な手順は、第8.5.2項「uploadおよびstageディレクトリの絶対パスへの変更」を参照してください。
管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。soa-infraおよびworklistappのURLにアクセスして検証します。
WLS_SOA2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:
管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。
管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。
次のURLでsoa-infraにアクセスします。
http://SOAHOST2VHN1:8001/soa-infra
次のURLにアクセスして、worklistappアプリケーションのステータスを確認します。
http://SOAHOST2VHN1:8001/integration/worklistapp/
アクセスが許可されていることを確認する前に、少なくとも1つの管理対象サーバー(WLS_WSM1またはWLS_WSM2)が稼働していることを確認します。
|
注意: WLS_SOA2サーバーが稼働していても、一部のアプリケーションが失敗した状態になることがあります。そのため、前述のURLを検証し、個別のアプリケーションに関するエラーがないか、サーバーの出力ファイルで確認することをお薦めします。 |
次のURLにアクセスして、composerアプリケーションのステータスを確認します。
http://SOAHOST2VHN1:8001/soa/composer/
サーバーが開始したら、GridLinkデータ・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたGridLinkデータ・ソースごとにこの手順を実行します。
Oracle SOA SuiteのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
作成済のGridLinkデータ・ソース名をクリックします。
「監視」タブをクリックします。
「テスト」タブをクリックし、WLS_SOA1を選択し、「データ・ソースのテスト」をクリックします(図9-3)。
構成が正しい場合、テストは成功します。
GridLinkデータ・ソースを使用する各SOA管理対象サーバーに、テストを繰り返します。
Oracle SOA SuiteのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
作成済のGridLinkデータ・ソース名をクリックします。
「監視」タブをクリックします。
「ONS」タブをクリックし、「テスト」タブ(図9-4)をクリックします。
「WLS_SOA1」を選択し、「ONSのテスト」をクリックします。
構成が正しい場合、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データ・ソースを使用する各管理対象サーバーに、ONSテストを繰り返します。
ドメイン構成をSOAHOST2に伝播した後、拡張したドメインでOracle HTTP Serverを構成します。
この項には次のトピックが含まれます:
WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。
Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。
WEBHOST1とWEBHOST2上で、例9-1で太字で示したディレクティブを、次のディレクトリにあるwcp_vh.confファイルに追加します。
ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
第7.6項「仮想ホストの定義」の指示に従って、wcp_vh.confファイルを作成している必要があります。
wcp_vh.confファイルは例9-1のように表示されます。
例9-1 wcp_vh.confファイル
<VirtualHost *:7777>
ServerName https://wcp.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# UMS prefs
<Location /sdpmessaging/userprefs-ui>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# SOA composer application
<Location /soa/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>
同様に、例9-2に太字で示したディレクティブを、同じ場所にあるwcpinternal_vh.confファイルに追加します。
wcpinternal_vh.confファイルは、例9-2のように表示されます。
例9-2 wcpinternal_vh.confファイル
<VirtualHost *:7777>
ServerName wcpinternal.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
</Location>
# Worklist
<Location /integration>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>
# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>
</VirtualHost>
WEBHOST1およびWEBHOST2で、Oracle HTTP Serverを再起動します。
WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=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 Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』を参照してください。
管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。
次のロード・バランサURLを検証し、Oracle HTTP ServerからSOA_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。
http://webhostN:7777/soa-infra
http://webhostN:7777/integration/worklistapp
http://webhostN:7777/sdpmessaging/userprefs-ui
http://webhostN:7777/soa/composer
ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。
この項では、フロントエンドHTTPのホストとポートを管理コンソールを使用して設定する手順を示します。コールバックURLがどのように決定されるかについても説明します。
Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定する手順は次のとおりです。
WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。
左ペインの「ドメイン構造」ウィンドウで「環境」を選択し、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。
SOA_Clusterクラスタを選択します。
「HTTP」を選択します。
次の値を設定します。
フロントエンド・ホスト: wcp.mycompany.com
フロントエンドHTTPSポート: 443
フロントエンドHTTPポート: 80
「保存」をクリックします。
変更を有効にするために、管理コンソールの「チェンジ・センター」セクションの「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。
|
注意: ロード・バランサでHTTPSが有効になっており、SSLがロード・バランサで終了する場合(SOAサーバーはHTTPSではなくHTTPリクエストのみを受信します)、ここに示しているように、Webサービスのエンドポイント・プロトコルは (javax.xml.soap.SOAPException: oracle.j2ee.ws.saaj.ContentTypeException) この例外を解決するには、URLエンドポイントを更新します。 Enterprise Managerの「テスト」ページで、エンドポイントURLの編集を確認します。 「エンドポイントURL」ページで、次の操作を実行します。
|
この項では、SOAシステムでコールバックURLがどのように決定されるかについて説明します。
SOAへのリクエストが外部または内部のサービスから発行された場合、SOAはクライアントで指定されたコールバックURLを使用します。
外部または内部の非同期サービスへのリクエストがSOAから送られると、コールバックURLは次のように、優先度の高い順に決定されます。
特定の参照用のバインド・プロパティとして指定されたcallbackServerURLを使用します(このプロパティは、コンポジットのモデリング時または実行時にMBeansを使用して設定できます)。これにより、サービス呼び出しごとに異なるコールバックURLを割り当てることができます。つまり、外部サービスからのコールバックURLには、内部サービスへのコールバックURLとは異なる値を設定できます。エンタープライズ・デプロイメント・アーキテクチャでの一般的なコールバックURLは、外部サービスについてはwcp.mycompany.com (443/https)、内部サービスについてはwcpinternal.mycompany.com (7777/http)です。このプロパティは、システムMBeanブラウザに対応するバインドmbeanを通じ、実行時にシステムMBeanブラウザを使用して設定します。特定のURLを追加するには、そのProperties属性にcallbackServerURLプロパティを追加してから保存操作を実行します。
soa-infra-config.xmlで指定したコールバックURLを使用します。この場合、指定できるアドレスは1つのみです。外部サービスと内部サービスの両方を組み合せて呼び出し可能な場合は、エンタープライズ・デプロイメント・アーキテクチャでこのアドレスをwcp.mycompany.com (443/https)に設定する必要があります。内部サービスのみを呼び出す場合は、このアドレスをwcpinternal.mycompany.com (7777/http)に設定します。
SOA_ClusterのWLSで指定するフロントエンド・ホストとして、このコールバックURLを使用します。この場合も指定できるアドレスは1つのみなので、soa-infra-config.xmlの場合と同じ処理をお薦めします。
WLS MBean APIで指定されたローカル・ホスト名を使用します。これは、エンタープライズ・デプロイメントのような高可用性環境ではお薦めしません。
各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。
|
注意: デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。 |
デフォルトの永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーWLS_SOA1の名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。
「構成」タブをクリックしてから「サービス」タブをクリックします(トップレベルの「サービス」タブではありません)。
表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
WLS_SOA2サーバーについて、手順3、4、5、6を繰り返します。
「保存」→「変更のアクティブ化」をクリックします。
WLS_SOA1およびWLS_SOA2管理対象サーバーを再起動します。
WLS_SOA1とWLS_SOA2が再起動した後、次のディレクトリに次のファイルが作成されていることを確認します。
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
_WLS_WLS_SOA1000000.DAT
_WLS_WLS_SOA2000000.DAT
|
注意: トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。 |
Oracleファイル、FTPおよびデータベース・アダプタを、拡張したSOAドメイン用に構成します。
この項には次のトピックが含まれます:
OracleファイルおよびFTPアダプタを使用すると、ローカル・ファイル・システムやリモート・ファイル・システムのファイルをFTP(ファイル転送プロトコル)を使用してBPELプロセスまたはOracle Mediatorで読取りまたは書込みできるようになります。これらのアダプタは、Oracle BPEL Process ManagerおよびOracle Mediatorサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能を、インバウンドおよびアウトバウンドの両方の操作でサポートしています。Oracleファイル・アダプタとFTPアダプタがアウトバウンド操作に対する高可用性を備えるようにするには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作での高可用性に関する項で説明されているデータベースのmutexロック操作を使用します。データベースのmutex lock操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。
|
注意: 前述の操作は、これらのアダプタがアプリケーションで必要になる場合にのみ実行する必要があります。 |
|
注意: ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。 |
データベース表をコーディネータとして使用して、アウトバウンドのOracleファイルやFTPアダプタのサービスに高可用性を実現します。
|
注意: FTPアダプタの手順および構成オプションは、フィルタ・アダプタのオプションと完全に同じです。FTP HAの構成に使用する接続ファクトリは、FTPアダプタ・デプロイメントのアウトバウンド接続プールの下に表示される |
|
注意: データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトを増やします。 |
アウトバウンドのOracleファイルやFTPアダプタの高可用性を実現するには、Oracle WebLogic Server管理コンソールで、eis/HAFileAdapterに対応するconnection-instanceのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。
Oracle WebLogic Serverコンソールにログインします。コンソールにアクセスするには、次のURLにナビゲートします。
http://servername:portnumber/console
「ドメイン構造」の左ペインで「デプロイメント」をクリックします。
右ペインの「デプロイメントのサマリー」で「FileAdapter」をクリックします。
「構成」タブをクリックします。
「アウトバウンド接続プール」タブをクリックして「javax.resource.cci.ConnectionFactory」を開き、構成済の接続ファクトリを表示します。
「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。
図9-5に示すように、接続ファクトリのプロパティが表示されます。
図9-5 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プロパティを設定する必要があります。
outboundDataSourceLocal: jdbc/SOALocalTxDataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。
outboundLockTypeForWrite: Oracle Databaseを使用している場合は、この値をoracleに設定します。デフォルトでは、OracleファイルとFTPアダプタはインメモリーmutexを使用してアウトバウンドの書込み操作をロックします。書込み操作を同期化するには、次の値のいずれかを選択する必要があります。
memory: OracleファイルとFTPアダプタはインメモリーmutexを使用してファイル・システムへのアクセスを同期化します。
oracle: アダプタは、Oracle Databaseシーケンスを使用します。
db: アダプタは事前作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用している場合にのみ使用します。
user-defined: アダプタはユーザー定義のmutexを使用します。ユーザー定義のmutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutexを実装し、新しいバインド・プロパティoracle.tip.adapter.file.mutexを構成して、その値にアウトバウンド参照のmutexの完全修飾クラス名を指定します。
これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。
デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/cluster_name/dp/Plan.xml
「保存してアクティブ化」をクリックします。
一度新しいデプロイメント・プランを保存してアクティブ化すると、FileAdapterデプロイメントをアクティブ化します(まだ開始されていないデプロイメントのステータスは「準備完了」です)。FileAdapterデプロイメント・プランをアクティブ化する手順は次のとおりです。
管理コンソールの「ドメイン構造」の左ペインで「デプロイメント」をクリックします。
右ペインの「デプロイメントのサマリー」でFileAdapterを選択し、「起動」→「すべてのリクエストを処理」を選択します。
(オプション)次の例のように、(バインディング・コンポーネントのjcaファイル内で)接続ファクトリが使用されるように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>
|
注意:
|
Oracle JMSアダプタがクラスタ内の複数のサーバーと通信する場合、アダプタの通信ファクトリのプロパティFactoryPropertiesに使用可能なサーバーがリストされている必要があります。サーバーがリストされない場合、ランダムな1サーバーとの接続が確立されます。そのサーバーが停止しても、追加のメッセージは処理されません。
アダプタのJCA接続ファクトリを確認する手順は次のとおりです。
次のURLを使用して、Oracle WebLogic Server管理コンソールにログインします。
http://servername:portnumber/console
「ドメイン構造」の左ペインで「デプロイメント」をクリックします。
右ペインの「デプロイメントのサマリー」でJMSAdapterをクリックします。
「構成」タブをクリックします。
「アウトバウンド接続プール」タブをクリックしてoracle.tip.adapter.jms.IJmsConnectionFactoryを開き、構成済の接続ファクトリを表示します。
使用中の特定のインスタンス(例: eis/wls/Queue)をクリックします。接続ファクトリの「アウトバウンド接続のプロパティ」が開きます。
「ロックして編集」をクリックします。
FactoryPropertiesフィールドで(「プロパティ」値の該当するセルをクリックして)、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory; java.naming.provider.url=t3://soahostvhn1:8001,soahost2vhn1:8001;java.naming.security.principal=weblogic; java.naming.security.credentials=myPassword1
これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。
デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/cluster_name/dp/Plan.xml
「保存してアクティブ化」をクリックします。
コンソールでデプロイメントを更新します。
「デプロイメント」をクリックしてJMSアダプタを選択します。
「ロックして編集」をクリックし、「更新」をクリックします。
新規デプロイメント・プランの変更(デプロイメント・プランはこのオプションで指定)を含め、このアプリケーションの「更新」を選択し、共有記憶域の場所に保存されたデプロイメント・プランを選択すると、クラスタ内のすべてのサーバーは、このプランにアクセス可能になります。
「終了」をクリックします。
変更をアクティブ化します。
ロックのスキップ機能の導入により、これまでの最善の方法であった、各ポーリング・ノードでLogicalDeletePollingStrategyまたはDeletePollingStrategyと一意のMarkReservedValueを使用し、MaxTransactionSizeを設定する方法は使用できなくなりました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)選択解除するだけで、ロックが自動的にスキップされるようになります。
予約された値に対してロックのスキップを使用することには、次のような利点があります。
ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。
(更新/予約の次にコミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。
一意のMarkReservedValueを指定する必要がありません。以前は、そのようにするためには、R${weblogic.Name-2}-${IP-2}-${instance}のように、複雑な変数を構成することが必要でした。
論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。
以前は、複数のOracle BPEL Process ManagerノードまたはOracle Mediatorノードにデプロイする複数のOracle Databaseアダプタ・プロセス・インスタンスにおける最善の手法は、基本的に、ポーリング・ノードごとに一意のMarkReservedValueを設定し、さらにMaxTransactionSizeを設定して、LogicalDeletePollingStrategyまたはDeletePollingStrategyを使用することでした。
ただし、ロックのスキップが導入されたことによって、このアプローチは現在使用されなくなりました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)選択解除するだけで、ロックが自動的にスキップされるようになります。
詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティに関する項とポーリング戦略に関する項を参照してください。
拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。
ドメイン構成をバックアップする手順は次のとおりです。
Web層をバックアップする手順は次のとおりです。
opmnctlを使用してインスタンスを停止します。
ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。
tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。
tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
opmnctlを使用してインスタンスを起動します。
ORACLE_BASE/admin/instance_name/bin/opmnctl startall
データベースのバックアップを取ります。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。
管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。
ORACLE_BASE/admin/domain_name
管理サーバーをバックアップするには、SOAHOST1で次のコマンドを実行します。
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
