16 トポロジの管理

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

• 第16.1項「Oracle WebCenter Contentトポロジの管理の概要」

• 第16.2項「Oracle WebCenter Content: Imagingの入力ファイルを最適化する戦略の定義」

• 第16.3項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジ内でのコンポジットおよびアーティファクトのデプロイ」

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

• 第16.5項「Oracle WebCenter Content: ImagingのUMSドライバの構成」

• 第16.6項「Oracle WebCenter Contentトポロジのスケール・アップ」

• 第16.7項「Oracle WebCenter Contentトポロジのスケール・アウト」

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

• 第16.9項「Oracle WebCenter Contentエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」

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

• 第16.11項「Oracle WebCenter ContentとImagingサービスで使用するOracle Web Service Managerのセキュリティ・ポリシーの構成」

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

16.1 Oracle WebCenter Contentトポロジの管理の概要

Oracle WebCenter Contentエンタープライズ・デプロイメントを構成したら、この章の情報を使用してトポロジを管理できます。表16-1に、トポロジを管理するために実行できるタスクを示します。

表16-1 Oracle WebCenter Contentトポロジを管理するためのタスク

タスク	説明	詳細
Imagingクラスタにおいて高いパフォーマンス、スケーラビリティおよび高可用性を実現するためのImagingの構成	入力ファイルを最適化する戦略を定義します。	第16.2項「Oracle WebCenter Content: Imagingの入力ファイルを最適化する戦略の定義」
Imagingで使用するOracle SOA Suiteサブシステムの管理	SOAコンポジットをサーバーのアドレスにデプロイし、Oracle SOA Suiteインフラストラクチャ内の領域を管理し、UMSドライバを構成します。	第16.3項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジ内でのコンポジットおよびアーティファクトのデプロイ」 第16.4項「SOAインフラストラクチャ・データベースでの領域の管理」 第16.5項「Oracle WebCenter Content: ImagingのUMSドライバの構成」
スケール・アップまたはスケール・アウトによるトポロジの拡張	ノードに新しい管理対象サーバーを追加するか、または新しいノードを追加します。	第16.6項「Oracle WebCenter Contentトポロジのスケール・アップ」 第16.7項「Oracle WebCenter Contentトポロジのスケール・アウト」
管理サーバーの手動フェイルオーバーが正しく機能していることの確認	管理サーバーを別のノードにフェイルオーバーします。	第16.8項「管理サーバーの手動フェイルオーバーの検証」
構成の変更前後におけるトポロジのバックアップ	ディレクトリおよびファイルをバックアップし、構成の変更によって発生する障害から保護します。	第16.9項「Oracle WebCenter Contentエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」
接続タイムアウトの防止	データベース接続がタイムアウトしないようにファイアウォールを構成します。	第16.10項「SQLNet接続のタイムアウト防止」
Oracle WebCenter ContentとImagingのWebサービスで使用するOracle Web Service Manager(Oracle WSM)のセキュリティ・ポリシーの構成	HTTP基本認証のかわりに適切なOracle WSMポリシーを適用します。	第16.11項「Oracle WebCenter ContentとImagingサービスで使用するOracle Web Service Managerのセキュリティ・ポリシーの構成」
問題のトラブルシューティング	トポロジの構成後に発生する可能性のある既知の問題の解決方法を実施します。	第16.12項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」

Oracle WebCenter Contentの管理の詳細は、次のドキュメントを参照してください。

• Oracle® Fusion Middleware Oracle WebCenter Contentの管理

• Oracle Fusion Middleware Oracle WebCenter Contentの管理

• Oracle WebCenter Content Imaging管理者ガイド

16.2 Oracle WebCenter Content: Imagingの入力ファイルを最適化する戦略の定義

入力ファイルは、入力エージェントがスケジュール設定および処理できる作業の最小単位です。Imagingクラスタにおいて最高のパフォーマンス、スケーラビリティ、および可用性を実現するために、いくつかの考慮事項があります。

• Imagingクラスタ内のすべてのマシンは、共通の入力ディレクトリを共有します。

• このディレクトリからの入力ファイルは、JMSキューを介してそれぞれのマシンに配信されます。

• このディレクトリをポーリングして新しいファイルを調べる間隔は構成可能です。

• 各マシンには、入力ファイルを処理する解析エージェントが複数あります。解析エージェントの数は、Oracle WebCenter Content: Imagingデプロイメント内で作成されたワーク・マネージャを使用して構成されます。

次のような場合に最適なパフォーマンスを実現できます。

• それぞれのImagingクラスタ・インスタンスに、ユーザー・インタフェースやWebサービスなどの他のImagingアクティビティのパフォーマンスを損ねることなく、ワーク・マネージャを介して構成された最適な最大数の解析エージェントがある場合。

• ドキュメントのインバウンド・フローは、最適な数のドキュメントを含む入力ファイルに分割されます。平均では、クラスタ内の解析エージェントごとに2つの入力ファイルをキューに格納する必要があります。

• クラスタ内で1台以上のマシンに障害が発生した場合、アクティブなマシンが入力ファイルの処理を続行します。障害が発生したマシンの入力ファイルは、サーバーが再起動するまで処理されません。入力ファイルを小さくすることで、マシンの障害によって大量のドキュメントが未処理の状態にならないようにします。

たとえば、2台のサーバーで1時間当たり10,000のインバウンド・ドキュメントが処理されるとします。サーバーごとに2つの解析エージェントを構成すると、全体的に適度なパフォーマンスが実現され、エージェントごとに2ドキュメント/秒でインジェストされます。2ドキュメント/秒の解析エージェントが4つある場合、8ドキュメント/秒(28,800ドキュメント/時)で処理されます。10,000ドキュメントの単一の入力ファイルは、1時間では処理できません(7,200ドキュメント/時で処理する単一の解析エージェントだとその処理を完了できまません)。ただし、その入力ファイルを8つに分割して1,250ドキュメントずつにすると、4つのすべての解析エージェントはフルに活用され、1時間内に10,000ドキュメントの処理が完了するようになります。また、一方のサーバーで障害が発生した場合、処理が正常に終了するまでもう一方のサーバーで解析エージェントに残っている処理を続行できます。

