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

この章では、トポロジを設定した後に実行できる操作について説明します。この操作には、トポロジの監視、スケーリングおよびバックアップがあります。

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

• トポロジの管理および監視の概要

• SOAインフラストラクチャ・データベースでのスペースの管理

• UMSドライバの構成

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

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

• WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行

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

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

• Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング

16.1 トポロジの管理および監視の概要

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

トポロジおよびWebCenter Portalアプリケーションの監視の詳細は、『Oracle WebCenter Portalの管理』のOracle WebCenter Portalのパフォーマンスの監視に関する項を参照してください。

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

構成の変更前後にはトポロジをバックアップします。構成変更後の問題発生に対応するためバックアップしておく必要のあるディレクトリとファイルについては、第16.6項「WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行」で説明します。

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

16.2 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までの間に作成されたUNKNOWN状態のFlatStructureコンポジット(バージョン10)の最初の1000個のインスタンスが削除されます。提供されるSQLパッケージに含まれている可能性のある操作の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のSOAコンポジット・アプリケーション・インスタンスの管理に関する項を参照してください。必ず、適切に消去できるようにするために提供されているスクリプトを使用してください。composite_dn表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。

16.3 UMSドライバの構成

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

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

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

  ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml
  

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

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

これまでに行った変更を有効にする(変更後の構成情報をドライバに読み取らせる)ためにドライバを再起動する必要があります。ドライバを再起動する手順は次のとおりです。

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

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

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

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

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

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

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

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

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

トポロジのスケールアップとは、1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することです。新しい管理対象サーバーを作成する場合は、既存ノードのインストール(WebLogic Serverホーム、Oracle Fusion Middlewareホーム、ドメイン・ディレクトリなど)を使用できます。WebLogic Server、SOAまたはWebCenter Portalのバイナリを新しい場所にインストールしたり、packとunpackを実行したりする必要はありません。

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

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

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

このシナリオでは、ノード1またはノード2のいずれかですべてのサーバー(サーバー1、サーバー2、サーバー3および管理サーバー)が実行される恐れがあります。つまり、サーバー移行を使用するすべてのサーバーが1つのノード上(サーバー移行候補マシンの構成で定義される)で実行される最悪のケースに対応できるように、各ノードを十分なリソースで設計する必要があるということです。

注意: ドメイン内の特定のファイル(intradoc.cfgなど)が各ノードに固有であるため、WebCenter Content Serverを含む管理対象サーバーでは共有ドメイン・ディレクトリは動作しません。ノード固有のファイルの問題を防止するには、各WebCenter ContentおよびInbound Refinery管理対象サーバーにローカル(ノードごと)のドメイン・ディレクトリを使用します。

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

• 第16.4.1項「Oracle SOA (WSMを含む)のスケール・アップ」

• 第16.4.2項「Oracle WebCenter Portalのスケール・アップ」

• 第16.4.3項「Oracle WebCenter Contentのスケール・アップ」

16.4.1 Oracle SOA (WSMを含む)のスケール・アップ

SOAトポロジ(WSMを含む)をスケール・アップするには、次の手順を実行します。

1. 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が実行されています。

2. リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを割り当てます。推奨されているとおりにサーバー移行を使用する場合、サーバーを別のノードに移動できるようにVIP(浮動IPとも呼ばれる)を指定します。このVIPは、すでに実行されている管理対象サーバーで使用されているものとは異なっている必要があります。

