12 BAMを追加するためのドメインの拡張

この章では、Oracle Business Activity Monitoring (BAM)を追加するためのドメイン拡張の手順を説明します。

この章の項目は次のとおりです。

• 第12.1項「ドメインへのBAMの追加の概要」

• 第12.3項「BAMHOST1でのVIP4の有効化」

• 第12.4項「構成ウィザードを使用したドメインの拡張」

• 第12.5項「GridLinkデータ・ソースの検証」

• 第12.6項「トランザクション・リカバリ用デフォルト永続ストアの構成」

• 第12.7項「WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除」

• 第12.8項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」

• 第12.9項「WLS_BAMn管理対象サーバーに対するホスト名検証の無効化」

• 第12.10項「BAMHOST1およびBAMHOST2でのノード・マネージャの起動」

• 第12.11項「BAMシステムの起動」

• 第12.12項「BAMHOST1でBAMサーバーを使用するためのBAM Webアプリケーションの構成」

• 第12.13項「WLS_BAMn管理対象サーバーについてのOracle HTTP Serverの構成」

• 第12.14項「Oracle HTTP Serverを介したアクセスの検証」

• 第12.15項「WLS_BAM1サーバーのサーバー移行の構成」

• 第12.16項「BAMクラスタ内のBAMコンポーネントへの構成変更の適用」

• 第12.17項「BAM構成のバックアップ」

12.1 ドメインへの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で保持しておく必要があります。このシステム構成がないと、バイナリの実行で予期しない動作が発生することがあります。

12.2 BAMを追加するためのドメイン拡張の前提条件

この項の手順を実行する前に、次の前提条件を確認してください。

既存インストールのバックアップ

既存の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をこのファイルに追加します。

12.3 BAMHOST1でのVIP4の有効化

BAMシステムでは、BAMサーバー・コンポーネントをホストする管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。この仮想ホスト名とそれに対応する仮想IPは、BAMサーバー・コンポーネントでサーバー移行を有効にするときに必要となります。BAMHOST1で仮想IP(VIP4)のマッピングBAMHOST1VHN1を有効にして、トポロジ(DNSサーバーとホスト解決のいずれか)で使用されるネットワーク・システムでBAMHOST1VHN1ホスト名を正しく解決します。

Linuxで仮想IPを有効にする手順は次のとおりです。

1. rootとしてifconfigコマンドを実行します。

   /sbin/ifconfig <interface:index> IPAddress netmask netmask
   /sbin/arping -q -U -c 3 -I interface IPAddress
   

   例:

   /sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
   

2. 次の例のように、ネットワークで仮想IPの新しい場所を登録できるようにします。

   /sbin/arping -q -U -c 3 -I ethX 100.200.140.206
   

3. 別のノードからこのアドレスをpingして、このアドレスが使用可能であることを検証します。次の例を示します。

   /bin/ping 100.200.140.206
   

   この例で、'ethX'はイーサネット・インタフェース(eth0またはeth1)、Yはインデックス(0、1、2)です。

BAMアダプタを使用したOracle BAM Serverへのアクセスについて

BAMアダプタ(rmi)を使用しOracle BAM Serverにアクセスする場合、接続にはBAMサーバー(BAMHOST1VNH1)の仮想ホスト名を使用する必要があります。SOAPリクエストはHTTPを介するため、アダプタを使用する場合はロード・バランサ・アドレスを使用します。

12.4 構成ウィザードを使用したドメインの拡張

この手順では、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを、BAMを扱うことができるように拡張します。この項の手順は、SOAのデプロイメントと同じデータベース・サービス(soaedg.mycompany.com)をBAMのデプロイメントでも使用することを前提としています。ただし、BAM専用の別のデータベース・サービスを使用することもできます。

1. ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。

   cd ORACLE_COMMON_HOME/common/bin
   

2. 構成ウィザードを起動します。

   ./config.sh
   

3. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

4. 「WebLogicドメイン・ディレクトリ」画面で、次のWebLogicドメイン・ディレクトリを選択します。

   ORACLE_BASE/admin/domain_name/aserver/domain_name
   

   「次へ」をクリックします。

