14 Exalogicエンタープライズ・デプロイメント用のトポロジの管理

この章では、Fusion Middleware SOAトポロジをセットアップした後に実行できるいくつかの操作について説明します。これらの操作には、トポロジのモニタリング、スケーリング、バックアップおよびトラブルシューティングが含まれます。

この章には次のトピックが含まれます:

• 第14.1項「トポロジの管理の概要」

• 第14.2項「SOAエンタープライズ・デプロイメント・トポロジにコンポジットおよびアーティファクトをデプロイする際のヒント」

• 第14.3項「SOAインフラストラクチャ・データベースでの領域の管理」

• 第14.4項「UMSドライバの構成」

• 第14.5項「トポロジのスケール・アップ(管理対象サーバーを既存ノードに追加)」

• 第14.6項「トポロジのスケール・アウト(管理対象サーバーを新しいノードに追加)」

• 第14.7項「管理サーバーの手動フェイルオーバーの検証」

• 第14.8項「Oracle SOAエンタープライズ・デプロイメントのバックアップ」

• 第14.9項「SQLNet接続のタイムアウトの防止」

• 第14.10項「失敗したBPELインスタンスとメディエータ・インスタンスのリカバリ」

• 第14.11項「サービス拒否攻撃や再帰的ノード攻撃を防ぐためのWebサービスの構成」

• 第14.12項「デプロイメント・プランおよびSOAインフラストラクチャ・アプリケーション更新での共有記憶域の使用方法」

• 第14.13項「HASとパフォーマンスの分離を向上させるための外部BPELキャッシュの使用方法」

• 第14.14項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」

14.1 トポロジの管理の概要

SOAエンタープライズ・デプロイメントを構成したら、この章の情報を使用してトポロジを管理します。

SOAアプリケーションは、様々な種類のコンポーネントで構成されるコンポジットとしてデプロイされます。SOAコンポジット・アプリケーションには次のものが含まれます。

• ルーティングのためのOracle Mediator、オーケストレーションのためのBPELプロセス、ワークフロー承認のためのヒューマン・タスク、SOAコンポジット・アプリケーションにJavaインタフェースを統合するためのSpring、ビジネス・ルールを使用するためのデシジョン・サービスなどのサービス・コンポーネント。

• 外部のサービス、アプリケーションおよびテクノロジにSOAコンポジット・アプリケーションを接続するためのバインディング・コンポーネント(サービスと参照)。

これらのコンポーネントが、1つのSOAコンポジット・アプリケーションに組み込まれています。この章では、Oracle Exalogicでのエンタープライズ・デプロイメント・トポロジのSOAコンポジット・アプリケーションの管理およびトラブルシューティングのヒントを示します。

SOAコンポジット・アプリケーションのモニタリングの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAコンポジット・アプリケーションのモニタリングに関する項を参照してください。

SOAコンポジット・アプリケーションの管理の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAコンポジット・アプリケーションの管理に関する項を参照してください。

スケール・アップまたはスケール・アウトによるトポロジの拡張が必要になることがあります。スケール・アップとスケール・アウトの違いおよびこれらのタスクの実行方法の詳細は、第14.5項「トポロジのスケール・アップ(管理対象サーバーを既存ノードに追加)」と第14.6項「トポロジのスケール・アウト(管理対象サーバーを新しいノードに追加)」を参照してください。

構成の変更の前後にはトポロジをバックアップします。構成変更の結果として発生する障害から保護するためにバックアップしておく必要のあるディレクトリとファイルについては、第14.8項「Oracle SOAエンタープライズ・デプロイメントのバックアップ」に記載しています。

この章では、トポロジの構成後に発生する可能性のある既知の問題の解決方法も示します。

14.2 SOAエンタープライズ・デプロイメント・トポロジにコンポジットおよびアーティファクトをデプロイする際のヒント

この項では、SOAエンタープライズ・デプロイメントにコンポジットおよびアーティファクトをデプロイする際のヒントを示します。コンポジットのデプロイ手順は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の「SOAコンポジット・アプリケーションのデプロイ」を参照してください。

特定のサーバー・アドレスへのコンポジットのデプロイ

SOAコンポジットをSOAエンタープライズ・デプロイメント・トポロジにデプロイする場合、ロード・バランサ・アドレス(soa.mycompany.com)にではなく、特定のサーバーのアドレスにデプロイします。ロード・バランサ・アドレスにデプロイするには、デプロイヤ・ノードから外部のロード・バランサ・アドレスへの直接接続が必要になることがあり、そのために、システムによって使用されるファイアウォールで追加ポートを開く必要が生じる場合があります。

B2Bコンソールを使用したアグリーメントのデプロイおよびメタデータのパージとインポート

B2Bの場合、アグリーメントのデプロイおよびメタデータのパージとインポートは、B2BコンソールのGUIからのみ実行してください。コマンド行ユーティリティは使用しないでぐたさい。これらの操作にコマンド行ユーティリティを使用すると、B2Bシステムで不整合やエラーが発生することがあります。

FODデプロイメントに関するその他の指示

SOA Fusion Order Demoをデプロイする場合は、FODのREADMEファイルで指定されたデプロイメント手順を完了した後、次の追加手順を完了します。

1. earファイルが各ノードにコピーされるように、Webアプリケーションのbuild.xmlファイルのnostageプロパティをfalseに変更します。FOD_dir\CreditCardAuthorization\binおよびFOD_dir\OrderApprovalHumanTask\binディレクトリにあるCreditCardAuthorizationおよびOrderApprvalHumanTask build.xmlファイルを編集して次のフィールドを変更します。

   <target name="deploy-application">
        <wldeploy action="deploy" name="${war.name}"
          source="${deploy.ear.source}" library="false"
          nostage="false"
          user="${wls.user}" password="${wls.password}"
          verbose="false" adminurl="${wls.url}"
          remote="true" upload="true"
          targets="${server.targets}" />
      </target>
   

   これを次のように変更します。

   <target name="deploy-application">
        <wldeploy action="deploy" name="${war.name}"
          source="${deploy.ear.source}" library="false"
          nostage="true"
          user="${wls.user}" password="${wls.password}"
          verbose="false" adminurl="${wls.url}"
          remote="true" upload="true"
          targets="${server.targets}" />
      </target>
   

2. Webアプリケーションのターゲットを変更して、デプロイメントが個別のサーバーでなくSOAクラスタにターゲット設定されるようにします。FOD_Dir/binディレクトリにあるFODのbuild.propertiesファイルを編集し、次のフィールドを変更します。

   # wls target server (for shiphome set to server_soa, for ADRS use AdminServer) 
   server.targets=SOA_Cluster (the SOA cluster name in your SOA EDG)
   

3. JMSシード・テンプレートを変更し、通常の宛先でなく共通分散宛先を使用して、JMSアーティファクトがエンタープライズ・デプロイメントJMSモジュールにターゲット設定されるようにします。FOD_DIR\bin\templatesディレクトリにあるcreateJMSResources.seedファイルを編集し、次のように変更します。

   # lookup the SOAJMSModule - it's a system resource
        jmsSOASystemResource = lookup("SOAJMSModule","JMSSystemResource")
   
        jmsResource = jmsSOASystemResource.getJMSResource()
       
        cfbean = jmsResource.lookupConnectionFactory('DemoSupplierTopicCF')
        if cfbean is None:
            print "Creating DemoSupplierTopicCF connection factory"
            demoConnectionFactory =
    jmsResource.createConnectionFactory('DemoSupplierTopicCF')
            demoConnectionFactory.setJNDIName('jms/DemoSupplierTopicCF')
            demoConnectionFactory.setSubDeploymentName('SOASubDeployment')
    .
        topicbean = jmsResource.lookupTopic('DemoSupplierTopic')
        if topicbean is None:
            print "Creating DemoSupplierTopic jms topic"
            demoJMSTopic = jmsResource.createTopic("DemoSupplierTopic")
            demoJMSTopic.setJNDIName('jms/DemoSupplierTopic')
            demoJMSTopic.setSubDeploymentName('SOASubDeployment')
   

   これを次のように変更します。

   jmsSOASystemResource = lookup("SOAJMSModule","JMSSystemResource")
   
   jmsResource = jmsSOASystemResource.getJMSResource()
   
    topicbean=jmsResource.lookupTopic('DemoSupplierTopic_UDD')
   
   if topicbean is None: 
            print "Creating DemoSupplierTopicC jms topic"
            #create a udd - so clustering is automatically working and done
            demoJMSTopic = jmsResource.createUniformDistributedTopic("DemoSupplierTopic_UDD")
   
            demoJMSTopic.setJNDIName('@jms.topic.jndi@')
            #Replace the subdeployment name with the one that appears in the WLS AdminConsole as listed for the SOAJMSModule
   
            demoJMSTopic.setSubDeploymentName()
   
   else: print "Found DemoSupplierTopic_UDD topic – noop"
   

   FOD JMSリソースに別のデプロイメント・モジュールを使用することが理想的です。

4. build.propertiesファイルのmanaged.server.hostエントリを更新し、2つのSOAサーバーのうちの1つのEoIBリスニング・アドレスにします。

5. build.propertiesのadmin.server.hostエントリを更新し、管理サーバーのEoIBリスニング・アドレスにします。

14.3 SOAインフラストラクチャ・データベースでの領域の管理

すべてのコンポジットがデータベースを頻繁に使用するわけではありませんが、CUBE_INSTANCEおよびMEDIATOR_INSTANCEスキーマにはかなりの量のデータがサービス・エンジンによって生成されます。データベースの領域が不足すると、SOAコンポジットが機能しなくなることがあります。

SOAインフラストラクチャ・データベースの領域を管理する手順は、次のとおりです。

• Oracle Enterprise Manager Fusion Middleware Controlコンソール(のダッシュボードなど)でoracle.fabric.common.FabricInvocationExceptionなどの汎用エラーがないか確認します。

• SOAサーバーのログで次のようなエラーを検索します。

  Error Code: 1691
  ...
  ORA-01691: unable to extend lob segment
  SOAINFRA.SYS_LOB0000108469C00017$$ by 128 in tablespace SOAINFRA
  

  これらのメッセージは、通常、データ・ファイルの追加や既存のファイルへの領域の追加を必要とする可能性がある、データベースの領域の問題を示します。SOAデータベース管理者は、領域を追加する際に使用する拡張ポリシーおよびパラメータを決定する必要があります。

• 古いコンポジット・インスタンスをパージしてSOAインフラストラクチャ・データベースのサイズを縮小します。このタイプの操作に、Oracle Enterprise Manager Fusion Middleware Controlを使用することはお薦めしません。多くの場合、これらの操作でトランザクション・タイム・アウトが発生します。リポジトリ作成ユーティリティには、インスタンスのパージ用に提供されているパッケージがあります。次に例を示します。

  DECLARE 
    FILTER INSTANCE_FILTER := INSTANCE_FILTER(); 
   
     MAX_INSTANCES NUMBER; 
    DELETED_INSTANCES NUMBER; 
    PURGE_PARTITIONED_DATA BOOLEAN := TRUE; 
   BEGIN 
     . 
    FILTER.COMPOSITE_PARTITION_NAME:='default'; 
    FILTER.COMPOSITE_NAME := 'FlatStructure'; 
    FILTER.COMPOSITE_REVISION := '10.0';   
    FILTER.STATE := fabric. STATE_UNKNOWN; 
    FILTER.MIN_CREATED_DATE := to_timestamp('2010-09-07','YYYY-MM-DD'); 
    FILTER.MAX_CREATED_DATE := to_timestamp('2010-09-08','YYYY-MM-DD'); 
    MAX_INSTANCES := 1000; 
   . 
    DELETED_INSTANCES := FABRIC.DELETE_COMPOSITE_INSTANCES( 
      FILTER => FILTER, 
      MAX_INSTANCES => MAX_INSTANCES, 
      PURGE_PARTITIONED_DATA => PURGE_PARTITIONED_DATA 
    );
  

  これによって2010-09-07から2010-09-08までの間に作成されたFlatStructureコンポジット(バージョン10)のUNKNOWN状態の最初の1000個のインスタンスが削除されます。提供されるSQLパッケージに含まれている可能性のある操作の詳細は、Oracle Fusion Middleware Oracle SOA Suite管理者ガイドのSOAコンポジット・アプリケーションの管理に関する項を参照してください。正しく消去するには、常に、提供されているスクリプトを使用してください。composite_dn表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。詳細は、Oracle FMW MAAサイトにあるSOA 11gデータベースの肥大化の管理戦略のペーパーを参照してください。

14.4 UMSドライバの構成

UMSドライバの構成は、SOAクラスタ内に自動的に伝播されません。クラスタ内にUMSドライバの構成を伝播する手順は、次のとおりです。

• UMSドライバの構成を、そのドライバを使用するエンタープライズ・デプロイメント・トポロジ内のすべてのサーバーに適用します。

• サーバー移行を使用する場合、サーバーは別のノードのドメイン・ディレクトリに移動します。フェイルオーバー・ノード内でUMSドライバ構成をあらかじめ作成しておきます。UMSドライバの構成ファイルは、次のディレクトリにあります。

  MSERVER_HOME//servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml
  

  *は、デプロイ中にOracle WebLogic Serverによってランダムに生成されるディレクトリ名を表します。たとえば、3682yqです。

フェイルオーバーに備えて、サーバー移行を強制的に実行することでUMSドライバ構成ファイルを作成し、そのファイルをソース・ノードからコピーします。

