ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド
11g リリース1(11.1.1)
B55900-03
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

11 トポロジの管理

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

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

11.1 トポロジの監視

トポロジの監視方法の詳細は、Oracle Fusion Middleware Oracle WebCenter管理者ガイドの第15章を参照してください。

11.2 UMSドライバの構成

UMSドライバの構成情報は、SOAクラスタに自動的には伝播されません。したがって、ユーザーが次の作業を行う必要があります。

  1. UMSドライバの構成情報を、そのドライバを使用するEDGトポロジ内のすべてのサーバーに適用します。

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

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

    (「*」はデプロイメント時にランダムに生成されるディレクトリ名、たとえば「3682yq」を表します)。

フェイルオーバーに備えてファイルを作成するには、強制的にサーバー移行を実行してファイルをソース・ノードからコピーしてください。

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

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

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

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

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

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

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

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

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

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

すべてのコンポジットでデータベースが頻繁に使用されるわけではありませんが、サービス・エンジンは大量のデータをCUBE_INSTANCEスキーマとMEDIATOR_INSTANCEスキーマで生成します。データベースの領域が不足していると、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管理者ガイドの第8章「SOAコンポジット・アプリケーションの管理」を参照してください。必ず、適切に消去できるようにするために提供されているスクリプトを使用してください。表composite_dnのみの列を削除しても、Oracle Fusion Middleware SOAインフラストラクチャで使用される他の表での未解決の参照がそのまま残ってしまう可能があります。

11.4 トポロジのスケーリング

エンタープライズ・トポロジは、スケールアウトまたはスケールアップできます。トポロジのスケールアップとは、1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することです。トポロジのスケールアウトとは、新しいノードに新しい管理対象サーバーを追加することです。

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

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

この項では、トポロジのスケール・アップ方法について説明します。トポロジのスケール・アップには、既存ノードへの管理対象サーバーの追加などがあります。

11.4.1.1 SOAおよびWSMのスケール・アップ

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

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

    管理対象サーバーのクローンを作成するには、次の手順を実行します:

    1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

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

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

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

    以降の手順は、新しいサーバーをSOAHOST1に追加する場合を想定しています。このホストではすでにWLS_SOA1が実行されています。

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

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

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

    1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリ・パスは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、JMS永続ストアのディレクトリとして指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_N

      注意:

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

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

    3. 新しいUMS JMSサーバー用の新しい永続ストアを作成し(UMS JMSサーバーの作成方法は後述します)、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリ・パスは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、JMS永続ストアのディレクトリとして指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_N

      注意:

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


      注意:

      新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。

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

    5. BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、次のように共有記憶域上のディレクトリにする必要があります。

      ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N


      注意:

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

      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を構成します。手順は、第5.5項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。


    注意:

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

    Dtangosol.coherence.localhost=SOAHOST1VHNn

  6. 新しいサーバー用の永続ストアを構成します。これは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、他のノードから見える場所にする必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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


    注意:

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

    Oracle WebLogic Server管理コンソールを使用してサーバー移行を構成するには、次の手順を実行します:

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

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

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

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

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


      注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11.4.1.2 WebCenterのスケール・アップ

この場合は、Oracle WebCenterコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードの共有記憶域には、MiddlewareホームとWebCenterディレクトリが格納されています。

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


注意:

1つのノードでの複数の管理対象サーバーの実行は、WC_SpacesサーバーとWC_Portletサーバーに対してのみサポートされています。

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

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

    管理対象サーバーのクローンを作成するには:

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

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

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

    4. 新しい管理対象サーバーSERVER_NAMEnに名前を付けます。n は、新しい管理対象サーバーを識別する番号です。

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

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

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

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

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

    • ポートレットの場合は、メンバーを/portalTools、/wsrp-tools、/richtextportlet、/pageletadminおよび/wcps/codeのLocationブロックに追加します。

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

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

11.4.2.1 SOAおよびWSMのスケール・アウト

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