5. 「拡張ソースの選択」画面で、次の手順を実行します。

   • 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

   • 次の製品を選択します。

     • Oracle Business Activity Monitoring 11.1.1.0

   「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

   • 「BAM Schema」を選択します。

   • 「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。

   「次へ」をクリックします。

7. 「GridLink RACコンポーネント・スキーマの構成」画面が表示されます(図12-1)。

   図12-1 「GridLink RACコンポーネント・スキーマの構成」画面

   
   

   この画面で、次の各フィールドに値を入力して、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)

     
     

8. 「JDBCデータ・ソースのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。

   すべての接続に成功したら「次へ」をクリックします。

9. 「オプションの構成を選択」画面で、次を選択します。

   • 管理対象サーバー、クラスタ、およびマシン

   • デプロイメントとサービス

   • JMSファイル・ストア

     「次へ」をクリックします。

10. 「JMS分散宛先タイプの選択」画面で、すべてのFusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストから「UDD」を選択します。

    
    

    注意: Fusion Middlewareコンポーネントでは、WDDの使用はサポートされていません。

    
    

11. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。

    bam_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_BAM1に変更し、WLS_BAM2という新しいサーバーを追加します。表12-1に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは、このまま変更しません。

    表12-1 管理対象サーバー

    名前	リスニング・アドレス	リスニング・ポート	SSLリスニング・ポート	SSL有効
    WLS_BAM1	BAMHOST1VHN1	9001	なし	いいえ
    WLS_BAM2	BAMHOST2	9001	なし	いいえ

    
    

    「次へ」をクリックします。

12. 「クラスタの構成」画面で、表12-2に示す次のクラスタを追加します。この画面に表示されている他のクラスタは、このまま変更しません。

    表12-2 クラスタ

    名前	クラスタ・メッセージング・モード	マルチキャスト・アドレス	マルチキャスト・ポート	クラスタ・アドレス
    BAM_Cluster	ユニキャスト	なし	なし	空白

    
    

    「次へ」をクリックします。

13. 「サーバーのクラスタへの割当」画面で、次の項目を追加します。この画面に表示されている他の割当ては、このまま変更しません。

    • BAM_Cluster

      • WLS_BAM1

      • WLS_BAM2

    「次へ」をクリックします。

14. 「マシンの構成」画面で、次の手順を実行します。

    • デフォルトで表示される「LocalMachine」を削除します。

    • 「Unixマシン」タブをクリックします。マシンBAMHOST1およびBAMHOST2を追加して、次のように入力します。

      表12-3 マシン

      名前	ノード・マネージャのリスニング・アドレス
      SOAHOST1	SOAHOST1
      SOAHOST2	SOAHOST2
      BAMHOST1	BAMHOST1
      BAMHOST2	BAMHOST2

      
      

    他のフィールドはすべてデフォルト値のままにします。

    「次へ」をクリックします。

15. 「サーバーのマシンへの割当」画面で、次の項目を追加します。

    • WLS_BAM1をBAMHOST1に割り当てます。

    • WLS_BAM2をBAMHOST2に割り当てます。

    「次へ」をクリックします。

16. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

    • 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および管理サーバーにターゲット設定します。

    • このライブラリは、SOA_ClusterまたはBAM_Clusterにもターゲット設定します。ただしこれは、WebLogic WebServicesをそれらにデプロイする場合のみです。

    • oracle.bam*は、BAM_Clusterにのみターゲット設定する必要があります。

    「次へ」をクリックします。

17. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

    • mds-owsmをWSM-PM_ClusterおよびAdminServerの両方にターゲット設定します。

    • mds-soaをSOA_ClusterおよびAdminServerの両方にターゲット設定します。

    • OraSDPMDatasourceをSOA_ClusterおよびBAM_Clusterの両方にターゲット設定します。

      「次へ」をクリックします。

18. 「構成のサマリ」画面で、「拡張」をクリックします。

19. 「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
    

20. ドメインのポートの競合に関する警告ダイアログで「OK」をクリックします。

21. 「ドメインの作成中」画面で、「完了」をクリックします。

22. 管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で再起動します。

12.5 GridLinkデータ・ソースの検証

サーバーが開始したら、GridLinkデーター・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。

GridLinkデータ・ソースの構成を検証する手順は次のとおりです。

