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

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

この章には次の項が含まれます:

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

• 第19.2項「Imagingの入力ファイルを最適化する戦略の定義」

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

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

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

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

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

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

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

• 第19.10項「Oracle DatabaseでのOPSSセキュリティ・ストアの保持」

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

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

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

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

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

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

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

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

• Oracle WebCenter Enterprise Captureの管理

• Oracle WebCenter Contentの管理

• Oracle Fusion Middleware Oracle WebCenter Content: Imagingの管理

• Oracle WebCenter Contentのマネージング

19.2 Imagingの入力ファイルを最適化する戦略の定義

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

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

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

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

• 各マシンには、入力ファイルを処理する解析エージェントが複数あります。解析エージェントの数は、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ドキュメントの処理が完了するようになります。また、一方のサーバーで障害が発生した場合、処理が正常に終了するまでもう一方のサーバーで解析エージェントに残っている処理を続行できます。

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

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

19.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インフラストラクチャ・データベースのサイズを縮小することもできます。Fusion Middleware Controlのこのような操作への使用は、ほとんどの場合、トランザクション・タイムアウトが発生するのでお薦めできません。

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

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

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

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

ImagingのUMSドライバを構成する手順は次のとおりです。

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

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

   /u02/oracle/config/domains/WCCDomain/servers/server_name/
   tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml
   

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

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

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

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

   cd /u02/oracle/config/domains/WCCDomain/servers/server_name/
   tmp/_WL_user/ums_driver_name/*/configuration
   

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

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

   scp /u02/oracle/config/domains/WCCDomain/servers/server_name/
   tmp/_WL_user/ums_driver_name/*/configuration/
   driverconfig.xml oracle@WCCHOST2:/u02/oracle/config/domains/WCCDomain/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/
   

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

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

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

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

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

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

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

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

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

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

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

19.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管理対象サーバーにローカル(ノードごと)のドメイン・ディレクトリを使用します。

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

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

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

• 第19.6.3項「Oracle WebCenter Enterprise Captureのスケール・アップ手順」

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

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

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

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

Imagingサーバーをスケール・アップする前に、WCCHOST1 (WCCHOST1VHN2など)で仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスの有効化方法の詳細は、第10.7項「WLS_WCC管理対象サーバー用のノード・マネージャの構成」を参照してください。

