12 Oracle WebCenter Contentを追加するためのドメインの拡張

Oracle WebCenter Contentソフトウェアを含めてエンタープライズ・デプロイメント・ドメインを拡張するために、特定のタスクを実行する必要があります。これには、WebCenter Contentのインストール、WebCenter Contentを追加するためのドメインの拡張、および構成後のタスクや検証タスクの実行があります。

この章では、WebCenter Contentのインストール、WebCenter Contentを追加するためのドメインの拡張、および構成後のタスクや検証タスクの実行について説明します。

• Oracle WebCenter Contentでの動的クラスタのサポート
  Oracle WebCenter Contentは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。
• エンタープライズ・デプロイメントでのWebCenter Contentのインストール
  この項では、エンタープライズ・デプロイメントにWebCenter Contentをインストールする手順を説明します。
• Oracle WebCenter Contentデータベース・スキーマの作成
  Oracle WebCenter Contentドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。
• WebCenter Contentを使用するためのドメインの拡張
  Oracle WebCenter Contentソフトウェアを含めて既存のエンタープライズ・デプロイメント・ドメインを拡張するために、特定のタスクを実行する必要があります。
• WebCenter Contentの構成後および検証タスクの実行
  コンテンツ・サーバーをオンラインにするには、いくつかの構成および検証ステップを実行する必要があります。以下の項をリストされている順序で実行します。
• WebCenter Contentクラスタ用のOracle HTTP Serverの構成
  この項では、WebCenter Contentクラスタ用にOracle HTTP Serverを構成する手順を説明します。
• WebCenter Portal用のOracle WebCenter Contentの構成
  この項では、WebCenter Portalで使用するOracle WebCenter Content Serverを構成するための必須タスクについて説明します。
• JDBC永続ストアの有効化
  Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。
• 自動サービス移行の有効化
  この章でインストールした製品の高可用性を実現するには、適切にサービス移行を構成する必要があります。
• 構成のバックアップ
  ベスト・プラクティスとして、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。ここまでのインストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。

Oracle WebCenter Contentでの動的クラスタのサポート

Oracle WebCenter Contentは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。

静的クラスタは、構成済クラスタとも言い、各サーバー・インスタンスを手動で構成して追加する従来型のクラスタです。動的クラスタには、新しい"server-template"オブジェクトが含まれています。このオブジェクトは、すべての生成された(動的)サーバー・インスタンスの一元的な構成を定義するために使用します。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。この機能により、追加のサーバー容量が必要になったときに、動的クラスタ内のサーバー・インスタンスの数をスケール・アップできます。動的サーバーは、最初に手動で構成してそれをクラスタに追加する必要はなく、単に起動するだけで使用できます。

この項に示すステップには、静的トポロジまたは動的トポロジの両方に対応するドメインの構成ステップが含まれています。この2種類の構成の相違点は次のとおりです。

• 構成ウィザードのプロセスは、それぞれのケースに応じて異なることがあります。たとえば、サーバーではなく動的クラスタ用のサーバー・テンプレートの定義が必要になります。

• 動的クラスタの場合は、サーバー固有の構成(リスニング・アドレスの設定、アップロードとステージングのディレクトリの構成、キーストアの構成など)をサーバーではなくサーバー・テンプレートで実行する必要があります。

• 動的クラスタの場合は、サービス移行が異なる方法で構成されます。動的クラスタは移行可能ターゲットを使用しないかわりに、JMSリソースがクラスタをターゲットにします。動的クラスタのサービス移行を構成する際の具体的な手順は、このガイドに記載されています。

複合クラスタ(動的サーバー・インスタンスと構成済サーバー・インスタンスの両方を含むクラスタ)は、Oracle WebCenter Portalエンタープライズ・デプロイメントではサポートされていません。

エンタープライズ・デプロイメントでのWebCenter Contentのインストール

この項では、エンタープライズ・デプロイメントにWebCenter Contentをインストールする手順を説明します。

この項では次の手順について説明します。

• WCCHOST1でのOracle WebCenter Contentインストーラの起動
  
• インストール画面への移動
  
• 他のホスト・コンピュータでのOracle WebCenter Contentのインストール
  
• インストールの検証
  

WCCHOST1でのOracle WebCenter Contentインストーラの起動

インストール・プログラムを起動する手順は次のとおりです。

1. WCCHOST1にログインします。
2. インストール・プログラムがダウンロードされたディレクトリに移動します。
3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

   JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.3.0_wccontent.jar

   これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

   ソフトウェアをダウンロードして製品の実際のインストーラ・ファイル名を見つける方法の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。

インストール画面への移動

インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面	説明
「インストール・インベントリ」画面	Oracle Fusion Middleware Infrastructureソフトウェアをインストールしたときに中央インベントリを作成しなかった場合に、このダイアログ・ボックスが表示されます。 ローカル・インベントリの場所を指すように「インベントリ・ディレクトリ」フィールドを編集して、「OK」をクリックします。
ようこそ	製品のインストーラの紹介画面です。
自動更新	この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索するか、組織のためにすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。
インストール場所	この画面を使用してOracleホーム・ディレクトリの位置を指定します。 Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。
前提条件のチェック	この画面では、ご使用のシステムが最小要件を満たしていることを検証します。 警告メッセージまたはエラー・メッセージが表示された場合は、Oracle Fusion Middleware Infrastructureのインストール計画のシステム環境の検証ロードマップに関する項でいずれかのドキュメントを参照してください。
インストール・サマリー	この画面を使用して、選択したインストール・オプションを確認します。 「インストール」をクリックしてインストールを開始します。
インストールの進行状況	この画面では、インストールの進行状況を参照できます。 進捗バーが100%完了になった後で、「次へ」をクリックします。
インストール完了	この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

他のホスト・コンピュータでのOracle WebCenter Contentのインストール

EDG共有記憶域の推奨事項に従った場合、製品インストール用の別の共有記憶域ボリュームがWCCHOST2上にあり、WCCHOST2上にソフトウェアをインストールする必要もあります。「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

インストールの検証

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

• インストール・ログ・ファイルの確認
  
• ディレクトリ構造のチェック
  
• Oracleホームの内容の表示
  

インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルとその場所の詳細は、『Oracle Universal Installerによるソフトウェアのインストール』のインストール・ログ・ファイルの理解に関する項を参照してください。

ディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

Oracle WebCenter Contentを追加すると、次のディレクトリおよびサブディレクトリが追加されます。

/u01/oracle/products/fmw/wccontent
axf
common
ipm
plugins
ucm
wccadf
wccadfrui

/u01/oracle/products/fmw/wccapture
capture
common
plugins

インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。

Oracleホームの内容の表示

viewInventoryスクリプトを使用して、Oracleホームの内容を表示することもできます。『Oracle Universal Installerによるソフトウェアのインストール』のOracleホームの内容の表示に関する項を参照してください。

Oracle WebCenter Contentデータベース・スキーマの作成

Oracle WebCenter Contentドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

この項で説明する手順を実行して、スキーマをインストールします。

• リポジトリ作成ユーティリティ(RCU)の起動
  
• スキーマ作成のためのRCU画面のナビゲート
  

リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。
2. 対象のシステムで、JAVA_HOME環境変数が、動作保証されたJDKの場所に設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

   UNIXオペレーティング・システムの場合:

   export JAVA_HOME=/u01/oracle/products/jdk

3. RCUを起動します。

   UNIXオペレーティング・システムの場合:

   ./rcu

   注意:

   データベースで透過的データ暗号化(TDE)が有効化されている場合に、RCUによって作成される表領域を暗号化するには、RCUの起動時に-encryptTablespace trueオプションを指定します。

   これによって、RCUの実行中に追加の操作をすることなく、「表領域のマップ」画面で適切なRCU GUI「表領域の暗号化」チェック・ボックスが選択されるようにデフォルト指定されます。『リポジトリ作成ユーティリティによるスキーマの作成』の表領域の暗号化に関する項を参照してください。

スキーマ作成のためのRCU画面のナビゲート

RCUを起動した後で、ウィザードの画面を使用して、Oracle Fusion Middleware製品で必要なスキーマを選択してインストールできます。スキーマ作成に必要なタスクは、次のとおりです。

タスク1   RCUの導入

「次」をクリックします。

タスク2   スキーマ作成の方法の選択