1. Oracle WebLogic管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 新しいデータ・ソースの内の1つをクリックします。

4. 「監視」タブをクリックし、いずれかのサーバーを選択します。

5. 「統計」タブをクリックし、いずれかのサーバーを選択します。

6. 「ONS」タブをクリックし、「テスト」タブをクリックします。

7. サーバーを選択して、「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テストを実行します。

12.6 トランザクション・リカバリ用デフォルト永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーからアクセスできる場所にトランザクション・ログを格納します。

注意: お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。

WLS_BAM1のデフォルト永続ストアの場所を設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_BAM1」(これはハイパーリンクとして表示されています)をクリックします。WLS_BAM1サーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。

5. 「サービス」サブタブをクリックします。

6. ページの「デフォルト・ストア」セクションで、そのデータ・ファイルが格納されるデフォルト永続ストアのあるフォルダのパスを入力します。パスのディレクトリ構造は次のとおりです。

   ORACLE_BASE/admin/domain_name/bam_cluster_name/tlogs
   

7. 「保存」をクリックします。

8. 「変更のアクティブ化」をクリックします。

注意: トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。BAMHOST1とBAMHOST2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

12.7 WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除

BAMのBAMサーバー・コンポーネントはシングルトンなので、そのコンポーネントをサーバー移行用に構成する前に、いずれかのWLS_BAMサーバーのターゲット設定を解除する必要があります。

次の手順では、BAMサーバーのランタイムをWLS_BAM2から削除します。

WLS_BAM2からBAM Serverアーティファクトのターゲット指定を解除する手順は次のとおりです。

1. http://ADMINVHN:7001/consoleのOracle WebLogic管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択します。「サーバーの概要」ページが表示されます。

3. 表の「名前」列で「WLS_BAM2」を選択します。WLS_BAM2の「設定」ページが表示されます。

4. 「デプロイメント」タブをクリックします。

5. 表の「名前」列でoracle-bamアプリケーションを選択します。oracle-bamアプリケーションの「設定」ページが表示されます。

6. 「ターゲット」タブをクリックします。

7. 「ロックして編集」をクリックします。

8. 表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

   
   

9. 「保存」→「変更のアクティブ化」をクリックします。

12.8 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

pack/unpackユーティリティを使用して、BAMHOST1およびBAMHOST2にドメイン構成を伝播します。

新しいドメイン構成を伝播する手順は次のとおりです。

1. BAMHOST1に、SOAHOST2と同様のディレクトリおよび共有記憶域構成(第3章「エンタープライズ・デプロイメント用のネットワークの準備」の説明のとおり)があることを確認します。BAMHOST1とBAMHOST2が、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したMW_HOMEディレクトリをマウントしている必要があります。

2. SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

   1. 次のコマンドを実行します。

      cd ORACLE_COMMON_HOME/common/bin
      

      
      

      注意: このディレクトリは第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したMW_HOMEへのマウント・ポイントとして使用できます。

      
      

   2. 次のようにpackコマンドを実行します。

      ./pack.sh -managed=true -domain=ORACLE_BASE/admin/
      domain_name/aserver/domain_name -template=soadomaintemplateExtBAM.jar
       -template_name=soa_domain_templateExtBAM
      

3. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをBAMHOST1にコピーします。

   scp soadomaintemplateBAM.jar
      oracle@BAMHOST1:/ORACLE_COMMON_HOME/common/bin
   

4. 次のように、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
   

5. BAMHOST2に対してcopyコマンドとunpackコマンドを実行します。

注意: このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

12.9 WLS_BAMn管理対象サーバーに対するホスト名検証の無効化

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle BAMを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。そのため、WLS_SOAn管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverを管理するときにエラーが出ないようにします。エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

ホスト名検証を無効化するには:

1. Oracle WebLogic Server管理コンソールにログインします。

2. 管理コンソールで、「WLS_BAM1」→「SSL」→「詳細」を選択します。

3. 「ホスト名の検証」を「なし」に設定します。

4. 管理コンソールで、「WLS_BAM2」→「SSL」→「詳細」を選択します。

5. 変更を保存してアクティブ化します。

12.10 BAMHOST1およびBAMHOST2でのノード・マネージャの起動