16.3 Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジ内でのコンポジットおよびアーティファクトのデプロイ

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

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

すべてのコンポジットがデータベースを頻繁に使用するわけではありませんが、CUBE_INSTANCEおよびMEDIATOR_INSTANCEスキーマにはかなりの量のデータがサービス・エンジンによって生成されます。データベース領域が不足すると、SOAコンポジットが機能しなくなることがあります。Oracle Enterprise Manager Fusion Middleware Control(ダッシュボードなど)で、oracle.fabric.common.FabricInvocationExceptionのような一般的なエラーがないかどうか監視してください。Oracle SOA Suiteサーバーのログについても、次のようなエラーがないかどうか検索します。

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のこのような操作への使用は、ほとんどの場合、トランザクション・タイムアウトが発生するのでお薦めできません。

提供されるSQLパッケージで可能な操作の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のSOAコンポジット・アプリケーションの管理に関する項を参照してください。正しく消去するには、提供されているスクリプトを常に使用します。composite_dn表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。

16.5 Oracle WebCenter Content: ImagingのUMSドライバの構成

注意: この手順が必要になるのは、Oracle WebCenter Content: Imagingが使用するOracle SOA SuiteシステムがUnified Messaging System (UMS)を使用している場合のみです。

UMSドライバの構成情報は、Oracle SOA Suiteクラスタに自動的には伝播されません。これは、Oracle WebCenter Content: Imagingによって起動されるOracle SOA SuiteシステムがUMSを使用する場合、次を実行する必要があることを意味します。

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
   

   (*は、デプロイ中にOracle WebLogic Serverによってランダムに生成される3682yqなどのディレクトリ名を表します)。

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

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

2. SOAHOST2へのWLS_IMG1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内のUMSドライバ構成のディレクトリ構造が、次のとおりであることを確認してください。

   cd ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration
   

   (*は、デプロイ中にWLSによってランダムに生成される3682yqなどのディレクトリ名を表します)。

3. 次のコマンドをSOAHOST1で実行し、SOAHOST1からSOAHOST2にドライバ構成ファイルをリモート・コピーします

   scp ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml oracle@SOAHOST2:ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/
   

   (*は、デプロイ中にOracle WebLogic Serverによってランダムに生成される3682yqなどのディレクトリ名を表します)。

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

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

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

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

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

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

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

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

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

16.6 Oracle WebCenter Contentトポロジのスケール・アップ

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

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

スケール・アップの手順は、トポロジのコンポーネントによって異なります。

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

• 第16.6.2項「Oracle WebCenter Content: Imagingのスケール・アップ手順」

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

16.6.1 Oracle WebCenter Contentのスケール・アップ手順

1つのドメイン、1つのノードに対して、Oracle WebCenter Content管理対象サーバー1台のみが、Oracle Fusion Middlewareによってサポートされます。Oracle WebCenter Content管理対象サーバーを追加するには、第16.7.1項「Oracle WebCenter Contentのスケール・アウト手順」に従い、新しいノードにOracle WebCenter Content管理対象サーバーを追加します。

16.6.2 Oracle WebCenter Content: Imagingのスケール・アップ手順

Imagingサーバーをスケール・アップする前に、WCCHOST1(WCCHOST1VHN2など)ではVIPを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはhost解決のいずれかで)正しく解決する必要があります。VIPを有効にするには、第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」で説明した例に従ってください。

エンタープライズ・デプロイメント・トポロジ内でImagingサーバーをスケール・アップする手順は次のとおりです。

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

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

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

   2. 「サーバーのサマリー」ページで、「ロックして編集」をクリックし、クローンを作成する管理対象サーバー(WLS_IMG1)を選択します。

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

   4. 新しい管理対象サーバーの名前を「WLS_IMGn」にします。nは、新しい管理対象サーバーの識別番号です。

   5. サーバーのリスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーの仮想ホスト名を割り当てる必要があります。この仮想ホスト名は、既存の管理対象サーバーとは別のものを使用してください。

   6. サーバーのリスニング・ポートに対して、Imagingクラスタ(IMG_Cluster)のリスニング・ポート番号を入力します。このガイドにおける参照用トポロジはポート番号16000を使用します。

   7. 「OK」をクリックし、「変更のアクティブ化」をクリックします。この時点で、「サーバーのサマリー」に、新しく作成されたサーバーWLS_IMGnが表示されます。

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

2. Oracle WebCenter Content: Imaging JMS用に、JMS永続ストアとJMSサーバーを構成します。

   2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Oracle WebCenter Content: Imagingで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/store/default)を使用しています。

   次のように、共有ベースのディレクトリを使用するように、Oracle JMSサーバーの永続ストアを変更する必要があります。

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

   2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて永続ストアノードをクリックします。

   3. 「永続ストアの概要」ページで「ロックして編集」をクリックします。

   4. 「新規」→「ファイル・ストアの作成」をクリックします。

   5. 「新しいファイル・ストアの作成」ページで次の情報を入力します。

      - 名前: IMGJMSServernStore(例: IMGJMSServer3Store。これにより、作成対象のサービスを特定できます)。

      - ターゲット: WLS_IMGn(例: WLS_IMG3)。

      - ディレクトリ: WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを指定します (ORACLE_BASE/admin/domain_name/img_cluster_name/jms)。

      
      

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

      
      

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

   7. 「ドメイン構造」ウィンドウで、「サービス」ノード→「メッセージ」ノードを開いて、「JMSサーバー」をクリックします。

   8. 「JMSサーバーのサマリー」ページで「新規」をクリックし、次の情報を入力します。

      - 名前: IpmJmsServern(例: IpmJmsServer3)。

      - 永続ストア: 前述のとおり作成した永続ストアIMGJMSServernStore(例: IMGJMSServer3Store)を選択します。

      「次へ」をクリックし、WLS_IMGn(例: WLS_IMG3)をターゲットとして指定します。「終了」をクリックします。

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