対象のデータベースに対するDBAアクティビティの実行に必要なパーミッションと権限が付与されている場合は、「システム・ロードおよび製品ロード」を選択します。この手順は、必要な権限が付与されていることを前提としています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。これによってSQLスクリプトが生成され、これをデータベース管理者が利用できます。リポジトリ作成ユーティリティを使用したスキーマの作成のシステム・ロードおよび製品ロードの理解に関する項を参照してください。

タスク3   データベース接続の詳細の指定

RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。

「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

「DBMS/サービス」詳細を入力します。

「スキーマ所有者」および「スキーマ・パスワード」詳細を入力します。

「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

タスク4   カスタム接頭辞の指定とスキーマの選択

既存の接頭辞を選択し、初期ドメインを構成したときに使用した接頭辞を選択します。

スキーマのリストから、「WebCenter Content」スキーマ・セクションを開き、「Oracle WebCenter Content Server - 完全」スキーマのみを選択します。

カスタム接頭辞は、これらのスキーマを論理的にグループ化して、このドメイン内でのみ使用することを目的としています。複数のドメイン間でのスキーマの共有はサポートされていないため、ドメインごとに固有のスキーマのセットを作成する必要があります。

ヒント:

カスタム接頭辞の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のカスタム接頭辞の理解に関する項を参照してください。

マルチドメイン環境でスキーマを編成する方法の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のスキーマ作成の計画に関する項を参照してください。

ヒント:

ここに入力するカスタム接頭辞は、メモしておく必要があります。このカスタム接頭辞は、後述するドメイン作成のプロセスで必要になります。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6   必須スキーマの表領域の検証

「表領域のマップ」画面で情報を確認し、「次へ」をクリックして、デフォルト値を受け入れます。

確認ダイアログ・ボックスで「OK」をクリックします。

タスク7   スキーマ作成の完了

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

タスク8   スキーマの作成の検証

スキーマが正常に作成されたことと、データベース接続詳細を確認するためには、SQL*Plusまたは別のユーティリティで、OCSスキーマ名および指定したパスワードを使用してデータベースに接続します。

次に例を示します。

./sqlplus  

SQL*Plus: Release 12.1.0.1.0 Production on Wed Aug 31 05:41:31 2016 
 
Copyright (c) 1982, 2013, Oracle. All rights reserved.  

Enter user-name: FMW1221_OCS 
Enter password: schema_password  

Connected to: Oracle Database 11g Enterprise Edition Release 12.1.0.1.0 - 64bit Production 
With the Partitioning, OLAP, Data Mining and Real Application Testing options  

SQL>

WebCenter Contentを使用するためのドメインの拡張

Oracle WebCenter Contentソフトウェアを含めて既存のエンタープライズ・デプロイメント・ドメインを拡張するために、特定のタスクを実行する必要があります。

ドメインの拡張には、次のタスクが含まれます。

• 構成ウィザードの起動
  既存のエンタープライズ・デプロイメント・ドメインを拡張するための最初のステップとして構成ウィザードを起動します。
• WebCenter Contentを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート
  

構成ウィザードの起動

既存のエンタープライズ・デプロイメント・ドメインを拡張するための最初のステップとして構成ウィザードを起動します。

注意:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverridesLate.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のJavaコマンド行オプションの指定、追加の環境変数の指定などを実施するように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。

このエンタープライズ・デプロイメント・ガイドでのsetUserOverridesLateスクリプトの使用の詳細は、「setUserOverridesLateスクリプトを使用したサーバー・パラメータのカスタマイズ」を参照してください。

構成ウィザードを起動する手順は次のとおりです。

1. WebLogic Serverコンソールで、このドメイン拡張によって変更するすべての管理対象サーバーを停止します。影響を受けない管理対象サーバーはオンラインのままです。
2. 変更するすべての管理対象サーバーについて、管理対象サーバーのシャットダウンが完了していることを確認します。
3. すべての管理対象サーバーが安定した状態になったら、管理サーバーを停止します。
4. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

   cd ORACLE_HOME/oracle_common/common/bin
   ./config.sh

WebCenter Contentを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

次の各項に示す手順に従って、静的または動的クラスタを含むトポロジのドメインを拡張します。

• 静的クラスタを含めるドメインの拡張
  
• 動的クラスタを含めるドメインの拡張
  

静的クラスタを含めるドメインの拡張

この項に示す手順に従って、静的クラスタを含めてトポロジのドメインを拡張します。

注意:

この項で説明する手順を使用して、静的クラスタを含めて既存のドメインを拡張できます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを拡張して構成するためのタスクは次のとおりです。

• タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

• タスク2「構成テンプレートの選択」

• タスク3「高可用性オプションの構成」

• タスク4「データベース構成タイプの指定」

• タスク5「JDBCコンポーネント・スキーマ情報の指定」

• タスク6「GridLink Oracle RACデータベース接続の詳細情報の指定」

• タスク7「JDBC接続のテスト」

• タスク8「拡張構成の選択」

• タスク9「管理対象サーバーの構成」

• タスク10「クラスタの構成」

• タスク11「サーバー・テンプレートの割当て」

• タスク12「動的サーバーの構成」

• タスク13「クラスタへの管理対象サーバーの割当て」

• タスク14「Coherenceクラスタの構成」

• タスク15「WebCenter Content Serverのマシンを作成」

• タスク16「マシンへのサーバーの割当て」

• タスク17「仮想ターゲットの構成」

• タスク18「パーティションの構成」

• タスク19「ファイル・ストアの構成」

• タスク20「構成の仕様の確認とドメインの構成」

• タスク21「ドメイン・ホームと管理サーバーURLのメモ」

• タスク22「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、初期ドメインの一部として作成した管理ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

• Oracle Universal Content Management - Content Server - 12.2.1.3.0[wccontent]

  また、初期インフラストラクチャ・ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

  • Oracle Enterprise Manager - 12.2.1.3.0[em]

  • Oracle JRF - 12.2.1.3.0[oracle_common]

  • WebLogic Coherenceクラスタの拡張 - 12.2.1.3.0 [wlserver]

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「テンプレート」に関する項を参照してください。

タスク3   高可用性オプションの構成

この画面は、自動サービス移行またはJDBCストアあるいはその両方を使用するクラスタを初めて作成するときに表示されます。クラスタに対してHAオプションを選択した後、構成ウィザードを使用してドメインに追加される後続のすべてのクラスタで、HAオプションが自動的に適用されます(つまり、構成ウィザードにより、JDBCストアが作成され、これらに対してASMが構成されます)。

「高可用性のオプション」画面で、次を実行します。

• 「データベース・ベース」を使用して「自動サービス移行の有効化」を選択します。

• 「JTAトランザクション・ログ永続性」を「JDBC TLogストア」に設定します。

• 「JMSサーバー永続性」を「JMS JDBCストア」に設定します。

注意:

Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。このため、構成ウィザードのステップでは、JDBC永続ストアが自動サービス移行とともに使用されていることを前提としています。

JDBC永続ストアを選択すると、余分な未使用のファイル・ストアが自動的に作成されますが、クラスタをターゲットとしたものではありません。こうしたファイル・ストアは無視してください。

なんらかの理由でファイル・ストアを使用する場合、この画面ではTLOGおよびJMS永続ストアのオプションをデフォルト値のままにしておき、後から共有の場所で構成することができます。タスク8「詳細構成の選択」を参照してください。フェイルオーバー・シナリオでJMSおよびHAを再開するには、共有の場所が必要です。

事後ステップでTLOGおよびJMS永続ストアを手動で構成することもできます。JDBCとファイル・ストアの間の差異の詳細、およびこれらの手動構成の特定の手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」を参照してください。

「次」をクリックします。

タスク4   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。

すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。操作に成功すると、「接続結果ログ」に次の出力が示されます。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。

タスク5   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、表のすべてのUCMスキーマを選択します(WebCenter Content用)。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク6   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素	説明と推奨値
「SCAN」、「ホスト名」および「ポート」	「SCAN」チェック・ボックスを選択します。 「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。 「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)
「ONSホスト」と「ポート」	「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。 「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。
FANの有効化	「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。

タスク7   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテストに関する項を参照してください。

タスク8   拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

• トポロジ

• ファイル・ストア

タスク9   管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストにOracle WebCenter Content用の新しい管理対象サーバーが表示されます。

次のタスクを実行して、デフォルトのOracle WebCenter Content管理対象サーバーを変更して2つ目の管理対象サーバーを作成します。

1. デフォルトの管理対象サーバーの名前をWLS_WCC1に変更します。