setNMProps.shスクリプトを使用してノード・マネージャを起動します。

BAMHOST1およびBAMHOST2でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、各サーバーのORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

   BAMHOSTn> cd ORACLE_COMMON_HOME/common/bin
   BAMHOSTn> ./setNMProps.sh
   

   
   

   注意: クラスのロード失敗やその他の問題を回避するため、StartScriptEnabledプロパティを使用します。StartScriptEnabledの詳細は、第16.13.5項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」を参照してください。

   
   
   
   

   注意: 第3章「エンタープライズ・デプロイメント用のネットワークの準備」の共有記憶域構成で示しているように、BAMサーバーがローカル記憶域または共有記憶域でSOAとMW_HOMEを共有している場合には、setNMProps.shを再度実行する必要はありません。この場合、ノード・マネージャはすでに起動スクリプトを使用するように構成されています。

   
   

2. 次のコマンドを実行し、BAMHOST1でノード・マネージャを起動します。

   BAMHOST1> cd WL_HOME/server/bin
   BAMHOST1> ./startNodeManager.sh
   

   次のコマンドを実行し、BAMHOST2でノード・マネージャを起動します。

   BAMHOST2> cd WL_HOME/server/bin
   BAMHOST2> ./startNodeManager.sh
   

12.11 BAMシステムの起動

Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーWLS_BAM1を起動します。

ここで示す手順は、SOAHOST2でWS-MまたはSOAの管理対象サーバーについて事前にホスト名の検証が行われており、さらに、SOAHOST2でノード・マネージャがすでに実行されていることを前提としています。

BAMHOST1上の管理対象サーバーWLS_BAM1を起動する手順は次のとおりです。

1. WLS_BAM1管理対象サーバーを起動します。

   1. http://ADMINVHN:7001/consoleのOracle WebLogic Server管理コンソールにログインします。

   2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

   3. 「制御」タブをクリックします。

   4. 表の「サーバー」列の「WLS_BAM1」を選択します。

   5. 「起動」をクリックします。

2. 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台のサーバーを起動した後で別のサーバーを起動した場合です。

1. WLS_BAM2管理対象サーバーを起動します。

   1. http://ADMINVHN:7001/consoleのOracle WebLogic管理コンソールにログインします。

   2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

   3. 「制御」タブをクリックします。

   4. 表の「サーバー」列の「WLS_BAM2」を選択します。

   5. 「起動」をクリックします。

2. http://BAMHOST2:9001/OracleBAMにアクセスしてWLS_BAM2のステータスを確認します。

12.12 BAMHOST1でBAMサーバーを使用するためのBAM Webアプリケーションの構成

BAMHOST1でBAM Serverを使用するためのOracleBamWeb(WLS_BAM1)アプリケーションおよびOracleBamWeb(WLS_BAM2)アプリケーションを構成する手順は次のとおりです。

1. http://ADMINVHN:7001/emのOracle Enterprise Manager Fusion Middleware Controlにアクセスします。

2. ナビゲーション・ツリーの「BAM」を開きます。

3. 「OracleBamWeb(WLS_BAM1)」を右クリックします。

4. コンテキスト・メニューから「BAM Webプロパティ」を選択します。「BAM Webプロパティ」ページが表示されます。

5. 次のプロパティを定義します。

   • アプリケーションURLにhttps://soa.mycompany.com:443と入力します。

   • サーバー名にBAMHOST1VHN1と入力します。第3.4項「IPおよび仮想IPについて」の表3-1も参照してください。

   • 「適用」をクリックします。

   • Mbeanブラウザを使用し、サーバーのリスニング・ポートを変更します。

     • Oracle Enterprise Manager Fusion Middleware Controlにログインします。

     • 左側のナビゲーション・ツリーのドメイン名を展開します。

     • 左側のナビゲーション・ツリーのBAM項目を展開します。

     • 右上のBAMドロップダウン・メニューから「MBeanブラウザ」を選択します。

     • 右側で「oracle.bam.web」→「サーバー」→「アプリケーション」→「構成」→「BAMWebConfig」に移動します。

     • 「ServerPort」フィールドの「デフォルト」値を「9001」に置き換えます。