3. トランザクション・リカバリのためのWLS_IMGnのデフォルトの永続ストアを構成します。

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

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

   3. 「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)「WLS_IMGn」をクリックします。WLS_IMGnサーバーの設定ページが開き、「構成」タブがアクティブに表示されます。

   4. 「サービス」タブを開きます。

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

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

      ORACLE_BASE/admin/domain_name/img_cluster_name/tlogs
      

      
      

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

      
      

   7. 「保存」をクリックして、変更をアクティブ化します。

4. 第8.4.5項「ホスト名検証の無効化」の手順に従って、新しい管理対象サーバーのホスト名検証を無効化します。

   WLS_IMGn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

5. 新しく作成した管理対象サーバー(WLS_IMG)を起動します。

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

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

   3. 「サーバーのサマリー」ページで、「制御」タブを開き、クラスタ内にある既存のWLS_IMGnすべての管理対象サーバーを停止します。

   4. 新規作成した管理対象サーバーであるWLS_IMGnが稼働していることを確認します。

6. WLS_IMGn管理対象サーバー(WCCHOSTnVHN2)のホスト名をSocketHostNameSecurityFilterパラメータ・リストに追加します。

   1. テキスト・エディタで、ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfgのファイルを開きます。

   2. リスニング・アドレスをOracle WebCenter Contentへの接続を許可するアドレスのリストに追加するために、WLS_IMGn管理対象サーバーを追加します(SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|WCCHOST1|WCCHOST2|WCCHOSTnVHNn)。

   3. 変更されたconfig.cfgファイルを保存して、Oracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

7. サーバー移行が新しい管理対象サーバー用に構成されていることを確認します。

   
   

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

   
   

   サーバー移行が構成されていることを確認する手順は次のとおりです。

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

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

   3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成する新しい管理対象サーバー名(ハイパーリンクで表示されている)をクリックします。

   4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

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

      たとえば、すでにWLS_IMG1が実行されているWCCHOST1上の新しい管理対象サーバーには、WCCHOST2を選択します。すでにWLS_IMG2が実行されているWCCHOST2上の新しい管理対象サーバーには、WCCHOST1を選択します。

      
      

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

      
      

   6. 「サーバーの自動移行を有効化」オプションが選択されていることを確認します。

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

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

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

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

   • WLS_IMGn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

     ps -ef | grep WLS_IMGn
     

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

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

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

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

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

エンタープライズ・デプロイメント・トポロジ内でOracle SOA Suiteサーバーをスケール・アップする手順は次のとおりです。

注意: Oracle WebCenter Content: Imagingが使用するOracle SOA Suiteサブシステムのスケール・アップについては、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのドキュメントを参照してください。

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

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

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

   2. 「サーバーのサマリー」ページで、クローンを作成する管理対象サーバー(WLS_SOA1)を選択します。

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

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

      
      

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

      
      

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

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

   1. WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。第4.3項「各種ディレクトリの推奨場所について」でお薦めしているように、これは共有記憶域上のディレクトリにします。

      ORACLE_BASE/admin/domain_name/soa_cluster_name/jms/
      

      
      

      注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。

      
      

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

   3. 新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_N)。このストアのパスを指定します。第4.3項「各種ディレクトリの推奨場所について」でお薦めしているように、これは共有記憶域上のディレクトリにします。

      ORACLE_BASE/admin/domain_name/soa_cluster_name/jms/
      

      
      

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

      
      

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

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

      
      

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

      
      

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

   6. UMSJMSSystemResourceのサブデプロイメント・ターゲットを更新し、先ほど作成したUMS JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。

      
      

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

      
      

      「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

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

   
   

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

   
   

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

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

   ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
   

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

   WLS_SOAn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、この手順は不要です。

   詳細は、第8.4.5項「ホスト名検証の無効化」を参照してください。

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

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

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

   
   

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

   
   

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

   
   

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

   
   

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

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

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

   3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成する新しい管理対象サーバー名(ハイパーリンクで表示されている)をクリックします。

   4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

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

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

      
      

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

      
      

   6. 「サーバーの自動移行を有効化」オプションが選択されていることを確認します。

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

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

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

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

   • WLS_SOAn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

     ps -ef | grep WLS_SOAn
     

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

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

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

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

16.7 Oracle WebCenter Contentトポロジのスケール・アウト

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

前提条件

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

• Oracle Fusion Middlewareで構成された管理対象サーバーを実行しているノードがトポロジ内に存在しています。

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

• ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して、そのノードに共有記憶域内のインストールを追加するには、ORACLE_HOME/oui/bin/attachHome.shを使用します。

  WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、User_Home/bea/beahomelistファイルを編集します。次の手順を参照してください。

• 新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。

  
  

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

  
  

スケール・アウトの手順は、トポロジのコンポーネントによって異なります。

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

• 第16.7.2項「Oracle WebCenter Content: Imagingのスケール・アウト手順」

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

16.7.1 Oracle WebCenter Contentのスケール・アウト手順

エンタープライズ・デプロイメント・トポロジ内でOracle WebCenter Contentのサーバーをスケール・アウトする手順は次のとおりです。

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

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

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

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

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

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

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

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

6. WebLogic Server管理コンソールを使用して、WLS_WCC1をクローニングして新しい管理対象サーバーを作成します。これにWLS_WCCnという名前を付けます(nには番号を指定します)。

   
   

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

   
   

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

8. WLS_WCCn管理対象サーバーを新しく作成されたマシンに割り当てます。

   使用可能なサーバーのリストからWLS_WCCnサーバーを選択し、「終了」をクリックします。

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

   
   

   注意: 管理対象サーバーのドメイン・ディレクトリはWCCHOSTnでまだ作成されていないため、この手順と次の2つの手順を実行する必要があります。

   
   

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleWCC.jar -template_name=edgdomain_templateScaleWCC
   

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

    scp edgdomaintemplateScaleWCC.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin
    

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

    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateScaleWCC.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
    

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

    CD WL_HOME/server/bin
    ./startNodeManager.sh
    

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

    WLS_WCCn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

    詳細は、第8.4.5項「ホスト名検証の無効化」を参照してください。