たとえば、BAM用のファイルを作成する手順は次のとおりです。

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

2. BAMHOST2へのWLS_BAM1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内でUMSドライバ構成用の次のディレクトリ構造を確認します。

   cd MSERVER_HOME/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/
   

   (*はデプロイメント中にWLSによってランダムに生成されるディレクトリ名を表し、たとえば、3682yqです)。

3. ドライバ構成ファイルをBAMHOST1からBAMHOST2にリモート・コピーします。

   BAMHOST1> scp MSERVER_HOME/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml 
   oracle@BAMHOST2:MSERVER_HOME/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/
   

4. これらの変更を有効にするため、ドライバを再起動します。

   ドライバを再起動する手順は、次のとおりです。

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

   2. ナビゲーション・ツリーの環境ノードを開きます。

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

   4. ドライバを選択します。

   5. 「停止」→「作業完了時」をクリックし、操作を確認します。

   6. ドライバの状態が「準備完了」に遷移するまで待ちます(必要に応じて、管理コンソール・ページを更新します)。

   7. 再度ドライバを選択し、「起動」→「すべてのリクエストを処理」をクリックして操作を確認します。

ドライバのプロパティが保持されていることを、Oracle Enterprise Manager Fusion Middleware Controlで確認します。

14.5 トポロジのスケール・アップ(管理対象サーバーを既存ノードに追加)

トポロジをスケール・アップするときには、Fusion Middlewareコンポーネントを使用して構成されている管理対象サーバーまたはWSM-PMを含む管理対象サーバーを実行するノードがすでに存在しています。このノードには、共有記憶域内にWebLogic ServerホームとOracle Fusion Middleware SOAホームが含まれています。これらの既存のインストール(WebLogic Serverホーム、Oracle Fusion Middlewareホーム、ドメイン・ディレクトリなど)を使用して、新しい管理対象サーバーをWLS_SOAおよびWLS_WSMという名前で作成します。WLSまたはSOAのバイナリを新しい場所にインストールしたり、packおよびunpackを実行する必要はありません。

この項の内容は次のとおりです。

• 第14.5.1項「スケール・アップの計画」

• 第14.5.2項「Oracle SOAのスケール・アップ手順」

• 第14.5.3項「Oracle Service Busのスケール・アップ手順」

14.5.1 スケール・アップの計画

サーバー移行を使用するサーバーをスケール・アップする場合、それに必要とされる適切な容量およびリソース割当てを計画します。例として次のシナリオを考えてみます。

• サーバー1がノード1上にあり、このサーバーはノード2上のサーバー2を使用するクラスタ内サーバー移行を使用します。

• スケール・アップ操作によって、ノード1のクラスタにサーバー3が追加されます。これもサーバー移行を使用します。

このシナリオでは、結果的にノード1またはノード2ですべてのサーバー(サーバー1、サーバー2、サーバー3および管理サーバー)が実行される状況が起こりえます。したがって、サーバー移行を使用するすべてのサーバーが結果的に(サーバー移行の候補マシンの構成で定義される)1つのノード上で実行されるという最悪の場合のシナリオに備えて十分なリソースを割り当てて各ノードを設計する必要があります。

14.5.2 Oracle SOAのスケール・アップ手順

SOAトポロジをスケール・アップする手順は、次のとおりです。

1. 新しいサーバー用のTX永続ストアを、他のノードから見える場所に、このガイドに示す共有記憶域の推奨事項に従って構成します。

   1. 管理コンソールから、「Server_name」→「サービス」タブを選択します。

   2. 「デフォルト・ストア」の下の「ディレクトリ」に、データ・ファイルを格納するディレクトリのパスを入力します。

      ASERVER_HOME/tlogs
      

2. Oracle WebLogic Server管理コンソールを使用して、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。クローニング元の管理対象サーバーとなるものは、新しい管理対象サーバーを実行するノード上にすでに存在しているサーバーです。

   管理対象サーバーのクローンを作成する手順は、次のとおりです。

   1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。

   2. 「ロックして編集」をクリックして、クローニングする管理対象サーバー(たとえばWLS_SOA1)を選択します。

   3. 「クローンの作成」をクリックします。

   4. 新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーを識別する番号です。ここでは、WLS_SOA1が実行されていたノード1に新しいサーバーを追加します。

   以降の手順では、新しいサーバーをSOAHOST1に追加します。そこではすでにWLS_SOA1が実行されています。

3. リスニング・アドレスには、この新しい管理対象サーバーに使用するホスト名またはIPを指定します。SOAサーバーのリスニング・アドレスには、この新しい管理対象サーバーに使用する新しい浮動IPoIBホスト名を指定します。これは、新しいサーバーのデフォルト・リスニング・アドレスであり、Exalogicラックの内部浮動アドレスです。この仮想IPは、すでに稼働している管理対象サーバーで使用されているものとは異なるものにする必要があります。

   
   

   注意: WLS_WSMサーバーの場合、WSMサーバーはサーバー移行を使用しないため、既存のWSMサーバーに使用されているものと異なるポートおよび同じリスニング・アドレスを使用できます。第8.17項「Oracle WSM用Javaオブジェクト・キャッシュの構成」の説明に従って、Javaオブジェクト・キャッシュ構成ユーティリティを再度実行し、JOC分散キャッシュに新しいサーバーを含めます。同じノード上の複数のWLS_WSMサーバーに同一の検出ポートを使用できます。第8.17項に示す手順をWLS_WSMサーバーごとに繰り返して、サーバー・リストを更新します。

   
   

4. SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。

   
   

   注意: WLS_WSM管理対象サーバーをスケール・アップする場合は、新しい管理対象サーバー上でSOAおよびUMSのJMSサーバーを作成する必要はありません。この手順は、WLS_SOA管理対象サーバーをスケール・アップする場合にのみ必要です。

   
   

   SOAおよびUMS用のJMSサーバーを作成する手順は、次のとおりです。

   1. Oracle WebLogic Server管理コンソールを使用して、SOAJMSServerおよびPS6SOAJMSServer_auto_nという新しいJMSサーバー(これらの作成方法は後述する)用に、SOAJMSFileStore_nおよびPS6SOAJMSFileStore_auto_Nという名前の2つの新しい永続ストアを作成します。JMS永続ストアのディレクトリとして、第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているストアのパスを指定します。

      ASERVER_HOME/jms
      

   2. SOAに対してSOAJMSServer_nおよびPS6SOAJMSServer_auto_nという名前の2つの新しいJMSサーバーを作成します。これらのJMSサーバーに対してSOAJMSFileStore_nおよびPS6SOAJMSFileStore_auto_Nを使用します。JMSサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_SOAn)を指定します。

   3. 新しいUMS JMSサーバー(後述の手順で作成する)用に新しい永続ストアを作成し、それに、たとえばUMSJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているストアのパスを指定します。

      ASERVER_HOME/jms
      

      
      

      注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすくするためと分離のために、後続の手順では個別の永続ストアを使用します。

      
      

   4. UMS用に新しいJMSサーバー(例: UMSJMSServer_N)を作成します。このJMSサーバーにUMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_SOAn)を指定します。

   5. BPMシステムの場合のみ: BPMJMSServer_NおよびAGJMSServer_auto_nという新しいJMSサーバー(後述の手順で作成する)用のBPMJMSFileStore_nおよびAGJMSFileStore_auto_nという名前の2つの新しい永続ストアを作成します。JMS永続ストアのディレクトリとして、第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているストアのパスを指定します。

      ASERVER_HOME/jms
      

      
      

      注意: このディレクトリは、管理対象サーバーを起動する前に存在している必要があります。それ以外の場合は起動操作に失敗します。 新しいBPM JMSサーバー用のストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすくするためと分離のために、後続の手順では個別の永続ストアを使用します。

      
      

   6. BPMシステムの場合のみ: BPM用にBPMJMSServer_NおよびAGJMSServer_auto_nという名前の2つの新しいサーバーを作成します。これらのJMSサーバーに対してBPMJMSFileStore_NおよびAGJMSFileStore_auto_nを使用します。これらのサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_SOAn)を指定します。

   7. 拡張操作中に変更された可能性があるため、UMSJMSSystemResourceのターゲットとして、SOA_Clusterを指定します。そのためには、「サービス」→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(先ほどクローニングで作成したWLS_SOAnも含む)が選択されていることを確認してください。

   8. SOA、UMSおよびBPMの各JMSモジュール(該当する場合)のSubDeploymentターゲットを更新して、先ほど作成したJMSサーバーを含めます。

      そのためには、「サービス」→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA用: SOAJMSModule、BPM用: BPMJMSModuleおよびUMS用: UMSSYtemResource、またはSOA用: SOAJMSModuleおよびUMS用: UMSSYtemResource)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

      
      

      注意: このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、またはUMSJMSServerXXXXXX、またはBPMJMSServerXXXXXXの形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

      
      

      それをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを、SOAの場合はSOAJMSServer_Nを、BPMの場合はBPMJMSServer_Nを追加します)。

5. 第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」の説明に従って、新しいサーバーのコンポジットをデプロイするようにOracle Coherenceを構成します。

   
   

   注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。 Dtangosol.coherence.localhost=SOAHOST1-PRIV-Vn

   
   

6. クラスタ・アドレスを更新し、新しいサーバーを含めます。

   1. 管理コンソールから、「環境」→「クラスタ」を選択します。

   2. 「SOA_Cluster」サーバーをクリックします。

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

   4. 新しいサーバーのアドレスおよびポートを「クラスタ・アドレス」フィールドに追加します。次に例を示します。

      SOAHOST1-PRIV-V1:8011,SOAHOST2-PRIV-V1:8001,SOAHOST1-PRIV-Vn

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

7. 新しい管理対象サーバーに対するホスト名検証を無効化します。

   WLS_SOAn管理対象サーバーを起動および検証する前に、ホスト名検証を無効化する必要があります。それは、Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの間の通信用のサーバー証明書を構成した後で、再度有効化できます。

   新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効化する手順は、次のとおりです。

   1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

   2. 「ドメイン構造」ウィンドウから、「環境」ノードを開き、「サーバー」をクリックします。

      「サーバーのサマリー」ページが表示されます。

   3. 表の「名前」列で移行を構成するサーバーの名前(ハイパーリンクで表示される)をクリックします。

      選択したサーバーの設定ページが表示されます。

   4. 「SSL」タブをクリックし、「詳細」をクリックします。

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

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

      
      

      注意: ホスト検証を使用している場合は、新しい仮想IPアドレスをキー・ストアに追加し、サーバーID(秘密鍵の別名)を変更します。

      
      

8. 新しいサーバー用に適切なHTTP、T3およびレプリケーション・チャネルを作成します。第9.6項「EoIBを介したHTTPクライアントとT3クライアント用のネットワーク・チャネルの構成」および第9.11項「クラスタ・レベルのセッション・レプリケーション拡張機能の有効化」を参照してください。

   クローニング後は、管理対象サーバー・チャネルのリストされたサーバー・リスナーが正しくなくなります。適切なサーバー・リスナーを入力します。

9. Oracle Traffic Directorのorigin-server-pool-1に新しいサーバーのリスニング・アドレスを追加します。詳細は、第7.7項「Exalogicエンタープライズ・デプロイメント向けOracle Traffic Director仮想サーバーの定義」を参照してください。

10. 管理コンソールでFactoryPropertiesフィールドを使用して新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の下の対応するセルをクリックし、次のように入力します。

    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://SOAHOST1-PRIV-V1:8001,SOAHOST2-PRIV-V1:8001,SOAHOST1-PRIV-Vn:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic
    

    保存とアクティブ化をクリックします。

    FactoryProperties値の変更の詳細は、第9.12.2項「Oracle JMSアダプタの高可用性の有効化」を参照してください。