前提条件

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

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

  • ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておくことをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールをアタッチするには、ORACLE_HOME/oui/bin/attachHome.shを使用します。ミドルウェア・ホーム・リストでWL_HOMEを追加または削除するには、<user_home>/bea/beahomelistファイルを編集します。次の手順を参照してください。

トポロジをスケールアウトするには、次の手順を実行します:

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

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

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

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

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

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

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

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


    注意:

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

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

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

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

  9. SOA用、BPM用および(適用可能な場合)UMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。


    注意:

    この手順は、WSM_PM管理対象サーバーをスケールアウトする場合は不要です。WLS_SOA管理対象サーバーの場合にのみ実行してください。BAM Webアプリケーション・システムをスケールアップする場合も、この手順は不要です。

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

    1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述)、SOAJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリ・パスは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、JMS永続ストアのディレクトリとして指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_N

      注意:

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

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

    3. 新しいUMSJMSServer用の新しい永続ストアを作成し、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリ・パスは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、JMS永続ストアのディレクトリとして指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore _N

      注意:

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


      注意:

      新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。

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

    5. BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、次のように共有記憶域上のディレクトリにする必要があります。

      ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N


      注意:

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

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

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

    7. SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したSOA JMSサーバーを追加します。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModuleUDDs」をクリックします(表の「名前」列にハイパーリンクとして表示されます)。SOAJMSModuleUDDsの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSSubDMサブデプロイメントが表示されます。


      注意:

      このサブデプロイメント・モジュールは、最初の2つのサーバー(WLS_SOA1およびWLS_SOA2)のJMS構成を共通分散宛先(UDD)スクリプト(soa-createUDD.py)によって更新した結果作成されたものです。このスクリプトは、EDGトポロジの初期設定に必要です。

      このサブデプロイメントをクリックします。SOA用の新しいJMSサーバーSOAJMSServer_Nを、このサブデプロイメントに追加します。「保存」をクリックします。

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

    9. 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を追加します)。保存してアクティブ化をクリックします。

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

    SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

    SOAHOST1> ./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コマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。

    SOAHOSTN> cd ORACLE_COMMON_HOME/common/bin

    SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name/
-template=soadomaintemplateScale.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/apps

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


    注意:

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

    Dtangosol.coherence.localhost=SOAHOST1VHNn

  12. 新しいサーバー用の永続ストアを構成します。これは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、他のノードから見える場所にする必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    SOAHOSTN> WL_HOME/server/bin/startNodeManager

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

    1. 新たに作成した管理対象サーバー、WLS_SOAnが実行されていることを確認します。

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


      注意:

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

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


    注意:

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

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

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

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

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

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


      注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11.4.2.2 WebCenterのスケール・アウト

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

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

  • トポロジ内には、WebCenterアプリケーションを使用して構成されている管理対象サーバーを実行しているノードがすでに存在しています。

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

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

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

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

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

    WCHOSTn> cd ORACLE_BASE/product/fmw/wc/
WCHOSTn> ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>

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

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

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

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

  6. Oracle WebLogic Server管理コンソールを使用して、WC_Spaces1、WC_Portlet1、WC_Collaboration1またはWC_Utilities1のクローンを新しい管理対象サーバーに作成します。そのクローンにWLS_XXXn(nは数字)という名前を付けて新しいマシンに割り当てます。

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

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

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

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

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

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

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

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

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

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

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

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

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

    WCHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip

  10. 新しい管理対象のCollaborationサーバーの場合:

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

    2. 第6.14項「マルチキャストからユニキャストへのディスカッション・フォーラムの変換」の手順が実行されていることも確認します。coherence.localhostパラメータに、新しいホストのホスト名を指定してください。

  11. 新しいUtilities管理対象サーバーの場合は、アクティビティ・グラフが第6.17項「アクティビティ・グラフの構成」の手順に従って無効にされていることを確認します。また、UtilitiesとローカルSpacesサーバーに対して、第6.16項「分析コレクタの構成」の分析コレクタの構成手順が実行されていることを確認します。

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

    1. 新たに作成した管理対象サーバー、WLS_SOAnが実行されていることを確認します。

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


      注意:

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