14. WebLogic Server管理コンソールで、新しい管理対象サーバーであるWLS_WCCnを起動します。

    1. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

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

    3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

    4. WLS_WCCnサーバーを選択して、「起動」をクリックします。

    5. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

15. 新しい管理対象サーバーであるWLS_WCCnを構成します。

    1. http://WCCHOSTn:16200/csでWebLogic Serverの管理ユーザー名とパスワードを使用してWLS_WCCnにログインします。WebCenter Contentの「構成」ページが表示されます。

       
       

       注意: 「データベース内のRevisions表が空ではないため、このサーバーを新規インスタンスとして 構成できません。このサーバーは既存のクラスタ内のノードのみに構成できます。」というテキストが、ページの最後に表示されます。

       
       

    2. 「サーバーの構成」ページで次の値を変更します。「クラスタ・ノード識別子」が、管理対象サーバーのID (WLS_WCCnなど)と一致するように設定されていることを確認してください。

       - コンテンツ・サーバーのインスタンス・フォルダ: これをORACLE_BASE/admin/
domain_name/wcc_cluster_name/csに設定します。

       - ネイティブ・ファイル・リポジトリの場所: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/vaultに設定します。

       - Webレイアウト・フォルダ: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/weblayoutに設定します。

       - ユーザー・プロファイル: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/data/users/profilesに設定します。

    3. 完了したら「送信」をクリックし、WebLogic Server管理コンソールを使用して新しい管理対象サーバーを再起動します。

16. Oracle WebCenter Contentで許可されているホストのリストに、WLS_WCCnのリスニング・アドレスを追加します。

    1. テキスト・エディタで、ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfgのファイルを開きます。

    2. Oracle WebCenter Contentへの接続を許可されているアドレスのリストに、WLS_WCCnのリスニング・アドレスを追加します。

    3. 変更されたconfig.cfgファイルを保存して、Oracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

    サーバーおよびリスニング・アドレスは次のContent Serverプールに追加されます。

    • WCCHOST1:4444

    • WCCHOST2:4444

    • WCCHOST3:4444

    詳細は、第11.17項「Oracle WebCenter Content Serverへの接続の作成」を参照してください。

17. LBR上のアプリケーション(https://wcc.mycompany.com/cs)にアクセスしてWLS_WCCn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

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

16.7.2 Oracle WebCenter Content: Imagingのスケール・アウト手順

エンタープライズ・デプロイメント・トポロジ内でImagingサーバーをスケール・アウトする手順は次のとおりです。

1. 新しいノードで、Oracle WebCenter Contentのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認します。

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

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

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

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

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

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

6. WebLogic Server管理コンソールを使用して、WLS_IMG1をクローニングして新しい管理対象サーバーを作成します。これにWLS_IMGnという名前を付けます(nには番号を指定します)。

   
   

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

   
   

7. 新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーのVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、既存の管理対象サーバーとは別のものを使用してください。

   
   

   注意: ノードnではVIPを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはhosts解決のいずれかで)正しく解決する必要があります。VIPを有効にするには、第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」で説明した例に従ってください。

   
   

   また、新しく作成したサーバーを手順4で追加したマシンに割り当てます。これを実行しない場合、クローン元のサーバーのマシン名が残ります。

8. 新しい管理対象サーバーでOracle WebCenter Content: ImagingのJMSサーバーを作成します。

   1. WebLogic Server管理コンソールを使用して、新しいIMGJMSServer用の新しい永続ストアを最初に作成し(IMGJMSServerの作成方法は後述)、IMGJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4.3項「各種ディレクトリの推奨場所について」でお薦めしているストアのパスを指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms
      

      
      

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

      
      

   2. 新しいJMSサーバーを作成します(たとえば、IMGJMSServer_N)。このJMSサーバーには、前述で作成したIMGJMSFileStore_Nを使用します。IMGJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_IMGn)を指定します。

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

   
   

   注意: 他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、この手順および次の2つの手順は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバー用に使用します。

   
   

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleIMG.jar -template_name=edgdomain_templateScaleIMG
   

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

    
    

    注意: 新しいホストである、WCCHOSTnまたはSOAHOSTnがSOAHOST1と同じMW_HOMEを使用する場合、この手順は不要です。

    
    

    scp edgdomaintemplateScaleIMG.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin
    

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

    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template= edgdomaintemplateScaleIMG.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
    

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

    WLS_WCCn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

    詳細は、第8.4.5項「ホスト名検証の無効化」を参照してください。

13. 次により、「サーバーの自動移行を有効化」オプションを無効にします。

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

    2. WLS_IMGn管理対象サーバーを選択し、「移行」タブをクリックします。

    3. 「サーバーの自動移行を有効化」の選択を解除します。

    4. 「保存」および「変更のアクティブ化」をクリックします。

14. ノード・マネージャがまだ起動されていない場合は、新しいノードで起動します。WCCHOSTnで次のコマンドを実行し、ノード・マネージャを起動します。

    CD WL_HOME/server/bin
    ./startNodeManager.sh
    

15. Fusion Middleware Controlで、新しい管理対象サーバーであるWLS_IMGnを起動し、稼働していることを確認します。

16. Oracle WebCenter Content Serverで許可されているホストのリストに、新しいImagingサーバーのリスニング・アドレスを追加します。第11.16項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」の手順に従って、新しいサーバーを、Oracle WebCenter ContentのSocketHostNameSecurityFilter構成に追加します。

17. すべてのOracle WebCenter Content管理対象サーバーを再起動します。

    
    

    注意: Imaging管理対象サーバーのホスト名が、ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfgファイルにあるSocketHostNameSecurityFilterパラメータ・リストに追加されたことを確認します。

    
    