2. 「追加」をクリックして新しい管理対象サーバーを作成し、そのサーバーにWLS_WCC2と名前を付けます。

   ヒント:

   ここで推奨するサーバー名は、このドキュメント全体で使用します。別の名前を選択する場合は、必要に応じてそれらの名前に置き換えてください。

3. 次の表の情報を使用して、各Oracle WebCenter Content管理対象サーバーの残りの列を入力します。

サーバー名	リスニング・アドレス	リスニング・ポート	SSLの有効化	SSLリスニング・ポート	サーバー・グループ
WLS_WCC1	WCCHOST1	16200	選択解除	無効	UCM-MGD-SVR
WLS_WCC2	WCCHOST2	16200	選択解除	無効	UCM-MGD-SVR

ヒント:

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

タスク10   クラスタの構成

このタスクでは、Oracle WebCenter Contentソフトウェアのターゲットにすることができる管理対象サーバーのクラスタを作成します。

「クラスタ」画面を使用して、新しいクラスタを作成します。

1. 「追加」ボタンをクリックします。

2. 「クラスタ名」フィールドでWCC_Clusterを指定します。

3. 「動的サーバー・グループ」ドロップダウン・リストで、「未指定」を選択します。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「クラスタ」に関する項を参照してください。

タスク11   サーバー・テンプレートの割当て

「次へ」をクリックして次の画面に進みます。

タスク12   動的サーバーの構成

静的クラスタとして残そうとするクラスタに対して、動的サーバーのすべてのオプションが無効になっていることを確認します。

1. この画面の「動的クラスタ」、「計算済リスニング・ポート」および「計算済マシン名」チェック・ボックスの選択が解除されていることを確認します。

2. 「サーバー・テンプレート」で「未指定」が選択されていることを確認します。

3. 「次」をクリックします。

タスク13   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、WLS_WCC1およびWLS_WCC2を新規クラスタWCC_Clusterに割り当てます。

1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではWCC_Cluster)を選択します。

2. 「サーバー」ペインで、次のいずれかの操作を実行して、WLS_WCC1をWCC_Clusterに割り当てます。

   • WLS_WCC1管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。

   • WLS_WCC1をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。

3. 同じ手順を繰り返して、WLS_WCC2をWCC_Clusterに割り当てます。

4. 「次へ」をクリックして次の画面に進みます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

タスク14   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号の値を9991に更新します。

注意:

Coherenceライセンス情報については、Oracle Fusion Middlewareライセンス情報のOracle Coherenceに関する項を参照してください。

タスク15   WebCenter Content Serverのマシンを作成

必要に応じて、「マシン」画面を使用して2つの新しいUnixマシンを追加します。

1. 「Unixマシン」タブで、「追加」ボタンをクリックします。

2. 「名前」フィールドにWCCHOST1と入力します。

3. ノード・マネージャ・リスナー・アドレスにホスト名WCCHOST1を入力します。ノード・マネージャ・ポートはデフォルト値の5556にしておきます。

4. このステップをWCCHOST2に対して繰り返します。

「Unixマシン」タブで、初期インフラストラクチャ・ドメインの作成時に作成したマシンの名前を確認します(次の表を参照)。

「次へ」をクリックします。

名前	ノード・マネージャのリスニング・アドレス	ノード・マネージャのリスニング・ポート
WCCHOST1	WCCHOST1ホスト名変数の値。たとえば、WCCHOST1.example.comです。	5556
WCCHOST2	WCCHOST2ホスト名変数の値。たとえば、WCCHOST2.example.comです。	5556

タスク16   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle WebCenter Content管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。クラスタに管理対象サーバーを割り当てるときと同様のプロセスを使用します。タスク13「クラスタへの管理対象サーバーの割当て」を参照してください。

WLS_WCC1をWCCHOST1、WLS_WCC2をWCCHOST2に割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

タスク17   仮想ターゲットの構成

「次へ」をクリックして次の画面に進みます。

タスク18   パーティションの構成

「次へ」をクリックして次の画面に進みます。

タスク19   ファイル・ストアの構成

「ファイル・ストア」画面で、コンテンツ・サーバーJMSファイル・ストアを含む各WebCenter Content永続ストアに次のディレクトリを割り当てます。

ORACLE_RUNTIME/domain_name/WCC_Cluster/jms

注意:

管理対象サーバーを起動する前にjmsフォルダを作成します。

この例では、ORACLE_RUNTIMEをご使用の環境の変数値に置き換えます。WCC_Clusterを、WebCenter Contentクラスタに割り当てた名前に置き換えます。

「同期書込みポリシー」のドロップダウン・リストで「直接書込み」を選択します(両方のストア)。

タスク20   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックして、ドメインの拡張を実行します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク21   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

• ドメインの場所

• 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、ノード・マネージャと管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク22   管理サーバーの起動

管理サーバーを起動してログインし、クラスタ・ビューとサーバー・ビューを確認して、ドメインに対する変更が適用されていることを確認します。

静的クラスタを含めるドメインの拡張を完了したら、「WebCenter Content用の構成後タスクおよび検証タスクの実行」に進みます。

動的クラスタを含めるドメインの拡張

この項に示す手順に従って、動的クラスタを含めてトポロジのドメインを拡張します。

注意:

この手順では、既存のドメインを拡張することを想定しています。手順に示された内容と要件があわないときは、適切な内容を選択していることを確認するか、その他の詳細について説明されているドキュメントを参照してください。

ドメインを拡張して構成するためのタスクは次のとおりです。

• タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

• タスク2「構成テンプレートの選択」

• タスク3「高可用性オプションの構成」

• タスク4「データベース構成タイプの指定」

• タスク5「JDBCコンポーネント・スキーマ情報の指定」

• タスク6「GridLink Oracle RACデータベース接続の詳細情報の指定」

• タスク7「JDBC接続のテスト」

• タスク8「拡張構成の選択」

• タスク9「管理対象サーバーの構成」

• タスク10「クラスタの構成」

• タスク11「サーバー・テンプレートの割当て」

• タスク12「動的サーバーの構成」

• タスク13「Coherenceクラスタの構成」

• タスク14「WebCenter Content Serverのマシンを作成」

• タスク15「マシンへのサーバーの割当て」

• タスク16「仮想ターゲットの構成」

• タスク17「パーティションの構成」

• タスク18「構成の仕様の確認とドメインの構成」

• タスク19「ドメイン・ホームと管理サーバーURLのメモ」

• タスク20「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、初期ドメインの一部として作成した管理ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

• Oracle Universal Content Management - Content Server - 12.2.1.3.0[wccontent]

  また、初期インフラストラクチャ・ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

  • Oracle Enterprise Manager - 12.2.1.3.0[em]

  • Oracle JRF - 12.2.1.3.0[oracle_common]

  • WebLogic Coherenceクラスタの拡張 - 12.2.1.3.0 [wlserver]

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「テンプレート」に関する項を参照してください。

タスク3   高可用性オプションの構成

この画面は、自動サービス移行またはJDBCストアあるいはその両方を使用するクラスタを初めて作成するときに表示されます。クラスタに対してHAオプションを選択した後、構成ウィザードを使用してドメインに追加される後続のすべてのクラスタで、これらのHAオプションが自動的に適用されます。

「高可用性のオプション」画面で、次のステップを実行します。

1. 「自動サービス移行の有効化」が選択されていないことを確認します。

2. 「JTAトランザクション・ログ永続性」オプションとして「デフォルトの永続ストア」が選択されていることを確認します。

3. JMSサービス永続性オプションとして「JDBCストア」を選択します。

構成ウィザードを使用して動的クラスタ用に構成できるのはJMSサーバー永続性のみです。構成ウィザードを使用して、動的クラスタのサービス移行とJTAトランザクション・ログ永続性を構成することはできません。手動で構成する必要があります。手順は、このガイドのこれ以降の章で説明します。

注意:

Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。このため、構成ウィザードのステップでは、JDBC永続ストアが自動サービス移行とともに使用されていることを前提としています。

JDBC永続ストアを選択すると、余分な未使用のファイル・ストアが自動的に作成されますが、クラスタをターゲットとしたものではありません。こうしたファイル・ストアは無視してください。

なんらかの理由でファイル・ストアを使用する場合、この画面ではTLOGおよびJMS永続ストアのオプションをデフォルト値のままにしておき、後から共有の場所で構成することができます。タスク8「詳細構成の選択」を参照してください。フェイルオーバー・シナリオでJMSおよびHAを再開するには、共有の場所が必要です。