11. 新しい管理対象サーバー用のサーバー移行を構成します。Oracle WebLogic Server管理コンソールを使用してサーバー移行を構成する手順は、次のとおりです。

    
    

    注意: これはスケール・アップ操作であるため、ノードにノード・マネージャが存在していること、およびサーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済であることが必要です。新しいSOA管理対象サーバー用の浮動IPも、すでに存在している必要があります。

    
    

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

    2. 表の「名前」列で移行を構成するサーバーの名前(ハイパーリンクで表示される)をクリックします。

       選択したサーバーの設定ページが表示されます。

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

    4. 「移行の構成」セクションの「使用可能」ウィンドウで、右向き矢印をクリックすることで移行に参加するサーバーを選択します。ノード上にすでに存在するサーバー用のものと同じ移行ターゲットを選択してください。

       たとえば、SOAHOST1(すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

       
       

       注意: 移行中に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。

       
       

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

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

    6. 新しいサーバーのリスニング・アドレスがnodemanager.propertiesで定義されている範囲内に収まらない場合、それを適切に更新します。

       bond0=SOAHOST1-PRIV-V1-ip- soahost1-priv-vn-ip,NetMask=255.255.248.0
       

       詳細は、第12.2.2項「ノード・マネージャのプロパティ・ファイルの編集」を参照してください。

    7. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

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

12. この新しいサーバーのサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードから次のように実行します。

    1. 次のコマンドを使用してWLS_SOAn管理対象サーバーを停止します。

       kill -9 pid
       

       このノードのPID (プロセスID)は次のコマンドを使用して特定できます。

       ps -ef | grep WLS_SOAn
       

    2. ノード・マネージャ・コンソールで、WLS_SOA1の浮動IPが無効になったことを示すメッセージがないかモニターします。

    3. ノード・マネージャによってWLS_SOAnの2回目の再起動が試行されるまで待機します。

       ノード・マネージャは、この再起動を試行するまで、30秒間待機します。

    4. ノード・マネージャがサーバーを再起動したら再度停止します。

       ノード・マネージャによって、サーバーが再度ローカルで再起動されないことを示すメッセージがログに記録されます。

14.5.3 Oracle Service Busのスケール・アップ手順

1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することで、Oracle Service Busサーバーをスケール・アップできます。

前提条件

Oracle Service Busサーバーをスケール・アップする前に、次の前提条件を確認します。

• すでに、Oracle Service Busコンポーネントを使用して構成されている管理対象サーバーを実行しているクラスタが存在しています。

• ノードには、既存の管理対象サーバーのミドルウェア・ホーム、Oracleホーム(SOAとOracle Service Bus)およびドメイン・ディレクトリが含まれています。

• クローニング元の管理対象サーバーが、新しい管理対象サーバーを実行するノード上にすでに存在しています。

新しいWLS_OSBサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。SOAまたはOracle Service Busのバイナリを新しい場所にインストールしたり、packやunpackを実行したりする必要はありません。

Oracle Service Busサーバーをスケール・アップする手順は、次のとおりです。

1. 新しいサーバー用のTX永続ストアを、他のノードから見える場所に、このガイドに示す共有記憶域の推奨事項に従って構成します。

   1. 管理コンソールから、「Server_name」→「サービス」タブを選択します。

   2. 「デフォルト・ストア」の下の「ディレクトリ」に、データ・ファイルを格納するディレクトリのパスを入力します。

      ASERVER_HOME/tlogs
      

2. 管理コンソールを使用し、WLS_OSBnのクローンを新しい管理対象サーバーにします。

   1. 「環境」→「サーバー」を選択します。

   2. クローンを作成する管理対象サーバー(WLS_OSB1など)を選択します。

   3. 「クローンの作成」を選択します。

      新しい管理対象サーバーにWLS_OSBnという名前を付けます。nは新しい管理対象サーバーを識別する番号です。

      以降の手順では、新しいサーバーをすでにWLS_OSB1が実行されているSOAHOST1に追加します。

3. サーバーのリスニング・アドレスには、この新しい管理対象サーバーに使用する新しい浮動IPoIBホスト名を指定します。これは、新しいOSBサーバーのデフォルト・リスニング・アドレスであり、Exalogicラックの内部浮動アドレスです。この仮想ホスト名は、すでに稼働している管理対象サーバーで使用されているものとは異なるものにする必要があります。

   管理対象サーバーのリスニング・アドレスを設定する手順は、次のとおりです。

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

   2. 「チェンジ・センター」で「ロックして編集」をクリックします。

   3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

   4. 「サーバー」をクリックします。

      「サーバーのサマリー」ページが表示されます。

   5. 表の「名前」列で、更新するリスニング・アドレスを持つ管理対象サーバーを選択します。

      その管理対象サーバーの「設定」ページが表示されます。

   6. 「リスニング・アドレス」を「SOAHOST1-PRIV-Vn」に設定し、「保存」をクリックします。

      管理対象サーバーを再起動して変更を有効にします。

4. クラスタ・アドレスを更新し、新しいサーバーを含めます。

   1. 管理コンソールから、「環境」→「クラスタ」を選択します。

   2. 「OSB_Cluster」サーバーをクリックします。

      OSB_Clusterの「設定」画面が表示されます。

   3. 「チェンジ・センター」で「ロックして編集」をクリックします。

   4. 新しいサーバーのアドレスおよびポートを「クラスタ・アドレス」フィールドに追加します。次に例を示します。

      SOAHOST1-PRIV-V2:8011,SOAHOST2-PRIV-V2:8011,SOAHOST1-PRIV-VN:8011
      

5. 新しいサーバー用に適切なHTTPおよびT3チャネルを作成します。

   クローニング後は、管理対象サーバー・チャネルのリストされたサーバー・リスナーが正しくなくなります。適切なサーバー・リスナーを入力します。

   詳細は、第9.6項「EoIBを介したHTTPクライアントとT3クライアント用のネットワーク・チャネルの構成」を参照してください。

6. Oracle Traffic Directorのosb-poolに新しいサーバーのリスニング・アドレスを追加します。

   詳細は、第7.7項「Exalogicエンタープライズ・デプロイメント向けOracle Traffic Director仮想サーバーの定義」を参照してください。

7. Oracle Service Bus構成にJMSリクエスト/レスポンス機能を使用するビジネス・サービスが1つ以上含まれている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールを使用して次の手順を実行します。

   1. 「チェンジ・センター」で「作成 」をクリックし、セッションを作成します。

   2. プロジェクト・エクスプローラを使用して、JMSリクエスト/レスポンスを使用するビジネス・サービスを見つけて、選択します。

      このタイプのビジネス・サービスには、「サービス・タイプ」として「メッセージ・サービス」が表示されます。

   3. 「詳細の表示」ページの下部にある「編集」をクリックします。

   4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

   5. 「ビジネス・サービスの編集 - サマリー」ページで、「保存」をクリックします。

   6. JMSリクエスト/レスポンスを使用する残りの各ビジネス・サービスに前述の手順を繰り返します。

   7. 「チェンジ・センター」で、「アクティブ化」をクリックします。

   8. 管理対象サーバーを再起動します。

   9. 管理サーバーを再起動します。

      これで、ビジネス・サービスは、拡張されたドメインで操作できるように構成されました。

      
      

      注意: JMS MessageID相関スキームを使用するビジネス・サービスの場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加します。キューとトピック宛先の構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。

      
      

8. Oracle Service Bus構成にクラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスが1つ以上含まれている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールを使用して次の手順を実行します。

   1. 「チェンジ・センター」で「作成 」をクリックし、セッションを作成します。

   2. プロジェクト・エクスプローラを使用して、クラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスを見つけて、選択します。

   3. 「詳細の表示」ページの下部にある「編集」をクリックします。

   4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

   5. 「プロキシ・サービスの編集 - サマリー」ページで、「保存」をクリックします。

   6. クラスタ・アドレスを含むJMSエンドポイントを使用する残りの各プロキシ・サービスに、前述の手順を繰り返します。

   7. 「チェンジ・センター」で、「アクティブ化」をクリックします。

   8. 管理対象サーバーを再起動します。

      これで、プロキシ・サービスは、拡張されたドメインで操作できるように構成されました。

9. 新しいサーバーのOracle Service Busの結果キャッシュのCoherence構成を更新します。

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

   2. 「チェンジ・センター」で「ロックして編集」をクリックします。

   3. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

   4. 「サーバー」をクリックします。

      「サーバーのサマリー」ページが表示されます。

   5. 表の「名前」列で、サーバーの名前(ハイパーリンク)をクリックします。

      選択したサーバーの設定ページが表示されます。

   6. 「サーバーの起動」タブをクリックします。

      WLS_OSBnについて(改行を入れずに1行で)次のように入力します。

      -DOSB.coherence.localhost=soahost1-priv-vn -DOSB.coherence.localport=7890
      -DOSB.coherence.wka1=SOAHOST1-PRIV-V2 -DOSB.coherence.wka1.port=7890 
      -DOSB.coherence.wka2=SOAHOST2-PRIV-V2 -DOSB.coherence.wka1.port=7890
      

      
      

      注意: この構成では、WLS_OSBnの起動時に、サーバーWLS_OSB1とWLS_OSB2が実行されている(このガイドの残りの部分で使用しているように仮想ホスト名SOAHOST1VHNおよびSOAHOST2VHNでリスニングしている)必要があります。これにより、WLS_OSBnは、WLS_OSB1またはWLS_OSB2のいずれかによって起動されたCoherenceクラスタに、指定されたWKAアドレスを使用して参加できます。また、3つのサーバーすべてを再起動する場合、WLS_OSBnが起動される前にWLS_OSB1とWLS_OSB2が起動されることを確認します。これにより、WLS_OSBnは、WLS_OSB1またはWLS_OSB2のいずれかによって起動されたクラスタに参加するようになります。サーバーの起動順序が重要でない場合は、WLS_OSB1とWLS_OSB2のWKAとしてWLS_OSBnのホストとポートを追加し、さらにWLS_OSBnのWKAとしてWLS_OSBnを追加します。

      
      

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

      Oracle Service Busサーバーを再起動して、変更内容を有効にします。

10. 管理コンソールでFactoryPropertiesフィールドを使用して新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の下の対応するセルをクリックし、次のように入力します。

    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://SOAHOST1-PRIV-V2:8011,SOAHOST2-PRIV-V2:8011,SOAHOSTn-PRIV-V1:8011;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1
    

    保存とアクティブ化をクリックします。

11. 新しい管理対象サーバーにOracle Service Busのレポート作成/内部宛先のJMSサーバーと永続ストアを作成します。

    1. Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、それにOSB_rep_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているように、共有記憶域上のディレクトリである必要があります。次に例を示します。

       ASERVER_HOME/jms/
       

       このストアを、新しくクローニングで作成したサーバー(WLS_OSBn)にターゲット指定します。

    2. Oracle Service Busの新しいJMSサーバーを作成します(たとえば、OSB_rep_JMSServer_N)。このJMSサーバーに対して、OSB_rep_JMSFileStore_Nを使用します。OSB_rep_JMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_OSBn)を指定します。

    3. 先ほど作成したOSB JMSサーバーが含まれるように、jmsResources Oracle Service Bus JMSモジュールのSubDeploymentターゲットを更新します。

       「サービス」→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。

       「jmsResources」(表の「名前」列内のハイパーリンク)をクリックします。jmsResourcesの「設定」ページが表示されます。

       「サブデプロイメント」タブをクリックします。jmsresourcesのサブデプロイメント・モジュールが表示されます。

       
       

       注意: 宛先のこのサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OSB1とWLS_OSB2)のJMS構成から生成されたwlsbJMSServerXXXXXXという形式のランダム名です。

       
       

       「wlsbJMSServerXXXXXX」サブデプロイメントをクリックし、新しいOSB_rep_JMSServer_nサーバーが含まれるようにターゲットを更新します。

12. 新しい管理対象サーバーにOSB JAX-RPCのJMSサーバー、永続ストアおよび宛先を作成します。

    
    

    注意: WebLogic Advanced Web Services for JAX-RPC Extensionでは、通常の(非分散)宛先を使用して、ローカルに処理するサービスに対するリクエストがローカル・メンバーにのみエンキューされることを保証します。

    
    

    1. Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、それにWsee_rpc_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているように、共有記憶域上のディレクトリである必要があります。

    2. OSB JAX-RPCの新しいJMSサーバーを作成します(たとえば、OSB_rpc_JMSServer_N)。このJMSサーバーに対して、Wsee_rpc_JMSFileStore_Nを使用します。OSB_rpc_JMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_OSBn)を指定します。

    3. 「サービス」ノード→「メッセージング」ノードを開いて、WseeJMSModule OSB JMSモジュールを宛先および先ほど作成したOSB JMSサーバーで更新します。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「WseeJmsModule」(表の「名前」列内のハイパーリンク)をクリックします。WseeJmsModuleの「設定」ページが表示されます。ステップdからvを実行して、この手順を完了します。

    4. 「チェンジ・センター」で「ロックして編集」→「新規」をクリックします。

    5. 「キュー」を選択し、「保存」をクリックします。

    6. 「新しいサブデプロイメントの作成」をクリックします。

    7. デフォルトの名前を受け入れて「OK」をクリックします。

    8. ターゲットとして「OSB_rpc_JMSServer_n」を選択し、「終了」をクリックします。

    9. 宛先のローカルJNDI名を更新します。

       「チェンジ・センター」で「ロックして編集」をクリックします。

       WseeJmsModuleの「設定」ページで、「DefaultCallbackQueue-WseeJmsServer_auto_n」宛先をクリックします。

       一般の「構成」タブで、「詳細」をクリックします。

       ローカルJNDI名をweblogic.wsee.DefaultCallbackQueueに更新します。

    10. DefaultQueue-WseeJmsServer_auto_nキューに対して、JNDI名としてweblogic.wsee.DefaultQueue-WseeJmsServer_auto_nを、ローカルJNDI名としてweblogic.wsee.DefaultQueueを使用して、ステップdからhを繰り返します。

13. 新しいSAFエージェントを作成し、そのターゲットとして、新しく追加した管理対象サーバーを指定します。

    1. Oracle WebLogic Server管理コンソールで、「サービス」→「メッセージング」→「ストア・アンド・フォワード・エージェント」を開きます。

    2. 新しいSAFエージェントReliableWseeSAFAgent_auto_Nを追加します。

    3. 永続ストアWsee_rpc_JMSFileStore_N (OSB JAX-RPC用に作成された永続ストア)を選択します。

    4. SAFエージェントのターゲットとして、新しい管理対象サーバーを指定し、変更をアクティブにします。