11.5 バックアップとリカバリの実行

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

表11-1 11gのOracle WebCenterエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト

タイプ ホスト 場所 層

ORACLEホーム(DB)

RACデータベース・ホスト: CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

ディレクトリ層

MWホーム(SOAおよびWC)

SOAHOST1およびSOAHOST2: SOA

WCHOST1およびWCHOST2: WC

すべてのホスト上のMW_HOME

アプリケーション層

Oracleホーム(OHS)

WEBHOST1およびWEBHOST2

ORACLE_BASE/admin/<instance_name>

Web層

Oracleホーム(OCS)

WCHOST1およびWCHOST2

共有ディスク上: /share/oracle/ucm

各ホスト: ORACLE_HOME/ucmにあるローカル・ファイル

アプリケーション層

インストール関連ファイル

OraInventory、<user_home>/bea/beahomelist、oraInst.loc、oratab

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

表11-2 11gのOracle WebCenterエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト

タイプ ホスト 場所 層

ドメイン・ホーム

SOAHOST1

SOAHOST2

WCHOST1

WCHOST2

ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>

アプリケーション層

アプリケーション・アーティファクト(earおよびwarファイル)

SOAHOST1

SOAHOST2

WCHOST1

WCHOST2

管理コンソールですべてのデプロイメントを確認し、すべてのアプリケーション・アーティファクトを取得する

アプリケーション層

OHSインスタンス・ホーム

WEBHOST1およびWEBHOST2

WEBHOST1上: ORACLE_HOME/ohs_1/instances/instance1

WEBHOST2上: ORACLE_HOME/ohs_2/instances/instance2

Web層

OHS OCS構成ファイル

WEBHOST1およびWEBHOST2

各ホストの/share/oracle/ucm(ローカル・ファイル・システム)

Web層

RACデータベース

CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

ディレクトリ層

OCSコンテンツ・リポジトリ

データベース・ベース

ディレクトリ層

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


注意:

ORACLE_HOMEのバックアップは、B2B設定の一部であるXEngine構成が変更されたときに実行する必要があります。対象のファイルは、ORACLE_HOME/soa/thirdparty/edifecs/XEngineにあります。ORACLE_HOMEをバックアップするには、次のコマンドを実行してください。 
SOAHOST1> tar -cvpf fmwhomeback.tar MW_HOME

11.6 トラブルシューティング

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

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

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

<Feb 19, 2009 3:43:05 AM PST> <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を削除します。

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

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

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ファイルから削除してください(管理サーバーの再起動が必要)。

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

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

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

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

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

"Error"
"Portlet unavailable"

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

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

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

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

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


注意:

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

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

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

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

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

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

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

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

11.6.8 JMS構成の復元

問題: soa-createUDD.pyスクリプトに渡されたパラメータに誤りがあるか、別の誤りによってSOAクラスタまたはBAMクラスタの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

11.7 ベスト・プラクティス

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

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

EDG本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters(RAC)の場合、データベース接続はOracle RACのVIPとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。そのように構成できない場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルの*SQLNET.EXPIRE_TIME=n*パラメータを設定してください。nは分単位の数値です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定してください。

11.7.2 監査

Oracle Fusion Middleware監査フレームワークは、Oracle Fusion Middleware 11gで追加された新しいサービスです。これは、ミドルウェア製品ファミリの集中監査フレームワークです。このフレームワークでは、Oracle Platform Security Services(OPSS)やOracle Web Servicesなどのプラットフォーム・コンポーネントに対して監査サービスが提供されます。また、これは、Oracle固有のJavaEEコンポーネントをはじめ、様々なJavaEEアプリケーションのフレームワークとしても機能します。また、このようなJavaEEアプリケーションで、アプリケーション固有の監査イベントを作成できます。ミドルウェアのOracleコンポーネントのうちJavaEE以外のもの、たとえばCやJavaSEのコンポーネントについても、JavaEEアプリケーションと同様、エンドツーエンドのフレームワーク構造を実現します。