事後ステップでTLOGおよびJMS永続ストアを手動で構成することもできます。JDBCとファイル・ストアの間の差異の詳細、およびこれらの手動構成の特定の手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」を参照してください。

「次」をクリックします。

タスク4   データベース構成タイプの指定

1. 「データベース構成タイプ」画面で、「RCUデータ」を選択します。

   Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。

2. すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

3. 「接続パラメータ」を選択します。

4. データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。操作に成功すると、「接続結果ログ」に次の出力が示されます。

   Connecting to the database server...OK 
   Retrieving schema data from database server...OK 
   Binding local schema components with retrieved data...OK  
   
   Successfully Done

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。

タスク5   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、表のすべてのUCMスキーマを選択します(WebCenter Content用)。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク6   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素	説明と推奨値
「SCAN」、「ホスト名」および「ポート」	「SCAN」チェック・ボックスを選択します。 「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。 「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)
「ONSホスト」と「ポート」	「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。 「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。
FANの有効化	「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。

タスク7   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテストに関する項を参照してください。

タスク8   拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

• トポロジ

注意:

JMS JDBCストアを使用することをお薦めしますが、これは、タスク3「高可用性オプションの構成」で選択されているため、ファイル・ストアを構成する必要はありません。

タスク3「高可用性オプションの構成」で「JMSファイル・ストア」を選択した場合は、ファイル・ストアのオプションを選択して、ORACLE_RUNTIME/domain_name/SOA_Cluster/jmsの共有の場所で構成する必要があります。フェイルオーバー・シナリオでJMSおよびHAを再開するには、共有の場所が必要です。

タスク9   管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストにOracle WebCenter Content用の新しい管理対象サーバーが表示されます。

動的クラスタ構成に静的管理対象サーバー定義は必要ありません。デフォルトの管理対象サーバーを削除するには、次のステップを実行します。

1. デフォルトの管理対象サーバーを削除します。

2. 「次へ」をクリックして次の画面に進みます。

タスク10   クラスタの構成

このタスクでは、Oracle WebCenter Contentソフトウェアのターゲットにすることができる管理対象サーバーのクラスタを作成します。

「クラスタ」画面を使用して、新しいクラスタを作成します。

1. 「追加」ボタンをクリックします。

2. 「クラスタ名」フィールドでWCC_Clusterを指定します。

3. 「クラスタ・アドレス」フィールドは空白のままにします。

4. 「動的サーバー・グループ」ドロップダウン・リストで、「UCM-DYN-CLUSTER」を選択します。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストまたはマルチキャストを選択する際の考慮事項に関する項を参照してください。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「クラスタ」に関する項を参照してください。

タスク11   サーバー・テンプレートの割当て

「サーバー・テンプレート」画面で、次のUCMサーバー・テンプレート構成を検証および更新し、必要に応じてテンプレートを追加します。

UCMサーバー・テンプレートで、次のステップを完了します。

1. 「名前」フィールドでUCM-server-templateがリストされていることを確認します。

2. 「リスニング・ポート」フィールドで、16200を指定します。

3. 「SSLの有効化」オプションは未選択のままにしておきます。

4. 「次へ」をクリックして次の画面に進みます。

タスク12   動的サーバーの構成

「動的クラスタ」画面を使用して、必要なクラスタを構成します。

1. クラスタ名値がWCC_Clusterである行を探します。

2. 「サーバー名の接頭辞」フィールドにWLS_WCCがリストされていることを確認します。

3. 「サーバー・テンプレート」ドロップダウン・リストで、「UCM-server-template」を選択します。

4. 「最大動的サーバー数」フィールドで、2を指定します。

5. 「マシン名マッチング式」フィールドで、WCCHOST*を指定し、「計算済マシン名」を選択します。

   注意:

   動的クラスタの「計算済マシン名」および「マシン名マッチング式」属性は、動的クラスタ内のサーバー・インスタンスをマシンに割り当てる方法を制御します。

   • 「計算済マシン名」属性がFalseに設定されている場合、動的サーバーはマシンに割り当てられません。

   • 「計算済マシン名」属性が Trueに設定されている場合、「マシン名マッチング式」属性が使用され、動的サーバーに使用されるマシンのセットが選択されます。

   • 「マシン名マッチング式」属性が設定されていない場合、ドメイン内のすべてのマシンが選択されます。割当は、ラウンド・ロビン・アルゴリズムを使用して行われます。

   実際の物理的なホスト名とは関係なく作業をより簡単にするために、WebLogicマシン名としてWCCHOSTn (nは連続番号です)を使用することをお薦めします。これについては、インフラストラクチャ・ドメインの構成に関するタスク14「WebCenter Content Serverのマシンを作成」で説明しています。この規則により、動的クラスタが各クラスタ・メンバーをどこから起動するかを決定しやすくなります。この規則に従う場合、「マシン・マッチング式」フィールドでWCCHOST*を入力します。

   この規則を採用しない場合、クラスタ・メンバーは、タスク14「WebCenter Content Serverのマシンを作成」で定義する各マシン上で起動されます。これには、ADMINHOSTも含まれます。この状況は、2つのクラスタ・メンバーが同じ物理サーバー上で動作するが2つの異なるドメイン・ホームにアタッチされる結果となるため、望ましくありません。

6. 「計算済リスニング・ポート」および「動的クラスタ」フィールドを選択します。

7. 「次へ」をクリックして次の画面に進みます。

タスク13   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号の値を9991に更新します。

注意:

Coherenceライセンス情報については、Oracle Fusion Middlewareライセンス情報のOracle Coherenceに関する項を参照してください。

タスク14   WebCenter Content Serverのマシンを作成

「Unixマシン」タブで、初期インフラストラクチャ・ドメインの作成時に作成したマシンの名前を確認します(次の表を参照)。

表12-1 Unixマシンの作成時に使用する値

名前	ノード・マネージャのリスニング・アドレス	ノード・マネージャのリスニング・ポート
ADMINHOST	ADMINVHN変数の値を入力します。	5556
WCCHOST1	WCCHOST1ホスト名変数の値。たとえば、WCCHOST1.example.comなどです。	5556
WCCHOST2	WCCHOST2ホスト名変数の値。たとえば、WCCHOST2.example.comなどです。	5556
WCPHOST1	WCPHOST1ホスト名変数の値。たとえば、WCPHOST1.example.comとなります。	5556
WCPHOST2	WCPHOST2ホスト名変数の値。たとえば、WCPHOST2.example.comとなります。	5556

必要に応じて、「マシン」画面を使用して2つの新しいUnixマシンを追加します。

1. 「Unixマシン」タブで、「追加」ボタンをクリックします。

2. 「名前」フィールドにWCCHOST1と入力します。

3. ノード・マネージャ・リスナー・アドレスにホスト名WCCHOST1を入力します。ノード・マネージャ・ポートはデフォルト値の5556にしておきます。

4. このステップをWCCHOST2に対して繰り返します。

5. 「次へ」をクリックします。

タスク15   マシンへのサーバーの割当て

「次へ」をクリックして次の画面に進みます。

タスク16   仮想ターゲットの構成

「次へ」をクリックして次の画面に進みます。

タスク17   パーティションの構成

「次へ」をクリックして次の画面に進みます。

タスク18   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックして、ドメインの拡張を実行します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク19   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

• ドメインの場所

• 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、ノード・マネージャと管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク20   管理サーバーの起動

管理サーバーを起動してログインし、クラスタ・ビューとサーバー・ビューを確認して、ドメインに対する変更が適用されていることを確認します。

WebCenter Content用の構成後タスクおよび検証タスクの実行

コンテンツ・サーバーをオンラインにするには、いくつかの構成および検証ステップを実行する必要があります。以下の項をリストされている順序で実行します。

• ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
  起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。
• ドメイン解凍後のNodeManager構成の更新
  ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。
• 既存の管理対象サーバーの再起動と検証
  
• uploadおよびstageディレクトリの絶対パスへの変更
  ドメインを構成し、すべてのホスト上の管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタの管理対象サーバーに対してuploadディレクトリとstageディレクトリを検証および更新します。 動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。
• 動的クラスタの使用時のリスニング・アドレスの構成
  
• WLS_WCC1管理対象サーバーの起動
  
• WLS_WCC1管理対象サーバー上のコンテンツ・サーバーの構成
  
• 管理サーバーのcwalletファイルの更新
  