14. 新しい管理対象サーバーに対するホスト名検証を無効化します。WLS_OSBn管理対象サーバーを起動および検証する前に、ホスト名検証を無効化します。それは、Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの間の通信用のサーバー証明書を構成した後で、再度有効化できます。新しいサーバーのクローンの元となったソース・サーバーでホスト名検証がすでに無効化されている場合、これらの手順は不要です(ホスト名検証の設定はクローニングされたサーバーに伝播されているため)。

    ホスト名検証を無効にする手順は次のとおりです。

    1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

    2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

       「サーバーのサマリー」ページが表示されます。

    3. 表の「名前」列で「WLS_OSBn」を選択します。

       そのサーバーの「設定」ページが表示されます。

    4. 「SSL」タブをクリックし、「詳細」をクリックします。

    5. 「ホスト名の検証」を「なし」に設定し、「保存」をクリックします。

15. そのノードでノード・マネージャがまだ起動されていない場合はそれを起動します。ノード・マネージャを起動するには、次のように、既存のノードから共有記憶域にあるインストールを使用します。

    SOAHOSTN> WL_HOME/server/bin/startNodeManager
    

16. 管理コンソールから、新しい管理対象サーバーを起動してテストします。

    1. クラスタ内の既存の管理対象サーバーを停止します。

    2. 新たに作成した管理対象サーバーWLS_OSBnが起動していることを確認します。

    3. 次のURLを使用して、新しく作成した管理対象サーバー上のアプリケーションにアクセスします。

       http://vip:port/sbinspection.wsil
       

17. 新しい管理対象サーバー用のサーバー移行を構成します。

    
    

    注意: これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。新しいOracle Service Bus管理対象サーバー用の浮動IPがすでに存在している必要があります。

    
    

    サーバー移行を構成する手順は、次のとおりです。

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

    2. 左側のペインで、「環境」を開き、「サーバー」を選択します。

    3. 移行を構成する新しい管理対象サーバーの名前を選択します。

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

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

    6. ノード上の既存のサーバーに使用しているものと同じ移行ターゲットを選択します。

       たとえば、SOAHOST1(すでにWLS_OSB1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_OSB2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

       移行中に複数の管理対象サーバーを同時に実行するために十分な空きリソースが確保されていることを確認してください。

    7. 「サーバーの自動移行を有効化」オプションを選択し、「保存」をクリックします。

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

    8. 新しいサーバーのリスニング・アドレスがnodemanager.propertiesで定義されている範囲内に収まらない場合、それを適切に更新します。

       bond0=SOAHOST1-PRIV-V1-ip- soahost1-priv-vn-ip,NetMask=255.255.248.0
       

       詳細は、第13.4項「ノード・マネージャのプロパティ・ファイルの編集」を参照してください。

    9. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

18. この新規サーバーを追加したノードから、この新規サーバーのサーバー移行をテストします。

    1. 管理対象サーバーのPID (プロセスID)で次のコマンドを実行することで、WLS_OSBn管理対象サーバーを停止します。

       kill -9 pid
       

       このノードのPIDは次のコマンドを使用して特定できます。

       ps -ef | grep WLS_OSBn
       

       
       

       注意: Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。次に例を示します。 taskkill /f /pid pid pidは、管理対象サーバーのプロセスIDです。 WLS_OSBn管理対象サーバーのプロセスIDを確認するには、次のコマンドを実行します。 MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v

       
       

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

    3. ノード・マネージャによって、WLS_OSBnの2回目の再起動が試行されるまで待ちます。

       ノード・マネージャは、この再起動を試行するまで、30秒間待機します。

    4. ノード・マネージャがサーバーを再起動したら再度停止します。

       ノード・マネージャによって、サーバーが再度ローカルで再起動されないことを示すメッセージがログに記録されます。

       
       

       注意: サーバーの移行後、そのサーバーを元のノードにフェイルバックするには、Oracle WebLogic管理コンソールからその管理対象サーバーを停止し、再起動します。適切なノード・マネージャによって、最初に割り当てられていたマシン上の管理対象サーバーが起動されます。

       
       

14.6 トポロジのスケール・アウト(管理対象サーバーを新しいノードに追加)

トポロジをスケール・アウトする場合は、SOA、OSB、およびWSM-PM(またはそれらのいずれか)で構成されている新しい管理対象サーバーを新しいノードに追加します。

この項の内容は次のとおりです。

• 第14.6.1項「トポロジのスケール・アウトの前提条件」

• 第14.6.2項「Oracle SOAのスケール・アウト手順」

• 第14.6.3項「Oracle Service Busのスケール・アウト手順」

14.6.1 トポロジのスケール・アウトの前提条件

この項の手順を実行する前に、次の条件を満たしているか確認します。

• SOAおよびWSM-PMで構成されている管理対象サーバーが、トポロジ内の既存のノードで実行されている必要があります。

• 新しいノードが、WebLogic ServerおよびSOAの既存のホーム・ディレクトリにアクセスできます。(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerまたはSOAのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpackおよびunpackを実行してドメイン構成をブートストラップする必要はあります。)

• ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておきます。ノード内のoraInventoryを更新し、これに共有記憶域のインストールをアタッチするには、次の場所でattachHome.shスクリプトを使用します。

  ORACLE_HOME/oui/bin/
  

  ミドルウェア・ホーム・リストを更新してWL_HOMEを追加または削除するには、次のディレクトリにあるbeahomelistファイルを編集します。

  MW_HOME/bea
  

14.6.2 Oracle SOAのスケール・アウト手順

トポロジをスケール・アウトする手順は、次のとおりです。

1. 新しいサーバー用のTX永続ストアを、他のノードから見える場所に、このガイドに示す共有記憶域の推奨事項に従って構成します。

   1. 管理コンソールから、「Server_name」→「サービス」タブを選択します。

   2. 「デフォルト・ストア」の下の「ディレクトリ」に、データ・ファイルを格納するディレクトリのパスを入力します。

      ASERVER_HOME/tlogs
      

2. 新しいノード上に、既存のFusion Middlewareホームおよび第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」に示す残りのプライベートおよび共有マウントをマウントします。

3. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチするには、次のコマンドを実行します。

   SOAHOSTn>cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh
   SOAHOSTn>./attachHome.sh -jreLoc MSERVER_HOME/jrockit_160_<version>
   

   ミドルウェア・ホーム・リストを更新するには、beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、それを編集し)、それにMW_HOMEを追加します。beahomelistファイルは、次のディレクトリにあります。

   MW_HOME/bea
   

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

5. この新しいノード用に新しいマシンを作成し、そのマシンをドメインに追加します。

6. マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのプライベートIPoIBをマッピングします。

7. Oracle WebLogic Server管理コンソールを使用して、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。それにWLS_SOAnまたはWLS_WSMnという名前を付けます。nは数字です。これを、前に作成した新しいマシンに割り当てます。

   
   

   注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

   
   

8. 新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。

   このサーバーでサーバー移行を使用する予定である場合(推奨)、これはこのサーバーの仮想IP(浮動IPとも呼ばれる)にする必要があります。この仮想IPは、既存の管理対象サーバーに使用しているものとは別のものにする必要があります。たとえば、SOAHOSTn-PRIV-V1などです。

9. WLS_WSMサーバーの場合、第8.17項「Oracle WSM用Javaオブジェクト・キャッシュの構成」の説明に従って、Javaオブジェクト・キャッシュ構成ユーティリティを再度実行し、JOC分散キャッシュに新しいサーバーを含めます。

10. SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。

    
    

    注意: WSM_WSM管理対象サーバーまたはBAM Webアプリケーション・システムをスケール・アップする場合は、新しい管理対象サーバー上でSOAおよびUMSのJMSサーバーを作成する必要はありません。この手順は、WLS_SOA管理対象サーバーをスケール・アップする場合にのみ必要です。

    
    

    次のようにして、SOAおよびUMS用のJMSサーバーを作成します。

    1. Oracle WebLogic Server管理コンソールを使用して、SOAJMSServerおよびPS6SOAJMSServer_auto_nという新しいJMSサーバー(これらの作成方法は後述する)用に、SOAJMSFileStore_nおよびPS6SOAJMSFileStore_auto_Nという名前の2つの新しい永続ストアを作成します。JMS永続ストアのディレクトリとして、第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているストアのパスを指定します。

       ASERVER_HOME/jms/
       

    2. SOAに対してSOAJMSServer_nおよびPS6SOAJMSServer_auto_nという名前の2つの新しいJMSサーバーを作成します。これらのJMSサーバーに対してSOAJMSFileStore_nおよびPS6SOAJMSFileStore_auto_Nを使用します。JMSサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_SOAn)を指定します。

    3. 新しいUMSJMSServer用に新しい永続ストアを作成し、それに、たとえばUMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリとして、JMS永続ストアのディレクトリとして第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているパスを指定します。

       ASERVER_HOME/jms
       

       
       

       注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすくするためと分離のために、後続の手順では個別の永続ストアを使用します。

       
       

    4. UMS用に新しいJMSサーバー(例: UMSJMSServer_N)を作成します。このJMSサーバーにUMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_SOAn)を指定します。

    5. BPMシステムの場合のみ: BPMJMSServer_NおよびAGJMSServer_auto_nという新しいJMSサーバー(後述の手順で作成する)用のBPMJMSFileStore_nおよびAGJMSFileStore_auto_nという名前の2つの新しい永続ストアを作成します。JMS永続ストアのディレクトリとして、第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているストアのパスを指定します。

    6. BPMシステムの場合のみ: BPM用にBPMJMSServer_NおよびAGJMSServer_auto_nという名前の2つの新しいサーバーを作成します。これらのJMSサーバーに対してBPMJMSFileStore_NおよびAGJMSFileStore_auto_nを使用します。これらのサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_SOAn)を指定します。

    7. SOA、UMSおよびBPMの各JMSモジュール(該当する場合)のSubDeploymentターゲットを更新して、先ほど作成したJMSサーバーを含めます。これを実行するには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA用: SOAJMSModule、BPM用: BPMJMSModuleおよびUMS用: UMSSYtemResource)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

       
       

       注意: このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

       
       

       それをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを、SOAの場合はSOAJMSServer_Nを、BPMの場合はBPMJMSServer_Nを追加します)。保存とアクティブ化をクリックします。

    8. 拡張操作中に変更された可能性があるため、UMSJMSSystemResourceのターゲットとして、SOA_Clusterを指定します。そのためには、「サービス」→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(先ほどクローニングで作成したWLS_SOAnも含む)が選択されていることを確認してください。

    9. SOA、UMSおよびBPMの各JMSモジュール(該当する場合)のSubDeploymentターゲットを更新して、先ほど作成したJMSサーバーを含めます。

       そのためには、「サービス」→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA用: SOAJMSModule、UMS用: UMSSYtemResource、BRM用: BPMJMSModule)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

       
       

       注意: このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

       
       

       それをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを、SOAの場合はSOAJMSServer_Nを、BPMの場合はBPMJMSServer_Nを追加します)。

11. 第8.5.2項「SOAHOST1およびSOAHOST2でのノード・マネージャの構成と起動」に示すように、新しいノードのノード・マネージャ・ディレクトリおよびプロパティを構成します。

12. 次のように、SOAHOST1でpackコマンドを実行し、テンプレート・パックを作成します。

    cd ORACLE_COMMON_HOME/common/bin
    

    ./pack.sh -managed=true -domain=ASERVER_HOME
    -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
    

    次のように、SOAHOSTnでunpackコマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。

    SOAHOSTN> cd ORACLE_COMMON_HOME/common/bin
    

    SOAHOSTN> ./unpack.sh -domain=MSERVER_HOME
    -template=soadomaintemplateScale.jar
    -app_dir=APP_DIR
    

    
    

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

    
    

13. 第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」の説明に従って、新しいサーバーのコンポジットをデプロイするようにOracle Coherenceを構成します。

    
    

    注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。 Dtangosol.coherence.localhost=SOAHOSTnVHN1-PRIV-V1

    
    

14. 管理コンソールでFactoryPropertiesフィールドを使用して新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の下の対応するセルをクリックし、次のように入力します。

    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://SOAHOST1-PRIV-V1:8001,SOAHOST2-PRIV-V1:8001,SOAHOSTn-PRIV-V1;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1
    

    保存とアクティブ化をクリックします。

15. 新しいサーバー用の永続ストアを構成します。これは、第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているように、他のノードから見える場所である必要があります。

    管理コンソールから、Server_name→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」の下で、デフォルト永続ストアによってそのデータ・ファイルが格納されるフォルダへのパスを入力します。

16. クラスタ・アドレスを更新し、新しいサーバーを含めます。

    1. 管理コンソールから、「環境」→「クラスタ」を選択します。

    2. 「SOA_Cluster」サーバーをクリックします。

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

    4. 新しいサーバーのアドレスおよびポートを「クラスタ・アドレス」フィールドに追加します。次に例を示します。

       SOAHOST1-PRIV-V1:8011,SOAHOST2-PRIV-V1:8001,SOAHOSTn-PRIV-V1
       

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

17. 新しい管理対象サーバーに対するホスト名検証を無効化します。WLS_SOAn管理対象サーバーを起動および検証する前に、ホスト名検証を無効化する必要があります。それは、Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの間の通信用のサーバー証明書を構成した後で、再度有効化できます。

    新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効化する手順は、次のとおりです。

    1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

    2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

    3. 「サーバー」をクリックします。

       「サーバーのサマリー」ページが表示されます。

    4. 表の「名前」列で「WLS_SOAn」を選択します。

       そのサーバーの「設定」ページが表示されます。

    5. 「SSL」タブをクリックします。

    6. 「詳細」をクリックします。

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

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