3. WLS_WSMサーバーの場合は、第8.6項「Oracle WSMについてのJavaオブジェクト・キャッシュの構成」で説明されているように、Javaオブジェクト・キャッシュの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。同じノードの複数のWLS_WSMサーバー用に同じディスカバリ・ポートを使用できます。第8.6項「Oracle WSMについてのJavaオブジェクト・キャッシュの構成」の手順をWLS_WSMサーバーごとに繰り返すと、サーバー・リストが更新されます。

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

   1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms
      

      
      

      注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

      
      

   2. SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

   3. 新しいUMS JMSサーバー用の新しい永続ストアを作成し(UMS JMSサーバーの作成方法は後述します)、UMSJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms
      

      
      

      注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

      
      
      
      

      注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

      
      

   4. UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

   5. BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。

      ORACLE_BASE/admin/domain_name/cluster_name/jms
      

      
      

      注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。 SOAJMSFileStore_Nを新しいBPM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

      
      

   6. BPMシステムの場合のみ: BPM用の新しいJMSサーバー(たとえばBPMJMSServer_N)を作成します。このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

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

   8. SOA、UMSおよび(適用可能な場合)BPM JMSモジュールのサブデプロイメント・ターゲットを更新し、作成した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を追加します)。「保存してアクティブ化」をクリックします。

5. 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順は、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。

   
   

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

   
   

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

   java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=myPassword1
   

   「保存してアクティブ化」をクリックします。

7. 新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。

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

8. 新しい管理対象サーバーのホスト名検証を無効にします。次を起動して検証する前に: WLS_SOAn管理対象サーバー、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。

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

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

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

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

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

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

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

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

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

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

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

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

   
   

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

   
   

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

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

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

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

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

      
      

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

      
      

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

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

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

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

10. 新しいサーバーを含むように、クラスタのアドレスを更新します。

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

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

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

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

    4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例: SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOST1VHN1:8001

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

11. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

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

       これを実行するには、run kill -9 <pid>を管理対象サーバーのPIDに対して実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを実行します。

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

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

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

16.4.2 Oracle WebCenter Portalのスケール・アップ

WebCenter Portalトポロジをスケール・アップするには、次の手順を実行します。

注意: 1つのノードでの複数の管理対象サーバーの実行は、WC_SpacesおよびWC_Portletサーバーでのみサポートされます。

1. WebLogic Server管理コンソールを使用して、新しい管理対象サーバーにWC_Spaces1またはWC_Portlet1をクローニングします。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。

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

   1. 管理コンソールで、「環境」を選択し、「サーバー」を選択します。

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

   3. クローニングする管理対象サーバー(たとえば、WC_Spaces1またはWC_Portlet1)を選択します。

   4. 「クローン」を選択します。

   5. 新しい管理対象サーバーにWC_SERVERNAMEnという名前を付けます(ここで、nは新しい管理対象サーバーを識別する番号です)。

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

2. リスニング・アドレスには、この新しい管理対象サーバーに使用するホスト名またはIP(既存サーバーと同じもの)を割り当てます。

   この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。

3. 新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します。詳細は、第10.5項「Spaces_Cluster用のJavaオブジェクト・キャッシュの構成」を参照してください。

4. Oracle HTTP Serverモジュールをクラスタの新規メンバーで再構成します。詳細は、第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」を参照してください。WebLogicClusterパラメータの終わりに、新しいサーバーのホストとポートを追加します。

   • WC_Spacesの場合は、メンバーを/webcenter、/webcenterhelp、/rss、/restのLocationブロックに追加します。

   • WC_Portletの場合は、メンバーを/portalTools、/wsrp-tools、/pageletsのLocationブロックに追加します。

16.4.3 Oracle WebCenter Contentのスケール・アップ

1つのドメイン、1つのノードに対して、Oracle WebCenter Content管理対象サーバー1台のみが、Oracle Fusion Middlewareによってサポートされます。Oracle WebCenter Content管理対象サーバーを追加するには、『Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド』のWebCenter Contentのスケール・アウト手順に関する項の手順に従って、Oracle WebCenter Content管理対象サーバーを新しいノードに追加します。

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

トポロジをスケール・アウトするには、SOA、WebCenter PortalまたはWebCenter Contentで構成した新しい管理対象サーバーを新しいノードに追加します。

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

• 第16.5.1項「Oracle SOA (WSMを含む)のスケール・アウト」

• 第16.5.2項「Oracle WebCenter Portalのスケール・アウト」