18. LBR上のアプリケーション(https://wcc.mycompany.com/imaging)にアクセスしてWLS_IMGn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

    
    

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

    
    

19. 新しく追加したサーバー用のサーバー移行を構成します。

    新しいサーバーのクローン元となったソース・サーバー(ここではWLS_IMGn)はすでにサーバー移行が構成されていると想定しています。この場合、サーバー移行の設定はクローンされたサーバーに伝播されるため、次の手順は不要です。

    すでにノード・マネージャにホスト名検証証明書を設定している場合は、前提条件として、新しく作成されたサーバーに対してこの手順を実行する必要があります。詳細は、第13.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

    
    

    注意: この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいノードで定義される権限を検証して、サーバー移行が機能することを確認します。権限の要件の詳細は、第14章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。

    
    

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

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

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

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

    4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

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

       
       

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

       
       

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

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

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

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

    • WLS_IMGn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

      ps -ef | grep WLS_IMGn
      

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

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

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

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

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

トポロジ内でOracle SOA Suiteサーバーをスケール・アウトする手順は次のとおりです。

注意: Oracle WebCenter Content: Imagingが使用するOracle SOA Suiteサブシステムのスケール・アウトについては、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのドキュメントを参照してください。

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

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

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

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

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

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

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

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

   
   

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

   
   

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

   このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーのVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、既存の管理対象サーバーとは別のものを使用してください。

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

   
   

   注意: 他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、この手順は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバー用に使用します。

   
   

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleSOA.jar -template_name=edgdomain_templateScaleSOA
   

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

   scp edgdomaintemplateScaleSOA.jar oracle@SOAHOSTn:/ORACLE_COMMON_HOME/common/bin
   

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

    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template= edgdomaintemplateScaleSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
    

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

    1. WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。第4.3項「各種ディレクトリの推奨場所について」でお薦めしているように、このディレクトリは共有記憶域上にある必要があります。

       ORACLE_BASE/admin/domain_name/cluster_name/jms
       

       
       

       注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。

       
       

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

    3. 新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_N)。このストアのパスを指定します。第4.3項「各種ディレクトリの推奨場所について」でお薦めしているように、これは共有記憶域上のディレクトリにします。

       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. SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、先ほど作成したSOA JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列にハイパーリンクとして表示)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSのサブデプロイメント・モジュールが表示されます。

       
       

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

       
       

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

    6. UMSJMSSystemResourceのサブデプロイメント・ターゲットを更新し、先ほど作成したUMS JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。

       
       

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

       
       

       「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

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

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

    ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
    

13. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

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

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

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

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

    4. 「サーバーのサマリー」ページで、表の「名前」列にある「WLS_SOAn」を選択します。

    5. サーバーの設定ページで「SSL」タブを開きます。

    6. 表示されたページの「詳細」セクションを開きます。

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

    8. ホスト名の検証をNoneに設定します。

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

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

    WL_HOME/server/bin/startNodeManager.sh New_Node_IP
    

    
    

    注意: 第6章にある「Oracle WebLogic Serverのインストールとミドルウェア・ホームの作成」で示されたパスを使用した場合は、WL_HOMEは、ORACLE_BASE/product/fmw/wlserver_10.3となります。

    
    

15. WebLogic Server管理コンソールで、新しい管理対象サーバーであるWLS_SOAnを起動し、稼働していることを確認します。