エンタープライズ・デプロイメント・トポロジ内で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サーバーを構成します。

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

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

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

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

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

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

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

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

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

      - ディレクトリ: WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを指定します(/u01/oracle/config/domains/WCCDomain/IMG_Cluster/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. 「保存」をクリックして、変更をアクティブ化します。

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. テキスト・エディタでファイル/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgを開きます。

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

   3. 変更されたconfig.cfgファイルを保存しら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

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

   
   

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

   
   

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

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

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

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

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

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

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

      
      

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

      
      

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

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

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

   8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

      • まず、管理コンソールを使用して管理対象サーバーを停止します。

      • 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

      • 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

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

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

     ps -ef | grep WLS_IMGn
     

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

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

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

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

19.6.3 Oracle WebCenter Enterprise Captureのスケール・アップ手順

Oracle WebCenter Enterprise Captureサーバーをスケール・アップする前に、WCCHOST1 (WCCHOST1VHN3など)で仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスの有効化方法の詳細は、第10.7項「WLS_WCC管理対象サーバー用のノード・マネージャの構成」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

2. Capture用にJMS永続ストアとJMSサーバーを構成します。

   2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Captureで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(/u01/oracle/config/domains/WCCDomain/servers/server_name/data/store/default)を使用しています。

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

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

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

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

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

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

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

      - ターゲット: WLS_CPTn(例: WLS_CPT3)。

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

   6. 「OK」をクリックして、変更内容を有効にします。

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

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

      - 名前: CaptureJmsServern(例: CaptureJmsServer3)。

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

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

   9. 「終了」をクリックして変更内容を有効にします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   1. テキスト・エディタでファイル/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgを開きます。

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

   3. 変更されたconfig.cfgファイルを保存しら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

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

   
   

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

   
   

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

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

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

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

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

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

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

      
      

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

      
      

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

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

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

   8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

      • まず、管理コンソールを使用して管理対象サーバーを停止します。

      • 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

      • 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

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

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

     ps -ef | grep WLS_IMGn
     

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

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

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

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

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

Imagingサーバーをスケール・アップする前に、WCCHOST1 (WCCHOST1VHN1など)で仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスの有効化方法の詳細は、第10.7項「WLS_WCC管理対象サーバー用のノード・マネージャの構成」を参照してください。

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

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

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

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

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

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

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

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

      
      

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

      
      

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

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

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

      /u01/oracle/config/domains/WCCDomain/SOA_Cluster/jms/
      

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

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

      /u01/oracle/config/domains/WCCDomain/SOA_Cluster/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」サブデプロイメントをクリックします。UMSの新しいJMSサーバーであるUMSJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。

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

   
   

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

   
   

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

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

   /u01/oracle/config/domains/WCCDomain/SOA_Cluster/tlogs
   

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

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

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

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

   2. LBR上のアプリケーション(http://wccinternal.example.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. 「移行の構成」セクションで、移行に参加するサーバーを 「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。

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

      
      

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

      
      

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

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

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

   8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

      • まず、管理コンソールを使用して管理対象サーバーを停止します。

      • 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

      • 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

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

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

     ps -ef | grep WLS_SOAn
     

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

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

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

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

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

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

前提条件

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

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

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

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

  Middlewareホームの一覧を更新してWebLogic Serverホームを追加または削除するには、User_Home/bea/beahomelistファイルを編集します。次の手順を参照してください。

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

  
  

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

  
  

スケール・アウト手順

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

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

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

• 第19.7.3項「Oracle WebCenter Enterprise Captureのスケール・アウト手順」

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

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

WebCenter Contentのスケール・アウト手順では、構成済のWLS_WCCn管理対象サーバーを新しいノードに追加します。

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

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

   
   

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

   
   

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

   cd ORACLE_COMMON_HOME/oui/bin/
   
   ./attachHome.sh -jreLoc MW_HOME/jrockit_160_version
   

   
   

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

   
   

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

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

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

   
   

   注意: ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_WCCnサーバーをスケール・アウトする場合は、unpackコマンドで-overwrite_domainオプションを指定する必要があります。

   
   

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

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

   
   

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

   
   

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

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

   使用可能なサーバーのリストからWLS_WCCnを選択し、「終了」→「変更のアクティブ化」の順にクリックします。

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

   
   

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

   
   

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateScaleWCC.jar -template_name=edgdomain_templateScaleWCC
   

   参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

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

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

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

    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=/u02/oracle/config/domains/WCCDomain -template=edgdomaintemplateScaleWCC.jar -app_dir=/u01/oracle/config/applications/WCCDomain
    

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

    CD WL_HOME/server/bin
    nohup ./startNodeManager.sh > nm.out&
    

    参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

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

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

14. WebLogic Server管理コンソールで、新しい管理対象サーバーであるWLS_WCCnを起動し、サーバーの状態が「実行中」と表示されることを確認します。

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

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

       
       

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

       
       

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

       - コンテンツ・サーバーのインスタンス・フォルダ: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/csに設定します。

       - ネイティブ・ファイル・リポジトリの場所: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/vaultに設定します。

       - Webレイアウト・フォルダ: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/weblayoutに設定します。

       - ユーザー・プロファイル: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/data/users/profilesに設定します。

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

16. /u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgファイルにあるOracle WebCenter Contentで許可されているホストのリストに、WLS_WCCnのリスニング・アドレスを追加します。管理コンソールを使用して、Oracle WebCenter Content管理対象サーバーを再起動します。

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

    • WCCHOST1:4444

    • WCCHOST2:4444

    • WCCHOST3:4444

    詳細は、第13.5.12項「コンテンツ・サーバーへの接続の作成」を参照してください。

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

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

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

Imagingのスケール・アウト手順では、構成済のWLS_IMGn管理対象サーバーを新しいノードに追加します。

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

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

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

   cd ORACLE_COMMON_HOME/oui/bin/
   
   ./attachHome.sh -jreLoc MW_HOME/jrockit_160_version
   

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

   
   

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

   
   

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

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

   
   

   注意: WLS_WCCnサーバーと同じマシンでWLS_IMGnサーバーをスケール・アウトする場合、新しいマシンを作成する必要はありません。第19.7.1項「WebCenter Contentのスケール・アウト手順」の手順4で作成したマシンを使用します。

   
   

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

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

   
   

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

   
   

   1. 新しい管理対象サーバー用に使用するホスト名またはIPアドレスを、その管理対象サーバーのリスニング・アドレスとして割り当てます。このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーの仮想IPアドレス(別称: 浮動IPアドレス)である必要があります。この仮想IPアドレスは、既存の管理対象サーバーとは別のものを使用してください。

      
      

      注意: ノードnでは仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスを有効化する方法の詳細は、第6.6項「仮想IPアドレスの有効化」を参照してください。

      
      

   2. 「はい、このサーバーを既存のクラスタのメンバーにします。」を選択します。

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

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

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

      /u01/oracle/config/domains/WCCDomain/IMG_Cluster/jms
      

   2. 新しいJMSサーバーを作成します(例: IpmJmsServerN)。

      前の手順で作成したIMGJMSServerNStoreをJMSサーバーに使用します。IpmJmsServerNサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_IMGn)を指定します。

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

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateScaleIMG.jar 
   -template_name=edgdomain_templateScaleIMG
   

   参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

   
   

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

   
   

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

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

   
   

   注意: 新しいホストである、WCCHOSTnがWCCHOST1と同じMiddlewareホームを使用する場合、この手順は不要です。

   
   

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

    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=MSERVER_HOME -template= edgdomaintemplateScaleIMG.jar -app_dir=APPLICATION_HOME
    

    参照トポロジで、APPLICATION_HOMEは/u01/oracle/config/applications/WCCDomainディレクトリです。

    
    

    注意: ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_IMGnサーバーをスケール・アウトする場合は、unpackコマンドで-overwrite_domainオプションを指定する必要があります。

    
    

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

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

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

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

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

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

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

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

    CD WL_HOME/server/bin
    nohup ./startNodeManager.sh > nm.out&
    

    参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

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

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

    
    

    注意: すべてのImaging管理対象サーバーのホスト名が/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgファイルにあるSocketHostNameSecurityFilterパラメータ・リストに追加されていることを確認してください。

    
    

16. WebLogic Server管理コンソールを使用してすべてのOracle WebCenter Content管理対象サーバーを再起動します。

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

    
    

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

    
    

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

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

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

    
    

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

    
    

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

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

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

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

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

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

       
       

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

       
       

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

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

    8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

       • まず、管理コンソールを使用して管理対象サーバーを停止します。

       • 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

       • 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

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

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

      ps -ef | grep WLS_IMGn
      

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

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

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

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

19.7.3 Oracle WebCenter Enterprise Captureのスケール・アウト手順

Imagingのスケール・アウト手順では、構成済のWLS_CPTn管理対象サーバーを新しいノードに追加します。

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

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

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

   cd ORACLE_COMMON_HOME/oui/bin/
   
   ./attachHome.sh -jreLoc MW_HOME/jrockit_160_version
   

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

   
   

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

   
   

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

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します(まだ実行していない場合)。

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

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

   
   

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

   
   

   1. 新しい管理対象サーバー用に使用するホスト名またはIPアドレスを、その管理対象サーバーのリスニング・アドレスとして割り当てます。このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーの仮想IPアドレス(別称: 浮動IPアドレス)である必要があります。この仮想IPアドレスは、既存の管理対象サーバーとは別のものを使用してください。

      
      

      注意: ノードnでは仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスを有効化する方法の詳細は、第6.6項「仮想IPアドレスの有効化」を参照してください。

      
      

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

7. 新しい管理対象サーバーにCapture用のJMSサーバーを作成します。

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

      MSERVER_HOME/cluster_name/jms
      

   2. 新しいJMSサーバーを作成します(例: CaptureJmsServerN)。1つ前の手順で作成したCPTJMSServerNStore永続ストアをこのJMSサーバーに使用します。CaptureJmsServerNのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_CPTn)を指定します。

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

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateScaleCPT.jar 
   -template_name=edgdomain_templateScaleCPT
   

   参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

   
   

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

   
   

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

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

   
   

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

   
   

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

    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=MSERVER_HOME -template= edgdomaintemplateScaleCPT.jar -app_dir=APPLICATION_HOME
    

    
    

    注意: ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_CPTnサーバーにunpackコマンドを実行する場合は、unpackコマンドで-overwrite_domainオプションを指定する必要があります。

    
    

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

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

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

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

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

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

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

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

    CD WL_HOME/server/bin
    nohup ./startNodeManager.sh > nm.out&
    

    参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

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

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

    
    

    注意: すべてのCapture管理対象サーバーのホスト名が/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgファイルにあるSocketHostNameSecurityFilterパラメータ・リストに追加されていることを確認してください。

    
    