• 管理対象サーバーWLS_WCC2の起動
  
• WLS_WCC2管理対象サーバー上のコンテンツ・サーバーの構成
  
• GridLinkデータ・ソースの検証
  
• その他のパラメータの構成
  
• Oracle WebCenter Contentのサービス再試行の構成
  
• 資格証明マップ経由のWebCenter Content管理ロールの付与
  

ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

WebCenter Content管理対象サーバーにドメイン構成を伝播するには次のステップを実行します。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのコピーを作成します。
2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true 
             -domain=ASERVER_HOME 
             -template=/full_path/edgdomaintemplateExtWCC.jar 
             -template_name=edgdomain_templateExtWCC

   この例では、次のようになります。

   • ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

   • full_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。ORACLE_HOME以外の共有ボリュームを選択するか、/tmp/に書き込み、そのファイルをサーバー間で手動でコピーすることをお薦めします。

     テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。

     SHARED_CONFIG_DIR/domains/template_filename.jar

   • edgdomaintemplateExtWCC.jarは、作成するJARファイルのサンプル名です。これには、Oracle HTTP Serverインスタンスの構成ファイルなどのドメイン構成ファイルが含まれます。

   • edgdomain_templateExtWCCは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

3. 次のunpackコマンドをWCCHOST1で実行して、前のステップで作成したテンプレートをMSERVER_HOMEディレクトリに伝播します。

   cd ORACLE_COMMON_HOME/common/bin
   
   ./unpack.sh -domain=MSERVER_HOME 
               -template=/full_path/edgdomaintemplateExtWCC.jar 
               -app_dir=APPLICATION_HOME 
               -overwrite_domain=true
   

   この例では、次のようになります。

   • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

   • edgdomaintemplateExtWCC.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

   • 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。

     上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

   • APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

   ヒント:

   packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

4. パック済のJARファイルへのフルパスが他のサーバーで使用可能な共有ボリューム上にある場合は、このステップをスキップします。それ以外の場合は、次のコマンドをWCCHOST1で実行し、ステップ1で作成したテンプレート・パックをWCCHOST2にコピーします。この時点では、WCPHOSTnサーバーにドメイン構成は必要ありません。

   scp /full_path/edgdomaintemplateExtWCC.jar oracle@WCCHOST2:/full_path/
   

5. 次のunpackコマンドを各リモート・ホストで実行して、前のステップでコピーしたドメイン・テンプレートをMSERVER_HOMEディレクトリにデプロイします。

   cd ORACLE_COMMON_HOME/common/bin
   
   ./unpack.sh -domain=MSERVER_HOME 
               -template=/full_path/edgdomaintemplateExtWCC.jar 
               -app_dir=APPLICATION_HOME 
               -overwrite_domain=true
   

   この例では、次のようになります。

   • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

   • edgdomaintemplateExtWCC.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

   • 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。

     上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

   • APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

   ヒント:

   packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

ドメイン解凍後のNodeManager構成の更新

ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。

注意:

• ListenAddressは通常、ASERVER_HOME nodemanagerと同じホストに常駐するMSERVER_HOME nodemanager上でリセットされます。このトポロジでは、WCCHOST1です。

• SOAサーバーとハードウェア・ロード・バランサ間のSSL通信を有効にする前のドメイン拡張では、CustomIdentityAliasに関してステップ2から4は当てはまらないことがあります。

各ホストのMSERVER_HOME/nodemanager/nodemanager.propertiesファイルについて、次のことを実行します。

1. 正しいListenAddressパラメータ値を確認して、必要な場合は値を再設定します。

   grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties

2. 次のコマンドの参照として、ドメイン構成ファイルから構成済アイデンティティ別名のリストを確認します。

   grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq

   注意:

   動的クラスタの使用時には、このリストにADMINVHNとワイルドカードの証明書アイデンティティ別名のみが表示されます。

   次の手順でnodemanger.properties CustomIdentityAliasプロパティを更新するときには、適切なホスト固有の証明書アイデンティティ別名を使用してください。

3. 現在のnodemanager.properties CustomIdentityAliasパラメータの値がホストの別名と一致していることを確認します。

   grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties

4. 必要に応じて、CustomIdentityAliasパラメータ値を、現在のホストに適した正しい別名文字列に再設定します。
5. nodemanagerプロセスを再起動します。

   kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
   nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

注意:

CustomIdentityAliasパラメータの詳細は、「カスタム・キーストアを使用するためのノード・マネージャの構成」を参照してください。

既存の管理対象サーバーの再起動と検証

ドメインが拡張され、すべてのサーバーのMSERVER_HOMEディレクトリに解凍されたので、既存のコンポーネントの管理対象サーバーを再起動します。

1. WebLogic Serverコンソールから、WebServices Manager Policy ManagerのWLS_WSMn管理対象サーバーを再起動します。
2. 別のブラウザ・ウィンドウから、URLを正常にロードすることで、WSM-PMアプリケーションが応答していることを確認します。

   http://wcpinternal.example.com/wsm-pm/validator
   

uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。 動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。

このステップは、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。

管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。

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

2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

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

4. 使用するクラスタ・タイプに適したオブジェクトに移動して編集します。

   1. 静的クラスタの場合、「サーバー」に移動し、編集する管理対象サーバーの名前をクリックします。

   2. 動的クラスタの場合、「クラスタ」→「サーバー・テンプレート」に移動し、編集するサーバー・テンプレートの名前をクリックします。

5. 編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。

   1. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

   2. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。

      MSERVER_HOME/servers/server_or_template_name/stage
      

      MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。静的クラスタを使用している場合、編集する管理対象サーバーの正しい名前で更新します。

      動的クラスタを使用している場合、テンプレート名はそのままにしておきます。

      例: /u02/oracle/config/domains/wcpedg_domain/servers/XYZ-server-template/stage

   3. 「アップロード・ディレクトリ名」を次の値に更新します。

      ASERVER_HOME/servers/AdminServer/upload
      

      ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

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

   5. 「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。

6. 該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。

7. 変更がアクティブになると表示されるステータス・メッセージを確認し、必要に応じて管理対象サーバーを再起動します。

動的クラスタを使用する際のリスニング・アドレスの構成

動的クラスタにおける動的な管理対象サーバーのデフォルト構成では、使用可能なネットワーク・インタフェースすべてでリスニングするようになっています。ほとんどの場合、デフォルトの構成は望ましくありません。動的クラスタを使用する際に、リスニング・アドレスを特定のアドレスに限定するには、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。リスニング・アドレスを変更した後に前の項で指定したテストURLを再確認し、クラスタ化された管理対象サーバーを再起動します。

管理対象サーバーWLS_WCC1の起動

WLS_WCC1管理対象サーバーを起動する手順は次のとおりです。

1. http://admin.example.com/consoleでOracle WebLogic Server管理コンソールにログインします。
2. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_WCC1管理対象サーバーを起動します。
   1. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。
   2. 「サーバー」をクリックします。
   3. 「サーバーのサマリー」ページで、「制御」タブを開きます。
   4. 「WLS_WCC1」を選択して、「起動」をクリックします。
3. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

WLS_WCC1管理対象サーバー上のコンテンツ・サーバーの構成

コンテンツ・サーバーを構成する手順は次のとおりです。

1. Oracle WebCenter Contentクラスタ構成に必要なランタイム・クラスタ・サブディレクトリを作成します。

   Oracle WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Contentエンタープライズ・デプロイメントの共有ディスクの場所は、ORACLE_RUNTIME/WCDomain/WCC_Clusterです。

   次のコマンドを実行して、必要なサブディレクトリを作成します。

   mkdir -p ORACLE_RUNTIME/domain_name/WCC_Cluster/cs/vault 
   mkdir -p ORACLE_RUNTIME/domain_name/WCC_Cluster/cs/weblayout 
   mkdir -p ORACLE_RUNTIME/domain_name/WCC_Cluster/cs/data/users/profiles

2. http://WCCHOST1:16200/csでweblogicユーザー名とパスワードを使用してWLS_WCC1にログインし、構成ページを表示します。
   Oracle WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Contentエンタープライズ・デプロイメントの共有ディスクの場所は、ORACLE_RUNTIME/wcpedg_domain/WCC_Clusterです。