18. 新しいサーバー用に適切なHTTP、T3およびレプリケーション・チャネルを作成します。詳細は、第9.6項「EoIBを介したHTTPクライアントとT3クライアント用のネットワーク・チャネルの構成」および第9.11項「クラスタ・レベルのセッション・レプリケーション拡張機能の有効化」を参照してください。

19. Oracle Traffic Directorのorigin-server-pool-1に新しいサーバーのリスニング・アドレスを追加します。詳細は、第7.7項「Exalogicエンタープライズ・デプロイメント向けOracle Traffic Director仮想サーバーの定義」を参照してください。

    管理コンソールでFactoryPropertiesフィールドを使用して新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の下の対応するセルをクリックし、次のように入力します。

    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://SOAHOST1-PRIV-V1:8001,SOAHOST2-PRIV-V1:8001,SOAHOSTN-PRIV-V1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic
    

20. 保存とアクティブ化をクリックします。

21. 新しいノード上のノード・マネージャを起動します。ノード・マネージャを起動するには、次のディレクトリにあるstartNodeManager.shを使用します。

    SOAHOSTn>  /u02/private/oracle/config/nodemanager/startNodeManager.sh 
    

22. Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動およびテストします。

    1. 新しく作成した管理対象サーバーWLS_SOAnが稼働していることを確認します。

    2. 次のURLを使用してExalogicラック内からアプリケーションにアクセスします。

       http://SOAHOSTn-PRIV-V1:8001/soa-infra/
       

       アプリケーションは、機能可能である必要があります。

23. 新しい管理対象サーバー用のサーバー移行を構成します。

    Oracle WebLogic Server管理コンソールにログインし、サーバー移行を構成します。

    サーバー移行を構成する手順は、次のとおりです。

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

    2. 表の「名前」列から、移行を構成するサーバー(ハイパーリンクとして表示される)を選択します。そのサーバーの「設定」ページが表示されます。

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

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

       
       

       注意: 新しいサーバーの移行ターゲットとして負荷が最も少ないマシンを指定します。必要なキャパシティ・プランニングを完了し、このノードで、追加の管理対象サーバーを維持するために十分なリソースが使用可能になるようにする必要があります。

       
       

    5. 「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャによって、障害が発生したサーバーをターゲット・ノードで自動的に起動できるようになります。

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

    7. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

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

24. クラスタ・アドレスを更新し、新しいサーバーを含めます。

    1. 管理コンソールから、「環境」→「クラスタ」を選択します。

    2. 「SOA_Cluster」サーバーをクリックします。

       SOA_Clusterの「設定」画面が表示されます。

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

    4. 新しいサーバーのアドレスおよびポートを「クラスタ・アドレス」フィールドに追加します。次に例を示します。

       SOAHOST1-PRIV-V1:8001,SOAHOST2-PRIV-V1:8001,SOAHOSTn-PRIV1:8001
       

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

25. この新規サーバーを追加したノードから、この新規サーバーのサーバー移行をテストします。

    1. 次のコマンドを実行することで、WLS_SOAn管理対象サーバーを突然停止します。

       kill -9 pid
       

       このノードのPID (プロセスID)は次のコマンドを使用して特定できます。

       ps -ef | grep WLS_SOAn
       

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

    3. ノード・マネージャによって、WLS_SOAnの2回目の再起動が試行されるまで待ちます。ノード・マネージャは、この再起動を試行するまで、30秒間待機します。

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

14.6.3 Oracle Service Busのスケール・アウト手順

トポロジをスケール・アウトする場合は、Oracle Service Busで構成されている新しい管理対象サーバーを新しいノードに追加します。

前提条件

Oracle Service Busトポロジをスケール・アウトする前に、次の前提条件を満たしていることを確認します。

• Oracle Service Busで構成されている管理対象サーバーが、トポロジ内の既存のノードで実行されている必要があります。

• 新しいノードは、オプションで、WebLogic ServerおよびOracle Service Busのインストールの既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーWLS_OSBを作成するには、共有記憶域内の既存のインストールを使用します。この場合、すべての新しい場所にWebLogic ServerまたはOracle Service Busのバイナリをインストールする必要はありませんが、Oracle Service Busサーバーを、同じドメインの他のサーバー(SOAサーバー)が含まれているマシンにスケーリングする場合以外は、packおよびunpackコマンドを実行して新しいノードのドメイン構成をブートストラップする必要があります。

• ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておきます。ノード内のoraInventoryを更新し、これに共有記憶域のインストールをアタッチするには、次のディレクトリにあるattachHome.shファイルを使用します。

  ORACLE_HOME/oui/bin/
  

  ミドルウェア・ホーム・リストを更新してWL_HOMEを追加または削除するには、次のディレクトリにあるbeahomelistファイルを編集します。

  MW_HOME/bea
  

トポロジをスケール・アウトする手順は、次のとおりです。

1. 新しいサーバー用のTX永続ストアを、他のノードから見える場所に、このガイドに示す共有記憶域の推奨事項に従って構成します。

   1. 管理コンソールから、「Server_name」→「サービス」タブを選択します。

   2. 「デフォルト・ストア」の下の「ディレクトリ」に、データ・ファイルを格納するディレクトリのパスを入力します。

      ASERVER_HOME/tlogs
      

2. 新しいノード上に、既存のFusion Middlewareホームおよび残りのプライベートおよび共有マウント(第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」の説明に従う)をマウントします。

3. 次のコマンドを使用して、共有記憶域内のORACLE_HOMEをプライベートOracleインベントリにアタッチします。

   SOAHOSTn>cd MW_HOME/soa/
   SOAHOSTn>./attachHome.sh -jreLoc MW_HOME/jrockit_160_<version>
   

   ミドルウェア・ホーム・リストを更新するには、次のディレクトリにbeahomelistファイルを作成(別のWebLogicインストールがノード内に存在する場合は、それを編集)します。

   MW_HOME/bea/
   

   リストにMW_HOMEを追加します。

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

5. この新しいノード用に新しいマシンを作成し、そのマシンをドメインに追加します。

6. マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのプライベートIPoIBをマッピングします。

7. Oracle WebLogic Server管理コンソールを使用して、WLS_OSB1をクローニングして新しい管理対象サーバーを作成します。それにWLS_OSBnという名前を付けます。nは数字です。それを新しいマシンに割り当てます。

   
   

   注意: これらの手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加します。

   
   

8. リスニング・アドレスには、この新しい管理対象サーバーに使用する仮想ホスト名を指定します。お薦めされるとおりにこのサーバーにサーバー移行を使用する予定である場合、この仮想ホスト名によって、それを別のノードに移動することが可能になります。この仮想ホスト名は、OSB/SOAドメインによって使用されるノードで実行されている(同じドメイン内であるか異なるドメイン内であるかに関係なく)他の管理対象サーバーで使用されるものとは異なる必要があります。

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

   2. 「チェンジ・センター」で「ロックして編集」をクリックします。

   3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

   4. 「サーバー」をクリックします。

      「サーバーのサマリー」ページが表示されます。

   5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。

      その管理対象サーバーの「設定」ページが表示されます。

   6. 「リスニング・アドレス」を「SOAHOSTn-PRIV-V1」に設定し、「保存」をクリックします。

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

   8. 管理対象サーバーを再起動します。

9. クラスタ・アドレスを更新し、新しいサーバーを含めます。

   1. 管理コンソールから「環境」→「クラスタ」を選択します。

   2. 「OSB_Cluster」サーバーをクリックします。

      OSB_Clusterの「設定」画面が表示されます。

   3. 「チェンジ・センター」で「ロックして編集」をクリックします。

   4. 新しいサーバーのアドレスおよびポートを「クラスタ・アドレス」フィールドに追加します。次に例を示します。

      SOAHOST1-PRIV-1:8011,SOAHOST2-PRIV-1:8011,SOAHOSTn-PRIV-1:8011
      

10. 新しいサーバー用に適切なHTTPおよびT3チャネルを作成します。

    詳細は、第9.6項「EoIBを介したHTTPクライアントとT3クライアント用のネットワーク・チャネルの構成」を参照してください。

11. Oracle Traffic Directorのosb-poolに新しいサーバーのリスニング・アドレスを追加します。

    詳細は、第7.7項「Exalogicエンタープライズ・デプロイメント向けOracle Traffic Director仮想サーバーの定義」を参照してください。

12. 新しい管理対象サーバーにOracle Service Busのレポート作成/内部宛先のJMSサーバーと永続ストアを作成します。

    1. Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、それにOSB_rep_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているように、共有記憶域上のディレクトリである必要があります。

       
       

       注意: このディレクトリは、管理対象サーバーを起動する前に存在している必要があります。それ以外の場合は起動操作に失敗します。 ASERVER_HOME/jms/OSB_rep_JMSFileStore _N

       
       

    2. Oracle Service Busの新しいJMSサーバーを作成します(たとえば、OSB_rep_JMSServer_N)。このJMSサーバーに対して、OSB_rep_JMSFileStore_Nを使用します。OSB_rep_JMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_OSBn)を指定します。

    3. 先ほど作成したOracle Service Bus JMSサーバーが含まれるように、jmsresources Oracle Service Bus JMSモジュールのSubDeploymentターゲットを更新します。

       「サービス」→「メッセージング」ノードを開きます。

       Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。

       「jmsresources」(表の「名前」列内のハイパーリンク)をクリックします。jmsResourcesの「設定」ページが表示されます。

       「サブデプロイメント」タブを開きます。jmsresourcesのサブデプロイメント・モジュールが表示されます。

       
       

       注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OSB1とWLS_OSB2)のJMS構成から生成されたwlsbJMSServerXXXXXXという形式のランダム名です。 「wlsbJMSServerXXXXXX」サブデプロイメントをクリックし、新しいOSB_rep_JMSServer_Nサーバーが含まれるようにターゲットを更新します。

       
       

13. 新しい管理対象サーバーにOSB JAX-RPCのJMSサーバー、永続ストアおよび宛先を作成します。

    
    

    注意: WebLogic Advanced Web Services for JAX-RPC Extensionでは、通常の(非分散)宛先を使用して、ローカルに処理するサービスに対するリクエストがローカル・メンバーにのみエンキューされることを保証します。

    
    

    1. Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、それにWsee_rpc_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているように、共有記憶域上のディレクトリである必要があります。

       
       

       注意: このディレクトリは、管理対象サーバーを起動する前に存在している必要があります。それ以外の場合は起動操作に失敗します。 ASERVER_HOME/jms/Wsee_rpc_JMSFileStore_N

       
       

    2. Oracle Service Bus JAX-RPCの新しいJMSサーバーを作成します(たとえば、OSB_rpc_JMSServer_N)。このJMSサーバーに対して、Wsee_rpc_JMSFileStore_Nを使用します。OSB_rpc_JMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_OSBn)を指定します。

    3. 次のようにして、WseeJMSModule Oracle Service Bus JMSモジュールを、宛先および先ほど作成したOracle Service Bus JMSサーバーで更新します。

       「サービス」→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。

       「WseeJmsModule」(表の「名前」列内のハイパーリンク)をクリックします。WseeJmsModuleの「設定」ページが表示されます。

       ステップdからjを実行して、この手順を完了します。

    4. 「チェンジ・センター」で「ロックして編集」→「新規」をクリックします。

    5. 「キュー」を選択し、「次へ」をクリックします。

    6. キューの名前としてDefaultCallbackQueue-WseeJmsServer_auto_nを入力します。

    7. JNDI名としてweblogic.wsee.DefaultCallbackQueue-WseeJmsServer_auto_nを入力し、「次へ」をクリックします。

    8. 「新しいサブデプロイメントの作成」をクリックします。

    9. デフォルトの名前を受け入れて「OK」をクリックします。

    10. ターゲットとして「OSB_rpc_JMSServer_n」を選択し、「終了」をクリックします。

    11. 変更内容を有効化します。

    12. 宛先のローカルJNDI名を更新します。

        「チェンジ・センター」で「ロックして編集」をクリックします。

        WseeJmsModuleの「設定」ページで、「DefaultCallbackQueue-WseeJmsServer_auto_n」宛先をクリックします。

        一般の「構成」タブで、「詳細」をクリックします。

        ローカルJNDI名をweblogic.wsee.DefaultCallbackQueueに更新します。

14. 新しいSAFエージェントを作成し、そのターゲットとして、新しく追加した管理対象サーバーを指定します。

    Oracle WebLogic Server管理コンソールで、「サービス」→「メッセージング」→「ストア・アンド・フォワード・エージェント」を開き、新しいSAFエージェントReliableWseeSAFAgent_auto_Nを追加します。

    永続ストアWsee_rpc_JMSFileStore_N (Oracle Service Bus JAX-RPC用に作成された永続ストア)を選択します。SAFエージェントのターゲットとして、新しい管理対象サーバーを指定し、変更をアクティブにします。

15. 新しいサーバー用に適切なHTTPおよびT3チャネルを作成します。

    詳細は、第9.6項「EoIBを介したHTTPクライアントとT3クライアント用のネットワーク・チャネルの構成」を参照してください。

16. Oracle Traffic Directorのosb-poolに新しいサーバーのリスニング・アドレスを追加します。

    詳細は、第7.7項「Exalogicエンタープライズ・デプロイメント向けOracle Traffic Director仮想サーバーの定義」を参照してください。

