Oracle® Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド 11gリリース1 (11.1.1.6.0) B55900-06 |
|
前 |
次 |
この章では、WebCenter Portalコンポーネントを含めるために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを構成ウィザードを使用して拡張する方法を説明します。
この章の内容は次のとおりです。
WebLogicドメインを拡張して、Oracle WebCenter Portalコンポーネントを追加することができます。表10-1には、WebCenter Portalコンポーネント用にドメインを拡張するために、WebCenter Portalを構成する手順と、その他の必要なタスクを示しています。
表10-1 WebCenter Portalコンポーネントを使用するためのドメインの拡張の手順
手順 | 説明 | 詳細 |
---|---|---|
WebCenter Portalコンポーネントを使用するためのドメインの拡張 |
第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogicドメインを拡張します。 |
第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オブジェクト・キャッシュを構成し、Spacesアプリケーションのパフォーマンスを向上させます。 |
第10.5項「Spaces_Cluster用のJavaオブジェクト・キャッシュの構成」 |
WebCenter Portalサービスの構成 |
ディスカッション、Analytics、アクティビティ・グラフおよび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ドメイン・ディレクトリを選択します。
ORACLE_BASE/admin/domain_name/aserver/domain_name
「次へ」をクリックします。
「拡張ソースの選択」画面で、次の手順を実行します。
「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。
次の製品を選択します。
Oracle WebCenter Spaces
Oracle WebCenterサービス・ポートレット
Oracle WebCenterページレット・プロデューサ
Oracleポートレット・プロデューサ
Oracle WebCenterディスカッション・サーバー
Oracle WebCenterアクティビティ・グラフ・エンジン
Oracle WebCenterパーソナライズ
Oracle Webcenter Analyticsコレクタ
次の製品はすでに選択されてグレー表示されています。これらは、第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順でドメインを作成したときに選択したものです。
WebLogic Serverの基本ドメイン
Oracle JRF
Oracle WSM Policy Manager
「次へ」をクリックします。
このドメインでは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コンポーネント・スキーマの構成」画面で、次の手順を実行します。
最初のGridLinkデータ・ソース・スキーマである、WebCenterDSスキーマを選択します。
次の各フィールドに値を入力して、RCUでシードされたGridLink Oracle RACデータベースの接続情報を指定します。
ドライバ: 「OracleのGridLinkConnectionsドライバ(Thin)、バージョン: 10以降」を選択します。
サービス名: Oracle RACデータベースのサービス名と、続けてドメイン名を小文字で入力します。たとえば、wcpedg.mycompany.com
です。
ユーザー名: データベースのスキーマ所有者の完全な名前(接頭辞を含む)を入力します。表10-2に示すユーザー名は、RCUでスキーマを作成する際に接頭辞としてwcpedg
が使用されていると想定しています。
パスワード: データベース・スキーマ所有者のパスワードを入力します。
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.mycompany.com:1521
注意: データベース・バージョンがSCANをサポートしない場合は次を実行します。
|
ONSホスト: データベースからの通知のとおり、Oracle RACデータベースとONSリモート・ポートのSCANアドレスを入力します。
[orcl@db-scan1 ~]$ 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情報が入力されていることを確認します。
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、テストするスキーマを選択し(または「すべて選択」をクリックし)、「接続のテスト」をクリックします。
「接続結果ログ」に結果が表示されます。スキーマを含むデータベースに正常に接続できたことを確認します。できなかった場合は、「前」をクリックし、前の画面に戻り、入力を修正し、テストを再試行します。
すべての接続に成功したら「次へ」をクリックします。
「オプションの構成を選択」画面で、次の項目を選択します。
管理対象サーバー、クラスタ、およびマシン
デプロイメントとサービス
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、次の管理対象サーバー(表10-3)を追加します。
表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)を追加します。
注意: WSM-PM_Clusterはリストにすでにあるはずです。 |
表10-4 クラスタ
名前 | クラスタ・メッセージング・モード | マルチキャスト・アドレス | マルチキャスト・ポート | クラスタ・アドレス |
---|---|---|---|---|
Spaces_Cluster |
ユニキャスト |
該当なし |
該当なし |
空白のままにします。 |
Portlet_Cluster |
ユニキャスト |
該当なし |
該当なし |
空白のままにします。 |
Collab_Cluster |
ユニキャスト |
該当なし |
該当なし |
空白のままにします。 |
Utilities_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マシン」タブをクリックし、次の4つのエントリがあることを確認します。
表10-5 マシン
名前 | ノード・マネージャのリスニング・アドレス |
---|---|
SOAHOST1 |
SOAHOST1 SOAHOST1は、第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」で構成ウィザードを実行したときにすでに構成されています。 |
SOAHOST2 |
SOAHOST2 SOAHOST2は、第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」で構成ウィザードを実行したときにすでに構成されています。 |
WCPHOST1 |
WCPHOST1 |
WCPHOST2 |
WCPHOST2 |
その他すべてのフィールドはデフォルト値のままにします。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。
ADMINHOST:
AdminServer
SOAHOST1:
WLS_WSM1
SOAHOST2:
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にのみターゲット設定する必要があります。
「次へ」をクリックします。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
mds-owsmをWSM-PM_ClusterとAdminServerの両方のターゲットとします。
「次へ」をクリックします。
「構成サマリー」画面では、(ドメインを拡張しているので)画面に表示される情報は変更しないようにしてください。「拡張」をクリックします。
「ドメインの拡張」画面で、「完了」をクリックします。
この構成を有効にするには、管理サーバーを起動する必要があります。
管理サーバーを、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で起動します。
構成ウィザードでドメインを拡張した後は、次の手順に従って構成後タスクを実行します。
この項の内容は次のとおりです。
このマニュアルでは、WebCenter Portalを使用するためのドメインの拡張手順の完了後、管理サーバーで様々なノードを認証するために適切な証明書を設定します。そのため、WebCenter Portalの管理対象サーバーのホスト名検証を無効化して、様々なWebLogicサーバーを管理するときにエラーが出ないようにします。エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第11.5項「SOAHOST2およびWCPHOST2でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。
ホスト名検証を無効化するには:
Oracle WebLogic Server管理コンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」を選択します。「サーバーの概要」ページが表示されます。
表の「名前」列で「WC_Spaces1」(これはハイパーリンクとして表示されています)を選択します。「設定」ページが表示されます。
「SSL」タブを選択します。
表示されたページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
これらの手順を、管理対象サーバーWC_Spaces2、WC_Portlet1、WC_Portlet2、WC_Collaboration1、WC_Collaboration2、WC_Utilities1およびWC_Utilities2に対して繰り返します。
変更を保存してアクティブ化します。
この変更内容を有効にするには、管理サーバーおよびノード・マネージャを再起動する必要があります。
管理サーバーを再起動する手順は、第8章「SOAHOST1での管理サーバーの起動」を参照してください。
SOAHOST1でノード・マネージャを再起動するには、第10章「SOAHOST1でのノード・マネージャの起動」を参照してください。
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
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。
起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。
管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。
次の一連のコマンドを使用し、SOAHOST1でpack
コマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=wcdomaintemplate.jar -template_name=wcdomaintemplate
次のようにunpack
コマンドをSOAHOST1上で実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=wcdomaintemplate.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/domain_name/mserver/apps
注意: unpackコマンドで |
SOAHOST1の構成が完了したら、unpackユーティリティを使用してSOAHOST2、WCPHOST1およびWCPHOST2に構成を伝播し、伝播した構成を検証します。
この項の内容は次のとおりです。
第10.4.1項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」
第10.4.3項「WCPHOST1でのWC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの起動」
第10.4.5項「WC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの検証」
第10.4.6項「WCPHOST2でのWC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの起動」
第10.4.7項「WC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの検証」
構成したばかりのドメインをSOAHOST2、WCPHOST1およびWCPHOST2にunpackユーティリティを使用して伝播できます。
注意: システム間でミドルウェア・ホームが共有されている場合は、ドメイン・テンプレートが適切なディレクトリに存在しているはずなので、次のステップ1を省略できます。 |
ドメイン構成を伝播する手順は次のとおりです。
SOAHOST1で次のコマンドを実行し、すでに作成されているテンプレート・ファイルをSOAHOST2、WCPHOST1およびWCPHOSTにコピーします。
scp wcdomaintemplate.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin
scp wcdomaintemplate.jar oracle@WCPHOST1:ORACLE_COMMON_HOME/common/bin
scp wcdomaintemplate.jar oracle@WCPHOST2:ORACLE_COMMON_HOME/common/bin
unpack
コマンドをSOAHOST2、WCPHOST1とWCPHOST2で実行し、伝播されたテンプレートを解凍します。
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/ -template=wcdomaintemplate.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
WCPHOST1およびWCPHOST2に対し、前述の手順を繰り返します。
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は省略できます。このインスタンスでは、 |
WCPHOST1およびWCPHOST2の両方で次のコマンドを実行し、ノード・マネージャを起動します。
WCPHOST1> cd WL_HOME/server/bin
WCPHOST1> ./startNodeManager.sh
WCPHOST2> cd WL_HOME/server/bin
WCPHOST2> ./startNodeManager.sh
管理コンソールを使用し、WC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーを起動するには、次の手順を実行します。
管理コンソール(http://ADMINVHN:7001/console
)にアクセスします。
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「制御」タブを開きます。
「WC_Spaces1」、「WC_Portlet1」、「WC_Utilities1」および「WC_Collaboration1」を選択します。
「起動」をクリックします。
WC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1の伝播を行う前に、前に作成したGridLinkデータ・ソースの構成とOracle Notification Service (ONS)の設定がデータ・ソースに対して正しいことを検証する必要があります。
GridLinkデータ・ソースとWebCenter Portalの構成を確認するには、次の手順を実行します。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
作成済のGridLinkデータ・ソース名をクリックします。
「テスト」タブをクリックし、WebCenter Portal管理対象サーバーの1つを選択して「データ・ソースのテスト」をクリックします。
構成が正しい場合、テストは成功します。
GridLinkデータ・ソースを使用する各WebCenter管理対象サーバーに、テストを繰り返します。
「監視」タブをクリックし、サーバー名の1つをクリックします。
「ONS」→「テスト」タブをクリックします。
たとえば、WC_Spaces1など、WebCenter Portal管理対象サーバーの1つを選択し、「ONSのテスト」をクリックします。
構成が正しい場合、ONSのテストは成功します。ONSのテストが失敗する場合、Oracle RACデータベース・ノードでONSサービスが実行されていることを確認します。
[orcl@db-scan1 ~]$ srvctl status scan_listener SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node db-scan1 SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node db-scan2 SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node db-scan3 [orcl@db-scan1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016 [orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS ONS is enabled ONS daemon is running on node: db-scan1 ONS daemon is running on node: db-scan2
GridLinkデータ・ソースを使用する各WebCenter Portal管理対象サーバーに、ONSテストを繰り返します。
WCPHOST1上のすべてのWebCenter Portal管理対象サーバーが起動され稼働中であることを確認するには、次の手順を実行します。
次のURLをテストして、管理対象サーバーがアクセス可能であることを確認します。
http://WCPHOST1:9000/webcenter
http://WCPHOST1:9000/webcenterhelp
http://WCPHOST1:9000/rss
http://WCPHOST1:9000/rest
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)を構成できます。このローカル・キャッシュは、Spacesアプリケーションのパフォーマンスを向上させるために提供されています。
Javaオブジェクト・キャッシュはMW_HOME/oracle_common/bin/configure-joc.py
スクリプトを使用して構成できます。これは管理対象サーバーでのJOCの構成に使用できるPythonスクリプトです。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが稼働中であることが求められます。WLSTオンライン・モードの詳細は、『Oracle Application Server管理者ガイド』の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構成全体で共通です。
注意: 検出ポートには任意の空きポートを指定できます。 |
高可用性環境で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
このスクリプトを使用すると、次のJOCの構成も実行できます。
指定されたすべての管理対象サーバー用のJOCの構成
クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたら'n'を入力し、プロンプトが表示されたら管理対象サーバーと検出ポートを指定します。次に例を示します。
Do you want to specify a cluster name (y/n) <y>n Enter Managed Server and Discover Port (eg WC_Spaces1:9988,WC_Spaces2:9988) : WC_Spaces1:9988,WC_Spaces2:9988
一部の管理対象サーバー用のJOC構成の除外
このスクリプトでは、JOC構成のDistributeModeを'false'に設定する管理対象サーバーのリストを指定できます。JOC構成から除外するサーバーがあるかどうかを尋ねるプロンプトが表示されたら'y'を入力し、プロンプトが表示されたら除外する管理対象サーバー名を入力します。次に例を示します。
Do you want to exclude any server(s) from JOC configuration (y/n) <n>y Exclude Managed Server List (eg Server1,Server2) : WC_Spaces1,WC_Spaces2
すべての管理対象サーバーに対して分散モードを無効にします。
このスクリプトでは、指定されたクラスタのすべての管理対象サーバーに対する分散を無効にできます。分散モードに関するプロンプトが表示されたら'false'を指定します。デフォルトでは、分散モードは'true'に設定されています。
CacheWatcherユーティリティを使用してJOCの構成を確認します。『Oracle Fusion Middleware高可用性ガイド』を参照してください。
『Oracle Fusion Middleware高可用性ガイド』で説明しているように、Oracle WebLogic管理コンソールで「HAパワー・ツール」タブを使用してJavaオブジェクト・キャッシュ(JOC)を構成できます。
(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の通信用に予約されているポートです。
WCPHOST1をWCPHOST2に、WCPHOST2をWCPHOST1に替えて、WC_Collaboration2に対して手順1と2を繰り返します。
-Dtangosol.coherence.wka1=WCPHOST2 -Dtangosol.coherence.wka2=WCPHOST1 -Dtangosol.coherence.localhost=WCPHOST2 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.localport=8089
WC_Collaborationサーバーを再起動します。
ユニキャスト・クラスタの場合は、まず、第10.6項「マルチキャストからユニキャストへのディスカッションの変換」の手順をすべて完了します。
ディスカッション・クラスタ内のすべてのメンバーが互いに通信できるようにするには、次の手順を実行します。
次の場所にあるクラスタ内の各メンバー用のディスカッション・サーバーの管理コンソールにログインします。
http://host:port/owc_discussions/admin
「キャッシュ設定」を選択します。
「キャッシュ機能」セクションで、「クラスタリング」が「有効」に設定されていることを確認します。
サーバーは、クラスタを結合すると、画面の上部に表示されます。
「ツール」セクションで、「クラスタ・メンバーをすべてリセット」と「キャッシュ・ウォームアップ・タスクの開始」を選択します。クラスタのすべてのメンバーで、キャッシュのウォームアップ・タスクを繰り返します。
クラスタのすべてのメンバーに対して、手順1から4を繰り返します。
サーバーは、クラスタを結合すると、画面の上部に表示されます。
Analyticsコレクタは、デフォルトでローカルのSpacesアプリケーションと1対1の関係で通信できるよう構成されています(コレクタはlocalhost
をリスニングします)。Analyticsコレクタは、別途構成する必要はありません。
ただし、localhostにイベント・メッセージを送信するよう、Spacesアプリケーションを構成する必要があります。
SpacesアプリケーションをAnalyticsコレクタに接続するには、次の手順を実行します。
Spacesアプリケーションが実行されている管理対象サーバーに、WLSTを使用し、たとえば次のように接続します。
MW_HOME/wc/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "WCPHOST1:9000")
WC_Spacesサーバーのホストとポートに接続します。
SpacesアプリケーションとAnalyticsコレクタ間に接続を作成し、それをデフォルトの接続にします(default=1
)。
次に例を示します。
createAnalyticsCollectorConnection(appName="webcenter", name="HAConn1", isUnicast=1, collectorHost="localhost", collectorPort=31314, isEnabled=1, timeout=30, default=1)
Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのcreateAnalyticsCollectorConnectionに関する説明も参照してください。
変更を確認します。
listDefaultAnalyticsCollectorConnection(appName="webcenter")
Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのlistDefaultAnalyticsCollectorConnectionに関する説明も参照してください。
アクティビティ・グラフはシングルトンとして実行する必要があります。クラスタ環境では、すべてのアクティビティ・グラフ・エンジン・アプリケーションのインスタンスは1つを除いてすべて無効化する必要があります。
アクティビティ・グラフ・エンジン・アプリケーションを無効化する手順は次のとおりです。
管理コンソールにログインします。
WC_Utilities1とWC_Utilities2サーバーをシャットダウンします。
「デプロイメント」を選択します。
「ロックして編集」をクリックします。
これらの各デプロイメントのターゲットを変更します。
activitygraph-engines (11.1.1.6.0)
oracle.webcenter.activitygraph.enginelib(11.1.1,11.1.1)
oracle.webcenter.activitygraph.lib(11.1.1,11.1.1)
デプロイメントを選択します。
「ターゲット」タブを選択します。
「ターゲットの変更」をクリックします。
Utilities_Clusterのデプロイメントのターゲットが、クラスタの一部/管理対象サーバーの1つのみになっていることを確認します。その他のサーバーおよびクラスタのターゲットは変更しないでください。
「OK」をクリックして変更を保存します。
3つのデプロイメントのすべての手順を完了したら、「すべての変更のアクティブ化」をクリックします。
WC_Utilities1サーバーとWC_Utilities2サーバーを起動します。
アクティビティ・グラフは1つのノードでのみ実行されているので、このノードが失われたり、管理対象サーバーが使用不可能であったりすると、アクティビティ・グラフが使用不可能になります。ノードに障害が発生した場合は、アクティビティ・グラフをクラスタ内で使用可能な他のいずれかの管理対象サーバーに手動でデプロイできます。
注意: アクティビティ・グラフはフェイルオーバーできない他のコンポーネントと同じサーバー上にあるため、サーバーの移行をアクティビティ・グラフには構成しないことをお薦めします。サーバーの移行の詳細は、第14章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。 |
WebCenter Portal REST APIを使用する場合、この項で説明するサーバー側の構成を実行する必要があります。
RESTセキュリティ・トークンを正しく機能させる、資格証明ストア内のエントリをシードするには、次の手順を実行します。
コマンドラインのOracle WebLogic Scripting Tool(WLST)を使用して管理サーバーに接続します。例:
MW_HOME/wc/common/bin/wlst.sh
次の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 Fusion Middleware Oracle WebCenter Portal管理者ガイドを参照してください。
この項の内容は次のとおりです。
第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」
Oracle HTTP ServerがWebCenter Portalクラスタにルーティングできるようにするには、クラスタ内のノードのリストをWebLogicClusterパラメータに設定する必要があります。次の行をすべてのWEBHOSTマシンのOHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.conf
ファイルに追加します。管理サーバーとSOAサーバーの以前の設定をすべて保持しておきます。完了したら、すべてのHTTP Serversを再起動します。
# Virtual Host for wcp.mycompany.com holds all the external URLs. The Virtual Host should already exist # and any existing Location blocks should be kept. NameVirtualHost *:7777 <VirtualHost *:7777> ServerName https://wcp.mycompany.com:443 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit # Spaces Application <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> 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 #The WebLogicHost below should be set to the Host on which ActivityGraph is running. <Location /activitygraph-engines> WebLogicHost WCPHOST1 WebLogicPort 9003 WLProxySSL ON WLProxySSLPassThrough ON </Location> </VirtualHost> # Virtual host entry for internal http URL. # This should already be in the config file. The new Location blocks go inside of it NameVirtualHost *:7777 <VirtualHost *:7777> ServerName wcpinternal.mycompany.com:80 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit # 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:9001,WCPHOST2:9002 SetHandler weblogic-handler </Location> </VirtualHost> #Virtual host for SharePoint access <VirtualHost *:7777> ServerName wcp-spaces.mycompany.com ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit #SharePoint entry point <Location /> WebLogicCluster WCPHOST1:9000,WCPHOST2:9000 SetHandler weblogic-handler WLProxySSL ON WLProxySSLPassThrough ON </Location> # Spaces Application <Location /webcenter> Deny from all </Location> <Location /webcenterhelp> Deny from all </Location> <Location /rss> Deny from all </Location> <Location /rest> Deny from all </Location> </VirtualHost>
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 WebLogic ServerにおけるWebサーバー・プラグインの使用』ガイドを参照してください。
Microsoftクライアントの組込みについては、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドの概要および詳細な手順を参照してください。
具体的には、これらのクライアントに別のコンテキスト・ルートを提供するには、別に仮想ホストを作成する必要があります。手順については、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドの仮想ホストでのSSOの構成に関する説明を参照してください。
Windows認証サービスを正しく構成する手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのMicrosoftクライアント用のSSOの構成に関する手順を参照してください。
次のURLにアクセスできることを確認します。
http://WEBHOSTn:7777/webcenter
http://WEBHOSTn:7777/webcenterhelp
http://WEBHOSTn:7777/rss
http://WEBHOSTn:7777/rest
http://WEBHOSTn:7777/pagelets
http://WEBHOSTn:7777/portalTools
http://WEBHOSTn:7777/wsrp-tools
http://WEBHOSTn:7777/owc_discussions
http://WEBHOSTn:7777/activitygraph-engines/Login.jsp
http://WEBHOSTn:7777/wcps/api/property/resourceIndex
ここで、WEBHOSTn
は各Oracle HTTP Serverホスト(たとえば、WEBHOST1
、WEBHOST2
)です。
次のURLにアクセスできることを確認します。
https://wcp.mycompany.com/webcenter
https://wcp.mycompany.com/webcenterhelp
https://wcp.mycompany.com/rss
https://wcp.mycompany.com/rest
https://wcp.mycompany.com/pagelets
https://wcp.mycompany.com/portalTools
https://wcp.mycompany.com/wsrp-tools
https://wcp.mycompany.com/owc_discussions
https://wcp.mycompany.com/activitygraph-engines/Login.jsp
https://wcp.mycompany.com/wcps/api/property/resourceIndex
拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。
バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、このガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、このガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、このガイドで別のホストへの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
管理サーバーをバックアップするには、SOHOST1で次のコマンドを実行します。
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name