3. 「サーバーの構成」ページで次の値を変更します。
   「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていることを確認します。
   • コンテンツ・サーバーのインスタンス・フォルダ: これをORACLE_RUNTIME/domain_name/WCC_Cluster/cs/に設定します

     例:/u01/oracle/runtime/wcpedg_domain/WCC_Cluster/cs/

   • ネイティブ・ファイル・リポジトリの場所: これをORACLE_RUNTIME/domain_name/WCC_Cluster/cs/vault/に設定します

     例:/u01/oracle/runtime/wcpedg_domain/WCC_Cluster/cs/vault/

   • Webレイアウト・フォルダ: これをORACLE_RUNTIME/domain_name/WCC_Cluster/cs/weblayout/に設定します

     例:/u01/oracle/runtime/wcpedg_domain/WCC_Cluster/cs/weblayout/

   • ユーザー・プロファイル・フォルダ: これをORACLE_RUNTIME/domain_name/WCC_Cluster/cs/data/users/profiles/に設定します

     例:/u01/oracle/runtime/wcpedg_domain/WCC_Cluster/cs/data/users/profiles/

   • サーバーのソケット・ポート: 4444
   • 受信ソケット接続アドレス・セキュリティ・フィルタ: 次のようにローカル・ホストとサーバーIPアドレスをパイプ区切りで指定します。

     127.0.0.1|0:0:0:0:0:0:0:1|WCCHOST1-IP|WCCHOST2-IP|WCPHOST1-IP|WCPHOST2-IP|WEBHOST1-IP|WEBHOST2-IP|wcp.example.com-IP|wcpinternal.example.com-IP|load-balancer-host-IP

     注意:

     内部仮想サーバーおよびプライマリ・インタフェース用のロード・バランサIPアドレスを含め、すべてのエントリにIPアドレスを使用する必要があります。これは、ロード・バランサのネットワーク・アドレス変換構成設定に依存します。
   • WebサーバーのHTTP/HTTPSアドレス: wcp.example.com:443
   • WebアドレスはHTTPSです: このチェック・ボックスを選択します。
   • コンテンツ・サーバーのインスタンス名: WCC_Cluster
   • コンテンツ・サーバーのインスタンス・ラベル: WCC_Cluster
   • サーバー・インスタンスの説明: WebCenter Contentクラスタ
   • 自動採番接頭辞: WCC_Cluster-
4. 終了する場合、「発行」をクリックします。
5. WebLogic Server管理コンソールを使用して、管理対象サーバーを再起動します。

管理サーバーのcwalletファイルの更新

コンテンツ・サーバーは、起動時にMSERVER_HOME/config/fmwconfigディレクトリにあるcwallet.ssoファイルを更新します。この変更は、元の管理サーバーに伝播する必要があります。

WebCenter ContentをWebCenter Portalエンタープライズ・デプロイメントに追加する場合、WC Contentホスト(WCCHOST1)から管理サーバーが稼働しているサーバーのASERVER_HOME構成ディレクトリにcwalletファイルをコピーする必要があります。EDGトポロジの場合、このリリースでは、どちらの場所もWCCHOST1上にあります。

これを行うには、WCCHOST1で次のコマンドを使用してcwallet.ssoファイルをASERVER_HOME/config/fmwconfig/にコピーします(複数行形式にはバックスラッシュを使用することに注意してください)。

cp MSERVER_HOME/config/fmwconfig/cwallet.sso \       
ASERVER_HOME/config/fmwconfig/cwallet.sso

注意:

WLS_WCCnサーバーでMSERVER_HOME/config/fmwconfig/ディレクトリにあるcwallet.ssoファイルを変更する操作を行った場合は、ASERVER_HOME/config/fmwconfigにあるWCCHOST1の管理サーバー・ドメイン構成ディレクトリにそのファイルをすぐにコピーする必要があります。

管理対象サーバーWLS_WCC2の起動

WLS_WCC2管理対象サーバーを起動する手順は次のとおりです。

1. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_WCC2管理対象サーバーを起動します。
   1. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。
   2. 「サーバー」をクリックします。
   3. 「サーバーのサマリー」ページで、「制御」タブを開きます。
   4. 「WLS_WCC2」,を選択して、「起動」をクリックします。
2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

WLS_WCC2管理対象サーバー上のコンテンツ・サーバーの構成

コンテンツ・サーバーを構成する手順は次のとおりです。

1. http://WCCHOST2:16200/csでweblogic管理ユーザー名とパスワードを使用してWLS_WCC2にログインし、構成ページを表示します。
   Oracle WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Contentエンタープライズ・デプロイメントの共有ディスクの場所は、ORACLE_RUNTIME/WCDomain/WCC_Clusterです。
2. 「サーバーの構成」ページで次の値を変更します。
   • コンテンツ・サーバーのインスタンス・フォルダ: これをORACLE_RUNTIME/WCDomain/WCC_Cluster/csに設定します。
   • ネイティブ・ファイル・リポジトリの場所: これをORACLE_RUNTIME/WCDomain/WCC_Cluster/cs/vaultに設定します。
   • Webレイアウト・フォルダ: これをORACLE_RUNTIME/WCDomain/WCC_Cluster/cs/weblayoutに設定します。
   • ユーザー・プロファイル・フォルダ: これをORACLE_RUNTIME/WCDomain/WCC_Cluster/cs/data/users/profilesに設定します。
   • コンテンツ・サーバーのURL接頭辞: /cs/ (デフォルト値)
   「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。
3. 終了する場合、「発行」をクリックします。
4. WebLogic Server管理コンソールを使用して、管理対象サーバーを再起動します。

GridLinkデータ・ソースの検証

サーバーが開始したら、GridLinkデータ・ソースが正しく構成され、ONS設定が正しいことを確認します。これらの手順を、作成した各GridLinkデータ・ソースで実行します。

• WebCenter ContentのGridLinkデータ・ソースの構成の確認
  
• GridLinkデータ・ソースのONSの構成の確認
  

WebCenter ContentのGridLinkデータ・ソースの構成の確認

WebCenter ContentのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。
2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。
3. 作成済のGridLinkデータ・ソース名をクリックします。
4. 「監視」タブをクリックします。
5. 「テスト」タブをクリックし、サーバーの1つを選択して「データ・ソースのテスト」をクリックします。
   構成が正しい場合、テストは成功します。
6. GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスでテストを繰り返します。

GridLinkデータ・ソースのONSの構成の確認

WebCenter ContentのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。

1. 管理コンソールの「ドメイン構造」ツリーで、「サービス」ノードを開いて「データ・ソース」をクリックします。
2. GridLinkデータ・ソースの名前をクリックします。
3. 「監視」タブをクリックします。
4. サーバーの名前(WLS_WCC1)をクリックします。
5. 「ONS」タブをクリックします。
6. 「ONS」タブで、「テスト」タブを選択します。
7. サーバーを選択し、「ONSのテスト」をクリックします。
   構成が正しい場合、テストは成功します。ONSのテストが失敗する場合、Oracle RACデータベース・ノードでONSサービスが実行されていることを確認します。

   [orcl@WCCDBHOST1 ~]$ srvctl status scan_listener
   SCAN Listener LISTENER_SCAN1 is enabled
   SCAN listener LISTENER_SCAN1 is running on node WCCDBHOST1
   SCAN Listener LISTENER_SCAN2 is enabled
   SCAN listener LISTENER_SCAN2 is running on node WCCDBHOST2
   SCAN Listener LISTENER_SCAN3 is enabled
   SCAN listener LISTENER_SCAN3 is running on node WCCDBHOST2 
    
    
   [orcl@WCCDBHOST1 ~]$ srvctl config nodeapps -s 
   ONS exists: Local port 6100, remote port 6200, EM port 2016 
    
    
   [orcl@WCCDBHOST1 ~]$ srvctl status nodeapps | grep ONS
   ONS is enabled
   ONS daemon is running on node: WCCDBHOST1
   ONS daemon is running on node: WCCDBHOST2

8. GridLinkデータ・ソースを使用するすべてのWebLogic ServerインスタンスでONSテストを繰り返します。

その他のパラメータの構成

テキスト・エディタを使用して、次のオプションを各クラスタ・ノードのMSERVER_HOME/ucm/cs/bin/WLS_WCCn_intradoc.cfgファイルに追加します。ここで指定されたディレクトリは、バスに直接アタッチされていて制御されているlocalディスク上にあり、NFSをマウントしたUNIX/Linuxまたはクラスタ化されたファイル・システム(たとえば、OCFS2、GFS2、GPFS)などのリモート・ファイル・システムではありません。