17. Oracle Service Bus構成にJMSリクエスト/レスポンス機能を使用するビジネス・サービスが1つ以上含まれている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールを使用して次の手順を実行します。

    1. 「チェンジ・センター」で「作成 」をクリックし、セッションを作成します。

    2. プロジェクト・エクスプローラを使用して、JMSリクエスト/レスポンスを使用するビジネス・サービスを見つけて、選択します。

       このタイプのビジネス・サービスには、「サービス・タイプ」として「メッセージ・サービス」が表示されます。

    3. 「詳細の表示」 ページの下部にある「編集」をクリックします。

    4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

    5. 「ビジネス・サービスの編集 - サマリー」ページで、「保存」をクリックします。

    6. JMSリクエスト/レスポンスを使用する残りの各ビジネス・サービスに前述の手順を繰り返します。

    7. 「チェンジ・センター」で、「アクティブ化」をクリックします。

    8. 管理対象サーバーを再起動します。

    9. 管理サーバーを再起動します。

       これで、ビジネス・サービスは、拡張されたドメインで操作できるように構成されました。

       
       

       注意: JMS MesageID相関スキームを使用するビジネス・サービスの場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加します。キューとトピック宛先の構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。

       
       

18. Oracle Service Bus構成にクラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスが1つ以上含まれている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールを使用して次の手順を実行します。

    1. 「チェンジ・センター」で「作成 」をクリックし、セッションを作成します。

    2. プロジェクト・エクスプローラを使用して、クラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスを見つけて、選択します。

    3. 「詳細の表示」ページの下部にある「編集」をクリックします。

    4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

    5. 「プロキシ・サービスの編集 - サマリー」ページで、「保存」をクリックします。

    6. クラスタ・アドレスを含むJMSエンドポイントを使用する残りの各プロキシ・サービスに、前述の手順を繰り返します。

    7. 「チェンジ・センター」で、「アクティブ化」をクリックします。

    8. 管理対象サーバーを再起動します。

    これで、プロキシ・サービスは、拡張されたドメインで操作できるように構成されました。

19. 新しいサーバーのOracle Service Busの結果キャッシュのCoherence構成を更新します。

    1. Oracle WebLogic Server管理コンソールにログインします。「チェンジ・センター」で「ロックして編集」をクリックします。

    2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

    3. 「サーバー」をクリックします。

       「サーバーのサマリー」ページが表示されます。

    4. 表の「名前」列で、サーバーの名前(ハイパーリンク)をクリックします。

       選択したサーバーの設定ページが表示されます。

    5. 「サーバーの起動」タブをクリックします。

    6. 「詳細」をクリックします。

    7. WLS_OSBnについて(改行を入れずに1行で)次のように入力します。

       -DOSB.coherence.localhost=SOAHOSTn-PRIV-1 -DOSB.coherence.localport=7890 
       -DOSB.coherence.wka1=SOAHOST1-PRIV-1 -DOSB.coherence.wka1.port=7890 
       -DOSB.coherence.wka2=SOAHOST2-PRIV-1 -DOSB.coherence.wka1.port=7890
       

       
       

       注意: 前の構成では、WLS_OSBnの起動時にはサーバーWLS_OSB1およびWLS_OSB2が実行中です。これにより、WLS_OSBnは、WLS_OSB1またはWLS_OSB2のいずれかによって起動されたCoherenceクラスタに、指定されたWKAアドレスを使用して参加できます。また、3つのサーバーすべてを再起動する場合、WLS_OSBnの前にWLS_OSB1とWLS_OSB2が起動されることを確認します。これにより、WLS_OSBnは、WLS_OSB1またはWLS_OSB2のいずれかによって起動されたクラスタに参加するようになります。サーバーの起動順序が重要でない構成の場合は、WLS_OSB1とWLS_OSB2のWKAとしてWLS_OSBnのホストとポートを追加し、さらにWLS_OSBnのWKAとしてWLS_OSBnを追加します。

       
       

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

       Oracle Service Busサーバーを再起動します。

20. 管理コンソールでFactoryPropertiesフィールドを使用して新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の下の対応するセルをクリックし、次のように入力します。

    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahost1-priv-1:8001,soahost2-priv-1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1
    

    保存とアクティブ化をクリックします。

21. 第8.5.2項「SOAHOST1およびSOAHOST2でのノード・マネージャの構成と起動」に示すように、新しいノードのノード・マネージャ・ディレクトリおよびプロパティを構成します。

22. 次のように、SOAHOST1でpackコマンドを実行し、テンプレート・パックを作成します。

    cd ORACLE_COMMON_HOME/common/bin
    
    ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/soadomain/
    -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
    

    次のように、SOAHOSTNでunpackコマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。

    cd MW_HOME/soa/common/bin
     
    ./unpack.sh -domain=MSERVER_HOME/ -template=soadomaintemplateScale.jar
    

23. 新しいサーバー用のTX永続ストアを、他のノードから見える場所に、共有記憶域に関する推奨事項に従って構成します。

    1. 管理コンソールから、サーバー名を選択し、「サービス」タブを選択します。

    2. 「ディレクトリ」の「デフォルト・ストア」の下で、デフォルト永続ストアによってそのデータ・ファイルが格納されるフォルダへのパスを入力します。

24. 新しい管理対象サーバーに対するホスト名検証を無効化します。

    WLS_OSBn管理対象サーバーを起動および検証する前に、ホスト名検証を無効化します。それは、Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの間の通信用のサーバー証明書を構成した後で、再度有効化できます。新しいサーバーのクローンの元となったソース・サーバーでホスト名検証がすでに無効化されている場合、これらの手順は省略できます(ホスト名検証の設定はクローニングされたサーバーに伝播されています)。

    ホスト名検証を無効にする手順は次のとおりです。

    1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

    2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

    3. 「サーバー」をクリックします。

       「サーバーのサマリー」ページが表示されます。

    4. 表の「名前」列で「WLS_OSBn」を選択します。

       そのサーバーの「設定」ページが表示されます。

    5. 「SSL」タブをクリックします。

    6. 「詳細」をクリックします。

    7. 「ホスト名の検証」を「なし」に設定し、「保存」をクリックします。

25. 既存のノードから共有記憶域にあるインストールを使用して、新しいノード上のノード・マネージャを起動します。次のように、新しいノードのホスト名をパラメータとして渡します。

    SOAHOSTN> WL_HOME/server/bin/startNodeManager new_node_ip
    

26. Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動およびテストします。

    1. クラスタ内の既存の管理対象サーバーをすべて停止します。

    2. 新しく作成した管理対象サーバーWLS_OSBnが稼働していることを確認します。新しく作成した管理対象サーバー上のアプリケーションにアクセスします。

       http://vip:port/sbinspection.wsil
       

       アプリケーションは、機能可能である必要があります。