6. ナビゲーション・ツリーで「OracleBamWeb(WLS_BAM2)」を選択し、手順3から5を繰り返します。

12.13 WLS_BAMn管理対象サーバーについてのOracle HTTP Serverの構成

WLS_BAMn管理対象サーバーが属するBAM_ClusterにOracle HTTP Serverからルーティングをできるようにするには、次のようにWebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。

1. 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のように表示されます。

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
   

例12-1 soa_vh.confファイル

<VirtualHost *:7777>
    ServerName https://soa.mycompany.com:443
    ServerAdmin [e-mail]
    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 /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サーバー・プラグインの使用』ガイドを参照してください。

12.14 Oracle HTTP Serverを介したアクセスの検証

URLを検証して、HTTP ServerからBAM_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。

URLを検証する手順は次のとおりです。

1. WLS_BAM2が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_BAM1を停止します。

2. WebHost1:7777/OracleBAMにアクセスして正常に機能していることを確認しますBAMサーバーが起動していないため、この時点ではレポートやデータを取得できません。

3. Oracle WebLogic Server管理コンソールでWLS_BAM1を起動します。

4. Oracle WebLogic Server管理コンソールでWLS_BAM2を停止します。

5. WebHost1:7777/OracleBAMにアクセスして正常に機能していることを確認します

12.15 WLS_BAM1サーバーのサーバー移行の構成

BAMの高可用性アーキテクチャでは、サーバーの移行を使用してBAMサーバーのシングルトン・サービスを障害から保護します。障害が発生した場合にBAMHOST2で再起動できるようにWLS_BAM1管理対象サーバーを構成します。この構成では、WebLogic Serverの移行によってフェイルオーバーの対象となる特定の浮動IPをWLS_BAM1でリスニングします。WLS_BAM1管理対象サーバーのサーバー移行を構成する手順は次のとおりです。

• ステップ1: サーバー移行リース・テーブルのユーザーおよび表領域の設定

• ステップ2: 管理コンソールによるリース用のGridlinkデータ・ソースの作成

• ステップ3: ノード・マネージャのプロパティ・ファイルの編集

• ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する

• ステップ5: BAMHOSTnノードのノード・マネージャと管理サーバーのホスト名検証の有効化

• ステップ6: サーバー移行ターゲットの構成

• ステップ7: サーバー移行のテスト

注意: SOAに対してサーバーの移行を構成済であれば、それと同じデータ・ソースとデータベース・スキーマをBAMステムで使用できます。この場合、ステップ1から4は不要ですが、対応するサーバー移行/リース・データソースをBAMクラスタにターゲット設定する必要があります。

12.15.1 サーバー移行リース・テーブルのユーザーおよび表領域の設定

ユーザーと表領域を作成する手順は次のとおりです。

1. 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;
   

2. 次のように、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;
   

3. 次のように、leasing.ddlスクリプトを使用してリース・テーブルを作成します。

   1. WL_HOME/server/db/oracle/920ディレクトリにあるleasing.ddlファイルを、使用するデータベース・ノードにコピーします。

   2. データベースにleasingユーザーとして接続します。

   3. 次のように、leasing.ddlスクリプトをSQL*Plusで実行します。

      SQL> @copy_location/leasing.ddl;
      

12.15.2 管理コンソールによるリース用のGridlinkデータ・ソースの作成

第14.3項「管理コンソールによるリース用のGridLinkデータ・ソースの作成」の手順に従って、Oracle WebLogic Server管理コンソールを使用して、リース・テーブルに使用するGridLinkデータ・ソースを作成します。

12.15.3 ノード・マネージャのプロパティ・ファイルの編集

サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。nodemanager.propertiesファイルは次のディレクトリにあります。

WL_HOME/common/nodemanager 

次のプロパティを追加してサーバー移行が正常に動作するようにします。

• Interface

  Interface=eth0
  

  このプロパティは浮動IP(eth0など)のインタフェース名を指定します。

  
  

  注意: eth0:1やeth0:2のようなサブ・インタフェースは指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

  
  

• NetMask

  NetMask=255.255.255.0
  

  このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。