TraceDirectory=MSERVER_HOME/servers/WLS_WCCN/logs
EventDirectory=MSERVER_HOME/servers/WLS_WCCN/logs/event/
ArchiverDoLocks=true 
DisableSharedCacheChecking=true 

後続のNは、WLS_WCC1ではWCCHOST1、WLS_WCC2ではWCCHOST2のようにノードのサーバー名と一致している必要があります。

この変更は、「資格証明マップ経由のWebCenter Content管理ロールの付与」の項で説明する手順の最後で、すべてのWebCenter Content管理対象サーバーを再起動させてから有効になります。

注意:

ディレクトリは、WebCenter Contentログおよび任意のトレースを構成する場合は、ログおよびトレースを保持するために十分なスペースがあると判断される任意のローカル・ディスク・パスに配置できます。前述のパスは一案です。

Oracle WebCenter Contentのサービス再試行の構成

Oracle RACのフェイルオーバー時にログインの再試行を可能にするため、コンテンツ・サーバーのconfig.cfgファイル内の次のパラメータを設定する必要があります。

ServiceAllowRetry=true

この値が設定されていない場合、フェイルオーバーが開始されたときに、ユーザーは処理中の任意の操作を手動で再試行する必要があります。

Oracle WebCenter Contentのサービス再試行を構成する手順は次のとおりです。