27. 新しい管理対象サーバー用のサーバー移行を構成します。

    
    

    注意: 前の手順で、このノードのノード・マネージャのプライベート・ディレクトリをすでに作成してあります。新しいサーバーのリスニング・アドレスおよびチャネルを考慮して、第13章「Exalogicエンタープライズ・デプロイメント用のサーバー移行の構成」に示すようにノード・マネージャのプロパティを更新します。

    
    

    サーバー移行を構成する手順は、次のとおりです。

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

    2. 左側のペインで、「環境」を開き、「サーバー」を選択します。

    3. 表の「名前」列から、移行を構成するサーバー(ハイパーリンクとして表示される)を選択します。

       そのサーバーの「設定」ページが表示されます。

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

    5. 「移行の構成」セクションの「使用可能」フィールドで、サーバーの移行先のマシンを選択して、右向き矢印をクリックします。

       たとえば、SOAHOST1(すでにWLS_OSB1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_OSB2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

       
       

       注意: 新しいサーバーの移行ターゲットとして負荷が最も少ないマシンを指定します。このノードで追加の管理対象サーバーを維持するために十分なリソースが使用可能になるように、必要なキャパシティ・プランニングを完了します。

       
       

    6. 「サーバーの自動移行を有効化」オプションを選択し、「保存」をクリックします。

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

    7. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

28. この新規サーバーを追加したノードから、この新規サーバーのサーバー移行をテストします。

    1. 管理対象サーバーのPID (プロセスID)で次のコマンドを実行することで、WLS_OSBn管理対象サーバーを突然停止します。

       kill -9 pid
       

       このノードのPIDは次のコマンドを使用して特定できます。

       ps -ef | grep WLS_OSBn
       

       
       

       注意: Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。次に例を示します。 taskkill /f /pid pid pidは、管理対象サーバーのプロセスIDです。 次のコマンドを使用すると、WLS_OSBn管理対象サーバーのプロセスIDを確認できます。 MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v

       
       

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

    3. ノード・マネージャによって、WLS_OSBnの2回目の再起動が試行されるまで待ちます。ノード・マネージャは、この再起動を試行するまで、30秒間待機します。

    4. ノード・マネージャがサーバーを再起動したら再度停止します。

       これにより、サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

       
       

       注意: サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルバックするには、Oracle WebLogic管理コンソールからその管理対象サーバーを停止し、再起動します。適切なノード・マネージャによって、最初に割り当てられていたマシン上の管理対象サーバーが起動されます。

       
       

14.7 管理サーバーの手動フェイルオーバーの検証

ノードで障害が発生した場合、管理サーバーを別のノードにフェイルオーバーできます。後続の項では、SOAHOTS1およびSOAHOSt2から管理サーバーのフェイルオーバーおよびフェイルバックを検証する手順を示します。

前提:

• 管理サーバーを、任意のアドレスではなくADMINVHN上でリスニングするように構成します。第8.4項「ドメインを作成するためのSOAHOST1での構成ウィザードの実行」の手順14を参照してください。

• これらの手順では、2つのノードがそれぞれ別々のドメイン・ディレクトリを使用していることおよびこれらのディレクトリがプライベート記憶域または別のボリュームにある共有記憶域に配置されていることを想定しています。

• 管理サーバーは、SOAHOST1からSOAHOST2にフェイルオーバーされ、2つのノードには次のIPが割り当てられます。

  • SOAHOST1: 100.200.140.165

  • SOAHOST2: 100.200.140.205

  • ADMINVHN: 100.200.140.206。これは管理サーバーを実行している場所の仮想IPであり、ethX:Yに割り当てられており、SOAHOST1とSOAHOST2で使用できます。

• SOAHOST1上の管理サーバーが実行されているドメイン・ディレクトリは、共有記憶域上にあり、SOAHOST2からもマウントされています。

• 第8.2項「Oracle Fusion Middlewareのインストール」の説明のとおり、Oracle WebLogic ServerおよびOracle Fusion MiddlewareコンポーネントはSOAHOST2にインストールされています(つまり、SOAHOST1に存在するORACLE_HOMEおよびMW_HOMEと同じパスをSOAHOST2でも使用できます)。

この項の内容は次のとおりです。

• 第14.7.1項「別ノードへの管理サーバーのフェイルオーバー」

• 第14.7.2項「SOAHOST2へのアクセスの検証」

• 第14.7.3項「SOAHOST1への管理オーバーのフェイルバック」

14.7.1 別ノードへの管理サーバーのフェイルオーバー

次の手順では、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーする方法を説明していますが、管理サーバーは、依然として同じWebLogic Serverマシン(論理マシンであり、物理マシンではありません)を使用します。

別ノードに管理サーバーをフェイルオーバーする手順は、次のとおりです。

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

2. IPを2つ目のノードに移行します。

   1. SOAHOST1上で次のコマンドをrootとして実行します(X:YはADMINVHNで現在使用しているインタフェース)。

      /sbin/ifconfig bond1:Y down
      

   2. 次のコマンドをSOAHOST2で実行します。

      /sbin/ifconfig <interface:index> IP_Address netmask <netmask>
      

      次に例を示します。

      /sbin/ifconfig bond1:1 10.0.0.1 netmask 255.255.255.0
      

      
      

      注意: 使用するネットマスクとインタフェースが、SOAHOST2の使用可能なネットワーク構成と一致していることを確認します。

      
      

3. arpingでルーティング表を更新します。次に例を示します。

   /sbin/arping -q -U -c 3 -I bond1 10.0.0.1
   

4. 第8.5.3項「SOAHOST1での管理サーバーの起動」の手順を使用して、SOAHOST2上の管理サーバーを再起動します。

5. 次のように、SOAHOST2上の管理サーバーにアクセスできるかテストします。

   1. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。

      http://ADMINVHN:7001/console
      

   2. 次のURLを使用してOracle Enterprise Managerにアクセスし、コンポーネントのステータスを確認できることを確認します。

      http://ADMINVHN:7001/em
      

      
      

      注意: 管理サーバーでは、フェイルオーバーにノード・マネージャを使用しません。手動でのフェイルオーバーの後、そのサーバーの管理コンソールの「現在のマシン」フィールドに表示されるマシン名はSOAHOST1であり、フェイルオーバー・マシンであるSOAHOST2ではありません。ノード・マネージャは管理サーバーをモニターしないため、「現在のマシン」フィールドに表示されるマシン名は無関係であり、無視できます。

      
      

14.7.2 SOAHOST2へのアクセスの検証

第8.11項「管理サーバー構成の検証」と同じ手順を実行します。これは、管理サーバーがSOAHOST2上で実行されている場合にもそれにアクセスできることを確認するためです。

14.7.3 SOAHOST1への管理オーバーのフェイルバック

この手順では、管理サーバーをフェイルバックできること、つまり、SOAHOST2上でそれを停止してから、ADMINVHNをSOAHOST1ノードに移行して戻すことで、それをSOAHOST1上で実行できることを確認します。

ADMINVHNをSOAHOST1に移行して戻す手順は、次のとおりです。

1. 管理サーバーが実行されていないことを確認します。

2. 次のコマンドをSOAHOST2で実行します。

   /sbin/ifconfig bond1:N down
   

3. 次のコマンドをSOAHOST1で実行します。

   /sbin/ifconfig bond1:Y 100.200.140.206 netmask 255.255.255.0
   

   
   

   注意: 使用するネットマスクとインタフェースが、SOAHOST1の使用可能なネットワーク構成と一致していることを確認します。

   
   

4. arpingでルーティング表を更新します。次のコマンドをSOAHOST1から実行します。

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

5. 第8.5.3項「SOAHOST1での管理サーバーの起動」の手順を使用して、SOAHOST1上の管理サーバーを再度起動します。

   cd ASERVER_HOME/bin
   ./startWebLogic.sh
    
   

6. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。

   http://ADMINVHN:7001/console
   

7. 次のURLを使用してOracle Enterprise Managerにアクセスし、コンポーネントのステータスを確認できることを確認します。

   http://ADMINVHN:7001/em
   

14.8 Oracle SOAエンタープライズ・デプロイメントのバックアップ

構成の変更の前後にはトポロジをバックアップします。

14.8.1 データベースのバックアップ

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

14.8.2 管理サーバー・ドメイン・ディレクトリのバックアップ

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

ASERVER_HOME

管理サーバーをバックアップするには、SOAHOST1上で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ASERVER_HOME

14.8.3 Web層のバックアップ

Web層をバックアップします。構成ファイルは次のディレクトリにあります。

WEB_ORACLE_ADMININSTANCE

Oracle Traffic Director管理サーバーをバックアップするには、WEBHOST1上で次のコマンドを実行します。

tar -cvpf webasback.tar WEB_ORACLE_ADMININSTANCE

14.8.4 ミドルウェア・ホームのバックアップ

新しいインストールによってMW_HOMEが変更された場合、次のコマンドを使用してそれをバックアップします。

tar -cvpf mw_home.tar MW_HOME

14.9 SQLNet接続のタイムアウトの防止

エンタープライズ・デプロイメントの本番デプロイメントの大部分にファイアウォールが使用されています。データベース接続はファイアウォールを通して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters(Oracle RAC)の場合、データベース接続はOracle RACの仮想IPとデータベース・リスナー・ポートで行われます。このような接続がタイムアウトしないように、ファイアウォールを構成する必要があります。このような構成が不可能である場合は、次のディレクトリにあるsqlnet.oraファイル内の*SQLNET.EXPIRE_TIME=n*パラメータを設定します。

ORACLE_HOME/network/admin

nは分単位の時間です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さく設定します。Oracle RACの場合は、このパラメータをすべてのOracleホーム・ディレクトリで設定します。

14.10 失敗したBPELインスタンスとメディエータ・インスタンスのリカバリ

この項では、BPEL、メディエータおよびその他のサービス・エンジンの失敗したインスタンスを調べてリカバリする方法について説明します。

注意: SQL文を実行する必要がある手順では、データベースにsoainfraスキーマとして接続してください。

• リカバリ可能インスタンスについて調べるには、データベース内で次のSQL文を実行します。

  // Find recoverable activities
  SQL> select * from work_item where state = 1 and execution_type != 1;
  
  // Find recoverable invoke messages
  SQL> select * from dlv_message where dlv_type = 1 and state = 0;
  
  // Find recoverable callback messages
  SQL> select * from dlv_message where dlv_type = 2 and (state = 0 or state = 1);
  

• 失敗したBPELインスタンスをリカバリする手順は、次のとおりです。

  Enterprise Managerで、「Farm_<domain_name>」を選択し、「SOA」を開き、「soa-infra (server_soa)」を右クリックして、「サービス・エンジン」→「BPEL」→「リカバリ」を選択します。

• 失敗したメディエータ・コンポジットをリカバリする手順は、次のとおりです。

  Enterprise Managerで、「Farm_<domain_name>」を選択し、「SOA」を開き、「soa-infra (server_soa)」を右クリックして、「サービス・エンジン」→「メディエータ」→「フォルト」を選択します。

• 拒否メッセージについて調べる手順は、次のとおりです。

  SQL> select * from rejected_message
  

• インスタンス・トラッキング表のデータを調べるには、次のSQL問合せを実行します。

  SQL> select ID, STATE from COMPOSITE_INSTANCE where CREATED_TIME > datetime
  

  datetimeには、問合せを絞り込むための日時を指定します。次に例を示します。

  '04-NOV-09 03.20.52.902000000 PM'

  アダプタからのデータは、最初にCOMPOSITE_INSTANCE表に入力されます。

  アダプタからのデータがアダプタBCに公開されると、BCによってSTATEが0のエントリ1個がCOMPOSITE_INSTANCE表に挿入されます。そのメッセージの処理が完了すると、STATEは1になります。エラーの場合は、STATE >= 2になります。

14.11 サービス拒否攻撃や再帰的ノード攻撃を防ぐためのWebサービスの構成

サービス拒否攻撃や再帰的ノード攻撃を防ぐようにWebサービスを構成するは、SCABindingProperties.xmlおよびoracle-webservices.xmlを構成します。

SCABindingProperties.xmlの構成

サービス拒否攻撃および再帰的ノード攻撃を防ぐには、例14-1に示すようにSCABBindingProperties.xmlでエンベロープ・サイズおよびネスト制限を設定します。

例14-1 SCABBindingProperties.xmlでのエンベロープ・サイズとネスト制限の構成

<bindingType type="ws">
        <serviceBinding>
                <bindingProperty>
                     <name>request-envelope-max-kilobytes</name>
                    <type>xs:integer</type>
                     <defaultValue>-1</defaultValue>
                 </bindingProperty>
                 <bindingProperty>
                   <name>request-envelope-nest-level</name>
                     <type>xs:integer</type>
                    <defaultValue>-1</defaultValue>
                 </bindingProperty>
        </serviceBinding> 

oracle-webservices.xmlの構成

スタンドアロンのWebサービスについては、oracle-webservices.xmlでエンベロープ・サイズとネスト制限を構成します。次に例を示します。

<request-envelope-limits kilobytes="4" nest-level="6" />

注意: エンベロープおよびネスト制限を極端に大きい値に設定したり、値を何も設定しないと、サービス拒否攻撃を受けるおそれがあります。

14.12 デプロイメント・プランおよびSOAインフラストラクチャ・アプリケーション更新での共有記憶域の使用方法

SOAクラスタ内のSOAインフラストラクチャ・アプリケーションまたはリソース・アダプタを再デプロイするときは、デプロイメント・プランとアプリケーション・ビットに、クラスタ内の全サーバーからアクセスできる必要があります。SOAのアプリケーションおよびリソース・アダプタは、nostageデプロイメント・モードを使用してインストールされます。nostageデプロイメント・モードを選択した場合、管理サーバーはアーカイブ・ファイルをソースの場所からコピーしないため、各サーバーが同じデプロイメント・プランにアクセスできるようにしておく必要があります。デプロイメント・プランおよびアプリケーションに次の場所を使用します。

 u01/oracle/config/dp/soaedg_domain

第4章「Exalogicエンタープライズ・デプロイメントのストレージの構成」でお薦めされているとおり、このディレクトリはエンタープライズ・デプロイメント・トポロジ内のすべてのノードからアクセス可能である必要があります。

14.13 HASとパフォーマンスの分離を向上させるための外部BPELキャッシュの使用方法

この項では、外部PBELキャッシュを使用してHASとパフォーマンスの分離を向上する方法について説明します。

この項の内容は次のとおりです。

• 第14.13.1項「サーバーのbpel.cache.localStorageプロパティの設定」

• 第14.13.2項「キャッシュ構成ファイルと起動スクリプトの作成」

• 第14.13.3項「BPELキャッシュ・インスタンスの起動」

14.13.1 サーバーのbpel.cache.localStorageプロパティの設定

サーバーのbpel.cache.localStorageプロパティをfalseに設定します。

bpel.cache.localStorageプロパティを設定する手順は、次のとおりです。

1. 次のURLを使用してOracle WebLogic Server管理コンソールにログインします。

   http://ADMINVHN:7001/console
   

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。

   「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列内のサーバー名(ハイパーリンクとして表示されているWLS_SOA1またはWLS_SOA2)をクリックします。

   選択したサーバーの設定ページが表示されます。

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

6. 「サーバーの起動」タブをクリックします。

7. WLS_SOA1およびWLS_SOA2の「引数」フィールドを置き換えます。次のように置き換えます。

   -Dbpel.cache.localStorage=true
   

   これを次のものに置き換えます。

   -Dbpel.cache.localStorage=false
   

8. 「保存」、「変更のアクティブ化」の順にクリックします。

14.13.2 キャッシュ構成ファイルと起動スクリプトの作成

適切なキャッシュ構成ファイルおよび起動スクリプトを作成します。

キャッシュ構成ファイルおよび起動スクリプトを作成する手順は、次のとおりです。

1. 各ノード(SOAHOST1およびSOAHOST2)にcachesディレクトリを作成します。

   mkdir /u02/private/oracle/config/soaexa_domain/caches
   

2. 各ノードの/u02/private/oracle/config/soaexa_domain/caches/にbpelCacheEnv.shファイルを作成します。/u01/oracle/products/fmw/soa/bin/start-bpel-cache.shスクリプトのnotesセクションの例を参照してください。

   次のものは、SOAサーバーのみを実行するセルの例です。たとえば、同じボックス内で他のサーバーまたはコンポーネントとのメモリーの競合が発生する場合などは、サーバーを別のリソースでカスタマイズできます。

   BPEL_UNICAST_WKA="SOAHOST1-PRIV-V1:8089;SOAHOST2-PRIV-V1:8089"
   MEMORY="3gb"
   INSTANCE_CACHE_SIZE="1024"
   INVOKE_MESSAGE_CACHE_SIZE="512"
   DELIVERY_MESSAGE_CACHE_SIZE="512" 
   DELIVERY_SUBSCRIPTION_CACHE_SIZE="256" 
   JAVA_HOME=/u01/oracle/products/fmw/jrockit_160_29_D1.2.0-10
   MW_HOME=/u01/oracle/products/fmw
   COHERENCE_LIB=$MW_HOME/oracle_common/modules/oracle.coherence/coherence.jar
   MW_ORA_HOME=MW_HOME/soa 
   

3. 両方のノードで、start-bpel-cache.shのコピーをMW_HOME/soa/binからcachesディレクトリに作成します。

   cp MW_HOME/soa/bin/start-bpel-cache.sh  MSERVER_HOME/caches/
   

14.13.3 BPELキャッシュ・インスタンスの起動

バックグラウンドでstart-bpel-cache.shスクリプトを2回実行することで、2つのキャッシュ・インスタンスを起動します。

キャッシュ・インスタンスを起動するには:

MSERVER_HOME/caches/start-bpel-cache.sh &

MSERVER_HOME/caches/start-bpel-cache.sh &

オペレーティング・システム内の実行中プロセスとしてJVMを識別するには、報告されたPIDをメモします。

14.14 エンタープライズ・デプロイメントのトポロジのトラブルシューティング

この項では、SOAエンタープライズ・デプロイメントで発生する可能性のある問題を示し、その解決方法を提案します。

この項では、次のトピックを取り扱います:

• 第14.14.1項「soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する」

• 第14.14.2項「デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)」

• 第14.14.3項「データベース内の最大許容プロセス数に達したためにSOA、OSBまたはWMSサーバーの起動に失敗する」

• 第14.14.4項「手動フェイルオーバー後に管理サーバーの起動に失敗する」

• 第14.14.5項「管理コンソールで変更をアクティブ化するときにエラーが発生する」

• 第14.14.6項「サーバー移行後にSOA/OSBサーバーがフェイルオーバーしない」

• 第14.14.7項「サーバー移行後にSOA/OSBサーバーにブラウザからアクセスできない」

• 第14.14.8項「SOAサーバーのアクティブ化後、しばらくの間高い負荷がかかるとサーバーが応答を停止する」

• 第14.14.9項「構成したJOCポートがすでに使用されている」

• 第14.14.10項「SOAサーバーまたはOSBサーバーの起動に失敗する」

• 第14.14.11項「同じノードに複数のクラスタがある場合のSOA Coherenceクラスタの不一致」

• 第14.14.12項「サーバー移行時にSudoエラーが発生する」

• 第14.14.13項「トランザクション・タイムアウト・エラー」

• 第14.14.14項「最大サイズ超過エラー・メッセージ」

14.14.1 soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する

問題: ロード・バランサのアドレスを使用してsoa-infraアプリケーションにアクセスしようとしたときに、404 "page not found"メッセージがWebブラウザに表示されます。このエラーは断続的に発生し、WLS管理コンソールではSOAサーバーが「実行中」と表示されます。

解決方法: SOA管理対象サーバーが起動されて実行中であるように見えても、その中に含まれるアプリケーションのいくつかが「アクティブ」ではなく、「管理」、「準備完了」またはその他の状態である場合があります。SOAサーバーの実行中にsoa-infraアプリケーションが使用不可になることもあります。管理コンソールの「デプロイメント」ページで、soa-infraアプリケーションの状態を確認してください。それは「アクティブ」状態になっている必要があります。soa-infraアプリケーション関連のエラーについてSOA Serverの出力ログを確認し、管理コンソールの「デプロイメント」ページでそれの起動を試みてください。

