| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-07 |
|
前 |
次 |
この章では、Oracle Service Busを追加するためのドメイン拡張の手順を説明します。
この章の項目は次のとおりです。
この項では、SOAドメインへのOracle Service Busの追加について概説します。表11-1は、Oracle Service Busを使用するためのSOAドメイン拡張の大まかな手順と説明を示しています。
表11-1 Oracle Service Busを追加するためのSOAドメインの拡張手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
SOAHOST1でのVIP5およびSOAHOST2でのVIP6の有効化 |
2つのSOAマシン上でこれらの各ホスト名の仮想IPマッピングを有効化します。 |
第11.2項「SOAHOST1でのVIP5およびSOAHOST2でのVIP6の有効化」 |
|
ドメイン拡張のための構成ウィザードの実行 |
Oracle Service Busコンポーネントを追加するためにSOAドメイン拡張します |
第11.3項「SOAHOST1での構成ウィザードを使用したOracle Service Busを追加するためのSOAドメインの拡張」 |
|
WLS_OSBn管理対象サーバーに対するホスト名検証の無効化 |
管理サーバー、管理対象サーバーおよびノード・マネージャの間のホスト名を検証するための適切な証明書を設定していない場合、ホスト名検証を無効化します。 |
第11.4項「WLS_OSBn管理対象サーバーに対するホスト名検証の無効化」 |
|
Oracle Service Busの結果キャッシュのOracle Coherenceの構成 |
Oracle Service Busの結果キャッシュでユニキャスト通信を使用します。 |
第11.5項「Oracle Service Busの結果キャッシュのOracle Coherenceの構成」 |
|
トランザクション・リカバリのためのデフォルトの永続ストアの構成 |
クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。 |
第11.6項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」 |
|
SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播 |
Oracle Service Busでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。 |
第11.7項「SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播」 |
|
Oracle Service Busサーバーの起動 |
Oracle Service Busサーバーは既存のドメインを拡張します。そのため、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。 |
第11.8項「Oracle Service Busサーバーの起動」 |
|
WLS_OSB管理対象サーバーの検証 |
管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認し、URLにアクセスしてサーバーのステータスを確認します。 |
|
|
WLS_OSBn管理対象サーバーについてのOracle HTTP Serverの構成 |
Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。 |
第11.10項「WLS_OSBn管理対象サーバーについてのOracle HTTP Serverの構成」 |
|
OSB_Clusterに対するフロントエンドHTTPのホストおよびポートの設定 |
Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定します。 |
第11.11項「OSB_Clusterに対するフロントエンドHTTPのホストおよびポートの設定」 |
|
Oracle HTTP Serverを介したアクセスの検証 |
サーバーのステータスが「実行中」であることを確認します。 |
第11.12項「Oracle HTTP Serverを使用したアクセスの検証」 |
|
OracleファイルとFTPアダプタの高可用性化 |
OracleファイルとFTPアダプタのアウトバウンド操作に対する高可用性を、データベースのmutexロック操作を使用して実現します。 |
第11.13項「Oracle DB、ファイルおよびFTPのアダプタの高可用性化」 |
|
WLS_OSBサーバーのサーバー移行の構成 |
Oracle Service Busシステムの高可用性アーキテクチャでは、一部のシングルトン・サービスを障害から保護するためにサーバー移行を利用します。 |
第11.14項「WLS_OSBサーバーのサーバー移行の構成」 |
現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。
インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームおよびドメインをバックアップするには、次のコマンドをSOAHOST1で実行します。
tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name
これらのコマンドにより、Oracle WebLogic ServerとOracle Fusion Middlewareの両方のインストール・ファイルのバックアップ、およびドメイン構成が作成されます。
WL_HOMEとMW_HOME (バイナリ)が共有記憶域にインストールされており、SOAHOST1とSOAHOST2からアクセスできます。
前の章の説明のとおり、SOAシステムを実行するために、ノード・マネージャ、管理サーバー、SOAサーバーおよびWSMサーバーがすでに構成されています。サーバー移行、トランザクション・ログ、一貫性など、SOAシステムのその他のすべての構成手順が完了しています。
SOAドメインは、Oracle Service Bus管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのSOAマシンでそれぞれのホスト名の仮想IPマッピングを有効にして(SOAHOST1上のVIP5およびSOAHOST2上のVIP6)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバー、ホスト解決のいずれかで)正しく解決します。
仮想IPを有効にするには、第8.2項「SOAHOST1でのVIP1の有効化」で説明している手順に従ってください。これらの仮想IPおよびVHNは、Oracle Service Busサーバーのサーバー移行を有効にするために必要です。Oracle Service Busクラスタで高可用性を実現するために、サーバー移行を構成する必要があります。Oracle Service Busサーバーのサーバー移行の構成の詳細は、第11章のサーバー移行に関する項を参照してください。
この手順では、第9項「SOAコンポーネントを使用するためのドメインの拡張」で作成したドメインを、Oracle Service Busを扱うことができるように拡張します。Oracle Service Busを追加して管理サーバーとWSM-PMクラスタのみを含むドメインを拡張する場合の手順は、この項で説明する手順とほぼ同じになりますが、画面に表示される一部のオプション、ライブラリ、コンポーネントは実際に表示されるものと異なる場合があります。
Oracle Service Busを使用するためのドメイン拡張手順は次のとおりです。
ディレクトリを構成ウィザードの場所に変更します。これはOracle Service Busディレクトリ内にあります。(すべてのデータベース・インスタンスを稼働しておく必要があります。)
cd ORACLE_COMMON_HOME/common/bin
構成ウィザードを起動します。
./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
「WebLogicドメイン・ディレクトリ」画面で、WebLogicドメイン・ディレクトリを選択します。
ORACLE_BASE/admin/domain_name/aserver/domain_name
「次へ」をクリックします。
「拡張ソースの選択」画面で、「次の追加製品をサポートするために、自動的にドメインを拡張する」を選択して、次の製品を選択します(Oracle SOAおよびOracle WSM Policy Managerで必要となるコンポーネントはすでに選択されてグレー表示になっています)。
Oracle Service Bus OWSM Extension - 11.1.1.6 [osb]
Oracle Service Bus - 11.1.1.0 [osb]
WebLogic Advance Web Services JAX-RPC Extension
「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。
OSB JMSレポート・プロバイダ・スキーマを選択します。
「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。
「次へ」をクリックします。「GridLink RACコンポーネント・スキーマの構成」画面が表示されます。
「GridLink RACコンポーネント・スキーマの構成」画面で、ドメイン内にすでに存在するデータ・ソースに対する値を受け入れ、「次へ」をクリックします。
「JDBCコンポーネント・スキーマのテスト」画面で、Oracle Service Bus JMSレポート・データ・ソースが正常に検証されたことを確認し、「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
JMS分散宛先
管理対象サーバー、クラスタ、およびマシン
デプロイメントとサービス
JMSファイル・ストア
「次へ」をクリックします。
「JMS分散宛先タイプの選択」画面で、すでに存在するJMSシステム・リソースはそのままにしておき、WseeJMSMOduleおよびJmsResourcesにはドロップダウン・リストからUDDを選択します。
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、Oracle Service Busで必要な管理対象サーバーを追加します。
自動的に作成されたサーバーを選択し、「名前の変更」をクリックして、名前をWLS_OSB1に変更します。
「追加」をクリックし他の新規サーバーを追加して、サーバー名としてWLS_OSB2と入力します。
WLS_OSB1およびWLS_OSB2サーバーに、表11-2内の属性を指定します。
最終的に、管理対象サーバーのリストは表11-2と一致する必要があります。
「次へ」をクリックします。
「クラスタの構成」画面で、Oracle Service Busクラスタを追加します(既存のクラスタはそのままにしておきます)。
表11-3 クラスタ
| 名前 | クラスタ・メッセージング・モード | マルチキャスト・アドレス | マルチキャスト・ポート | クラスタ・アドレス |
|---|---|---|---|---|
|
SOA_Cluster(*) |
ユニキャスト |
なし |
なし |
SOAHOST1VHN1:8001、SOAHOST2VHN1:8001 |
|
WSM-PM_Cluster |
ユニキャスト |
なし |
なし |
空白 |
|
OSB_Cluster |
ユニキャスト |
なし |
なし |
SOAHOST1VHN2:8011、SOAHOST2VHN2:8011 |
(*) - SOAドメインを拡張する場合
「次へ」をクリックします。
|
注意: 直接バインディングを介してリクエスト/レスポンスが非同期でやり取りされるようにするため、SOAコンポジットでは、JNDIプロバイダURLを提供して、呼び出されたサービスが、コールバックするBeanを検索できるようにする必要があります。 soa-infraの構成プロパティは指定されていないがWebLogic Serverクラスタ・アドレスが指定されている場合は、JNDIプロバイダURLのクラスタ・アドレスが使用されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名を指定することも、サーバーip:portのカンマ区切りリストを指定することもできます。また、ユーザーが明示的に設定していれば、soa-infraの構成プロパティ |
「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。
SOA_Cluster - SOAドメインを拡張する場合
WLS_SOA1
WLS_SOA2
WSM-PM_Cluster
WLS_WSM1
WLS_WSM2
OSB_Cluster
WLS_OSB1
WLS_OSB2
「次へ」をクリックします。
次のエントリが表示されることを確認します。
他のフィールドはすべてデフォルト値のままにします。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。
ADMINHOST:
AdminServer
SOAHOST1
WLS_SOA1 (SOAドメインを拡張する場合)
WLS_WSM1
WLS_OSB1
SOAHOST2:
WLS_SOA2 (SOAドメインを拡張する場合)
WLS_WSM2
WLS_OSB2
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定します。(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。
oracle.sdp.*およびoracle.soa.*ライブラリは、SOA_Clusterにのみターゲット設定します。
oracle.rules.*ライブラリは、AdminServerおよびSOA_Clusterにのみターゲット設定します。
wsm-pmアプリケーションは、WSM-PM_Clusterにのみターゲット設定します。
すべてのトランスポート・プロバイダのデプロイメントを、OSB_ClusterおよびAdminServerの両方にターゲット設定します。
WebLogic WebServicesをSOA_Clusterにもデプロイする場合のみ、このライブラリをそれにもターゲット設定します。
「次へ」をクリックします。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次の設定をします。
mds-owsmをWSM-PM_ClusterおよびAdminServerに対してのみターゲット設定します。
mds-soaをSOA_Clusterに対してのみターゲット設定します。
「次へ」をクリックします。
「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
すべてのストアに対してDirect-writeポリシーを選択します。
「次へ」をクリックします。
「構成のサマリ」画面で、「拡張」をクリックします。
「ドメインの拡張」画面で、「完了」をクリックします。
この構成を有効にするには、管理サーバーを再起動します。
管理サーバー、管理対象サーバーおよびノード・マネージャの間のホスト名を検証するための適切な証明書を設定していない場合、ホスト名検証を無効化します。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。ドメイン内の既存のサーバーのホスト名検証をアドレス指定しておく必要があります。
ホスト名の検証は、管理サーバー、管理対象サーバーおよびノード・マネージャの間にSSL通信を設定した後で、再度有効化できます。
ホスト名検証を無効化するには:
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_OSB1」(これはハイパーリンクとして表示されています)を選択します。
「設定」ページが表示されます。
「SSL」タブを選択します。
このページの「詳細」セクションを展開します。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
WLS_OSB2管理対象サーバーについて手順5から9を繰り返します。
変更を保存してアクティブ化します。
この変更内容を有効にするには、管理サーバーおよびノード・マネージャを再起動する必要があります。
管理サーバーを再起動する手順は、第8.4.3項「SOAHOST1での管理サーバーの起動」を参照してください。
SOAHOST1でノード・マネージャを再起動するには、第9.5.2項「SOAHOST1でのノード・マネージャの再起動」の手順を繰り返します。
第9.5.2項「SOAHOST1でのノード・マネージャの再起動」の手順をSOAHOST2のノード・マネージャで実行します
デフォルトで、コンポジットのデプロイではマルチキャスト通信が使用されます。Oracle Service Busの結果キャッシュでは、ユニキャスト通信を使用することをお薦めします。また、SOAに使用するcoherenceクラスタから、結果キャッシュに使用するcoherenceクラスタの異なるポート範囲を分離することをお薦めします。
Oracle Service Busの結果キャッシュのCoherenceインフラストラクチャに対してユニキャストを有効にするには、次の手順を実行します。
Oracle WebLogic Server管理コンソールにログインします。「チェンジ・センター」で、「 ロックして編集 」をクリックします。
「ドメイン構造」ウィンドウで、「 環境 」ノードを開きます。
「サーバー」をクリックします。
表の「 名前 」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの「設定」ページが表示されます。
「Server Start」タブをクリックします。
WLS_OSB1には、次の1行を入力します(改行は入れません)。
-DOSB.coherence.localhost=soahost1vhn2 -DOSB.coherence.localport=7890 -DOSB.coherence.wka1=soahost1vhn2 -DOSB.coherence.wka1.port=7890 -DOSB.coherence.wka2=soahost2vhn2 -DOSB.coherence.wka2.port=7890
WLS_OSB2には、次の1行を入力します(改行は入れません)。
-DOSB.coherence.localhost=soahost2vhn2 -DOSB.coherence.localport=7890 -DOSB.coherence.wka1=soahost1vhn2 -DOSB.coherence.wka1.port=7890 -DOSB.coherence.wka2=soahost2vhn2 -DOSB.coherence.wka2.port=7890
|
注意: 異なる -D パラメータの間には、空白の行を入れないでください。テキストは、前述の場所からコピーして管理コンソールの引数テキスト・フィールドに貼り付けないでください。貼り付けると、Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。 |
変更を保存してアクティブ化します。これらの変更を有効にするには、Oracle Service Busサーバー再起動する必要があります。
|
注意: Oracle Service Busの結果キャッシュに使用するCoherenceクラスタは、前述のとおりポート7890を使用して構成されます。このポートは、次の起動パラメータで別のポート(8089など)を指定することで変更できます。 -Dtangosol.coherence.wkan.port -Dtangosol.coherence.localport Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。 |
これらの変数が管理対象サーバーに正しく渡されていることを、サーバーの出力ログで確認します。
Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。
各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。
|
注意: お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。 |
デフォルトの永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列にあるサーバーの名前(ハイパーリンクとして表示されています)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
「サービス」タブをクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
パスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
「保存」、「変更のアクティブ化」をクリックします。
|
注意: トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_OSB1とWLS_OSB2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。 |
Oracle Service Busでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。
前提条件
管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのバックアップ・コピーを作成します。
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播するには:
SOAHOST1で pack コマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/ domain_name/aserver/domain_name -template=soadomaintemplateExtOSB.jar -template_name=soa_domain_templateExtOSB
SOAHOST1でunpackコマンドを実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -overwrite_domain=true -template=soadomaintemplateExtOSB.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
|
注意: unpackコマンドで |
テンプレートをSOAHOST2にコピーするには、次のコマンドをSOAHOST1で実行します。
cd ORACLE_COMMON_HOME/common/bin scp soadomaintemplateExtOSB.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/ -overwrite_domain=true -template=soadomaintemplateExtOSB.jar -app_dir=ORACLE_BASE/admin/ domain_name/mserver/applications
|
注意: このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。 |
Oracle Service Busでは既存のドメインが拡張されているので、管理サーバーおよびそれぞれのノード・マネージャがSOAHOST1およびSOAHOST2で稼働していると想定します。
追加したWLS_OSBサーバーを起動する手順は次のとおりです。
次の場所にあるOracle WebLogic Server管理コンソールにログインします。
http://ADMINVHN:7001/console
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。
「サーバーの概要」ページが表示されます。
「Control」タブをクリックします。
表の「サーバー」列から「WLS_OSB1」を選択します。
「起動」をクリックします。サーバーが起動するのを待ち、管理コンソールでステータスが「実行中」であることを確認します。
WLS_OSB2について手順2から5を繰り返します。
Oracle WebLogic Server管理コンソールを使用し、URLにアクセスして、管理対象サーバーWLS_OSBを検証します。
WLS_OSB管理対象サーバーを検証する手順は次のとおりです。
管理コンソールに表示されるサーバーのステータスが「 実行中 」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.13項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。
次のURLにアクセスして、WLS_OSB1のステータスを確認します。
http://SOAHOST1VHN2:8011/sbinspection.wsil
デフォルトのインストールでは、これはHTTPレスポンスです。
次のURLにアクセスします。
http://SOAHOST1VHN2:8011/alsb/ws/_async/AsyncResponseServiceJms?WSDL
デフォルトのインストールでは、これはHTTPレスポンスです。
同等URLにアクセスします。
http://SOAHOST2VHN2:8011/
次のURLにアクセスし、Oracle Service Busコンソールから管理サーバーへのデプロイメントが適切であることを確認します。
http://ADMINHOSTVHN:7001/sbconsole/
Oracle Service Busコンソールがエラーなしで表示されます。
Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。
管理目的で仮想サーバーを使用する場合は、admin_vh.confファイルの仮想サーバーのコンテキストで、/sbconsoleによりルーティングを定義します。同様に、Oracle Service Busの残りのURLをosb_vh.confファイルに追加します。
/osb/project-name/folder-name/proxy-service-nameなどの共通名を使用して、HTTPプロキシ・サービスのコンテキスト・パスを開始し、Oracle HTTP Serverのすべてのプロキシ・サービスに対するルーティングを促進します。
パラメータを設定する手順は次のとおりです。
WEBHOST1およびWEBHOST2で、次のディレクトリにあるosb_vh.confファイルにディレクティブを追加します。
ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
第7.6項 「仮想ホストの定義」の説明に従ってosb_vh.confファイルを作成しておく必要があります。
<VirtualHost>タグ内に、次のディレクティブを追加します。
<Location /sbinspection.wsil >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /sbresource >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /osb >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /alsb >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
osb_vh.confファイルは、例11-1のように表示されます。
次のエントリをadmin_vh.confファイルの<VirtualHost>タグ内に追加します。
<Location /sbconsole >
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
admin_vh.confファイルは、例11-2のように表示されます。
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
例11-1 osb_vh.confファイル
<VirtualHost *:7777>
ServerName https://osb.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
<Location /sbinspection.wsil >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /sbresource >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /osb >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /alsb >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>
例11-2 admin_vh.confファイル
# The admin URLs should only be accessible via the admin virtual host
<VirtualHost *:7777>
ServerName admin.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
<Location /sbconsole >
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>
WebLogic Server管理コンソールを使用して、Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定します。
フロントエンドのホストおよびポートを設定する手順は次のとおりです。
WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。
左側のペインで、「環境」→「クラスタ」を選択します。
「OSB_Cluster」を選択します。
「HTTP」を選択します。
次の値を設定します。
フロントエンド・ホスト: osb.mycompany.com
フロントエンドHTTPポート: 80
フロントエンドHTTPSポート: 443
|
注意: このアドレスが正しく、使用可能である(ロード・バランシング・ルーターが稼働している)ことを確認してください。アドレスの http:// やホスト名の末尾 / など、値が誤っていると、仮想IPを使用してもSOAシステムにアクセスできません。 |
「保存」をクリックします。
変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
OSB_Clusterのクラスタ・アドレスをすでに設定しているため、Oracle Service BusコンテキストURLをWebLogic ServersにルーティングするようにOracle HTTP Serverを構成しておくだけで、Oracle Service BusのURLを検証できます。URLを検証して、HTTP ServerからOracle Service Busコンポーネントへのルーティングとフェイルオーバーが適切に機能することを確認します。
ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。
URLを検証する手順は次のとおりです。
WLS_OSB1が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_OSB2を停止します。
WebHost1:7777/sbinspection.wsilにアクセスし、HTTPレスポンスが第11.9項「WLS_OSB管理対象サーバーの検証」のとおりであることを確認します。
Oracle WebLogic Server管理コンソールでWLS_OSB2を起動します。
Oracle WebLogic Server管理コンソールでWLS_OSB1を停止します。
WebHost1:7777/sbinspection.wsilにアクセスし、HTTPレスポンスが第11.9項「WLS_OSB管理対象サーバーの検証」のとおりであることを確認します。
|
注意: OSB_ClusterにフロントエンドURLが設定されているため、URLへのリクエストはLBRへの再ルーティングになりますが、どのようなケースでも、Oracle HTTP Server内のマウント・ポイントおよびフェイルオーバーの検証には十分です。 |
ロード・バランサのアドレスを使用して、このURLを検証します。
http://osb.mycompany.com:80/sbinspection.wsil
Oracle SOA SuiteとOracle Service Busは、同じデータベース、ファイルおよびFTP JCAアダプタを使用します。SOAでOracle Repository Creation Utilityを使用するときに、これらのアダプタに必要なデータベース・スキーマを作成します。アダプタに必要な構成は、第9.9.1項「OracleファイルとFTPアダプタの高可用性化」に記載されています。DBアダプタの構成は、WebLogic Serverのリソース・レベルでは必要ありません。SOAドメインの拡張としてOracle Service Busを構成する場合は、アダプタに対する構成はすでに行われているため構成に加える必要はありません。
Oracle Service Busを、WSM-PMおよび管理サーバーのドメインへの拡張としてデプロイする場合は、次の手順を実行します。
RCUを実行し、Oracle Service Busデータベースに必要なアダプタ・スキーマをシードします(RCUで「SOAインフラストラクチャ」、「SOAおよびBAMインフラストラクチャ」を選択)。
第9.9.1項「OracleファイルとFTPのアダプタの高可用性化」の手順を実行します。
Oracle Service Busシステムの高可用性アーキテクチャでは、一部のシングルトン・サービスを障害から保護するためにサーバー移行を利用します。サーバー全体の移行の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。
WLS_OSB1管理対象サーバーは、障害発生時にSOAHOST2で再起動するように構成され、WLS_OSB2管理対象サーバーは、障害発生時にSOAHOST1で再起動するように構成されます。このような構成では、WLS_OSB1サーバーおよびWLS_OSB2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。
表11-5は、WLS_OSBサーバーのサーバー移行を構成するための大まかな手順を示しています。
表11-5 WLS_OSBサーバーのサーバー移行の構成の手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
サーバー移行リース・テーブルのユーザーおよび表領域の設定 |
サーバー移行リース・テーブルのユーザーおよび表領域を設定します。 SOAの表領域がすでに設定されている場合、この手順は不要です。 |
第11.14.1項「サーバー移行リース・テーブルのユーザーと表領域の設定」 |
|
ノード・マネージャのプロパティ・ファイルの編集 |
サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。 |
第11.14.2項「ノード・マネージャのプロパティ・ファイルの編集」 |
|
wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定 |
wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定します。 |
第11.14.3項「wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定」 |
|
サーバー移行ターゲットの構成 |
クラスタの移行ターゲットを構成し、 |
|
|
サーバー移行の検証 |
サーバーの移行が適切に行われていることを確認します。 |
|
SQL*Plusを使用して、サーバー移行表のユーザーおよび表領域を設定します。
ユーザーと表領域を作成する手順は次のとおりです。
leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。
SQL> create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;
次のように、leasingという名前のユーザーを作成し、leasing表領域に割り当てます。
SQL> create user leasing identified by welcome1; SQL> grant create table to leasing; SQL> grant create session to leasing; SQL> alter user leasing default tablespace leasing; SQL> alter user leasing quota unlimited on LEASING;
次のように、leasing.ddlスクリプトを使用してリース・テーブルを作成します。
次のディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。
WL_HOME/server/db/oracle/920
データベースにleasingユーザーとして接続します。
次のように、leasing.ddlスクリプトをSQL*Plusで実行します。
SQL> @copy_location/leasing.ddl;
サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。nodemanager.propertiesファイルは次のディレクトリにあります。
WL_HOME/common/nodemanager
次のプロパティを追加してサーバー移行が正常に動作するようにします。
Interface
Interface=eth0
このプロパティは浮動IP(eth0など)のインタフェース名を指定します。
|
注意:
|
NetMask
NetMask=255.255.255.0
このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。
UseMACBroadcast
UseMACBroadcast=true
このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。
これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力は次のようになります。
... StateCheckInterval=500 Interface=eth0 (Linux) or Interface="Local Area Connection" (Windows) NetMask=255.255.255.0 UseMACBroadcast=true ...
wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定します。
環境およびスーパーユーザー権限を設定する手順は次のとおりです。
表11-6に示すファイルをPATH環境変数で指定していることを確認します。
パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
セキュリティ上の理由から、sudoは、wlsifconfig.shスクリプトの実行に必要なコマンド・セットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定などです。
Windowsでは、このスクリプトの名前はwlsifconfig.cmdであり、管理者権限で実行できます。
|
注意: この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。 |
WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。
パスワードによる制限を設けずにsudo権限をWebLogicユーザー('oracle')に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
Defaults:oracle !requiretty oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
クラスタの移行ターゲットを構成するには、DataSourceForAutomaticMigrationプロパティをtrueに設定します。
クラスタ内の移行ターゲットを構成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。
「クラスタの概要」ページが表示されます。
表の「名前」列で、移行を構成するクラスタ(OSB_Cluster)をクリックします。
「移行」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。この場合は、「SOAHOST1」と「SOAHOST2」を選択します。
自動移行に使用するデータ・ソースを選択します。この場合は、リース・データソースを選択し、「保存」をクリックします。
「変更のアクティブ化」をクリックします。
WLS_OSB1およびWLS_OSB2について、サーバー移行の候補となるマシンを設定します。
WLS_OSB1についてのみ、サーバー移行の候補となるマシンを設定します。WLS_OSB2では、サーバー移行を使用しません。再設定が必要です。OSBサーバーが同一なため、OSB1およびOSB2の両方に対して構成する必要があります。BAM1とBAM2は同一ではないため、BAMではこれを注意してきました。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。WLS_OSB1には「SOAHOST2」を選択します。WLS_OSB2には「SOAHOST1」を選択します。
「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
「変更のアクティブ化」をクリックします。
管理サーバーとWLS_OSB1サーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。
サーバーの移行が適切に行われていることを確認する手順は次のとおりです。
ノード1からテストする手順は次のとおりです。
WLS_OSB1管理対象サーバーを強制停止します。
kill -9 pid
pidは、その管理対象サーバーのプロセスID(PID)を指定します。次のコマンドを実行すると、ノードのPIDを識別できます。
ps -ef | grep WLS_OSB1
|
注意: Windowsの場合は、 taskkill コマンドを使用して管理対象サーバーを終了できます。例:
taskkill /f /pid pid
pidは、管理対象サーバーのプロセスIDを表します。 WLS_OSB1管理対象サーバーのプロセスIDを確認する手順は次のとおりです。
MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v
|
ノード・マネージャのコンソールを確認します。WLS_OSB1の浮動IPが無効になっていることを示すメッセージが表示されています。
ノード・マネージャがWLS_OSB1の2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。
ノード2からテストする手順は次のとおりです。
ローカルのノード・マネージャ・コンソールを確認します。ノード1でのWLS_OSB1の再起動が前回試行されてから30秒間経過した後に、WLS_OSB1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。
同じIPのsbinspection.wsil urlconsoleにアクセスします。
WebLogic Server管理コンソールから移行を検証する手順は次のとおりです。
管理コンソールにログインします。
左のコンソールで「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」タブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。
|
注意: サーバーの移行後、そのサーバーを元のノードにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。 |
拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
環境のバックアップの詳細は、『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
管理サーバーをバックアップする手順は次のとおりです。
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