1. コンテンツ・サーバー(http://WCCHOST1:16200/cs)にアクセスし、非LDAP WebLogic Serverの管理ユーザー名(たとえば、weblogic)とパスワードを使用してログインします。
2. 「管理」トレイまたはメニューで、「管理サーバー」、「一般構成」の順に選択します。
3. 「一般構成」ページで、「追加の構成変数」ボックスに、次のパラメータを追加します。

   ServiceAllowRetry=true

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

   この変更は、「資格証明マップ経由のWebCenter Content管理ロールの付与」の項で説明する手順の最後で、すべてのWebCenter Content管理対象サーバーを再起動させてから有効になります。

   注意:

   新しいパラメータはconfig.cfgファイルに含まれます。このファイルは次の場所にあります。

   ORACLE_RUNTIME/domain_name/cluster_name/cs/config/config.cfg

   (このファイルをテキスト・エディタで直接編集することもできます。必ずすべてのWebCenter Content管理対象サーバーを再起動してください。

資格証明マップ経由のWebCenter Content管理ロールの付与

資格証明マップを構成してWCPAdministrators LDAPグループにContent Server管理ロールを付与する必要があります。

WCPAdministrators LDAPグループは、以前に完了した「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」の項で作成されました。資格証明マップのこの構成により、すべての構成、管理およびメンテナンス・タスクのLDAP管理ユーザーの一貫した利用が保証されます。

資格証明マップを構成し、LDAPベースのWCPAdministratorsグループに必要なロール権限を付与する手順は次のとおりです。

1. weblogicアカウントを使用してコンテンツ・サーバーにログインします。
2. 「管理」メニューを開き、「資格証明マップ」を選択します。
3. 「マップ識別子」フィールドに、新しい資格証明マップの名前をLDAPAdminsと入力します。
4. 次の行を追加して、LDAPグループを複数の管理ロールにマップします。

   # Assign full set of administration roles to the LDAP WCPAdministrators group
        WCPAdministrators, admin
        WCPAdministrators, sysmanager
        WCPAdministrators, refineryadmin
        WCPAdministrators, rmaadmin
        WCPAdministrators, pcmadmin
        WCPAdministrators, ermadmin
   # Allow existing roles to propagate without mappings
        |#all|             , %%
   #
   # Comment the following if you are not implementing Accounts in Content Server
        WCPAdministrators, @#all(RWDA)
        WCPAdministrators, @#none(RWDA)

   注意:

   アカウントを実装しない場合、前述の例の最後の2行をコメント・アウトします。
5. 「更新」をクリックします。
6. 「管理」→「プロバイダ」に移動します。
7. 既存のJPSプロバイダの「info」リンクをクリックします。
8. 「資格証明マップ」パラメータが、リストされたマップ識別子をまだ持っていないことを確認します。
9. 「編集」ボタンをクリックします。
10. 前述のステップ3のマップ識別子の名前を「資格証明マップ」の値として入力します。

    注意:

    入力した値に、入力ミスや余分な文字が含まれていないかを再確認します。この設定が間違っていると、コンテンツ・サーバー・インスタンスにログインできなくなります。
11. 「更新」をクリックします。
12. WCCHOST2のコンテンツ・サーバーについて、変更したプロセスを繰り返します。

    1. LDAPAdmins資格証明マップが「資格証明マップ」ビューですでに選択可能であることを確認します。

    2. JpsUserProviderの編集を繰り返します(正しいLDAPAdmins資格証明マップ値がフォームに自動的に表示されても、各サーバーで発行して有効にする必要があることに注意してください)。

13. WCC_Cluster内の管理対象サーバーを再起動します。
14. weblogic_wcp LDAPユーザーを使用して各コンテンツ・サーバーにログインし、管理メニュー・オプションがユーザー・インタフェースに表示されていることを確認します。

    注意:

    プロバイダ構成の入力に間違いがあり、ログインできなくなってしまった場合は、jpsuserproviderデータ・ファイルを手動で修正する必要があります。この場合は、すべてのコンテンツ・サーバー・インスタンスを停止し、ORACLE_RUNTIME/DOMAIN_NAME/WCC_Cluster/cs/data/providers/jpsuserprovider/provider.hdaのProviderCredentialsMapパラメータの値を編集して、サーバー・インスタンスを1つずつ再起動してテストします。

WebCenter Contentクラスタ用のOracle HTTP Serverの構成

この項では、WebCenter Contentクラスタ用にOracle HTTP Serverを構成する手順を説明します。

• WLS_WCC管理対象サーバー用のOracle HTTP Serverの構成
  
• ロード・バランサを介したアクセスの検証
  

WLS_WCC管理対象サーバー用のOracle HTTP Serverの構成

Oracle WebCenter Contentクラスタにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、wcp.example.com仮想サーバーのパラメータを作成して定義するOracle HTTP Server構成ファイルを追加作成します。WLS_WCC管理対象サーバー用にOracle HTTP Serverを構成する手順は次のとおりです。

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

   cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/
   

   注意:

   インスタンスの構成ファイルと実行時ファイルにはそれぞれ別のディレクトリがあります。.../OHS/instances/ohsn/*フォルダにある実行時ファイルは、直接編集しないでください。.../OHS/ohsn/*構成ファイルのみ編集します。

2. wcp_vh.confファイルを作成し、次のディレクティブを追加します。

   <VirtualHost WEBHOST1:7777>
       ServerName https://wcp.example.com:443
       ServerAdmin [e-mail]
       RewriteEngine On
       RewriteOptions inherit
   </VirtualHost>

3. wcp_vh.confファイルで、次の行を<VirtualHost>および</VirtualHost>タグ内に追加します。

   注意:

   • 静的クラスタの場合: WCPHOST1およびWCPHOST2のポート番号は16200です。

   • 動的クラスタの場合: 「計算済リスニング・ポート」オプションが有効である場合、WCPHOST1のポート番号は16201、WCPHOST2のポート番号は16202です。

   • 次の例では、動的クラスタを使用していること、および「計算済リスニング・ポート」オプションが有効であることが前提です。

   #UCM
   <Location /cs>
      WebLogicCluster WCCHOST1:16201,WCCHOST2:16202
      WLSRequest ON
      WLCookieName JSESSIONID
      WLProxySSL ON
      WLProxySSLPassThrough ON
   </Location>
   
   <Location /adfAuthentication>
      WebLogicCluster WCCHOST1:16201,WCCHOST2:16202
      WLSRequest ON
      WLCookieName JSESSIONID
      WLProxySSL ON
      WLProxySSLPassThrough ON
   </Location>
   
   <Location /_ocsh>
      WebLogicCluster WCCHOST1:16201,WCCHOST2:16202
      WLSRequest ON
      WLCookieName JSESSIONID
      WLProxySSL ON
      WLProxySSLPassThrough ON
   </Location>
   

4. wcp_vh.confファイルを2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

   WEB_DOMAIN_HOME/config/fmwconfig/components/ohs2/moduleconf/
   

5. wcp_vh.confを編集して、<VirtualHost>ディレクティブ内のWEBHOST1の参照をWEBHOST2の参照に変更します。
6. WEBHOST1とWEBHOST2上のOracle HTTP Serverインスタンスを再起動します。

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

URLを検証して、Oracle HTTP ServerからWCC_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。

• URLの検証
  
• クラスタ・ノードの検証
  

URLの検証

URLを検証する手順は次のとおりです。

1. WLS_WCC2が稼動している状態で、WebLogic Server管理コンソールを使用してWLS_WCC1を停止します。
2. https://wcp.example.com/csにアクセスし、正しく動作していることを確認します。
3. WebLogic Server管理コンソールからWLS_WCC1を起動します。
4. WebLogic Server管理コンソールでWLS_WCC2を停止します。
5. https://wcp.example.com/csにアクセスし、正しく動作していることを確認します。

クラスタ・ノードを検証できます。このクラスタ・ノードは、ロード・バランサを介してトラフィック・バランシングが行われ、再びWeb層を介してトラフィック・バランシングが行われた後で転送されるクラスタ・ノードです。

クラスタ・ノードの検証

クラスタ・ノードを検証する手順は次のとおりです。

1. 管理ユーザーおよびパスワードの資格証明を使用して、次のWebCenter Contentページにログインします。

   https://wcp.example.com/cs/idcplg?IdcService=CONFIG_INFO

2. 「管理」の「WCC_Clusterの構成」ページを表示します。
3. ページの「オプションとその他」セクションで、右側の「Javaプロパティ」をクリックします。
4. weblogic.Nameの値を確認します。

   この値は、現在アクセスしているクラスタ・ノードを示します。

WebCenter Portal用のOracle WebCenter Contentの構成

この項では、WebCenter Portalで使用するOracle WebCenter Content Serverを構成するための必須タスクについて説明します。

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

• 必須のContent Serverコンポーネントの有効化
  
• Dynamic Converterコンポーネントの有効化および構成
  
• その他のContent Server機能の構成
  

必須のContent Serverコンポーネントの有効化

WebCenter Portalで、次のContent Serverコンポーネントを有効にします。

• WebCenterConfigure - 有効化すると、WebCenter Portal用のContent Serverのインスタンスを構成できます。

• Folders_gまたはFrameworkFolders - これらのコンポーネントのいずれかを有効にして、コンテンツ・サーバーに構成されたフォルダ・サービスを指定します。

  • Folders_g - コンテンツ・サーバーのコンテンツに階層フォルダ・インタフェースを提供します。Folders_gコンポーネントを使用する以前のリリースからパッチを適用されたOracle WebCenter Portalインスタンスの場合は、引き続きFolders_gを使用するか、FrameworkFolderインタフェースに移行できます。パフォーマンスを向上させてContent Serverの任意の新機能を使用できるようにするために、FrameworkFoldersインタフェースに移行することをお薦めします。

  • FrameworkFolders - 通常のファイル・システムと同様の階層フォルダ・インタフェースを提供し、リポジトリのコンテンツの一部またはすべてを編成および検索できます。FrameworkFoldersはスケーラブルなエンタープライズ・ソリューションであり、コンテンツ・サーバーのフォルダ・サービスとしてFolders_gに置き換わるコンポーネントです。Oracle WebCenter Portalの新規インストールの場合、Content ServerでFrameworkFoldersコンポーネントを有効にすることをお薦めします。

    注意:

    FrameworkFoldersコンポーネントを有効にする前に、AutoSuggestConfigコンポーネントを有効にする必要があります。

詳細なステップは、『Oracle WebCenter Portalの管理』の必須コンポーネントの有効化に関する項を参照してください。

注意:

Oracle WebCenter PortalがFolders_gコンポーネントを使用するように構成されているが、Folders_gが有効化されていない場合は、次の例外が表示されます。

SEVERE: UCM feature folders is not installed on server. at
oracle.webcenter.content.integration.spi.ucm.UCMBridge.getBridge(UCMBridge.java:349) ....

Oracle WebCenter PortalがFrameworkFoldersコンポーネントを使用するように構成されているが、FrameworkFoldersが有効化されていない場合は、次のメッセージが表示されます。

Foldering service from content server Folders_g and Portal Server Configuration FrameworkFolders do not match

Dynamic Converterコンポーネントの有効化および構成

このタスクはオプションですが、推奨です。

この構成は、Dynamic Converterによってオンザフライで生成される、HTMLレンディションが利用される、WebCenter PortalのSlide Previewer機能で必要です。

Dynamic Converterは、Dynamic Converterを有効にし、Dynamic Converterを使用するファイルの種類を定義する2つステップで構成します。詳細なステップは、『Oracle WebCenter Portalの管理』のDynamic Converterコンポーネントの構成に関する項を参照してください。

その他のContent Server機能の追加構成

その他のいくつかのContent Server機能は、必須ではないものの、WebCenter Portalエンタープライズ・デプロイメントにおける追加機能を提供します。たとえば、Site Studio、OracleTextSearchなどの機能を有効にすることも可能です。 

詳細説明および詳細ステップについては、『Oracle WebCenter Portalの管理』のContent Serverの構成ロードマップに関する項を参照してください。

JDBC永続ストアの有効化

Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。

静的クラスタまたは動的クラスタを使用するときには、次のガイドラインに従って確実にJDBCストアを使用してください。

• 静的クラスタの場合

  このガイドで静的クラスタに対してお薦めしたように、「高可用性のオプション」画面で、次のとおりに選択した場合は、すでにJMSとTLOGSの両方のJDBC永続ストアが構成されています。

  • 「JTAトランザクション・ログ永続性」を「JDBC TLogストア」に設定します。

  • 「JMSサーバー永続性」を「JMS JDBCストア」に設定します。

• 動的クラスタの場合

  構成ウィザードを使用して動的クラスタ用に構成できるのはJMSサーバー永続性のみです。JTAトランザクション・ログ永続性は、手動で構成する必要があります(この永続性が必要な場合)。このガイドで動的クラスタに対してお薦めしたように、「高可用性のオプション」画面で、次のとおりに選択した場合は、すでにJMSのJDBC永続ストアが構成されています。

  • 「JMSサーバー永続性」を「JMS JDBCストア」に設定します。

  • 「JTAトランザクション・ログ永続性」が「デフォルトの永続ストア」に設定されていることを確認します。

  JDBCストアでJTAトランザクション・ログを構成するには、追加のステップが必要になります。「TLOG用のJDBC永続ストア構成のロードマップ」を参照してください。

「高可用性のオプション」画面で、JMSとTLOGSの永続のためにJDBCを選択していなかった場合でも、その後のステップでJDBCストアを手動で構成できます。手動で構成する際の具体的な手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

注意:

「高可用性のオプション」画面は、自動サービス移行とJDBCストアの両方またはどちらかを使用するクラスタの作成時に、構成ウィザードの初回のセッション中に表示されます。それ以降、構成ウィザードを使用してドメインに追加されるクラスタには、選択済のHAオプションが自動的に適用されます。

自動サービス移行の有効化

この章でインストールした製品の高可用性を実現するには、適切にサービス移行を構成する必要があります。

静的クラスタまたは動的クラスタを使用するときには、次のガイドラインに従ってWebLogicサービスに必要な高可用性を指定していることを確認してください。

• 静的クラスタの場合

  自動サービス移行は、「高可用性のオプション」画面の「データベース・ベース」で「自動サービス移行の有効化」を選択していると、すでに構成されています。

  データベース・リースはすでに構成されていて、移行可能ターゲットはクラスタの適切なポリシーで作成されます。この設定が実施済の場合は、構成を検証します。検証の詳細は、「静的クラスタでの自動サービス移行の検証」を参照してください。

  構成ウィザードのセッション中に、このオプションを選択していない場合でも、その後のステップで自動移行を手動で構成できます。静的クラスタに対する完全なステップについては、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

• 動的クラスタの場合

  動的クラスタのサービス移行は、構成ウィザードを使用して構成することはできません。手動で構成する必要があります。次のステップを実行する必要があります。

  • クラスタのデータベース・リースを構成します。

  • JTAサービスとJMS永続ストアに適切な移行ポリシーを設定します。

  動的クラスタに対する完全なステップについては、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

注意:

「高可用性のオプション」画面は、自動サービス移行とJDBCストアの両方またはどちらかを使用するクラスタの作成時に、構成ウィザードの初回のセッション中に表示されます。それ以降、構成ウィザードを使用してドメインに追加されるクラスタには、選択済のHAオプションが自動的に適用されます。

構成のバックアップ

ベスト・プラクティスとして、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。ここまでのインストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。