16. WebLogic Server管理コンソールを使用してすべてのOracle WebCenter Content管理対象サーバーを再起動します。

17. LBR上のアプリケーション(Captureコンソールの場合はhttps://wcc.example.com/dc-console、Captureクライアントの場合はhttps://wcc.example.com/dc-client)にアクセスして、WLS_CPTn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

    
    

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

    
    

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

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

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

    
    

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

    
    

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

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

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

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

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

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

       
       

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

       
       

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

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

    8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

       • まず、管理コンソールを使用して管理対象サーバーを停止します。

       • 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

       • 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

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

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

      ps -ef | grep WLS_CPTn
      

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

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

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

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

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

Imagingのスケール・アウト手順では、構成済のWLS_SOAn管理対象サーバーを新しいノードに追加します。

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

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

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

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

   cd ORACLE_COMMON_HOME/oui/bin/
   
   ./attachHome.sh -jreLoc MW_HOME/jrockit_160_version
   

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

   
   

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

   
   

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

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

   
   

   注意: ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_SOAnサーバーをスケール・アウトする場合は、unpackコマンドで-overwrite_domainオプションを指定する必要があります。

   
   

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

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

   
   

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

   
   

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

   このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーの仮想IPアドレス(別称: 浮動IPアドレス)である必要があります。この仮想IPアドレスは、既存の管理対象サーバーとは別のものを使用してください。

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

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateScaleSOA.jar 
   -template_name=edgdomain_templateScaleSOA
   

   
   

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

   
   

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

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

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

    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=MSERVER_HOME -template= edgdomaintemplateScaleSOA.jar 
    -app_dir=APPLICATION_HOME
    

    
    

    注意: ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_CPTnサーバーをスケール・アウトする場合は、unpackコマンドで-overwrite_domainオプションを指定する必要があります。

    
    

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

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

       /u01/oracle/config/domains/WCCDomain/SOA_Cluster/jms
       

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

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

       /u01/oracle/config/domains/WCCDomain/SOA_Cluster/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. 新しいサーバーのTx永続ストアを構成します。これは、共有記憶域に関する推奨事項で示されるとおり、他のノードから見える場所にする必要があります。(第4.4項「各種ディレクトリの推奨場所」を参照)。

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

    /u01/oracle/config/domains/WCCDomain/SOA_Cluster/tlogs
    

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

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

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

    cd WL_HOME/server/bin
    nohup ./startNodeManager.sh > nm.out& New_Node_IP
    

    参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

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

16. LBR上のアプリケーション(http://wccinternal.example.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. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

       • まず、管理コンソールを使用して管理対象サーバーを停止します。

       • 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

       • 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

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

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

      ps -ef | grep WLS_SOAn
      

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

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

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

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

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

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

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

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

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

19.8.1 前提条件および手順

次の前提条件があることに留意してください。

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

• 管理サーバーはWCCHOST1からWCCHOST2にフェイルオーバーされ、この2つのノードに次のIPアドレスがある。

  • WCCHOST1: 100.200.140.165

  • WCCHOST2: 100.200.140.205

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

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

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

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

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

2. IPアドレスを第2ノードに移行します。

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

      /sbin/ifconfig ethX:Y down
      

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

      /sbin/ifconfig interface:index IP_address netmask netmask
      

      例:

      /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
      

      
      

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

      
      

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

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

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

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

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

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

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

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

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

19.8.3 WCCHOST1への管理サーバーのフェイルバック

この手順により、管理サーバーをフェイルバックできることを確認します。すなわち、WCCHOST2では管理サーバーを停止し、WCCHOST1で再び管理サーバーを実行します。

ADMINVHNを元のWCCHOST1ノードに移行する手順は次のとおりです。

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

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

   /sbin/ifconfig ethZ:N down
   

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

   /sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
   

   
   

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

   
   

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

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

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

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

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

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

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

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

タイプ	ホスト	場所	層
Oracleホーム(DB)	WCCDBHOST1およびWCCDBHOST2	ユーザー定義	データ層
Middlewareホーム(OHS)	WEBHOST1およびWEBHOST2	/u02/oracle/products/fmw_home/web_home	Web層
Middlewareホーム(MW_HOME。これには、Oracle WebCenter ContentおよびOracle SOA SuiteのOracleホームが含まれています。)	WCCHOST1およびWCCHOST2*	/u01/oracle/products/fmw_home Oracle WebCenter ContentおよびOracle SOA SuiteのOracleホームもMW_HOMEにあります。	アプリケーション層
インストール関連ファイル		OraInventory、User_Home/bea/beahomelist、 oraInst.loc、oratab	N/A

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

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

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

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

19.10 Oracle DatabaseでのOPSSセキュリティ・ストアの保持

この項では、管理者がOracle Databaseのセキュリティ・ストアをメンテナンスする場合に実行する可能性のある一部のタスクについて説明します。

データベース・ベースのセキュリティ・ストアには、変更ログが保持されますが、このログは定期的にパージする必要があります。変更ログをパージするには、管理者が、提供されているSQLスクリプトopss_purge_changelog.sqlを使用して、24時間以上前の変更ログをパージするか、データベースに接続して、次の行で示すように、SQLのdeleteを(適切な引数を指定して)実行します。

SQL>delete from jps_changelog where createdate < (select(max(createdate) - 1) from jps_changelog);
SQL>Commit;

データベース・ベースのセキュリティ・ストアにアクセスする際に、OPSS管理APIの実行速度が遅い場合は、DBMS_STATSパッケージを実行して、DBの表、索引、クラスタの物理記憶域に関する統計情報を収集します。この情報はデータ・ディクショナリに格納され、分析対象のオブジェクトにアクセスするSQL文の実行計画を最適化する際に使用できます。

数千の新しいアプリケーション・ロールを作成する場合など、大量のデータをデータベース・ベースのセキュリティ・ストアにロードする場合は、短期間内にロード・アクティビティと同時にDBMS_STATSを実行することをお薦めします。それ以外で、ロード・アクティビティが小規模な場合は、DBMS_STATSを必要に応じて1回のみ実行する必要があります。

次のサンプルは、DBMS_STATSの使用例を示しています。

EXEC DBMS_STATS.GATHER_SCHEMA_STATS('WCC_OPSS', DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);

WCC_OPSSは、RCUの設定時(第5.4項「データベース・スキーマの作成」を参照)に作成されたDBスキーマの名前です。DBMS_STATSパッケージの詳細は、『Oracle Database管理者ガイド』を参照してください。

DBMS_STATSを定期的に実行するには、次に説明するように、シェル・スクリプトまたはSQLスクリプトを使用します。

次のサンプル・スクリプトは、コマンドDBMS_STATSを10分ごとに実行します。

#!/bin/sh
i=1
while [ $i -le 1000 ]
do
echo $i
sqlplus wcc_opss/welcome1@inst1 @opssstats.sql
sleep 600
i=`expr $i + 1`
done

opssstats.sqlには、次のテキストが含まれます。

EXEC DBMS_STATS.gather_schema_stats('WCC_OPSS',DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);
QUIT;

また次のサンプルSQLスクリプトも、コマンドDBMS_STATSを10分ごとに実行します。

variable jobno number;
BEGIN
DBMS_JOB.submit
(job => :jobno,
what => 'DBMS_STATS.gather_schema_stats(''WCC_OPSS'',DBMS_STATS.AUTO_SAMPLE_SIZE,no_invalidate=>FALSE);',
interval => 'SYSDATE+(10/24/60)');
COMMIT;
END;
/

前述のSQLスクリプトによるDBMS_STATSの定期的な起動を停止するには、最初に次のコマンドを発行してそのジョブ番号を見つけます。

sqlplus '/as sysdba'
SELECT job FROM dba_jobs WHERE schema_user = 'WCC_OPSS' AND what = 'DBMS_STATS.gather_schema_stats(''WCC_OPSS'',DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);';

続いて、次のようなコマンドを発行します。このコマンドでは、前述の問合せがジョブ番号31を返すと仮定しています。

EXEC DBMS_JOB.remove(31);

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

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

19.12 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 Fusion Middleware Oracle WebCenter Content: Imagingの開発』および『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』の手順に従います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19.13.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アプリケーションを起動してください。

19.13.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
   

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

問題: WebCenter Contentサーバー、Oracle SOA SuiteサーバーまたはImagingサーバーの起動に失敗します。新しい管理対象サーバー・タイプ用にドメインが拡張されている(たとえば、Imaging用にWebCenter Contentを拡張)か、システムがスケール・アップ(同じタイプの新しいサーバーを追加)されています。WebCenter Contentサーバー、Oracle SOA Suiteサーバーまたは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管理者ガイドを参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19.13.8 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を削除します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. テキスト・エディタでファイル/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgを開きます。

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

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

3. WLS_CPT1およびWLS_CPT2管理対象サーバー(それぞれWCCHOST1VHN3およびWCCHOST2VHN3)の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_CPT1とWLS_CPT2のリスニング・アドレスです。(同様に、アドレス127.0.0.1がこのリストに含まれている必要があります。)

4. 変更されたconfig.cfgファイルを保存しら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

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

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

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

Java VMに割り当てられているメモリー・ヒープのサイズを増やす手順は次のとおりです。

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

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

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

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

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

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

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

   
   

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

   
   

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

8. WebLogic Server管理コンソールを使用して、実行中のすべての管理対象サーバーを再起動します。

19.13.15 Oracle WebCenter Content管理対象サーバーのマスター・パスワードを再生成する

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

Oracle WebCenter Content管理対象サーバーのマスター・パスワードを再生成する手順は次のとおりです。

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

2. MSERVER_HOME/config/fmwconfig/からcwallet.ssoファイルを削除します。

3. ASERVER_HOME/wcc_cluster_name/cs/config/privateからpassword.hdaファイルを削除します。

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

5. MSERVER_HOME/config/fmwconfig/にあるcwallet.ssoファイルの作成または更新、およびASERVER_HOME/wcc_cluster_name/cs/config/private/にあるpassword.hdaファイルの作成を確認します。

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

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

8. MSERVER_HOME/config/fmwconfigディレクトリからASERVER_HOME/config/fmwconfigにある管理サーバーのドメイン・ディレクトリにcwallet.ssoファイルをコピーします。

9. 2番目のOracle WebCenter Content管理対象サーバーを起動し、更新されたcwallet.ssoファイルを、管理サーバーがWCCHOST2にあるMSERVER_HOME/config/fmwconfigディレクトリにプッシュし、そのファイルがWCCHOST1上のOracle WebCenter Content Serverによって作成または更新されたものと同じファイルであることを検証します。

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

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

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

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

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

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

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構成は正しく動作します。特定の操作に想定されるトランザクション時間に合せて、これらの値を調整します。

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

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

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

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

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

./servers/AdminServer/upload

./servers/server_name/stage