14.14.2 デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)

問題: デプロイメントのCoherence構成に対する変更を適用した後、soa-infraアプリケーションの起動に失敗します。SOAサーバーの出力ログには、次のように報告されます。

Cluster communication initialization failed. If you are using multicast, Please make sure multicast is enabled on your network and that there is no interference on the address in use. Please see the documentation for more details.

解決方法:

1. SOAコンポジットのクラスタ・デプロイメントに対してユニキャストではなくマルチキャストを使用する場合、soa-infraアプリケーションの起動時(つまり、SOAが実行される管理対象サーバーの起動時)にマルチキャスト競合が発生すると、前述のようなメッセージが表示されることがあります。これらのメッセージは、Oracle Coherenceがランタイム例外をスローしたときに生成されるものであり、例外自体の詳細も含まれています。このようなメッセージが表示された場合、ネットワークのマルチキャスト構成を確認してください。マルチキャスト・アドレスに対してpingを実行できることを確認します。さらに、ネットワーク内に同じマルチキャスト・アドレスを使用しているがクラスタ名が異なるクラスタがないかを調べてください。そのようなものがあると、競合が発生してsoa-infraを起動できなくなることがあります。ネットワークでマルチキャストが有効化されていない場合、Oracle Coherence開発者ガイドの説明に従って、ユニキャストを使用するようにデプロイメント・フレームワークを変更してください。

2. ユニキャスト用の既知アドレス・リストを(サーバー起動パラメータ内に)入力するときは、入力したローカル・ホストおよびクラスタ化されたサーバー用のノードのアドレスが正しいことを確認してください。次のようなエラー・メッセージがあります。

   oracle.integration.platform.blocks.deploy.CompositeDeploymentCoordinatorMessages errorUnableToStartCoherence
   

   前述がサーバーの出力ログに記録されます(アドレスのいずれかが適切に解決されない場合)。

14.14.3 データベース内の最大許容プロセス数に達したためにSOA、OSBまたはWMSサーバーの起動に失敗する

問題: SOA、WSMまたはOSBサーバーが起動に失敗します。新しいタイプの管理対象サーバー用にドメインが拡張されているか(たとえば、OSB用に拡張されたSOA)、システムがスケール・アップ(同じタイプのサーバーが追加)されています。SOA/OSBまたはWSMサーバーの出力ログに、次のように報告されます。

<Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "SOADataSource-rac0": Listener refused the connection with the following error:

ORA-12516, TNS:listener could not find available handler with matching protocol stack >

解決方法: データベース内のプロセス数を確認し、それにあわせて調整します。SYSユーザーとして、SHOW PARAMETERコマンドを発行します。

SQL> SHOW PARAMETER processes

次のコマンドを使用して、初期化パラメータを設定します。

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

データベースを再起動します。

注意: パラメータの値を変更するために使用する方法は、パラメータが静的か動的かどうか、およびデータベースでパラメータ・ファイルまたはサーバーのパラメータ・ファイルを使用するかによって異なります。パラメータ・ファイル、サーバーのパラメータ・ファイルおよびパラメータ値変更方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

14.14.4 手動フェイルオーバー後に管理サーバーの起動に失敗する

問題: 管理サーバーに障害が発生して別のノードへの手動フェイルオーバーを実行した後、それの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。

<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ASERVER_HOME/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

解決方法: 次のディレクトリからEmbeddedLDAP.lokファイルを削除します。

ASERVER_HOME/servers/AdminServer/data/ldap/ldapfiles/ 

.

14.14.5 管理コンソールで変更をアクティブ化するときにエラーが発生する

問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。

An error occurred during activation of changes, please see the log for details.
 [Management:141190]The commit phase of the configuration update failed with an exception:
In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean

解決方法: 構成を変更していた特定のサーバーのサーバー起動構成にユーザー名/パスワードの情報を管理コンソールで指定するか、config.xmlファイルの<password-encrypted></password-encrypted>エントリを削除してください(これには管理サーバーの再起動が必要です)。

14.14.6 サーバー移行後にSOA/OSBサーバーがフェイルオーバーしない

問題: ローカルのノード・マネージャによる最大再起動試行回数に達した後で、フェイルオーバー・ノードのノード・マネージャがそれの再起動を試行しますが、サーバーは起動しません。ノード・マネージャの出力情報の報告より、サーバーがフェイルオーバーしたと思われます。ノード・マネージャによって移行が試みられた後に、SOAサーバーによって使用される仮想IPがフェイルオーバー・ノードで有効化されません(フェイルオーバー・ノードでconfigを実行しても、どのインタフェースの仮想IPも報告されません)。コマンドsudo ifconfig $INTERFACE $ADDRESS $NETMASKを実行しても、そのIPはフェイルオーバー・ノード内で有効化されません。

解決方法: sudo実行時にパスワード入力を要求するような権限と構成を設定しないでください。パスワードを要求することなくsudoが動作するようにsudoが構成されていることを、システム管理者に確認してください。

14.14.7 サーバー移行後にSOA/OSBサーバーにブラウザからアクセスできない

問題: サーバー移行は正常に実行されますが(SOA/OSBサーバーがフェイルオーバー・ノード内で再起動される)、<Virtual Hostname>:8001/soa-infra URLにWebブラウザからアクセスできません。元のホストではすでにサーバーが強制終了されており、フェイルオーバー・ノードのノード・マネージャでは、仮想IPが移行済でサーバーが起動していることが報告されます。SOAサーバーが使用する仮想IPに対して、クライアントのノード(ブラウザが使用されているノード)からpingを実行できません。

解決方法: nodemanager.propertiesファイルを更新してMACBroadcastを含めるか、次のように手動でarpingを実行してください

/sbin/arping -b -q -c 3 -A -I $INTERFACE $ADDRESS > $NullDevice 2>&1

$INTERFACEは、仮想IPが有効化されているネットワーク・インタフェースであり、$ADDRESSは仮想IPアドレスです。

14.14.8 SOAサーバーのアクティブ化後、しばらくの間高い負荷がかかるとサーバーが応答を停止する

問題: WLS_SOAは正常に起動し、しばらくの間機能しますが、Oracleファイル・アダプタまたはOracle FTPアダプタを使用するアプリケーションの実行後に応答しなくなります。サーバーのログ・ファイルには、次のように報告されます。

<Error> <Server> <BEA-002606> <Unable to create
a server socket for listening on channel "Default". The address
X.X.X.X might be incorrect or another process is using port 8001:
@ java.net.SocketException: Too many open files.>

解決方法: コンポジットでOracleファイルおよびFTPアダプタを使用している場合は(これらは大量の同時メッセージを処理するように設計されている)、オペレーティング・システムのオープン・ファイル・パラメータの数値を大きくしてください。たとえば、Linuxのオープン・ファイル・パラメータの数を8192に設定するには、ulimit -n 8192コマンドを使用します。この値は、予想されるシステム負荷に基づいて調整する必要があります。

14.14.9 構成したJOCポートがすでに使用されている

問題: Java Object Cacheを使用する管理対象サーバー(OWSMやWebCenter Spaces管理対象サーバーなど)を起動しようとすると失敗します。ログには次のようなエラーが記録されます。

J2EE JOC-058 distributed cache initialization failure
J2EE JOC-043 base exception:
J2EE JOC-803 unexpected EOF during read.

解決方法: JOCが取得しようとしているポートを別のプロセスが使用しています。そのプロセスを停止するか、このクラスタのJOCを再構成して、お薦めされるポート範囲内の別のポートを使用します。

14.14.10 SOAサーバーまたはOSBサーバーの起動に失敗する

SOAまたはOSBサーバーを初めて起動するときに失敗して、config.xmlの解析の失敗が報告されます。

問題: ノード・マネージャを使用して初めて起動しようとしたサーバーが、起動に失敗します。サーバーの出力ログには、次のようなメッセージが記録されます。

<Critical> <WebLogicServer> <eicfdcn35> <wls_server1> <main> <<WLS Kernel>> <> <> <1263329692528> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.

管理対象サーバーは、初回はMSI(管理対象サーバー独立)モードで起動を試みます。サーバーは初回起動時に適切な構成を取得できませんでした。管理対象サーバーは、初回起動時に管理サーバーと通信できるようになっている必要があります。

解決方法: 管理サーバーのリスニング・アドレスと管理対象サーバーのリスニング・アドレスの間の通信が可能になっていることを確認します(管理対象サーバーのノードから管理サーバーのリスニング・アドレスに対してpingを実行し、管理サーバーのリスニング・アドレスおよびポートに対してtelnetを実行します)。通信が有効になったら、ドメインの圧縮と新しいノードへの解凍を再度行うか、(他のサーバーが同じドメイン・ディレクトリ内ですでに正常に実行されている場合は)次のディレクトリを削除してサーバーを再起動します。

OARCLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/nodemanager

14.14.11 同じノードに複数のクラスタがある場合のSOA Coherenceクラスタの不一致

問題: 同じノードに複数のSOAクラスタが存在する場合にsoa-infraの起動に失敗します。サーバーの.outファイルに次のようなメッセージが表示されます。

<Error> <Coherence> <BEA-000000> <Oracle Coherence GE 3.6.0.4 <Error> (thread=Cluster, member=1): This senior Member(…) appears to have been disconnected from another senior Member…stopping cluster service.>

解決方法: Coherenceメンバーは再起動したときに、そのlocalport設定で構成されたポートへのバインドを試みます。このポートが使用できない場合は、ポート番号を2つずつ増やしてそのポートへの接続を試みます。複数のSOAクラスタがCoherence用に同じ範囲のポートを使用していると、異なるWKAのクラスタにメンバーが参加する可能性があり、不一致が発生し、soa-infraアプリケーションが起動しなくなることがあります。この問題を解決するには、いくつかの方法があります。

• クラスタ・ポートを2ずつ増やす方法ではなく、様々なクラスタそれぞれにポート範囲を設定します。たとえば、クラスタ1は8000から8090、クラスタ2は8091から8180のように設定します。これは、このガイドの表3-4でお薦めしているモデルが暗黙的に示すもので、各Coherenceクラスタにはそれぞれ別の範囲を使用する必要があります。

• ポートの自動調整を無効化し、メンバーが、それらに構成されているlocalhostアドレスを使用するように強制します。これは、システム・プロパティtangosol.coherence.localport.adjustを使用して行います(例: -Dtangosol.coherence.localport.adjust=false)。

• 各クラスタに一意のクラスタ名を構成します。これは、システム・プロパティtangosol.coherence.clusterを使用して行えます。次に例を示します。

  -Dtangosol.coherence.cluster=SOA_Cluster1
  

これらの様々なオプションの詳細は、次のURLにあるCoherenceクラスタの構成に関するドキュメントを参照してください。

http://download.oracle.com/docs/cd/E24290_01/coh.371/e22837/cluster_setup.htm

14.14.12 サーバー移行時にSudoエラーが発生する

問題: サーバー移行のためにwlsifconfigを実行すると、次の警告が表示されます。

sudo: sorry, you must have a tty to run sudo

解決方法: WebLogicユーザー('oracle')がバックグラウンドでsudoを実行できません。この問題を解決するには、次の行を/etc/sudoersに追加します。

Defaults:oracle !requiretty

14.14.13 トランザクション・タイムアウト・エラー

問題: 次のトランザクション・タイムアウト・エラーがログに表示されます。

Internal Exception: java.sql.SQLException: Unexpected exception while enlisting
 XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start()
failed on resource 'SOADataSource_soaedg_domain': XAER_NOTA : The XID
is not valid

解決方法: トランザクション・タイムアウト設定を確認し、JTAトランザクション・タイムアウトがDataSource XAトランザクション・タイムアウト(これは(データベースの) distributed_lock_timeoutより小さい)より小さいことを確認します。

初期のままの構成では、SOAデータソースでは、XAタイムアウトがいかなる値にも設定されていません。WebLogic Server管理コンソールで、Set XA Transaction Timeout構成パラメータが選択解除されています。この場合、データソースでは、30に設定されているドメイン・レベルのJTAタイムアウトを使用します。また、データベースに対するデフォルトdistributed_lock_timeout値は60です。結果として、トランザクションの予想存続期間がこのような値より短いことが予想されるシステムでは、SOAの構成が正常に機能します。特定の操作にかかると予想されるトランザクション時間に応じて、これらの値を調整してください。

14.14.14 最大サイズ超過エラー・メッセージ

問題: 複雑なルールを編集してSOAクラスタに保存すると、レプリケーション・メッセージの最大サイズを超えたことを報告するエラー・メッセージが、サーバーの出力ファイルに表示されることがあります。次に例を示します。

<rws3211539-v2.company.com> <WLS_SOA1> <ExecuteThread: '2' for queue:
'weblogic.socket.Muxer'> <<WLS Kernel>> <> <> <1326464549135> <BEA-000403>
<IOException occurred on socket:
Socket[addr=/10.10.10.10,port=48290,localport=8001]
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'.
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'

解決方法: このエラーは、HTTPセッションで配置されクラスタに複製された、シリアル化されたルールのサイズが大きいために発生します。使用するルールのサイズに応じて、最大メッセージ・サイズを増やしてください。

最大メッセージ・サイズを増やす手順は、次のとおりです。

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

2. 「サーバー」→「Server_name」→「プロトコル」→「一般」を選択します。

3. 必要に応じて、「最大メッセージ・サイズ」フィールドを変更します。