Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-08 |
|
前 |
次 |
この章では、Oracle Business Activity Monitoring (BAM)を追加するためのドメイン拡張の手順を説明します。
この章の項目は次のとおりです。
BAMシステムは、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成された、共有記憶域上のWL_HOMEおよびORACLE_HOMEを使用してインストールされます。BAMHOST1およびBAMHOST2は、MW_HOME
をマウントして、既存のWLSおよびSOAのインストールを再利用します。pack
ユーティリティおよびunpack
ユーティリティを使用して、この2つの新しいノードでWLS_BAM1サーバーおよびWLS_BAM2サーバーのドメイン構成をブートストラップします。この結果、各ノードにソフトウェアをインストールする必要がなくなります。BAMシステムが正常に機能するには、SOAHOST1およびSOAHOST2にOracle FMWをインストールするときに必要としたシステム構成と同一の構成をBAMHOST1およびBAMHOST2で保持しておく必要があります。このシステム構成がないと、バイナリの実行で予期しない動作が発生することがあります。
この項の手順を実行する前に、次の前提条件を確認してください。
既存インストールのバックアップ
既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップします。
既存のFusion Middlewareホームおよびドメインをバックアップする手順は次のとおりです。
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の両方のインストール・ファイルのバックアップ、およびドメイン構成が作成されます。
BAMHOSTSのインベントリへの既存のOracleホームのアタッチ
新しいノード上に、既存のミドルウェア・ホーム(SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチするには、BAMHOSTで次のコマンドを実行します。
cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_version
ミドルウェア・ホーム・リストを更新するには、$HOME/bea/beahomelist
ファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集)、MW_HOMEをこのファイルに追加します。
BAMシステムでは、BAMサーバー・コンポーネントをホストする管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。この仮想ホスト名とそれに対応する仮想IPは、BAMサーバー・コンポーネントでサーバー移行を有効にするときに必要となります。BAMHOST1で仮想IP(VIP4)のマッピングBAMHOST1VHN1を有効にして、トポロジ(DNSサーバーとホスト解決のいずれか)で使用されるネットワーク・システムでBAMHOST1VHN1ホスト名を正しく解決します。
仮想IPを有効にするには、第3.5項「管理サーバーの仮想IPアドレスの有効化」を参照してください。
BAMアダプタを使用したOracle BAM Serverへのアクセスについて
BAMアダプタ(rmi)を使用しOracle BAM Serverにアクセスする場合、接続にはBAMサーバー(BAMHOST1VNH1)の仮想ホスト名を使用する必要があります。SOAPリクエストはHTTPを介するため、アダプタを使用する場合はロード・バランサ・アドレスを使用します。
この手順では、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを、BAMを扱うことができるように拡張します。この項の手順は、SOAのデプロイメントと同じデータベース・サービス(soaedg.mycompany.com
)をBAMのデプロイメントでも使用することを前提としています。ただし、BAM専用の別のデータベース・サービスを使用することもできます。
ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。
cd ORACLE_COMMON_HOME/common/bin
構成ウィザードを起動します。
./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
「WebLogicドメイン・ディレクトリ」画面で、次のWebLogicドメイン・ディレクトリを選択します。
ORACLE_BASE/admin/domain_name/aserver/domain_name
「次へ」をクリックします。
「拡張ソースの選択」画面で、次の手順を実行します。
「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。
次の製品を選択します。
Oracle Business Activity Monitoring 11.1.1.0
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。
「BAM Schema」を選択します。
「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。
「次へ」をクリックします。
「GridLink RACコンポーネント・スキーマの構成」画面が表示されます(図12-1)。
この画面で、次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 10以上を選択します。
サービス名: データベースのサービス名を、小文字で入力します。例:
soaedg.mycompany.com
ユーザー名: 対応するコンポーネントのデータベース・スキーマ・オーナーの名前を入力します。
パスワード: データベース・スキーマ・オーナーのパスワードを入力します。
「FANの有効化」を選択します。
「SSLの有効化」が選択解除されていることを確認します(暗号化するONS通知にsslが選択されている場合は、適切なウォレットとウォレット・パスワードを指定します)。
サービス・リスナー: 使用するRACデータベースのためのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。
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ホスト: Oracle RACデータベースのSCANアドレスおよびデータベースから報告されたONSリモート・ポートを入力します。
[orcl@db-scan1 ~]$ 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) |
「JDBCデータ・ソースのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理対象サーバー、クラスタ、およびマシン
デプロイメントとサービス
JMSファイル・ストア
JMS分散宛先
「次へ」をクリックします。
「JMS分散宛先タイプの選択」画面で、すべてのFusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストから「UDD」を選択します。
注意: Fusion Middlewareコンポーネントでは、WDDの使用はサポートされていません。 |
「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
bam_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_BAM1に変更し、WLS_BAM2という新しいサーバーを追加します。表12-1に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは、このまま変更しません。
表12-1 管理対象サーバー
名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
---|---|---|---|---|
WLS_BAM1 |
BAMHOST1VHN1 |
9001 |
なし |
いいえ |
WLS_BAM2 |
BAMHOST2 |
9001 |
なし |
いいえ |
「次へ」をクリックします。
「クラスタの構成」画面で、表12-2に示す次のクラスタを追加します。この画面に表示されている他のクラスタは、このまま変更しません。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次の項目を追加します。この画面に表示されている他の割当ては、このまま変更しません。
BAM_Cluster
WLS_BAM1
WLS_BAM2
「次へ」をクリックします。
「マシンの構成」画面で、次の手順を実行します。
デフォルトで表示される「LocalMachine」を削除します。
「Unixマシン」タブをクリックします。マシンBAMHOST1およびBAMHOST2を追加して、次のように入力します。
他のフィールドはすべてデフォルト値のままにします。
「次へ」をクリックします。
WLS_BAM1をBAMHOST1に割り当てます。
WLS_BAM2をBAMHOST2に割り当てます。
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
usermessagingserverおよびusermessagingdriver-emailは、SOA_ClusterおよびBAM_Clusterにのみターゲット設定する必要があります(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。
WSM-PMはWSM-PM_Clusterにのみターゲット設定する必要があります。
「DMSアプリケーション」は、BAM_Cluster、SOA_Cluster、WSM-PM_Clusterおよび「管理サーバー」にターゲット設定する必要があります。
oracle.sdp.*ライブラリは、SOA_ClusterおよびBAM_Clusterにのみターゲット設定します。oracle.soa.*ライブラリは、SOA_Clusterにのみターゲット設定します。
oracle.rules.*ライブラリは、SOA_Cluster、BAM_Clusterおよび管理サーバーにターゲット設定します。
oracle.bam*は、BAM_Clusterにのみターゲット設定する必要があります。
「次へ」をクリックします。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
mds-owsmをWSM-PM_ClusterおよびAdminServerの両方にターゲット設定します。
mds-soaをSOA_ClusterおよびAdminServerの両方にターゲット設定します。
OraSDPMDatasourceをSOA_ClusterおよびBAM_Clusterの両方にターゲット設定します。
「次へ」をクリックします。
アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。
「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
「構成のサマリ」画面で、「拡張」をクリックします。
管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で再起動します。
サーバーが開始したら、GridLinkデーター・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。
GridLinkデータ・ソースの構成を検証する手順は次のとおりです。
Oracle WebLogic管理コンソールにログインします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
新しいデータ・ソースの内の1つをクリックします。
「監視」タブをクリックし、いずれかのサーバーを選択します。
「統計」タブをクリックし、いずれかのサーバーを選択します。
「ONS」タブをクリックし、「テスト」タブをクリックします。
サーバーを選択して、「ONSのテスト」をクリックします。
テストが両方とも成功すれば、正しく構成されています。ONSのテストが失敗した場合は、RACデータベース・ノードでONSサービスが実行されていることを確認します。
orcl@db-scan1 ~]$ srvctl status scan_listener SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node db-scan1 SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node db-scan2 SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node db-scan2 [orcl@db-scan1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016 [orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS ONS is enabled ONS daemon is running on node: db-scan1 ONS daemon is running on node: db-scan2
データ・ソースを使用するすべてのWebLogicサーバーからONSテストを実行します。
各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーからアクセスできる場所にトランザクション・ログを格納します。
注意: お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。 |
WLS_BAM1のデフォルト永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_BAM1」(これはハイパーリンクとして表示されています)をクリックします。WLS_BAM1サーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。
「サービス」サブタブをクリックします。
ページの「デフォルト・ストア」セクションで、そのデータ・ファイルが格納されるデフォルト永続ストアのあるフォルダのパスを入力します。パスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/bam_cluster_name/tlogs
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
注意: トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。BAMHOST1とBAMHOST2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。 |
BAMのBAMサーバー・コンポーネントはシングルトンなので、そのコンポーネントをサーバー移行用に構成する前に、いずれかのWLS_BAMサーバーのターゲット設定を解除する必要があります。
次の手順では、BAMサーバーのランタイムをWLS_BAM2から削除します。
WLS_BAM2からBAM Serverアーティファクトのターゲット指定を解除する手順は次のとおりです。
http://ADMINVHN:7001/console
のOracle WebLogic管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択します。「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_BAM2」を選択します。WLS_BAM2の「設定」ページが表示されます。
「デプロイメント」タブをクリックします。
表の「名前」列でoracle-bamアプリケーションを選択します。oracle-bamアプリケーションの「設定」ページが表示されます。
「ターゲット」タブをクリックします。
「ロックして編集」をクリックします。
表12-4に従って各モジュールのターゲットを変更します。これらのコンポーネントをすべて変更する必要があり、ターゲット指定を誤ると、BAMシステムが起動しなくなります。
表12-4 oracle-bamコンポーネントのターゲット・タイプ
コンポーネント | タイプ | ターゲット |
---|---|---|
oracle-bam(11.1.1) |
エンタープライズ・アプリケーション |
BAM_Cluster |
/oracle/bam |
WEBAPP |
WLS_BAM1 |
oracle-bam-adc-ejb.jar |
EJB |
WLS_BAM1 |
oracle-bam-ems-ejb.jar |
EJB |
WLS_BAM1 |
oracle-bam-eventengine-ejb.jar |
EJB |
WLS_BAM1 |
oracle-bam-reportcache-ejb.jar |
EJB |
WLS_BAM1 |
OracleBAM |
WEBAPP |
BAM_Cluster |
OracleBAMWS |
WEBAPP |
BAM_Cluster |
oracle-bam-statuslistener-ejb.jar |
EJB |
WLS_BAM1 |
sdpmessagingclient-ejb.jar |
EJB |
WLS_BAM1 |
「保存」をクリックして、「変更のアクティブ化」をクリックします。
アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。
pack/unpackユーティリティを使用して、BAMHOST1およびBAMHOST2にドメイン構成を伝播します。
新しいドメイン構成を伝播する手順は次のとおりです。
BAMHOST1に、SOAHOST2と同様のディレクトリおよび共有記憶域構成(第3章「エンタープライズ・デプロイメント用のネットワークの準備」の説明のとおり)があることを確認します。BAMHOST1とBAMHOST2が、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したMW_HOME
ディレクトリをマウントしている必要があります。
SOAHOST1でpack
コマンドを実行してテンプレート・パックを作成します。
次のコマンドを実行します。
cd ORACLE_COMMON_HOME/common/bin
次のようにpackコマンドを実行します。
./pack.sh -managed=true -domain=ORACLE_BASE/admin/ domain_name/aserver/domain_name -template=soadomaintemplateExtBAM.jar -template_name=soa_domain_templateExtBAM
次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをBAMHOST1にコピーします。
scp soadomaintemplateBAM.jar
oracle@BAMHOST1:/ORACLE_COMMON_HOME/common/bin
次のように、BAMHOST1でunpack
コマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。
BAMHOST1> cd ORACLE_COMMON_HOME/common/bin BAMHOST1> ./unpack.sh -domain= ORACLE_BASE/admin/ domain_name/mserver/domain_name -template=soadomaintemplateExtBAM.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
BAMHOST2に対してcopyコマンドとunpackコマンドを実行します。
注意: このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。 |
このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_BAM1およびWLS_BAM2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。
エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。
setNMProps.sh
スクリプトを使用してノード・マネージャを起動します。
BAMHOST1およびBAMHOST2でノード・マネージャを起動する手順は次のとおりです。
ノード・マネージャを起動する前に、各サーバーのORACLE_COMMON_HOME/common/bin
ディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabled
プロパティをtrueに設定します。
BAMHOSTn> cd ORACLE_COMMON_HOME/common/bin
BAMHOSTn> ./setNMProps.sh
注意: クラスのロード失敗やその他の問題を回避するため、 |
注意: 第3章「エンタープライズ・デプロイメント用のネットワークの準備」の共有記憶域構成で示しているように、BAMサーバーがローカル記憶域または共有記憶域でSOAとMW_HOMEを共有している場合には、 |
次のコマンドを実行し、BAMHOST1でノード・マネージャを起動します。
BAMHOST1> cd WL_HOME/server/bin
BAMHOST1> ./startNodeManager.sh
次のコマンドを実行し、BAMHOST2でノード・マネージャを起動します。
BAMHOST2> cd WL_HOME/server/bin
BAMHOST2> ./startNodeManager.sh
Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーWLS_BAM1を起動します。
ここで示す手順は、SOAHOST2でWS-MまたはSOAの管理対象サーバーについて事前にホスト名の検証が行われており、さらに、SOAHOST2でノード・マネージャがすでに実行されていることを前提としています。
BAMHOST1上の管理対象サーバーWLS_BAM1を起動する手順は次のとおりです。
WLS_BAM1管理対象サーバーを起動します。
http://ADMINVHN:7001/console
のOracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
「制御」タブをクリックします。
表の「サーバー」列の「WLS_BAM1」を選択します。
「起動」をクリックします。
http://BAMHOST1VHN1:9001/OracleBAM
にアクセスしてWLS_BAM1のステータスを確認します。
管理対象サーバーの起動に失敗すると次のメッセージが表示されます。
Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was <db_connect_string>
この場合は、データベースのPROCESSES
初期化パラメータが十分に高い値に設定されていることを確認してください。詳細は、第5.2.3項「初期化パラメータについて」を参照してください。このエラーが発生する可能性があるのは、1台のサーバーを起動した後で別のサーバーを起動した場合です。
WLS_BAM2管理対象サーバーを起動します。
http://ADMINVHN:7001/console
のOracle WebLogic管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
「制御」タブをクリックします。
表の「サーバー」列の「WLS_BAM2」を選択します。
「起動」をクリックします。
http://BAMHOST2:9001/OracleBAM
にアクセスしてWLS_BAM2のステータスを確認します。
BAMHOST1でBAM Serverを使用するためのOracleBamWeb(WLS_BAM1)アプリケーションおよびOracleBamWeb(WLS_BAM2)アプリケーションを構成する手順は次のとおりです。
http://ADMINVHN:7001/em
のOracle Enterprise Manager Fusion Middleware Controlにアクセスします。
ナビゲーション・ツリーの「BAM」を開きます。
「OracleBamWeb(WLS_BAM1)」を右クリックします。
コンテキスト・メニューから「BAM Webプロパティ」を選択します。「BAM Webプロパティ」ページが表示されます。
次のプロパティを定義します。
アプリケーションURLにhttps://soa.mycompany.com:443と入力します。
サーバー名にBAMHOST1VHN1と入力します。第3.4項「IPおよび仮想IPについて」の表3-2も参照してください。
「適用」をクリックします。
Mbeanブラウザを使用し、サーバーのリスニング・ポートを変更します。
Oracle Enterprise Manager Fusion Middleware Controlにログインします。
左側のナビゲーション・ツリーのドメイン名を展開します。
左側のナビゲーション・ツリーのBAM項目を展開します。
左側のナビゲーション・ツリーのOracleBamServerを強調表示します。
右上のBAMServerドロップダウン・メニューから「MBeanブラウザ」を選択します。
右側で「oracle.bam.web」→「サーバー」→「アプリケーション」→「構成」→「BAMWebConfig」に移動します。
「ServerPort」フィールドの「デフォルト」値を「9001」に置き換えます。
ナビゲーション・ツリーで「OracleBamWeb(WLS_BAM2)」を選択し、手順3から5を繰り返します。
WLS_BAMn管理対象サーバーが属するBAM_ClusterにOracle HTTP Serverからルーティングをできるようにするには、次のようにWebLogicCluster
パラメータをこのクラスタにあるノードのリストに設定する必要があります。
Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。
WEBHOST1とWEBHOST2上で、次のディレクトリにあるsoa_vh.conf
ファイルにディレクティブを追加します。
ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
第7.6項「仮想ホストの定義」の指示に従って、soa_vh.conf
ファイルを作成している必要があります。
次のディレクティブをsoa_vh.conf
ファイルの<VirtualHost>
タグ内に追加します。
# BAM Web Application <Location /OracleBAM > SetHandler weblogic-handler WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /OracleBAMWS > SetHandler weblogic-handler WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001 WLProxySSL ON WLProxySSLPassThrough ON </Location>
soa_vh.conf
ファイルは、例12-1のように表示されます。
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
例12-1 soa_vh.confファイル
<VirtualHost *:7777> ServerName https://soa.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> # Worklist <Location /integration> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # B2B <Location /b2bconsole> 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 /workflow/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> # BAM Web Application <Location /OracleBAM > SetHandler weblogic-handler WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /OracleBAMWS > SetHandler weblogic-handler WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001 WLProxySSL ON WLProxySSLPassThrough ON </Location> </VirtualHost>
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サーバー・プラグインの使用』ガイドを参照してください。
URLを検証して、HTTP ServerからBAM_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。
URLを検証する手順は次のとおりです。
WLS_BAM2が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_BAM1を停止します。
WebHost1:7777/OracleBAM
にアクセスして正常に機能していることを確認しますBAMサーバーが起動していないため、この時点ではレポートやデータを取得できません。
Oracle WebLogic Server管理コンソールでWLS_BAM1を起動します。
Oracle WebLogic Server管理コンソールでWLS_BAM2を停止します。
WebHost1:7777/OracleBAM
にアクセスして正常に機能していることを確認します
BAMの高可用性アーキテクチャでは、サーバーの移行を使用してBAMサーバーのシングルトン・サービスを障害から保護します。障害が発生した場合にBAMHOST2で再起動できるようにWLS_BAM1管理対象サーバーを構成します。この構成では、WebLogic Serverの移行によってフェイルオーバーの対象となる特定の浮動IPをWLS_BAM1でリスニングします。WLS_BAM1管理対象サーバーのサーバー移行を構成する手順は次のとおりです。
ステップ1: サーバー移行リース・テーブルのユーザーおよび表領域の設定
ステップ3: ノード・マネージャのプロパティ・ファイルの編集
ステップ6: サーバー移行ターゲットの構成
ステップ7: サーバー移行のテスト
注意: SOAに対してサーバーの移行を構成済であれば、それと同じデータ・ソースとデータベース・スキーマをBAMステムで使用できます。この場合、ステップ1から4は不要ですが、対応するサーバー移行/リース・データソースをBAMクラスタにターゲット設定する必要があります。 |
ユーザーと表領域を作成する手順は次のとおりです。
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 password;
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
スクリプトを使用してリース・テーブルを作成します。
WL_HOME/server/db/oracle/920
ディレクトリにあるleasing.ddlファイルを、使用するデータベース・ノードにコピーします。
データベースにleasingユーザーとして接続します。
次のように、leasing.ddl
スクリプトをSQL*Plusで実行します。
SQL> @copy_location/leasing.ddl;
第14.3項「管理コンソールによるリース用のGridLinkデータ・ソースの作成」の手順に従って、Oracle WebLogic Server管理コンソールを使用して、リース・テーブルに使用するGridLinkデータ・ソースを作成します。
サーバーが稼働している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 NetMask=255.255.255.0 ...
注意: サーバーのプロパティ(起動プロパティ)が設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。 |
nodemanager.properties
ファイルのStartScriptEnabled
プロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。
WL_HOME/server/bin/
ディレクトリにあるstartNodeManager.sh
スクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。
注意: 共有記憶域のインストールからノード・マネージャを実行している場合、同じ |
wlsifconfig.sh
スクリプトの環境およびスーパーユーザー権限を設定します。
表12-5に示すファイルをPATH環境変数で指定していることを確認します。
表12-5 PATH環境変数に必要なファイル
ファイル | ディレクトリの場所 |
---|---|
|
ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration |
|
WL_HOME/common/bin
|
|
WL_HOME/common/nodemanager
|
パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
セキュリティ上の理由から、sudoの付与はwlsifconfig.sh
スクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.sh
スクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。
注意: この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。 |
WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。sudo実行権限をoracle
およびifconfig
とarping
に付与するエントリを記述した/etc/sudoersの例を次に示します。
パスワードによる制限を設けずにsudo権限をWebLogicユーザー('oracle')に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
BAMHOSTnノードのノード・マネージャと管理サーバー間でのホスト名検証証明書を有効化します。ホスト名検証証明書を有効化するには、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。
クラスタの移行ターゲットを構成するには、DataSourceForAutomaticMigration
プロパティをtrueに設定します。
クラスタ内の移行ターゲットを構成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
表の「名前」列で、移行を構成するクラスタ(BAM_Cluster)をクリックします。
「移行」タブをクリックします。
「ロックして編集」をクリックします。
「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。この場合は、「BAMHOST1」と「BAMHOST2」を選択します。
自動移行に使用するデータソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」および「変更のアクティブ化」をクリックします。
WLS_BAM1についてのみ、サーバー移行の候補となるマシンを設定します。WLS_BAM2はサーバー移行を使用しません。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。WLS_BAM1についてBAMHOST2を選択します。
「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
「変更のアクティブ化」をクリックします。
管理サーバーとWLS_BAM1サーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。
ヒント: 「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。 |
サーバーの移行が適切に行われていることを確認する手順は次のとおりです。
ノード1からテストする手順は次のとおりです。
WLS_BAM1管理対象サーバーを停止します。
BAMHOST1> kill -9 pid
pidは、その管理対象サーバーのプロセスID(PID)を指定します。次のコマンドを実行すると、ノードのPIDを識別できます。
BAMHOST1> ps -ef | grep WLS_BAM1
ノード・マネージャのコンソールを確認します。WLS_BAM1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_BAM1の2回目の再起動を試行するまで待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。
ノード2からテストする手順は次のとおりです。
ローカルのノード・マネージャ・コンソールを確認します。ノード1でのWLS_BAM1の再起動が前回試行されてから30秒間経過した後に、WLS_BAM1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。
BAMHOST1VHN1とsoa.mycompany.com/OracleBAMを使用してOracle BAMコンソールにアクセスします。
管理コンソールから移行を検証する手順は次のとおりです。
管理コンソールにログインします。
左のコンソールで「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」タブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。
Oracle BAMをクラスタ環境で使用している場合、あるノードをOracle Enterprise Managerで変更したときには、その変更をすべてのノードに適用する必要があります。また、BAMエンタープライズ・デプロイメント・トポロジでBAMサーバーに構成変更を行う場合には、次の作業も検討してください。
サーバーの移行機能を使用するため、BAMサーバーは別のノードのドメイン・ディレクトリに移動します。BAMサーバー構成は、フェイルオーバー・ノード内であらかじめ作成しておく必要があります。このBAMサーバー構成ファイルは、次のディレクトリにあります。
DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/oracle_bam-11.1.1/config
フェイルオーバーに備えてファイルを作成するには、強制的にサーバー移行を実行してファイルをソース・ノードからコピーしてください。たとえば、BAMの場合の手順は次のとおりです。
WLS_BAM1のドライバをBAMHOST1内で構成します。
BAMHOST2へのWLS_BAM1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内のBAMサーバーのディレクトリ構造を確認してください。
DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/oracle_bam-11.1.1/config
拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
環境のバックアップの詳細は、『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