• UseMACBroadcast

  UseMACBroadcast=true
  

  このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力は次のようになります。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意: サーバーのプロパティ(起動プロパティ)が設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

1. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

2. WL_HOME/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。

   
   

   注意: 共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、NetMaskプロパティやInterfaceプロパティにはノードごとに異なる値が必要です。この場合、環境変数を使用してノードごとに個別のパラメータを指定します。たとえば、SOAHOSTnで異なるインタフェース(eth3)を使用するには、SOAHOSTn> export JAVA_OPTIONS=-DInterface=eth3としてInterface環境変数を使用します。この環境変数をシェルに設定した後、ノード・マネージャを起動します。

   
   

12.15.4 wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定

wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定します。

表12-5に示すファイルをPATH環境変数で指定していることを確認します。

表12-5 PATH環境変数に必要なファイル

ファイル	ディレクトリの場所
wlsifconfig.sh	ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration
wlscontrol.sh	WL_HOME/common/bin
nodemanager.domain	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

12.15.5 BAMHOSTnノードのノード・マネージャと管理サーバーのホスト名検証の有効化

BAMHOSTnノードのノード・マネージャと管理サーバー間でのホスト名検証証明書を有効化します。ホスト名検証証明書を有効化するには、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

12.15.6 サーバー移行ターゲットの構成

クラスタの移行ターゲットを構成するには、DataSourceForAutomaticMigrationプロパティをtrueに設定します。

クラスタ内の移行ターゲットを構成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. 表の「名前」列で、移行を構成するクラスタ(BAM_Cluster)をクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。この場合は、「BAMHOST1」と「BAMHOST2」を選択します。

7. 自動移行に使用するデータソースを選択します。この場合は、leasingデータ・ソースを選択します。

8. 「保存」をクリックします。

9. 「変更のアクティブ化」をクリックします。

10. WLS_BAM1についてのみ、サーバー移行の候補となるマシンを設定します。WLS_BAM2はサーバー移行を使用しません。

    1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

    2. 移行を構成するサーバーを選択します。

    3. 「移行」タブをクリックします。

    4. 「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。WLS_BAM1についてBAMHOST2を選択します。

    5. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。

       これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

    6. 「変更のアクティブ化」をクリックします。

    7. 管理サーバーとWLS_BAM1サーバーを再起動します。

       管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

ヒント: 「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。

12.15.7 サーバー移行のテスト

サーバーの移行が適切に行われていることを確認する手順は次のとおりです。

ノード1からテストする手順は次のとおりです。

1. WLS_BAM1管理対象サーバーを停止します。

   BAMHOST1> kill -9 pid
   

   pidは、その管理対象サーバーのプロセスID(PID)を指定します。次のコマンドを実行すると、ノードのPIDを識別できます。

   BAMHOST1> ps -ef | grep WLS_BAM1
   

2. ノード・マネージャのコンソールを確認します。WLS_BAM1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_BAM1の2回目の再起動を試行するまで待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

ノード2からテストする手順は次のとおりです。

1. ローカルのノード・マネージャ・コンソールを確認します。ノード1でのWLS_BAM1の再起動が前回試行されてから30秒間経過した後に、WLS_BAM1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。

2. BAMHOST1VHN1とsoa.mycompany.com/OracleBAMを使用してOracle BAMコンソールにアクセスします。

管理コンソールから移行を検証する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左のコンソールで「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」タブをクリックします。

   「移行の状態」の表に、移行の状態に関する情報が表示されます。

12.16 BAMクラスタ内の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の場合の手順は次のとおりです。

1. WLS_BAM1のドライバをBAMHOST1内で構成します。

2. BAMHOST2へのWLS_BAM1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内のBAMサーバーのディレクトリ構造を確認してください。

   DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/oracle_bam-11.1.1/config
   

12.17 BAM構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

ドメイン構成をバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

   1. opmnctlを使用してインスタンスを停止します。

      ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
      

   2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

      tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
      

   3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

      tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE
      

   4. opmnctlを使用してインスタンスを起動します。

      ORACLE_BASE/admin/instance_name/bin/opmnctl startall
      

2. データベースをバックアップします。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

   ORACLE_BASE/ admin/domain_name
   

   管理サーバーをバックアップする手順は次のとおりです。

   tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name