| Oracle® Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド 11gリリース1 (11.1.1.9.0) B55900-11 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド 11gリリース1 (11.1.1.9.0) B55900-11 |
|
前 |
次 |
この章では、WebCenter Portalコンポーネントを含めるために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを構成ウィザードを使用して拡張する方法を説明します。
この章には次のトピックが含まれます:
Oracle WebCenter Portalコンポーネントを追加するためにWebLogic Serverドメインを拡張します。表10-1には、WebCenter Portalコンポーネント用にドメインを拡張するために、WebCenter Portalを構成する手順と、その他の必要なタスクを示しています。
表10-1 WebCenter Portalコンポーネントを使用するためのドメインの拡張の手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
WebCenter Portalコンポーネントを使用するためのドメインの拡張 |
第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogic Serverドメインを拡張します。 |
第10.2項「WebCenter Portalコンポーネントを使用するための構成ウィザードを使用したドメインの拡張」 |
|
WebCenter Portal管理対象サーバーのホスト名の検証の無効化 |
ホスト名の検証を無効にします。 |
第10.3.1項「WebCenter Portal管理対象サーバーに対するホスト名検証の無効化」 |
|
構成後のタスクの実行 |
構成後タスクの手順に従います。 |
|
|
ドメイン構成の管理対象サーバーのドメイン・ディレクトリへの伝播 |
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。 |
第10.3.3項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更の伝播」 |
|
ドメイン構成のSOAHOST2、WCPHOST1、WCPHOST2への伝播 |
その他すべてのホストにドメイン構成を伝播します。 |
第10.4.1項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」 |
|
Javaオブジェクト・キャッシュの構成 |
Javaオブジェクト・キャッシュを構成し、WebCenter Portalアプリケーションのパフォーマンスを向上させます。 |
第10.5項「Spaces_Cluster用のJavaオブジェクト・キャッシュの構成」 |
|
WebCenter Portalのツールとサービスの構成 |
ディスカッション、分析、アクティビティ・グラフおよびREST APIサービスを構成します。 |
第10.6項「マルチキャストからユニキャストへのディスカッションの変換」 第10.7項「ディスカッション・サーバーでのクラスタリングの構成」 |
|
拡張したドメインでのOracle HTTP Serverの構成 |
管理対象サーバーとともにOracle HTTP Serverを構成し、アクセスを検証します。 |
第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」 |
|
WebCenter Portalの構成のバックアップ |
新しく拡張したドメイン構成をバックアップします。 |
第10.12項「WebCenter Portalの構成のバックアップ」 |
WebCenter Portalコンポーネントを含めるために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを、構成ウィザードを使用して拡張できます。
構成ウィザードを使用してドメインを拡張する手順は次のとおりです。
リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。
ドメイン内の管理サーバーおよびすべての管理対象サーバーを停止します。
構成ウィザードの場所にディレクトリを変更します。これは共通のOracleホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するSOAHOST1から実行することに注意してください)。
cd ORACLE_COMMON_HOME/common/bin
./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
「WebLogicドメイン・ディレクトリ」画面で、WebLogic Serverドメイン・ディレクトリを選択します。
ORACLE_BASE/admin/domain_name/aserver/domain_name
「次へ」をクリックします。
「拡張ソースの選択」画面で、次の手順を実行します。
「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。
次の製品を選択します。
Oracle WebCenter Spaces 脚注 1
Oracle WebCenterサービス・ポートレット
Oracle WebCenterページレット・プロデューサ
Oracleポートレット・プロデューサ
Oracle WebCenterディスカッション・サーバー
Oracle WebCenterアクティビティ・グラフ・エンジン
Oracle WebCenterパーソナライズ
Oracle WebCenter Analyticsコレクタ
次の製品はすでに選択されてグレー表示されています。これらは、ドメインを作成した際(第8.3項)またはOracle SOA Suiteコンポーネント用に拡張した際(第9.3項)に選択されました。
WebLogic Serverの基本ドメイン
Oracle SOA Suite
Oracle Enterprise Manager
Oracle WSM Policy Manager
Oracle JRF
「次へ」をクリックします。
このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。
画面に次のコンポーネント・スキーマが表示されることを確認します。表10-2に示すスキーマ所有者名は、RCUでスキーマを作成する際に接頭辞としてwcpedgが使用されていると想定しています。
表10-2 コンポーネント・スキーマの値
| コンポーネント・スキーマ | スキーマ所有者 |
|---|---|
|
WebCenterDSスキーマ |
|
|
ActivitiesDSスキーマ |
|
|
DiscussionDSスキーマ |
|
|
PersonalizationDSスキーマ |
|
|
PortletDSスキーマ |
|
|
Portlet-ServicesProducerDSスキーマ |
|
|
WC-ServicesProducerDS |
|
|
WebCenterMDSスキーマ |
|
|
PersonalizationMDSスキーマ |
|
|
mds-PageletProducerDSスキーマ |
|
|
mds-ServicesProducerDSスキーマ |
|
表10-2のコンポーネント・スキーマの横のすべてのチェック・ボックスを選択します。
RACの構成には、(付録A「Oracle RACでのマルチ・データ・ソースの使用」で説明した)「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます。
ここの手順では、「GridLinkへ変換」を選択します。
「次へ」をクリックします。
「GridLink RACコンポーネント・スキーマの構成」画面で、次の手順を実行します。
表10-2に示された11個のすべてのデータ・ソース・スキーマを選択します。
「ユーザー名」を除くすべてのフィールドに値を入力して、RCUでシードされたGridLink Oracle RACデータベースの接続情報を指定します。
ドライバ: 「OracleのGridLinkConnectionsドライバ(Thin)、バージョン: 10以降」を選択します。
サービス名: Oracle RACデータベースのサービス名と、続けてドメイン名を小文字で入力します。たとえば、wcpedg.example.comです。
パスワード: データベース・スキーマ所有者のパスワードを入力します。
FANの有効化: このオプションを選択します。
SSLの有効化: このオプションを選択解除します。
Oracle Notification Service (ONS)の通知の暗号化するためにSSLが選択されている場合は、「ウォレット・ファイル」と「ウォレット・パスワード」に適切な詳細を入力します。
サービス・リスナー: 使用しているOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。このプロトコルは、TCPである必要があります。
Oracle RACノードの追加または削除時にSCANアドレスを含むGridLinkデータ・ソースを更新する必要がないよう、サービス・リスナー(とOSNホスト)の指定にはSCANアドレスを使用することをお薦めします。SCANアドレスを判断するには、データベースに対してremote_listenerパラメータを問い合せます。
SQL>show parameter remote_listener; NAME TYPE VALUE ----- ------ ------- remote_listener string db-scan.example.com:1521
|
注意: データベース・バージョンがSCANをサポートしない場合は次を実行します。
|
ONSホスト: データベースからの通知のとおり、Oracle RACデータベースとONSリモート・ポートのSCANアドレスを入力します。
[orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016
|
注意: Oracle Database 11gリリース1 (11.1)の場合、データベースのONSサービスのホスト名とポートを入力します。例:
および
|
たとえば、次のActivitiesDSスキーマを選択し、適切な詳細を指定します。
表10-2のすべてのWebCenter Portalスキーマに、GridLink情報が入力されていることを確認します。
「次へ」をクリックします。
ユーザー名: 11個のデータ・ソースを1つずつ選択し、データベース・スキーマ所有者の完全なユーザー名(接頭辞を含む)を入力します。表10-2に示されたユーザー名では、RCUでスキーマを作成する際の接頭辞はwcpedgでした。
「JDBCデータ・ソースのテスト」画面で、テストするスキーマを選択し(または「すべて選択」をクリックし)、「接続のテスト」をクリックします。
「接続結果ログ」に結果が表示されます。スキーマを含むデータベースに正常に接続できたことを確認します。できなかった場合は、「前」をクリックし、前の画面に戻り、入力を修正し、テストを再試行します。
すべての接続に成功したら「次へ」をクリックします。
「オプションの構成を選択」画面で、次の項目を選択します。
管理対象サーバー、クラスタ、およびマシン
デプロイメントとサービス
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、表10-3に示す管理対象サーバーを変更します。
|
注意: この表の管理対象サーバー(WC_Spacesn、WC_Collaborationn、WC_UtilitiesnおよびWC_Portletn)は、画面上では異なる順序で表示されることがあります。 |
表10-3 管理対象サーバー
| 名前 | サーバー | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
|
WC_Spaces1 |
WCPHOST1 |
9000 |
該当なし |
いいえ |
|
WC_Spaces2 |
WCPHOST2 |
9000 |
該当なし |
いいえ |
|
WC_Portlet1 |
WCPHOST1 |
9001 |
該当なし |
いいえ |
|
WC_Portlet2 |
WCPHOST2 |
9001 |
該当なし |
いいえ |
|
WC_Collaboration1 |
WCPHOST1 |
9002 |
該当なし |
いいえ |
|
WC_Collaboration2 |
WCPHOST2 |
9002 |
該当なし |
いいえ |
|
WC_Utilities1 |
WCPHOST1 |
9003 |
該当なし |
いいえ |
|
WC_Utilities2 |
WCPHOST2 |
9003 |
該当なし |
いいえ |
|
注意:
|
「次へ」をクリックします。
「クラスタの構成」画面で、4つ新しいクラスタ(表10-4)を追加します。
表10-4 クラスタ
| 名前 | クラスタ・メッセージング・モード | マルチキャスト・アドレス | マルチキャスト・ポート | クラスタ・アドレス |
|---|---|---|---|---|
|
Spaces_Cluster |
ユニキャスト |
該当なし |
該当なし |
空白のままにします。 |
|
Portlet_Cluster |
ユニキャスト |
該当なし |
該当なし |
空白のままにします。 |
|
Collab_Cluster |
ユニキャスト |
該当なし |
該当なし |
空白のままにします。 |
|
Utilities_Cluster |
ユニキャスト |
該当なし |
該当なし |
空白のままにします。 |
|
注意: WSM-PM_ClusterおよびSOA_Clusterは、リストにすでに表示されている必要があります。 |
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。
Spaces_Cluster:
WC_Spaces1
WC_Spaces2
Portlet_Cluster:
WC_Portlet1
WC_Portlet2
Collab_Cluster:
WC_Collaboration1
WC_Collaboration2
Utilities_Cluster:
WC_Utilities1
WC_Utilities2
「次へ」をクリックします。
「マシンの構成」画面で「Unixマシン」タブをクリックし、表10-5に示されている5つのエントリがあることを確認します。
表10-5 マシン
| 名前 | ノード・マネージャのリスニング・アドレス |
|---|---|
|
SOAHOST1 |
SOAHOST1 SOAHOST1は、第8.3項「SOAHOST1での構成ウィザードによるドメインの作成」で構成ウィザードを実行したときにすでに構成されています。 |
|
SOAHOST2 |
SOAHOST2 SOAHOST2は、第8.3項「SOAHOST1での構成ウィザードによるドメインの作成」で構成ウィザードを実行したときにすでに構成されています。 |
|
ADMINHOST |
localhost |
|
WCPHOST1 |
WCPHOST1 |
|
WCPHOST2 |
WCPHOST2 |
その他すべてのフィールドはデフォルト値のままにします。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。
ADMINHOST:
AdminServer
SOAHOST1:
WLS_SOA1
WLS_WSM1
SOAHOST2:
WLS_SOA2
WLS_WSM2
WCPHOST1:
WC_Spaces1
WC_Portlet1
WC_Collaboration1
WC_Utilities1
WCPHOST2:
WC_Spaces2
WC_Portlet2
WC_Collaboration2
WC_Utilities2
|
注意: 構成ウィザードにデフォルトで表示される元のサーバーの名前を変更することはできますが、絶対に削除はしないでください。 |
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
wsm-pmアプリケーションは、WSM-PM_Clusterにターゲット設定する必要があります。
SOA_ClusterにWebサービス・マネージャをデプロイする場合は、wsm-pmアプリケーションもSOA_Clusterにターゲット設定されていることを確認します。
WebCenter Portalに固有のすべてのクラスタから、wsm-pmアプリケーションのターゲット設定を削除します。
「次へ」をクリックします。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次の設定をします。
mds-owsmは、WSM-PM_ClusterおよびAdminServerにターゲット設定する必要があります。
(オプションで、他のクラスタ/サーバーが存在する場合は、それらにmds-owsmをターゲット設定することもできます。)
「次へ」をクリックします。
「構成のサマリ」画面で、「拡張」をクリックします。
「ドメインの拡張」画面で、「完了」をクリックします。
この構成を有効にするには、管理サーバーを起動する必要があります。
管理サーバーを、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で起動します。
構成ウィザードでドメインを拡張した後は、次の手順に従って構成後タスクを実行します。
この項には次のトピックが含まれます:
このガイドで説明するエンタープライズ・デプロイメントでは、WebCenter Portalを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。異なるWebLogic Serverを管理する場合のエラーを防止するには、WebCenter Portal管理対象サーバー(WC_Spacesn、WC_Portletn、WC_Collaborationn、WC_Utilitiesn)のホスト名検証を無効化する必要があります。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。
エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第11.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。
startNodeManager.shスクリプトを使用してノード・マネージャを再起動します。
SOAHOST1でノード・マネージャを再起動する手順は次のとおりです。
ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。
シェルのフォアグラウンドで実行されている場合は、[Ctrl]を押しながら[C]を押します。
シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、killコマンドを使用して停止します。例:
ps -ef | grep NodeManager orcl 9139 9120 0 Mar03 pts/6 00:00:00 /bin/sh ./startNodeManager.sh kill -9 9139
ノード・マネージャを起動します。
cd WL_HOME/server/bin ./startNodeManager.sh
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。
起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。
管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリをバックアップします。
tar -cpzf BACKUP_LOCATION/edg10.3.3-doman_name.tgz ORACLE_BASE/admin/domain_name
次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=wcpdomaintemplateExtWCP.jar -template_name=wcpdomaintemplateExtWCP
|
注意: 前回のpack/unpack処理からの指定されたテンプレート・パックjarファイルが存在する場合は、別の名前(wcpdomaintemplateExtWCP2.jarなど)を選択します。 |
次のようにunpackコマンドをSOAHOST1上で実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=wcpdomaintemplateExtWCP.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
|
注意: unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、このunpack処理の後に再適用する必要があります。 |
SOAHOST1の構成が完了したら、unpackユーティリティを使用してSOAHOST2、WCPHOST1およびWCPHOST2に構成を伝播し、伝播した構成を検証します。
この項には次のトピックが含まれます:
第10.4.1項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」
第10.4.4項「WCPHOST1でのWC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの起動」
第10.4.6項「WC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの検証」
第10.4.7項「WCPHOST2でのWC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの起動」
第10.4.8項「WC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの検証」
構成したばかりのドメインをSOAHOST2、WCPHOST1およびWCPHOST2にunpackユーティリティを使用して伝播できます。
|
注意: システム間でミドルウェア・ホームが共有されている場合は、ドメイン・テンプレートが適切なディレクトリに存在しているはずなので、次のステップ1を省略できます。 |
ドメイン構成を伝播する手順は次のとおりです。
SOAHOST1で次のコマンドを実行し、すでに作成されているテンプレート・ファイルをSOAHOST2、WCPHOST1およびWCPHOSTにコピーします。
scp wcpdomaintemplateExtWCP.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin
scp wcpdomaintemplateExtWCP.jar oracle@WCPHOST1:ORACLE_COMMON_HOME/common/bin
scp wcpdomaintemplateExtWCP.jar oracle@WCPHOST2:ORACLE_COMMON_HOME/common/bin
必要なアプリケーション・デプロイメント・ファイルを管理サーバーからSOAHOST2、WCPHOST1およびWCPHOST2にコピーします。
|
注意: 管理サーバーがマウントされているかどうかに関係なく、管理サーバーが作成したconfig.xml内のパスは、すべてのマシン上で使用可能である必要があります。これを達成するには、欠落しているフォルダまたはファイル、あるいはその両方を、プライマリ・ドメインから新しいノードのローカル・ファイル・システムにコピーします。 |
SOAHOST2、WCPHOST1およびWCPHOST2に、必要ディレクトリ構造を作成します。
mkdir -p ORACLE_BASE/admin/domain_name/aserver/applications/domain_name
SOAHOST1の管理サーバーから、必要なファイルを転送します。
cd ORACLE_BASE/admin/domain_name/aserver/applications/domain_name
scp -r oracle@SOAHOST1:ORACLE_BASE/admin/domainname/aserver/applications/domain_name
unpackコマンドをSOAHOST2、WCPHOST1とWCPHOST2で実行し、伝播されたテンプレートを解凍します。
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=wcpdomaintemplateExtWCP.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
WCPHOST1およびWCPHOST2について、前述の手順を繰り返します。
ドメイン変更の伝播後、uploadおよびstageディレクトリを更新します。詳細な手順は、第8.5.2項「uploadおよびstageディレクトリの絶対パスへの変更」を参照してください。
startNodeManager.shスクリプトを使用し、ノード・マネージャを起動します。
WCPHOST1およびWCPHOST2上のノード・マネージャを起動する手順:
WCPHOST1とWCPHOST2の両方でノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティを'true'に設定します。
WCPHOSTn> cd ORACLE_COMMON_HOME/common/bin
WCPHOSTn> ./setNMProps.sh
|
注意: WebCenter Portalサーバーが、(第3章「エンタープライズ・デプロイメント用のネットワークの準備」のとおり、)MiddlewareホームをSOAとローカルまたは共有記憶域で共有し、SOAがすでに構成されている場合、手順1は省略できます。このインスタンスでは、setNMProps.shは再度実行する必要がなく、ノード・マネージャはすでにSOAHOST1およびSOAHOST2で実行されています。 |
WCPHOST1およびWCPHOST2の両方で次のコマンドを実行し、ノード・マネージャを起動します。
WCPHOST1> cd WL_HOME/server/bin
WCPHOST1> ./startNodeManager.sh
WCPHOST2> cd WL_HOME/server/bin
WCPHOST2> ./startNodeManager.sh
WCPHOST1上のWC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーを起動する手順:
管理コンソール(http://ADMINVHN:7001/console)にアクセスします。
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「制御」タブを開きます。
「WLS_WSM1」および「WLS_WSM2」を選択します。
「起動」をクリックします。
WLS_WSM1およびWLS_WSM2管理対象サーバーが稼働中であることを確認します。
「WC_Spaces1」、「WC_Portlet1」、「WC_Utilities1」および「WC_Collaboration1」を選択します。
「起動」をクリックします。
WCPHOST2でWC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2を起動する前に、前に作成したGridLinkデータ・ソースの構成とOracle Notification Service (ONS)の設定がデータ・ソースに対して正しいことを検証する必要があります。
GridLinkデータ・ソースとWebCenter Portalの構成を確認するには、次の手順を実行します。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
「データ・ソース」ページ(図10-1)で、作成されたGridLinkデータ・ソースの名前をクリックします。
「データ・ソースのテスト」ページ(図10-2)で、「監視」タブをクリックしてから「テスト」タブをクリックし、いずれかのWebCenter Portal管理対象サーバー(WC_Spaces1など)を選択し、「データ・ソースのテスト」をクリックします。
構成が正しい場合、テストは成功します。
GridLinkデータ・ソースを使用するWCPHOST1上で実行されている各WebCenter Portal管理対象サーバーに対してテストを繰り返します。
「監視」タブをクリックし、サーバー名の1つをクリックします。
「ONS」→「テスト」タブをクリックします。
たとえば、WC_Spaces1など、WebCenter Portal管理対象サーバーの1つを選択し、「ONSのテスト」をクリックします。
構成が正しい場合、ONSのテストは成功します。ONSのテストが失敗する場合、Oracle RACデータベース・ノードでONSサービスが実行されていることを確認します。
[orcl@CUSTDBHOST1 ~]$ srvctl status scan_listener SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node CUSTDBHOST1 SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node CUSTDBHOST2 SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node CUSTDBHOST2 [orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016 [orcl@CUSTDBHOST1 ~]$ srvctl status nodeapps | grep ONS ONS is enabled ONS daemon is running on node: CUSTDBHOST1 ONS daemon is running on node: CUSTDBHOST2
GridLinkデータ・ソースを使用する各WebCenter Portal管理対象サーバーに、ONSテストを繰り返します。
WCPHOST1上のすべてのWebCenter Portal管理対象サーバーが稼働中であることを確認する手順:
次のURLをテストして、管理対象サーバーがアクセス可能であることを確認します。
http://WCPHOST1:9000/webcenter
http://WCPHOST1:9000/webcenterhelp
http://WCPHOST1:9000/rss
http://WCPHOST1:9001/pagelets
http://WCPHOST1:9001/portalTools
http://WCPHOST1:9001/wsrp-tools
http://WCPHOST1:9002/owc_discussions
http://WCPHOST1:9003/activitygraph-engines/Login.jsp
http://WCPHOST1:9003/wcps/api/property/resourceIndex
すべてのデプロイメントがアクティブであることを確認します。管理コンソールで、「デプロイ」を選択します。
いずれかに障害が発生した場合は、ログ・ファイルでエラーを確認します。ログ・ファイルは次の場所にあります。
ORACLE_BASE/admin/domain_name/mserver/domain_home/servers/server_name/logs
管理コンソールを使用してWC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーを起動する手順:
管理コンソール(http://ADMINVHN:7001/console)にアクセスします。
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「制御」タブを開きます。
「WC_Spaces2」、「WC_Portlet2」、「WC_Utilities2」および「WC_Collaboration2」を選択します。
「起動」をクリックします。
WCPHOST2上のすべてのWebCenter Portal管理対象サーバーが稼働中であることを確認する手順:
次のURLをテストして、管理対象サーバーがアクセス可能であることを確認します。
http://WCPHOST2:9000/webcenter
http://WCPHOST2:9000/webcenterhelp
http://WCPHOST2:9000/rss
http://WCPHOST2:9000/rest
http://WCPHOST2:9001/pagelets
http://WCPHOST2:9001/portalTools
http://WCPHOST2:9001/wsrp-tools
http://WCPHOST2:9002/owc_discussions
http://WCPHOST2:9003/wcps/api/property/resourceIndex
すべてのデプロイメントがアクティブであることを確認します。管理コンソールで、「デプロイ」を選択します。
いずれかに障害が発生した場合は、ログ・ファイルでエラーを確認します。ログ・ファイルは次の場所にあります。
ORACLE_BASE/admin/domain_name/mserver/domain_home/servers/server_name/logs
Spaces_Cluster内のすべての管理対象サーバー間のJavaオブジェクト・キャッシュ(JOC)を構成します。このローカル・キャッシュは、WebCenter Portalアプリケーションのパフォーマンスを向上させるために提供されています。
Javaオブジェクト・キャッシュはMW_HOME/oracle_common/bin/configure-joc.pyスクリプトを使用して構成できます。これはPythonスクリプトであり、管理対象サーバーでJOCを構成するために使用できます。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが稼働中であることが求められます。WLSTのオンライン・モードに関する一般的な情報は、『管理者ガイド』のOracle WebLogic Scripting Tool (WLST)の使用の開始に関する項を参照してください。
WebCenter Portal管理対象サーバーのJavaオブジェクト・キャッシュを構成する手順:
たとえば、次のようにWLSTを使用し管理サーバーに接続します。
MW_HOME/wc/common/bin/wlst.sh
$ connect()
Oracle WebLogicの管理ユーザー名とパスワードの入力を求められたら、これらを入力します。
WLSTを使用して管理サーバーに接続後、execfileコマンドを使用してスクリプトを開始します。たとえば、次のようにします。
wls:/mydomain/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")
指定されたクラスタのすべての管理対象サーバーのJOCを構成します。
クラスタ名を指定するかどうかを尋ねるスクリプト・プロンプトが表示されたらyを入力し、プロンプトに従ってクラスタ名および検出ポートを指定します。これによって、指定したクラスタの管理対象サーバーがすべて検出され、JOCが構成されます。検出ポートはクラスタのJOC構成全体で共通です。
|
注意: Discover Portには任意の空きポートを指定できます。 |
高可用性環境でconfigure-joc.pyを使用する場合の手順を次に示します。
execfile("MW_HOME/oracle_common/bin/configure-joc.py")
.
Enter Hostnames (eg host1,host2) : WCPHOST1,WCPHOST2
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : Spaces_Cluster
.
Enter Discover Port : 9988
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n
CacheWatcherユーティリティを使用してJOC構成を確認します。詳細は、『Oracle Fusion Middleware高可用性ガイド』の「分散Javaオブジェクト・キャッシュの構成」を参照してください。
(Collab_Cluster内のすべての管理対象サーバー上の)ディスカッションをマルチキャストからユニキャストに変換するには、関係する起動パラメータを追加します。
Oracle WebLogic Server管理コンソールで、「サーバー」→「WC_Collaboration1」→「構成」→「サーバーの起動」を選択します。
「引数」ボックスに次の引数を追加します。
-Dtangosol.coherence.wka1=WCPHOST1 -Dtangosol.coherence.wka2=WCPHOST2 -Dtangosol.coherence.localhost=WCPHOST1 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.localport=8089
WCPHOST1は、WC_Collaboration1を実行しているホストです。
ポート8089は、WebCenter Coherenceの通信用に予約されているポートです。
正確に同じパラメータ値を使用して、WC_Collaboration2に手順1と手順2を繰り返します。
-Dtangosol.coherence.wka1=WCPHOST1 -Dtangosol.coherence.wka2=WCPHOST2 -Dtangosol.coherence.localhost=WCPHOST2 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.localport=8089
WC_Collaborationサーバーを再起動します。
ユニキャスト・クラスタの場合は、まず、第10.6項「マルチキャストからユニキャストへのディスカッションの変換」の手順をすべて完了します。
ディスカッション・クラスタ内のすべてのメンバーが互いに通信できるようにするには、次の手順を実行します。
次の場所にあるクラスタ内の各メンバー用のディスカッション・サーバーの管理コンソールにログインします。
http://WCPHOSTn:9002/owc_discussions/admin
「キャッシュ設定」を選択します。
キャッシュ機能セクション(図10-4)で、「クラスタリング」が「有効」に設定されていることを確認します。
サーバーは、クラスタを結合すると、画面の上部に表示されます。
|
注意: クラスタ化されたキャッシュが有効な場合、ディスカッション・コンテンツの更新は即座にリフレッシュされません。ユーザーは、いつでも「リフレッシュ」アイコンをクリックして、強制的に手動でリフレッシュできます。 |
「ツール」セクション(図10-5)で、「クラスタ・メンバーをすべてリセット」と「キャッシュ・ウォームアップ・タスクの開始」を選択します。クラスタのすべてのメンバーで、キャッシュのウォームアップ・タスクを繰り返します。
クラスタのすべてのメンバーに対して、手順1から4を繰り返します。
サーバーは、クラスタを結合すると、画面の上部に表示されます。
分析コレクタは、デフォルトでローカルのWebCenter Portalアプリケーションと1対1の関係で通信できるよう構成されています(コレクタはlocalhostをリスニングします)。分析コレクタは、別途構成する必要はありません。
ただし、localhostにイベント・メッセージを送信するよう、WebCenter Portalアプリケーションを構成する必要があります。
WebCenter Portalアプリケーションを分析コレクタに接続する手順は次のとおりです。
WLSTを使用して、WebCenter Portalアプリケーションが実行されている管理対象サーバーに、たとえば次のように接続します。
MW_HOME/wc/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "WCPHOST1:9000")
WC_Spacesサーバーのホストとポートに接続します。
WebCenter Portalアプリケーションと分析コレクタの間に接続を作成し、それをデフォルトの接続にします(default=1)。
例:
createAnalyticsCollectorConnection(appName="webcenter", connectionName="HAConn1", isUnicast=1, collectorHost="localhost", collectorPort=31314, isEnabled=1, timeout=30, default=1)
『WebLogic Scripting Toolコマンド・リファレンス』のcreateAnalyticsCollectorConnectionに関する項も参照してください。
変更を確認します。
listDefaultAnalyticsCollectorConnection(appName="webcenter")
『WebLogic Scripting Toolコマンド・リファレンス』のlistDefaultAnalyticsCollectorConnectionに関する項も参照してください。
分析タスク・フローがデータを表示するには、アクティビティ・グラフ・エンジンが1回以上実行されている必要があります。詳細は、第10.9項「アクティビティ・グラフの構成」を参照してください。
アクティビティ・グラフはシングルトンとして実行する必要があります。クラスタ環境では、すべてのアクティビティ・グラフ・アプリケーションのインスタンスは1つを除いてすべて無効化する必要があります。
アクティビティ・グラフ・エンジン・アプリケーションを無効化する手順は次のとおりです。
管理コンソールにログインします。
WC_Spacesn、WC_Portletn、WC_CollaborationnおよびWC_Utilitiesnサーバーを停止します。
「デプロイメント」を選択します。
「ロックして編集」をクリックします。
これらの各デプロイメントのターゲットを変更します。
activitygraph-engines(11.1.1.4.0)
oracle.webcenter.activitygraph.enginelib (11.1.1,11.1.1)
oracle.webcenter.activitygraph.lib (11.1.1,11.1.1)
デプロイメントを選択します。
「ターゲット」タブを選択します。
エンタープライズ・アプリケーションの場合は、「エンタープライズ・アプリケーション」チェック・ボックスを選択します。
「ターゲットの変更」をクリックします。
Utilities_Clusterのターゲット設定を、「クラスタのすべてのサーバー」からWC_Utilities1管理対象サーバーのみに変更します。その他のターゲットの詳細は変更しないでください。
「はい」をクリックして変更を保存します。
3つのデプロイメントのすべての手順を完了したら、「すべての変更のアクティブ化」をクリックします。
WC_Spacesn、WC_Portletn、WC_CollaborationnおよびWC_Utilitiesnサーバーを起動します。
アクティビティ・グラフが推奨事項を表示し、分析タスク・フローがデータを表示するには、アクティビティ・グラフ・エンジンが1回以上実行されている必要があります。
WebLogic管理ユーザーとして、アクティビティ・グラフ(http://WCPHOST1:9003/activitygraph-engines)にログインします。
このページにアクセスするには、Administratorsグループのメンバーである必要があります。
「開始」/「実行」をクリックして、統計の収集を開始します。
『Oracle WebCenter Portalの管理』のアクティビティ・グラフのデータの準備に関する項も参照してください。
アクティビティ・グラフは1つのノードでのみ実行されているので、このノードが失われたり、管理対象サーバーが使用不可能であったりすると、アクティビティ・グラフが使用不可能になります。ノードに障害が発生した場合は、アクティビティ・グラフをクラスタ内で使用可能な他のいずれかの管理対象サーバーに手動でデプロイできます。
|
注意: アクティビティ・グラフはフェイルオーバーできない他のコンポーネントと同じサーバー上にあるため、サーバーの移行をアクティビティ・グラフには構成しないことをお薦めします。サーバーの移行の詳細は、第14章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。 |
WebCenter Portal REST APIを使用する場合、この項で説明するサーバー側の構成を実行する必要があります。
RESTセキュリティ・トークンを正しく機能させる、資格証明ストア内のエントリをシードするには、次の手順を実行します。
コマンド行のOracle WebLogic Scripting Tool (WLST)を使用して管理サーバーに接続します。例:
MW_HOME/wc/common/bin/wlst.sh
connect()
次のWLSTのコマンドを実行して、資格証明ストアを構成します。
createCred(map="o.webcenter.jf.csf.map", key="keygen.algorithm",
user="keygen.algorithm", password="AES")
createCred(map="o.webcenter.jf.csf.map", key="cipher.transformation",
user="cipher.transformation", password="AES/CBC/PKCS5Padding")
後でOAMのRESTポリシーを構成する必要があります(第15章「RESTポリシーの更新」)。
REST APIの詳細は、『Oracle WebCenter PortalおよびOracle Jdeveloperでのポータルの開発』を参照してください。
この項には次のトピックが含まれます:
第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」
Oracle HTTP ServerがWebCenter Portalクラスタにルーティングできるようにするには、クラスタ内のノードのリストをWebLogicClusterパラメータに設定する必要があります。
WEBHOST1とWEBHOST2上で、次のディレクトリにあるwcp_vh.confおよびwcpinternal_vh.confファイルにディレクティブを追加します。
ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
第7.6項「仮想ホストの定義」の指示に従って、wcp_vh.confおよびwcpinternal_vh.confファイルを作成しておく必要があります。
|
注意: Oracle SOA Suiteに対する以前の構成は残してください。 |
例10-1に太字で示したディレクティブを、wcp_vh.confファイルの<VirtualHost>タグ内に追加します。
wcp_vh.confファイルは例10-1のように表示されます。
例10-1 wcp_vh.confファイル
<VirtualHost *:7777>
ServerName https://wcp.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# UMS prefs
<Location /sdpmessaging/userprefs-ui>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# SOA composer application
<Location /soa/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# WebCenter Portal Application (previously called Spaces)
<Location /webcenter>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /webcenterhelp>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /rss>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /rest>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Discussions
<Location /owc_discussions/admin>
WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /owc_discussions
WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Portlets
<Location /pagelets>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /portalTools>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /wsrp-tools>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Personalization
<Location /wcps>
WebLogicCluster WCPHOST1:9003,WCPHOST2:9003
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
#Activity Graph
<Location /activitygraph-engines>
WebLogicCluster WCPHOST1:9003
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>
|
注意: エンタープライズ・デプロイメントにMicrosoft Officeの統合またはMicrosoft SharePointサーバーへのアクセスが必要な場合は、仮想ホストの追加が必要です。詳細は、『Oracle WebCenter Portalの管理』のMicrosoft Office統合の管理に関する項を参照してください。 |
例10-2に太字で示したディレクティブを、wcpinternal_vh.confファイルに追加します。
wcpinternal_vh.confファイルは、例10-2のように表示されます。
例10-2 wcpinternal_vh.confファイル
<VirtualHost *:7777>
ServerName wcpinternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
</Location>
# Worklist
<Location /integration>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>
# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>
# Portlet Internal access
<Location /pagelets>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
</Location>
<Location /portalTools>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
</Location>
<Location /wsrp-tools>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
</Location>
# Discussions Internal access
<Location /owc_discussions>
WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
SetHandler weblogic-handler
</Location>
</VirtualHost>
WEBHOST1およびWEBHOST2で、Oracle HTTP Serverを再起動します。
WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このノードのリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。
例としていくつかのシナリオを次に示します。
例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時にその場で検出されます。
例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのメンバーをすべてリストに記述した場合は、Oracle HTTP Serverの起動時にそのうちの1つ以上を実行しておくことで、クラスタに確実に到達できます。
WebLogic Serverプラグインの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』を参照してください。
Microsoftクライアントに対応するには、『Oracle WebCenter Portalの管理』で説明する概要および詳細手順を参照してください。
具体的には、これらのクライアントに別のコンテキスト・ルートを提供するには、別に仮想ホストを作成する必要があります。手順については、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』の仮想ホストでのSSOの構成に関する項を参照してください。
Windows認証サービスを正しく構成するには、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のMicrosoftクライアント用のSSOの構成に関する項の手順に従ってください。
次のロード・バランサURLを検証し、Oracle HTTP ServerからWebCenter Portalクラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。
https://wcp.example.com/webcenter
https://wcp.example.com/webcenterhelp
https://wcp.example.com/rss
https://wcp.example.com/rest/api/resourceIndex
https://wcp.example.com/pagelets
https://wcp.example.com/portalTools
https://wcp.example.com/wsrp-tools
https://wcp.example.com/owc_discussions
https://wcp.example.com/wcps/api/property/resourceIndex
https://wcp.example.com/activitygraph-engines/Login.jsp
拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。
バックアップを必要とするOracle HTTP Serverのデータの詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法の詳細は、『Oracle Fusion Middleware管理者ガイド』のコンポーネントのリカバリに関する項とコンポーネント・ホストが失われた後のリカバリに関する項を、ホストの損失からのリカバリに固有の推奨事項はこのガイドの別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。
データベースのバックアップの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドも参照してください。
ドメイン構成をバックアップする手順は次のとおりです。
Web層をバックアップする手順は次のとおりです。
opmnctlを使用してインスタンスを停止します。
ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。
tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。
tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE
opmnctlを使用してインスタンスを起動します。
ORACLE_BASE/admin/instance_name/bin/opmnctl startall
データベースのバックアップを取ります。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。
管理サーバーのドメイン・ディレクトリをバックアップします。バックアップを実行してドメイン構成を保存します。構成ファイルは次のディレクトリにあります。
ORACLE_BASE/admin/domain_name
管理サーバーをバックアップするには、SOAHOST1で次のコマンドを実行します。
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
脚注の凡例
脚注 1: 前のリリースでは、すぐに使用できるアプリケーションWebCenter Portalはスペースと呼ばれていました。構成ウィザードの一部の画面では、前の名前で呼ばれています。