• 第16.5.3項「Oracle WebCenter Contentのスケール・アウト」

16.5.1 Oracle SOA (WSMを含む)のスケール・アウト

トポロジをスケールアウトするには、SOAおよび(または)WSM-PMで構成した新しい管理対象サーバーを新しいノードに追加します。

この項の手順を実行する前に、次の要件が満たされていることを確認してください。

前提条件

• 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ファイルを編集します。

  user_home/bea/
  

トポロジをスケール・アウトするには:

1. 新しいノード上に、既存のMW_Home (SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、SOAHOSTnで次のコマンドを実行します。

   cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh
   ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_version
   

   ミドルウェア・ホーム・リストを更新するには、$HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集)、MW_HOMEをこのファイルに追加します。

   
   

   注意: このガイドで説明する例ではJRockitを使用します。この手順には、動作保証された任意のバージョンのJavaを使用することができ、特に記載がないかぎり完全にサポートされています。

   
   

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

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

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

6. Oracle WebLogic Server管理コンソールを使用して、新しい管理対象サーバーにWLS_SOA1またはWLS_WSM1をクローニングします。この管理対象サーバーには、WLS_SOAnまたはWLS_WLS_WSMnという名前を付けます(nは番号です)。

   
   

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

   
   

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

   このサーバーでサーバー移行を実行する場合(推奨)、ここでサーバーのVIP(浮動IPとも呼ばれる)を指定します。このVIPは、既存の管理対象サーバーとは別のものを使用してください。

8. WLS_WSMサーバーの場合は、第8.6項「Oracle WSMでのJava Object Cacheの構成」で説明されているように、Java Object Cacheの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。

9. 新しい管理対象サーバーにSOA、BPM(該当する場合)およびUMSのJMSサーバーを作成します。

   
   

   注意: この手順は、WLS_SOA管理対象サーバーの場合にのみ実行し、WLS_WSM管理対象サーバーをスケール・アウトする場合は不要です。

   
   

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

   1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms
      

      
      

      注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

      
      

   2. SOA用の新しいJMSサーバーを作成します(例: SOAJMSServer_N)。SOAJMSFileStore_Nは、このJMSサーバーで使用します。先ほど作成した管理対象サーバー(WLS_SOAn)をSOAJMSServer_Nサーバーのターゲットに指定します。

   3. 新しいUMSJMSServer用の新しい永続ストアを作成し、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」でJMS永続ストアのディレクトリとして推奨されているパスを指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms
      

      
      

      注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

      
      
      
      

      注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

      
      

   4. UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。先ほど作成した管理対象サーバー(WLS_SOAn)を、UMSJMSServer_Nサーバーのターゲットに指定します。

   5. BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。

      ORACLE_BASE/admin/domain_name/cluster_name/jms
      

      
      

      注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。 SOAJMSFileStore_Nを新しいBPM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

      
      

   6. BPMシステムの場合のみ: BPM用の新しいJMSサーバー(たとえばBPMJMSServer_N)を作成します。このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

   7. SOA、UMSおよび(適用可能な場合)BPM JMSモジュールのサブデプロイメント・ターゲットを更新し、作成した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を追加します)。「保存してアクティブ化」をクリックします。

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

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

    cd ORACLE_COMMON_HOME/common/bin
    

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

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

    SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_COMMON_HOME/common/bin
    

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

    cd ORACLE_COMMON_HOME/common/bin
    

    ./unpack.sh -domain=ORACLE_BASE/admin/domain_name
    /mserver/domain_name/ -template=soadomaintemplateScale.jar
    -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications -overwrite_domain=true
    
    

11. 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順は、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。

    
    

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

    
    

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

    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=myPassword1
    

    「保存してアクティブ化」をクリックします。

13. 新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。

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

14. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーを起動して検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。

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

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

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

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

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

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

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

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

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

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

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

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

    SOAHOSTN> WL_HOME/server/bin/startNodeManager
    

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

    1. 新しく作成したWLS_SOAn管理対象サーバーが実行中であることを確認します。

    2. ロード・バランサ上のアプリケーションにアクセスします(https://soa.example.com/soa-infra)。アプリケーションが機能している必要があります。

       
       

       注意: トポロジ内のHTTP Serverでは、新たに追加されたサーバーへのリクエストをラウンド・ロビン方式で処理する必要があります(新しいリクエストは、クラスタ内のサーバー数に応じて、新しいサーバーにヒットする必要があります)。Oracle HTTP Serverの*_vh.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

       
       

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

    
    

    注意: この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいSOA管理対象サーバー用の浮動IPも、新しいノードにすでに存在します。

    
    

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

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

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

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

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

       
       

       注意: マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。

       
       

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

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

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

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

18. 新しいサーバーを含むように、クラスタのアドレスを更新します。

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

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

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

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

    4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。たとえば、ADMINVHN:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8001と入力します。

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

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

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

       kill -9 pid
       

       ノードのPIDは次のコマンドで特定できます。

       ps -ef | grep WLS_SOAn
       

       
       

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

       
       

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

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

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

16.5.2 Oracle WebCenter Portalのスケール・アウト

トポロジのスケール・アウトでは、Oracle WebCenter Portalアプリケーションで構成された新しい管理対象サーバーを新しいノードに追加します。

この項の手順を実行する前に、次の要件が満たされていることを確認してください。

前提条件

• WebCenter Portalで構成された管理対象サーバーを実行している既存ノードがトポロジ内に存在する必要があります。

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

• WC_SpacesとWC_Utilitiesサーバーは、どちらも新しいノードでスケール・アウトされるか、どちらもスケール・アウトされない必要があります。これは、WebCenter Portalアプリケーションと分析アプリケーションの間のローカル・アフィニティによるものです。

トポロジをスケール・アウトするには:

1. 新しいノードで、WebCenter Portalのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するために、次のコマンドを実行します。

   WCPHOSTn> cd ORACLE_BASE/product/fmw/wc/
   WCPHOSTn> ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_verion
   

   ミドルウェア・ホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、ORACLE_BASE/product/fmwをこのファイルに追加します。

   
   

   注意: このガイドで説明する例ではJRockitを使用します。この手順には、動作保証された任意のバージョンのJavaを使用することができ、特に記載がないかぎり完全にサポートされています。

   
   

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

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

5. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。

6. Oracle WebLogic Server管理コンソールを使用して、新しい管理対象サーバーにWC_Spaces1、WC_Portlet1、WC_Collaboration1またはWC_Utilities1のいずれかをクローニングします。それにWC_XXXnという名前を付けます(nはその新しいマシンに割り当てる番号です)。

7. リスニング・アドレスには、新しい管理対象サーバーに使用するホスト名またはIPを割り当てます。次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。

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

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

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

   4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

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

   6. 「リスニング・アドレス」をWCPHOSTnに設定します(ここで、WCPHOSTnは、新しいマシンのDNS名です)。

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

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

      変更内容は、管理対象サーバーが再起動されるまでは有効になりません。

8. packコマンドをSOAHOST1上で実行してテンプレート・パックを作成し、WCPHOSTnに解凍します。

   これらの手順は、第10.4.1項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」に記載されています。

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

   WCPHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip
   

10. これが新しいコラボレーション管理対象サーバーである場合:

    1. 第10.7項「ディスカッション・サーバーでのクラスタリングの構成」の手順に従って新しいディスカッション・サーバーのクラスタリングを構成します。

    2. また、第10.6項「マルチキャストからユニキャストへのディスカッションの変換」の手順を、coherence.localhostパラメータに新しいホストのホスト名を使用して実行済であることも確認します。

11. これが新しいユーティリティ管理対象サーバーである場合は、第10.9項「アクティビティ・グラフの構成」の手順に従ってアクティビティ・グラフが無効化済であることを確認します。また、ユーティリティおよびローカルSpacesサーバーで、第10.8項「Analyticsの構成」の新しいAnalyticsコレクタの構成手順が実行済であることも確認します。

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

    1. 新しく作成したWLS_SOAn管理対象サーバーが実行中であることを確認します。

    2. ロード・バランサ上のアプリケーションにアクセスします(https://soa.example.com/soa-infra)。アプリケーションが機能している必要があります。

       
       

       注意: トポロジ内のHTTP Serverでは、新たに追加されたサーバーへのリクエストをラウンド・ロビン方式で処理する必要があります(新しいリクエストは、クラスタ内のサーバー数に応じて、新しいサーバーにヒットする必要があります)。Oracle HTTP Serverの*_vh.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

       
       

16.5.3 Oracle WebCenter Contentのスケール・アウト

Oracle WebCenter Content管理対象サーバーを追加するには、『Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド』のWebCenter Contentのスケール・アウト手順に関する項の手順に従って、Oracle WebCenter Content管理対象サーバーを新しいノードに追加します。

16.6 WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行

表16-1は、WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。

表16-1 WebCenter Portal (11g)エンタープライズ・デプロイメントでバックアップする静的アーティファクト

タイプ	ホスト	場所	層
ORACLEホーム(DB)	RACデータベース・ホスト - CUSTDBHOST1およびCUSTDBHOST2	ユーザー定義	データ層
Oracleホーム(OHS)	WEBHOST1およびWEBHOST2	ORACLE_BASE/admin/instance_name	Web層
MWホーム(SOAおよびWC)	SOAHOST1およびSOAHOST2 - SOA WCPHOST1とWCPHOST2 - WC	すべてのホスト上のMW_HOME	アプリケーション層
ORACLE HOME (WCC)	WCPHOST1とWCPHOST2	共有ディスク上: /share/oracle/wcc 各ホストのORACLE_HOME/wccにあるローカル・ファイル	アプリケーション層
インストール 関連のファイル		OraInventory user_home/bea/beahomelist, oraInst.loc, oratab

表16-2は、WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。

表16-2 WebCenter Portal (11g)エンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト

タイプ	ホスト	場所	層
ドメイン・ホーム	SOAHOST1 SOAHOST2 WCPHOST1 WCPHOST2	ORACLE_BASE/admin/domain_name/ mserver/domain_name	アプリケーション層
アプリケーション・アーティファクト(earおよびwarファイル)	SOAHOST1 SOAHOST2 WCPHOST1 WCPHOST2	管理コンソールですべてのデプロイメントを確認し、すべてのアプリケーション・アーティファクトをバックアップする	アプリケーション層
OHSインスタンス・ホーム	WEBHOST1およびWEBHOST2	ORACLE_BASE/admin/instance_name	Web層
OHS WCC構成ファイル	WEBHOST1およびWEBHOST2	各ホストの/share/oracle/wcc(ローカル・ファイル・システム)	Web層
RACデータベース	CUSTDBHOST1およびCUSTDBHOST2	ユーザー定義	データ層
Oracle WebCenter Contentリポジトリ		データベース・ベース	データ層

Oracle Fusion Middlewareのコンポーネントのバックアップとリカバリの詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。

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

ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。次に、SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。

前提条件:

• 管理サーバーが、すべてのアドレスではなく、ADMINVHNでリスニングするように構成されている。第8.3項「SOAHOST1での構成ウィザードによるドメインの作成」の手順14を参照してください。

• 管理サーバーは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での管理サーバーの実行場所であるドメイン・ディレクトリは、共有記憶域にあります。この共有記憶域は一度に1つのマシンにのみマウントする必要がありますが、SOAHOST2にマウントできます。管理サーバーがSOAHOST2にフェイルオーバーした場合、ASERVER_HOMEをSOAHOST2にマウントし、SOAHOST1からアンマウントする必要があります。

• 第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」の説明のとおり、Oracle WebLogic ServerおよびOracle Fusion MiddlewareコンポーネントはSOAHOST2にインストールされています(つまり、SOAHOST1に存在するORACLE_HOMEおよびMW_HOMEのパスをSOAHOST2でも使用できます)。

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

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

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

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

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

次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーしたうえで、同じWebLogic Serverマシン(これは物理マシンではなく論理マシンです)を引き続きその管理サーバーで使用する方法を示しています。

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

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

2. 最初のノードからaserver共有をアンマウントします。

3. 第2ノードにaserver共有をマウントします。

4. IPを第2ノードに移行します。

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

      /sbin/ifconfig ethX:Y down
      

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

      /sbin/ifconfig interface:index IP_Address netmask netmask
      

      例:

      /sbin/ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0
      

      
      

      注意: 使用するネットマスクとインタフェースは、SOAHOST2で使用可能なネットワーク構成と一致している必要があります。

      
      

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

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

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

7. 次の方法でSOAHOST2上の管理サーバーにアクセスできることをテストします。

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

      http://ADMINVHN:7001/console
      

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

      http://ADMINVHN:7001/em
      

      
      

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

      
      

16.7.2 Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証

第8.7.5項「Oracle HTTP Serverを介したアクセスの検証」と同じ手順を実行します。この目的は、SOAHOST2で実行している管理サーバーにもアクセスできることを確認することです。

16.7.3 SOAHOST1への管理サーバーのフェイルバック

この手順では、管理サーバーをフェイルバックできることを確認します。フェイルバックとは、SOAHOST2で実行している管理サーバーを停止し、ADMINVHNをSOAHOST1ノードに戻して、SOAHOST1で再び管理サーバーを実行することです。

ADMINVHNをSOAHOST1に戻す手順は次のとおりです。

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

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

   /sbin/ifconfig ethZ:N down
   

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

   /sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
   

   
   

   注意: 使用するネットマスクとインタフェースは、SOAHOST1で使用可能なネットワーク構成と一致している必要があります。

   
   

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

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

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

   cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin
   ./startWebLogic.sh
    
   

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

   http://ADMINVHN:7001/console
   

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

   http://ADMINVHN:7001/em
   

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

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

ORACLE_HOME/network/admin

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

16.9 Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング

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

注意: 内部URLにアクセスしようとすると404エラーが発生する場合は、独自のポータルまたはランディング・ページへのリダイレクトを追加できます。

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

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

• 第16.9.2項「管理コンソールで変更をアクティブ化した後にユーザーがログイン画面にリダイレクトされる」

• 第16.9.3項「OAMに対する変更をアクティブ化した後でユーザーが管理コンソールのホーム・ページにリダイレクトされる」

• 第16.9.4項「ドメインの伝播後WC_Spaces Serverが起動しない」

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

• 第16.9.6項「データベースのフェイルオーバー後にポートレットが使用できなくなる」

• 第16.9.7項「構成済のJOCポートがすでに使用中」

• 第16.9.8項「JMS構成の復元」

• 第16.9.9項「OAM構成ツール実行時にURLが削除されない」

• 第16.9.10項「RESTポリシーの構成後に2次認証を無効にする」

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

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

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

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

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

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

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

16.9.2 管理コンソールで変更をアクティブ化した後にユーザーがログイン画面にリダイレクトされる

問題: Oracle WebLogic管理コンソールにアクセスするためにOHSおよびロード・バランサを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。

解決方法: この問題は、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、管理コンソールがその変更を反映しようとすると発生します。変更内容によっては、管理サーバーのリスニング・アドレスにリダイレクトすることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、URLをwcp.example.com/console/console.portalに変更して管理コンソールのホーム・ページに直接アクセスできます。

注意: この項で説明する変更の追跡を無効にしている場合、この問題は発生しません。

16.9.3 OAMに対する変更をアクティブ化した後でユーザーが管理コンソールのホーム・ページにリダイレクトされる

問題: OAMを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻りません)。

解決方法: これは、OAM SSOが構成済のときに発生する現象で、管理サーバーによってリダイレクトが実行された結果です。このリダイレクトにかかわらず、アクティブ化は完了します。必要であれば、ユーザーは手動で目的のコンテキスト・メニューに戻ることができます。

16.9.4 ドメインの伝播後WC_Spaces Serverが起動しない

問題: unpackユーティリティを使用し、SOAHOST2、WCPHOST1およびWCPHOST2にドメイン構成を伝播した後、WC_Spacesサーバーを起動できません。

[Deployer:149158]No application files exist at '/u01/app/oracle/admin/wcpedg_domain/aserver/wcpedg_domain/custom.webcenter.spaces.fwk'... 

解決方法: 管理サーバーがマウントされているかどうかに関係なく、管理サーバーが作成したconfig.xml内のパスは、すべてのマシンで使用可能にする必要があります。これは、欠落しているフォルダまたはファイルを、プライマリ・ドメインから新しいノードのローカル・ファイル・システムにコピーすることによって行われます。

1. 各マシンで、WebCenter Portalファイルを共有記憶域からローカル記憶域にコピーします。

   管理サーバーがマウントされた状態では、次のように一時ディレクトリに対して実行できます。

   $ mkdir /tmp/wcptemp
   $ cp ORACLE_BASE/admin/domain_name/aserver/applications/domain_name/* /tmp/wcptemp
   

2. 管理サーバーがディスマウントされた状態の各マシンでは、ローカル・ディレクトリを作成してから、そのディレクトリに次のファイルを移動します。

   $ mkdir -p ORACLE_BASE/admin/domain_name/aserver/applications/domain_name
   $ mv /tmp/webcentertemp/* ORACLE_BASE/admin/domain_name/aserver/applications/domain_name
   
   

すべての管理対象サーバーが正常に起動されるはずです。

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

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

<Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: 
ORACLE_BASE/admin/soadomain/aserver/
soadomain/servers/AdminServer/data/ldap/ldapfiles.
Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

解決方法: ノードの障害発生後にノードを復旧させるときに、ドメイン・ディレクトリに共有記憶域が使用されている場合、ロック・クリーンアップの失敗が原因で、管理サーバーのログにこのエラーが記録されることがあります。このエラーを解決するには、ファイルを削除します。

ORACLE_BASE/ admin/domain_name/aserver/domain_name/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lok

16.9.6 データベースのフェイルオーバー後にポートレットが使用できなくなる

問題: WebCenter Portal内でページを作成しているときに、そのページにポートレットを追加した後でデータベース・フェイルオーバーが発生すると、エラーがあるコンポーネントがページに表示されます。

"Error"
"Portlet unavailable"

このメッセージは、ページをリフレッシュしたり、いったんログアウトして再度ログインしてもなくなりません。

解決方法: この問題を解決するには、該当のコンポーネントを削除してからもう一度追加します。

16.9.7 構成済のJOCポートがすでに使用中

問題: Javaオブジェクト・キャッシュ(OWSM、WebCenter Portal管理対象サーバーなど)を使用している管理対象サーバーの起動に失敗します。次のエラーがログに表示されます。

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

解決方法: JOCが取得しようとしているポートと同じポートを別のプロセスが使用しています。このプロセスを停止するか、または推奨ポート範囲内の別のポートを使用するようにこのクラスタのJOCを再構成します。

16.9.8 JMS構成の復元

問題: soa-createUDD.pyスクリプトに渡されたパラメータに誤りがあるか、別の誤りによってSOAクラスタのJMS構成で障害が発生しています。

解決方法: soa-createUDD.pyを使用して、構成をリストアします。

SOAクラスタがOracle Fusion Middleware構成ウィザードから作成された後でsoa-createUDD.pyスクリプトを実行しているときに、なんらかの誤りが生じた(誤ったオプションが使用された、ターゲットが変更された、またはモジュールが間違って削除された)場合。このような状況では、soa-createUDD.pyスクリプトを使用し、次の手順で適切なJMS構成をリストアできます。

1. 既存のSOA JMSリソース(SOAインフラストラクチャ・システムが所有するJMSモジュール)を削除します。

2. soa-createUDD.pyを再実行します。このスクリプトは、SOA用に作成されたJMSサーバーが保持され、SOA用の共通分散送り先を使用するために必要な宛先とサブデプロイメント・モジュールが作成されることを想定しています。この場合、オプション--soaclusterを指定してスクリプトが実行される必要があります。スクリプトを再実行後、WebLogic Server管理コンソールから次のアーティファクト(ドメイン構造、サービス、メッセージング、JMSモジュール)が存在することを確認します。

   SOAJMSModuleUDDs        ---->SOAJMSSubDM targeted to SOAJMSServer_auto_1 and SOAJMSServer_auto_2
   UMSJMSSystemResource    ---->UMSJMSSubDMSOA targeted to UMSJMSServer_auto_1 and UMSJMSServer_auto_2
   

16.9.9 OAM構成ツール実行時にURLが削除されない

問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しました。1つ以上のURLが不正です。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。

解決方法: 同じapp_domain名を指定してOAM構成ツールを実行したときは、既存ポリシーへの新しいURLの追加のみが行われます。特定のURLを削除するには、OAMのポリシー・マネージャ・コンソールを使用してください。OAMのアクセス管理サイトにログインして、「ポリシー・ドメイン」をクリックし、作成されたポリシー・ドメイン(WebCenter_EDG)→「リソース」タブをクリックし、誤ったURLを削除します。

16.9.10 RESTポリシーの構成後に2次認証を無効にする

問題: RESTポリシーの構成後、その後の認証でもOAMを介した外部のクライアントの認証が要求されます。

解決方法: 2次認証はWebLogic Serverから発生しています。WebLogic Serverの資格証明の要求を無効にするには、次のようにセキュリティ・ポリシーを更新する必要があります。

1. 次のファイルを探します。

   /aserver/domain_name/config/config.xml
   

2. セキュリティの構成の終わりの部分で(つまり</security-configuration>の前に)、次の行を追加します。

   <enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credenti als>
   

3. ドメイン内のすべてのサーバーを再起動します。

16.9.11 サーバー移行時にSudoエラーが発生する

問題: サーバー移行のためwlsifconfigを実行すると、次の警告が表示されます。

sudo: sorry, you must have a tty to run sudo

解決方法: WebLogicユーザー('oracle')がバックグラウンドでsudoを実行できません。この問題を解決するには、次の行を/etc/sudoersに追加します。

Defaults:oracle !requiretty

詳細は、第14.5項「wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定」を参照してください。

16.9.12 トランザクション・タイムアウト・エラー

問題: 次のトランザクション・タイムアウト・エラーがログに記録されます。

Internal Exception: java.sql.SQLException: Unexpected exception while enlisting
 XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start()
failed on resource 'SOADataSource_wcpedg_domain': XAER_NOTA : The XID
is not valid

解決方法: トランザクション・タイムアウト設定を確認し、JTAトランザクション・タイムアウトがデータ・ソースXAトランザクション・タイムアウトよりも短いことを確認します(後者はデータベースでのdistributed_lock_timeoutよりも短い)。

出荷時の構成では、SOAデータ・ソースではXAタイムアウト値は設定されていません。WebLogic Server管理コンソールでは、Set XA Transaction Timeout構成パラメータのチェック・ボックスの選択が解除されています。この場合、データ・ソースはドメイン・レベルのJTAタイムアウトを使用します。これは30に設定されています。また、データベースに対するデフォルトのdistributed_lock_timeout値は60です。このため、トランザクションの期間がこれらの値より低いことが想定されるシステムでは、SOA構成は正しく機能します。特定の処理にかかると想定されるトランザクション時間に応じてこれらの値を調整してください。

16.9.13 最大サイズ超過エラー・メッセージ

問題: 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. 必要に応じて「最大メッセージ・サイズ」フィールドを変更します。