16. LBR上のアプリケーション(http://soainternal.mycompany.com/soa-infra)にアクセスしてWLS_SOAn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

    
    

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

    
    

17. 新しく追加したサーバー用のサーバー移行を構成します。

    
    

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

    
    

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

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

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

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

    4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

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

       
       

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

       
       

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

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

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

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

    • WLS_SOAn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

      ps -ef | grep WLS_SOAn
      

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

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

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

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

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

ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをSOAHOST1からSOAHOST2にフェイルオーバーする方法を説明します。

• 第16.8.1項「前提条件および手順」

• 第16.8.2項「ロード・バランサを介したSOAHOST2へのアクセスの検証」

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

16.8.1 前提条件および手順

次の前提条件に注意してください。

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

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

  • SOAHOST1: 100.200.140.165

  • SOAHOST2: 100.200.140.205

  • ADMINVHN: 100.200.140.206.これは管理サーバーを実行している場所のVIPであり、ethX:Yに割り当てられています。

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

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

手順

次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーする方法を示します。

1. 管理サーバーが実行されている場合は停止します。

2. 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 100.200.140.206 netmask 255.255.255.0
      

      
      

      注意: 使用するネットマスクとインタフェースは、SOAHOST2で使用可能なネットワーク構成と一致している必要があります。また、第4.3項「各種ディレクトリの推奨場所について」で説明するとおりの位置に、管理サーバー・アプリケーションのディレクトリがマウントされていることを確認してください。

      
      

   3. 次の例のとおり、arpingを使用してSOAHOST2のルーティング表を更新します。

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

3. SOAHOST2でノード・マネージャを起動するには、第8.4.2項「SOAHOST1でのノード・マネージャの起動」の説明に従います。

4. SOAHOST2上で管理サーバーを起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の説明に従います。

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

   1. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにアクセスできることを確認します。

   2. http://ADMINVHN:7001/emでOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、そのコンポーネントのステータスを確認します。

16.8.2 ロード・バランサを介したSOAHOST2へのアクセスの検証

第8.5.5項「ロード・バランサを使用したアクセスの検証」と同様の手順を実行します。この目的は、SOAHOST2で稼働中の管理サーバーにアクセスできることを確認することにあります。

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

この手順により、管理サーバーをフェイルバックできることを確認します。すなわち、SOAHOST2では管理サーバーを停止し、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. SOAHOST1上で再び管理サーバーを起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の説明に従います。

6. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにアクセスできるかどうかテストします。

7. http://ADMINVHN:7001/emでOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、そのコンポーネントのステータスを確認します。

16.9 Oracle WebCenter Contentエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行

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

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

タイプ	ホスト	場所	層
ORACLEホーム(DB)	CUSTDBHOST1およびCUSTDBHOST2	ユーザー定義	データ層
MWホーム(OHS)	WEBHOST1およびWEBHOST2	ORACLE_BASE/product/fmw/	Web層
MW HOME (SOA Oracleホームも含む)	SOAHOST1およびSOAHOST2*	MW_HOME SOA OracleホームもMW_HOMEの下: ORACLE_HOME	アプリケーション層
インストール関連ファイル		OraInventory、User_Home/bea/beahomelist、 oraInst.loc、oratab	なし

^{* WCCHOST1およびWCCHOST2は、SOAHOST1およびSOAHOST2からインストールされたバイナリを使用します。バックアップは、SOAHOST1とSOAHOST2で一元化されています。}

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

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

タイプ	ホスト	場所	層
アプリケーション・アーティファクト(EARおよびWARファイル)	SOAHOST1、SOAHOST2、WCCHOST1およびWCCHOST2	アプリケーション・アーティファクトの場所を調べるには、管理コンソールですべてのデプロイメントを表示します。	アプリケーション層
Oracle SOA Suiteランタイム・アーティファクト	SOAHOST1またはSOAHOST2	ORACLE_BASE/admin/domain_name/soa_cluster_name	アプリケーション層
Oracle WebCenter Contentランタイム・アーティファクト	WCCHOST1またはWCCHOST2	ORACLE_BASE/admin/domain_name/wcc_cluster_name	アプリケーション層
Oracle WebCenter Content: Imagingランタイム・アーティファクト	WCCHOST1またはWCCHOST2	ORACLE_BASE/admin/domain_name/img_cluster_name	アプリケーション層
Oracle WebCenter Content用にカスタマイズされた管理対象サーバーの構成	WCCHOST1またはWCCHOST2	ORACLE_BASE/admin/domain_name/mserver/domain_name/ucm/cs/bin/intradoc.cfg および ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration/wlsifconfig.sh	アプリケーション層
Oracle SOA Suite用にカスタマイズされた管理対象サーバーの構成	SOAHOST1またはSOAHOST2	UMSを使用する場合: DOMAIN_HOME/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml (*は、デプロイ中にWebLogic Serverによってランダムに生成される3682yqなどのディレクトリ名を表します) および ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration/wlsifconfig.sh	アプリケーション層
Oracle HTTP Serverインスタンス・ホーム	WEBHOST1およびWEBHOST2	ORACLE_BASE/admin/instance_name	Web層
Oracle RACデータベース	CUSTDBHOST1およびCUSTDBHOST2	ユーザー定義	データ層

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

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

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

16.11 Oracle WebCenter ContentとImagingサービスで使用するOracle Web Service Managerのセキュリティ・ポリシーの構成

初回インストール時、Oracle WebCenter ContentおよびImagingのWebサービスは、Oracle Web Service Manager(OWSM) のセキュリティ・ポリシーを適用せずに構成されています。セキュリティ・ポリシーが適用されていない場合、サービスは、HTTPの基本認証メカニズムを使用します。このメカニズムでは、ユーザーの資格証明(ユーザーIDおよびパスワード)は、WebサービスのHTTPメッセージ・ヘッダー内で送信されます。HTTP基本認証ではなく適切なOracle WSMポリシーを適用することをお薦めします。Oracle WebCenter ContentおよびImagingのWebサービスで使用するOracle WSMのセキュリティ・ポリシーを構成するには、Oracle WebCenter Content Imaging開発者ガイドおよび『Oracle WebCenter Contentインストレーション・ガイド』の手順に従います。

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

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

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

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

• 第16.12.3項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」

• 第16.12.4項「データベース内の最大プロセス数に達したために、SOAサーバー、Oracle WebCenter ContentサーバーまたはImagingサーバーの起動に失敗する」

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

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

• 第16.12.7項「サーバー移行後にSOAサーバーまたはImagingサーバーがフェイルオーバーしない」

• 第16.12.8項「サーバー移行後にSOAサーバーまたはImagingサーバーにブラウザからアクセスできない」

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

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

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

• 第16.12.12項「構成されたJOCポートがすでに使用中」

• 第16.12.13項「CredentialAccessPermissionsを使用することで、Oracle WebCenter Content: Imagingが資格証明ストアから資格証明を読み取ることが可能になる」

• 第16.12.14項「Oracle WebCenter Content: ImagingからOracle WebCenter Contetに情報量の多いドキュメントをアップロードする際のパフォーマンスを向上させる」

• 第16.12.15項「管理対象サーバーのメモリー不足の問題」

• 第16.12.16項「Oracle WebCenter Contentサーバーのマスター・パスワードを再生成する」

• 第16.12.17項「WebLogic Server管理コンソールからログアウトしても、ユーザー・セッションが終了しない」

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

• 第16.12.19項「ファイルのキャッシュとロック」

• 第16.12.20項「リモートでデプロイされたアプリケーションで使用するアップロード・ディレクトリおよびステージ・ディレクトリの変更」

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

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

解決方法: Oracle SOA Suite管理対象サーバーが実行中であっても、そのサーバー内のアプリケーションの状態がActiveではなく、AdminやPreparedである場合があります。Oracle SOA Suiteサーバーが実行中でも、soa-infraアプリケーションが使用不可になることもあります。管理コンソールの「デプロイメント」ページで、soa-infraアプリケーションの状態を調べてください。これが「アクティブ」状態である必要があります。Oracle SOA Suiteサーバーの出力ログにsoa-infraアプリケーション関連のエラーがないことを確認し、管理コンソールの「デプロイメント」ページでsoa-infraアプリケーションを起動してください。

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

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

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

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

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

16.12.3 SOAサーバーの再起動に失敗したためにポリシー移行が未完になる

問題: ノード・マネージャのプロパティをstartScriptEnabled=trueに設定する前にOracle SOA Suiteサーバーを管理コンソールから起動しようとすると、失敗します。このプロパティを設定した後も、サーバーは起動しません。Oracle SOA Suiteサーバーの出力ログには、次のように報告されます。

SEVERE: <.> Unable to Encrypt data
Unable to Encrypt data.
Check installation/post-installation steps for errors. Check for errors during SOA server startup.

ORABPEL-35010
 .
Unable to Encrypt data.
Unable to Encrypt data.
Check installation/post-installation steps for errors. Check for errors
 during SOA server startup.
 .
 at oracle.bpel.services.common.util.EncryptionService.encrypt(EncryptionService.java:56)
...

解決方法: クラスタ内の最初のOracle SOA Suiteサーバーの起動が失敗したためにポリシー移行が未完になります。正常に移行するには、次のようにsystem-jazn-data.xmlファイル内の<jazn-policy>要素を編集してbpm-services.jarに権限を付与します。

<grant>
  <grantee>
    <codesource>
<url>file:${oracle.home}/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar</url>
    </codesource>
  </grantee>
  <permissions>
    <permission>
      <class>java.security.AllPermission</class>
    </permission>
  </permissions>
</grant>

16.12.4 データベース内の最大プロセス数に達したために、SOAサーバー、Oracle WebCenter ContentサーバーまたはImagingサーバーの起動に失敗する

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

<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コマンドを発行します。

SHOW PARAMETER processes

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

ALTER SYSTEM SET processes=300 SCOPE=SPFILE

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

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

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

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

<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/edg_domain/aserver/edg_domain/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.12.6 管理コンソールで変更をアクティブ化するときにエラーが発生する

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

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

解決方法: これは、管理コンソールでサーバーの起動パラメータが変更された場合に発生する可能性があります。この場合、管理コンソールで、構成を変更した特定のサーバーのサーバー起動構成でユーザー名とパスワードの情報を指定します。

16.12.7 サーバー移行後にSOAサーバーまたはImagingサーバーがフェイルオーバーしない

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

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

16.12.8 サーバー移行後にSOAサーバーまたはImagingサーバーにブラウザからアクセスできない

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

解決方法: arpingコマンドがノード・マネージャによって実行されてARPキャッシュが更新されましたが、この更新が適切にブロードキャストされていません。この場合、そのノードが外部ノードからは到達不能になります。nodemanager.propertiesファイルを更新してMACBroadcastを追加するか、次のように手動でarpingを実行してください。

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

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

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

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

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

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

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

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

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

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

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

解決方法: これは、Oracle Access Manager SSOが構成され、管理コンソールが構成の変更を反映するように設定されている場合に発生することが予想されます(リダイレクトはなんらかの変更をアクティブ化する際に管理コンソールによって実行されます)。このリダイレクトにかかわらず、アクティブ化は完了します。連続して変更を行ってもリダイレクトされないようにするには、管理コンソールにアクセスして、「プリファレンス」→「共有プリファレンス」を選択し、「構成変更の追跡」チェック・ボックスの選択を解除します。

16.12.12 構成されたJOCポートがすでに使用中

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

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

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

16.12.13 CredentialAccessPermissionsを使用することで、Oracle WebCenter Content: Imagingが資格証明ストアから資格証明を読み取ることが可能になる

問題: Oracle WebCenter Content: Imagingが、起動中に資格証明のアクセス権限を作成し、system-jazn-data.xmlファイルのローカル・ドメイン・ディレクトリ・コピーを更新します。LDAPポリシー・ストアが構成されていない状態で環境をテストしている間に、Oracle WebCenter Content: Imagingサーバーの存在しているドメイン・ディレクトリに、system.jazn-data.xmlファイルへの手動の更新を管理サーバーがプッシュする可能性があります。これによって、ファイルのコピーが上書きされたり、Oracle WebCenter Content: Imagingコンソールの再起動またはアクセス時に、様々な例外およびエラーが発生したりする可能性があります。

解決方法: 資格証明のアクセス権限を再作成し、管理サーバーにある、system-jazn-data.xmlファイルのドメイン・ディレクトリ・コピーを更新するために、Oracle WebLogic Scripting ToolでgrantIPMCredAccessコマンドを使用します。このためには、Oracle WebCenter Contentに関連付けられたORACLE_HOMEから wlst.shを起動して管理サーバーに接続し、WCCHOST1でgrantIPMCredAccess()コマンドを実行します。

cd ORACLE_HOME/common/bin

./wlst.sh

wls:/offline> connect()

wls:/domain_name/serverConfig> grantIPMCredAccess()

注意: 接続時には、管理サーバー用の資格証明とアドレスを指定してください。

16.12.14 Oracle WebCenter Content: ImagingからOracle WebCenter Contetに情報量の多いドキュメントをアップロードする際のパフォーマンスを向上させる

問題: ホスト名ベースのセキュリティ・フィルタがOracle WebCenter Content(config.cfgファイル)で使用されている場合、Oracle WebCenter Content: ImagingからOracle WebCenter Contentに情報量の多いドキュメントをアップロードする際に、大きな遅延とパフォーマンスへの影響がシステム内に発生する可能性があります。この問題の原因は、Imagingサーバーからの接続を許可するためにOracle WebCenter Contentで必要とされるDNSの逆引き参照です。

解決方法: 災害からの保護および異なるホストへのリストアのためにシステム構成を準備する場合、ホスト名ベースのセキュリティ・フィルタを使用することをお薦めします(ホスト名ベースのセキュリティ・フィルタ使用時は、使用される構成がIPにとらわれないものになるため)。ただし、アップロードのパフォーマンスを向上させる必要がある場合は、ホスト名ベースのフィルタのかわりにIPベースのセキュリティ・フィルタを使用できます。

Oracle WebCenter Contentでホスト名ベースのセキュリティ・フィルタをIPベースのフィルタに変更する手順は次のとおりです。

1. テキスト・エディタで、ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfgのファイルを開きます。

2. 次の2行を削除またはコメント・アウトします。

   SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|wcchost1vhn1|wcchost2vhn1
   AlwaysReverseLookupForHost=Yes
   

3. WLS_IMG1およびWLS_IMG2管理対象サーバー(それぞれWCCHOST1VHN1およびWCCHOST2VHN1)のIPアドレス(リスニング・アドレス)をSocketHostAddressSecurityFilterパラメータ・リストに追加します。

   SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1|X.X.X.X|Y.Y.Y.Y
   

   ここで、X.X.X.XおよびY.Y.Y.Yは、それぞれWLS_IMG1とWLS_IMG2のリスニング・アドレスです。(同様に、127.0.0.1がこのリストに含まれている必要があります。)

4. 変更されたconfig.cfgファイルを保存して、Oracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

16.12.15 管理対象サーバーのメモリー不足の問題

問題: 管理対象サーバーでメモリー不足が発生します。

解決方法: Java VMに割り当てられているメモリー・ヒープのサイズを少なくとも1GBに増やします。

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

2. 「環境」をクリックし、「サーバー」をクリックします。

3. 管理対象サーバー名をクリックします。

4. 「構成」タブを開きます。

5. 2列目にある「サーバーの起動」タブを開きます。

6. 「引数」ボックスでメモリー・パラメータを追加します。例:

   -Xms256m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m
   

   
   

   注意: メモリー・パラメータ要件は、各種のJVM(Sun、JRockitなど)ごとに異なる可能性があることに注意してください。詳細は、『Oracle WebCenter Contentインストレーション・ガイド』の管理対象サーバーのJava VMヒープ・サイズの増加に関する項を参照してください。

   
   

7. 構成の変更を保存します。

8. 実行されているすべての管理対象サーバーを再起動します。

16.12.16 Oracle WebCenter Contentサーバーのマスター・パスワードを再生成する

Oracle WebCenter Content管理対象サーバーのドメイン・ホームのcwallet.ssoファイルが、クラスタ間で不整合を生じたり、ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/ディレクトリにおける無効なコピーによってこのファイルが削除または誤って上書きされたりする場合は、次の手順を実行して、ファイルを再生成できます。

1. すべてのOracle WebCenter Content管理対象サーバー(WLS_WCCx)を停止します。

2. ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig/のcwallet.ssoファイルを削除します。

3. ORACLE_BASE/admin/domain_name/aserver/wcc_cluster_name/cs/config/privateのpassword.hdaファイルを削除します。

4. WCCHOST1でWLS_WCC1サーバーを起動します。

5. ORACLE_BASE/admin/domain_name/aserver/wcc_cluster_name/cs/config/private/にあるpassword.hdaファイルの作成と同様に、ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig/にあるcwallet.ssoファイルの作成または更新も検証します。

6. Oracle WebCenter Contentのシステム・プロパティのコマンドライン・ツールを使用して、データベースのパスワードを更新します。

7. スタンドアロンのOracle WebCenter Contentアプリケーション(Batchloader、システム・プロパティなど)が正しく機能しているか検証します。

8. cwallet.ssoファイルをORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig/から、ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/の管理サーバーのドメイン・ディレクトリにコピーします。

9. 2台目のOracle WebCenter Contentのサーバーを起動し、更新されたcwallet.ssoファイルを、管理サーバーがWCCHOST2におけるORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig/にプッシュし、そのファイルがWCCHOST1上のOracle WebCenter Contentのサーバーによって作成または更新されたのと同じファイルであることを検証します。

10. スタンドアロンのOracle WebCenter Contentアプリケーション(Batchloader、システム・プロパティなど)が正しく機能しているか検証します。

11. スタンドアロンのOracle WebCenter Contentアプリケーションが両方のノードで同時に正しく機能することを検証します。

16.12.17 WebLogic Server管理コンソールからログアウトしても、ユーザー・セッションが終了しない

Oracle Access Managerのシングル・サインオン(SSO)を使用してWebLogic Serverの管理コンソールにログインする場合、ログアウトボタンをクリックしても、ユーザー・セッションが終了しません。これは、SSOのログアウトのガイドラインに従って、Oracle Access Managerログイン・ページにリダイレクトされるのではなく、ホームページがリロードされるからです。本当にログアウトするには、WebブラウザのCookieを手動で消去する必要があります。

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

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

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タイムアウトに値を設定していません。Set XA Transaction Timeout構成パラメータはWebLogic Server管理コンソールでは確認されません。この場合、データ・ソースは30に設定されたドメインレベルのJTAタイムアウトを使用します。また、データベースのdistributed_lock_timeoutのデフォルト値は60です。この結果、トランザクションにかかる時間がこれらの値よりも短いと想定されるシステムでは、SOA構成は正しく動作します。特定の操作に想定されるトランザクション時間に合せて、これらの値を調整します。

16.12.19 ファイルのキャッシュとロック

Oracle WebCenter Contentは、ファイルに対して固有のロック・メカニズムを使用するため、ファイル属性のキャッシュおよびクラスタ・ノードにより実行されるロックなしでファイルにアクセスする必要があります。ノードの1つがある状態のファイルにアクセスし、そのファイルがキャッシュされている場合、そのノードは別のノードがすでに実行しているプロセスの実行を試みる場合があります。または、特定のファイルがノード・クライアントの1つにロックされている場合、別のノードによるアクセスが妨げられる場合があります。ファイル共有でファイル属性のキャッシュを無効化すると、パフォーマンスに影響する可能性があります。よって、必要とされる特定のフォルダでのみキャッシュおよびロックを無効化することが重要です。たとえば、ネットワーク・ファイル・システム(NFS)を介して共有を作成している場合は、マウント・オプションでnoacおよびnolockを使用します。

16.12.20 リモートでデプロイされたアプリケーションで使用するアップロード・ディレクトリおよびステージ・ディレクトリの変更

アプリケーションをリモートでデプロイした場合は、ドメインを作成しmserverディレクトリに解凍した後、uploadディレクトリおよびstageディレクトリを絶対パスに更新する必要がある場合があります。絶対パスの名前により、リモートのデプロイメントの問題とステージ・モードを使用するデプロイメントの混乱を防ぐことができます。

これらのディレクトリに対するデフォルトのパス名は次のとおりです。

./servers/AdminServer/upload

./servers/server_name/stage