図11-1は、Oracle Fusion Middleware監査フレームワーク・アーキテクチャの概要図です。

図11-1 監査イベント・フロー

図11-1の説明が続きます
「図11-1 監査イベント・フロー」の説明

Oracle Fusion Middleware監査フレームワークを構成する主なコンポーネントは次のとおりです。

  • 監査API

    Oracle Fusion Middleware監査フレームワークに統合される監査対応コンポーネント用のAPIです。実行時にアプリケーションからこのAPIを呼び出すと、アプリケーション・コード内で発生した特定のイベントに関する必要な情報の監査を行うことができます。監査対象のイベントのコンテキストを示すために、イベントの詳細情報、たとえばユーザー名や属性を、このAPIを通してアプリケーション側で指定できます。

  • 監査イベントと構成

    Oracle Fusion Middleware監査フレームワークには、汎用イベントがあらかじめ用意されており、アプリケーション監査イベントを簡単にマッピングできるようになっています。この汎用イベントとは、認証などの一般的なイベントです。このフレームワークでは、アプリケーション側でアプリケーション固有イベントも定義できます。

    このイベント定義および構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成の更新は、Enterprise Manager(UI)およびWLST(コマンドライン・ツール)から実行できます。

  • 監査バスストップ

    バスストップとは、監査リポジトリにプッシュされる前の監査データが格納されるローカル・ファイルです。データベース・リポジトリが1つも構成されていない場合は、このバスストップ・ファイルをファイルベースの監査リポジトリとして使用できます。バスストップ・ファイルは単純なテキスト・ファイルであり、特定の監査イベントの検索も簡単に実行できます。データベース・リポジトリがある場合、バスストップはコンポーネントと監査リポジトリの間の中間ファイルになります。ローカル・ファイルは、構成したアップロード間隔に基づいて、定期的に監査リポジトリにアップロードされます。

  • 監査ローダー

    その名のとおり、監査ローダーの機能は、監査バスストップのファイルを監査リポジトリにロードすることです。プラットフォームおよびJavaEEアプリケーションの監査の場合、JavaEEコンテナ起動時に監査ローダーも起動されます。システム・コンポーネントの場合、監査ローダーは定期的に生成されるプロセスになります。

  • 監査リポジトリ

    監査リポジトリに格納されるのは、事前定義されたOracle Fusion Middleware監査フレームワークのスキーマです。これは、リポジトリ作成ユーティリティ(RCU)によって作成されます。構成が完了すると、すべての監査ローダーがリポジトリを認識し、そのリポジトリに定期的にデータをアップロードするようになります。監査データは監査リポジトリ内に蓄積されるため、時間とともに増加します。監査リポジトリには、他のアプリケーションが使用している運用データベースではなく、監査専用のスタンドアロンのRDBMSを使用するのが理想的です。高可用性構成の場合は、Oracle Real Application Clusters(RAC)データベースを監査データ・ストアとして使用することをお薦めします。

  • Oracle Business Intelligence Publisher

    監査リポジトリ内のデータは、Oracle Business Intelligence Publisherの事前定義済レポートとして公開されます。このレポートでは、監査データを様々な条件に基づいてドリルダウンできます。例:

    • ユーザー名

    • 時間範囲

    • アプリケーション・タイプ

    • 実行コンテキスト識別子(ECID)

Oracle Fusion Middleware監査フレームワークの概要情報は、『Oracle Fusion Middlewareセキュリティ・ガイド』の「Oracle Fusion Middleware Audit Frameworkの概要」の章を参照してください。

Oracle Fusion Middleware監査フレームワークのリポジトリの構成の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』の「監査の構成と管理」の章を参照してください。

EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成は含まれません。バスストップ・ファイルへの監査データの出力、および監査ローダーの構成は、製品をインストールした後に実行できるようになります。最大の懸念事項は、監査データが格納される監査データベース・リポジトリです。監査データはサイズが大きく、過去のデータが蓄積されていくため、他のミドルウェア・コンポーネントの運用ストアとは別に、専用のデータベースを用意することを強くお薦めします。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引